Le modèle confiance complète convient à des entreprises ayant une équipe d'administrateurs distincte pour chaque département ou site autonome. Chaque division maintient un domaine séparé qui contient les utilisateurs et les ordinateurs de cette division. Pour qu'un utilisateur d'un domaine puisse accéder aux informations d'autres domaines, le modèle spécifie que
Le modèle confiance complète
l’on crée des relations de confiance bidirectionnelles entre tous les domaines.
Le nombre de relations de confiance est égal à y (y-1), où y est le nombre de domaines du réseau. Le modèle confiance complète est extrêmement évolutif. Chaque domaine peut contenir des milliers d’utilisateurs, mais comme tous les domaines se font réciproquement confiance, un utilisateur n’a besoin que d’un compte pour accéder aux ressources en un point quelconque du réseau. Toutefois, ce modèle peut aboutir à une grande quantité de relations de confiance. Ainsi, pour mettre en oeuvre le modèle d’un réseau à sept domaines, il faudra définir 42 relations de confiance.
Le modèle confiance complète prête le flanc à des standards de sécurité incohérents. Alors que les autres modèles limitent le nombre de domaines qui peuvent contenir des comptes utilisateurs, ici chaque domaine contient des comptes utilisateurs et une équipe informatique différente administre chaque domaine. Chaque domaine présent dans le modèle confiance complète a une politique de verrouillage, une politique d’audit, et des exigences de mots de passe distinctes.
Comme expliqué dans l’article « PDCs, BDCs, and Trust Relationships », quand votre domaine fait confiance à un autre, vous comptez sur le fait que les administrateurs de l’autre domaine gèreront leurs comptes utilisateurs aussi soigneusement que vous gérez les vôtres. Supposons que vous créiez une relation de confiance avec un autre domaine et que vous accordiez à un utilisateur de ce domaine l’accès aux ressources de votre domaine. Plus tard, l’utilisateur est licencié, mais les administrateurs du domaine trusted négligent de désactiver son compte. Votre domaine est dès lors vulnérable aux actes malveillants de cet utilisateur.
De même, quand vous accordez l’accès à un groupe global à partir d’un autre domaine, vous devez être sûr que les administrateurs de ce domaine tiendront à jour les membres du groupe. Autre problème potentiel avec ce modèle : les mots de passe nécessaires. Si les administrateurs du domaine trusted n’imposent pas des mots de passe puissants, un pirate peut deviner le mot de passe d’un utilisateur de ce domaine, puis utiliser le compte ainsi pénétré pour menacer les ressources de votre domaine. Si les standards de sécurité dans un domaine trusted ne sont pas égaux ou supérieurs à ceux de votre domaine, vous êtes vulnérable.
Vous pourrez alors juger qu’il est plus sûr de créer et de maintenir des comptes utilisateurs secondaires dans votre domaine pour les utilisateurs d’autres domaines qui doivent accéder aux ressources du vôtre. Toutefois, ce choix n’est pas sans risques : si ces utilisateurs se trouvent dans des départements ou des sites distants, il sera peut-être difficile de se tenir au courant des utilisateurs supprimés ou de ceux dont l’état a changé.
Téléchargez cette ressource
Microsoft 365 Tenant Resilience
Face aux failles de résilience des tenants M365 (configurations, privilèges, sauvegarde). Découvrez 5 piliers pour durcir, segmenter et surveiller vos environnements afin de limiter l’impact des attaques. Prioriser vos chantiers cyber et améliorer la résilience de vos tenants Microsoft 365.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- ADI, l’infrastructure de données de Scality pensée pour l’ère de l’IA et de la souveraineté
- Les coûts cachés des merge requests générées par l’IA
- WatchGuard lance Rai, une IA agentique taillée pour les MSP
- Mythos révèle les limites d’un Zero Trust centré sur le réseau
Articles les + lus
Analyse Patch Tuesday Mai 2026
Les coûts cachés des merge requests générées par l’IA
Femmes et métiers de la tech : une attractivité réelle freinée par des stéréotypes persistants
Moderniser le développement logiciel : de la fragmentation à l’intégration
Analyse Patch Tuesday Avril 2026
À la une de la chaîne Tech
- Analyse Patch Tuesday Mai 2026
- Les coûts cachés des merge requests générées par l’IA
- Femmes et métiers de la tech : une attractivité réelle freinée par des stéréotypes persistants
- Moderniser le développement logiciel : de la fragmentation à l’intégration
- Analyse Patch Tuesday Avril 2026
