El valor de la SRA de AWS

Influya en el futuro de la arquitectura de referencia de AWS seguridad (AWSSRA) realizando una breve encuesta.

AWS cuenta con un amplio (y creciente) conjunto de servicios de seguridad y relacionados con la seguridad. Los clientes han expresado su agradecimiento por la información detallada disponible en la documentación de nuestro servicio, las publicaciones de blog, los tutoriales, las cumbres y las conferencias. También nos dicen que quieren entender mejor el panorama general y obtener una visión estratégica de los servicios de seguridad de AWS. Cuando trabajamos con los clientes para comprender mejor lo que necesitan, surgen tres prioridades:

• Los clientes desean obtener más información y patrones recomendados sobre cómo pueden implementar, configurar y operar los servicios de seguridad de AWS de manera integral. ¿En qué cuentas y con qué objetivos de seguridad se deben implementar y administrar los servicios?  ¿Hay una cuenta de seguridad en la que deban operar todos o la mayoría de los servicios?  ¿Cómo influye la elección de la ubicación (unidad organizativa o cuenta de AWS) en los objetivos de seguridad? ¿Qué ventajas y desventajas (consideraciones de diseño) deben tener en cuenta los clientes?

• Los clientes están interesados en ver diferentes perspectivas para organizar de forma lógica los numerosos servicios de seguridad de AWS. Más allá de la función principal de cada servicio (por ejemplo, los servicios de identidad o los servicios de registro), estos puntos de vista alternativos ayudan a los clientes a planificar, diseñar e implementar su arquitectura de seguridad. Un ejemplo que se comparte más adelante en esta guía agrupa los servicios en función de las capas de protección alineadas con la estructura recomendada de su entorno de AWS.

• Los clientes buscan orientación y ejemplos para integrar los servicios de seguridad de la manera más eficaz. Por ejemplo, ¿cuál es la mejor manera de alinear y conectar AWS Config con otros servicios para hacer el trabajo pesado de los procesos automatizados de auditoría y supervisión?  Los clientes solicitan orientación sobre la forma en que cada servicio de seguridad de AWS se basa en otros servicios de seguridad o los apoya.

Abordamos cada uno de estos aspectos en la SRA de AWS. La primera prioridad de la lista (a dónde van las cosas) es centrar la atención en el diagrama de arquitectura principal y en las discusiones que lo acompañan en este documento. Proporcionamos una arquitectura de AWS Organizations recomendada y una account-by-account descripción de qué servicios van a cada lugar.  Para empezar con la segunda prioridad de la lista (cómo pensar en el conjunto completo de servicios de seguridad), lea la sección Aplicar servicios de seguridad en toda la organización de AWS. En esta sección se describe una forma de agrupar los servicios de seguridad según la estructura de los elementos de su organización de AWS. Además, esas mismas ideas se reflejan en el análisis de la cuenta de aplicaciones, que destaca cómo se pueden operar los servicios de seguridad para centrarse en determinadas capas de la cuenta: las instancias de Amazon Elastic Compute Cloud (Amazon EC2), las redes de Amazon Virtual Private Cloud (Amazon VPC) y la cuenta más amplia. Por último, la tercera prioridad (la integración de los servicios) se refleja en toda la guía, especialmente en el análisis de los servicios individuales en las secciones de esta documentación que profundiza en las cuentas y en el código del repositorio de códigos SRA de AWS.

Cómo usar la SRA de AWS

Existen diferentes formas de utilizar la SRA de AWS en función del punto en el que se encuentre en el proceso de adopción de la nube. Esta es una lista de formas de obtener el máximo conocimiento de los activos de la SRA de AWS (diagrama de arquitectura, orientación escrita y ejemplos de código).

• Defina el estado objetivo de su propia arquitectura de seguridad.

