Gérer les identités et les politiques d'autorisation

Le service Oracle Cloud Infrastructure Identity and Access Management permet de contrôler l'accès à vos ressources en nuage. Les données d'identification pour l'accès et l'autorisation comprennent les clés d'API, le mot de passe de connexion, la connexion fédérée et les jetons d'authentification. Utilisez les données d'identification appropriées pour protéger votre compte et vos ressources en nuage. Oracle vous encourage à adopter les recommandations suivantes lors de la mise en oeuvre de la gestion des identités dans le nuage.

Utiliser l'authentification multifacteur

Architecte d'entreprise, architecte de sécurité, architecte d'application

Restreindre l'accès aux ressources aux utilisateurs qui ont été authentifiés au moyen de la solution d'authentification unique de votre entreprise, d'un mot de passe à usage unique limité dans le temps ou d'un autre facteur approprié, comme une fonction de balayage biométrique.

Avec les domaines d'identité IAM (Gestion des identités et des accès OCI), l'authentification multifacteur est configurée et appliquée dans une politique d'authentification prédéfinie pour la console OCI. Cette politique ne doit pas être désactivée.

Vous devez l'exiger au niveau de l'utilisateur et l'appliquer au niveau des ressources au moyen du service IAM. Vous pouvez appliquer l'authentification multifacteur à une ressource dans la politique d'accès qui autorise l'accès à la ressource.

L'authentification multifacteur peut également être configurée pour des cas d'utilisation d'urgence lorsque vous devez donner à un utilisateur un accès élevé temporaire pour contourner le contrôle d'accès régulier afin d'obtenir un accès immédiat aux systèmes critiques.

Ne pas utiliser le compte d'administrateur de location pour les opérations quotidiennes

Architecte d'entreprise, architecte de sécurité, architecte d'application

Les administrateurs de niveau de service de la location doivent être créés pour limiter davantage l'accès administratif. Les administrateurs au niveau du service doivent seulement gérer les ressources d'un service ou d'un domaine spécifique.

Par exemple, la politique suivante permet aux utilisateurs du groupe VolumeAdmins de gérer uniquement les ressources de la famille de volumes par blocs.

Allow group VolumeAdmins to manage volume-family in tenancy

Créer des politiques de sécurité pour empêcher le verrouillage du compte d'administrateur

Architecte d'entreprise, architecte de la sécurité

Créez et protégez un compte d'administrateur spécifiquement pour une utilisation au cas où l'administrateur de la location quitterait votre organisation, ou pour toute autre situation d'urgence lorsqu'aucun administrateur de location n'est disponible.

Par exemple, créez un persona Utilisateur d'urgence, avec l'appartenance au groupe OCI Administrateurs, non fédéré, et avec le mot de passe local uniquement. Ceci est parfois appelé un compte "Break Glass".

Le Break Glass fait référence aux processus et mécanismes utilisés pour obtenir un accès hautement privilégié en cas d'urgence informatique. Le terme est dérivé de la pratique consistant à placer un déclencheur d'alarme derrière une vitre de protection, qui sert de barrière physique pour empêcher l'activation non autorisée ou non urgente. Dans le domaine de l'informatique, on utilise métaphoriquement l'outil Break Glass pour décrire la nécessité de disposer de privilèges d'accès complets en cas d'urgence critique qui ne peut pas être traitée dans le cadre de la séparation des fonctions (SOD) établie et des contrôles d'accès les moins privilégiés. Les principales caractéristiques d'un processus d'urgence efficace sont la haute disponibilité, l'accès restreint, l'évaluation des risques, l'approbation accélérée, les droits de courte durée, la vérification et les tests réguliers. Même un modèle d'accès bien conçu peut ne pas tenir compte de toutes les urgences possibles. Dans de tels cas, Break Glass fournit un moyen de concentrer le plus haut niveau de privilèges d'accès dans un ou plusieurs comptes Break-glass, transcendant le modèle d'accès établi. Le groupe d'administrateurs OCI peut être utilisé pour accorder un accès d'urgence, ainsi qu'une autre option de droits.

Empêcher les groupes d'administrateurs IAM de gérer les administrateurs et les groupes d'administrateurs de données d'identification par défaut

Architecte d'entreprise, architecte de la sécurité

