Seguridad como código: cómo se basa en políticas repetibles …



El enfoque de SaC permite a los usuarios codificar y hacer cumplir un estado seguro de implementación de la configuración de la aplicación que limita el riesgo.

La adopción de prácticas de infraestructura como código (IaC) para ayudar a automatizar y acelerar las operaciones de TI realmente se ha afianzado en los últimos años, incluso más durante la pandemia.

Con IaC, las organizaciones se están alejando de un modelo en el que se requiere que los humanos realicen cambios manuales para configurar e implementar la infraestructura de aplicaciones, tanto en las instalaciones como en la mayoría de las veces, en la nube. IaC ofrece la promesa de automatización y patrones predecibles repetibles para la implementación de infraestructura de computer software. En la actualidad, se utilizan varios modelos y servicios populares para habilitar un enfoque de IaC, incluidos Terraform, Chef, Puppet, Ansible, SaltStack y AWS CloudFormations.

Si bien el enfoque tiene muchos beneficios, los enfoques de seguridad tradicionales generalmente ralentizan el ciclo de vida del desarrollo de software program y pueden evaporar los beneficios del uso de IaC. Es por eso que existe una necesidad actual de que las organizaciones adopten un enfoque de «seguridad como código» (SaC) para reconocer plenamente los beneficios de la automatización que puede proporcionar la infraestructura componible, repetible y completamente auditable.

IaC requiere un nuevo enfoque de seguridad
En pocas palabras, asegurar el código de automatización es elementary porque, en muchos casos, literalmente dirige nuestros negocios. Los sistemas IaC están implementando recursos y aplicaciones automáticamente. Una vulnerabilidad o una mala configuración en un flujo de trabajo de IaC podría tener un impacto en cascada en múltiples cargas de trabajo e implementaciones que podrían permitir que un atacante potencial induce mucho daño. IaC es muy poderoso, por lo que cuando ocurren errores, ocurren de manera rápida y exponencial.

Uno de los desafíos que plantea la seguridad de los flujos de trabajo automatizados es que, a menudo, puede haber varias rutas hacia un sistema o servicio para ejecutar una acción. También podría haber varias personas de diferentes partes de la organización que tengan acceso a los distintos puntos de entrada para IaC. Para agregar más complejidad, es posible que algunas organizaciones no se comuniquen de manera efectiva sobre los objetivos y los cambios necesarios en una organización distribuida.

Principios básicos de seguridad
Una foundation principal para proteger la infraestructura creada y administrada por Las plantillas IAC establecen primero una fuente de verdad para la configuración. Es necesario que haya una versión codificada de la configuración, generalmente en un repositorio de software program Git, que defina el estado de configuración deseado. Es un enfoque al que algunos se refieren como GitOps, que ayuda a habilitar IaC. Con una fuente de verdad definida, es hora de implementar procesos de acceso, auditoría y revisión.

  • Management de acceso. Con una fuente de verdad definida para la configuración, se pueden y deben aplicar controles seguros. Debe haber un manage de acceso que defina estrictamente quién puede acceder y realizar cambios en el código de configuración.
  • Auditoría y cumplimiento. Controlar el acceso es solo la primera parte del IaC de seguridad. Todos los cambios deben ser auditados y monitoreados para verificar el cumplimiento de la política corporativa y los marcos de cumplimiento normativo.
  • Revisión. Incluso con los controles de acceso y auditoría, los cambios que podrían no ser ideales aún pueden escaparse por las grietas. Por eso es imperativo tener también activamente un proceso de revisión y gestión de cambios para validar aún más el estado de la configuración de IaC y cualquier cambio.

Definir una ruta única y segura a la producción
Para asegurar IaC por completo, también debe haber una ruta única bien definida hacia la producción, de modo que todas las partes interesadas de la organización, incluidos los desarrolladores, las operaciones y la seguridad, estén involucradas.

Definir el camino hacia la producción a menudo se trata de romper los silos dentro de la empresa y centrarse en la colaboración entre equipos. La mayoría de las veces en el pasado, los desarrolladores han visto la seguridad como un bloqueador y no como un habilitador. El enfoque de seguridad como código puede ayudar a cambiar esa mentalidad al trabajar con los desarrolladores en un lenguaje que entiendan: el código.

Un concepto clave que hemos visto que funciona bien es el uso de barandillas, en lugar de puertas, como parte del proceso de SaC. En lugar de implementar una puerta, donde el código no puede pasar a menos que sea aprobado por seguridad, una barandilla mantiene el código dentro de ciertos límites definidos, lo que limita el riesgo.

Las barandillas pueden ayudar a los desarrolladores y las organizaciones a centrarse en la velocidad, sin sacrificar la seguridad.

Seguridad como código en la práctica
¿Cómo funciona realmente para mejorar la seguridad? La realidad es que con una visibilidad continua puede garantizar la corrección, alertar y luego corregir cualquier divergencia en un enfoque repetible, auditable y seguro.

Aquí hay solo un ejemplo en el que este enfoque puede ayudar. El problema de los depósitos de almacenamiento en la nube no seguros, a menudo en Amazon S3, está bien documentado y se ha informado ampliamente en Dim Looking through y otros lugares. El modelo SaC puede ayudar a eliminar ese riesgo de manera eficaz.

Al ejecutar evaluaciones de cumplimiento continuas de los entornos de nube, una organización puede recibir una alerta cada vez que un bucket de S3 se ha aprovisionado inadvertidamente con acceso público de lectura o escritura. Luego, un administrador puede ir al repositorio de Git donde se outline el código de configuración para el servicio IaC y realizar el cambio necesario para eliminar el riesgo. Una vez que se ha confirmado el cambio, puede pasar por el proceso de aprobación y, una vez aceptado, la canalización de IaC puede ejecutar el código para solucionar el problema en todas las implementaciones. Todo el proceso está registrado y también es auditable.

Los errores ocurren y las vulnerabilidades parecen provenir de nuevos lugares todo el tiempo. Pero con el enfoque de SaC, es posible codificar y hacer cumplir un estado seguro de implementación de la configuración de la aplicación que limita el riesgo.

Dan Hubbard es CEO de Lacework, impulsando la innovación y expandiendo la estrategia de seguridad de la compañía para nubes públicas y privadas. Una fuerza pionera en la seguridad de Online, la experiencia de Dan abarca desde la reputación y los sistemas de clasificación avanzados hasta los datos de seguridad a gran escala … Ver biografía completa

Lectura recomendada:

Más información





Enlace a la noticia unique