Note:

Profundización en las políticas de Oracle Cloud Infrastructure Identity and Access Management basadas en etiquetas

Introducción

Las políticas de Oracle Cloud Infrastructure Identity and Access Management (OCI IAM) son la piedra angular de un entorno en la nube sólido y seguro. Proporcionan un mecanismo potente y flexible para controlar el acceso a los recursos de OCI, lo que garantiza que solo los usuarios y servicios autorizados puedan realizar acciones específicas en los recursos designados.

En esencia, una política de OCI IAM es un juego de sentencias declarativas escritas en una sintaxis legible por humanos que dicta quién puede acceder a qué y en qué condiciones. Estas políticas permiten a las organizaciones aplicar el principio de privilegio mínimo, otorgando a los usuarios y servicios solo los permisos que necesitan para realizar sus tareas y nada más. Esto minimiza los riesgos de seguridad al tiempo que mantiene la eficiencia operativa.

Las políticas de OCI IAM se aplican en varios niveles de la jerarquía de OCI, incluidos compartimentos, arrendamiento y recursos específicos, lo que las hace altamente adaptables a estructuras organizativas complejas. Con la herencia de políticas y la compartimentación de OCI, los administradores pueden establecer controles granulares adaptados a sus requisitos operativos y de seguridad específicos. Para obtener más información sobre las políticas de OCI, consulte Getting Started with Policies.

En este tutorial, profundizaremos en la importancia de la optimización de políticas, exploraremos las mejores prácticas para ajustar políticas para lograr resultados óptimos y resaltaremos escenarios en los que la optimización de políticas se puede aprovechar al máximo su potencial.

Objetivos

Requisitos

Desmitificar Componentes y Sintaxis de Políticas

Para ajustar eficazmente las políticas de OCI IAM, es esencial comprender su estructura y componentes clave. Las políticas de OCI definen los permisos especificando quién (principal), qué (acción) en qué (recurso) y dónde (ámbito). A continuación, se desglosa este proceso:

Componentes clave de una política de OCI IAM

Consejo adicional: descripción del concepto Sets-Intersect en la política de OCI IAM

La intersección de juegos en las políticas de OCI IAM se utiliza para otorgar acceso solo cuando hay una superposición entre dos juegos de valores. Esto garantiza que los permisos se otorguen de forma dinámica en función de la pertenencia a grupos, las etiquetas de recursos u otros atributos, en lugar de codificar usuarios o grupos específicos en las políticas.

Modelo de política de OCI IAM a gran escala

Las políticas de OCI IAM son una de las partes fundamentales de proteger las cargas de trabajo en OCI. Es crucial poder escalar y soportar una gran carga de trabajo para nuestros clientes. Por eso hemos creado un modelo de política que requiere un pequeño número de políticas, dentro de los límites de políticas de OCI, que funcionen para cualquier tamaño de carga de trabajo. A continuación se muestran algunos de los motivos para adoptar el modelo de política escalable. Para obtener más información, consulte IAM con límites de dominios de identidad.

El ajuste de las políticas de OCI IAM es una tarea fundamental para mantener un entorno en la nube seguro, escalable y eficiente mientras se mantiene dentro de los límites de las políticas de OCI. Esta es la razón por la que este proceso es esencial:

El papel del etiquetado en la gestión de políticas

El etiquetado es una potente función de OCI que mejora significativamente la gestión de políticas al permitir un control detallado de los recursos. Las etiquetas son etiquetas de metadatos, representadas como pares clave-valor, que se pueden asociar a los recursos. Ayudan a organizar, gestionar y aplicar el control de acceso a escala, especialmente en entornos de nube complejos con varios equipos y proyectos. Para obtener más información, consulte Visión general de Tagging.

Cómo el etiquetado mejora la gestión de políticas

  1. Simplifica la identificación de recursos: las etiquetas proporcionan una forma unificada de categorizar recursos en función de atributos como proyectos, entornos, propietarios o departamentos. Esto simplifica el proceso de aplicación de políticas a subconjuntos específicos de recursos.

    Ejemplo: el etiquetado de recursos con Project: ProjectX permite políticas de acceso de destino.

    Allow group Developers to manage instances in tenancy where tag.Project = 'ProjectX'

  2. Activar aplicación de políticas dinámicas: las políticas basadas en etiquetas se adaptan al cambio de atributos de recursos. Por ejemplo, si una nueva instancia se etiqueta con Environment: Production, hereda automáticamente las políticas definidas para los entornos de producción.

    Política de ejemplo:

    Allow group QA to inspect instances in tenancy where tag.Environment = 'Test'

  3. Optimiza la gobernanza de varios proyectos y equipos: las etiquetas ayudan a aislar el acceso mediante la asociación de recursos con equipos o proyectos específicos. Esto reduce la complejidad al gestionar permisos en varios grupos.

  4. Facilita la automatización: las etiquetas pueden impulsar flujos de trabajo automatizados para la creación de recursos, la supervisión y la gestión del ciclo de vida. Por ejemplo, los scripts de seguimiento de costos pueden recuperar todos los recursos etiquetados con CostCenter: Marketing para generar informes de gastos detallados.

  5. Mejora la gestión de costos y la generación de informes: las etiquetas permiten la atribución granular de costos a proyectos, departamentos o entornos específicos. Esto ayuda a las organizaciones a realizar un seguimiento del gasto y optimizar los presupuestos de forma más eficaz.

