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.

Control del 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. 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 directores accedan a la página de inicio de sesión desde redes inesperadas.

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

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

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

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

AWS Sign-In evalúa las políticas basadas en 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 una autenticación correcta (la fase posterior a la autenticación). Cada evaluación comprueba 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 considera 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 con el control de acceso a la consola mediante políticas de recursos

Requisitos previos

Especifique todas las operaciones --region us-east-1 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 permiso de recursos

Cree declaraciones de permiso que definan sus controles de acceso. Todas las operaciones de escritura --region us-east-1 son obligatorias (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 añade 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 en la consola en su 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 AWS Organizations:

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: Verifica tu 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 las declaraciones de permiso. Revise esta política para confirmar que refleja los 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 las políticas

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

Ambas declaraciones son obligatorias porque el inicio de sesión en la consola utiliza OAuth 2.0, que realiza las tres acciones de forma secuencial. Una política con una sola declaración deja desprotegida la otra fase. signin:PrincipalArnadmite los tipos principales de usuario root, usuario de IAM y rol. aws:PrincipalArnadmite todos los tipos principales (usuario root, 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) deniega 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 son únicos solo dentro de una región, la política incluye una tercera declaración que fija el VPC-based acceso a la región esperada.

La EnforceNetworkPerimeterPreAuth declaración se utiliza signin:PrincipalArn para eximir a los directores excluidos durante la fase previa a la autenticación. La EnforceNetworkPerimeterPostAuth declaración se utiliza aws:PrincipalArn para eximir a los directores 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 principal excluido

La siguiente política basada en los recursos deniega el acceso a la consola a todos los principales que realicen solicitudes desde fuera del rango de IP especificado, con la excepción del principal excluido. La política contiene dos declaraciones: una declaración previa a la autenticación que utiliza la signin:PrincipalArn clave específica del servicio y una declaración posterior a la autenticación que utiliza 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, rol).

Los principales excluidos son opcionales, pero omitirlos aumenta el riesgo de bloqueo de la cuenta si las condiciones de la red cambian inesperadamente o si las políticas están mal configuradas.

Pasos de configuración recomendados para el principal excluido:

Mantenga las rutas de acceso de recuperación

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

Realice pruebas antes del despliegue en producción

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

Flujo de trabajo de pruebas:

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 continuamente

AWS CloudTrail registra automáticamente todas las evaluaciones AWS Sign-In de políticas y los cambios de configuración. Vea 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 mediante la creación de una ruta (consulte Creación de una ruta). Para recibir alertas en tiempo real, crea EventBridge reglas de Amazon que coincidan con AWS Sign-In los eventos, configura tu ruta para que se entregue a un grupo de CloudWatch registros para las alarmas basadas en filtros de métricas o reenvía los eventos a tu solución SIEM existente.

Casos de uso

Solución de problemas con el control de acceso a

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

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

Si ve alguno de estos errores y cree que debería permitirse el acceso, póngase en contacto con su AWS administrador. Pueden revisar CloudTrail los registros para ver si hay ConsoleLogin eventos con las errorMessage palabras «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 qué declaración de política denegó el acceso.

Causas posibles:

Solución:

Para los administradores que estén diagnosticando este problema:

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

Si configuraste la autorización de la consola y ya no puedes acceder a tu cuenta, es posible que no hayas configurado las entidades excluidas antes de aplicar la política.

Existen 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 mediante programación (por ejemplo, claves de acceso existentes o un rol multicuenta), úsalo para invocar la política de restricción signin:DeleteConsoleAuthorizationConfiguration y eliminarla. Las credenciales que utilice deben tener permiso para llamar. signin:DeleteConsoleAuthorizationConfiguration La política AWSSignInResourcePolicyManagement gestionada incluye este permiso. AWS recomienda las credenciales temporales en lugar de las claves de acceso de los usuarios 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 que fueron invitadas 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: Contactar con AWS Support

Si no tiene acceso programático y no puede usarlo OrganizationAccountAccessRole para acceder a la cuenta, póngase en contacto con AWS Support para iniciar el proceso de recuperación del 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 dentro de ese período, póngase en contacto con AWS Support para reiniciar el proceso.

Tras recuperar el acceso:

Los cambios que realizo no están siempre visibles inmediatamente

Los cambios de política se replican a nivel mundial, 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: