Numéro spécial : Windows Server 2008

Audit et conformité dans Windows Server 2008

Rob Campbell et Joel Yoker

Vue d'ensemble:

• Accroître l'importance de la conformité
• Comprendre les modifications de votre environnement
• Défis de l'audit des événements de sécurité
• Aspects techniques de l'audit

Dans le monde de l'informatique, les modifications sont constantes. Comme la plupart des entreprises, vous êtes constamment poussé à comprendre les modifications qui surviennent dans votre environnement. La complexité et l'étendue des environnements informatiques augmentent et il en va de même pour les

erreurs d'administration et les divulgations de données accidentelles. La société actuelle exige de déterminer les responsabilités dans de telles circonstances et les entreprises sont maintenant considérées légalement responsables de la protection des informations qui leur sont confiées.

Par conséquent, l'audit des modifications dans votre environnement a pris de l'importance. Pourquoi ? L'audit fournit les moyens de comprendre et de gérer les modifications dans les grands environnements informatiques hautement distribués d'aujourd'hui. Dans cet article, nous couvrirons les problèmes courants que rencontrent la plupart des organisations, la conformité et la réglementation, certains des principes fondamentaux de l'audit dans un environnement Windows® et la manière dont les composants de Windows Server® 2008 et Microsoft® System Center Operations Manager 2007 Audit Collection Services (ACS) peuvent compléter une stratégie d'audit.

Défis de l'audit

Un coup d'œil rapide aux gros titres des actualités montre que la divulgation des données devient un problème de tous les jours. Beaucoup de ces incidents impliquent des actions légales, des pertes financières et des problèmes de relations publiques pour les entreprises responsables. La capacité d'expliquer les modifications survenues ou d'identifier les problèmes rapidement est essentielle à la réduction de l'impact des incidents de divulgation de données.

Imaginons par exemple que votre entreprise soit responsable de la gestion des informations d’identification personnelles des membres d'une clientèle donnée. Bien qu'il existe plusieurs manières de protéger les informations contenues sur les systèmes que vous gérez, une compromission peut toujours se produire. Un audit approprié pourrait permettre à l'entreprise de déterminer avec précision les systèmes qui ont été compromis et peut-être les données qui ont été perdues. Sans audit, les conséquences de la perte de données pourraient être beaucoup plus graves, principalement parce qu'il n'y aurait aucune manière d'estimer l'étendue de la compromission.

Pourquoi les sociétés informatiques n'effectuent-elles pas déjà ceci ? Il faut savoir que la plupart des entreprises ne comprennent pas totalement les aspects techniques de l'audit. Bien que la direction comprenne généralement les concepts tels que la sauvegarde et la restauration, la complexité inhérente à l'audit des modifications dans l'environnement est un message difficile à faire passer. Par conséquent, les questions concernant les audits ne sont souvent posées qu'après la survenue d'un incident majeur. Par exemple, un audit de base peut être mis en place mais, si le système n'est pas configuré pour l'audit d'une modification particulière, en l'absence de planification, ces informations ne seront pas recueillies.

De plus, les événements de sécurité audités ont certains problèmes inhérents dont doivent se charger les informaticiens. L'une de ces difficultés est la distribution de systèmes dans les grands environnements informatiques d'aujourd'hui, qui présente des défis de collection et d'agrégation significatifs puisque les modifications peuvent survenir sur tout système ou ensemble de systèmes, et ce, à tout moment. Ceci nous mène à un autre défi : la corrélation. La traduction des relations entre les événements sur des systèmes simples ou multiples est souvent nécessaire pour donner un véritable sens à ce qui survient.