Gobernanza de etiquetas: control de la gestión de etiquetas

Para mantener la coherencia, la fiabilidad y la seguridad en la gestión de políticas, la creación y modificación de etiquetas deben controlarse estrechamente. La gobernanza garantiza que las etiquetas se apliquen correctamente y se alineen con los estándares de la organización. La restricción de la gestión de etiquetas a un conjunto específico de individuos o grupos es un elemento clave para mantener el control, la coherencia y la seguridad dentro del entorno en la nube de una organización.

Políticas de OCI IAM basadas en etiquetas para casos de uso reales

Ahora, con todo lo que ha aprendido anteriormente, vamos a trabajar en el ajuste de las políticas de OCI IAM para los principios de usuario e instancia en casos de uso reales. Pero antes de hacerlo, hay algunas políticas comunes que cada cliente requerirá independientemente de su caso de uso.

Escala de políticas de OCI IAM para entidades de usuario

Modelo de política de OCI IAM: en este modelo de política, el objetivo es escribir un pequeño número de políticas más gestionables que estén informadas por datos (etiquetas en nuestro caso), también conocidas como control de acceso basado en atributos. Haremos referencia a las etiquetas asignadas al recurso de destino o al compartimento de recursos de destino para el control de acceso como etiquetas de permiso.

Etiquetas de permiso: defina la etiqueta de permiso para cada combinación de verbo (acción) + tipo de recurso en el arrendamiento. Definen un permiso único que debe asignar a un grupo de usuarios para los recursos de destino. La lista no se define ni se realiza una vez. Comience con un pequeño número de etiquetas de permiso. Una vez que obtenga un identificador sobre el modelo de política, puede agregar más etiquetas de permiso. Para este tutorial, crearemos un espacio de nombres de etiqueta de permiso como mgmt. Además, crearemos un espacio de nombres de etiqueta (llamaremos a infosec) con una clave de etiqueta denominada gname.

  1. Para la siguiente estructura de compartimentos con cuatro tipos de recursos y para asignar permisos de gestión y uso para esos recursos, crearemos etiquetas de permisos.

    Etiquetas de Permiso

  2. Para cada permiso que necesite asignar a un destino (en la mayoría de los casos, los compartimentos), cree un grupo. Asignamos etiquetas de permiso a los recursos (mediante etiquetas por defecto de compartimento) y compartimentos de recursos. El valor de etiqueta es el grupo que debe tener el permiso proporcionado en el recurso de destino.

    Grupos de etiquetas de permiso

  3. Una vez definidas las etiquetas de permiso, podemos escribir políticas. El resultado final es que solo necesitaremos una política por etiqueta de permiso definida en el arrendamiento. La misma política para el permiso proporcionado funcionará en todo el arrendamiento.

    Políticas de etiquetas de permisos

  4. A medida que incorporamos más cargas de trabajo, si hay más tipos de recursos que gestionar, puede que tenga que agregar más etiquetas de permiso y políticas para esas etiquetas de permiso. De lo contrario, solo tendrá que asignar etiquetas de permiso existentes a la nueva carga de trabajo con un grupo de usuarios que deberían tener acceso. No tenemos que escribir ninguna política nueva para la nueva carga de trabajo.

Este enfoque seguirá siendo coherente en todos los ejemplos que se tratan aquí, sirviendo como base para definir grupos y políticas de OCI IAM.

Ejemplo 1: compartimento para cada aplicación

Paso 1: Obtenga una comprensión completa de la visión general del negocio del cliente

CompanyA es una empresa tecnológica en crecimiento que desarrolla y despliega varias aplicaciones nativas en la nube para sus clientes. Cada aplicación atiende a un segmento de clientes específico, con estrictos requisitos de seguridad y conformidad. Para garantizar el aislamiento, la escalabilidad y el control de acceso eficiente, CompanyA organiza sus recursos de OCI mediante un enfoque de compartimentación estructurado.

Paso 2: Diseño de la Estructura de Compartimentos para la Carga de Trabajo

Como se describe, CompanyA sigue el modelo de política de OCI IAM para escalar sus políticas de OCI IAM. Han creado compartimentos independientes para sus aplicaciones a fin de mantener el aislamiento de recursos.

Caso de uso 1

Nota: Solo los administradores deben poder gestionar el espacio de nombres de etiqueta mgmt y infosec.

Paso 3: Diseña las siguientes etiquetas de permiso de combinación de tipo Verb+Resource

Crear grupos en OCI.

  1. Conéctese al dominio de OCI IAM con una cuenta de administrador que tenga el privilegio de crear grupos.

    Directorio raíz de OCI

  2. Vaya a Identidad y seguridad y haga clic en Dominios en Identidad.

    Dominios

  3. Seleccione el compartimento y haga clic en el dominio para el que desea crear los grupos.

    Seleccionar Dominios

  4. Haga clic en Grupos.

    Grupos

  5. Defina sus grupos según las etiquetas de permiso. (Opcionalmente) agregue los usuarios a esos grupos.

    Creación de grupos

