Rapports de conformité : Première étape du contrôle de l'accès en nuage aux clients

Améliorez vos rapports d'audit et de conformité à l'aide de la protection d'accès réseau NAP (Network Access Protection) et IPsec pour contrôler l'accès aux clients via DirectAccess.

Dan Griffin et Lee Walker

L'établissement d'un accès sécurisé est logiquement la première étape afin d'étendre le nuage à toute l'entreprise. En définissant dès maintenant des stratégies de conformité, de rapports et de connectivité à distance, vous plantez le décor pour que votre équipe travaille au sein du nuage sans problème et en toute sécurité. À l'aide de la protection d'accès réseau (NAP) et des technologies de connectivité IPsec comme DirectAccess, vous pouvez améliorer vos rapports d'audit et de conformité.

Lors de la création d'une solution d'audit et de rapports pour un nouveau déploiement DirectAccess ou IPsec, il peut s'avérer difficile d'identifier et de rassembler les données nécessaires. Nous présenterons ici comment une entreprise fictive peut créer une solution DirectAccess et NAP permettant d'obtenir des données de rapports afin de déterminer qui était connecté, à quel moment et si l'ordinateur client était dans les limites de la conformité.

Le problème de conformité

Les employés devenant de plus en plus mobiles, les technologies flexibles d'accès à distance comme DirectAccess sont de plus en plus utilisées par les entreprises. Grâce à DirectAccess, dès qu'une machine autorisée se connecte à Internet, l'utilisateur est automatiquement connecté au réseau à distance. Puisque les clients distants peuvent parfois avoir des correctifs de sécurité dépassés et susceptibles d'être infectés par des logiciels malveillants, nombreuses sont les entreprises qui déploient également une NAP avec IPsec pour garantir que seuls les clients intègres puissent accéder aux ressources sécurisées.

Dans les secteurs tels que les services financiers, la santé et les administrations publiques, l'importance de vérifier que seuls les clients intègres et approuvés se connectent aux ressources basées sur le nuage ou sur le réseau sur site est essentielle à l'intégrité des données. Ces secteurs sont souvent soumis à des stratégies de conformité internes et à des réglementations qui les obligent à confirmer qu'aucun accès par des parties non autorisées (notamment des logiciels malveillants et des applications tierces inconnues) à des informations d'identification personnelle, tels que des numéros de compte bancaire, des noms ou des dossiers médicaux, n'a eu lieu.

Puisque les utilisateurs recherchent une plus grande facilité d'accès à distance à leurs ressources professionnelles, les responsables informatiques de ces secteurs sécurisés doivent également garantir que seuls des clients intègres accèdent au réseau de l'entreprise. Malheureusement, créer des rapports significatifs à partir de journaux NAP et DirectAccess est un véritable défi.

La solution passe par l'établissement d'une infrastructure DirectAccess pour un accès transparent des clients distants, par la sécurisation des ressources des intranets par NAP et IPsec et par la surveillance de la stratégie via la création de rapports. TechNet présente quelques bonnes informations sur la manière de mettre en œuvre une NAP avec DirectAccess, mais il existe peu de directives sur la manière de journaliser efficacement l'intégrité des clients et de créer des rapports à ce sujet. Nous présenterons une entreprise fictive (Woodgrove National Bank) et démontrerons comment un consultant peut, à l'aide d'un code et de requêtes SQL simples, créer des rapports lisibles pour les responsables, contenant des détails sur les clients qui se sont connectés au cours d'une période donnée, ainsi que sur leur conformité NAP.

Établissement d'une NAP en plus de DirectAccess

DirectAccess requiert que les clients en cours de connexion exécutent une version compatible de Windows (Windows 7 Édition Intégrale ou Windows 7 Entreprise). Ces clients se connectent à un serveur DirectAccess exécutant Windows Server 2008 R2. Un déploiement DirectAccess peut comprendre un ou plusieurs serveurs DirectAccess. (Nous conseillons d'utiliser au moins deux serveurs afin de favoriser l'équilibre de la charge sur les réseaux très occupés.) Ce déploiement doit également comprendre un serveur d'emplacement réseau (afin de déterminer si le client est connecté à Internet ou à l'intranet) et un ou plusieurs points de distribution CRL (Certification Revocation Lists, listes de révocation des certificats) afin de faire le suivi des clients qui ne devraient plus avoir d'autorisation d'accès. Pour savoir comment concevoir un déploiement DirectAccess, voir le Guide de conception de DirectAccess sur TechNet.

