Accounting on an AWS landing zone

Lo prometido es deuda y tras un primer artículo de introducción centrado en describir que es una landing zone en el ecosistema de AWS, es hora de profundizar en los distintos apartados allí presentados, y en este escrito le llega el turno al modelo de cuentas.

Sin más dilación, comenzamos.

AWS Organizations

Si algo quedó patente en el post introductorio al mundo de la landing zone, es que, en AWS, las cuentas son contenedores de recursos totalmente aislados que permiten garantizar una segregación de responsabilidades entre equipos, aplicar controles de seguridad personalizados o obtener una facturación individualizada por unidades de negocio, entre otros.

La gran cuestión que se planteaba era precisamente cómo organizar estas cuentas para obtener todos los beneficios descritos, y, tal y cómo deja entrever el título de la sección, la respuesta pasa por AWS Organizations.

La documentación oficial de Amazon describe AWS Organizations como un servicio de gestión de cuentas que permite consolidar múltiples cuentas de AWS en una organización y administrarla de forma centralizada, para satisfacer mejor las necesidades presupuestarias, de seguridad y de conformidad del negocio.

La siguiente imagen ilustra de forma brillante como funciona.

En el primer nivel se ubica el nodo raíz que contiene todas las cuentas de la organización. Si se aplica una política sobre él, esta es heredada de forma automática por todas las unidades organizativas y cuentas de la organización.

En el segundo nivel aparecen las unidades organizativas, que no son más que contenedores de cuentas u otras unidades organizativas. Se podría decir que se asemejan a los grupos de usuarios de IAM, sobre los que se aplican políticas.

Esto da lugar a una jerarquía similar a un árbol invertido, con el nodo raíz en la parte superior, las unidades organizativas a modo de ramas y las cuentas a modo de hojas. Por tanto, cuando se aplica una política sobre una unidad organizativa, esta es heredada de forma automática por todas las unidades organizativas y cuentas de la organización que cuelgan de ella.

Finalmente están las cuentas, que no son mas contenedores de recursos totalmente aislados, sobre las que también se pueden aplicar políticas, si bien la recomendación es realizarlo siempre a nivel de unidad organizativa.

Hablando de políticas, las políticas en AWS Organizations se denominan políticas de control de servicios (SCP), y si bien son similares a las políticas de IAM, se diferencian en que no conceden permisos, sino que determinan las políticas que están disponibles en las cuentas para ser aplicadas a los usuarios vía IAM. Por ejemplo, es posible establecer una SCP que prohibe el uso de DynamoDB para todas las cuentas que cuelgan de una determinada unidad organizativa.

Accounting model

La siguiente imagen ilustra el modelo de unidades organizativas y cuentas recomendadas para una landing zone de AWS corporativa.

Recordar que, tal y como se comentó en el artículo de introducción, se trata de una solución que busca plasmar un escenario de máximos purista basado en las propuestas/recomendaciones de AWS (no se busca reinventar la rueda ni mucho menos) , con una segregación de cuentas y responsabilidades que requieren un volumen de negocio que justifique un equipo detrás que lo mantenga. Si no es vuestro caso, una estructura de cuentas mas comedida puede ser la solución mas adecuada.

Dicho esto, un pequeño consejo, no os preocupéis si en un inicio el diseño os resulta algo abrumador, ya que su implementación puede ser llevada a cabo de forma progresiva. Es decir, no es necesario desplegar todo el árbol desde el día cero para poder comenzar a trabajar de forma óptima en la nube.

Security OU

Unidad organizativa fundacional, gestionada por el equipo de seguridad, que se divide en sub-unidades organizativas que representan los entornos de ejecución (Dev, Test, Pro), que a su vez contienen las cuentas encargadas de albergar aquellos recursos directamente relacionados con la seguridad.

Log archive account

Cuenta encargada de custodiar de forma centralizada, segura, duradera e inmutable, todos los logs generados a lo largo de todas las cuentas de la organización, como por ejemplo, los logs de acceso, auditoria, seguridad, aplicativos etc. Es decir, se trata de la fuente de la verdad que alberga todo lo ocurrido en la plataforma, sobre la que los equipos de seguridad y auditoria podrán realizar análisis forenses o de cumplimiento legal.