Nota: Tendrá que crear grupos para una combinación única de permiso y destino. Si el mismo grupo funcional de usuarios (NetworkAdmin) necesita tener acceso para gestionar la red en todos los destinos, solo necesita un grupo para gestionar el acceso en todos los destinos.

A continuación se muestran las etiquetas de permiso y los grupos de OCI IAM para esas etiquetas. Siga los pasos anteriores para crear grupos para cada una de las etiquetas de permiso definidas.

  1. Compartimento raíz: el compartimento raíz sirve como capa de gestión de nivel superior. Dónde tendremos nuestros grupos de administradores etiquetados con etiquetas de permiso. Las siguientes etiquetas son:

    • Administradores: permiso manageall para gestionar la gestión general del arrendamiento.
    • UseAdministrators: permiso useall para acceder a recursos en todo el arrendamiento.
    • Auditor: permiso readall con acceso de solo lectura a recursos para la supervisión en todo el arrendamiento.

  2. Modelo de compartimento por aplicación: CompanyA tiene varias aplicaciones basadas en la nube. Crearemos un compartimento principal independiente para cada aplicación. Exploremos cómo se aplica este modelo a Aplicación 1 (App1) y Aplicación 2 (App2) como compartimentos principales.

    • Aplicación 1 (App1): una aplicación orientada al cliente alojada en OCI.

      • Compartimento de red: compartimento para todos los recursos relacionados con la red, como VCN, subredes, etc. Ahora, podemos crear las etiquetas de permiso y sus respectivos grupos de OCI IAM.
        • App1NetworkAdmin: etiqueta de permiso de recursos managenetwork para ingenieros que gestionan recursos de red para App1.
        • App1NetworkUser: etiqueta de permiso de recursos usenetwork para desarrolladores que necesitan acceso limitado a configuraciones de red de App1.
        • App1NetworkReader: etiqueta de permiso de recursos readnetwork para auditores que verifican la configuración de red de App1.
      • Compartimento informático: compartimento para instancias informáticas. Ahora, podemos crear las etiquetas de permiso y sus respectivos grupos de OCI IAM.
        • App1ComputeAdmin: etiqueta de permiso de recursos managecompute para administradores del sistema que aprovisionan y escalan instancias informáticas para el backend App1.
        • App1ComputeUser: etiqueta de permiso de recursos usecompute para desarrolladores que despliegan y prueban servicios de backend de App1.
        • App1ComputeReader: etiqueta de permiso de recursos readcompute para auditores que supervisan el uso de recursos informáticos para App1.
      • Compartimento de datos: compartimento para recursos relacionados con la base de datos y el almacenamiento. Ahora, podemos crear las etiquetas de permiso y sus respectivos grupos de OCI IAM.
        • App1DataAdmin: etiqueta de permiso de recursos managedb para administradores de bases de datos que gestionan bases de datos autónomas de Oracle y OCI Object Storage para App1.
        • App1DataUser: etiqueta de permiso de recursos usedb para científicos de datos que acceden a juegos de datos para su análisis con respecto a App1.
        • App1DataReader: etiqueta de permiso de recursos readdb para los auditores que revisan las configuraciones de base de datos de App1.

    • Aplicación 2 (App2): sistema interno de planificación de recursos empresariales (ERP) para las operaciones de la empresa.

      Nota: También aquí seguiremos el mismo enfoque de estructura de compartimento y crearemos Compartimento de red, Compartimento informático y Compartimento de datos en el compartimento App2 principal. Para evitar la redundancia, anotaremos las etiquetas de permiso y los grupos de OCI IAM para App2.

      • Compartimento de red:

        • App2NetworkAdmin: etiqueta de permiso de recursos managenetwork.
        • App2NetworkUser: etiqueta de permiso de recursos usenetwork.
        • App2NetworkReader: etiqueta de permiso de recursos readnetwork.

      • Compartimento de recursos informáticos:

        • App2ComputeAdmin: etiqueta de permiso de recursos managecompute.
        • App2ComputeUser: etiqueta de permiso de recursos usecompute.
        • App2ComputeReader: etiqueta de permiso de recursos readcompute.

      • Compartimento de datos:

        • App2DataAdmin: etiqueta de permiso de recursos managedb.
        • App2DataUser: etiqueta de permiso de recursos usedb.
        • App2DataReader: etiqueta de permiso de recursos readdb.

Nota: Aplique una etiqueta de permiso a un destino (el destino puede ser un recurso o compartimento) para dictar qué grupo tendrá ese permiso específico en el destino para App1 y App2.

Paso 4: Escribir políticas de OCI IAM para esas etiquetas de permiso

