Last updated
Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE)
En AWS hay una cuenta raíz, que es el contenedor principal para todas las cuentas de tu organización. Sin embargo, no necesitas usar esa cuenta para desplegar recursos, puedes crear otras cuentas para separar diferentes infraestructuras de AWS entre ellas.
Esto es muy interesante desde un punto de vista de seguridad, ya que una cuenta no podrá acceder a los recursos de otra cuenta (excepto si se crean puentes específicamente), así que de esta manera puedes crear límites entre los despliegues.
Por lo tanto, hay dos tipos de cuentas en una organización (estamos hablando de cuentas de AWS y no de cuentas de usuario): una única cuenta que se designa como la cuenta de gestión, y una o más cuentas miembro.
La cuenta de gestión (la cuenta raíz) es la cuenta que usas para crear la organización. Desde la cuenta de gestión de la organización, puedes hacer lo siguiente:
Crear cuentas en la organización
Invitar a otras cuentas existentes a la organización
Eliminar cuentas de la organización
Gestionar invitaciones
Aplicar políticas a entidades (raíces, OUs o cuentas) dentro de la organización
Habilitar la integración con servicios de AWS compatibles para proporcionar funcionalidad de servicio en todas las cuentas de la organización.
Es posible iniciar sesión como el usuario raíz usando el correo electrónico y la contraseña utilizados para crear esta cuenta raíz/organización.
La cuenta de gestión tiene las responsabilidades de una cuenta pagadora y es responsable de pagar todos los cargos que son acumulados por las cuentas miembro. No puedes cambiar la cuenta de gestión de una organización.
Las cuentas miembro constituyen el resto de las cuentas en una organización. Una cuenta puede ser miembro de solo una organización a la vez. Puedes adjuntar una política a una cuenta para aplicar controles solo a esa cuenta.
Las cuentas miembro deben usar una dirección de correo electrónico válida y pueden tener un nombre, en general no podrán gestionar la facturación (pero podrían recibir acceso a ella).
Las cuentas pueden agruparse en Unidades de Organización (OU). De esta manera, puedes crear políticas para la Unidad de Organización que se van a aplicar a todas las cuentas hijas. Ten en cuenta que una OU puede tener otras OUs como hijas.
Una política de control de servicio (SCP) es una política que especifica los servicios y acciones que los usuarios y roles pueden usar en las cuentas que la SCP afecta. Las SCP son similares a las políticas de permisos de IAM excepto que no otorgan ningún permiso. En cambio, las SCP especifican los permisos máximos para una organización, unidad organizativa (OU) o cuenta. Cuando adjuntas una SCP a la raíz de tu organización o a una OU, la SCP limita los permisos para las entidades en las cuentas miembros.
Esta es la ÚNICA forma en que incluso el usuario raíz puede ser detenido de hacer algo. Por ejemplo, podría usarse para evitar que los usuarios deshabiliten CloudTrail o eliminen copias de seguridad. La única forma de eludir esto es comprometer también la cuenta maestra que configura las SCP (la cuenta maestra no puede ser bloqueada).
Ten en cuenta que las SCP solo restringen a los principales en la cuenta, por lo que otras cuentas no se ven afectadas. Esto significa que tener una SCP que niegue s3:GetObject no detendrá a las personas de acceder a un bucket S3 público en tu cuenta.
Ejemplos de SCP:
Negar completamente la cuenta raíz
Solo permitir regiones específicas
Solo permitir servicios en la lista blanca
Negar que GuardDuty, CloudTrail y S3 Public Block Access sean
deshabilitados
Negar que los roles de seguridad/respuesta a incidentes sean eliminados o
modificados.
Negar que las copias de seguridad sean eliminadas.
Negar la creación de usuarios IAM y claves de acceso
Encuentra ejemplos JSON en https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html
Amazon Resource Name es el nombre único que tiene cada recurso dentro de AWS, se compone así:
Note que hay 4 particiones en AWS pero solo 3 formas de llamarlas:
AWS Standard: aws
AWS China: aws-cn
AWS US public Internet (GovCloud): aws-us-gov
AWS Secret (US Classified): aws
IAM es el servicio que te permitirá gestionar Autenticación, Autorización y Control de Acceso dentro de tu cuenta de AWS.
Autenticación - Proceso de definir una identidad y la verificación de esa identidad. Este proceso se puede subdividir en: Identificación y verificación.
Autorización - Determina a qué puede acceder una identidad dentro de un sistema una vez que ha sido autenticada.
Control de Acceso - El método y proceso de cómo se concede acceso a un recurso seguro.
IAM se puede definir por su capacidad para gestionar, controlar y gobernar los mecanismos de autenticación, autorización y control de acceso de identidades a tus recursos dentro de tu cuenta de AWS.
Cuando creas por primera vez una cuenta de Amazon Web Services (AWS), comienzas con una única identidad de inicio de sesión que tiene acceso completo a todos los servicios y recursos de AWS en la cuenta. Este es el usuario raíz de la cuenta de AWS y se accede iniciando sesión con la dirección de correo electrónico y la contraseña que usaste para crear la cuenta.
Ten en cuenta que un nuevo usuario administrador tendrá menos permisos que el usuario raíz.
Desde el punto de vista de la seguridad, se recomienda crear otros usuarios y evitar usar este.
Un usuario de IAM es una entidad que creas en AWS para representar a la persona o aplicación que lo utiliza para interactuar con AWS. Un usuario en AWS consiste en un nombre y credenciales (contraseña y hasta dos claves de acceso).
Cuando creas un usuario de IAM, le otorgas permisos haciéndolo miembro de un grupo de usuarios que tiene políticas de permisos apropiadas adjuntas (recomendado), o adjuntando políticas directamente al usuario.
Los usuarios pueden tener MFA habilitado para iniciar sesión a través de la consola. Los tokens API de los usuarios con MFA habilitado no están protegidos por MFA. Si deseas restringir el acceso de las claves API de un usuario usando MFA, necesitas indicar en la política que para realizar ciertas acciones se necesita que MFA esté presente (ejemplo aquí).
ID de clave de acceso: 20 caracteres alfanuméricos aleatorios en mayúsculas como AKHDNAPO86BSHKDIRYT
ID de clave de acceso secreta: 40 caracteres aleatorios en mayúsculas y minúsculas: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (No es posible recuperar IDs de claves de acceso secretas perdidas).
Siempre que necesites cambiar la clave de acceso, este es el proceso que debes seguir: Crear una nueva clave de acceso -> Aplicar la nueva clave al sistema/aplicación -> marcar la original como inactiva -> Probar y verificar que la nueva clave de acceso funciona -> Eliminar la antigua clave de acceso
Se utiliza para crear un factor adicional para la autenticación además de tus métodos existentes, como la contraseña, creando así un nivel de autenticación multifactor. Puedes usar una aplicación virtual gratuita o un dispositivo físico. Puedes usar aplicaciones como Google Authenticator de forma gratuita para activar un MFA en AWS.
Las políticas con condiciones de MFA se pueden adjuntar a lo siguiente:
Un usuario o grupo de IAM
Un recurso como un bucket de Amazon S3, cola de Amazon SQS o tema de Amazon SNS
La política de confianza de un rol de IAM que puede ser asumido por un usuario
Si deseas acceder a través de CLI a un recurso que verifica MFA, necesitas llamar a GetSessionToken. Eso te dará un token con información sobre MFA.
Ten en cuenta que las credenciales de AssumeRole no contienen esta información.
Como se indica aquí, hay muchos casos diferentes en los que MFA no se puede usar.
Un grupo de usuarios de IAM es una forma de adjuntar políticas a múltiples usuarios a la vez, lo que puede facilitar la gestión de los permisos para esos usuarios. Los roles y grupos no pueden ser parte de un grupo.
Puedes adjuntar una política basada en identidad a un grupo de usuarios para que todos los usuarios en el grupo de usuarios reciban los permisos de la política. No puedes identificar un grupo de usuarios como un Principal en una política (como una política basada en recursos) porque los grupos se relacionan con permisos, no con autenticación, y los principales son entidades IAM autenticadas.
Aquí hay algunas características importantes de los grupos de usuarios:
Un grupo de usuarios puede contener muchos usuarios, y un usuario puede pertenecer a múltiples grupos.
Los grupos de usuarios no pueden estar anidados; solo pueden contener usuarios, no otros grupos de usuarios.
No hay un grupo de usuarios predeterminado que incluya automáticamente a todos los usuarios en la cuenta de AWS. Si deseas tener un grupo de usuarios así, debes crearlo y asignar a cada nuevo usuario a él.
El número y tamaño de los recursos IAM en una cuenta de AWS, como el número de grupos y el número de grupos de los que un usuario puede ser miembro, son limitados. Para más información, consulta cuotas de IAM y AWS STS.
Un rol de IAM es muy similar a un usuario, en el sentido de que es una identidad con políticas de permisos que determinan qué puede y no puede hacer en AWS. Sin embargo, un rol no tiene ninguna credencial (contraseña o claves de acceso) asociada. En lugar de estar asociado de manera única a una persona, un rol está destinado a ser asumido por cualquier persona que lo necesite (y tenga suficientes permisos). Un usuario de IAM puede asumir un rol para temporalmente adquirir diferentes permisos para una tarea específica. Un rol puede ser asignado a un usuario federado que inicia sesión utilizando un proveedor de identidad externo en lugar de IAM.
Un rol de IAM consta de dos tipos de políticas: una política de confianza, que no puede estar vacía, definiendo quién puede asumir el rol, y una política de permisos, que no puede estar vacía, definiendo qué puede acceder.
El Servicio de Token de Seguridad de AWS (STS) es un servicio web que facilita la emisión de credenciales temporales de privilegios limitados. Está específicamente diseñado para:
Las credenciales temporales se utilizan principalmente con roles de IAM, pero también hay otros usos. Puedes solicitar credenciales temporales que tengan un conjunto de permisos más restringido que tu usuario IAM estándar. Esto previene que realices accidentalmente tareas que no están permitidas por las credenciales más restringidas. Un beneficio de las credenciales temporales es que expiran automáticamente después de un período de tiempo establecido. Tienes control sobre la duración durante la cual las credenciales son válidas.
Se utilizan para asignar permisos. Hay 2 tipos:
Políticas administradas por AWS (preconfiguradas por AWS)
Políticas administradas por el cliente: configuradas por ti. Puedes crear políticas basadas en políticas administradas por AWS (modificando una de ellas y creando la tuya propia), utilizando el generador de políticas (una vista GUI que te ayuda a otorgar y denegar permisos) o escribiendo la tuya propia.
Por defecto, el acceso es denegado, el acceso se otorgará si se ha especificado un rol explícito. Si existe un solo "Deny", anulará el "Allow", excepto para las solicitudes que utilizan las credenciales de seguridad raíz de la cuenta de AWS (que están permitidas por defecto).
Los campos globales que se pueden usar para condiciones en cualquier servicio están documentados aquí. Los campos específicos que se pueden usar para condiciones por servicio están documentados aquí.
Este tipo de políticas son asignadas directamente a un usuario, grupo o rol. Entonces, no aparecen en la lista de Políticas ya que ningún otro puede usarlas. Las políticas en línea son útiles si deseas mantener una relación estricta uno a uno entre una política y la identidad a la que se aplica. Por ejemplo, quieres asegurarte de que los permisos en una política no se asignen inadvertidamente a una identidad diferente de la que están destinados. Cuando usas una política en línea, los permisos en la política no pueden ser adjuntados inadvertidamente a la identidad incorrecta. Además, cuando usas la Consola de Administración de AWS para eliminar esa identidad, las políticas incrustadas en la identidad también se eliminan. Eso es porque son parte de la entidad principal.
Estas son políticas que se pueden definir en recursos. No todos los recursos de AWS las soportan.
Si un principal no tiene una denegación explícita sobre ellos, y una política de recurso les otorga acceso, entonces se les permite.
Los límites de IAM se pueden usar para limitar los permisos a los que un usuario o rol debería tener acceso. De esta manera, incluso si se otorgan un conjunto diferente de permisos al usuario por una política diferente, la operación fallará si intenta usarlos.
Un límite es solo una política adjunta a un usuario que indica el nivel máximo de permisos que el usuario o rol puede tener. Así que, incluso si el usuario tiene acceso de Administrador, si el límite indica que solo puede leer buckets S·, ese es el máximo que puede hacer.
Esto, SCPs y seguir el principio de menor privilegio son las formas de controlar que los usuarios no tengan más permisos de los que necesitan.
Una política de sesión es una política establecida cuando se asume un rol de alguna manera. Esto será como un límite de IAM para esa sesión: Esto significa que la política de sesión no otorga permisos, sino que los restringe a los indicados en la política (siendo los permisos máximos los que tiene el rol).
Esto es útil para medidas de seguridad: Cuando un administrador va a asumir un rol muy privilegiado, podría restringir el permiso solo a los indicados en la política de sesión en caso de que la sesión se vea comprometida.
Nota que por defecto AWS podría agregar políticas de sesión a las sesiones que se van a generar por razones de terceros. Por ejemplo, en roles asumidos de cognito no autenticados por defecto (usando autenticación mejorada), AWS generará credenciales de sesión con una política de sesión que limita los servicios a los que la sesión puede acceder a la siguiente lista.
Por lo tanto, si en algún momento te enfrentas al error "... porque ninguna política de sesión permite el ...", y el rol tiene acceso para realizar la acción, es porque hay una política de sesión que lo impide.
La federación de identidad permite a los usuarios de proveedores de identidad que son externos a AWS acceder a los recursos de AWS de manera segura sin tener que proporcionar credenciales de usuario de AWS de una cuenta IAM válida. Un ejemplo de un proveedor de identidad puede ser tu propio Microsoft Active Directory corporativo (a través de SAML) o servicios de OpenID (como Google). El acceso federado permitirá a los usuarios dentro de él acceder a AWS.
Para configurar esta confianza, se genera un Proveedor de Identidad IAM (SAML u OAuth) que confiará en la otra plataforma. Luego, al menos un rol IAM es asignado (confiando) al Proveedor de Identidad. Si un usuario de la plataforma confiable accede a AWS, lo hará como el rol mencionado.
Sin embargo, generalmente querrás dar un rol diferente dependiendo del grupo del usuario en la plataforma de terceros. Entonces, varios roles IAM pueden confiar en el Proveedor de Identidad de terceros y la plataforma de terceros será la que permitirá a los usuarios asumir un rol u otro.
AWS IAM Identity Center (sucesor de AWS Single Sign-On) amplía las capacidades de AWS Identity and Access Management (IAM) para proporcionar un lugar central que reúne la administración de usuarios y su acceso a cuentas de AWS y aplicaciones en la nube.
El dominio de inicio de sesión será algo como <user_input>.awsapps.com.
Para iniciar sesión a los usuarios, hay 3 fuentes de identidad que se pueden usar:
Directorio del Centro de Identidad: Usuarios regulares de AWS
Active Directory: Soporta diferentes conectores
Proveedor de Identidad Externo: Todos los usuarios y grupos provienen de un Proveedor de Identidad externo (IdP)
En el caso más simple del directorio del Centro de Identidad, el Centro de Identidad tendrá una lista de usuarios y grupos y podrá asignar políticas a ellos para cualquiera de las cuentas de la organización.
Para dar acceso a un usuario/grupo del Centro de Identidad a una cuenta, se creará un Proveedor de Identidad SAML que confíe en el Centro de Identidad, y se creará un rol que confíe en el Proveedor de Identidad con las políticas indicadas en la cuenta de destino.
Es posible dar permisos a través de políticas en línea a roles creados a través del Centro de Identidad IAM. Los roles creados en las cuentas que se les dan políticas en línea en AWS Identity Center tendrán estos permisos en una política en línea llamada AwsSSOInlinePolicy.
Por lo tanto, incluso si ves 2 roles con una política en línea llamada AwsSSOInlinePolicy, no significa que tenga los mismos permisos.
Un usuario (confiando) puede crear un Rol entre Cuentas con algunas políticas y luego, permitir a otro usuario (confiado) acceder a su cuenta pero solo teniendo el acceso indicado en las nuevas políticas del rol. Para crear esto, solo crea un nuevo Rol y selecciona Rol entre Cuentas. Los roles para Acceso entre Cuentas ofrecen dos opciones. Proporcionar acceso entre cuentas de AWS que posees, y proporcionar acceso entre una cuenta que posees y una cuenta de AWS de terceros. Se recomienda especificar el usuario que es confiado y no poner algo genérico porque si no, otros usuarios autenticados como usuarios federados también podrán abusar de esta confianza.
No soportado:
Relaciones de Confianza
Centro de Administración de AD
Soporte completo de API de PS
Papelera de reciclaje de AD
Cuentas de servicio administradas por grupos
Extensiones de esquema
Sin acceso directo a OS o Instancias
La aplicación utiliza AssumeRoleWithWebIdentity para crear credenciales temporales. Sin embargo, esto no otorga acceso a la consola de AWS, solo acceso a recursos dentro de AWS.
Puedes establecer una configuración de política de contraseñas con opciones como longitud mínima y requisitos de contraseña.
Puedes descargar "Informe de Credenciales" con información sobre las credenciales actuales (como tiempo de creación del usuario, si la contraseña está habilitada...). Puedes generar un informe de credenciales tan a menudo como una vez cada cuatro horas.
AWS Identity and Access Management (IAM) proporciona control de acceso granular en toda AWS. Con IAM, puedes especificar quién puede acceder a qué servicios y recursos, y bajo qué condiciones. Con las políticas de IAM, gestionas los permisos para tu fuerza laboral y sistemas para asegurar permisos de menor privilegio.
En esta página puedes encontrar los prefijos de ID de IAM de las claves dependiendo de su naturaleza:
ABIA | |
ACCA | Credencial específica del contexto |
AGPA | Grupo de usuarios |
AIDA | Usuario IAM |
AIPA | Perfil de instancia de Amazon EC2 |
AKIA | Clave de acceso |
ANPA | Política administrada |
ANVA | Versión en una política administrada |
APKA | Clave pública |
AROA | Rol |
ASCA | Certificado |
ASIA | IDs de claves de acceso temporales (AWS STS) utilizan este prefijo, pero son únicos solo en combinación con la clave de acceso secreta y el token de sesión. |
Los siguientes privilegios otorgan varios accesos de lectura de metadatos:
arn:aws:iam::aws:policy/SecurityAudit
arn:aws:iam::aws:policy/job-function/ViewOnlyAccess
codebuild:ListProjects
config:Describe*
cloudformation:ListStacks
logs:DescribeMetricFilters
directconnect:DescribeConnections
dynamodb:ListTables
Para que un usuario regular se autentique en AWS a través de CLI, necesitas tener credenciales locales. Por defecto, puedes configurarlas manualmente en ~/.aws/credentials o ejecutando aws configure.
En ese archivo puedes tener más de un perfil, si no se especifica un perfil usando el aws cli, se utilizará el llamado [default] en ese archivo.
Ejemplo de archivo de credenciales con más de 1 perfil:
Si necesitas acceder a diferentes cuentas de AWS y tu perfil tiene acceso para asumir un rol dentro de esas cuentas, no necesitas llamar manualmente a STS cada vez (aws sts assume-role --role-arn <role-arn> --role-session-name sessname) y configurar las credenciales.
Puedes usar el archivo ~/.aws/config para indicar qué roles asumir, y luego usar el parámetro --profile como de costumbre (el assume-role se realizará de manera transparente para el usuario).
Un ejemplo de archivo de configuración:
Con este archivo de configuración, puedes usar aws cli así:
Si estás buscando algo similar a esto pero para el navegador, puedes revisar la extensión AWS Extend Switch Roles.
Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE)
