FAQ sur Identity and Access Management

FAQ

Généralités

Qu'est-ce qu'Oracle Cloud Infrastructure Identity and Access Management (OCI IAM) ?

OCI IAM est un service natif d'OCI qui fournit des fonctionnalités de gestion des identités et des accès de niveau entreprise, telles qu'une authentification forte et adaptative, une gestion du cycle de vie utilisateur (LCM) et un accès avec connexion unique (SSO) aux applications d'entreprise. OCI IAM est déployé en tant que domaine(s) d'identité dans OCI. Le ou les domaines inclus permettent aux organisations de gérer l'accès à leurs services Oracle Cloud (réseau, calcul, stockage, etc.) et à leurs applications Oracle SaaS. Les clients peuvent choisir de mettre à niveau ou de créer des domaines d'identité supplémentaires pour répondre à d'autres cas d'utilisation, tels que la gestion de l'accès du personnel aux applications autres qu'Oracle, l'accès pour les consommateurs aux applications destinées aux clients ou l'intégration d'IAM aux applications personnalisées.

Que sont les domaines d'identité ?

Chaque domaine d'identité OCI IAM est une solution autonome de gestion des identités et des accès, qui peut être utilisée pour répondre à divers cas d'utilisation d'IAM. Par exemple, vous pouvez utiliser un domaine d'identité OCI IAM pour gérer l'accès des collaborateurs à de nombreuses applications cloud et sur site, ce qui permet une authentification sécurisée, une gestion facile des habilitations et une connexion unique transparente pour les utilisateurs finaux. Vous pouvez également mettre en place un domaine d'identité pour permettre l'accès aux systèmes de chaîne d'approvisionnement ou de commande pour les partenaires commerciaux. Vous pouvez également utiliser des domaines d'identité afin d'activer IAM pour les applications destinées aux clients et d'autoriser les utilisateurs à effectuer l'auto-inscription, la connexion par réseau social et/ou le consentement selon les conditions d'utilisation. Les domaines d'identité représentent une solution complète d'identité as-a-service (IDaaS) prenant en charge de nombreux cas d'utilisation et scénarios IAM.

Quel type de domaine d'identité choisir ?

  • Domaines d'identité gratuits : chaque location OCI inclut un domaine d'identité OCI IAM par défaut de niveau gratuit pour la gestion de l'accès aux ressources OCI (réseau, calcul, stockage, etc.). Si vous souhaitez uniquement gérer l'accès aux ressources OCI, vous pouvez utiliser le domaine par défaut inclus. Il fournit un ensemble robuste de fonctionnalités IAM pour la gestion de l'accès aux ressources Oracle Cloud. Selon le modèle de sécurité et l'équipe, les clients peuvent choisir de réserver ce domaine aux administrateurs OCI.
  • Domaines d'identité Oracle Apps : de nombreuses applications Oracle Cloud (HCM, CRM, ERP, applications sectorielles, etc.) peuvent inclure l'utilisation d'OCI IAM via un domaine Oracle Apps. Ces domaines sont inclus pour être utilisés avec les applications Oracle abonnées et fournissent des fonctionnalités IAM robustes pour la gestion de l'accès aux services Oracle Cloud et SaaS. Les clients peuvent choisir d'ajouter tous les collaborateurs à ce domaine pour activer l'accès avec connexion unique à un service d'application Oracle Cloud. Ils peuvent également utiliser ce domaine pour gérer l'accès à tout ou partie de leurs ressources OCI.
  • Domaines d'identité Oracle Apps Premium : pour étendre un domaine Oracle Apps avec des fonctionnalités d'entreprise complètes, afin de gérer l'accès aux applications Oracle qui ne sont peut-être pas fournies avec SaaS (par ex., Oracle E-Business Suite ou Oracle Databases, sur site ou hébergées dans OCI), les domaines Oracle Apps Premium offrent l'ensemble complet de fonctionnalités OCI IAM à utiliser avec des cibles Oracle pouvant être déployées dans des environnements cloud hybrides. Il s'agit d'un service économique complet, mais limité à l'utilisation avec des cibles Oracle.
  • Domaines d'identité externes : les domaines d'identité externes offrent un ensemble complet de fonctionnalités OCI IAM pour les non-collaborateurs, comme les consommateurs qui accèdent à un site de vente au détail, les gouvernements qui autorisent l'accès aux citoyens ou les entreprises qui autorisent l'accès aux partenaires commerciaux. Il n'existe aucune restriction quant aux applications pouvant être ciblées. Toutefois, certaines fonctionnalités d'entreprise généralement inutiles dans les scénarios pour les non-collaborateurs, comme App Gateway et Provisioning Bridge, ne sont pas incluses. Les domaines externes incluent la prise en charge de la connexion sociale, de l'auto-enregistrement, du consentement aux conditions d'utilisation et de la gestion des profils/mots de passe.
  • Domaines d'identité Premium : les domaines d'identité Premium offrent l'ensemble complet de fonctionnalités OCI IAM, sans restriction quant aux applications pouvant être ciblées. Les domaines Premium peuvent être utilisés en tant que service IAM d'entreprise gérant l'accès des collaborateurs ou du personnel aux applications cloud et sur site, pour une authentification sécurisée, une gestion simple des droits et une connexion unique transparente pour les utilisateurs finaux.

Puis-je associer collaborateurs et non-collaborateurs dans un même domaine d'identité ?

Non. OCI IAM les considère comme des populations d'utilisateurs distinctes concernant la licence. Toutefois, vous pouvez utiliser le même service OCI IAM pour gérer plusieurs domaines pouvant s'adapter aux collaborateurs et aux non-collaborateurs (partenaires, affiliés, consommateurs, etc.). Plusieurs domaines peuvent être utilisés pour accéder aux mêmes applications, mais les règles et les stratégies de sécurité pour les non-collaborateurs diffèrent généralement de celles qui s'appliquent aux collaborateurs. Chaque domaine dispose de son propre ensemble de paramètres, de configurations et de stratégies de sécurité qui sont uniques pour cette population d'utilisateurs. Ceci est conçu pour répondre aux exigences très diverses typiques de différentes populations d'utilisateurs.

Qui a accès à un domaine d'identité ?

Chaque location OCI inclut un groupe d'administrateurs qui fournit un accès complet à toutes les ressources OCI. Il est important de comprendre que tous les membres du groupe d'administrateurs OCI disposent d'un accès complet pour gérer les domaines d'identité OCI IAM. Oracle recommande d'utiliser ce groupe avec précaution. Des privilèges d'administration peuvent être accordés au sein de chaque domaine via des rôles d'administrateur qui permettent de séparer les tâches entre les groupes de personnes. Pour plus d'informations, reportez-vous à Présentation des rôles d'administrateur.

OCI IAM fournit-il une haute disponibilité et/ou une récupération après sinistre ?

Chaque région OCI comporte plusieurs domaines de disponibilité (DD) ou domaines de pannes (DP) (dans les régions avec un seul domaine de disponibilité). Les DD et les DP remplissent des fonctions similaires, mais les DP sont physiquement plus proches les uns des autres que les DD. Les domaines d'identité sont déployés avec des installations redondantes dans chaque région (deux sur les DD/DP) qui assurent une haute disponibilité. Les domaines d'identité OCI IAM offrent également une récupération après sinistre (RS) inter-région via une approche active-passive qui exploite la réplication de données hautes performances. Cela permet une récupération fiable des données pour les domaines d'identité dans le cas peu probable où une région OCI entière deviendrait indisponible. La RS est fournie via une seule URL, ce qui la rend transparente pour les applications.

Quels sont les termes et concepts clés d’Oracle Identity and Access Management ?

Les concepts clés du service IAM sont les suivants :

  • Compte ou location : lorsque vous inscrivez à OCI, Oracle crée une location pour votre entreprise, qui est une partition isolée au sein d'OCI dans laquelle vous pouvez créer, organiser et administrer vos ressources cloud. On parle parfois de compte OCI.
  • Compartiment : conteneur logique dans un compte OCI pour les ressources Oracle Cloud. Les administrateurs peuvent créer au moins un compartiment dans un compte OCI pour organiser et gérer les ressources. Par exemple, les compartiments peuvent être utilisés pour appliquer la séparation des fonctions entre différents types d'administrateurs (réseau, calcul, stockage, etc.).
  • Compartiment racine : compartiment de niveau supérieur au sein d'un compte OCI. Le compartiment racine est créé automatiquement pour vous lorsque votre compte est provisionné.
  • Domaines d'identité : un domaine d'identité représente un parc d'utilisateurs dans OCI, ainsi que les configurations et paramètres de sécurité associés. Chaque compte inclut un domaine d'identité par défaut permettant aux clients de gérer l'accès aux ressources OCI. Les clients peuvent choisir de créer des domaines d'identité supplémentaires en fonction de leurs besoins spécifiques. Les domaines d'identité sont créés dans un compartiment et l'accès permettant de les gérer est lié aux droits d'accès du compartiment. Il est possible d'écrire des stratégies d'accès OCI pour permettre aux utilisateurs d'un compartiment/d'un domaine donné d'accéder aux ressources d'autres compartiments.
  • Utilisateur - Une entité qui peut être authentifiée. Un utilisateur peut être une personne ou un compte d’ordinateur. Chaque utilisateur a un nom unique dans votre compte et un identifiant globalement unique. Les utilisateurs peuvent recevoir des mots de passe pour accéder à la console web et des clés pour accéder aux services via les API.
  • Groupe - Un ensemble d'utilisateurs. Les groupes sont utilisés pour simplifier la gestion des accès. Par exemple, les développeurs de logiciels peuvent être regroupés en tant que membres d’un groupe de « développeurs », ce qui leur permet de lire, d’écrire et/ou de modifier du code. Un même utilisateur peut être membre de plusieurs groupes.
  • Stratégie : document précisant quelles personnes peuvent accéder à telle ou telle ressource OCI et les privilèges dont elles disposent. Une stratégie se compose d'instructions de stratégie qui utilisent la syntaxe du langage naturel.

En quoi l’approche d’Oracle Cloud Infrastructure en matière de gestion des identités et des accès est-elle unique ?

Avec OCI IAM, vous pouvez exploiter un modèle unique d’authentification et d’autorisation pour tous les services Oracle Cloud et Cloud Application. OCI IAM facilite la gestion de l’accès pour les entreprises de toutes tailles, d’une personne travaillant sur un seul projet aux grandes entreprises dont plusieurs groupes travaillent sur plusieurs projets en même temps, le tout au sein d’un seul compte. La gestion et l’autorisation des ressources peuvent avoir lieu au niveau du compte ou au niveau du compartiment, tout en permettant un audit et une facturation centralisés. OCI IAM a été conçu à partir de zéro pour vous permettre d’appliquer le principe de sécurité du moindre privilège : par défaut, les nouveaux utilisateurs ne sont autorisés à effectuer aucune action sur aucune ressource. Les administrateurs peuvent ensuite accorder à chaque utilisateur uniquement l’accès approprié pour cet utilisateur spécifique.

En plus de gérer les ressources OCI, OCI IAM met à votre disposition une solution d'entreprise IDaaS. En cliquant simplement sur un bouton, vous pouvez déployer une solution IAM fiable pouvant être utilisée pour répondre à de nombreuses exigences IAM dans les cas d'utilisation des collaborateurs/du personnel, des partenaires ou des consommateurs.

Comment Oracle Cloud Infrastructure prend-il en charge l’authentification multifacteur ?

OCI IAM fournit une prise en charge étendue de l'authentification à plusieurs facteurs, qui inclut une application d'authentification à plusieurs facteurs mobile proposant des options pour les codes d'accès à la demande ou à usage unique, la prise en charge des authentificateurs FIDO2, et la prise en charge des SMS, des e-mails, des appels téléphoniques, etc. OCI IAM inclut également une sécurité adaptative contextuelle qui réduit les risques sans entraver l'expérience de l'utilisateur final. Adaptive Security évalue l'appareil, le réseau, l'emplacement et le comportement passé de l'utilisateur afin de créer un score de risque pour la session de l'utilisateur. Les administrateurs peuvent configurer des stratégies d'authentification multifacteur qui peuvent être différentes pour des applications spécifiques ou pour des groupes d'utilisateurs spécifiques.

Les modifications apportées aux utilisateurs, groupes, compartiments et stratégies sont-elles enregistrées à des fins de débogage et d’audit ?

Oui. Pour prendre en charge les exigences de l’entreprise en matière d’audit et de conformité, toutes les modifications sont enregistrées. Ces enregistrements peuvent être mis à votre disposition sans frais supplémentaires.

Comment commencer avec OCI IAM ?

OCI IAM est activé par défaut sans frais supplémentaires. Le tout premier utilisateur de votre compte est l’administrateur par défaut. Tous les utilisateurs suivants sont créés via le service IAM, où vous leur accordez explicitement des privilèges pour interagir avec les ressources cloud spécifiées.

Vous pouvez accéder à Oracle IAM à l’aide de la Console, de l’API Rest ou de SDK.

En tant qu’utilisateur Oracle Cloud Infrastructure, comment réinitialiser mon mot de passe ?

Pour réinitialiser votre mot de passe pour Oracle Cloud Infrastructure, vous devez d’abord vous assurer que vous avez associé une adresse e-mail à votre compte. Visitez la page de profil utilisateur de votre compte Oracle Cloud Infrastructure et ajoutez une adresse e-mail à laquelle vous seul avez accès. Vous recevrez un e-mail confirmant votre intention d’enregistrer cette adresse sur votre compte. Ensuite, vous pouvez réinitialiser votre mot de passe avec votre compte de messagerie, sauf s’il a été désactivé par votre administrateur de locataire.

Compartiments

Quels problèmes les compartiments sont-ils conçus pour résoudre ?

Un compartiment est un conteneur logique sécurisé au sein de votre compte utilisé pour héberger vos ressources d’infrastructure (telles que le calcul, le stockage et le réseau), ainsi qu’un ensemble de stratégies de gestion d’accès pour ces ressources. Les compartiments vous permettent d’organiser logiquement vos ressources cloud pour prendre en charge une grande variété de cas d’utilisation.

Voici quelques façons courantes d’utiliser les compartiments pour :

  • Séparer vos environnements de développement logiciel pour une administration simple. Par exemple, vous pourriez avoir des compartiments séparés pour le développement, le test et la production ; ou, vous pouvez avoir des compartiments séparés pour prendre en charge le déploiement bleu/vert.
  • Simplifier la gestion des autorisations. Par exemple, vous pouvez créer un compartiment séparé pour vos ressources réseau (VCN, sous-réseaux, passerelles Internet, etc.), puis autoriser uniquement les administrateurs réseau à accéder à ce compartiment.
  • Mesurer l’utilisation séparément pour des unités commerciales distinctes afin de facturer correctement ces unités commerciales pour leur consommation de ressources cloud.
  • Minimiser l’ensemble des ressources visibles par certains ensembles d’utilisateurs. Par exemple, vous voudrez peut-être avoir un compartiment séparé pour votre équipe des finances qui n’est visible que pour certains collaborateurs.

Les compartiments peuvent-ils contenir des ressources dans plusieurs domaines de disponibilité ?

Oui. Les compartiments sont des regroupements logiques de ressources distincts des constructions physiques des domaines de disponibilité. Un compartiment individuel peut contenir des ressources à travers les domaines de disponibilité.

Comment les compartiments sont-ils utilisés pour le contrôle d’accès ?

L'ensemble des stratégies est associé au compartiment racine ou à un compartiment enfant. Chaque stratégie consiste en une ou plusieurs déclarations de stratégie qui suivent cette syntaxe de base :

Autoriser le groupe dans le compartiment

Les déclarations de stratégie vous permettent d’utiliser des compartiments pour simplifier la gestion des autorisations ; par exemple, vous pouvez écrire une stratégie qui permet au groupe HRAdministrators de gérer toutes les ressources dans le compartiment HRCompartment.

Puis-je supprimer des compartiments ?

Oui, vous pouvez supprimer des compartiments.

Puis-je déplacer des arborescences de compartiments entiers et leurs ressources incluses ?

Oui, vous pouvez déplacer des arborescences de compartiments entières et leurs ressources incluses vers d’autres compartiments parents.

Puis-je déplacer des ressources, telles qu’une instance de calcul ou un volume de blocs, d’un compartiment vers un autre ?

Oui, vous pouvez déplacer des ressources d’un compartiment vers un autre.

Puis-je créer une hiérarchie de compartiments ?

Oui, vous pouvez créer une hiérarchie de compartiments en les imbriquant. Avec des compartiments hiérarchiques ou imbriqués, l’administrateur système peut organiser les ressources et permettre aux administrateurs de niveau inférieur de faire de même, tout en conservant une visibilité et un contrôle complets via une stratégie.

Combien de niveaux de profondeur pouvez-vous imbriquer des compartiments ?

La profondeur maximale d’un compartiment imbriqué est de six.

Les stratégies sur un compartiment de niveau supérieur s’appliquent-elles à un sous-compartiment ?

Oui, les stratégies sur les compartiments de niveau supérieur sont héritées par les sous-compartiments.

Puis-je suivre les coûts et l’utilisation par compartiments ?

Oui, vous pouvez suivre les coûts et l’utilisation par compartiments dans Mes services.

Qu’est-ce que le compartiment racine ?

Pour chaque compte, Oracle Cloud Infrastructure crée automatiquement un compartiment de niveau supérieur appelé compartiment racine. Tout comme le dossier racine dans un système de fichiers, le compartiment racine se comporte exactement comme ses compartiments enfants, à l’exception de quelques caractéristiques spéciales :

  • Étant donné que les autorisations sont hiérarchiques, les autorisations de groupe dans le compartiment racine s’appliqueront à tous les compartiments enfants. Par exemple, si le groupe NetworkAdmins est autorisé à gérer les réseaux virtuels cloud (VCN) dans le compartiment racine, ce groupe pourra gérer les VCN dans tous les compartiments.
  • Actuellement, tous les utilisateurs et groupes sont créés à l’intérieur du compartiment racine. Les stratégies peuvent être utilisées pour leur accorder l’accès à des compartiments enfants spécifiques uniquement.

Remarque : actuellement, vous ne pouvez créer des compartiments supplémentaires que dans le compartiment racine et non dans d’autres compartiments.

Quand dois-je créer des ressources dans le compartiment racine et quand dois-je les créer dans un compartiment enfant ?

Généralement, les ressources doivent être créées dans un compartiment qui n’est pas le compartiment racine. Il est préférable de concevoir la hiérarchie de vos compartiments avant de commencer à créer des compartiments et des ressources.

Utilisateurs

Que peut faire un utilisateur de la console Oracle Cloud Infrastructure ?

Un utilisateur est une personne qui peut s’authentifier auprès d’OCI IAM et qui dispose des privilèges suffisants pour consommer ou gérer les ressources cloud au sein de votre compte. Les administrateurs peuvent créer un ou plusieurs utilisateurs dans leur compte et les affecter à des groupes afin de leur accorder des autorisations sur les ressources dans des compartiments spécifiques.

Qui peut créer et gérer des utilisateurs ?