Crearemos las políticas para CompanyA con el mismo enfoque que se trata aquí: Tener menos que ser más: escalar políticas de OCI IAM para grupos. Para ello, cree un espacio de nombres de etiqueta (llamaremos a infosec) con una clave de etiqueta denominada gname.

  1. Conéctese al dominio de OCI IAM con una cuenta de administrador que tenga el privilegio de crear políticas.

    Directorio raíz de OCI

  2. Vaya a Identidad y seguridad y haga clic en Políticas en Identidad.

    Políticas

  3. Seleccione el compartimento raíz y haga clic en Crear Política.

    Creación de políticas

  4. Introduzca Nombre, Descripción en la política y agregue también las sentencias de política. Haga clic en Crear.

    • Política de todos los recursos:

      Allow any-user to manage all-resources in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.manageall)
Allow any-user to use all-resources in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.useall)
Allow any-user to read all-resources in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readall)

      Sentencias de política

      Nota: Siga el mismo procedimiento para definir todas las políticas mencionadas a continuación y agregar sus respectivas sentencias de política.

    • Política de Cloudguard:

      Allow any-user to manage cloud-guard-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.managecspm)
Allow any-user to use cloud-guard-family in tenancy where
sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.usecspm)
Allow any-user to read cloud-guard-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readcspm)

    • Política de red:

      Allow any-user to manage virtual-network-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.managenetwork)
Allow any-user to use virtual-network-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.useetwork)
Allow any-user to read virtual-network-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readnetwork)

    • Política de recursos informáticos:

      Allow any-user to manage instance-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.managecompute)
Allow any-user to use instance-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.usecompute)
Allow any-user to read instance-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readcompute)

    • Política de base de datos:

      Allow any-user to manage database-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.managedb)
Allow any-user to use database-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.usedb)
Allow any-user to read database-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readdb)

Ejemplo 2: Compartimento para cada cliente/inquilino

Paso 1: Obtenga una comprensión completa de la visión general del negocio del cliente

CompanyB Solutions es un proveedor de software independiente (ISV) líder que proporciona aplicaciones SaaS basadas en inquilinos en infraestructura en la nube, gestión de datos y análisis. CompanyB atiende a varios clientes de todos los sectores, ofreciendo soluciones fluidas, seguras y escalables. Su éxito depende del uso de OCI con una estructura compartimental bien diseñada para gestionar los recursos de manera eficiente, al tiempo que cumplen los requisitos de seguridad y cumplimiento.

Paso 2: Diseño de la Estructura de Compartimentos para la Carga de Trabajo

CompanyB ha aislado las cargas de trabajo de sus clientes y ha creado un subcompartimento dedicado. Además, tienen un compartimento de red, almacenamiento compartido y compartimento de base de datos. Incluso CompanyB sigue el modelo de política de OCI IAM para escalar sus políticas de OCI IAM.

Caso de uso 2

Paso 3: Diseñar las siguientes etiquetas de permiso de combinación de tipo Verb+Resource

Para crear grupos, consulte el ejemplo 1, paso 3. Tendrá que crear grupos para todas las etiquetas de permiso que se definen a continuación.

  1. Compartimento raíz: gobernanza centralizada: el componente raíz actúa como capa central para supervisar todos los recursos y actividades en todo el arrendamiento de OCI. Dónde tendremos nuestros grupos de administradores etiquetados con etiquetas de permiso. Las siguientes etiquetas son:

    • Administradores: permiso manageall para gestionar la gestión general del arrendamiento.
    • UseAdministrators: permiso useall para acceder a recursos en todo el arrendamiento.
    • Auditor: permiso readall con acceso de solo lectura a recursos para la supervisión en todo el arrendamiento.

  2. Compartimento de red: eje central de operaciones: el compartimento de red soporta la infraestructura de red en la nube de CompanyB, lo que permite la conectividad en todos los recursos. Esto incluye redes virtuales en la nube (VCN), subredes, gateways y equilibradores de carga. Permítanos definir las etiquetas de permiso y sus respectivos grupos de OCI IAM.

    • NetworkAdmin: etiqueta de permiso de recursos managenetwork para ingenieros que gestionan recursos de red para CompanyB.
    • NetworkUser: etiqueta de permiso de recursos usenetwork para desarrolladores que necesitan acceso limitado a las configuraciones de red de CompanyB.
    • NetworkReader: etiqueta de permiso de recursos readnetwork para auditores que verifican la configuración de red de CompanyB.

  3. Compartimento de inquilinos - Compartimentos aislados para diferentes cargas de trabajo de clientes: el compartimento de inquilinos está estructurado para aislar recursos y cargas de trabajo para cada cliente (inquilino). Esto garantiza que CompanyB ofrezca servicios seguros y privados mientras mantiene la eficiencia operativa.

    • Compartimento de inquilino 1: el inquilino 1 representa un cliente de empresa principal que utiliza CompanyB para servicios de registro y desarrollo de aplicaciones. A continuación se muestran las etiquetas de permiso y los grupos de OCI IAM respectivos:

      • t1devadmin: el permiso de recurso manageappdev para el equipo de desarrollo para el inquilino 1 tiene privilegios administrativos para configurar y desplegar aplicaciones personalizadas.
      • t1devuser: permiso de recurso useappdev para supervisar y ajustar los recursos de la aplicación. Los desarrolladores de Tenant 1 utilizan estos recursos para el desarrollo y las pruebas diarias.
      • t1logsadmin y t1devuser: el permiso de recursos managelogs y uselogs para los roles de registro y supervisión garantiza que los administradores configuren los servicios de registro mientras los desarrolladores acceden a los logs para depurar y optimizar las aplicaciones.
      • t1devadmin y t1devuser: permiso de recurso managecspm y usecspm para el inquilino 1, ya que también se centran en la estrategia de seguridad, con la capacidad de supervisar y solucionar riesgos de seguridad.

    • Tenant 2 and Tenant 3 Compartments: The structure for Tenant 2 and Tenant 3 mirrors that of Tenant 1, with roles like t2devadmin, t2devuser, t3devadmin, t3devuser, t2logsadmin and t3logsadmin ensuring that each tenant operates in a fully isolated environment. Este enfoque permite a CompanyB mantener una gobernanza coherente a la vez que se atiende a las necesidades específicas de los inquilinos.

    • Compartimento compartido - Recursos centralizados para todos los inquilinos: el compartimento compartido incluye recursos como bases de datos y almacenamiento de objetos que utilizan varios inquilinos, pero que permanecen segregados lógicamente por motivos de privacidad y seguridad.

      • Compartimento de base de datos:
        • dbadmin: permiso de recurso managedb para que los administradores de base de datos de CompanyB manejen las bases de datos compartidas utilizadas por todos los inquilinos, incluido el aprovisionamiento, la escala y la aplicación de parches.
        • dbuser: el permiso de recurso usedb para usuarios específicos de inquilino accede a sus respectivos esquemas o servicios de base de datos.
        • dbreader: el permiso de recurso readdb para auditores tiene acceso de solo lectura para garantizar que las configuraciones de base de datos cumplan con las políticas de seguridad.
      • Compartimento de almacenamiento: OCI Object Storage se gestiona de forma centralizada, con cubos dedicados para cada inquilino:
        • osadmin: permiso de recurso manageobject responsable de gestionar los recursos de almacenamiento de objetos compartidos.
        • osuser: el permiso de recurso de almacenamiento específico del inquilino useobject (o, por ejemplo, t1osur, t2osur, t3osur) garantiza que los inquilinos solo accedan a sus respectivos cubos.
        • osreader: permiso de recurso readobject para que los equipos de conformidad revisen las configuraciones de almacenamiento y los patrones de uso.

