Caso práctico ilustrativo de la organización basada en la UE

Aunque los detalles de las distintas funciones son informativos, resulta útil ilustrar la implantación de entornos con ejemplos. En los ejemplos a continuación, presentamos el concepto de un usuario sub-SC.

Un usuario de subSC tiene las siguientes características:

• Relacionado directamente con la entidad cliente por organización o tratado y tiene una relación gubernamental o comercial con la entidad cliente.
• Contiene íntegramente dentro de la UE y está sujeta al menos a los mismos requisitos de protección de datos y soberanía que la propia entidad cliente.
• No son simplemente grupos organizativos dentro del propio cliente, sino que son entidades por derecho propio. Esto podría ser una división gubernamental o una subsidiaria de una entidad corporativa comercial. Pueden tener un superjuego de requisitos en torno a la protección y clasificación de datos, pero no pueden caer por debajo de los requisitos mínimos de la propia entidad cliente. Por ejemplo, si un cliente de ejemplo mantenía un juego de compartimentos y recursos para sí mismo, pero proporcionaba acceso a los usuarios de subSC, el cliente mantendría el control sobre los recursos desplegados por el usuario de subSC de acuerdo con el marco legal particular del usuario de subSC.

Este caso práctico utiliza una situación hipotética en la que el cliente desea proporcionar un conjunto de servicios en la nube a un conjunto de organizaciones subsidiarias o usuarios de subSC, incluida la capacidad de esos usuarios de subSC para alojar sus propios servicios que interactúan con los servicios globales proporcionados por el propio cliente. El cliente controlaría el arrendamiento en términos de costos, asignación de compartimentos dentro del arrendamiento general y creación de grupos globales para la gestión del arrendamiento. Sin embargo, cada subSC tendría su propio entorno definido por los espacios de compartimento que "poseen" y que están totalmente controlados por su base de usuarios y que proporcionan a través de un dominio de identidad. En los compartimentos secundarios o "raíz" de cada sub-SC, se pueden crear compartimentos adicionales y desplegar recursos.

Los compartimentos de subSC serían exclusivos de cada usuario de subSC, sin que ningún otro usuario de subSC tuviera visibilidad de la estructura de compartimentos, los recursos o las actividades de otros usuarios de subSC. Los logs de auditoría y otras actividades de auditoría y conformidad se producen a nivel de cliente, pero se hacen visibles para cada dominio de identidad, filtrado por su compartimento "raíz" individual y restringido en función de su afiliación de identidad para obtener visibilidad. Esto permitiría tanto al cliente como al usuario individual del subSC auditar la detección de costos, cumplimiento y amenazas de forma independiente. Los recursos creados quedarán a discreción tanto del cliente (para sus propios compartimentos) como de cada usuario de subSC y podrían estar restringidos por las funciones de cuotas de compartimento y presupuestos de OCI en EU Sovereign Cloud.

Modelo de Seguridad de Ejemplo

El modelo de seguridad de este ejemplo se ilustra en el siguiente diagrama:

Descripción de la ilustración iam-security-model.png

iam-security-model-oracle.zip (modelo de seguridad de iam)

Aquí, el cliente establece un arrendamiento y crea un juego de compartimentos para su propio uso (los compartimentos "División") y un juego de compartimentos base para su uso por cada miembro de sub-SC. A medida que cada usuario de subSC se registra para utilizar recursos dentro del arrendamiento, se crea un dominio de identidad alrededor del compartimento de nivel superior específico creado para el usuario de subSC. El usuario de subSC podría federar su propia base de usuarios a su dominio de identidad individual y asignar permisos independientemente de los asignados por el cliente. Estos dominios podrían funcionar como entidades casi independientes, con relaciones que se definen en función de un acuerdo conjunto.

Caso de uso de protección de datos

El usuario de subSC tendría varias opciones no exclusivas para iniciar la protección de datos mediante EU Sovereign Cloud. El primero sería simplemente utilizar el modelo de protección de datos existente ilustrado anteriormente. El dominio de identidad de subSC es transitorio en todo el arrendamiento; en otras palabras, dado que el dominio de identidad es un recurso de todo el arrendamiento, las opciones de acceso están disponibles en ambas regiones en función de las políticas establecidas para el arrendamiento en su conjunto.

Los compartimentos también siguen este modelo. Esto permite a cada usuario de subSC realizar la replicación de datos mediante los recursos individuales creados en sus propios compartimentos, en dos regiones de datos, para actuar como destinos u orígenes de replicación. Esto permite el uso de modelos activos/activos y activos/pasivos de protección de datos, dependiendo de la capacidad de las aplicaciones individuales desplegadas por el sub-SC y la tolerancia RTO/RPO de aquellas que no pueden funcionar en activo/activo. La protección de datos sería independiente y aislada de la opinión de otros usuarios del subSC. Sería observable por el cliente que proporciona los servicios de línea base en virtud del hecho de que existe la replicación, pero no observando los datos en sí. Los servicios de copia de seguridad y/o instantánea están disponibles para su uso por parte del usuario de subSC (en el caso de Block Storage y Object Storage) y se localizarán en el dominio de identidad/compartimento de cada usuario de subSC al que no pueden acceder otros usuarios de subSC.

Como alternativa, cada usuario de subSC puede utilizar recursos de terceros o locales (dentro de los límites físicos del entorno de subSC) como destinos de protección de datos. Esto se lograría mediante el establecimiento de conexiones VPN privadas FastConnect o CPE a compartimentos bajo el control del subusuario de SC. La conexión de datos estaría completamente aislada del otro usuario de subSC y del cliente, ya que cada punto de conexión existiría exclusivamente dentro de la estructura de dominio de identidad/compartimento del propio usuario de subSC. Este modelo permitiría la protección y extracción de datos a un tercero, fuera del control del cliente, a un repositorio de datos local ubicado dentro de los límites físicos del entorno sub-SC, o una combinación de los mismos, dependiendo de las necesidades del usuario sub-SC individual.

Descripción de la ilustración security_structure_overview.png

security_structure_overview-oracle.zip