Políticas e protocolos
      Voltar para o início
      1. Central de Conhecimento
      2. Manuais e Artigos
      3. Políticas e protocolos

      Especificações de Políticas de Tratamento de Informações

      O documento detalha as políticas de tratamento de informações do myHotel com fornecedores e clientes, explicando os protocolos de segurança e os processos que garantem padrões ótimos.

      Extrato

       

      Neste documento, detalham-se todas as políticas de tratamento de informações da myHotel com seus fornecedores ou clientes (conforme o caso). Nele, explicam-se, com o maior detalhamento possível, todos os protocolos de segurança implementados, bem como os processos adjacentes a esses protocolos que garantem que as informações sejam tratadas com os melhores padrões de precaução e segurança do mercado.

       

      Esta documentação será dividida em 4 partes:

      1. Informações na nuvem
      2. Transferência de informações com clientes ou fornecedores
      3. Conformidade com o GDPR
      4. Controle de acessos da Fidelity Suite

       

      1.- INFORMAÇÕES NA NUVEM

       

      myHotel possui um único provedor de nuvem onde as informações de todos os seus clientes são armazenadas: AWS. A seguir, detalha-se um esquema da infraestrutura dos aplicativos da myHotel na AWS para uma melhor compreensão:

      Os aspectos mais importantes a serem mencionados aqui são as diferentes camadas de segurança que myHotel possui para lidar com potenciais violações de segurança:

      • API Gateway: Essa ferramenta da AWS tem uma capacidade considerável para aplicar políticas de segurança, a fim de ter rastreabilidade e alertas sobre quem, onde e quando fez diferentes chamadas às aplicações.
        • Em primeiro lugar, apenas as aplicações no ELB são capazes de se conectar com api.myhotel.io através de IAM configurados na AWS, garantindo que apenas elas possam fazer consultas, e nenhuma outra máquina possa. 
        • Em segundo lugar, a myHotel implementou o CloudTrail nesta camada para ter rastreabilidade dos pedidos, tokens, etc., a cada segundo possível, para fins de uma auditoria minuciosa em caso de violação de segurança. 
        • Em terceiro lugar, a myHotel implementou o CloudWatch para receber alertas em tempo real sobre certas métricas predefinidas pela empresa, fornecendo indicadores de possíveis ataques, pedidos acima de um número normal e outras métricas semelhantes.
      • JAVA com Spring, Spring Security e Hibernate: Todas as aplicações são desenvolvidas em JAVA com Spring, Spring Security e Hibernate, ferramentas que facilitam as camadas de segurança utilizadas dentro da aplicação e a comunicação com o exterior. Isso adiciona uma camada muito robusta de segurança a nível de código dos aplicativos. Garante que a comunicação entre os aplicativos e as BBDD seja segura, utilizando os protocolos de segurança do Spring Security que garantem anonimização, proteção de chaves e transporte da informação por meios criptografados, entre outras funções importantes.
      • Criptografia de informações em BD: Tudo contido em nossas BDs está criptografado de acordo com as políticas de segurança da Amazon Web Services (AWS).

       

      2.- TRANSFERÊNCIA DE INFORMAÇÃO COM CLIENTES OU FORNECEDORES

       

      myHotel possui 2 grandes categorias de transferência de informações entre seus clientes ou fornecedores:

      A. myHotel "lê para fora" informações disponibilizadas por seu cliente/fornecedor.

       

      No seguinte esquema, é apresentado um diagrama de fluxo de informações entre o myHotel e seus clientes ou fornecedores, no caso em que o fornecedor disponibiliza as informações por meio de algum canal possível:

       

       

      Há 4 grandes maneiras de acessar essas informações dos fornecedores:

      • API / Webservice: o fornecedor ou cliente disponibiliza um ponto de extremidade de uma API que o myHotel lê periodicamente para manter um registro dos hóspedes que passam pelas propriedades. A restrição que o myHotel impõe é que pelo menos este ponto de extremidade seja através de HTTPS. Cada cliente ou fornecedor é livre para adicionar camadas adicionais de segurança, como OAuth, OAuth 2.0, login via Google / Facebook, etc.
      • Banco de Dados (BBDD): o cliente ou fornecedor nos fornece um caminho e credenciais de acesso a um banco de dados com privilégios apenas de leitura, para que o myHotel possa ler periodicamente as informações. Assim como a API, todas as conexões são feitas através de HTTPS, e o cliente é livre para adicionar camadas adicionais de segurança, sendo o filtro por IP o mais comum.
      • Email: o myHotel possui um e-mail que é reports@myhotel.cl / reports@fidelitycx.com, exclusivamente para receber relatórios de seus clientes ou fornecedores. Este e-mail não é acessível por nenhuma pessoa física, apenas por sistemas que utilizam a API do Google para esse fim, garantindo que apenas as informações configuradas nesta mesma aplicação sejam lidas por propriedade e não compartilhadas entre diferentes propriedades.
      • FTP / SFTP / FTPS: geralmente, FTPS ou SFTP são usados para a transferência de informações, pois isso garante uma camada de segurança maior do que apenas usuário e senha (como no caso de um FTP normal). Isso assegura que as informações que viajam entre o myHotel e o fornecedor sejam transmitidas por meio de um canal seguro e criptografado.

       

      Por fim, assim como a infraestrutura da Fidelity Suite, apenas o aplicativo tem acesso ao banco de dados por meio de políticas de segurança IAM, e não um programador ou engenheiro do myHotel. Isso garante que ninguém possa "olhar" as informações diretamente no banco de dados."

       

      B. La myHotel recebe informações através de uma API.

       

      En el esquema a seguir, é apresentado um diagrama de fluxo de informações entre o fornecedor e myHotel no caso em que o fornecedor utiliza um API / Webservice fornecido pelo myHotel:

       

       

      En relação ao esquema anterior, ao ser implementado em um Load Balancer da AWS que permite a criação de políticas de segurança personalizadas, o myHotel geralmente cria um filtro por IP de origem para garantir que apenas esses IPs sejam autorizados a utilizar a API, reduzindo assim as possibilidades de ciberataques. Embora essa configuração seja a mais comum, nem sempre é utilizada, já que o cliente ou fornecedor pode não ter IPs estáticos. Nesse caso, é possível utilizar um serviço como o NO-IP, que determina um domínio predefinido para um pool de IPs dinâmicos possíveis, proporcionando a mesma garantia.

      Além dessa primeira camada de segurança por IP / Domínio, o myHotel gera tokens e credenciais de acesso exclusivas para cada cliente / fornecedor, que são enviadas no momento da implementação da API. Isso garante que apenas o provedor seja responsável por suas credenciais para o uso da API.

      Por fim, o serviço também está vinculado ao CloudTrail e o myHotel é capaz de rastrear completamente cada uso da API, caso seja necessário realizar uma auditoria. Com essas medidas robustas de segurança, o myHotel assegura que o fluxo de informações entre o provedor e o myHotel seja seguro, restrito a provedores autorizados, e inclua todas as medidas de contingência necessárias para uma auditoria, se necessário.

      Por último, assim como a infraestrutura da Fidelity Suite, apenas o aplicativo tem acesso ao banco de dados por meio de políticas de segurança IAM, e não um programador ou engenheiro do myHotel. Isso garante que ninguém possa acessar diretamente as informações no banco de dados.

       

      3.- COMPATIBILIDADE COM O GDPR

       

      Em contexto de por que o myHotel precisa ser compatível com o GDPR (Regulamento Geral de Proteção de Dados), é porque o myHotel lida com informações pessoais de passageiros de qualquer origem, incluindo a Europa, onde a regulamentação está sendo fiscalizada com maior minúcia. Por isso, em 2018, o myHotel teve que adotar uma série de medidas preventivas para cumprir com essas regulamentações de privacidade. Mais informações sobre a lei podem ser encontradas neste link: https://www.privacy-regulation.eu/en/index.htm

       

      A regulamentação é bastante abrangente e se aplica de maneira diferente a diversas empresas, dependendo de sua responsabilidade no manuseio da informação. Para o myHotel, os pontos mais importantes são:

       

      • myHotel é uma entidade "processadora" de informações: de acordo com a regulamentação, existem duas possíveis entidades - 1) a "controladora" de informações, e 2) a "processadora" de informações. Neste caso, myHotel atua como a entidade número 2), e isso é formalizado durante a assinatura de todos os contratos com seus clientes em um anexo, garantindo que fique por escrito e claro que o myHotel não é o responsável pelas informações pessoais contidas no cliente, sendo apenas a processadora de informações.
      • Medidas como entidade "processadora" de informações: ao ser uma entidade processadora, o myHotel tem a responsabilidade de cumprir com os seguintes protocolos no tratamento de informações:
        • Opção de Cancelamento de Envios: O passageiro deve ter a capacidade de cancelar a subscrição de convites para responder às pesquisas, garantindo que não receba mais e-mails daquela propriedade.
        • Protocolo para Solicitações de Modificação ou Eliminação de Informações: Caso um passageiro queira que seus dados sejam eliminados do banco de dados, o myHotel está obrigado a fazê-lo e a fornecer uma resposta em até 2 dias úteis, confirmando a solicitação. Além disso, a empresa deve informar ao hotel "controlador de informações" sobre tal solicitação para que tomem as medidas necessárias.
        • Protocolo para Encerramento do Serviço de um Cliente / Fornecedor que Requer Eliminação ou Modificação de Informações: Sendo o myHotel a entidade "processadora" de outra "controladora" (cliente ou fornecedor), caso a entidade controladora solicite formalmente a eliminação ou modificação de parte ou de toda a informação processada pelo myHotel, isso deve ser cumprido e informado em um prazo máximo de 2 dias úteis, confirmando a solicitação.
      • Acesso à Informação por Parte dos Funcionários do myHotel: Assim como detalhado em seções anteriores deste documento, as camadas de segurança garantem que apenas as aplicações da Fidelity Suite, ou as processadoras de informações, tenham acesso ao banco de dados onde tudo está armazenado. Ninguém é capaz de visualizar o banco de dados por si só, garantindo a segurança das informações. Além disso, essas informações são criptografadas no nível do banco de dados, e a transferência de informações é criptografada de "ponto a ponto", protegendo contra interceptações não autorizadas.

       

      Por outro lado, o myHotel possui Políticas de Privacidade atualizadas em seu site: https://www.myhotel.cl/politica-de-privacidad/

       

      4.- CONTROLE DE ACESSO DA FIDELITY SUITE

       

      Fidelity Suite está equipada com um módulo de autoadministração de usuários que têm acesso a determinadas propriedades. Este módulo pode conceder acesso a uma ou várias propriedades (hotéis), conforme necessário pelo cliente. Não é necessário passar pelo myHotel para realizar essas configurações, o cliente pode fazê-las por conta própria.

      Dentro deste mesmo módulo, os usuários Administradores da(s) propriedade(s) terão a capacidade de:

      1. Editar informações do perfil de outros usuários.
      2. Ajustar alertas de produtos.
      3. Configurar papéis de acesso e ações dentro da Fidelity Suite myHotel.
      4. Ajustar relatórios semanais e mensais.
      5. Modificar a senha de outros usuários.
      6. Iniciar o processo de redefinição de senha.
      7. Excluir usuários e todos os seus acessos.

      Isso permite que os próprios clientes sejam responsáveis por administrar o acesso de seus usuários em caso de modificações estruturais na empresa ou outros motivos.

      Por outro lado, existem políticas de segurança relacionadas à qualidade da senha de cada usuário, com requisitos mínimos de criação:

      1. Pelo menos oito caracteres (128Hd.fvk.jerb1).
      2. Pelo menos uma letra maiúscula (KJBLK).
      3. Pelo menos uma letra minúscula (anfvoe).
      4. Pelo menos um número (2357).
      5. Pelo menos um caractere especial (/.-).

      Quando ocorrem três tentativas de acesso malsucedidas com uma senha incorreta de um usuário específico, esse usuário é bloqueado automaticamente e a única forma de desbloqueá-lo é redefinindo a senha via e-mail ou por meio de um usuário "Administrador" que redefina a senha manualmente.