Structure de sécurité IAM

L'un des principaux avantages de l'adoption de l'environnement en nuage est l'extensibilité, qui permet aux entreprises de commencer petites entreprises et de se développer. Par rapport aux infrastructures traditionnelles, l'automatisation vous permet de déployer des ressources en quelques minutes, plutôt qu'en quelques jours, ce qui peut favoriser l'innovation. Sans un contrôle adéquat, un environnement en nuage peut devenir trop complexe et la sécurité et les coûts peuvent être difficiles à gérer, ce qui met votre organisation en danger.

Avant de créer plusieurs ressources en nuage dans Oracle Cloud Infrastructure (OCI), nous vous recommandons de configurer un modèle de sécurité de gestion des identités et des accès (IAM). Une version initiale d'un modèle de sécurité peut aider votre organisation à limiter les risques liés à la gestion en séparant les tâches et les ressources, favorisant une croissance future réussie.

Note : Avant d'ajouter des ressources en nuage, définissez un modèle de sécurité GIA qui couvre la location, la structure de compartiments, etc.

Dans OCI, l'isolement des ressources est intégré, en commençant par les ressources suivantes :

• Location
• Domaine d'identité
• Structure de compartiments
• Politiques GIA

Organisation et location

Lors de votre inscription à OCI, Oracle crée une location pour vous. La location contient vos entités IAM, telles que des utilisateurs, des groupes, des compartiments et certaines politiques, ainsi que d'autres ressources OCI. Vous pouvez également placer des politiques et des ressources dans des compartiments de la location. Pour plus d'informations, voir Gestion de l'organisation et Gestion de l'accès aux ressources.

Considérer la location comme le niveau de limite de sécurité le plus élevé

• La location est le conteneur de haut niveau qui héberge vos ressources OCI. Elle est également appelée compartiment racine.
• Tout le contrôle d'accès des ressources OCI est dicté par les politiques IAM, où la location est le niveau le plus élevé auquel les politiques IAM peuvent être affectées. Les règles de gouvernance du service de gestion de l'organisation OCI peuvent contrôler les régions autorisées, les quotas de service et les marqueurs des locations enfants, mais n'ont aucun contrôle sur les politiques IAM. Il est possible d'accorder l'accès à toutes les locations en créant des politiques IAM interlocation. Dans ce cas, les administrateurs qui accordent et acceptent des locations doivent créer des énoncés de politique spéciaux indiquant explicitement les ressources accessibles et partagées.

Note : Le compartiment racine est le niveau supérieur de la hiérarchie des politiques IAM et les politiques IAM ne peuvent pas hériter d'une location à l'autre. Pour plus d'informations, voir Comment fonctionnent les politiques et Politiques interlocation.

Tirer parti de plusieurs locations pour étendre vos activités au-delà des limites

• Chaque location OCI est créée avec un jeu de limites de service configurées par Oracle. Bien que les utilisateurs puissent demander une augmentation de limite de service, ils n'ont pas un contrôle direct sur les limites.
• Pour éviter l'interruption du service, les utilisateurs peuvent contrôler la répartition de l'utilisation en affectant des quotas de service aux compartiments, si nécessaire.
• Les utilisateurs peuvent étendre les limites du service dur en tirant parti d'une nouvelle location qui a son propre jeu de limites affecté lors de la création.

Vous pouvez ajouter des locations à votre organisation à l'aide du service de gestion de l'organisation et faire en sorte que les locations utilisent les crédits de votre abonnement principal financé. Vous pouvez ensuite créer une location isolée pour créer vos charges de travail sans passer une nouvelle commande.

Les types de location sont les suivants :

• Location parent : Associée à l'abonnement principal financé, pouvant analyser chaque location et produire des rapports. Chaque organisation ne peut avoir qu'une seule location parent. Il est courant d'utiliser la location parent à des fins de gestion où les opérations de développement, de finances et de TI pourraient avoir besoin d'y accéder. Dans ce cas, nous vous recommandons de ne pas héberger d'applications ou de services dans cette location.
• Liens enfants : Locations qui utilisent un abonnement qui n'est pas le leur. Les locations enfants peuvent être créées en tant que nouvelles locations, ou des locations existantes peuvent être invitées à rejoindre la location parent et à faire partie de la même organisation.

