Camino a una estrategia multi-cuenta en AWS, parte 2

Por: Ingrid Sánchez es Arquitecta de Soluciones en Amazon Web Services para el Sector Público

En la primer entrega de esta publigación de blog, llegamos a la conclusión de qué, un entorno de AWS con varias cuentas le permite utilizar la nube para moverse con más rapidez y crear productos y servicios diferenciados, todo ello de manera segura, escalable y resiliente. Sin embargo, ¿cómo debería crear su entorno de AWS con varias cuentas? Es posible que se haga preguntas como qué estructura de cuentas utilizar, qué políticas y barreras de protección deberían implementarse o cómo configurar su entorno.

Y ahora, ¿cómo aprovechamos las cuentas en AWS?

Una cuenta es una unidad de protección de seguridad. Los posibles riesgos y amenazas de seguridad pueden estar contenidos en una cuenta sin afectar a los demás. Por lo tanto, las necesidades de seguridad pueden requerir que aísle las cuentas unas de otras. Por ejemplo, puede tener equipos con diferentes perfiles de seguridad.

Básicamente, ofrece un límite de aislamiento que lo ayuda a mantener cada fuente de datos para cada carga de trabajo separada entre sí y puede permitir que las diferentes cargas de trabajo y los diferentes permisos accedan a ellos cuando sea necesario.

La base de un entorno de AWS con varias cuentas con buena arquitectura es AWS Organizations. Primero, considere qué agrupaciones de cuentas u OU debería crear. Sus OU deben basarse en una función o conjunto común de controles en lugar de reflejar la estructura informativa de su organización.

Entonces, ¿cómo estructuraría su entorno de múltiples cuentas? Esta es la recomendación general.

OU Seguridad

Dentro de esta unidad organizacional, lo que tenemos son las herramientas de seguridad que el equipo de seguridad usaría para monitorear el entorno y asegurarse de que no haya brechas de seguridad y que tengan las herramientas necesarias para remediar cualquiera de estas acciones.

OU Infraestructura

Se utiliza para servicios de infraestructura compartidos como redes y servicios de TI. Cree cuentas para todos los tipos de servicios de infraestructura necesarios. Esta OU es administrada por un equipo central y le recomendamos tener dentro una cuenta de herramientas de operación, una cuenta de red y una cuenta de servicios compartidos.

OU Sandbox

Contiene cuentas de AWS que los desarrolladores individuales pueden utilizar para experimentar con servicios de AWS. Asegúrese de que estas cuentas se pueden desconectar de redes internas y configurar un proceso para limitar el gasto y evitar un uso excesivo.

OU Cargas de Trabajo

Contiene cuentas de AWS que alojan sus servicios de aplicaciones externas. Debe estructurar OU respecto a entornos de SDLC y Prod para aislar y controlar de manera estricta las cargas de trabajo de producción.

OU Ensayo de Políticas

Contiene cuentas de AWS en las que puede probar cambios de políticas propuestos antes de aplicarlos a toda la organización. Comience implementando cambios en el nivel de cuenta en la OU prevista, y extiéndalos lentamente a otras cuentas, OU y luego al resto de la organización.

OU Suspendida

Contiene cuentas de AWS que han sido cerradas y están esperando a que la organización las elimine. Adjunte una SCP a esta OU que deniegue todas las acciones. Asegúrese de que las cuentas están etiquetadas con detalles sobre rastreabilidad por si es necesario restaurarlas.

Es básicamente para cuentas que están cerradas o cualquier cosa que necesite hacer que deba suspenderse o limitarse temporalmente.

OU Usuarios Empresariales Individuales

Una OU de acceso limitado que contiene cuentas de AWS para usuarios empresariales (no desarrolladores) que pueden necesitar crear aplicaciones relacionadas con productividad empresarial, como la configuración de un bucket de S3 para compartir informes o archivos con un socio.

OU Excepciones

Contiene cuentas de AWS utilizadas para casos de uso empresariales que cuentan con requisitos de seguridad o auditoría muy personalizados, diferentes de aquellos definidos en las OU de cargas de trabajo. Por ejemplo, la configuración de una cuenta de AWS de manera específica para una nueva aplicación o característica confidencial. Utilice SCP en el nivel de cuenta para cumplir necesidades personalizadas. Considere configurar un sistema de detección y reacción mediante CloudWatch Events y reglas de AWS Config.

Otro ejemplo sería que si tiene una cuenta o un flujo de trabajo que realmente no necesita ninguno de los requisitos, como permitir que algunas operaciones se realicen en otra región. Podría tener esa cuenta aquí, a través de una SCP por sus siglas en inglés, que se pueda adjuntar a ese nivel. Entonces, de esa manera, puede tener esa excepción para que la cuenta pueda operar y siempre tendrá un poco, pero también tiene todas las demás limitaciones de todas las otras cuentas aplicadas porque la SCP se aplicaría a nivel de cuenta.

OU Implementaciones

Contiene cuentas de AWS diseñadas para implementaciones de CI/CD. Puede crear esta OU si cuenta con un modelo de gobernanza y operaciones para implementaciones de CI/CD diferente en comparación con las cuentas de las OU de cargas de trabajo (Prod y SDLC).