Tanto si acaba de empezar su viaje a la nube de AWS (está configurando su primer conjunto de cuentas) como si planea mejorar un entorno de AWS establecido, la SRA de AWS es el lugar ideal para empezar a crear su arquitectura de seguridad. Comience con una base integral de estructura de cuentas y servicios de seguridad y, a continuación, ajústelos en función de su conjunto tecnológico concreto, sus habilidades, sus objetivos de seguridad y sus requisitos de conformidad. Si sabe que va a crear y lanzar más cargas de trabajo, puede utilizar su versión personalizada de la SRA de AWS como base para la arquitectura de referencia de seguridad de su organización. Para saber cómo puede alcanzar el estado objetivo descrito por la SRA de AWS, consulte la sección Creación de su arquitectura de seguridad: un enfoque gradual.

• Revise (y revise) los diseños y las capacidades que ya ha implementado.

Si ya tiene un diseño e implementación de seguridad, vale la pena tomarse un tiempo para comparar lo que tiene con la SRA de AWS. La SRA de AWS está diseñada para ser integral y proporciona una base de diagnóstico para revisar su propia seguridad. Si sus diseños de seguridad se ajustan a la SRA de AWS, puede estar más seguro de que sigue las prácticas recomendadas al utilizar los servicios de AWS. Si sus diseños de seguridad difieren o incluso no están de acuerdo con las directrices de la SRA de AWS, esto no es necesariamente una señal de que esté haciendo algo mal. Por el contrario, esta observación le brinda la oportunidad de revisar su proceso de toma de decisiones. Existen motivos empresariales y tecnológicos legítimos por los que podría desviarse de las prácticas recomendadas de la SRA de AWS. Es posible que sus requisitos particulares de conformidad, normativa o seguridad de la organización requieran configuraciones de servicio específicas. O bien, en lugar de usar los servicios de AWS, es posible que prefiera una función para un producto de la red de socios de AWS o una aplicación personalizada que haya creado y administrado. A veces, durante esta revisión, es posible que descubra que sus decisiones anteriores se tomaron en función de tecnologías antiguas, características de AWS o restricciones empresariales que ya no se aplican. Es una buena oportunidad para revisar las actualizaciones, priorizarlas y añadirlas al lugar correspondiente de su cartera de tareas de ingeniería. Independientemente de lo que descubra al evaluar su arquitectura de seguridad a la luz de la SRA de AWS, le resultará útil documentar ese análisis. Tener ese registro histórico de las decisiones y sus justificaciones puede ayudar a informar y priorizar las decisiones futuras.

• Inicie la implementación de su propia arquitectura de seguridad.

Los módulos de infraestructura como código (IaC) de AWS SRA proporcionan una forma rápida y fiable de empezar a crear e implementar su arquitectura de seguridad. Estos módulos se describen con más detalle en la sección del repositorio de código y en el repositorio público GitHub . No solo permiten a los ingenieros basarse en ejemplos de alta calidad de los patrones de la guía SRA de AWS, sino que también incorporan los controles de seguridad recomendados, como las políticas de contraseñas de AWS Identity and Access Management (IAM), Amazon Simple Storage Service (Amazon S3) (Amazon S3), el acceso público a las cuentas de bloqueo, el cifrado predeterminado de Amazon EC2 (Amazon Elastic Block Store (Amazon EBS), y integración con AWS Control Tower para que los controles se apliquen o eliminen a medida que se incorporen o retiren nuevas cuentas de AWS.

• Obtenga más información sobre las capacidades y los servicios de seguridad de AWS.

Las directrices y los debates de la SRA de AWS incluyen características importantes, así como consideraciones sobre la implementación y la administración de los servicios individuales de seguridad y de seguridad de AWS. Una característica de la SRA de AWS es que proporciona una introducción de alto nivel sobre la variedad de los servicios de seguridad de AWS y cómo funcionan juntos en un entorno de varias cuentas. Esto complementa el análisis profundo de las características y la configuración de cada servicio que se encuentra en otras fuentes. Un ejemplo de ello es el análisis de cómo AWS Security Hub incorpora las conclusiones de seguridad de una variedad de servicios de AWS, productos de socios de AWS e incluso de sus propias aplicaciones.

• Organice un debate sobre el gobierno de la organización y las responsabilidades en materia de seguridad.

Un elemento importante al diseñar e implementar cualquier arquitectura o estrategia de seguridad es comprender qué miembros de la organización tienen qué responsabilidades relacionadas con la seguridad. Por ejemplo, la cuestión de dónde agrupar y supervisar los hallazgos de seguridad está vinculada a la cuestión de qué equipo será responsable de esa actividad. ¿Todos los hallazgos de la organización son supervisados por un equipo central que necesita acceder a una cuenta específica de Security Tooling? ¿O son los equipos de aplicaciones individuales (o unidades de negocio) responsables de determinadas actividades de supervisión y, por lo tanto, necesitan acceder a determinadas herramientas de alerta y supervisión? Otro ejemplo: si su organización tiene un grupo que administra todas las claves de cifrado de forma centralizada, esto influirá en quién tiene permiso para crear claves de AWS Key Management Service (AWS KMS) y en qué cuentas se administrarán esas claves. Comprender las características de su organización (los distintos equipos y responsabilidades) le ayudará a personalizar la SRA de AWS para que se adapte mejor a sus necesidades. Por el contrario, a veces, el debate sobre la arquitectura de seguridad se convierte en el impulso para analizar las responsabilidades organizativas existentes y considerar los posibles cambios. AWS recomienda un proceso de toma de decisiones descentralizado en el que los equipos de carga de trabajo sean responsables de definir los controles de seguridad en función de sus funciones y requisitos de carga de trabajo. El objetivo de un equipo centralizado de seguridad y gobierno es crear un sistema que permita a los propietarios de las cargas de trabajo tomar decisiones informadas y que todas las partes puedan ver la configuración, los resultados y los eventos. La SRA de AWS puede ser un medio para identificar y fundamentar estos debates.

Directrices clave de implementación de la SRA de AWS

Estas son ocho conclusiones clave de la SRA de AWS que debe tener en cuenta al diseñar e implementar su seguridad.   

• AWS Organizations y una estrategia de cuentas múltiples adecuada son elementos necesarios de su arquitectura de seguridad. La separación adecuada de las cargas de trabajo, los equipos y las funciones constituye la base para separar las tareas y defense-in-depth las estrategias. La guía trata este tema con más detalle en una sección posterior.

• D efense-in-depth es una consideración de diseño importante a la hora de seleccionar los controles de seguridad para su organización. Le ayuda a introducir los controles de seguridad adecuados en las diferentes capas de la estructura de AWS Organizations, lo que ayuda a minimizar el impacto de un problema: si hay un problema en una capa, existen controles que aíslan otros recursos de TI valiosos. La SRA de AWS demuestra cómo funcionan los distintos servicios de AWS en las distintas capas del conjunto de tecnologías de AWS y cómo el uso combinado de esos servicios le ayuda a lograrlo defense-in-depth. Este defense-in-depth concepto en AWS se analiza con más detalle en una sección posterior con ejemplos de diseño que se muestran en Cuenta de aplicación.

• Utilice la amplia variedad de componentes básicos de seguridad de varios servicios y características de AWS para crear una infraestructura de nube sólida y resiliente. Al adaptar la SRA de AWS a sus necesidades particulares, tenga en cuenta no solo la función principal de los servicios y características de AWS (por ejemplo, autenticación, cifrado, supervisión o política de permisos), sino también la forma en que se integran en la estructura de su arquitectura. En una sección posterior de la guía se describe cómo funcionan algunos servicios en toda la organización de AWS. Otros servicios funcionan mejor en una sola cuenta, y algunos están diseñados para conceder o denegar permisos a directores individuales. Tener en cuenta estas dos perspectivas le ayuda a crear un enfoque de seguridad por capas más flexible.

• Siempre que sea posible (como se detalla en secciones posteriores), utilice los servicios de AWS que se puedan implementar en todas las cuentas (distribuidas en lugar de centralizadas) y cree un conjunto coherente de barreras de protección compartidas que puedan ayudar a proteger sus cargas de trabajo contra el uso indebido y a reducir el impacto de los eventos de seguridad. La SRA de AWS utiliza AWS Security Hub (supervisión centralizada de búsquedas y comprobaciones de conformidad), Amazon GuardDuty (detección de amenazas y detección de anomalías), AWS Config (supervisión de recursos y detección de cambios), IAM Access Analyzer (supervisión del acceso a los recursos), AWS CloudTrail (registro de la actividad de las API del servicio en su entorno) y Amazon Macie (clasificación de datos) como conjunto base de servicios de AWS que se implementarán en todas las cuentas de AWS.

• Utilice la función de administración delegada de AWS Organizations, donde sea compatible, tal y como se explica más adelante en la sección de administración delegada de la guía. Esto le permite registrar una cuenta de miembro de AWS como administrador de los servicios compatibles. La administración delegada proporciona flexibilidad para que los distintos equipos de la empresa utilicen cuentas independientes, según corresponda a sus responsabilidades, para gestionar los servicios de AWS en todo el entorno. Además, el uso de un administrador delegado le ayuda a limitar el acceso a la cuenta de administración de AWS Organizations y a administrar la sobrecarga de permisos de dicha cuenta.

• Implemente la supervisión, la administración y la gobernanza centralizadas en todas sus organizaciones de AWS. Al utilizar los servicios de AWS que admiten la agregación de varias cuentas (y, a veces, de varias regiones), junto con las funciones de administración delegada, permite a sus equipos centrales de ingeniería de seguridad, redes y nube tener una amplia visibilidad y control sobre la configuración de seguridad y la recopilación de datos adecuadas. Además, los datos se pueden devolver a los equipos de carga de trabajo para que puedan tomar decisiones de seguridad eficaces en una fase temprana del ciclo de vida del desarrollo del software (SDLC).

• Utilice AWS Control Tower para configurar y administrar su entorno de AWS multicuenta con la implementación de controles de seguridad prediseñados para impulsar su arquitectura de referencia de seguridad. AWS Control Tower proporciona un plan para proporcionar administración de identidades, acceso federado a las cuentas, registro centralizado y flujos de trabajo definidos para el aprovisionamiento de cuentas adicionales. A continuación, puede usar la solución Customizations for AWS Control Tower (cFCT) para basar las cuentas administradas por la Torre de Control de AWS con controles de seguridad, configuraciones de servicios y gobierno adicionales, como lo demuestra el repositorio de códigos SRA de AWS. La función de fábrica de cuentas aprovisiona automáticamente las nuevas cuentas con plantillas configurables en función de la configuración de cuentas aprobada para estandarizar las cuentas dentro de sus AWS Organizations. También puede extender la gobernanza a una cuenta individual de AWS existente inscribiéndola en una unidad organizativa (OU) que ya esté gobernada por la Torre de Control de AWS.

• Los ejemplos de código de la SRA de AWS demuestran cómo se puede automatizar la implementación de patrones en la guía de la SRA de AWS mediante el uso de la infraestructura como código (IaC). Al codificar los patrones, puede tratar la IaC como cualquier otra aplicación de su organización y automatizar las pruebas antes de implementar el código. La IaC también ayuda a garantizar la coherencia y la repetibilidad mediante la implementación de barreras de protección en varios entornos (por ejemplo, SDLC o específicos de una región). Los ejemplos de código SRA se pueden implementar en un entorno de cuentas múltiples de AWS Organizations con o sin AWS Control Tower. Las soluciones de este repositorio que requieren la Torre de Control de AWS se han implementado y probado en un entorno de Torre de Control de AWS mediante AWS CloudFormation y las personalizaciones para la Torre de Control de AWS (cFCT). Las soluciones que no requieren la Torre de Control de AWS se han probado en un entorno de AWS Organizations con AWS CloudFormation. Si no utiliza la Torre de Control de AWS, puede utilizar la solución de implementación basada en AWS Organizations.