Ep2. Architecture Championship Simplificando Cloud Governance

Es el Architecture Championship del día de hoy, el cual el tema es Simplificando Cloud Governance, Comprendiendo Control Tower versus AWS Organization. En esta sesión del día de hoy, pues vamos a ver un poquito sobre la importancia de tener administrados los accesos dentro de lo que es la consola de AWS. Algunas prácticas que van más allá de lo que es organización, son principalmente de seguridad, para que ustedes sepan la importancia de tener niveles en accesos. Y pues bueno, igual los ingenieros que nos acompañan el día de hoy, pues les van a estar platicando un poquito más sobre este tema. Entonces, justamente quienes nos acompañan hoy es la Ingeniera Daniela Blanco, Coordinadora de Servicios Profesionales de aquí de CompuCloud, con diferentes certificaciones en lo que son sus especializaciones dentro de la nube, al igual que el ingeniero Víctor Ramírez, Coordinador de Customer Success de aquí de CompuCloud, quien digamos siempre está al frente de las batallas Eli junto con su equipo en cuanto a dar mejores prácticas, ya que ustedes se encuentran en la nube de AWS, están monitoreando y revisando las infraestructuras que tienen con nosotros. Entonces, pues qué mejor que ambos para explicarnos el tema del día de hoy. Muy bien, entonces tal vez ustedes ya nos conocen algunos, ¿No? Les platico rápidamente, en CompuCloud somos un partner advanced de Amazon Web Services, solo estamos especializados en lo que es la nube de AWS. Tenemos más de 10 años especializados en lo que es Amazon Web Services, por lo tanto, somos líderes en el tema, desde migración, modernización, implementación, servicios serverless, diferentes servicios que existen dentro de AWS y pues bueno que compuclo y su equipo se ha estado encareciendo de lo que son estos temas. Tenemos también diferentes certificaciones y reconocimientos, así como lo ven, los ingenieros tienen certificaciones para ir aprendiendo de lo que es la nube de AWS, las actualizaciones que tenemos año a año, entonces es la importancia de que tendremos que tener con estas certificaciones, además de diferentes competencias SDPS, somos Manage Service Provider, somos World Architecture Partner Program, lo que significa que conocemos muy bien lo que es construir una infraestructura a base de los pilares que tiene Well Architecture. Y pues bueno, pasando a la siguiente, les comento la primera persona que va a participar aquí en el Architecture Championship y que nos va a dar por ahí su punto de vista de lo que es este primer servicio, que es AWS Organizations es el ingeniero Víctor. Y pues bueno, bienvenido Víctor, un placer que nos acompañes el día de hoy. Y como les dije al inicio de la sesión, si tienen alguna duda para el ingeniero lo pueden colocar en lo que es este chat y pues demos comienza lo que es el.

¿De acuerdo? Sí. Muchas gracias Gio. Muchas gracias a todos igualmente por acompañarnos hoy en este webinar de Architecture Championship. Y pues básicamente como lo explicó Gio, vamos a hablar un poquito más a fondo sobre estos dos servicios que son bastante buenos, que básicamente nos van a ayudar en la parte de gobernanza, la visibilidad de los costos, el cómo implementamos buenas prácticas con base en el Well architected Framework. Y pues ahora sí que sin más vamos a dar inicio con la siguiente diapositiva que básicamente son las características del servicio AWS Organizations. Tenemos para iniciar una pequeña arquitectura sobre lo que son los puntos más importantes de cómo se comprende el esquema de AWS Organization. Como tal, estamos viendo que es un servicio de administración multicuentas. Básicamente en este nos va a ayudar a centralizar todas nuestras cuentas que a lo mejor ya tenemos y es que nosotros ya contamos con la buena práctica de segmentar nuestras cuentas por ambiente, por cargas de trabajo, por departamento, etcétera. Aquí nosotros podemos crear este esquema con el servicio directamente en la consola e incluso podemos crear a partir de nuevas cuentas. Y como bien lo dije, si es que ya tenemos también cuentas existentes, se pueden ir agregando posteriormente a que ya tengamos creados nuestra arquitectura de Organization. Entonces, como siguiente punto también a partir de este esquema de Organizations, tenemos una cuenta de administración. Esta cuenta maestra básicamente se encarga de centralizar esta administración, consolidar nuestra facturación, tener visibilidad de todos los gastos de todas las cuentas que se encuentren dentro de esta organización y básicamente con ayuda de otros servicios que también voy a estar hablando un poquito más adelante, es que nos ayudan a tener visibilidad y no perder esta administración de todas las cuentas y que pues a lo mejor tengamos también nuestros gastos controlados y saber en dónde básicamente se está llevando a cabo el mayor uso a lo mejor de recursos que tengamos aprovisionados en nuestras cuentas. Como tercer punto en nuestra arquitectura tenemos grupos de cuentas centralizadas, estas básicamente se despliegan por jerarquía llamadas unidades organizacionales. En estas como bien lo dije anteriormente, es donde nosotros segmentamos por ambiente, por departamentos o unidades de negocio a una organización u organizaciones grandes o pequeñas, etcétera, es beneficioso saber en dónde tenemos a lo mejor un gasto mayor, en dónde podemos optimizar en costos, en qué se me está gastando más sobre este recurso, cómo lo puedo optimizar, Entonces es importante segmentarlos por departamento, por ambiente, etcétera, porque sí nos damos cuenta de dónde se está yendo o dónde se está gastando más esto. Aquí también básicamente las unidades se utilizan para segmentar los permisos de cada usuario, también voy a estar hablando un poquito más adelante sobre eso, los accesos a las demás cuentas y pues obviamente el tener un esquema de Organizations pues nos ayuda porque se considera una buena práctica, como bien lo dije, tener visibilidad de todos los recursos. Y pues finalmente en nuestra arquitectura tenemos nuestras Child Accounts, que básicamente son.