Lorsque vous ajoutez une NAP en plus de DirectAccess, vous devez mettre en œuvre la méthode de contrainte de mise en conformité IPsec pour la NAP. Avec IPsec, les clients conformes NAP reçoivent des certificats d'intégrité. Si un ordinateur n'est pas conforme, il ne reçoit pas l'autorisation de communiquer avec les ordinateurs qui le sont. Pour savoir comment concevoir et déployer une NAP, voir Planification de DirectAccess avec protection d'accès réseau sur TechNet. Pour savoir comment concevoir une NAP avec une méthode de contrainte IPsec, voir Conception de contrainte IPsec sur TechNet.

Il est intéressant de se pencher sur la manière dont fonctionne le scénario de contrainte IPsec pour la mise en conformité NAP dans le contexte de DirectAccess et de ses stratégies de connexion IPsec. Tout d'abord, puisque DirectAccess utilise IPsec pour l'authentification et la confidentialité, le scénario de contrainte de la mise en conformité NAP d'un déploiement de DirectAccess doit être IPsec. Ensuite, gardez à l'esprit que le composant AuthIP d'IPsec vous permet de configurer deux exigences d'authentification séparées dans cette stratégie, de manière que la connexion doit satisfaire les deux pour réussir. Généralement, si les deux options d'authentification AuthIP sont configurées, la première est l'information d'identification de la machine et la seconde est celle de l'utilisateur. Cependant, il est techniquement possible de configurer deux informations d'identification pour les machines.

Où la NAP s'intègre-t-elle dans les stratégies AuthIP ? Le scénario de contrainte NAP/IPsec octroie un certificat et son identificateur d'objet (OID, Object Identifier) d'intégrité aux machines intègres. Le moteur de stratégies AuthIP comprend une option visant à exiger cet OID d'intégrité. Ainsi, seules les machines intègres pourront satisfaire la première exigence d'authentification AuthIP et établir une connexion IPsec avec le serveur DirectAccess.

Finalement, l'information d'identification de l'utilisateur concerne la deuxième option d'identification AuthIP. Techniquement, l'information d'identification de l'utilisateur n'est pas obligatoire pour DirectAccess. En d'autres termes, les clients pourraient s'authentifier au niveau du point de terminaison DirectAccess simplement à l'aide d'un certificat de la machine. Tout professionnel de l'informatique soucieux de la sécurité doit veiller à ne pas donner un accès distant complet au réseau sans authentification renforcée. Par conséquent, au minimum, la stratégie AuthIP doit être configurée pour exiger une seconde authentification de Kerberos. Comme dans le scénario de Woodgrove National Bank, il est préférable d'exiger un certificat pour l'information d'identification de l'utilisateur car cela réduit le risque d'attaques par mots de passe statiques à distance.

Dans ce scénario, les services de sécurité et de conformité réseau de Woodgrove National Bank ont requis un rapport indiquant qui s'est connecté au réseau de l'entreprise sur une période donnée, ainsi que la conformité NAP de ces clients. Ces groupes pensent que des données de clients ont pu être compromises au cours de cette période. En tant que consultant pour la banque, nous devons déterminer comment permettre une création de rapports après les faits pour DirectAccess et la NAP, puis récupérer ces informations dans un rapport lisible pour le personnel.

Configuration correcte de stratégie

Dans ce scénario fictif, Woodgrove National Bank a configuré DirectAccess de manière à ce que la stratégie IPsec requière les certificats des clients comprenant l'OID d'intégrité du système NAP et l'OID d'authentification du client. Woodgrove utilise la NAP en mode de contrainte (plutôt que simplement en mode de rapports), ce qui signifie que les clients non intègres ne pourront pas communiquer avec les clients intègres.

