Utilizando AWS Organizations Para Gestionar Múltiples Cuenta de AWS

¿Qué es AWS Organizations?

AWS Organizations es un servicio de gestión de cuentas que te permite consolidar y administrar de forma centralizada múltiples cuentas de AWS. Esto te permite separar tus cargas de trabajo en diferentes cuentas, centralizar la administración de tus cuentas y cargas de trabajo de AWS, y aplicar políticas de seguridad en toda la organización. AWS Organizations incluye facturación consolidada, lo que te permite manejar toda la facturación de tu organización completa desde una sola cuenta de AWS.

¿Por qué deberías usar múltiples cuentas de AWS?

Separar tus cargas de trabajo en diferentes cuentas de AWS te permite lograr un mejor aislamiento de cargas de trabajo, mejora tu postura de seguridad y hace que la administración general sea significativamente más fácil.

Cada cuenta de AWS debe servir un solo propósito y contener una carga de trabajo. Para múltiples aplicaciones, cada aplicación diferente debe tener su propia cuenta de AWS. Si estás utilizando múltiples entornos para la misma aplicación, como entornos de desarrollo, staging y producción, entonces cada uno debe estar en su propia cuenta de AWS.

Cuentas de Soporte en un Entorno Multi-Cuenta

Además de las cuentas que contendrán tus cargas de trabajo, deberías crear cuentas de soporte que contengan recursos compartidos o de soporte. Los ejemplos más comunes son:

• Cuenta de Seguridad: Está destinada a contener aplicaciones de seguridad y configuraciones de seguridad. Debería tener acceso de solo lectura a todas las demás cuentas de AWS. Los expertos en seguridad pueden usarla para instalar aplicaciones o configurar servicios de AWS que escaneen el tráfico o las configuraciones en todas las demás cuentas de AWS. Además, pueden usar su acceso desde la cuenta de seguridad para realizar detección de incidentes y análisis de causa raíz.

• Cuenta de Redes: Aquí es donde despliegas recursos de red compartidos, como una conexión Direct Connect a tu data center local, o NAT Gateways compartidos. Los recursos de la cuenta de Redes suelen compartirse a través de VPC Peerings, AWS Transit Gateway o AWS Resource Access Manager.

• Cuenta de Servicios Compartidos: Servicios Compartidos contiene servicios de AWS y aplicaciones que no pertenecen estrictamente a una carga de trabajo en particular, sino que pueden ser compartidos entre múltiples cargas de trabajo. El ejemplo más común son los pipelines de CI/CD, que pueden ser compartidos entre varias cargas de trabajo. Otros recursos compartidos comunes son herramientas de análisis de código estático, instancias de AWS Workspaces, o herramientas y paneles de monitoreo cruzado entre cargas de trabajo.

• Logging o Archivo de Logs: Esta cuenta mantiene un archivo de todos los logs de aplicaciones y seguridad de todas las cuentas y cargas de trabajo. El acceso es solo de escritura de nuevos logs, lo que significa que los logs pueden ser escritos en ella, pero no pueden ser modificados o eliminados. Además, la mayoría de las personas en tu empresa deberían tener solo acceso de lectura a esta cuenta. Está destinada a usarse como un repositorio de archivado de cualquier cosa que necesite logs que sean guardados por algún período de tiempo significativo. Estos logs pueden ser consultados para el análisis de causa raíz de incidentes, o para propósitos de auditoría.

• Respaldo o Backup: El propósito de esta cuenta es almacenar respaldos o backups de tus datos importantes, para que no pierdas acceso a ellos incluso si un atacante obtiene acceso a tus cuentas de producción. Puedes usar AWS Backup para automatizar la creación de respaldos y compartirlos entre cuentas. Aquí hay un artículo donde puedes aprender más sobre replicación de datos y recuperación de desastres en AWS.

Organizational Units (Unidades de Organización)

En una Organización, las Cuentas se pueden agregar a grupos de cuentas llamados Unidades Organizacionales (OUs). Esto proporciona una forma sencilla de agruparlas lógicamente según el rol, la carga de trabajo o el área a la que pertenece la cuenta.

Este es un ejemplo de estructura de cuenta utilizando AWS Organizations:

Beneficios de AWS Organizations

Estos son los principales beneficios de separar tus cargas de trabajo en diferentes cuentas y usar AWS Organizations para administrarlas.

Facturación consolidada

