Gestion des identités et des stratégies d'autorisation

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

Utiliser l'authentification à plusieurs facteurs

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

Limitez l'accès aux ressources aux seuls utilisateurs authentifiés via la solution d'accès avec connexion unique de votre entreprise, ainsi qu'à un mot de passe à usage unique limité dans le temps ou à un autre facteur approprié, tel qu'une fonction de balayage biométrique.

Avec les domaines d'identité OCI Identity and Access Management (IAM), l'authentification à plusieurs facteurs est configurée et appliquée dans une stratégie de connexion prédéfinie pour la console OCI. Cette stratégie ne doit pas être désactivée.

Vous devez en avoir besoin au niveau de l'utilisateur et l'appliquer au niveau des ressources via IAM. Vous pouvez appliquer l'authentification à plusieurs facteurs pour une ressource dans la stratégie d'accès qui autorise l'accès à la ressource.

L'authentification à plusieurs facteurs peut également être configurée pour les cas d'utilisation avec accès d'urgence lorsque vous devez accorder à 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 administrateur. Les administrateurs de niveau service doivent uniquement gérer les ressources d'un service ou d'un domaine spécifique.

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

Allow group VolumeAdmins to manage volume-family in tenancy

Créer des stratégies de sécurité pour empêcher le verrouillage du compte administrateur

Architecte d'entreprise, architecte de sécurité

Créez et protégez un compte d'administrateur spécifiquement destiné à être utilisé si l'administrateur de location quitte votre organisation ou en cas d'urgence lorsqu'aucun administrateur de location n'est disponible.

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

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 un vitrage protecteur, qui sert de barrière physique pour empêcher une activation non autorisée ou non urgente. Dans le domaine informatique, le verre de rupture est utilisé métaphoriquement 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 tâches (SOD) et des contrôles d'accès les moins privilégiés. Les principales caractéristiques d'un processus d'accès rapide efficace sont la haute disponibilité, l'accès restreint, l'évaluation des risques, l'approbation accélérée, les droits à court terme, l'audit 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, le break glass permet de concentrer le plus haut niveau de privilèges d'accès sur un ou plusieurs comptes break-glass, au-delà du modèle d'accès établi. Le groupe d'administrateurs OCI peut être utilisé pour accorder un accès avec accès d'urgence, ainsi qu'une autre option d'habilitation.

Limitation des groupes d'administrateurs IAM à la gestion des administrateurs par défaut et des groupes d'administrateurs d'informations d'identification

Architecte d'entreprise, architecte de sécurité

Les droits d'accès administrateur doivent respecter la règle du moindre privilège. Par conséquent, l'appartenance à un groupe d'administrateurs ou l'association à une stratégie d'administration doivent être limitées en fonction des besoins.

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

Allow group UserAdmins to inspect groups in tenancy

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

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

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

Par exemple, la stratégie suivante permet uniquement aux utilisateurs du groupe PolicyAdmins de créer des stratégies, mais pas de les modifier ou de les supprimer.

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

Limitez les administrateurs d'informations d'identification à la gestion des fonctionnalités utilisateur et des informations d'identification 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 sécurité

Utilisez le domaine d'identité OCI Identity and Access Management par défaut pour les administrateurs OCI uniquement.

Pour les charges globales d'application, utilisez des domaines d'identité distincts pour chaque environnement, tels que le développement, les tests et 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.
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.

Fédération d'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 qui correspond au groupe d'administrateurs du fournisseur d'identités fédéré et qui est régi par les mêmes stratégies 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 accès d'urgence (par exemple, l'impossibilité d'accéder aux ressources via la fédération).
Définissez une stratégie pour empêcher le groupe IAM d'administrateurs fédérés de modifier l'appartenance des groupes Administrators de location par défaut.
Détectez les accès non autorisés et les opérations en surveillant les journaux d'audit 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 l'utilisateur immédiatement.
Appliquer la rotation du mot de passe utilisateur, des clés d'API et de toutes les fonctionnalités utilisateur liées à l'authentification, tous les 90 jours ou moins.
Assurez-vous que les informations d'identification Identity and Access Management (IAM) ne sont pas codées en dur dans la documentation de votre logiciel ou de vos opérations.
Créez un utilisateur IAM pour toutes les personnes de l'organisation ayant besoin d'accéder aux ressources de la location. Ne partagez pas un utilisateur IAM entre plusieurs utilisateurs humains.
Implémentez l'accès avec connexion unique fédéré pour rationaliser l'accès à plusieurs applications et centraliser l'authentification.
Examinez régulièrement les utilisateurs dans les groupes IAM et supprimez les utilisateurs qui n'ont plus besoin d'accès.