De cara garantizar la seguridad, durabilidad e inmutabilidad de los datos, todos los registros deben ser almacenados en un bucket S3 configurado, al menos, con políticas de acceso extremadamente limitadas, cifrado de datos en reposo mediante una clave SSE-S3, versionado de los objetos, object locking y multi-factor authentication para el borrado de los datos. Adicionalmente se recomienda configurar una política de gestión de vida que permita mover los objetos a una modalidad de almacenamiento mas barata, como S3 Glacier, pasado el tiempo oportuno.

En lo que a la cuenta específicamente se refiere, es extremadamente importante que no residan cargas de trabajo sobre ella, ya que existe el riesgo de que puedan alterar los datos o acceder a información confidencial. Es decir, no se trata de una cuenta de obervabilidad centralizada o sobre la que desplegar servicios de big data o machine learning.

Así, si alguna aplicación o herramienta requiere consumir datos de la misma, lo deberá realizar desde su propia cuenta, mediante un cross-account-role de solo lectura y sobre aquellos registros estrictamente necesarios.

Lo que si deben de estar desplegados, de cara a garantizar el cumplimiento de las medidas de seguridad establecidas por la organización, son los servicios AWS Security Hub, Amazon GuardDuty, AWS Config, AWS IAM Access Analyzer, Amazon Macie, AWS CloudTrail Organization Trails y Amazon EventBridge, con la administración delegada en la cuenta de Security Tooling, para garantizar que las medidas de seguridad van en consonancia con lo prescrito por el AWS Security Reference Architecture (AWS SRA).

Finalmente, señalar que el acceso a esta cuenta debe ser extremadamente limitado y que deben de saltar las alarmas oportunas cada vez que alguien inicie sesión en ella.

Security tooling account

Cuenta dedicada operar servicios de seguridad, monitorear cuentas de AWS y automatizar alertas y respuestas de seguridad de forma centralizada, mediante el uso de los siguientes servicios de AWS:

• AWS Security Hub: Servicio que brinda una vista integral del estado de seguridad de las cuentas de AWS y su cumplimiento con los estándares de seguridad y las mejores prácticas.
• Amazon GuardDuty: Servicio de detección de amenazas para monitorizar y proteger de manera continua las cuentas de AWS, cargas de trabajo y datos almacenados en Amazon S3. Para ello, analiza flujos continuos de metadatos que se generan a partir de la actividad de la cuenta y la red registrada en AWS CloudTrail Events, VPC flow logs y DNS logs.
• AWS Config: Servicio administrado que ofrece un inventario de los recursos de AWS, así como el historial de configuración y las notificaciones de los cambios en la configuración, para garantizar seguridad y gobernanza.
• AWS IAM Access Analyzer: Servicio que permite identificar los recursos de la organización y cuentas, como buckets de Amazon S3 o roles de IAM, compartidos con una entidad externas.
• Amazon Detective: Servicio de seguridad que facilita el análisis, la investigación y la rápida identificación de la causa raíz de posibles problemas de seguridad o actividades sospechosas. Para ello, recopila datos de forma automática a partir de los recursos de AWS y utiliza machine learning realizar investigaciones de seguridad más rápidas y eficientes.
• Amazon Macie: Servicio de privacidad y seguridad de datos totalmente administrado que utiliza el aprendizaje automático y la correspondencia de patrones para descubrir y proteger los datos confidenciales en AWS.
• AWS Firewall Manager: Servicio de administración de seguridad que permite la configuración y administración centralizadas de reglas de firewall en todas las cuentas y aplicaciones en AWS Organization.

Todos estos servicios requieren leer datos del resto de cuentas de AWS, por lo que se debe implementar un cross-account-role de solo lectura, únicamente sobre aquella información estrictamente necesaria.

Finalmente, señalar que el acceso a esta cuenta debe ser extremadamente limitado.

Security read-only access account

Cuenta dedicada a dar soporte a los procesos de auditoria e investigaciones de seguridad, cuando los logs centralizados o las herramientas de seguridad previamente descritas no puedan resolver la problemática planteada. Para ello, proporciona acceso en modo solo lectura al resto de cuentas, mediante un cross-account-role.

En el modelo de referencia previo había una única cuenta de seguridad, pero la última recomendación es hacer una división en read-only y break-glass.