Enfin, Woodgrove a configuré la stratégie IPsec de DirectAccess pour demander deux informations d'identification basées sur des certificats : un provenant de l'ordinateur client et un de l'utilisateur. Comme suggéré précédemment, Woodgrove a choisi la configuration à deux certificats afin de mieux utiliser son investissement PKI (infrastructure de clés publiques) et éliminer l'accès à distance par mots de passe statiques, ainsi que pour profiter de l'auto-inscription des certificats.

Le reste de cette histoire part du principe que vous disposez de suffisamment de connaissances sur la manière dont fonctionnent DirectAccess, la NAP et le mode de contrainte d'IPsec. Veuillez vous reporter aux ressources suivantes pour en savoir plus sur ces technologies :

• Présentation exécutive de DirectAccess
• Introduction à la protection d'accès réseau
• Présentation de la contrainte de mise en conformité IPsec NAP

La solution de création de rapports suivante tire avantage des fonctions d'audit intégrées d'IPsec sur le serveur DirectAccess ainsi que des fonctionnalités d'audit du HRA (Health Registration Authority) du serveur NPS (Network Policy Server). Ces fonctions d'audit produisent des événements dans les journaux d'événements du système et de sécurité, que nous extrayons et à partir desquels nous créons des rapports. Lors du développement de cette approche, nous avons constaté que les événements HRA sont produits par défaut, tandis que les événements IPsec peuvent devoir être activés explicitement. Pour activer les événements IPsec, vous pouvez employer les commandes suivantes dans une fenêtre d'invite de commande :

auditpol.exe /set /category:"Logon/Logoff" /subcategory:"IPsec Main Mode" /success:enable /failure:enable

auditpol.exe /set /category:"Logon/Logoff" /subcategory:"IPsec Quick Mode" /success:enable /failure:enable

auditpol.exe /set /category:"Logon/Logoff" /subcategory:"IPsec Extended Mode" /success:enable /failure:enable

Rapports d'intégrité DirectAccess

Pour commencer à travailler sur les événements NAP et DirectAccess de Woodgrove National Bank, nous avons téléchargé et installé Log Parser 2.2 de Microsoft. Log Parser est un outil indispensable pour un projet comme celui-ci, où vous devez étudier une nouvelle source d'événements et développer un schéma approprié. En résumé, Log Parser peut importer et exporter des données depuis et vers plusieurs formats, notamment le journal d'événement Windows (.evtx), CSV et SQL.

L'étape suivante consiste à capturer les événements intéressants. Il s'agit :

• Des événements liés aux associations de sécurité IPsec dans le journal de sécurité des serveurs DirectAccess
• Des événements liés à la HRA dans les journaux de sécurité et système du ou des serveurs HRA (cet élément s'applique uniquement si vous utilisez une NAP)

La solution idéale pour regrouper ces événements est à la fois automatisée et centralisée. Parmi les options possibles, on trouve la fonction Windows de transfert d'événements. Microsoft System Center conviendrait mieux dans un déploiement de production de grande taille. Dans notre cas, nous ne voulions pas introduire de nouvelles dépendances sur les serveurs de production, nous avons donc utilisé des scripts simples pour regrouper les événements.

Avec cette approche, le défi est double. Tout d'abord, l'objectif étant de mettre en corrélation plusieurs sources de données, il est important que les données provenant de toutes les sources soient regroupées en même temps. Ensuite, puisque nous ne prenons qu'un cliché des journaux et que les journaux d'événements à fort trafic s'exécutent rapidement, il est inévitable qu'il manquera certains des événements en corrélation, en particulier en limite de la période de prise du cliché. Ces éléments n'invalident pas l'expérience, mais ils la rendent effectivement plus difficile pour régler les requêtes.

Pour chaque association de sécurité du mode principal d'IPsec (sur l'un des serveurs DirectAccess), nous nous attendons à voir le trafic d'intégrité de la NAP (sur l'un des serveurs HRA). En mode de rapports de la mise en conformité NAP, le client peut être conforme ou non. En mode de contrainte de la mise en conformité NAP, le client doit être conforme. Dans le cas contraire, comment dispose-t-il d'un certificat valide pour l'authentification au serveur DirectAccess et l'établissement d'une association de sécurité (SA, Security Association) ? Imaginons que nous réalisions une capture du journal, en une fois et simultanément, sur tous les serveurs DirectAccess et HRA à 15h. Il est possible qu'apparaisse l'événement d'association de sécurité du mode principal (MM SA, Main Mode Security Association), mais pas l'événement d'intégrité.