AWS Organizations te permite pagar todos los cargos de AWS de toda la Organización directamente desde la cuenta raíz. De esta manera, solo configuras los detalles de tu tarjeta de crédito una vez y todo se carga a la cuenta raíz.

Los costos se pueden analizar de forma granular usando Cost Explorer. Además, desde la cuenta raíz puedes analizar los costos de toda la Organización. Esto te brinda una vista de alto nivel de dónde provienen los gastos, y puedes profundizar en tantos detalles como desees utilizando los filtros de Cost Explorer.

Gestión y gobierno centralizados

La consola de Organizations en la cuenta raíz te permite administrar todas las Cuentas de tu Organización desde un solo lugar. Puedes modificar sus Unidades Organizacionales, agregar o eliminar Service Control Policies y modificar configuraciones centrales.

También puedes crear nuevas cuentas directamente desde la cuenta raíz, y se unirán automáticamente a tu Organización. La creación de cuentas también se puede delegar utilizando una solución llamada Account Vending Machine, para brindar a tus equipos una experiencia completa de autoservicio.

Seguridad mejorada

Puedes usar Service Control Policies para definir permisos máximos en una Organización. Estos mecanismos de seguridad te permiten administrar centralmente los límites de permisos y restringir acciones como salir de la Organización o evitar el uso del usuario raíz de la cuenta.

¿Cuánto cuesta AWS Organizations?

AWS Organizations es gratuito. No hay cargos adicionales por usarlo para configurar y administrar tus cuentas de AWS. Además, no hay cargos adicionales por usar una configuración de múltiples cuentas con AWS, ya que las cuentas en sí son gratuitas.

Todos los demás recursos necesarios para AWS Organizations, como el acceso entre cuentas a través de Roles de IAM, también son gratuitos para configurar y usar.

¿Qué son las Service Control Policies?

Las Service Control Policies (SCPs) son políticas de organización que te permiten restringir permisos en cuentas de una Organización de AWS. Te permiten establecer los permisos máximos para una cuenta, asegurándote de que todos los permisos cumplan con tus pautas de permisos.

Las Service Control Policies usan la misma sintaxis que las políticas de IAM. Se crean y administran desde la consola de AWS Organizations, con la CLI de AWS o con cualquiera de los SDK de AWS, utilizando la cuenta raíz de la organización. Puedes asociar SCPs a cuentas directamente o a Unidades Organizacionales, y todas las OUs y cuentas dentro de esa Unidad Organizacional heredarán esas SCPs.

Las Service Control Policies funcionan otorgando permisos al usuario raíz de la cuenta, que luego se delegan a los Usuarios y Roles de IAM dentro de esa cuenta en particular. Cuando habilitas las Service Control Policies para una Organización, el valor predeterminado es crear una SCP que otorgue todos los permisos, lo que tiene el mismo efecto que si no hubieras habilitado SCPs. A partir de ahí, puedes crear SCPs adicionales con sentencias explícitas de Deny para ciertas acciones, restringiendo así los permisos del usuario raíz de la cuenta y de todos los Usuarios y Roles de IAM en esa cuenta.

Algunas SCPs comunes son:

• Restringir regiones: Una SCP que niega todas las acciones para algunas regiones. Dado que la mayoría de las empresas solo utilizan un puñado de las más de 20 regiones de AWS, negar todo el acceso a las regiones de AWS que no se utilizan simplifica la administración y la seguridad.

• Restringir el tamaño de los recursos: Es muy poco probable que las cuentas de desarrollo o sandbox necesiten crear instancias grandes de EC2, instancias de RDS o funciones Lambda. Se puede establecer una SCP para denegar la creación de estos recursos si el tamaño es mayor que "large", o para funciones Lambda si la configuración de memoria está por encima de un cierto valor.

• Requerir MFA: Las SCPs se pueden usar para denegar ciertas acciones a menos que se haya utilizado la autenticación multifactor (MFA). Con una Service Control Policy de este tipo, a los usuarios que intenten esas acciones se les pedirá automáticamente que ingresen su código de autenticación multifactor. Es común habilitar esto para acciones irreversibles como eliminar objetos de un bucket S3.

• Evitar el acceso root: El usuario raíz (root) solo debe usarse para acciones que solo se pueden realizar a través del usuario root, como modificar el nivel de soporte de AWS. Para protegerse del acceso malintencionado, todas las acciones del usuario raíz se pueden bloquear usando una Service Control Policy. En caso de que realmente se necesite el usuario raíz, la SCP que impide el acceso se puede eliminar temporalmente y luego volver a colocar.

