Structure de sécurité IAM

L'évolutivité est l'un des principaux avantages de l'adoption du cloud. Les entreprises peuvent ainsi commencer à petite échelle et se développer. Grâce à l'automatisation, vous pouvez déployer des ressources en quelques minutes au lieu de plusieurs jours, ce qui n'est pas le cas avec les infrastructures traditionnelles. Cela favorise l'innovation. Sans contrôle adéquat, un environnement cloud peut se complexifier et devenir ingérable en matière de sécurité et de coûts, mettant ainsi votre entreprise en danger.

Avant de créer plusieurs ressources cloud dans Oracle Cloud Infrastructure (OCI), nous vous recommandons de configurer un modèle de sécurité IAM. La version initiale d'un modèle de sécurité peut aider votre organisation à atténuer les risques liés à la gestion en séparant les tâches et les ressources, ce qui favorise la croissance future.

Remarque : avant d'ajouter plusieurs ressources cloud, définissez un modèle de sécurité IAM qui couvre la location, la structure de compartiments, etc.

Dans OCI, l'isolation des ressources est intégrée, à commencer par celle des ressources suivantes :

• Location
• Domaine d'identité
• Structure de compartiments
• Stratégies IAM

Organisation et location

Lorsque vous vous inscrivez à OCI, Oracle crée une location pour vous. La location contient vos entités IAM, telles que les utilisateurs, les groupes, les compartiments et certaines stratégies, et d'autres ressources OCI. Vous pouvez également placer des stratégies et des ressources dans des compartiments de la location. Pour plus d'informations, reportez-vous aux rubriques Gestion d'organisation et Gestion de l'accès aux ressources.

Location : limite de sécurité la plus élevée

• La location est le conteneur d'hébergement des ressources OCI de plus haut niveau. Elle est également appelée compartiment racine.
• Tous les contrôles d'accès des ressources OCI sont dictés par les stratégies IAM, où la location est le niveau le plus élevé auquel les stratégies IAM peuvent être affectées. Les règles de gouvernance d'OCI Organization Management peuvent contrôler les régions, les quotas de service et les balises autorisés pour les locations enfant, mais n'ont aucun contrôle sur les stratégies IAM. Vous pouvez accorder l'accès à plusieurs locations en créant des stratégies IAM inter-location. Dans ce cas, les administrateurs qui accordent et acceptent des locations doivent créer des instructions de stratégie spéciales qui indiquent explicitement les ressources accessibles et partagées.

Remarque : le compartiment racine est le niveau supérieur de la hiérarchie de stratégies d'IAM. Les stratégies IAM ne peuvent pas hériter d'une location à l'autre. Pour plus d'informations, reportez-vous à Fonctionnement des stratégies et à Stratégies inter-location.

Exploiter plusieurs locations pour faire évoluer votre entreprise au-delà des limites

• Chaque location OCI est créée avec un ensemble de limites de service configurées par Oracle. Bien que les utilisateurs puissent demander une augmentation de limite de service, ils n'ont pas de contrôle direct sur les limites.
• Pour éviter toute interruption de service, les utilisateurs peuvent contrôler la distribution de l'utilisation en affectant des quotas de service aux compartiments, le cas échéant.
• Les utilisateurs peuvent évoluer au-delà des limites de service strictes en tirant parti d'une nouvelle location, qui dispose de son propre ensemble de limites affectées lors de la création.

Vous pouvez ajouter des locations à votre organisation à l'aide de la gestion d'organisation et faire en tant que ces locations utilisent des crédits de votre abonnement financé principal. Vous pouvez ensuite créer une location isolée pour créer des charges globales sans réaliser de nouvelle commande.

Les types de location sont les suivants :

• Location parent : associée à l'abonnement financé principal. Elle peut générer analyses et rapports sur chacune de vos locations. 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 finance et d'informatique peuvent 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.
• Locations enfant : locations utilisant un abonnement qui n'est pas le leur. Il peut s'agir de locations entièrement nouvelles ou de locations existantes invitées à rejoindre la location parent et à faire partie de la même organisation.

