Buenas prácticas de seguridad en AWS

Bueno, muy buenos días nuevamente y gracias por conectarse a nuestro webinar Buenas Prácticas de Seguridad en AWS. Les comentamos que esta sesión será grabada y transmitida a través de nuestro canal de YouTube. Y pues, con el fin de que ustedes puedan tener acceso nuevamente a ver el contenido de la sesión del día de hoy y que también lo puedan compartir en redes sociales en el correo que nos enviaron. También les estaremos enviando el material que vamos a ver el día de hoy y también el link con el acceso a esta grabación. Les platico rápidamente quienes nos están acompañando el día de hoy. El día de hoy nos acompaña la ingeniera Victoria Hernández, que es especialista en ciberseguridad. Y también está el ingeniero Víctor Ramírez, que es el líder del departamento de Customer Success aquí en CompuCloud. Y pues, ambos son consultores especializados en la nube de AWS. Muy bien, también les platico brevemente quiénes somos. Algunos de ustedes ya nos conocen, otros tal vez no. Entonces, pues, Compost, un Partner Advanced de AWS. Y pues, esta certificación tiene el fin de poder ofrecerles a las empresas este nivel de conocimiento y expertise que tenemos en la nube de AWS. Y pues, actualmente también contamos con presencia tanto en la República Mexicana como en Centroamérica. Y también hace poco estuvimos trabajando con algunas empresas en el extranjero que también están buscando este tipo de modernización en la nube de AWS. Y pues, en esta sesión vamos a explorar también los principales desafíos que enfrentan las organizaciones al proteger su entorno en la nube de AWS. También les compartiremos las buenas Prácticas de Seguridad recomendadas por AWS y podremos apoyarlos para reforzar su postura de seguridad, brindándoles una visión clara y práctica de cómo implementar estas soluciones y los controles efectivos de protección, detección y respuestas ante amenazas. Muy bien, entonces los dejo con mi compañera Victoria para que ella pueda iniciar dando esta charla.

