Gestion des politiques d'authentification

Cette rubrique décrit comment créer, activer, mettre à jour, désactiver et supprimer des politiques d'authentification pour un domaine d'identité.

À propos des politiques et des règles d'authentification

Une politique d'authentification utilise des règles d'authentification pour définir des critères qui déterminent si un utilisateur doit se connecter à un domaine d'identité ou à une application.

Tous les domaines d'identité sont fournis avec une politique d'authentification par défaut. Si votre domaine d'identité a été préconfiguré avec la politique d'authentification Politique de sécurité pour la console OCI, nous vous recommandons d'utiliser cette politique. Vous pouvez ajouter des politiques d'authentification supplémentaires si nécessaire. Prioriser les règles d'authentification pour une politique d'authentification afin de spécifier l'ordre dans lequel les règles doivent être évaluées.

Politique d'authentification par défaut

Tous les domaines d'identité comprennent une politique d'authentification par défaut active qui contient une règle d'authentification par défaut.

Par défaut, cette règle d'authentification par défaut permet à tous les utilisateurs de se connecter au domaine d'identité avec un nom d'utilisateur et un mot de passe. Vous pouvez tirer parti de cette politique en y ajoutant d'autres règles d'authentification. En ajoutant ces règles, vous pouvez empêcher certains de vos utilisateurs de se connecter au domaine d'identité. Vous pouvez également leur permettre de se connecter et les inviter à entrer un facteur supplémentaire pour accéder aux ressources protégées par le domaine d'identité, comme la console Oracle Cloud Infrastructure.

Par exemple, vous pouvez créer deux règles d'authentification pour la politique d'authentification par défaut. La première règle empêche les utilisateurs de se connecter au domaine d'identité s'ils utilisent une adresse IP comprise dans l'intervalle d'un périmètre de réseau que vous avez défini nommé Périmètres de réseau refusés. La deuxième règle exige que les utilisateurs qui appartiennent à un groupe particulier (par exemple, le groupe de développeurs UA) soient invités à entrer un deuxième facteur dans le cadre du processus de vérification en 2 étapes nommé : Groupe de développeurs UA. Tous les autres utilisateurs pourront se connecter sans être invités à entrer un deuxième facteur.

Important

Pour la règle d'authentification par défaut, ne définissez jamais le refus de l'accès pour tous vos utilisateurs. Si les utilisateurs ne satisfont pas aux critères d'autres règles que vous définissez qui leur permettent de se connecter au domaine d'identité, ils ne pourront pas accéder aux ressources protégées par le domaine d'identité. Configurez également le domaine d'identité pour évaluer cette règle d'authentification en dernier car, par défaut, elle permet à tous les utilisateurs de se connecter au domaine d'identité.

Politique d'authentification "Politique de sécurité pour la console OCI"

La politique d'authentification Politique de sécurité pour la console OCI est activée par défaut et préconfigurée avec les meilleures pratiques de sécurité Oracle.

  • Les facteurs suivants nécessaires pour cette politique d'authentification sont déjà activés : Code secret pour application mobile, Avis pour application mobile, Code d'omission et Authentificateur FIDO (Fast ID Online).
  • L'application de la console OCI a été ajoutée à la politique.
  • La politique d'authentification est fournie avec deux règles d'authentification actives :

    Règles de la politique de sécurité pour la politique d'authentification de la console OCI

    • AMF pour les administrateurs : La règle est prioritaire. Cette règle préconfigurée exige que tous les utilisateurs du groupe Administrateurs et tous les utilisateurs dotés d'un rôle d'administrateur s'inscrivent à l'authentification multifacteur et doivent fournir un facteur supplémentaire chaque fois qu'ils se connectent.
      Note

      Vous pouvez supprimer cette règle et utiliser l'authentification multifacteur pour tous les utilisateurs pour exiger que tous les utilisateurs (y compris les administrateurs) s'inscrivent à l'authentification multifacteur. Vous pouvez également laisser cette règle en place et tous les utilisateurs (y compris les administrateurs) devront quand même s'inscrire à l'authentification multifacteur lors de l'évaluation de la règle d'authentification multifacteur pour tous les utilisateurs.
    • AMF pour tous les utilisateurs : La règle est la deuxième dans l'ordre de priorité. Cette règle préconfigurée exige que tous les utilisateurs s'inscrivent à l'authentification multifacteur et qu'ils fournissent un facteur supplémentaire chaque fois qu'ils se connectent.
      Note

      Si vous ne voulez pas exiger l'authentification multifacteur pour tous les utilisateurs pour le moment, vous pouvez définir cette règle facultative et les utilisateurs auront la possibilité de s'inscrire à l'authentification multifacteur. Vous pouvez également supprimer cette règle et conserver l'authentification multifacteur pour les administrateurs afin que seuls les administrateurs puissent s'inscrire à l'authentification multifacteur.