Note : Nous vous recommandons de ne pas héberger d'applications ou de services dans la location parent, surtout si elle est utilisée à des fins de gestion. Pour plus d'informations, voir Blogue sur OCI - Utiliser les organisations pour gérer les coûts de manière centralisée.

Points à considérer pour la structure des locations

Tenez compte des informations suivantes pour vos locations :

• Gestion de la facturation et des coûts : Le partage d'un engagement unique permet de limiter les dépassements de coûts et de consolider la facturation.
• Isolement de l'environnement : Lorsque vous avez besoin d'une autonomie opérationnelle élevée avec un isolement strict des ressources, vous pouvez utiliser une location comme limite de niveau supérieur pour isoler vos environnements. Chaque location étant fournie avec un jeu distinct de ressources et de règles GIA, les paramètres de sécurité et de gouvernance sont administrés séparément. Une administration distincte permet de bénéficier du niveau le plus élevé d'autonomie opérationnelle.
• Frais généraux de gestion : Plusieurs locations assurent une autonomie opérationnelle avec un niveau d'isolement élevé, mais engagent des frais généraux de gestion. Si vous n'avez pas besoin d'un haut niveau d'isolement, par exemple pour la conformité réglementaire, envisagez d'utiliser des domaines d'identité et des services.
• Résidence des ressources IAM : Chaque location a sa propre région principale, qui contient les informations de votre compte Oracle Cloud et les ressources d'identité dans le domaine d'identité IAM par défaut.
  • Le domaine par défaut est toujours répliqué dans toutes les régions auxquelles le locataire est abonné. Lorsqu'un administrateur s'abonne à une autre région, seul le domaine par défaut est répliqué dans cette région. La région principale du domaine par défaut est la région principale de la location, qui ne peut pas être modifiée.
  • Les domaines d'identité secondaires (différents des domaines par défaut) peuvent avoir leur propre région principale, mais seulement dans le jeu de régions auxquelles la location est abonnée. Il est également possible de répliquer des domaines d'identité secondaires dans le jeu de régions auxquelles la location est abonnée.

Limites relatives aux locations

Tenez compte des limitations suivantes pour les locations :

• La région principale contient les informations sur votre compte et les ressources d'identité, et ne peut pas être modifiée une fois la location provisionnée. Pour plus d'informations, voir Région principale.
• Lorsqu'une location enfant est créée, elle n'est pas automatiquement fédérée avec les domaines d'identité Oracle Identity Cloud Service/OCI. Pour plus d'informations, voir Création d'une location enfant.
• Les locations utilisant un abonnement à Pay As You Go ou un abonnement de niveau gratuit ne peuvent pas ajouter de nouvelles locations enfants. Pour plus d'informations, voir Création d'une location enfant.
• La location parent-enfant est une structure à un seul niveau qui ne prend pas en charge une hiérarchie à plusieurs niveaux.

Exemples de cas d'utilisation des locations

Dans les exemples de cas d'utilisation suivants, des locations distinctes peuvent être utilisées :

• Fournisseur de services SaaS pour héberger des locations dédiées pour les clients réglementés
• Exigences relatives à la résidence des ressources GIA en vertu des lois sur la confidentialité et la sécurité des données.
• Pour les fusions et acquisitions, certaines entreprises doivent maintenir une autonomie opérationnelle avec des processus distincts de gestion des identités et d'embauche.
• Pour les marathons de programmation et les démonstrations de faisabilité, capacité de lancer des projets innovants dans une location de l'offre de gratuité pour Oracle Cloud Infrastructure basée sur un projet, puis de les appliquer à l'organisation globale pour négocier les prix et améliorer la visibilité sur les coûts.
• Exigences réglementaires telles que la séparation des environnements de production et hors production.

Décisions de conception clés relatives aux locations

Appuyez-vous sur les informations suivantes pour prendre des décisions de conception clés :

• Cas d'utilisation acceptés pour ajuster l'adoption d'OCI avec des locations et des organisations distinctes
• Modèles opérationnels de location, tels que le processus de demande d'une nouvelle location et la gestion de la propriété, des coûts et du budget de la location

Pour plus d'informations, voir Gestion de l'organisation et Gestion de la location.

Empêcher d'autres personnes de créer un compte Oracle Cloud avec votre nom de domaine public