Perfecto. Hola a todos. Muchas gracias por conectarse. Entonces, iniciaremos principalmente revisando nuestro escenario para hacerlo un poco más dinámico. En este caso tenemos a una empresa X, que su objetivo fue modernizar su infraestructura, optimizar los costos, ganar una mayor escalabilidad, agilidad, resiliencia, pero se olvidaron un poco de la estrategia de seguridad. Claro que para estos puntos nos ayuda estarnos moviendo la nube, pero cuando se busca llevar una implementación bastante rápida, Muchas veces nos olvidamos de este tipo de objetivos, tienen la oportunidad de construir una base sólida de seguridad desde cero pero si no lo hacen a tiempo pueden ser un objetivo bastante vulnerable y para eso estaremos iniciando un poco con algunos casos prácticos aquí dentro de la consola. El primero que vamos a estar revisando es de la parte de IAM que es lo esencial cuando estamos iniciando con nuestra cuenta para poder analizar quiénes tienen acceso, qué usuarios tenemos, qué roles tienen asignados, las políticas y hasta dónde pueden llegar. Para eso vamos a utilizar la herramienta de Access Analyzer y se preguntarán para qué nos sirve precisamente esta herramienta nos ayuda para estar monitoreando qué usuarios son los que tenemos, qué es lo que están realizando e incluso qué tipo de configuraciones tenemos que ya no han sido utilizadas, esto fácilmente se puede configurar aquí le damos en crear y lo único que tenemos que seleccionar es qué tipo de analizador es el que vamos a necesitar tenemos el de uso de accesos externos, disculpen, este no lleva ningún costo adicional también tenemos uno para accesos internos y uno para los recursos que no son utilizados, lo único que tendrían que hacer es seleccionar cada uno de ellos. Enseguida podríamos tener otras configuraciones que son un poco más opcionales e incluso agregar por ejemplo etiquetas, eso nos ayudará para hacer alguna conexión a futuro con servicios como Security Hub, lo único que tendríamos que hacer es darle en crear, de momento no lo vamos a hacer porque ya tenemos uno aquí listo y así es como se vería, nos muestra diferente información y aquí podríamos darle cierto seguimiento para revisar qué es lo que nos está arrojando y este sería un ejemplo por ejemplo de cómo utilizar, implementar y tener el acceso a Analyzer. Continuaremos ahora con el cifrado de los datos y para eso nos vamos a ayudar del Secret Manager y System Manager de inicio, este de Secret Manager nos ayuda para poder configurar secretos, básicamente un secreto sería esa información sensible, tokens, contraseñas, datos que realmente tenemos que tener de una forma mucho más segura lo único que tienes que hacer es darle en almacenar un nuevo secreto y aquí nos da diferentes opciones, por ejemplo puede ser Amazon RDS, Amazon DocumentoDB, Amazon Redshift nos deja incluso para seleccionar otro tipo de bases de datos, en este caso vamos a estar creando uno que fuera como clave API o tokens que nos sirve para desarrollos, aquí sólo colocamos algunos datos podemos darle siguiente, necesitamos un nombre, podemos agregar alguna descripción o etiqueta, damos siguiente y una cosa muy importante que nos permite hacer aquí es la rotación automática, para esto anteriormente tendríamos que tener cargado un lambda, entonces también quedaría como parte de esta tarea para poder implementarlo, sin embargo es de bastante utilidad el poder utilizar la rotación. Después le damos siguiente, revisamos toda la configuración que ya hicimos y aquí nos da incluso un código de muestra que podríamos estar implementando en nuestros desarrollos, ya sea Java, JavaScript y algunos otros. Por último solo deberíamos darle Almacenar y recargamos, aquí ya aparecería nuestro secreto. Otra opción de las que les quería platicar es aquí en System Manager, tenemos que ir a Herramientas de aplicación y Parameter Store, desde este lado nos deja almacenar también ciertas credenciales, contraseñas, información sensible, pero este funciona más a modo de almacenarlo y la verdad es que es más recomendable utilizar el otro por esa función de poder automatizarlo y que se pueda cambiar cada cierto tiempo, entonces solo como pequeño ejemplo igual le tendríamos que poner un nombre y podemos almacenar scripts para que pueda visualizarlo, por ejemplo aquí tenemos uno ya creado, Así se vería más o menos Y con esto podemos dar inicio a la primera parte de nuestra presentación, básicamente lo que queremos es mantener nuestra consola, nuestra infraestructura de una forma más segura y para eso veamos cuáles son las principales causas de incidentes En la parte de seguridad, el 66 % es por compromiso de credenciales, esto puede ser debido a phishing, robo de credenciales o que entramos en una página que realmente no es segura, sin embargo lo más curioso es que el 33% de ellos fue con el usuario root, esa es una cifra bastan alta y sabemos que ese usuario tiene que ser protegido de la forma más exhausta posible. Por otro lado, el 13 % es por la explotación de vulnerabilidades en instancias de EC, esto puede ser debido a falta de parches o puertos que están abiertos. Y el 21 % es por incidentes relacionados a usuarios internos, configuraciones débiles, buckets abiertos o repositorios de código abierto para que lo tengamos en consideración. Ahora sí, con esto podemos iniciar con cuáles son las buenas prácticas que nos ayudarán a evitar este tipo de incidentes y para eso Víctor, ayúdanos a comentar cuáles son los mejores manejos para poder tener segura nuestra cuenta RUT.

Claro, claro, Victoria, ¿Qué tal? Muy buenos días a todos. Agradecemos bastante su asistencia, esperamos que la información sea relevante para ustedes y que se puedan llevar algo de esto igual para continuar obviamente aquí en su camino en AWS. Como primer punto vamos a estar revisando estos temitas respecto a buenas prácticas de la cuenta root. La verdad, o sea, iniciamos con esto porque es la base de donde nosotros, por así decirlo, construimos nuestra cuenta directamente en AWS. Y como primer punto y muy importante es el tema de una activación de una autenticación en multifactor. Está básicamente se puede estar configurando directamente con lo que son dispositivos móviles o dispositivos físicos. En móviles podemos a lo mejor utilizar el Google Authenticator, el de Microsoft o Auti, básicamente para utilizar tokens de usos únicos. Esto nos da otro nivel de seguridad respecto a lo que es el uso y el acceso a nuestra cuenta. Un segundo punto que va muy de la mano también es que este usuario root solamente se utilice en actividades críticas, es decir, cuando es muy necesario por así decirlo, y evitar el uso en tareas cotidianas. A veces creemos que al momento de que creamos nuestra cuenta inicial y por consiguiente configuramos el correo y algo y estamos accediendo y usando la cuenta y con este usuario creemos que es lo más normal que pueda haber, pero definitivamente es una práctica, pues por así decirlo, insana, que no se recomienda del AWS, porque directamente si este usuario se puede ver comprometido, directamente toda nuestra carga y todo lo que pueda haber dentro de esta cuenta se puede ver comprometida. El tercer punto es la parte del monitoreo y el uso de la cuenta, apoyándonos de servicios como AWS CloudTrail, más adelante vamos a ver un poquito de cómo se utiliza CloudTrail, ver algunos tipos de registros, cómo podemos ubicar también, pero pues básicamente es también el uso del monitoreo y la auditoría sobre el manejo de esta cuenta, apegado también a lo mejor con otros servicios directamente, como ejemplo de Wear Duty que nos puede lanzar alertas a lo mejor cuando se puede estar usando este usuario. Este cuarto punto es el tema de Access Keys, evitar obviamente estar usando este usuario directamente con Access Keys, también más adelante vamos a platicar un poquito sobre qué es lo que es, pero básicamente son credenciales de acceso programático. Entonces, si estas credenciales las utilizamos directamente para acceder desde otras entidades pues directamente también se pueden ver comprometidas nuestros recursos y directamente lo que es el usuario. Vale, No sé qué te parezca Victoria continuar con las siguientes.