Al igual que en la cuenta de log archive, no deben residir cargas de trabajo sobre ella y dado que no se ingestan datos de otras cuentas, no puede haber aplicaciones o herramientas que consuman datos de la misma mediante un cross-account-role.

Lo que si deben de estar desplegados, de cara a garantizar el cumplimiento de las medidas de seguridad establecidas por la organización, son los servicios AWS Security Hub, Amazon GuardDuty, AWS Config, AWS IAM Access Analyzer, Amazon Macie, AWS CloudTrail Organization Trails y Amazon EventBridge, con la administración delegada en la cuenta de Security Tooling, para garantizar que las medidas de seguridad van en consonancia con lo prescrito por el AWS Security Reference Architecture (AWS SRA).

Finalmente, señalar que el acceso a esta cuenta debe ser limitado, con permisos únicamente para los miembros del equipo de seguridad.

Security break-glass account

Cuenta de emergencia para dar respuesta a incidentes de seguridad, en aquellos casos en los que los mecanismos de acceso estándar no estén disponibles. Es un claro símil al martillo rojo que se puede encontrar en cualquier autobús para romper la ventana durante una evacuación de emergencia, cuando las puertas normales no son accesibles. Para ello, proporciona acceso en modo administrador al resto de cuentas, mediante un cross-account-role.

Dado que su uso queda reservado a aquellos casos en los que los mecanismos de acceso estándar no estén disponibles, y suponiendo que el método por defecto es un AWS SSO integrado con un Active Directory, ya sea on-premise o en la propia nube, se recomienda disponer de un usuario IAM de acceso correctamente custodiado.

Al igual que en la cuenta de log archive, no deben residir cargas de trabajo sobre ella y dado que no se ingestan datos de otras cuentas, no puede haber aplicaciones o herramientas que consuman datos de la misma mediante un cross-account-role. Ahora bien, si para resolver el incidente se requiere algún tipo de aplicativo, este podrá ser instalado de forma extraordinaria y temporal hasta que el problema sea subsanado.

Lo que si deben de estar desplegados, de cara a garantizar el cumplimiento de las medidas de seguridad establecidas por la organización, son los servicios AWS Security Hub, Amazon GuardDuty, AWS Config, AWS IAM Access Analyzer, Amazon Macie, AWS CloudTrail Organization Trails y Amazon EventBridge, con la administración delegada en la cuenta de Security Tooling, para garantizar que las medidas de seguridad van en consonancia con lo prescrito por el AWS Security Reference Architecture (AWS SRA).

Finalmente, señalar que lo ideal es que esta cuenta no sea utilizada nunca, pero en caso de que sea necesario, el acceso debe estar extremadamente limitado y siempre de forma temporal, con una autorización previa de dos o mas aprobadores. Sobra decir que si alguien trata de acceder a ella, debe saltar la alarma correspondiente.

Infrastructure OU

Unidad organizativa fundacional, gestionada por el equipo de infraestructura, que se divide en sub-unidades organizativas que representan los entornos de ejecución (Dev, Test, Pro), que a su vez contienen las cuentas encargadas de albergar aquellos recursos o servicios compartidos entre todas las cuentas.

Network account

Cuenta que centraliza la entrada, inspección, enrutado y salida de todo el tráfico de red mediante elementos de infraestructura como el WAF, Firewall, Transit Gateway, Route53, VPC Endpoint etc. En el artículo dedicado al networking se describirá en detalle cada una de las áreas y casos de uso, con servicios de AWS y flujos de red pertinentes.

De cara a garantizar el cumplimiento de las medidas de seguridad establecidas por la organización, se deben desplegar los servicios AWS Security Hub, Amazon GuardDuty, AWS Config, AWS IAM Access Analyzer, Amazon Macie, AWS CloudTrail Organization Trails y Amazon EventBridge, con la administración delegada en la cuenta de Security Tooling, para garantizar que las medidas de seguridad van en consonancia con lo prescrito por el AWS Security Reference Architecture (AWS SRA).

Señalar que el acceso a esta cuenta debe ser limitado, con permisos únicamente para los miembros del equipo de networking.

Shared services account

Cuenta que alberga aquellos servicios de infraestructura comunes empleados por las distintas aplicaciones, equipos o cuentas de AWS para desempeñar su trabajo.

Lo primero de todo, esta NO es la cuenta sobre la reside el código fuente o se orquestan los despliegues de las aplicaciones o infraestructura, para eso están las cuentas de Deployment.

