Contrôle d’accès de l’ingénieur de service Microsoft 365

  • Article

L’accès permanent zéro (ZSA) signifie que le personnel de l’équipe de service Microsoft n’a aucun accès privilégié permanent à l’environnement de production Microsoft 365 ou aux données client. Lorsqu’un membre de l’équipe de service Microsoft souhaite mettre à jour le service ou accéder aux données client pour une raison quelconque, il doit envoyer une demande justifiant le besoin et recevoir l’approbation d’un responsable autorisé. À grande échelle, il n’est pas possible de fournir et de supprimer manuellement l’accès nécessaire pour gérer les services Microsoft 365. Microsoft a donc développé une solution automatisée pour gérer l’accès privilégié en fonction des besoins.

Lockbox

Tout accès aux systèmes Microsoft 365 et aux données client est réparti par Lockbox, un système de contrôle d’accès qui utilise un modèle juste-à-temps (JIT) et juste-assez-accès (JEA) pour fournir aux ingénieurs du service un accès privilégié temporaire aux services et données Microsoft 365 spécifiés. En outre, toutes les requêtes et actions sont journalisées à des fins d’audit et sont accessibles à l’aide de l’API d’activité de gestion Office 365 et du Centre de sécurité et de conformité.

Avant qu’un ingénieur de service Microsoft puisse se connecter à n’importe quel système Microsoft 365 ou accéder aux données client, il doit envoyer une demande d’accès via Lockbox. Cette demande ne peut être approuvée que si certains critères sont remplis :

  • L’ingénieur de service répond aux conditions d’éligibilité d’un compte d’équipe de service,
  • Ils appartiennent au rôle Lockbox associé au travail dans la demande,
  • Le temps d’accès demandé ne dépasse pas la durée maximale autorisée,
  • Ils ont une justification professionnelle légitime,
  • La ressource demandée à laquelle ils souhaitent accéder se trouve dans leur étendue de travail, et
  • Ils reçoivent l’approbation du responsable

Une fois que tous les critères ont été remplis et vérifiés par Lockbox, l’accès temporaire est accordé pour effectuer l’action spécifique demandée. Une fois le temps écoulé pour la demande, l’accès est révoqué.

Flux lockbox.

En outre, si un client accorde des licences et active la fonctionnalité Customer Lockbox , toute tentative d’accès aux données client effectuée par un ingénieur de service Microsoft doit être approuvée par un administrateur dans le locataire du client. Le besoin d’accéder aux données client peut provenir à la fois du client et de Microsoft. Par exemple, un incident déclenché par un client peut nécessiter l’accès à ses données pour résoudre le problème ou lorsque Microsoft a besoin d’un accès aux données pour appliquer une mise à jour spécifique.

Les clients ne disposent d’aucun outil pour lancer une demande Customer Lockbox ; ils doivent envoyer un ticket à Microsoft qui nécessite l’envoi d’une demande Customer Lockbox. Une demande Customer Lockbox déclenchée par un ingénieur de service Microsoft doit être approuvée par un responsable Microsoft et un administrateur autorisé dans le locataire du client.

Flux customer lockbox.

Rôles Lockbox

Pour appliquer la séparation des tâches et le principe du privilège minimum, les ingénieurs de service doivent appartenir à un rôle Lockbox qui correspond à leur rôle dans l’équipe. Les rôles Lockbox sont gérés dans l’outil Gestion des identités et définissent les privilèges et les actions pour lesquelles un membre de l’équipe de service peut être approuvé via le processus de demande Lockbox. Le personnel de l’équipe de service doit demander à être membre d’un rôle Lockbox et recevoir l’approbation de la direction. S’il est approuvé, le compte d’équipe de service de l’employé est placé dans un groupe de sécurité appliqué par Active Directory (AD) et Microsoft Entra ID.

Interfaces de gestion contraintes

Les ingénieurs de service utilisent deux interfaces de gestion pour effectuer des tâches administratives : Bureau à distance à partir d’une station de travail Administration sécurisée (SAW) via une passerelle de service terminal (TSG) sécurisée et PowerShell à distance. Au sein de ces interfaces de gestion, les contrôles d’accès basés sur la demande Lockbox et les stratégies logicielles approuvées imposent des restrictions significatives sur les applications exécutées et sur les commandes et applets de commande disponibles.

