Estructura de seguridad de IAM

Una de las ventajas principales de la adopción de la nube es la escalabilidad, que permite a las empresas empezar a pequeña escala y crecer. En comparación con las infraestructuras tradicionales, el uso de la automatización le permite desplegar recursos en cuestión de minutos en lugar de días, lo que puede llevar a una mayor innovación. Sin un control adecuado, un entorno en la nube puede llegar a ser demasiado complejo y difícil de gestionar en términos de seguridad y costos, poniendo en riesgo a tu organización.

Antes de crear varios recursos en la nube en Oracle Cloud Infrastructure (OCI), recomendamos configurar un modelo de seguridad de identidad y gestión de acceso (IAM). Una versión inicial de un modelo de seguridad puede ayudar a su organización a mitigar los riesgos de gestión mediante la separación de tareas y recursos, lo que guía el éxito del crecimiento futuro.

Nota: Antes de agregar varios recursos en la nube, defina un modelo de seguridad de IAM que cubra el arrendamiento, la estructura de compartimentos, etc.

En OCI, el aislamiento de recursos está incorporado, empezando por los siguientes recursos:

• Arrendamiento
• Dominio de identidad
• Estructura de compartimentos
• Políticas de IAM

Organización y arrendamiento

Cuando se registra en OCI, Oracle crea un arrendamiento para usted. El arrendamiento contiene sus entidades IAM (usuarios, grupos, compartimentos y algunas políticas) y otros recursos de OCI. También puede colocar políticas y recursos en compartimentos dentro del arrendamiento. Para obtener más información, consulte Gestión de organización y Gestión de acceso a recursos.

Consideración del arrendamiento como el nivel más alto del límite de seguridad

• El arrendamiento es el contenedor de nivel más alto que aloja los recursos de OCI, y también se denomina compartimento raíz.
• Todo el control de acceso de los recursos de OCI lo dictan las políticas de IAM, donde el arrendamiento es el nivel más alto al que se pueden asignar las políticas de IAM. Las reglas de gobernanza de OCI Organization Management pueden controlar las regiones, la cuota de servicio y las etiquetas permitidas para los arrendamientos secundarios, pero no tienen control sobre las políticas de IAM. Puede otorgar acceso entre arrendamientos mediante la creación de políticas de IAM entre arrendamientos. En este caso, los administradores de otorgamiento y aceptación de arrendamientos deben crear sentencias de política especiales que indiquen explícitamente los recursos a los que se puede acceder y compartir.

Nota: El compartimento raíz es el nivel superior de las jerarquías de política de IAM, y las políticas de la IAM no se pueden heredar entre arrendamientos. Para obtener más información, consulte Cómo funcionan las políticas y Políticas entre arrendamientos.

Aproveche varios arrendamientos para ampliar su negocio más allá de los límites

• Cada arrendamiento de OCI se crea con un juego de límites de servicio configurado por Oracle. Aunque los usuarios pueden solicitar un aumento del límite de servicio, no tienen control directo sobre los límites.
• Para evitar la interrupción del servicio, los usuarios pueden controlar la distribución del uso asignando cuotas de servicio a los compartimentos según sea necesario.
• Los usuarios pueden ampliar más allá de los límites del servicio físico aprovechando un nuevo arrendamiento, que tiene su propio conjunto de límites asignados durante la creación.

Puede agregar arrendamientos a su organización mediante Gestión de Organización y hacer que los arrendamientos consuman créditos de su suscripción financiada principal. A continuación, puede crear un arrendamiento aislado para crear sus cargas de trabajo sin reservar una nueva orden.

Los tipos de arrendamiento son los siguientes:

• Arrendamiento principal: asociado a la suscripción financiada principal, que puede analizar e informar en cada uno de sus arrendamientos. Cada organización solo puede tener un arrendamiento principal. Es típico utilizar el arrendamiento principal para fines de gestión, donde las operaciones de desarrollador, finanzas y TI pueden necesitar acceso a él. En este caso, recomendamos que no aloje ninguna aplicación o servicio dentro de este arrendamiento.
• Arrendamientos secundarios: Arrendamientos que consumen de una suscripción que no es suya. Los arrendamientos secundarios se pueden crear como arrendamientos nuevos por completo, o se puede invitar a los arrendamientos existentes a unirse al arrendamiento principal y formar parte de la misma organización.