Típicamente aquí se ubica la gestión de los usuarios mediante IAM o AWS Single Sign-On, un servicio de inicio de sesión único (SSO) gestionado que facilita la administración centralizada del acceso SSO a todas las cuentas de AWS y aplicaciones en la nube. En otras palabras, permite gestionar los usuarios, grupos y roles por cuenta de AWS, pudiendo integrarse con el directorio activo corporativo. No os preocupéis, en el artículo dedicado al login se describirá en detalle como implementar esta solución.

Aqui tambien se aloja el AWS System Manager, servicio que centraliza datos operativos de diferentes servicios de AWS, con lo que posteriormente automatizar tareas sobre los recursos. En concreto, permite crear grupos lógicos de recursos, ver su actividad reciente de API, cambios en la configuración, sus notificaciones relacionadas, alertas operativas, inventario de software y parches aplicados, pudiendo actuar sobre ellos en función de las necesidades operativas.

De cara a garantizar el cumplimiento de las medidas de seguridad establecidas por la organización, también se deben desplegar los servicios AWS Security Hub, Amazon GuardDuty, AWS Config, AWS IAM Access Analyzer, Amazon Macie, AWS CloudTrail Organization Trails y Amazon EventBridge, con la administración delegada en la cuenta de Security Tooling, para garantizar que las medidas de seguridad van en consonancia con lo prescrito por el AWS Security Reference Architecture (AWS SRA).

Finalmente, señalar que el acceso a esta cuenta debe ser limitado, con permisos únicamente para los miembros del equipo de infraestructura.

Sandbox OU

Unidad organizativa que contiene cuentas de carácter temporal en la que los desarrolladores son libres de explorar y experimentar con los servicios de AWS.

Lo primero de todo y por motivos evidentes, las cuentas no se agrupan en unidades organizativas qué identifiquen el entorno, es un árbol plano de un único nivel. Eso sí, las cuentas pueden ser tanto de carácter individual, es decir, una por desarrollador, como de carácter grupal, es decir, una por equipo que es compartida entre los distintos miembros del mismo.

Por motivos de seguridad, deben estar totalmente desconectadas de las redes y servicios internos corporativos, y que dispongan de un limite de gasto establecido. También se recomienda establecer un SCP que delimite el tipo de instancias a desplegar, por ejemplo, prohibiendo todas aquellas instancias superiores a las “médium”.

Precisamente de cara a reducir los costes, o mas bien, para evitar que se disparen de forma accidental, se suelen implementar procedimientos automatizados para purgar periódicamente los recursos creados en estos entornos. Cloud Nuke, la CLI de Gruntwork(Terragrunt, Terratest…) para eliminar todos los recursos de una cuenta de AWS, es una buena herramienta para esto.

Finalmente, de cara a garantizar el cumplimiento de las medidas de seguridad establecidas por la organización, se deben desplegar los servicios AWS Security Hub, Amazon GuardDuty, AWS Config, AWS IAM Access Analyzer, Amazon Macie, AWS CloudTrail Organization Trails y Amazon EventBridge, con la administración delegada en la cuenta de Security Tooling, para garantizar que las medidas de seguridad van en consonancia con lo prescrito por el AWS Security Reference Architecture (AWS SRA).

Workloads OU

Unidad organizativa que se divide en sub-unidades organizativas que representan los entornos de ejecución (Dev, Test, Pro), que a su vez contienen las cuentas encargadas de albergar las cargas de trabajo o aplicativos de la organización, por proyecto.

Lo primero de todo, estas cuentas tampoco son las que albergan el código fuente o orquestan los despliegues de las aplicaciones o infraestructura, para eso están las cuentas de Deployment.

Como no podía ser de otra forma, se encuentran conectadas a la cuenta de networking centralizada del entorno correspondiente, para gestionar así el tráfico entrante y saliente, de forma segura.

De cara a garantizar el cumplimiento de las medidas de seguridad establecidas por la organización, se deben desplegar los servicios AWS Security Hub, Amazon GuardDuty, AWS Config, AWS IAM Access Analyzer, Amazon Macie, AWS CloudTrail Organization Trails y Amazon EventBridge, con la administración delegada en la cuenta de Security Tooling, para garantizar que las medidas de seguridad van en consonancia con lo prescrito por el AWS Security Reference Architecture (AWS SRA).

