Pages

dimanche 2 février 2020

Présentation des comptes brises-glace AZURE AD/OFFICE 365)

Azure AD/Office 365

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.
 
Comment créer ce type de compte

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.
 
Quelle sécurité apporter à ce compte Brise-Glace


-        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
 
En effet, tant que cette stratégie n’est pas créée et vérifiée, il ne faut surtout pas donner les droits d’administration globale aux comptes brise-glace. 
 
Celle-ci peut être créée dans le portail « Cloud Apps »:

https://portal.cloudappsecurity.com/oauth2/login
 
-        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
      -        Définir la stratégie et les paramètres

-        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.

 Attention, les groupes que l’on veut utiliser doivent être ajoutés (et synchronisés) dans l’outil avant de pouvoir être utilisés. Cela peut prendre jusqu’à 2 heures avant que le groupe puis les membres ne soient visibles.

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.

 

Aucun commentaire:

Enregistrer un commentaire