Il est encore plus probable qu'apparaissent les événements d'association de sécurité du mode rapide (QM SA, Quick Mode Security Association) IPsec et les événements d'association de sécurité du mode étendu (EM SA, Extended Mode Security Association) IPsec, mais pas les événements MM SA ou d'intégrité. Le premier peut se produire une heure ou plus tard encore après le second. De plus, les journaux de serveurs séparés s'exécutent presque certainement à des fréquences différentes, nous pouvons ainsi nous retrouver avec des événements à 14h sur le serveur DirectAccess mais des événements seulement à 14h30 au mieux sur le serveur HRA. C'est pour ces raisons que nous souhaitons répéter qu'il est important d'utiliser un regroupement des événements centralisé en production.

Génération des données

Pour générer les données, nous avons exécuté des scripts sur les serveurs DirectAccess et sur les serveurs HRA. Nous avons également configuré l'exécution automatique des scripts à l'aide du Planificateur de tâches. Nous avons configuré l'exécution du script sur le serveur DirectAccess et sur tous les serveurs HRA en une fois et simultanément.

Recueil des données sur les serveurs DirectAccess

Nous avons utilisé le script suivant pour capturer les événements sur le serveur DirectAccess (voir la Figure 1).

set MPATH=c:\temp\Logs

%MPATH%\LogParser.exe "SELECT * INTO %MPATH%\DA_Security_Events_%COMPUTERNAME%.csv FROM Security WHERE EventCategory=12549 OR EventCategory=12547 OR EventCategory=12550" -o:CSV

Remarque : Ce script utilise une copie locale de LogParser.exe (et de LogParser.dll, son fichier de dépendance). Nous avons pris cette référence pour des raisons pratiques, afin de pouvoir copier facilement ce script d'un serveur à l'autre.

Figure 1 Détails des événements capturés sur le serveur DirectAccess à l'aide d'un script exécuté automatiquement via le Planificateur de tâches.

Événement	Description
12547	Informations MM SA (Association de sécurité du mode principal) IPsec
12549	Informations QM SA (Association de sécurité du mode rapide) IPsec
12550	Informations EM SA (Association de sécurité du mode étendu) IPsec

 

Recueil des données sur les serveurs HRA

Pour capturer les événements des serveurs HRA, nous avons utilisé le script suivant :

set MPATH=c:\temp\Logs

%MPATH%\LogParser.exe "SELECT * INTO %MPATH%\HRA_Security_Events_%COMPUTERNAME%.csv FROM Security WHERE EventCategory=12552" -o:CSV

%MPATH%\LogParser.exe "SELECT * INTO %MPATH%\HRA_System_Events_%COMPUTERNAME%.csv FROM System WHERE SourceName='HRA'" -o:CSV

Remarque : Dans le script HRA, la catégorie d'événement 12552 correspond au service NPS (Network Policy Server).

Importation des données

Après l'exécution des scripts, nous avons regroupé les fichiers CSV de sortie sur une autre machine exécutant SQL Server 2008. Nous avons utilisé le script suivant pour importer les données CSV dans SQL :

LogParser.exe "SELECT * INTO DaSasTable FROM DA_*.csv" -i:CSV -o:SQL -server:dev1 -database:NapDa -createTable:ON -maxStrFieldLen:1023
LogParser.exe "SELECT * INTO HraSecurityEventsTable  FROM HRA_Security_*.csv" -i:CSV -o:SQL -server:dev1 -database:NapDa -createTable:ON -maxStrFieldLen:1023
LogParser.exe "SELECT * INTO HraSystemEventsTable  FROM HRA_System_*.csv" -i:CSV -o:SQL -server:dev1 -database:NapDa -createTable:ON -maxStrFieldLen:1023

Remarques :

• La machine hôte SQL porte le nom dev1. La base de données s'appelle NapDa et a été créée à l'aide des valeurs par défaut de SQL Management Studio.
• Les trois tables, DaSasTable, HraSecurityEventsTable et HraSystemEventsTable n'existaient pas. L'option de ligne de commande -createTable:ONLog Parser indique à Log Parser de créer automatiquement ces tables à l'aide d'un schéma convenable basé sur les données d'entrée (les fichiers CSV de journaux d'événement, dans ce cas).
• Le paramètre -maxStrFieldLen:1023setting est important dans ce scénario. Sans ce paramètre, Log Parser utiliserait une longueur de champ varchar par défaut de 255 pour les différents champs de chaîne du journal d'événements. Cependant, le format CSV du journal d'événements présente des chaînes de données plus longues que cela (en particulier dans le champ des chaînes, voir la figure 2), et il est important qu'elles ne soient pas tronquées. Nous avons expérimenté une longueur par défaut de 1023 qui semble être adéquate.

La figure 2 indique le schéma résultant de l'importation du journal d'événements CSV de Log Parser.

Figure 2 Schéma d'importation du journal d'événements CSV de Log Parser.

Préparation des données

Lors de la création du rapport d'intégrité DirectAccess, le défi principal en termes d'extraction des données requises réside dans le format CSV du journal d'événement car celui-ci est basé sur les chaînes de données. Dans le contexte d'une interface graphique, les données sont entrelacées en chaînes statiques qui décrivent la signification de chaque champ de données. Les chaînes de données comprennent tout ce qui intéresse un rapport d'intégrité DirectAccess, notamment le nom des utilisateurs, des machines, des groupes de stratégies et les adresses IP.

Les chaînes de données sont concaténées en un seul champ CSV, puis en une seule colonne SQL (encore une fois, des chaînes). Chaque chaîne est séparée de la suivante par le caractère « | ». Une possibilité de résolution serait d'attribuer un jeton aux chaînes, soit avant, soit juste après l'importation des données dans SQL. Cela dit, notre préférence est allée à l'analyse des chaînes après l'importation dans SQL, puis à l'extraction des quelques éléments de données spécifiques dont nous avions besoin pour remplir des tables SQL séparées.

La réalisation de cette tâche, et la correspondance des modèles de chaînes avec T-SQL, est difficile. Nous avons opté pour une alternative : une approche documentée dans un ancien article de MSDN Magazine, Les expressions régulières facilitent la recherche de correspondances et l'extraction de données. Il s'agit de mettre en œuvre des fonctionnalités définies par l'utilisateur pour SQL à l'aide de C#, spécifiquement dans le but de correspondances de modèles basés sur les expressions régulières.

Sous Visual Studio 2008, nous avons suivi pratiquement à la lettre les étapes décrites dans cet article, bien qu'il nous a été utile de se référer à de la documentation supplémentaire pour que l'intégration initiale de SQL et CLR fonctionne avec Visual Studio. De même, en raison de la complexité inhérente aux expressions régulières (RegEx), nous référer à la documentation de cette technologie nous a également été utile, en particulier la section sur le regroupement, puisque c'est cette approche qui est utilisée par l'exemple de code fourni dans l'article de MSDN Magazine.

L'exemple de code suivant donne en détails le code source de la fonctionnalité SQL définie par l'utilisateur afin d'exposer les fonctions RegEx dans nos instructions SELECT. Cette fonction s'appelle RegexGroup, exactement comme celle citée dans l'article de MSDN Magazine. Nous avons apporté une modification aux deux premières lignes du corps de la fonction afin de pouvoir vérifier la présence des valeurs d'entrée NULL. Avant d'ajouter ces deux lignes, nous avons rencontré de nombreuses exceptions car plusieurs colonnes de notre table d'aide SQL (décrite ici) présentent des valeurs NULL :

 

