Hasta el momento de escribir este artículo, muchos organismos encargados de regular normativas de cumplimiento no incluyen directrices específicas relacionadas con los procesos o productos específicos de los entornos nativos en la nube. Resulta irónico que, a pesar de esta falta de orientación (o posiblemente como resultado de esto), los equipos tienden a creer, como en el Mito 2, que los controles clásicos que se ajustan a los requisitos de cumplimiento en otros entornos también lo harán en una arquitectura nativa en la nube. Como ya hemos visto, los sistemas de control clásicos no son adecuados para un entorno de este tipo, pero esto no significa que debamos entrar en pánico o desesperarnos. Significa que el objetivo es contar con algo que demuestre que la empresa está poniendo en práctica sus «mejores esfuerzos» en línea con los términos establecidos por los organismos reguladores.
Qué incluyen los entornos nativos en la nube en cuanto a seguridad
Los entornos nativos en la nube, por lo general, incluyen controles para los componentes y las capas que se actualizan por separado unos de otros. Por ejemplo, si antes nos limitábamos a reforzar una máquina virtual y a analizar el malware, ahora es importante escanear las imágenes de los contenedores, escanear y reforzar la máquina virtual, y, también, escanear y reforzar el orquestador. Además de supervisar y registrar los eventos, para poder probar que se han implementado los controles.
Por ejemplo, las recomendaciones del PCI DSS (Estándar de Seguridad de Datos para la Industria de Tarjeta de Pago) exigen separar los sistemas PCI de los no PCI. Las recomendaciones hablan de cortafuegos, controles de acceso físico, autenticación multifactorial, supervisión activa y restricción del acceso administrativo como métodos para «proporcionar una garantía razonable de que el sistema fuera del ámbito de aplicación no pueda utilizarse para comprometer uno de sus componentes».
Para alcanzar el nivel de separación exigido por el PCI DSS en un clúster de Kubernetes multi-tenant, tendríamos que tener registros y procesos separados, dividir los recursos entre las diferentes entidades y los administradores autorizados a través de los espacios de nombres de K8s; a continuación, garantizar un etiquetado y marcado adecuados dentro de dichos espacios de nombres para reforzar aún más la segregación, y se debería exigir un control de acceso basado en roles para controlar el acceso durante el tiempo de ejecución y a las medidas de seguridad del cortafuegos utilizadas por la herramienta de seguridad para evitar quebrantamientos de la segmentación deseada. Todo es interpretable, pero si se toman medidas y se demuestra que estos controles se están utilizando, la mayoría de los auditores se quedarán más que satisfechos.
Al igual que en entornos Kubernetes en cualquier otra plataforma IT la segmentación es algo que no puede aplicarse con tecnologías tradicionales tipo VLAN. Nuevas aproximaciones basadas en arquitecturas SASE permiten por ejemplo abordar una segmentación extrema (zero-trust) de manera mucho más sencilla de implementar y mantener.