Remarque : nous vous recommandons de ne pas héberger d'applications ou de services dans la location parent, en particulier si elle est utilisée à des fins de gestion. Pour plus d'informations, reportez-vous à Blog OCI - Utilisez les organisations pour gérer les coûts de manière centralisée.

Remarques relatives à la structure des locations

Prenez en compte les informations suivantes pour les locations :

• Facturation et gestion des coûts : le partage d'un engagement unique permet de réduire les excédents de coût et de consolider la facturation.
• Isolation de l'environnement : lorsque vous avez besoin d'une autonomie opérationnelle élevée avec une isolation stricte des ressources, vous pouvez utiliser une location en tant que limite de niveau supérieur pour isoler vos environnements. Etant donné que chaque location est fournie avec un ensemble distinct de règles et de ressources IAM, les paramètres de sécurité et de gouvernance sont administrés séparément. Cette administration séparée permet le plus haut degré d'autonomie opérationnelle.
• Frais généraux de gestion : les locations multiples assurent l'autonomie opérationnelle avec un niveau d'isolement élevé, mais entraînent des frais généraux de gestion. Si vous n'avez pas besoin d'un niveau d'isolation élevé, par exemple, à des fins de conformité réglementaire, envisagez d'utiliser des domaines d'identité et descompartiments.
• Résidence des ressources IAM : chaque location dispose d'une région d'origine propre, qui contient les informations de compte Oracle Cloud et les ressources d'identité du domaine d'identité IAM par exemple.
  • Le domaine par défaut est toujours répliqué vers 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é vers cette région. La région d'origine du domaine par défaut est celle de la location, qui ne peut pas être modifiée.
  • Les domaines d'identité secondaires (autres que celui par défaut) peuvent disposer de leur propre région d'origine, mais uniquement dans l'ensemble de régions auquel la location est abonnée. Les domaines d'identité secondaires peuvent également être répliqués vers les régions de l'ensemble de régions auquel la location est abonnée.

Limites relatives aux locations

Tenez compte des limites suivantes pour les locations :

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

Exemples de cas d'emploi pour les locations

Examinez les exemples de cas d'emploi suivants, qui requièrent des locations distinctes :

• Le fournisseur de services SaaS héberge des locations dédiées pour les clients réglementés
• Exigences des lois de confidentialité et de sécurité des données en matière de résidence des ressources IAM.
• Dans le contexte des fusions et des acquisitions, entreprises qui doivent maintenir l'autonomie opérationnelle avec des processus de gestion des identités et de recrutement distincts.
• Dans le contexte des hackathons et des études de faisabilité, possibilité de démarrer des projets novateurs dans une location Niveau gratuit propre à un projet, puis de les appliquer à l'ensemble de l'organisation pour bénéficier de tableaux de prix négociés et d'une meilleure visibilité des coûts.
• Exigences réglementaires telles que la séparation des environnements de production et autres que de production.

Décisions de conception clés relatives aux locations

Appuyez vos décisions de conception clés sur les informations suivantes :

• Cas d'emploi acceptés de redimensionnement de 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, la propriété de location, les coûts et la gestion budgétaire

Pour plus d'informations, reportez-vous à Gestion d'organisation et à Gestion de la location.

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

Pour renforcer la gouvernance, certaines entreprises peuvent avoir besoin d'avoir un contrôle centralisé de la création de nouveaux comptes cloud dans une entité professionnelle.

Vous pouvez enregistrer votre nom de domaine public auprès d'OCI via la gestion des domaines, ce qui empêche d'autres utilisateurs de revendiquer ce domaine à l'avenir pour l'utilisation de nouveaux comptes cloud. Vous pouvez rediriger des tentatives d'inscription de nouveaux utilisateurs qui utilisent une adresse électronique d'entreprise provenant de leur domaine vérifié.

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

Par conséquent, grâce à la gestion des domaines, les grandes entreprises peuvent contrôler plus facilement 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é des 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 d'aide de l'administrateur de domaine public pour ajouter l'enregistrement TXT fourni par OCI afin de vérifier que vous êtes propriétaire du domaine. Ce processus de vérification de domaine peut prendre jusqu'à 72 heures.

