Denegar pólizas
Las políticas de denegación de Oracle Cloud Infrastructure (OCI) Identity and Access Management (IAM) son una función de inclusión que permite a los administradores bloquear explícitamente acciones no deseadas, lo que mejora la seguridad y optimiza el control de acceso. La opción de denegación no está activada por defecto. Los administradores deben activarlo.
Las políticas de denegación de IAM introducen sentencias de denegación que simplifican la gestión de políticas, lo que facilita la restricción del acceso a los recursos. Solo los miembros del grupo de administradores por defecto del dominio por defecto pueden activar las políticas de denegación mediante un flujo de trabajo guiado en la consola. Durante la configuración, la siguiente política de nivel raíz por defecto restringe quién puede gestionar las sentencias de denegación y garantiza que solo el administrador de arrendamiento que activó la denegación de IAM pueda escribir políticas de denegación, junto con los miembros del grupo de administradores por defecto:
deny any-user to manage policies in tenancy where all {target.policy.type='deny', request.principal.id!='[ocid]'}
Los miembros del grupo de administradores por defecto del dominio por defecto siempre están exentos de una política de denegación para garantizar el acceso continuo en el nivel más alto.
Para ayudar a controlar el riesgo, los administradores pueden activar notificaciones para denegar cambios de política. Aunque las políticas de denegación mejoran la seguridad y la flexibilidad, se deben gestionar con cuidado, ya que los administradores de compartimentos secundarios pueden utilizar políticas de denegación para bloquear el acceso principal. Las políticas de denegación tienen prioridad sobre las políticas de permiso.
Las ventajas de las políticas de denegación de IAM incluyen lo siguiente:
- Protección de inclusión: desactivada por defecto. Los administradores de arrendamiento deben activar explícitamente la función de denegación, lo que reduce el riesgo involuntario.
- Control de acceso más estricto: permite el bloqueo explícito del acceso, lo que permite una gobernanza más precisa incluso con usuarios con privilegios.
- Guardias más estrictas: los administradores raíz pueden definir restricciones amplias para todo el arrendamiento.
Sintaxis de políticas
La sintaxis de política de denegación coincide con la sintaxis de política de permiso, excepto que las sentencias de política comienzan con la palabra clave deny. Permitir que las políticas comiencen con allow indicado o implícito:
allow...admit...endorse...
Denegar políticas indica explícitamente deny:
deny...deny admit...deny endorse...
Variable de contexto
Mediante la variable de tipo de política, puede restringir los autores de políticas para crear solo tipos específicos de políticas. Por ejemplo, puede restringir a los usuarios para que solo creen políticas de permiso dentro de un compartimento especificado. Para soportar esto, la variable de contexto target.policy.type está en las API de creación, actualización y supresión de políticas. El valor target.policy.type es un juego y puede contener valores tanto para allow como para deny cuando una única política tiene sentencias de permiso y rechazo.
La variable de contexto
target.policy.type se aplica a los tres tipos de políticas de denegación: deny, deny admit y deny endorse.| Clave | Valor | Descripción |
|---|---|---|
target.policy.type |
permitir/denegar | Especifica si la política que se modifica es 1 de 5 políticas de permiso o 1 de 3 políticas de denegación |
A continuación, se muestra un ejemplo de política de permiso mediante la variable target.policy.type:
allow group SampleGroup to manage policies in tenancy where sets-equal(target.policy.type, 'allow')
allow group SampleGroup to manage policies in tenancy where target.policy.type != 'deny'El mismo resultado se puede lograr utilizando una política de denegación:
deny group SampleGroup to manage policies in tenancy where target.policy.type = 'deny'
Al utilizar una política de permiso, una comparación '=' (en lugar de sets-equal o '!=') no se comportaría como se esperaba. Una comparación '=' coincidiría si al menos una de las sentencias tuviera el valor, pero no necesariamente todas.
Inversión de metaverbo
Las políticas de denegación de IAM limitan el acceso mediante la eliminación de permisos específicos, lo que garantiza que solo se permitan las acciones previstas. La sustitución de políticas de denegación permite que las políticas restrinjan el acceso. En cambio, IAM permite que las políticas otorguen permisos para acceder a los recursos.
El nivel de acceso es acumulativo (desde el nivel mínimo de acceso hasta el nivel más alto de acceso). La jerarquía es
inspect (el nivel más bajo de acceso) para read para use para manage (el nivel más alto de acceso).Por ejemplo, al permitir permisos, otorgar acceso a los permisos manage normalmente significa que a un usuario también se le otorgan permisos como read o inspect. El verbo manage siempre amplía el ámbito para incluir los permisos use, read y inspect en un recurso.
Sin embargo, al denegar permisos, lo contrario es cierto. Cuando se escribe una política que deniega el acceso a los permisos manage, no necesariamente bloquea los permisos para inspect, read o use.
Por ejemplo, si escribe una política de denegación para bloquear un permiso inspect, normalmente también desearía restringir los permisos read, use o manage. En otras palabras, negar la capacidad de inspect a un recurso también denegaría la capacidad de read, use o manage.
Para las políticas de permiso, incluya todos los metaverbos con permisos iguales o inferiores a los especificados.
Para las políticas de denegación, incluya todos los metaverbos con permisos superiores a los especificados. Por ejemplo, la siguiente política impediría que SampleGroup suprimiera cualquier cubo, pero no bloquearía el acceso a read. Esto supone otra política a la que se ha otorgado ese acceso, ya que AuthZ aún se deniega por defecto.
deny group SampleGroup to manage buckets in tenancy
Mientras que la siguiente política impediría que SampleGroup realice cualquier acción en esos cubos. Denegar el acceso significa denegar también todos los permisos de nivel inferior.
deny group SampleGroup to inspect buckets in tenancy
Las cadenas de permisos específicas aún se pueden denegar tal como están hoy en día con las políticas de permiso, si es necesario.
deny group SampleGroup to { BUCKET_INSPECT } in tenancy
Prevención de bloqueo de cuenta
Las políticas de denegación podrían bloquear involuntariamente a los usuarios de un arrendamiento si se escribe una política de denegación demasiado amplia. Por ejemplo, si un administrador de compartimento crea una política como deny any-user to inspect any-resource in compartment X, la política impide que todos los usuarios accedan a los recursos de ese compartimento, incluido el administrador que ha creado la política. Para evitarlo, el grupo de administradores por defecto que se crea en cada arrendamiento del dominio por defecto está exento de las políticas de denegación. Esto permite a los administradores predeterminados agrupar el acceso si alguien es bloqueado accidentalmente por una amplia política de denegación.
Activación de la función de política de denegación de IAM
Para utilizar las políticas de denegación de IAM, primero debe activar la función.
Qué hacer a continuación: familiarícese con los problemas conocidos de las políticas de denegación relacionados con las políticas de denegación basadas en etiquetas y los identificadores de grupos dinámicos.