Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Controlar el acceso a la consola con políticas basadas en recursos y políticas de control de recursos

AWS Sign-In admite políticas basadas en recursos y políticas de control de recursos (RCP) para controlar el acceso a. AWS Sign-In Utilice estas políticas para verificar la identidad del usuario y la ubicación de la red durante el Consola de administración de AWS acceso, antes, durante y después de la autenticación. En el caso de los usuarios raíz, estas políticas validan la ubicación de la red y la identidad del usuario antes de que comience la recopilación de credenciales. Las credenciales solo se pueden introducir cuando el acceso se origina en las redes esperadas.

AWS Sign-In políticas basadas en recursos:

Políticas de control de recursos (RCP):

Ambos tipos de políticas verifican el acceso antes de la autenticación. Esto impide que los principales accedan a la página de inicio de sesión desde redes inesperadas.

Estas políticas no sustituyen a las políticas basadas en la identidad de IAM, que siguen aplicándose.

AWS Sign-In Las políticas basadas en recursos y los RCP se aplican a los siguientes métodos de autenticación:

Estos controles no se aplican al acceso programático mediante claves de acceso (llamadas a AWS SDK o API firmadas con SIGv4).

Cómo AWS Sign-In evalúa las políticas basadas en recursos

AWS Sign-In evalúa las políticas basadas en los recursos o las políticas de control de recursos (RCP) aplicables en dos momentos durante el acceso a la consola: antes de la autenticación (la fase previa a la autenticación) y después de la autenticación satisfactoria (la fase posterior a la autenticación). En cada evaluación se comprueban las claves de condición definidas en su política. Las claves disponibles dependen de la fase y la acción. Para obtener más información, consulte Claves de condición admitidas.

Tras la autenticación, la evaluación también tiene en cuenta las políticas del director basadas en la identidad. Una política de IAM que deniegue la acción de inicio de sesión correspondiente puede impedir que se conceda la sesión de consola, incluso cuando se cumplan las condiciones de la red.

Acciones admitidas

AWS Sign-In las políticas de recursos (políticas basadas en recursos y RCP) admiten las siguientes acciones:

Claves de condición admitidas

AWS Sign-In admite las siguientes claves de condición en las políticas basadas en recursos y en las políticas de control de recursos (RCP). Utilice estas teclas para controlar el acceso a la consola en función de la ubicación de la red y la identidad principal:

Para ver las reglas de uso detalladas, la compatibilidad de los operadores, las restricciones de combinación y la matriz de disponibilidad por acción, consulteAWS Sign-In referencia de claves de condición.

Cómo empezar a controlar el acceso a la consola mediante políticas de recursos

Requisitos previos

Especifíquelo --region us-east-1 para todas las operaciones de escritura en las políticas. AWS Sign-In AWS replica las políticas de esta región a nivel mundial. Las operaciones de lectura pueden dirigirse a cualquier región.

Paso 1: Crear declaraciones de permisos de recursos

Cree declaraciones de permiso que definan sus controles de acceso. Todas las operaciones de escritura lo requieren --region us-east-1 (el AWS Sign-In servicio solo acepta cambios de política en esta región). Los parámetros restantes (--source-vpc,--source-ip,--requested-region,--excluded-principal) definen las condiciones de su política. Por ejemplo, --requested-region us-west-2 agrega una condición que restringe el inicio de sesión en el punto final de inicio de sesión regional us-west-2.

Ejemplo: restringir el acceso a la VPC corporativa:

aws signin put-resource-permission-statement \
  --source-vpc vpc-0abc123def456789 \
  --requested-region us-west-2 \
  --excluded-principal "arn:aws:iam::123456789012:user/EmergencyAdmin" \
  --client-token unique-request-id-12345 \
  --region us-east-1

Ejemplo: restringir el acceso a un rango de IP específico:

aws signin put-resource-permission-statement \
  --source-ip "IP_ADDRESS" \
  --excluded-principal "arn:aws:iam::123456789012:role/BreakGlassRole" \
  --region us-east-1

Paso 2: Habilitar la configuración de autorización de la consola

