Aspectos importantes del cumplimiento normativo para los contenedores y Kubernetes

Si trabaja con contenedores, seguramente ya ha pensado en los posibles riesgos de seguridad. La protección de los datos confidenciales es de suma importancia, ya sea que recién haya adoptado un enfoque de DevOps para los flujos de trabajo o que tenga un canal de CI/CD consolidado.

El control de acceso basado en funciones (RBAC) es el método estándar para gestionar la autorización en los extremos de la API de Kubernetes. La configuración del RBAC de su clúster de Kubernetes controla quién puede ejecutar determinados verbos u operaciones en ciertos tipos de recursos dentro de algunos espacios de nombres. Sin embargo, no establece la manera en que debe configurar las funciones. Para ello, se utilizan los marcos de cumplimiento normativo.

En muchos sectores, el cumplimiento de los requisitos normativos es fundamental para los negocios. Si bien este aspecto podría obstaculizar el desarrollo de las aplicaciones en contenedoresen la nube y su ejecución, los marcos y las tecnologías evolucionan rápidamente para permitir que las empresas cumplan con todas las normas en un entorno de nube. Los principales marcos normativos para las aplicaciones en contenedores son:

• Indicadores de CIS para Kubernetes y Docker
• Publicación especial 800-190 del NIST
• PCI
• HIPAA

El cumplimiento normativo consiste en garantizar la seguridad de las aplicaciones. Sin embargo, puede implicar mucho más que eso, ya que exige a las empresas que demuestren a un tercero que estas se encuentran protegidas permanentemente. Asimismo, implica realizar seguimientos y mantener registros para garantizar que las normas se aplican en todo momento.

El cumplimiento de las reglas representa un gran desafío, pero no hacerlo puede ser sumamente perjudicial para la economía de la empresa. De hecho, el costo promedio de las multas relacionadas con las infracciones en este aspecto es casi tres veces mayor que el costo que supone cumplir con ellas.

Por otra parte, las normas también definen la manera en que las empresas establecen las políticas de control de la seguridad. Incluso aquellas que no tienen la obligación de cumplir con los lineamientos de un marco en particular, pueden utilizarlos como punto de partida para establecer sus propias políticas internas, en lugar de crearlas desde cero.

Los marcos

Indicadores de CIS: estos indicadores, que desarrolló el Centro de Seguridad de Internet (CIS), proporcionan las prácticas recomendadas para el uso de Kubernetes y de los contenedores (en particular, aquellos que utilizan el tiempo de ejecución de Docker), pero ningún sector está obligado a seguirlas.

Publicación especial 800-190 del NIST: el marco del Instituto Nacional de Estándares y Tecnología (NIST) para la protección de los contenedores es uno de los muchos marcos de cumplimiento relacionados con la ciberseguridad que ha publicado esta institución. Todos los organismos del gobierno de los Estados Unidos, o las empresas que tienen un contrato con él, deben cumplir con los requisitos de la NIST 800-190.

PCI: cinco grandes empresas de tarjetas de crédito se asociaron para desarrollar el marco de la Industria de Tarjetas de Pago (PCI), el cual abarca a aquellas que almacenan, procesan o transmiten la información relacionada con los pagos.

HIPAA: las medidas de seguridad tecnológica que establece la ley HIPAA incluyen los métodos de recopilación, procesamiento y transmisión de la información de salud personal, la cual se encuentra protegida y en formato electrónico.

La publicación especial 800-190 del Instituto Nacional de Estándares y Tecnología (NIST 800-190) brinda un marco que permite conocer no solo algunos de los desafíos asociados con la protección de las aplicaciones en contenedores, sino también lo que necesitan las empresas para mejorar el perfil de seguridad de estos sistemas.

Si bien los lineamientos del NIST se crearon para los organismos del gobierno de los Estados Unidos, o las empresas que tienen un contrato con él, cualquier organización puede aplicarlas para mejorar su seguridad general o para facilitar el cumplimiento de otros marcos normativos, como la PCI y la HIPAA.

Los riesgos

La NIST 800-190 señala las fuentes habituales de puntos vulnerables para las aplicaciones en contenedores, que incluyen:

