¿Qué característica de IAM le permite otorgar acceso temporal y limitado a los recursos de AWS a usuarios que no tienen cuentas de AWS, como contratistas externos?
Elige la mejor respuesta.
Respuesta correcta
Los IAM Roles con cross-account access permiten otorgar permisos temporales y limitados a usuarios de otra cuenta de AWS o proveedores de identidad externos (por ejemplo, contratistas externos) sin crear usuarios de IAM para ellos. El rol se asume a través de AWS Security Token Service (STS), el cual emite credenciales temporales que caducan después de una duración definida, garantizando el acceso de menor privilegio.
IAM Groups
Los IAM Groups son contenedores lógicos utilizados para adjuntar políticas de permisos a múltiples usuarios de IAM a la vez dentro de la misma cuenta de AWS. Son una conveniencia administrativa para gestionar los permisos de identidades que ya ha creado como usuarios de IAM, pero no tienen la capacidad de autenticar a nadie; los grupos no son principales y no poseen credenciales. Dado que el grupo es completamente interno a su cuenta y opera sobre usuarios de IAM existentes, no se puede utilizar para otorgar acceso a una parte externa a su cuenta de AWS; no hay forma de agregar una entidad externa a un grupo de IAM sin crear primero un usuario de IAM permanente para dicha entidad.
IAM Roles con cross-account access
Los IAM Roles con cross-account access son el enfoque correcto porque crean una relación de confianza temporal y delimitada con una identidad externa. Usted configura la política de confianza del rol para permitir que una cuenta específica de AWS externa o un proveedor de identidad federado invoque la operación AssumeRole de Security Token Service (STS), lo cual proporciona a cambio credenciales de corta duración. La política de permisos del rol define exactamente a qué acciones y recursos puede acceder la parte externa, por lo que aplica controles de menor privilegio y grano fino sin crear nunca un usuario de IAM permanente para dicha parte. Debido a que las credenciales caducan automáticamente (normalmente en el plazo de una hora), este diseño reduce el riesgo y es el patrón estándar para otorgar acceso controlado a colaboradores o aplicaciones externas.
IAM password policies
Las IAM password policies son reglas locales de la cuenta que imponen restricciones de complejidad de contraseña, longitud mínima, rotación y reutilización para los usuarios de IAM ya definidos en su cuenta. Se aplican únicamente a las credenciales que existen dentro de su propio directorio de identidades, por lo que una parte externa no tiene ninguna contraseña que deba ser regida por ellas. En lugar de crear cualquier concesión de acceso, estas políticas simplemente limitan cómo los usuarios internos mantienen sus propios secretos de inicio de sesión, lo que las hace irrelevantes para otorgar acceso a alguien externo a su cuenta de AWS.
Service Control Policies (SCPs)
Las Service Control Policies (SCPs) son características de AWS Organizations que actúan como barreras de protección de permisos sobre todas las cuentas de la organización. Son restrictivas, no permisivas: una SCP puede denegar o limitar lo que los principales en una cuenta miembro pueden hacer, pero nunca otorga nuevos permisos ni permite que exista un principal. Fundamentalmente, las SCP se aplican únicamente a los principales ya presentes dentro de las cuentas miembro, por lo que no pueden proporcionar un mecanismo para que una parte externa obtenga acceso autenticado; solo reducen los permisos efectivos de las identidades que la cuenta ya posee.
El concepto subyacente que evalúa esta pregunta es la federación de identidades y el acceso delegado en AWS. Los roles de IAM no son la única forma de otorgar acceso entre cuentas; AWS también admite políticas basadas en recursos en servicios como S3 y SNS que se pueden compartir directamente con una cuenta externa, pero los roles son el mecanismo de propósito general porque la política de confianza puede especificar quién puede asumir el rol y la política de permisos especifica qué pueden hacer una vez asumido. Una idea errónea común es que se debe crear un usuario de IAM para cada colaborador externo; de hecho, los roles entre cuentas eliminan las credenciales de larga duración y el riesgo de claves de acceso estáticas filtradas. La sutileza clave es la distinción entre la autenticación (probar quién es usted, gestionada por el proveedor de identidad externo o la cuenta) y la autorización (decidir qué puede hacer, gestionada por las políticas del rol). Para los usuarios externos que no se encuentran en ninguna cuenta específica de AWS, puede ampliar el mismo patrón basado en roles utilizando la federación SAML o OIDC, donde la política de confianza autentica al proveedor de identidad externo en lugar de a una cuenta de AWS. Este diseño es fundamental para los principios de seguridad de AWS Well-Architected de menor privilegio y credenciales temporales, y es la razón por la cual los roles entre cuentas son la respuesta recomendada por encima de cualquier credencial permanente o política organizacional.
Sobre estas preguntas de práctica
Esta es una de las preguntas de práctica originales de CLF-C02 de Courseiva, escrita para aprender y nunca copiada de exámenes reales ni de dumps.
Traducida del original en inglés con IA y revisada para comprobar el sentido. Los códigos de examen, los comandos y los nombres de productos se mantienen tal como aparecen en el examen.