El siguiente paso activa la aplicación de políticas para el proceso de inicio de sesión de la consola en tu cuenta u organización. Las declaraciones de permisos de recursos se pueden crear en cualquier momento, pero no se evalúan hasta que se habilita la autorización de la consola.

Para cuentas independientes:

aws signin put-console-authorization-configuration \
  --target-id <your-aws-account-id> \
  --region us-east-1

Para las organizaciones de AWS:

aws signin put-console-authorization-configuration \
  --target-id <your-aws-organization-id> \
  --region us-east-1

Verifique la configuración:

aws signin get-console-authorization-configuration \
  --target-id <your-target-id> \
  --region <your-region>

Elimine la configuración de autorización de la consola:

aws signin delete-console-authorization-configuration \
  --target-id <your-target-id> \
  --region us-east-1

Paso 3: Verifique su política

Enumere todas las declaraciones de permiso:

aws signin list-resource-permission-statements \
  --max-results 50 \
  --region <your-region>

Recupere la política consolidada completa:

aws signin get-resource-policy \
  --region <your-region>

El get-resource-policy comando devuelve la política completa basada en los recursos, compuesta por todas sus declaraciones de permiso. Revisa esta política para confirmar que refleja tus controles de acceso previstos antes de probar el acceso a la consola.

Disponibilidad regional

Las API de autorización de consolas están disponibles en todas las regiones AWS comerciales. Puede llamar a estas API desde cualquier región en la que opere.

Comprender la estructura de la política

AWS Sign-In las políticas contienen dos declaraciones que protegen las diferentes fases del flujo de inicio de sesión de la consola:

Ambas instrucciones son obligatorias porque el inicio de sesión en la consola utiliza OAuth 2.0, que se ejecuta de forma secuencial entre las tres acciones. Una política con una sola sentencia deja la otra fase desprotegida. signin:PrincipalArnadmite los tipos principales de usuario raíz, usuario de IAM y rol. aws:PrincipalArnadmite todos los tipos principales (usuario raíz, usuario de IAM, usuario federado, rol).

Ejemplos de políticas

Ejemplo 1: RCP con perímetro de red y principales excluidos

La siguiente política de control de recursos (RCP) niega el Consola de administración de AWS inicio de sesión desde fuera de la red corporativa en todas las cuentas de la organización. Los directores excluidos designados están exentos del acceso de emergencia. Dado que los ID de VPC solo son únicos dentro de una región, la política incluye una tercera declaración que fija el VPC-based acceso a la región en cuestión.

La EnforceNetworkPerimeterPreAuth declaración se utiliza signin:PrincipalArn para eximir a los principales excluidos durante la fase previa a la autenticación. La EnforceNetworkPerimeterPostAuth declaración se utiliza aws:PrincipalArn para eximir a los principales excluidos después de la autenticación. La EnforceSourceVPCRegion declaración garantiza que la región de la solicitud coincida con la región de la VPC, lo que restringe el acceso a la región esperada para la VPC especificada.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EnforceNetworkPerimeterPreAuth",
      "Effect": "Deny",
      "Principal": "*",
      "Action": ["signin:Authenticate"],
      "Resource": "*",
      "Condition": {
        "ArnNotEquals": {
          "signin:PrincipalArn": [
            "arn:aws:iam::111122223333:root",
            "arn:aws:iam::444455556666:root",
            "arn:aws:iam::777788889999:user/EmergencyUser",
            "arn:aws:iam::777788889999:role/OrgBreakGlassRole"
          ]
        },
        "NotIpAddressIfExists": {
          "aws:SourceIp": "<my-corporate-cidr>"
        },
        "StringNotEquals": {
          "aws:SourceVpc": "<my-vpc>"
        }
      }
    },
    {
      "Sid": "EnforceNetworkPerimeterPostAuth",
      "Effect": "Deny",
      "Principal": "*",
      "Action": ["signin:CreateOAuth2Token", "signin:AuthorizeOAuth2Access"],
      "Resource": "*",
      "Condition": {
        "ArnNotEquals": {
          "aws:PrincipalArn": [
            "arn:aws:iam::111122223333:root",
            "arn:aws:iam::444455556666:root",
            "arn:aws:iam::777788889999:user/EmergencyUser",
            "arn:aws:iam::777788889999:role/OrgBreakGlassRole"
          ]
        },
        "NotIpAddressIfExists": {
          "aws:SourceIp": "<my-corporate-cidr>"
        },
        "StringNotEquals": {
          "aws:SourceVpc": "<my-vpc>"
        }
      }
    },
    {
      "Sid": "EnforceSourceVPCRegion",
      "Effect": "Deny",
      "Principal": "*",
      "Action": [
        "signin:Authenticate",
        "signin:CreateOAuth2Token",
        "signin:AuthorizeOAuth2Access"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:SourceVpc": "<my-vpc>"
        },
        "StringNotEqualsIfExists": {
          "aws:RequestedRegion": "<my-vpc-region>"
        }
      }
    }
  ]
}

