En esta charla explicaremos cómo usando política como código (policy-as-code) podemos dotar de la máxima agilidad y flexibilidad a nuestros equipos sin sacrificar la seguridad y control

1. Policy as Code
cómo no poner puertas al campo cloud

2. ~# whoami
Datos personales
● David Acacio Albareda
● 45 años
● 26 años trabajando en IT
● Lead Cloud Architect en Zurich España
Curiosidades
● Co-host en el podcast de EntreDevyOps
● Radioaficionado con indicativo EA3IPX
Contacto
● Email → dacacioa@gmail.com
● X Twitter → https://twitter.com/david_acacio
● LinkedIn → https://www.linkedin.com/in/davidacacio/

3. Zurich

4. Primeros pasos al cloud
● Selección de AWS como proveedor cloud.
● Dependencia con un partner.
● Tres cuentas.
● Uso exclusivo de computing y RDS
(emulando on-premises).
● Consciencia de la existencia del serverless.

5. Evolución de servicios en el tiempo (AWS)

6. Evolución de Zurich en el uso de AWS
Requisitos:
● Garantizar seguridad.
● Garantizar auditoría.
● Bajo coste de mantenimiento: 1 FTE (2 x 50%).
● Permitir innovación y experimentación.
● 24 horas aplicación en producción.
● No introducir animales nuevos al Zoo

7. The IT Zoo

9. Tecnología seleccionada
1. AWS (enfoque multicuenta).
2. GitOps (CI/CD)
○ Auditoría.
○ Control.
○ Aislamiento a nivel de “aplicación”.
3. Uso del IaC
○ CDK → Typescript

10. Seguridad banco vs casino

11. Cómo conseguimos seguridad de casino
● Vallas de seguridad perimetrales.
○ Ninguna cuenta tiene acceso directo a internet.
○ Servicios bloqueados (SCP)
■ Internet Gateway.
■ Public IP.
● GitOps
○ Cualquier despliegue sólo puede realizarse por pipeline.
○ Acceso limitado a sólo lectura a la consola y a ciertos servicios.
○ Doble nivel de validación en los MR.
● Proyectos auto-contenidos.
● Control/supervisión sobre los recursos desplegados.

12. Primer intento de seguridad casino
● Ofrecer a los desarrolladores abstracciones de la infraestructura para los
diferentes servicios (CDK Constructs).
○ Poca flexibilidad.
○ Mucho esfuerzo de mantenimiento.
○ Lentitud en time to market.
○ Bloqueo de la innovación.

13. Policy as code 1/2
● Definición:
○ Policy-as-code is a method of defining and managing security
rules, criteria, and conditions through code.
● Primer enfoque:
○ OPA (https://www.openpolicyagent.org/)
○ Dificultad del lenguaje (Rego).
○ Lentitud en la definición de reglas.
○ Demasiada dedicación.

14. Policy as code 2/2
● Keeping infrastrutres as code secure - Kics (https://kics.io/)
○ Open Source (https://github.com/Checkmarx/kics)
○ Creado por Checkmarx.
○ 1500 reglas para:
■ Cloudformation.
■ Terraform
■ K8s
■ Azure Resource Manager
■ GCP
○ CIS compliance:
■ CIS Amazon Web Services Foundations Benchmark v1.4 Level 2
■ CIS Kubernetes Benchmark v1.6.1, Level 2 - Master Node
■ CIS Kubernetes Benchmark v1.6.1, Level 2 - Worker Node
● Otras soluciones de terceros:
○ Checkov (Prisma)
○ Sentinel (Hashicorp)
○ cdk-nag

15. Lecciones aprendidas 1/2
● Shift to the left

16. Lecciones aprendidas 2/2
● Control de excepciones
○ Excepción a nivel de aplicación.
○ Trazabilidad
■ Proceso estandarizado
● Regla excepcionada.
● Fecha.
● Justificación.
■ Triple nivel de validación
● Developer.
● Arquitecto responsable de la plataforma.
● Arquitecto de cloud.

17. Situación actual
● +50 cuentas AWS (y creciendo).
● 75% soluciones Serverless.
● +100 aplicaciones/plataformas.
● 24 horas (casi) OK!

19. Preguntas