Ejemplos de casos de uso para las políticas de Límite de Acceso de las Entidades

Las siguientes son situaciones comunes en las que tal vez quieras usar políticas de Límite de Acceso de las Entidades y ejemplos de las políticas y las vinculaciones de políticas que podrías crear en cada situación. Para obtener información sobre cómo crear políticas de Límite de Acceso de las Entidades y vincularlas a conjuntos de entidades, consulta Crea y aplica políticas de Límite de Acceso de las Entidades.

Impide que los usuarios accedan a recursos fuera de tu organización

Debido a que las políticas de Límite de Acceso de las Entidades están asociadas con las entidades y no con los recursos, puedes usarlas para impedir que las entidades accedan a recursos que no son de tu propiedad. Por ejemplo, considera la siguiente situación:

Política de límite de acceso de la entidad principal que impide el acceso a un recurso

Política de límite de acceso de la entidad principal que impide el acceso a un recurso

  • La entidad Tal (tal@example.com) forma parte de la organización de Google Workspace example.com.
  • A Tal se le otorga el rol Administrador de almacenamiento (roles/storage.admin) en un bucket de Cloud Storage en una organización diferente, cymbalgroup.com. Este rol contiene el permiso storage.objects.get, que es necesario para ver objetos en el bucket.
  • No hay políticas de denegación en cymbalgroup.com que impidan que Tal use el permiso storage.objects.get.

Los administradores de example.com no pueden usar políticas de permiso y denegación para impedir que Tal vea objetos en este bucket externo. Ninguna entidad de example.com tiene permiso para editar la política de permiso del bucket, por lo que no puede revocar el rol de Tal. Tampoco tienen permiso para crear políticas de denegación en cymbalgroup.com, por lo que no pueden usar una política de denegación para impedir que Tal acceda al bucket.

Sin embargo, con las políticas de Límite de Acceso de las Entidades, los administradores de example.com pueden impedir que Tal vea objetos en el bucket cymbalgroup.com o en cualquier bucket fuera de example.com.

Para ello, los administradores pueden crear una política de Límite de Acceso de las Entidades que indique que las entidades de example.com solo son aptas para acceder a recursos en example.com:

{
  "name": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-org-only",
  "displayName": "Boundary for principals in example.org",
  "details": {
    "rules": [
      {
        "description": "Principals are only eligible to access resources in example.org",
        "resources": [
            "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
        ],
        "effect": "ALLOW"
      }
    ],
    "enforcementVersion": "4"
  }
}

Luego, pueden crear una vinculación de políticas para adjuntar esta política a todas las entidades de la organización example.com:

{
  "name": "organizations/0123456789012/locations/global/policyBindings/example-org-only-binding",
  "displayName": "Bind policy to all principals in example.com",
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
  },
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-org-only"
}

Las entidades que están en example.com incluyen todas las identidades del dominio example.com, todos los grupos de identidades para cargas de trabajo en example.com y todas las cuentas de servicio y los grupos de identidades para cargas de trabajo en cualquier proyecto de example.com.

Con esta política implementada, las entidades de example.com no pueden usar permisos que están bloqueados por la política de Límite de Acceso de las Entidades para acceder a recursos fuera de example.com, incluso si tienen esos permisos en esos recursos.

En este caso, la política de Límite de Acceso de las Entidades usa la versión de aplicación 4, por lo que puede bloquear el permiso storage.objects.get. Como resultado, Tal no podrá ver objetos en el bucket cymbalgroup.com, incluso si se le otorga el rol Administrador de almacenamiento en el bucket.

Haz que las cuentas de servicio sean aptas para acceder a recursos en un solo proyecto

También puedes usar políticas de Límite de Acceso de las Entidades para hacer que los subconjuntos de entidades sean aptos para acceder a subconjuntos de recursos en tu organización.

Por ejemplo, imagina que tienes un proyecto, example-dev, con el número de proyecto 901234567890. Quieres asegurarte de que las cuentas de servicio en example-dev solo sean aptas para acceder a recursos en example-dev.

Para ello, primero crea una nueva política de Límite de Acceso de las Entidades que haga que las entidades sean aptas para acceder a recursos en dev-project:

{
  "name": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-dev-only",
  "displayName": "Boundary for principals in example-dev",
  "details": {
    "rules": [
      {
        "description": "Principals are only eligible to access resources in example-dev",
        "resources": [
          "//cloudresourcemanager.googleapis.com/projects/example-dev"
        ],
        "effect": "ALLOW"
      }
    ],
    "enforcementVersion": "4"
  }
}

