Présentation des
comptes brises-glace.
Qu’est-ce
qu’un compte brise-glace
Ces comptes très
privilégiés ne doivent être utilisés que lorsque les comptes d'administration
normaux ne peuvent pas se connecter.
Microsoft recommande au
moins deux comptes brise-glace pour un tenant Azure
AD.
Les comptes brise-glace
doivent être gardés secrets et aucun administrateur ne devrait connaître le mot
de passe entier sans « casser la glace ». Pour obtenir cela, le mot de passe
est divisé en au moins 2 parties.
Voici quelques règles à suivre pour la création de ces comptes :
-
Les comptes
peuvent être créés dans AzureAD, Office 365 ou Powershell.
-
Un exemple de
script a été préparé pour gérer cette création.
-
Le mot de
passe doit aussi être complexe, de préférence divisé en deux parties, stocké (dans
des enveloppes) à deux endroits différents sécurisés dans des coffres-forts
ignifuges (ou virtuels).
-
Seule une
liste d'administrateurs doit être autorisée à utiliser ces comptes. Ces
administrateurs devraient, bien sûr, également avoir le rôle d’administration globale
dans des circonstances normales.
-
Il est très
important d’avoir activé des règles de surveillance d’utilisation de ces
comptes à partir des journaux de connexion Azure AD, des journaux d'audit et
d'agir sur toute activité imprévue. Ces règles devraient être testées AVANT
d’avoir donné les droits maxima.
Quelle configuration pour un
compte Brise-Glace
-
Le rôle
d'administrateur global doit être attribué de façon permanente.
-
Le mot de
passe ne doit pas expirer.
-
MFA ne doit
pas être activé sur ce compte.
-
Le compte
doit être exclu de TOUTES les politiques d'accès conditionnel.
-
Il ne doit
pas être assigné à une personne en particulier.
-
Ce compte ne
doit servir que pour le cloud.
-
Il faut utiliser
le domaine du tenant par défaut « onmicrosoft.com » (pour éviter tous
les problèmes de domaine et de fédération).
-
Il ne doit donc
pas être fédéré ni synchronisé avec l’AD on-premises.
-
Ce compte ne
doit pas être associé à des téléphones mobiles ou des jetons matériels fournis
par les employés.
Un exemple de script a été créé avec ces paramètres :
- 64 chars aléatoires pour le nom
-
Mot de posse
composé de 2 chaines complexes aléatoires de 64 chars enregistrés dans 2
fichiers
Bien sûr, il est possible et assez facile de modifier dans le script les différentes limites (taille du compte, du mot de passe).
-
Le composant
MSOL est requis pour ce script qui est publié et téléchargeable à partir de mon Sharepoint publié sur Internet:
Fichier TXT du script!
Créer
la stratégie d’alerte
-
Choisir “Investigate”
et “Activity log” dans le menu.
-
Choisir le
dernier événement de type “Log on” dans l’activité
-
Cliquer sur
les “3 points” et
-
Sélectionner
“View activity of the same type”
-
Cliquer sur le bouton “New
policy from search”
-
Ajouter la condition
“member of group” et spécifier le groupe qui contient tous les comptes de type
« brise-glace ».
On peut aussi créer une stratégie pour chaque compte de type de type
brise-glace (Voir exemple en Annexe 2). Mais, cela oblige à tester la stratégie
et l’alerte sur chaque compte en « brisant » la glace. Il est donc
conseillé de tester la stratégie basée sur le groupe, en ajoutant
temporairement un utilisateur standard, ce qui évite d’avoir à regrouper les 2
parties du mot de passe.
A noter que le nom du groupe choisi pourrait aussi
être créé de manière aléatoire.
-
Choisir la ou
les alertes souhaitées.
o
Message
(email)
o
SMS (suppose
un crédit téléphonique et une connexion)
o
Playbook flow
Cette stratégie pourra être modifiée dans le menu
“control/policies”.
Toute
connexion à Office 365, par exemple sur le portail (portal.office.com) va
générer une alerte à la moindre tentative d’utilisation :
Si
cela est configuré, le message d’alerte arrive environ 5 minutes après
l’événement :
L’ajout du rôle d’administration globale sur les comptes Brise-Glace :
Les permissions globales ne devraient être
ajoutées qu’après avoir testé que les alertes sont fonctionnelles mais aussi qu’il
y a effectivement au moins une personne prête à réagir.
Un exemple de script d’ajout est fourni en annexe 3
de cet article.
Si PIM (Privileged Identity Management) a été
activé, il y aura une alerte comme celle présentée par l’Annexe 3.
2)
Exemple
de stratégie basée sur un seul utilisateur
3)
Exemple
de script pour affecter le role “Global admin”
Ce script nécessite les
snap-ins « Msol » et AzureAD ».
$RoleName="Company
Administrator"
#$roleTemplate =
Get-AzureADDirectoryRoleTemplate | Where {$_.displayName -eq $roleName}
#Enable-AzureADDirectoryRole
-RoleTemplateId $roleTemplate.ObjectId
$role = Get-AzureADDirectoryRole | Where
{$_.displayName -eq $roleName}
$user=get-MsolUser -userprincipalname FuturCompteBriseGlace@NomDuTenant.OnMicrosoft.com
Add-AzureADDirectoryRoleMember -ObjectId
$role.ObjectId -RefObjectId $User.ObjectID
Si PIM (Privileged Identity
Management) a été activé préalablement, une alerte sera envoyée aux
administrateurs désignés dans PIM.