Nota: Le recomendamos que no aloje ninguna aplicación o servicio en el arrendamiento principal, especialmente si se utiliza con fines de gestión. Para obtener más información, consulte OCI Blog-Use Organizations para gestionar los costos de forma centralizada.

Consideraciones sobre la estructura de los arrendamientos

Tenga en cuenta la siguiente información para los arrendamientos:

• Gestión de facturación y costos: compartir un único compromiso ayuda a reducir los excedentes de costos y permite una facturación consolidada.
• Aislamiento del entorno: si necesita una alta autonomía operativa con aislamiento estricto de los recursos, puede utilizar un arrendamiento como límite de nivel superior para aislar los entornos. Debido a que cada arrendamiento incluye un juego distinto de recursos y reglas de IAM, la configuración de seguridad y gobernanza se administra por separado. Una administración independiente hace posible el grado más alto de autonomía operativa.
• Gastos generales de gestión: el uso de varios arrendamientos permite la autonomía operativa con un nivel fuerte de aislamiento, pero se generan costos generales de gestión. Si no necesita un alto nivel de aislamiento, como el de la conformidad normativa, considere la posibilidad de utilizar dominios de identidades y compartimentos.
• IAM resources residency: Each tenancy has its own home region, which contains your Oracle Cloud account information and identity resources in the default IAM identity domain.
  • El dominio por defecto se replica siempre en todas las regiones a las que está suscrito el inquilino. Cuando un administrador se suscribe a otra región, solo se replica el dominio por defecto en esa región. La región principal del dominio por defecto es la región principal del arrendamiento, que no se puede cambiar.
  • Los dominios de identidad secundarios (no por defecto) pueden tener su propia región principal, pero solo dentro del juego de regiones al que está suscrito el arrendamiento. Los dominios de identidad secundarios también pueden replicarse en las regiones dentro del juego de regiones al que está suscrito el arrendamiento.

Limitaciones para los arrendamientos

Tenga en cuenta las siguientes limitaciones para los arrendamientos:

• La región principal contiene los recursos de identidad y la información de su cuenta, y que no se pueden cambiar después de aprovisionar el arrendamiento. Para obtener más información, consulte Región principal.
• Cuando se crea un arrendamiento secundario, el arrendamiento no se federa automáticamente a los dominios de identidad de OCI/Oracle Identity Cloud Service. Para obtener más información, consulte Creación de un nuevo arrendamiento secundario.
• Los arrendamientos que utilizan suscripciones de Pay As You Go o Free Tier no pueden agregar nuevos arrendamientos secundarios. Para obtener más información, consulte Creación de un nuevo arrendamiento secundario.
• El arrendamiento padre-hijo es una estructura de un solo nivel y no soporta una jerarquía de varios niveles.

Casos de uso de ejemplo para arrendamientos

Considere los siguientes casos de uso de ejemplo para tener arrendamientos independientes:

• Proveedor de servicios SaaS para alojar arrendamientos dedicados para clientes regulados
• Requisitos de residencia de recursos de IAM de leyes de privacidad y seguridad de datos.
• Para fusiones y adquisiciones (M&A), empresas que necesitan mantener la autonomía operativa con procesos de contratación y gestión de identidades independientes.
• Para hackatones y pruebas de concepto (PoC), la capacidad de iniciar proyectos innovadores en un arrendamiento gratuito y basado en proyectos y luego aplicarlos a toda la organización para lograr tablas de precios negociadas y una mejor visibilidad de costos.
• Requisitos de conformidad como la separación de los entornos de producción y no producción.

Decisiones clave de diseño para los arrendamientos

Tome decisiones de diseño clave basadas en la siguiente información:

