Blog de Amazon Web Services (AWS)
Cómo Moeve protege cargas externas con PKI privada y AWS IAM Roles
Por Rayco Martínez, Jesús Monda e Ignacio Rodríguez.
En entornos empresariales complejos, la gestión de identidades ya no se limita al perímetro de AWS. Las organizaciones operan cargas de trabajo distribuidas entre entornos on-premises, edge, otras nubes y plataformas de terceros que necesitan interactuar con servicios AWS de forma segura y controlada.
Como parte de su estrategia de mejora continua de la seguridad, Moeve lleva años evolucionando los mecanismos utilizados por las cargas de trabajo para acceder a AWS. En escenarios donde el uso de credenciales programáticas era necesario, la organización implantó controles centralizados para su gestión, rotación y gobierno, tal y como se describe en el blog: «Gestión automática y segura de Access Keys a escala en AWS». Sin embargo, cuando se trata de integraciones machine-to-machine, el objetivo es avanzar hacia modelos que eliminen por completo la dependencia de credenciales persistentes.
En este contexto, Moeve, compañía energética global anteriormente conocida como Cepsa, ha adoptado AWS IAM Roles Anywhere como mecanismo para que las cargas de trabajo externas puedan autenticarse frente a AWS mediante certificados X.509 y obtener credenciales temporales, suprimiendo la necesidad de exponer mecanismos de acceso persistente ni extender el plano de identidad corporativo fuera de su dominio natural.
Este enfoque sustituye la confianza basada en secretos compartidos por un modelo fundamentado en certificados X.509 y una Infraestructura de Clave Pública (PKI – Public Key Infrastructure) privada, que pasa a convertirse en el elemento central del diseño. La identidad de la carga de trabajo deja de depender de credenciales estáticas y pasa a sustentarse en un certificado emitido por una Autoridad de Certificación (CA – Certificate Authority) de confianza.
Para ello, Moeve, en colaboración con Keepler, partner de la AWS Partner Network (APN), y AWS han diseñado una PKI privada basada en AWS Private Certificate Authority, estructurada en una jerarquía de autoridades de certificación e integrada con IAM Roles Anywhere mediante trust anchors, profiles y roles de AWS Identity and Access Management (IAM), todo ello bajo el modelo de gobernanza del Cloud Center of Excellence (CCoE). La separación entre CA raíz y CA subordinadas, así como el uso de mecanismos de revocación mediante Listas de Revocación de Certificados (CRL – Certificate Revocation List), forma parte de las prácticas base de esta arquitectura PKI.
Requisitos previos
Para implementar una solución similar a la descrita en este blog, se recomienda disponer de:
- Una organización multi-cuenta gestionada con AWS Organizations.
- Capacidad de despliegue centralizado mediante AWS CloudFormation StackSets.
- Una PKI privada desplegada sobre AWS Private Certificate Authority.
- Una jerarquía de certificación compuesta, al menos, por una CA raíz y una CA subordinada.
- Mecanismos de revocación definidos, por ejemplo, mediante CRL.
- Procedimientos para la generación de Solicitudes de Firma de Certificado (CSR – Certificate Signing Request) por parte de las cargas de trabajo consumidoras.
Además, es preferible tener nociones sobre:
- Conocimiento de AWS IAM, roles y políticas.
- Familiaridad con AWS IAM Roles Anywhere.
- Conocimientos operativos de Linux y Windows para integrar aws_signing_helper.
El reto de gestionar identidades fuera de AWS
Autenticar cargas de trabajo externas de forma segura plantea un reto distinto al de gestionar identidades nativas en AWS. En Moeve, este reto abarca desde aplicaciones on-premises hasta sistemas Windows y Linux desplegados fuera de la organización AWS, así como integraciones operadas desde otros entornos corporativos.
El objetivo del CCoE no era únicamente habilitar acceso técnico, sino hacerlo bajo un modelo gobernado donde la confianza estuviera centralizada, la identidad de la carga de trabajo fuera verificable y las credenciales emitidas por AWS fueran temporales y trazables.
IAM Roles Anywhere habilita este modelo, pero su adopción introduce un nuevo dominio de diseño: la gestión de la confianza criptográfica. Ya no basta con definir permisos IAM; es necesario decidir qué autoridades de certificación son válidas, cómo se emiten los certificados, cómo se revocan y cómo se gobierna esta confianza a escala organizativa.
El caso de uso se centra especialmente en comunicaciones machine-to-machine, donde no existe intervención interactiva de un usuario, y la carga de trabajo necesita obtener credenciales de forma automatizada, trazable y con permisos acotados.
Principios de diseño de la solución
Para abordar este modelo, el CCoE de Moeve definió un conjunto de principios orientados a garantizar seguridad, control y escalabilidad.
El primero es la separación de responsabilidades dentro de la PKI. La CA raíz se utiliza exclusivamente como ancla de confianza y solo firma autoridades subordinadas. La emisión de certificados de carga de trabajo se delega en CA subordinadas, evitando exponer operativamente la raíz. Este patrón se alinea con las buenas prácticas de AWS Private CA y de diseño de una jerarquía PKI privada, donde la raíz no debe emitir certificados directamente y la emisión operativa recae en autoridades subordinadas.
El segundo principio es la centralización de la confianza en el CCoE. La creación de la jerarquía PKI, la definición de políticas de emisión, la configuración de revocación y la publicación del trust anchor en AWS son responsabilidades del equipo central. Los equipos consumidores usan el servicio dentro de un marco definido, pero no administran la infraestructura de confianza.
El tercer principio es la separación explícita entre autenticación y autorización. El certificado X.509 se utiliza únicamente para autenticar la carga de trabajo frente a IAM Roles Anywhere. Los permisos efectivos siguen gestionándose mediante roles y políticas IAM, manteniendo consistencia con el modelo de autorización ya existente en la organización.
El cuarto principio es la custodia local de la clave privada. Cada consumidor genera localmente su par de claves y remite una CSR para su firma. De este modo, la clave privada nunca abandona el entorno de la carga de trabajo, reduciendo la superficie de exposición y simplificando el modelo de custodia.
El quinto principio es el control centralizado del acceso externo. Solo el CCoE puede crear profiles de IAM Roles Anywhere, lo que permite decidir de forma centralizada qué roles pueden asumirse desde fuera de la organización y bajo qué condiciones.
Por último, la solución se diseña para operar en entornos multi-cuenta, manteniendo presente que IAM Roles Anywhere es un servicio regional. Esto implica que los trust anchors, los profiles y las llamadas de autenticación deben alinearse con la región donde se despliega la solución.
Fundamentos de PKI en este modelo
Antes de entrar en la arquitectura, conviene detenerse en el papel que juega la PKI dentro de esta solución.
Una infraestructura de clave pública se basa en una jerarquía de confianza. En la parte superior se sitúa la CA raíz, que representa el máximo nivel de confianza y cuyo certificado es autofirmado. Esta autoridad no debe emitir certificados directamente a las cargas de trabajo. Por debajo se sitúan las CA subordinadas, encargadas de firmar los certificados operativos. Esta separación reduce el riesgo y aísla el componente más sensible de la jerarquía.
Cada carga de trabajo genera su propio par de claves y produce una CSR. La CA subordinada firma esa CSR y emite un certificado X.509. El resultado no es solo un certificado aislado, sino una identidad que puede validarse recorriendo la cadena de certificación hasta la CA raíz.
En este modelo también resulta esencial la revocación. Las CRL permiten invalidar certificados antes de su expiración, por ejemplo, ante el compromiso de una clave privada o la retirada de una carga de trabajo. En la base PKI de Moeve, la CRL se publica sobre Amazon S3, que actúa como repositorio central del estado de revocación de los certificados emitidos. Opcionalmente, puede exponerse mediante Amazon CloudFront cuando se requiere facilitar su acceso desde múltiples ubicaciones o consumidores externos.
La revocación debe analizarse con especial cuidado en arquitecturas machine-to-machine. La invalidación de un certificado afecta exclusivamente a la identidad asociada a dicho certificado y no al resto de certificados emitidos por la misma autoridad de certificación. Sin embargo, la revocación de una CA subordinada sí implicaría la pérdida de confianza sobre todos los certificados emitidos por esa autoridad, por lo que este tipo de operaciones deben evaluarse cuidadosamente.
Desde un punto de vista operativo, resulta fundamental mantener la trazabilidad entre certificados emitidos, cargas de trabajo consumidoras, perfiles de IAM Roles Anywhere y roles IAM asociados. Esta relación permite estimar el impacto de una revocación antes de ejecutarla, identificando qué integraciones, automatismos o procesos machine-to-machine podrían verse afectados y facilitando la planificación de renovaciones o sustituciones controladas.
En la solución de Moeve, este proceso adquiere una relevancia adicional debido a que IAM Roles Anywhere no actualiza automáticamente las CRL una vez configuradas en un trust anchor. Para mantener alineado el estado de confianza entre la PKI y AWS, el CCoE ha implementado un mecanismo basado en eventos mediante AWS Lambda que detecta las actualizaciones de la CRL y actualiza de forma automatizada los trust anchors desplegados en la organización.
Arquitectura de la solución
La solución se articula en cuatro dominios: el dominio de confianza, el dominio de identidad en AWS, el dominio organizativo y el dominio de consumo.
Ilustración 1. Arquitectura de la solución
1. Dominio de confianza: PKI privada gobernada por el CCoE
La base del modelo es una PKI privada desplegada sobre AWS Private Certificate Authority. Esta infraestructura se organiza jerárquicamente en dos niveles:
- Una CA raíz, utilizada exclusivamente como ancla de confianza y para firmar autoridades subordinadas.
- Una o varias CA subordinadas, responsables de firmar los certificados de las cargas de trabajo externas.
Esta separación no es solo técnica. También refleja un reparto organizativo de responsabilidades. La CA raíz se mantiene bajo controles más estrictos y con un uso muy reducido, mientras que las CA subordinadas soportan la operativa de emisión.
Desde el punto de vista de la carga de trabajo, el flujo no implica que el CCoE genere ni transfiera claves privadas. La carga de trabajo genera localmente su clave privada y su CSR, y el CCoE (o el flujo autorizado) firma esa CSR mediante la CA subordinada correspondiente.
2. Dominio de identidad: IAM Roles Anywhere
Sobre esta base de confianza se construye el modelo de identidad en AWS mediante IAM Roles Anywhere. La integración se apoya en tres elementos.
El primero es el trust anchor, que representa la autoridad de certificación que AWS acepta como confiable. En Moeve, el trust anchor se configura usando el cuerpo del certificado de la CA raíz, que actúa como ancla última de confianza dentro de la jerarquía.
El segundo es el profile, que define qué roles pueden ser asumidos, durante cuánto tiempo y bajo qué configuración. En Moeve, los profiles solo los crea el CCoE. Esto convierte al profile en un mecanismo de control organizativo, no solo técnico.
El tercero es el rol IAM, que representa la identidad final que asumirá la carga de trabajo autenticada. El certificado no concede permisos directamente; únicamente habilita la asunción del rol.
3. Dominio organizativo: despliegue centralizado con StackSets
Un aspecto clave de la arquitectura es que el trust anchor no se despliega manualmente cuenta a cuenta. Desde el CCoE se despliega mediante un StackSet organizativo, lo que permite publicar el recurso en toda la organización y exponer de forma uniforme el export TrustAnchorArn-PKI.
Este patrón aporta consistencia entre cuentas, control centralizado del trust anchor y simplificación en el despliegue de roles y profiles en cuentas consumidoras.
4. Dominio de consumo: cargas de trabajo externas
Las cargas de trabajo externas necesitan disponer de:
- Un certificado X.509 firmado por la CA subordinada.
- Su clave privada local, generada y custodiada por ellas mismas.
- La cadena de certificación correspondiente.
- Un mecanismo de integración con IAM Roles Anywhere, típicamente aws_signing_helper.
El flujo consiste en presentar el certificado a IAM Roles Anywhere, que valida la cadena de confianza frente al trust anchor configurado. Si la validación es correcta y el profile asociado lo permite, AWS emite credenciales temporales mediante AWS Security Token Service (AWS STS) para el rol IAM autorizado.
Despliegue de la solución
Una vez definida la arquitectura, el despliegue se aborda como la construcción progresiva de la cadena de confianza y su integración con IAM Roles Anywhere.
Ilustración 2. Diagrama de la PKI
1. Creación de la CA raíz
El primer paso es la creación de la CA raíz en AWS Private CA. Su finalidad es actuar como raíz de confianza y firmar las CA subordinadas. No se utiliza para emitir certificados de cargas de trabajo.
2. Creación y firma de la CA subordinada
Una vez creada la raíz, se despliega una CA subordinada y se firma con la CA raíz. A partir de ese momento, la cadena de confianza queda establecida y puede utilizarse para emitir certificados operativos.
3. Configuración de revocación y CRL
Como parte del despliegue de la PKI, se define también la configuración de revocación. En la solución de Moeve, la CRL se publica sobre S3 y puede exponerse mediante CloudFront para facilitar su consumo. Este punto es esencial porque el valor de la confianza no depende solo de emitir certificados, sino también de poder invalidarlos de forma controlada cuando sea necesario.
Sin embargo, es importante tener en cuenta que actualmente IAM Roles Anywhere no actualiza automáticamente las CRL una vez configurado el trust anchor. Esto implica que la revocación de un certificado en la PKI no se refleja de forma automática en los trust anchors existentes. Para resolver esta limitación, el CCoE ha implementado un mecanismo basado en eventos mediante el cual cada actualización de la CRL desencadena la ejecución de una función de Lambda centralizada. Esta función recorre la organización y actualiza los trust anchors desplegados mediante StackSets, asegurando que el estado de confianza en AWS se mantiene alineado con la PKI.
4. Firma de la CSR de las cargas de trabajo
Cuando una carga de trabajo necesita acceder a AWS a través de IAM Roles Anywhere, genera localmente su clave privada y construye una CSR (Certificate Signing Request). Esta solicitud es posteriormente validada y firmada por la CA subordinada conforme a las políticas definidas por el CCoE. Este modelo evita que el equipo central tenga acceso a claves privadas o que tenga que intercambiarlas con los equipos consumidores.
Este punto es especialmente relevante desde la perspectiva de seguridad: el certificado se emite centralmente, pero la clave privada permanece siempre bajo custodia de la carga de trabajo. De esta forma, la confianza se centraliza en la PKI gestionada por el CCoE sin comprometer la custodia de los materiales criptográficos utilizados por los consumidores.
El proceso completo se resume en los siguientes pasos:
- La carga de trabajo genera localmente su clave privada.
- La carga de trabajo genera una CSR que identifica la identidad que posteriormente utilizará IAM Roles Anywhere.
- La CSR se remite al CCoE para su validación y aprobación.
- La CA subordinada firma la CSR mediante AWS Private CA.
- Se entrega a la carga de trabajo el certificado X.509 emitido junto con la cadena de certificación.
- La carga de trabajo utiliza el certificado y su clave privada para autenticarse mediante IAM Roles Anywhere.
Por ejemplo, desde el lado de la carga de trabajo:
Posteriormente, desde el CCoE, la CSR puede firmarse utilizando AWS Private CA:
Tras la emisión, la carga de trabajo recibe el certificado firmado y la cadena de certificación correspondiente, manteniendo en todo momento la clave privada bajo su control. Este certificado será posteriormente utilizado por IAM Roles Anywhere para autenticar la identidad de la carga de trabajo y permitir la obtención de credenciales temporales de AWS.
5. Despliegue del trust anchor en toda la organización
Con la PKI ya operativa, el siguiente paso es integrar esta infraestructura de confianza con IAM Roles Anywhere. En Moeve, el CCoE despliega el trust anchor en toda la organización mediante el StackSet platform-child-trusted-anchor-pki. Este despliegue permite disponer del export TrustAnchorArn-PKI en todas las cuentas, facilitando que las plantillas de CloudFormation consumidoras puedan importar ese valor y reutilizarlo de forma consistente.
Además, este enfoque reduce el riesgo de que cada cuenta cree o configure sus propios trust anchors de forma independiente.
6. Creación de roles y profiles para el acceso externo
Una vez disponible el trust anchor, cada caso de uso se habilita mediante una plantilla de CloudFormation que crea el rol IAM y el profile de IAM Roles Anywhere.
En esta plantilla, el trust anchor se importa mediante el export organizativo y el rol define la política de confianza contra el servicio rolesanywhere.amazonaws.com, restringiendo además el acceso mediante atributos del certificado, como el Common Name (CN).
La siguiente plantilla de CloudFormation despliega los componentes necesarios para habilitar el acceso de una carga de trabajo externa mediante IAM Roles Anywhere. En primer lugar, crea una política gestionada con permisos sobre un bucket de S3. A continuación, crea un rol IAM cuya política de confianza permite exclusivamente su asunción por parte del servicio IAM Roles Anywhere, restringiendo además el acceso a certificados X.509 con un Common Name específico y procedentes de un trust anchor determinado. Finalmente, crea un profile de IAM Roles Anywhere que vincula el rol autorizado, define la duración máxima de la sesión y aplica políticas adicionales de control de acceso.
El resultado es un modelo donde los permisos efectivos quedan determinados por la intersección entre los permisos concedidos al rol IAM y las restricciones definidas en el profile de IAM Roles Anywhere, proporcionando una capa adicional de gobierno sobre el acceso externo.
AWSTemplateFormatVersion: '2010-09-09'
Description: >
IAM Roles Anywhere - Usa Trust Anchor importado via Export,
crea Role y Profile con CN en confianza
Parameters:
ProjectName:
Type: String
Default: roles-anywhere-demo
RoleName:
Type: String
Default: RolesAnywhereReadOnlyRole
ProfileName:
Type: String
Default: RolesAnywhereReadOnlyProfile
AllowedCommonName:
Type: String
Description: CN exacto del certificado X.509 que podra asumir el rol
Default: TuCN
SessionDurationSeconds:
Type: Number
Default: 28800
MinValue: 900
MaxValue: 43200
TrustAnchorExportName:
Type: String
Description: Nombre del Export que publica el TrustAnchorArn
Default: TrustAnchorArn-PKI
Resources:
S3BucketAccessPolicy:
Type: AWS::IAM::ManagedPolicy
Properties:
ManagedPolicyName: !Sub "${ProjectName}-s3-bucket-access"
PolicyDocument:
Version: "2012-10-17"
Statement:
- Sid: BucketLevel
Effect: Allow
Action:
- s3:ListBucket
- s3:GetBucketLocation
- s3:ListBucketMultipartUploads
Resource: "arn:aws:s3:::s3-bucket-access"
- Sid: ObjectLevel
Effect: Allow
Action:
- s3:GetObject
- s3:GetObjectAcl
- s3:GetObjectTagging
- s3:PutObject
- s3:PutObjectAcl
- s3:PutObjectTagging
- s3:DeleteObject
- s3:AbortMultipartUpload
- s3:ListMultipartUploadParts
Resource: "arn:aws:s3:::s3-bucket-access/*"
RolesAnywhereRole:
Type: AWS::IAM::Role
DependsOn:
- S3BucketAccessPolicy
Properties:
RoleName: !Ref RoleName
MaxSessionDuration: 28800
AssumeRolePolicyDocument:
Version: "2012-10-17"
Statement:
- Effect: Allow
Principal:
Service: rolesanywhere.amazonaws.com
Action:
- sts:AssumeRole
- sts:TagSession
- sts:SetSourceIdentity
Condition:
StringEquals:
aws:PrincipalTag/x509Subject/CN: !Ref AllowedCommonName
ArnEquals:
aws:SourceArn:
Fn::ImportValue: !Ref TrustAnchorExportName
ManagedPolicyArns:
- arn:aws:iam::aws:policy/ReadOnlyAccess
- !Ref S3BucketAccessPolicy
Profile:
Type: AWS::RolesAnywhere::Profile
DependsOn:
- RolesAnywhereRole
- S3BucketAccessPolicy
Properties:
Name: !Ref ProfileName
Enabled: true
DurationSeconds: !Ref SessionDurationSeconds
RoleArns:
- !GetAtt RolesAnywhereRole.Arn
AcceptRoleSessionName: true
ManagedPolicyArns:
- arn:aws:iam::aws:policy/ReadOnlyAccess
- !Ref S3BucketAccessPolicyEn este diseño conviene destacar dos consideraciones:
La primera es que las políticas que se asignan al rol IAM y al profile deben definirse cuidadosamente, ya que el profile actúa como una capa adicional de control sobre los permisos efectivos que podrán obtenerse a través de IAM Roles Anywhere.
La segunda es que el servicio es regional, por lo que los trust anchors, los profiles y las llamadas del helper deben estar alineados con la región donde se ha desplegado la configuración.
Uso de IAM Roles Anywhere en Windows
Desde el punto de vista de la carga de trabajo, el consumo del servicio puede estandarizarse mediante aws_signing_helper.
Requisitos previos en Windows
Es necesario disponer de:
- El certificado instalado en el almacén Personal (MY) del usuario actual.
- Un trust anchor.
- Un Amazon Resource Name (ARN) de profile.
- Un ARN de rol.
- El binario exe.
Selección del certificado por CN
Para verificar que el certificado está disponible en el almacén:
Para obtener credenciales temporales:
Este comando usa el certificado desde el almacén del usuario, firma la solicitud con la clave privada asociada y devuelve credenciales temporales en formato JSON compatible con credential_process.
Por defecto, el helper busca certificados en el almacén MY del usuario actual. Si el certificado se encuentra en otro almacén, puede indicarse explícitamente mediante --system-store-name. Es importante tener en cuenta que el asistente no accede a los certificados del equipo, sino a los del usuario. Por ejemplo:
Selección del certificado por número de serie
Para identificar el número de serie del certificado:
Para validar el certificado concreto:
Y para solicitar credenciales temporales:
Integración con la AWS CLI en Windows
La forma más práctica de integrar IAM Roles Anywhere con la interfaz de línea de comandos de AWS, AWS Command Line Interface (CLI), y los kits de desarrollo de software, AWS Software Development Kit (SDK), es mediante credential_process en ~/.aws/config:
Validación:
Uso de IAM Roles Anywhere en Linux
En Linux, el patrón es equivalente, aunque normalmente se trabaja con ficheros PEM.
Detectar la arquitectura
- x86_64 usa el binario X86_64.
- aarch64 usa el binario Aarch64.
Descargar el helper
Para x86_64 (conviene revisar cuál es la última versión disponible del helper):
Para aarch64 (conviene revisar cuál es la última versión disponible del helper):
Obtener credenciales temporales
En este flujo, la carga de trabajo presenta su certificado, su clave privada local, la cadena de certificación intermedia y los ARN del rol, el trust anchor y el profile. Si la validación es correcta, IAM Roles Anywhere devuelve credenciales temporales.
Integración con la AWS CLI en Linux
En ~/.aws/config:
Validación:
Operación y gobernanza de la solución
Una vez desplegada, la operación se centra en mantener el control sobre la confianza.
El primer aspecto es el ciclo de vida del certificado. La emisión, renovación, expiración y revocación deben formar parte del diseño desde el inicio. No se trata únicamente de emitir certificados válidos, sino de mantener trazabilidad sobre a qué carga de trabajo pertenecen, bajo qué condiciones fueron emitidos y cuándo deben dejar de ser aceptados.
El segundo aspecto es la revocación. En un modelo basado en certificados, la capacidad de invalidar rápidamente una identidad es crítica. La CRL publicada por la PKI permite responder ante incidentes como la exposición de una clave privada, la retirada de una carga de trabajo o un cambio de contexto de seguridad.
El tercer aspecto es la gobernanza del acceso externo. El hecho de que solo el CCoE despliegue el trust anchor organizativo y cree los profiles garantiza que el acceso desde fuera de AWS no se habilita de forma descentralizada. Este control es clave para mantener coherencia entre cuentas y evitar multiplicar puntos de entrada externos no gobernados.
Por último, la solución preserva el modelo IAM existente. Los permisos siguen estando definidos en los roles y políticas IAM, lo que permite aplicar el principio de mínimo privilegio, la segmentación por cuentas y el resto de controles organizativos ya establecidos.
Limpieza de recursos
Si has desplegado esta solución con fines de prueba, elimina los recursos creados para evitar costes recurrentes, especialmente los asociados a AWS Private Certificate Authority. Se recomienda seguir este orden:
- Elimina los profiles y roles IAM creados para cada caso de uso (por ejemplo, borrando los stacks de AWS CloudFormation correspondientes).
- Elimina el StackSet que publica el trust anchor organizativo y sus instancias de pila en las cuentas miembro.
- Revoca y elimina los certificados emitidos que ya no se necesiten y actualiza la CRL correspondiente.
- Deshabilita y elimina las CA subordinadas y, por último, la CA raíz en AWS Private CA.
- Vacía y elimina el bucket de S3 que aloja la CRL y, si procede, la distribución de CloudFront asociada.
Ten en cuenta que la eliminación de una CA en AWS Private CA está sujeta a un periodo de restauración configurable de 7 a 30 días (30 por defecto), planifícalo según tus necesidades.
Conclusiones
La combinación de una PKI privada con AWS IAM Roles Anywhere permite extender el modelo de identidad de Moeve más allá del perímetro nativo de AWS sin romper la gobernanza existente.
El valor de la solución no reside únicamente en habilitar acceso técnico desde cargas de trabajo externas, sino en introducir un modelo de confianza más sólido y gobernado. La identidad de la carga de trabajo pasa a estar vinculada a un certificado emitido bajo una jerarquía PKI controlada por el CCoE, mientras que la autorización sigue resolviéndose mediante roles IAM y políticas de mínimo privilegio.
Desde el punto de vista operativo, el modelo también refuerza la postura de seguridad. La autenticación pasa a basarse en criptografía en lugar de en secretos compartidos, las credenciales emitidas por AWS son temporales, la revocación puede integrarse en la operación diaria mediante CRL y cada acceso queda alineado con el modelo IAM ya existente. Esto evita crear un sistema paralelo de autorización y permite que la adopción de IAM Roles Anywhere encaje dentro del marco general de gobierno cloud de la organización.
La adopción de este patrón también ha aportado beneficios operacionales tangibles. La PKI corporativa utilizada como base de la solución permite gestionar de forma centralizada cientos de identidades de carga de trabajo mediante certificados X.509, proporcionando un modelo común de confianza, trazabilidad y revocación para escenarios machine-to-machine.
Además, la implantación de IAM Roles Anywhere ha permitido reducir significativamente la necesidad de utilizar credenciales programáticas persistentes en aquellos escenarios donde este modelo resulta aplicable. Este enfoque se ha convertido en el patrón recomendado para nuevas integraciones machine-to-machine, permitiendo avanzar progresivamente hacia un modelo basado en certificados X.509 y credenciales temporales emitidas bajo demanda, reduciendo la dependencia de Access Keys de larga duración y reforzando la seguridad mediante una confianza basada en criptografía.
Este enfoque representa una evolución natural respecto a modelos basados en credenciales programáticas. Cuando el caso de uso lo permite, IAM Roles Anywhere elimina la necesidad de distribuir y custodiar credenciales persistentes, reforzando la seguridad y simplificando su gobierno. Para aquellos escenarios donde siguen siendo necesarias credenciales programáticas, Moeve dispone de mecanismos específicos de gestión y control descritos en el blog Gestión automática y segura de Access Keys a escala en AWS.
Si tienes preguntas o comentarios sobre esta solución, no dudes en dejar un comentario en este blog.
Autores
 |
Rayco Martínez es Head of Cloud Governance / Cloud CoE en Moeve. Rayco es un arquitecto Cloud con más de 20 años de experiencia en la industria energética, especializado en gobernanza cloud, cumplimiento normativo y transformación digital. Su pasión reside en diseñar e implementar soluciones cloud escalables, seguras y eficientes que impulsen la innovación empresarial. |
 |
Jesús Monda es Platform Engineer y parte del Cloud CoE en Moeve. Jesús es ingeniero informático por la Universidad de Sevilla (US), especializado en el diseño, construcción y operación de infraestructuras escalables, seguras y eficientes sobre AWS. Desde el equipo del Cloud CoE contribuye a la definición de buenas prácticas, automatización y modelos de gobierno que impulsan una adopción cloud segura y estandarizada en la organización. |
 |
Ignacio Rodríguez García es Technical Account Manager en AWS. En su rol, Ignacio proporciona orientación técnica estratégica para ayudar a los clientes a planificar y construir soluciones utilizando las prácticas recomendadas de AWS. Posee un máster en Ingeniería por Télécom Paris y un título de Ingeniero de Telecomunicaciones por la Universidad Politécnica de Madrid (UPM).
|