Paso 4: Escribir políticas de OCI IAM para esas etiquetas de permiso

Para crear políticas, consulte el ejemplo 1, paso 4. Tendrá que crear las siguientes políticas.

Ejemplo 3: Estructura de compartimento de gran empresa

Paso 1: Obtenga una comprensión completa de la visión general del negocio del cliente

CompanyC Solutions, una organización multinacional especializada en soluciones de software innovadoras, decidió migrar sus cargas de trabajo esenciales a OCI. La compañía opera en industrias altamente reguladas como finanzas y atención médica, donde la seguridad, el cumplimiento y la escalabilidad son de suma importancia.

Paso 2: Diseño de la Estructura de Compartimentos para la Carga de Trabajo

Vamos a explorar ahora la estructura de compartimentos para CompanyC, que sigue el modelo de política de OCI IAM para escalar sus políticas de OCI IAM.

Caso de uso 3

Paso 3: Diseña las siguientes etiquetas de permiso de combinación de tipo Verb+Resource

Para crear grupos, consulte el ejemplo 1, paso 3. Debe crear grupos para todas las siguientes etiquetas de permiso.

  1. Compartimento raíz: gobernanza centralizada: el componente raíz actúa como capa central para supervisar todos los recursos y actividades en todo el arrendamiento de OCI. Dónde tendremos nuestros grupos de administradores etiquetados con etiquetas de permiso. Las siguientes etiquetas son:

    • Administradores: permiso manageall para gestionar la gestión general del arrendamiento.
    • UseAdministrators: permiso useall para acceder a recursos en todo el arrendamiento.
    • Auditor: permiso readall con acceso de solo lectura a recursos para la supervisión en todo el arrendamiento.

  2. Compartimento PROD: compartimento para alojar cargas de trabajo de producción esenciales que afectan directamente a las operaciones de negocio y a los usuarios finales. Cada aplicación tiene su subcompartimento dedicado para el aislamiento de recursos y la gestión optimizada. Permítanos definir las etiquetas de permiso y sus respectivos grupos de OCI IAM.

    • NetworkAdmin: etiqueta de permiso de recursos managenetwork para ingenieros que gestionan recursos de red para CompanyC.
    • NetworkReader: etiqueta de permiso de recursos readnetwork para auditores que verifican la configuración de red de CompanyC.
    • ComputeAdmin: etiqueta de permiso de recursos managecompute para administradores de sistemas que aprovisionan y escalan instancias informáticas para CompanyC.
    • ComputeReader: etiqueta de permiso de recursos readcompute para auditores que supervisan el uso de recursos informáticos para CompanyC.
    • StorageReader: permiso de recurso manageobject para que los equipos administradores de almacenamiento gestionen las configuraciones de almacenamiento.
    • StorageReader: permiso de recurso readobject para que los equipos de conformidad revisen las configuraciones de almacenamiento y los patrones de uso.
    • SecurityAdmin: permiso de recurso managecspm para Compartment PROD, ya que también se centran en la estrategia de seguridad, con la capacidad de supervisar y solucionar riesgos de seguridad.

    Ahora continuaremos definiendo las etiquetas de permiso y los respectivos grupos de OCI IAM para los subcompartimentos específicos de la aplicación. En aras del tiempo, hemos fusionado y definido permisos para los 3 compartimentos de aplicación diferentes.

    • Compartimentos de aplicación:
      • PRApp1NetAdmin, PRApp2NetAdmin y PRApp3NetAdmin: administre grupos de OCI IAM con la etiqueta de permiso de recursos managenetwork para ingenieros que gestionen recursos de red para App1, App2 y App3, respectivamente.
      • PRApp1NetUser, PRApp2NetUser y PRApp3NetUser: administre grupos de OCI IAM con la etiqueta de permiso de recursos usenetwork para ingenieros que gestionen recursos de red para App1, App2 y App3, respectivamente.
      • PRApp1ComputeAdmin, PRApp2ComputeAdmin y PRApp3ComputeAdmin: administre grupos de OCI IAM con la etiqueta de permiso de recursos managecompute para ingenieros que gestionen instancias de OCI Compute para App1, App2 y App3 respectivamente.
      • PRApp1ComputeUser, PRApp2ComputeUser y PRApp3ComputeUser: administre grupos de OCI IAM con la etiqueta de permiso de recursos usecompute para ingenieros que utilicen instancias de OCI Compute para App1, App2 y App3, respectivamente.
      • PRApp1StorageAdmin, PRApp2StorageAdmin y PRApp3StorageAdmin: administre grupos de OCI IAM con la etiqueta de permiso de recursos manageobject para ingenieros que gestionen OCI Object Storage para App1, App2 y App3 respectivamente.
      • PRApp1StorageUser, PRApp2StorageUser y PRApp3StorageUser: administre grupos de OCI IAM con la etiqueta de permiso de recursos useobject para ingenieros que utilicen OCI Object Storage para App1, App2 y App3 respectivamente.

  3. Compartimento NPROD: dedicado a entornos de almacenamiento en área temporal, desarrollo y garantía de calidad. Este compartimento está estructurado de forma similar a PROD para garantizar la coherencia. Permítanos definir las etiquetas de permiso y sus respectivos grupos de OCI IAM.

    • NetworkAdmin: etiqueta de permiso de recursos managenetwork para ingenieros que gestionan recursos de red para CompanyC.
    • NetworkReader: etiqueta de permiso de recursos readnetwork para auditores que verifican la configuración de red de CompanyC.
    • ComputeAdmin: etiqueta de permiso de recursos managecompute para administradores de sistemas que aprovisionan y escalan instancias de OCI Compute para CompanyC.
    • ComputeReader: etiqueta de permiso de recursos readcompute para auditores que supervisan el uso de recursos de OCI Compute para CompanyC.
    • StorageReader: permiso de recurso manageobject para que los equipos administradores de almacenamiento gestionen las configuraciones de almacenamiento.
    • StorageReader: permiso de recurso readStorage para que los equipos de conformidad revisen las configuraciones de almacenamiento y los patrones de uso.
    • SecurityAdmin: permiso de recurso managecspm para Compartment NPROD, ya que también se centran en la estrategia de seguridad, con la capacidad de supervisar y solucionar los riesgos de seguridad.

    Del mismo modo, ahora seguiremos definiendo las etiquetas de permiso y los respectivos grupos de OCI IAM para los subcompartimentos específicos de la aplicación.

    • Compartimentos de aplicación:
      • NPApp1NetAdmin, NPApp2NetAdmin y NPApp3NetAdmin: administre grupos de OCI IAM con la etiqueta de permiso de recursos managenetwork para ingenieros que gestionen recursos de red para App1, App2 y App3, respectivamente.
      • NPApp1NetUser, NPApp2NetUser y NPApp3NetUser: administre grupos de OCI IAM con la etiqueta de permiso de recursos usenetwork para ingenieros que gestionen recursos de red para App1, App2 y App3, respectivamente.
      • NPApp1ComputeAdmin, NPApp2ComputeAdmin y NPApp3ComputeAdmin: administre grupos de OCI IAM con la etiqueta de permiso de recursos managecompute para ingenieros que gestionen instancias de OCI Compute para App1, App2 y App3 respectivamente.
      • NPApp1ComputeUser, NPApp2ComputeUser y NPApp3ComputeUser: administre grupos de OCI IAM con la etiqueta de permiso de recursos usecompute para ingenieros que utilicen instancias de OCI Compute para App1, App2 y App3, respectivamente.
      • NPApp1StorageAdmin, NPApp2StorageAdmin y NPApp3StorageAdmin: administre grupos de OCI IAM con la etiqueta de permiso de recursos manageobject para ingenieros que gestionen OCI Object Storage para App1, App2 y App3 respectivamente.
      • NPApp1StorageUser, NPApp2StorageUser y NPApp3StorageUser: administre grupos de OCI IAM con la etiqueta de permiso de recursos useobject para ingenieros que utilicen OCI Object Storage para App1, App2 y App3 respectivamente.

  4. Compartimento compartido: el compartimento compartido aloja recursos para la supervisión, como el registro y los servicios de OCI de Cloud Guard. También tiene claves para el cifrado y descifrado que utilizan varios inquilinos al tiempo que garantiza la segregación lógica para mantener la privacidad y la seguridad. Todos los administradores de sus aplicaciones que necesiten acceso a estos servicios se agregarán a los grupos de OCI IAM creados para estos servicios. Permítanos definir las etiquetas de permiso y los grupos de IAM de OCI correspondientes.

    • Compartimentos de Oracle Cloud Guard:

      • cspmAdmin: administre grupos de OCI IAM con la etiqueta de permiso de recursos managecspm para administradores que gestionan Oracle Cloud Guard para compartimentos PROD y Non PROD.
      • cspmUser: grupos de OCI IAM con etiqueta de permiso de recursos usecspm para ingenieros que utilizan/supervisan Oracle Cloud Guard para compartimentos PROD y Non PROD.
      • cspmReader: grupos de OCI IAM con etiqueta de permiso de recursos readcspm para ingenieros que leen Oracle Cloud Guard para compartimentos PROD y Non PROD.

    • Compartimentos de OCI Logging:

      • logsAdmin: administre grupos de OCI IAM con la etiqueta de permiso de recursos managelogs para administradores que gestionan OCI Logging para compartimentos PROD y Non PROD.
      • logsUser: grupos de OCI IAM con etiqueta de permiso de recursos uselogs para ingenieros que utilizan/supervisan OCI Logging para compartimentos PROD y Non PROD.
      • logsReader: grupos de OCI IAM con etiqueta de permiso de recursos readlogs para ingenieros que leen OCI Logging para compartimentos PROD y Non PROD.

    • Compartimentos de claves:

      • kmsAdmin: administre grupos de OCI IAM con la etiqueta de permiso de recursos managekeys para administradores que gestionan el almacén de claves para los compartimentos PROD y Non PROD.
      • kmsUser: grupos de OCI IAM con etiqueta de permiso de recursos usekeys para ingenieros que utilizan/supervisan el almacén de claves para los compartimentos PROD y Non PROD.
      • kmsReader: grupos de OCI IAM con etiqueta de permiso de recursos readkeys para ingenieros que leen el almacén de claves para los compartimentos PROD y Non PROD.

  5. Compartimento de terreno de juego: entorno flexible y aislado para experimentación, desarrollo y pruebas. Este compartimento no está vinculado a restricciones de producción o conformidad, por lo que es ideal para la innovación. Aquí solo tendremos un grupo de administradores de OCI IAM para el compartimento muy secundario y otorgaremos los privilegios de gestión a todos los recursos de OCI necesarios para probar los requisitos.

    • Compartimentos de desarrollo:

      • DevAdmin: administre grupos de OCI IAM con permisos de recursos managenetwork, managecompute, manageobject, managekeys, managelogs para administradores de desarrollo para probar una nueva implantación en el compartimento de desarrollo.

    • Compartimentos de prueba:

      • TestAdmin: administre grupos de OCI IAM con permisos de recursos managenetwork, managecompute, manageobject, managekeys, managelogs para administradores de desarrollo para probar una nueva implantación en el compartimento de prueba.

    • Compartimentos de prueba de rendimiento:

      • PerfTestAdmin: administre grupos de OCI IAM con permisos de recursos managenetwork, managecompute, manageobject, managekeys, managelogs para administradores de desarrollo para probar una nueva implantación en el compartimento de prueba de rendimiento.