Sí, perfecto. Como siguiente punto, una de las recomendaciones es que al nosotros crear nuestra cuenta o estar haciendo las primeras configuraciones lo mejor sería no estar utilizando el usuario root para todo este tipo de actividades, sino que creemos un usuario que funja con este tipo de permisos más ilimitados con el fin de que lo vamos a estar utilizando bastante pero para no exponer precisamente a esta cuenta root que es la esencial. Y por último, un gran punto, eduquemos a todos nuestros equipos, hay que estar asegurados de que todos los que tienen acceso a esta cuenta root sepan para qué se utiliza y cuál es el riesgo que tiene el utilizarla tal cual, muy importante sería el siempre tenerla protegida, no dejarla con acceso para todos los usuarios y que así todos comprendamos un poco mejor de cómo tenemos que cuidarla. Con esto cerramos el tema de la cuenta root e iremos a las access keys y para eso Víctor nos ayudas diciéndonos qué es una access key.

Claro que sí, justo como lo comentábamos anteriormente, las access key son credenciales de uso programático, básicamente son, si podemos así llamarlos como tokens o credenciales alfanuméricas de uso, como lo viene así de uso duradero, o sea nosotros delimitamos el tiempo que nosotros queramos usarlos, AWS naturalmente no las rota ni son acceso temporal, tienen un periodo por así decirlo de caducidad y puede ser usada desde cualquier lugar, es decir, si podemos nosotros a lo mejor la integración con un tercero, a lo mejor queremos manipular una instancia o queremos manipular incluso alguna RDS o algún bucket de ese con algún otro proveedor, una aplicación, etcétera. Estas credenciales directamente son, vamos a decir que el medio que se usa para tener esta comunicación, va a depender mucho también el tema de las políticas que también vamos a hablar un poquito más adelante, que nosotros le otorguemos y sobre eso también el acceso que tengan directamente para manipular los servicios. Y como último punto pues no incluyen un MFA o otro nivel de acceso en tema de seguridad, entonces la verdad por eso es que, o sea, si son bastante útiles pero tenemos que tener cuidado al momento de utilizarlas.

Perfecto, y como lo comentas, estas realmente son muy peligrosas pero también son bastante riesgosas por lo cual se tiene que gestionar de la forma más adecuada y para eso tenemos estas mejores prácticas. Respecto a las access keys, uno de estos puntos sería el tener credenciales temporales, para eso nos ayudamos del STS que es el AWS Security Token Service para generar credenciales temporales, esto nos ayuda para que no dejemos más bien nuestras access keys de una forma ilimitada y desatendida. Otro gran punto es no nos expongamos en nuestro código, para eso estaremos viendo más adelante el tema de el cifrado que es con lo que abrimos también, pero muy recomendable, en lugar de tenerlas así, simplemente lo ideal sería agregarlas con un Secret Manager o un Parameter Store y también no usar las access keys del usuario root, como ya lo comentamos, el usuario root es solo para tareas críticas, precisamente por eso solamente se tiene que utilizar en esos casos. ¿Me ayudas a comentar los últimos puntos Víctor?