La distribución de CI/CD ayuda a reducir la dependencia organizativa en un entorno de CI/CD compartido que opera un equipo central. Para cada conjunto de cuentas de AWS de SDLC/Prod para una aplicación en la OU Cargas de trabajo, cree una cuenta para CI/CD en la OU Implementaciones.

Puesto que la mayor parte de compañías disponen de diferentes requisitos de políticas para cargas de trabajo de producción, infraestructura y seguridad pueden contar con OU anidadas para producción (Prod) y para ciclo de vida de desarrollo de software (SDLC). Las cuentas de la OU de SDLC alojan cargas de trabajo que no son de producción y, por lo tanto, no deben contar con dependencias de producción respecto a otras cuentas. Si hay variaciones en políticas de OU en las fases de ciclo de vida, la OU de SDLC se puede dividir en varias OU (por ejemplo, desarrollo y preproducción). Las cuentas en la OU de Prod alojan las cargas de trabajo de producción.

Aplique políticas a nivel de OU para controlar el entorno de Prod y SDLC según sus requisitos. En general, aplicar políticas en el nivel de OU es mejor práctica que aplicarlas a nivel de cuenta individual ya que simplifica la administración de políticas y la resolución de cualquier problema potencial.

Comience de manera progresiva: organización de inicio de producción

Sabemos que trasladarse al enfoque de múltiples cuentas es un proceso que se puede desplegar con el tiempo, por lo tanto, le recomendamos que comience de manera progresiva. AWS le recomienda que empiece con la seguridad y la infraestructura en mente. La mayoría de empresas cuentan con equipos centralizados que asisten a toda la organización para cubrir esas necesidades. En ese caso, le recomendamos crear un conjunto de OU básicas para esas funciones específicas: Seguridad e Infraestructura.

Así es como se ve una organización de inicio de producción que comienza con la OU de seguridad y la OU de infraestructura, para sus equipos y para que su equipo central administre realmente el entorno. Después tenemos la OU Sandbox que le permitirá jugar, aprender y ser curioso. Posteriormente está la OU Cargas de trabajo, aquí tendrá las aplicaciones para sus clientes. Se recomienda que divida los que está en producción y cualquier cosa que no esté en producción. La OU de pruebas podría ser varias OU’s o varias cuentas, según el ciclo de vida de desarrollo de su software.

Retomando las OU’s fundamentales, la OU de seguridad, contendrá las herramientas de seguridad en la cuenta local y la cuenta de archivo de registro. Dentro de la OU Infraestructura tendrá herramientas de operaciones, redes y servicios compartidos. La cuenta de administración, como lo mencionamos con anterioridad, es aquella que posee su organización de AWS.

Tendrá las políticas de control de servicio, políticas de etiquetas y cualquier servicio que se integre con todas las cuentas de la organización se puede administrar desde aquí. Le recomendamos que habilite esas funciones si tiene una organización.

Un ejemplo es AWS Cloud Trail. AWS CloudTrail permite la auditoría, el monitoreo de la seguridad y la solución de problemas operativos mediante el seguimiento de la actividad del usuario y el uso de la API. CloudTrail registra, monitorea continuamente y retiene la actividad de la cuenta relacionada con las acciones en su infraestructura de AWS, lo que le brinda control sobre las acciones de almacenamiento, análisis y remediación.

Entonces, en la cuenta de herramientas de seguridad, colocaremos los diferentes servicios usando el administrador delegado. Como se mencionó antes, puede usar su cuenta madre para administrar y controlar los servicios de toda su organización. Tenemos esta característica llamada administración delegada que le permite delegar al administrador fuera de la cuenta madre porque no recomendamos que tenga cargas de trabajo aqui porque los permisos de su cuenta madre podrían eliminar su organización, podrían cambiar las cosas.

Entonces, cuantas menos personas tengan acceso a la cuenta de administración, mejor. Por lo tanto, al delegar la administración de estos servicios a una cuenta de herramientas de seguridad, puede asegurarse de que solo las personas dentro de su organización que necesitan acceso a estos servicios tendrán acceso a ellos por separado y fuera de la administración.

La OU archivo de registro, puede asegurarse de que todos los registros de acceso, registros de DNS, eventos de seguimiento en la nube se envíen a un bucket el contenido dentro de la cuenta del archivo de registro y que esté fuera de su cuenta de administración. Esto le permite establecer controles y establecer permisos de acceso para que nadie pueda acceder realmente a esta cuenta.

Romper cristal (break glass access)

Hablar de romper el cristal es muy importante. Cuando se tiene múltiples cuentas administradas, asegurar su acceso de emergencia a múltiples cuentas es complicado porque tiene que administrar múltiples claves, múltiples accesos. Lo primero es que, si sucede algo, debería poder comunicarse con el equipo que tiene los recursos y pedirles que lo solucionen. Si eso no sucede, deberá acudir al equipo de seguridad y operaciones porque deberían tener algún tipo de acceso de emergencia. Y este acceso es federado. Entonces, una vez que haya terminado con eso, si eso no funciona o el equipo de seguridad no puede acceder, eso significa que sus mecanismos de autenticación habituales no funcionan, lo que significa que realmente necesita romper el cristal.

