Note :
- Ce tutoriel nécessite l'accès à Oracle Cloud. Pour vous inscrire à un compte gratuit, voir Démarrer avec le niveau gratuit d'Oracle Cloud Infrastructure.
- Il utilise des exemples de valeurs pour les données d'identification, la location et les compartiments d'Oracle Cloud Infrastructure. À la fin de votre laboratoire, remplacez ces valeurs par celles qui sont propres à votre environnement en nuage.
Plongez dans les politiques Oracle Cloud Infrastructure Identity and Access Management basées sur des marqueurs
Présentation
Les politiques d'Oracle Cloud Infrastructure Identity and Access Management (OCI IAM) sont la pierre angulaire d'un environnement en nuage robuste et sécurisé. Ils fournissent un mécanisme puissant et flexible pour contrôler l'accès aux ressources OCI, qui garantit que seuls les utilisateurs et services autorisés peuvent effectuer des actions spécifiques sur les ressources désignées.
À la base, une politique OCI IAM est un ensemble d'énoncés déclaratifs écrits dans une syntaxe lisible qui dicte qui peut accéder à quoi et sous quelles conditions. Ces politiques permettent aux organisations d'appliquer le principe du moindre privilège, en accordant aux utilisateurs et aux services uniquement les autorisations dont ils ont besoin pour effectuer leurs tâches et rien de plus. Cela minimise les risques de sécurité tout en maintenant l'efficacité opérationnelle.
Les politiques du service OCI IAM sont appliquées à différents niveaux de la hiérarchie OCI, y compris les compartiments, la location et des ressources spécifiques, ce qui les rend hautement adaptables aux structures organisationnelles complexes. Grâce à l'héritage des politiques et au compartimentage d'OCI, les administrateurs peuvent établir des contrôles granulaires adaptés à leurs exigences opérationnelles et de sécurité particulières. Pour plus d'informations, voir Présentation des politiques OCI.
Dans ce tutoriel, nous allons examiner l'importance de l'optimisation des politiques, explorer les meilleures pratiques pour affiner les politiques afin d'obtenir des résultats optimaux et mettre en évidence les scénarios dans lesquels l'optimisation des politiques peut être exploitée à son plein potentiel.
Objectifs
-
Démystifier les composants et la syntaxe de la politique.
-
Découvrez pourquoi la mise au point des politiques OCI IAM est cruciale pour l'évolutivité et les limites des politiques.
-
Offrir de meilleures pratiques exploitables.
-
Soulignez le rôle du marquage dans la gestion des politiques.
-
Mettez en évidence les défis et les solutions courants grâce à la présentation de cas d'utilisation réels.
Préalables
-
Accès à une location OCI.
-
Compréhension de base des concepts OCI.
-
Connaissance du service OCI IAM.
-
Connaissance de la syntaxe des stratégies.
-
Compréhension des fonctions de base de compartimentation et de marquage.
-
Conscience du principe du moindre privilège.
-
La politique OCI limite les connaissances.
-
Expérience en matière de gouvernance et de normes de conformité.
Démystifier les composants et la syntaxe de politique
Pour ajuster efficacement les politiques OCI IAM, il est essentiel de comprendre leur structure et leurs composants clés. Les politiques d'OCI définissent les autorisations en spécifiant qui (principal), quelle (action) sur quoi (ressource) et où (portée). Décrivons ceci :
Composants clés d'une politique OCI IAM
-
Principal (Objet) : Entité demandant l'accès, qui peut être l'un des suivants :
-
Utilisateur : Compte individuel dans OCI, représentant généralement une personne. Pour plus d'informations, voir Gestion des utilisateurs.
-
Groupe : Collection d'utilisateurs ayant des besoins d'accès partagé. Pour plus d'informations, voir Utilisation des groupes.
-
Groupe dynamique : Jeu de ressources OCI (par exemple, instances de calcul, fonctions) identifié par des règles spécifiques. Les ressources d'un groupe dynamique sont automatiquement regroupées en fonction de critères tels que les marqueurs ou les métadonnées. Pour plus d'informations, voir Gestion des groupes dynamiques.
-
Principal de ressource : Service (comme OCI Functions ou Oracle Autonomous Database) agissant en son propre nom. Les principaux de ressource permettent aux services de s'authentifier en toute sécurité avec OCI et d'autres ressources sans nécessiter de données d'identification explicites. Pour plus d'informations, voir Authentification du principal de ressource.
-
Principal d'instance : Type de principal de ressource propre aux instances de calcul. Il permet aux instances d'interagir directement avec les services OCI (par exemple, OCI Object Storage ou Identity) à l'aide des politiques OCI IAM, sans intégrer les données d'identification dans l'application s'exécutant sur l'instance. Pour plus d'informations, voir Instance Principals.
-
-
Action (Verbe) : Spécifie les opérations que le principal peut effectuer :
inspect
: Voir les métadonnées sur la ressource.read
: Voir les métadonnées et les données dans la ressource.use
: Effectuer des actions de lecture et des opérations de gestion limitées.manage
: Effectuez toutes les actions, y compris la création et la suppression de ressources.
Pour plus d'informations, voir Opérations.
-
Ressource (Type de ressource) : Définit le type de ressource OCI auquel l'action s'applique, par exemple :
- Instances de calcul, seaux de stockage, réseaux en nuage virtuels, bases de données, etc.
- Les ressources peuvent être organisées de manière hiérarchique à l'aide de compartiments pour une meilleure gestion.
Pour plus d'informations, voir Ressources.
-
Portée (emplacement) : Spécifie l'emplacement où la politique s'applique :
- Compartiment : Conteneur logique pour les ressources, permettant l'organisation hiérarchique.
- Location : Tout le compte OCI, généralement utilisé pour les autorisations globales.
Pour plus d'informations, voir Emplacement.
-
Règle de correspondance (conditions) : Spécifiez une ou plusieurs conditions. Utilisez any ou all avec plusieurs conditions pour un opérateur logique OR ou AND, respectivement.
- Syntaxe pour une seule condition :
variable =|!= value
. - Syntaxe pour plusieurs conditions :
any|all {<condition>,<condition>,...}
.
Pour plus d'informations, voir Conditions.
- Syntaxe pour une seule condition :
Conseil supplémentaire : Présentation du concept d'intersection de jeux dans la politique IAM pour OCI
L'intersection des jeux dans les politiques OCI IAM est utilisée pour accorder l'accès uniquement en cas de chevauchement entre deux jeux de valeurs. Cela garantit que les autorisations sont accordées dynamiquement en fonction de l'appartenance à un groupe, des marqueurs de ressource ou d'autres attributs, plutôt que de coder en dur des utilisateurs ou des groupes spécifiques dans les politiques.
-
Exemple d'intersection de jeux dans la politique IAM pour OCI
Allow any-user to manage database-family-resources in tenancy where sets-intersect(request.groups.name, target.resource.compartment.tag.database.admins)
Rompre l'énoncé de politique :
-
Autoriser tout utilisateur : Cette politique s'applique à tout utilisateur authentifié dans OCI (indépendamment de l'appartenance à un groupe spécifique).
-
pour gérer database-family-resources : Permet un contrôle administratif complet sur toutes les ressources liées aux bases de données (bases de données autonomes, systèmes de base de données, sauvegardes, etc.).
-
dans la location : La politique s'applique à l'ensemble de la location (tous les compartiments).
-
où sets-intersect(
request.groups.name
,target.resource.compartment.tag.database.admins
)request.groups.name
: Représente les groupes auxquels l'utilisateur appartient.target.resource.compartment.tag.database.admins
: Marqueur du compartiment qui contient la liste des groupes autorisés pouvant gérer les ressources de base de données de ce compartiment.- sets-intersect(…) : Garantit que l'accès n'est accordé que si l'utilisateur appartient à au moins un groupe listé dans le marqueur.
-
Modèle de politique OCI IAM à grande échelle
Les politiques du service OCI IAM sont l'un des éléments fondamentaux de la sécurisation des charges de travail sur OCI. Il est essentiel de pouvoir évoluer et prendre en charge une charge de travail importante pour nos clients. C'est pourquoi nous avons créé un modèle de politique qui nécessite un petit nombre de politiques, dans les limites des politiques d'OCI, qui fonctionnent pour toute taille de charge de travail. Voici quelques-unes des raisons d'adopter le modèle de politique évolutif. Pour plus d'informations, voir Service IAM avec des limites de domaines d'identité.
Le réglage des politiques du service IAM pour OCI est une tâche critique pour la maintenance d'un environnement en nuage sécurisé, évolutif et efficace tout en restant dans les limites des politiques d'OCI. Voici pourquoi ce processus est essentiel :
-
Limites et contraintes de politique : OCI applique des limites spécifiques au nombre de politiques pouvant être créées dans une location et des compartiments. Ces limites peuvent être rapidement épuisées dans les environnements à grande échelle ou complexes si les politiques ne sont pas optimisées.
-
Les principales raisons sont les suivantes :
- Éviter la redondance : La définition répétée de politiques similaires pour différents compartiments ou ressources peut entraîner un gonflement des politiques, ce qui complique leur gestion.
- Limites de politique de séjour dans OCI : OCI comporte un nombre maximal d'énoncés de politique par politique et par location. Le réglage garantit que vous n'atteignez pas ces limites prématurément.
-
-
Amélioration de la gérabilité : À mesure que les organisations se développent, la gestion de centaines de politiques sur plusieurs compartiments peut devenir fastidieuse sans mise au point. Politiques optimisées :
- Simplifiez la gestion en réduisant le nombre total de politiques.
- Améliorez la clarté et évitez les chevauchements ou les conflits de règles, facilitant ainsi le débogage et l'audit.
-
Extensibilité sur des environnements complexes : Des politiques mises au point permettent une mise à l'échelle transparente en :
- Utiliser des caractères génériques et des autorisations au niveau de la ressource, le cas échéant, pour réduire le besoin de règles propres à un compartiment ou à une ressource. Pour plus d'informations, voir Conditions.
- Tirer parti de l'héritage des politiques pour que les politiques de niveau supérieur s'appliquent aux compartiments enfants sans qu'il soit nécessaire d'avoir des énoncés en double. Pour plus d'informations, voir Héritage des politiques.
- Regroupement logique des utilisateurs et des ressources pour appliquer des autorisations plus larges, mais toujours sécurisées.
-
Optimisation des performances : OCI évalue les politiques lors de chaque demande d'accès. Un grand nombre de politiques redondantes ou trop spécifiques peuvent augmenter le temps d'évaluation, ce qui peut ralentir les décisions de contrôle d'accès. Des politiques optimisées réduisent les frais généraux et garantissent des opérations plus rapides et plus efficaces.
-
Respect du principe du moindre privilège : Lors de la mise au point pour l'évolutivité, il est essentiel de maintenir le principe du moindre privilège. Des politiques larges et non contrôlées peuvent compromettre la sécurité, il est donc essentiel de trouver un équilibre entre un accès minimal et l'évolutivité.
Le rôle du marquage dans la gestion des politiques
Le service de marquage est une fonction puissante dans OCI qui améliore considérablement la gestion des politiques en permettant un contrôle détaillé sur les ressources. Les marqueurs sont des étiquettes de métadonnées, représentées sous forme de paires clé-valeur, pouvant être associées à des ressources. Ils aident à organiser, gérer et appliquer un contrôle d'accès à grande échelle, particulièrement dans les environnements en nuage complexes comportant plusieurs équipes et projets. Pour plus d'informations, voir Aperçu du service de marquage.
Comment le service de marquage améliore la gestion des politiques
-
Simplifie l'identification des ressources : Les marqueurs fournissent un moyen unifié de catégoriser les ressources en fonction d'attributs tels que les projets, les environnements, les responsables ou les services. Cela simplifie le processus d'application des politiques à des sous-ensembles spécifiques de ressources.
Exemple : Le marquage des ressources avec
Project: ProjectX
active les politiques d'accès ciblées.Allow group Developers to manage instances in tenancy where tag.Project = 'ProjectX'
-
Activer l'application dynamique des politiques : Les politiques basées sur des marqueurs s'adaptent à la modification des attributs de ressource. Par exemple, si une nouvelle instance est marquée avec
Environment: Production
, elle hérite automatiquement des politiques définies pour les environnements de production.Exemple de politique :
Allow group QA to inspect instances in tenancy where tag.Environment = 'Test'
-
Gouvernance de projets et d'équipes multiples dans les lignes de flux : Les marqueurs aident à isoler l'accès en associant des ressources à des équipes ou à des projets spécifiques. Cela réduit la complexité lors de la gestion des autorisations pour plusieurs groupes.
-
Automatisation facilitée : Les marqueurs peuvent piloter des flux de travail automatisés pour la création, la surveillance et la gestion du cycle de vie des ressources. Par exemple, les scripts de suivi des coûts peuvent extraire toutes les ressources marquées avec CostCenter : Marketing pour générer des rapports de frais détaillés.
-
Amélioration de la gestion et de la production de rapports des coûts : Les marqueurs permettent une attribution granulaire des coûts à des projets, services ou environnements spécifiques. Cela aide les organisations à suivre les dépenses et à optimiser les budgets plus efficacement.
Gouvernance des marqueurs : Contrôler la gestion des marqueurs
Pour assurer la cohérence, la fiabilité et la sécurité de la gestion des politiques, la création et la modification des marqueurs doivent être étroitement contrôlées. La gouvernance garantit que les marqueurs sont appliqués correctement et qu'ils sont conformes aux normes organisationnelles. Limiter la gestion des marqueurs à un ensemble spécifique de personnes ou de groupes est un élément clé du maintien du contrôle, de la cohérence et de la sécurité dans l'environnement en nuage d'une organisation.
-
Pourquoi restreindre la gestion des marqueurs?
Le marquage est un outil puissant pour organiser et contrôler les ressources, mais s'il est mal géré, il peut entraîner des contrôles d'accès incohérents ou non autorisés, des problèmes de suivi des coûts et des problèmes de gouvernance. En mettant en œuvre des politiques strictes concernant les personnes pouvant gérer les marqueurs, les organisations peuvent s'assurer que seul le personnel autorisé peut créer, modifier ou supprimer des marqueurs critiques, tout en préservant l'intégrité de l'environnement.
-
Prévenir les modifications non autorisées : Les marqueurs sont souvent liés à des processus d'affaires importants, tels que la ventilation des coûts, la catégorisation des ressources et le contrôle d'accès. L'autorisation d'un accès sans restriction à la modification des marqueurs peut entraîner des modifications non autorisées ou accidentelles, ce qui peut perturber les opérations ou entraîner une mauvaise affectation des ressources.
-
Assurer des normes de marquage cohérentes : Les organisations bénéficient de schémas de marquage normalisés qui facilitent l'organisation des ressources et le suivi. En limitant la gestion des marqueurs à un groupe défini d'administrateurs, les organisations peuvent assurer le respect de ces normes et éviter toute fragmentation et toute incohérence dans les pratiques de marquage.
-
Gérer la sécurité et la conformité : Les marqueurs peuvent être utilisés pour appliquer les politiques de sécurité et les exigences de conformité. Par exemple, les marqueurs peuvent définir des environnements (par exemple, Production, Développement) ou des classifications de données sensibles. L'autorisation de modifier ces marqueurs uniquement pour les utilisateurs autorisés garantit que les environnements sensibles sont protégés et que les contrôles d'accès sont appliqués correctement.
-
Réduire le risque d'une mauvaise configuration des politiques : Les politiques basées sur des marqueurs dans OCI (telles que le contrôle d'accès aux ressources) dépendent d'une utilisation cohérente et précise des marqueurs. Si le mauvais groupe ou la mauvaise personne peut modifier ou supprimer des marqueurs, cela peut entraîner par inadvertance des politiques d'accès trop larges ou restrictives.
-
-
Comment restreindre la gestion des marqueurs dans OCI
Dans OCI, la gestion des marqueurs peut être contrôlée en créant et en appliquant des politiques IAM pour OCI qui définissent qui peut effectuer des opérations de marqueur telles que la création, la mise à jour ou la suppression de marqueurs. Ces politiques peuvent être adaptées pour accorder l'accès à des utilisateurs, groupes ou compartiments spécifiques, afin que seules les personnes autorisées aient le pouvoir de modifier des marqueurs critiques.
Voici quelques façons de limiter la gestion des marqueurs à des personnes ou à des groupes spécifiques :
-
Utiliser le contrôle d'accès basé sur un groupe : La première étape du contrôle de la gestion des marqueurs consiste à s'assurer que seuls des groupes spécifiques disposent des autorisations nécessaires pour gérer les marqueurs. Par exemple, un groupe désigné tel que
TagAdmins
peut se voir accorder des autorisations exclusives pour gérer la création et les mises à jour de marqueurs.Exemple de politique OCI IAM :
Allow group TagAdmins to manage tag-namespaces in tenancy
Cette politique garantit que seul le groupe
TagAdmins
peut créer, modifier ou supprimer des marqueurs et des espaces de noms de marqueur sur l'ensemble de la location. Pour autoriser certains groupes tels que les ingénieurs devops ou les groupes Terraform Runner à utiliser ces marqueurs créés au moyen de la console pour les scripts, vous pouvez définir la politique suivante.Allow group devopsTeam to use tag-namespaces in tenancy Allow group terraformRunner to use tag-namespaces in tenancy Allow dynamic-group terraformRunner to use tag-namespaces in tenancy
-
Utiliser des politiques au niveau du compartiment pour le contrôle granulaire : Les politiques de gestion des marqueurs peuvent être appliquées au niveau du compartiment, de sorte que seuls certains compartiments disposent d'un accès à la gestion des marqueurs. Par exemple, si vous voulez limiter la gestion des marqueurs à un projet ou à une unité d'affaires spécifique, vous pouvez appliquer des politiques qui limitent l'accès aux marqueurs dans le compartiment approprié.
Exemple de politique pour la gestion des marqueurs propres au compartiment :
Allow group TagAdmins to manage tag-namespaces in compartment ProjectA
Cela garantit que seuls les utilisateurs du groupe
TagAdmins
peuvent gérer les marqueurs dans le compartimentProjectA
, ce qui limite leur accès aux autres compartiments. De plus, vous pouvez créer des groupes pour autoriser uniquement les utilisateurs à utiliser les marqueurs créés, mais pas les modifier au niveau du compartiment.Allow group TagUser to use tag-namespaces in compartment ProjectA
-
Contrôle de marquage avec des espaces de noms de marqueur : OCI prend en charge
tag namespaces
, qui regroupe les marqueurs connexes. Vous pouvez contrôler qui peut gérer les marqueurs dans un espace de noms spécifique, ce qui permet un contrôle plus granulaire sur les utilisateurs ayant accès à des types de marqueurs spécifiques.Exemple de politique pour la gestion des marqueurs propres à un espace de noms :
Allow group TagAdmins to manage tag-namespaces in tenancy where tag.namespace = 'Billing'
Cela garantit que seuls les utilisateurs disposant des autorisations
TagAdmins
peuvent gérer les marqueurs dans l'espace de noms de facturation, ce qui assure une gouvernance plus stricte des marqueurs de suivi des coûts. -
Vérifier et surveiller les modifications de marqueur : Pour garantir la sécurité de la gestion des marqueurs, les organisations doivent mettre en oeuvre des politiques de vérification et de surveillance pour suivre les modifications apportées aux marqueurs. Les journaux de vérification d'OCI offrent une visibilité sur les actions liées à la création, à la suppression et à la modification de marqueurs. La surveillance de ces journaux permet d'identifier toute tentative non autorisée de modification de marqueurs ou de modèles suggérant une mauvaise gestion.
-
Politiques OCI IAM basées sur des marqueurs pour des cas d'utilisation en temps réel
Maintenant, avec tout ce que vous avez appris ci-dessus, travaillons à la mise au point des politiques OCI IAM pour les principes d'utilisateur et les principes d'instance dans des cas d'utilisation réels. Mais avant de le faire, il existe des politiques communes dont chaque client aura besoin, quel que soit son cas d'utilisation.
-
Politiques OCI IAM communes :
-
Politiques pour OCI IAM pour la gestion des utilisateurs : Le groupe
IAMAdmin
est responsable de la gestion des configurations associées à OCI IAM, telles que les domaines OCI IAM, les utilisateurs et les groupes.Allow group IAMAdmin to manage domains in tenancy Allow group IAMAdmin to manage users in tenancy Allow group IAMAdmin to manage groups in tenancy
-
Politiques OCI IAM pour la gestion des marqueurs : Le groupe
InfoSec
est responsable de la gestion des configurations liées à la sécurité, telles que les politiques OCI IAM, les utilisateurs et les espaces de noms de marqueur.Allow group InfoSec to manage tag-namespaces in tenancy Allow group InfoSec to manage policies in tenancy Allow group InfoSec to use users in tenancy Allow group InfoSec to manage groups in tenancy where all {target.group.name != ‘Administrators’, target.group.name != ‘InfoSec’}
-
Politiques OCI IAM pour (Terraform Runner) : Le groupe
terraform-runner
est dédié à l'exécution de scripts d'automatisation Terraform pour le provisionnement de l'infrastructure.Allow group terraform-runner to use tag-namespaces in tenancy Allow group terraform-runner to manage instance-family in compartment Tenants Allow group terraform-runner to manage virtual-network-family in compartment Tenants Allow group terraform-runner to manage volume-family in compartment Tenants Allow group terraform-runner to manage object-family in compartment Storage Allow group terraform-runner to manage secret-family in compartment Tenants Allow group terraform-runner to manage key-family in compartment Tenants
-
Adapter les politiques OCI IAM pour les principaux d'utilisateur
Modèle de politique OCI IAM : Dans ce modèle de politique, l'objectif est d'écrire un petit nombre de politiques plus faciles à gérer qui sont informées par des données (marqueurs dans notre cas), également connues sous le nom de contrôle d'accès basé sur des attributs. Nous ferons référence aux marqueurs affectés à la ressource cible ou au compartiment de la ressource cible pour le contrôle d'accès en tant que marqueurs d'autorisation.
Marqueurs d'autorisation : Définissez un marqueur d'autorisation pour chaque combinaison Verbe (Action) + Type de ressource de la location. Ils définissent une autorisation unique que vous devez affecter à un groupe d'utilisateurs pour les ressources cibles. La liste n'est pas définie et terminée une seule fois. Commencez par un petit nombre de balises d'autorisation. Une fois que vous obtenez un descripteur sur le modèle de politique, vous pouvez ajouter d'autres marqueurs d'autorisation. Pour ce tutoriel, nous allons créer un espace de noms de marqueur d'autorisation en tant que mgmt
. De plus, nous allons créer un espace de noms de marqueur (appelons infosec
) avec une clé de marqueur nommée gname
.
-
Pour la structure de compartiment suivante avec quatre types de ressource et pour affecter des autorisations de gestion et d'utilisation à ces ressources, nous créerons des marqueurs d'autorisation.
-
Pour chaque autorisation que vous devez affecter à une cible (dans la plupart des cas), créez un groupe. Nous affectons des marqueurs d'autorisation aux ressources (à l'aide des marqueurs par défaut du compartiment) et aux compartiments de ressources. La valeur de marqueur est le groupe qui doit avoir l'autorisation indiquée sur la ressource cible.
-
Une fois les marqueurs d'autorisation définis, nous pouvons écrire des politiques. Le résultat final est que nous n'aurons besoin que d'une seule politique par marqueur d'autorisation défini dans la location. La même politique pour l'autorisation donnée fonctionnera dans l'ensemble de la location.
-
À mesure que nous intégrons plus de charges de travail, s'il existe plus de types de ressource à gérer, vous devrez peut-être ajouter d'autres marqueurs d'autorisation et politiques pour ces marqueurs d'autorisation. Sinon, il vous suffit d'affecter des marqueurs d'autorisation existants à la nouvelle charge de travail avec un groupe d'utilisateurs qui devraient avoir l'accès. Nous n'avons pas besoin d'écrire de nouvelles politiques pour la nouvelle charge de travail.
Cette approche restera cohérente dans tous les exemples discutés ici, servant de base à la définition des groupes et politiques OCI IAM.
Exemple 1 : Compartiment pour chaque application
Étape 1 : Obtenir une compréhension complète de l'aperçu commercial du client
CompanyA est une entreprise technologique en pleine croissance qui développe et déploie plusieurs applications en nuage natives pour ses clients. Chaque application s'adresse à un segment de clientèle spécifique, avec des exigences de sécurité et de conformité strictes. Pour assurer l'isolement, l'extensibilité et un contrôle d'accès efficace, CompanyA organise ses ressources OCI à l'aide d'une approche de compartimentation structurée.
Étape 2 : Concevoir la structure de compartiment pour la charge de travail
Comme indiqué, CompanyA suit le modèle de politique OCI IAM pour l'ajustement de leurs politiques OCI IAM. Ils ont créé des compartiments distincts pour leurs applications afin de maintenir l'isolement des ressources.
Note : Seuls les administrateurs doivent être en mesure de gérer l'espace de noms de marqueur
mgmt
etinfosec
.
Étape 3 : Concevoir les marqueurs d'autorisation suivants de la combinaison de type Verb+Resource
Créer des groupes dans OCI.
-
Connectez-vous au domaine OCI IAM avec un compte d'administrateur ayant le privilège de créer des groupes.
-
Allez à Identité et sécurité et cliquez sur Domaines sous Identité.
-
Sélectionnez votre compartiment et cliquez sur le domaine pour lequel vous voulez créer les groupes.
-
Cliquez sur Groupes.
-
Définissez vos groupes en fonction des marqueurs d'autorisation. (Facultatif) ajoutez vos utilisateurs à ces groupes.
Note : Vous devrez créer des groupes pour une combinaison unique d'autorisation et de cible. Si le même groupe fonctionnel d'utilisateurs (NetworkAdmin) nécessite l'accès pour gérer le réseau sur toutes les cibles, vous avez besoin d'un seul groupe pour gérer l'accès sur toutes les cibles.
Voici les marqueurs d'autorisation et les groupes OCI IAM pour ces marqueurs. Suivez les étapes ci-dessus pour créer des groupes pour chaque marqueur d'autorisation défini.
-
Compartiment racine : Le compartiment racine sert de couche de gestion de niveau supérieur. Où nos groupes d'administrateurs seront marqués avec des marqueurs d'autorisation. Les marqueurs suivants sont les suivants :
- Administrateurs : Autorisation
manageall
pour la gestion globale de la location. - UseAdministrators : Autorisation
useall
pour accéder aux ressources sur l'ensemble de la location. - Vérificateur : Autorisation
readall
avec accès en lecture seule aux ressources pour la surveillance sur l'ensemble de la location.
- Administrateurs : Autorisation
-
Modèle de compartiment par application : CompanyA comporte plusieurs applications basées sur le nuage. Nous allons créer un compartiment parent distinct pour chaque application. Voyons comment ce modèle s'applique à l'application 1 (App1) et à l'application 2 (App2) en tant que compartiments parents.
-
Application 1 (App1) : Application destinée aux clients et hébergée sur OCI.
- Compartiment du réseau : Compartiment de toutes les ressources liées au réseau telles que les réseaux VCN, les sous-réseaux, etc. Maintenant, créons les marqueurs d'autorisation et leurs groupes OCI IAM respectifs.
- App1NetworkAdmin : Marqueur d'autorisation des ressources
managenetwork
pour les ingénieurs gérant les ressources de réseau pour App1. - App1NetworkUser : Marqueur d'autorisation des ressources
usenetwork
pour les développeurs ayant besoin d'un accès limité aux configurations réseau de App1. - App1NetworkReader : Marqueur d'autorisation des ressources
readnetwork
pour les vérificateurs vérifiant la configuration du réseau de App1.
- App1NetworkAdmin : Marqueur d'autorisation des ressources
- Compartiment de calcul : Compartiment pour les instances de calcul. Maintenant, créons les marqueurs d'autorisation et leurs groupes OCI IAM respectifs.
- App1ComputeAdmin : Marqueur d'autorisation des ressources
managecompute
pour les administrateurs de système qui provisionnent et ajustent les instances de calcul pour le système dorsal App1. - App1ComputeUser : Marqueur d'autorisation des ressources
usecompute
pour les développeurs déployant et testant les services dorsaux de App1. - App1ComputeReader : Marqueur d'autorisation des ressources
readcompute
pour les vérificateurs surveillant l'utilisation des ressources de calcul pour App1.
- App1ComputeAdmin : Marqueur d'autorisation des ressources
- Compartiment de données : Compartiment pour les ressources liées à la base de données et au stockage. Maintenant, créons les marqueurs d'autorisation et leurs groupes OCI IAM respectifs.
- App1DataAdmin : Marqueur d'autorisation des ressources
managedb
pour les administrateurs de base de données gérant des bases de données autonomes Oracle et le stockage d'objets OCI pour App1. - App1DataUser : Marqueur d'autorisation des ressources
usedb
pour les experts en science des données qui accèdent aux jeux de données à des fins d'analyse en ce qui concerne App1. - App1DataReader : Marqueur d'autorisation des ressources
readdb
pour les vérificateurs vérifiant les configurations de base de données de App1.
- App1DataAdmin : Marqueur d'autorisation des ressources
- Compartiment du réseau : Compartiment de toutes les ressources liées au réseau telles que les réseaux VCN, les sous-réseaux, etc. Maintenant, créons les marqueurs d'autorisation et leurs groupes OCI IAM respectifs.
-
Application 2 (App2) : Système interne de planification des ressources d'entreprise (ERP) pour les opérations de la société.
Note : Ici aussi, nous suivrons la même approche de structure de compartiment et créerons Compartiment de réseau, Compartiment de calcul et Compartiment de données sous le compartiment App2 parent. Pour éviter la redondance, il suffit de noter les marqueurs d'autorisation et les groupes OCI IAM pour App2.
-
Compartiment du réseau :
- App2NetworkAdmin : Marqueur d'autorisation des ressources
managenetwork
. - App2NetworkUser : Marqueur d'autorisation des ressources
usenetwork
. - App2NetworkReader : Marqueur d'autorisation des ressources
readnetwork
.
- App2NetworkAdmin : Marqueur d'autorisation des ressources
-
Compartiment de calcul :
- App2ComputeAdmin : Marqueur d'autorisation des ressources
managecompute
. - App2ComputeUser : Marqueur d'autorisation des ressources
usecompute
. - App2ComputeReader : Marqueur d'autorisation des ressources
readcompute
.
- App2ComputeAdmin : Marqueur d'autorisation des ressources
-
Compartiment de données :
- App2DataAdmin : Marqueur d'autorisation des ressources
managedb
. - App2DataUser : Marqueur d'autorisation des ressources
usedb
. - App2DataReader : Marqueur d'autorisation des ressources
readdb
.
- App2DataAdmin : Marqueur d'autorisation des ressources
-
-
Note : Appliquez un marqueur d'autorisation à une cible (la cible peut être une ressource ou un compartiment) pour dicter quel groupe aura cette autorisation spécifique sur la cible pour App1 et App2.
Étape 4 : Écrire des politiques IAM OCI pour ces marqueurs d'autorisation
Nous allons créer les politiques pour CompanyA à l'aide de la même approche que celle décrite ici : Avoir moins d'informations - Ajustement des politiques OCI IAM pour les groupes. Pour cela, créez un espace de noms de marqueur (nous appellerons infosec
) avec une clé de marqueur nommée gname
.
-
Connectez-vous au domaine OCI IAM avec un compte d'administrateur ayant le privilège de créer des politiques.
-
Allez à Identité et sécurité et cliquez sur Politiques sous Identité.
-
Sélectionnez le compartiment racine, puis cliquez sur Créer une politique.
-
Entrez le nom, la description de la politique et ajoutez également les énoncés de la politique. Cliquez sur Créer.
-
Politique sur toutes les ressources :
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)
Note : Suivez la même procédure pour définir toutes les politiques mentionnées ci-dessous et ajouter leurs énoncés de politique respectifs.
-
Politique 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)
-
Politique de réseau :
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)
-
Politique de calcul :
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)
-
Politique de base de données :
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)
-
Exemple 2 : Compartiment pour chaque client/locataire
Étape 1 : Obtenir une compréhension complète de l'aperçu commercial du client
Solutions CompanyB est un fournisseur indépendant de logiciels de premier plan qui fournit des applications SaaS basées sur des locataires dans l'infrastructure en nuage, la gestion des données et l'analyse. CompanyB sert plusieurs clients de tous les secteurs, offrant des solutions transparentes, sécurisées et évolutives. Leur succès repose sur l'utilisation d'OCI avec une structure compartimentale bien conçue pour gérer les ressources de manière efficace tout en respectant les exigences en matière de sécurité et de conformité.
Étape 2 : Concevoir la structure de compartiment pour la charge de travail
CompanyB a isolé les charges de travail de ses clients et créé un sous-compartiment dédié. Ils disposent également d'un compartiment de réseau, d'un stockage partagé et d'un compartiment de base de données. Même CompanyB suit le modèle de politique de l'OCI IAM pour ajuster ses politiques OCI IAM.
Étape 3 : Concevoir les marqueurs d'autorisation suivants de la combinaison de type Verb+Resource
Pour créer des groupes, voir l'exemple 1 étape 3. Vous devrez créer des groupes pour tous vos marqueurs d'autorisation définis ci-dessous.
-
Compartiment racine - Gouvernance centralisée : Le composant racine sert de couche centrale pour la supervision de toutes les ressources et activités dans l'ensemble de la location OCI. Où nos groupes d'administrateurs seront marqués avec des marqueurs d'autorisation. Les marqueurs suivants sont les suivants :
- Administrateurs : Autorisation
manageall
pour la gestion globale de la location. - UseAdministrators : Autorisation
useall
pour accéder aux ressources sur l'ensemble de la location. - Vérificateur : Autorisation
readall
avec accès en lecture seule aux ressources pour la surveillance sur l'ensemble de la location.
- Administrateurs : Autorisation
-
Compartiment du réseau - Base des opérations : Le compartiment de réseau prend en charge l'infrastructure de réseau en nuage de CompanyB, ce qui permet la connectivité sur toutes les ressources. Cela inclut les réseaux en nuage virtuels, les sous-réseaux, les passerelles et les équilibreurs de charge. Définissons les marqueurs d'autorisation et les groupes OCI IAM correspondants.
- NetworkAdmin : Marqueur d'autorisation des ressources
managenetwork
pour les ingénieurs gérant les ressources de réseau pour CompanyB. - NetworkUser : Marqueur d'autorisation des ressources
usenetwork
pour les développeurs ayant besoin d'un accès limité aux configurations réseau de CompanyB. - NetworkReader : Marqueur d'autorisation des ressources
readnetwork
pour les vérificateurs vérifiant la configuration réseau de CompanyB.
- NetworkAdmin : Marqueur d'autorisation des ressources
-
Compartiment des locataires - Compartiments isolés pour différentes charges de travail de client : Le compartiment des locataires est structuré de manière à isoler les ressources et les charges de travail de chaque client (locataire). Cela garantit que CompanyB fournit des services sécurisés et privés tout en maintenant l'efficacité opérationnelle.
-
Compartiment du locataire 1 : Le locataire 1 représente un client d'entreprise majeur qui utilise CompanyB pour les services de développement d'applications et de journalisation. Les marqueurs d'autorisation et les groupes OCI IAM respectifs sont les suivants :
t1devadmin
: L'autorisation de ressourcemanageappdev
pour l'équipe de développement du locataire 1 dispose de privilèges d'administration pour configurer et déployer des applications personnalisées.t1devuser
: Autorisation de ressourceuseappdev
pour surveiller et ajuster les ressources d'application. Les développeurs de Tenant 1 utilisent ces ressources pour le développement et les tests quotidiens.t1logsadmin
ett1devuser
: L'autorisation de ressourcemanagelogs
etuselogs
pour les rôles de journalisation et de surveillance garantit que les administrateurs configurent les services de journalisation pendant que les développeurs accèdent aux journaux pour déboguer et optimiser les applications.t1devadmin
ett1devuser
: Autorisation de ressourcemanagecspm
etusecspm
pour le locataire 1, car il se concentre également sur l'état de sécurité, avec la possibilité de surveiller et de corriger les risques de sécurité.
-
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
andt3logsadmin
ensuring that each tenant operates in a fully isolated environment. Cette approche permet à CompanyB de maintenir une gouvernance uniforme tout en répondant aux besoins spécifiques des locataires. -
Compartiment partagé - Ressources centralisées pour tous les locataires : Le compartiment partagé comprend des ressources telles que les bases de données et le stockage d'objets utilisés par plusieurs locataires, mais qui restent logiquement séparés pour assurer la confidentialité et la sécurité.
- Compartiment de la base de données :
dbadmin
: Autorisation de ressourcemanagedb
pour les administrateurs de base de données de CompanyB qui gère les bases de données partagées utilisées par tous les locataires, y compris le provisionnement, l'ajustement et l'application de correctifs.dbuser
: Autorisation de ressourceusedb
pour les utilisateurs propres au locataire accèdent à leurs schémas ou services de base de données respectifs.dbreader
: L'autorisation de ressourcesreaddb
pour les vérificateurs est accessible en lecture seule pour s'assurer que les configurations de base de données sont conformes aux politiques de sécurité.
- Compartiment de stockage : Le service de stockage d'objets pour OCI est géré de manière centralisée, avec des seaux dédiés pour chaque locataire :
osadmin
: Autorisation de ressourcemanageobject
permettant de gérer les ressources de stockage d'objets partagées.osuser
:useobject
L'autorisation de ressource de stockage propre au locataire (ou, par exemple,t1osur
,t2osur
,t3osur
) garantit que les locataires accèdent uniquement à leurs seaux respectifs.osreader
: L'autorisation de ressourcesreadobject
pour les équipes de conformité passe en revue les configurations du stockage et les modèles d'utilisation.
- Compartiment de la base de données :
-
Étape 4 : Écrire des politiques IAM OCI pour ces marqueurs d'autorisation
Pour créer des politiques, voir Exemple 1 étape 4. Vous devrez créer les politiques suivantes.
-
Politique sur toutes les ressources :
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)
-
Politique 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)
-
Politique de réseau :
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)
-
Politique de journaux :
Allow any-user to manage logging-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.managelogs) Allow any-user to use logging-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.uselogs) Allow any-user to read logging-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readlogs)
-
Politique d'Appdev :
Allow any-user to manage instance-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.manageappdev) Allow any-user to use instance-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.useappdev) Allow any-user to read instance-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readappdev)
-
Politique de base de données :
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)
-
Politique de stockage :
Allow any-user to manage object-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.manageobject) Allow any-user to use object-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.useobject) Allow any-user to read object-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readobject)
Exemple 3 : Grande structure de compartiment d'entreprise
Étape 1 : Obtenir une compréhension complète de l'aperçu commercial du client
Solutions CompanyC, organisation multinationale spécialisée dans les solutions logicielles innovantes, a décidé de migrer ses charges de travail critiques vers OCI. La société opère dans des secteurs hautement réglementés tels que la finance et les soins de santé, où la sécurité, la conformité et l'évolutivité sont de la plus haute importance.
Étape 2 : Concevoir la structure de compartiment pour la charge de travail
Explorons maintenant la structure de compartiments pour CompanyC, qui suit le modèle de politique OCI IAM pour l'ajustement de leurs politiques OCI IAM.
Étape 3 : Concevoir les marqueurs d'autorisation suivants de la combinaison de type Verb+Resource
Pour créer des groupes, voir l'exemple 1 étape 3. Vous devez créer des groupes pour tous les marqueurs d'autorisation suivants.
-
Compartiment racine - Gouvernance centralisée : Le composant racine sert de couche centrale pour la supervision de toutes les ressources et activités dans l'ensemble de la location OCI. Où nos groupes d'administrateurs seront marqués avec des marqueurs d'autorisation. Les marqueurs suivants sont les suivants :
- Administrateurs : Autorisation
manageall
pour la gestion globale de la location. - UseAdministrators : Autorisation
useall
pour accéder aux ressources sur l'ensemble de la location. - Vérificateur : Autorisation
readall
avec accès en lecture seule aux ressources pour la surveillance sur l'ensemble de la location.
- Administrateurs : Autorisation
-
Compartiment PROD : Compartiment d'hébergement de charges de travail de production critiques qui ont une incidence directe sur les opérations commerciales et les utilisateurs finaux. Chaque application comporte son sous-compartiment dédié pour l'isolement des ressources et une gestion optimisée. Définissons les marqueurs d'autorisation et les groupes OCI IAM correspondants.
- NetworkAdmin : Marqueur d'autorisation des ressources
managenetwork
pour les ingénieurs gérant les ressources de réseau pour CompanyC. - NetworkReader : Marqueur d'autorisation des ressources
readnetwork
pour les vérificateurs vérifiant la configuration réseau de CompanyC. - ComputeAdmin : Marqueur d'autorisation des ressources
managecompute
pour les administrateurs de système qui provisionnent et ajustent les instances de calcul pour CompanyC. - ComputeReader : Marqueur d'autorisation des ressources
readcompute
pour les vérificateurs surveillant l'utilisation des ressources de calcul pour CompanyC. - StorageReader : Autorisation de ressource
manageobject
pour les équipes d'administration du stockage afin de gérer les configurations de stockage. - StorageReader : L'autorisation de ressources
readobject
pour les équipes de conformité passe en revue les configurations du stockage et les modèles d'utilisation. - SecurityAdmin : Autorisation de ressource
managecspm
pour Compartment PROD, car elle met également l'accent sur la sécurité, avec la possibilité de surveiller et de corriger les risques de sécurité.
Nous allons maintenant définir les marqueurs d'autorisation et les groupes OCI IAM respectifs pour les sous-compartiments propres à l'application. Dans l'intérêt du temps, nous avons fusionné et défini des autorisations pour les 3 compartiments d'application différents.
- Compartiments d'application :
- PRApp1NetAdmin, PRApp2NetAdmin et PRApp3NetAdmin : Administrez les groupes IAM OCI avec un marqueur d'autorisation
managenetwork
ressources pour les ingénieurs gérant les ressources de réseau pour App1, App2 et App3, respectivement. - PRApp1NetUser, PRApp2NetUser et PRApp3NetUser : Administrez les groupes OCI IAM avec un marqueur d'autorisation des ressources
usenetwork
pour les ingénieurs gérant les ressources de réseau pour App1, App2 et App3, respectivement. - PRApp1ComputeAdmin, PRApp2ComputeAdmin et PRApp3ComputeAdmin : Administrez les groupes OCI IAM avec le marqueur d'autorisation des ressources
managecompute
pour les ingénieurs gérant les instances OCI Compute pour App1, App2 et App3 respectivement. - PRApp1ComputeUser, PRApp2ComputeUser et PRApp3ComputeUser : Administrez les groupes OCI IAM avec le marqueur d'autorisation des ressources
usecompute
pour les ingénieurs utilisant des instances OCI Compute pour App1, App2 et App3, respectivement. - PRApp1StorageAdmin, PRApp2StorageAdmin et PRApp3StorageAdmin : Administrez les groupes OCI IAM avec le marqueur d'autorisation des ressources
manageobject
pour les ingénieurs gérant le service de stockage d'objets OCI pour App1, App2 et App3, respectivement. - PRApp1StorageUser, PRApp2StorageUser et PRApp3StorageUser : Administrez les groupes IAM OCI avec le marqueur d'autorisation des ressources
useobject
pour les ingénieurs utilisant le service de stockage d'objets pour OCI pour App1, App2 et App3, respectivement.
- PRApp1NetAdmin, PRApp2NetAdmin et PRApp3NetAdmin : Administrez les groupes IAM OCI avec un marqueur d'autorisation
- NetworkAdmin : Marqueur d'autorisation des ressources
-
Compartiment NPROD : Dédié aux environnements de production, de développement et d'assurance qualité. Ce compartiment est structuré de la même manière que PROD pour assurer la cohérence. Définissons les marqueurs d'autorisation et les groupes OCI IAM correspondants.
- NetworkAdmin : Marqueur d'autorisation des ressources
managenetwork
pour les ingénieurs gérant les ressources de réseau pour CompanyC. - NetworkReader : Marqueur d'autorisation des ressources
readnetwork
pour les vérificateurs vérifiant la configuration réseau de CompanyC. - ComputeAdmin : Marqueur d'autorisation des ressources
managecompute
pour les administrateurs de système provisionnant et ajustant les instances de calcul OCI pour CompanyC. - ComputeReader : Marqueur d'autorisation des ressources
readcompute
pour les vérificateurs surveillant l'utilisation des ressources du service de calcul pour OCI pour CompanyC. - StorageReader : Autorisation de ressource
manageobject
pour les équipes d'administration du stockage afin de gérer les configurations de stockage. - StorageReader : L'autorisation de ressources
readStorage
pour les équipes de conformité passe en revue les configurations du stockage et les modèles d'utilisation. - SecurityAdmin : Autorisation de ressource
managecspm
pour Compartment NPROD, car elle met également l'accent sur la sécurité, avec la capacité de surveiller et de corriger les risques de sécurité.
De même, nous allons maintenant définir les marqueurs d'autorisation et les groupes OCI IAM respectifs pour les sous-compartiments propres à l'application.
- Compartiments d'application :
- NPApp1NetAdmin, NPApp2NetAdmin et NPApp3NetAdmin : Administrez les groupes OCI IAM avec un marqueur d'autorisation des ressources
managenetwork
pour les ingénieurs gérant les ressources de réseau pour App1, App2 et App3, respectivement. - NPApp1NetUser, NPApp2NetUser et NPApp3NetUser : Administrez les groupes OCI IAM avec un marqueur d'autorisation des ressources
usenetwork
pour les ingénieurs gérant les ressources de réseau pour App1, App2 et App3, respectivement. - NPApp1ComputeAdmin, NPApp2ComputeAdmin et NPApp3ComputeAdmin : Administrez les groupes OCI IAM avec le marqueur d'autorisation des ressources
managecompute
pour les ingénieurs gérant les instances OCI Compute pour App1, App2 et App3 respectivement. - NPApp1ComputeUser, NPApp2ComputeUser et NPApp3ComputeUser : Administrez les groupes OCI IAM avec le marqueur d'autorisation des ressources
usecompute
pour les ingénieurs utilisant des instances OCI Compute pour App1, App2 et App3, respectivement. - NPApp1StorageAdmin, NPApp2StorageAdmin et NPApp3StorageAdmin : Administrez les groupes OCI IAM avec le marqueur d'autorisation des ressources
manageobject
pour les ingénieurs gérant le service de stockage d'objets OCI pour App1, App2 et App3, respectivement. - NPApp1StorageUser, NPApp2StorageUser et NPApp3StorageUser : Administrez les groupes IAM OCI avec le marqueur d'autorisation des ressources
useobject
pour les ingénieurs utilisant le service de stockage d'objets pour OCI pour App1, App2 et App3, respectivement.
- NPApp1NetAdmin, NPApp2NetAdmin et NPApp3NetAdmin : Administrez les groupes OCI IAM avec un marqueur d'autorisation des ressources
- NetworkAdmin : Marqueur d'autorisation des ressources
-
Compartiment partagé : Le compartiment partagé héberge des ressources pour la surveillance telles que la journalisation et les services OCI Cloud Guard. Il comporte également des clés pour le chiffrement et le déchiffrement qui sont utilisées par plusieurs locataires tout en assurant la séparation logique pour assurer la confidentialité et la sécurité. Tous les administrateurs de vos applications qui ont besoin de l'accès à ces services seront ajoutés aux groupes OCI IAM créés pour ces services. Définissons les marqueurs d'autorisation et les groupes OCI IAM correspondants.
-
Compartiments Oracle Cloud Guard :
cspmAdmin
: Administration des groupes IAM OCI avec marqueur d'autorisation des ressourcesmanagecspm
pour les administrateurs gérant Oracle Cloud Guard pour les compartiments PROD et Non PROD.cspmUser
: Marqueur d'autorisation des ressources OCI IAM avecusecspm
pour les ingénieurs utilisant/surveillant Oracle Cloud Guard pour les compartiments PROD et Non PROD.cspmReader
: Marqueur d'autorisation des groupes OCI IAM avec ressourcesreadcspm
pour les ingénieurs lisant Oracle Cloud Guard pour les compartiments PROD et Non PROD.
-
Compartiments du service de journalisation pour OCI :
logsAdmin
: Administrateur des groupes OCI IAM avec marqueur d'autorisation des ressourcesmanagelogs
pour les administrateurs gérant le service de journalisation OCI pour les compartiments PROD et Non PROD.logsUser
: Marqueur d'autorisation des groupes OCI IAM avec ressourcesuselogs
pour les ingénieurs utilisant/surveillant le service de journalisation OCI pour les compartiments PROD et Non PROD.logsReader
: Marqueur d'autorisation des groupes OCI IAM avec ressourcesreadlogs
pour les ingénieurs lisant le service de journalisation OCI pour les compartiments PROD et Non PROD.
-
Compartiments de clés :
kmsAdmin
: Administrateur des groupes OCI IAM avec marqueur d'autorisation des ressourcesmanagekeys
pour les administrateurs gérant la chambre forte de clés pour les compartiments PROD et Non PROD.kmsUser
: Marqueur d'autorisation des groupes OCI IAM avecusekeys
pour les ingénieurs utilisant ou surveillant une chambre forte de clés pour les compartiments PROD et Non PROD.kmsReader
: Marqueur d'autorisation des groupes OCI IAM avecreadkeys
pour les ingénieurs lisant la chambre forte de clés pour les compartiments PROD et Non PROD.
-
-
Compartiment de terrain de jeu : Environnement flexible et isolé pour l'expérimentation, le développement et les tests. Ce compartiment n'est pas lié aux contraintes de production ou de conformité, ce qui le rend idéal pour l'innovation. Ici, nous n'aurons qu'un seul groupe d'administrateurs OCI IAM pour le compartiment très enfant et nous accorderons les privilèges de gestion à toutes les ressources OCI nécessaires pour les tests requis.
-
Compartiments de développement :
DevAdmin
: Administrer les groupes OCI IAM avec l'autorisationmanagenetwork
,managecompute
,manageobject
,managekeys
,managelogs
sur les ressources pour les administrateurs Dev afin de tester une nouvelle mise en oeuvre dans le compartiment Dev.
-
Tester les compartiments :
TestAdmin
: Administrer les groupes OCI IAM avec l'autorisationmanagenetwork
,managecompute
,manageobject
,managekeys
,managelogs
sur les ressources pour les administrateurs Dev afin de tester une nouvelle mise en oeuvre dans le compartiment de test.
-
Compartiments de tests de performance :
PerfTestAdmin
: Administrer les groupes OCI IAM avec l'autorisationmanagenetwork
,managecompute
,manageobject
,managekeys
,managelogs
sur les ressources pour les administrateurs Dev afin de tester une nouvelle mise en oeuvre dans le compartiment de test de performance.
-
Étape 4 : Écrire des politiques IAM OCI pour ces marqueurs d'autorisation
Pour créer des politiques, voir Exemple 1 étape 4. Vous devez créer les politiques suivantes.
-
Politique sur toutes les ressources :
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)
-
Politique de journaux :
Allow any-user to manage logging-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.managelogs) Allow any-user to use logging-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.uselogs) Allow any-user to read logging-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readlogs)
-
Politique 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)
-
Politique clé
Allow any-user to manage keys in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.managekeys) Allow any-user to use keys in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.usekeys) Allow any-user to read keys in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readkeys)
-
Politique d'application :
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 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 manage object-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.manageobject) Allow any-user to use object-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.useobject)
-
Politique de terrain de jeu :
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 manage virtual-network-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.managenetwork) Allow any-user to manage object-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.manageobject) Allow any-user to manage logging-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.managelogs) Allow any-user to manage vaults in compartment Playground where request.principal.group.tag.infosec.gname=target.compartment.tag.mgmt.manageVaults Allow any-user to manage keys in compartment Playground where request.principal.group.tag.infosec.gname=target.compartment.tag.mgmt.manageKeys
Note : Pour un tel scénario chaque fois que vous intégrez une nouvelle charge de travail :
- Vérifiez si vous avez besoin de marqueurs d'autorisation supplémentaires. Si vous le faites, créez-les avec les politiques OCI IAM pour ces marqueurs d'autorisation.
- Créez des groupes pour gérer l'accès au nouveau compartiment de charge de travail.
- Marquer le compartiment de charge de travail à l'aide de marqueurs d'autorisation et des groupes créés.
Modèle d'autorisation basé sur une balise pour le contrôle d'accès granulaire
Jusqu'à présent, nous avons examiné tous les exemples de création d'autorisations de gestion, d'utilisateur ou de lecture pour une famille de ressources. Toutefois, la plupart des clients ont besoin d'un contrôle d'accès granulaire pour suivre le modèle de privilège minimal. L'objectif du tutoriel est de comprendre le modèle de politique, c'est pourquoi nous avons parlé d'un cas d'utilisation simple. Toutefois, permettez-moi de prendre un exemple de quatre personnes du réseau et de concevoir des marqueurs d'autorisation granulaires et des politiques OCI IAM pour ces quatre personas.
-
NetworkOwner : Cette personne ou cette équipe est responsable de la mise en oeuvre de réseau pour la location OCI. Ils ont accès à la configuration de FastConnect et sont autorisés à gérer le réseau pour toutes les applications.
-
NetworkAdmin : Cette équipe est responsable de la mise en oeuvre réseau pour les équipes d'application. Ils peuvent créer des réseaux en nuage virtuels pour les équipes d'application. Toutefois, ils n'ont pas accès à la configuration d'un pare-feu de réseau ou FastConnect.
-
NetworkOperator : Cette équipe est responsable du réseau de l'application. L'équipe peut créer un sous-réseau d'application dans le VCN de l'application ou un VCN partagé. Toutefois, ils ne sont pas autorisés à gérer ou à mettre à jour les réseaux en nuage virtuels.
-
NetworkUser : Il s'agit de l'équipe d'administration de l'application qui nécessite une autorisation d'utilisation sur les ressources de réseau de l'application.
Nous définirons networkowner
, networkadmin
, networkoperator
et networkuser
comme quatre marqueurs sur le compartiment de réseau. Pour ces marqueurs, nous affecterons des noms de groupe qui ont accès au compartiment de réseau.
-
Politique NetworkOwner :
Allow any-user to manage virtual-network-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkowner)
-
Politique NetworkAdmin :
Allow any-user to manage vcns in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkadmin) Allow any-user to manage subnets in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkadmin) Allow any-user to manage route-tables in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkadmin) Allow any-user to manage security-lists in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkadmin) Allow any-user to manage network-security-groups in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkadmin) Allow any-user to manage dhcp-options in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkadmin) Allow any-user to manage local-peering-gateways in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkadmin) Allow any-user to manage service-gateways in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkadmin) Allow any-user to manage internet-gateways in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkadmin)
-
Politique NetworkOperator :
Allow any-user to {VCN_ATTACH,VCN_DETACH} in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkoperator) Allow any-user to inspect vcns in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkoperator) Allow any-user to manage subnets in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkoperator) Allow any-user to manage route-tables in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkoperator) Allow any-user to manage security-lists in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkoperator) Allow any-user to manage network-security-groups in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkoperator) Allow any-user to manage dhcp-options in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkoperator)
-
Politique NetworkUser :
Allow any-user to inspect vcns in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkuser) Allow any-user to use subnets in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkuser) Allow any-user to use vnics in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkuser) Allow any-user to use security-lists in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkuser) Allow any-user to use network-security-groups in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkuser)
Ajuster les politiques OCI IAM pour les principaux d'instance
Exemple 1 : Contrôle d'accès d'instance multilocataire pour le stockage partagé et les clés secrètes dans OCI
Étape 1 : Obtenir une compréhension complète de l'aperçu commercial du client
Solutions en nuage XYZ est un fournisseur SaaS offrant un système de gestion de documents (DMS) hébergé sur OCI. La plateforme dessert plusieurs entreprises clientes, chacune nécessitant un isolement strict de leurs données tout en tirant parti d'une infrastructure partagée.
Exigences du client :
- Chaque entreprise (locataire) doit avoir des instances isolées pour traiter et gérer des documents.
- Les clés secrètes de chaque client (clés d'API, données d'identification de base de données) ne doivent être accessibles qu'aux instances de ce client.
- Tous les locataires stockent leurs documents dans un compartiment de stockage d'objets OCI centralisé, mais ils ne doivent accéder qu'à leur propre seau.
- Le système doit prendre en charge la mise à l'échelle automatique et l'intégration facile des nouveaux locataires.
Étape 2 : Concevoir la structure de compartiment pour la charge de travail
Explorons maintenant la structure de compartiments pour les solutions en nuage XYZ, qui suit le modèle de politique OCI IAM pour l'ajustement de leurs politiques OCI IAM.
-
Isolement du locataire avec des compartiments :
- Créez un compartiment OCI dédié pour chaque client d'entreprise (Tenant1, Tenant2, etc.).
- Déployez des instances de calcul (VM, fonctions ou conteneurs) dans leurs compartiments respectifs.
- Stockage centralisé avec contrôle d'accès.
-
Tenir à jour un compartiment de stockage partagé pour les seaux de stockage d'objets OCI :
- Chaque locataire obtient un seau dédié, marqué avec
Enterprise.Tenant=<TenantName>
. - Les politiques OCI IAM garantissent que les instances de chaque locataire peuvent uniquement lire à partir de leur propre seau.
- Gestion des clés secrètes avec le service de chambre forte OCI.
- Chaque locataire obtient un seau dédié, marqué avec
-
Stocker les données d'identification de base de données, les clés d'API et les clés de chiffrement dans le service de chambre forte OCI :
- Les clés secrètes de chaque locataire sont marquées avec
Enterprise.Tenant=<TenantName>
. - Les politiques OCI IAM permettent uniquement aux instances de ce locataire d'extraire leurs clés secrètes.
- Stratégie de marquage d'entreprise pour la gouvernance.
- Les clés secrètes de chaque locataire sont marquées avec
-
Définissez un espace de noms de marqueur d'entreprise avec
Enterprise.Tenant
pour suivre la responsabilité du locataire :- Appliquez des marqueurs par défaut de compartiment pour marquer automatiquement les ressources dans le compartiment de chaque client.
- Utiliser des politiques basées sur des marqueurs pour un contrôle d'accès automatisé.
Étape 3 : Créer des groupes OCI IAM
Pour assurer une gestion de l'accès sécurisée et isolée dans un environnement multilocataire OCI, les politiques suivantes seront définies pour :
-
Groupe InfoSec : Administrateurs de la sécurité autorisés à gérer les politiques, les marqueurs, les utilisateurs et les groupes.
-
Terraform-Runner Group : Groupe d'exécution Infrastructure-as-Code (IaC) pour la gestion des ressources OCI.
Remarque : Ces groupes et les politiques OCI IAM sont déjà créés, comme décrit ci-dessus dans la section Politiques OCI IAM communes.
Étape 4 : Créer des politiques OCI IAM pour les groupes définis
Politiques d'accès aux ressources du locataire : Pour maintenir l'isolement des données, les ressources du locataire ne doivent pouvoir accéder qu'à leurs propres clés secrètes et à leur stockage d'objets.
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 les principes d'instance de client requièrent également une autorisation pour créer de nouveaux objets, vous pouvez créer des noms de seau portant le même nom que le nom du client et utiliser la balise de nom de client pour les comparer au nom du seau.
Allow any-user to manage objects in compartment Storage where request.principal.compartment.tag.Enterprise.Tenant = target.bucket.name
Exemple 2 : Contrôle d'accès détaillé pour l'accès aux données multiservices dans un modèle de stockage OCI partagé
Étape 1 : Obtenir une compréhension complète de l'aperçu commercial du client
XYZ Corp est une entreprise en rapide croissance spécialisée dans les solutions de transformation numérique. Avec une présence mondiale, XYZ Corp fonctionne dans plusieurs régions et tire parti d'OCI pour héberger des applications critiques, gérer les données et assurer une collaboration transparente entre les équipes.
Exigences du client :
- Toutes les instances du service d'administration pour un locataire spécifique peuvent lire les seaux d'administration dans le compartiment de stockage partagé.
- Toutes les instances du service de vente d'un locataire spécifique peuvent lire les seaux de vente dans le compartiment de stockage partagé.
- Toutes les instances du service d'approvisionnement d'un locataire spécifique peuvent lire les seaux d'approvisionnement dans le compartiment de stockage partagé.
- Toutes les instances d'un locataire spécifique peuvent lire des seaux de services partagés dans le compartiment de stockage partagé.
- Toutes les instances d'un locataire spécifique peuvent lire des clés secrètes pour ce locataire dans le compartiment du locataire.
Étape 2 : Concevoir la structure de compartiment pour la charge de travail
Explorons maintenant la structure de compartiments pour XYZ Corp, qui suit le modèle de politique OCI IAM pour l'ajustement de ses politiques OCI IAM.
-
Création de compartiment propre au locataire :
- Créez un compartiment dédié pour chaque client.
- Toutes les ressources appartenant à un locataire doivent être provisionnées dans le compartiment de ce locataire.
-
Espace de noms du service de marquage d'entreprise :
- Définissez un espace de noms de marqueur d'entreprise avec les clés de marqueur suivantes :
Enterprise.Tenant
Saisit le nom du locataire.Enterprise.Service
Saisit le type de service. Par exemple, Admin, Sales, Supply ou Shared.
- Définissez un espace de noms de marqueur d'entreprise avec les clés de marqueur suivantes :
-
Marqueurs par défaut pour les compartiments de locataires :
- Configurez les marqueurs par défaut du compartiment pour chaque compartiment du locataire, en vous assurant que le marqueur
Enterprise.Tenant
est automatiquement appliqué à toutes les ressources du compartiment, en saisissant le nom du locataire.
- Configurez les marqueurs par défaut du compartiment pour chaque compartiment du locataire, en vous assurant que le marqueur
-
Marquage au niveau des ressources :
- Chaque ressource d'un compartiment de locataire doit être marquée avec
Enterprise.Service
spécifie le type de service. Par exemple, Admin, Sales, Supply, etc.
- Chaque ressource d'un compartiment de locataire doit être marquée avec
-
Marquage des ressources cibles (seaux et clés secrètes) :
- Marquer chaque ressource cible (par exemple, seaux et clés secrètes) avec :
Enterprise.Tenant
Saisit le nom du locataire.Enterprise.Service
Saisit le type de service associé.
- Marquer chaque ressource cible (par exemple, seaux et clés secrètes) avec :
-
Marquage de seaux partagés :
- Pour les ressources de seau partagé, réglez
Enterprise.Service = 'Shared'
pour indiquer l'accessibilité interservices.
- Pour les ressources de seau partagé, réglez
Étape 3 : Créer des groupes OCI IAM
Pour assurer une gestion de l'accès sécurisée et isolée dans un environnement multilocataire OCI, les politiques suivantes seront définies pour :
-
Groupe InfoSec : Administrateurs de la sécurité autorisés à gérer les politiques, les marqueurs, les utilisateurs et les groupes.
-
Terraform-Runner Group : Groupe d'exécution Infrastructure-as-Code (IaC) pour la gestion des ressources OCI.
-
Groupe dynamique AdminInstances : Avec la règle de correspondance
All {tag.Enterprise.Service.value=’Admin’}
. -
Groupe dynamique SalesInstances : Avec la règle de correspondance
All {tag.Enterprise.Service.value=’Sales’}
. -
Groupe dynamique SupplyInstances : Avec la règle de correspondance
All {tag.Enterprise.Service.value=’Supply’}
.
Remarque : Les groupes InfoSec et Terraform-Runner et les politiques IAM sont déjà créés, comme décrit ci-dessus dans la section Politiques OCI IAM communes.
Étape 4 : Créer des politiques OCI IAM pour les groupes définis
Politiques d'accès aux ressources du locataire : Pour maintenir l'isolement des données, les ressources du locataire ne doivent pouvoir accéder qu'à leurs propres clés secrètes et à leur stockage d'objets.
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’}
Liens connexes
Remerciements
-
Auteur - Chetan Soni (ingénieur en nuage principal)
-
Contributeur - Kiran Thakkar (architecte en nuage en chef)
Autres ressources d'apprentissage
Explorez d'autres laboratoires sur le site docs.oracle.com/learn ou accédez à plus de contenu d'apprentissage gratuit sur le canal Oracle Learning YouTube. De plus, visitez education.oracle.com/learning-explorer pour devenir un explorateur Oracle Learning.
Pour obtenir la documentation sur le produit, visitez Oracle Help Center.
Deep Dive into Tag based Oracle Cloud Infrastructure Identity and Access Management Policies
G30365-01
Copyright ©2025, Oracle and/or its affiliates.