usingSystem;

usingSystem.Data;

usingSystem.Data.SqlClient;

usingSystem.Data.SqlTypes;

usingMicrosoft.SqlServer.Server;

usingSystem.Text.RegularExpressions;

publicpartialclassUserDefinedFunctions

{

    [Microsoft.SqlServer.Server.SqlFunction]

publicstaticSqlChars RegexGroup(

SqlChars input, SqlString pattern, SqlString name)

{

if (true == input.IsNull)

returnSqlChars.Null;

Regex regex = newRegex(pattern.Value, Options);

Match match = regex.Match(newstring(input.Value));

returnmatch.Success ?

newSqlChars(match.Groups[name.Value].Value) : SqlChars.Null;

}

};

Les commandes SQL suivantes créent et remplissent deux tables d'aide composées de chaînes extraites des données initiales à l'aide de RegEx :

/* Create the User-Computer-Address mapping helper table */
/* This step should only be performed once per data set */
CREATE TABLE UserComputerAndAddr
(
[RowN] int null,
[UserName] varchar(1023) null,
[ComputerName] varchar(1023) null,
[Address] varchar(1023) null
)

/* Populate the User-Computer-Address table */
/* This step should only be performed once per data set */
INSERT INTO UserComputerAndAddr(RowN, UserName, ComputerName, Address)
SELECT RowNumber,
    dbo.RegexGroup([Strings],N'(?<un>[0-9a-zA-Z]+)@redmond.corp.microsoft.com',N'un'),
    dbo.RegexGroup([Strings],N'(?<machine>[0-9a-zA-Z\-]+)(?<!CO1RED-TPM-01)\$@redmond.corp.microsoft.com',N'machine'),
    dbo.RegexGroup([Strings],N'(?<ipv6addr>[0-9a-fA-F]{1,4}:[0-9a-fA-F]{1,4}:[0-9a-fA-F]{1,4}:[0-9a-fA-F]{1,4}:[0-9a-fA-F]{1,4}:[0-9a-fA-F]{1,4}:[0-9a-fA-F]{1,4}:[0-9a-fA-F]{1,4})',N'ipv6addr')
FROM [NapDa].[dbo].[DaSasTable]

/* Create the Computer-Health mapping helper table */
/* This step should only be performed once per data set */
CREATE TABLE ComputerHealth
(
[RowN] int null,
[TimeGenerated] datetime null,
[EventType] int null,
[ComputerName] varchar(1023) null
)

/* Populate the Computer-Health mapping table */
/* This step should only be performed once per data set */
INSERT INTO ComputerHealth(RowN, TimeGenerated, EventType, ComputerName)
SELECT RowNumber,
    TimeGenerated,
    EventType,
    dbo.RegexGroup([Strings],N'REDMOND\\(?<machine>[0-9a-zA-Z\-]+)\$',N'machine')
FROM [NapDa].[dbo].[HraSystemEventsTable]

Vous pouvez commencer à comprendre les modèles de chaînes en examinant la première instruction SELECT et son utilisation de la fonction RegexGroup installée par la technique que nous avons décrite. Figure 3 Détails des trois modèles RegEx définis.

Figure 3 Les trois modèles RegEx définis à l'aide des commandes SQL.

Modèle d'expression régulière	Remarques
Nom d'utilisateur	Exemple : ichiro@redmond.corp.microsoft.com
Nom de l'ordinateur	Exemple : dan-dev-1@redmond.corp.microsoft.com Remarquez que, dans ce modèle, nous avons explicitement exclu les correspondances avec le serveur DirectAccess lui-même.
Adresse IPv6	Exemple : 2001:0:4137:1f6b:8c8:2f30:e7ed:73a8 ·        Ce modèle ne correspondra pas à toutes les adresses IPv6 valides. Vous devrez l'améliorer si vous souhaitez l'utiliser dans d'autres contextes. ·        Même s'il existait d'autres champs d'adresse IPv6 intégrées dans la colonne des chaînes, l'adresse du client semblait être la seule à correspondre à ce modèle. Vous devrez peut-être revoir ceci si vous obtenez des adresses inattendues dans vos requêtes.

 