Finalmente, señalar que el acceso a esta cuenta debe estar muy limitado en los entornos productivos, en los debe saltar la alarma correspondiente si alguien trata de acceder a ellos. En los entornos de desarrollo se puede conceder permisos limitados a los desarrolladores, pero nunca con la capacidad de crear, modificar o eliminar ni infraestructura ni aplicaciones.

Policy Staging OU

Unidad organizativa que contiene las cuentas sobre las que el equipo de administración de políticas puede probar los cambios de forma seguras antes de ser aplicados en los entornos reales.

Tal y como se observa en la imagen, replica internamente la estructura de unidades organizativas, para que las pruebas puedan llevarse a cabo de la forma mas fidedigna posible.

Teniendo en cuenta el propósito para el que han sido concedidas, deben estar totalmente desconectadas de las redes y servicios internos corporativos y no deben residir cargas de trabajo sobre ella. Por tanto, dado que no se ingestan datos de otras cuentas, tampoco puede haber aplicaciones o herramientas que consuman datos de la misma mediante un cross-account-role.

Señalar que el acceso a esta cuenta debe ser limitado, con permisos únicamente para los miembros del equipo de seguridad encargados de implementar las políticas de seguridad.

Suspended OU

Unidad organizativa que se emplea como area de retention para aquellas cuentas suspendidas de forma temporal o permanente.

La razón de ser principal de esta unidad organizativa es que AWS no elimina fisicamente una cuenta hasta 30 días después de haberlo solicitado. Por lo tanto, se recomienda trasladarla a esta OU, con un tag que indique su precedencia (Una vez migrada no es posible conocer su origen sin analizar los logs de Cloud Trail), y añadirle una política que elimine cualquier posible acción sobre ellas, para asegurarse que no son reactivadas sin el consentimiento pertinente.

Como no podía ser de otra forma, el acceso a estas cuentas debe ser extremadamente limitado y que deben de saltar las alarmas oportunas cada vez que alguien inicie sesión en ella.

Individual Business Users OU

Unidad organizativa que contiene cuentas de carácter temporal para aquellos equipos y usuarios que, necesitan acceso para administrar directamente mis recursos de AWS, fuera del contexto de los proyectos. Se asemeja a las cuentas de Sandbox de los desarrolladores pero para la gente de negocio.

Al igual que en la OU de Sandbox, las cuentas no se agrupan en unidades organizativas qué identifiquen el entorno, es un árbol plano de un único nivel. Eso sí, las cuentas pueden ser tanto de carácter individual como de carácter grupal.

En lo que a la seguridad se refiere, más de lo mismo. Las cuentas deben estar totalmente desconectadas de las redes y servicios internos corporativos, y que dispongan de un limite de gasto establecido. También se recomienda establecer un SCP que delimite el tipo de instancias a desplegar, por ejemplo, prohibiendo todas aquellas instancias superiores a las “médium”.

De cara a garantizar el cumplimiento de las medidas de seguridad establecidas por la organización, también se deben desplegar los servicios AWS Security Hub, Amazon GuardDuty, AWS Config, AWS IAM Access Analyzer, Amazon Macie, AWS CloudTrail Organization Trails y Amazon EventBridge, con la administración delegada en la cuenta de Security Tooling, para garantizar que las medidas de seguridad van en consonancia con lo prescrito por el AWS Security Reference Architecture (AWS SRA).

Finalmente, se recomienda analizar caso a caso la creación de estas cuentas, siendo mas restrictivos que las de los desarrolladores.

Exceptions OU

Unidad organizativa que alberga una serie de cuentas excepcionales sobre las que no aplicar políticas de seguridad, para aquellos casos excepcionales en los que se requiere probar algo fuera del marco de seguridad establecido por la organización.

De nuevo, al igual que en la OU de Sandbox, las cuentas no se agrupan en unidades organizativas qué identifiquen el entorno, es un árbol plano de un único nivel. Eso sí, las cuentas pueden ser tanto de carácter individual como de carácter grupal.

En lo que a la seguridad se refiere, más de lo mismo. Las cuentas deben estar totalmente desconectadas de las redes y servicios internos corporativos, y que dispongan de un limite de gasto establecido. También se recomienda establecer un SCP que delimite el tipo de instancias a desplegar, por ejemplo, prohibiendo todas aquellas instancias superiores a las “médium”.