Pour renforcer la gouvernance, certaines entreprises peuvent avoir besoin d'un contrôle centralisé de la création de nouveaux comptes en nuage dans un groupe d'affaires.

Vous pouvez enregistrer votre nom de domaine public auprès d'OCI au moyen de la gestion des domaines, ce qui empêche d'autres personnes de revendiquer ce domaine à l'avenir pour l'utilisation de nouveaux comptes en nuage. Vous pouvez rediriger les tentatives de connexion de nouveaux utilisateurs qui utilisent une adresse de courriel d'entreprise provenant de ce domaine vérifié.

Par exemple, si une personne utilisant OCI tente de créer une location avec "companyA.com" dans le domaine de courriel, la tentative est empêchée et elle est dirigée vers OCI.

Par conséquent, avec la gestion des domaines, les grandes entreprises peuvent plus facilement contrôler leurs environnements en sachant qui crée des locations et en appliquant la politique de l'entreprise aux locations. Vous pouvez vérifier en toute sécurité la propriété de vos domaines et contrôler plus facilement les dépenses et la gestion des ressources.

En général, cela est couvert dans la location parent dans le cadre de la capacité de gestion centrale. Vous avez besoin de l'aide de votre administrateur de domaine public pour ajouter l'enregistrement TXT fourni par OCI afin de vérifier que vous êtes bien responsable du domaine. Ce processus de vérification de domaine peut prendre jusqu'à 72 heures.

Note : Vous pouvez empêcher d'autres personnes de créer un compte Oracle Cloud avec votre domaine vérifié au moyen de la gestion de domaine. Nous utilisons l'avis Oracle pour vous aviser si quelqu'un tente de créer un compte avec votre domaine.

Note : Vous pouvez bloquer d'autres secteurs d'activité pour créer leurs propres comptes en activant cette fonction si vous partagez un domaine. Nous vous recommandons d'activer cette fonction en utilisant votre équipe d'administration centrale et en communiquant correctement avec les parties prenantes concernées, telles que les secteurs d'activité concernés.

Décisions de conception clés relatives à la structure des locations

Pour plus d'informations, voir Gestion de l'organisation et Gestion de la location.

Domaines d'identité GIA

Un domaine d'identité est un conteneur pour la gestion des utilisateurs et des rôles, la fédération et le provisionnement des utilisateurs, l'intégration sécurisée des applications au moyen de la configuration d'authentification unique (SSO) et l'administration des fournisseurs d'identités basée sur SAML/OAuth. Le domaine représente une population d'utilisateurs d'OCI, ainsi que les configurations et paramètres de sécurité associés, tels que l'authentification multifacteur.

Vous pouvez créer et gérer plusieurs domaines d'identité (par exemple, un domaine pour le développement et un autre pour la production). Chaque domaine peut présenter des exigences différentes en matière d'identité et de sécurité pour protéger vos applications et vos services OCI.

L'utilisation de plusieurs domaines d'identité offre plusieurs avantages. Avec des domaines d'identité distincts, le travail des utilisateurs dans un domaine n'a aucune incidence sur celui des utilisateurs dans un autre domaine.

L'utilisation de plusieurs domaines d'identité peut vous aider à maintenir l'isolement du contrôle administratif de chaque domaine d'identité. Plusieurs domaines d'identité sont requis, par exemple, lorsque vos normes de sécurité interdisent que les ID utilisateur de développement existent également dans l'environnement de production. Plusieurs domaines sont également utilisés lorsque différents administrateurs doivent contrôler différents environnements.

Points à considérer pour la conception des domaines d'identité

Lorsque vous concevez une structure IAM, tenez compte des informations suivantes :

• Exigences de séparation des ID utilisateur et des administrateurs entre les environnements et les charges de travail. Par exemple :
  • Production par rapport aux environnements de développement
  • Charges de travail du personnel par rapport aux charges de travail des clients
  • Employés par rapport aux sous-traitants
• Les administrateurs peuvent créer autant de domaines d'identité secondaires que les limites de service l'autorisent.
• Vous pouvez mettre à niveau le domaine d'identité par défaut ou secondaire vers un type de domaine différent. Chaque type de domaine d'identité est associé à différentes fonctions et limites d'objet.

