El papel de DevOps en la gestión de la seguridad en la nube
El cambio a la infraestructura de computación en la nube ha creado un panorama de desarrollo de software disperso, que ha sido fundamental en el crecimiento y la escala del desarrollo de software. DevOps ayuda a los equipos a crear, probar e implementar software a un ritmo acelerado, respaldando esa agilidad mediante el uso de una amplia gama de servicios durante todo el ciclo de vida del desarrollo de software. Sin embargo, hacer esto también ha introducido nuevas vulnerabilidades de seguridad cibernética que los silos tradicionales de seguridad de la información no están bien equipados para administrar. Para asegurar el entorno DevOps, se creó el sector DevSecOps, un campo cuyo principal pilar es la gestión de secretos.
La ciberseguridad es imprescindible
No debería sorprender que la seguridad en la nube se haya convertido en una parte integral de las responsabilidades del equipo de DevOps. Ser proactivo con respecto a la gestión de la seguridad en la nube (CSM) es fundamental.
Seguridad en la nube: secretos y cómo evitar que se filtren.
Por lo tanto, los desarrolladores, además de crear software, ahora deben proteger los secretos de sus organizaciones del acceso no autorizado o no autenticado y hacerlo durante el proceso de desarrollo. Pero, ¿qué es un secreto? Los secretos son credenciales digitales que respaldan el permiso de acceso, ya sea de persona a aplicación o de aplicación a aplicación. Este último emplea «secretos» como contraseñas, claves de cifrado, certificados y claves API, entre otros.
Para que DevOps proteja el código de las fugas de datos resultantes de filtraciones de secretos, primero deben ser conscientes de las muchas formas en que los secretos proliferan en su entorno. Los secretos aumentan a través de siete impulsores que incluyen: desarrollo basado en la nube nativa, infraestructura de múltiples nubes, arquitectura de microservicios, cambios de identidad de usuario a máquina, análisis de datos/AL/ML/IoT/dispositivos integrados y, sí, DevOps. Estos controladores crean vulnerabilidades porque permiten más oportunidades de errores, ya sea codificando secretos para acelerar las pruebas, utilizando bibliotecas de código abierto no seguras o descuidando la seguridad de la nube frente a la seguridad en la nube.
Si bien existen varias tecnologías para ayudar a administrar secretos, tanto comerciales como de código abierto, considere el presupuesto y los requisitos de su organización, las tecnologías que implementa actualmente y la experiencia de su equipo de DevOps con la administración de secretos, y las oportunidades para implementar y mantener esas tecnologías actualizadas y actualizadas. hasta la fecha.
Ocho formas en que los equipos de DevOps pueden ayudar a proteger la infraestructura de la nube
1- Identificar los requisitos necesarios
Prevenido es prevenido, por lo que cuanto antes se inicie este proceso, mejor. La mayoría de las empresas ya están, al menos parcialmente, en la nube, por lo que a veces es difícil dar un paso atrás para ver el panorama general.
No lo olvide: los servicios en la nube no son solo AWS, Azure y Google. Los servicios en la nube abarcan todas esas aplicaciones SaaS, desde la pila de contabilidad hasta Zoom. ¿Los equipos usan Slack u otro DM basado en SaaS?
Si los equipos de desarrollo o DevOps utilizan su canal de Slack para compartir secretos de la empresa, un ataque de fuerza bruta para obtener acceso a Slack puede poner en riesgo a toda la organización.
El acceso a la canalización de CI/CD debe definirse y administrarse con una gobernanza clara.
Dado que la mayoría de las violaciones de datos son causadas por errores humanos que conducen a errores de configuración, fuga de secretos y mala higiene digital, corresponde a DevOps y DevSecOps administrar quién tiene acceso a qué, un requisito básico de cada sistema de seguridad conectado.
El DBA necesita un acceso a los datos muy diferente al del equipo de desarrollo, etc. Al seguir una política de privilegios de acceso mínimo combinada con una pila configurada correctamente, podrá reducir el riesgo.
Todo IaaS, PaaS, o realmente cualquier XaaS, debe protegerse en el nivel más básico: en el nivel de credencial. Google envía alertas a sus clientes comerciales de forma regular, notificándoles sobre posibles filtraciones de credenciales.
Haga lo que haga, no se olvide de ShadowIT: asegúrese de que todos en la organización sepan que la filtración de sus credenciales podría ser el eslabón más débil de las joyas de la corona. ShadowIT aumenta el riesgo de una fuga de credenciales simplemente porque TI no está al tanto de las muchas plataformas externas que repentinamente se conectan a sistemas internos controlados.
Por último, aprende de los errores de otras personas. Intel tiene una práctica lista de verificación de seguridad que puede usar como base para identificar los requisitos de seguridad en la nub
2- Defina la arquitectura
Una vez que haya identificado los requisitos de seguridad en la nube de su organización, tendrá una imagen más completa del tipo de servicios en la nube que ya está utilizando y otros que necesita agregar.
La seguridad en la nube frente a la seguridad de la nube siempre debe ser una prioridad. No olvide que usted es responsable de proteger sus propias aplicaciones, datos, sistema operativo, acceso de usuarios y tráfico de red virtual. Más allá de estos, perfecciona tus conceptos básicos de configuración. Más del 5 % de los depósitos de AWS S3 están mal configurados para ser legibles públicamente.
Si bien las tres grandes nubes han invertido millones para proteger sus pilas, las empresas de PaaS no tienen esos presupuestos, así que verifique, verifique y verifique dos veces. Hay una razón por la que se llama «confianza cero».
Con SaaS y seguridad web, nuevamente la protección de credenciales es clave.
Cada tipo de arquitectura requiere su propio tipo de seguridad: sea diligente. Por ejemplo, una infraestructura de nube híbrida necesita un «triple golpe» de seguridad: el local debe ser altamente seguro con todos los puertos cerrados, el área de superficie rastreada y un Centro de operaciones de seguridad (SOC) altamente activo. El aspecto de la nube pública debe protegerse con la última y mejor tecnología de seguridad disponible con esa pila de nube pública. La conectividad entre ellos también debe protegerse contra ataques.
3- Analice los controles existentes e identifique las brechas
Adoptar un enfoque fragmentario para la pila de seguridad no funciona bien; construir desde cero es claramente un enfoque más completo y sólido. Aquí hay algunas opciones que lo hacen posible:
- Agente de seguridad de acceso a la nube (CASB)
- Plataformas de protección de cargas de trabajo en la nube (CWPP)
- Gestión de postura de seguridad en la nube (CSPM)
- Pruebas de seguridad de aplicaciones estáticas (SAST)
- Prevención de pérdida de datos (DLP)
Un CASB sirve como intermediario entre la organización y el proveedor de servicios en la nube, y ofrece auditoría de configuración, prevención de pérdida de datos, gobierno y monitoreo, entre otros servicios. Los CASB comunes incluyen Broadcom, Palo Alto y Forcepoint.
Los CWPP evitan las sobrecargas del sistema, como DDoS o código incorrecto que conduce a posibles desbordamientos de memoria. Supervisan los recursos informáticos de su nube desplegados en la infraestructura de la nube. CheckPoint, Trend Micro y Carbon Black ofrecen CWPP.
Los CSPM ayudan a detectar errores humanos (una de las principales causas de las infracciones de seguridad) al proporcionar una auditoría continua para detectar errores de configuración, incluido Spectral, entre otros.
AST escanea el código fuente en busca de posibles vulnerabilidades, como credenciales de acceso a la base de datos codificadas que se olvidan después de la prueba, para evitar que los secretos se divulguen debido a errores u omisiones humanos.
Los DLP pueden ser parte de un CASB o una tecnología separada que ofrece herramientas y políticas para proteger los datos confidenciales al reducir/eliminar el riesgo de exfiltración de datos, ya sea por parte de malos actores o recursos internos.
Estas herramientas se pueden usar individualmente o como parte de una pila de seguridad más grande. Se pueden usar en toda la organización o solo dentro de áreas específicas, por ejemplo, SAST para desarrollo.
4- Concéntrese en proteger sus secretos en la nube
En primer lugar, en el mundo ideal, a través de la educación, una cultura centrada en la seguridad y suficientes herramientas, nunca se filtrarán secretos. Pero el error humano eventualmente ganará. Por lo tanto, si bien, en general, el viejo dicho es «más rápido, más barato, mejor, elija dos», la nueva versión debe incluir «más seguro». Por supuesto, los ingresos iniciales se obtienen durante «más rápido» y «más barato», pero las repercusiones de ignorar «más seguro» pueden tener un impacto mucho más duradero en el negocio.
Los desarrolladores están bajo una enorme presión para sacar el código por la puerta. A veces toman atajos o intentan simplificar el acceso a las herramientas con una contraseña fácil de recordar, o rotan las contraseñas con un patrón fácil de adivinar.
Por lo tanto, el enfoque debe estar en la protección de credenciales. Las claves y contraseñas deben rotarse automáticamente cuando sea posible, eliminando la necesidad de interacción humana. Deben ser lo suficientemente fuertes para resistir ataques de fuerza bruta.
No olvide capacitar a los empleados para que estén al tanto de las amenazas “típicas” como phishing, smishing , enlaces envenenados, etc.
Sin embargo, no importa cuán cuidadoso sea un equipo, todos cometemos errores
5- Escanee en busca de errores de configuración
Como se mencionó anteriormente, en la carrera por ser más rápido, más rápido y mejor, los desarrolladores se han centrado en sacar el código por la puerta. Una forma de acelerar el proceso es codificar secretos, como el acceso a la base de datos, en las configuraciones. Ocasionalmente, toman atajos al establecer «derechos de acceso de lectura» en «público» para el control de calidad y las pruebas.
El problema es que los desarrolladores tienen tantas otras cosas en las que se están enfocando que a veces se olvidan de quitar estos privilegios de acceso, dejando a todo el sistema vulnerable. El escaneo de configuración automatizado es la clave para encontrar este tipo de errores, ya que nadie tiene tiempo para dedicarse a revisar cada línea del código de configuración.
6- Concéntrese en los principios de acceso mínimo
En un mundo ideal, todos son 100 por ciento competentes y honestos, nunca cometen errores ni contemplan cometer errores.
En el mundo real, hacer cumplir el principio de privilegio de acceso mínimo (limitar el acceso a quienes lo necesitan estrictamente) permitirá una mejor gestión del acceso al reducir el riesgo de errores, limitar el alcance del daño y fortalecer la seguridad. Por ejemplo, tal política podría haber reducido en gran medida el daño causado en Sage , cuando un solo empleado de contabilidad se volvió deshonesto. Es cierto que el privilegio de acceso mínimo puede no ser una solución suficiente y debe complementarse con un monitoreo continuo, pero puede reforzarse con:
- Eliminación de privilegios de administrador en las máquinas de los usuarios finales
- Mejor protección de las credenciales de la cuenta
- Supervisión de sesiones privilegiadas para garantizar un uso adecuado
- Restringir el acceso de los desarrolladores, a menos que tengan un requisito específico
- Restricción del acceso a los sistemas de producción
Una vez más, existe una solución tecnológica. La tecnología de gestión de acceso privilegiado proporciona supervisión, auditoría y aplicación del cumplimiento. Una buena solución de acceso privilegiado permite una fácil asignación o denegación sobre la marcha, asegurando el acceso solo cuando sea necesario.
7- Proteja completa y continuamente su canalización de CI/CD
El desplazamiento a la izquierda es clave. La seguridad debe comenzar con la primera línea de código y no dejarse para el control de calidad o las pruebas. La seguridad proactiva reduce el potencial de problemas en todo el SDLC, desde prevenir el incumplimiento y la mala configuración hasta limitar la fuga de secretos y las vulnerabilidades de las credenciales.
La seguridad proactiva y reactiva debe ir de la mano con cada paso del desarrollo, manteniendo todo ágil mientras acelera la capacidad de respuesta. La seguridad debe estar en la mente de todos los desarrolladores, y tanto el código nuevo como el antiguo deben examinarse en busca de posibles vulnerabilidades. La mejor manera de comenzar es simple: al escribir código nuevo, hágalo de forma segura. Al revisar el código antiguo, busque problemas.
8- Manténgalo simple
La automatización es la forma más rápida y sencilla de garantizar la seguridad en todo el SDLC. La inspección de configuración, los escáneres secretos, la gestión de acceso a la identidad, la gobernanza, el cumplimiento, el enmascaramiento y los datos sintéticos son todas soluciones importantes. La clave es encontrar la combinación que maximizará la seguridad en la nube, minimizará los falsos positivos y mantendrá el código de calidad saliendo por la puerta de forma rápida y económica.
La mejor solución es la más simple: cree una pila segura utilizando la menor cantidad de herramientas que brinden el nivel más alto de seguridad y el nivel más bajo de falsos positivos. Desafortunadamente, llegar allí es bastante complejo. Muchas empresas ofrecen herramientas todo en uno o conjuntos compatibles que pueden simplificar el proceso, pero no siempre se puede contar con eso. Al igual que con todos los proyectos gigantescos, el mejor enfoque es dar este paso a paso.
Nunca olvide la seguridad en la nube versus la seguridad de la nube, aunque la responsabilidad compartida rara vez es completamente eso. Verifique sus acuerdos de nivel de servicio para encontrar todos los agujeros que su proveedor de nube le ha dejado y llénelos.
Fuente: InfoQ