Pourquoi séparer les rôles d’administrateurs des rôles utilisateurs ?

Introduction

En 2022, tout le monde est conscient de la nécessité de sécuriser l’authentification de son/ses comptes avec un mot de passe fort, et l’intérêt d’utiliser une double authentification. Et que ces critères sont devenus un minimum requis. Ce qui est vrai pour les comptes utilisateurs, à privilèges standard, est d’autant plus vrai pour les comptes à privilèges d’administration. Entendons par là, l’ensemble des comptes ayant une autorisation d’administration, tels que les administrateurs du SI, mais aussi les administrateurs d’applis métiers, etc.

Les modèles d’implémentations et règles de base diffusées par l’ANSSI sont les suivants :

  • Principe du moindre privilège : tout compte utilisateur du SI ne doit posséder que le niveau de privilèges strictement nécessaire à sa mission
  • Séparation des comptes : un utilisateur doit disposer d’un compte utilisateur distinct de son compte à privilèges. En clair, un administrateur doit travailler quotidiennement avec un compte utilisateur standard, réservant son compte à privilège pour le travail spécifique d’administration
  • Gestion des comptes d’administration de domaine (ou de plus hauts privilèges) : nécessité de gérer les arrivées et les départs, le processus d’attribution, les audits, etc. ;
  • Un compte à hauts privilèges ne dispose pas d’accès à l’Internet ;
  • Les comptes à privilèges ont une politique spécifique de mot de passe.

Il est d’ailleurs souvent constaté que la non-application de ces modèles et règles au niveau des comptes à hauts privilèges du Système d’information, se retrouve également à plusieurs sous niveaux de l’environnement, rendant de facto le SI globalement peu sécurisée.

C’est pourquoi, la bonne gestion des rôles d’administration doit être considérée comme un élément critique de la sécurité de votre Système d’information


Exemple, sur un environnement Active Directory Local

Comme représenté dans le tableau ci-dessous, l’appartenance à un des groupes par défaut à haut privilège d’un environnement Active Directory, peut entrainer une extension des droits d’administrations jusqu’à tous les postes intégrés aux domaines. Il est donc important d’être très vigilant dans l’affectation de comptes à ces groupes.

Nom du groupe ou du compteDescription
Administrateurs de l’entrepriseCe groupe est automatiquement ajouté aux groupes des Administrateurs dans chaque domaine de la forêt, en veillant à assurer un accès complet à la configuration de tous les contrôleurs du domaine.
Administrateurs du schémaCe groupe possède des droits d’accès administratifs complets au schéma Active Directory.
AdministrateursCe groupe effectue un contrôle intégral sur tous les contrôleurs du domaine et sur le contenu des répertoires dans ce domaine. Il peut modifier l’appartenance des groupes d’administration dans le domaine. Il correspond au groupe d’administration des services le plus puissant.
Admins du domaineCe groupe est automatiquement ajouté au groupe des Administrateurs correspondant, dans chacun des domaines. Il exerce un contrôle absolu sur tous les contrôleurs du domaine et sur le contenu des répertoires dans ce domaine. Il peut également modifier l’appartenance des comptes d’administration à ce domaine. Il est également administrateur local de tous les serveurs et stations membres du domaine

De plus, l’affectation à l’un de ces groupes, d’un compte utilisateur standard (avec accès bureautique, accès internet, accès messagerie, etc.) pourrait donner l’accès à l’ensemble du système d’information en cas de corruption de compte.

L’usurpateur pourrait même se créer son propre compte à haut privilège et continuer en arrière-plan des actions de cyber malveillance.

En effet ce type de compte peut plus facilement être corrompu qu’un compte administrateur, qui serait lui utilisé dans des conditions strictes et en environnement contrôlé et surveillé plus activement.

Celui-ci pourrait être corrompu par exemple, via un document bureautique pouvant contenir des macros qui vont exécuter des commandes sur l’ordinateur, le serveur. De même pour un site internet qui lance une application java, ou encore un mail avec une pièce jointe infectée.

Notez, que ce principe de gestion des droits s’applique à tous type d’environnements (ISeries, Linux, Aix etc.)


Sur un environnement Cloud

Lorsqu’une entreprise migre ou utilise de nouveaux services cloud, il est très fréquent qu’elle mette en place une synchronisation de l’annuaire local vers l’annuaire cloud associé aux nouveaux services. Cette pratique est tout à fait compréhensible, d’un point de vue gestion IT et expérience utilisateur.

Cependant, dans le scénario d’un environnement local n’utilisant pas les recommandations d’implémentation, ou les règles de gestion des comptes, les comptes utilisateurs ayant de droits à hauts privilèges se retrouvent synchronisés dans le cloud, et donc plus accessibles aux hackers pour effectuer des actions de type brut force. L’utilisation d’un mot de passe faible entrainerait la corruption du compte très rapidement, et ainsi, par extension, l’accès avec un compte à haut privilège à tout l’environnement local.

La configuration la plus courante dans ce scénario est l’affectation de ce même compte au groupe Administrateurs Globaux de l’environnement Cloud. Inutile de donner à ce stade plus de précisions sur la surface d’attaque et d’action que possède le hacker.

Vous l’aurez compris, il faut séparer les comptes d’administrations, des comptes utilisateurs standard !

Nous conseillons d’ailleurs de ne jamais synchroniser les comptes admins locaux vers les environnements cloud, dont le but serait d’en faire un compte d’administration permettant de gérer l’environnement local et cloud.

Nous préconisons plutôt la création d’un compte administrateur uniquement cloud (non synchronisé) pour l’administration des services cloud.


Pour conclure

La gestion des comptes d’administration doit respecter certaines règles, qui, une fois appliquées à la base du Système d’information, seront naturellement répliquées sur l’ensemble du SI.

Vous avez un doute sur l’état de sécurisation de votre système d’information ? Nous pouvons effectuer un audit sur tout ou partie de votre SI, et vous accompagner durant tout le processus d’amélioration de votre de score de sécurisation.

N’hésitez pas à nous contacter afin que nous puissions échanger ensemble sur vos besoins et attentes.

Sources :

guide_protection_des_systemes_essentiels.pdf (ssi.gouv.fr) (MAJ 18/12/2020 V1.0)

anssi-guide-admin_securisee_si_v3-0.pdf (MAJ 11/05/2021- V3.0)

0 commentaires