Esta política de Límite de Acceso de las Entidades usa la versión de aplicación 4, lo que significa que puede bloquear todos los permisos admitidos en la versión de aplicación 4.

Después de crear la política de Límite de Acceso de las Entidades, crea una vinculación de políticas para vincular la política nueva a todas las entidades de example-dev, y agrega una condición para que la vinculación de políticas solo se aplique a las cuentas de servicio:

{
  "name": "organizations/0123456789012/locations/global/policyBindings/example-dev-only-binding",
  "displayName": "Bind policy to all service accounts in example-dev",
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/projects/example-dev"
  },
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-dev-only",
  "condition": {
    "title": "Only service accounts",
    "description": "Only enforce the policy if the principal in the request is a service account",
    "expression": "principal.type == 'iam.googleapis.com/ServiceAccount'"
  }
}

Si esta es la única política de Límite de Acceso de las Entidades a la que están sujetas las cuentas de servicio, las cuentas de servicio no podrán usar ningún permiso que la política de Límite de Acceso de las Entidades pueda bloquear para acceder a recursos fuera de example-dev.

Administra la elegibilidad para diferentes grupos de entidades

Puedes usar varias políticas de Límite de Acceso de las Entidades en la misma organización para hacer que diferentes entidades sean aptas para acceder a diferentes recursos. Cuando uses varias políticas de Límite de Acceso de las Entidades, usa condiciones en las vinculaciones de políticas para asegurarte de que cada política solo se aplique a las entidades a las que deseas que se aplique.

Por ejemplo, imagina que quieres que la mayoría de las entidades sean aptas para acceder a todos los recursos de tu organización, como se muestra en Impide que los usuarios accedan a recursos fuera de tu organización. Sin embargo, también quieres asegurarte de que las cuentas de servicio en example-dev solo sean aptas para acceder a recursos en example-dev, como se muestra en Haz que las cuentas de servicio sean aptas para acceder a recursos en un solo proyecto.

Para lograr este objetivo, haz lo siguiente:

  1. Siguiendo el ejemplo de Impide que los usuarios accedan a recursos fuera de tu organización, crea una política de Límite de Acceso de las Entidades que haga que las entidades sean aptas para acceder a recursos en example.com y vincúlala al conjunto de entidades de la organización.

  2. Siguiendo el ejemplo de Haz que las cuentas de servicio sean aptas para acceder a recursos en un solo proyecto, crea una política de Límite de Acceso de las Entidades que haga que las cuentas de servicio en example-dev sean aptas para acceder a recursos en example-dev y vincúlala a las cuentas de servicio en example-dev.

  3. Exime las cuentas de servicio en example-dev de la política de Límite de Acceso de las Entidades que hace que las entidades sean aptas para acceder a todos los recursos en example.com. Para ello, agrega la siguiente condición a la vinculación de políticas que adjunta esa política de Límite de Acceso de las Entidades al conjunto de entidades de la organización:

    "condition": {
  "title": "Exempt example-dev service accounts",
  "description": "Don't enforce the policy for service accounts in the example-dev project",
  "expression": "principal.type != 'iam.googleapis.com/ServiceAccount' || (!principal.subject.endsWith('@example-dev.iam.gserviceaccount.com') && principal.subject != 'example-dev@appspot.gserviceaccount.com' && principal.subject != '901234567890-compute@developer.gserviceaccount.com')"
}

Este último paso es fundamental. Si no eximes las cuentas de servicio de example-dev de la política de Límite de Acceso de las Entidades inicial, esa política las hará aptas para acceder a todos los recursos de example.com, independientemente de las otras políticas de Límite de Acceso de las Entidades a las que estén sujetas. Para obtener más información, consulta Define los recursos aptos.

También es importante crear y adjuntar una nueva política de Límite de Acceso de las Entidades a las cuentas de servicio de example-dev antes de eximirlas de la política de Límite de Acceso de las Entidades inicial. Seguir este procedimiento garantiza que las cuentas de servicio siempre estén sujetas a al menos una política de Límite de Acceso de las Entidades, lo que impide que se vuelvan aptas para acceder a todos los Google Cloud recursos. Para obtener más información sobre cómo reducir de forma segura los recursos a los que una entidad puede acceder, consulta Reduce los recursos a los que pueden acceder las entidades.

¿Qué sigue?