Sí, claro que sí. Rotar regularmente las access keys Como bien mencionamos AWS no realiza ningún tipo de mantenimiento o rotación en estas claves que se asocian directamente a usuarios, entonces definitivamente la tarea de nosotros como usuario es tener un tiempo predeterminado para rotarlos de manera manual. El límite que recomienda AWS es de al menos 90 días, pero si se puede hacer incluso en menos de este tiempo pues sería lo mejor. Adicional también desactivar las access keys cuando se encuentren inactivas, si por ejemplo ya nosotros no tenemos ningún tema de utilización respecto a estas mismas, pues lo ideal sería inhabilitarlas, a lo mejor por temas de cumplimiento o temas de que las queramos volver a utilizar en un tiempo corto o un periodo largo, dependiendo se pueden volver a activar o de lo contrario también se pueden eliminar. Por cada usuario se pueden crear hasta tres access keys, entonces también tenemos ahí la capacidad de estar utilizando más de una por usuario dentro de lo que es el servicio de IAM. Pero como bien mencionamos en el segundo punto, nosotros evitamos recomendar el uso de estas claves porque la verdad sí representan un riesgo pues de medio a alto en el tema de la exposición, entonces recomendamos siempre utilizar tal cual servicios como AWS Secret Manager o directamente Parameter Store para almacenar estas claves.

Perfecto, como algunos puntos extra podríamos recomendarles también el uso de las SCP que son Service Control Policies que nos ayudarán para poder organizar el nivel de permisos a nivel de la cuenta e incluso también el tener educados a nuestro usuarios, nuevamente, asegurarnos de que los desarrolladores, operadores o todos quienes tengan acceso a estas access keys sepan para qué se utilizan, pero cuál es el riesgo que conlleva dejarlas expuestas. ¿Con esto cerraríamos el tema de access keys y podemos continuar en AWS IAM para eso Víctor, nos ayudas explicándonos un poco para qué funciona IAM?

El servicio de Identity and Access Management de AWS es un servicio completamente administrado por AWS y yo creo que también es uno de los principales servicios que nosotros tenemos que conocer al momento de estar utilizando AWS o crear nuestra primer cuenta directamente, ya que aquí nosotros gestionamos, administramos lo que es el acceso seguro a todos los recursos desde nuestras entidades o identidades que puedan estar accediendo o manipulando lo que son nuestros servicios AWS, tales como podemos nosotros administrar directamente a los usuarios, podemos administrar grupos de usuarios, podemos administrar tal cual políticas, también roles, etcétera. Entonces sí, es un pilar fundamental en la parte de los servicios de seguridad que tiene AWS.

Perfecto, ahora continuaremos presentando cuál es el manejo o las buenas prácticas precisamente para IAM. Como uno de los primeros puntos tenemos el principio de mínimos privilegios, que este es uno de los principales pilares en el tema de la seguridad de una forma muy general, pero de lo que se trata es de dejar que los usuarios solamente tengan acceso a realizar las tareas que ellos necesitan hacer, nada más allá para evitar la curiosidad y también para esos usuarios que tal vez no tengan el expertise, que no puedan llegar a borrar algo o evitarnos ese tipo de problemas que también cae de la parte de la seguridad. Por el siguiente punto, nuevamente evitemos el uso del usuario root, el usuario root es solo para tareas críticas, ya lo hemos mencionado varias veces, pero no está de mal volverlo a mencionar aquí, sobre todo cuando estamos en un punto de usuarios. El siguiente punto sería el utilizar roles IAM en lugar de usuarios, esto nos ayuda bastante a facilitar la gestión, ya que en lugar de estar dando permisos a cada uno de los usuarios, podemos crear diferentes roles que ya vayan definidos y asignarlos simplemente a estos usuarios, esto nos ayuda por si alguno de nuestros usuarios dejara de funcionar, podemos llegar a hacer una gestión mucho más rápida o también para poder actualizar ese tipo de permisos a un grupo en general en lugar de hacerlo uno por uno ¿Me ayudas con los últimos dos puntos, Víctor?

Sí, y bueno, quiero hacer también hincapié en que estamos recomendando muchos temas en la parte del usuario root, porque a veces no nos imaginamos la verdad, cuánto tenemos expuesto a lo mejor este usuario sobre las prácticas. Entonces sí lo vamos a ver bastante o lo estamos viendo bastante a lo largo de este webinar. Como cuarto punto es un poquito también de lo que ya hemos hablado, el activar directamente servicios de multi autenticación para el tema de los tokens de uso único e igual esto directamente también se pueden relacionar y asignar a estos usuarios que nosotros estemos dando de alta, que puedan estar manipulando los servicios y que tengan el acceso a lo que es la consola AWS. Y finalmente, pues también el monitoreo y la auditoría. De acuerdo a lo que son temas de cumplimiento, existen servicios tales como AWS Configuración, en donde nosotros tenemos la capacidad de configurar reglas de cumplimiento. Es decir, voy a poner un ejemplo de que si algún usuario debe de tener, o todos los usuarios, perdón, deben de tener el MF activo o que también las credenciales de cada usuario de acceso a la consola se estén rotando por al menos 60 días, por así decirlo. Entonces, si hay usuarios que no lo han hecho, directamente este servicio nos permite visualizar qué usuarios no están cumpliendo con este mandato, por así decirlo, nivel organización. Entonces ahí nosotros también podemos tomar acciones y la verdad es que nos ayuda porque podemos ver a lo mejor también todo centralizado directamente en un servicio.

Perfecto. Ahora continuaremos con algunas novedades que tenemos de la parte de IAM, entre las cuales está la protección mejorada para OEBC en IAM. Esto básicamente es que implementa un análisis de LinkedIn para las políticas de confianza de roles. El objetivo es prevenir que los clientes creen roles públicos por error al configurar el OpenID Connect, que es el OIDDC, básicamente nos ayuda para poder identificar errores de configuración antes de que estas políticas sean implementadas. ¿Para qué nos ayuda? Para evitar que nosotros nos expongamos básicamente cuando utilizamos entidades externas como podría ser GitHub o algunos otros proveedores y que asuman estos roles públicos. El otro es el IAM Roles Anywhere, que nos ayuda con la compatibilidad de claves de cifrados de PKCS, que es un formato bastante común y seguro para almacenar nuestras claves privadas. Este servicio permite que espacios de trabajo fuera de AWS como podrían ser servidores on premise o incluso otras nubes puedan asumir roles de IAM, esto mejorando nuestra seguridad también para que podamos contemplarlo si están interesados también podrían buscarnos por ahí más adelante para darles más detalles sobre estas novedades y muy importante, continuaremos con esta parte para saber cómo podemos evaluar nuestras propias políticas. Víctor, ¿Nos ayudas a definirlo?

Sí, claro que sí, esto es un diagrama de flujo muy básico realmente aquí tratamos de explicar un poquito de cómo AWS evalúa lo que son el tema de las políticas en el punto uno iniciando por ejemplo que todo, todo este, toda política si no tiene un deny o un allá explícito entonces está todo denegando, está bloqueado tal cual el acceso, ¿Vale? Entonces eso nos lleva al siguiente punto de cómo evalúa prácticamente AWS una política cuando se tienen estos dos por así decirlo, permisos, si se tiene como tal un deny explícito esto nos quiere decir que nosotros estamos denegando lo que es una, la manipulación directamente a lo que es un objeto y es muy importante saber, o sea que el término deny en una política si está inicialmente configurada va a denegar todo lo que conlleva a lo mejor si nosotros incluso ponemos una laud debajo de un deny, la sentencia y lo que va a tomar inicialmente AWS es el deny, entonces para que nosotros por ejemplo queramos al momento de crear una política vamos a poner, vamos a decir con condicionantes o segmentadas debemos nosotros ponerlos a law primero y al final poner los deny para que no, a lo mejor no tengamos problema al momento de la manipulación de algún servicio o por ahí a lo mejor nos esté generando algún error. Entonces si no se tiene un deny explícito, es decir, se tiene un allow, si se tiene el allá explícito que tal cual estamos permitiendo lo que es una condicionante y el acceso a ese recurso y definitivamente si nos lleva al punto 5, si no hay ningún deny o un halago explícito en alguna política nos lleva básicamente al primer punto por así decirlo, que no podemos estar manipulando ningún tema de algún servicio, ¿Vale? Entonces siempre tenemos que tener delimitados o completamente explícitas nuestras acciones que vamos a realizar dentro de nuestras políticas con un INA y un ALLÁ, de lo contrario pues no vamos a poder tener ninguna este temas de permisos para la manipulación de los recursos.

Perfecto, y ahora continuaremos con cómo podemos inspeccionar los hallazgos en IAM, para eso utilizaríamos la herramienta de Access Analyzer que es la que estuvimos viendo al inicio. Como podríamos observar tenemos diferentes tipos de accesos que se pueden estar analizando, que era el acceso externo, el interno y accesos no utilizados. Una vez que los activamos podemos revisar en el panel de control cuáles son como esos hallazgos que está teniendo, entre ellos se pueden encontrar logs sobre Access Keys, User Password, IAM roles y recursos que no están siendo utilizados, además de que se puede integrar con las herramientas de Security hub y Amazon EventBridge para futuras funciones Lambda. Ahora continuemos con uno de los apartados, tocamos hace un momento un poquito de ello, que es el principio del privilegio mínimo, que como ya lo comentamos es uno de los pilares de la parte de la seguridad y básicamente es lo que nos dice hasta dónde debemos dejar que un usuario tenga el acceso a las tareas que está realizando. ¿Para eso Víctor, nos ayudas a comentar un poco sobre estas prácticas?