Les informations suivantes résument les principales différences entre le domaine d'identité par défaut et les domaines d'identité secondaires.

Exemples de cas d'utilisation des domaines d'identité

Dans les exemples de cas d'utilisation suivants, des domaines d'identité distincts peuvent être utilisés :

• L'utilisation de la séparation des environnements étant donné que certaines normes de sécurité et réglementations de l'industrie exigent que vous sépariez les utilisateurs entre les environnements de production et de développement, ce qui empêche l'accès du développement à la production.
• Séparation des utilisateurs externes, tels que les clients et les sous-traitants, des identités des employés.

Recommandations pour les domaines d'identité

Suivez ces recommandations lors de la configuration de vos domaines :

• Utilisez des domaines d'identité différents pour chaque population d'utilisateurs.
• Utilisez le domaine d'identité par défaut pour l'administration au niveau de la location. Utilisez des domaines d'identité secondaires pour l'administration de l'environnement et les service PaaS, afin de mieux contrôler le comportement du domaine, notamment le cycle de vie, la région principale et la réplication.
• Commencez avec le domaine d'identité gratuit/Oracle Apps pour les scénarios en nuage seulement et passez à Premium/Oracle Apps Premium pour augmenter les limites ou pour prendre en charge des cas d'utilisation avancés. Par exemple :
  • Authentification auprès des applications Oracle sur place ou hébergées dans le nuage.
  • Utilisation de la synchronisation bidirectionnelle avec Active Directory ou d'autres systèmes GIA.
  • Utilisation des fonctionnalités AuthN/AuthZ modernes telles que l'authentification sans mot de passe, les jetons matériels FIDO2 et les solutions de sécurité adaptative.
• Créez un domaine d'identité externe secondaire pour les cas d'utilisation côté consommateur, non destinés aux employés, qui nécessitent les ressources suivantes :
  • Authentification sociale, mot de passe d'utilisateur en libre-service, gestion des profils et consentement aux conditions d'utilisation.
  • Identité-service (IDaaS) complète à adapter pour des millions d'utilisateurs.
  • Aucun accès à la gestion des droits OCI. Par exemple : gestion de l'accès aux ressources OCI et fonctions GIA destinées au personnel pour le provisionnement à des applications de tierce partie qui utilisent le catalogue d'applications et la synchronisation d'Active Directory.

Décisions de conception clés pour les domaines d'identité

• Endosser les cas d'utilisation acceptables pour avoir des domaines d'identité secondaires supplémentaires pour les isolations IAM.
• Déterminez la région principale du domaine IAM, qui ne peut pas être modifiée après sa création.
• Déterminez si une fonction IAM de premier plan est obligatoire, telle que la synchronisation bidirectionnelle avec LDAP/AD par pont, l'assesseur EBS et le mandataire RADIUS.
• Déterminer la responsabilité et l'administration du domaine IAM d'utilisateur externe si des fonctions telles que la connexion sociale, le mot de passe en libre-service pour les utilisateurs et la gestion des profils sont nécessaires.

Pour plus d'informations, voir Types de domaine d'identité IAM.

Compartiments et structure de marquage pour les politiques IAM de niveau fin

Utilisez des compartiments et des marqueurs pour organiser et isoler les ressources pour le contrôle d'accès.

Informations de base sur les politiques IAM

• La politique IAM est un énoncé qui spécifie qui peut accéder aux ressources OCI de votre entreprise, et comment.

• Comme OCI n'accorde pas l'accès par défaut, votre organisation a besoin d'au moins une politique pour commencer à régir le contrôle de vos ressources. Chaque politique est constituée d'énoncés qui suivent la syntaxe de base suivante :

  Autoriser <subject> à <verb> <resource-type> dans <location> où <conditions>

• Les informations suivantes décrivent les trois principaux groupes de politiques IAM.

• Comme le changement d'accès aux services OCI et au groupe dynamique peut entraîner des interruptions de service si elles ne sont pas gérées correctement, nous vous recommandons de lancer ces types de modifications au moyen d'une location ou d'un environnement de test canari afin d'éviter d'introduire des modifications cassantes dans la production.
• Vous pouvez affiner les contrôles d'accès en organisant les ressources avec des compartiments et des marqueurs.

Points à considérer pour la conception des compartiments et des marqueurs