Votre compte est provisionné avec un seul utilisateur (l'administrateur par défaut) et un seul groupe (celui des administrateurs), dont l'administrateur par défaut est membre. Ce groupe (Administrateurs) dispose d’un accès complet à votre compte. Cet utilisateur spécial (administrateur par défaut) doit créer des utilisateurs supplémentaires ou accorder l’autorisation à d’autres utilisateurs de créer de nouveaux utilisateurs.

De quel accès dispose un nouvel utilisateur lors de sa création ?

Par défaut, un nouvel utilisateur n’a pas l’autorisation d’utiliser une ressource ou un service au sein de votre compte - toutes les autorisations doivent être explicitement accordées. Cette approche vous permet d’adhérer au principe de sécurité du moindre privilège selon lequel vous accordez à chaque utilisateur uniquement l’accès requis pour cet utilisateur spécifique. Vous devez soit ajouter explicitement l’utilisateur à un groupe existant, soit créer un nouveau groupe pour lui, puis attribuer les autorisations appropriées à ce groupe via une stratégie.

Puis-je activer et désactiver l’accès utilisateur ?

Les administrateurs peuvent désactiver ou verrouiller un utilisateur afin de désactiver temporairement son accès. Ils peuvent également réinitialiser les mots de passe des utilisateurs ou supprimer des clés.

Pouvons-nous définir l'expiration des mots de passe ? Comment faire pivoter les informations d’identification ?

Oui, les stratégies de mot de passe vous permettent de définir un délai d'expiration pour les mots de passe. Vous pouvez également automatiser la réinitialisation des mots de passe, les modifications de clé ou les modifications d'utilisateurs et d'appartenances à des groupes par le biais d'une API REST et de SDK.

Politiques

Qu’est-ce qu’une stratégie ?

Une stratégie est un document composé d’instructions de stratégie descriptives qui accordent des autorisations spécifiques à des groupes d’utilisateurs. Elles sont écrites avec une syntaxe de type SQL facile à comprendre. Des exemples de stratégies peuvent être appliqués :

  • Les administrateurs système peuvent « terminer » ou « redémarrer » vos instances de calcul à nu.
  • Les administrateurs réseau peuvent administrer entièrement toutes les ressources d’infrastructure liées au réseau.
  • Les administrateurs informatiques peuvent créer des utilisateurs et modifier les appartenances aux groupes

Une stratégie permet à un groupe de travailler de certaines manières avec des types spécifiques de ressources dans un compartiment particulier. Facultativement, les stratégies peuvent contenir une clause conditionnelle (« où ... ») qui restreint davantage la déclaration de stratégie. Les stratégies respectent la syntaxe suivante :

Autoriser le groupe dans le compartiment [where]

Par exemple, voici une déclaration de stratégie qui accorde des autorisations pour utiliser des instances de calcul :

Autoriser le groupe Développeurs à utiliser des instances dans le compartiment ProjectA

  • « nom_groupe » est le nom du groupe auquel des autorisations ont été accordées.
  • Les verbes sont des actions que vous pouvez réaliser sur les ressources, par exemple, les inspecter, les lire, les utiliser ou les gérer.
  • « type-ressource » est la ressource cloud à laquelle des autorisations sont accordées. Les types de ressource peuvent par exemple être des instances, des volumes et des tables de routage.
  • « nom_compartiment » est le nom du compartiment dans lequel les ressources sont organisées.
  • Les « conditions » sont des spécifications supplémentaires qui restreignent la portée de la déclaration de stratégie. En voici quelques exemples : "where request.user.id=target.user.id" ou "where target.group_name != Administrators".

Pour plus de détails, consultez la section OCI IAM de la documentation Oracle Cloud Infrastructure.

Les stratégies pour le compartiment racine sont-elles héritées des compartiments enfants ?

Oui. Une stratégie accordant des autorisations dans le compartiment racine accorde automatiquement les mêmes autorisations pour tous les compartiments enfants. Par exemple, la stratégie suivante autorise tous les utilisateurs du groupe « InstanceAdmins » à gérer les instances dans le compartiment racine ainsi que tous les compartiments enfants :

Autoriser le groupe InstanceAdmins à gérer les instances dans la location

Les stratégies peuvent-elles être limitées à des compartiments spécifiques ?

Oui. Chaque stratégie est « attachée » à un compartiment. L’endroit où vous l’attachez contrôle qui peut ensuite la modifier ou la supprimer. Si vous attachez une stratégie au compartiment racine, toute personne autorisée à gérer les stratégies dans le compartiment racine peut la modifier ou la supprimer. Si vous attachez plutôt la stratégie au compartiment, alors toute personne ayant accès à la gestion des stratégies dans ce compartiment peut la modifier ou la supprimer. En termes pratiques, cela signifie qu’il est facile de donner aux administrateurs de compartiment (c’est-à-dire un groupe ayant accès à « gérer toutes les ressources » dans le compartiment) un accès pour gérer les stratégies de leur propre compartiment, sans leur donner un accès plus large pour gérer les stratégies qui résident dans le compte.

Où puis-je en savoir plus sur la rédaction de déclarations de stratégie ?

Pour plus d’informations sur la stratégie et les déclarations de stratégie, consultez le sections Pour commencer avec les politiques et Stratégies communes dans la documentation Oracle Cloud Infrastructure.

Stratégie de refus IAM

FAQ sur les stratégies de refus d'identité et d'accès OCI

Ces FAQ guident les utilisateurs à travers les stratégies de refus d'Oracle Cloud Infrastructure (OCI) Identity and Access Management, qui permettent aux utilisateurs qui peuvent gérer des stratégies de bloquer explicitement les actions, d'améliorer la sécurité et de simplifier le contrôle d'accès dans les locations OCI. Pour plus de détails, reportez-vous à la documentation OCI Identity and Access Management.

Introduction à IAM Deny

Comment activer la fonctionnalité de refus d'IAM dans OCI ?

IAM Deny est une fonctionnalité de consentement qui doit être explicitement activée par un administrateur de location via la console OCI, puis les Politiques, Actions et les paramètres de Politiques. Elle ne peut pas être activée par les utilisateurs réguliers ou les auteurs de politiques. Une fois activée, la fonctionnalité devient une partie permanente de la structure IAM de la location et ne peut pas être désactivée via l'interface utilisateur. Toutefois, un administrateur de location ayant la possibilité d'écrire des stratégies de refus peut contrôler efficacement l'utilisation des politiques de refus en écrivant une stratégie de refus de niveau racine qui empêche tous les utilisateurs de créer ou de modifier des stratégies de refus, à l'exception du groupe d'administrateurs par défaut. Exemple : Deny any-user pour gérer les stratégies dans la location où target.policy.type='DENY'

Lorsque le refus IAM est activé

  • OCI génère automatiquement une stratégie de refus par défaut au niveau du compartiment racine pour une utilisation sûre.
  • Seuls le groupe d'administrateurs par défaut et l'administrateur de location qui a activé IAM Deny conservent les droits d'accès permettant de configurer et de gérer les politiques de refus.
  • L'administrateur de location peut ensuite mettre à jour la politique de refus par défaut pour autoriser les utilisateurs autorisés, tels que les groupes d'administrateurs dans les compartiments Banque, Investissements et Conformité, à écrire des stratégies de refus dans la console OCI.

Que sont les instructions de refus d'OCI Identity and Access Management ?

Avec les instructions de refus OCI Identity and Access Management, vous pouvez écrire des politiques de refus explicites pour bloquer des actions spécifiques dans les locations OCI, en complément des instructions OCI Identity and Access Management pour un contrôle d'accès précis. Par exemple, vous pouvez utiliser Deny any-user pour inspecter toutes les ressources dans la location, où request.service='streaming' pour définir une garde-corps empêchant tout accès au service OCI Streaming dans votre location, tout en autorisant d'autres droits d'accès via des instructions d'autorisation.

Quelles sont les limites des stratégies de refus IAM ?

Les stratégies de refus IAM partagent les mêmes limites que les stratégies d'autorisation. Une location peut comporter jusqu'à 100 objets de politique IAM, chacun contenant jusqu'à 50 instructions de politique (refuser ou autoriser), mais le nombre total d'instructions de politique pour tous les objets de la location est limité à 100.

Quels méta-verbes sont pris en charge par les politiques de refus IAM, et sont-ils nouveaux ou existants ?

Les politiques de refus IAM utilisent les méta-verbes existants : gérer, utiliser, lire et inspecter. Aucun nouveau méta-verbe n'est introduit. Contrairement aux instructions d'autorisation, qui accordent des autorisations de manière additive (par exemple, manage inclut toutes les autorisations inférieures), les instructions de refus sont soustractives, bloquant uniquement les autorisations spécifiées et tout niveau supérieur de la hiérarchie.

Par exemple, la politique Deny group DevOps de gestion d'instance dans le compartiment Prod bloque uniquement le droit d'accès en gestion, ce qui permet à DevOps d'effectuer des actions d'utilisation, de lecture et d'inspection. Toutefois, le refus d'inspection bloque toutes les autorisations, car il s'agit de l'autorisation de niveau de base.

Création et gestion des politiques

Où écrire des politiques de refus dans la console OCI ?

Les politiques de refus sont créées dans la même interface de console OCI que les politiques d'autorisation. Accédez à Identité et sécurité, puis à Stratégies, sélectionnez un compartiment et utilisez l'éditeur de politiques pour ajouter le mot-clé de refus en même temps que Autoriser. Le processus ne nécessite aucune interface distincte.

Existe-t-il un objet de politique distinct pour les politiques de refus ?

Non. Les politiques de refus utilisent le même objet de politique que les politiques d'autorisation. Les deux sont gérés au sein du même objet de politique, ce qui simplifie l'administration.

Puis-je inclure des instructions de refus et d'autorisation dans un seul objet de politique IAM ?

Oui. Vous pouvez combiner des instructions de refus et d'autorisation dans un objet de politique pour un contrôle d'accès flexible.

Par exemple, une seule politique peut inclure des instructions d'autorisation et de refus, comme indiqué ci-dessous :

Refuser aux stagiaires de groupe d'utiliser une instance dans le compartiment Finance
Autoriser les administrateurs de groupe à gérer toutes les ressources dans le compartiment Finance

Ces politiques permettent aux administrateurs de gérer toutes les ressources du compartiment Finance tout en empêchant les stagiaires d'effectuer des opérations d'écriture sur les instances, ce qui simplifie le contrôle d'accès.

Comment empêcher les utilisateurs qui peuvent gérer des politiques d'écrire des politiques de refus ?

Pour empêcher les utilisateurs de politique qui peuvent gérer des politiques d'écrire des politiques de refus, créez une politique de refus au niveau racine pour bloquer la création de politiques de refus.

Exemple : Deny group PolicyAdmins pour gérer les politiques dans la location où target.policy.type='DENY'

Cette politique garantit que PolicyAdmins ne peut pas créer ou modifier des politiques de refus tout en leur permettant de gérer des politiques d'autorisation. Les groupes d'administrateurs par défaut restent exemptés et peuvent écrire des politiques de refus si nécessaire.

Comment bloquer l'ensemble d'un service OCI à l'aide d'une politique de refus IAM ?

Pour bloquer un service OCI entier, créez une politique de refus au niveau du compartiment racine ciblant les ressources ou les actions du service à l'aide d'une condition telle que request.service.name.

Par exemple, pour bloquer l'ensemble de la location du service OCI Streaming

Deny any-user pour inspecter toutes les ressources dans la location où request.service.name='streaming'

Cette politique empêche tout accès au service OCI Streaming, ce qui est utile pour la conformité dans des secteurs tels que les soins de santé. Placez la politique au niveau du compartiment racine pour vous assurer qu'elle s'applique à tous les compartiments, ce qui réduit l'étalement de la politique.

Comment refuser la gestion des ressources d'un groupe dans une région spécifique ?

Pour empêcher un groupe de gérer des ressources dans une région spécifique, utilisez une politique de refus avec une valeur request.region condition.

Par exemple, si vous voulez empêcher un groupe d'effectuer des actions autres que l'accès en lecture seule dans une région spécifique, vous pouvez écrire une politique de refus comme suit :

Deny group RegionalAdmins pour utiliser toutes les ressources dans la location où request.region='sa-saopaulo-1'

Cette politique empêche le groupe RegionalAdmins d'utiliser des ressources dans la région de São Paulo, mais autorise les droits d'accès d'utilisation, de lecture et d'inspection. Il est idéal pour les institutions financières qui respectent les lois régionales sur la résidence des données.

Comment refuser l'accès d'un groupe aux instances de calcul d'un compartiment spécifique ?

Pour empêcher un groupe d'accéder aux instances de calcul d'un compartiment spécifique, utilisez la commande suivante :

Deny group DevTeam pour inspecter l'instance dans le compartiment ProjectX

Cette politique bloque tous les droits d'accès (inspecter, lire, utiliser, gérer) sur les instances de calcul du compartiment ProjectX. Par exemple, une entreprise de technologie peut l'utiliser pour empêcher DevTeam d'accéder aux instances de production, en isolant les environnements de développement et de production pour une sécurité renforcée.

Comment refuser la gestion du stockage d'objets dans un compartiment spécifique à un groupe ?

Pour empêcher un groupe de gérer des ressources de stockage d'objets dans un compartiment spécifique, utilisez la commande suivante :

Refuser le groupe StorageUsers pour inspecter la famille d'objets dans le compartiment DataLake

Cette politique bloque tous les droits d'accès (inspecter, lire, utiliser, gérer) sur les ressources de stockage d'objets dans le compartiment DataLake. Par exemple, un organisme de santé peut l'appliquer pour empêcher StorageUsers d'accéder aux données sensibles des patients, ce qui permet de respecter les réglementations en matière de confidentialité.

Comment déléguer des tâches aux utilisateurs qui peuvent gérer une politique dans un compartiment enfant sans leur permettre de modifier certaines ressources ou d'écrire des politiques de refus ?

Pour déléguer des tâches en toute sécurité aux utilisateurs qui peuvent gérer une politique dans un compartiment enfant, vous pouvez :

  • Accordez des droits d'accès spécifiques aux compartiments ou ressources désignés à l'aide de politiques d'autorisation.
  • Limitez l'autorisation de refus de politiques pour empêcher les utilisateurs qui peuvent gérer une politique dans un compartiment enfant de créer des politiques perturbatrices.
  • Utilisez des politiques de refus pour bloquer l'accès aux ressources sensibles.

Par exemple, pour permettre aux utilisateurs qui peuvent gérer une politique dans un compartiment enfant de gérer des ressources de calcul dans un compartiment tout en limitant les modifications réseau et en refusant la création de politiques, utilisez les politiques suivantes :

Refuser au groupe ProjectAdmins de gérer network-family dans le compartiment ProjectX Refuser au groupe ProjectAdmins de gérer les politiques dans le compartiment ProjectXoù target.policy.type='DENY'

Autoriser le groupe ProjectAdmins à gérer instance-family dans le compartiment ProjectX

Ces politiques permettent à ProjectAdmins de gérer les instances dans ProjectX, de les empêcher de modifier les réseaux et d'écrire des politiques de refus, ce qui prend en charge la délégation sécurisée. Une organisation financière peut utiliser cette approche pour permettre aux sous-administrateurs de gérer les ressources de calcul tout en maintenant un contrôle strict sur les configurations réseau et la gestion des politiques.

Mécanismes de sécurité et de récupération

Les politiques de refus sont-elles évaluées avant les politiques d'autorisation ?

Oui. OCI Identity and Access Management utilise un premier modèle d'évaluation de refus, dans lequel les politiques de refus sont évaluées avant d'autoriser les politiques dans la hiérarchie de compartiments. Si une demande correspond à une politique de refus, l'accès est bloqué, quelles que soient les politiques d'autorisation. Les groupes d'administrateurs par défaut sont exemptés des politiques de refus pour empêcher les verrouillages.

Par exemple, les politiques suivantes peuvent exister dans le compartiment Prod :

Refuser au groupe Devs de gérer instance-family dans le compartiment Prod
Autoriser le groupe Devs à gérer toutes les ressources dans le compartiment Prod

La politique de refus empêche les développeurs de gérer les instances, tandis que les administrateurs par défaut peuvent toujours gérer les instances.

Que se passe-t-il si un utilisateur qui peut gérer des politiques écrit une stratégie de refus qui verrouille tous les utilisateurs de la location ?

Le groupe d'administrateurs par défaut est exempté des politiques de refus. Ses membres peuvent donc se connecter, afficher et modifier les politiques pour résoudre les verrouillages. Cette protection permet d'éviter les pannes à l'échelle de la location.

Exemple : si Refuser any-user pour inspecter toutes les ressources dans la location est appliqué, les utilisateurs du groupe d'administrateurs par défaut peuvent toujours se connecter et accéder à l'éditeur de politiques pour l'enlever ou l'ajuster.

Comment effectuer une récupération à partir d'une politique de refus à l'échelle de la location qui verrouille tous les utilisateurs ?

Une politique de refus à l'échelle de la location, telle que Refuser à tout utilisateur d'inspecter toutes les ressources de la location, peut bloquer l'accès de tous les utilisateurs, entraînant une interruption de service. Pour récupérer :

1. Connectez-vous en tant que membre du groupe d'administrateurs par défaut (exempt des politiques de refus).
2. Dans la console OCI, accédez à Identité et sécurité, puis à Politiques.
3. Localisez la politique problématique dans le compartiment racine.
4. Modifiez ou supprimez la politique (par exemple, remplacez Refuser tout utilisateur pour inspecter toutes les ressources de la location par Refuser les stagiaires du groupe pour inspecter toutes les ressources de la location).
5. Vous pouvez également utiliser l'interface de ligne de commande OCI suivante : OCI iam policy update --policy-id --statements '["Deny group Interns to inspect all-resources in tenancy"]

Par exemple, si un utilisateur qui peut gérer une politique dans un compartiment enfant applique accidentellement Refuser à tout utilisateur d'inspecter toutes les ressources dans la location, un utilisateur de groupe d'administrateurs par défaut peut se connecter et la modifier pour cibler uniquement le groupe Invités, ce qui empêche les verrouillages futurs. Pour éviter de tels problèmes, testez soigneusement les politiques et limitez le refus de la paternité des politiques.

Effets d'autorisation

Que se passe-t-il si je refuse la permission de « gérer » ?

Le refus de gérer les blocs n'autorise que la gestion, laissant l'utilisation, la lecture et l'inspection intactes.

Exemple : le groupe de refus DevOps permettant de gérer l'instance dans le compartiment Production empêche DevOps de gérer les instances, mais lui permet de les utiliser, de les lire ou de les inspecter.

Que se passe-t-il si je refuse l'autorisation d'utilisation ?

Le refus des blocs d'utilisation utilise et gère les droits d'accès, mais la lecture et l'inspection sont toujours autorisées.

Exemple : Refuser aux testeurs de groupe d'utiliser le bucket dans le compartiment QA empêche les testeurs d'utiliser ou de gérer les buckets, mais permet de les lire ou de les inspecter.

Que se passe-t-il si je refuse la permission de « lire » ?

Le refus des autorisations de lecture, d'utilisation et de gestion des blocs de lecture, mais l'inspection est toujours autorisée.

Exemple : le refus des auditeurs de groupe de lire les journaux dans le compartiment Logging empêche les auditeurs de lire, d'utiliser ou de gérer les journaux, mais autorise l'inspection.

Que se passe-t-il si je refuse la permission « d'inspecter » ?

Le refus de l'inspection bloque tous les droits d'accès (inspecter, lire, utiliser, gérer) car l'inspection est l'autorisation de niveau de base.

Exemple : interdire aux visualiseurs de groupe d'inspecter l'instance dans le compartiment Public empêche complètement les visualiseurs d'accéder aux instances.

Cas d'usage avancés et dépannage

Comment surveiller les politiques de refus pour s'assurer qu'elles fonctionnent comme prévu ?

Consultez les journaux d'audit OCI pour suivre les actions bloquées par les stratégies de refus. Si une politique telle que Deny any-user pour inspecter le shell cloud dans la location provoque des problèmes, affinez-la pour que les stagiaires du groupe Deny inspectent le shell cloud dans la location. Configurez des alertes pour que les modifications de politiques restent proactives.

Exemple : Surveillez les journaux pour ajuster les pilotes de groupe de refus afin de gérer la famille d'instances dans le compartiment Fleet s'il bloque les tâches légitimes.

Quelles sont les erreurs courantes à éviter avec les politiques de refus ?

Le premier modèle de refus d'OCI donne la priorité aux politiques de refus plutôt qu'aux politiques d'autorisation, ce qui peut entraîner des perturbations si les politiques sont trop larges. Les erreurs courantes incluent l'application de verrouillages à l'échelle de la location ou du compartiment ou l'utilisation de conditions basées sur des balises trop larges.

Par exemple, une stratégie telle que Refuser à tout utilisateur d'inspecter toutes les ressources de la location peut bloquer tous les accès, ce qui entraîne un verrouillage à l'échelle de la location. Utilisez plutôt des politiques ciblées, telles que les suivantes :

Deny group Interns to inspect all-resources in compartment Public

Cela limite l'accès au groupe Interns uniquement, en évitant les interruptions involontaires. Une entreprise technologique peut utiliser cette approche pour limiter l'accès des clients tout en préservant les fonctionnalités pour les autres utilisateurs. Pour éviter les problèmes, testez les politiques dans un environnement de modèle d'environnement restreint, gardez-les simples et limitez la création de politiques de refus.

Les instructions de refus sont-elles prises en charge pour les cas d'usage inter-locations ?

Oui. Les instructions de refus prennent en charge les scénarios inter-locations. Une instruction d'approbation ou de refus d'admission unique peut bloquer les demandes inter-établissements, contrairement aux paires d'approbation/d'admission nécessitant que les deux soient satisfaites.

La location source suivante est un exemple :

Approuvez le groupe Devs pour utiliser object-family dans la location PartnerTenancy Refusez d'approuver le groupe Devs pour gérer object-family dans la location PartnerTenancy

Cela permet aux développeurs d'utiliser le stockage d'objets dans PartnerTenancy, mais bloque les actions de gestion. Une organisation partenaire peut l'utiliser pour activer le partage de données tout en gardant le contrôle sur les ressources.

Comment les politiques de refus interagissent-elles avec OCI Zero Trust Packet Routing ?

OCI Zero Trust Packet Routing fonctionne au niveau de la couche 4 (niveau réseau) du modèle Open Systems Interconnection, tandis qu'IAM refuse que les politiques imposent l'accès au niveau de la couche 7 (niveau application). Si OCI Zero Trust Packet Routing autorise la communication, les politiques de refus IAM peuvent toujours bloquer les actions.

Exemple :

  • Politique OCI Zero Trust Packet Routing : autorisez dynamic-group FrontEnd dans VCN web:vcn à se connecter à backend:server-instance dans VCN vcn:server autorise le trafic réseau.
  • Politique IAM : refusez le groupe dynamique FrontEnd pour gérer la famille d'instances dans le compartiment ProjectA bloque la gestion des instances malgré l'autorisation OCI Zero Trust Packet Routing.

Les politiques OCI Zero Trust Packet Routing et IAM sont évaluées séquentiellement, IAM étant le gardien final.

Comment les politiques définies par le système interagissent-elles avec les politiques de refus ?

Les politiques du système standard remplacent toujours les politiques de refus définies par l'utilisateur pour garantir le fonctionnement des services essentiels (par exemple, autoriser tout utilisateur à lire des domaines dans la location où target.domain.id='request.domain.id').

Exemple : une politique de refus telle que Refuser aux utilisateurs de groupe de lire les domaines dans la location ne bloquera pas une politique du système standard autorisant l'accès au domaine.

Les politiques de refus sont-elles évaluées différemment des politiques d'autorisation ?

OCI Identity and Access Management utilise un premier modèle d'évaluation de refus, dans lequel les politiques de refus sont évaluées avant d'autoriser les politiques dans la hiérarchie de compartiments. Si une demande correspond à une politique de refus, l'accès est bloqué, quelles que soient les politiques d'autorisation. Les politiques définies par le système peuvent remplacer les refus définis par l'utilisateur (voir la question 27). Les groupes d'administrateurs par défaut sont exemptés des politiques de refus, de sorte qu'ils peuvent gérer les politiques pendant les verrouillages.

Exemple : si les utilisateurs de groupe de refus pour la gestion de la famille d'instances dans le compartiment Prod existent en même temps que les utilisateurs de groupe de privilège pour la gestion de toutes les ressources dans le compartiment Prod, la politique de refus bloque la gestion d'instance.

Le refus d'IAM remplace-t-il les rôles d'administration de domaine d'identité Oracle (par exemple, administrateur de domaine d'identité, administrateur de sécurité et gestionnaire d'utilisateurs) ?

Dans la version actuelle, les politiques de refus IAM ne remplacent pas les rôles d'administration Oracle Identity Cloud Service (par exemple, administrateur de domaine d'identité, administrateur de sécurité et gestionnaire d'utilisateurs). C'est une limitation. Dans la prochaine version, IAM Deny prévaudra sur les rôles d'administration d'Oracle Identity Cloud Service pour un contrôle d'accès cohérent.

Comment puis-je utiliser IAM Deny pour que l'accès à un service ne se fasse que via le nouvel accès au service privé OCI ?

L'accès au service privé OCI permet d'accéder aux services Oracle via un chemin de réseau privé plutôt que via le réseau Internet public. OCI Private Service Access est conçu pour les clients qui souhaitent une connectivité privée entre leurs workloads et les services Oracle, pour des raisons de conformité, de performances ou de sécurité.

Si vous utilisez OCI Private Service Access pour accéder en toute sécurité à un service (tel qu'OCI Object Storage ou OCI Streaming), vous pouvez imposer que tous les accès doivent passer par OCI Private Service Access. Avec IAM Deny, vous pouvez bloquer explicitement tout le trafic d'accès au service privé non OCI vers un service, même si des politiques d'autorisation existent.

Par exemple, pour autoriser l'accès à OCI Object Storage uniquement via OCI Private Service Access, utilisez

Refusez à any-user d'accéder à object-family dans la location où n'importe quel élément {not request.gateway.id, request.gateway.type !='privateserviceaccess'}

Cette politique empêche les utilisateurs d'accéder à OCI Object Storage sauf si leur trafic est acheminé via une adresse d'accès au service privé OCI. Il est particulièrement utile si vous avez configuré une configuration d'accès au service privé OCI pour les données sensibles et que vous souhaitez éliminer le risque d'accès via des acheminements publics involontaires.

Quelle est la différence entre les politiques de refus OCI Identity and Access Management et Oracle Security Zones, et quand dois-je les utiliser ?

OCI propose des politiques de refus IAM et Oracle Security Zones pour sécuriser votre location en empêchant les actions non sécurisées. Bien que les deux renforcent votre sécurité, ils diffèrent dans la façon dont ils fonctionnent et leur flexibilité.

  • Similitudes : IAM refuse les politiques et Oracle Security Zones bloque les actions spécifiques pour protéger vos ressources et appliquer les meilleures pratiques de sécurité dans votre location OCI.
  • Différences clés
    • Stratégies de refus IAM : vous créez des politiques personnalisées pour bloquer les actions en fonction de conditions telles que l'identité de l'utilisateur, le type de ressource, l'adresse IP ou les balises. Ces politiques agissent comme des garde-fous, et à partir de la prochaine version, elles prévaudront sur toutes les stratégies IAM. Par exemple, vous pouvez empêcher un groupe d'utilisateurs spécifique de supprimer des ressources critiques si la ressource a une balise spécifique, telle que environment:production.
    • Oracle Security Zones : ces règles appliquent des règles de sécurité prédéfinies aux compartiments ou à l'ensemble de la location. Lorsqu'elle est activée, Oracle Security Zones applique automatiquement des restrictions pour certains ensembles de services OCI, telles que la prévention des sous-réseaux publics ou la désactivation du cryptage. Vous n'avez pas besoin d'écrire des politiques : les règles sont intégrées et vérifient automatiquement les paramètres des ressources.
  • Quand l’utiliser
    • Utilisez les politiques de refus IAM pour les restrictions personnalisées et ciblées, telles que le blocage d'utilisateurs ou d'actions spécifiques en fonction des conditions définies.
    • Utilisez Oracle Security Zones pour des règles de sécurité automatiques et prêtes à l'emploi afin d'appliquer les meilleures pratiques avec une configuration minimale.
    • Combinez les deux pour une protection plus forte. Activez Oracle Security Zones pour des garde-corps étendus et de référence et ajoutez des politiques de refus IAM pour des contrôles spécifiques et personnalisés.

Obtenir de l'aide sur les politiques de refus OCI Identity and Access Management

Pour obtenir de l'aide, consultez la documentation OCI Identity and Access Management ou contactez votre équipe de compte OCI.

Groupes

Qu’est-ce qu’un groupe ?

Un groupe est un ensemble d’utilisateurs qui ont besoin de privilèges d’accès similaires pour utiliser ou gérer une ressource spécifique dans votre compte. Les utilisateurs peuvent appartenir à plusieurs groupes. Les autorisations sont additives. Par exemple, si l’appartenance à un groupe permet à un utilisateur d’utiliser des instances de calcul et l’appartenance à un deuxième groupe permet à cet utilisateur de gérer des volumes de blocs, alors l’utilisateur est autorisé à gérer à la fois les instances et les volumes de blocs.

Les administrateurs écrivent des stratégies qui spécifient des groupes (pas des utilisateurs individuels) avec l’accès requis dont ils ont besoin, que ce soit pour un compartiment spécifique ou le compte. Les administrateurs ajoutent ensuite des utilisateurs aux groupes appropriés.

Puis-je avoir plusieurs administrateurs ?

Oui. Votre compte est provisionné avec un seul administrateur par défaut qui appartient à un groupe Administrateurs dans votre compartiment racine. Ce groupe a tous les privilèges pour créer et gérer toutes les ressources Oracle Cloud Infrastructure de votre compte, y compris les utilisateurs, les groupes, les stratégies et les compartiments, ainsi que toutes les autres ressources d’infrastructure cloud dans tous les compartiments. Vous pouvez ajouter des utilisateurs supplémentaires à ce groupe d’administrateurs.

Fonctionnalités

Comment OCI IAM répond-il aux exigences d'expiration des mots de passe ?

Les stratégies de mot de passe vous permettent de définir un délai d'expiration pour les mots de passe. Une stratégie de mot de passe par défaut définit une expiration des mots de passe après 120 jours. Cette durée est configurable. Différentes stratégies peuvent être appliquées à des sous-ensembles d'utilisateurs.

Comment exécuter des tâches sur une instance de calcul sans y intégrer des informations d'identification utilisateur ?

Utilisez des groupes de ressources dynamiques pour affecter un ensemble de ressources de calcul à un groupe. Vous pouvez ensuite affecter ces autorisations de groupe via une stratégie. Cela permet à une instance de calcul d'accéder à d'autres ressources OCI en toute sécurité, sans intégrer d'informations d'identification dans des scripts.

Fédération

Qu’est-ce que la fédération d’identité dans Oracle Cloud Infrastructure ?

La fédération d’identité est un mécanisme permettant de déléguer la gestion des utilisateurs de votre location Oracle Cloud Infrastructure à une autre entité appelée fournisseur d’identité ou IdP. Ceci est utile pour les entreprises qui ont un système d’identité existant qu’elles souhaitent utiliser, plutôt que de créer et de maintenir un nouvel ensemble d’utilisateurs. La fédération nécessite une configuration unique entre Oracle Cloud Infrastructure et l’IdP connu sous le nom de fédération d’approbation.

Que sont les utilisateurs fédérés ?

Les utilisateurs fédérés (identités externes) sont des utilisateurs que vous gérez en dehors d’Oracle Cloud Infrastructure (par exemple, dans votre répertoire d’entreprise), mais à qui vous accordez l’accès à votre compte Oracle Cloud Infrastructure. Ils diffèrent des utilisateurs Oracle Cloud Infrastructure, qui sont créés et maintenus dans votre compte Oracle Cloud Infrastructure.

Les utilisateurs fédérés peuvent-ils accéder à la console Oracle Cloud Infrastructure ?

Oui. Les utilisateurs fédérés peuvent accéder à la console Oracle Cloud Infrastructure.

Les utilisateurs fédérés peuvent-ils accéder au SDK et à la CLI Oracle Cloud Infrastructure ?

Oui. Les utilisateurs fédérés peuvent accéder au SDK et à la CLI Oracle Cloud Infrastructure.

Quelles actions les utilisateurs Oracle Cloud Infrastructure peuvent-ils effectuer dans la console que les utilisateurs fédérés ne peuvent pas effectuer ?

Les utilisateurs fédérés ne peuvent ni modifier ni réinitialiser leurs mots de passe dans la console Oracle Cloud Infrastructure.

Comment puis-je contrôler ce qu’un utilisateur fédéré est autorisé à faire lorsqu’il est connecté à la console ?

Vous utilisez les mêmes stratégies Oracle Cloud Infrastructure pour gérer les utilisateurs fédérés que vous utilisez pour gérer les utilisateurs natifs. Vous mappez les rôles et les groupes de votre fournisseur d’identité aux groupes d’Oracle Cloud Infrastructure. Lorsqu’un utilisateur fédéré se connecte, la console Oracle Cloud Infrastructure applique ensuite des stratégies basées sur son appartenance au groupe Oracle Cloud Infrastructure, tout comme avec les utilisateurs natifs. Pour obtenir des exemples, consultez la documentation.

Un seul rôle ou groupe de votre fournisseur d’identité peut être mappé à plusieurs groupes Oracle Cloud Infrastructure. De plus, plusieurs rôles ou groupes de votre fournisseur d’identité peuvent être associés à un seul groupe Oracle Cloud Infrastructure.

À combien d’utilisateurs fédérés puis-je donner accès à la console Oracle Cloud Infrastructure ?

Il n’y a pas de limite au nombre d’utilisateurs fédérés qui peuvent avoir accès à la console.

Quels fournisseurs d’identité prenez-vous en charge ?

OCI IAM prend en charge tous les fournisseurs d'identités compatibles SAML 2.0, Open ID Connect ou OAuth, y compris les solutions populaires telles qu'Oracle Access Manager, Microsoft Active Directory Federation Services (AD FS) et Okta.

Authentification multifacteur

Qu'est-ce que l'authentification multifacteur (MFA) et pourquoi est-elle importante ?

Par le passé, les comptes étaient seulement protégés par un nom d'utilisateur et un mot de passe. Toutefois, les mots de passe peuvent être difficiles à mémoriser et relativement faciles à deviner à l'aide de techniques courantes de cyberattaques, telles que le reniflage réseau, l'hameçonnage et les attaques par force brute. Si un pirate vole vos identifiants, il peut accéder à tous vos comptes et ressources.

L'authentification multifacteur (MFA) est une fonction de sécurité reconnue qui permet de réduire le risque de vol de compte en vérifiant de manière plus robuste l'identité des utilisateurs d'une application. La MFA nécessite que les utilisateurs fournissent plusieurs formes d'authentification. Il existe trois catégories de facteurs d'authentification : ce que vous connaissez (un mot de passe, un code PIN, etc.), ce que vous possédez (un jeton de sécurité, un téléphone mobile, etc.) et ce que vous êtes (données biométriques, telles qu'une empreinte digitale ou un scan du visage). Lorsque l'authentification multifacteur est activée, même si un attaquant parvient à obtenir votre mot de passe, il ne pourra pas se connecter à votre compte sans fournir également les preuves supplémentaires requises par l'authentification multifacteur. Vous évitez ainsi plus facilement les accès non autorisés, le vol d'informations et les activités malveillantes. L'authentification multifacteur répond également en partie aux exigences de conformité et au respect des normes du secteur, telles que celle de l'Institut national de normalisation et de technologie (NIST).

Qui devrait utiliser l'authentification multifacteur ?

Oracle recommande d'activer l'authentification multifacteur pour tous les utilisateurs. Au minimum, vous devriez activer l'authentification multifacteur pour les utilisateurs disposant de privilèges administrateurs, permettant par exemple de créer et de gérer des ressources OCI. Vous devez également exiger l'authentification multifacteur pour accéder à toutes les applications hébergeant des informations sensibles ou permettant des actions à haut risque.

Quelle est l'expérience de l'utilisateur final lorsque les administrateurs activent l'authentification multifacteur ?

Lorsque l'authentification multifacteur est activée pour la première fois par un administrateur, les utilisateurs sont invités à paramétrer l'authentification multifacteur à la prochaine authentification. Après, les utilisateurs doivent valider l'authentification multifacteur lors du processus de connexion à chaque visite ultérieure. Si l'administrateur active une option de périphériques sécurisés, les utilisateurs ont la possibilité de marquer un appareil comme sécurisé, ce qui leur évite de devoir réaliser une authentification multifacteur à chaque fois sur cet appareil.

Pour plus d'informations, les utilisateurs peuvent se référer aux instructions suivantes :

L'authentification multifacteur est-elle obligatoire dans toutes les circonstances ?

Non, la MFA n'est pas strictement obligatoire en toutes circonstances. Si vous accordez l'accès à un site Web public, par exemple, vous n'avez généralement besoin d'aucune authentification. Si vous souhaitez que les utilisateurs se connectent lors d'un achat afin d'indiquer le compte à débiter et le lieu de livraison, un nom d'utilisateur et un mot de passe suffisent probablement. Toutefois, si le même utilisateur souhaite modifier le mode de paiement ou l'adresse de livraison, ou si l'application autorise des actions susceptibles d'avoir des conséquences pour votre entreprise, l'authentification multifacteur est recommandée.

Oracle vous recommande vivement d'activer l'authentification multifacteur pour tous les administrateurs cloud et d'application. En fin de compte, l'activation de l'authentification multifacteur dépend des politiques de sécurité internes de votre entreprise et de l'évaluation des risques. Toutefois, il est recommandé de commencer avec une politique qui prévoit que l'authentification multifacteur est toujours obligatoire et nécessite l'approbation d'un cadre pour les applications pour lesquelles vous souhaitez rendre l'authentification multifacteur facultative.

Quels facteurs d'authentification sont à ma disposition ? Y a-t-il un coût ?

Pour bien comprendre les différents facteurs d'authentification et les coûts, il est important de comprendre le type de location OCI dont vous disposez. Pour déterminer si votre location dispose d'OCI Identity and Access Management (IAM) avec des domaines d'identité ou si elle dispose d'OCI IAM sans domaines d'identité, consultez cette documentation.

  • Si votre location dispose d'OCI IAM avec des domaines d'identité, tous les types de domaine d'identité prennent en charge l'authentification multifacteur sans frais supplémentaires. Les domaines d'identité Free ne peuvent pas utiliser l'envoi de SMS comme facteur d'authentification, mais d'autres facteurs sont disponibles. Pour plus de détails, consultez la documentation de l'authentification multifacteur OCI IAM avec domaines d'identité.
  • Si votre location dispose d'OCI IAM sans domaine d'identité, vous disposez de deux options pour l'authentification multifacteur :
    • Activez l'authentification multifacteur pour une connexion utilisateur directe via le service OCI IAM. Cette option offre un ensemble limité de facteurs d'authentification sans frais supplémentaires. Pour plus de détails, consultez la documentation de l'authentification multifacteur OCI IAM sans domaines d'identité.
    • Utilisez Oracle Identity Cloud Service (IDCS) pour authentifier les utilisateurs dans OCI. Cette option offre davantage de fonctionnalités d'authentification multifacteur et de choix d'authentification.
  • Si vous utilisez IDCS pour l'authentification, il existe deux types de licence :
    • IDCS Foundation (niveau gratuit) prend en charge l'authentification multifacteur uniquement pour l'accès à la console OCI, sans frais, avec un ensemble limité de facteurs d'authentification comme documenté ici. Pour protéger d'autres applications, vous devez effectuer une mise à niveau vers IDCS Standard.
    • IDCS Standard prend en charge une large gamme d'options d'authentification multifacteur pour tout service ou application protégé, sans frais supplémentaires. Pour plus de détails, consultez la documentation sur l'authentification multifacteur d'Identity Cloud Service (IDCS).

Où puis-je apprendre à implémenter l'authentification multifacteur ?

Les instructions spécifiques pour l'implémentation de l'authentification multifacteur varient en fonction du type de location OCI. Pour déterminer si votre location dispose d'OCI IAM avec des domaines d'identité ou si elle dispose d'OCI IAM sans domaines d'identité, consultez cette documentation.

Que se passe-t-il si je n'implémente pas l'authentification multifacteur ?

Si vous n'implémentez pas l'authentification multifacteur, vos comptes risquent de ne pas résister à une cyberattaque. Avec l'authentification multifacteur, votre location et/ou d'autres processus d'authentification continueront de fonctionner normalement.