DEV Community

Cover image for Cómo lograr un gobierno de múltiples cuentas a escala con AWS Control Tower - Parte 2

Cómo lograr un gobierno de múltiples cuentas a escala con AWS Control Tower - Parte 2

En la primera parte de esta serie, entendimos cuales son los beneficios que se obtienen al hacer uso de una estrategia de múltiples cuentas AWS por sobre el uso de una cuenta única.

Descubrimos que haciendo uso de AWS Control Tower se obtiene el aprovisionamiento automatizado de cuentas AWS con una configuración básica consistente, simplificando el gobierno, y el cumplimiento de múltiples cuentas con modelos prescriptivos y prácticas recomendadas.

Como resumen, al llegar a este blog, ya hemos aprendido a activar AWS Control Tower y a configurarlo adecuadamente.

En esta segunda parte, nos enfocaremos a, ¿Cuál es la estrategia de gobierno que puedo lograr con AWS Control Tower de acuerdo a los intereses y lineamientos de mi organización?, por supuesto que, cada organización tiene intereses y objetivos diferentes, hay organizaciones que están interesadas en el cumplimiento de estándares como la ISO 270001 y PCI, otras en cambio a estándares como GDPR, NIST e incluso HIPAA. Todo depende del rubro de la organización, de la residencia de sus datos, del tipo de datos que almacenen y procesen sean propios o de clientes, entre otros factores.

Para profundizar en el tema de este blog, usaremos como escenario ser una organización del rubro de servicios financieros (Banca, Fintech, Neo Bank, Payment Processors, Corredora de seguros, etc) donde como lineamientos de la organización es el cumplimiento de estándares como PCI, ISO 27001 y NIST. Veremos a continuación como AWS Control Tower nos ayuda a cumplir con nuestros objetivos.

PASO 1: Cómo organizar mis cargas de trabajo mediante Unidades Organizativas

Cuando tenemos cargas de trabajo para diferentes propósitos y entornos, es una recomendación general organizarlas en OUs diferentes. A continuación te explico cuales son las OUs que deberías tener dentro de tu AWS Organization.

- OU Workloads:
Esta OU puede subdividirse en otras OUs para organizar mejor tus cargas de trabajo por entornos (Dev, QAS y PRD), por país operación (Perú, Argentina, Colombia, Chile, etc), por tipo de unidad de negocio (Banca, Seguro, Corredora), por tipo de carga de trabajo (Inteligencia de Negocios, Seguridad, Machine Learning, Serverless, etc).

- OU Sandbox:
Las cuentas dentro de esta OU deben estar aisladas del resto del ecosistema pues se requieren permisos menos restrictivos ya que su propósito es solo de experimentación, tal y como su nombre lo indica. Debemos asegurarnos que las cuentas dentro de esta OU se encuentren completamente aisladas de las otras OUs tanto a nivel de autenticación y red. Es muy útil que se apliquen los guardrails o service control policies (SCP) necesarios para evitar que “por simple aprendizaje” se termine levantando recursos de manera indiscriminada y que generen un alto costo.
Les recomiendo este blogpost donde encontrarán una forma automatizada con buenas prácticas incorporadas para operar dicha OU y tener un buen control sobre el presupuesto de la cuenta.

- OU Shared:
Aquí se pueden desplegar servicios compartidos por el resto de cuentas, por ejemplo, el uso de algún firewall IPS/IDS como AWS Network Firewall con un modelo de despliegue de salida hacia internet centralizada, el uso de VPNs como Site to Site o SSL. También puede centralizar la implementación de AWS Transit Gateway, RAM. Asi como casos donde se implementan y comparten servicios de directorio (AD), resolución de nombre de dominio (DNS) y cuentas de herramientas de desarrollo y ciclo de vida del software (SDLC) repositorio de código fuente, repositorio de artefactos, pipelines de CI/CD, servicios de infraestructura cómo código, etc.

- OU Security:
En esta OU, se despliegan 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 Suspended:
Si tienes cuentas que ya no son necesarias y quieres mantenerla en una OU un tanto especifica, puedes incluirla en esta OU. No está demás mencionar que es necesario que a esta OU se les asocie una SCP que deniegue cualquier tipo de acción.

- OU Policy Staging:
Recomiendo que antes de aplicar los guardrails o SCPs a una cuenta de producción, estos hayan sido probado antes en alguna cuenta para pruebas (no confundir con un ambiente sandbox).Tener una OU para ensayar políticas, puede resultar útil.