Esta política:

Ejemplo 2: Resource-based política de IP-based acceso con un principal excluido

La siguiente política basada en recursos niega el acceso a la consola a todas las personas principales que realicen solicitudes desde fuera del rango de IP especificado, y se exime a las principales excluidas. La política contiene dos instrucciones: una declaración previa a la autenticación que usa la signin:PrincipalArn clave específica del servicio y una declaración posterior a la autenticación que usa la clave global. aws:PrincipalArn

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Principal": { "AWS": "*" },
      "Action": ["signin:Authenticate"],
      "Resource": "*",
      "Condition": {
        "ArnNotEquals": {
          "signin:PrincipalArn": "<excluded-principal-arn>"
        },
        "NotIpAddress": {
          "aws:SourceIp": "<my-corporate-cidr>"
        },
        "StringEquals": {
          "aws:ResourceAccount": "<my-aws-account-id>"
        }
      }
    },
    {
      "Effect": "Deny",
      "Principal": { "AWS": "*" },
      "Action": ["signin:CreateOAuth2Token", "signin:AuthorizeOAuth2Access"],
      "Resource": "*",
      "Condition": {
        "ArnNotEquals": {
          "aws:PrincipalArn": "<excluded-principal-arn>"
        },
        "NotIpAddress": {
          "aws:SourceIp": "<my-corporate-cidr>"
        },
        "StringEquals": {
          "aws:ResourceAccount": "<my-aws-account-id>"
        }
      }
    }
  ]
}

Esta política:

Prácticas recomendadas

Configure los principales excluidos para el acceso de recuperación de emergencia

AWS recomienda configurar al menos un usuario excluido antes de aplicar las políticas de autorización de la consola en producción. En la fase previa a la autenticación, la clave de signin:PrincipalArn condición exime al usuario raíz, al usuario de IAM y a los directores de rol. En la fase posterior a la autenticación, la clave de aws:PrincipalArn condición exime a todos los tipos principales (usuario raíz, usuario de IAM, usuario federado y rol).

La exclusión de los principales es opcional, pero omitirlos aumenta el riesgo de que se bloquee la cuenta si las condiciones de la red cambian inesperadamente o si las políticas están mal configuradas.

Pasos recomendados para la configuración de los principales excluidos:

Mantenga las rutas de acceso a la recuperación

Además del principio de exclusión descrito anteriormente, asegúrese de que haya métodos de acceso alternativos disponibles en caso de que las políticas de autorización de la consola bloqueen el inicio de sesión de forma inesperada:

Realice una prueba antes de la implementación en producción

AWS recomienda no adjuntar RCP restrictivos a la raíz de la organización sin comprobar minuciosamente el impacto que la política tiene en las cuentas. En su lugar, crea una unidad organizativa a la que puedas mover tus cuentas de una en una, o al menos en pequeñas cantidades, para asegurarte de no bloquear inadvertidamente el acceso de los usuarios a las cuentas clave.

Flujo de trabajo de prueba:

Diseñe con una defensa en profundidad

Utilice las políticas AWS Sign-In basadas en los recursos y las políticas de control de los recursos como una capa dentro de una estrategia de seguridad más amplia. AWS Sign-In las políticas restringen el acceso a la consola en función de la ubicación de la red y la identidad principal. Combínelas con otros tipos de políticas para crear controles de acceso integrales:

Supervise y audite de forma continua