El.

Último nivel que despliega nuestra arquitectura de Organizations. En estas últimas es donde básicamente se va a provisionar todo, vamos a decir que es el núcleo de toda nuestra organización, porque en esta es donde tenemos desplegados todos nuestros servicios, igualmente sobre estas se segmentan los permisos adicionales, mediante roles, mediante políticas, etcétera. Entonces a grandes rasgos este es un esquema básico de Organizations para que nosotros podamos construirlo. A continuación vamos a estar viendo lo que son los servicios que se integran también directamente con AWS Organizations. Estos son unos pocos de tantos que se pueden integrar con AWS Organization mediante la administración, porque nos ayuda, nos ayuda a desplegar básicamente todo este tema de seguridad, continuidad de negocio y respaldos. Todo este tema también nos ayuda a tenerlo centralizado desde Organization, nosotros básicamente desde este servicio podemos desplegar estos tantos como por ejemplo la AWS, el Dashboard, nosotros también podemos configurar notificaciones o alarmas cuando ocurre algún evento relacionado con la infraestructura de la nube de AWS y nos puede estar notificando directamente a lo mejor por correo, por SMS, etc. Un aplicativo a lo mejor que también tengamos, se puede estar integrando todo esto. Tenemos también el servicio de AWS IIM Identity Center, este básicamente nos permite el acceso a las cuentas o aplicaciones que tenemos alojado, hosteado dentro de la nube y obviamente que tengamos los permisos de interacción activos que podamos permitir el tráfico hacia estos servicios. Básicamente este servicio se conecta o se puede integrar con un directorio activo de Microsoft a través de lo que es el servicio de AWS nativo también que se llama Directory Service y este básicamente nos permite tal cual reutilizar estas mismas credenciales que nosotros tenemos y utilizarlas para el acceso a nuestras cuentas que tenemos también en AWS Organization, nuestras Child Accounts. Entonces básicamente nos evitamos de tener múltiples usuarios, múltiples contraseñas para acceder a las distintas cuentas, sino únicamente con solo una podemos acceder a todas o a las que nos concedan el permiso. Obviamente el principio del mínimo privilegio de AWS también hay que tenerlo en cuenta de no dar el acceso a todas las cuentas a lo mejor a un único usuario. Como tercer punto de AWS Marketplace, en este básicamente también se pueden compartir las licencias o suscripciones de terceros que se tiene a través de esta, básicamente son las que están aprobadas por AWS, todo lo que esté en Marketplace está aprobado por AWS. Entonces estas suscripciones si nosotros la tenemos desde nuestra Master Account, se pueden también compartir hacia nuestras Child Accounts y y esto nos ayuda también a no estar teniendo cada suscripción en cada cuenta, administrarla, etcétera, renovarlas como sea. Entonces desde AWS Organizations nos ayuda también a administrar estas y pues tener visibilidad y también segmentar los permisos, sabes que a lo mejor algún servicio X de un tercero solamente lo necesito en dos cuentas, únicamente le podemos otorgar el permiso de que se comparta hacia esta cuenta y que a las otras no. Entonces esto también es la bondad del servicio, nos permite segmentar este tipo de permisos. El siguiente punto es AWS Audit Manager, este básicamente nos ayuda a auditar nuestras cuentas, todas las cuentas que tenemos o que tengamos dentro de nuestro esquema de Organizations para simplificar la evaluación, la evaluación de los riesgos y el cumplimiento que tenemos hacia nuestras cuentas. Esto básicamente nosotros lo definimos y se puede estar auditando continuamente, nos da básicamente la evaluación y de los riesgos que pudieran estar comprometidos todas nuestras cuentas. Y continuando con AWS Backup, también se pueden configurar este servicio para administrar los respaldos completos de todas las cuentas o unidades organizacionales. Básicamente si todas nuestras cuentas que tenemos en AWS obviamente son importantes, entonces con este servicio nos ayuda básicamente a la continuidad de negocio, Nosotros podemos respaldar completa la cuenta y tener una unidad organizacional únicamente para los respaldos, podemos segmentarlas por cuentas de auditoría, etcétera. Entonces el servicio que nos ayuda para esto es AWS Backup e igualmente pues todo este servicio se almacena en lo que son los buckets de s para que tengamos ahora sí que ahí segmentado toda y centralizada toda nuestra información. Yendo un poquito más abajo tenemos el servicio de AWS Reachability Analyzer, este básicamente nos ayuda a las trazas, es un servicio de red, nos ayuda a las trazas de las rutas de tráfico entre cuentas, por ejemplo si nosotros tenemos dos cuentas y la tenemos dentro de un esquema de organizaciones y necesitamos saber si es que tiene comunicación esta VPC con la VPC de mi otra cuenta, entonces este servicio nos ayuda también a trazar las rutas de tráfico en donde se queda atorado a lo mejor el tráfico y pues tener visibilidad también de lo que es la red y las comunicaciones entre VPC entre cuentas, entonces esto también es bastante de mucha ayuda en el tema de las redes que tenemos configuradas en nuestras cuentas. El siguiente punto es Tag Policies, estas básicamente también nosotros desde Urbanizations podemos nosotros configurar políticas de taggeo, esto es muy importante tomarlo en cuenta porque mediante el taggeo de los recursos nosotros tenemos la visibilidad completa de dónde se está yendo o qué tanto está gastando tal recurso, entonces si nosotros configuramos una política de taggeo, nosotros también podemos a todas las cuentas que se estén agregando automáticamente, si nosotros configuramos sabes qué, que todo este servicio por ejemplo F se taguen con este, con esta clave valor que yo configuro dentro de mi tag de mi política, todas estas cuentas se van a estar taggeando mediante el servicio y eso nos ayuda obviamente a tener visibilidad de los recursos y que más adelante voy a estar hablando del servicio también con el que podemos visualizar todos estos cobro o el gasto de nuestros servicios o recursos. Y finalmente tenemos el AWS CloudFormation Stacksets, este básicamente nos permite el despliegue de los recursos a través de las cuentas específicas o incluso a todas cuentas en una sola operación, o sea básicamente si nosotros queremos desplegar roles, queremos desplegar alguna configuración hacia nuestras cuentas, El servicio de CloudFormation nos ayuda a hacerlo mediante organizations y que todos estos cambios que nosotros metamos en nuestra plantilla afecte a las cuentas que nosotros tenemos configurado, como bien lo dije anteriormente, incluso a todas nuestras cuentas, entonces básicamente estos son uno de los pocos servicios con los que AWS Organizations puede integrar, de hecho la lista es más, pero al menos quise poner los más importantes porque esto creo que nos ayuda mucho a lo que es la continuidad de nuestro negocio y ver obviamente el valor agregado que se le puede dar a un esquema mediante AWS Organization. Entonces continuamos. Muy bien, vamos a presentar el caso de estudio, este básicamente engloba 4 puntos, el primero es que tenemos una empresa transnacional que cuenta con diferentes ambientes desplegados en una misma cuenta, actualmente no tienen segmentados los permisos para todos los usuarios de los ambientes, esta es una mala práctica, entonces por esto es que requieren una consultoría para poder aplicar buenas prácticas con base en el Web Architected Framework sin perder gobernanza de todas las cuentas, quieren seguir administrándolas y finalmente el siguiente punto es que requieren visibilidad de todos los recursos y un control de gastos mensuales, obviamente también para poder administrar la seguridad de los accesos a las cuentas, etc. Entonces continuando a la siguiente diapositiva vamos a ver cómo es que tiene este cliente actualmente su arquitectura en la nube de AWS, estamos viendo que tiene dentro de su cuenta está desplegado en multiambiente por así decirlo y en multirregión cada ambiente, el ambiente productivo, vemos que tiene un aplicativo web, al menos tiene segmentados la parte del aplicativo expuesto en una subnet pública, la base de datos en una subnet privada, tiene replicado el ambiente en otra región para desarrollo y vemos que también tiene en otra región también la parte de todos los respaldos del aplicativo del ambiente de producción y del ambiente de desarrollo en un Bookend s y el histórico lo tienen en un s Glacier Deep Archive, esto por temas obviamente de costos. El detalle aquí que tienen es que no tienen segmentados los permisos, entonces básicamente vamos a ver cómo es que se mantiene o cómo podemos ayudarle en esta parte vemos que no tienen permisos de de cuentas, vemos que ni siquiera tienen a lo mejor activado el MFA directamente en la cuenta, entonces estas son malas prácticas, ni siquiera tienen roles. Entonces partiendo de esta vamos a desglosar cómo se visualizaría en un esquema de organizations y también para que tengan visibilidad de todos los recursos. A partir de aquí tenemos desplegados ahora sí que ya el ambiente un poquito más detallado de lo que estábamos viendo anteriormente, vemos que se puede desglosar en unidades organizacionales el tema de las cargas de trabajo que es la primera de Warlocks, tenemos otra unidad organizacional que engloba todas las cuentas de seguridad, tenemos otra unidad organizacional que implique temas de monitoreo, de visibilidad de todas las cuentas, etcétera. Entonces nosotros podemos segmentar esta parte mediante estas unidades organizacionales y obviamente sin perder la gobernanza y la administración de todas estas cuentas. Inicialmente vamos con los servicios de lo que es los costos, aquí tenemos implementado en nuestra cuenta de administración los Budgets, Esto básicamente por ejemplo el cliente menciona que quiere visibilidad de los costos que se estén generando en cada cuenta. El servicio de AWS Budgets nos ayuda a configurar un umbral de gasto por un mes o el periodo que nosotros tengamos y por ejemplo si nosotros definimos que a lo largo del mes en una cuenta queremos únicamente gastar 100 dólares, si es que nosotros ya estamos llegando podemos definir umbrales por porcentaje 90%, 80% enton cuando ya esté llegando al 80% y si es que aún no llega el mes o estamos a mitad del mes, pues ya nos va a lanzar una alerta, entonces nos da visibilidad de cómo se está gastando. Obviamente mediante el tagueo también de los recursos que mencionaba anteriormente es que nosotros podemos ubicar en dónde se está gastando a lo mejor más los recursos que tenemos aprovisionados en nuestra cuenta y va muy de la mano con el servicio de AWS Cost Explorer, Este básicamente nos ayuda a tener visibilidad de las facturas, tener visibilidad también de los costos que estemos llevando a cabo en nuestra cuenta por los recursos, lo podemos filtrar también por los tags, por zonas de disponibilidad, por tipo familia, etc. Cosplore nos da la visibilidad 360 de los gastos que nosotros estemos haciendo en nuestras cuentas. Ahí en un esquema de Organizations, en nuestra Master Account, aquí podemos ver todas las cuentas que tenemos dentro de nuestra organización y podemos ubicar también los gastos que pudieran estar generando extra. Entonces hasta aquí sería el tema de de la visibilidad y de los costos.