Remarque : vous pouvez empêcher d'autres personnes de créer un compte Oracle Cloud avec votre domaine vérifié via la gestion des domaines. Nous utilisons Oracle Notification pour vous avertir si quelqu'un tente de créer un compte avec votre domaine.

Remarque : 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 fonctionnalité en utilisant votre équipe d'administration centrale et en communiquant correctement avec les parties prenantes, telles que les secteurs d'activité concernés.

Décisions de conception clés relatives à la structure de location

Pour plus d'informations, reportez-vous à Gestion d'organisation et à Gestion de la location.

Domaines d'identité IAM

Un domaine d'identité est un conteneur destiné à la gestion des utilisateurs et des rôles, à la fédération et au provisionnement des utilisateurs, à la sécurisation de l'intégration d'applications via des configurations d'accès avec connexion unique (SSO), ainsi qu'à l'administration de fournisseurs d'identités SAML/OAuth. Le domaine représente une population d'utilisateurs dans OCI et les configurations et paramètres de sécurité associés, tels que l'authentification à plusieurs facteurs.

Vous pouvez créer et gérer plusieurs domaines d'identité (par exemple, un domaine pour le développement et un pour la production). Chaque domaine présente 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é présente divers avantages. Si vous disposez de domaines d'identité distincts, le travail des utilisateurs dans un domaine d'identité n'a aucune incidence sur le travail des utilisateurs dans un autre.

Le recours à plusieurs domaines d'identité peut vous aider à maintenir l'isolation du contrôle d'administration sur chaque domaine d'identité. Plusieurs domaines d'identité sont requis, par exemple, lorsque les normes de sécurité empêchent l'existence d'ID utilisateur de développement dans l'environnement de production. Plusieurs domaines sont également utilisés lorsque vous exigez des administrateurs différents pour contrôler les divers environnements.

Remarques de conception concernant les domaines d'identité

Tenez compte des informations suivantes lors de la conception d'une structure IAM :

• Besoin de séparer les ID utilisateur et les administrateurs dans les environnements et les charges globales. Par exemple :
  • Production par rapport aux environnements de développement
  • Charges globales orientées personnel et orientées clients
  • Employés par rapport aux sous-traitants
• Les administrateurs peuvent créer autant de domaines d'identité secondaires que leurs limites de service le permettent.
• Vous pouvez mettre à niveau le domaine d'identité par défaut ou secondaire vers un autre type de domaine. Chaque type de domaine d'identité est associé à différentes fonctionnalités 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'emploi pour les domaines d'identité

Examinez les exemples de cas d'emploi suivants, qui requièrent des domaines d'identité distincts :

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

Recommandations pour les domaines d'identité

Suivez ces recommandations lors de la configuration des 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 propre à l'environnement et les services PaaS (Platform-as-a-Service) afin de mieux contrôler le comportement du domaine, comme le cycle de vie, la région d'origine et la réplication.
• Commencez avec un domaine d'identité de type Gratuit/Oracle Apps adapté à des scénarios cloud uniquement. Effectuez ensuite une mise à niveau vers le type Premium/Oracle Apps Premium pour obtenir des limites plus élevées ou pouvoir prendre en charge des cas d'emploi avancés. Par exemple :
  • Authentification des applications Oracle sur site ou hébergées sur le cloud.
  • Utilisation de la synchronisation bidirectionnelle avec Active Directory ou d'autres systèmes IAM.
  • Utilisation de fonctionnalités d'authentification/d'autorisation 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'emploi orientés clients et personnes extérieures qui nécessitent les ressources suivantes :
  • Connexion par réseau social, mots de passe en libre-service des utilisateurs, gestion des profils et consentement relatif aux conditions d'utilisation.
  • Solution Identity-as-a-Service (IDaaS) complète pour une adaptabilité à des millions d'utilisateurs.
  • Aucun accès à la gestion des habilitations OCI. Par exemple, la gestion de l'accès aux ressources OCI et les fonctionnalités IAM destinées au personnel de provisionnement des applications tierces utilisant le catalogue d'applications et la synchronisation avec Active Directory.

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