AWS CloudTrail registra automáticamente todas las evaluaciones AWS Sign-In de políticas y los cambios de configuración. Consulta estos eventos en el historial de CloudTrail eventos durante un máximo de 90 días. Para una retención más prolongada, envíe los eventos a Amazon S3 creando un registro (consulte Creación de un registro). Para recibir alertas en tiempo real, cree EventBridge reglas de Amazon que coincidan con AWS Sign-In los eventos, configure su registro para enviarlo a un grupo de CloudWatch registros para las alarmas basadas en filtros métricos o reenvíe los eventos a su solución SIEM existente.

Casos de uso

Solución de problemas relacionados con el control de acceso

No puedo iniciar sesión debido a las condiciones de red que figuran en las políticas basadas en Sign-in los recursos

Es posible que aparezca uno de los siguientes mensajes de error cuando una AWS Sign-In política deniegue el acceso:

Si ves alguno de estos errores y crees que se te debería permitir el acceso, ponte en contacto con tu AWS administrador. Pueden revisar CloudTrail los registros en busca de ConsoleLogin eventos diciendo errorMessage «Autorización denegada debido a una política basada en recursos» o «Autorización denegada debido a una política de control de recursos» para identificar a qué declaración de política se ha denegado el acceso.

Causas posibles:

Solución:

Usuarios del portal del IAM Identity Center: el acceso a la consola a través del portal del IAM Identity Center no es compatible actualmente con AWS Sign-In las políticas que restringen el acceso en función de las claves de estado de la red. Para restablecer el acceso de los usuarios del Identity Center de IAM, elimine o ajuste las claves de condición basadas en la red de su política, o indique a esos usuarios que inicien sesión mediante un método de autenticación alternativo.

Para los administradores que diagnostican este problema:

Se me bloquea el acceso a mi cuenta después de habilitar la autorización de la consola

Si has configurado la autorización de la consola y ya no puedes acceder a tu cuenta, es posible que no hayas configurado los principales excluidos antes de aplicar la política.

Hay varias rutas para recuperar el acceso, según el tipo de cuenta y las credenciales disponibles.

Opción 1: usar el acceso programático (AWS CLI o SDK)

Las políticas de autorización de la consola se aplican únicamente al inicio de sesión en la consola interactiva. No se aplican a las solicitudes de API firmadas con SIGv4. Si tienes acceso programático (por ejemplo, claves de acceso existentes o una función multicuenta), úsalo para invocar la política restrictiva signin:DeleteConsoleAuthorizationConfiguration y eliminarla. Las credenciales que utilices deben tener permiso para realizar llamadas. signin:DeleteConsoleAuthorizationConfiguration La política AWSSignInResourcePolicyManagement gestionada incluye este permiso. AWS recomienda las credenciales temporales en lugar de las claves de acceso de usuario de IAM a largo plazo. OrganizationAccountAccessRoleEn el caso de las cuentas de los miembros, los administradores de las cuentas de administración pueden utilizar la cuenta del miembro para obtener credenciales temporales. Este rol no se crea automáticamente en las cuentas a las que se invitó a unirse a la organización.

aws signin delete-console-authorization-configuration \
  --target-id <your-aws-account-id> \
  --region us-east-1

O elimina declaraciones de permiso específicas:

# First, list statements to get the statement ID
aws signin list-resource-permission-statements \
  --region us-east-1

# Then delete the problematic statement
aws signin delete-resource-permission-statement \
  --statement-id <statement-id> \
  --region us-east-1

Opción 2: Póngase en contacto con el AWS servicio de asistencia

Si no tienes acceso programático y no puedes usarlo OrganizationAccountAccessRole para acceder a la cuenta, ponte en contacto con el equipo de AWS soporte para iniciar el proceso de recuperación tras el bloqueo.

El proceso de recuperación funciona de la siguiente manera:

El enlace al portal de recuperación caduca 72 horas después de que AWS Support lo comparta. Si no completa la recuperación en ese período, póngase en contacto con el equipo de AWS soporte para reiniciar el proceso.

Tras recuperar el acceso:

Los cambios que realizo no están siempre visibles inmediatamente

Los cambios en las políticas se replican en todo el mundo, pero la replicación puede tardar unos minutos.

Solución:

aws signin get-resource-policy --region <your-region>

Problemas comunes de replicación de políticas: