El valor del AWS SRA - AWS Guía prescriptiva

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

El valor del AWS SRA

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

AWScuenta 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 AWS seguridad. Cuando trabajamos con los clientes para comprender mejor lo que necesitan, surgen tres prioridades:

  • Los clientes desean más información y patrones recomendados sobre cómo pueden implementar, configurar y operar los servicios de AWS seguridad 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 AWS cuenta) 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. 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 según los niveles de protección alineados con la estructura recomendada de su AWS entorno.

  • 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 AWS seguridad depende de otros servicios de seguridad o los apoya.

Abordamos cada uno de ellos en el AWSSRA. La primera prioridad de la lista (a dónde van las cosas) es centrarse 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), lee la sección Aplicar los servicios de seguridad en toda AWS la organización. En esta sección se describe una forma de agrupar los servicios de seguridad según la estructura de los elementos de AWS la organización. 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 (AmazonEC2), las redes de Amazon Virtual Private Cloud (AmazonVPC) y la cuenta más amplia. Por último, la tercera prioridad (la integración de 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 se profundiza en las cuentas y en el AWS SRA código del repositorio de códigos.

Cómo utilizar el AWS SRA

Existen diferentes formas de utilizarla AWS SRA según el punto en el que se encuentre en su proceso de adopción de la nube. Esta es una lista de formas de obtener el máximo conocimiento de los AWS SRA activos (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 AWS la nube (configurando su primer conjunto de cuentas) como si planea mejorar un AWS entorno establecido, este AWS SRA es el lugar ideal para empezar a crear su arquitectura de seguridad. Comience con una base integral de estructura contable 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 como base para la arquitectura de referencia de seguridad de su organización. AWS SRA Para saber cómo puede alcanzar el estado objetivo descrito en el AWSSRA, 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 los demás AWSSRA. AWSSRAEstá diseñado para ser exhaustivo y proporciona una base de diagnóstico para revisar su propia seguridad. Si sus diseños de seguridad se ajustan a los requisitos AWSSRA, puede estar más seguro de que sigue las mejores prácticas al utilizar AWS los servicios. Si sus diseños de seguridad difieren o incluso no están de acuerdo con las directrices de la guía AWSSRA, esto no es necesariamente una señal de que esté haciendo algo mal. En cambio, esta observación le brinda la oportunidad de revisar su proceso de toma de decisiones. Existen razones empresariales y tecnológicas legítimas por las que podrías desviarte de las AWS SRA mejores prácticas. 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 utilizar AWS los servicios, es posible que prefiera una función para un producto de AWS Partner Network o una aplicación personalizada que haya creado y gestionado. A veces, durante esta revisión, es posible que descubra que sus decisiones anteriores se basaron en tecnologías, AWS funciones o limitaciones empresariales antiguas que ya no se aplican. Esta 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 ello AWSSRA, 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 AWS SRA infraestructura como código (IaC) 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 GitHub repositorio público. No solo permiten a los ingenieros basarse en ejemplos de alta calidad de los patrones de la AWS SRA guía, sino que también incorporan los controles de seguridad recomendados, como las políticas de contraseñas de AWS Identity and Access Management (IAM), el acceso público a las cuentas bloqueadas del Amazon Simple Storage Service (Amazon S3), el cifrado EC2 predeterminado de Amazon Elastic Block Store (EBSAmazon) y la integración con la AWS Torre de Control, de modo que los controles se aplican o eliminan a medida que se crean AWS nuevas cuentas embarcado o

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

Las directrices y los debates que figuran en este AWS SRA documento incluyen características importantes, así como consideraciones sobre la implementación y la administración de los servicios individuales de AWS seguridad y relacionados con la seguridad. Una de sus características AWS SRA es que proporciona una introducción de alto nivel a la amplitud de los servicios de AWS seguridad y a la forma en que funcionan juntos en un entorno de múltiples cuentas. Esto complementa el análisis profundo de las funciones 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 absorbe los hallazgos de seguridad de una variedad de AWS servicios, productos de AWS socios e incluso 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? Como otro ejemplo, si su organización tiene un grupo que administra todas las claves de cifrado de forma centralizada, eso influirá en quién tiene permiso para crear las AWS claves del Servicio de administración de claves (AWSKMS) 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 adaptarlo mejor a sus necesidades. AWS SRA 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. AWSrecomienda 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 la carga de trabajo tomar decisiones informadas y a todas las partes obtener visibilidad de la configuración, los hallazgos y los eventos. AWSSRAPuede ser un medio para identificar e informar estas discusiones.

Directrices clave de implementación del AWS SRA

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

  • AWSLas organizaciones y una estrategia multicuenta 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.

  • Defense-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 la AWS organización, 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. AWSSRAEsto demuestra cómo funcionan AWS los distintos servicios en las distintas capas del conjunto de AWS tecnologías y cómo el uso combinado de esos servicios le ayuda a lograrlo defense-in-depth. Este defense-in-depth concepto AWS se analiza con más detalle en una sección posterior con ejemplos de diseño que se muestran en la cuenta de la aplicación.

  • Utilice la amplia variedad de componentes básicos de seguridad de varios AWS servicios y funciones para crear una infraestructura de nube sólida y resiliente. Al adaptarla AWS SRA a sus necesidades particulares, tenga en cuenta no solo la función principal de los AWS servicios y características (por ejemplo, la autenticación, el cifrado, la supervisión o la 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 AWS la organización. 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 AWS servicios 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. AWSSRAUtiliza AWS Security Hub (monitoreo centralizado de búsquedas y controles de cumplimiento), Amazon GuardDuty (detección de amenazas y detección de anomalías), AWS Config (monitoreo de recursos y detección de cambios), IAM Access Analyzer (monitoreo de acceso a recursos), AWS CloudTrail (registro de la API actividad del servicio en su entorno) y Amazon Macie (clasificación de datos) como conjunto base AWS de servicios que se implementarán en todas las cuentas. AWS

  • Utilice la función de administración delegada de AWS Organizations, donde sea compatible, 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 AWS miembro como administrador de los servicios compatibles. La administración delegada proporciona flexibilidad a los distintos equipos de la empresa para que utilicen cuentas independientes, según corresponda a sus responsabilidades, a fin de gestionar AWS los servicios 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 Organizations y a administrar la sobrecarga de permisos de la cuenta de administración de AWS Organizations.

  • Implemente la supervisión, la administración y la gobernanza centralizadas en todas sus AWS organizaciones. Al utilizar AWS servicios que admiten la agregación de varias cuentas (y, a veces, de varias regiones), junto con 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 AWS entorno de múltiples cuentas con la implementación de controles de seguridad prediseñados para impulsar su arquitectura de referencia de seguridad. AWSControl 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. Luego, puede usar la solución Customizations for AWS Control Tower (cFCT) para basar las cuentas administradas por AWS Control Tower con controles de seguridad, configuraciones de servicio y gobierno adicionales, como lo demuestra el repositorio de AWS SRA código. La función de fábrica de cuentas aprovisiona automáticamente las nuevas cuentas con plantillas configurables basadas en la configuración de cuentas aprobada para estandarizar las cuentas dentro de sus AWS Organizations. También puede extender la gobernanza a una AWS cuenta individual existente inscribiéndola en una unidad organizativa (OU) que ya esté gobernada por AWS Control Tower.

  • Los ejemplos de AWS SRA código muestran cómo se puede automatizar la implementación de patrones de la AWS SRA guía 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 al implementar barandas de protección en varios entornos (por ejemplo, o en entornos específicos de una región). SDLC Los ejemplos SRA de código se pueden implementar en un AWS entorno de múltiples cuentas de Organizations con o sin AWS Control Tower. Las soluciones de este repositorio que requieren la Torre de AWS Control se han implementado y probado en un entorno de Torre de AWS Control mediante AWS CloudFormation el uso de Customizations for AWS Control Tower (cFCT). Las soluciones que no requieren la Torre AWS de Control se han probado en un entorno de AWS Organizations mediante el uso de AWS CloudFormation. Si no utiliza la Torre de AWS Control, puede utilizar la solución de despliegue AWS basada en organizaciones.