Tenez compte des informations suivantes lorsque vous configurez des compartiments et des marqueurs :

• Compartiments :

  • Les compartiments existent à l'échelle de la location et couvrent plusieurs régions. Lorsque vous créez un compartiment, celui-ci est disponible dans toutes les régions auxquelles votre location est abonnée.
  • Vous pouvez créer des sous-compartiments dans des compartiments pour créer des hiérarchies d'une profondeur de six niveaux au maximum. Un sous-compartiment hérite des autorisations d'accès des compartiments situés au-dessus dans la hiérarchie.

  

  • Le compartiment est l'une des unités obligatoires pour l'octroi du contrôle d'accès. Vous pouvez mieux définir le compartiment à l'aide de clauses conditionnelles.

• Marqueurs : Vous pouvez utiliser le contrôle d'accès basé sur des marqueurs pour définir des politiques d'accès couvrant plusieurs compartiments, groupes et ressources. L'utilisation du contrôle d'accès basé sur des marqueurs peut vous aider à éviter la duplication des politiques GIA, à assurer la cohérence et à réduire les frais généraux de gestion.

  Attention : Les clés de marqueur défini ne sont pas sensibles à la casse, alors que les valeurs de marqueur définies le sont. Par exemple, "Env" et "ENV" correspondent à la même clé de marqueur. "Dev" et "DEV" sont des valeurs de marqueur distinctes.

• Politique GIA conditionnelle :

  • La mise en correspondance des conditions n'est pas sensible à la casse, les valeurs de marqueur sont sensibles à la casse et certains types de ressource permettent l'attribution d'un nom sensible à la casse. Prenons par exemple l'énoncé suivant :

    Un utilisateur de Group A peut accéder aux ressources des compartiments ayant le marqueur Operations.Project= 'sample'. L'utilisateur peut également accéder aux ressources des compartiments ayant le marqueur Operations.Project= 'Sample'.

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

  • Envisagez d'utiliser des valeurs prédéfinies dans les marqueurs définis si le contrôle d'accès basé sur des marqueurs est utilisé. Voir Utilisation de valeurs prédéfinies.

  • Tous les services OCI prennent en charge les variables de politique request.principal.compartment, request.principal.group et target.resource.compartment.tag. Toutefois, tous les services ne prennent pas tous en charge la variable de politique target.resource.tag. Voir Services pris en charge.

    Pour les fonctions conditionnelles avancées de politique IAM, voir Contrôle d'accès basé sur des marqueurs et Contrôle d'accès basé sur le temps.

Recommandations pour les compartiments et les marqueurs

Utilisez les recommandations suivantes lors de la configuration de compartiments et de marqueurs :

• Créez et désignez des compartiments pour des catégories de ressources spécifiques. Écrivez également des politiques GIA pour autoriser l'accès aux ressources uniquement aux groupes d'utilisateurs qui en ont besoin.
• Répartissez les charges de travail de production et hors production dans des compartiments distincts.
• Créez et utilisez des compartiments enfants pour isoler les ressources et créer d'autres couches organisationnelles. Écrivez des politiques distinctes pour chaque niveau de compartiment.
• Autorisez uniquement certains utilisateurs à déplacer des compartiments vers des compartiments parents différents, et à déplacer des ressources d'un compartiment à un autre. Écrivez les politiques appropriées pour appliquer cette restriction.
• Limitez le nombre de ressources de chaque type pouvant être créées dans un compartiment en définissant des quotas au niveau du compartiment.
• Limitez les ressources qu'un principal d'instance peut gérer en spécifiant un compartiment dans la politique GIA.
• Affectez des marqueurs aux ressources pour les organiser et les identifier en fonction de vos besoins d'affaires.
  • Utilisez des compartiments et le marquage pour simplifier la gestion des accès. Alignez la conception de vos compartiments OCI sur vos structures de services ou de projets. Pour plus d'informations, voir Gestion des compartiments.
  • Si un contrôle d'accès basé sur des marqueurs est adopté, assurez-vous de mettre en place les contrôles appropriés pour déterminer qui peut appliquer des marqueurs.
  • Une fois les politiques en place, n'oubliez pas que l'application de marqueurs à un groupe, à un utilisateur ou à une ressource peut accorder l'accès à ceux-ci.