Ensemble, ces expressions régulières permettent de créer une table composée des informations Utilisateur, Ordinateur et Adresse pour chaque ligne de DaSasTable (c.-à-d., les événements SA d'IPsec exportés depuis la machine DirectAccess).

Une fois la table UserComputerAndAddr créée et remplie, une seconde table est créée. Elle mappe le nom de l'ordinateur au type d'événement pour chaque ligne de la table HraSystemEventsTable. Si vous examinez le modèle de nom de l'ordinateur, vous constaterez que le format du nom de l'ordinateur dans ce journal est différent du journal DirectAccess. Dans le cas présent, nous recherchons les chaînes telles que REDMOND\dan-dev-1. La figure 4 décrit les différents événements pouvant être présents dans le champ EventType.

Figure 4 Types d'événements pouvant être présents dans le champ EventType.

Type d'événement	Description
0	Succès. L'ordinateur a soumis une instruction d'intégrité conforme NAP.
1	Échec. L'ordinateur n'est pas conforme à la stratégie NAP.

 

Dans le rapport d'intégrité de ce déploiement, nous nous attendons uniquement à voir un type d'événement 0. Ceci est dû au mode de contrainte de la mise en conformité NAP. Comme vous le constaterez ci-dessus, nous filtrons également les associations de sécurité IPsec réussies. Si le client n'est pas conforme, il ne doit pas pouvoir acquérir de certificat IPsec valide et établir de SA. En revanche, si votre entreprise a déployé une NAP en mode de création de rapports, vous pouvez vous attendre à constater la connexion de machines non conformes. Le pourcentage relatif de machines conformes par rapport aux machines non conformes connectées au réseau est une statistique importante à signaler.

Remarque : Lorsque vous utilisez des tables pour les résultats RegEx, nous vous conseillons d'utiliser des tables SQL permanentes. Si vous utilisez des tables temporaires (comme nous l'avons fait dans la démo de l'étape suivante), les requêtes RegEx seront lentes.

Génération du rapport

Une fois l'analyse des expressions régulières terminées et les tables d'aide créées, nous pouvons nous concentrer sur la génération du rapport d'intégrité. Lorsque les données ont été préparées, la rédaction des requêtes du rapport est relativement facile.

L'objectif de cet exemple de rapport consiste à dresser la liste de tous les utilisateurs ayant établi une connexion DirectAccess entre 15h et 16h le 5 mai 2010. Outre le nom d'utilisateur, le rapport mentionne le nom de l'ordinateur et l'état de l'intégrité.

Afin d'identifier ces utilisateurs, nous allons commencer par écrire une requête des QM SA (catégorie d'événement 12549) réussies (type d'événement 8) de la période. L'utilité de l'événement QM SA dans ce scénario réside dans le fait que l'IPsec a été configuré pour requérir une authentification du second facteur (informations d'identification de l'utilisateur). Nous avons choisi de suivre cette approche de création de rapports car les QM SA ont une durée de vie relativement courte (une heure, dans le cas présent, avec un délai d'inactivité de cinq minutes) et sont donc pratiques pour l'accès de l'audit. Un MM SA, en revanche, implique uniquement l'utilisation des informations d'identification de l'ordinateur et dure huit heures par défaut (même si nous recommandons de réduire la durée MM si l'audit est un composant important de votre déploiement de DirectAccess).

Malheureusement, les événements QM n'incluent ni le nom d'utilisateur ni le nom de l'ordinateur. Ils ne comprennent que l'adresse IP. Pour mapper l'adresse IP à un nom de machine et d'utilisateur, nous pouvons utiliser quelques instructions SELECT dans la requête SQL. La première instruction SELECT de la requête suivante renverra la liste des adresses apparaissant dans les nouvelles QM SA de la période. La seconde instruction SELECT utilise ces adresses pour les mapper aux noms d'utilisateur et de l'ordinateur associés à cette adresse ailleurs dans le fichier journal. (Cette association utilisateur/ordinateur/adresse se trouve dans les événements EM SA. Ceux-ci sont critiques pour le présent exercice car ils contiennent les trois valeurs. Si vous n'utilisez pas de seconde authentification IPsec, vous ne pourrez pas effectuer de type de rapports.)

/* The following steps build the report, based on the three imported tables

* plus the two helpers above. These steps can be run any number of times as

* you refine your query.

*/

/* Create a temporary table to populate as the final report */

CREATE TABLE #SaHealthReport
(

[UserName] varchar(1023) null,

[ComputerName] varchar(1023) null,

[HealthEventType] int null

)

/* Run a query to find all IPsec Quick Mode Security Associations established

* within a given period. Populate a temporary table with the client IPv6

* addresses. */

SELECT DISTINCT[Address] INTO #TempAddresses

FROM [NapDa].[dbo].[DaSasTable] JOIN [NapDa].[dbo].[UserComputerAndAddr]

      ON RowN = RowNumber

WHERE [EventType]=8 AND

      [EventCategory]=12549 AND

      ([TimeGenerated] BETWEEN'2010-05-10 15:00:00.000' AND '2010-05-10 16:00:00.000')

/* Map the QM SA addresses to user and computer names and insert those into

* the final report. */

INSERT INTO #SaHealthReport(UserName,ComputerName)

SELECT UserComputerAndAddr.UserName,UserComputerAndAddr.ComputerName

FROM [NapDa].[dbo].[UserComputerAndAddr] JOIN #TempAddresses

      ON #TempAddresses.Address = UserComputerAndAddr.Address

WHERE (UserComputerAndAddr.UserName IS NOT NULL) AND (UserComputerAndAddr.ComputerName IS NOT NULL)

/* Populate the health column of the report. */

UPDATE #SaHealthReport

SET HealthEventType = ComputerHealth.EventType

FROM #SaHealthReport JOIN [NapDa].[dbo].[ComputerHealth]

      ON #SaHealthReport.ComputerName = ComputerHealth.ComputerName

/* Display all rows and columns of the report. */

SELECT DISTINCT *

FROM #SaHealthReport

La dernière étape nécessaire pour remplir la table de rapport SaHealthReport consiste à mettre en corrélation les informations d'intégrité HRA avec les informations d'identité de l'ordinateur et de l'utilisateur qui, pour l'instant, venaient exclusivement du serveur DirectAccess. L'incorporation des informations du serveur HRA dans ce mélange est un outil puissant qui permet de déterminer si les ordinateurs connectés à distance à votre réseau présentent un risque (en raison de la non-conformité). Regardez l'instruction UPDATE dans la requête SQL précédente : la corrélation entre les données DirectAccess et HRA est réalisée en utilisant le nom d'ordinateur du client.

La figure 5 présente des exemples de données pouvant être retournées depuis un rapport d'intégrité terminé.

Figure 5 Exemple de rapport d'intégrité terminé

UserName	ComputerName	HealthEventType
Ichiro	ichiroadmin1	0
Grinch	whoville-cli	0
Raquel	omybc	0

 

Vous pouvez établir des rapports sur le déploiement d'IPsec (notamment DirectAccess) et de la NAP relativement facilement grâce à des scripts personnalisés et à l'outil LogParser. Cette approche permettra à toute entreprise de commencer à créer un cadre sécurisé pour les services métier exposés, que ce soit sur site ou dans le nuage.

Dan Griffin est consultant en sécurité logicielle basé à Seattle. Vous pouvez le joindre à  www.jwsecure.com

 

Lee Walker est l'architecte technologique du service informatique interne de Microsoft. Il se concentre sur IPv6, IPsec, NAP, DirectAccess et d'autres technologies. Vous pouvez le joindre à lee.walker@microsoft.com.

 

Contenu associé

• Le petit câbleur : DirectAccess et le réseau « Thin Edge »
• Vigilance sécurité : Réflexions sur l'identité, première partie
• Vigilance sécurité : Réflexions sur l'identité, deuxième partie