Especificaciones de Políticas de Tratamiento de Información

El documento detalla las políticas de tratamiento de información de myHotel con proveedores y clientes, explicando protocolos de seguridad y procesos que garantizan estándares óptimos.

Extracto

 

En este documento se detallan todas las políticas de tratamiento de la información de myHotel con sus proveedores o clientes (dependiendo del caso). En él se explica con el mayor detalle posible todos los protocolos de seguridad implementados, como también los procesos adyacentes a estos protocolos que garantizan que la información sea tratada con los mejores estándares de precaución y seguridad del mercado.

 

Esta documentación se dividirá en 4 partes:

1. Información en la nube
2. Transferencia de información con clientes o proveedores
3. Compatibilidad GDPR
4. Control de accesos de Fidelity Suite

 

1.- INFORMACIÓN EN LA NUBE

 

myHotel tiene un único proveedor de la nube en donde está almacenada la información de todos sus clientes: AWS. A continuación, se detalla un esquema de la infraestructura de los aplicativos de myHotel en AWS para mejor entendimiento:

Los aspectos más importantes a mencionar acá son las diferentes capas de seguridad con las que cuenta myHotel para efectos de potenciales brechas de seguridad:

• API Gateway: esta herramienta de AWS tiene una capacidad bastante amplia en términos de aplicar políticas de seguridad cosa de tener trazabilidad y alertas de quién, dónde y cuándo hizo diferentes llamadas a las aplicaciones. 
  • Primero que nada, sólo las aplicaciones en ELB son capaces de conectar con api.myhotel.io a través de IAM configurados en AWS que garantizan que sólo entre ellos se pueden hacer consultas, entre ninguna otra máquina más.
  • Segundo, myHotel tiene implementado CloudTrail en esta capa para poder tener trazabilidad de los requests, tokens, etc.. en cada segundo posible, para efectos de una auditoría minuciosa si se llegase a necesitar en caso de una brecha de seguridad.
  • Y tercero, myHotel tiene implementado CloudWatch para tener alertas en tiempo real sobre ciertas métricas predefinidas por la empresa que nos dan ciertos indicadores de potenciales ataques, o requests por sobre un número normal, y muchas más de ese estilo.
• JAVA con Spring, Spring Security y Hibernate: todas las aplicaciones están desarrolladas en JAVA  con Spring, Spring Security y Hibernate que son herramientas del lenguaje JAVA que facilitan mucho las capas de seguridad utilizadas dentro de la aplicación, como también la comunicación con el exterior, añadiendo así una capa muy robusta de seguridad a nivel de código de los aplicativos. Esto garantiza a su vez que la comunicación entre los aplicativos y las BBDD sean seguras, bajo los protocolos de seguridad de Spring Security que garantizan anonimización, protección de claves, y transporte de la información por medios encriptados, entre las más importantes a destacar.
• Encriptación de información en BBDD: todo lo contenido en nuestras BBDD está encriptado según las políticas de seguridad de Amazon Web Services (AWS).

 

2.- TRANSFERENCIA DE INFORMACIÓN CON CLIENTES O PROVEEDORES

 

myHotel tiene 2 grandes categorías de transferencia de información entre sus clientes o proveedores:

A. myHotel “lee hacia afuera” información disponibilizada por su cliente / proveedor

 

En el siguiente esquema, se muestra un diagrama de flujo de información entre myHotel y sus clientes o proveedores para el caso en que el proveedor disponibiliza la información a través de algún canal posible:

 

 

Existen 4 grandes maneras de leer esta información desde los proveedores:

• API / Webservice: el proveedor o cliente disponibiliza un endpoint de una API que myHotel lee periódicamente para poder ir teniendo un registro de los pasajeros que pasan por las propiedades. La restricción que myHotel impone es que al menos este endpoint sea a través de HTTPS. Cada clientes o proveedor es libre de agregar mayores capas de seguridad, como OAuth, OAuth 2.0, login por Google / Facebook, etc..
• BBDD: el clientes o proveedor nos da una ruta y credenciales de acceso a una BBDD con privilegios sólo de lectura, para que myHotel pueda leer periódicamente la información. Al igual que la API, todas las conexiones son a través de HTTPS, y el cliente es libre de agregar mayores capas de seguridad, siendo filtro por IP la más común.
• Email: myHotel tiene un correo que es reports@myhotel.cl / reports@fidelitycx.com que es de uso único y exclusivo para recibir reporte de parte de sus clientes o proveedores. A este correo no tiene acceso ninguna persona natural, solamente a través de sistemas que utilizan la API de Google para dicho fin, con eso se garantiza que sólo se lea la información por propiedad configurada en este mismo aplicativo, y no se compartan entre distintas propiedades.
• FTP / SFTP / FTPS: generalmente se utiliza FTPS o SFTP para la transferencia de información, ya que con eso se garantiza una capa de seguridad mayor que solamente usuario y contraseña (como es el caso de un FTP normal). Con esto se asegura que la información que viaja entre myHotel y el proveedor sea a través de un medio seguro y encriptado.

 

Por último, y al igual que la infraestructura de Fidelity Suite, sólo la aplicación tiene acceso a la BBDD por medio de políticas IAM de seguridad, y no un programador o ingeniero de myHotel. Con eso se garantiza que nadie podrá estar “mirando” la información directo a la BBDD.

 

B. A myHotel le “inyectan” información a través de una API

 

En el siguiente esquema, se muestra un diagrama de flujo de información entre el proveedor y myHotel para el caso en que el proveedor hace uso de una Api / Webservice otorgado por myHotel:

 

 

Del esquema anterior, al estar montado sobre un Load Balancer de AWS que permite crear políticas de seguridad a la medida, lo que myHotel generalmente hace es crear un filtro por IP de origen para garantizar que esas IPs y sólo esas IPs son las autorizadas para hacer uso de la API, y con eso se evita muchas posibilidades de ciberataques. Si bien esta configuración es la más común, no siempre es utilizada ya que el cliente o proveedor no posee IP estáticas para ello. En ese caso se puede hacer a través de un servicio como NO-IP que determinará un dominio predefinido para un pool de IPs dinámicas posibles, y así replicar la misma garantía.

Aparte de esa primera capa de seguridad por IP / Dominio, myHotel genera tokens y credenciales de accesos únicas por clientes / proveedor, las cuales son enviadas al momento de la puesta en marcha de la API. Con esto se garantiza que el proveedor y sólo el proveedor es responsable de sus credenciales para el uso de la API.

Por último, el servicio también está colgado de CloudTrail y myHotel es capaz de hacer una trazabilidad completa de cada uno de los consumos de la API en caso de tener que hacer una auditoría.

Con estas grandes medidas de seguridad myHotel garantiza que el flujo de información entre el proveedor y myHotel sea segura, sea únicamente para un proveedor autorizado, y tenga todas las medidas de contingencia necesarias para hacer una auditoría en caso de que se necesite.

Por último, y al igual que la infraestructura de Fidelity Suite, sólo la aplicación tiene acceso a la BBDD por medio de políticas IAM de seguridad, y no un programador o ingeniero de myHotel. Con eso se garantiza que nadie podrá estar “mirando” la información directo a la BBDD.

 

3.- COMPATIBILIDAD GDPR

 

En contexto de porqué myHotel tiene la necesidad de ser compatible con GDPR (“General Data Protection Regulation”), es porque myHotel trata con información personal de pasajeros de cualquier procedencia, incluyendo Europa que es dónde la regulación está siendo fiscalizada con mayor minuciosidad. Es por esto que en el 2018 myHotel tuvo que tomar una serie de medidas de prevención para cumplir con estas regulaciones de privacidad. Más información sobre la ley en este enlace: https://www.privacy-regulation.eu/en/index.htm 

 

La regulación es muy amplia, y aplica a diferentes empresas según su responsabilidad en el manejo de la información. Para myHotel los puntos más importantes son:

 