Paso 4: Escribir políticas de OCI IAM para esas etiquetas de permiso

Para crear políticas, consulte el ejemplo 1, paso 4. Debe crear las siguientes políticas.

Nota: Para estos escenarios cada vez que incorpore una nueva carga de trabajo:

Modelo de permisos basado en etiquetas para control de acceso granular

Hasta ahora, todos los ejemplos han tratado los permisos de creación, gestión, usuario o lectura para una familia de recursos. Sin embargo, la mayoría de los clientes necesitan un control de acceso granular para seguir el modelo con privilegios mínimos. El tutorial se centra en la comprensión del modelo de política, por lo que hablamos de un caso de uso simple. Sin embargo, permítanme tomar un ejemplo de cuatro personas de red y cómo puede diseñar etiquetas de permisos granulares y políticas de OCI IAM para esas cuatro personas.

Definiremos networkowner, networkadmin, networkoperator y networkuser como cuatro etiquetas en el compartimento de red. Para esas etiquetas, asignaremos nombres de grupo que tengan acceso al compartimento de red.

Escala de políticas de OCI IAM para principales de instancia

Ejemplo 1: control de acceso a instancias multiinquilino para almacenamiento compartido y secretos en OCI

Paso 1: Obtenga una comprensión completa de la visión general del negocio del cliente

