Noticias para administradores de Google Cloud

Desbloqueando el misterio de una gestión de claves de seguridad más fuerte

Uno de los errores “clásicos” de la seguridad de los datos que implica la encriptación es el cifrado de la información y no asegurar la clave de cifrado de la manera adecuada. Para empeorar las cosas, un problema tristemente común es dejar la clave “cerca” de la información, como en la misma base de datos o en el mismo sistema que los archivos cifrados. Según se informa, esas prácticas fueron un factor que contribuyó a varias brechas de seguridad importantes. Una investigación reveló que, en algunos casos, la encriptación se aplicaba para el cumplimiento de los criterios de seguridad pero sin un modelo de amenaza claro, la gestión de las claves era una idea tardía o ni siquiera se consideraba.

Se podría argumentar que la clave debe estar mejor protegida que los datos que encripta (o, en términos más generales, que la clave debe tener controles más fuertes sobre ella que los datos que protege). Si la clave se almacena cerca de los datos, la implicación es que los controles que aseguran la clave no son, de hecho, mejores.

Los reglamentos ofrecen orientación sobre la gestión de las claves, pero pocos dan consejos precisos sobre dónde guardar las claves de cifrado en relación con los datos cifrados. Mantener las claves “lejos” de los datos es obviamente una buena práctica de seguridad, pero una que lamentablemente es mal entendida por muchas organizaciones. ¿Cómo se mide “lejos” en el terreno de la informática? 

Ahora, agreguemos la computación en la nube a la ecuación. Una línea de pensamiento particular que surgió en los últimos años fue: “así como no puedes mantener la clave en la misma base de datos, no puedes mantenerla en la misma nube”.

La reacción esperada aquí es que la mitad de los lectores dirán “¡Obviamente!” mientras que la otra mitad puede decir “¿Qué? ¡Eso es una locura!” ¡Exactamente por eso es un gran tema de análisis!

Por ahora, primero, señalemos lo obvio: no existe “la nube”. Y, no, no se trata de un dicho popular sobre que es “el ordenador de otro”. Aquí estamos hablando de la falta de algo monolítico que se llama “la nube”.

Por ejemplo, cuando Google encripta los datos en reposo, hay una serie de opciones de gestión de claves. De hecho, siempre utilizan su encriptación predeterminada y almacena las claves de forma segura (frente a los modelos y requisitos de amenazas específicas) y transparente. Puedes leer sobre esto en detalle en este documento. Lo que notarás, sin embargo, es que las claves siempre están separadas de los datos cifrados con muchas, muchas barreras de muchos tipos diferentes. Por ejemplo, en el desarrollo de aplicaciones, una buena práctica común es mantener las claves en un proyecto separado de las cargas de trabajo. Así pues, esto introduciría límites adicionales como la red, la identidad, la configuración, el servicio y probablemente también otros límites. La cuestión es que mantener las claves “en la misma nube” no significa necesariamente que se esté cometiendo el mismo error que mantener las claves en la misma base de datos …., salvo en algunos casos especiales en los que esta práctica sí sería un error (que se examinarán a continuación). 

Además, la nube introduce una nueva dimensión en el riesgo de mantener la clave “cerca” de los datos: donde la clave se almacena físicamente frente a quien controla la clave. Por ejemplo, ¿está la clave cerca de los datos si se encuentra dentro de un dispositivo de hardware seguro (por ejemplo, un HSM) que está ubicado en la misma red (o: en el mismo centro de datos de la nube) que los datos? O, ¿está la clave cerca de los datos si está localizada dentro de un sistema en otro país, pero las personas con credenciales para acceder a los datos también pueden acceder a la clave con ellas? Esto también plantea la pregunta de quién es el responsable final si la clave está comprometida, lo que complica aún más el asunto. Todo esto plantea dimensiones interesantes para explorar.

Por último, hay que tener en cuenta que la mayor parte del debate aquí se centra en los datos en reposo (y tal vez un poco en los datos en tránsito, pero no en los datos en uso).

Riesgos

Ahora que entendemos que el concepto de “en la misma nube” está matizado, veamos los riesgos y requisitos que están impulsando el comportamiento en relación con el almacenamiento de claves de cifrado.

Antes de empezar, ten en cuenta que si tienes una aplicación on-premise con una arquitectura pobremente diseñada que almacena las claves en la misma base de datos o en el mismo disco que tus datos cifrados, y esta aplicación se migra a la nube, el problema por supuesto también migra a la nube. La solución a este desafío puede ser utilizar los mecanismos de gestión de claves nativas de la nube (y, sí, eso implica cambiar la aplicación).   

Dicho esto, aquí se indican algunos de los principales riesgos y problemas:

Error humano

