par Randy F.Smith
Les administrateurs qui concentrent leur attention sur les dernières solutions de sécurité oublient trop souvent de considérer l'importance d'un concept de base : l'organisation des domaines.Comme je l'expliquais dans le premier article de cette série, « NT : les fondamentaux de la sécurité », octobre 2001, même les vétérans de la sécurité de Windows NT peuvent approfondir leur connaissance du fonctionnement interne de NT. Le placement des PDC, des BDC et des systèmes non-DC (domain controller) ; l'utilisation de DC a des fins additionnelles (par exemple, l'exécution de Microsoft Exchange Server) ; et les relations de confiance, tout cela affecte la sécurité du réseau au niveau le plus élémentaire. C'est pourquoi il faut se familiariser avec ces facteurs et, tout naturellement, planifier le réseau autour d'eux.
D’autres fondamentaux NT pour l’administrateur soucieux de sécurité
Un domaine NT est le plus souvent constitué d’un PDC, d’un ou plusieurs BDC, de serveurs membres et de stations de travail. La base de données SAM du PDC est le SAM central pour tout le domaine. Ce SAM est le référentiel pour tous les comptes d’utilisateurs et de groupes de domaines et il contient la politique d’audit et de comptes qu’utilisent les PDC et les BDC. Les BDC maintiennent simplement une copie en lecture seule du SAM du PDC. (Pour plus d’informations sur la relation entre le PDC et les BDC, voir l’article de L.J. Locher, « Understanding PDCs and BDCs », janvier 2000).
On a besoin des BDC pour deux raisons. Tout d’abord, ils assurent la tolérance aux pannes. Quand des serveurs membres ou des stations de travail ont besoin de confirmer des noms d’utilisateurs et des mots de passe, ils recherchent un DC disponible, que ce soit le PDC ou un BDC. Par conséquent, si le PDC est défaillant avec un BDC disponible, les opérations DC en lecture seule – plus important, les logons qui utilisent des comptes de domaines – continuent à fonctionner correctement.
Deuxièmement, les BDC aident à maintenir le temps de réponse quand de nombreux utilisateurs se connectent (log on) simultanément. Microsoft recommande un BDC pour 2.000 utilisateurs. On devrait pouvoir augmenter le nombre d’utilisateurs par BDC, selon les habitudes des utilisateurs du réseau, et le matériel DC.
Mais le nombre de BDC en place n’est qu’une partie d’une implémentation de domaine NT réussie. Trois aspects physiques de chaque BDC sont aussi importants que le nombre de BDC présents. Premièrement, il faut sécuriser physiquement chaque BDC. Même après avoir configuré de manière sûre un NT DC, un assaillant disposant d’un accès physique au système peut combiner les utilitaires L0phtCrack, de @stake, Ntpasswd de Petter Nordahl-Hagen et Pwdump2 de Todd Sabin, pour obtenir tous les mots de passe du domaine.
Deuxièmement, il faut distribuer les BDC judicieusement par rapport aux routeurs et aux commutateurs. Pour améliorer les performances de connexion (logon), il faut répartir les BDC dans le domaine, de telle sorte que chaque BDC serve un nombre à peu près égal d’ordinateurs membres.
Troisièmement, il faut voir quels emplacements offrent la meilleure tolérance aux pannes dans un environnement WAN. Supposons, par exemple, qu’un domaine comporte deux sites : un à New York et un à San Francisco. Le domaine a un PDC et un BDC, dont tous deux résident physiquement à New York. Les stations de travail et les serveurs de San Francisco utilisent une liaison WAN pour se connecter au site de New York. Cette configuration assure la tolérance aux pannes en cas de défaillance du PDC – mais que se pas-sera- t-il si la liaison WAN devient indisponible ? Les utilisateurs de San Francisco ne pourront pas accéder à leurs serveurs locaux, même si le LAN de San Francisco fonctionne. C’est pourquoi il faut déployer au moins un BDC sur chaque site physique qui héberge à la fois les serveurs et les stations de travail. Ainsi, si une liaison WAN est interrompue, les utilisateurs peuvent quand même effectuer des tâches utilisant des applications impliquant leurs serveurs locaux.
Quand un site n’héberge que des stations de travail, on n’a pas besoin d’un BDC pour la tolérance aux pannes liées à la connexion (logon). Par défaut, NT stocke les références des 10 dernières connexions interactives réussies dans le registre de chaque système. Par conséquent, les utilisateurs peuvent utiliser leurs comptes de domaines pour se connecter interactivement à leurs stations de travail, même quand un DC n’est pas disponible. En revanche, si l’on déploie un BDC sur des sites avec beaucoup de stations de travail, on peut améliorer les performances WAN. Comme les stations de travail utiliseront un BDC local au lieu d’accéder à un DC par le WAN, on peut souvent réduire la quantité de trafic DC sur le WAN et économiser ainsi une bande passante précieuse. Dans ce scénario, le seul trafic WAN entre le site local et le site qui héberge le PDC devrait être le trafic de réplication de PDC à BDC. (Ce scénario peut ne pas convenir à des sites constitués uniquement de stations de travail, qui font partie d’un domaine bien plus grand à l’échelle de la société, mais qui n’hébergent qu’un petit nombre de stations de travail. Dans de tels cas, le trafic de réplication nécessaire pour épauler un BDC local excéderait probablement le trafic de connexion que le WAN devrait transporter s’il n’existait pas de BDC local.)
Téléchargez cette ressource
Guide de Sécurité IA et IoT
Compte tenu de l'ampleur des changements que l'IA est susceptible d'entraîner, les organisations doivent élaborer une stratégie pour se préparer à adopter et à sécuriser l'IA. Découvrez dans ce Livre blanc Kaspersky quatre stratégies efficaces pour sécuriser l'IA et l'IoT.