• Conservez le moins de compartiments possible. Cela complique la navigation dans la console OCI.
• Ne pas combiner avec la sécurité du réseau. Les compartiments ont une incidence limitée sur la charge de travail réelle.

Environnements multiples

Les informations suivantes fournissent des exemples de stratégies d'isolement de l'environnement pour la conception des structures d'environnement. Votre organisation pourrait avoir besoin d'une combinaison de ces stratégies.

Note : Le diagramme n'est pas une architecture de référence, mais fournit des exemples de cas d'utilisation pour la conception.

• Type 0 : Cet isolement d'environnement n'implique aucun partage de ressources. Il s'agit généralement de notre structure de location pour le niveau maximal d'isolement des ressources. En dehors de la raison d'affaires stratégique mentionnée précédemment, vous pourriez également avoir besoin de ce type d'environnement pour prendre en charge vos processus de gestion du changement. Par exemple, vous pourriez avoir besoin d'un environnement de test ou de test canari pour que votre équipe de plate-forme en nuage déploie les modifications au niveau de la location afin d'éviter d'introduire des perturbations massives pour vos équipes d'applications en même temps.
• Type 1 : Cet isolement d'environnement partage des ressources minimales au niveau du compartiment racine, telles que les politiques d'activation des services OCI et les administrateurs d'urgence. Avec un compartiment dédié et un domaine d'identité supplémentaire, vous pouvez avoir plusieurs environnements hautement séparés au sein d'une même location qui ont leurs propres fournisseurs d'identités, politique d'accès et ressources en nuage.
• Type 2 : Cet isolement de l'environnement partage certains services clés sélectifs, tels que le domaine d'identité et la connexion rapide, pour améliorer les coûts et l'efficacité de l'administration. Il est généralement utilisé pour les environnements hors production tels que les environnements de test d'acceptation par les utilisateurs (UAT), de test d'acceptation par les utilisateurs (SIT) et de développement (DEV). Certaines organisations acceptent également les pratiques pour les environnements de production et de préproduction.
• Type 3 : Cet isolement de l'environnement partage tous les services de plate-forme de base, tels que les services de sécurité et de réseau. Il est généralement utilisé pour gérer des charges de travail de même nature avec des politiques de contrôle communes.
• Type 4 : Cet isolement de l'environnement partage les infrastructures de charges de travail, telles que l'intergiciel, OKE et la base de données, entre plusieurs instances d'application.

Meilleures pratiques de gestion des identités et des accès

Pour des informations à jour sur les meilleures pratiques GIA, voir Meilleures pratiques de gestion des identités et des accès dans Oracle Cloud Infrastructure. Les points à retenir sont les suivants :

• N'utilisez pas le groupe d'administrateurs de domaine par défaut et l'utilisateur doté du rôle d'administrateur de domaine d'identité pour les activités quotidiennes. Créez plutôt un administrateur distinct chargé de gérer des ressources spécifiques dans OCI.
• Vérifiez régulièrement qui fait partie du groupe d'administrateurs de domaine par défaut et qui a le rôle d'administrateur de domaine d'identité dans le domaine par défaut. Les utilisateurs appartenant à ces deux groupes sont des superadministrateurs, qui peuvent gérer toutes les ressources dans OCI.
• Utilisez le domaine par défaut comme domaine de démarrage. Non seulement les utilisateurs du domaine par défaut peuvent accéder aux ressources OCI ou les gérer, mais les utilisateurs d'un domaine secondaire peuvent également accéder à toutes les ressources OCI et les gérer.
• Créez d'autres domaines secondaires pour divers cas d'utilisation tels que la segmentation des identités (consommateurs par rapport aux employés), la séparation des environnements (développement, test, production) et les exigences en matière de résidence de données (création d'un domaine dans une région géographique particulière).
• Nous recommandons d'utiliser un domaine secondaire pour répondre aux exigences strictes en matière de résidence des données. Avec les domaines secondaires, vous pouvez choisir les régions géographiques dans lesquelles vous voulez répliquer un domaine.

Informations complémentaires

• Meilleures pratiques de gestion des identités et des accès dans Oracle Cloud Infrastructure

• Isoler les ressources et contrôler l'accès
• Mise en oeuvre d'une convention d'attribution de nom pour les ressources OCI à l'aide du service de marquage