Slide 1

Slide 1 text

SEGURIDAD EN Herramientas Principales SANTIAGO GIMENEZ OCAÑO Security Engineer

Slide 2

Slide 2 text

AGENDA • Motivación • Modelo de responsabilidad compartida • Herramientas • IAM • Certificate Manager • WAF & Shield • AWS Inspector • Conclusión

Slide 3

Slide 3 text

MOTIVACIÓN

Slide 4

Slide 4 text

MOTIVACIÓN http://www.nextgov.com/sponsor-content/in-cloud-we-should-trust/ “The idea that cloud is less secure comes from a perceived loss of control. However with AWS you actually gain more control over your data than you have in your own on-premises environment.” --Bill Murray, senior manager of security programs at AWS

Slide 5

Slide 5 text

MOTIVACIÓN • Migramos todo a AWS. • Nuestra seguridad se incrementó un 478923%. • Podemos dormir a la noche sabiendo que nuestros datos están seguros, sin nada mas por hacer. • El mundo es un lugar mejor. • Esto no es así. • Si bien AWS es seguro, nosotros somos también responsables de la seguridad.

Slide 6

Slide 6 text

MODELO DE RESPONSABILIDAD COMPARTIDA DE AWS

Slide 7

Slide 7 text

https://aws.amazon.com/compliance/shared-responsibility-model/

Slide 8

Slide 8 text

MODELO DE RESPONSABILIDAD COMPARTIDA EN AWS SECURITY OF THE CLOUD • AWS es responsable de proteger la infraestructura global del los servidores de la nube. • Host OS y capa de virtualización. • Seguridad física del data center. • Provee herramientas de seguridad. SECURITY IN THE CLOUD • El cliente de AWS es responsable de la seguridad del contenido, aplicaciones, sistemas y redes. • Guest OS (actualizaciones y parches), aplicaciones dentro del OS, configuración de los security groups. • El cliente implementa/usa herramientas de seguridad. https://aws.amazon.com/compliance/shared-responsibility-model/

Slide 9

Slide 9 text

HERRAMIENTAS DE SEGURIDAD DE AWS

Slide 10

Slide 10 text

HERRAMIENTAS DE SEGURIDAD DE AWS

Slide 11

Slide 11 text

AWS IDENTITY AND ACCESS MANAGEMENT (IAM)

Slide 12

Slide 12 text

AWS IAM • Permite manejar usuarios y permisos a recursos dentro de AWS. • Emplea controles de acceso: • Usuarios • Grupos • Políticas • Roles • Usuarios se identifican con contraseñas, o con AWS Keys y AWS Secret Keys. http://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html FEATURES ADICIONALES • Políticas de contraseñas • Multi-factor para acceso a consola • Identity federation • Integración con CloudTrail IMPORTANTE • Si no lo usamos bien, estamos en problemas.

Slide 13

Slide 13 text

¿CÓMO FUNCIONA AWS IAM? • Usuarios obtienen permisos para acceder a un recurso mediante una política, que puede usar condiciones. • Las poíticas son representadas en un JSON file. • Las políticas pueden agregarse a usuarios, grupos, roles, o recursos. http://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_access-management.html • Las políticas pueden ser ”managed” (creadas por AWS o administradores) o ”inline” (creadas por administradores). • Los usuarios pueden ser agregados a grupos. • Los roles pueden ser asignados a instancias. • Esto permite usar instancias sin una AWS Key y AWS Secret Key.

Slide 14

Slide 14 text

¿CÓMO FUNCIONA AWS IAM? http://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_access-management.html { "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "dynamodb:*", "Resource": "arn:aws:dynamodb:us-east-2:123456789012:table/Books" } }

Slide 15

Slide 15 text

CONSIDERACIONES EN IAM • IAM tiene limitaciones en la cantidad de usuarios, grupos, roles, cantidad de grupos por usuario, etc, etc. • Los números son relativamente altos. • Pero si escribimos muchas políticas inline, podemos alcanzarlos. • Usuarios: 2.048 símbolos • Roles: 10.240 símbolos • Grupos: 5.120 símbolos http://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-limits.html • Las limitaciones nos llevan a un modelo donde usuarios son en general agregados a grupos, donde no se usan muchas políticas inline.

Slide 16

Slide 16 text

BUENAS PRACTICAS EN IAM • No usar API Keys y API Secret Keys del usuario root. Nunca. • Crear cuentas individuales por usuario. • Usar Grupos. • No usar políticas inline. • Habilitar MFA. http://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html • Usar roles para aplicaciones en instancias. Si esto no es posible, crear cuentas de servicio. • Buscar y remover credenciales innecesarias. • Usar condiciones en las políticas.

Slide 17

Slide 17 text

AWS WAF AND SHIELD

Slide 18

Slide 18 text

AWS WAF Y AWS SHIELD AWS WAF • Web Application Firewall. • Monitorea request en CloudFront (AWS’s CDN) y Application Load Balancer. • Restringe acceso, en función de condiciones, reglas y ACLs. AWS SHIELD • Protección contra DDoS. • Puede tener costo extra https://aws.amazon.com/documentation/waf/

Slide 19

Slide 19 text