Sí, es un pilar fundamental directamente en la parte de cuando nosotros concedemos el acceso a nuestros usuarios en nuestra organización al momento de manipular lo que son los servicios y la administración de nuestras cuentas. Y el mínimo privilegio, como su nombre lo dice, es dar el mínimo permiso para que un usuario tenga la capacidad de realizar alguna acción directamente en lo que es la cuenta de AWS. Esto nos lleva a tres puntos importantes que están desglosados en pantalla, que es la parte de las políticas, como bien mencionamos anteriormente, una buena práctica es evitar el uso de políticas tales como Administrator Access o Power User Access, ya que estas políticas prácticamente dan por así decirlo acceso total y a la manipulación de todos los servicios, la modificación, la actualización, la eliminación o la creación de nuevos recursos. Entonces si cualquiera de estos usuarios que pueden contener a lo mejor ese tipo de políticas y ya sea que tengan acceso directamente a consola o que tengan acceso programático mediante CLI o algún otro tipo de credencial, pues se puede y si se puede llegar a ver comprometido, pues sí, también la cuenta puede llegar a verse comprometida directamente a lo mejor con algunas acciones que nosotros no requiramos hacer en ese momento. Para esto estas políticas, o sea, una buena práctica también es el uso de condicionantes, nosotros podemos tener condicionantes tal cual en nuestras políticas que pueden limitarse directamente a una IP, a la IP a lo mejor de la persona que si es que tiene cuenta con una IP fija o algún recurso, se pueden configurar directamente a una región incluso, o directamente también a algún TAC de algún tema de clave valor en específico que pueda tener dicha entidad que va a estar manipulando algún recurso. Y último punto, pues la parte de roles y usuarios. Al momento de utilizar roles y también usuarios, es importante a lo mejor crear políticas con el uso de credenciales temporales, como mencionado hace rato Victoria, el uso de STS nos ayuda a proporcionarnos un token y nosotros esto que lo podemos hacer temporal. Entonces, por ejemplo, estos roles o usuarios que puedan tener acceso a algún recurso, pues pueden ser directamente a lo mejor por un tiempo predeterminado que nosotros estemos otorgando. ¿De acuerdo?

Muy bien Víctor, muchas gracias. Ahora continuaremos con el cifrado por defecto para activar KMS para nuestros datos. Con esto ya lo vimos también un poquito en el inicio de esta presentación, pero veamos que ¿Que es el KMS? Este servicio nos permite crear, controlar claves criptográficas para cifrar los datos de AWS y es muy fundamental para poder mantener la confidencialidad, integridad y control de accesos de la información sensible. Para eso tenemos estas buenas prácticas por aquí Víctor, ¿Nos ayudas a comentarlas?

Sí, KMS es un servicio completamente administrado de AWS para la que es la encriptación de llaves directamente nosotros podemos utilizar llaves personalizadas para el control granular. Nosotros podemos crear este tipo de claves, por ejemplo, para encriptar a lo mejor los discos directamente en nuestras instancias, la parte de las RDS también, nuestra base de datos, nuestros buckets de s, entre otros, por así decirlo. Incluso también nos ayuda a encriptar lo que es la parte en tránsito en los certificados SCL que se proporcionan directamente aquí en AWS. Entonces, de manera granular se recomienda tener una llave criptográfica por servicio o por recurso incluso si es que se podría llegar a hacer, más que nada para el control. El siguiente punto, pues también es la rotación automática de estas claves. Estas claves son cifradas directamente por AWS, o sea, nosotros no tenemos ni siquiera el acceso a estas claves criptográficas. Entonces existe una configuración muy básica que es tal cual activar una rotación y naturalmente AWS va a estar rotando anualmente, en este caso 365 días estas claves, ¿Vale? Otro punto también muy importante es restringir el uso de estas claves por región, que no puedan manipular a lo mejor, o que no podamos manipular directamente otros servicios en otra región o que no se puedan estar compartiendo. Y justo el último punto, evitar compartirlas. Nosotros aquí también recomendamos que si tienen directamente un especialista dentro de la organización, que éste sea únicamente el que pueda administrar dichas claves para que este mismo pueda conceder lo que es la manipulación a lo mejor de los servicios. Porque directamente cuando están cifrados este tipo de recursos con una clave es muy difícil que se puedan manipular. Entonces necesariamente se tiene que tener políticas fuertes para el uso y la manipulación de estos recursos y que mejor que lo haga directamente a lo mejor una persona o un equipo en especí.

