Etude de cas illustrative basée sur l'UE

Bien que les détails des différentes fonctionnalités soient informatifs, il est utile d'illustrer l'implémentation des environnements avec des exemples. Dans les exemples ci-dessous, nous présentons le concept d'utilisateur de sous-SC.

Un utilisateur de sous-SC présente les caractéristiques suivantes :
  • Directement lié à l'entité client par organisation ou traité et a une relation gouvernementale ou commerciale avec l'entité client.
  • Il est entièrement intégré dans l'UE et est soumis au moins aux mêmes exigences en matière de protection et de souveraineté des données que l'entité cliente elle-même.
  • Ce ne sont pas simplement des groupes organisationnels au sein du client lui-même, mais des entités à part entière. Il peut s'agir d'une division gouvernementale ou d'une filiale d'une société commerciale. Ils peuvent avoir un surensemble d'exigences en matière de protection et de classification des données, mais ne peuvent pas être inférieurs aux exigences minimales de l'entité client elle-même. Par exemple, si un exemple de client tenait à jour un ensemble de compartiments et de ressources pour lui-même mais donnait accès aux utilisateurs de sous-SC, le client conserverait le contrôle des ressources déployées par l'utilisateur de sous-SC conformément au cadre juridique particulier de l'utilisateur de sous-SC.
Cette étude de cas utilise une situation hypothétique dans laquelle le client souhaite fournir un ensemble de services cloud à un ensemble d'organisations subsidiaires ou d'utilisateurs de sous-SC, y compris la possibilité pour ces utilisateurs de sous-SC d'héberger leurs propres services qui interagissent avec les services globaux fournis par le client lui-même. Le client contrôle la location en termes de coûts, d'affectation de compartiments au sein de la location globale et de création de groupes globaux pour la gestion de la location. Cependant, chaque sous-service disposerait de son propre environnement défini par des espaces de compartiment qu'il possède et qu'il contrôle entièrement par sa base d'utilisateurs et qu'il fournit via un domaine d'identité. Dans les compartiments enfant ou "racine" de chaque sous-SC, des compartiments supplémentaires peuvent être créés et des ressources déployées.

Les compartiments de sous-SC seraient exclusifs à chaque utilisateur de sous-SC, aucun autre utilisateur de sous-SC n'ayant accès à la structure de compartiment, aux ressources ou aux activités des autres utilisateurs de sous-SC. Les journaux d'audit et les autres activités d'audit et de conformité ont lieu au niveau du client, mais sont rendus visibles par chaque domaine d'identité, filtrés par leur compartiment racine individuel et restreints en fonction de leur appartenance à l'identité pour plus de visibilité. Cela permettrait à la fois au client et à l'utilisateur du sous-service de vérifier indépendamment les coûts, la conformité et la détection des menaces. Les ressources créées sont à la discrétion du client (pour ses propres compartiments) et de chaque utilisateur de sous-service et peuvent être restreintes par les fonctionnalités de quotas et de budgets de compartiment OCI dans le cloud souverain de l'UE.

Exemple de modèle de sécurité

Le modèle de sécurité de cet exemple est illustré dans le diagramme ci-dessous :


La description de iam-security-model.png suit
Description de l'image iam-security-model.png

iam-sécurité-modèle-oracle.zip

Ici, le client établit une location et construit à la fois un ensemble de compartiments pour son propre usage (les compartiments "Division") et un ensemble de compartiments de base pour chaque membre du sous-SC. Au fur et à mesure que chaque utilisateur de sous-SC s'inscrit pour utiliser les ressources de la location, un domaine d'identité est créé autour du compartiment de niveau supérieur spécifique créé pour l'utilisateur de sous-SC. L'utilisateur du sous-SC peut ensuite fédérer sa propre base d'utilisateurs avec son domaine d'identité individuel et allouer des autorisations indépendantes de celles allouées par le client. Ces domaines pourraient fonctionner comme des entités quasi indépendantes, avec des relations qui sont définies sur la base d'un accord conjoint.

Cas d'utilisation de la protection des données

L'utilisateur du sous-SC dispose de plusieurs options non exclusives pour initier la protection des données à l'aide du cloud souverain de l'UE. La première consisterait simplement à utiliser le modèle de protection des données existant illustré ci-dessus. Le domaine d'identité de sous-SC est transitoire dans l'ensemble de la location. En d'autres termes, étant donné que le domaine d'identité est une ressource à l'échelle de la location, les options d'accès sont disponibles dans les deux régions en fonction des stratégies établies pour la location dans son ensemble.

Les compartiments suivent également ce modèle. Cela permet à chaque utilisateur de sous-système d'effectuer une réplication de données en utilisant les ressources individuelles créées dans leurs propres compartiments (dans deux régions de données) pour agir en tant que cibles ou sources de réplication. Cela permet l'utilisation de modèles actifs/actifs et actifs/passifs de protection des données, en fonction de la capacité des applications individuelles déployées par le sous-SC et de la tolérance RTO/RPO de ceux qui ne peuvent pas travailler en actif/actif. La protection des données serait indépendante et isolée du point de vue des autres utilisateurs du SCC. Il serait observable par le client qui fournit les services de base en raison du fait que la réplication existe, mais pas en observant les données elles-mêmes. Les services de sauvegarde et/ou d'instantané peuvent être utilisés par l'utilisateur du sous-SC (dans le cas de Block Storage et d'Object Storage) et sont localisés dans le domaine d'identité/compartiment de chaque sous-SC, inaccessible aux autres utilisateurs du sous-SC.

Chaque utilisateur de sous-SC peut également utiliser des ressources tierces ou locales (dans les limites physiques de l'environnement de sous-SC) comme cibles de protection des données. Pour ce faire, il faudrait établir des connexions VPN privées FastConnect ou CPE à des compartiments sous le contrôle de l'utilisateur du sous-SC. La connexion de données serait complètement isolée de l'autre utilisateur du sous-SC et du client, car chaque point de connexion existerait exclusivement dans la structure de domaine d'identité/compartiment de l'utilisateur du sous-SC lui-même. Ce modèle permettrait la protection et l'extraction des données à un tiers, en dehors du contrôle du client, vers un référentiel de données local situé dans les limites physiques de l'environnement du sous-SC, ou une combinaison de celles-ci, en fonction des besoins de chaque utilisateur du sous-SC.


Description de l'image security_structure_overview.png
Description de l'image security_structure_overview.png

security_structure_overview-oracle.zip