Por lo tanto, deberá configurar un usuario de IAM o un par de usuarios de IAM en su cuenta de administración que se tratan como si fueran la raíz. Tendrían autenticación M. F. A. donde la clave está en manos de alguna persona y las contraseñas en manos de otra persona. De esa manera, se asegura de que esos permisos no se usen o no se abuse de ellos. Aparte de su típica escalada de privilegios o acceso temporal para diferentes cosas, debería ser suficiente.

Recomendaciones de control

Y lo último son las recomendaciones de control. Hay tres tipos de controles: preventivos, detectivos y proactivos. Los controles preventivos evitan que se produzcan acciones. Por ejemplo, el control electivo llamado No permitir cambios en buckets de Amazon S3 impide cualquier cambio en la política de IAM dentro de la cuenta compartida de logs. Cualquier intento de realizar una acción preventiva se deniega y se registra en AWS CloudTrail. El recurso también se registra en AWS Config.

Los controles detectivos, detectan eventos específicos cuando se producen y registran la acción en AWS CloudTrail. Por ejemplo, el control llamado Detectar si el cifrado está habilitado para los volúmenes de Amazon EBS adjuntos a las instancias de Amazon EC2 detecta si un volumen de Amazon EBS no cifrado está adjunto a una instancia de EC2 en su landing zone.

Los controles proactivos comprueban si los recursos cumplen con las políticas y los objetivos de la organización antes de aprovisionar los recursos en sus cuentas. Si los recursos no cumplen con las normas, no se aprovisionan. Los controles proactivos supervisan los recursos que se desplegarían en sus cuentas mediante plantillas de AWS CloudFormation.

Siguientes pasos

Puede usar herramientas nativas para crear su entorno desde cero con AWS Organizations, lo que requiere más esfuerzo inicial con control total sobre cada aspecto de su entorno, o puede ponerse en marcha rápidamente con las funciones de automatización y la interfaz de usuario simple en AWS Control Tower.

AWS Control Tower, ofrece la manera más fácil de configurar y gobernar un entorno de AWS seguro con varias cuentas. Establece una Landing Zone que se basa en los planos de las mejores prácticas y permite la gobernanza utilizando guardrails que pueden elegir de una lista preempaquetada.

Conclusiones

En la segunda entrega de esta publicación de blog, se mostró una recomendación general para la creación de la estructura de unidades organizacionales, así como una estructura más pequeña para iniciar poco a poco. También presentamos servicios de gobierno que pueden ayudarlo cuando administra varias cuentas y explicamos cómo estos servicios funcionan juntos para ayudarlo a lograr su objetivo de administrar un entorno de nube seguro y escalable.

Para implementar las mejores prácticas de múltiples cuentas, use los servicios de AWS y familiarícese con la forma en que se activan y administran en un entorno organizacional. Para el acceso entre cuentas, use AWS SSO. Por seguridad, utilice características de los servicios de seguridad de AWS. Para simplificar el aprovisionamiento de cuentas, empareje funciones de automatización para compartir recursos y permisos. Independientemente de su ruta de implementación, comprender los beneficios y las características de estos servicios lo ayudará a construir y escalar su entorno de AWS.

Sobre la autora

Ingrid Sánchez es Arquitecta de Soluciones en Amazon Web Services para el Sector Público. Ingrid cuenta con 5 años de experiencia, a lo largo de este tiempo ha profundizado en temas de CloudOps, con énfasis en estrategias multi-cuenta . Le apasionan los temas como administración, gobernanza y analítica en las organizaciones. En sus inicios en AWS, apoyaba el Sector Comercial para cuentas “Small & Medium Business”, actualmente forma parte del equipo de Central SA para cuentas en Latinoamérica.

Revisores

Jorge Hernández es Arquitecto de Soluciones en Amazon Web Services para el Sector Comercial. Jorge Ha trabajado en el sector de empresas privadas ayudando a las personas en la adopción de los servicios de AWS, también en el desarrollo de las practicas de Gobierno de tecnología, seguridad y continuidad de negocio.

José Cuencar ha trabajado en empresas de consultoría, sector de la construcción ,y logística, así como startups de comercialización de bienes y servicios, apoyando en la adopción de tecnologías en la nube en América Latina. Actualmente se desempeña como Arquitecto de Soluciones en Amazon Web Services para el Sector Educativo en México donde se especializa en Cómputo y Computo de Alto desempeño, apoya a la transformación digital de instituciones educativas en México.

José Antonio es Arquitecto de Soluciones en Amazon Web Services. Con más de 12 años de experiencia trabajando en tecnologías de nube, en diversos sectores como el financiero, seguros y fianzas, retail, manufactura y sector público entre otros. Le apasionan los temas especializados en ML y DS así como BigData y bases de datos NoSQL. Actualmente forma parte del equipo de Central SA para cuentas del sector público para Latinoamérica.