Perfecto. Y como puntos extra, también se recomienda el tener cierto monitoreo constante respecto a estas KMS para que podamos utilizarlas de una mejor forma, pero también para ello importante agregar etiquetas y alias que sean fáciles para poder identificarlas y tener una gestión mucho más organizada de ellas. Ahora, continuando, ¿Dónde podemos almacenar nuestras llaves de cifrado? Además de KMS, también tenemos otras herramientas que nos ayudan para poder estar cifrando precisamente los datos que tenemos sensibles. Incluso hay opciones on premise o de AWS Marketplace. Lo importante aquí es que ustedes realmente apliquen esta práctica de cifrar sus datos, porque si no se quedan bastante vulnerables ante diferentes ataques y que sepan que existen varias opciones. Si tienen alguna duda de cuál sería mejor implementar, se pueden comunicar con nosotros para que podamos informarles dependiendo de cada caso. ¿Ahora continuaremos con la visibilidad de nuestro entorno, que es muy importante para poder saber Ya aplicamos todo esto, pero qué pasaría si algo se alerta? ¿Cómo puedo darme cuenta y que sería importante tomar como prioridad? Para eso tenemos esta herramienta que sería la de cloudwatch. Para eso Víctor, ¿Nos ayudas a explicarnos un poco qué es lo que estamos viendo aquí?

Cloudwatch Logs es un apartado de lo que es el servicio de CloudWatch en el que nosotros podemos almacenar ahí tal cual nuestros registros, ya sea de flujo, de red, de acceso o incluso también de registros o logs de nuestras aplicaciones. Entonces, ahí lo que vemos en pantalla, pues básicamente es un registro, un log de una solicitud de una aplicación, entre otras cosas, se puede ver directamente en estos logs, por ejemplo en la parte de red se pueden ver el tema de obviamente el horario, a qué hora se realizó dicha solicitud, lo que es la origen, el origen de la solicitud, del destino, a dónde fue el puerto de origen, el puerto de destino, el tamaño del paquete, la IP, también nos puede atrapar este servicio y directamente también a lo mejor si la solicitud fue aceptada o denegada, entonces este servicio la verdad nos ayuda bastante al momento de nosotros hacer debug, perdón, debugueo o tratar de ubicar a lo mejor algún intento, alguna sospecha que podamos tener a lo mejor de acceso no autorizado, la verdad es que nos ayuda bastante en el tema de las aplicaciones, también atrapa lo que son todos los logs, podemos ver errores, podemos ver a lo mejor en donde no esté utilizándose bien a lo mejor nuestra aplicación, etcétera, ayudará a optimizar y directamente también este servicio pues la verdad o sea si a lo mejor puede llegar a ser un poquito confuso al momento de estar utilizando pero podemos apalancarnos de otros servicios como Atina o incluso un tablero en QuickSight para tener a lo mejor un tablero o una vista un poquito más intuitiva o más digerible.