Precisamente de cara a reducir los costes, o mas bien, para evitar que se disparen de forma accidental, se suelen implementar procedimientos automatizados para purgar periódicamente los recursos creados en estos entornos. Cloud Nuke, la CLI de Gruntwork(Terragrunt, Terratest…) para eliminar todos los recursos de una cuenta de AWS, es una buena herramienta para esto.

De cara a garantizar el cumplimiento de las medidas de seguridad establecidas por la organización, también se deben desplegar los servicios AWS Security Hub, Amazon GuardDuty, AWS Config, AWS IAM Access Analyzer, Amazon Macie, AWS CloudTrail Organization Trails y Amazon EventBridge, con la administración delegada en la cuenta de Security Tooling, para garantizar que las medidas de seguridad van en consonancia con lo prescrito por el AWS Security Reference Architecture (AWS SRA).

Finalmente señalar qué debería haber un limitadísimo número de cuentas, si es que las hubiera, y que su concesión debe pasar por un estricto proceso de aprobación.

Deployments OU

Unidad organizativa, gestionada por el equipo de DevOps, que se divide en sub-unidades organizativas que representan los entornos de ejecución (Dev, Test, Pro), que a su vez contienen las cuentas encargadas de realizar los despliegues de los aplicativos e infraestructura en las cuentas workload.

Lo primero de todo, sí, aquí es donde su ubican el código fuente y ficheros de despliegue referentes a las aplicaciones y la infraestructura.

Tal y como se mencionaba previamente, estos despliegues deben llevarse a cabo de forma automatizada mediante pipelines de CI/CD, logrando así erradicar aquellos errores derivados de los pasos manuales.

Así, estos pipelines deben, al menos, validar la calidad del código, garantizar el cumplimiento de las medidas de seguridad, crear y publicar los artefactos, promocionarlos y, en última instancia, desplegarlos en el entorno de producción. Es precisamente la criticidad de estas acciones, lo que impulsa una segregación de cuentas entre DevOps y Workloads, con sus políticas de seguridad diferenciadas.

Si bien cualquier herramienta es valida para ello, AWS dispone de un set de servicios cuanto menos a tener en cuenta:

• AWS CodeArtifact: Servicio de repositorio de artefactos compatible con Maven y Gradle (Java), npm y yarn (JavaScript), pip y twine (Python) o NuGet (.NET), para almacenar, publicar y compartir de forma segura paquetes de software utilizados en los procesos de desarrollo de software.
• AWS CodeCommit: Servicio de control de código fuente seguro, gestionado y con alta escalabilidad que facilita la colaboración de los equipos en el código. 
• AWS CodeBuild: Servicio de integración continua gestionado en la nube con el que compilar el código fuente, ejecutar pruebas y producir paquetes de software listos para su despliegue.
• AWS CodeDeploy: Servicio que automatiza las implementaciones de código en cualquier instancia, incluidas las instancias de Amazon EC2 y aquellas ejecutadas localmente.
• AWS CodePipeline: Servicio de entrega continua que permite modelar, visualizar y automatizar los pasos necesarios para lanzar software.

De cara a garantizar el cumplimiento de las medidas de seguridad establecidas por la organización, también se deben desplegar los servicios AWS Security Hub, Amazon GuardDuty, AWS Config, AWS IAM Access Analyzer, Amazon Macie, AWS CloudTrail Organization Trails y Amazon EventBridge, con la administración delegada en la cuenta de Security Tooling, para garantizar que las medidas de seguridad van en consonancia con lo prescrito por el AWS Security Reference Architecture (AWS SRA).

Finalmente, señalar que el acceso a esta cuenta debe ser limitado, con permisos únicamente para los miembros del equipo de de DevOps.

Conclusiones

En conclusión, se ha descrito como organizar las cuentas en 9 unidades organizativas, describiendo el propósito y servicios a desplegar en cada una de ellas, siguiendo al pie de la letra el marco de referencia definido por el AWS Well-Architected Tool, garantizando así un entorno multi-cuenta de AWS escalable y seguro.

Como siempre, estad atentos a futuros artículos en los que se detallarán en profundidad los diseños técnicos pendientes de networking, logging centralizado o single sign-on, entre otros.