Víctor, por ejemplo, tomando de referencia del warning de la arquitectura anterior, ¿Cómo se podría estar mejorando la postura de las políticas o la administración de estas a través de Organization?

Justo, justo Dani, de hecho el siguiente tema es que básicamente nosotros podemos estar configurando nuestras. Las políticas de los permisos hacia nuestros usuarios lo podemos estar configurando mediante cuenta por cuenta. Pero sabemos que también esto es un poquito. Pudiera ser a lo mejor muy tedioso hacerlo si es que tenemos un esquema de organizaciones amplio, porque tenemos que estar metiendo cuenta por cuenta. Pero mediante organizations, como bien mencionaba anteriormente, a través de nuestra Master Account, nosotros podemos configurar políticas que se llaman Service Control Policies, perdón. Y estas básicamente nos ayudan a segmentar los permisos directamente hacia todas nuestras cuentas. Si es que nosotros podemos configurar alguna política de negación de acceso y queremos que afecte a lo mejor a alguna o todas las cuentas, la podemos configurar desde nuestra Master Account. Y estas políticas afectan a todas las que nosotros desglosemos y nos ayudan obviamente a estar editándonos, estar metiéndonos cuenta por cuenta. Y así podemos segmentar los permisos tanto de denegación o de permisión de los recursos. Entonces, las Service Control Policies nos ayudan bastante a hacer el despliegue de todas estas políticas de acceso o denegación. Entonces, no sé si con esto cumple tu pregunta, Dan.