• Imágenes comprometidas
• Errores de configuración en las imágenes de contenedores
• Imágenes de contenedores no confiables
• Datos confidenciales mal gestionados
• Errores de configuración en los controles de acceso
• Puntos vulnerables en el sistema operativo
• Superficies de ataque innecesariamente grandes

Asimismo, la NIST 800-190 subraya la necesidad de que las empresas aborden la seguridad de las aplicaciones en contenedores con un enfoque distinto al que utilizaban en los sistemas tradicionales, ya que sus factores de riesgo no son los mismos que presentan las máquinas virtuales y, además, requieren un conjunto diferente de prácticas de seguridad.

Para la NIST 800-190, es importante que las empresas:

• Utilicen herramientas específicas para gestionar los puntos vulnerables de las imágenes durante todo su ciclo de vida, es decir, desde el diseño hasta la implementación y la ejecución.
• Garanticen que las imágenes cumplan con las prácticas recomendadas de configuración.
• Almacenen los datos confidenciales fuera de la imagen, utilicen Kubernetes para gestionarlos, permitan el acceso a ellos solo por parte de los contenedores que los necesitan e implementen el cifrado en reposo y en tránsito para protegerlos.
• Utilicen una conexión segura a la hora de extraer información de los registros o de agregarla a ellos.
• Se aseguren de que los contenedores siempre utilicen la versión más reciente de las imágenes.
• Segmenten el tráfico de la red para aislar las redes que transmiten información confidencial de las que no.
• Utilicen Kubernetes para introducir los nodos de forma segura y los detallen en un inventario junto con sus estados de conectividad.
• Controlen el tráfico de salida de los contenedores.
• Garanticen el cumplimiento permanente de las normas de configuración para los tiempos de ejecución de los contenedores, como los indicadores de CIS.
• Apliquen medidas de seguridad para detectar amenazas o posibles intrusiones en los contenedores y la infraestructura.
• Utilicen un sistema operativo sólido y específico para los contenedores con una superficie de ataque lo más pequeña posible.
• Se aseguren de que los contenedores tengan la menor cantidad de permisos posible para que funcionen acorde a lo previsto, a fin de prevenir la manipulación del sistema de archivos del host.

Todas las empresas, incluso las que no tienen la obligación de cumplir con la NIST 800-190, deberían considerarlo un marco útil para mejorar su estrategia de seguridad. Esto se debe a que aborda los requisitos de seguridad específicos de cada etapa (diseño, implementación y ejecución) y garantiza que se tenga en cuenta durante todas ellas.

El Estándar de Seguridad de Datos (DSS) para la Industria de Tarjetas de Pago (PCI) data del año 2004, cuando Visa, MasterCard, American Express, Discover y JCB decidieron elaborar una serie de normas en torno a la seguridad y la protección de los datos que pudieran aplicarse a todo el sector. Desde su publicación, se ha actualizado en varias ocasiones para adaptarse a los cambios en la tecnología. Estas normas se aplican a todo lo relacionado con el entorno de datos de los titulares de tarjetas, lo cual abarca las personas, los procesos y las tecnologías de software y hardware que almacenan, procesan o transmiten esa información.

Cumplir con los requisitos normativos de la PCI no es nada sencillo e implica un gasto promedio por parte de las empresas de US$ 5,5 millones al año. Sin embargo, no hacerlo puede ser mucho más costoso, ya que las sanciones alcanzan los US$ 14,8 millones al año, en promedio. Si cuenta con las herramientas y los procesos adecuados, esta tarea no debería representar un gran problema.

El DSS para la PCI establece doce requisitos que se agrupan en seis objetivos generales:

Desarrolle y mantenga un sistema de red seguro

1. Instale y mantenga una configuración de firewalls para proteger los datos que pertenecen a los titulares de tarjetas.
2. No utilice los valores predeterminados que proporcionan los proveedores para las contraseñas del sistema y otros parámetros de seguridad.

Proteja los datos de los titulares de tarjetas

1. Proteja los datos almacenados de los titulares de tarjetas.
2. Cifre la transmisión de los datos de los titulares de tarjetas en las redes públicas abiertas.

Mantenga programas de gestión de los puntos vulnerables