Important

Quelle que soit la règle que vous décidez de conserver, excluez au moins un administrateur de la règle. Si vous conservez les deux règles, modifiez-les. Voir Création d'une politique d'authentification pour savoir comment exclure des utilisateurs d'une règle d'authentification.

Pour configurer l'authentification multifacteur à l'aide de la politique d'authentification Politique de sécurité pour la console OCI, voir les meilleures pratiques sous Domaines d'identité avec la politique d'authentification "Politique de sécurité pour la console OCI".

Politiques d'authentification supplémentaires

Vous pouvez créer des politiques d'authentification et les associer à des applications spécifiques. Lorsqu'un utilisateur se sert de l'une de ces applications pour tenter de se connecter au domaine d'identité, celui-ci vérifie si des politiques d'authentification sont associées à l'application. Le cas échéant, le domaine d'identité évalue les critères des règles d'authentification affectées à la politique. S'il n'existe aucune politique d'authentification pour l'application, la politique d'authentification par défaut est évaluée.

Priorité des règles d'authentification pour une politique

Comme vous pouvez définir plusieurs règles d'authentification pour une politique d'authentification, le domaine d'identité doit connaître l'ordre dans lequel les règles doivent être évaluées. Pour ce faire, vous pouvez définir la priorité des règles.

À l'aide des règles d'authentification de l'exemple Politique d'authentification par défaut ci-dessus, vous pouvez faire évaluer la règle d'authentification Périmètres de réseau refusés en premier et la règle d'authentification Groupe de développeurs UA en deuxième. Si un utilisateur satisfait aux critères de la règle d'authentification Périmètres de réseau refusés (c'est-à-dire que l'adresse IP utilisée pour tenter de se connecter au domaine d'identité est comprise dans l'intervalle d'adresses IP que vous avez défini dans le périmètre de réseau), il ne peut pas accéder aux ressources protégées par le domaine d'identité. Si l'utilisateur ne correspond pas aux critères de cette règle, la règle ayant la prochaine priorité la plus élevée est évaluée. Pour cet exemple, il s'agit de la règle UA Developers Group. Si l'utilisateur est membre du groupe de développeurs UA, il sera invité à entrer un facteur supplémentaire pour se connecter au domaine d'identité. Si l'utilisateur n'est pas membre du groupe de développeurs UA, la règle ayant la prochaine priorité la plus élevée est évaluée. Dans cet exemple, il s'agit de la règle d'authentification par défaut. Etant donné que cette règle permet par défaut à tous les utilisateurs de se connecter au domaine d'identité, l'utilisateur peut se connecter sans être invité à entrer un deuxième facteur.

Politique ou rôle requis

Politique ou rôle requis.

Pour gérer les politiques d'authentification, vous devez disposer de l'un des droits d'accès suivants :
  • Être membre du groupe d'administrateurs
  • Disposer du rôle administrateur de domaine d'identité, administrateur de la sécurité ou administrateur d'application
  • Être membre d'un groupe disposant du droit manage identity-domains

Pour en savoir plus sur les politiques et les rôles, voir Groupe Administrateurs, politique et rôles d'administrateur, Présentation des rôles d'administrateur et Présentation des politiques.