En primer lugar, un riesgo muy visible es, por supuesto, un error humano no malintencionado que conduce a la divulgación de claves, la pérdida, el robo, etc. Piense en los errores de los desarrolladores, el uso de una fuente de entropía deficiente, la configuración errónea o permisos relajados, etc. No hay nada específico de la nube en ellos, pero su impacto tiende a ser más dañino en la nube pública. En teoría, los errores del proveedor de la nube que conducen a una posible revelación de la clave también están en este punto.

Atacante externo

En segundo lugar, el robo de claves por parte de un atacante externo también es un reto que se remonta a la era pre-nube. Se sabe que los actores de primer nivel han atacado los sistemas de gestión de claves (KMS) para obtener un mayor acceso a los datos. También saben cómo acceder y leer los registros de las aplicaciones, así como observar el tráfico de la red de aplicaciones, todo ello puede dar pistas sobre la ubicación de las claves. Instintivamente, muchos profesionales de la seguridad que obtuvieron la mayor parte de su experiencia antes de la nube se sienten mejor acerca de un KMS si está tras varias capas de firewalls. Los atacantes externos tienden a encontrar los errores humanos mencionados anteriormente y, como resultado, convierten estas debilidades en puntos débiles.

Amenaza interna

Tercero, y aquí es donde las cosas se ponen interesantes: ¿qué pasa con las amenazas internas? Los modelos de computación en la nube implican dos modelos diferentes de amenaza interna: las personas con información privilegiada del lado de la organización del usuario y los del lado del proveedor de servicios en la nube. Mientras que parte de la atención pública se centra en los proveedores de servicios en la nube, o CSP (Cloud Service Providers), es el lado del cliente quien suele tener las credenciales válidas para acceder a los datos. Si bien algunos empleados de los proveedores de CSP podrían (en teoría y sujetos a muchos controles de seguridad con los niveles de connivencia masiva necesarios) acceder a los datos, es en el lado de los clientes de la nube los que realmente tienen acceso directo a sus datos en la nube mediante credenciales válidas. Desde la perspectiva del modelado de amenazas, la mayoría de los maleantes encontrarán el eslabón más débil -probablemente en la organización de usuarios de la nube- para explotarlo primero sin necesitar mayores esfuerzos más adelante.

Cumplimiento

En cuarto lugar, puede haber mandatos y reglamentos que prescriban el manejo de claves de una manera particular. Muchos de ellos son anteriores a la computación en nube, por lo que no ofrecerán una orientación explícita para el caso de la nube. Es útil diferenciar los requisitos explícitos, los requisitos implícitos y lo que puede denominarse requisitos “interpretados” o internos. Por ejemplo, una organización puede tener una política de mantener siempre las claves de cifrado en un sistema determinado, aseguradas de una manera particular. Esas políticas internas pueden haber estado en vigor durante años, y su origen exacto basado en el riesgo suele ser difícil de rastrear porque ese origen puede tener décadas de antigüedad. De hecho, los sistemas y prácticas de seguridad complejos, a menudo heredados, podrían en realidad hacerse más sencillos (y comprensibles) con técnicas más modernas ofrecidas a través de los recursos y prácticas de la computación en nube.

Además, algunas empresas multinacionales pueden haber sido objeto de algún tipo de asunto jurídico resuelto y sellado con una entidad estatal o gubernamental separada de cualquier tipo de actividad de cumplimiento normativo. En estos casos, las obligaciones podrían requerir la aplicación de algunas salvaguardias técnicas que no pueden compartirse ampliamente dentro de la organización.

Soberanía de los datos

Por último, y aquí es donde las cosas se desvían rápidamente fuera del dominio digital, hay riesgos que se sitúan fuera del ámbito de la ciberseguridad. Éstos pueden estar relacionados con diversas cuestiones de soberanía de los datos y la soberanía digital, e incluso con riesgos geopolíticos. Para abreviar, no importa si estos riesgos son reales o percibidos (o si el mero hecho de tener la llave impediría en última instancia su divulgación). Lo que sí es importante es que se cumplan los requisitos para el control directo de las claves de cifrado. Por ejemplo, se informó de que el temor a las “citaciones ciegas o a terceros” ha impulsado algunas de las decisiones de las organizaciones en materia de seguridad de los datos. 

¿Están estos cinco riesgos por encima de lo “real”? ¿Importa que los riesgos no sean reales, pero que una organización planee actuar como si lo fueran? Y si una organización los toma en serio, ¿qué opciones en cuanto a arquitecturas tienen?

Arquitecturas y enfoques

En primer lugar, una afirmación contundente: las arquitecturas modernas de las nubes hacen que algunos de los errores de cifrado sean menos probables de cometer. Si un determinado rol de usuario no tiene acceso al KMS de la nube, no hay forma de obtener “accidentalmente” las claves (lo que equivale a encontrarlas en un disco en un directorio compartido, por ejemplo). De hecho, la identidad sirve como un fuerte límite en la nube. 