• Casos de uso aceptados para escalar la adopción de OCI con arrendamientos y organizaciones independientes
• Modelos operativos de arrendamiento, como el proceso para solicitar un nueva gestión del arrendamiento, la propiedad del arrendamiento, los costos y los presupuestos

Para obtener más información, consulte Gestión de organización y Gestión del arrendamiento.

Impedir que otros creen una cuenta de Oracle Cloud con su nombre de dominio público

Para aplicar una gobernanza sólida, es posible que algunas empresas necesiten tener un control centralizado de la creación de nuevas cuentas en la nube en un grupo de negocio.

Puede registrar su nombre de dominio público con OCI a través de Domain Management, que impide que otros reclamen ese dominio en el futuro para usar nuevas cuentas en la nube. Puede redirigir nuevos intentos para el registro de usuario que utilizan una dirección de correo electrónico corporativa desde ese dominio verificado.

Por ejemplo, si alguien que utiliza OCI intenta crear un arrendamiento con "companyA.com" en el dominio de correo electrónico, se evita el intento y se dirige en su lugar a OCI.

Como resultado, con la gestión de dominios, las grandes empresas pueden controlar más fácilmente sus entornos conociendo quién está creando arrendamientos y aplicando la política corporativa a los mismos. Puede verificar de forma segura la propiedad de sus dominios, y controlar más fácilmente el gasto y la gestión de recursos.

Normalmente, esto se trata en el arrendamiento principal como parte de la capacidad de gestión central. Necesita ayuda del administrador de dominio público para agregar el registro TXT proporcionado por OCI para verificar la propiedad del dominio. Este proceso de verificación de dominio puede tardar hasta 72 horas en terminar.

Nota: Puede evitar que otros usuarios creen una cuenta de Oracle Cloud con el dominio verificado mediante la gestión de dominios. Utilizamos Oracle Notification para notificarle si alguien intenta crear una cuenta con su dominio.

Nota: Puede bloquear otras líneas de negocio para crear sus propias cuentas activando esta función si comparte un dominio. Le recomendamos que active esta función mediante el uso de su equipo de administración central y la comunicación adecuada con las partes interesadas relacionadas, como las líneas de negocio afectadas.

Decisiones clave de diseño para la estructura de los arrendamientos

Para obtener más información, consulte Gestión de organización y Gestión del arrendamiento.

Dominios de identidad de IAM

Un dominio de identidad es un contenedor para gestionar usuarios y roles, federar y aprovisionar usuarios, proteger la integración de aplicaciones mediante configuraciones de conexión única (SSO) y la administración de proveedores de identidad basada en SAML/OAuth. El dominio representa una población de usuarios en OCI y sus configuraciones y valores de seguridad asociados, como la autenticación multifactor (MFA).

Puede crear y gestionar varios dominios de identidad (por ejemplo, un dominio para desarrollo y otro para producción). Cada dominio puede tener diferentes requisitos de identidad y seguridad para proteger sus aplicaciones y servicios de OCI.

El uso de varios dominios de identidad ofrece varias ventajas. Al tener dominios de identidad independientes, los usuarios que trabajan en un dominio de identidad no tienen ningún impacto en el trabajo de los usuarios de otro dominio de identidad.

El uso de varios dominios de identidad puede ayudarle a mantener el aislamiento del control administrativo en cada dominio de identidad. Se necesitan varios dominios de identidad, por ejemplo, cuando los estándares de seguridad impiden que los identificadores de usuario para el desarrollo existan en el entorno de producción. También se utilizan varios dominios cuando se requiere que diferentes administradores tengan el control de varios entornos.

Consideraciones de diseño para los dominios de identidad

Tenga en cuenta la siguiente información al diseñar la estructura de IAM:

• La necesidad de separar identificadores de usuario y administradores en entornos y cargas de trabajo. Por ejemplo:
  • Producción en comparación con entornos de desarrollo
  • Cargas de trabajo orientadas al personal en comparación con las cargas de trabajo orientadas al cliente
  • Empleados en comparación con los contratistas