• Approuvez les cas d'emploi acceptables pour disposer de domaines d'identité secondaires supplémentaires pour les isolations IAM.
• Déterminez la région d'origine du domaine IAM, qui ne peut pas être modifiée après sa création.
• Décidez si une fonctionnalité IAM de premier ordre est obligatoire, telle que la synchronisation bidirectionnelle avec LDAP/AD par pont, l'assesseur EBS et le proxy RADIUS.
• Décidez de la propriété et de l'administration du domaine IAM utilisateur externe si des fonctionnalités telles que la connexion aux réseaux sociaux, le mot de passe en libre-service des utilisateurs et la gestion des profils sont nécessaires.

Pour plus d'informations, reportez-vous à Types de domaine d'identité IAM.

Compartiments et structure de balisage pour les stratégies IAM affinées

Utilisez les compartiments et les balises pour organiser et isoler les ressources en vue du contrôle de l'accès.

Notions de base des stratégies IAM

• La stratégie IAM est une instruction qui spécifie qui peut accéder à quelles ressources OCI votre entreprise dispose, et comment.

• Etant donné qu'OCI n'accorde pas d'accès par défaut, votre organisation a besoin d'au moins une stratégie pour commencer à régir le contrôle de vos ressources. Chaque stratégie comprend des instructions 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 stratégies IAM.

• Etant donné que le changement d'accès pour les services OCI et le groupe dynamique peut entraîner des coupures de services s'ils ne sont pas gérés correctement, nous vous recommandons de publier ces types de modifications via une location/un environnement canari pour éviter d'introduire des modifications de rupture en production.
• Vous pouvez affiner l'octroi de contrôles d'accès en organisant les ressources avec des compartiments et des balises.

Remarques de conception concernant les compartiments et les balises

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

• Compartiments :

  • Les compartiments sont à l'échelle de la location et s'étendent sur plusieurs régions. Lorsque vous créez un compartiment, celui-ci est disponible dans chaque région à laquelle votre location est abonnée.
  • Vous pouvez créer des sous-compartiments dans d'autres compartiments pour créer des hiérarchies comportant jusqu'à six niveaux. Un sous-compartiment hérite des droits d'accès des compartiments au-dessus de lui dans la hiérarchie.

  

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

• Balises : vous pouvez utiliser le contrôle d'accès basé sur des balises pour définir des stratégies d'accès couvrant plusieurs compartiments, groupes et ressources. L'utilisation du contrôle d'accès basé sur des balises peut vous aider à éviter la duplication des stratégies IAM, à garantir la cohérence et à réduire les frais généraux de gestion.

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

• Stratégie IAM conditionnelle :

  • La correspondance de condition ne tient pas compte de la casse, la valeur de balise en tient compte et certains types de ressource utilisent la dénomination avec respect de la casse. Par exemple, prenons l'instruction suivante :

    Un utilisateur dans Group A peut accéder aux ressources dans des compartiments avec la balise Operations.Project= 'sample'. L'utilisateur peut également accéder aux ressources de compartiments avec la balise 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 des balises définies si le contrôle d'accès basé sur des balises est adopté. Reportez-vous à Utilisation des valeurs prédéfinies.

  • Tous les services OCI prennent en charge ces variables. request.principal.compartment, request.principal.group et target.resource.compartment.tag. Cependant, tous les services ne supportent pas la variable target.resource.tag. Reportez-vous à Services pris en charge.

    Pour connaître les fonctionnalités avancées de stratégie IAM conditionnelle, reportez-vous à Contrôle d'accès basé sur des balises et à Contrôle d'accès basé sur le temps.

Recommandations pour les compartiments et les balises

Utilisez les recommandations suivantes lors de la configuration des compartiments et des balises :