¿CÓMO FUNCIONA AWS WAF? CONDICIONES • Características básicas en los requests. • Ejemplos: • Scripts (XSS) • Direcciones IP • Longitud de partes del request • Código SQL (injection) • Strings que aparecen en el request (user agent) REGLAS • Combinación de condiciones. • Se deben cumplir todas las condiciones. • Reglas regulares: deben incluir al menos una condición. • Reglas basadas en rate (X requests en Y minutos): si no tienen condición, todos los request son considerados. http://docs.aws.amazon.com/waf/latest/developerguide/how-aws-waf-works.html

Slide 20

Slide 20 text

¿CÓMO FUNCIONA AWS WAF? ACL • Combinación de reglas. • Definen acciones: • Permitir • Bloquear • Contar (testing) • Acción para cada regla y una acción por defecto. • Se deben satisfacer todas las condiciones de un reglas en una ACL. http://docs.aws.amazon.com/waf/latest/developerguide/how-aws-waf-works.html

Slide 21

Slide 21 text

http://docs.aws.amazon.com/waf/latest/developerguide/how-aws-waf-works.html

Slide 22

Slide 22 text

https://d0.awsstatic.com/whitepapers/Security/aws-waf-owasp.pdf

Slide 23

Slide 23 text

¿CÓMO FUNCIONA AWS SHIELD? AWS SHIELD STANDARD • Basado en condiciones, reglas y ACLs de WAF. • Bloquear tráfico. • Sin costo adicional. AWS SHIELD ADVANCED • Para Load Balancers, CloudFront, Route53. • Costo adicional. Pero incluye WAF. • DDoS en capas 3, 4, y 7. • Métricas en tiempo real. • Se puede escalar a AWS DDoS Response Team. • Puede detectar DDoS en capa 7, pero no mitiga. http://docs.aws.amazon.com/waf/latest/developerguide/ddos-overview.html

Slide 24

Slide 24 text

AWS CERTIFICATE MANAGER

Slide 25

Slide 25 text

AWS CERTIFICATE MANAGER • Maneja los certificados TLS usados en: • Elastic Load Balncing (en load balancer o en el backend) • Amazon CloudFront (en la CDN or en el backend) • AWS Elastic Beanstalk (load balancer) • Amazon API Gateway • AWS CloudFormation • Los certificados son por región. • Dos alternativas: • Pedir un certificado a AWS (autorenewal). • Importar un certificado en AWS (se puede ”elegir” el root CA). • No olvidarse de asignar el certificado al recurso J. • Validar el certificado con un agente externo (Digicert). http://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html

Slide 26

Slide 26 text

¿CÓMO FUNCIONA AWS CERTIFICATE MANAGER? PEDIR UN CERTIFICADO A AWS 1. Hacer el pedido: solo hace falta un FQDN. 2. Validar el dominio: generalmente por mail a [email protected] http://docs.aws.amazon.com/acm/latest/userguide/gs-acm-request.html

Slide 27

Slide 27 text

¿CÓMO FUNCIONA AWS CERTIFICATE MANAGER? IMPORTAR UN CERTIFICADO A AWS • Requerimientos: • El certificado (PEM, clave pública RSA de 1024 o 2048 bits) • Clave privada del certificado (PEM) • Cadena de certificados (PEM, Opcional) http://docs.aws.amazon.com/acm/latest/userguide/import-certificate-console.html

Slide 28

Slide 28 text

AWS INSPECTOR

Slide 29

Slide 29 text

AWS INSPECTOR • Analizador de vulnerabilidades de seguridad. • CVEs, buenas prácticas, información. • Menos de 2 años en producción. • Penetration testing requiere permiso especial de AWS. • AWS Inspector no necesita permiso. • Tiene una API para automatizar los análisis. https://docs.aws.amazon.com/inspector/latest/userguide/inspector_introduction.html

Slide 30

Slide 30 text

¿CÓMO FUNCIONA AWS INSPECTOR? • Se instala un agente en la instancia a analizar • Se crea un ”Assessment target” • Se crea un ”Assessment template” • Se ejecuta el template • Se revisan los findings https://docs.aws.amazon.com/inspector/latest/userguide/inspector_introduction.html IMPORTANTE • Arreglar los findings

Slide 31

Slide 31 text

INSTALANDO EL AGENTE • El agente es compatible con: • Linux • Windows • Se instala como servicio http://docs.aws.amazon.com/inspector/latest/userguide/inspector_agents.html $ curl -O https://d1wk0tztpsntt1.cloudfront.net/linux/latest/install $ sudo bash install

Slide 32

Slide 32 text

ASSESSMENT TARGET

Slide 33

Slide 33 text

No content

Slide 34

Slide 34 text

ASSESSMENT FINDINGS https://blog.cloudthat.com/assets/InspectorFindings.png

Slide 35

Slide 35 text

CONSIDERACIONES EN AWS INSPECTOR • ¿Cada cuánto correr un análisis? • ¿Puedo ”reciclar” lo suficientemente rápido? • ¿Aprovechar la API y agregarlo a un CI? • ¿Qué hago si AWS detecta vulnerabilidades durante el lanzamiento de una instancia? • ¿Sólo notificar o notifica y parar el lanzamiento?

Slide 36

Slide 36 text

Q&A