• Los administradores pueden crear tantos dominios de identidad secundarios como permitan sus límites de servicio.
• Puede cambiar la versión del dominio de identidad por defecto o secundario a otro tipo de dominio. Cada tipo de dominio de identidad está asociado a diferentes funciones y límites de objetos.

La siguiente información resume las diferencias clave entre el dominio de identidad predeterminado y los dominios de identidad secundarios.

Casos de uso de ejemplo para dominios de identidad

Considere los siguientes casos de uso de ejemplo para tener dominios de identidad independientes:

• El uso de la separación del entorno, ya que algunos estándares de seguridad y regulaciones del sector requieren que se separen los usuarios de los entornos de producción y desarrollo, lo que evita el acceso del desarrollo a la producción.
• Separación de los usuarios externos, como los clientes y los contratistas, de las identidades de los empleados.

Recomendaciones para los dominios de identidad

Siga estas recomendaciones al configurar los dominios:

• Utilice diferentes dominios de identidad para cada población de usuarios.
• Utilice el dominio de identidad por defecto para la administración de nivel de arrendamiento. Utilice dominios de identidad secundarios para los servicios de plataforma como servicio (PaaS) y administración específicos del entorno con el fin de tener más control sobre el comportamiento del dominio, como el ciclo de vida, la región principal y la replicación.
• Empiece por el dominio de identidad Oracle Apps/Gratuito para escenarios solo en la nube y cambie la versión a Premium/Oracle Apps Premium por disponer de límites superiores o para dar soporte a casos de uso avanzados. Por ejemplo:
  • Realice la autenticación en aplicaciones de Oracle locales o alojadas en la nube.
  • Utilice la sincronización bidireccional con Active Directory u otros sistemas de IAM.
  • Utilice funciones modernas de AuthN/AuthZ, como la autenticación sin contraseña, los tokens de hardware FIDO2 y las soluciones de seguridad adaptativa.
• Cree un dominio de identidad externo secundario para casos de uso orientados al consumidor y no empleados que requieran los siguientes recursos:
  • Conexión social, contraseña de autoservicio de usuario, gestión de perfiles y consentimiento de condiciones de uso.
  • Identidad como servicio (IDaaS) con todas las funciones que se puede escalar para millones de usuarios.
  • Sin acceso a la gestión de derechos de OCI. Algunos ejemplos son la gestión del acceso a los recursos de OCI y las funciones de IAM orientadas al personal para el aprovisionamiento en aplicaciones de terceros que utilizan el catálogo de aplicaciones y la sincronización de Active Directory.

Decisiones de diseño clave para dominios de identidad

• Apruebe los casos de uso aceptables para tener dominios de identidad secundarios adicionales para aislamientos de IAM.
• Decida la región principal del dominio de IAM, que no se puede cambiar después de la creación.
• Decida si alguna función de IAM principal es obligatoria, como la sincronización bidireccional con LDAP/AD por puente, EBS Asserter y el proxy RADIUS.
• Decida la propiedad y la administración del dominio de IAM de usuario externo si se necesitan funciones como la conexión social, la contraseña de autoservicio de usuario y la gestión de perfiles.

Para obtener más información, consulte Tipos de dominio de identidad de IAM.

Compartimentos y estructura de etiquetado para políticas de IAM bien otorgadas

Utilice compartimentos y etiquetas para organizar y aislar recursos para el control de acceso.

Conceptos básicos de las políticas de IAM

• La política de IAM es una sentencia que especifica quién puede acceder a qué recursos de OCI de la compañía y cómo.

• Debido a que OCI no otorga acceso por defecto, su organización necesita al menos una política para empezar a controlar el control de sus recursos. Cada política consta de una o más sentencias de políticas que siguen esta sintaxis básica:

  Permitir a <subject> <verb> <resource-type> en <location> donde <conditions>

• La siguiente información describe los tres grupos principales de políticas de IAM.

• Debido a que el cambio de acceso de los servicios de OCI y Dynamic Group puede provocar interrupciones de los servicios si no se manejan correctamente, le recomendamos que publique estos tipos de cambios mediante un arrendamiento/entorno canario para evitar introducir cambios de última hora en la producción.
• Puede otorgar controles de acceso mediante la organización de recursos con compartimentos y etiquetas.