Es notable que confiar, por ejemplo, en un firewall (barrera de la red) más que en un sistema de autenticación bien diseñado (barrera de la identidad) es una reliquia de los tiempos anteriores a la nube. Además, el control de acceso a la nube o los registros en la nube cada vez que se utiliza una clave, cómo y por quién, pueden ser una seguridad mejor de la que podrían aspirar la mayoría de los on-prem.

Claves de cifrado en la nube almacenadas en sistemas basados en software

Por ejemplo, si es necesario aplicar prácticas de gestión clave específicas (cumplimiento interno, riesgos, ubicación, revocación, etc.), se puede utilizar Google Cloud KMS con CMEK. Ahora, tomando la definición amplia, la clave está en la misma nube (Google Cloud), pero la clave definitivamente no está en el mismo lugar que los datos (detalla cómo se almacenan las claves). Las personas que pueden acceder a los datos (por ejemplo, a través de credenciales válidas para el acceso a los datos, es decir, los clientes internos) no pueden llegar a la clave, a menos que tengan permisos de acceso específicos para acceder a KMS (la identidad sirve como una barrera fuerte).  Por lo tanto, ningún desarrollador de aplicaciones puede obtener accidentalmente las claves o diseñar la aplicación con claves incrustadas.

Esto aborda la mayoría de los riesgos mencionados, pero, obviamente, no aborda algunos de ellos. Ten en cuenta que mientras el cliente de la nube no controla las salvaguardas que separan las claves de los datos, pueden leer sobre ellos.

Claves de encriptación en la nube almacenadas en sistemas basados en hardware

A continuación, si hay una necesidad de asegurarse de que un humano no puede llegar a la clave, sin importar los permisos de su cuenta, un HSM de la nube es una forma de almacenar las claves dentro de un dispositivo de hardware. En este caso, la barrera que separa las claves de los datos no es sólo la identidad, sino las características de seguridad de un dispositivo de hardware y todos los controles de seguridad validados que se aplican a al dispositivo y alrededor de la ubicación del mismo. Esto aborda casi todos los riesgos anteriores, pero no los aborda todos. También incurre en algunos costes y posibles fricciones. 

También en este caso, aunque el cliente de la nube puede solicitar garantías sobre el uso de un dispositivo de seguridad de hardware y otros controles, el cliente de la nube no controla las salvaguardias que separan las claves de los datos, sino que sigue confiando en la confianza del proveedor de servicios de la nube en el manejo del hardware. Por lo tanto, aunque el acceso al material de las claves está más restringido con las claves HSM que con las claves de software, el acceso al uso de las claves no es intrínsecamente más seguro. Además, la clave dentro de un HSM alojado por el proveedor se considera que está bajo el control lógico o físico del proveedor de la nube, por lo que no se ajusta al verdadero significado o filosofía del requisito de “Hold Your Own Key” (HYOK).

Claves de cifrado en la nube almacenadas fuera de la infraestructura del proveedor

Por último, hay una forma de abordar realmente los riesgos mencionados, incluido el último punto relacionado con las cuestiones geopolíticas. Y la decisión es simplemente practicar Hold Your Own Key (HYOK) implementado con tecnologías como Google Cloud External Key Manager (EKM). En este escenario, los bugs de los proveedores, los errores, los ataques externos a las redes de proveedores, los internos del proveedor de servicios en la nube no importan ya que la llave nunca aparece allí. Un proveedor de nubes no puede revelar la clave de cifrado a nadie porque no la tiene. Esto aborda todos los riesgos mencionados, pero incurre en algunos costes y posibles fricciones. Aquí, el cliente de la nube controla las salvaguardas que separan las claves de los datos, y puede solicitar garantías de cómo se implementa la tecnología EKM. 

Naturalmente, este enfoque es críticamente diferente de cualquier otro enfoque, ya que incluso los dispositivos HSM gestionados por el cliente y ubicados en el centro de datos del proveedor de la nube no proporcionan el mismo nivel de garantía.

Puntos clave