OUs

PASO 2: Identificar y habilitar los controles (guardrails)

Una vez separada tus cargas de trabajo mediante la segmentación de cuentas y unidades organizativas y como organización cuyo rubro es de servicios financieros, necesitamos controles que nos permitan cumplir o en su efecto estar alineados a los estándares que necesitamos.

AWS Control Tower Controls Library

Esta feature nos permite usar los diferentes tipos de controles que podemos encontrar agrupados por categoría.

Repasemos, ¿Qué es un control o guardrail en AWS Control Tower?
👉 Un control es una regla de alto nivel que nos permite aplicar una definición de gobierno sobre una unidad organizacional y posteriormente una cuenta o grupo de cuentas. Estos controles van a tener la misión de mejorar una postura de seguridad enfocada a objetivos de controles que pueden ser: logging monitoring, protección de datos entre otros, gestión de las vulnerabilidades, mínimo privilegio, entre otros.

Dentro de esta característica, vamos a conocer cuáles son, cómo funcionan y qué tipos existen, hasta aplicar una estrategia de controles en nuestro ambiente de múltiples cuentas AWS.

All Controls Library

Control Behavior: ¿Cómo es que funcionan?

Repasemos nuevamente, existen 3 tipos de comportamientos para los controles:
1️⃣ Preventivos
2️⃣ Detectivos
3️⃣ Proactivos

Controls Behavior

Controles Preventivos

Previenen acciones dentro de nuestra infraestructura en AWS. Estos controles funcionan con SCP manejada por Control Tower, y deniegan acciones específicas relacionadas con el tipo de control que queremos aplicar.

Preventive control

Los controles preventivos, garantizan que la infraestructura esté en compliance con ese control o requerimiento específico, ya que no permite por medio de la SCP que se despliega recursos o que se haga alguna configuración inadecuada.

Controles Preventivos

Otra característica de este tipo de controles es que su estado es “enforced” o “not enabled". Por lo que si queremos saber si estamos en cumplimiento con un control específico, solo basta con mirar el estado del control preventivo.

Ejemplo de un control preventivo
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": "*",
            "Resource": "*",
            "Effect": "Deny",
            "Condition": {
                "StringLike": {
                    "aws:PrincipalArn": [
                        "arn:aws:iam::*:root"
                    ]
                }
            }
        }
    ]
}
Enter fullscreen mode Exit fullscreen mode

Este guardrail (por detrás se aplica una SCP) es un control que previene que se realicen acciones en las cuentas AWS con el usuario root ya que se considera que el uso de este usuario privilegiado sobre la cuenta son para acciones de alto nivel y no para tareas del día a día, es decir, si tus acciones son de desplegar infra, cómo crear recursos en EC2, S3 entre otros, por favor, no uses la cuenta root. Y como parte del equipo de seguridad, si lo que requiero es prevenir este tipo de acciones y estar 100% en cumplimiento, pues este control preventivo de ejemplo es el ideal para responder.

Controles Detectivos

Nos permiten detectar cambios en la configuración actual de nuestra infraestructura e identifica si estos cambios se alinean o no con la postura de seguridad de la organización. Estos controles no garantizan qué todos nuestros recursos estén en compliance a diferencia de los controles preventivos.

Detective Control

Los controles detectivos funcionan con Config Rules, que nos permite conocer los cambios de configuración de los elementos en los recursos que estén desplegados y cuyos resultados son aprovechados por Control Tower.

En este tipo de controles, tenemos 3 estados que son “Clear”, “In Violation” y “not enabled”.

Ejemplo de un control detectivo
AWSTemplateFormatVersion: "2010-09-09"
Description: ""
Resources:
  ConfigRule:
    Type: "AWS::Config::ConfigRule"
    Properties:
      ConfigRuleName: "s3-bucket-public-read-prohibited"
      Scope:
        ComplianceResourceTypes:
          - "AWS::S3::Bucket"
      Description: "A Config rule that checks that your Amazon S3 buckets do not allow public read access. If an Amazon S3 bucket policy or bucket ACL allows public read access, the bucket is noncompliant."
      Source:
        Owner: "AWS"
        SourceIdentifier: "S3_BUCKET_PUBLIC_READ_PROHIBITED"
Parameters: {}
Metadata: {}
Conditions: {}
Enter fullscreen mode Exit fullscreen mode

Este guardrail (por detrás se aplica una config rule) es un control que detecta cuando un bucket S3 cambia su estado de configuración, pasando de haber sido un recurso privado a uno público.