• Créez et désignez des compartiments pour des catégories de ressources spécifiques. De plus, n'écrivez des stratégies IAM autorisant l'accès aux ressources que pour les groupes d'utilisateurs en ayant besoin.
• Répartissez les charges globales de production et les charges globales autres que de production dans des compartiments distincts.
• Créez et utilisez des compartiments enfant pour isoler les ressources et obtenir davantage de couches organisationnelles. Ecrivez des stratégies distinctes pour chaque niveau de compartiment.
• Permettez uniquement aux utilisateurs autorisés de déplacer des compartiments vers d'autres compartiments parent et de déplacer des ressources d'un compartiment vers un autre. Ecrivez des stratégies 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 indiquant un compartiment dans la stratégie IAM.
• Affectez des balises aux ressources pour les organiser et les identifier en fonction des besoins de votre entreprise.
  • Utilisez les compartiments et le balisage pour simplifier la gestion des accès. Alignez la conception des compartiments OCI sur les structures des services ou des projets. Pour plus d'informations, reportez-vous à Gestion des compartiments.
  • Si le contrôle d'accès basé sur des balises est adopté, veillez à disposer de contrôles appropriés afin de déterminer les personnes habilitées à appliquer des balises.
  • Une fois les stratégies en place, n'oubliez pas que l'application de balises à un groupe, à un utilisateur ou à une ressource peut potentiellement accorder l'accès aux ressources.
• Conservez le moins de compartiments possible. La navigation dans la console OCI est ainsi moins compliquée.
• Ne pas combiner avec la sécurité réseau. Les compartiments ont un impact limité sur la charge globale réelle.

Environnements multiples

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

Remarque : 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. Outre le motif commercial stratégique mentionné précédemment, vous pouvez également avoir besoin de ce type d'environnement pour prendre en charge vos processus de gestion du changement. Par exemple, vous aurez peut-être besoin d'un environnement de test ou de canari pour que votre équipe de plate-forme cloud déploie des modifications au niveau de la location afin d'éviter d'introduire des perturbations massives à vos équipes d'application en même temps.
• Type 1 : cet isolement d'environnement partage des ressources minimales au niveau du compartiment racine, telles que les stratégies d'activation des services OCI et les administrateurs avec accès d'urgence. Avec un compartiment dédié et un domaine d'identité supplémentaire, vous pouvez disposer de plusieurs environnements hautement séparés au sein d'une même location qui disposent de leur propre fournisseur d'identités, stratégie d'accès et ressources cloud.
• Type 2 : cet isolement d'environnement partage certains services clés sélectifs, tels que le domaine d'identité et la connexion rapide, afin d'améliorer l'efficacité des coûts et de l'administration. Il est généralement utilisé pour les environnements hors production tels que les environnements UAT, SIT et DEV. Certaines organisations acceptent également les pratiques pour les environnements de production et de pré-production.
• Type 3 : cet isolement d'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 stratégies de contrôle communes.
• Type 4 : cet isolement d'environnement partage les infrastructures de charges globales, telles que le middleware, OKE et la base de données, entre plusieurs instances d'application.

Meilleures pratiques pour IAM

Pour obtenir les dernières informations concernant les meilleures pratiques IAM, reportez-vous à Meilleures pratiques pour Identity and Access Management. Voici les points clés :

• 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 pour 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 dispose du rôle d'administrateur de domaine d'identité dans le domaine par défaut. Les utilisateurs appartenant à ces deux groupes sont des superadministrateurs et peuvent gérer toutes les ressources dans OCI.
• Utilisez le domaine par défaut en tant que domaine de départ. Les utilisateurs du domaine par défaut peuvent accéder aux ressources dans OCI et les gérer non seulement, mais également les utilisateurs d'un domaine secondaire.
• Créez d'autres domaines secondaires pour divers cas d'emploi, tels que la segmentation des identités (clients et employés), la séparation des environnements (développement, test, production) et les exigences de résidence des 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 de résidence des données. Les domaines secondaires vous permettent de choisir les régions géographiques dans lesquelles répliquer un domaine.

En savoir plus

• Meilleures pratiques pour Identity and Access Management (IAM) dans Oracle Cloud Infrastructure

• Isolation des ressources et contrôle de l'accès
• Implémentation de la convention de dénomination pour les ressources OCI à l'aide de Tagging