Políticas de denegación

Las políticas de denegación de Gestión de Identidades y Accesos (IAM) te permiten definir medidas de protección para el acceso a losTrusted Cloud by S3NS recursos. Con las políticas de denegación, puedes definir reglas de denegación que impidan que determinadas entidades principales usen ciertos permisos, independientemente de los roles que tengan asignados.

En esta página se ofrece una descripción general de las políticas de denegación y las reglas de denegación. Para saber cómo crear y actualizar políticas de denegación, consulta Denegar el acceso a los recursos.

Cómo funcionan las políticas de denegación

Las políticas de denegación se componen de reglas de denegación. Cada regla de denegación especifica lo siguiente:

• Conjunto de principales a los que se les deniegan permisos
• Los permisos que se deniegan a las entidades o que estas no pueden usar
• Opcional: la condición que debe cumplirse para que se deniegue el permiso.

Cuando se deniega un permiso a una entidad principal, esta no puede hacer nada que requiera ese permiso, independientemente de los roles de gestión de identidades y accesos que se le hayan concedido. Esto se debe a que IAM siempre comprueba las políticas de denegación pertinentes antes de comprobar las políticas de permiso pertinentes. Para obtener más información, consulta la evaluación de las políticas.

Para especificar dónde quieres que se aplique una política de denegación, debes asociarla a un proyecto, una carpeta o una organización. Cuando se adjunta una política de denegación a uno de estos recursos, las entidades de la política no pueden usar los permisos especificados para acceder al recurso ni a ninguno de sus descendientes. Para obtener más información sobre dónde puede adjuntar una política de denegación, consulte la sección Punto de adjunto de esta página.

Puede asociar varias políticas de denegación a un solo recurso. De esta forma, puedes crear políticas de denegación independientes para diferentes tipos de reglas de denegación. Por ejemplo, puedes incluir reglas de denegación relacionadas con el cumplimiento en una política y, a continuación, usar otra política para otras reglas de denegación. Cada política de denegación se evalúa independientemente de todas las demás políticas de denegación.

Cada recurso puede tener hasta 500 políticas de denegación. En conjunto, estas políticas de denegación pueden contener un total de 500 reglas de denegación.

Punto de fijación

Cada política de denegación se adjunta a una organización, una carpeta o un proyecto. Cuando se adjuntan a uno de estos recursos, las políticas de denegación se heredan en todos los recursos de nivel inferior de ese proyecto, carpeta u organización. Para trabajar con políticas de denegación, necesitas un identificador del recurso al que se adjunta la política de denegación, que se denomina punto de adjunción. Este identificador usa uno de los formatos de la siguiente tabla:

Denegar la herencia de políticas

Las políticas de denegación, al igual que las de permiso, se heredan a través de la jerarquía de recursos. Cuando adjuntas una política de denegación a un proyecto, una carpeta o una organización, la política también se aplica a todos los recursos de ese proyecto, carpeta u organización.

Por ejemplo, si una política de denegación de una organización indica que una entidad de seguridad no puede usar un permiso específico, la entidad de seguridad no podrá usar ese permiso para ningún recurso de la organización. Esta regla se aplica aunque las carpetas y los proyectos de esa organización tengan políticas de denegación más permisivas.

Del mismo modo, si una política de denegación de un proyecto indica que una entidad de seguridad no puede usar un permiso específico, la entidad de seguridad no podrá usar ese permiso para ningún recurso del proyecto. Esta regla se aplica aunque la organización principal y las carpetas tengan políticas de denegación más permisivas.

Condiciones de denegación

Las condiciones de denegación especifican las condiciones que se deben cumplir para que se aplique una regla de denegación. Si la condición se evalúa como true o no se puede evaluar, se aplica la regla de denegación y las entidades no pueden usar los permisos especificados. Si la condición se evalúa como false, la regla de denegación no se aplica y las entidades de seguridad pueden usar los permisos especificados si los tienen.

Las condiciones de denegación tienen la misma estructura que las condiciones de IAM. Sin embargo, las condiciones de denegación solo reconocen las funciones de etiquetas de recursos.

Para saber cómo escribir condiciones, consulta la descripción general de las condiciones de gestión de identidades y accesos.

Grupos de permisos

Algunos servicios te permiten denegar grupos de permisos. Los grupos de permisos son conjuntos de permisos que coinciden con un patrón especificado. Puedes usar un grupo de permisos para denegar conjuntos de permisos relacionados. Por ejemplo, puedes denegar todos los permisos de un solo servicio o recurso.

