Resumen
- Sabre reveló un acceso no autorizado que involucraba información de tarjetas de pago en un subconjunto de reservas hoteleras procesadas a través de su sistema Sabre Hospitality Solutions SynXis Central Reservations, una plataforma de proveedor utilizada por clientes hoteleros más que una marca que la mayoría de los viajeros afectados necesariamente conocían.
- La pregunta de responsabilidad es esta: ¿Quién tenía control práctico sobre el acceso a la plataforma de reservas, el manejo de tarjetas de pago, el aviso al cliente hotelero, la evidencia del comerciante, la detección de intrusiones y la asignación de deberes entre Sabre, las propiedades, las marcas y las redes de tarjetas?
- Los registros de los fiscales generales estatales describieron posteriormente un acuerdo multiestatal sobre la violación del sistema de reservas hoteleras de 2017, incluidas las obligaciones de notificación y los cambios de seguridad, mientras que los avisos a nivel hotelero mostraron cómo los huéspedes se enteraron de un incidente de proveedor a través de comunicaciones de la propiedad o la marca.
- Los huéspedes del hotel, las propiedades, las marcas, los gerentes de viajes, los emisores de tarjetas, los adquirentes y los administradores de la plataforma tuvieron que gestionar el riesgo creado por un sistema de proveedor que se encontraba detrás de muchas relaciones de viaje.
- El registro público respalda una conclusión de responsabilidad de alta confianza sobre los deberes de la plataforma y las brechas de evidencia. No respalda la invención de hechos privados sobre cada reserva vista, cada notificación hotelera o cada pérdida específica de un viajero.
Registro de evidencia y cómo se utiliza
Este artículo trata el registro público como evidencia en capas en lugar de como un relato único maestro. Las declaraciones para inversores de Sabre y los archivos SEC se utilizan para lo que Sabre declaró públicamente sobre el incidente de SynXis. Los registros de los fiscales generales estatales se utilizan para la cronología del acuerdo, los deberes de notificación y los cambios de seguridad requeridos. Los avisos hoteleros y los informes de la industria de viajes se utilizan para el contexto de notificación a los huéspedes posteriores.
Los estándares de tarjetas de pago, la orientación al consumidor, los marcos de control y las referencias a técnicas de adversarios se utilizan para enmarcar el control de acceso, el manejo de datos de pago, la responsabilidad de la plataforma y las implicaciones para las partes afectadas.
| # | Registro público | Uso en este análisis |
|---|---|---|
| 1 | Actualización para inversores de Sabre | Declaración principal de la empresa utilizada para la investigación completada, el subconjunto de reservas afectado, las categorías de datos, el aviso a la agencia de viajes y las afirmaciones sobre los límites del sistema. |
| 2 | Formulario 10-K de Sabre ante la SEC | Archivo principal utilizado para detalles sobre credenciales, acceso, rango de fechas, categorías de datos, notificación al cliente y divulgación de riesgos. |
| 3 | Aseguramiento de desistimiento del fiscal general de Nueva York | Registro regulatorio utilizado para la cronología de la violación, los hechos de acceso a la cuenta, los deberes de notificación y las obligaciones del acuerdo. |
| 4 | Comunicado de prensa del fiscal general de Nueva York | Comunicado regulatorio utilizado para el acuerdo multiestatal, la cifra de 1.3 millones de tarjetas y los cambios de seguridad y notificación requeridos. |
| 5 | Anuncio de acuerdo del fiscal general de Tennessee | Comunicado regulatorio utilizado para los deberes de notificación al cliente hotelero, el tiempo y los requisitos de lenguaje contractual. |
| 6 | Anuncio del fiscal general de Florida | Comunicado regulatorio utilizado para el papel de SynXis, el tiempo de notificación, la cifra de 1.3 millones de tarjetas y los términos del acuerdo. |
| 7 | Informe de KrebsOnSecurity sobre la violación de Sabre Hospitality | Reportaje de seguridad utilizado para el contexto de divulgación temprana y el encuadre de las propiedades afectadas. |
| 8 | Informe de PhocusWire sobre la información de pago de SynXis | Reportaje de tecnología de viajes utilizado para el contexto de divulgación del 10-Q y el encuadre de la audiencia de la plataforma. |
| 9 | Informe de Hotel Management sobre la violación del sistema de reservas de Sabre | Reportaje de la industria hotelera utilizado para el contexto de la plataforma SynXis. |
| 10 | Aviso al huésped del Domain Hotel | Aviso a nivel de propiedad utilizado para el lenguaje de notificación al huésped y la asignación de Sabre a la propiedad. |
| 11 | Aviso de Four Seasons | Aviso de múltiples propiedades utilizado para el contexto de notificación al socio de viajes. |
| 12 | Aviso de Hartz Hotel Services alojado por el estado | Aviso a nivel de propiedad utilizado para la redacción de datos afectados y la orientación al huésped. |
| 13 | Página de estándares del PCI Security Standards Council | Utilizado para el contexto de control de seguridad de tarjetas de pago. |
| 14 | Guía Comience con la Seguridad de la FTC | Utilizado para el encuadre de minimización de datos, control de acceso, segmentación y riesgo de proveedores. |
| 15 | Marco de Ciberseguridad del NIST | Utilizado para el vocabulario de identificar, proteger, detectar, responder y recuperar. |
| 16 | Controles Críticos de Seguridad del CIS | Utilizado para clases de inventario, cuentas, registro, monitoreo y control de proveedores. |
| 17 | Técnica de MITRE: Cuentas Válidas | Contexto de técnica para el encuadre de acceso basado en credenciales. |
| 18 | Recursos de CISA: Seguro por Diseño | Utilizado para el encuadre de responsabilidad de la plataforma, seguridad predeterminada y recuperación verificable por el cliente. |
El marco de responsabilidad es más estrecho que la culpa y más amplio que un aviso hotelero
La violación de Sabre SynXis Central Reservations es útil porque muestra cómo una plataforma de proveedor puede convertirse en el límite de responsabilidad para los registros de viajes que los huéspedes asocian con los hoteles, no con el proveedor detrás del motor de reservas. Un huésped puede reservar una habitación a través del sitio web de un hotel, un gerente de viajes, un centro de llamadas, un canal de marca u otra vía de reserva. La relación visible suele ser con la propiedad o la marca. Sin embargo, el registro de pago y reserva puede pasar a través de una plataforma central de reservas que el huésped nunca evalúa directamente.
Esa posición oculta cambia la pregunta de responsabilidad. Sabre reveló un incidente que involucraba acceso no autorizado a información de pago contenida en un subconjunto de reservas hoteleras procesadas a través del sistema Sabre Hospitality Solutions SynXis Central Reservation. Registros posteriores describieron el acceso como ocurrido a través de credenciales e involucrando reservas entre agosto de 2016 y marzo de 2017. Los registros de los fiscales generales estatales y los anuncios públicos de acuerdos describieron una población afectada de aproximadamente 1.3 millones de tarjetas de crédito.
Los avisos hoteleros luego tradujeron ese evento de proveedor en instrucciones dirigidas al huésped para propiedades y marcas particulares.
La culpa es demasiado contundente para este registro. La mejor pregunta es quién controlaba cada capa de riesgo práctico. Sabre controlaba la plataforma, el acceso a credenciales, el registro de la plataforma y la investigación del lado del proveedor. Los hoteles controlaban las relaciones con los huéspedes, los avisos de propiedad, las relaciones comerciales y algunas comunicaciones posteriores. Las marcas de tarjetas, los adquirentes, los emisores y las empresas de gestión de viajes tenían sus propios deberes.
Los huéspedes tenían que monitorear las tarjetas y decidir si una reserva que hicieron a través de un hotel podía verse afectada por un nombre de proveedor que quizás nunca vieron. Eso es un límite de responsabilidad de la plataforma.
El registro también muestra por qué la incertidumbre debe ser nombrada. El público puede ver declaraciones de la empresa, archivos SEC, registros de fiscales generales y avisos hoteleros. No puede ver cada registro interno, cada contrato hotelero, cada registro de reserva, cada notificación específica al cliente o cada acción del emisor. La respuesta correcta no es llenar esos vacíos con especulación. Es identificar qué parte tenía la evidencia faltante y qué habría mostrado un registro público más sólido.
Lo que establece el registro público
El registro público establece un incidente concreto de proveedor. La presentación de Sabre de mayo de 2017 reveló un incidente que involucraba acceso no autorizado a información de pago contenida en un subconjunto de reservas hoteleras procesadas a través del sistema SynXis Central Reservation. Sabre dijo que el acceso no autorizado había sido cortado y que había contratado asesores externos y estaba trabajando con las autoridades.
Su actualización para inversores de julio de 2017 dijo que la investigación estaba completa y que una parte no autorizada accedió a cierta información de tarjetas de pago para un subconjunto limitado de reservas hoteleras procesadas a través del sistema de reservas de Sabre Hospitality Solutions.
El registro público también establece las categorías de datos. La actualización de Sabre dijo que la información de tarjetas de pago a la que se accedió podría incluir el nombre del titular de la tarjeta, el número de tarjeta, la fecha de vencimiento y potencialmente el código de seguridad de la tarjeta. En algunos casos, también se pudo haber accedido a cierta información del huésped, como nombre, correo electrónico, número de teléfono, dirección y otra información. Sabre dijo que no se accedió a números de Seguro Social, pasaporte o licencia de conducir.
Esa distinción importaba porque reducía el riesgo de documentos de identidad mientras dejaba en el alcance el riesgo de datos de pago y contacto.
La cronología también es visible en los materiales regulatorios. Los registros y comunicados de los fiscales generales estatales describieron una violación del sistema de reservas hoteleras de Sabre Hospitality Solutions, un período de agosto de 2016 a marzo de 2017 y términos de acuerdo que requieren cambios en las prácticas de seguridad y notificación. El anuncio de Tennessee dijo que Sabre informó a los clientes hoteleros el 6 de junio de 2017, después de revelar el asunto en un archivo SEC el mes anterior, y que los hoteles responsables de informar a sus clientes no emitieron algunas notificaciones hasta 2018.
Los comunicados de Nueva York y Florida describieron un acuerdo multiestatal y la cifra de 1.3 millones de tarjetas de crédito.
El registro público no establece todos los hechos privados. No publica cada reserva en el alcance, cada cliente hotelero, cada fecha de aviso al huésped, cada comunicación de la marca de tarjeta, cada detalle técnico de la causa raíz o cada paso de remediación privado. Tampoco permite que un lector externo sepa qué hoteles recibieron la evidencia de proveedor más detallada o qué tan rápido cada huésped recibió aviso. Esas brechas son centrales para el análisis de responsabilidad porque la división de evidencia entre el proveedor de la plataforma y el cliente hotelero hizo que la asignación de evidencia fuera parte del riesgo.
Por qué importa el objeto de confianza
El objeto de confianza en este caso era la plataforma de reservas hoteleras. Esa frase es más específica que "violación" y más amplia que "datos de tarjetas de pago". Una plataforma central de reservas se sitúa entre las marcas hoteleras, las propiedades individuales, los canales de reserva, las agencias de viajes, los centros de llamadas, el procesamiento de pagos y las operaciones de servicio al huésped. Los hoteles dependen de ella para recibir y gestionar reservas. Los huéspedes confían en la relación hotelera sin saber necesariamente qué proveedor almacena o enruta el registro de reserva.
Los gerentes de viajes dependen de los datos de reserva para apoyar a los empleados. Los emisores de tarjetas dependen de los comerciantes y procesadores para identificar tarjetas comprometidas.
Cuando la plataforma de reservas se ve afectada, el daño viaja a través de las relaciones. Un huésped puede recibir un aviso de un hotel, no de Sabre. Un gerente de viajes puede escuchar que un sistema de reservas fue afectado pero no saber qué empleados usaron el sistema. Un hotel puede necesitar evidencia del proveedor antes de notificar con precisión a los huéspedes. Un emisor de tarjetas puede ver patrones de fraude pero necesita ventanas de compromiso y detalles del comerciante. La evidencia del proveedor de la plataforma se convierte en el mapa práctico para la respuesta de todos los demás.
El objeto de confianza también contiene más que números de tarjetas. Los registros de reservas pueden incluir nombre del huésped, datos de contacto, detalles de la estancia, solicitudes especiales, información de tarifas, información de fidelidad y campos de pago según el sistema y la transacción. La actualización pública de Sabre redujo las categorías confirmadas para el incidente, y ese límite debe ser respetado. El punto más amplio de responsabilidad es que las plataformas de reservas a menudo contienen datos contextuales que hacen que la exposición de tarjetas de pago sea más significativa.
Un número de tarjeta emparejado con el contexto del hotel puede apoyar la ingeniería social incluso cuando no están involucrados documentos de identidad gubernamentales.
Es por esto que el caso pertenece tanto a la dependencia de servicios en la nube como a la hotelería. El huésped puede pensar que la relación es con un hotel. El hotel puede depender de una plataforma alojada u operada centralmente. La plataforma puede enrutar campos de pago y detalles de reserva a través de muchas propiedades. La dependencia se vuelve visible solo cuando el incidente del proveedor obliga a cada parte posterior a actuar.
La superficie de control antes del incidente
Antes de un incidente en la plataforma de reservas, los controles centrales son la gobernanza de cuentas, el acceso privilegiado, la segmentación por cliente hotelero, la minimización de datos de pago, el cifrado o tokenización, el registro, la detección de anomalías, la gestión de vulnerabilidades y la notificación definida por contrato. Estos controles deciden si una cuenta comprometida puede ver muchas reservas, si el acceso está limitado por hotel o rol, si los datos de tarjeta están presentes en forma utilizable y si la plataforma puede reconstruir qué huéspedes fueron afectados.
La gobernanza de credenciales es un control central porque el registro público apunta al acceso a la cuenta. Las credenciales válidas pueden ser más difíciles de distinguir de la actividad legítima que el malware obvio. Por lo tanto, un operador de plataforma debe saber qué cuentas pueden ver datos de pago, qué cuentas tienen derechos administrativos, cómo se autentican esas cuentas, con qué frecuencia se revisan y cómo se detecta el acceso anormal. Si una cuenta puede ver las reservas de muchos clientes hoteleros sin un monitoreo fuerte, la plataforma ha creado una exposición compartida.
La segmentación por cliente hotelero es igualmente central. Una plataforma de reservas puede servir a miles de hoteles. Esa escala es su valor comercial. También es la razón por la que la plataforma debe poder separar la evidencia del cliente rápidamente. Cada hotel necesita saber si sus huéspedes fueron afectados, qué reservas estaban en el alcance, qué rango de fechas aplica, qué campos de datos fueron visibles y qué lenguaje de notificación es preciso. La segmentación débil o el registro débil transfieren la incertidumbre del proveedor a los hoteles y huéspedes.
La minimización de datos de pago es el control que cambia las apuestas. Si la plataforma puede evitar almacenar o mostrar campos sensibles de la tarjeta, un incidente de credenciales se vuelve menos grave. Si el nombre del titular de la tarjeta, el número de tarjeta, la fecha de vencimiento y el posible código de seguridad se pueden acceder a través de las vistas de reserva, la plataforma debe proteger esas vistas con un estándar más alto. Los estándares de pago y las expectativas de los comerciantes existen porque los datos de tarjeta tienen consecuencias especiales posteriores.
En una plataforma de reservas, esas consecuencias se multiplican por el número de hoteles y canales que dependen del sistema.
Detección, contención y el reloj
El tiempo es evidencia. La cronología pública indica acceso no autorizado que afecta reservas de agosto de 2016 a marzo de 2017, divulgación pública a la SEC en mayo de 2017, aviso a las marcas de tarjetas de pago poco después, aviso al cliente hotelero en junio de 2017 según materiales regulatorios, y algunas notificaciones hoteleras posteriores que se extendieron más tarde. Esa secuencia importa porque el retraso de un proveedor de plataforma se convierte en retraso del hotel y del huésped. El proveedor puede necesitar tiempo para investigar. Los hoteles pueden necesitar evidencia del proveedor para identificar a los huéspedes.
Los huéspedes aún corren el riesgo de las tarjetas de pago mientras ese trabajo continúa.
La contención en un incidente de plataforma de reservas tiene varias capas. La plataforma debe cortar el acceso no autorizado, preservar registros, identificar cuentas afectadas, determinar el alcance de la reserva y los datos, trabajar con las autoridades y las marcas de tarjetas de pago, notificar a los clientes hoteleros, apoyar los avisos a nivel de propiedad y remediar la debilidad de acceso. Los hoteles deben traducir esa evidencia en comunicación al huésped y pueden necesitar coordinar con bancos comerciales, marcas, administradores de propiedades y centros de llamadas.
Los emisores de tarjetas deben decidir si monitorear o reemplazar tarjetas.
La actualización pública de Sabre dijo que el acceso no autorizado había sido cortado y la investigación completada. Eso fue útil. La pregunta de responsabilidad es qué evidencia acompañó a esa declaración para hoteles y reguladores. ¿Podía cada hotel ver listas de reservas afectadas? ¿Estaban claras las ventanas de fecha y las categorías de datos? ¿Se separaron las posibilidades de exposición del código de seguridad de la tarjeta por reserva? ¿Se les dijo a los hoteles qué redacción usar y cuándo notificar?
El registro público sugiere que la asignación de notificación fue un problema central porque los acuerdos estatales abordaron los términos de notificación y contrato.
El reloj también muestra cómo la dependencia de la plataforma puede alargar la respuesta. Un huésped no puede actuar sobre una presentación de proveedor que nunca ve. Un hotel no puede notificar con precisión a un huésped sin evidencia del proveedor. Un proveedor puede no conocer las obligaciones de contacto con el huésped para cada propiedad. Esas dependencias son predecibles, por lo que deben gobernarse antes de un incidente. Una plataforma central debe tener una ruta practicada desde la detección hasta la evidencia específica del hotel y el aviso al huésped.
Carga de trabajo del hotel y del huésped después de la divulgación
La divulgación transfirió trabajo a hoteles y huéspedes. Los hoteles tuvieron que determinar si sus reservas fueron procesadas a través del sistema SynXis afectado, qué huéspedes estaban en el alcance, qué categorías de datos estaban involucradas y cómo se debía entregar el aviso. Algunos hoteles emitieron avisos a nivel de propiedad a través de comunicados de prensa o presentaciones estatales. Esos avisos a menudo explicaban que Sabre, no el hotel en sí, había sufrido el incidente, pero que las reservas realizadas en la propiedad a través del sistema afectado podían incluir información de pago del huésped.
Los huéspedes tenían una carga de trabajo diferente. Tenían que conectar una reserva de hotel con un sistema de proveedor, revisar los estados de cuenta de la tarjeta de pago, reportar cargos no autorizados y estar atentos a mensajes sospechosos. Un huésped podía recordar la propiedad pero no la ruta de reserva. Podría haber usado una tarjeta corporativa, una tarjeta personal o una empresa de gestión de viajes. Podría haber cancelado o cambiado una reserva. Un aviso útil debe ayudar al huésped a entender si una reserva, no solo una estancia, puso la tarjeta en riesgo.
Los gerentes de viajes enfrentaron una versión más difícil del mismo problema. Pueden haber reservado empleados a través de agencias o herramientas de viajes corporativas que no interactuaban directamente con SynXis, mientras que las reservas aún se movían a través de una plataforma hotelera. La actualización para inversores de Sabre dijo que algunas empresas de gestión de viajes y agencias de viajes que reservaron viajeros potencialmente afectados también habían sido notificadas, aunque esas partes no usaban ni interactuaban con el sistema Sabre SynXis. Ese detalle muestra la cadena de dependencia extendida.
El aviso tenía que llegar a partes que eran adyacentes a, pero no operadoras de, la plataforma.
El deber del huésped es real pero limitado. Los huéspedes deben monitorear los estados de cuenta y reportar cargos no autorizados de inmediato. Los equipos de viajes corporativos deben coincidir las propiedades afectadas y las ventanas de fecha con las tarjetas de los empleados. Los emisores deben estar atentos al fraude. Pero esos deberes dependen de la evidencia del proveedor y del hotel. Un huésped no puede saber de forma independiente si una reserva se almacenó en el subconjunto afectado. Sabre y sus clientes hoteleros controlaban esa evidencia.
Límite de la plataforma y responsabilidad compartida
La responsabilidad compartida es real, pero se vuelve significativa solo cuando los deberes se asignan a la parte con control práctico. Sabre controlaba la plataforma SynXis, la autenticación de cuentas, los registros de la plataforma y la investigación del lado del proveedor. Los clientes hoteleros controlaban las relaciones con los huéspedes, los avisos a nivel de propiedad, las relaciones comerciales y algunos flujos de trabajo de reserva. Las agencias de viajes, las empresas de gestión de viajes, las marcas de tarjetas, los adquirentes y los emisores tenían piezas adicionales de la respuesta. El huésped se sentaba al final de esa cadena.
El límite de la plataforma es donde la responsabilidad compartida a menudo se rompe. Los hoteles pueden ser responsables de notificar a sus huéspedes, pero necesitan evidencia del proveedor para hacerlo con precisión. Un proveedor puede decir que los clientes hoteleros son responsables del aviso al huésped, pero el proveedor controla los hechos que hacen posible el aviso. Las marcas de tarjetas pueden requerir acción, pero necesitan evidencia de tarjetas afectadas. Cada parte puede afirmar verazmente que otra parte controla parte de la respuesta. La responsabilidad requiere que las transferencias estén definidas de antemano.
Los registros de acuerdos estatales reconocieron ese problema a través de cambios requeridos en los protocolos de seguridad y notificación y en los términos contractuales. La lección pública es que un proveedor de plataforma no debe tratar la notificación al cliente como una ocurrencia tardía. Si un sistema de proveedor procesa reservas hoteleras, el proveedor debe tener un paquete de incidente claro para los clientes hoteleros: reservas afectadas, campos de datos, ventanas de fecha, lenguaje recomendado para el huésped, estado de coordinación con la marca de tarjeta e incertidumbre residual.
Los hoteles deben tener su propio plan para convertir ese paquete en aviso al huésped rápidamente.
El principio de equidad es simple. La responsabilidad debe seguir a la evidencia. La parte con los registros de la plataforma debe producir evidencia de la plataforma. La parte con las relaciones con los huéspedes debe comunicar instrucciones dirigidas al huésped. La parte con las obligaciones de la red de tarjetas debe coordinar la respuesta de pago. La parte con los listados de viajeros debe identificar a los empleados afectados. Cuando esos deberes están coordinados, el huésped recibe un aviso claro. Cuando no lo están, el huésped experimenta retraso y confusión.
Soberanía y localidad de los datos en los registros de reservas
El tema manifiesto de soberanía y localidad de los datos encaja con el registro de Sabre porque las reservas cruzan fronteras físicas y legales. Un huésped puede vivir en un país, reservar un hotel en otro, hacer la reserva a través de una agencia de viajes en un tercero y tener los datos de pago procesados por una plataforma o red de tarjetas que opera en otro lugar. Los fiscales generales estatales en Estados Unidos tomaron medidas, mientras que las propiedades y los huéspedes afectados podrían estar dispersos en muchas jurisdicciones. El registro de reserva es local para una estancia y global en su cadena de procesamiento.
La localidad importa para la notificación. Una propiedad hotelera puede tener huéspedes de varios estados y países. Los requisitos de notificación de violaciones estatales pueden aplicarse según la residencia. Los requisitos de la red de tarjetas pueden aplicarse según el enrutamiento del pago. Los deberes de viajes corporativos pueden aplicarse según las políticas del empleador. Una plataforma de proveedor que sirve a muchos hoteles debe, por lo tanto, producir evidencia que pueda clasificarse por propiedad, huésped, fecha y categoría de datos. Una declaración global única no es suficiente para los deberes legales y del cliente locales.
La localidad también importa para la comprensión del huésped. Un huésped que reservó The Domain Hotel, una propiedad de Four Seasons u otro hotel afectado puede no saber que el registro relevante fluyó a través de SynXis. Los avisos hoteleros cerraron esa brecha explicando que Sabre Hospitality Solutions sufrió el incidente y que las reservas para la propiedad estaban involucradas. Ese puente es una herramienta de responsabilidad. Hace visible una plataforma oculta para la persona afectada en el momento en que necesita actuar.
La soberanía de los datos no debe convertirse en un lenguaje vago. En este caso significa evidencia a nivel de registro: qué huésped, qué reserva, qué propiedad, qué fecha, qué campo de tarjeta y qué ley de notificación o canal de comunicación. Sin esa evidencia, la respuesta transfronteriza se convierte en una cadena de explicaciones parciales.
Automatización de software empresarial y flujos de trabajo de reservas
La automatización de software empresarial es central en este caso porque SynXis hizo lo que las plataformas empresariales están diseñadas para hacer: estandarizar y automatizar el manejo de reservas en muchos clientes hoteleros. La automatización puede reducir la fricción, centralizar las actualizaciones y dar a los hoteles una capa operativa compartida. También puede centralizar el riesgo. Una sola credencial o ruta de acceso de la plataforma puede exponer registros de reservas en muchos clientes hoteleros si los controles no están suficientemente segmentados y monitoreados.
La automatización también afecta la detección. Una plataforma de reservas genera patrones: vistas de reservas, acceso a campos de pago, acciones administrativas, exportaciones, cambios de cuentas y uso de API o interfaz. Esos patrones deben crear oportunidades para detectar comportamientos inusuales. Si una cuenta de repente ve volúmenes anormales, toca hoteles inusuales o accede a datos de pago fuera de los flujos de trabajo esperados, la plataforma debe tener monitoreo que convierta esas señales en alertas.
Los registros regulatorios y los términos del acuerdo plantean la pregunta práctica de si el monitoreo y la ruta de respuesta fueron lo suficientemente rápidos.
La lección de automatización no es que las plataformas sean malas. Los hoteles usan plataformas porque necesitan infraestructura de reservas confiable. La lección es que la automatización requiere auditabilidad. Cada flujo de trabajo automatizado debe dejar evidencia sobre quién accedió a qué, cuándo, para qué hotel, bajo qué rol y a través de qué canal. Sin esa evidencia, la automatización se convierte en una caja negra durante la respuesta a incidentes.
Las plataformas empresariales también necesitan informes específicos para el cliente. Un cliente hotelero no debe recibir solo una declaración amplia de la plataforma. Debe recibir el subconjunto relevante para sus huéspedes. Eso requiere que la plataforma etiquete y separe los registros correctamente antes de un incidente. La arquitectura de datos y la arquitectura de notificación al cliente están vinculadas. La forma en que una plataforma organiza los registros determina qué tan rápido puede apoyar a los clientes afectados más tarde.
Manejo de tarjetas de pago y contexto de reserva
El manejo de tarjetas de pago en los sistemas de reservas es diferente del manejo en un terminal de recepción, pero la preocupación posterior es similar: los datos del titular de la tarjeta pueden volverse utilizables para fraude. La actualización pública de Sabre dijo que la información de tarjetas de pago a la que se accedió podría incluir el nombre del titular de la tarjeta, el número de tarjeta, la fecha de vencimiento y potencialmente el código de seguridad de la tarjeta.
Esa posible exposición del código de seguridad hizo que el incidente fuera más grave porque los códigos de seguridad de las tarjetas se consideran altamente sensibles en contextos de pago.
El contexto de reserva puede hacer que el riesgo de la tarjeta de pago sea más creíble para un huésped. Un mensaje sospechoso que haga referencia a una reserva de hotel real, al nombre del huésped o a un detalle de viaje puede parecer más creíble que un intento de fraude ordinario. La actualización de Sabre también dijo que en algunos casos se podía acceder a cierta información del huésped que no era de tarjeta, como nombre, correo electrónico, número de teléfono y dirección. El registro público dijo que no se accedió a números de Seguro Social, pasaporte o licencia de conducir.
Esas exclusiones reducen ciertos riesgos de documentos de identidad, pero no eliminan el phishing y la carga de trabajo de las tarjetas de pago.
Los estándares de pago importan aquí como contexto de control. Una plataforma que almacena o muestra datos de tarjeta debe minimizar la exposición, restringir el acceso, monitorear la actividad y ser capaz de reconstruir los registros afectados. El artículo no infiere un estado de cumplimiento específico del registro público. Utiliza los estándares de pago para identificar las clases de control que una plataforma de reservas debe gobernar: control de cuentas, registro, cifrado o tokenización, desarrollo seguro, monitoreo, pruebas y políticas.
Los emisores y adquirentes de tarjetas también dependen de la evidencia de la plataforma. Si la plataforma puede proporcionar listas de tarjetas afectadas y ventanas de fecha rápidamente, los emisores pueden monitorear o reemplazar tarjetas de manera más eficiente. Si la evidencia de la plataforma se retrasa o es imprecisa, los emisores pueden enfrentar una incertidumbre más amplia. El huésped ve el resultado como una instrucción clara o un aviso confuso posterior al hecho.
Calidad de la divulgación y el costo de un proveedor oculto
La calidad de la divulgación importa más cuando el proveedor está oculto para el viajero. La actualización para inversores de Sabre fue clara en que un subconjunto de reservas hoteleras procesadas a través del sistema de reservas de Sabre Hospitality Solutions había sido afectado y que los clientes hoteleros y algunas empresas de gestión de viajes o agencias habían sido notificados. Los avisos hoteleros luego explicaron el incidente a los huéspedes en términos específicos de la propiedad. Esa estructura refleja la cadena real: proveedor a cliente hotelero a huésped.
El costo de esa cadena es el retraso y el riesgo de traducción. Una declaración del proveedor puede ser técnicamente precisa pero no visible para los huéspedes. Un aviso hotelero puede ser visible pero dependiente de la evidencia del proveedor. Un gerente de viajes puede necesitar un listado de empleados afectados pero no tener los mismos datos que la propiedad. Cada traducción puede perder precisión. Es por eso que los registros de acuerdos que abordan los protocolos de notificación y los términos contractuales son tan relevantes. Apuntan a la necesidad de gobernanza detrás de la confusión pública.
Un paquete de notificación de proveedor sólido debería facilitar la traducción. Debería indicar el sistema afectado, el rango de fechas, los campos de datos, las reservas afectadas, las categorías de datos excluidas, el estado de contención, la coordinación con la marca de tarjeta, la orientación recomendada para el huésped y las preguntas abiertas. También debería identificar si las empresas de gestión de viajes o las agencias necesitan notificación incluso si no usaron la plataforma directamente. La actualización pública de Sabre reconoció que las partes de viaje adyacentes fueron notificadas.
Un proceso maduro haría que esa adyacencia sea parte del modelo de notificación planificado.
La incertidumbre debe permanecer visible. El registro público no muestra si cada hotel emitió un aviso tan rápido como fue posible o si cada huésped recibió un aviso individualizado. Muestra que algunas notificaciones ocurrieron más tarde y que los estados trataron el tiempo de notificación como parte del registro del acuerdo. La lección no es que cada retraso tenga la misma causa. La lección es que los proveedores ocultos requieren reglas de transferencia más sólidas.
Lo que mostraría una evidencia pública más sólida
Un registro público más sólido no necesitaría publicar registros sensibles o listas completas de reservas. Explicaría la ruta de acceso a la cuenta a alto nivel, la señal de monitoreo que detectó el problema, la lógica del rango de fechas, el subconjunto de reservas afectado y el método utilizado para separar los clientes hoteleros afectados de los no afectados. También describiría cómo se evaluó la exposición del código de seguridad de la tarjeta y cómo se definió el alcance de los campos de contacto del huésped.
Para los clientes hoteleros, la evidencia más sólida incluiría recuentos de reservas afectadas específicas de la propiedad, categorías de datos, fechas, estado de coordinación con la marca de tarjeta y lenguaje de notificación recomendado. Para los gerentes de viajes, incluiría suficiente información para coincidir las reservas de los empleados sin exponer registros de huéspedes no relacionados. Para los huéspedes, incluiría instrucciones claras sobre el monitoreo de estados de cuenta, los canales de contacto legítimos y el significado de un nombre de proveedor en un aviso hotelero.
La evidencia pública más sólida también explicaría los cambios duraderos. ¿Fortaleció Sabre los controles de credenciales? ¿Modificó el monitoreo de acceso? ¿Actualizó el lenguaje de notificación del contrato? ¿Redujo la visibilidad de los campos de tarjeta? ¿Revisó los protocolos de notificación al cliente? ¿Exigió o permitió avisos hoteleros más rápidos? Los registros de acuerdos estatales dijeron que se requerían cambios, pero un registro de aprendizaje público más sólido conectaría esos requisitos con indicadores operativos.
El propósito de una evidencia más sólida no es el castigo público. Es el aprendizaje del mercado. Otras plataformas de reservas, marcas hoteleras, empresas de gestión de viajes y procesadores de pagos pueden comparar sus propias superficies de control con el registro. Los huéspedes pueden entender mejor el riesgo del proveedor. Los reguladores pueden hacer preguntas sobre la evidencia en lugar de preguntas sobre titulares. Los consejos directivos pueden verificar si la dependencia de la plataforma se ha vuelto visible en la gobernanza del riesgo.
Los consejos directivos deben tratar las plataformas de reservas como activos gobernados
Los consejos directivos de hoteles, empresas de tecnología de viajes y compradores de viajes deben tratar las plataformas de reservas como activos gobernados, no simplemente como herramientas de adquisición. Una plataforma de reservas puede contener datos de pago, detalles de identidad del huésped, información de contacto, contexto de la estancia, campos relacionados con la fidelidad e instrucciones operativas. También puede conectar a muchas partes que no comparten los mismos deberes legales.
La pregunta del consejo es si la dirección sabe qué almacena la plataforma, quién puede acceder a ella, cómo se monitorea la actividad y cómo se notificará a los clientes si falla.
Para un proveedor de plataforma, un tablero de control útil para el consejo mostraría cuentas privilegiadas, segmentación de clientes, exposición de datos de pago, cobertura de registro, tiempos de respuesta a alertas, manuales de notificación al cliente, obligaciones de notificación contractual y elementos de remediación pendientes. Para una marca hotelera, el tablero mostraría qué plataformas de proveedores procesan reservas, qué campos de datos contienen, cómo se entregará la evidencia del incidente y cómo se coordinará la notificación al huésped.
Para un comprador de viajes, el tablero mostraría qué rutas de reserva crean dependencias de proveedores y cómo funcionará la notificación a los empleados.
El registro de Sabre también muestra por qué la supervisión del consejo debe seguir la relación con el huésped, no solo el contrato con el proveedor. Los huéspedes confían en el hotel, pero el hotel puede depender de un proveedor. Si el proveedor falla, el hotel todavía posee gran parte de la relación con el huésped. Eso significa que el consejo del hotel necesita asegurarse sobre los derechos de evidencia del proveedor y la preparación para la notificación. El riesgo del proveedor no es un riesgo de back-office cuando determina lo que los huéspedes aprenden después de una violación.
Los consejos también deben evitar la dependencia excesiva de garantías amplias. Una declaración de que el acceso no autorizado ha sido cortado es útil, pero los consejos deben preguntar cómo se verificó eso, qué registros fueron afectados, qué clientes fueron notificados y qué cambió después. La responsabilidad de la plataforma es responsabilidad de la evidencia.
Lecciones de adquisición para marcas hoteleras y gerentes de viajes
Las marcas y propiedades hoteleras deben leer el registro de Sabre como una lección de adquisición. La pregunta no es solo si un proveedor de reservas tiene certificaciones de seguridad. La pregunta es si el proveedor puede producir evidencia específica del cliente durante un incidente. Los contratos deben requerir notificación oportuna, datos de reservas afectadas, detalle de categorías de datos, información de coordinación con la marca de tarjeta, apoyo para la notificación al huésped e informes de remediación. Un proveedor que no pueda proporcionar esas salidas transferirá incertidumbre a hoteles y huéspedes.
Las preguntas de adquisición útiles incluyen: ¿Están segmentados lógica y operativamente los registros de los clientes hoteleros? ¿Qué cuentas pueden acceder a los datos de pago? ¿Se requiere autenticación multifactor para el acceso de alto riesgo? ¿Se almacenan, muestran o manejan los códigos de seguridad de las tarjetas en algún flujo de trabajo de reserva? ¿Cuánto tiempo se conservan los registros? ¿Qué tan rápido puede el proveedor producir exportaciones de registros afectados? ¿Qué redacción de aviso y paquete de evidencia proporcionará el proveedor?
Los gerentes de viajes deben hacer preguntas paralelas. ¿Qué rutas de reserva dependen de plataformas de reservas de terceros? ¿Recibirá la empresa de gestión de viajes un aviso si los empleados están potencialmente afectados? ¿Cómo se identificará a los empleados afectados? ¿Qué método de pago reduce la exposición? ¿Pueden las tarjetas virtuales o las tarjetas de uso limitado reducir el impacto de un incidente en la plataforma de reservas? Estas preguntas hacen visible una dependencia oculta del proveedor antes de que se convierta en un evento en vivo.
La lección de adquisición no es evitar todas las plataformas. Es exigir que las plataformas fallen de una manera que pueda explicarse. Los hoteles necesitan infraestructura de reservas. Los huéspedes necesitan una reserva confiable. La relación se vuelve más segura cuando los derechos de evidencia y los deberes de notificación están escritos en el modelo de servicio.
Enfoque regulatorio y de la red de tarjetas
Los reguladores y las redes de tarjetas deben centrarse en la evidencia que los huéspedes y los hoteles no pueden ver. Eso incluye acceso a cuentas, señales de monitoreo, listas de reservas afectadas, alcance de categorías de datos, tiempo de notificación, coordinación con la marca de tarjeta y contratos con clientes. En un incidente de plataforma, la evidencia más relevante puede estar en manos del proveedor aunque el aviso legal a los huéspedes pueda fluir a través de los hoteles. Los reguladores agregan valor al probar si esas transferencias funcionaron.
Los registros de los fiscales generales estatales hicieron exactamente eso en forma amplia. El registro del acuerdo abordó la violación, la exposición de los datos de las tarjetas de pago, el tiempo de notificación y los cambios requeridos. Los comunicados de prensa describieron la cifra de 1.3 millones de tarjetas y los cambios de seguridad y notificación. Los términos legales precisos importan menos para este artículo que la señal de gobernanza: las obligaciones de respuesta a incidentes de un proveedor de plataforma se extienden a cómo los clientes hoteleros posteriores y los huéspedes reciben los hechos.
Las redes de tarjetas y los adquirentes tienen un papel paralelo. Necesitan evidencia de tarjetas afectadas, ventanas de fecha y contexto del comerciante o propiedad. Pueden requerir revisión forense y validación de remediación. Sus procesos pueden reducir el fraude pero siguen siendo en gran medida invisibles para los huéspedes. Un registro público sólido puede al menos explicar que las marcas de tarjetas de pago fueron notificadas y qué campos de datos estuvieron implicados.
El enfoque regulatorio no debe colapsar a todas las partes en una responsabilidad indiferenciada. Los hoteles, proveedores, marcas de tarjetas y agencias de viajes tienen diferentes roles. La mejor pregunta es si cada parte realizó el deber que controlaba y si la transferencia entre ellas preservó evidencia útil para el huésped.
Rastro de evidencia del lado del cliente
Los huéspedes y los gerentes de viajes deben preservar su propio rastro de evidencia después de un incidente en la plataforma de reservas. Un huésped debe guardar el aviso, identificar la reserva y la propiedad, determinar qué tarjeta se usó, monitorear los estados de cuenta, reportar cargos no autorizados de inmediato y ser cauteloso con los mensajes que hagan referencia a la reserva. Un equipo de viajes corporativo debe coincidir los avisos con los viajes de los empleados, los métodos de pago y las ventanas de reserva afectadas.
El rastro de evidencia debe incluir incertidumbre. Un huésped puede saber que un aviso de propiedad mencionó a Sabre pero puede no saber si una reserva particular estaba en el subconjunto afectado. Un gerente de viajes puede saber que los empleados se alojaron en propiedades afectadas pero no saber si sus reservas fueron procesadas a través de SynXis. Anotar esas incógnitas ayuda a la revisión posterior y evita confundir hechos de proveedor no disponibles con una acción omitida del cliente.
Los hoteles pueden facilitar el rastro del lado del cliente preservando avisos públicos claros y presentaciones estatales. Los avisos deben identificar al proveedor, el sistema afectado, la ventana de reserva, las categorías de datos, los datos excluidos y las acciones recomendadas. También deben dejar claro cómo el hotel se comunicará y no se comunicará con los huéspedes. Debido a que los detalles de la reserva pueden usarse en ingeniería social, los huéspedes deben tener una forma segura de verificar los mensajes.
El proveedor puede apoyar este proceso manteniendo paquetes de evidencia para hoteles consistentes. Si cada propiedad recibe una redacción diferente o evidencia incompleta, los huéspedes reciben explicaciones desiguales. Si el proveedor de la plataforma proporciona evidencia clara y específica para el cliente, los hoteles pueden comunicarse de manera más coherente.
Por qué este caso sigue siendo útil después del ciclo de noticias
El registro de Sabre sigue siendo útil porque las plataformas de reservas siguen siendo centrales para los viajes. Los hoteles continúan dependiendo de sistemas de proveedores que manejan reservas, campos de pago, datos de contacto de huéspedes, distribución de canales y conexiones con agencias de viajes. Los huéspedes todavía ven principalmente la marca del hotel en lugar de la plataforma. Un incidente de proveedor aún puede convertirse en un problema de tarjeta de pago para el huésped del hotel.
El registro también enseña que la notificación de la plataforma no es una notificación única. Es una cadena. Sabre notificó a inversores, marcas de tarjetas de pago, clientes hoteleros y algunas partes de agencias de viajes. Los hoteles notificaron a los huéspedes. Los estados revisaron el tiempo de notificación y los deberes del acuerdo. Cada paso tenía que preservar suficientes hechos para la siguiente parte. Si un eslabón es débil, el huésped recibe orientación tardía o poco clara.
El caso recompensa el análisis cuidadoso. Sería incorrecto tratar a cada hotel que usa SynXis como afectado a menos que la evidencia lo diga. También sería incorrecto tratar una declaración del proveedor como suficiente para los huéspedes que nunca la vieron. El término medio responsable es seguir el subconjunto de reservas afectado, los campos de datos, la cadena de notificación y los deberes de control.
La lección duradera es que las plataformas invisibles deben hacerse visibles durante la falla. Los huéspedes no necesitan evaluar a cada proveedor antes de reservar una habitación. Pero cuando un sistema de proveedor expone datos de pago, las partes responsables deben explicar la relación con el proveedor con suficiente claridad para que los huéspedes puedan actuar.
Indicadores operativos que harían que la recuperación sea verificable
El registro más útil siguiente incluiría indicadores operativos. Para una plataforma de reservas, esos indicadores incluirían el número de cuentas privilegiadas, la cobertura de autenticación multifactor para roles de alto riesgo, el estado de segmentación de clientes, el estado de minimización de datos de pago, la cobertura de retención de registros, el tiempo de alerta de acceso anormal, la velocidad de exportación de reservas afectadas, la finalización del paquete de notificación al cliente y la validación de remediación.
Los indicadores específicos del incidente incluirían el tiempo desde la detección hasta la contención, el tiempo desde la contención hasta el aviso a la marca de tarjeta, el tiempo desde la contención hasta el aviso al cliente hotelero, la finalización del aviso al cliente hotelero, el número de propiedades afectadas, el número de reservas afectadas, el número de tarjetas afectadas y la agrupación de categorías de datos. La información pública puede no necesitar cada cifra exacta, pero las categorías y el estado de finalización hacen que las afirmaciones de recuperación sean verificables.
Los indicadores deben distinguir la recuperación técnica de la recuperación de gobernanza. La recuperación técnica significa que el acceso no autorizado ha sido cortado y la plataforma endurecida. La recuperación de gobernanza significa que los clientes pueden recibir evidencia precisa rápidamente, los contratos definen los deberes de notificación, los datos de tarjeta están minimizados y los hoteles pueden notificar a los huéspedes sin reconstruir el registro del proveedor desde cero. Una plataforma puede terminar la limpieza técnica y aún así dejar la gobernanza débil.
Para los consejos directivos y reguladores, estos indicadores son más útiles que las garantías amplias. Muestran si la organización aprendió del incidente del proveedor o solo cerró un caso. También crean una forma de comparar proveedores de plataformas sin depender solo de la reputación.
El lenguaje contractual debe seguir la superficie expuesta
El lenguaje contractual debe seguir la superficie expuesta. Si la superficie expuesta es el acceso a la plataforma de reservas, el contrato debe abordar el control de cuentas, la segmentación de clientes, el registro y la evidencia de incidentes. Si la superficie expuesta es el manejo de tarjetas de pago, el contrato debe abordar la minimización de datos, el manejo de códigos de seguridad, la coordinación con la marca de tarjeta y la notificación de tarjetas afectadas. Si la superficie expuesta es la notificación al huésped, el contrato debe abordar quién notifica a quién, cuándo, con qué hechos y cómo se entregan las actualizaciones.
Los contratos de los hoteles con los proveedores de reservas deben requerir notificación temprana cuando se sospeche acceso a la plataforma que involucre reservas hoteleras o campos de pago, no solo cuando se complete el alcance final. Deben requerir un paquete de evidencia posterior que identifique los registros afectados, las categorías de datos, las categorías excluidas, las medidas de contención y la incertidumbre residual. También deben definir el apoyo para las obligaciones de notificación estatales, nacionales o transfronterizas.
Los contratos de gerentes de viajes y agencias deben abordar la notificación adyacente. La actualización pública de Sabre dijo que ciertas empresas de gestión de viajes y agencias de viajes fueron notificadas aunque no usaban ni interactuaban con SynXis. Ese es exactamente el tipo de relación que debe anticiparse. Una parte de viaje puede necesitar advertir a viajeros o clientes corporativos incluso cuando no es el operador de la plataforma.
El propósito no es enterrar a la industria en papeleo. Es hacer que la cadena de reservas sea responsable. Las plataformas pueden continuar haciendo que la distribución hotelera sea eficiente cuando los deberes en torno al acceso, la evidencia y la notificación son claros.
La pregunta de recurrencia
La pregunta de recurrencia no es si el incidente idéntico de Sabre volverá a ocurrir. Las plataformas cambian, los controles de acceso cambian y los atacantes cambian. La pregunta de recurrencia es si la misma debilidad de control podría regresar bajo otra etiqueta. Una cuenta con credenciales podría convertirse en un token API. Una vista de reserva podría convertirse en una exportación de informes. Un campo de tarjeta de pago podría moverse a un flujo de trabajo de reserva diferente. Un paquete de notificación al cliente hotelero aún podría ser demasiado lento o incompleto.
Para los proveedores de plataformas de reservas, la prevención de recurrencia debe centrarse en el privilegio mínimo, la autenticación resistente al phishing para acceso de alto riesgo, la segmentación de clientes, la minimización de datos de pago, el monitoreo, la evidencia rápida específica del cliente y los manuales de notificación. Para los hoteles, la prevención de recurrencia debe centrarse en los contratos con proveedores, la preparación para la notificación al huésped, el diseño del método de pago y el conocimiento de qué plataformas procesan qué registros.
Para los gerentes de viajes, la prevención de recurrencia significa saber qué rutas de reserva crean dependencias de proveedores.
El aprendizaje es más fuerte que el cierre. El cierre dice que el acceso no autorizado ha sido cortado. El aprendizaje dice que la plataforma cambió la forma en que gobierna la clase de exposición que hizo que el incidente fuera consecuente. Los lectores deben buscar evidencia de aprendizaje: controles de cuenta más fuertes, mejor registro, notificación más rápida al cliente, exposición reducida de datos de tarjeta y contratos más claros.
El registro de Sabre debe permanecer en las revisiones de adquisiciones, los programas de riesgo hotelero, la planificación de gestión de viajes, la gobernanza de pagos con tarjeta y las discusiones del consejo sobre plataformas de proveedores. No es solo una violación pasada. Es un recordatorio de que el software central de reservas se convierte en infraestructura de responsabilidad pública cuando contiene registros de pago y de huéspedes.
El resultado final para la responsabilidad
El resultado final es que Sabre convirtió las reservas hoteleras en un límite de responsabilidad de la plataforma. El incidente importa porque los huéspedes del hotel, las propiedades, las marcas, los gerentes de viajes, los emisores de tarjetas, los adquirentes y los administradores de la plataforma tuvieron que gestionar el riesgo creado por un sistema de proveedor que muchos viajeros afectados nunca conocieron por nombre. El estándar responsable no fue la prevención perfecta.
Fue el control práctico: gobernar credenciales, minimizar la exposición de pago, segmentar los registros de clientes, detectar acceso anormal, notificar rápidamente a los clientes hoteleros y preservar evidencia que permita a los huéspedes actuar.
El registro respalda una conclusión de alta confianza sobre los deberes en torno al acceso a la plataforma de reservas, el manejo de tarjetas de pago, la notificación al cliente hotelero, la evidencia del comerciante, la detección de intrusiones y la asignación de deberes entre Sabre, las propiedades, las marcas y las redes de tarjetas. No respalda pretender que se conoce cada hecho privado. Esa distinción es la esencia del análisis responsable. La responsabilidad debe seguir a la parte con control y evidencia, mientras que la incertidumbre debe permanecer visible hasta que una mejor evidencia la cierre.
Para los consejos directivos, compradores hoteleros, gerentes de viajes, reguladores y huéspedes, la conclusión es directa. No pregunte solo si una plataforma de reservas tuvo un incidente. Pregunte qué objeto de confianza fue perturbado, quién lo controlaba antes del evento, quién asumió el trabajo después de la divulgación y qué evidencia prueba que el límite de la plataforma es más seguro ahora. En la tecnología hotelera, la plataforma detrás de la reserva es parte de la relación con el huésped, sepa o no el huésped su nombre.