Le fait que l'audit traverse généralement les limites traditionnelles de l'entreprise constitue un autre problème. Des différences de structures entre les entreprises et les équipes existent et peuvent ne pas être faciles à réconcilier. De nombreuses entreprises possèdent une équipe de services d'annuaire, une équipe d'infrastructure de messagerie et une équipe de poste de travail, mais il existe probablement une seule équipe de sécurité responsable de tous ces domaines. Qui plus est, les personnes affectées à la sécurité de votre entreprise peuvent ne pas être physiquement présentes à tous ces emplacements. Par exemple, les succursales s'appuient souvent sur une seule personne ou une petite équipe pour toutes les tâches, y compris la gestion du journal des événements de sécurité.

Enfin, la quantité d'événements pose à elle seule un défi. Les événements de sécurité audités surviennent avec un volume beaucoup plus élevé que les autres types d'enregistrements d'événements. Le nombre d'événements recueillis rend difficiles la rétention et la consultation des enregistrements. De plus, en stipulant des exigences de rétention pour ces informations, les réglementations actuelles et proposées ne contribuent pas à réduire ce fardeau dans les infrastructures informatiques d'aujourd'hui.

Par le passé, l'audit de l'accès aux informations pouvait se résumer à la volonté de savoir et à la tentative d'assurer la sécurité. Maintenant, alors que les entreprises et leurs responsables sont tenus légalement responsables de la perte d'informations ou du manque de protections appropriées, il est essentiel que les administrateurs informatiques se familiarisent avec les règlementations qui peuvent s'appliquer à leurs environnements. Pour les entreprises internationales, les défis sont encore plus complexes puisque chaque pays possède ses propres règlementations concernant les informations et leur protection. Certains exemples de législations concernant la conformité aux réglementations existantes sont répertoriés dans la figure 1, avec les attentes associées placées sur les entreprises.

Figure 1 Réglementations et leur signification pour les professionnels de l'informatique

Compte tenu de toute la pression légale, que doivent faire les professionnels de l'informatique ? Les gestionnaires et les techniciens informatiques doivent établir un historique clair et concis à présenter au sein de l'entreprise comme à l'extérieur. Ceci inclut le développement d'une stratégie d'audit appropriée, nécessitant des mesures et des investissements proactifs. Le concept clé ici est que l'audit ne peut pas constituer une réflexion après-coup dans la conception, comme c'est souvent le cas.

Les défis informatiques tels que celui-ci peuvent généralement être résolus par une combinaison de personnel, de processus et de technologie. Avec l'audit, c'est le processus qui est important. Par conséquent, la première étape doit être la maîtrise des principes fondamentaux afin de pouvoir répondre aux besoins et exigences de votre entreprise concernant la conformité aux réglementations. Nous couvrirons certains principes de base de l'audit dans Windows, puis nous nous plongerons dans les modifications de Windows Server 2008 et Windows Vista®.

Audit des événements de sécurité

Tous les événements audités sont enregistrés dans le journal des événements de sécurité de Windows. Ces événements ne mènent habituellement pas à une intervention immédiate et sont de nature informationnelle. Chaque événement enregistre un Succès de l'audit ou Échec de l'audit pour un type spécifique d'accès survenu. Ceci est différent des journaux des événements système ou d'applications, dans lesquels les problèmes peuvent être identifiés grâce à un codage par couleurs (astuce : recherchez les événements rouges pour arriver au problème).

Le journal des événements de sécurité est différent parce que les événements audités sont souvent masqués par leur volume et, comme indiqué précédemment, la corrélation des données de sécurité peut présenter un défi important. Même une simple infraction des données sur un système unique est source de problèmes. Le journal des événements de sécurité doit être analysé pour identifier le compte qui a été utilisé pour accéder aux données, ce qui nécessite qu'un administrateur parcoure le journal pour essayer de trouver le compte. Malheureusement, les attaques sophistiquées d'aujourd'hui sont souvent coordonnées et distribuées, rendant ce type d'analyse très difficile pour la personne qui en est victime.

