Restrictions de locataire v2 : empêcher la fuite de données vers d'autres locataires
Vous protégez votre locataire contre les connexions indésirables. Mais qu'est-ce qui empêche un collaborateur, depuis un poste de l'entreprise, de se connecter à un autre locataire Microsoft 365 et d'y déposer vos documents ? Par défaut, rien. C'est le rôle des restrictions de locataire.
Le scénario d'exfiltration
Les services Microsoft 365 partagent les mêmes noms de domaine pour tous les clients. Un pare-feu qui autorise SharePoint Online ou Outlook autorise donc aussi le locataire de n'importe quelle autre organisation, y compris un locataire créé par un attaquant ou par un employé sur le départ. Il suffit de s'y connecter avec une identité externe pour y copier des fichiers, sans jamais sortir des flux considérés comme légitimes.
Les paramètres d'accès interlocataire sortants ne suffisent pas à couvrir ce cas : ils encadrent ce que vos identités peuvent faire dans d'autres locataires. Ils ne disent rien d'une identité étrangère utilisée sur vos appareils.
De la v1 à la v2
La première version des restrictions de locataire reposait sur un proxy qui injectait, dans le trafic d'authentification, la liste des locataires autorisés. Elle fonctionne encore, mais présente des limites : la liste est gérée sur le proxy et non dans Entra ID, et le contrôle ne porte que sur l'authentification.
La v2 déplace la stratégie dans Entra ID, au sein des paramètres d'accès interlocataire. Le proxy ou l'appareil n'envoie plus qu'une référence à votre locataire et à votre stratégie ; c'est Entra ID qui décide si l'identité externe peut obtenir un jeton, et pour quelles applications.
Construire la stratégie
La stratégie se définit dans les paramètres par défaut, puis se précise par organisation :
- Par défaut : bloquer l'accès de toutes les identités externes à tous les locataires tiers depuis vos appareils et votre réseau ;
- Par organisation : autoriser explicitement les partenaires avec lesquels vos utilisateurs doivent travailler, en limitant si besoin les utilisateurs, groupes et applications concernés ;
- Comptes Microsoft personnels : décider s'ils doivent également être bloqués, ce qui est généralement souhaitable sur des postes gérés.
Avant d'appliquer un blocage par défaut, recensez les usages réels : réunions Teams chez des clients, portails de fournisseurs, locataires de test. Les journaux de connexion permettent d'identifier les identités externes utilisées depuis votre réseau.
Ne pas confondre. Les restrictions de locataire ne concernent pas les invités B2B de votre propre locataire. Elles s'appliquent aux identités d'autres organisations utilisées depuis vos appareils ou votre réseau.
Réseau ou appareil : où appliquer le contrôle
La stratégie n'a d'effet que si le trafic la transporte. Plusieurs modes d'application coexistent, et leurs périmètres diffèrent :
| Mode | Principe | Point d'attention |
|---|---|---|
| Proxy d'entreprise | Le proxy inspecte le TLS et ajoute un en-tête désignant votre stratégie aux requêtes d'authentification. | Ne couvre que le trafic qui passe par le proxy ; contrôle limité au plan d'authentification. |
| Global Secure Access | Le client de Microsoft Entra Internet Access insère la référence à la stratégie, y compris hors du réseau de l'entreprise. | Nécessite le déploiement du client et les licences correspondantes. |
| Appareil Windows | Une stratégie de groupe ou un paramètre de gestion des appareils applique la stratégie localement. | Protection du plan de données limitée à certaines applications et versions de Windows. |
Les versions de Windows prises en charge, les applications couvertes par le plan de données et les licences requises évoluent : vérifiez la documentation Microsoft actuelle avant de concevoir votre déploiement.
Déployer sans casser
- Inventorier les locataires externes réellement utilisés depuis vos postes.
- Créer les autorisations par organisation pour les partenaires légitimes.
- Configurer le blocage par défaut, puis activer l'injection de la stratégie sur un périmètre pilote.
- Suivre les échecs de connexion liés aux restrictions de locataire et ajuster.
- Étendre progressivement, en prévoyant une procédure de demande d'exception.
Ce qu'un audit vérifie
- L'existence d'une stratégie de restrictions de locataire v2 et son comportement par défaut.
- La liste des organisations autorisées et la justification de chacune.
- Le mode d'application réel : proxy, Global Secure Access ou appareil, et la part du parc couverte.
- Le traitement des comptes Microsoft personnels.
- La cohérence avec les paramètres d'accès interlocataire sortants.