1. Proteja todos los sistemas contra los malware y actualice regularmente los software antivirus.
2. Desarrolle y mantenga aplicaciones y sistemas seguros.
3. Implemente medidas sólidas de control de acceso.

Permita el acceso a los datos de los titulares de tarjetas solo cuando sea absolutamente necesario para la empresa

1. Identifique y autentique el acceso a los elementos del sistema.
2. Restrinja el acceso físico a los datos de los titulares de tarjetas.

Supervise y evalúe las redes con regularidad

1. Rastree y supervise todos los accesos a los recursos de red y a los datos de los titulares de tarjetas.
2. Pruebe los sistemas y los procesos de seguridad periódicamente.

Mantenga políticas de seguridad de la información

1. Mantenga una política que aborde la seguridad de la información para todo el personal.

Cumplimiento de las normas de la PCI para las aplicaciones en contenedores

Varios de los requisitos que establecen estos seis objetivos son sumamente relevantes para los entornos de contenedores y Kubernetes. Evalúe sus herramientas para asegurarse de que cumplen con los siguientes puntos:

1.1.2 Diagrama de red actual que identifica todas las conexiones entre el entorno de datos de los titulares de tarjetas (CDE) y otras redes, lo cual incluye cualquier red inalámbrica.

1.1.4 Requisitos para tener un firewall en cada conexión a Internet y entre la zona desmilitarizada y la red interna.

1.2 Desarrolle configuraciones para los firewalls y los enrutadores que restrinjan las conexiones entre las redes no confiables y los elementos del sistema que se encuentran en los entornos de datos de los titulares de tarjetas.

1.2.1 Restrinja el tráfico de entrada y salida al necesario para el entorno de datos de los titulares de tarjetas, y rechace el restante.

1.3.2 Limite el tráfico de entrada de Internet a las direcciones IP que se encuentran dentro de la zona desmilitarizada.

1.3.4 No permita que el tráfico de salida no autorizado de los entornos de datos de los titulares de tarjetas ingrese a Internet.

1.3.5 Admita solo las conexiones "establecidas" en la red.

2.1 Cambie los valores predeterminados que proporciona el proveedor y elimine o deshabilite las cuentas predeterminadas innecesarias antes de instalar un sistema en la red.

2.2 Elabore estándares de configuración para todos los elementos del sistema. Asegúrese de que contemplen todos los puntos vulnerables de seguridad conocidos y que concuerden con las normas de fortalecimiento de la seguridad de los sistemas que ya se aceptaron en el sector.

2.2.1 Implemente solo una función principal por servidor a fin de evitar la coexistencia de funciones que requieran diferentes niveles de seguridad en el mismo servidor. (Por ejemplo, los servidores web, los servidores de bases de datos y los sistemas de nombres de dominio se deben implementar en servidores separados).

2.2.2 Habilite solo los servicios, protocolos, daemons, etc., que sean necesarios para el funcionamiento del sistema.

2.2.3 Implemente funciones de seguridad adicionales para los servicios, protocolos o daemons necesarios que no se consideren seguros.

2.2.5 Elimine todas las funciones que resulten innecesarias, como las secuencias de comandos, los drivers, los sistemas secundarios, los sistemas de archivos, los servidores web, etc.

2.3 Cifre todos los accesos administrativos que no sean de consola utilizando un método criptográfico sólido.

2.4 Lleve un inventario de los elementos del sistema que están dentro del alcance del DSS de la PCI.

3.6.2 Proteja la distribución de las claves de cifrado.

6.1 Establezca un procedimiento para identificar los puntos vulnerables de seguridad usando fuentes externas confiables que brinden información sobre ellos, y clasifíquelos según su nivel de riesgo (por ejemplo, "alto", "medio" o "bajo").

6.2 Instale los parches de seguridad que proporcionan los proveedores para proteger todos los elementos del sistema y los software de los puntos vulnerables conocidos. Instale los más importantes en el plazo de un mes desde su lanzamiento.

6.4.1 Separe los entornos de desarrollo y prueba de los entornos de producción, y utilice herramientas de control de acceso para garantizar esa división.

6.4.2 Separación de las funciones entre los entornos de desarrollo y prueba, y los de producción.