XYZ Cloud Solutions es un proveedor de SaaS que ofrece un sistema de gestión de documentos (DMS) alojado en OCI. La plataforma presta servicio a varios clientes empresariales, cada uno de los cuales requiere un aislamiento estricto de sus datos y, al mismo tiempo, aprovecha una infraestructura compartida.

Requisitos del cliente:

Paso 2: Diseño de la Estructura de Compartimentos para la Carga de Trabajo

Vamos a explorar ahora la estructura de compartimentos para XYZ Cloud Solutions, que sigue el modelo de política de OCI IAM para escalar sus políticas de OCI IAM.

Caso de uso de instancia 1

Paso 3: Creación de grupos de OCI IAM

Para garantizar una gestión de acceso segura y aislada en un entorno multiinquilino de OCI, se definirán las siguientes políticas para:

Nota: Estos grupos y políticas de OCI IAM ya se han creado como se describe anteriormente en la sección Políticas comunes de OCI IAM.

Paso 4: Creación de políticas de OCI IAM para los grupos definidos

Políticas de acceso a recursos de inquilino: para mantener el aislamiento de datos, los recursos de inquilino solo deben poder acceder a sus propios secretos y almacenamiento de objetos.

Allow any-user to use object-family in compartment Storage where request.principal.compartment.tag.Enterprise.Tenant = target.resource.tag.Enterprise.Tenant
Allow any-user to use secret-family in compartment Tenants where request.principal.compartment.tag.Enterprise.Tenant = target.resource.tag.Enterprise.Tenant