Sí, todo claro. Gracias, Víctor.

Muy bien. Entonces, el siguiente punto también es que mediante la administración de las cuentas podemos configurar el doble factor de autenticación. Este básicamente es un dispositivo, ya puede ser nuestro dispositivo móvil o un dispositivo físico avalado. Y podemos configurar políticas para que todas nuestras cuentas tengan también a la fuerza, todos nuestros usuarios tengan activado este MFA para que puedan acceder a las distintas cuentas. De lo contrario, no podrían acceder o no les mostraría incluso los recursos que estén aprovisionados o que quieran estar consultando. Y también la segmentación finalmente de los roles. Este básicamente es para temas de cross Account, que Dani también va a hablar un poquito sobre esto, para el acceso centralizado entre cuentas. Y finalmente, los servicios adicionales que se pueden estar integrando también en este esquema que estamos resolviendo. La problemática anterior es que nosotros también tenemos la visibilidad a través del HEL Dashboard, como bien lo dije, se puede configurar una política de notificaciones a los eventos. Si nosotros o AWS tiene alguna ventana de mantenimiento hacia los recursos, este servicio nos puede estar notificando y nos puede estar notificando directamente a través de esta cuenta y estar nosotros notificando vía, como lo dije, SMS, email, etc. Podemos ahí hacer algún desarrollo particular para que se pueda estar centralizando las notificaciones y pues tenemos también el tema de auditoría. En esta solución que estamos desarrollando configuramos el servicio de Audit Manager, nos ayuda a evaluar los riesgos que pudiera tener nuestras cargas de trabajo, nuestras cuentas hijo que tenemos aquí configuradas y pues nos ayuda con el cumplimiento de estas mismas. Y para el tema de AWS Backup también lo tenemos configurado para estar respaldando todas estas cuentas que tenemos actualmente y pues obviamente no nos estamos. Tenemos ahora sí que la continuidad de negocio reforzada en el tema de a lo mejor un desastre que pudiera estar ocurriendo en alguna cuenta o en algún recurso. Y finalmente la parte seguridad también reforzando el acceso a las múltiples cuentas que tenemos nosotros aquí en este esquema tenemos configurado lo que es el IAM identificado y tenemos básicamente el acceso federado hacia un proveedor, un tercero y este básicamente también nos ayuda a que si nosotros tenemos algún, como bien lo dije, un directorio de accesos, este se puede utilizar mediante este servicio para no estar accediendo mediante múltiples contraseñas que tengamos configuradas hacia las distintas cuentas que tengamos que acceder o que manipular. Entonces pues básicamente este es un esquema de Organizations. Mi participación es toda por ahora, les dejo con Dani y pues les agradezco más que nada la atención.