Las Service Control Policies de A Secure Cloud son un excelente punto de partida para configurar tus propias Service Control Policies. Te recomiendo encarecidamente que las utilices como base o inspiración para tus propias SCPs.

¿Qué es AWS Control Tower?

AWS Control Tower es un servicio que te ayuda a configurar y gobernar un entorno seguro de AWS de múltiples cuentas. Es una arquitectura con opiniones que construye una arquitectura de múltiples cuentas con configuraciones de seguridad y acceso preconfiguradas. Con Control Tower, no necesitas configurar tu organización desde cero. Con solo unos pocos clics, puedes implementar plantillas predefinidas de organizaciones, incluida la creación de las cuentas de AWS necesarias y la configuración de permisos.

Control Tower utiliza controles y opciones predefinidos para crear una estructura con opiniones que se adapta a la mayoría de los casos de uso. Aplica las mejores prácticas en toda la organización y la configura de una manera segura. En la mayoría de los casos, AWS Control Tower es la mejor manera de configurar tu organización de AWS.

Cómo configurar un entorno de múltiples cuentas usando AWS Organizations y Control Tower

Estos son los pasos básicos para configurar una organización de AWS usando Control Tower:

1. Inicia sesión en la consola de AWS

2. Ve a la consola de AWS Control Tower

3. Verifica que estás en tu región de inicio deseada

4. Haz clic en "Set up landing zone"

5. Sigue las instrucciones, aceptando todos los valores predeterminados.

6. Agrega la dirección de correo electrónico para tu cuenta, una cuenta de archivo de registros y una cuenta de auditoría

7. Verifica todas las opciones

8. Haz clic en "Set up landing zone"

9. Espera alrededor de 30 minutos mientras Control Tower configura todo

Si deseas configurar una Organización sin usar los valores predeterminados, lee esta guía.

Mejores prácticas de AWS Organizations

Para obtener los máximos beneficios de Organizations, sigue estas mejores prácticas:

No uses la cuenta raíz

En cierto sentido, la cuenta raíz de una Organización cumple un papel similar al usuario raíz de una cuenta de AWS. Cualquier persona con acceso a la raíz puede modificar o eliminar Service Control Policies, dejándolos expuestos o bloqueándote. Debes proteger el acceso a la cuenta raíz y solo otorgarlo a las personas que realmente lo necesitan. Para garantizar eso, no implementes ninguna carga de trabajo en la cuenta raíz. En su lugar, crea cuentas específicas para tus cargas de trabajo y recursos.

Crea una organización desde cero

Si ya tienes una cuenta con recursos existentes, puede parecer natural crear tu Organización allí. Sin embargo, eso significaría que necesitas usar la cuenta raíz para administrar tu carga de trabajo existente. En su lugar, debes crear una cuenta completamente nueva para usar como raíz de la Organización e invitar a tus cuentas existentes a ser parte de la Organización.

Usa Service Control Policies

Las Service Control Policies te permiten limitar los permisos en las cuentas. Configúralas para tus diferentes cuentas y Unidades Organizacionales, de modo que las acciones estén restringidas y se apliquen protecciones de seguridad. Recuerda que con SCPs habilitadas, todos los permisos necesitan una declaración explícita de Allow en una SCP además de la declaración de Allow en las políticas de IAM. Además, ten en cuenta que si hay una declaración explícita de Deny en una SCP, la acción será denegada. Utiliza estas características para denegar ciertas acciones o incluir ciertas condiciones, como usar solo regiones específicas o requerir autenticación MFA.

Usa Single Sign-On

A medida que la cantidad de cuentas crece más allá de un puñado, usar usuarios IAM y roles IAM para acceder a tus cuentas se vuelve problemático. En su lugar, debes configurar IAM Identity Center para permitir iniciar sesión en tus diferentes cuentas con un solo conjunto de credenciales. IAM Identity Center puede usar su propio almacén de identidades o conectarse a Active Directory, Google Workspaces, Okta y cualquier proveedor de identidades OAuth. Además, puedes permitir diferentes roles y conjuntos de permisos en diferentes cuentas, limitando lo que cada persona puede hacer.

Limita el acceso a las cuentas

Al igual que no todos necesitan acceso a todas las cargas de trabajo, no todos necesitan acceso a todas las cuentas. Define tus permisos cuidadosamente y solo permite las acciones que realmente se necesitan. Aplica permisos mínimos. Esto se hace mucho más fácil al tener cargas de trabajo en cuentas separadas.