Muy bien y adicionando un poco a ese último punto que tú mencionas, nos ayuda bastante el tener la visualización desde ese tipo de tableros, pero muy importante también si alguien va entrando ya existen tableros que se quiera meter esta parte para que pueda identificar de dónde está saliendo toda la información que puede identificarlo en caso de que en algún momento lo requiera, siempre es útil saber de dónde salen este tipo de logs porque a veces vemos muchos símbolos, códigos y no nos perdemos entre ellos. Ahora dando continuación a esta parte de la visibilidad tenemos estos otros servicios que los estaremos mostrando principalmente en consola. El primero de ellos es el de CloudTrail, también muy utilizado y bastante recomendado para dejarlo activo ya que nos va a estar registrando toda la actividad que generan nuestros usuarios, por ejemplo aquí hizo el registro de que hice un refresh de cuando creamos un secreto y básicamente aquí nos muestra información que podría llegar a ser de utilidad para los usuarios, por ejemplo mi nombre de usuario, qué tipo de rol es el que yo estoy utilizando, la IP, el sistema operativo que tengo, el navegador que estoy utilizando y un poco más acerca del evento que se realizó que en este caso fue una llamada a una API de AWS y todo fue para el Secret Manager, entonces esto nos ayudará para poder identificar si hay algún tema de vulnerabilidad, sabemos ya unos datos más específicos para poder darles seguimiento tal vez con otras herramientas o incluso si nosotros estuviéramos haciendo cierta actividad y alguna política nos está bloqueando, podríamos regresar a este apartado donde veremos el error de esta actividad y así sabríamos si nos está bloqueando por ejemplo las políticas de AAM o de alguna organización para poder gestionarlo de la mejor forma. Ahora continuaremos con este servicio que es el Security Hub, ya lo hemos mencionado también, este básicamente lo que hace es integrar todas las herramientas que tengas de seguridad dentro de este visualizador para que tengamos todo de la forma más centralizada posible. En este caso tenemos una consola que es únicamente para eventos, entonces no tenemos infraestructura levantada por lo cual no nos va a traer muchos hallazgos u observaciones, pero de este lado podríamos ver las observaciones que tenemos. También nos maneja diferentes hallazgos, por ejemplo aquí tenemos uno sobre AWS Config que tendría que estar habilitado para que el Security Hub tome datos de ahí y así nos entregue también más hallazgos. Aquí están las diferentes integraciones que es precisamente con lo que podemos conectar esta herramienta, como ven son bastantes, lo ideal es que todas las que tengamos nosotros habilitadas las tengamos aquí conectadas para que realmente se estemos haciendo uso de esta herramienta de la mejor forma. Ahora continuaremos también con el TrustAdvisor, este lo que hace, podría considerarse como un paso más allá, es hacer recomendaciones respecto a estos pilares que tenemos de este lado, por ejemplo la optimización de costos, el tema de rendimiento para la seguridad, si se fijan en estos los tengo en gris ya que no se cuenta con una licencia más avanzada, solamente está como lo más básico, pero ahí depende cada quien que revise hasta dónde quiere revisar o cuáles son los pilares que les gustaría estar mejorando. Continuaremos también con tolerancia, errores, cuotas de servicio y excelencia operativa, básicamente esta herramienta nos va a ayudar a mejorar estos aspectos y con esto terminaríamos nuestra parte práctica, entonces te cedo la palabra Andy.

Muy bien, muchas gracias Victoria y Víctor por la información que nos compartieron el día de hoy, si gustas Vicky me puedes apoyar a compartir de nuevo la presentación, por favor. Y bueno, antes de concluir, les queremos agradecer por la asistencia el día de hoy. Miki, ¿Le puedes dar la siguiente por favor, a la diapositiva? Bueno, gracias por asistir, acompañarnos el día de hoy y pues tener sobre todo un acercamiento sobre las buenas prácticas en la nube de AWS. Es evidente también que esta transformación en la nube no solo nos abre nuevas posibilidades, sino también que nos proporciona un entorno más ágil, seguro y escalable para las empresas. Aquí en el chat tenemos una pregunta, no sé si Victoria o Víctor nos pueden apoyar a responderla. Y Miguel Alcocer nos según su experiencia, ¿Nos recomendarían centralizar la autenticación tipo Active Directory u otras soluciones?

OK, aquí si me permiten directamente, por así decirlo, si ustedes ya manejan un tipo de directorio activo de Microsoft, si se puede estar centralizando lo que es el acceso a las cuentas por este lado en AWS. Pero nosotros, o sea, recomendamos si es un ambiente multicuentas de AWS, hacerlo directamente mediante Organizations y a través otro servicio que se llama Identity Center. Aquí básicamente se centralizaría lo que es el acceso a todas las cuentas y no estar accediendo uno por uno, ¿Vale? Pero de lo contrario, sea si en respuesta corta o sea con actividad directo y si se puede, pero nosotros recomendaríamos este mejor Identity.

De acuerdo, Muchas gracias Víctor. Y si alguien más tiene alguna duda o pregunta, con gusto la pueden poner en el chat y la responder. También les queremos otorgar una prueba de concepto de tres servicios de seguridad que elijan de los que estuvimos platicando en esta sesión. Y pues esta consultoría es válida del 17 de julio hasta el 27 de agosto de 2025. Bueno, nuevamente muchas gracias por acompañarnos el día de hoy. Vamos a estar atentos al chat. En caso de que alguien más quiera compartir alguna pregunta, les estaremos compartiendo este material a través del correo electrónico con el que se dieron de alta. Y pues también para que puedan volver a ver la grabación del día de hoy. También lo estaremos compartiendo a través de nuestras redes sociales. Y aquí les dejo una imagen con el equipo comercial. Con gusto si desean tener una consultoría, nosotros los podemos aportar. Muchas gracias por acompañarnos y esperamos tengan un excelente día.