• No hay una prohibición total de guardar las claves con el mismo proveedor de nubes que sus datos o “en la misma nube”. El concepto mismo de “clave en la misma nube” es matizado y debe ser revisado a la luz de sus regulaciones y modelos de amenaza -algunos riesgos pueden ser nuevos, pero otros serán totalmente mitigados por el paso a la nube-. Revisa tus riesgos, tolerancias de riesgo y motivaciones que impulsan tus decisiones de gestión de claves.
• Considera la posibilidad de hacer un inventario de tus claves y anota cuán lejos o cerca están de tus datos. En general, ¿están mejor protegidos que los datos? ¿Coinciden las protecciones con el modelo de amenaza que tienes en mente?  Si se descubren nuevas amenazas potenciales, despliega los controles necesarios en el entorno.
• Las ventajas para la gestión de claves utilizando el KMS de Google Cloud incluyen un IAM completo y consistente, políticas, justificación de acceso, registro, así como probablemente una mayor agilidad para los proyectos que utilizan tecnologías nativas de la nube. Por lo tanto, utiliza tu proveedor de nube KMS para la mayoría de las situaciones que no requieren de confianza externalizada u otras situaciones.
• Los casos en los que es necesario mantener las claves fuera de la nube están claramente especificados por la regulación o los requisitos de negocio; un conjunto de situaciones comunes para esto se discutirá en el próximo blog. ¡Mantente informado!

---

Presentación del nuevo Dashboard Público de Estado de la Plataforma Google Maps

El equipo de la plataforma de Google Maps se esfuerza por proporcionar el mayor nivel de servicio posible a nuestros usuarios. Aún así, de vez en cuando, ocurren interrupciones inesperadas del servicio. Cuando su equipo experimenta una interrupción u otro desafío técnico, una de las primeras evaluaciones que deben realizar es si el problema es con un proveedor de servicios externo o interno. Como parte de nuestro compromiso con la transparencia y la rapidez a la hora de comunicar el estado de nuestros productos, y los incidentes cuando se producen, hemos implementado el Dashboard de Estado Público de la Plataforma Google Maps. 

El Dashboard Público de Estado proporciona información sobre el estado de los productos generalmente disponibles y cubiertos por el SLA de la plataforma de Google Maps. Puedes consultar el panel para ver el estado actual de cualquiera de esos servicios. Incluso puedes hacer clic en “Ver historial” para ver las incidencias que se han producido en los últimos 365 días. Los incidentes que se muestran en el panel se clasifican como Interrupciones (naranja) o Cortes (rojo), dependiendo de su gravedad. Todos los incidentes son verificados primero por nuestros ingenieros de soporte, por lo que puede haber un ligero retraso desde el momento en que se produjeron realmente. 

Para un rápido acceso al tablero de mandos, puedes marcar el sitio en tu barra de favoritos. Y en un futuro próximo, podrás tener acceso a actualizaciones mediante las notificaciones push. Si experimentas un problema que no aparece en el tablero, contacta con Soporte. Y para obtener más información sobre lo que se publica en el tablero, consulta las preguntas frecuentes (FAQ). 

El Dashboard Público de Estado es el primer lugar donde ir a comprobar cuando descubres un problema que te afecta. Pero no es la única forma en que comunicamos los problemas conocidos o informados y brindamos asistencia. Dependiendo de tu situación y necesidades particulares, puede que también quieras utilizar alguno de nuestros otros recursos. Aquí tienes un resumen de algunos otros que deberías conocer: 

Rastreador de Problemas

Nuestro Rastreador de Problemas público es donde mantenemos activamente una lista de problemas conocidos y reportados. El rastreador de problemas incluye problemas técnicos que no son tan graves como para aparecer en el Tablero de Estado. Aquí es donde puedes ver fácilmente los errores ya reportados y agregar tus propios comentarios para ayudar a nuestros equipos a investigar los problemas o identificar soluciones. En caso de que experimentemos un fallo, aparecerá un mensaje en forma de banner en la sección de asistencia de Google Maps de la consola de Google Cloud, con un enlace al rastreador de problemas para obtener más información que te permita conocer el estado del problema en tiempo real. Tanto si quieres informar de un fallo como si tienes una solicitud de nueva función, empieza por presentar una solicitud. Incluir un código de muestra o una captura de pantalla nos ayudará a identificar el problema y a responder más rápidamente.

Grupos de notificación por correo electrónico

Para obtener actualizaciones técnicas sobre los productos de la plataforma de Google Maps, notificaciones de interrupciones y anuncios de funciones, puedes suscribirte al grupo de notificaciones por correo electrónico de Google para recibir las actualizaciones directamente en tu bandeja de entrada. 

Contactos esenciales 

Pronto, Google comenzará a enviar notificaciones importantes a tus Contactos Esenciales. Para personalizar qué miembros del equipo recibirán estas notificaciones de la plataforma de Google Maps en un futuro próximo, puedes establecer tus Contactos Esenciales en la consola de Google Cloud proporcionando tu propia lista de contactos. Puedes añadir tanto alias individuales como de grupo para asegurarte de que estás reduciendo de forma preventiva el impacto de los cambios de personal. Puedes obtener más información sobre las categorías de notificación y sobre cómo habilitar los Contactos esenciales aquí. 

Visita la documentación de Google sobre gestión de incidencias para obtener más información. Y para obtener más información sobre la plataforma de Google Maps, visita su página web.