Ceci dit, il est important de comprendre les éléments essentiels qui permettent aux informations d'être enregistrées dans le journal des événements de sécurité dans Windows : Stratégie d'audit et listes de contrôle d'accès système (SACL). Les stratégies d'audit sont des paramètres configurables pour un ordinateur local au travers de la Stratégie de groupe ou la Stratégie de sécurité locale, qui définissent la collecte d'événements de réussite et d'échec pour des types d'accès spécifiques. Les catégories de stratégie d'audit principales suivantes sont présentes dans Windows depuis plusieurs années (nous en dirons davantage sur la nouvelle Stratégie d'audit granulaire de Windows Server 2008 plus tard) :

• Auditer les événements de connexion aux comptes
• Auditer la gestion des comptes
• Auditer l'accès au service d'annuaire
• Auditer les événements de connexion
• Auditer l'accès aux objets
• Auditer les modifications de stratégie
• Auditer l'utilisation des privilèges
• Auditer le suivi des processus
• Auditer les événements système

La nécessité de définir la stratégie d'audit et ces catégories associées est généralement bien comprise par la plupart des sociétés d'informatique, mais la stratégie d'audit représente seulement une partie de la solution. Les SACL jouent également un rôle significatif dans la mise en œuvre d'une planification d'audit holistique. Deux catégories spécifiques de stratégie d'audit, l'audit des accès au service d'annuaire et l'audit des accès aux objets, dépendent totalement des SACL pour renvoyer les informations dans le journal des événements de sécurité. Mais que sont exactement les SACL ?

Chaque objet, qu'il s'agisse d'un fichier, du Registre ou du service d'annuaire, possède une liste de contrôle d'accès (ACL) avec une ou plusieurs entrées de contrôle d'accès (ACE) divisée en deux types : une liste de contrôle d'accès discrétionnaire (DACL) et une SACL (cette dernière définit des paramètres qui consignent dans des journaux les tentatives d'accès aux objets sécurisés). Chaque ACE d'une SACL spécifie les types de tentatives d'accès par un utilisateur approuvé qui doivent être consignées dans le journal des événements de sécurité. Les ACE définissent la journalisation des tentatives d'accès ayant réussi ou échoué pour des objets spécifiés. La figure 2 illustre l'utilisation d'une SACL sur un objet pour générer des événements pour des types d'accès spécifiques.

Figure 2** Utilisation d'une SACL sur un objet **(Cliquer sur l'image pour l'agrandir)

La compréhension de la relation entre la stratégie d'audit et les SACL est essentielle car la configuration est nécessaire pour capturer les événements audités « corrects » lorsqu'elle a trait aux modifications de l'environnement. Comme mentionné précédemment, les stratégies d'audit d'accès au service d'annuaire et d'audit d'accès aux objets permettent seulement la génération d'audits dans le journal des événements de sécurité pour ces catégories spécifiques, mais les événements sont seulement générés si une ACE est configurée pour un objet dans sa SACL. Une fois ces éléments en place, les événements de sécurité sont produits par l'autorité de sécurité locale de Windows (LSA) et sont écrits dans le journal des événements de sécurité.