Muchas gracias Víctor. Muy buenos días a todos. Muy bien, yo les voy a hablar acerca de Control Tower, que más que ser un versus entre Organizations y Control Tower, es cómo vamos a ir vinculando estos servicios para hacer que nuestra carga de trabajo, la organización, que estemos manejando, toda nuestra estructura de cuentas, pues cuente con los mejores lineamientos, las mejores prácticas de AWS, ¿Vale? ¿Bueno, comenzando con Control Tower, pues bueno, este es un servicio de AWS que se integra con Organization, de hecho este vendría siendo la base para que Control Tower pueda funcionar, OK? ¿Control Tower nos ofrece una forma sencilla de configurar y gobernar nuestro entorno multicuenta, nos permite estar, digamos, ampliar las capacidades que tenemos de la organización, de la organización como tal, para lograr que éstas se encuentren estandarizadas bajo ciertos lineamientos de seguridad, OK? ¿Bueno, les voy a presentar aquí un par de casos de usos que podemos ver en cuanto a Organization, perdón, a Control tower, OK? Tengo 4 puntos en total, que es implementación de nuevas aplicaciones con rapidez, aprovisionamiento de cuentas de AWS en conformidad, despliegue de controles de residencia de datos y aumentar la agilidad sin comprometer la seguridad, OK, muy bien, para la aplicación de todos estos casos de uso los voy a estar desarrollando digamos a través de las arquitecturas, vale, o sea mediante el conjunto de servicios vamos a ver cómo se integran entre sí para poder cumplir con estos casos, vale, muy bien, comenzando con Control Tower les voy a mostrar como una arquitectura, o sea ya sabemos que este requiere de Organizations y que Organization se conforma por un conjunto de de unidades organizacionales, vale, aquí les muestro algunos ejemplos más de las unidades que podemos estar generando, OK, obviamente las unidades que vamos a estar configurando van a depender muchísimo de la organización, puede que exista una base obviamente de seguridad, sandbox, producción para varias organizaciones, pero si ustedes quieren dividir su organización entre algunas otras unidades que a lo mejor por departamento dentro de la empresa es válido, vale, muy bien, aquí es donde entra Control Tower OK, Control Tower básicamente va a empezar a brindar los permisos necesarios a Organization y a todas las unidades, ya nos comentaba Víctor que se tiene el tema de Service Control Policies para proveer los permisos, OK, esto viene siendo algo complementario a nuestro servicio de Control Tower, vale, ¿Qué tiene Control Tower en particular? Pues bueno, este debe de contar con tres cuentas estándar, lo que es la cuenta Máster que digamos viene siendo nuestra cuenta principal donde habilitamos básicamente nuestro recurso, tenemos también nuestra cuenta de logs, Log Archive y Audit Account que esa la podemos encontrar dentro del apartado de seguridad, vale, dentro de la unidad de seguridad, ahí lo podemos visualizar, OK, la cuenta Máster como ya les mencionaba anteriormente es la que nos permite la creación y la gestión financiera de todo nuestro ambiente multicuenta OK, esta es la principal ventaja que vamos a estar obteniendo de nuestra cuenta maestra, el tener un billing consolidado que ya les explicó Víctor hace un momento, vale, muy la cuenta de locask es la que nos va a incluir este bucket centralizado en esta cuenta, OK, para mandar ahí todos los logs de las llamadas a API que se generan dentro de cada uno de las cuentas o consolas de AWS. ¿Por qué es bueno tener los logs en una cuenta independiente? ¿Víctor les mostraba en la primera arquitectura el un ejemplo de que se tenía una región para mandar ahí los logs, OK, esa es una buena práctica para comenzar y podemos decir que tenemos el inicio de todas las buenas prácticas de seguridad si lo queremos ver de alguna forma, pero qué pasa si tenemos algún usuario que pues bueno, con intenciones maliciosas, vale? ¿Si esa persona tiene acceso a la cuenta va a tener acceso a los logs y si quiere borrar lo que hizo, pues simplemente lo va a eliminar porque tiene acceso a la cuenta, OK? ¿Qué hacemos cuando tenemos esta cuenta de logs aparte? Pues bueno, solamente algunas personas autorizadas van a poder acceder a esta información y esto ya nos brinda una capa de seguridad adicional. Lo mismo sucede con la cuenta de auditoría, ¿Vale? ¿Esta cuenta de auditoría para comenzar se tiene que encontrar restringida en cuanto a los permisos, OK? Esto en cuanto a permisos de lectura y escritura, esto quiere decir que no cualquiera debería poder acceder ni modificar los datos que se generan en esta cuenta, ¿Vale? ¿Muy bien, aquí obviamente como les mencionaba en el Deluxe, pues bueno, es tener nuestros usuarios predeterminados con sus correctas políticas de seguridad, con privilegios mínimos, que tenga el MFA configurado, tener el MFA en la cuenta root, son las mejores prácticas que podemos estar habilitando de forma inicial, OK? Para temas de auditoría, cuando tengan que presentar alguna auditoría con algún externo, terceros, esta cuenta les va a servir muchísimo, porque si bien existen servicios que de forma nativa nos están dando los logs en nuestra propia cuenta, pues bueno, esta solamente tienen retención de 90 días y cuando queramos presentar alguna auditoría o que nos pidan tener un periodo mayor de retención, pues bueno, este es el escenario ideal porque ya nosotros podemos colocar la política de ciclo de vida según lo necesitemos, ¿Vale? Muy bien, bueno, como les mencionaba, Control Tower cuenta con, pues con algunas características que les voy a explicar en la siguiente arquitectura.

