AWS: examen de seguridad

Una emprendedora sin conocimientos técnicos se pone en tus manos para arrancar su proyecto. Se trata de un servicio de entrega de pan a domicilio enfocado a urbanizaciones. El model de negocio se basará en una subscripción y se están desarrollando diveras aplicaciones que incluye un catálogo de productos panaderos, un Sistema de Información Geográfica para el reparto óptimo de los mismos y la gestión de unas pequeñas taquillas mediante Internet of Things.

Obviamente, los requerimientos de seguridad deben cumplir los mejores estándares. Y el hecho de tratarse de un proyecto green-field lo convierte en candidato claro para desplegarlo en cloud. Tras una breve discusión, se opta por AWS como proveedor de infraestructura.

¿Qué características son habituales en el uso de cloud público para gestionar la infrastructura? (Indica si estás de acuerdo o no con cada afirmación)

* Siempre resulta más económico en términos absolutos, incluso si trasladamos cargas de trabajo tradicionales sin ningún tipo de adaptación a la nueva plataforma
* Es posible desplegar con facilidad en cualquier parte del mundo gracias a la presencia global de los proveedores
* Los únicos servicios que merece la penan utilizar en el cloud público son los balanceadores de carga, las máquinas virtuales y las bases de datos (con el objetivo de facilitar las migraciones entre ellos)
* Suele pagarse por lo que se consume exclusivamente (pago por uso) y se dispone de mecanismos para adaptar automáticamente la capacidad existente a la necesaria (elasticidad)
* Es más difícil crear entornos seguros en el cloud público al tratarse de plataformas compartidas entre miles de diferentes clientes
* La aproximación tradicional a la seguridad basada en análisis de la infrastructura desplegada y establecimiento de perímetros defensivos con redes y firewalls sigue siendo un modelo perfectamente válido que implica el aprovechamiento de las capacidades ofrecidas por el cloud público
* El hecho de que todo sea automatizable implica que la seguridad resulte mucho más complicada de imponer al obligar a revisar la arquitectura de la infraestructura muchas más veces de lo que era necesario hacerlo tradicionalmente
* La Infraestructura como Código hace que puedan aplicarse técnicas de seguridad propias del desarrollo de software también a la creación de datacenters en el cloud público

¿Qué estructura de permisos crearías? (Indica si estás de acuerdo o no con cada afirmación)

* Crear una cuenta en la que se utilice la región de Irlanda para producción y la región de Frankfurt para pruebas
* Activar Organizations para poder establecer una gestión global de diversas cuentas
* Añadir una Organizations Unit para englobar todas las cuentas de destinadas a desarrollo y otra OU para todas las cuentas destinadas a producción
* Añadir una Organizations Unit para cada una de las tres aplicaciones del sistema
* Crear una cuenta de desarrollo y otra de producción para cada Organization Unit existente
* Añadir una Service Control Policy (SCP) que limite el uso de regiones no deseadas en todas las cuentas del sistema
* Añadir una Service Control Policy (SCP) que pueda utilizarse para hacer login en las cuentas de producción
* Crear usuarios en cada cuenta de desarrollo con los nombres "desarrolladorPrincipal", "desarrolladorAuxiliar" y "desarrolladorFrontend"
* Crear usuarios nominales en cada cuenta correspondiente según las personas físicas que necesiten acceder a las mismas
* Utilizar el root user de cada cuenta para administrarla, delegando permisos en los usuarios del IAM local para que puedan llevar a cabo sus responsabilidades
* Activar el Multifactor Authentication (MFA) para el root user y crear un usuario del IAM local de cada cuenta que necesite ser administrada con los permisos necesarios para ello. No volver a utilizar el root user excepto en caso de imperiosa necesidad
* En cada IAM local de las cuentas creadas, dar de alta una serie de grupos que describan las distintas funciones a desempeñar en cada cuenta y asignar IAM Policies a los mismos de acorde a ellas
* En cada IAM local crear una serie de usuarios, asignarlos a los grupos correspondientes y si alguno de ellos lo requiere añadir IAM Policies particulares al usuario para realizar tareas adicionales
* Diseñar un plan para a medio plazo delegar la autenticación de usuarios en un Identity Provider (como Azure Active Directory) con el objetivo de simplificar la gestión de los mismos
* Crear un IAM role para cada una de las aplicaciones que se vayan a desplegar en cada cuenta, con los permisos suficientes para que puedan interactuar con la infraestructura que necesitan
* Crear un IAM Role para cada usuario de cada una de las cuentas, asignándole a dicho Role las correspondientes IAM Policies


¿Qué decisiones desde el punto de vista de la seguridad tomarías a la hora de diseñar la arquitectura de las aplicaciones? (Indica si estás de acuerdo o no con cada afirmación)

* Crear una VPC global a todas las cuentas para unificar la gestión del tráfico
* Crear VPCs independientes, una por proyecto y entorno, que se expandan a lo largo de todo el planeta
* Crear VPCs independientes, una por proyecto y entorno, restringidas a la región de Irlanda al ser Europa el primer mercado en el que la startup operará
* Evitar utilizar Internet Gateways (IGWs) al ser el acceso directo a internet el vector de actaque más habitual en AWS
* Conectar las VPCs a internet mediante un Internet Gateway (IGW). Dividir cada VPC en dos subnets, una que disponga de enrutado al IGW y otra que no
* Colocar los balanceadores de carga y las flotas de máquinas virtuales en las subredes públicas (enrutadas al Internet Gateway). Colocar las bases de datos en las subredes privadas.
* Colocar los balanceadores de carga en las subredes públicas (enrutadas al Internet Gateway). Colocar las flotas de máquinas virtuales y las bases de datos en las subredes privadas
* Modificar las tablas de rutas de las subredes privadas para proporcionar conectividad hasta internet en las horas de mantenimiento en las que las máquinas virtuales deben poder acceder a los parches de seguridad de los sistemas operativos. Retomar la situación original a continuación para minimizar riesgos.
* Establecer un NAT Gateway (NATgw) en la subred **privada** para permitir el acceso a máquinas situadas en internet a través del mismo, proporcionando un mecanismo de parcheo seguro a las instancias EC2
* Establecer un NAT Gateway (NATgw) en la subred **publica** para permitir el acceso a máquinas situadas en internet a través del mismo, proporcionando un mecanismo de parcheo seguro a las instancias EC2
* Evitar utilizar el servicio de Elastic Load Balancer (ELB) de AWS en favor de configurar nuestra propia solución basada en Nginx en el convencimiento de que podemos llevar a cabo una parametrización más personalizada y por tanto más segura de esta capa del sistema
* Utilizar Relational Database Service (RDS) para crear las bases de datos y automatizar las copias de seguridad y el parcheo de las mismas
* Crear siempre todas las bases de datos con las opciones de Alta Disponibilidad actividas para garantizar el acceso a los datos en caso de desastre
* Crear siempre todas las bases de datos **destinadas a producción** con las opciones de alta disponibilidad activadas, pero mantener las bases de datos **destinadas a desarrollo* sin dicha característica activada para reducir el coste a final de mes
* Desplegar un único firewall que centralice el control del tráfico entrante y saliente de las redes creadas es el método más eficiente para garantizar la seguridad del sistemao
* La segregación del tráfico puede llevarse a cabo estableciendo una cadena de Security Groups, cada uno de ellos asociado a una capa diferente de la arquitectura de la aplicación