Maintenance d’un environnement plus sécurisé
S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
Loi numéro dix : la technologie n’est pas une panacée. - 10 lois immuables de l’administration de la sécurité
Une fois que vous avez créé un environnement gérable et sécurisé pour vos ressources d’entreprise critiques, vous devez vous concentrer sur sa maintenance sécurisée. Bien que vous ayez reçu des contrôles techniques spécifiques pour renforcer la sécurité de vos installations AD DS, la technologie à elle seule ne protégera pas un environnement dans lequel le service informatique ne travaille pas en partenariat avec l’entreprise pour maintenir une infrastructure sécurisée et utilisable. Les recommandations générales de cette section sont destinées à être utilisées comme des instructions que vous pouvez utiliser pour développer non seulement une sécurité efficace, mais aussi une gestion efficace du cycle de vie.
Dans certains cas, votre organisation informatique peut déjà avoir une relation de travail étroite avec les unités commerciales, ce qui facilite l’implémentation de ces recommandations. Dans les organisations dans lesquelles l’informatique et les unités commerciales ne sont pas étroitement liées, vous devrez peut-être d’abord obtenir le soutien de la direction pour les efforts visant à établir une relation plus étroite entre l’informatique et les unités commerciales. Le Rapport de synthèse est destiné à être utile en tant que document autonome pour l’examen par la direction, et il peut être diffusé aux décideurs de votre organisation.
Création de pratiques de sécurité métier pour Active Directory
Dans le passé, les technologies de l’information au sein de nombreuses organisations étaient perçues comme une structure de support et un centre de coûts. Les services informatiques ont souvent été en grande partie séparés des utilisateurs métier, et les interactions se limitaient à un modèle de demande-réponse dans lequel l’entreprise demandait des ressources et le service informatique y répondait.
À mesure que la technologie a évolué et proliféré, la vision « un ordinateur sur chaque bureau » s’est effectivement réalisée pour une grande partie du monde, et a même été éclipsée par la large gamme de technologies facilement accessibles disponibles aujourd’hui. La technologie de l’information n’est plus une fonction de support, mais une fonction commerciale. Si votre organisation ne peut pas continuer à fonctionner si tous les services informatiques ne sont pas disponibles, l’activité de votre organisation est, au moins en partie, liée aux technologies de l’information.
Pour créer des plans de récupération après compromis efficaces, les services informatiques doivent travailler en étroite collaboration avec les unités commerciales de votre organisation afin d’identifier non seulement les composants les plus critiques du paysage informatique, mais également les fonctions critiques requises par l’entreprise. En identifiant ce qui est important pour votre organisation dans son ensemble, vous pouvez vous concentrer sur la sécurisation des composants qui ont le plus de valeur. Il ne s’agit pas d’une recommandation pour se soustraire à la sécurité des données et des systèmes à faible valeur. Au lieu de cela, à mesure que vous définissez des niveaux de service pour la durée de fonctionnement du système, vous devez envisager de définir des niveaux de contrôle de sécurité et de surveillance en fonction de la criticité de la ressource.
Lorsque vous avez investi dans la création d’un environnement à jour, sécurisé et gérable, vous pouvez vous concentrer sur sa gestion efficace et veiller à disposer de processus de gestion de cycle de vie efficaces qui ne sont pas déterminés uniquement par l’informatique, mais par l’entreprise. Pour ce faire, vous devez non seulement créer un partenariat avec l’entreprise, mais également investir l’entreprise dans la « propriété » des données et des systèmes dans Active Directory.
Lorsque des données et des systèmes sont introduits dans Active Directory sans propriétaires, propriétaires métier et propriétaires informatiques désignés, il n existe aucune chaîne de responsabilité claire pour l’approvisionnement, la gestion, la surveillance, la mise à jour et éventuellement la désaffectation du système. Il en résulte des infrastructures dans lesquelles les systèmes exposent l’organisation à des risques, mais ne peuvent pas être mis hors service, car la propriété n’est pas claire. Pour gérer efficacement le cycle de vie des utilisateurs, des données, des applications et des systèmes gérés par votre installation Active Directory, vous devez suivre les principes décrits dans cette section.
Affecter un propriétaire métier à des données Active Directory
Les données dans Active Directory doivent avoir un propriétaire métier identifié, c’est-à-dire un service ou un utilisateur spécifié qui est le point de contact pour les décisions relatives au cycle de vie de la ressource. Dans certains cas, le propriétaire d’un composant Active Directory est un service informatique ou un utilisateur. Les composants d’infrastructure comme les contrôleurs de domaine, les serveurs DHCP et DNS et Active Directory seront probablement « possédés » par le service informatique. Pour les données ajoutées à AD DS pour soutenir l’entreprise (par exemple, les nouveaux employés, les nouvelles applications et les nouveaux référentiels d’informations), une unité commerciale ou un utilisateur désigné doit être associé aux données.
Que vous utilisiez Active Directory pour enregistrer la propriété des données dans l’annuaire, ou que vous implémentiez une base de données distincte pour le suivi des ressources informatiques, aucun compte d’utilisateur ne doit être créé, aucun serveur ou aucune station de travail ne doit être installé et aucune application ne doit être déployée sans propriétaire désigné et noté. Essayer d’établir la propriété des systèmes une fois qu’ils ont été déployés en production peut être difficile, au mieux, voire impossible dans certains cas. Par conséquent, la propriété doit être établie au moment où les données sont introduites dans Active Directory.
Implémenter la gestion du cycle de vie métier
La gestion du cycle de vie doit être implémentée pour toutes les données dans Active Directory. Par exemple, lorsqu’une nouvelle application est introduite dans un domaine Active Directory, le propriétaire métier de l’application doit, à intervalles réguliers, attester de l’utilisation continue de l’application. Lorsqu’une nouvelle version d’une application est publiée, le propriétaire métier de l’application doit en être informé et décider si et quand la nouvelle version sera implémentée.
Si un propriétaire métier choisit de ne pas approuver le déploiement d’une nouvelle version d’une application, ce propriétaire doit également être informé de la date à laquelle la version actuelle ne sera plus prise en charge et doit être responsable de déterminer si l’application sera désactivée ou remplacée. Laisser des applications héritées et non prises en charge s’exécuter ne doit pas être une option.
Lorsque des comptes d’utilisateur sont créés dans Active Directory, leurs responsables d’enregistrement doivent être avertis lors de la création de l’objet et être tenus d’attester de la validité du compte à intervalles réguliers. En implémentant un cycle de vie piloté par l’entreprise et une attestation régulière de la validité des données, les personnes les mieux équipées pour identifier les anomalies dans les données sont les personnes qui examinent les données.
Par exemple, les attaquants peuvent créer des comptes d’utilisateur qui semblent être des comptes valides, en suivant les conventions d’affectation des noms et le placement des objets de votre organisation. Pour détecter ces créations de comptes, vous pouvez implémenter une tâche quotidienne qui retourne tous les objets utilisateur sans propriétaire métier désigné afin de pouvoir examiner les comptes. Si des attaquants créent des comptes et attribuent un propriétaire métier, en implémentant une tâche qui signale la création d’un nouvel objet au propriétaire désigné, ce dernier peut rapidement déterminer si le compte est légitime.
Vous devez implémenter des approches similaires pour les groupes de sécurité et de distribution. Bien que certains groupes puissent être des groupes fonctionnels créés par le service informatique, en créant chaque groupe avec un propriétaire désigné, vous pouvez récupérer tous les groupes appartenant à un utilisateur désigné et exiger de l’utilisateur qu’il atteste de la validité de ses appartenances. Comme pour la création de compte d’utilisateur, vous pouvez déclencher des modifications de groupe de rapports pour le propriétaire métier désigné. Plus il devient courant pour un propriétaire métier d’attester de la validité ou de l’invalidité des données dans Active Directory, mieux vous êtes équipé pour identifier les anomalies qui peuvent indiquer des échecs de processus ou une compromission réelle.
Classifier toutes les données Active Directory
Outre l’enregistrement d’un propriétaire métier pour toutes les données Active Directory au moment où elles sont ajoutées à l’annuaire, vous devez également exiger des propriétaires métier qu’ils fournissent une classification pour les données. Par exemple, si une application stocke des données critiques pour l’entreprise, le propriétaire métier doit étiqueter l’application comme telle, conformément à l’infrastructure de classification de votre organisation.
Certaines organisations implémentent des stratégies de classification des données qui étiquettent les données en fonction des dommages que l’exposition des données entraînerait en cas de vol ou d’exposition. D’autres organisations implémentent la classification des données qui étiquette les données par criticité, par exigences d’accès et par rétention. Quel que soit le modèle de classification des données utilisé dans votre organisation, vous devez vous assurer que vous êtes en mesure d’appliquer la classification aux données Active Directory, pas seulement aux données « fichier ». Si le compte d’un utilisateur est un compte VIP, il doit être identifié dans votre base de données de classification des ressources (que vous implémentiez cela via l’utilisation d’attributs sur les objets dans AD DS ou que vous déployiez des bases de données de classification de ressources distinctes).
Dans votre modèle de classification des données, vous devez inclure la classification pour les données AD DS, comme suit.
Systèmes
Vous devez non seulement classer les données, mais également leurs populations de serveurs. Pour chaque serveur, vous devez savoir quel système d’exploitation est installé, quels rôles généraux le serveur fournit, quelles applications s’exécutent sur le serveur, le propriétaire informatique de l’enregistrement et le propriétaire métier de l’enregistrement, le cas échéant. Pour toutes les données ou applications s’exécutant sur le serveur, vous devez exiger une classification, et le serveur doit être sécurisé en fonction des exigences des charges de travail qu’il prend en charge et des classifications appliquées au système et aux données. Vous pouvez également regrouper des serveurs par classification de leurs charges de travail, ce qui vous permet d’identifier rapidement les serveurs qui doivent être les plus surveillés et les plus rigoureusement configurés.
Applications
Vous devez classer les applications par fonctionnalité (ce qu’elles font), par base d’utilisateurs (qui utilise les applications) et en fonction du système d’exploitation sur lequel elles s’exécutent. Vous devez conserver des enregistrements qui contiennent des informations de version, l’état des correctifs et toute autre information pertinente. Vous devez également classer les applications selon les types de données qu’elles gèrent, comme décrit précédemment.
Utilisateurs
Que vous les appeliez des utilisateurs « VIP », des comptes critiques ou que vous utilisiez une autre étiquette, les comptes de vos installations Active Directory qui sont les plus susceptibles d’être ciblés par des attaquants doivent être étiquetés et surveillés. Dans la plupart des organisations, il n’est tout simplement pas possible de surveiller toutes les activités de tous les utilisateurs. Toutefois, si vous êtes en mesure d’identifier les comptes critiques dans votre installation Active Directory, vous pouvez surveiller ces comptes pour les modifications décrites plus haut dans ce document.
Vous pouvez également commencer à créer une base de données de « comportements attendus » pour ces comptes lors de l’audit des comptes. Par exemple, si vous constatez qu’un cadre donné utilise sa station de travail sécurisée pour accéder aux données critiques depuis son bureau et son domicile, mais rarement à partir d’autres emplacements, si vous voyez des tentatives d’accès aux données à l’aide de son compte à partir d’un ordinateur non autorisé ou d’un emplacement à l’autre bout de la planète où vous savez que le cadre n’est pas actuellement situé, vous pouvez identifier et examiner plus rapidement ce comportement anormal.
En intégrant des informations métier à votre infrastructure, vous pouvez les utiliser pour vous aider à identifier les faux positifs. Par exemple, si les déplacements des cadres sont enregistrés dans un calendrier accessible au personnel informatique chargé de surveiller l’environnement, vous pouvez mettre en corrélation les tentatives de connexion avec les emplacements connus des cadres.
Supposons que l’administrateur A se trouve normalement à Chicago et qu’il utilise une station de travail sécurisée pour accéder aux données stratégiques de son bureau, et qu’un événement est déclenché par une tentative d’accès aux données ayant échoué à partir d’une station de travail non sécurisée située à Atlanta. Si vous êtes en mesure de vérifier que le cadre est actuellement à Atlanta, vous pouvez résoudre l’événement en contactant le cadre ou son assistant pour déterminer si l’échec d’accès est le résultat de l’oubli du cadre d’utiliser la station de travail sécurisée pour accéder aux données. En construisant un programme qui utilise les approches décrites dans Planification des compromis, vous pouvez commencer à créer une base de données des comportements attendus pour les comptes les plus « importants » de votre installation Active Directory, ce qui peut potentiellement vous aider à détecter et à répondre plus rapidement aux attaques.