Si los principios de instancia de inquilino también necesitan permiso para crear nuevos objetos, puede crear nombres de cubo con el mismo nombre que el nombre de inquilino y utilizar la etiqueta de nombre de inquilino para comparar con el nombre de cubo.

Allow any-user to manage objects in compartment Storage where request.principal.compartment.tag.Enterprise.Tenant = target.bucket.name

Ejemplo 2: control de acceso detallado para el acceso a datos de varios servicios en un modelo de almacenamiento de OCI compartido

Paso 1: Obtenga una comprensión completa de la visión general del negocio del cliente

XYZ Corp es una empresa de rápido crecimiento especializada en soluciones de transformación digital. Con una presencia global, XYZ Corp opera en varias regiones y aprovecha OCI para alojar aplicaciones críticas, gestionar datos y garantizar una colaboración perfecta entre equipos.

Requisitos del cliente:

Paso 2: Diseño de la Estructura de Compartimentos para la Carga de Trabajo

Vamos a explorar ahora la estructura de compartimentos para XYZ Corp, que sigue el modelo de política de OCI IAM para escalar sus políticas de OCI IAM.

Caso de uso de instancia 2

Paso 3: Creación de grupos de OCI IAM

Para garantizar una gestión de acceso segura y aislada en un entorno multiinquilino de OCI, se definirán las siguientes políticas para:

Nota: Los grupos InfoSec y Terraform-Runner y las políticas de IAM ya se han creado como se ha descrito anteriormente en la sección Políticas comunes de OCI IAM.

Paso 4: Creación de políticas de OCI IAM para los grupos definidos

Políticas de acceso a recursos de inquilino: para mantener el aislamiento de datos, los recursos de inquilino solo deben poder acceder a sus propios secretos y almacenamiento de objetos.

Allow dynamic-group AdminInstances to use object-family in compartment Storage where all {request.principal.compartment.tag.Enterprise.Tenant=target.resource.tag.Enterprise.Tenant, target.resource.tag.Enterprise.Service=’Admin’}

Allow dynamic-group SalesInstances to use object-family in compartment Storage where all {request.principal.compartment.tag.Enterprise.Tenant=target.resource.tag.Enterprise.Tenant, target.resource.tag.Enterprise.Service=’Sales’}

Allow dynamic-group SupplyInstances to use object-family in compartment Storage where all {request.principal.compartment.tag.Enterprise.Tenant=target.resource.tag.Enterprise.Tenant, target.resource.tag.Enterprise.Service=’Supply’}

Allow any-user to use object-family in compartment Storage where all {request.principal.compartment.tag.Enterprise.Tenant=target.resource.tag.Enterprise.Tenant, target.resource.tag.Enterprise.Service=’Shared’}

Allow dynamic-group AdminInstances to use secret-family in compartment Tenants where all {request.principal.compartment.tag.Enterprise.Tenant=target.resource.tag.Enterprise.Tenant, target.resource.tag.Enterprise.Service=’Admin’}

Allow dynamic-group SalesInstances to use secret-family in compartment Tenants where all {request.principal.compartment.tag.Enterprise.Tenant=target.resource.tag.Enterprise.Tenant, target.resource.tag.Enterprise.Service=’Sales’}

Allow dynamic-group SupplyInstances to use secret-family in compartment Tenants where all {request.principal.compartment.tag.Enterprise.Tenant=target.resource.tag.Enterprise.Tenant, target.resource.tag.Enterprise.Service=’Supply’}

Agradecimientos

Más recursos de aprendizaje

Explore otros laboratorios en docs.oracle.com/learn o acceda a más contenido de formación gratuita en el canal YouTube de Oracle Learning. Además, visite education.oracle.com/learning-explorer para convertirse en un explorador de Oracle Learning.

Para obtener documentación sobre el producto, visite Oracle Help Center.