6.5.1 Fallas que permiten la inserción de código malicioso (especialmente, de SQL). También tenga en cuenta la de comandos en el sistema operativo, LDAP y Xpath, así como otros errores del mismo tipo.

6.5.3 Almacenamiento cifrado poco seguro.

6.5.4 Comunicaciones poco seguras.

6.5.6 Todos los puntos vulnerables de "alto riesgo" detectados durante el proceso de identificación (como se define en el Requisito 6.1 del DSS de la PCI).

10.2.5 Implemente registros de auditoría automatizados para todos los elementos del sistema, a fin de reconstruir el uso y los cambios de los mecanismos de identificación y autenticación (lo cual incluye la creación de cuentas nuevas y el aumento de privilegios), y todas las modificaciones, incorporaciones y eliminaciones de las cuentas con privilegios de administrador o superusuario.

11.2.1 Lleve a cabo análisis internos trimestrales para detectar puntos vulnerables, y abórdelos. Vuelva a realizar el análisis para verificar que todos los puntos que sean de "alto riesgo" se hayan corregido según la clasificación establecida por la empresa (como se define en el Requisito 6.1). Los análisis deben estar a cargo de personal calificado.

11.5 Implemente un mecanismo de detección de cambios (por ejemplo, herramientas de control de la integridad de los archivos) para alertar al personal sobre las modificaciones no autorizadas (cambios, adiciones y eliminaciones) en los archivos más importantes del sistema, los de configuración o los de contenido, y configure el software para que compare los archivos fundamentales al menos una vez por semana.

11.5.1 Implemente un procedimiento para responder a las alertas que genera el mecanismo de detección de cambios.

La Ley de Portabilidad y Responsabilidad de Seguros de Salud (HIPAA) de 1996 dio lugar a un marco de cumplimiento normativo que controla la confidencialidad de los registros de salud de los pacientes. En 2003, se incorporó la Regla de seguridad, que regula los registros en formato digital. Todas las empresas que manejen información de salud protegida en formato electrónico (ePHI) de índole personal deben cumplir con los requisitos normativos de la HIPAA. Esto incluye las aplicaciones que utilizan directamente los proveedores de servicios médicos para la atención, la comunicación o la facturación.

El principal desafío en torno al cumplimiento de esta norma es que el marco de seguridad no proporciona información detallada y específica, sino que brinda orientación general sobre cómo las empresas deben cumplir con estas directrices en los contenedores y Kubernetes. Por otro lado, no siempre resulta evidente cuál es la información de salud que debe protegerse y cuál no, como sí sucede con la información de las tarjetas de crédito, para la cual se utilizan las normas de cumplimiento de la PCI.

No solo los proveedores de atención médica deben cumplir con los requisitos de la ley HIPAA, sino también cualquier empresa que les preste sus servicios (por ejemplo, de almacenamiento o facturación), siempre que dicho servicio maneje información de salud personal en formato electrónico (ePHI).

Las normas que establece la Regla de seguridad de la HIPAA se dividen en tres tipos de medidas: administrativas, físicas y técnicas. Las medidas técnicas, que se refieren a la infraestructura de TI, incluyen los siguientes estándares:

• Control de acceso
• Controles de auditoría
• Integridad
• Autenticación
• Seguridad de la transmisión de datos

Esta regla no detalla la manera en la que las organizaciones deben proteger la ePHI ni es específica para las aplicaciones en contenedores. Por lo general, lo ideal para comenzar a cumplir con los requisitos de la HIPAA es aplicar el marco NIST 800-190, ya que proporciona lineamientos y prácticas recomendadas para la seguridad de los contenedores. A diferencia de la HIPAA, este marco fue especialmente diseñado para los contenedores, por lo que resulta más fácil demostrar su cumplimiento. Sin embargo, para cumplir con los requisitos de esta Ley, también es importante implementar otros controles de segregación de los datos que protejan la ePHI y la mantengan separada de otro tipo de información.

Asimismo, exige que las empresas mantengan copias de seguridad de los datos y de los archivos de configuración, de modo que la aplicación pueda recuperarse por completo y garantizar el cumplimiento permanente.