Consideraciones de diseño para compartimentos y etiquetas

Tenga en cuenta la siguiente información al configurar compartimentos y etiquetas:

• Compartimentos:

  • Los compartimentos abarcan todo el arrendamiento y pueden abarcar regiones. Cuando crea un compartimento, este estará disponible en cada región a la que esté asociado el arrendamiento.
  • Puede crear subcompartimentos en otros compartimentos para crear jerarquías con hasta seis niveles de profundidad. Un subcompartimento hereda los permisos de acceso de los compartimentos situados por encima de él en la jerarquía.

  

  • El compartimento es una de las unidades obligatorias de otorgamiento de control de acceso. Puede acotar aún más el compartimento mediante cláusulas condicionales.

• Etiquetas: puede utilizar el control de acceso basado en etiquetas para definir políticas de acceso que abarquen compartimentos, grupos y recursos. El uso del control de acceso basado en etiquetas puede ayudarle a evitar la duplicación de políticas de IAM, garantizar la coherencia y minimizar la sobrecarga de gestión.

  Atención: las claves de etiquetas definidas no son sensibles a mayúsculas/minúsculas, mientras que los valores de etiquetas definidas son sensibles a mayúsculas/minúsculas. Por ejemplo, "Env" y "ENV" son la misma clave de etiqueta. "Dev" y "DEV" son valores de etiqueta distintos.

• Política de IAM condicional:

  • La coincidencia de condiciones no es sensible a mayúsculas/minúsculas, el valor de etiqueta es sensible a mayúsculas/minúsculas y algunos tipos de recursos permiten la nomenclatura sensible a mayúsculas/minúsculas. Por ejemplo, considere la siguiente sentencia:

    Un usuario del grupo Group A puede acceder a recursos de compartimentos con la etiqueta Operations.Project= 'sample'. El usuario también puede acceder a los recursos de los compartimentos con la etiqueta Operations.Project= 'Sample'.

    >allow group GroupA to manage all-resources in tenancy where target.resource.compartment.tag.Operations.Project= 'sample'
    

  • Considere el uso de valores predefinidos en etiquetas definidas si se adopta el control de acceso basado en etiquetas. Consulte Trabajar con valores predefinidos.

  • Todos los servicios de OCI soportan variable de política request.principal.compartment, request.principal.group y target.resource.compartment.tag. Sin embargo, no todos los servicios soportan la variable target.resource.tag. Consulte Servicios soportados.

    Para conocer las funciones avanzadas de la política de IAM condicional, consulte Control de acceso basado en etiquetas y Control de acceso basado en tiempo.

Recomendaciones para compartimentos y etiquetas

Utilice las siguientes recomendaciones al configurar compartimentos y etiquetas:

• Cree y designe compartimentos para categorías de recursos específicas. Además, escriba políticas de IAM para permitir el acceso a los recursos solo a los grupos de usuarios que necesiten acceso.
• Divida las cargas de trabajo de producción y las cargas de trabajo que no son de producción en compartimentos distintos.
• Cree y utilice compartimentos secundarios para aislar recursos para más capas organizativas. Escriba políticas distintas para cada nivel de compartimento.
• Permita solo a los usuarios autorizados mover compartimentos a diferentes compartimentos principales y mover recursos de un compartimento a otro. Escriba políticas adecuadas para aplicar esta restricción.
• Limite el número de recursos de cada tipo que se pueden crear en un compartimento mediante la definición de cuotas de nivel de compartimento.
• Limite los recursos que puede gestionar un principal de instancia especificando un compartimento en la política de IAM.
• Asigne etiquetas a los recursos para organizarlos e identificarlos en función de sus necesidades empresariales.
  • Utilice compartimentos y el etiquetado para simplificar la gestión del acceso. Alinee el diseño del compartimento de OCI con las estructuras de su departamento o proyecto. Para obtener más información, consulte Gestión de compartimentos.
  • Si se adopta el control de acceso basado en etiquetas, asegúrese de que dispone de los controles adecuados para gestionar quién puede aplicar etiquetas.
  • Una vez definidas las políticas, recuerde que la aplicación de etiquetas a un grupo, un usuario o un recurso puede otorgar acceso a los recursos.
