Gérer les identités et les politiques d'autorisation
Utiliser l'authentification multifacteur
Architecte d'entreprise, architecte de sécurité, architecte d'application
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
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é
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é
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
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é
- 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
- 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
etCredential 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
- 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.