• myHotel es entidad “procesadora” de información: bajo la regulación existen dos posibles entidades: 1) la “controladora” de información, y 2) la “procesadora” de información. En este caso myHotel viene siendo la N° 2), y esto se firma al momento de todos los contratos con sus clientes en un anexo, cosa de que quede por escrito y claro que myHotel no es el responsable de la información personal que contiene el cliente, sino solamente procesadora de información.
• Medidas como entidad “procesadora” de información: a ser entidad procesadora, myHotel tiene la responsabilidad de cumplir con los siguientes protocolos de trato de información:
  • Des suscripción de envíos: el pasajero debe tener la capacidad de poder des suscribirse de los envíos de invitaciones a responder las encuestas, y esto debe garantizar que no le lleguen más correos a esa casilla de parte de esa propiedad.
  • Protocolo ante solicitudes de modificación o eliminación de información: en caso de que un pasajero quiera que sus datos sean eliminados de la base de datos, myHotel está en la obligación de hacerlo y darle respuesta no más de 2 días hábiles a la persona con la confirmación de su solicitud, como también informarle al hotel “controlador de información” de aquella solicitud para que ellos tomen sus medidas respectivas.
  • Protocolo ante baja del servicio de un cliente / proveedor que quiera la eliminación o modificación de información: al ser myHotel la entidad “procesadora” de otra “controladora” (cliente o proveedor), en caso de que la entidad controladora pida formalmente la eliminación o modificación de una parte, o toda, la información que myHotel ha procesado, esta debe ser cumplida e informada en un plazo de 2 días hábiles como máximo, confirmando la solicitud.
• Accesibilidad a la información por parte de empleados myHotel: al igual que como se detalla en este documento en secciones anteriores, las capas de seguridad son tales que solamente las aplicaciones de Fidelity Suite, o las procesadoras de información, son quienes tienen acceso a la BBDD en dónde se encuentra guardado todo. Nadie es capaz de “mirar” la BBDD por sí sola, lo que garantiza que la información está guardada segura. Además, esta información está encriptada a nivel de la BBDD, y por último, la transferencia de información está encriptada de “punto a punto” por lo que se protege la intención de intercepción de una llamada no-autorizada. 

 

Por otro lado, myHotel cuenta con Políticas de Privacidad actualizadas en su pagina web: https://www.myhotel.cl/politica-de-privacidad/ 

 

4.- CONTROL DE ACCESOS DE FIDELITY SUITE

 

Fidelity Suite está equipado con un módulo de autoadministración de los usuarios que tienen acceso a ciertas propiedades. Este módulo puede otorgar acceso a una, o varias propiedades (hoteles), según cómo lo requiera el cliente. No es necesario pasar por myHotel para tener que hacer estas configuraciones, las puede hacer el cliente mismo.

Dentro de este mismo módulo, los usuarios Administradores de la o las propiedades tendrán la capacidad de:

1. Editar información del perfil de otros usuarios
2. Ajustar Alertas de productos
3. Configurar roles de accesos y acciones dentro de Fidelity Suite myHotel
4. Ajustar Reportes semanales y mensuales
5. Modificar la contraseña de otros usuario
6. Iniciar el proceso de restablecimiento de contraseña
7. Eliminar usuarios y todos sus accesos. 

Esto permite que los clientes mismos sean los responsables de administrar el acceso de sus usuarios en caso de modificaciones estructurales en la empresa u otros motivos.

Por otro lado, existen políticas de seguridad en torno a la calidad de la contraseña de cada usuario, con exigencias mínimas de creación:

1. Al menos ocho caracteres (128Hd.fvk.jerb1)
2. Al menos una mayúscula (KJBLK)
3. Al menos una minúscula (anfvoe)
4. Al menos un número (2357)
5. Al menos un carácter especial (/.-)

Cuando existen tres intentos de acceso fallidos por contraseña incorrecta de un usuario en específico este usuario se bloquea automáticamente y la única forma de desbloquearlo restableciendo contraseña vía correo o que un usuario “Administrador” restablezca la contraseña manualmente