Los grupos de permisos admitidos se indican en Permisos admitidos en las políticas de denegación. Los identificadores de los grupos de permisos admitidos sustituyen una o varias secciones de un nombre de permiso por un comodín (*). Los permisos que incluye cada grupo dependen de la posición del comodín:

• SERVICE_FQDN/RESOURCE.*: deniega todos los permisos del recurso especificado.
• SERVICE_FQDN/*.*: deniega todos los permisos del servicio especificado.
• SERVICE_FQDN/*.VERB: deniega todos los permisos de un servicio que termina con el verbo especificado.

Los grupos de permisos incluyen todos los permisos actuales y futuros que coincidan con el patrón especificado. Por ejemplo, supongamos que usa el grupo de permisos example.googleapis.com/exampleResource.* para denegar a un usuario todos los permisos del tipo de recurso exampleResource. Si example.googleapis.com añade un nuevo permiso para el tipo de recurso exampleResource, como example.googleapis.com/exampleResource.newPermission, se denegará automáticamente al usuario.

Solo puedes usar comodines en los grupos de permisos admitidos. No se pueden usar comodines en otros nombres de permisos.

Estructura de una política de denegación

Una política de denegación es un conjunto de metadatos y reglas de denegación. Una regla de denegación asocia un conjunto de entidades principales con un conjunto de permisos que se deniegan a las entidades principales o que estas no pueden usar. Cada regla también puede especificar una condición que determine cuándo se deniega el permiso.

Por ejemplo, la siguiente política de denegación impide que todas las entidades eliminen proyectos, a menos que la entidad sea miembro del grupo project-admins o que el proyecto que se vaya a eliminar tenga una etiqueta con el valor test.

{
  "name": "policies/cloudresourcemanager.googleapis.com%2Fprojects%2F253519172624/denypolicies/limit-project-deletion",
  "uid": "06ccd2eb-d2a5-5dd1-a746-eaf4c6g3f816",
  "kind": "DenyPolicy",
  "displayName": "Only project admins can delete projects.",
  "etag": "MTc1MTkzMjY0MjUyMTExODMxMDQ=",
  "createTime": "2021-09-07T23:15:35.258319Z",
  "updateTime": "2021-09-07T23:15:35.258319Z",
  "rules": [
    {
      "denyRule": {
        "deniedPrincipals": [
          "principalSet://goog/public:all"
        ],
        "exceptionPrincipals": [
          "principalSet://iam.googleapis.com/locations/global/workforcePools/example-pool/group/project-admins"
        ],
        "deniedPermissions": [
          "cloudresourcemanager.googleapis.com/projects.delete",
          "cloudresourcemanager.googleapis.com/folders.*"
        ],
        "exceptionPermissions": [
          "cloudresourcemanager.googleapis.com/folders.list",
          "cloudresourcemanager.googelapis.com/folders.get"
        ],
        "denialCondition": {
          "title":  "Only for non-test projects",
          "expression": "!resource.matchTag('12345678/env', 'test')"
        }
      }
    }
  ]
}

En las siguientes secciones se describen los campos de los metadatos y las reglas de denegación de una política de denegación.

Metadatos

Las políticas de denegación contienen los siguientes metadatos:

• name: nombre de la política de denegación. Este nombre tiene el formato policies/ATTACHMENT_POINT/denypolicies/POLICY_ID, donde ATTACHMENT_POINT es el proyecto, la carpeta o la organización a la que se adjunta la política de denegación y POLICY_ID es el ID alfanumérico de la política de denegación.
• uid: ID único asignado a la política de denegación por Google.
• kind: el tipo de política. El kind de una política de denegación siempre es DenyPolicy.
• displayName: opcional. Nombre legible de la política de denegación.
• etag: identificador de una versión de la política. Para evitar conflictos en las actualizaciones, el valor de etag debe coincidir con el valor almacenado en IAM. Si los valores de etag no coinciden, la solicitud fallará.
• createTime: hora en la que se creó la política de denegación.
• updateTime: la última vez que se actualizó la política de denegación.

Reglas de denegación

Cada regla de denegación puede tener los siguientes campos:

• deniedPrincipals: las entidades a las que se les deniegan permisos. Puede enumerar principales individuales y conjuntos de principales. Entre los tipos de principales individuales se incluyen las cuentas de usuario, las cuentas de servicio y las identidades únicas de un grupo de identidades de carga de trabajo o de personal. Los conjuntos de principales incluyen grupos de Google, dominios de Cloud Identity, conjuntos de identidades de Workforce o Workload y todos los usuarios de Internet.

  Para ver una lista de los tipos e identificadores de principales válidos, consulta Identificadores de principales para políticas de denegación.

• exceptionPrincipals: opcional. Los principales que están exentos de la regla de denegación. A estas entidades no se les deniegan los permisos especificados aunque aparezcan en deniedPrincipals o formen parte de un grupo que aparezca en deniedPrincipals.

  Puedes enumerar principales individuales y conjuntos de principales. Entre los tipos de principales individuales se incluyen las cuentas de usuario, las cuentas de servicio y las identidades únicas de un grupo de identidades de la plantilla o de la carga de trabajo. Los conjuntos de principales incluyen grupos de Google, dominios de Cloud Identity, conjuntos de identidades de empleados o de cargas de trabajo, y todos los usuarios de Internet.

  Para ver una lista de los tipos e identificadores de principales válidos, consulta Identificadores de principales para políticas de denegación.

• deniedPermissions: los permisos que los principales especificados no pueden usar o que se les han denegado. Estos permisos usan el formato de permiso v2 de IAM, que utiliza nombres de dominio completos (FQDNs) para identificar el servicio. El formato es SERVICE_FQDN/RESOURCE.ACTION. Las APIs de Google usan el dominio *.googleapis.com. Por ejemplo, iam.googleapis.com/roles.delete.

  Solo se pueden denegar algunos permisos. Para ver una lista completa de los permisos que se pueden denegar, consulta Permisos admitidos en las políticas de denegación.

  En algunos casos, también puedes usar grupos de permisos para denegar conjuntos de permisos. Para obtener más información, consulta Grupos de permisos.

• exceptionPermissions: opcional. Lista de permisos que pueden usar las entidades de seguridad especificadas, aunque esos permisos estén incluidos en deniedPermissions. Por ejemplo, puedes usar este campo para hacer excepciones de permisos específicos en un grupo de permisos.

• denialConditions: opcional. Una expresión lógica que afecta al momento en el que se aplica la regla de denegación. Si la condición se evalúa como true o no se puede evaluar, se deniega el permiso. Si la condición se evalúa como false, el permiso no se deniega. Para obtener más información, consulta las condiciones de denegación de esta página.

Casos prácticos habituales

A continuación, se muestran situaciones habituales en las que puede ser útil usar políticas de denegación, así como ejemplos de las reglas de denegación que puede crear en cada situación. Para saber cómo crear y actualizar políticas de denegación, consulta Denegar el acceso a recursos.

Centralizar los privilegios de administrador

Puedes usar políticas de denegación para restringir determinados tipos de actividades administrativas a un conjunto específico de principales.

Por ejemplo, imagina que quieres limitar la gestión de roles personalizados de tu organización a un solo equipo central. Para ello, crea una regla de denegación que deniegue los permisos necesarios para la gestión de roles personalizados a todos los usuarios, excepto a los usuarios del grupo administrativo (custom-role-admins):

{
  "deniedPrincipals": [
    "principalSet://goog/public:all"
  ],
  "exceptionPrincipals": [
    "principalSet://iam.googleapis.com/locations/global/workforcePools/example-pool/group/custom-role-admins"
  ],
  "deniedPermissions": [
    "iam.googleapis.com/roles.create",
    "iam.googleapis.com/roles.delete",
    "iam.googleapis.com/roles.update",
  ]
}

A continuación, adjunta la política de denegación a tu organización.

Ahora, solo los miembros del grupo custom-role-admins pueden gestionar roles personalizados, aunque otros usuarios tengan los permisos necesarios.

Por ejemplo, imagina que tanto Yuri como Tal tienen el rol de administrador de la organización (roles/iam.organizationRoleAdmin). Sin embargo, Yuri es miembro de custom-role-admins y Tal no. Con esta política de denegación, solo Yuri puede crear, eliminar y actualizar roles.

Crear excepciones a las concesiones de acceso

Puedes usar políticas de denegación para denegar permisos heredados. Esta función te permite asignar un rol a un nivel alto de la jerarquía de recursos y, después, denegar los permisos del rol en recursos concretos de nivel inferior si es necesario.

Por ejemplo, supongamos que tienes una carpeta, Engineering, que contiene varios proyectos. Quieres dar al grupo eng los permisos del rol Administrador de claves de cuentas de servicio (roles/iam.serviceAccountKeyAdmin) en casi todos los proyectos de la carpeta. Sin embargo, no quieres que el grupo pueda crear y eliminar claves de cuentas de servicio en un proyecto específico de la carpeta, example-prod.

En lugar de conceder el rol Administrador de claves de cuenta de servicio en cada proyecto, crea la siguiente regla de denegación, que deniega los permisos de creación y eliminación del rol Administrador de claves de cuenta de servicio a las entidades del grupo eng:

{
  "deniedPrincipals": [
    "principalSet://iam.googleapis.com/locations/global/workforcePools/example-pool/group/eng"
  ],
  "deniedPermissions": [
    "iam.googleapis.com/serviceAccountKeys.create",
    "iam.googleapis.com/serviceAccountKeys.delete"
  ]
}

A continuación, añade esta regla de denegación a una política de denegación y adjunta la política al proyecto example-prod.

Después de adjuntar la política de denegación al proyecto, puedes conceder el rol Administrador de claves de cuenta de servicio al grupo eng en la carpeta Engineering sin permitir que el grupo cree o elimine claves de cuenta de servicio en example-prod.

Los miembros del grupo eng pueden crear y eliminar claves de cuenta de servicio en todos los proyectos, excepto en example-prod. Por ejemplo, si Izumi es miembro del grupo eng, puede crear y eliminar claves de cuentas de servicio en example-dev y example-test, pero no en example-prod.

Sin embargo, supongamos que quieres que un subconjunto del grupo eng pueda crear y eliminar claves de cuentas de servicio en example-prod. Este subconjunto está representado por el grupo eng-prod. Para permitir que los miembros del grupo eng-prod creen y eliminen claves de cuentas de servicio en example-prod, puedes eximir al grupo de la regla de denegación:

{
  "deniedPrincipals": [
    "principalSet://goog/group/eng@example.com"
  ],
  "exceptionPrincipals": [
    "principalSet://iam.googleapis.com/locations/global/workforcePools/example-pool/group/eng-prod"
  ],
  "deniedPermissions": [
    "iam.googleapis.com/serviceAccountKeys.create",
    "iam.googleapis.com/serviceAccountKeys.delete"
  ]
}

Con esta política de denegación revisada, los miembros del grupo eng-prod pueden crear y eliminar claves de cuentas de servicio en todos los proyectos, incluido example-prod. Por ejemplo, si Charlie es miembro del grupo eng-prod, puede crear y eliminar claves en example-dev, example-test y example-prod, aunque también sea miembro del grupo eng.

Bloquear el acceso en función de las etiquetas

Una etiqueta es un par clave-valor que se puede asociar a una organización, una carpeta o un proyecto. Puedes usar políticas de denegación para denegar permisos basados en etiquetas sin añadir una condición de gestión de identidades y accesos a cada concesión de rol.

Por ejemplo, supongamos que etiquetas todos tus proyectos como dev, test o prod. Quieres que solo los miembros del grupo project-admins puedan eliminar proyectos etiquetados como prod.

Para solucionar este problema, crea una regla de denegación que deniegue el permiso cloudresourcemanager.googleapis.com/projects.delete a todos los usuarios, excepto al grupo project-admins, para los recursos etiquetados como prod:

{
  "displayName": "Only project admins can delete production projects.",
  "rules": [
    {
      "denyRule": {
        "deniedPrincipals": [
          "principalSet://goog/public:all"
        ],
        "exceptionPrincipals": [
          "principalSet://iam.googleapis.com/locations/global/workforcePools/example-pool/group/project-admins"
        ],
        "deniedPermissions": [
          "cloudresourcemanager.googleapis.com/projects.delete"
        ],
        "denialCondition": {
          "title":  "Only for prod projects",
          "expression": "resource.matchTag('12345678/env', 'prod')"
        }
      }
    }
  ]
}

A continuación, añade esta regla de denegación a una política de denegación y adjunta la política a tu organización.

Gracias a esta regla de denegación, puedes limitar el acceso de las entidades sin añadir una condición a sus concesiones de roles. En su lugar, puedes conceder a las entidades principales roles que contengan el permiso cloudresourcemanager.googleapis.com/projects.delete y usar la regla de denegación para evitar que las entidades principales que no pertenezcan al grupo project-admins eliminen proyectos etiquetados como prod.

Por ejemplo, supongamos que tenemos dos usuarios: María y Juan. Ambos usuarios tienen el rol Eliminador de proyectos (roles/resourcemanager.projectDeleter). Además, Kiran es miembro del grupo project-admins. Con esta política de denegación, Bola solo puede eliminar proyectos que tengan la etiqueta dev o test. Kiran puede eliminar todos los proyectos, independientemente de sus etiquetas.

Siguientes pasos

• Consulta cómo crear, actualizar y eliminar políticas de denegación.
• Consulta cómo solucionar problemas de acceso con políticas de denegación.
• Consulta los permisos que se pueden denegar.
• Consulta los tipos de principales que puedes incluir en las políticas de denegación.