• Conserve el menor número de compartimentos posible. Esto hace que la navegación en la consola de OCI sea menos complicada.
• No combine con la seguridad de red. Los compartimentos tienen un impacto limitado en la carga de trabajo real.

Entornos múltiples

La siguiente información proporciona estrategias de aislamiento de entorno de ejemplo para diseñar estructuras de entorno. Es posible que su organización necesite una combinación de estas estrategias.

Nota: El diagrama no es una arquitectura de referencia, sino que proporciona casos de uso de ejemplo para la consideración del diseño.

• Tipo 0: este aislamiento de entorno no implica el uso compartido de recursos. Por lo general, es nuestra estructura de arrendamiento para el nivel máximo de aislamiento de recursos. Aparte de la razón de negocio estratégica mencionada anteriormente, es posible que también necesite este tipo de entorno para respaldar sus procesos de gestión de cambios. Por ejemplo, puede que necesite un entorno de prueba o de canario para que su equipo de plataforma en la nube implemente cambios a nivel de arrendamiento para evitar la introducción de interrupciones masivas en sus equipos de aplicaciones de una sola vez.
• Tipo 1: este aislamiento de entorno comparte recursos mínimos en el compartimento raíz, como políticas de activación de servicios de OCI y administradores de acceso de emergencia. Con un compartimento dedicado y un dominio de identidad adicional, puede tener varios entornos muy separados en un único arrendamiento que tengan su propio proveedor de identidad, política de acceso y recursos en la nube.
• Tipo 2: este aislamiento de entorno comparte algunos servicios clave selectivos, como el dominio de identidad y la conexión rápida, para mejorar la eficiencia de costos y administración. Normalmente se utiliza para entornos que no son de producción, como UAT, SIT y DEV. Algunas organizaciones también aceptan las prácticas para entornos de producción y preproducción.
• Tipo 3: este aislamiento de entorno comparte todos los servicios principales de la plataforma, como los servicios de seguridad y red. Normalmente se utiliza para gestionar cargas de trabajo de naturaleza similar con políticas de control comunes.
• Tipo 4: este aislamiento de entorno comparte infraestructuras de cargas de trabajo, como middleware, OKE y DB, en varias instancias de aplicación.

Mejores prácticas de IAM

Para obtener la información más reciente sobre las mejores prácticas de IAM, consulte las mejores prácticas para Identity and Access Managemen. Los aspectos más destacados son:

• No utilice el usuario y el grupo de administradores de dominio por defecto con el rol de administrador de dominio de identidad para las actividades diarias. En su lugar, cree un administrador independiente para gestionar recursos específicos en OCI.
• Compruebe periódicamente quién forma parte del grupo de administradores de dominio por defecto y quién tiene el rol de administrador de dominio de identidad en el dominio por defecto. Los usuarios que pertenecen a estos dos grupos son superadministradores y pueden gestionar todos los recursos en OCI.
• Utilice el dominio por defecto como dominio de inicio. No solo los usuarios del dominio por defecto pueden acceder a los recursos de OCI y gestionarlos, también los usuarios de un dominio secundario pueden acceder a todos los recursos de OCI y gestionarlos.
• Cree otros dominios secundarios para diversos casos de uso, como la segmentación de identidades (consumidor frente a empleados), la separación de entornos (desarrollo, prueba, producción) y el requerimiento de residencia de datos (creación de un dominio en una región geográfica concreta).
• Recomendamos utilizar un dominio secundario para abordar los fuertes requisitos de residencia de datos. Con los dominios secundarios, puede elegir las regiones geográficas en las que desea replicar un dominio.

Explorar más

• Best Practices for Identity and Access Management (IAM) in Oracle Cloud Infrastructure

• Aísle los recursos y controle el acceso
• Implantación de una convención de nomenclatura para recursos de OCI mediante etiquetado