OK Dani, bueno, ya vimos todos los temas de Organizations con Control Power, pero ¿Cómo podemos obtener más seguridad? No sé si actualmente podemos agregar más seguridad a Organizations.

Es correcto, sí, de hecho vamos a entrar a este punto, digo, si bien aquí vemos el servicio de Service Catalog, existe algo más allá que se llama las Landing Zone. La Landing Zone, digamos, es básicamente un entorno de AWS que se conforma de diversas cuentas, en este caso estas cuentas se encuentran digamos, adheridas a las mejores prácticas de seguridad, o sea, seguridad y cumplimiento es lo que estamos buscando. Utiliza, pues como les decía, los lineamientos más que nada de identidad, acceso federado, mantener una estructura de cuentas para automatizar también la creación de nuevas landing zone o de nuevas cuentas, pero básicamente con el landing zone es como podemos proveer estas capas adicionales de seguridad. De hecho, ahorita voy a explicar un poco el flujo que vamos a estar manejando y cuáles son los alcances que se pueden llegar a tener. Muy bien, bueno, comenzando aquí con Service Catalog, que es uno de los servicios fundamentales dentro de Control Tower. Este servicio nos va a permitir mantener, como dice el nombre, un catálogo de los servicios de AWS. Aquí lo que vamos a hacer es que, digamos, ir más allá, o sea, dejar como un catálogo predefinido de los servicios que se pueden estar lanzando dentro de las cuentas de AWS, ¿Vale? Aquí ¿Qué hacemos? Evitamos que nuestros usuarios puedan lanzar, por ejemplo, un network firewall, nada más por pruebas, por poner un ejemplo, nosotros podemos estar delimitando tanto las capacidades como los servicios o que lancen una instancia CX large, por ejemplo, que lancen mejor una T large. Esto nada más por mencionar un par de ejemplos, ¿Vale? OK, Pero bueno, a través de este servicio tenemos un usuario que va a ser el lanzamiento de una nueva cuenta o va a gestionar el lanzamiento de una nueva cuenta. Esta cuenta se va a estar creando, digamos, en una consola independiente. Es cuando comienza el proceso de creación de esta nueva cuenta, o sea, ya se vuelve una cuenta hija, si lo vemos así. OK, Ya que tenemos esta cuenta creada, esto va a arrojarnos un evento, un evento que a través de Clowatch y las reglas de cloudwatch o evenbridge, que viene siendo el equivalente, se va a detectar este evento y lo que va a hacer es que nos va a lanzar una función blanda. ¿Esta función blanda nos va a permitir gestionar algún par de movimientos o lanzamientos que nos va a servir para configurar nuestra cuenta hija, OK? ¿Digo, crowdwatch no nada más nos sirve para monitoreo, sino también para la detección de eventos, haciendo un paréntesis, vale? Vale, muy bien. ¿Ya que tenemos nuestra función lambda, esta nos va a ayudar a lanzar un stack, nos va a añadir un nuevo stack, como les mencionaba Víctor, a través de CloudFormation, OK? Este stack es el que nos va a permitir hacer el lanzamiento de los nuevos recursos. Aquí solamente colocamos un par de servicios base. Aquí, digamos, lo que queremos en esta cuenta hija es que cuente con los roles para las estrategias de cross account, por ejemplo, para roles que se van a estar integrando, digamos, para llevarnos los logs de nuestra cuenta hija a la cuenta maestra o a la cuenta de auditoría, ¿OK? Vamos a también configurar una VPC con su respectivo VPC Flow Logs. En este caso ya vamos a tener una VPC estandarizada con cierto CIDR según nosotros lo necesitemos, ¿OK? Y vamos a tener la recopilación de los logs. Dichos logs obviamente se van a estar llevando a nuestras cuentas de logs para poder tener la retención correspondiente y pues bueno, que esto nos sirva para cuando ocurra algún incidente de red o algún incidente de seguridad, pues obviamente lo podamos consultar más a detalle, ¿Vale? A su vez, vamos a estar lanzando servicios de seguridad como tenemos Gardutti y Security Hub, eso también nos puede dar pauta configurar servicios como KMS o algunos otros servicios de seguridad. Yo solamente quise hacer hincapié en estos dos. Gerduty utiliza VPC Flow Locks, en este caso para poder hacer un análisis de los hallazgos de seguridad que ocurren en la cuenta, ¿OK? Muy bien. Este gordo nos va a mostrar hallazgos de seguridad de bajo, medio y alto nivel o bajo, medio y alto riesgo y dentro del riesgo que se detecte nos va a brindar información adicional en cuanto a la latitud, por ejemplo, las coordenadas que pueda tener la IP atacante o incluso la persona o el usuario que accedió o el rol que se estuvo utilizando para cre. Digamos, esa incidencia de seguridad, ¿OK? Security Hub también va a utilizar GuardDuty, digamos, para obtener la información base y poder brindar información adicional de nuestra cuenta. Este nos va a brindar información o bueno, digamos el nivel de compliance que tenemos en la cuenta de un 0 al 100%, ¿Vale? También va a estar de la mano con tres estándares de seguridad como es el CIS, como es el estándar de seguridad que maneja AWS y acorde a esos estándares nos va a mostrar nuestro nivel de conformidad. Security Hub lo que hace es que también va a mostrar un dashboard que le va a permitir al usuario, a la persona encargada de seguridad, visualizar qué es lo que está ocurriendo, o sea, no solamente el nivel de compliance, sino qué es lo que ocurrió, información adicional, los detalles e incluso las recomendaciones que se pueden estar aplicando en la cuenta para poder remediar esos errores de seguridad o esos incidentes de seguridad, más que nada que no se vuelvan a repetir, ¿Vale? Muy bien. Adicional a eso tenemos config, que config va a ser uno de nuestros servicios base, si lo vemos así, digo, control tower nos permite configurar como ciertos lineamientos que deben de cumplir las cuentas, ahorita se me ocurre que por ejemplo que todos los usuarios tengan un MFA configurado es uno de los lineamientos base y no vamos a poder utilizar este usuario si no cuenta con su MF activado o que en las instancias EC que se estén lanzando mandatoriamente deben de tener una clave KMS configurada, tachada para poderla lanzar y utilizar, en caso contrario pues no vamos a poder hacer uso de ella. Muy bien, config, retomando este tema, nos brinda algo que se llama como comportamiento, o sea un análisis de los comportamientos de los controles, lo que hace es que cuente como con ciertas plantillas, si lo vemos así, estas plantillas nos van a permitir estar analizando qué es lo que ocurre en nuestra cuenta, OK, porque lo que hace config es que también está registrando los detalles de los cambios en nuestros recursos para brindar un mejor historial de las configuraciones, es decir, va a ser esta herramienta que nos esté notificando cuando alguien haga algún movimiento en la consola, digamos nos va a importar más los movimientos que puedan ocurrir en nuestra consola productiva, entonces es importante tener habilitado config para que nosotros pod podamos detectar cuando algo esté ocurriendo, OK, o fue X persona, X usuario a pagar tal recurso o tal rol, apagó tal recurso, les va a llegar una notificación de ese evento que se estuvo accionando y ya ustedes van a poder tomar las acciones correspondientes, vale, los logs o esta información igual lo manda a un bucket de s, puede ser la misma cuenta de logs que les había mencionado anteriormente y pues también les mencionaba que cuenta como con estos paquetes de conformidad que van a ayudar a administrar o a ayudarnos a gestionar todo el cumplimiento de las configuraciones de nuestros recursos de AWS, vale, muy bien, este es básicamente el proceso de lanzamiento de una nueva cuenta y cómo se configuran estos servicios a través de una landing zone, vale, o sea vemos que no nada más es OK si utiliza landing zone y ahí se queda, obviamente se requiere el involucrar diversos servicios de AWS para poder llegar a cumplir con ciertos lineamientos de seguridad, que todas nuestras cuentas se encuentren estandarizadas ¿Vale? Muy bien, les voy a mostrar básicamente un resumen, un resumen de lo que es Control Tower y lo que es Organization, de cómo se van integrando. Ya sabemos que estos dos servicios son nuestra base para todas nuestras cuentas. Ya sabemos que podemos integrar Identity Center hacia nuestro Organization para tener accesos federados, un acceso centralizado hacia nuestros recursos. Aquí ya podemos hacer uso de el Directorio del Single Sign On, o sea, hacer uso de servicios nativos de AWS para complementar la oferta. Ya les comentaba que obviamente Organizations, pues pueden tener diversas unidades, en este caso voy a colocar las unidades, la unidad Core, si lo vemos así, y se va a encontrar distribuido entre las cuentas que consideramos las más importantes, ¿Vale? Y que Control Tower obviamente hace uso de los Stack, que hace uso de Service Catalog para poder llegar a tener este nivel de compliance en todas las cuentas de AWS que estemos lanzando, ¿OK? Retomando, aquí tenemos lo que son las cuentas de logs, que como les decía, obviamente debe de contar con una base, unos lineamientos bases de la cuenta, que eso nos los va a proveer Control Tower, como los que les mencionaba de el hecho de utilizar KMS o el hecho de que los usuarios tengan un MFA mandatorio en sus cuentas. Y también lo otro mandatorio, digamos, va a ser el hecho de que se va a estar agregando, por ejemplo, el Config a todas nuestras cuentas hijo y la habilitación o la recopilación de los logs de CloudTrail hacia esta cuenta de logs. Tenemos nuestra cuenta de auditoría, que igual, mismo lineamiento base, esta nos va a proveer también la seguridad acerca del Cross Account Role, que son los roles que básicamente se lanzaron anteriormente en nuestras cuentas para tener, por ejemplo, acceso desde nuestra cuenta Máster hacia nuestra cuenta hijo, ¿OK? Y pues bueno, también para podernos llevar la información de la recopilación de los logs, ¿OK? Muy bien, tenemos el apartado de seguridad, de las notificaciones de seguridad, en este caso, que también les mencionaba Víctor un poco de eso con el Held Dashboard, en este caso vamos más hacia Config para tener esta recopilación de las notificaciones y que casi en tiempo real les estén notificando de los eventos que estén ocurriendo, de los cambios que se estén haciendo y también el hecho de tener CloudWatch agregado hacia nuestras cuentas para poder tener, digo, si bien estuvimos enfocando en temas de detección de los de los eventos, pues obviamente puede ser para que ya esté monitoreando sus cuentas. Y por último tenemos las cuentas aprovisionadas. ¿Estas cuentas aprovisionadas básicamente van a ser todas nuestras cuentas hijo que vamos a estar lanzando, en donde se buscaría que éstas obviamente cuenten con los mismos lineamientos de seguridad, OK? Y aparte con lineamientos acerca de redes, ¿Vale? En temas de redes es el tema de lanzamiento de la VPC con su VPC Flow Logs integrado, pero no solamente se puede quedar ahí, sino que podemos tener una distribución de cuentas, digamos una cuenta para inspección, por ejemplo, otra cuenta para endpoints y en cada una configurar una VPC diferente, integrarlas a través de un Transit Gateway para que tengan comunicación, ¿Vale? Y que nuestra cuenta productiva, nuestra cuenta provisionada se integra a través de este Transit Gateway hacia las demás cuentas que han sido creadas, por ejemplo, podemos tener una que sea para temas de accesos por un bastión host, por ejemplo. Entonces aquí tenemos o aumentamos la resiliencia de nuestra carga de trabajo porque lo vamos a tener a través de un Transit Gateway, va a estar segmentada nuestra cuenta, van a estar obviamente en diferentes consolas y pues bueno, el tráfico se va a estar llevando a través del Transit Gateway. Entonces estas son algunas de las estrategias que podemos estar implementando. Como ven, no necesariamente es un verso, sino más bien es cómo podemos complementar estos servicios, estas ofertas que AWS nos brinda para lograr que nuestras cargas de trabajo, que todas nuestras cuentas se encuentren segmentadas y bajo las mejores prácticas de seguridad en este caso. ¿OK? ¿De mi parte sería todo, agradezco mucho el tiempo que nos brindaron durante la sesión, si tienen alguna pregunta nos la pueden hacer llegar por el chat, vale? Muchísimas gracias por su tiempo. ¿Tool Tower obviamente hace uso de los stack y hace uso de Service Catalog para poder llegar a tener este nivel de compliance en todas las cuentas de AWS que estemos lanzando, OK? Retomando, aquí tenemos lo que son las cuentas de logs, que como les decía, obviamente debe de contar con una base, unos lineamientos bases de la cuenta, que eso nos los va a proveer Control Tower, como los que les mencion de el hecho de utilizar KMS o el hecho de que los usuarios tengan un MFA mandatorio en sus cuentas, ¿Vale? Y también lo otro mandatorio, digamos, va a ser el hecho de que se va a estar agregando, por ejemplo, el config a todas nuestras cuentas hijo y la habilitación o la recopilación de los logs de CloudTrail hacia esta cuenta de logs, ¿OK? Tenemos nuestra cuenta de auditoría, que igual, mismo lineamiento base, esta nos va a proveer también la seguridad acerca del cross account rol, que son los roles que básicamente se lanzaron anteriormente en nuestras cuentas para tener, por ejemplo, acceso desde nuestra cuenta máster hacia nuestra cuenta hijo, ¿OK? Y pues bueno, también para podernos llevar la información de la recopilación de los logs, ¿OK? Muy bien. Tenemos el apartado de seguridad, de la notificaciones de seguridad, en este caso, que también les mencionaba Víctor un poco de eso con el Hell Dashboard. En este caso vamos más hacia config para tener esta recopilación de las notificaciones y que casi en tiempo real les estén notificando de los eventos que estén ocurriendo, de los cambios que se están haciendo y también el hecho de tener Cloud Watch agregado hacia nuestras cuentas para poder tener, digo, si bien estuvimos enfocando en temas de detección de los eventos, pues obviamente puede ser para que ya esté monitoreando sus cuentas. Y por último, tenemos las cuentas aprovisionadas. Estas cuentas aprovisionadas básicamente van a ser todas nuestras cuentas hijo que vamos a estar lanzando, en donde se buscaría que éstas obviamente cuenten con los mismos lineamientos de seguridad y aparte con lineamientos acerca de redes, ¿Vale? En temas de redes es el tema de lanzamiento de la VPC con su VPC Flow Logs integrado. Pero no solamente se puede quedar ahí, sino que podemos tener una distribución de cuentas, digamos una cuenta para inspección, por ejemplo, otra cuenta para endpoints, ¿Vale? Y en cada una configurar una BP.