Controles Proactivos:

Nos ayudan a identificar la infraestructura que está a punto de desplegarse en la cuenta AWS, dando como resultado si los recursos a aprovisionarse serán compliance o no. Este análisis es realizado en la misma definición del código o template por el que se aprovisiona la infraestructura.

Proactive control

Cabe mencionar que funcionan utilizando cloudformation hooks, que precisamente es para identificar configuraciones específicas en recursos a desplegar. Un punto a considerar sobre este tipo de controles, es que solo es aplicable por recursos que son provisionados por AWS Cloudformation, aun no soporta recursos desplegados por Terraform, Pulumi, CDK, entre otros.

💡 TIP: Si usas StackSets (característica que permite desplegar infraestructura en múltiples cuentas) también podrás hacer uso de los controles proactivos.

Categorías de controles y Frameworks

Los controles en AWS Control Tower, se agrupan de la siguiente manera:

Agrupados por servicios de AWS:

Indican los servicios sobre los que se aplican los controles.

Services

Agrupados por objetivos de control:

Indican en qué épica de seguridad nos ayudan a mejorar como: limitar el acceso a la red, administrar los secretos, impulsar el mínimo privilegio, administrar las vulnerabilidades, entre muchos otros.

Controls Objective

Agrupados por Framework:

Nos muestran 3 categorías que nos ayudan a estar en cumplimiento respecto a las buenas prácticas que recomienda AWS con referencia a NIST, PCI y CIS AWS Benchmark.

Framework

PASO 3: Recomendaciones para habilitar controles

  • Revisa cada uno de los controles antes de activarlos en una OU (y por consecuente en las cuentas). Es necesario tener una clara comprensión sobre los controles que necesites habilitar y que este entendimiento sea compartido entre los equipos de seguridad, desarrollo y operaciones.

Si quieres conocer el detalle de un control en especifico, desplázate hacia a la pestaña “About” y encontraras información útil del control.

controls details

  • Es importante que se tenga definido que objetivos se quieren mejorar en la organización, es decir, cuales son esas políticas de seguridad a las que se necesita estar alineado. De esta forma, en Controls Library podrás los controles que te ayuden a mejorar la postura de esa política.

Por ejemplo, si están utilizando Amazon S3 y quieren averiguar todos los controles relacionados a este servicio y cumplir con el control objetivo de “protección de datos” pueden hacerlo de esta manera:

protection data policy

PASO 4: Conclusión

  1. Identifica los controles que quieres habilitar
    • Recuerda profundizar sobre el control: definición, tipo, comportamiento y referencia.
  2. Despliega los controles aplicando buenas prácticas
    • Recuerda tener una OU Policy Stagging con la finalidad de probar aquí los guardrails (controles) para luego ir pasando de a poco hacia OU productivas.
  3. Monitorea el estado de los controles habilitados
    • Importante monitorear los controles de tipo detectivo, ya que ellos te dirán que recursos se encuentran "In Violation", quiere decir, recursos non-compliance, identifica esos recursos y remédialos.

💡 TIP: Usa esta sintaxis en tu AWS CLI o AWS CloudShell para identificar los controles que tengas habilitados en alguna OU especifica.

aws controltower list-enabled-controls --target-identifier <OU Id>
Enter fullscreen mode Exit fullscreen mode

ℹ️ Si quieres aprender mas sobre AWS Control Tower - Controls Library, te invito a ver este vídeo, recomendádselo

Te invito a compartir este blog, reaccionar y dejar un comentario de que te tan útil encuentras contenido como este. y te dejamos todas nuestras redes para que puedas seguirnos 🤝

🌎 CONTACTO:

🌐 Website: https://bit.ly/awssecuritylatam
🤝 Meetup: https://bit.ly/comunidad-awsseclatam
🔗 LinkedIn: https://bit.ly/linkedin-awsseclatam
🗣️ Slack: https://bit.ly/slack-awsseclatam

🔥 MÁS CONTENIDO:

📺 Youtube: https://bit.ly/youtube-awsseclatam
📺 Twitch: https://bit.ly/twitch-awsseclatam
🤳 https://bit.ly/instagram-awsseclatam
https://bit.ly/blogs-awsseclatam
🚨 Si quieres estar enterado de todo nuestros contenidos, no olvides suscribirte, y ¡compartir!

⚠️ Si alguno de nuestros enlaces no funciona, no dudes en reportarlo.

Top comments (0)