Les autorisations d'administrateur doivent respecter la règle du privilège minimal, de sorte que l'appartenance à un groupe d'administrateurs ou à un fichier joint à une stratégie d'administration doit être limitée au besoin.

La politique suivante permet aux utilisateurs du groupe UserAdmins d'inspecter uniquement les groupes de la location.

Allow group UserAdmins to inspect groups in tenancy

La politique d'administration de location prête à l'emploi ne doit pas non plus être modifiée.

Empêcher la suppression accidentelle ou malveillante des politiques d'accès (et les modifications apportées)

Architecte d'entreprise, architecte de sécurité, architecte d'application

Par exemple, la politique suivante autorise uniquement les utilisateurs du groupe PolicyAdmins à créer des politiques, mais pas à les modifier ou à les supprimer.

Allow group PolicyAdmins to manage policies in tenancy where
      request.permission='POLICY_CREATE'

Limitez les administrateurs de données d'identification à la gestion des capacités d'utilisateur et des données d'identification d'utilisateur, telles que les clés d'API, les jetons d'authentification et les clés secrètes.

Utiliser plusieurs domaines d'identité

Architecte d'entreprise, architecte de la sécurité

Utilisez le domaine d'identité par défaut du service de gestion des identités et des accès pour OCI uniquement pour les administrateurs OCI.

Pour les charges de travail d'application, utilisez des domaines d'identité distincts pour chaque environnement, par exemple pour le développement, les tests et la production.
Chaque domaine peut présenter des exigences différentes en matière d'identité et de sécurité pour protéger vos applications et vos services OCI.
L'utilisation de plusieurs domaines d'identité peut vous aider à maintenir l'isolement du contrôle administratif de chaque domaine d'identité. Plusieurs domaines d'identité sont requis, par exemple, lorsque vos normes de sécurité interdisent que les ID utilisateur de développement existent également dans l'environnement de production. Plusieurs domaines sont également utilisés lorsque différents administrateurs doivent contrôler différents environnements.

Fédérer le service Oracle Cloud Infrastructure Identity and Access Management

Architecte d'entreprise, architecte de sécurité, architecte d'application

Lorsque cela est possible et pertinent, fédérez Oracle Cloud Infrastructure Identity and Access Management avec le fournisseur d'identités centralisé de votre organisation (IdP).

Créez un groupe d'administrateurs de fédération mappé au groupe d'administrateurs du fournisseur d'identités fédéré et régi par les mêmes politiques de sécurité que le groupe d'administrateurs du fournisseur d'identités fédéré.
Créez des utilisateurs locaux et affectez-les aux groupes IAM Administrators, IAM Administrators et Credential Administrators par défaut. Utilisez ces utilisateurs pour les scénarios de type d'urgence (par exemple, incapacité à accéder aux ressources par fédération).
Définissez une politique pour empêcher le groupe IAM d'administrateurs fédérés de modifier l'appartenance aux groupes Administrators de la location par défaut.
Détectez les accès et les opérations non autorisés en surveillant les journaux de vérification pour les opérations effectuées par les administrateurs de location et les modifications apportées aux groupes Administrators.

Surveiller et gérer les activités et le statut de tous les utilisateurs

Architecte d'entreprise, architecte de sécurité, architecte d'application

Surveiller et gérer les activités et le statut de tous les utilisateurs.

Lorsqu'un employé quitte l'organisation, désactivez l'accès à la location en supprimant immédiatement l'utilisateur.
Appliquer la rotation du mot de passe d'utilisateur, des clés d'API et de toutes les capacités d'utilisateur liées à l'authentification, tous les 90 jours ou moins.
Assurez-vous que les données d'identification IAM (Identity and Access Management) ne sont pas codées de façon permanente dans la documentation de votre logiciel ou de vos opérations.
Créez un utilisateur IAM pour tous les membres de l'organisation qui ont besoin d'accéder aux ressources de la location. Ne partagez pas un utilisateur IAM entre plusieurs utilisateurs humains.
Mettez en oeuvre l'authentification unique fédérée pour simplifier l'accès à plusieurs applications et centraliser l'authentification.
Vérifiez régulièrement les utilisateurs des groupes IAM et supprimez les utilisateurs qui n'ont plus besoin d'accéder à ces groupes.