Les événements se composent de deux zones distinctes : l'en-tête, qui est statique et prédéfini pour chaque identificateur d'événement (ID d'événement), et le corps, qui est dynamique et contient des détails différents pour chaque événement. La figure 3 illustre ces deux éléments dans un exemple d'événement de sécurité Windows Server. La compréhension de ces composants d'événement est importante pour la phase d'analyse de tout projet d'audit et revêt un intérêt particulier pour la manière dont les informations sont renvoyées aux outils tels que les ACS.

Figure 3** En-tête et corps d'un événement audité **(Cliquer sur l'image pour l'agrandir)

Windows Eventing 6.0

Maintenant que nous comprenons le problème, comment Windows Server 2008 aide-t-il les entreprises à faire face à ces défis ? Windows Server 2008 est la première version de serveur contenant le sous-système d'événements Windows Eventing 6.0, qui améliore grandement l'administration des événements de sécurité. Notez que bien que nous nous concentrions ici sur Windows Server 2008, 95 pourcents du nouvel ensemble de fonctionnalités existent également dans Windows Vista.

L'une des premières choses que de nombreuses personnes remarqueront dans Windows Eventing 6.0 est la nouvelle interface utilisateur. La nouveau composant logiciel enfichable MMC (Microsoft Management Console) Observateur d'événements propose une page détaillée Présentation et synthèse, une page Vues personnalisées flexible et une page Texte d'explication grandement améliorée. Ces interfaces peuvent contribuer à aider l'utilisateur final ou l'administrateur système à trouver les informations d'événements et à configurer les options importantes de journal des événements directement depuis l'Observateur d'événements.

La rétention des données était un problème essentiel influant sur les données de sécurité du journal des événements. Jusqu'ici, le sous-système Journal des événements (y compris tous les journaux) avait une évolutivité limitée. Si ces limites étaient dépassées, le sous-système entier arrêtait la consignation des événements. Ce n'est cependant pas le cas avec Windows Eventing 6.0 et les entreprises sont maintenant uniquement limitées par la quantité d'espace disque disponible. Mais notez que les journaux des événements de taille très importante peuvent être difficiles à analyser puisque chaque entrée de journal doit être évaluée lors du filtrage. Donc il est souhaitable de conserver un journal dont la taille peut être facilement gérée.

Bien entendu, il est de la responsabilité de l'administrateur informatique de développer une planification d'archivage pour les journaux des événements sur de nombreux systèmes. Pour faciliter ceci au niveau du serveur local, l'option « Archiver le journal lorsqu’il est plein, ne pas effacer d’événements » est maintenant disponible dans Windows Eventing 6.0. Dans les versions précédentes de Windows, cette option pouvait uniquement être définie directement par une modification de la valeur de Registre AutoBackupLogFiles. Bien qu'offrant un mécanisme pour l'archivage local des journaux, ceci n'offre pas une solution pour la gestion de ces fichiers et ne répond pas non plus aux problèmes d'agrégation qui se produisent sur les systèmes. Les services ACS fournissent une solution complète pour ceci, ce que nous examinerons dans un instant.

La nouvelle interface n'est que le début. La véritable force de Windows Eventing 6.0 réside dans le nouveau service Journal des événements de Windows et le moteur sous-jacent basé sur XML. Ce sont ces composants qui permettent d'obtenir une évolutivité, une accessibilité et des options d'administration accrues. Les événements sont maintenant enregistrés sous un format XML flexible qui permet aux solutions personnalisées de puiser dans ces informations en mode natif.

Windows Eventing 6.0 offre également la possibilité d'associer des actions administratives à des événements spécifiques. Ceci est effectué en intégrant le service Collecteur d'événements de Windows au Planificateur de tâches afin d'obtenir une gestion des événements basée sur les tâches. C'est un nouveau paradigme pour le Planificateur de tâches, qui était jusqu'ici limité au déclenchement d'événements en fonction de l'horloge. L'Assistant « Joindre une tâche à cet événement » (disponible dans le menu contextuel de tout événement de l'Observateur d'événements de Windows Server 2008) offre un moyen facile de démarrer un programme, envoyer un message électronique ou afficher un message chaque fois qu'un événement spécifique est consigné. Ceci peut être très utile pour tenter d'identifier des actions spécifiques survenant dans votre environnement et pouvant être isolées à un événement de sécurité spécifique. Par exemple, si vous effectuez un audit des modifications de la clé de Registre de mise à jour de schéma autorisée sur vos contrôleurs de domaine, vous pouvez créer une tâche qui envoie un message électronique à des administrateurs de sécurité spécifiques pour les avertir lorsque cette clé de Registre est modifiée.

Outre la nouvelle capacité de collecter et d'enregistrer un grand nombre d'entrées d'événements, vous pouvez maintenant également mieux contrôler les événements enregistrés dans le journal des événements. Ceci est accompli par une nouvelle fonctionnalité appelée Stratégie d'audit granulaire (Granular Audit Policy). Dans les versions précédentes de Windows, les neuf catégories d'audit principales avaient souvent pour résultat une surcharge d'événements. Ces catégories de plus haut niveau peuvent maintenant être contrôlées au travers de 50 sous-catégories granulaires, chacune représentant un sous-ensemble apparenté d'événements.

Ceci vous donne la possibilité de filtrer les informations non critiques du journal des événements sans perdre la visibilité au niveau de la catégorie. Par exemple, si vous souhaitiez uniquement surveiller les modifications du Registre sur un système particulier, et non du système de fichiers, vous auriez auparavant choisi de signaler uniquement les réussites ou les échecs de la catégorie Accès à l'objet. Avec GAP, vous pouvez maintenant éliminer des sous-catégories telles que Système de fichiers, Services de certification et Partage de fichiers, pour uniquement faire état des événements de la sous-catégorie Registre. Pour explorer les sous-catégories GAP sur un système Windows Server 2008, vous devez exécuter la commande Auditpol depuis une invite de commande élevée. Pour obtenir la liste des sous-catégories GAP disponibles, saisissez ceci :

auditpol /list /subcategory:*

Pour obtenir une liste des sous-catégories GAP configurées sur votre système, saisissez ceci :

auditpol /get /category:*

Notez que GAP n'est pas configurable via l'interface utilisateur de Stratégie de groupe standard et doit être géré avec auditpol.exe. L'article de la base de connaissances à l'adresse support.microsoft.com/kb/921469 contient des informations sur le déploiement des paramètres GAP via la Stratégie de groupe pour les systèmes Windows Server 2008 et Windows Vista.

Windows Server 2008 peut également capturer les anciennes et nouvelles valeurs de types spécifiques dans le journal des événements de sécurité. Dans les versions précédentes de Windows, le sous-système consignait uniquement le nom de l'attribut d'objet Active Directory® ou la valeur de Registre qui était modifiée. Il ne consignait pas les valeurs précédentes et actuelles de l'attribut. Cette nouvelle possibilité s'applique aux Services de domaine Active Directory, à Active Directory Lightweight Directory Services et au Registre Windows. En activant Succès de l'audit ou Échec de l'audit dans les sous-catégories « Registre » ou « Modification du service d’annuaire  » et en définissant les SACL associées, les événements détaillés seront déclenchés dans le journal des événements pour des actions sur ces objets. Ceci peut être effectué en utilisant les commandes auditpol suivantes :

auditpol /set /subcategory:"Registry" /success:enable
auditpol /set /subcategory:"Directory Service     
    Changes" /success:enable

Pour les modifications du Registre, ceux-ci apparaissent comme la référence d'événement 4657, comme indiqué sur la figure 4.

Figure 4** Avant et après une modification du Registre **(Cliquer sur l'image pour l'agrandir)

Cette fonctionnalité est particulièrement utile pour effectuer le suivi des modifications des objets Active Directory. Pour les modifications du service d'annuaire, ces modifications s'affichent dans deux ID d'événement 5136, comme indiqué à la figure 5. Chaque événement comporte dans son corps l'objet, l'attribut et l'opération. Pour les modifications des attributs avec des données existantes, deux opérations sont visibles : Valeur supprimée et Valeur ajoutée. Pour les attributs qui n'ont pas été remplis, nous verrions seulement l'opération Valeur ajoutée lorsque des données sont écrites dans ces attributs. Par exemple, lorsqu'une opération de modification réussie est effectuée sur un attribut d'un objet utilisateur, tel que telephoneNumber, Active Directory enregistre la valeur précédente et actuelle de l'attribut dans des entrées de journal des événements détaillées.

Figure 5** Avant et après un événement de modification de service d'annuaire  **(Cliquer sur l'image pour l'agrandir)

Si un nouvel objet est créé, les valeurs des attributs qui étaient renseignées au moment de la création d'objet sont enregistrées. Si un objet est déplacé dans un domaine, l'emplacement précédent et le nouvel emplacement (sous la forme du nom unique) sont enregistrés. Cette fonctionnalité « ancien et nouveau » est activée par défaut lorsque les paramètres de stratégie d'audit appropriés sont en place. S'il existe un attribut que vous voulez garder privé, comme les modifications de numéro d'identification d'employé, vous pouvez exclure explicitement des attributs en effectuant une modification de schéma simple. En modifiant dans le schéma la propriété searchFlags de l'attribut pour lui donner la valeur 0x100 (valeur 256, NEVER_AUDIT_VALUE), comme indiqué à la figure 6, l'événement de modification de service d'annuaire ne sera pas déclenché lorsque des modifications de l'attribut surviennent.

Figure 6** Exclure un attribut des modifications de service d'annuaire **(Cliquer sur l'image pour l'agrandir)

Pour terminer, les abonnements d'événements constituent l'une des excellentes nouvelles fonctionnalités de Windows Eventing 6.0. Comme mentionné précédemment, l'accès au journal d'événements et son examen constituent une tâche d'administration système essentielle. La nouvelle fonctionnalité Abonnements d'événements offre une méthode pour le transfert direct d'événements entre systèmes. Les abonnements d'événements consistent en un Collecteur d'événements rassemblant des événements et des sources d'événements configurées pour transférer des événements à des hôtes spécifiés. La capacité de consommer des événements est fournie par le service Collecteur d'événements de Windows (nouveauté de Windows Eventing 6.0), et la fonctionnalité d'abonné est intégrée au service Journal des événements de Windows. Un collecteur peut être configuré pour rassembler des événements de plusieurs sources d'événements, qui peuvent être des systèmes Windows Server 2008 ou Windows Vista.

Toutes les données recueillies dans des sources d'événements résident dans un Journal des événements, nommé Événements transmis (ForwardedEvents.evtx) et géré par le service Journal des événements sur le collecteur. Une configuration sur les deux points de terminaison (le collecteur et la source) est nécessaire et peut être automatisée (winrm quickconfig –q sur la source, wecutil qc/q sur le collecteur). Il est important de noter que cette capacité d'abonnement d'événements n'a pas été conçue pour les entreprises ou pour remplacer les systèmes qui remettent les événements à une base de données externe.

Une petite batterie de serveurs Web constitue un exemple pouvant tirer parti de cette capacité. Supposez que vous disposez d'un petit ensemble de systèmes associés à un site Web particulier (serveurs Web et SQL Server compris). Ces systèmes peuvent consolider les informations de journal des événements de sécurité sur un système unique en utilisant la nouvelle fonctionnalité Abonnement d'événement. Les environnements de taille plus importante nécessiteront généralement une boîte à outils de consolidation de journal des événements plus avancée.

Services ACS

Compte tenu de toutes les nouvelles capacités de Windows Server 2008, la véritable solution pour la gestion à long terme et l'archivage des informations du journal des événements de sécurité consiste à recourir à une base de données centralisée des informations d'audit. Les services ACS sont une fonctionnalité fondamentale de System Center Operations Manager 2007. Les services ACS fournissent un mécanisme pour le transfert, la collecte, le stockage et l'analyse de données d'événements de sécurité. Les événements de sécurité sont recueillis en quasi-temps réel et enregistrés dans un référentiel SQL central. Les services ACS offrent également aux entreprises une méthode d'attribution d'accès de moindre privilège aux informations d'audit puisqu'aucun accès physique aux systèmes audités n'est en fait nécessaire. Examinons le fonctionnement des services ACS.

Les services ACS possèdent quatre composants principaux : Premièrement, le redirecteur, qui est la partie de l'agent Operations Manager qui transmet les données de journal des événements du client vers l'infrastructure des services ACS. Les redirecteurs transmettent des données au deuxième composant, le collecteur, qui est l'auditeur côté serveur. Les redirecteurs des services ACS se connectent sur le port TCP 51909 pour communiquer avec le collecteur qui leur est affecté, de manière sécurisée. Avant la transmission, les données de journal des événements sont normalisées en XML, ce qui signifie que les informations excédentaires sont éliminées et les informations d'événements sont résumées en champs mappés basés sur les informations spécifiques du corps et de l'en-tête spécifiques à l'événement. Une fois que les informations atteignent le collecteur, elles sont envoyées au troisième et dernier composant, la base de données ACS. Ceci devient le référentiel pour le stockage à long terme d'informations d'événements de sécurité. Une fois enregistrées, les informations peuvent être interrogées directement avec des requêtes SQL ou représentées avec des rapports HTML à l'aide des services SQL Server® Reporting Services. Les ACS fournissent trois affichages par défaut, comme illustré à la figure 7.

Figure 7 Affichages ACS

Du point de vue des performances, un collecteur ACS unique peut contrôler un nombre maximum ponctuel d'événements de l'ordre de 100 000, avec un nombre maximum continu égal à 2 500 événements par seconde. Pour la planification, un collecteur ACS unique peut prendre en charge jusqu'à 150 contrôleurs de domaine, 3 000 serveurs membres ou 20 000 postes de travail, sur la base des paramètres de stratégie d'audit par défaut. Dans un scénario réel testé, près de 150 contrôleurs de domaine ont démontré un maximum approximatif de 140 événements par seconde, avec une moyenne maximale de 500 000 événements par heure. En 14 jours seulement (la configuration de rétention par défaut pour les services ACS), plus de 150 Go de données d'événements de sécurité ont été enregistrés dans la base de données SQL Server. Une stratégie d'audit plus agressive et sa configuration SACL associée produiront évidemment encore plus de données (par heure, par jour et globalement).

Le point important à réaliser ici est qu'avec ce volume de données aucun humain ne pourrait de manière réaliste consulter chaque événement dans un environnement de grande entreprise typique. Réciproquement, les entreprises ne devraient pas s'alarmer des quantités représentées ici. La compréhension des modifications qui surviennent dans votre environnement nécessite l'analyse d'une quantité importante de données.

C'est dans ce domaine que les services ACS revêtent tout leur intérêt. Avec SQL Server Reporting Services et les services ACS, vous pouvez transformer des problèmes habituellement dissimulés dans le journal des événements de sécurité en un élément aussi facilement identifiable que les événements à codage par couleurs du journal des événements d'applications. Bien que les services ACS incluent un ensemble de rapports par défaut, l'extension de ceux-ci aux besoins spécifiques de votre environnement est simple.

Prenez le scénario suivant : en raison de la sensibilité des relations de confiance externes dans l'environnement, la direction nous a demandé de développer un rapport détaillant la création de relations de confiance Active Directory. Après avoir effectué quelques recherches, nous savons qu'un objet trustedDomain est créé dans le conteneur cn = System du contexte de dénomination spécifique d'Active Directory lorsqu'une relation de confiance est créée. Après avoir modifié le SACL de ce conteneur pour vérifier la réussite de la création de tout objet Domaine de confiance, nous avons alors la possibilité de capturer les événements de sécurité chaque fois qu'un objet de ce type est créé. Ceci est intégré à l'événement 566 du journal des événements de sécurité sur le contrôleur de domaine sur lequel la création de relation de confiance a été exécutée. Nous pouvons alors écrire une requête SQL simple pour récupérer cette information depuis ACS :

select * from AdtServer.dvAll 
where EventID = '566' and
String05 like '%trustedDomain%'
order by CreationTime desc

Pour obtenir ceci dans un rapport, utilisez la version de Visual Studio® 2005 incluse avec SQL Server 2005 Reporting Services car elle est faite tout spécialement pour le développement de rapports. À la fin de l'Assistant, des rapports très similaires à celui de la figure 8 seront faciles à créer. Qui plus est, toute modification dans l'environnement pouvant être représentée dans le journal des événements de sécurité peut être résumée dans un rapport d'aspect équivalent.

Figure 8** Rapport d'exemple ACS **(Cliquer sur l'image pour l'agrandir)

Planification d'un audit

Maintenant que nous comprenons les défis comme les aspects légaux et techniques de l'audit, comment les administrateurs informatiques doivent-ils planifier un audit pour leur entreprise ? Le développement d'une stratégie d'audit complète est un processus à plusieurs étapes. La première étape consiste à déterminer ce qui devrait être audité. Ceci inclut l'analyse de votre environnement et la détermination des types d'événements et de modifications devant produire des audits. Ceci pourrait inclure des éléments simples tels que les verrouillages de comptes, les modifications de groupes sensibles, la création de relations de confiance ou les modifications complexes telles que les modifications d'éléments de configuration dans les applications de votre environnement. L'élément clé ici est que la direction de l'entreprise doit être impliquée dans la détermination du « quoi » de la planification d'audit. Cette tâche doit être effectuée sur papier et doit être répétée à intervalles réguliers, et non uniquement après des incidents significatifs.

La deuxième étape implique l'identification de la manière dont les informations concernant des modifications spécifiques sont renvoyées sous la forme d'événements de sécurité. Les informations d'audit sont parfois énigmatiques et difficilement lisibles. Avant la mise en œuvre, des corrélations doivent être établies entre les événements de sécurité et les diverses actions pour comprendre que ce que signifient vraiment les événements de sécurité. Après un incident, il est trop tard pour déchiffrer les relations entre événements et actions.

La troisième étape est la mise en œuvre de votre stratégie d'audit et de vos SACL. Comme indiqué précédemment, vous devrez définir les paramètres de stratégie d'audit (pour permettre la génération d'événements de sécurité) et les SACL (pour produire des suivis d'audit pour les actions associées) dans l'annuaire, le système de fichiers et le Registre, afin d'obtenir un aperçu complet des modifications dans ces éléments.

Tout ceci nous amène à la quatrième et dernière étape, la collecte, les déclencheurs et l'analyse. En fonction de la taille et des besoins de votre entreprise, ces éléments peuvent être couverts avec les capacités natives de Windows Server 2008 ou avec les solutions avancées telles que la fonctionnalité Services ACS de System Center Operations Manager. La définition de la stratégie d'audit sans définition des SACL constitue une erreur courante commise par la plupart des entreprises. La dernière étape a entièrement trait à l'implémentation d'une solution technologique pour la création de rapports et le partage des données avec les parties prenantes de votre organisation. Comme mentionné précédemment, la plupart des organisations disposent d'une entité établie responsable de la sécurité et, pour être efficace, une planification d'audit doit être structurée autour des éléments organisationnels existants. L'élément clé de cette étape finale est la collecte et la présentation des informations de manière pertinente à toutes les personnes en charge de la compréhension des modifications dans l'environnement.

La plupart des entreprises ont besoin d'un incident significatif pour réaliser qu'elles nécessitent un plan d'audit. Windows Server 2008 fournit des mécanismes améliorés pour la collecte et l'analyse de données d'événements de sécurité par rapport aux plates-formes précédentes. Les technologies de collecte et de création de rapports avancées telles que les services ACS exposent des problèmes autrefois masqués par le volume et la distribution des événements, en rendant ces modifications instantanément évidentes.

Comme la plupart des problèmes informatiques, la mise en place d'un processus constitue le défi principal. Une configuration et une analyse supplémentaires sont toujours requises pour capturer ce que recherchent les responsables informatiques et le développement d'une compréhension poussée des exigences de votre environnement et des capacités de la plate-forme Windows vous permettra de répondre directement à ces défis. Bonne recherche !

Rob Campbell et Joel Yoker Rob Campbell est spécialiste technique senior et Joel Yoker est consultant senior dans l’équipe Microsoft Federal. Joel et Rob s'emploient tous deux à développer et à déployer des solutions de sécurité destinées aux agences gouvernementales américaines.

© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.