Bureau à distance

Les membres de l’équipe de service qui gèrent leur service à l’aide du Bureau à distance doivent se connecter à partir d’un saw, des ordinateurs portables spécialement conçus et fabriqués gérés par Microsoft spécifiquement pour ce cas d’usage. Microsoft s’associe à des fournisseurs pour créer des SAP, créant ainsi une chaîne d’approvisionnement courte et sécurisée. Les SAP utilisent des systèmes d’exploitation renforcés qui sont configurés pour limiter toutes les fonctionnalités, à l’exception de ce qui est nécessaire pour les tâches de gestion définies. Ces limitations incluent la désactivation de tous les ports USB, des listes d’accès aux applications strictes, la suppression de l’accès aux e-mails, la limitation de la navigation Internet et l’application de verrouillages d’écran d’inactivité. Les systèmes de contrôle d’accès Microsoft examinent régulièrement les machines SAW pour s’assurer qu’elles sont conformes aux contrôles de sécurité les plus récents et désactivent automatiquement les machines si elles sont jugées non conformes.

Les ingénieurs de service ne sont autorisés à se connecter qu’à un seul TSG à la fois et plusieurs sessions ne sont pas autorisées. Toutefois, les TSG permettent aux administrateurs de l’équipe de service Microsoft 365 de se connecter à plusieurs serveurs, chacun avec une seule session simultanée, afin que les administrateurs puissent effectuer efficacement leurs tâches. Les administrateurs de l’équipe de service ne disposent d’aucune autorisation sur les TSG eux-mêmes. Le TSG est utilisé uniquement pour appliquer les exigences d’authentification multifacteur (MFA) et de chiffrement. Une fois que l’administrateur de l’équipe de service se connecte à un serveur spécifique via un TSG, le serveur spécifique applique une limite de session d’un par administrateur.

Les restrictions d’utilisation, les connexions et les exigences de configuration pour le personnel Microsoft 365 sont établies par les stratégies de groupe Active Directory. Ces stratégies incluent les caractéristiques TSG suivantes :

  • Utiliser uniquement le chiffrement validé FIPS 140-2
  • Les sessions se déconnectent après 15 minutes d’inactivité
  • Les sessions se déconnectent automatiquement après 24 heures

Les connexions aux TSG nécessitent également l’authentification multifacteur à l’aide d’un carte intelligent physique distinct. Les ingénieurs de service reçoivent différentes cartes à puce pour différentes plateformes et les plateformes de gestion des secrets garantissent un stockage sécurisé des informations d’identification. Les TSG utilisent des stratégies de groupe Active Directory pour contrôler qui peut se connecter aux serveurs distants, le nombre de sessions autorisées et les paramètres de délai d’inactivité.

PowerShell à distance

En plus de l’accès à distance à l’aide de TSG spécialement configurés, le personnel de l’équipe de service disposant du rôle Service Engineer Operations Lockbox peut accéder à certaines fonctionnalités d’administration sur les serveurs de production à l’aide de PowerShell à distance. Pour utiliser cet accès, l’utilisateur doit être autorisé à accéder en lecture seule (débogage) à l’environnement de production Microsoft 365. L’escalade de privilèges est activée de la même façon que pour les TSG à l’aide du processus Lockbox.

Pour l’accès à distance, chaque centre de données a une adresse IP virtuelle à charge équilibrée qui sert de point d’accès unique. Les applets de commande PowerShell distantes disponibles sont basées sur le niveau de privilège identifié dans la revendication d’accès obtenue lors de l’authentification. Ces applets de commande fournissent la seule fonctionnalité d’administration accessible par les utilisateurs qui se connectent à l’aide de cette méthode. PowerShell distant limite l’étendue des commandes disponibles pour l’ingénieur et est basé sur le niveau d’accès accordé via le processus Lockbox. Par exemple, dans Exchange Online, l’applet de commande Get-Mailbox peut être disponible, mais pas l’applet de commande Set-Mailbox.

Ressources