June 2008 June 2008
Sécurité: Le grand débat : la sécurité par l'obscurité
La sécurité par l'obscurité implique la prise de mesures qui ne suppriment pas un vecteur d'attaque mais le dissimule. Certains considèrent qu'il s'agit d'une mauvaise pratique, tandis que d'autres estiment que dans le cadre d'une stratégie de plus grande taille, chaque élément compte. Le débat fait rage et certains de nos meilleurs experts en sécurité se font face à face, en expliquant la sécurité par l'obscurité et en présentant les deux camps. Jesper M. Johansson and Roger Grimes
Sécurité: Nouveaux PowerToys d’élévation pour Windows Vista
Michael Murgolo est de retour avec une mise à jour de ses PowerToys d'élévation. Découvrez une fonction Exécuter en tant qu'administrateur améliorée fonctionnant avec des outils de script de fournisseurs tiers, une façon de remplacer une fonction pratique de Windows XP supprimée dans Windows Vista, et de nombreux autres outils utiles. Michael Murgolo
Sécurité: Avancées dans le domaine du chiffrement de lecteur BitLocker
Windows Vista SP1 et Windows Server 2008 introduisent d'importants changements dans BitLocker, y compris la prise en charge de volumes de données et la protection améliorée contre les attaques cryptographiques. Byron Hynes explore ces nouvelles fonctionnalités, montre comment utiliser BitLocker sur un serveur et aborde certains aspects de la couverture médiatique récente concernant BitLocker. Byron Hynes
Sécurité: Verrouillage d'applications avec les stratégies de restriction logicielle
Lorsque vous voulez réduire le coût total de possession des ordinateurs de bureau de votre entreprise, le verrouillage d'applications peut être très utile puisqu'il permet de réduire les problèmes informatiques liés aux applications non prises en charge. Découvrez comment vous pouvez utiliser les stratégies de restriction logicielle et la Stratégie de groupe pour contrôler les applications exécutées dans votre infrastructure informatique. Chris Corio and Durga Prasad Sayana
Sécurité: Gestion du pare-feu Windows Vista
La mise à jour récente du pare-feu Windows Vista offre de nouvelles fonctions impressionnantes qui en font un outil de premier choix pour l'environnement d'entreprise. Jesper Johansson présente brièvement l'évolution du pare-feu Windows et examine les améliorations (telles que les nouvelles règles et profils, l'isolation de domaine et le chiffrement) qui peuvent intéresser les administrateurs. Jesper M. Johansson
Sécurité: Sécurisation du courrier électronique grâce aux certificats numériques
S/MIME (Secure Multipurpose Internet Mail Extensions) vous permet de masquer les informations en transit, de valider les expéditeurs et d'authentifier les messages. Apprenez à sécuriser le courrier électronique à l'aide des certificats numériques et comment résoudre des problèmes que vous pouvez rencontrer sur votre système S/MIME. Matt Clapham and Blake Hutchinson
Columns
Le mot du rédacteur en chef: Le grand débat: | Lettres: Les lecteurs ont la parole: | Boîte à outils: Nouveaux produits pour les professionnels de l’informatique:
Forum aux questions sur SQL&: Erreurs d'E/S, mise en miroir de base de données et bien plus encore: Paul Randal répond à vos questions sur SQL Server, vous montre comment créer une altération dans une base de données de test, vous aide à éviter un cycle réduction-accroissement-réduction-accroissement et explique comment déterminer le nombre de bases de données pouvant être mises en miroir avant une dégradation des performances.Paul S. Randal | Coup de projecteur sur les utilitaires: Conseiller de mise à niveau vers Windows Vista: Prêt à mettre à niveau les systèmes de votre entreprise vers Windows Vista ? Découvrez comment le Conseiller de mise à niveau vers Windows Vista peut vous aider à déterminer si vos systèmes sont prêts pour Windows Vista et les versions qu'ils peuvent prendre en charge.Lance Whitney | Au cœur de SharePoint: Décentralisation de l'administration de site: Découvrez les avantages et implications d'une délégation du contrôle administratif à des départements via des sites SharePoint tout en maintenant un contrôle administratif centralisé sur l'infrastructure SharePoint.Pav Cherny
Windows PowerShell: Du beau boulot: Découvrez comment la nature orientée objets de Windows PowerShell vous permet d'appliquer un formatage à ses résultats.Don Jones | Hé, vous le scripteur !: Pas besoin de travailler dur pour être récompensé: Les scripteurs considèrent le travail assidu comme le bonheur ultime et les données d'affichage dans la fenêtre de commande sous la forme d'un tableau lisible.The Microsoft Scripting Guys | Histoires de Bureau: Sécurité contre conformité: Les professionnels de l'informatique se retrouvent souvent avec des objectifs qui se contredisent. Prenez l'exemple de la manière dont la conformité est souvent obtenue au détriment de la sécurité.Wes Miller
L'informatique dans l'entreprise: 10 façons de devenir un leader écologique: Étant donné que les services informatiques jouent un rôle de plus en plus important dans les efforts écologiques des entreprises, les professionnels de l'informatique y trouvent une occasion d'initier un changement et de devenir des leaders d'opinion dans leurs entreprises et secteurs. Voici comment devenir un leader d'opinion efficace en matière d'environnement et de développement durable dans votre entreprise.Michael Walsh and Eliza Walsh | Sur le terrain: Split Screen: Développé par Microsoft Research Inde, Split Screen permet à deux utilisateurs de partager un moniteur tout en exécutant des instances séparées du système d'exploitation de chaque côté.Kentaro Toyama | La vie secrète de Windows: Les deux pires PC jamais conçus: Raymond Chen évoque tendrement son utilisation des deux pires ordinateurs qu'on n'ait jamais conçus.Raymond Chen


Sécurité
Le grand débat : la sécurité par l'obscurité
Jesper M. Johansson and Roger Grimes
Vue d'ensemble:
  • Définition de la sécurité par l'obscurité
  • Évaluation de la sécurité par des mesures d'obscurité
  • Comprendre l'intérêt du changement de nom du compte Administrateur
  • Prendre des décisions informées de gestion des risques

Le terme « sécurité par l'obscurité » est souvent pris à la dérision par les professionnels de la sécurité, notamment ceux qui se considèrent comme experts. Quasi considérée comme un juron dans certains milieux, la sécurité
par l'obscurité, selon Wikipedia (en.wikipedia.org/wiki/Security_through_obscurity), représente l'un des aspects véritablement controversés de la sécurité. Vous verrez souvent des références moqueuses à des personnes dont les efforts sont relégués comme étant « seulement de la sécurité par l'obscurité ».
La sécurité par l'obscurité est, pour rester simple, une violation du principe de Kerckhoffs, qui décrit un système comme étant sécurisé de par sa conception et non parce que sa conception est inconnue de l'adversaire. Le principe fondamental de Kerckhoffs est que les secrets ne restent pas secrets très longtemps.
Le protocole d'authentification Windows NT® LAN Manager (NTLM), qui était considéré au début comme un secret de conception, constitue un excellent exemple. Pour implémenter l'interopérabilité de produit Samba pour les systèmes d'exploitation basés sur UNIX, l'équipe Samba a dû effectuer une rétroconception du protocole. Le résultat a été la documentation la plus complète disponible sur NTLM (monyo.com/technical/samba/translation/ntlm.en.html) ainsi que la découverte de plusieurs bogues. Comme une très grande partie de la sécurité a évolué à partir de la cryptographie, et que tant de conceptions secrètes ont été révélées, de nombreux professionnels de la sécurité estiment que toute sécurité des informations doit suivre le principe de Kerckhoffs.
Mais la sécurité par l'obscurité est-elle toujours mauvaise ? Dans cet article, nous décrirons ce qu'est la sécurité par l'obscurité, tenterons d'expliquer pourquoi beaucoup la considèrent comme une perte de temps (et d'autres non) et vous montrerons pourquoi la réponse, comme d'habitude, est beaucoup plus compliquée qu'elle ne semble l'être au premier abord.

Présentation de la sécurité par l'obscurité
Ne modifiez pas les valeurs par défaut, par Steve Riley
Je suis partisan de l'opinion « ne changez rien » sur la question du changement de nom. Il ne s'agit même pas d'une question de sécurité. C'est un problème d'administration des systèmes. Comme je passe plus de temps à réfléchir sur le domaine de l'administration de systèmes (car l'administration et la sécurité sont en train de fusionner), je deviens de plus en plus partisan du « ne rien faire » qui peut accroître la vulnérabilité d'un système. Ne plus utiliser les éléments par défaut est une méthode garantie pour accroître la vulnérabilité. Il existe deux (d'accord, trois) raisons pour lesquelles les gens modifient les paramètres par défaut :
  • La modification permet de répondre à une exigence connue de la fonctionnalité.
  • Il est supposé que la modification améliorera la sécurité.
  • (Attention : préparez-vous à entendre des sottises) Quelqu'un l'a lu dans un article de magazine.
Si vous devez changer pour ne plus utiliser un nom par défaut pour la raison numéro 1, allez-y. Ces types de modifications ont rarement pour résultat l'instabilité du système, souvent parce qu'ils ont été testés au préalable.
Si vous modifiez une valeur par défaut pour la raison numéro 2, arrêtez-vous et prenez un moment pour réfléchir. Ces types de modifications ne sont presque jamais testés par le fabricant du logiciel et celui-ci ne peut donc pas prédire comment le système se comportera après que vous ayez effectué la modification. De plus, il existe généralement de bien meilleures alternatives qui vous offriront une véritable sécurité.
Si une personne mal intentionnée arrive à connaître le nom d'un compte, est-ce si important ? C'est le mot de passe et la force de ce mot de passe qui gardent cette personne à l'écart de votre système. L'envie de modifier les noms de compte par défaut comme Administrateur et Invité pour les remplacer par quelque chose de moins facile à deviner est en fait souvent un indicateur du désir d'éviter les mots de passe forts. Résolvez le véritable problème (les secrets douteux) et vous pourrez alors éviter la vulnérabilité (la modification des noms par défaut).

La sécurité par l'obscurité n'inclut pas de mesures qui ne font absolument rien pour atténuer un problème. Par exemple, une organisation qui bloque le protocole NNTP (Network News Transfer Protocol) aux routeurs de périmètre pour empêcher les employés de lire les groupes de discussion mais autorise le Shell sécurisé (SSH) sortant n'applique pas la sécurité par l'obscurité. Puisque SSH peut acheminer tous les protocoles, le problème n'est pas obscurci. L'atténuation absurde qui a été implémentée ne fait rien d'autre qu'empêcher les utilisateurs légitimes d'accomplir des tâches légitimes sans enfreindre des stratégies de sécurité. De telles mesures ne correspondent pas à la sécurité par l'obscurité. Elles sont absurdes et dénuées de sens.
Comme l'indique le mot « sécurité » dans le terme « sécurité par l'obscurité », vous obtenez vraiment une certaine protection grâce à celle-ci. Cependant, ce que ce terme implique également (et c'est là tout le problème) est que vous ne faites rien pour arrêter une attaque d'un ou plusieurs vecteurs (un vecteur d'attaque est en gros un moyen par lequel un attaquant peut accéder à un système).
Supposez que vous ayez par exemple un serveur Web vulnérable, pouvant être attaqué via le port TCP 80 par du code malveillant. Pour fermer ce vecteur particulier, vous pouvez appliquer un correctif au serveur Web ou l'éteindre. Chacune de ces actions arrêterait complètement ce vecteur. Vous pourriez arrêter partiellement le vecteur d'attaque en utilisant un pare-feu ou IPSec pour fermer le port 80 à tout sauf à quelques ordinateurs particuliers. Ceci ne bloquerait pas complètement le vecteur d'attaque, mais atténuerait de manière significative le problème.
La sécurité par l'obscurité, d'un autre côté, implique la prise de certaines mesures n'arrêtant pas le vecteur d'attaque mais le dissimulant simplement. Par exemple, vous pouvez décider de transférer le serveur Web sur le port 81 au lieu du port 80 afin que seuls ceux qui savent où trouver votre serveur Web puissent le faire. C'est ainsi que cela se justifie. En réalité, le transfert de votre serveur Web sur le port 81 arrête seulement certaines attaques et dérange principalement l'utilisateur final. Un intrus compétent exécuterait simplement un scanneur de port et une capture de bannière Web avec plusieurs ports pour découvrir des serveurs Web sur les ports non standard. Dès qu'il en aura trouvé, il pourra exécuter le code malveillant contre votre serveur car vous n'avez en fait pas éliminé le vecteur d'attaque, mais l'avez simplement (temporairement) obscurci.
Cela signifie-t-il que vous ne devriez même pas essayer ? La réponse est : ça dépend. Comme avec tout ce qui a trait au domaine de la sécurité des informations, cela se réduit à la gestion des risques. Pour comprendre les facteurs clés à prendre en considération, nous examinerons rapidement quelques mesures de sécurité par l'obscurité supplémentaires et commenterons l'une de celles-ci (renommer le compte administrateur) plus en détail.

Évaluer les mesures de sécurité
Les exemples de sécurité par l'obscurité sont nombreux. Il peut s'agir d'actions prises par les administrateurs système et réseau ou initiées par les développeurs de logiciels. Ce qu'elles ont toutes en commun, cependant, est qu'elles ont pour objectif d'atténuer une vulnérabilité en la masquant des attaquants potentiels.
Certaines de ces procédures ne pourraient-elles pas au moins avoir un effet avantageux ? Est-il vraiment juste de dire que toute sécurité par l'obscurité est mauvaise ? Vous trouverez certainement des partisans d'au moins certaines de ces mesures. Par exemple, dans Windows®, il est possible de masquer les lettres de lecteur dans l'Explorateur Windows. Dans de nombreux environnements, plus particulièrement dans les salles d'informatique des établissements scolaires, vous utiliserez cette technique pour empêcher les utilisateurs d'enregistrer des données sur le disque dur. Bien entendu, la plupart des applications peuvent toujours enregistrer des données sur le disque dur et elle n'a qu'une valeur limitée en tant que mesure de sécurité. Cependant, les établissements qui l'ont implémentée déclarent souvent qu'elle réduit la quantité de données sur le disque dur.
Une autre pratique de sécurité par l'obscurité souvent mise en œuvre sur Windows consiste à désactiver les partages réseau administratifs (tels que C$, Admin$, etc.). Ceci a pour but d'empêcher un attaquant de se connecter à l'ordinateur à distance. En réalité, ceci est non seulement faux, mais en plus, un attaquant possédant un compte qui peut utiliser les partages administratifs peut réactiver à distance ces mêmes partages. Pourtant, de nombreuses entreprises déclarent solennellement que la désactivation de ces partages réduit la quantité de logiciels malveillants sur leurs réseaux.
L'un des nos exemples préférés d'efforts mal gérés est le paramètre « autoriser le retrait sans ouverture de session préalable » de Windows. Si ceci est désactivé, le bouton « Retirer l’ordinateur » est masqué de l'écran d'ouverture de session. Le principe sous-jacent est que de cette manière un attaquant ne peut pas retirer normalement l'ordinateur. Bien sûr, tout intrus peut simplement mettre l'ordinateur et la station d'accueil dans un sac et s'en aller avec, que ce bouton soit visible ou non. Cette possibilité n'est pas même de manière lointaine de la sécurité par l'obscurité.
Le paramètre « permettre aux opérateurs du serveur de planifier des tâches » est un autre exemple évident. Comme il l'indique, il permet aux utilisateurs membres du groupe Opérateurs de serveur de planifier des tâches. Il s'agit d'un problème sensible car de telles tâches peuvent s'exécuter comme Système local, et seuls les administrateurs doivent pouvoir planifier des tâches s'exécutant comme Système local. Bien entendu, les opérateurs de serveur peuvent potentiellement se rendre administrateurs grâce à différents vecteurs et les empêcher de planifier des tâches de cette manière a en fait un intérêt minimal.
Pourtant, de nombreuses entreprises apprécient ce paramètre car il permet aux ingénieurs d'être opérateurs de serveurs au lieu des administrateurs, ce qui signifie qu'ils risquent probablement moins de détruire accidentellement le serveur. Ceci, en soi, peut apporter un certain avantage.
Par conséquent, quel est le verdict ? Il est évident que certains de ces problèmes peuvent être très complexes. Nous avons passé des heures à débattre agréablement de ces types de mesures. Roger est fermement dans le camp qui trouve que de telles pratiques ont une valeur. Jesper, d'un autre côté, pensent qu'elles sont, dans le meilleur des cas, une perte de temps. Examinons un cas fréquemment abordé (et débattu) pour la sécurité par l'obscurité : renommer le compte administrateur. Roger sera en faveur de cette mesure, Jesper contre celle-ci. Les barons de la sécurité Aaron Margosis et Steve Riley donnent également respectivement leur avis dans les encadrés « Renommer le compte administrateur » et « Ne modifiez pas les valeurs par défaut ».

Masquer le compte Administrateur
Renommer le compte Administrateur, d'identificateur relatif (RID) 500, est relativement peu connu du grand public, souvent recommandé par les professionnels de la sécurité et est inclus dans plusieurs guides de renforcement de Microsoft. La Stratégie de groupe inclut même un paramètre pour renommer le compte Administrateur, comme indiqué à la figure 1. Le principe est que si le compte administrateur est renommé, un attaquant aura plus de difficultés à se connecter en tant que véritable administrateur. Bien entendu, le problème évident avec l'utilisation de la Stratégie de groupe pour cette opération est que le compte Administrateur renommé aura le même nom sur chaque ordinateur auquel cet objet de Stratégie de groupe aura été appliqué. Cela diminue la valeur d'obscurité de cette mesure de sécurité particulière.
Figure 1 Renommer le compte administrateur
Figure 1 Renommer le compte administrateur (Cliquez sur l'image pour l'agrandir)
Il est également important dans ce contexte de se rendre compte que tout utilisateur avec un compte légitime peut récupérer le nom du compte Administrateur, qu'il ait été renommé ou non. Le compte Administrateur possède le RID 500. En demandant simplement le nom du compte de RID 500, tout utilisateur doté d'un compte peut voir quel est son véritable nom, comme indiqué à la figure 2.
Figure 2 Recherche des comptes Administrateur renommés
Figure 2 Recherche des comptes Administrateur renommés (Cliquez sur l'image pour l'agrandir)

L'avis de Roger
L'argument principal que j'entends contre le changement de nom du compte Administrateur est qu'il est si facile de convertir n'importe quel nom de compte d'entité de sécurité en son identificateur de sécurité (SID) et de découvrir son RID. Le véritable compte Administrateur possède toujours le RID 500. Par conséquent, si un attaquant peut facilement convertir des noms de comptes d'utilisateur en combinaisons SID/RID pour trouver le RID 500, pourquoi s'embêter ?
Ce n'est pas si simple. Pour accomplir la traduction du nom du compte d'utilisateur en SID/RID, vous devez avoir accès aux ports NetBIOS ou LDAP. La plupart des pare-feu de périmètre n'autorisent pas ce type d'accès sur Internet et jusqu'à ce que l'attaquant contourne complètement le pare-feu, il ne pourra rien traduire. De plus, les traductions anonymes de SID ne fonctionnent pas sur Windows XP et versions ultérieures de Windows, sauf sur les contrôleurs de domaine (DC). Face aux ordinateurs les plus exposés à l'extérieur (qui courent le plus grand risque), l'attaquant nécessiterait des informations d'identification authentifiées pour effectuer la traduction nom vers SID.
Il existe donc un bon nombre de véritables barrières devant être contournées pour commencer une attaque de traduction. Même si l'attaquant parvenait aussi loin, il finirait au même endroit que si le nom de compte n'avait pas été renommé. Renommer le compte Administrateur peut seulement améliorer la sécurité. Il ne peut certainement pas l'endommager.
C'est un autre secret Si un attaquant ne connaît pas le nom du compte Administrateur, celui-ci devient une autre étiquette « secrète », similaire à un mot de passe, qu'un attaquant doit connaître. Je vous l'accorde, les noms de compte d'utilisateur sont probablement loin d'être aussi complexes qu'un mot de passe administratif, mais il s'agit toujours d'une entrave supplémentaire qui complique l'opération visant à deviner/décoder le mot de passe. Si vous avez fait des tests de pénétration de mot de passe, vous savez déjà à quel point deviner le nom d'utilisateur ainsi que le mot de passe représente davantage de travail. Ce travail complique une tâche déjà difficile.
Déjoue les logiciels malveillants automatisés et les scripteurs amateurs Je pratique la défense de sécurité Windows depuis maintenant 22 ans maintenant, et j'ai utilisé huit « pots de miel » Windows, exposés à Internet, au cours des 5 dernières années. Pendant tout ce temps, je n'ai jamais vu de logiciel malveillant automatisé (ce qui inclut la vaste majorité de toutes les attaques) utiliser un compte utilisateur quelconque, mis à part Administrateur (ou root, pour les systèmes *NIX). Si vous renommez votre compte Administrateur, vous arrêtez tout de suite tout logiciel malveillant reposant sur le nom d'administrateur. Cela se traduit par un risque réduit pour la sécurité.
Ceci est également vrai pour les scripteurs amateurs. Chaque manuel de piratage Windows branché que je connais mentionne les techniques de traduction de SID mais, pour une raison ou une autre, je n'ai pas vu un seul cas correspondant sur mes pots de miel, lorsque ceux-ci possédaient un « faux » compte administrateur pour les égarer. Les bons pirates informatiques devraient toujours vérifier que le compte administrateur qu'ils ont trouvé est le véritable Administrateur (RID 500), mais ils ne font pas. Je ne sais pas pourquoi. Pour moi, la culpabilité en revient à la paresse des pirates informatiques et au comportement humain habituel.
Ca arrête également la plupart des professionnels Ca étonne la plupart des gens. Lorsque vous avez utilisé des pots de miel pendant quelques années, vous reconnaissez rapidement la différence entre les attaques automatisées, les scripteurs amateurs et les professionnels. Au cours des cinq dernières années, avec des millions d'attaques enregistrées pour mes pots de miel, je n'ai jamais vu de professionnels faire la traduction de SID lorsqu'un faux compte Administrateur était présent.
Je suis sûr que certains criminels utilisent la traduction de SID, mais je suis prêt à parier qu'il s'agit d'une petite minorité, que je n'ai jamais rencontrée. Pourquoi les professionnels ne le feraient-ils pas ? J'imagine qu'ils ne voient pas l'intérêt de faire quelque chose lorsque la plupart des gens ne le font pas.
Simplifie les alertes Maintenant, l'autre camp pourrait objecter que si renommer le compte Administrateur devenait courant, cette opération perdrait de sa valeur en tant que technique d'obscurité. La justification est que les logiciels malveillants, les scripteurs amateurs et les professionnels modifieraient leurs tactiques par défaut pour rechercher des noms différents d'Administrateur. Il s'agit d'une inquiétude fondée. Heureusement, elle ne change rien à la condition essentielle. Premièrement, si le compte Windows aux superprivilèges n'est pas nommé Administrateur, le pirate informatique malveillant doit travailler plus dur. Ce n'est qu'un fait. Si le pirate informatique malveillant doit travailler plus dur, il est un peu moins probable qu'il essaiera ce vecteur d'attaque, permettant ainsi peut-être à une autre des techniques de blocage approfondies de détecter plus rapidement l'activité malveillante.
Ceci me mène à mon dernier point en faveur du changement de nom. Si votre compte administrateur n'est jamais appelé Administrateur et que vous créez un autre compte avec ce nom, comme indiqué à la figure 3, vous disposez d'un bon mécanisme d'alerte. Si votre interception d'événements détecte une ouverture de session tentée utilisant le nom par défaut, il s'agit d'un événement à explorer immédiatement.
Figure 3 Les tentatives d'ouverture de connexion avec un compte d'appât nommé Administrateur peuvent servir d'avertissement en amont
Figure 3 Les tentatives d'ouverture de connexion avec un compte d'appât nommé Administrateur peuvent servir d'avertissement en amont (Cliquez sur l'image pour l'agrandir)
Nos journaux des événements sont remplis de « mauvaises » ouvertures de session qui n'ont pas de signification. Généralement, il s'agit simplement d'un utilisateur (ou de Windows) qui essaie d'ouvrir une session en utilisant un mauvais mot de passe ou quelque chose de ce genre. Si votre compte administrateur est appelé Administrateur, cependant, comment pouvez-vous séparer facilement les bonnes tentatives d'ouverture de session de celles qui sont malveillantes ? Si vous n'avez jamais eu de compte d'ouverture de session appelé Administrateur et que vous détectez une tentative d'ouverture de session utilisant ce nom de compte, vous savez que son but est probablement malveillant. Un avertissement en amont avec peu d'écho a une grande valeur pour les défenses d'aujourd'hui.

Le point de vue de Jesper
Renommer le compte Administrateur par Aaron Margosis
Jesper, dans un monde idéal, vous auriez absolument raison. Les mots de passe devraient toujours être assez forts pour rendre impossible leur déduction par force brute et les comptes Administrateur locaux -500 ne seraient jamais utilisés pour la récupération d'urgence. Dans le monde réel, cependant, rien de ceci n'est vrai.
Malgré l'excellente promotion de la sécurité que vous avez effectuée, et en particulier la série d'articles sur les mots de passe que vous avez écrits, (« Les grands débats : Codes contre mots de passe », parties 1, 2 et 3, aux adresses go.microsoft.com/fwlink/?LinkId=113157 ; go.microsoft.com/fwlink/?LinkId=113159 et go.microsoft.com/fwlink/?LinkId=113160), de nombreux administrateurs système n'ont pas une compréhension à jour de ce que constitue un mot de passe fort.
Il n'y a pas si longtemps que les mots de passe composés de huit caractères aléatoires tirés de jeux de caractères multiples étaient forts. La loi de Moore a rendu ceci obsolète. La formation des utilisateurs (et des administrateurs système) est un maillon faible et le demeurera probablement, tout du moins jusqu'à ce que le débat des mots de passe devienne un sujet si important que les journaux télévisés commencent à en parler.
Par conséquent, étant donné que la déduction d'un mot de passe du monde réel ne nécessite pas aujourd'hui 600 milliards d'années mais peut souvent s'effectuer dans le temps nécessaire à un repas, ajoutez-y un facteur multiplicateur égal à 1 000 et vous obtiendrez la véritable valeur. Contre les nombreuses attaques automatisées qui essaient de marteler le compte nommé Administrateur, renommer le compte le rend invulnérable.
Le temps et l'effort qu'implique généralement le fait de renommer le compte administratif sont habituellement peu importants. De manière générale, comme vous l'avez remarqué, ils se réduisent à définir un simple paramètre de GPO. La recommandation de configuration d'ordinateur du bureau gouvernemental des États-Unis (csrc.nist.gov/fdcc), exige en fait de renommer le compte -500. Renommer ce compte n'est qu'un des nombreux paramètres requis et je ne l'ai jamais vu nécessiter une quantité démesurée de temps ou d'attention. Je n'ai jamais non plus vu qui que ce soit conforté dans une fausse impression de sécurité quant à sa valeur. Je n'ai encore jamais entendu qui que ce soit déclarer « Nous n'avons pas besoin de gestion des correctifs car nous avons renommé nos comptes Administrateur ».
Le changement de nom offre-t-il une valeur ajoutée quelconque lorsque le compte est renommé de manière équivalente dans toute l'entreprise ? Ce n'est pas une valeur ajoutée énorme, mais elle est toujours positive : premièrement, il bloque les attaques automatisées qui s'attendent à Administrateur, et deuxièmement, l'ensemble d'attaquants potentiels n'est pas nécessairement un sous-ensemble du « tout le monde » qui connaît le nouveau nom (le plus grand risque est celui lié au partage dans toute une entreprise du mot de passe par les comptes Administrateur local. L'administration de ceux-ci demeure le problème le plus conséquent et le plus important. Désactiver le compte -500 est une méthode permettant d'y répondre, mais ceci bloque une voie de récupération importante lorsque les comptes de domaine ne peuvent pas être utilisés). Je ferai également remarquer que nos guides sur la sécurité ont depuis longtemps recommandé de renommer les comptes par défaut et cette pratique a par conséquent été bien testée et est entièrement prise en charge.
Je pense que nous savons tous à présent que ces mesures d'obscurité (en soi) ne constituent pas une défense suffisante. Mais elles peuvent améliorer d'autres mesures de sécurité et les données de Roger le montrent tout à fait clairement. Du moment que les coûts de mise en œuvre sont bas, les entreprises ne devraient pas les négliger.

Comme pour les arguments en leur faveur, il existe des arguments valides à l'encontre du changement de nom du compte Administrateur. Avant d'y venir, cependant, je dois admettre que le dernier point soulevé par Roger est tout à fait valable. Cependant, dans un environnement extrêmement géré, n'importe quelle ouverture de session avec le compte Administrateur devrait être examinée car ce compte ne devrait jamais être utilisé sauf dans les situations de récupération d'urgence.
C'est superflu Le risque principal qu'est supposé atténuer le changement de nom du compte administrateur est le risque que quelqu'un devine son mot de passe à distance. Mais seul un utilisateur ne possédant pas d'autre compte autorisé sur l'ordinateur serait contrecarré par le changement de nom du compte Administrateur. Un tel attaquant essaierait généralement une série de mots de passe aléatoires pour ouvrir une session avec le compte Administrateur. Cependant, un tel attaquant recevrait le même message d'erreur, que le nom de compte qu'il essaie de deviner soit incorrect ou que le mot de passe soit incorrect.
Cela suggère qu'un des arguments principaux en faveur du changement de nom du compte administrateur (tenir à l'écart les scripteurs amateurs) ne tient pas debout. Ceux-ci ne sont pas plus tenus à l'écart lorsque le compte Administrateur est renommé que lorsqu'il a son nom d'origine car ils sont incapables de faire la différence ! Ils devineront le même ensemble de mots de passe aléatoires quoi qu'il en soit et passeront à leur victime potentielle suivante.
Ceci signifie que tant que le mot de passe du compte Administrateur est assez robuste pour repousser des attaques, renommer le compte n'offre aucun avantage supplémentaire. Imaginons que nous avons un mot de passe de 15 caractères pour notre compte Administrateur, composé de lettres majuscules et minuscules, de chiffres et de symboles choisis depuis l'ensemble du clavier. Deviner ce mot de passe sur le réseau prendra environ 591 310 404 907 années. Pour vous donner une idée, c'est approximativement 43 fois plus longtemps que l'existence de l'univers.
Imaginons maintenant que nous renommons le compte Administrateur et lui donnons une valeur parmi 1 000 valeurs possibles. Nous étendrions le temps nécessaire pour deviner le mot de passe à 591 310 404 906 787 années ou 43 161 fois plus longtemps que l'existence de l'univers. Sommes-nous plus sécurisés ? Bien entendu, nous le sommes, d'un ordre de grandeur trois fois supérieur. Avons-nous fait en sorte qu'il soit moins probable que l'utilisateur devine notre mot de passe ? Eh bien, cette probabilité est infiniment réduite dans les deux cas. En d'autres termes, en termes réalistes, nous sommes absolument dans la même situation qu'avec le nom de compte Administrateur d'origine. Renommer simplement le compte arrête les logiciels malveillants qui tentent de l'utiliser et ne signifie pas que ces logiciels malveillants auraient réussi si vous n'aviez pas renommé le compte. En fait, si vous utilisez un mot de passe fort, comme vous devriez le faire, vous pouvez pratiquement garantir qu'ils ne réussissent pas, quel que soit le nom du compte.
Il est évident que de nombreuses recommandations de sécurité exigent de renommer le compte Administrateur, mais cela n'en fait pas une mesure de sécurité de valeur et encore moins valide. Elles suppriment simplement votre capacité à prendre une décision de gestion des risques appropriée le concernant. Les guides sur la sécurité ont souvent exigé l'utilisation de paramètres n'offrant aucune différence et dans beaucoup de cas, de paramètres qui n'existent même pas. En fin de compte, pour progresser dans le domaine de la sécurité, nous devons aller au-delà des exigences, analyser véritablement les problèmes et évaluer si les atténuations ont un sens ou non. Il est important de se souvenir ici d'un point essentiel : le fait qu'un attaquant cible une fonctionnalité n'est, en soi, pas une raison suffisante pour modifier cette fonctionnalité. Vous devriez uniquement modifier une fonctionnalité si vous avez des raisons valables de croire qu'une attaque réussira à moins que vous ne modifiiez la fonctionnalité.
Si nous utilisons un mot de passe fort, la probabilité de succès est en pratique nulle, que le compte soit renommé ou non. Par conséquent, tant que vous disposez d'un mot de passe fort, vous n'avez pas de raison de sécurité particulière de renommer le compte. De plus, si, comme moi, vous partez du principe qu'un ordinateur sera probablement plus stable si vous lui apportez peu de réglages et de modifications (un fait bien confirmé, par ailleurs), il est d'autant plus justifié de ne pas renommer le compte Administrateur.
L'attention est déplacée sur des atténuations de faible valeur Un problème avec la sécurité à faible valeur ajoutée offerte par les atténuations d'obscurité est qu'elle risque de déplacer l'attention de l'organisation des atténuations de grande valeur ajoutée. Par exemple, le temps et les efforts mis en œuvre pour renommer le compte Administrateur ne peuvent pas être utilisés pour quelque chose d'autre. Si ce quelque chose d'autre offre une valeur ajoutée plus élevée que le changement de nom des comptes Administrateur, l'entreprise a perdu une opportunité. Ceci peut ne pas sembler un coût important, mais imaginez renommer 50 000 comptes administrateur et vous commencerez à avoir une idée.
Ce qui est pire est qu'il est très vraisemblable que la direction de l'organisation sera satisfaite une fois l'atténuation de basse valeur mise en place. L'administration de l'entreprise peut ne pas toujours comprendre la valeur minimale fournie par la sécurité par atténuations d'obscurité et ne pas mettre en œuvre des étapes supplémentaires. Ceci peut en fait poser un risque significatif pour l'organisation, bien que le risque soit tout à fait évitable si l'administration consacre simplement du temps et des efforts à la compréhension de la valeur des atténuations en cours de mise en œuvre.
Coûteuse à gérer Enfin, en fonction de la qualité de la mise en œuvre de l'atténuation, elle peut devenir coûteuse à gérer. Si vous définissez simplement un objet de Stratégie de groupe (GPO) pour renommer le compte Administrateur, le coût est très faible. Tout le monde connaîtra le nom et le coût de déploiement est presque nul. Cependant, la valeur fournie est également tout à fait minimale car, comme je l'ai dit, toute personne possédant un compte connaîtra le nom. Par conséquent, pour véritablement tirer une valeur importante de cette atténuation, vous devez utiliser des noms différents sur les différents hôtes et cela devient un système assez coûteux à gérer.
Il serait vraiment préférable d'utiliser un outil tel que passgen (protectyourwindowsnetwork.com/tools.htm) pour définir un mot de passe complètement aléatoire de 100 caractères sur tous les comptes Administrateur du réseau et utiliser à la place des comptes différents pour la gestion de tous les jours. En prenant en compte le fait que le compte Administrateur a vraiment pour objectif la récupération après incident (sauf sur Windows Small Business Server 2003), ceci ne doit pas avoir du tout d'impact sur votre système de gestion de réseau. Qui plus est, l'attaquant aurait une plus grande chance de trouver une aiguille dans une botte de foin que de deviner le mot de passe sur n'importe lequel de vos comptes Administrateur. En vous concentrant à la place sur des mots de passe forts et uniques, les scripteurs amateurs peuvent simplement continuer à essayer de deviner ce qu'ils veulent.

Tout est une affaire de gestion des risques
Pratiquement toute sécurité par mesure d'obscurité peut être analysée de la façon dont nous l'avons fait ici. Chaque approche a des avantages et des inconvénients et la bonne approche pour une organisation n'est pas nécessairement adaptée à une organisation différente. En fin de compte, ceci devient un problème de gestion des risques. Les risques sont-ils plus importants que les coûts d'implémentation de la solution ? Chaque décision que vous prenez pour la protection de vos informations doit être une décision de gestion des risques informée et est rarement un choix noir ou blanc.
Il est vrai que certaines décisions ont déjà été prises pour vous. Par exemple, même si vous pouvez très certainement choisir de ne pas chiffrer les informations de carte de crédit ou d'enregistrer les codes de vérification de carte de crédit, chacune de ces actions aura probablement pour résultat une perte de votre capacité à accepter des cartes de crédit comme forme de paiement. L'impact négatif probable de cette décision pour votre entreprise est tel que vous n'avez pas vraiment de choix. En d'autres termes, bien que ceci soit certainement une décision de gestion des risques, c'est une décision qui n'est pas facile à prendre.
De même, il est également vrai que personne de sensé ne connecterait un réseau sans fil ouvert à l'arrière du réseau local d'un magasin physique. Cependant, cela ne signifie pas que la décision ne soit pas une décision de gestion des risques. C'en est une. Il est possible de choisir de le faire et, si ce choix est effectué, les conséquences doivent en être assumées (ce qui ne semble jamais se produire, malheureusement).
La mesure essentielle à prendre ici est de clairement définir le problème auquel vous devez répondre, les solutions proposées pour ce problème et les avantages et inconvénients de chacune. Une fois que vous avez cela, vous avez les informations dont vous avez besoin pour prendre une décision informée de gestion des risques. Sans ces informations, vous prenez des décisions fondées sur un pressentiment et ce sont rarement de bonnes décisions.

Jesper M. Johansson est architecte de logiciels chargé des logiciels de sécurité et contribue à l’élaboration de TechNet Magazine. Titulaire d'un doctorat en gestion des systèmes d'information, il a plus de 20 ans d'expérience dans le domaine de la sécurité et est MVP Microsoft dans la sécurité d'entreprise. Son dernier ouvrage s'intitule Windows Server 2008 Security Resource Kit.
Roger Grimes (CPA, CISSP, MCSE sécurité), consultant senior en sécurité pour l'équipe ACE de Microsoft, a écrit ou contribué à huit livres sur la sécurité informatique et à plus de 200 articles de magazines. Il intervient régulièrement lors de conférences sur la sécurité et est chroniqueur de sécurité d'InfoWorld.
© 2008 Microsoft Corporation and CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable..


Sécurité
Nouveaux PowerToys d’élévation pour Windows Vista
Michael Murgolo
Vue d'ensemble:
  • Exécuter en tant qu'administrateur pour outils de script de fournisseurs tiers
  • Exécuter en tant qu'utilisateur différent
  • Invite de commande en tant que système et Invite PowerShell en tant que système
  • Gadget d'élévation glisser-déplacer
Télécharger le code de cet article: Elevation2008_06.exe (197KB)

Bienvenue dans cette nouvelle édition des PowerToys d'élévation pour Windows Vista. J'ai examiné tout cela en détail dans le numéro de juin 2007 de TechNet Magazine. Nous voici un an plus tard. A cette occasion, je voudrais vous expliquer comment j'ai étendu la fonction Exécuter en tant qu'administrateur à certains
de mes outils de script de fournisseurs tiers préférés, comment vous pouvez remplacer une fonction pratique de Windows® XP supprimée dans Windows Vista® et examiner certains des outils utiles inclus dans les PowerToys d'élévation.

Exécuter en tant qu'administrateur pour outils de script supplémentaires
Dans l'article précédent (disponible sur technet.microsoft.com/magazine/cc162321.aspx), j'abordais notamment la question de l'activation de l'option Exécuter en tant qu'administrateur pour les outils de script Windows natifs. Pour cet article, j'ai créé des PowerToys Exécuter en tant qu'administrateur pour certains outils de script de fournisseurs tiers :
  • AutoIt v3 (www.hiddensoft.com)
  • AutoHotkey (www.autohotkey.com)
  • ActivePerl (www.activestate.com)
  • KiXtart 2010 (www.kixtart.org)
Le code de chacun d'eux est inclus dans le téléchargement de cet article, disponible sur technetmagazine com. Les fichiers sont respectivement nommés ElevateAutoIt3.inf, ElevateAutoHotKey.inf, ElevatePerlScript.inf et ElevateKiXtart.inf. Pour AutoIt v3, AutoHotkey et ActivePerl, la configuration est très simple. Il suffit de télécharger l'application correspondante et de l'installer à l'emplacement par défaut. Après voir installé les applications qui vous intéressent, vous pouvez simplement installer le PowerToy Exécuter en tant qu'administrateur approprié pour chaque outil.
Malheureusement, KiXtart 2010 ne comprend pas de programme d'installation. Donc, pour m'assurer que KiXtart est installé à un emplacement standard permettant à mon PowerToy de fonctionner correctement, j'ai fourni un fichier INF qui installe KiXtart 2010 (v 4.60) sous Program Files\KiXtart et inscrit l'extension de fichier .kix.
Accédez à www.kixtart.org/?p=downloads, téléchargez le fichier KiX2010_460.zip et décompressez-le dans un dossier. Copiez le fichier Install_KiXtart.inf (inclus dans le téléchargement de code qui accompagne cet article) dans ce même dossier. Cliquez ensuite avec le bouton droit de la souris sur Install_KiXtart.inf et sélectionnez Install (Installer). Après cela, vous pouvez simplement installer le PowerToy ElevateKiXtart.inf.

PowerToy Exécuter en tant qu'utilisateur différent
Le contrôle de compte d'utilisateur (UAC) a été créé pour rendre le système d'exploitation moins vulnérable aux logiciels malveillants en obligeant les utilisateurs, même les administrateurs, à exécuter la plupart des applications avec des privilèges utilisateur standard. L'UAC offre un potentiel d'élévation pour les tâches administratives et d'autres fonctions d'application. Ce potentiel d'élévation est fourni via l'option Exécuter en tant qu'administrateur, à laquelle vous accédez en cliquant avec le bouton droit de la souris sur des fichiers exécutables. Les PowerToys d'élévation examinés dans le numéro de juin 2007 étendaient cette capacité à d'autres types de fichier et d'objet.
La fonctionnalité intégrée dans Windows Vista fonctionne relativement bien pour de nombreuses tâches administratives. Cependant, un scénario important a été omis pour Windows Vista. Dans beaucoup de services informatiques, les administrateurs réseau utilisent un compte utilisateur pour leurs tâches quotidiennes (messagerie électronique, création de documents, etc.) et un autre uniquement pour l'administration réseau (ou l'administration informatique locale).
Ceci afin de contribuer à réduire le risque qu'un administrateur réseau compromette tout son système (ou le domaine dans lequel il se trouve) en exécutant accidentellement un logiciel malveillant lors de ses tâches quotidiennes. C'était possible sous Windows XP grâce à l'option de clic-droit Exécuter... Mais cette option a disparu de Windows Vista, où elle a été remplacée par l'option Exécuter en tant qu'administrateur.
L'outil de ligne de commande runas, cependant, existe toujours dans Windows Vista. Malheureusement, il ne peut pas être utilisé pour les tâches de compte double les plus courantes (exécution de composants logiciels enfichables de la console MMC (Microsoft® Management Console)). Par exemple, imaginons que l'on vous a délégué certaines tâches de gestion de compte dans Active Directory®. Vous travaillez en tant qu'utilisateur standard pour les tâches quotidiennes et votre compte d'administration réseau est également membre du groupe d'administrateurs locaux (afin que vous puissiez installer les outils de gestion de réseau si nécessaire) sur un ordinateur Windows Vista où UAC est activé. Vous voulez à présent démarrer des utilisateurs &ordinateurs Active Directory (ADU&C) avec votre compte administrateur Active Directory. Vous essayez donc la commande runas, comme suit :
runas /user:mydomain\admin
"mmc.exe %windir%\system32\dsa.msc"
Malheureusement, cela ne lance pas l'ADU&C. Au lieu de cela, vous recevez l'erreur runas suivante : « L'opération demandée nécessite une élévation ». Ce qui se passe dans ce cas, c'est que l'exécutable MMC est marqué pour s'exécuter au niveau de privilège highestAvailable. Puisque le niveau highestAvailable pour votre compte d'administration réseau est celui d'administrateur, lancer l'ADU&de cette manière nécessite une élévation. Puisque runas ne génère pas d'invite d'élévation, l'erreur se produit.
Windows Vista complique donc ce scénario en ne fournissant pas d'élément de menu contextuel pour Exécuter... et en ne proposant pas de moyens intégrés d'exécuter un processus en tant qu'utilisateur différent nécessitant une élévation.
Le sujet serait frustrant s'il n'y avait pas de solution, mais heureusement, un de mes PowerToys d'élévation originaux résout le deuxième problème, tandis que j'ai déniché une solution au premier. (Je voudrais pouvoir affirmer avoir trouvé la solution au problème d'élévation, mais cet honneur revient à Gov Maharaj de l'équipe Windows AppCompat).
Il apparaît que le PowerToy de commande d’élévation peut être utilisé avec la commande runas. Là où la commande précédente ne produisait pas d'invite d'élévation, celle-ci le fera :
runas /user:mydomain\admin
"elevate mmc.exe%windir%\system32\dsa.msc"
Elle pousse runas à lancer elevate.cmd (techniquement, le processus lancé est cmd.exe) en tant qu'utilisateur différent, tandis que la commande d'élévation lance mmc.exe avec une invite d'élévation.
Finalement, j'ai pris cette astuce, l'ai combinée avec des associations de fichiers pour .exe et .msc et l'ai intégrée à une interface utilisateur d'application HTML pour produire un PowerToy créant une option Exécuter en tant qu'utilisateur différent disponible via le menu contextuel. Lorsque vous sélectionnez Exécuter en tant qu'utilisateur différent, vous obtenez une application HTML semblable à celle de la figure 1.
Figure 1 Outil Exécuter en tant qu'utilisateur différent
Figure 1 Outil Exécuter en tant qu'utilisateur différent (Cliquez sur l'image pour l'agrandir)
Saisissez simplement le nom d'utilisateur et le domaine (pour un compte sur l'ordinateur local, cochez la case Use Local Account (Utiliser compte local)). Cliquez ensuite sur le bouton Exécuter pour lancer l'application comme un utilisateur standard. Vous pouvez également cliquer sur le bouton Run as Admin (Travailler en tant qu'administrateur) pour lancer l'application avec des privilèges élevés. Après avoir cliqué sur un de ces deux boutons, runas.exe s'exécute et vous demande un mot de passe ou un code confidentiel de carte à puce.
Comme ce PowerToy utilise le PowerToy de commande d'élévation, vous devez d'abord installer ce dernier. Cliquez ensuite avec le bouton droit de la souris sur le fichier RunAs.inf, sélectionnez Install (Installer) et acceptez l'élévation. Pour désinstaller l'outil, utilisez l'option Programmes et fonctionnalités du Panneau de configuration.
Vous constaterez que certains des raccourcis vers les fichiers .msc dans les Outils d'administration (comme la Gestion de l'ordinateur) fonctionnent avec ce PowerToy. Notez toutefois que si vous installez les outils d'administration Windows Server® 2003 avec adminpak.msi, les raccourcis créés ne sont pas des raccourcis standard vers les fichiers .msc. Il s'agit au contraire de raccourcis Windows Installer. Dès lors, l'Explorateur Windows n'affichera pas l'option Exécuter en tant qu'utilisateur différent pour ces raccourcis.
Pour ces derniers, vous devrez chercher les fichiers .msc et cliquez dessus avec le bouton droit de la souris ou créer de nouveaux raccourcis vers ces fichiers. De plus, runas ne fonctionne pas avec Internet Explorer® à cause de la façon dont celui-ci a été restructuré en mode protégé sous Windows Vista (vous pouvez trouver des informations supplémentaires sur ce problème sur support.microsoft.com/?id=922980).
Remarque : entre le moment où j'ai terminé ces PowerToys et la parution de cet article, Windows Sysinternals a publié un nouvel outil très semblable du point de vue fonctionnel à mon PowerToy Exécuter en tant qu'utilisateur différent. Cet outil s'appelle ShellRunas et est disponible sur le site Windows Sysinternals : technet.microsoft.com/sysinternals/cc300361.
Etant donné que c'est le métier des spécialistes de Sysinternals d'écrire du code, vous pouvez préférer leur outil. J'ai décidé de laisser le mien dans l'article en tant qu'exemple de la manière dont cette tâche en particulier et les extensions de shell en général peuvent être effectuées à l'aide d'applications HTML avec du code de script.

Invite de commande en tant que système et Invite PowerShell en tant que système
Il est parfois nécessaire d'exécuter des programmes dans un contexte de Système local. Par exemple, de nombreux outils de distribution de logiciel, comme System Center Configuration Manager (SCCM), utilisent un agent de client qui s'exécute en tant que système local pour accomplir ses tâches.
Pour tester le comportement d'un programme d'installation de logiciel s'exécutant en tant que système local avant de tenter une distribution avec un produit comme SCCM, il peut être utile de démarrer le programme d'installation à l'aide d'une invite de commande s'exécutant en tant que système local. J'ai donc commencé par créer mes PowerToys Invite de commande en tant que système et Invite PowerShell en tant que système.
Sous Windows XP, j'avais pour habitude de procéder avec un script d'interface de commande :
@echo off
sc create CmdAsSystem type= own type= interact
binPath= "cmd /c start cmd /k (cd c:\ ^& color ec ^&
title ***** SYSTEM *****)"
net start CmdAsSystem
sc delete CmdAsSystem
Cependant, si vous essayez d'exécuter à partir d'une invite de commande élevée sous Windows Vista, vous obtenez le message d'erreur suivant et l'invite de commande d'exécution en tant que système ne s'affiche pas :
AVERTISSEMENT : le service CmdAsSystem est configuré comme étant interactif et sa prise en charge est en cours de retrait. Il est possible que le service ne fonctionne pas correctement.
Le problème, c'est que ce script essaie de créer et de démarrer un service interactif. Les services interactifs ne fonctionnent pas correctement en raison de l'isolation de la session 0 sous Windows Vista. (Pour une explication de l'isolation de la session 0, voir le livre blanc « Services sous Windows Vista » sur microsoft.com/whdc/system/vista/Vista_Services.mspx).
Pour contourner cette restriction, j'ai utilisé l'outil Psexec développé par Sysinternals (voir technet.microsoft.com/sysinternals/bb897553.aspx). Cet outil permet de démarrer des processus dans le contexte Système. Malheureusement, la plupart des outils de Sysinternals ne comprennent pas de programme d'installation. J'ai donc fourni un fichier NF (disponible dans le téléchargement de code) pour installer la Suite Sysinternals complète (qui comprend Psexec) dans Program Files\Sysinternals Suite. Avantage supplémentaire, ce fichier INF crée des raccourcis de menu Démarrer pour les outils graphiques de la suite.
Pour installer la suite, téléchargez tout d'abord le fichier SysinternalsSuite.zip à l'adresse technet.microsoft.com/sysinternals/bb842062.aspx et décompressez-le dans un dossier. Copiez mon fichier INF (Install_SysinternalsSuite.inf) dans ce dossier, cliquez avec le bouton droit sur Install_SysinternalsSuite.inf, puis sélectionnez Installer. Puisque ces nouveaux PowerToys utilisent le PowerToy de commande d'élévation, installez ce dernier. Ensuite, vous pouvez installer CmdHereAsSystem.inf et PowerShellHereAsSystem.inf. Une fois ces PowerToys installés, les options Invite de commande en tant que système et Invite PowerShell en tant que système seront disponibles sous forme d'éléments de menu contextuel pour les dossiers et les lecteurs dans l'Explorateur Windows, comme vous pouvez le voir à la figure 2.
Figure 2 Options Invite de commande en tant que système et Invite PowerShell en tant que système
Figure 2 Options Invite de commande en tant que système et Invite PowerShell en tant que système
La figure 3 illustre une invite de commande s'exécutant en tant que système. J'ai sélectionné les couleurs brillantes pour rappeler que cette invite s'exécute en tant que Système et peut influencer le système de manière imprévue (et dommageable) si vous saisissez des commandes incorrectes.
Figure 3 L'option Invite de commande en tant que système doit donc être utilisée avec précaution.
Figure 3 L'option Invite de commande en tant que système doit donc être utilisée avec précaution.
Enfin, ces PowerToys ajoutent des commandes au système pour que ces invites puissent être démarrées dans la boîte de dialogue Exécuter ou une invite de commande. Par exemple, l'exécution de la commande suivante à partir de la boîte Exécuter démarrera une Invite de commande en tant que système dans le dossier Windows :
cmdassystem "c:\windows"
La commande équivalente pour Windows PowerShellTM est psassystem. Notez que j'ai également modifié les PowerToys Invite de commande en tant qu'administrateur et Invite PowerShell en tant qu'administrateur pour installer des commandes similaires (respectivement cmdasadmin et psasadmin).

Gadget d'élévation
La plupart de mes PowerToys nécessitent un clic-droit de la souris. Mais, cerise sur le gâteau pour cette mise à jour, j'ai inclus quelque chose d'un peu plus amusant. Il s'agit d'un gadget pour le volet Windows, que j'appelle Gadget d'élévation (voir figure 4). Il s'agit d'une cible de glisser-déplacer. Déplacez simplement un exécutable ou un script de l'Explorateur Windows doté d'une action runas définie et il démarrera en tant qu'élevé.
Figure 4 Gadget d'élévation glisser-déplacer
Figure 4 Gadget d'élévation glisser-déplacer
Si vous avez installé mes précédents PowerToys d'élévation, cela fonctionnera pour les scripts Windows Script Host, les scripts Windows PowerShell, les applications HTML et les packages et correctifs Windows Installer (de même que les exécutables et les scripts d'interface de commande qui ont une action runas définie par défaut dans Windows Vista). Vous pouvez également glisser plusieurs éléments à la fois. (Essayez de glisser un dossier dans le gadget et voyez ce qui se passe).
Pour installer le gadget, double-cliquez sur Elevation.Gadget (disponible dans le téléchargement de code). Si vous souhaitez voir le code du gadget, ajoutez simplement l'extension .cab au nom du fichier. Vous pouvez alors extraire le contenu du fichier Cab.

Conclusion
Le téléchargement associé à cet article contient les nouveaux PowerToys et ceux de l'article original. J'ai apporté des modifications mineures à certains des anciens. Par exemple, les versions originales de l'Invite PowerShell en tant qu'administrateur et Élever le script WSH installaient toutes deux leurs propres copies d'elevate.cmd et elevate.vbs. Comme plusieurs des nouveaux PowerToys dépendent également de ces fichiers, j'ai modifié ces outils pour que le PowerToy de commande d'élévation doive être installé (et que cette copie puisse être partagée). Pour déterminer si un PowerToy nécessite l'installation du PowerToy de commande d'élévation, vérifiez l'en-tête dans le fichier INF.
Certains autres PowerToys originaux ont également subi des modifications non fonctionnelles mineures. Désinstallez toujours l'ancienne version d'un PowerToy avant d'installer la nouvelle. Puisque cette collection comprend désormais 17 outils, j'ai inclus des scripts d'interface de commande permettant d'installer et de désinstaller toute la collection (respectivement InstallAllPowerToys.cmd et UninstallAllPowerToys.cmd). Vous pouvez les personnaliser pour seulement installer et désinstaller les outils dont vous avez besoin.
N'oubliez pas qu'InstallAllPowerToys.cmd n'installe pas les PowerToys Exécuter en tant qu'administrateur pour les outils de script de fournisseurs tiers par défaut. Vous pouvez modifier ce script afin d'installer seulement les PowerToys pour lesquels vous avez installé le logiciel. Lorsque vous exécutez l'un d'eux, il se relance lui-même en tant qu'élevé. UninstallAllPowerToys.cmd doit également supprimer toutes les anciennes versions de ces outils.
Comme pour tous mes PowerToys, ceux-ci sont des outils à « utiliser à vos propres risques », non pris en charge. Il ne s'agit pas de produits Microsoft officiels, mais de mes propres créations personnelles. Elles ont uniquement été testées par moi-même et quelques autres volontaires sur Windows Vista 32 bits avec US English comme langue par défaut. Enfin, il est possible qu'un ou tous ces PowerToys ne puissent pas fonctionner avec les futurs Services Packs, mises à jour ou versions de système d'exploitation de Windows.

Michael Murgolo est consultant en infrastructure senior pour Microsoft Consulting Services. Il se concentre sur les systèmes d’exploitation, le déploiement, les services réseau, Active Directory, la gestion des systèmes, l’automatisation et la gestion des correctifs. Il est expert dans le domaine du déploiement et de la migration des postes de travail.


Sécurité
Avancées dans le domaine du chiffrement de lecteur BitLocker
Byron Hynes
Vue d'ensemble:
  • Améliorations de BitLocker
  • Installation de BitLocker
  • Utilisation de BitLocker sur un serveur
  • Considérations sur la protection totale des données

Dans le numéro de l'année dernière de TechNet Magazine sur la sécurité, je donnais un aperçu des fonctionnalités du chiffrement de lecteur BitLocker de Windows pour montrer comment il était implémenté dans la version initiale de Windows Vista. Maintenant, avec la publication du Service Pack 1 pour
Windows Vista® et le nouveau système d'exploitation Windows Server® 2008, l'heure est venue de revisiter BitLocker®.
Dans cet article, j'examinerai certaines des modifications de la dernière version, je donnerai un aperçu de l'installation et de l'utilisation de BitLocker sur un serveur et j'aborderai certains aspects ayant fait l'objet d'articles récents à prendre en considération. Si vous souhaitez lire l'article de l'année dernière, intitulé « Protection des données avec BitLocker Drive Encryption », allez à l'adresse technet.microsoft.com/magazine/cc138009.aspx.)

Nouveautés
Les modifications introduites dans cette version de BitLocker apportent plus de flexibilité sans changer les opérations de base. Les modifications que j'examinerai sont la prise en charge des volumes de données, l'autorisation de l'authentification à trois facteurs pour l'accès aux ordinateurs, la prise en charge de la spécification UEFI (Unified Extensible Firmware Interface), le nouveau microprogramme normalisé pour systèmes 64 bits, la protection améliorée contre les attaques cryptographiques sur les métadonnées de volume et l'utilisation augmentée de la spécification TPM (Trusted Platform Module).

Volumes de données
Dans la première publication de Windows Vista, le Panneau de configuration de BitLocker vous autorisait seulement à activer le chiffrement pour le volume du système d'exploitation Windows® (généralement le lecteur C: ). Pour beaucoup de consommateurs, ceci était tout à fait adéquat, puisque dans la plupart des ordinateurs, toutes les données de l'utilisateur et les programmes sont enregistrés sur le même volume que le système d'exploitation. Dans les entreprises, cependant, et certainement sur les serveurs, ce n'est pas souvent le cas. En conséquence, l'une des requêtes les plus courantes que nous recevons des utilisateurs est la capacité à chiffrer des volumes de données, c'est-à-dire des volumes autres que le volume du système d'exploitation, qui sont installés sur l'ordinateur (notez que BitLocker n'est pas conçu pour chiffrer des supports amovibles).
Comme vous pouvez le voir dans la figure 1, je dispose de trois volumes utilisables sur cet ordinateur (en réalité, j'en ai quatre si vous incluez la petite partition active utilisée pour le démarrage). Mon système d'exploitation est installé sur le lecteur C: (indiqué par l'indicateur Windows) et deux volumes de données sont également présents, E: et P:. Le volume P: a été déjà chiffré avec BitLocker et est actuellement verrouillé. Le volume E: n'est pas encore chiffré. Dans Windows Vista SP1 et Windows Server 2008, je peux chiffrer et déverrouiller ces volumes de données à partir de l'applet de Panneau de configuration de BitLocker.
Figure 1 Interface de BitLocker
Figure 1 Interface de BitLocker (Cliquez sur l'image pour l'agrandir)
Si votre volume de système d'exploitation est chiffré avec BitLocker, le comportement par défaut définit que les volumes de données chiffrés sont déverrouillés lorsque le volume de système d'exploitation est déverrouillé. Si vous utilisez le Panneau de configuration pour déverrouiller un volume de données, vous pouvez voir cette option sous forme de case à cocher, comme illustré à la figure 2.
Figure 2 Enregistrement de clés pour autounlock
Figure 2 Enregistrement de clés pour autounlock (Cliquez sur l'image pour l'agrandir)
Pour activer ou désactiver un « autounlock » d'un volume de données, utilisez l'outil de ligne de commande manage-bde.wsf. manage-bde.wsf est un script puissant inclus avec Windows qui utilise les fournisseurs de WMI (Windows Management Instrumentation) sous-jacents installés avec BitLocker.
Par exemple, pour marquer le volume de données P: de façon à ce qu'il doive être manuellement déverrouillé, utilisez la commande suivante :
manage-bde.wsf –autounlock –disable P:
Pour réactiver autounlock pour P:, utilisez :
manage-bde.wsf –autounlock –enable P:
Le Panneau de configuration de BitLocker n'indique pas tout ce que vous pouvez faire avec BitLocker et les volumes de données. Utilisez l'option -? pour explorer les commandes manage-bde.wsf. La syntaxe de manage-bde.wsf est également incluse dans le « Guide de conception du chiffrement de lecteur Windows BitLocker » et le « Guide de déploiement de Windows BitLocker » qui sont disponibles sur le centre de téléchargement Microsoft à l'adresse go.microsoft.com/fwlink/?LinkId=115215.

TPM + USB + PIN
Les clients veulent généralement aussi pouvoir utiliser également des facteurs d'authentification supplémentaires avec BitLocker. BitLocker utilise le processeur TPM de votre ordinateur pour vérifier l'intégrité de la plate-forme, en d'autres termes, pour déterminer que les premiers composants de démarrage, y compris le BIOS, n'ont pas été altérés ni corrompus. Cependant, depuis la publication de Windows Vista, vous pouvez également maintenant demander un PIN ou la présence d'un lecteur flash USB contenant une clé créée au moment où vous avez activé BitLocker.
Avec Windows Server 2008 et Windows Vista SP1, vous pouvez maintenant combiner les trois. Le TPM continue à vérifier l'intégrité de la plate-forme, la clé USB représente « ce que vous avez » et le PIN représente « ce que vous savez ». Cette configuration fournit une protection très puissante qui empêche les utilisateurs non autorisés de démarrer l'ordinateur et de déverrouiller les disques protégés par BitLocker.
Comme c'est souvent le cas avec la sécurité, cela représente un compromis. Il est évident que lorsque BitLocker est configuré de cette façon, un ordinateur ne peut pas redémarrer automatiquement. Dans le cas d'un serveur, par exemple, vous devez décider ce qui est le plus important : un redémarrage automatique ou des niveaux de protection plus élevés.

Prise en charge d'UEFI
Avec Windows Server 2008 et Windows Vista SP1, une prise en charge a été également ajoutée pour les ordinateurs équipés d'UEFI (Unified Extensible Firmware Interface). UEFI est une spécification qui constitue une modernisation du BIOS traditionnel utilisé par la plupart des ordinateurs au démarrage. Pour plus d'informations sur la spécification UEFI, consultez le site Web www.uefi.org.

Protection renforcée
Lorsque BitLocker détecte que le système a été modifié, ou si un PIN requis ou une clé USB n'est pas disponible au démarrage, BitLocker entre en mode de récupération. Dans ce mode, les volumes activés par BitLocker restent verrouillés et une boîte de dialogue en mode texte appelée Console de récupération est présentée à l'utilisateur.
Pour déverrouiller le lecteur, l'utilisateur doit entrer un mot de passe de récupération (numéro à 48 chiffres) sur le clavier ou à partir d'un lecteur flash USB. Lorsque le mot de passe est enregistré sur un lecteur flash USB, il est quelquefois appelé clé de récupération, parce qu'il s'agit d'un format binaire et non texte.
BitLocker utilise le mot de passe de récupération pour déchiffrer les clés enregistrées dans les métadonnées de volume (clé VMK (Volume Master Key) et clé FVEK (Full Volume Encryption Key)) pour déverrouiller le lecteur. Pour que la récupération réussisse, une copie du mot de passe de récupération doit être disponible.
Pour cette raison, je recommande qu'en plus du stockage du mot de passe par l'utilisateur (comme sur un lecteur flash USB), vous enregistriez également le mot de passe de récupération de façon centralisée. Le système d'exploitation inclut la fonctionnalité d'enregistrement des mots de passe de récupération dans Active Directory® Domain Services (ADDS).
Les secrets enregistrés dans les métadonnées de volume, comme le VMK, sont chiffrés et l'intégrité des métadonnées de volume est cryptographiquement protégée. Si BitLocker détecte que les métadonnées de volume ont été altérées, il refuse d'utiliser les métadonnées et ne déverrouille pas les volumes protégés. Notez que le mot de passe de récupération ne peut pas déverrouiller seul un lecteur dans cet état.
Il est important de faire remarquer que cette situation survient seulement lors d'une attaque de sécurité intentionnelle contre l'ordinateur. Si c'est le cas, il y a de bonnes chances que votre ordinateur soit déjà entre les mains d'un utilisateur malveillant et hors de votre contrôle. Cette situation ne résulte pas simplement d'une modification imprévue de la plate-forme ou de l'oubli de votre PIN.
Pour déverrouiller le volume, vous avez besoin des trois éléments suivants :
  • le mot de passe de récupération (comme du texte à taper sur ou dans un lecteur flash USB)
  • le package de clé binaire qui inclut des versions chiffrées de FVEK et VMK
  • l'outil de réparation de BitLocker
Bref, vous devez vous assurer que votre entreprise a toujours accès à tous ces éléments.
Le mot de passe de récupération peut être manuellement ou automatiquement sauvegardé. Je recommande d'utiliser le paramètre de Stratégie de groupe pour sauvegarder automatiquement le mot de passe de récupération dans Active Directory Domain Services.
Lorsque vous configurez ce paramètre, comme le montre la figure 3, incluez l'option de sauvegarde du package de clé binaire. Le package de clé binaire inclut des versions chiffrées de VMK et FVEK, qui vous permettent d'utiliser l'outil de réparation BitLocker, si nécessaire.
Figure 3 Configuration de la stratégie de groupe pour inclure les packages de clé dans les informations de récupération
Figure 3 Configuration de la stratégie de groupe pour inclure les packages de clé dans les informations de récupération (Cliquez sur l'image pour l'agrandir)
L'outil de réparation de BitLocker a été conçu pour vous aider à récupérer des données des disques endommagés qui sont activés par BitLocker. Notez qu'il s'agit d'un outil avancé, destiné aux administrateurs expérimentés. Pour plus d'informations sur l'outil de réparation de BitLocker, lisez l'article de la base de connaissances de Microsoft, à l'adresse support.microsoft.com/kb/928201 ou regardez mon webcast « Microsoft BitLocker en entreprise: outils BitLocker Tools pour vous faciliter la vie » (qui inclut une démonstration en directe), à l'adresse go.microsoft.com/fwlink/?LinkId=114985.
J'en profite pour indiquer que BitLocker ne remplace pas la nécessité de sauvegarder vos données. Si votre disque est endommagé ou a été délibérément attaqué, il n'y a pas de certitude que l'outil de réparation de BitLocker pourra récupérer une partie des données, encore moins toutes les données.

Utilisation augmentée de TPM
Techniquement, il ne s'agit pas d'une modification de BitLocker, mais cela vaut tout de même la peine d'être mentionné. Avant SP1, la seule partie du système d'exploitation de Windows qui utilisait TPM était BitLocker. TPM est maintenant également utilisé pour d'autres fonctions. En premier lieu, lorsque Windows voit qu'un TPM est disponible, il utilise le TPM comme source d'entropie augmentée lors de la génération de nombres aléatoires. Ceci améliore la qualité de tous les types de chiffrement (voire la qualité de vos jeux).
Cependant, cela signifie également que tous les événements liés à TPM affichés dans l'Observateur d'événements ne sont pas nécessairement liés à BitLocker. En tant que professionnel de l'informatique, il est utile de savoir que d'autres composants système (et potentiellement des logiciels d'autres fournisseurs) peuvent utiliser le TPM et par conséquent provoquer la consignation d'événements.

BitLocker dans Windows Server 2008
En raison du codebase partagé entre Windows Vista et Windows Server 2008, les changements apportés à BitLocker dans SP1 font partie intégrante de Windows Server 2008. Mais pourquoi utiliser BitLocker sur un serveur ? Après tout, BitLocker est conçu pour protéger un ordinateur des attaques hors ligne. En d'autres termes, BitLocker n'offre pas de protection à un système en cours d'exécution et les serveurs sont, bien sûr, toujours en cours d'exécution.
Il se trouve qu'il y a des occasions où un serveur, ou un disque dur d'un serveur, peut être exposé à une attaque hors ligne. Même si cela n'arrive jamais, BitLocker peut offrir une aide considérable au moment de mettre hors service un serveur ou un disque dur, comme nous le verrons. Voyons tout d'abord comment installer et exécuter BitLocker sur un serveur.

Installation de BitLocker
BitLocker est inclus dans toutes les éditions de Windows Server 2008, mais c'est un composant ou une fonctionnalité facultative qui doit être installé à partir du Gestionnaire de serveur ou de la ligne de commande. BitLocker est implémenté, partiellement, comme un pilote de filtre NTFS. L'installation de ce pilote de filtre nécessite un redémarrage de l'ordinateur. Sachez donc que l'activation de BitLocker sur un serveur nécessite un redémarrage. En outre, tout comme avec Windows Vista, BitLocker nécessite une configuration à charge répartie, où la partition active utilisée pour démarrer l'ordinateur reste non chiffrée. L'outil de préparation de lecteur de BitLocker peut vous aider à configurer correctement vos disques durs pour prendre en charge BitLocker si le serveur n'est pas préconfiguré par le fabricant. Si vous avez l'expérience du partitionnement de disque dur, cependant, vous pouvez configurer les disques durs manuellement.
Pour installer BitLocker dans Windows Server 2008, vous pouvez utiliser l'interface graphique du Gestionnaire de serveur pour sélectionner BitLocker dans la liste de fonctionnalités, comme illustré à la figure 4, ou vous pouvez utiliser l'interface de ligne de commande du Gestionnaire de serveur, en émettant la commande :
Figure 4 Sélection de BitLocker dans le Gestionnaire de serveur
Figure 4 Sélection de BitLocker dans le Gestionnaire de serveur (Cliquez sur l'image pour l'agrandir)
ServerManagerCmd –install BitLocker –restart
Lorsque vous utilisez le Gestionnaire de serveur, celui-ci installe BitLocker et les outils de gestion pour BitLocker. Vous pouvez également installer les composants de gestion sans installer BitLocker. Ceci vous évite d'avoir à effectuer un redémarrage puisque le pilote de filtre n'est pas inclus. Le nom de ce composant est « RSAT-BitLocker. »
BitLocker fonctionne parfaitement sur les ordinateurs exécutant l'option d'installation Server Core, mais vous ne pouvez pas utiliser le Gestionnaire de serveur pour installer BitLocker sur Server Core ni utiliser l'interface utilisateur graphique pour gérer BitLocker sur Server Core. Pour installer les composants, utilisez plutôt les outils de ligne de commande pkgmgr ou ocsetup.
Une fois que vous avez installé les binaires BitLocker et que vos disques sont configurés dans la configuration à charge répartie requise, vous pouvez activer BitLocker sur le volume du système d'exploitation. L'applet de Panneau de configuration de BitLocker a les mêmes icônes et les mêmes options dans Windows Server 2008 que dans Windows Vista SP1. Pour activer les modes avancés de BitLocker, vous devez régler les paramètres par défaut à l'aide de l'Éditeur de stratégie de groupe locale ou d'un objet de stratégie de groupe qui s'applique au serveur.
Sur Server Core, ou si vous ne voulez pas utiliser le Panneau de configuration, vous pouvez utiliser manage-bde.wsf pour activer BitLocker. Pour activer BitLocker sur le lecteur C:, tapez :
manage-bde.wsf –on C: -RecoveryPassword –RecoveryKey F:\
où C: est le volume à chiffrer et F:\ est une clé USB ou un autre volume où une copie de la clé de récupération sera enregistrée (en format binaire). Vous pouvez utiliser également un chemin UNC pour enregistrer la clé de récupération sur un lecteur de réseau. Un mot de passe de récupération (au format de texte numérique) est également généré et affiché. Vous pouvez ajouter le paramètre –skiphardwaretest si vous êtes certain que la plate-forme matérielle répond à toutes les exigences de BitLocker. Ceci enregistre un redémarrage.

Scénarios serveur
Voyons maintenant certains scénarios spécifiques où BitLocker est utile pour les serveurs. N'oubliez pas que, comme je l'ai déjà mentionné, BitLocker est conçu pour vous aider à vous protéger contre les attaques hors ligne, c'est-à-dire le type d'attaques effectuées lorsque Windows n'est pas en cours d'exécution.
Succursales L'une des utilisations principales et évidentes de BitLocker sur un serveur est dans le contexte de la stratégie de succursale Windows Server 2008. Entre un quart et un tiers de serveurs sont installés dans des succursales, c'est-à-dire des bureaux qui peuvent avoir une sécurité physique moins importante, moins d'accès au support informatique et peut-être moins de connectivité aux centres de données. Les succursales sont également une cible attrayante pour les attaques. Conjointement avec les fonctionnalités comme les contrôleurs de domaine en lecture seule (RODC), BitLocker peut aider à protéger les données sensibles qui doivent être enregistrées dans une succursale, mais qui ne sont physiquement pas aussi sécurisées que dans un centre de données.
C'est une bonne occasion d'aborder le sujet du niveau approprié de protection. Qu'est-ce qui est plus important : empêcher l'accès non autorisé aux données ou nécessiter qu'un serveur puisse être sauvegardé de façon instantanée et sans intervention ? Ma suggestion est que dans beaucoup de succursales, il serait acceptable de demander un PIN pour redémarrer le serveur, mais c'est une décision que chaque entreprise doit prendre.
Expédition de disques Il est souvent nécessaire d'expédier des données sur un disque dur à une destination lointaine. Ceci peut inclure l'expédition d'un disque seul ou la préconfiguration et l'expédition d'un serveur entier. Pendant l'expédition, les données contenues sur ces disques sont hors de votre contrôle et risquent d'être copiées, perdues ou volées.
Pour atténuer ce risque, activez BitLocker sur les volumes de l'ordinateur avant l'expédition, puis supprimez tous les protecteurs clé sauf une clé de récupération ou un mot de passe de récupération. Cette clé ou ce mot de passe peut être porté à la main séparément du serveur ou même communiqué par téléphone ou dans un message électronique crypté au personnel de destination. Une fois l'ordinateur ou le disque reçu, le mot de passe de récupération est utilisé pour déverrouiller le lecteur. Le lecteur peut rester chiffré (replacez les autres protecteurs de clé) ou le disque peut être entièrement déchiffré après la livraison, le cas échéant.
Ceci est une méthode particulièrement efficace pour préconfigurer les contrôleurs de domaine ou les serveurs des succursales.
Cas de vol d'un serveur Comme indiqué dans la section précédente, il y a un réel danger qu'un serveur (surtout un contrôleur de domaine) soit volé. Des voleurs peuvent s'emparer d'un ordinateur portable à la volée, mais un serveur est généralement une cible soigneusement choisie. Si BitLocker est configuré pour nécessiter uniquement la vérification de l'intégrité TPM, le serveur volé peut tout simplement être mis sous tension et démarré. Par opposition, si les lecteurs d'un serveur sont protégés avec BitLocker et que BitLocker est configuré en mode avancé (nécessitant une clé USB, un PIN ou les deux) il est très difficile pour le voleur d'obtenir des informations utiles dans un laps de temps raisonnable.
Cas de vol d'un disque Inversement, cependant, si un seul disque est volé, le TPM fournit toujours une grande protection. Seul le TPM du serveur original peut être utilisé pour déverrouiller le lecteur protégé par BitLocker. Le disque ne peut donc pas être simplement inséré et lu dans un autre ordinateur.
Exposition réduite En achetant un matériel serveur qui inclut un processeur TPM et en utilisant la vérification d'intégrité de plate-forme, vous augmentez vos défenses contre certaines formes de programmes malveillants. En particulier, BitLocker détecte les modifications apportées lorsque Windows est hors ligne ou celles apportées aux premiers composants de démarrage, surtout si le logiciel malveillant, comme un rootkit, nécessite un redémarrage à l'installation. Ceci n'est pas une solution exhaustive, mais, associée aux fonctionnalités tels que l'intégrité de code de Windows et des produits tels que Microsoft® ForefrontTM Client Security, elle fournit une autre couche de défense en profondeur.
Désactivation sécurisée L'un des scénarios les plus utiles pour BitLocker intervient à la fin du cycle de vie d'un serveur ou d'un disque. Combien de fois avez-vous vu des serveurs ou leurs disques, mis au rebut sans avoir été convenablement mis hors service ? Savez-vous que les disques durs d'occasion se vendent parfois plus chers que des disques neufs sur les sites d'enchères, car des acheteurs sans scrupules espèrent trouver des informations utiles sur ces disques ?
Heureusement, au lieu d'entreprendre un processus long et coûteux pour nettoyer le disque de données utiles, BitLocker permet une autre approche. En gros, aucune information n'est jamais écrite sur le disque dans un format utile. Puisque les données chiffrées sont inutilisables, il est rapide et simple de supprimer toutes les informations clé. Ce qui arrive alors au matériel de disque n'a pas d'importance. Il peut être vendu, recyclé, réutilisé, etc., sans crainte que les données puissent tomber entre de mauvaises mains.
Dans Windows Vista et Windows Server 2008, la commande de format a été mise à jour pour effacer les clés BitLocker, y compris des remplacements multiples. Vous disposez maintenant d'une façon simple et efficace de mettre un lecteur hors service.

Nouvelles récentes
Alors que je rédige cet article (c'est-à-dire plusieurs semaines avant que vous ne le lisiez), plusieurs articles, documents et nouvelles ont abordé certaines caractéristiques matérielles intéressantes et la façon dont elles affectent BitLocker, les autres composants de sécurité de Windows et d'autres produits de chiffrement de divers fournisseurs. J'aimerais prendre un moment pour discuter des résultats de ces recherches.
Un article de ce type a été publié par les chercheurs de l'Université de Princeton et a démontré (très efficacement) un trait de mémoire informatique moderne parfois nommé « rémanence de la DRAM » (disponible à l'adresse citp.princeton.edu/pub/coldboot.pdf). En termes simples, le contenu de la mémoire informatique est accessible pendant une certaine période après que l'alimentation soit retirée de la mémoire. BitLocker, bien entendu, conserve des clés pour déchiffrer les données en mémoire pendant que Windows est en cours d'exécution et le problème est que ces clés risquent d'être obtenues par des utilisateurs non autorisés.
Une autre démonstration par Adam Boileau (security-assessment.com/files/presentations/ab_firewire_rux2k6-final.pdf) a montré comment le bus IEEE 1394 (souvent appelé FireWire) autorise l'accès direct à la mémoire (DMA), qui peut être utilisée pour obtenir des informations secrètes de Windows, comme des mots de passe ou les clés de déchiffrement. Ce qui est intéressant dans tout cela, c'est que DMA est presque ce qui fait l'intérêt de 1394. Ce n'est pas un défaut, mais plutôt ce pour quoi Firewire a été conçu.
Ce que ces deux attaques ont en commun, cependant, c'est qu'elles nécessitent l'accès physique à un ordinateur en cours d'exécution (ou du moins ayant été exécuté récemment). BitLocker n'est pas conçu pour protéger contre les attaques en ligne et il n'élimine pas le besoin d'une certaine quantité de sécurité physique. Une défense en profondeur nécessite l'utilisation de plusieurs outils et fonctionnalités pour créer un environnement de sécurité physique, présenter des stratégies d'entreprise essentielles et éduquer continuellement les utilisateurs.
En outre, il ne s'agit pas de nouvelles découvertes. On le sait depuis longtemps et ces sujets font de fait l'objet de discussions sur le site Microsoft® Data Encryption Toolkit (DET). L'analyse de risque fournie dans le DET est destinée à aider les clients à trouver un équilibre entre sécurité et convivialité, en tenant compte du coût de mise en œuvre et de gestion. Ceci n'est pas une décision simple. Nous sommes d'avis que les clients informés sont mieux à même de prendre des décisions sur le compromis entre la sécurité, la convivialité et le coût.
En plus du DET, certains de mes collègues ont fourni d'excellents commentaires et instructions. Tout d'abord, Russ Humphries a abordé les compromis de sécurité dans le contexte de la rémanence de la DRAM dans son entrée de blog, à l'adresse go.microsoft.com/fwlink/?LinkId=115217. Douglas MacIver a rédigé des étapes de configuration et des contre-mesures spécifiques supplémentaires que vous pouvez effectuer aujourd'hui, sur le blog de l'équipe d'intégrité système (SI), à l'adresse go.microsoft.com/fwlink/?LinkId=115218. Je vous recommande de prendre le temps de lire ces deux entrées de blog utiles. Je vous conseille également de lire le DET.
Le conseil le plus important est d'utiliser un mode avancé (c'est-à-dire un mode qui requiert une clé USB ou un PIN) et de ne pas laisser un ordinateur sans surveillance en mode Veille (utilisez plutôt le mode Veille prolongée).

Conclusion
BitLocker reste l'une des fonctionnalités les plus utiles de Windows Vista. Avec la publication du SP1, il a été amélioré en réponse directe aux commentaires des clients pour permettre plus de scénarios et répondre à un plus grand éventail de besoins en matière de protection des données. Le développement de cette protection des données au repos dans Windows Server 2008 vous offre plus de façons de protéger les données et de garantir leur conformité, qu'elles soient enregistrées sur les serveurs ou les postes de travail client, dans le centre de données, les succursales ou auprès d'un utilisateur mobile.

Byron Hynes est stratégiste en technologie d'entreprise au sein du groupe EPG (Microsoft Enterprise and Partner Group). Son travail porte sur les fonctionnalités et les produits de sécurité. Avant de rejoindre l'EPG, il a travaillé dans la division Windows Server et particulièrement sur BitLocker (intégrité de système) depuis 2005. Vos commentaires et vos questions sont les bienvenus. Vous pouvez le rencontrer pendant le Tech•Ed 2008 ou lui envoyer un message électronique à l'adresse bhynes@microsoft.com.


Sécurité
Verrouillage d'applications avec les stratégies de restriction logicielle
Chris Corio and Durga Prasad Sayana
Vue d'ensemble:
  • Fonctionnement des stratégies de restriction logicielle
  • Inventaire des applications de votre environnement
  • Création et application de stratégies

Lorsque les informaticiens cherchent à réduire le coût total de possession de leurs ordinateurs de bureau, deux stratégies essentielles viennent souvent à l'esprit. La première consiste à enlever les
comptes d'utilisateurs d'ordinateurs de bureau du groupe Administrateurs. La seconde est la limitation des applications pouvant être exécutées par les utilisateurs. S'attaquer à ces problèmes peut constituer un défi de taille dans un environnement d'entreprise, mais Windows Vista® dispose de technologies pouvant vous aider à atteindre ces objectifs.
Windows Vista et sa fonctionnalité de Contrôle de compte d'utilisateur constituent une étape importante dans l'aide apportée aux professionnels de l'informatique pour l'affectation des utilisateurs de l'entreprise en tant que membres du groupe Utilisateurs (Utilisateurs standard). Le Contrôle de compte d'utilisateur a modifié le contexte de sécurité par défaut de toutes les applications, le faisant passer d'Administrateur à Utilisateur. Cette migration vers le groupe Utilisateurs est toujours une tâche conséquente, mais la tâche devient progressivement plus facile tandis que le secteur s'ajuste à ce nouveau paradigme.
Après avoir analysé les défis du transfert d'utilisateurs vers le groupe Utilisateurs, ou parfois pendant ce processus, de nombreux administrateurs cataloguent les applications que leurs utilisateurs ont besoin d'exécuter et examinent les étapes nécessaires pour autoriser seulement ces applications. La fonctionnalité de stratégie de restriction logicielle est conçue précisément pour aider les informaticiens à effectuer cette tâche.
Vous spécifiez simplement les applications autorisées à être exécuter et déployez ensuite la stratégie à l'aide de la Stratégie de groupe. L'application d'une telle stratégie dans l'ensemble d'une entreprise peut réduire le coût total de possession, car ce verrouillage limitera les problèmes liés aux applications non prises en charge. (Vous pouvez également utiliser des stratégies de restriction logicielle de manières extrêmes et intéressantes, comme nous l'avons décrit dans l'encadré « Stratégie de restriction logicielle réduite à sa plus simple expression ».)

Fonctionnement de la stratégie de restriction logicielle
La stratégie de restriction logicielle vise à contrôler précisément le code qu'un utilisateur peut exécuter sur un ordinateur Windows Vista. Vous, l'administrateur, créez une stratégie qui définit ce qui peut (ou ne peut pas) être exécuté dans votre environnement. Cette stratégie est ensuite évaluée à tout moment et à tout emplacement auxquels le code pourrait être exécuté. Ceci inclut la création de processus, pendant un appel à ShellExecute et l'exécution d'un script. (Nous examinerons ceci dans un instant)
Si une application est autorisée à s'exécuter, l'application démarrera. Si, cependant, une application n'est pas autorisée à s'exécuter, l'application est bloquée et l'utilisateur est averti. Par exemple, si vous aviez essayé d'exécuter le Solitaire depuis le menu Démarrer et qu'il n'était pas autorisé, une boîte de dialogue similaire à celle affichée dans la figure 1 s'afficherait.
Figure 1 Une boîte de dialogue s'affiche lorsqu'une application est bloquée
Figure 1 Une boîte de dialogue s'affiche lorsqu'une application est bloquée (Cliquez sur l'image pour l'agrandir)
L'interface utilisateur pour la définition d'une stratégie de restriction logicielle est exposée dans l'éditeur d'objets de stratégie de groupe (Group Policy Object Editor, GPOE), et c'est là que la stratégie de verrouillage est créée. Il existe une variété de méthodes pour définir le code pouvant ou ne pouvant pas être exécuté. Une fois la stratégie terminée et testée, vous pouvez la déployer.

Définition de la stratégie de restriction logicielle
La première décision majeure que vous prendrez, une décision qui affectera de façon spectaculaire la manière dont la stratégie de restriction logicielle fonctionnera dans votre environnement, est de choisir un type de règle par défaut. Les stratégies de restriction logicielle peuvent être déployées dans deux modes : Liste verte ou Liste de refus. Vous choisissez si vous voulez créer une stratégie qui décrit chaque application autorisée à s'exécuter dans votre environnement ou une stratégie définissant chaque application à ne pas exécuter.
En mode Liste verte, la règle par défaut dans votre stratégie est Restreint et bloquera toutes les applications que vous n'autorisez pas explicitement à s'exécuter. En mode Liste de refus, la règle par défaut est Non restreint et restreint seulement les applications que vous avez répertoriées explicitement.
Le mode Liste de refus, comme vous pouvez le deviner, est une approche peu réaliste si vous recherchez une réduction du coût total de possession importante et les avantages de sécurité résultant d'un verrouillage d'application. La création et la maintenance d'une liste complète bloquant tous les logiciels malveillants et autres applications problématiques serait presque impossible. Nous recommandons que la stratégie de restriction logicielle soit implémentée en mode Liste verte, ce qui correspond à une règle par défaut Limité.

Inventaire des applications de votre environnement
Si vous allez concevoir une stratégie qui spécifiera les applications pouvant s'exécuter, vous devez déterminer avec précision les applications que vos utilisateurs nécessitent. La fonctionnalité de stratégie de restriction logicielle offre une fonctionnalité de journalisation avancée avec une stratégie très simple pour savoir précisément quelles sont les applications qui s'exécutent dans votre environnement.
Sur un ensemble d'ordinateurs de votre environnement, déployez votre stratégie de restriction logicielle avec la règle par défaut définie sur Non restreint et veillez à supprimer toute autre règle supplémentaire. L'objectif consiste à activer la stratégie de restriction logicielle mais à ne pas l'autoriser à restreindre des applications. Vous l'utilisez plutôt pour contrôler seulement ce qui est exécuté.
Ensuite, créez la valeur de Registre suivante pour activer la fonction de journalisation avancée et définir le chemin dans lequel le fichier journal devrait être écrit :
"HKLM\SOFTWARE\Policies\Microsoft\Windows\Safer\
CodeIdentifiers"
String Value: LogFileName, <path to a log file>
Maintenant, lorsqu'une application est exécutée et que la stratégie de restriction logicielle est évaluée (elle est évaluée même si elle autorise l'exécution de tout), une entrée est écrite dans le fichier journal.
Chaque entrée de journal inclut l'appelant de la stratégie de restriction logicielle et l'ID de processus (PID) du processus appelant, la cible évaluée, le type de règle de stratégie de restriction logicielle qui correspondait et un identificateur pour la règle. Voici une entrée d'exemple écrite lorsqu'un utilisateur double-clique sur notepad.exe :
explorer.exe (PID = 3268) identified
C:\Windows\system32\notepad.exe as Unrestricted using
path rule, Guid =
{191cd7fa-f240-4a17-8986-94d480a6c8ca}
Ce fichier journal représente chaque élément de code exécutable que cette stratégie de restriction logicielle vérifiera lorsqu'elle est activée et définie pour bloquer des applications. Ceci signifie que vous devez, pour chaque entrée du fichier journal, décider si elle devrait ou non figurer dans votre liste verte. Notez que vous verrez plusieurs fichiers binaires vérifiés faisant partie de Windows® et requis pour le fonctionnement du système.
La technique de journalisation que nous décrivons ici vous offre une méthode évidente pour connaître précisément les applications que la stratégie de restriction logicielle rencontrera dans votre environnement. Mais ce n'est pas la seule manière d'accomplir cette tâche.
Inventory Collector, inclus dans les Outils d’analyse de compatibilité des applications Microsoft® 5.0 vous donne la capacité d'effectuer l'inventaire des applications utilisées dans votre environnement. Cet outil offre plusieurs méthodes différentes vous permettant de découvrir les applications installées dans votre environnement et consolide également les résultats dans une base de données centrale.

Création de règles supplémentaires
Maintenant que vous disposez d'une liste d'applications devant être autorisées à s'exécuter dans votre environnement, vous êtes prêt à créer les véritables règles qui permettront à ces applications de s'exécuter. La fonctionnalité de stratégie de restriction logicielle utilise deux méthodes pour identifier la stratégie : l'une est basée sur les propriétés cryptographiques d'une application (comme son hachage) et l'autre définit un dossier ou chemin de confiance dans lequel les applications de confiance doivent résider.
La figure 2 montre l'emplacement auquel vous ajouteriez des règles pour autoriser les applications à s'exécuter dans le nœud Stratégies de restriction logicielle du GPOE (gpedit.msc). La façon la plus simple de définir des applications dans votre environnement est de créer une règle de hachage pour chaque fichier binaire que vous avez rencontré pendant la phase d'ouverture de session.
Figure 2 Utilisation de Gpedit.msc pour créer des stratégies de restriction logicielle
Figure 2 Utilisation de Gpedit.msc pour créer des stratégies de restriction logicielle (Cliquez sur l'image pour l'agrandir)
Puisque le hachage est une valeur unique renvoyée pour un ensemble particulier de bits, chaque fichier binaire de votre stratégie possèdera un hachage différent. Cette approche est particulièrement sécurisée et permettra seulement à des binaires spécifiques de votre stratégie de s'exécuter.
Il existe bien entendu des inconvénients à cette approche. Par exemple, votre environnement pourrait facilement comporter plusieurs milliers de binaires. Il pourrait être difficile de créer toutes ces règles dans l'interface utilisateur de stratégie de restriction logicielle, et lorsque le nombre de règles devient particulièrement important, les performances peuvent être affectées. Par ailleurs, chaque mise à jour d'application dans votre environnement nécessitera le déploiement d'une ou plusieurs nouvelles règles de hachage dans l'environnement. La mise à jour d'une stratégie de taille aussi grande lorsque les applications sont mises à jour peut constituer un fardeau énorme.
Heureusement, ce fardeau peut être évité car il existe deux autres façons d'identifier des règles et permettant d'utiliser plus facilement des stratégies de restriction logicielle dans votre environnement. En plongeant davantage dans la méthode de sécurité cryptographique, vous pouvez créer une règle qui autorisera tout fichier binaire par un certificat particulier à s'exécuter.
Ceci contribue à simplifier la maintenance de la liste de la stratégie car, lorsqu'une application est mise à jour, les nouveaux fichiers binaires seront généralement signés par le même certificat que les précédents. Cependant, si vous ne voulez pas qu'une version antérieure du fichier binaire soit exécutée dans votre environnement, vous devrez ajouter une règle de hachage Restreint pour empêcher l'autorisation du fichier.
Par défaut, l'évaluation des règles de certificat est désactivée pour les stratégies de restriction logicielle. Ceci s'explique par deux raisons.
Premièrement, les règles de certificat des stratégies de restriction logicielle sont définies par ce qui se trouve dans la banque Éditeurs approuvés du système. Comme la banque Éditeurs approuvés n'est pas uniquement utilisée pour les règles de stratégie de restriction logicielle, ceci nécessite du temps et un examen supplémentaires pour l'utilisation avec la fonctionnalité de stratégies de restriction logicielle.
La deuxième raison est que pour déterminer si une signature de fichier est valide, vous devez prendre un hachage de fichier et le comparer aux informations de signature. Un hachage de fichier est une opération longue. Le fichier entier doit être lu depuis le disque et traité pour calculer ce hachage.
Pour activer les règles de certificat, naviguez jusqu'au nœud Stratégies de restriction logicielle et sélectionnez l'objet Mise en œuvre dans le volet de résultats. Double-cliquez ensuite pour ouvrir sa boîte de dialogue de propriétés et sélectionnez la case Appliquer les règles de certificat.
L'autre façon courante d'identifier le code est d'utiliser le chemin du code sur l'ordinateur local. Ceci est une technique efficace et pratique, mais elle possède un inconvénient : vous devez veiller à ce que les paramètres de sécurité soient correctement définis sur le dossier.
Si vous ajoutez une règle de chemin d'accès particulière et que ce chemin permet aux utilisateurs d'y écrire des fichiers (sur le Bureau, par exemple), ils pourraient exécuter tout ce qu'ils veulent en plaçant simplement le fichier exécutable à cet emplacement. Cependant, si vos utilisateurs ne font pas partie du groupe Administrateurs, ils n'ont généralement pas la possibilité de modifier quoi que ce soit dans les dossiers Program Files et Windows. Ceci signifie que si toutes vos applications se situent dans le répertoire Program Files et que vos utilisateurs ne sont pas Administrateurs, il est intéressant d'utiliser les règles de chemin d'accès pour avoir une stratégie très simple et efficace.
Les règles de chemin d'accès offrent d'autres fonctionnalités qui les rendent plus appropriées pour certains environnements. Elles permettent l'utilisation de caractères génériques et vous permettent d'utiliser des variables d'environnement pour définir plus facilement des règles portables dans votre environnement. Après tout, %systemdrive% peut ne pas être le c:\ pour tous les utilisateurs.
En termes de performances et de maintenance, il s'agit probablement de la manière présentant le moins de difficultés pour identifier le code. Les règles de chemin d'accès sont certainement intéressantes, mais vous devez être conscients de questions de sécurité supplémentaires.

Règles de zone réseau
La stratégie de restriction logicielle inclut un type de règle appelé Zone réseau, bien que ce type de règle ne soit pas recommandé. L'intention première de ces règles était basée sur l'idée que la source d'un code exécutable particulier pouvait être identifiée et était digne de confiance et qu'ainsi le code serait autorisé à s'exécuter. Malheureusement, ceci est particulièrement difficile à effectuer et, par conséquent, n'a jamais vraiment bien fonctionné. Actuellement, ce type de règle n'est pas appliqué dans la majorité des cas sur les points d'entrée de stratégie de restriction logicielle.
Dans les cas de figure pour lesquels la plupart des applications sont installées dans le dossier %Program Files% mais qu'il existe d'autres fichiers exécutables installés ailleurs et signés par un certificat spécifique, il est sensé d'utiliser des règles de types différents. Quelques règles de hachage, quelques règles de chemin d'accès et vous vous retrouverez avec la stratégie qui vous convient.
Gardez à l'esprit qu'il existe un ordre dans lequel les règles doivent être traitées (comme indiqué sur la figure 3). Les règles de certificat sont les plus spécifiques, les règles de hachage suivent ensuite, puis les règles de chemin d'accès et enfin les règles de chemin d'accès avec caractères génériques. Par conséquent, si un élément de code est identifié par une règle de hachage et une règle de chemin d'accès, le niveau de sécurité de la règle de hachage aura priorité.
Figure 3 Ordre de traitement des règles
Figure 3 Ordre de traitement des règles (Cliquez sur l'image pour l'agrandir)

Application de stratégie
La fonctionnalité de stratégie de restriction logicielle fournit une couverture étendue du système sécurisé. Le principe est que n'importe quel emplacement depuis lequel le code peut être exécuté devrait être intégré à la stratégie de restriction logicielle et, ensuite, vérifier la stratégie pour voir si le code exécutable est autorisé à s'exécuter.
Bien qu'il existe de nombreux emplacements auxquels vérifier la stratégie de restriction logicielle, le point d'entrée le plus évident est CreateProcess. Pendant CreateProcess, la stratégie est vérifiée pour déterminer si le fichier binaire qui représente l'application est autorisé à s'exécuter. La vérification de stratégie est effectuée par l'API SaferIdentifyLevel, qui est décrite publiquement. Le processus général est illustré à la figure 4. (Nous aborderons SaferIdentifyLevel plus en détails dans un instant).
Figure 4 Utilisation de SaferIdentifyLevel pour déterminer si un fichier binaire peut être exécuté
Figure 4 Utilisation de SaferIdentifyLevel pour déterminer si un fichier binaire peut être exécuté (Cliquez sur l'image pour l'agrandir)
Après CreateProcess, l'API la plus couramment utilisée dans laquelle la stratégie de restriction logicielle est appliquée est ShellExecute. Il s'agit de l'API appelée lorsque l'utilisateur clique sur une application dans le menu Démarrer ou double-clique sur quelque chose sur le Bureau.
ShellExecute peut être appelée pour une grande variété de formats de fichier. Dans les cas tels qu'un fichier .txt, l'appel de ShellExecute pour le fichier n'a en fait pas pour résultat l'exécution du fichier : techniquement, bien sûr, le fichier est ouvert. Pour cette raison, la stratégie de restriction logicielle contient une liste de types de fichiers exécutables afin qu'elle puisse contrôler les types de fichiers vérifiés lorsque ShellExecute est appelé. Vous pouvez personnaliser cette liste de types de fichiers exécutables dans l'interface utilisateur de la stratégie de restriction logicielle.
Outre CreateProcess et ShellExecute, il existe deux autres points d'intégration essentiels : LoadLibrary et Script Host. LoadLibrary est évidemment un emplacement important pour vérifier le code exécutable, mais présente malheureusement certaines contraintes spéciales.
La plupart des applications possèdent un exécutable et plusieurs DLL qui sont chargés. De manière générale, de nombreuses applications s'exécutent sur le système. Ceci signifie que LoadLibrary nécessiterait de nombreuses vérifications de la stratégie. En fonction de votre stratégie pour l'identification de code, ceci pourrait être un point d'entrée coûteux à mettre en œuvre. Imaginez que vous ayez à vérifier le hachage de toutes les DLL chargées sur le système, ce qui inclut le hachage des bibliothèques et leur comparaison à une liste comportant peut-être des milliers de hachages.
Cette fonctionnalité est désactivée par défaut, mais peut être activée manuellement. Pour cela, naviguez jusqu'au nœud Stratégies de restriction logicielle dans gpedit.msc et double-cliquez sur Mise en œuvre. Ensuite, sélectionnez la case d'option Tous les fichiers de logiciels.
Comme nous l'avons mentionné, la stratégie de restriction logicielle est intégrée à la plupart des hôtes de script du système. Ceci inclut cmd, VBScript, Cscript et JScript®. Ces points d'entrée, de même que les autres, utilisent l'API de mise en œuvre de stratégie de restriction logicielle principale : SaferIdentifyLevel.
L'API SaferIdentifyLevel détermine si un exécutable spécifié devrait être autorisé à s'exécuter en recherchant les informations d'identification dans les stratégies de restriction logicielle pertinentes. Ceci est une API décrite publiquement. Les hôtes de script et les environnements exécutables tiers peuvent et doivent l'utiliser pour s'intégrer à la stratégie de restriction logicielle afin que la stratégie puisse déterminer si un élément de code exécutable doit être autorisé à s'exécuter.

Exécution en tant qu’utilisateur standard
Il existe une fonctionnalité peu connue de la stratégie de restriction logicielle offrant la possibilité de filtrer les privilèges de certaines applications lorsqu'elles sont lancées. Cette fonctionnalité a été introduite dans Windows XP, mais n'a pas été exposée dans l'interface utilisateur de la stratégie de restriction logicielle avant Windows Vista.
Elle était par conséquent un précurseur du Contrôle de compte d’utilisateur de Windows Vista car vous pouviez l'utiliser pour exécuter une application en tant qu'utilisateur standard même lorsque l'utilisateur était membre du groupe Administrateurs. C'est ce qui se passe lorsque vous créez une règle et définissez le niveau de sécurité sur Utilisateur normal dans l'interface utilisateur des règles supplémentaires.
La fonctionnalité de filtrage de jeton du Contrôle de compte d’utilisateur comme les règles d'utilisateur normal des stratégies de restriction logicielle tirent parti d'une API sous-jacente qui implémente le même comportement que l'API CreateRestrictedToken. Cependant, les différences architecturales générales des technologies sont très importantes. Le Contrôle de compte d’utilisateur diffère de la stratégie de restriction logicielle en quelques points essentiels.
Premièrement, dans Windows Vista avec Contrôle de compte d’utilisateur activé, chaque application est démarrée avec un jeton de sécurité similaire à un membre du groupe Utilisateurs par défaut, même lorsque l'utilisateur est administrateur. Ceci est possible avec la stratégie de restriction logicielle, mais il n'existe aucun moyen de démarrer une application avec le véritable jeton d'Administrateur de l'utilisateur, par exemple lorsque l'utilisateur doit installer une application. La modification de contexte de sécurité et l'accès facile à un jeton d'administrateur complet de l'utilisateur sont des avantages essentiels du Contrôle de compte d’utilisateur.
La deuxième différence est que, dans le cas des exécutables, le code lui-même exprime le niveau de privilège requis pour qu'il puisse fonctionner. Ceci est une distinction essentielle car les fabricants indépendants de logiciels (FIL) et les développeurs comprennent mieux les besoins de leur code. Par exemple, si une application du Panneau de configuration a besoin de modifier quelque chose nécessitant des droits d'administrateur, elle peut spécifier cette exigence dans son manifeste. Ainsi le FIL peut décrire les privilèges nécessaires par une application plutôt que de lui imposer un certain niveau de privilège sans disposer de véritables moyens de modifier ce niveau.
Pour l'instant, vous devriez éviter d'utiliser les règles d'Utilisateur normal à moins que vous ne compreniez vraiment leur fonctionnement. Le Contrôle de compte d’utilisateur est une excellente méthode pour aider à extraire les utilisateurs de bureau du groupe Administrateurs, et vous devriez sérieusement envisager de le laisser à votre environnement d'entreprise.

Stratégies de restriction logicielle utilisées aujourd'hui
Il existe plusieurs éléments à prendre en compte lorsque vous utilisez la stratégie de restriction logicielle. Mais ce n'est pas ce que vous pourriez penser et, en fait, vous utilisez peut-être même déjà des stratégies de restriction logicielle aujourd'hui, sans vous en rendre compte. Si, par exemple, vous exécutez le Contrôle parental sur un système Windows Vista, vous utilisez des stratégies de restriction logicielle pour contrôler l'exécution des applications.
La stratégie de restriction logicielle était un développement technologique important lors de son introduction initiale dans Windows XP. Mais le verrouillage d'applications commence véritablement maintenant à attirer l'attention des professionnels de l'informatique.
La fonctionnalité de stratégie de restriction logicielle dans Windows Vista nécessite d'être peaufinée, mais il est évident que les administrateurs souhaitent disposer de ce contrôle accru sur ce qui s'exécute dans leurs environnements. Heureusement pour nous tous, cette technologie continuera à évoluer et à faciliter l'administration des systèmes par les informaticiens comme la réduction du coût de l'utilisation d'un environnement Microsoft Windows.
Stratégie de restriction logicielle réduite à sa plus simple expression
Une application de la stratégie de restriction logicielle consiste à créer une stratégie verrouillant Windows dans un mode plein écran. Microsoft produit en fait un kit d'outils nommé SteadyState™, pour la création de ce mode plein écran. Cependant, si vous vous intéressez seulement au verrouillage des applications pouvant s'exécuter, ceci peut être effectué plus simplement.
Pour autoriser un ensemble minimal d'applications requises à ouvrir une session Windows Vista, créez une stratégie qui autorise logonui.exe et userinit.exe à s'exécuter à partir de %windir%\system32. La plupart des utilisateurs auront probablement également besoin des applications suivantes autorisées à s'exécuter :
dllhost.exe, rundll32.exe, control.exe (also under %windir%\system32)....
Si vous voulez le shell Windows par défaut, ajoutez alors également %windir%\explorer.exe.
Vous pourriez également choisir de démarrer directement dans une application, comme Internet Explorer®. Dans ce cas, il est nécessaire de répertorier iexplore.exe au lieu d'explorer.exe.
Un autre aspect de cette stratégie est que vos utilisateurs ne devraient pas être membres du groupe Administrateurs. Ceci est important afin qu'ils ne puissent pas contourner la stratégie. Cependant, comme ils peuvent uniquement exécuter un ensemble très simple d'applications et ne possèdent pas les autorisations d'Administrateur, les utilisateurs n'auront pas les autorisations d'installation d'applications ou de maintenance du système.
Vous devrez disposer d'un moyen d'effectuer ceci pour ces ordinateurs. Si vous prévoyez de mettre à jour et de maintenir ces ordinateurs en ouvrant une session localement avec un compte Administrateur, vous devriez sélectionner la case d'option qui applique la stratégie de restriction logicielle à tous les utilisateurs à l'exception des administrateurs locaux. La stratégie devrait également inclure consent.exe et cmd.exe. Ceci permettra à l'Administrateur de lancer toute option d'administration à partir d'une invite de commande d'Administrateur.
Notez que ce Contrôle de compte d’utilisateur limite les autorisations du jeton de sécurité de l'utilisateur par défaut pour donner l'impression que celui-ci n'est pas membre du groupe Administrateurs. Même si vous configurez le paramètre ci-dessus pour qu'il n'applique pas la stratégie aux Administrateurs, elle sera toujours appliquée aux utilisateurs. Ce n'est que lorsque vous effectuez l'élévation de Contrôle de compte d’utilisateur que l'Administrateur obtient réellement les droits d'administrateur complets et que la stratégie de restriction logicielle n'est plus appliquée.

Chris CorioChris Corio a été membre de l'équipe Windows Security chez Microsoft pendant plus de cinq ans. Ses activités principales chez Microsoft avaient trait aux technologies de sécurité des applications et aux technologies d'administration pour sécuriser Windows. Vous pouvez joindre Chris à l'adresse winsecurity@chriscorio.com
Durga Prasad SayanaDurga Prasad Sayana est ingénieur de conception logicielle (test) de l'équipe Windows Core Security. Ses centres d'intérêts principaux sont les technologies de sécurité et le test de logiciels. Vous pouvez joindre Durga à l'adresse durgas@microsoft.com.


Sécurité
Gestion du pare-feu Windows Vista
Jesper M. Johansson
Vue d'ensemble:
  • Types de règles et scénarios
  • Profils de pare-feu
  • Règles d'isolation de domaine
  • Problèmes du filtrage sortant

Il y a quelque temps de cela, j'ai écrit un article sur le pare-feu de Windows Vista dans mon blog. Cet article décrivait simplement certaines des fonctionnalités conviviales du pare-feu mais ne donnait pas de conseils spécifiques sur la façon de le déployer.
Dans le présent article, j'examinerai plus en détails certaines des fonctionnalités du pare-feu Windows Vista® qui sont spécifiquement conçues pour faciliter la gestion d'entreprise. J'inclurai également quelques conseils sur la façon dont vous pouvez les utiliser pour vous simplifier la tâche et garantir une plus grande sécurité pour vos utilisateurs.
Avec la publication récente du SP1 pour Windows Vista, le déploiement en entreprise de Windows Vista est susceptible de devenir plus généralisé. Les entreprises attendent généralement la sortie du premier Service Pack avant de migrer vers un nouveau système d'exploitation. Si vous faites partie des professionnels de l'informatique qui envisagent plus sérieusement de déployer Windows Vista dans votre environnement d'entreprise, je vous conseille de jeter un meilleur coup d'œil au pare-feu. Une fois que vous vous rendrez compte des capacités du pare-feu de Windows Vista, vous voudrez peut-être renégocier l'accord sur votre suite de logiciels de sécurité tiers pour supprimer le pare-feu.

Historique des pare-feu Windows
Le pare-feu inclus dans la version originale de Windows® XP laissait beaucoup à désirer. Bien qu'il était équivalent à la fonctionnalité de sécurité des pare-feu commerciaux basés sur des hôtes de l'époque, il n'apportait rien de nouveau ni d'innovant.
Le produit de remplacement livré avec Windows XP SP2 a été complètement modifié. Il est spécifiquement conçu pour faciliter la gestion d'entreprise. Le pare-feu Windows XP SP2 est très attrayant car il est léger, gérable de façon centralisée, efficace et non encombrant. Mais son atout essentiel est le suivant : le pare-feu Windows XP SP2 protège le système au démarrage.
Ce dernier point est crucial. Dans le passé, j'ai vu beaucoup de systèmes être infectés pendant le démarrage, même avec un pare-feu activé. En effet, pendant l'épidémie de Blaster, les taux d'attaques étaient de l'ordre d'une toutes les quatre minutes. En d'autres termes, si vous laissiez un ordinateur non protégé sur Internet, il risquait d'être infecté, en moyenne, toutes les quatre minutes. Avec un pare-feu ne protégeant pas le système au démarrage, 1 système sur 12 aurait été infecté au redémarrage. Ce sont ces chiffres qui ont conduit Microsoft à inclure une protection du système au démarrage dans le pare-feu Windows XP SP2.
Dans Windows Vista, le pare-feu a subi une autre transformation totale. La nouveauté la plus évidente, du point de vue de la gestion, est que les interfaces de gestion des protocoles IPSec (Internet Protocol Security) et le pare-feu ont été fusionnés. Cette modification est très logique. IPSec et le pare-feu sont tous deux conçus pour bloquer les éléments qui ne sont pas autorisés. La différence est que dans le pare-feu, les paramètres qui définissent ce qui est autorisé ou pas ne sont pas très granulaires, tandis qu'avec IPSec, il n'est pas facile de bloquer ou d'autoriser de grands groupes d'espaces d'adresse.
Avec les deux fonctionnalités réunies dans une même interface de gestion, les administrations peuvent utiliser les deux technologies de façon continue, sans s'inquiéter de savoir si une règle IPSec ou un filtre de pare-feu est requis. Bref, vous avez une vue unique de la surface d'attaque de réseau sur le système, ce qui réduit le risque d'erreurs.
SP1 pour Windows Vista apporte une fiabilité améliorée aux fonctions de pare-feu. Il ajoute également de nouveaux algorithmes, notamment les algorithmes Suite B, destinés à être utilisés dans IPSec. Il s'agit d'une série d'algorithmes de chiffrement, comprenant la norme de chiffrement avancé AES (Advanced Encryption System), le système de cryptographie de courbe elliptique ECC (Elliptic Curve Cryptography) et l'algorithme de hachage SHA (Secure Hash Algorithm) 256 et 384.
Plus important encore, le Service Pack 1 inclut maintenant la prise en charge de la protection de l'accès réseau (NAP). NAP est un outil de mise en application de stratégie qui s'assure que les clients gérés et non compromis sont à jour avec les dernières stratégies de sécurité, mises à jour et définitions anti-logiciels malveillants avant qu'ils ne soient autorisés à se connecter au réseau. NAP ne peut pas empêcher les hôtes malveillants de se connecter au réseau, mais il garantit que tous les hôtes gérés sont entièrement conformes tant qu'ils ne sont pas activement compromis.
Le pare-feu de Windows Vista, appelé Pare-feu Windows avec sécurité avancée, est également inclus dans Windows Server® 2008. Toutes les fonctionnalités peuvent en outre être gérées à distance et configurées sur un réseau à l'aide de la stratégie de groupe.

Types de règles et scénarios
La combinaison des fonctionnalités du pare-feu et IPSec dans l'interface de gestion signifie qu'il existe maintenant deux types de règles différents : les règles directionnelles et les règles de connexion. Les règles directionnelles sont des règles de pare-feu standard qui définissent quel trafic autoriser dans la direction appropriée. Les règles de connexion définissent les paramètres de protection pour les connexions entre les ordinateurs. Pour utiliser une analogie, les règles directionnelles sont un peu comme les règles des pare-feu précédents tandis que les règles de connexion sont plus comme les règles IPSec utilisées conjointement avec le pare-feu de Windows XP SP2.
La combinaison du pare-feu et d'IPSec dans la même interface permet plusieurs scénarios très intéressants. Par exemple, l'isolation des systèmes sur le réseau est l'un des concepts de sécurité les plus importants aujourd'hui. Microsoft appelle ce concept « l'isolation de serveur et de domaine ».
L'isolation de serveur et de domaine utilise les fonctionnalités IPSec et du pare-feu. Dans cet esprit, la nouvelle interface de gestion de pare-feu inclut une fonctionnalité spécifique pour les règles d'isolation. Celles-ci sont appropriées si vous voulez par exemple limiter la connexion en fonction des attributs des systèmes source ou de destination, comme l'appartenance à un domaine.
Comme vous pouvez le voir dans la figure 1, l'Assistant Nouvelle règle de sécurité de connexion commence par vous demander quel type de règle vous voulez créer. Si vous sélectionnez Isolation, l'Assistant préconfigure certains paramètres qui sont appropriés pour une règle d'isolation.
Figure 1 Utilisation de l'Assistant Nouvelle règle de sécurité de connexion pour créer une règle d'isolation
Figure 1 Utilisation de l'Assistant Nouvelle règle de sécurité de connexion pour créer une règle d'isolation (Cliquez sur l'image pour l'agrandir)
Vous remarquerez peut-être aussi dans la figure 1 que la règle d'isolation mentionne l'état d'intégrité. Les règles utilisées pour l'isolation de serveur et de domaine sont en réalité les mêmes règles que celles que vous utilisez pour NAP.
Vous ne pouvez pas appliquer l'authentification pour certains types de trafic. Par exemple, il est probable que vous n'ayez pas besoin de l'authentification pour la résolution DNS. Pour les points de terminaison de ce type de trafic, vous avez besoin d'une règle d'exemption d'authentification. Une règle d'exemption d'authentification fait exactement ce que son nom indique : elle exempte le trafic des exigences IPSec.
En revanche, le nom de règle serveur est plutôt mal choisi. Bien qu'elles soient plus couramment utilisées avec les serveurs, elles peuvent également être utilisées avec des clients. Une règle serveur à serveur configure simplement une connexion de façon à demander l'authentification. Ceci diffère d'une règle d'isolation dans la mesure où non seulement une règle d'isolation nécessite l'authentification, mais elle nécessite également que certains critères supplémentaires soient remplis, comme l'appartenance à un domaine ou un état d'intégrité.
Une règle de tunnel définit essentiellement un réseau privé virtuel de site à site (VPN) et le tunnel entre les passerelles. Les règles de tunnel sont rarement utilisées avec Windows Vista, car il est peu probable que vous utilisiez Windows Vista avec une passerelle. Vous pouvez créer des règles entièrement personnalisées, ce qui signifie que vous pouvez personnaliser chaque paramètre d'une règle.

Classement des règles
Le classement des règles semble à première vue un peu compliqué. La clé pour comprendre le classement des règles est d'oublier l'idée de classement. L'important n'est pas tant de classer mais plutôt d'effectuer une sélection correspondante. Prenons comme exemple le trafic entrant. Le trafic entrant qui ne correspond à aucune règle qui l'autorise est bloqué par défaut. Vous pourriez considérer cela comme un classement qui décrète que « les règles d'autorisation sont examinées en premier, » mais cette supposition serait inexacte. Si un paquet spécifique correspond à une règle d'autorisation et une règle de bloc, la règle de bloc gagne. En termes plus simples, ceci signifie que la correspondance est la suivante :
  1. Règles de blocage : si un paquet ou une connexion correspond à l'une de ces règles, il est rejeté.
  2. Règles d’autorisation : si un paquet ou une connexion correspond à l'une de ces règles, il est accepté.
  3. Comportement du profil directionnel par défaut : Si aucune règle de bloc ou d'autorisation ne correspond, le trafic est traité selon le comportement spécifié par défaut dans ce profil pour le trafic dans cette direction. Dans la direction entrante, dans tous profils, cela signifie que le trafic est bloqué dans une configuration par défaut. Dans la direction sortante, par défaut, cela signifie que le trafic est autorisé dans la configuration par défaut.
Le processus correspondant est géré par des règles de contournement authentifiées (IPSec). Avec ce type de règle, tout trafic authentifié qui correspond aux autres paramètres de la règle est autorisé, qu'il corresponde ou non à d'autres autres règles. Les règles de contournement authentifiées sont des règles directionnelles pour lesquelles l'option Substituer les règles de blocage est sélectionnée, comme le montre la figure 2. Ces règles sont examinées en premier, de façon à toujours autoriser le trafic authentifié à atteindre le système. Cet aspect est essentiel si vous voulez facilement autoriser le trafic provenant d'hôtes authentifiés tout en bloquant le trafic d'autres sources. Vous pouvez considérer cette règle comme 0 dans le classement. Ainsi, l'ordre complet des règles est le suivant :
Figure 2 Activation de l'option Substituer les règles de blocage pour configurer une règle de contournement authentifiée
Figure 2 Activation de l'option Substituer les règles de blocage pour configurer une règle de contournement authentifiée (Cliquez sur l'image pour l'agrandir)

0. Règles de contournement authentifié
1. Règles de blocage
2. Règles d’autorisation
3. Comportement du profil directionnel par défaut

Le fait que plusieurs règles dans chaque classe correspondent au schéma de trafic n'a pas d'importance. Dès qu'une règle correspond au trafic, le traitement de cette règle est arrêté.

Profils public, privé et de domaine
Ressources de mise en réseau
  • Centre de sécurité TechNet Security Center
  • Utilisation de l'outil de ligne de commande Netsh Advfirewall
  • Règles de sécurité pour le pare-feu Windows et pour les connexions IPsec dans Windows Vista et dans Windows Server 2008
  • Vigilance sécurité Utilisation de l'Assistant Configuration de la sécurité dans Windows Server 2008

Le nouveau pare-feu comprend trois profils : public, privé et de domaine. Le pare-feu Windows XP SP2 a, lui, deux profils de réseau : standard et de domaine. Le profil de domaine est automatiquement appelé lorsque l'ordinateur détecte le contrôleur de domaine. Dans Windows XP, le profil standard était utilisé autrement. Cette fonctionnalité puissante permettait à un administrateur de la sécurité de verrouiller l'ordinateur complètement lors d'une opération d'itinérance tout en autorisant la fonctionnalité de gestion à distance nécessaire sur le réseau de l'entreprise. Cette approche présentait cependant certains problèmes pour certains utilisateurs, en particulier pour ceux disposant de réseaux privés chez eux. Étant donné que le profil standard était toujours utilisé si le système était incapable d'atteindre le contrôleur de domaine, le système était verrouillé depuis le domicile de l'utilisateur.
Le nouveau profil privé inclus dans Windows Vista permet de résoudre ce problème. À présent, lorsque vous connectez le système à un nouveau réseau, il demande si ce réseau est public (il s'agit simplement du nouveau nom de l'ancien profil standard) ou privé et configure le système en conséquence. Le système se rappelle de cela chaque fois qu'il se connecte à ce réseau particulier, selon des paramètres de réseau qui lui sont présentés par les serveurs d'infrastructure sur le réseau. Cette méthode n'est pas totalement infaillible, mais elle est utile dans la mesure où elle autorise plus de réseaux à être mieux verrouillés.
La logique de détection de la présence d'un système sur le domaine a été également améliorée. Le résultat est une transition plus fiable et plus rapide et un nombre réduit de systèmes qui pensent pouvoir utiliser les profils public ou privé lorsqu'ils sont sur le domaine.
Vous pouvez lier vos règles à un type particulier de réseau, ce qui empêche le système de révéler trop d'informations et de tenter de se connecter aux systèmes sur des réseaux non fiables. C'est un domaine où l'intégration du pare-feu et d'IPSec porte ses fruits.
Grace à ces nouvelles règles, vous pouvez fournir certaines restrictions qui n'étaient pas possibles auparavant. Par exemple, pendant plusieurs années, les pirates ont tenté d'inciter des attaques en faisant en sorte que les utilisateurs effectuent des connexions SMB (bloc de message serveur), pour la mise en réseau Windows, à des hôtes non autorisés, ce qui forçait une séquence d'authentification à leur donner une paire défi-réponse pouvant être utilisée pour craquer les mots de passe. Les versions antérieures de cette attaque étaient également utilisées pour désactiver l'authentification de texte ou refléter la paire défi-réponse de l'utilisateur à l'ordinateur source. La première technique a été arrêtée il y a plusieurs années. La dernière technique a été atténuée grâce à Windows XP SP2, mais gardez à l'esprit que la divulgation de paires défi-réponse est néanmoins imprudente.
Pour empêcher cela, vous pourriez utiliser une autre nouvelle fonction du pare-feu de Windows Vista : le filtrage sortant. Un administrateur peut décider, par exemple, de bloquer toutes les connexions SMB sortantes (qui se terminent aux ports TCP 135, 139, 445 et UDP 137, 138, 445) dans le profil public. Il serait alors plus difficile pour un système d'être utilisé dans une attaque pour obtenir les paires de défi-réponse ou d'empêcher son accès aux fichiers partagés Windows non fiables sur l'Internet.
Encore une fois, cette méthode n'est certainement pas infaillible. Par exemple, si le système a déjà été compromis, cette règle n'arrêterait pas le système de communiquer vers l'extérieur car le pirate pourrait simplement désactiver la règle. Cependant, elle peut être très utile comme mesure de protection des systèmes légitimes mais potentiellement exposés.
Il est important de mentionner dans ce contexte que, tout comme dans Windows XP SP2, seul un profil peut être actif à la fois sur Windows Vista et Windows Server 2008. S'il y a deux interfaces de réseau en direct dans le système et que l'une d'elles est sur le domaine tandis que l'autre est sur un réseau public, le profil de pare-feu public est appliqué aux deux. Le profil le plus restrictif est toujours utilisé. Comme vous pouvez le deviner, le profil public est plus restrictif que le profil privé, et le profil privé est plus restrictif que le profil de domaine. Soyez donc conscient que la règle de blocage SMB sortant peut arrêter beaucoup de trafic sur des connexions VPN.
Pour activer le trafic sur une connexion VPN lorsque l'ordinateur est sur un réseau public ou privé, vous devez créer des règles directionnelles qui s'appliquent seulement aux interfaces VPN. Pour que cela fonctionne, les interfaces VPN doivent être reconnues comme telles par Windows. Si vous n'utilisez pas le serveur VPN des services de routage et d'accès à distance Microsoft®, testez cette fonctionnalité avant de la déployer à grande échelle. Il s'agit principalement d'un problème concernant le trafic entrant vers le client et les règles sortantes personnalisées que vous créez.

Création de règles de pare-feu
La création d'une règle de pare-feu est beaucoup plus facile avec le nouveau pare-feu. L'Assistant Nouvelle règle, illustré à la figure 3, vous permet de définir tous les types habituels de règles. Il inclut également des règles prédéfinies pour les services particuliers.
Figure 3 Règles prédéfinies de l'Assistant Nouvelle règle
Figure 3 Règles prédéfinies de l'Assistant Nouvelle règle (Cliquez sur l'image pour l'agrandir)
Les règles prédéfinies sont particulièrement importantes. L'isolation de serveur consiste essentiellement à limiter les services de telle façon qu'ils sont seulement disponibles pour les systèmes qui en ont besoin. Sur les produits serveur, l'assistant Configuration de Sécurité de Windows (SCW) peut être utilisé pour faciliter cette opération, bien qu'il n'élimine pas tous les problèmes (j'ai abordé le SCW dans le numéro de mars 2008 de TechNet Magazine).
Les versions client de Windows n'ont jusqu'à présent pas inclus de fonctionnalité similaire. Lorsque vous utilisez le type de règle prédéfini, une bonne partie du travail est faite pour vous, c'est-à-dire la tâche de déterminer quels points de terminaison un service utilise. Le pare-feu est non seulement conscient de l'application dans la mesure où il sait quel programme le « service iSCSI » représente, mais il contient également des règles prédéfinies qui décrivent certaines fonctionnalités. Vous pouvez alors vous concentrer sur les ordinateurs qui doivent être couverts par une règle. Cette tâche reste longue et difficile, mais au moins elle est unique à votre environnement.
Il existe également une règle personnalisée (masquée par la liste déroulante dans la figure 3) qui vous offre toute la flexibilité qu'un pare-feu d'authentification peut offrir. Par exemple, si vous voulez une règle qui autorise seulement le trafic IPSec chiffré, sélectionnez l'option qui autorise uniquement les connexions sécurisées sur la page Action de l'assistant illustrée à la figure 2.
Lorsque vous sélectionnez cette option, vous avez également la possibilité d'activer le chiffrement. Si vous laissez cette option vide, le trafic utilise ESP-NUL (charge utile de sécurité encapsulée avec une clé NULL). Il s'agit de la méthode recommandée pour utiliser IPSec pour l'authentification. Elle permet à la plupart des outils de gestion de réseau de continuer à fonctionner car le trafic traverse le réseau sans chiffrement, et si vous voulez ajouter le chiffrement, il vous suffit de cocher la case correspondante.
Dans beaucoup de situations, le chiffrement du trafic réseau n'est pas aussi important que le fait de ne pas accepter un trafic provenant d'hôtes malveillants. Le fait de chiffrer le trafic sur le réseau empêche les pirates ayant eu accès au réseau de voir ce qui est contenu dans le paquet. L'authentification peut vous empêcher d'envoyer le paquet et ainsi de subir une attaque tout court. Bien entendu, il y a des situations où le chiffrement au niveau du réseau est important, mais dans beaucoup d'autres, l'authentification suffit.

Création de règles d'isolation de domaine
Dans la plupart des environnements, il est préférable qu'un nombre limité d'ordinateurs puisse envoyer le trafic à un poste de travail. Tout au moins, tous les postes de travail doivent être configurés avec des règles d'isolation de domaine. Cette procédure était compliquée dans Windows XP, mais elle est facile dans Windows Vista.
Tout d'abord, ouvrez l'outil de gestion de votre choix et sélectionnez le nœud Règles de sécurité de connexion. Cliquez sur le nœud avec le bouton droit de la souris et sélectionnez Nouvelle Règle pour ouvrir la boîte de dialogue illustrée à la figure 1. Sélectionnez la règle d'isolation et cliquez sur Suivant. Vous devez maintenant définir si vous voulez que la règle soit obligatoire ou pas. Dans la plupart des cas sur les postes de travail, il est préférable de demander l'authentification pour le trafic entrant. Ceci empêche tout ordinateur qui n'est pas joint au domaine d'envoyer du trafic au poste de travail. Cependant, pour demander des services d'infrastructure, le système doit permettre à un minimum de trafic sortant de passer. La meilleure option est par conséquent de requérir l'authentification pour les connexions entrantes et de demander l'authentification pour les connexions sortantes.
Choisissez ensuite la méthode d'authentification. La sélection par défaut porte le nom Par défaut (ce qui n'est pas particulièrement explicite). Vous pouvez configurer la méthode d'authentification par défaut par ordinateur dans les propriétés IPSec (cliquez avec le bouton droit de la souris sur le nœud Pare-feu Windows avec sécurité avancée et sélectionnez les propriétés). La méthode d'authentification par défaut est toujours Kerberos parce qu'il s'agit de la plus simple et de la plus sécurisée. Cependant, pour des raisons de clarté, je vous recommande de la sélectionner lorsque vous créez vos règles. Normalement, vous n'authentifiez que l'ordinateur et pas l'utilisateur. Si vous nécessitez les deux, il se peut que vous ne puissiez pas accepter certains types de trafic de gestion, comme le trafic SNMP transmis anonymement.
Après avoir sélectionné la méthode d'authentification, il vous reste seulement à sélectionner les profils dans lesquelles vous voulez que cette règle soit disponible. Étant donné qu'il s'agit d'une règle qui s'applique aux ordinateur joints au domaine, qui peuvent présenter un ticket Kerberos, cela n'a pas de sens de l'utiliser pour les profils privé ou public. Pour finir, enregistrez la règle.
Les règles fondamentales d'isolation ne sont plus compliquées. Cependant, pour tirer parti de la puissance d'IPSec pour l'isolation, vous devez implémenter l'isolation de serveur, même sur vos postes de travail. Vous pouvez ainsi empêcher vos postes de travail d'écouter les autres clients. Ils répondront seulement aux stations de gestion appropriées. Imaginez à quel point vous pourriez réduire l'impact des attaques de programmes malveillants si les systèmes client refusaient d'écouter d'autres clients.

Écriture du script de pare-feu
Le nouveau pare-feu est fourni avec une API substantielle qui vous permet d'écrire le script de déploiement et d'évaluation. Idéalement, vous devez utiliser la Stratégie de groupe pour le déploiement, mais étant donné que la Stratégie de groupe n'est pas toujours disponible, il est important d'avoir un jeu d'API approprié pour configurer le pare-feu. Les API sont groupées sous le jeu d'API INetFWPolicy2. Le Kit de développement logiciel et MSDN® Library contiennent plus de détails sur la façon de les utiliser, mais quelques exemples illustrent bien ce point.
Un exemple courant est le besoin de déterminer si un groupe de règles est activé. Par exemple, supposons qu'une application ou un administrateur doive déterminer si le partage de fichiers et d'imprimante est autorisé depuis un système. Pour cela, vous pouvez utiliser INetFWPolicy2::IsRuleGroupCurrentlyEnabled. La figure 4 fournit un échantillon de VBScript qui démontre cette fonction.
Figure 4 Utilisation de INetFWPolicy2::IsRuleGroupCurrentlyEnabled
' Create the FwPolicy2 object.
Dim fwPolicy2
Set fwPolicy2 = CreateObject("HNetCfg.FwPolicy2")

' Get the Rules object
Dim RulesObject
Set RulesObject = fwPolicy2.Rules

'Create a profile object
Dim CurrentProfile
CurrentProfile = fwPolicy2.CurrentProfileTypes

'Check whether File and Printer Sharing is on, and turn it on if not
if fwPolicy2.IsRuleGroupEnabled(CurrentProfile, "File and Printer Sharing") <> TRUE then
    fwPolicy2.EnableRuleGroup CurrentProfile, "File and Printer Sharing", TRUE
end if
Si le partage de fichiers et d'imprimante est désactivé et que vous devez l'activer, vous devez d'abord vous assurer que c'est possible et que cela ne sera pas annulé par la Stratégie de groupe. Pour cela, utilisez l'API INetFWPolicy2::LocalPolicyModifyState. La structure, qui peut être remplie avec du code, est donnée ici :
Const NET_FW_MODIFY_STATE_OK = 0
Const NET_FW_MODIFY_STATE_GP_OVERRIDE = 1
Const NET_FW_MODIFY_STATE_NO_EXCEPTIONS = 2

Dim PolicyModifyState
PolicyModifyState = fwPolicy2.LocalPolicyModifyState
Select Case PolicyModifyState
  Case NET_FW_MODIFY_STATE_OK
  Case NET_FW_MODIFY_STATE_GP_OVERRIDE
  Case NET_FW_MODIFY_STATE_NO_EXCEPTIONS
End Select

Ligne de commande et types d'interfaces
Aucun pare-feu ne serait complet sans une ligne de commande correcte pour la gestion. Il y a un sous-contexte sous netsh, appelé advfirewall. Le contexte advfirewall vous donne accès par une ligne de commande à tout ce que vous pouvez faire dans l'interface utilisateur graphique. Par exemple, si vous voulez implémenter le bloc sortant sur le port 445, vous pouvez exécuter la commande suivante à partir d'une invite de commande élevée :
netsh advfirewall firewall add rule name="Block CIFS Out in the Public profile"
dir=out action=block enable=yes profile=public
localIP=any remoteIP=any remoteport=445 protocol=TCP interfacetype=any
Vous devez alors exécuter la même commande, en remplaçant TCP par UDP pour compléter le bloc. À ce stade, vous avez terminé la mise en œuvre de la règle.
L'une des fonctionnalités les plus utiles du pare-feu est la capacité à configurer des règles basées sur le type d'interface de réseau. N'oubliez pas que certaines règles peuvent avoir un impact sur les connexions VPN. Tant que Windows reconnaît l'interface comme une interface VPN, vous pouvez utiliser ce type de règle pour exempter le trafic sur cette interface :
netsh advfirewall firewall add rule name="Allow CIFS on VPN interfaces"
dir=out action=allow enable=yes profile=public localIP=any
remoteIP=any remoteport=445 protocol=TCP interfacetype=RAS
Vous pouvez également le faire dans l'interface utilisateur graphique, mais pas avant d'avoir créé la règle. Vous devez ensuite cliquer sur la règle avec le bouton droit de la souris, sélectionner des propriétés et cliquer sur l'onglet Avancé. Cet onglet contient une section de types d'interface qui vous permet de sélectionner les types d'interface appropriés.

Filtrage sortant
Le fait que le pare-feu Windows XP SP2 n'inclut pas de filtrage sortant a été utilisé pour démontrer que le pare-feu intégré était inadéquat pour la sécurité. Des milliers d'articles ont été écrits sur le manque de filtrage sortant du pare-feu Windows XP SP2, et ce malgré le fait qu'aucun pare-feu sous Windows XP ne pourrait fournir de façon sécurisée un filtrage sortant.
La fonctionnalité fondamentale qui fait du filtrage sortant un composant de sécurité utile plutôt qu'un simple « ralentisseur » (ou outil de mise en application de stratégie, comme mentionné précédemment) n'existe tout simplement pas dans Windows XP. Elle est cependant présente dans Windows Vista. Il est donc logique que le nouveau pare-feu utilise cette fonctionnalité. Par défaut, la plupart du trafic entrant est bloqué et la plupart du trafic sortant est autorisé.
Par défaut, le filtrage sortant dans le nouveau pare-feu de Windows Vista bloque uniquement le trafic inutile provenant des services. C'est tout ce que vous pouvez faire pour fournir une protection contre un compromis sur l'hôte qui fournit les filtres sortants, et il serait superflu de faire la même chose dans Windows XP.
Les services de Windows Vista peuvent s'exécuter avec un jeton extrêmement limité. En gros, chaque service a son propre identificateur de sécurité (SID), qui est unique pour ce service. Ce SID de service peut être utilisé pour limiter l'accès aux ressources, telles que les ports réseau. Il s'agit de la même fonctionnalité que nous avons vue précédemment lorsque nous avons examiné la restriction du trafic pour les utilisateurs. En conséquence, bien que deux services puissent s'exécuter comme NetworkService, ils ne peuvent pas gérer les processus de l'un l'autre et le pare-feu peut être configuré pour autoriser seulement l'un d'eux à communiquer vers l'extérieur. Si celui qui est bloqué est compromis, il ne peut pas détourner le service autorisé et utilise son port autorisé pour communiquer vers l'extérieur car le port est limité par le SID de service.
Cette fonctionnalité est un autre des composants de sécurité utiles ajoutés à Windows Vista, et le nouveau pare-feu l'utilise pour fournir une valeur de sécurité ajoutée grâce au filtrage de pare-feu sortant.
En effet, le filtrage de pare-feu sur les SID de service est activé par défaut dans le nouveau pare-feu. Cependant, il n'y a pas d'interface utilisateur pour le configurer. Les règles sont prédéfinies dans la clé de registre HKLM\System\CurrentControlSet\services\sharedaccess\parameters\firewallpolicy\RestrictedServices. Sachez cependant que la modification manuelle de cette clé n'est pas prise en charge.

Quel niveau de sécurité le filtrage sortant offre-t-il ?
Le niveau de sécurité offert par le filtrage sortant est souvent un sujet de malentendu dans la communauté des spécialistes de la sécurité. Jusqu'à présent, j'ai mentionné deux scénarios qui fournissent une sécurité par filtrage sortant, mais ils sont tous deux basés sur la nouvelle fonctionnalité de Windows Vista qui n'était auparavant pas disponible. Malgré cela, il y a une perception générale que le filtrage sortant est une bonne chose et doit être un facteur clé dans les décisions d'achat de pare-feu.
Ironiquement, dans beaucoup d'organisations, les capacités de filtrage sortant influencent la décision d'achat, alors qu'elles ne sont pas utilisées une fois le pare-feu implémenté. Cette décision est peu judicieuse et représente un gaspillage d'argent et d'efforts du groupe de sécurité de l'information. Elle semble être motivée plus par un désir de faire quelque chose pour la sécurité que par l'analyse d'une vraie menace. Trop souvent, ce type de sécurité conduit à des décisions qui devraient plutôt être basées sur des faits.
Il y a un fait très simple au sujet du filtrage sortant que ses partisans ne prennent pas en compte. L'argument habituel des fournisseurs de pare-feu basés sur hôte est que si un système est compromis (par un ver ou par un utilisateur malveillant interactif), le filtrage sortant empêche le ver d'infecter les autres systèmes ou le pirate de communiquer vers l'extérieur. Ce n'est pas vrai.
Ce qui est vrai c'est que, dans les mêmes conditions, le filtrage sortant aurait arrêté un logiciel malveillant déjà connu. Cependant, si Windows XP avait été fourni avec le filtrage sortant, les vers que nous avons vus jusqu'à présent auraient probablement été écrits pour le désactiver ou le contourner.
Sous Windows XP (et les versions précédentes de Windows), n'importe quel ver s'exécutant comme un service (et tous les vers courants étaient exécutés comme un service) aurait pu faire ceci. La seule raison pour laquelle cela n'a pas été fait est qu'il n'y avait pratiquement pas d'environnement utilisant le filtrage sortant et il aurait donc été inutile de le désactiver. Dans une attaque interactive, le pirate peut facilement contourner des filtres sortants. Si le pirate a la capacité d'exécuter le code arbitraire, c'est facile. Si nécessaire, le pirate peut également faire en sorte que l'utilisateur contourne les filtres.
Le contournement des filtres de pare-feu sortants basés sur hôte peut être accompli de plusieurs façons, selon le scénario de l'attaque. La façon la plus simple consiste à « demander » à un utilisateur superprivilégié de le faire pour vous. Trop d'environnements exécutent encore leurs utilisateurs comme administrateurs. Ces utilisateurs ont le droit de contourner les stratégies de sécurité à volonté. Il suffit au pirate de présenter à l'utilisateur un choix entre un avantage de sécurité intangible et non immédiat et quelque chose que l'utilisateur considère comme plus important.
Dans beaucoup de cas, l'utilisateur a été tellement inondé de ces types de boîtes de dialogue qu'il clique rapidement sans comprendre réellement ce qui se passe. C'est le problème principal du filtrage sortant. Entre la sécurité et la promesse de téléchargements attrayants, l'utilisateur choisira toujours ces derniers car la grande majorité des boîtes de dialogue demandant aux utilisateurs de prendre des décisions de sécurité sont dépourvues d'informations qui leur permettraient de prendre une telle décision.
Créer des boîtes de dialogue demandant à l'utilisateur de prendre des décisions de sécurité avec suffisamment d'informations est beaucoup plus difficile qu'il ne semble car cela nécessite que le produit de sécurité, comme le pare-feu, non seulement comprenne les ports, les protocoles et l'application qui fait la demande, mais également ce que l'application essaie vraiment de faire et ce que cela signifie pour l'utilisateur. Cette information est très difficile à obtenir par programmation. Par exemple, le fait que Microsoft Word tente de faire une connexion sortante n'est pas aussi intéressant que la raison pour laquelle Word cherche à établir cette connexion.
Nous devons réduire et non augmenter le nombre de boîtes de dialogue inutiles et les pare-feu avec filtrage sortant ne font rien pour aider la situation. Pour savoir ce qui se fait de mieux dans le domaine de l'information offerte à l'utilisateur, j'ai examiné la documentation de vente d'un fournisseur important de pare-feu basé sur hôte. La brochure vente la capacité de filtrage sortant et de conseil du pare-feu. La capacité de conseil détecte ce que l'utilisateur tente de faire et fournit le conseil approprié. Enfin, en théorie... Le texte de la brochure était accompagné d'une capture d'écran indiquant que la capacité de conseil n'est pas encore disponible avec ce programme. Les seules informations données sont des informations d'aide. Il semble que même dans le matériel marketing, les fournisseurs ne peuvent pas produire de boîtes de dialogue instructives.
Puisque les utilisateurs ne possèdent pas les informations suffisantes pour prendre les bonnes décisions de sécurité, il est de la responsabilité de l'administrateur de configurer tout le filtrage sortant car l'utilisateur final n'est pas en mesure de le faire. Ceci augmente considérablement la charge de l'administrateur.
Même si l'utilisateur clique sur une option du type « Me demander plus tard » lorsqu'il est sollicité par le pare-feu, le logiciel malveillant peut généralement contourner le pare-feu. Tant que l'utilisateur sous lequel le code malveillant s'exécute peut ouvrir des connexions sortantes sur un certain port, le code malveillant peut simplement utiliser ce port. Ainsi, n'importe quel processus peut s'accrocher à un processus existant. Cela est autorisé sur les systèmes d'exploitation secondaires. En commençant par Windows Vista, les processus peuvent être raisonnablement limités et c'est pour cette raison que les services, qui sont ceux limités par défaut, sont bloqués par les filtres sortants par défaut.
Malheureusement, la plupart des gens pensent que le filtrage sortant des pare-feu basés sur des hôtes empêche un élément compromis d'attaquer les autres. Cela n'est pas possible. Le fait d'appliquer des mesures protectives sur un élément compromis et de lui demander de ne pas compromettre les autres éléments ne fonctionne pas. La protection doit se situer au niveau de l'élément que vous tentez de protéger et non sur celui contre lequel vous voulez une protection. Demander à un cambrioleur de ne pas voler une fois qu'il a déjà cambriolé votre maison n'est pas aussi efficace que de l'empêcher en premier lieu d'entrer dans votre maison.

Jesper M. Johansson est architecte logiciel chargé du développement de logiciels de sécurité. Il contribue à l’élaboration de TechNet Magazine. Titulaire d'un doctorat en systèmes d'informations de gestion, il a plus de 20 ans d'expérience dans le domaine de la sécurité et est MVP Microsoft dans le domaine de la sécurité d'entreprise. Son dernier ouvrage s'intitule Windows Server 2008 Security Resource Kit.


Sécurité
Sécurisation du courrier électronique grâce aux certificats numériques
Matt Clapham and Blake Hutchinson
Vue d'ensemble:
  • Création d'une identité vérifiable
  • Mise à jour du statut de certificat
  • Obtention et échange de certificats
  • Dépannage de votre système de S/MIME

Depuis des milliers d'années, les humains utilisent diverses méthodes pour masquer les informations en transit, valider les expéditeurs et authentifier les messages. À mesure que la civilisation a évolué, une méthode pour effectuer ces trois tâches a été développée et devient largement utilisée. Les signatures numériques S/MIME
constituent un système permettant d'envoyer du courrier électronique en toute sécurité à l'aide du chiffrement et des signatures numériques.
Les technologies de chiffrement actuelles (masquage) appartiennent à deux types principaux : Les algorithmes à clé symétrique (secrète), comme DES (Data Encryption Standard) ou AES (Advanced Encryption Standard) (les CA) et les algorithmes à clé asymétrique (publique/privée) comme RSA ou ECC (Elliptical Curve Cryptography). Les outils modernes de validation de l'expéditeur sont des fonctions mathématiques unilatérales appelées hachages qui effectuent des signatures uniques. Deux méthodes de hachage utilisées couramment sont Message Digest algorithm 5 (MD5) et Secure Hash Algorithm (SHA). Les ordinateurs peuvent utiliser celles-ci pour générer un hachage ou un numéro unique qui correspond au texte source individuel (hachage des textes sources identiques à la même valeur). Ces outils simples sont exploités et combinés pour générer un système d'infrastructure de clé publique (PKI).

Une identité vérifiable
Ressources sur l'Autorité de certification
  • Utilisation d'une Autorité de certification pour la fonctionnalité EFS (Encrypting File Service)
  • Les serveurs de l'Autorité de certification ne peuvent pas être renommés ou supprimés du réseau
  • Comment supprimer une Autorité de certification approuvée à partir des ordinateurs du domaine
  • Comment faire pour désactiver une autorité de certification d'entreprise Windows et supprimer tous les objets associés de Windows Server 2003 et Windows 2000 Server
  • Comment déplacer une autorité de certification vers un nouveau serveur s'exécutant sur un contrôleur de domaine

Les identités d'un système PKI sont gérées à l'aide de certificats numériques, qui ne sont pas différentes du passeport que portent la plupart des gens lorsqu'ils traversent une frontière internationale. Le standard de passeport du monde du certificat numérique est le format X. 509, et il est largement utilisé pour la signature et le chiffrement dans les technologies comme S/MIME, Internet Protocol Security (IPsec), Secure Shell (SSH), la sécurité de réseau sans fil, les réseaux privés virtuels (VPN) et même les communications sécurisées des serveurs (comme les sites Web SSL).
Les certificats sont basés sur la cryptographie asymétrique et les hachages. Pour créer un certificat, le demandeur (l'entité souhaitant une clé signée par une autorité plus élevée) génère une clé privée. La clé est verrouillée de sorte que son authenticité ne constitue jamais une difficulté. En même temps que la clé privée, une clé publique correspondante est également générée. Comme son nom l'indique, la portion publique de cette paire n'est pas secrète et est distribuée gratuitement, quoique toujours d'une façon qui garantit son authenticité.
Cette paire de clés permet deux opérations fondamentales. Tout d'abord, n'importe qui peut utiliser la clé publique pour chiffrer quelque chose que seule la clé privée peut déchiffrer. En second lieu, la clé publique peut être utilisée pour déchiffrer un élément chiffré avec la clé privée. C'est important pour vérifier une signature que seule une clé privée aurait pu créer.
La requête à l'autorité de certification inclut des détails comme l'identité de la personne ou de l'ordinateur à laquelle la clé est destinée, le type et la force de l'algorithme et la portion publique de la paire de clés. L'autorité de certification (CA) reçoit et valide les informations de la requête et, utilisant un algorithme de hachage, crée un identificateur unique correspondant aux informations.
À l'aide de sa clé privée, l'autorité de certification chiffre le hachage des informations et les rassemble dans un format standard (comme X.509), en créant un certificat qui correspond à la requête originale. Le certificat X.509 contiendra une liste de déclarations y compris l'identité du certificat (le sujet), une période de validité, la clé publique et les opérations pour lesquelles le certificat peut être utilisé. Le certificat est alors renvoyé au demandeur. Il s'agit d'un jeton qui déclare, en effet, « moi, l'autorité de certification, je me porte garante de cette clé publique et de la portion privée correspondante, pour toutes les utilisations décrites dans ce document ».
Pour les autorités de certification racine (ceux qui sont au plus haut niveau de la chaîne de confiance), les certificats sont autosignés. La plupart des autorités de certification racine acceptables sont préinstallées dans le système d'exploitation de base ou l'application mais peuvent être mis à jour ou modifiés via la configuration de packages ou d'entreprise. Entre l'autorité de certification racine et un nœud terminal (qui décrit généralement une personne ou un système individuel), il peut y avoir une ou plusieurs autorités de certification intermédiaires.
La chaîne comprend tous les nœuds et tous les certificats précédents intégrés à ceux-ci, signés par l'autorité de certification à ce niveau. Un tiers essayant de valider le certificat peut vérifier le hachage calculé localement et le comparer à celui qui est déchiffré à partir du certificat utilisant la clé publique correspondante pour cette autorité de certification ou cet individu particulier. C'est une chaîne de confiance entièrement validée de la feuille à la racine, en supposant, bien sûr, que la racine soit approuvée.

Mise à jour du statut de certificat
Chaque autorité de certification correcte dispose d'un moyen de distribuer une liste de certificats qui ne sont plus fiables. Cette liste de révocation de certificats (CRL) décrit quels éléments publiés ont été annulés de façon spécifique par l'autorité de certification. Pour plus de commodité, l'emplacement du CRL est généralement une propriété du certificat de l'autorité de certification.
Les autorités de certification émettent régulièrement des CRL sur deux bases : un programme (peut-être toutes les deux semaines) ou un événement (une occurrence qui indique qu'un certificat émis n'est plus fiable). Une autorité de certification signera ses CRL émis lorsqu'il les publie. Lorsqu'un système de réception évalue la validité d'une chaîne, il tente généralement d'acquérir le CRL pour chaque CA émettrice de la chaîne (via les informations intégrées dans les certificats eux-mêmes ou via le mécanisme de distribution fiable prédéfini). Si une CRL est indisponible, le client peut avoir recours à une copie récente, mise en cache avec succès si elle n'est pas plus ancienne que la période de mise à jour de CRL spécifiée. Si cela ne marche pas, cependant, les systèmes client afficheront généralement une erreur indiquant que le certificat paraît valide mais l'état de révocation ne peut pas être déterminé.
De nombreuses applications prennent beaucoup plus de temps pour charger un certificat s'ils sont incapables de valider la chaîne ou la CRL pour chaque nœud de la chaîne. Selon ce que le certificat protégeait, l'utilisateur peut ne pas vouloir lui faire confiance. Un point de distribution de CRL régulièrement mis à jour largement disponible est absolument nécessaire pour chaque CA, surtout pour ces racines publiques.
Les racines sont la base de la chaîne de certificats et le chaînage est la base de toutes les hiérarchies de certificats. La plupart des systèmes ou applications client supposeront seulement qu'un certificat de nœud terminal est valide s'il est relié à une racine de confiance. Cela pourrait être une CA d'entreprise, possédée et utilisée par cette entreprise particulière ou cela pourrait être une CA racine publique (comme VeriSign).
Pour les CA racine publiques, il existe des attentes d'expertise opérationnelle significative pour que l'intégrité soit assurée. Les entreprises doivent parvenir au même niveau pour leurs opérations internes, comme l'intégrité d'une CA racine dans ce contexte est tout aussi importante. Pour une protection optimale, les CA racine doivent être conservées hors ligne et utilisées uniquement pour émettre les certificats et mettre à jour les CRL. Pour plus d'informations sur les méthodes opérationnelles recommandées des autorités de certification, consultez les articles énumérés dans l'encadré « Ressources sur l'Autorité de certification ».
Un aspect important à prendre en compte est la récupération des clés. Pour faciliter les investigations et assurer que les données ne sont pas irrémédiablement verrouillées par un utilisateur, l'entreprise doit effectuer des copies de sauvegarde de toutes les clés émises par les utilisateurs. De plus, ces copies de sauvegarde doivent être enregistrées dans un référentiel sécurisé. De cette façon, si une clé d'utilisateur disparaît, par exemple lorsqu'une carte à puce est oubliée dans un taxi, tout contenu protégé par la clé est toujours accessible.
Enfin, dans tout bon système cryptographique, on trouve le concept de gestion de cycle de vie. À mesure que les ordinateurs deviennent plus rapides, les algorithmes deviennent plus faibles. Tout bon système de chiffrement doit pouvoir se renouveler et passer progressivement à de nouveaux algorithmes et tailles de clé. Les autorités de certification doivent être mises à jour de manière appropriée lorsque les faiblesses cryptographiques sont identifiées et que certaines fonctions sont introduites ou supprimées progressivement.

Implémentation de S/MIME
On distingue plusieurs étapes pour le démarrage, la composition, l'envoi et la réception du courrier électronique signé ou chiffré à l'aide de S/MIME. Nous aborderons les détails, les problèmes et les solutions potentielles à mesure que nous avançons dans un scénario S/MIME typique : deux utilisateurs s'envoyant l'un à l'autre un message signé et/ou chiffré à partir de deux forêts Active Directory® différentes et de chaînes d'autorité de certificat différentes (c'est-à-dire, à partir d'entités fonctionnellement séparées, dans la même entreprise ou pas) utilisant Microsoft® Office Outlook® 2007.
Nous supposerons que l'infrastructure nécessaire est déjà en place pour permettre les opérations que nous décrirons. Dans notre cas, nous utilisons un serveur de certificat d'entreprise intégré à Active Directory.

Obtention des certificats
La première tâche consiste à obtenir les certificats appropriés. Pour ce faire, vous ouvrez le Gestionnaire de certificats de la console MMC (certmgr.msc), cliquez avec le bouton droit sur le dossier Personnel, sélectionnez Toutes les tâches dans la liste contextuelle, puis sélectionnez Request New (Demander nouveau) dans la liste.
Cela permet de lancer l'Assistant d'inscription du certificat, comme illustré à la figure 1. Par défaut, plusieurs options orientées entreprise seront affichées, mais le plus important est le certificat utilisateur. Il sera utilisé pour activer plus tard les processus de signature et de chiffrement. Le certificat doit pouvoir être utilisé pour :
Figure 1 Demander un certificat
Figure 1 Demander un certificat (Cliquez sur l'image pour l'agrandir)
  • Les signatures numériques (en créant un message avec un cachet d'authenticité de son créateur)
  • Chiffrement de la clé (en protégeant une clé avec une autre clé pour les technologies comme le système de fichier EFS)
  • Courrier sécurisé (messagerie chiffrée qui ne peut être lue que par le destinataire prévu en possession de la clé privée correspondante)
Pour envoyer le message électronique S/MIME signé, la propriété de chiffrement de clés n'est pas nécessaire. Cependant, pour envoyer ou recevoir le courrier chiffré, cette propriété est requise, bien que la propriété de signature ne le soit pas. Par défaut, les modèles dans les services de certificats de Windows® activent ces trois propriétés. Si l'utilisateur n'est pas autorisé à demander de nouveaux certificats, aucun certificat ne sera affiché lorsque l'Assistant démarre. Si aucune autorité de certification d'entreprise n'est disponible, l'utilisateur verra s'afficher une « erreur d'inscription » indiquant que le domaine ou l'autorité de certification n'a pas pu être contactée. Pour cette description, nous supposerons qu'un seul certificat autorise la signature et le chiffrement.

Échange de certificats
La façon la plus facile pour deux utilisateurs de commencer à envoyer du courrier chiffré est simplement de s'envoyer l'un à l'autre des messages signés. Après avoir composé un message, l'utilisateur clique sur le bouton Signer. (Quelquefois le bouton est masqué par défaut dans Outlook jusqu'à ce qu'il soit utilisé pour la première fois. Vous pouvez le trouver en cliquant sur le paramètre Options pour les nouveaux messages, en cliquant sur le bouton « Paramètres de Sécurité... », puis activez la case à cocher « Ajouter une signature numérique à ce message ». Le bouton de signature (une petite enveloppe jaune avec un ruban rouge portant l'inscription Signer) ajoute une signature numérique au message pour établir l'authenticité de sa source.
En appuyant sur le bouton Envoyer, l'utilisateur peut être invité à fournir des jetons supplémentaires de possession de clé, par exemple en insérant une carte à puce ou en entrant un code confidentiel. Cela dépend des méthodes particulières de protection de clé en place dans l'entreprise.
L'utilisateur recevant le message signé S/MIME devra afficher et cliquer avec le bouton droit sur le nom de l'expéditeur (après De :) et sélectionner « Ajouter aux contacts Outlook » dans le menu contextuel, qui ajoute une nouvelle entrée de contact ou met à jour une entrée existante. Le certificat est alors associé à cette entrée de contact particulière. Notez que dans un environnement commun d'Active Directory (deux utilisateurs dans la même forêt ou la même entreprise), la distribution des certificats utilisateur publics est effectuée automatiquement via les attributs dans l'objet Active Directory de l'utilisateur.
Une autre façon d'échanger les certificats est pour chaque utilisateur d'envoyer ses certificats S/MIME en tant que pièce jointe. Pour ce faire, les deux partis devront exporter leurs certificats vers un fichier CER. Les utilisateurs devront afficher le certificat et suivre le processus d'exportation que nous aborderons bientôt, en faisant attention de ne pas exporter la clé privée en même temps, comme illustré à la figure 2.
Figure 2 Lors de l'échange des certificats, n'exportez pas la clé privée
Figure 2 Lors de l'échange des certificats, n'exportez pas la clé privée (Cliquez sur l'image pour l'agrandir)
Ensuite chaque destinataire crée manuellement une entrée de contact dans Outlook et ajoute le certificat à l'entrée de l'expéditeur. Une fois que les deux utilisateurs ont échangé des certificats, ils pourront échanger entre eux du courrier chiffré.

Dépannage
Quelquefois le destinataire a des difficultés à ouvrir le message chiffré. Les trois sources les plus probables de problèmes que nous avons vus dans cette zone sont des CA racine non fiables, des CA intermédiaires qui ne peuvent pas être validées et des CRL non disponibles.
Une CA racine non fiable affiche généralement dans Outlook comme message d'erreur associé à la signature : « Des problèmes sont liés à la signature. Cliquez sur le bouton Signature pour plus de détails.) Pour résoudre le problème, ouvrez le certificat dans Outlook et cliquez sur le bouton « Afficher une autorité de certification. » dans le menu contextuel. Regardez le message dans l'onglet Général de la boîte de dialogue des propriétés de certificat. S'il indique que le certificat de la CA racine n'est pas fiable et doit être installé, allez à l'onglet Détails. Cliquez sur le bouton « Copier dans un fichier... » et suivez l'Assistant, en acceptant toutes les valeurs par défaut et en fournissant un nom de fichier et de dossier lorsque vous y êtes invité.
Ouvrez maintenant une nouvelle console MMC (Microsoft Management Console) en tant qu'administrateur de machine. Accédez à Fichier|Ajouter/Supprimer un composant logiciel enfichable (Ctrl+M), sélectionnez Certificats et ajoutez-le pour le compte d'ordinateur, en choisissant l'ordinateur local lorsque vous y êtes invité. Développez ensuite le nœud Certificats dans l'arborescence à gauche, faites de même pour les autorités de certificat racine de confiance. Cliquez avec le bouton droit et sélectionnez Toutes les tâches|Importer dans le menu contextuel. Importez le fichier de certificat exporté mentionné précédemment vers les autorités de certificat racine de confiance puis cliquez sur Terminer. L'utilisateur concerné doit ensuite redémarrer Outlook.
Ces instructions doivent être utilisées uniquement pour ajouter une CA racine dont vous savez qu'elle est fiable. Toutes les racines ne sont pas égales. Examinez soigneusement qui possède et utilise la CA racine avant d'utiliser cette méthode pour ajouter une racine au magasin pour tout le système. Si votre entreprise contrôle la liste des racines de confiance via la stratégie de groupe, la configuration sera définie sur les systèmes client. Dans ce cas, les instructions peuvent ne pas fonctionner. Si c'est le cas, vous pouvez avoir besoin d'explorer des alternatives telles que les sites Web ou les serveurs sécurisés pour échanger des données, si le courrier électronique ne bénéficie pas d'un environnement transparent et protégé.
Le deuxième problème que nous avons vu ci-dessus, les CA intermédiaires ne peuvent pas être validées, survient généralement dans deux situations : un client essayant de valider le certificat est incapable d'obtenir l'emplacement de l'Accès aux informations de l'Autorité (AIA) défini dans le certificat, ou le client dispose d'une version certificat de la CA intermédiaire qui ne correspond pas au document émis par la CA (le client dispose souvent d'une version antérieure). Ces conditions semblent très similaires dans l'interface utilisateur d'Outlook. Nous l'avons vu seulement dans une circonstance bien particulière lorsqu'une CA intermédiaire dans la chaîne expire et est réémise avant que les autres certificats subordonnés émis aient expiré.
Fondamentalement, ce problème survient lorsque la chaîne comprend des vides. Certains certificats parent peuvent ne pas être détaillés ou intégrés de manière appropriée dans le nœud terminal, ce qui complique la situation.
Pour résoudre ce problème, l'expéditeur devra ouvrir un nouveau message et cliquer sur les Options pour les nouveaux messages, sur le bouton Paramètres de Sécurité, puis sur le bouton Modifier les paramètres. Cliquez maintenant sur le bouton Choisir pour le certificat de signature, puis sur le bouton Afficher le certificat dans le menu contextuel. Accédez à l'onglet de Chemin d'accès de certification, sélectionnez l'émetteur du nœud terminal (un niveau plus haut dans la chaîne) et cliquez sur le bouton Afficher le certificat. Cliquez sur l'onglet Détails, sur le bouton Copier dans un fichier..., puis terminez l'Assistant d'exportation, en sélectionnant PKCS #7 (.P7B). Assurez-vous que l'option « Inclure tous les certificats dans le chemin d'accès de certification » est activée, comme illustré à la figure 3. Enfin, envoyez le fichier de chaîne exporté au destinataire souhaité.
Figure 3 Résolution des vides dans une chaîne de certificats
Figure 3 Résolution des vides dans une chaîne de certificats (Cliquez sur l'image pour l'agrandir)
Après avoir obtenu la chaîne de certificats exportée, le destinataire devra ouvrir et importer la chaîne tout comme nous avons importé une racine précédemment. La seule différence est que le dossier de stockage choisi doit être celui des Autorités de certification intermédiaires. Si le message s'ouvre et que le certificat est affiché comme valide dans Outlook, les choses fonctionnent correctement.
Quant au troisième problème, les CRL non disponibles, ce problème est relativement facile à corriger. La réponse initiale d'Outlook paraîtra très similaire au problème précédent. Cependant, l'erreur s'affichera même si les CA de signature racine ou intermédiaires sont fiables. Pour chaque niveau de la chaîne de certificats au-dessus de la feuille, ouvrez les propriétés de certificat, puis l'onglet de détails et regardez le champ appelé « Points de distribution de la liste de révocation de certificats ».
Pour chaque point de distribution CRL énuméré (surtout ceux qui sont accessibles sur Internet), vérifiez que l'URL du fichier CRL peut être ouverte. Comme chaque niveau est validé, montez d'un niveau dans la chaîne. Si aucune CRL ne peut être acquise, c'est probablement la source du problème. Pour résoudre le problème, vous devez vérifier que votre stratégie de réseau locale ne bloque pas votre accès. Sinon, essayez de contacter l'entreprise qui possède l'autorité de certification ou attendez que le point de distribution CRL de celle-ci revienne à l'état opérationnel.

Certificats de distribution
La distribution est le plus facile. Le message signé est transmis à un serveur de messagerie, qui l'envoie ensuite d'un emplacement à un autre via une méthode éprouvée, SMTP. Le problème que nous avons vu avec le courrier signé ou chiffré en transit est que certains systèmes de courrier refusent ou arrêtent des messages signés ou chiffrés qui passent par eux. La solution est de travailler avec le responsable informatique du système pour obtenir les types de message autorisés. Bien sûr, vous pouvez avoir à assumer le fait que certains types de message sont bloqués. La partie qui reçoit peut avoir une bonne raison pour ne pas autoriser de messages chiffrés dans un environnement d'exploitation particulier.

Réponses de chiffrement
Pour créer une réponse chiffrée (en supposant que le processus de démarrage décrit ci-dessus est déjà terminé), l'expéditeur doit créer seulement un message puis cliquer sur le bouton Chiffrer (la petite enveloppe jaune avec le cadenas bleu portant l'inscription Chiffrer) dans la fenêtre de composition du message. Si ce bouton est indisponible, suivez la procédure d'envoi d'un message signé, sauf à la dernière étape et activez la case à cocher « Crypter le contenu des messages et des pièces jointes ».
La signature S/MIME n'est pas nécessaire pour envoyer un message chiffré à un destinataire, mais les deux fonctionnent certainement bien ensemble, puisque la signature permet au lecteur de valider l'expéditeur (la fonction de chiffrement ne demande rien à l'expéditeur). Le processus de chiffrement essaiera de chiffrer le message avec les clés publiques connues de tous destinataires. Si le système est incapable de trouver des certificats pour certains destinataires souhaités, ils seront marqués dans un menu contextuel qui offre d'envoyer le message non chiffré, comme illustré à la figure 4.
Figure 4 Vous pouvez décider d'envoyer un message non chiffré si vous rencontrez un problème avec un certificat
Figure 4 Vous pouvez décider d'envoyer un message non chiffré si vous rencontrez un problème avec un certificat (Cliquez sur l'image pour l'agrandir)
Par défaut, la signature et le chiffrement doivent fonctionner avec les autres systèmes client configurés de manière similaire, mais parfois la messagerie interversion chiffrée ou signée peut présenter des problèmes si le hachage ou l'algorithme de chiffrement ne sont pas pris en charge à un niveau inférieur. Nous avons rencontré ce problème en envoyant un message électronique signé (utilisant SHA-512 comme algorithme de hachage) à un utilisateur exécutant Windows XP SP2. Comme le système de réception ne prenait pas en charge le hachage, l'utilisateur ne pouvait pas valider la signature ou lire le message. Cependant, il est peu probable que des utilisateurs rencontrent beaucoup de problèmes à ce stade sauf si les valeurs par défaut d'Outlook sont modifiées.
En recevant le message, le destinataire souhaité doit pouvoir l'ouvrir, étant donné que la clé privée associée au certificat public est disponible. Encore une fois, l'utilisateur peut être invité à fournir un jeton supplémentaire pour prouver la possession de la clé privée, en fonction de la manière dont elle a été déployée. Les autres utilisateurs qui ont effectué un processus de démarrage similaire peuvent bénéficier de communications similaires, signées et chiffrées avec l'expéditeur. Si un utilisateur modifie sa clé privée à un certain moment (peut-être en raison d'un ordinateur perdu), il devra redemander des certificats et redistribuer un fichier de message ou de certificat signé à d'autres personnes qui souhaitent échanger le courrier chiffré.

Conclusion
Le fonctionnement de la messagerie S/MIME signée et chiffrée entre deux utilisateurs appartenant à deux entreprises ou annuaires différents n'est généralement pas beaucoup plus compliqué que ce dont nous venons de parler. La signature est très pratique lorsqu'elle est utilisée correctement, car elle ajoute de l'authenticité au message. Pour les informations sensibles, le chiffrement fournit un niveau supplémentaire de confidentialité pour les données en transit. Combinés, les deux éléments permettent l'authenticité de la source et la confidentialité des données. Avec le processus que nous avons décrit ici, la plupart des utilisateurs profiteront sans difficulté de ces fonctionnalités.

Matt Clapham, CISSP, est ingénieur sécurité dans le service informatique de Microsoft. Pendant la journée, il effectue des évaluations de sécurité sur les applications métier et la nuit il joue avec la technologie, les jeux, la musique électronique ou la sécurité. Il parle de temps en temps à la communauté informatique dédiée à la sécurité Puget Sound. Vous pouvez le contacter à matt.clapham@microsoft.com.
Blake Hutchinson est analyste support dans le groupe Business Online Services Group (BOSG) chez Microsoft. Son rôle inclut le support d'exploitation et l'évaluation d'outils métier créés à usage interne pour les clients d'entreprise de BOSG. Blake apprécie la photographie, le ski et les jeux électroniques. Vous pouvez le contacter à blakeh@microsoft.com.


Le mot du rédacteur en chef Le grand débat
Joshua Hoffman

J'adore les grands débats. Je ne parle pas des petites querelles de clocher, lorsque des opinions différentes et des personnalités fortes entraînent des conflits stupides. Quelle perte de temps. Mais un vrai grand débat, où des gens intelligents avec des points de vue opposés présentent avec passion leurs arguments pour les confronter, c'est une chose puissante. Pensez connaissances. Pensez à Socrate.
Ce mois-ci, nous vous présentons un des vrais grands débats sur le secteur de l'informatique, la sécurité par l'obscurité. J'expliquerai ce concept ici, mais je soupçonne que dès que vous aurez lu cette expression, la plupart d'entre vous exprimerez déjà votre opinion sur le sujet et probablement haut et fort. Je fais également le pari que la plupart d'entre vous appartenez à l'un de ces deux camps : soit « la sécurité par l'obscurité est complètement inutile » soit « quand il s'agit de la sécurité, il ne faut rien négliger ».
Bien, ce mois-ci nous réunissons les experts en sécurité renommés Jesper Johansson et Roger Grimes pour présenter les deux parties à ce débat. Nous avons inclus également les commentaires de soutien pour chacun d'eux, de deux autres spécialistes, Aaron Margosis et Steve Riley. Alors que je suis certainement fier de chaque page que nous publions, je dois admettre que c'est l'un de mes articles préférés. J'espère que, quelle que soit votre opinion dans ce grand débat, vous lirez cet article avec un esprit ouvert. Je suis persuadé que vous l'apprécierez.
Comme il s'agit de notre numéro annuel sur la sécurité, il contient, bien sûr, de nombreuses autres informations. Nous abordons à nouveau certains sujets que nous avons étudiés dans le numéro de l'année dernière. Un des articles les plus populaires de l'année dernière a traité de la série Elévation de script Power Toys du rédacteur Michael Murgolo, qui permet d'exécuter les scripts VBScript ou Windows PowerShell dans un contexte élevé conjointement avec la fonctionnalité de contrôle des comptes utilisateur de Windows Vista. Michael a reçu beaucoup de commentaires très positifs sur cet article, donc il revient cette année avec une nouvelle série complète d'utilitaires pour étendre son code original. Je vous invite à essayer ces outils très puissants.
Byron Hynes était également avec nous l'année dernière, avec une présentation du chiffrement de lecteur BitLocker dans Windows Vista. Byron reprend son rôle avec un aperçu des modifications de BitLocker avec la version de Windows Vista SP1 et Windows Server 2008. Nous avons aussi des articles sur les stratégies de restriction logicielle, la gestion du Pare-feu Windows Vista, le dépannage S/MIME, la deuxième édition de notre nouvelle rubrique Au cœur de SharePoint, des idées métier pour promouvoir l'informatique durable etc. Amusez-vous bien ! —Joshua Hoffman

Grâce aux experts techniques Microsoft suivants : Troy Funk, Aaron Margosis, Michael Murgolo, Steve Peschka, Steve Riley, Mark Russinovich, Jon Schwartz et Jim Truher.


Lettres Les lecteurs ont la parole

Les sauvegardes Windows
J'ai été si passionné par la lecture de votre numéro sur Windows Server® 2008 (TechNet magazine, mars 2008, technet.microsoft.com/magazine/cc268370), que je suis allé à l'événement de lancement et j'ai obtenu une copie pour mon réseau domestique. Tout s'est bien passé pour l'installation. Cependant, j'ai été bloqué pour les sauvegardes.
NT Backup a été supprimé et la nouvelle Sauvegarde Windows Server ne prend pas en charge les lecteurs de bande, bien que le système d'exploitation le fasse. (Je sauvegarde mes données personnelles, y compris Active Directory® et Exchange Server 2007, sur un lecteur de bande).
J'ai essayé de télécharger Microsoft® Data Protection Manager (DPM) en suivant les conseils du site Web, même si DPM paraît excessif pour mon installation. Cependant, DPM ne peut pas s'installer sur Windows Server 2008 et je n'ai pas eu de chance avec leurs instructions d'installation manuelle. Que sont censées faire les petites installations pour les sauvegardes ?
—Ravi S.

DPM est en effet la solution pour les sauvegardes de bande, puisque la nouvelle solution dans Windows Server 2008 est optimisée pour le stockage sur disque. DPM prendra officiellement en charge Windows Server 2008 au cours des prochains mois.
—Karandeep Anand, responsable de programme principal chez Microsoft

Flux de travail de l'enquête
Dans l'article de février 2008 « Création d'une infrastructure d'enquête puissante » (technet.microsoft.com/magazine/cc194407), l'instruction suivante est dans la section Utilisation de WSS seul : « Vous pouvez également attribuer un flux de travail à l'enquête ».
C'est ma compréhension que Windows® SharePoint® Services 3.0 (WSS) et Microsoft Office SharePoint Server 2007 (MOSS) ne prennent pas en charge les flux de travail associés aux réponses à une enquête. J'ai essayé d'associer un flux de travail à une réponse à une enquête, et même si SharePoint Designer autorise l'association, le flux de travail a toujours une erreur d'échec de démarrage. Il existe un article de la Base de connaissances (support.microsoft.com/kb/926370) qui précise clairement que les flux de travail associés aux réponses à une enquête ne sont pas pris en charge.
Je comprends qu'il est possible d'associer un destinataire d'événement à une enquête et de lancer un autre processus, mais ce n'est pas vraiment un flux de travail référencé habituellement dans SharePoint. Cette instruction a-t-elle été faite par erreur, ou est-ce qu'il y a quelque chose qui m'échappe ici ?
—Matt B.

Le paragraphe référencé explique comment WSS fournit un Assistant pour un processus détaillé permettant de créer des enquêtes. Il y a également une discussion sur les diverses options (la logique de branchement, les questions ouvertes/fermées, etc.).
Une des options fournies par l'Assistant est l'attribution d'un flux de travail. Ainsi, d'une certaine manière, il n'est pas faux de dire que « vous pouvez également attribuer un flux de travail à l'enquête ». Vous pouvez l'attribuer. Cependant, comme vous le faites remarquer, les flux de travail dans les enquêtes ne fonctionnent pas tout simplement, bien que, malgré tout, cette option soit incluse. Je vais essayer de vous expliquer pourquoi.
Après avoir associé un flux de travail à une enquête et essayé de le démarrer, vous recevez une erreur d'échec de démarrage. Les journaux de cette activité affichent ceci :
RunWorkflow: System.ArgumentException: Invalid field name.
{<<< GUID>>>} at ...
Ce GUID représente l'instance du flux de travail. Cela semble être une façon idéale de s'assurer que le flux de travail correct est lancé, sauf que le type de liste d'« enquête » ne prend pas en charge l'attribut de flux de travail. Il n'est pas codé tout simplement. Si lorsque le flux de travail essaie de s'activer avec la méthode MakeActivation et fait quelque chose comme ceci :
internal static void MakeActivation(SPWorkflow workflow, SPWorkflowEvent e)
{e.EventData = new object[ ] { workflow.InstanceId, new SPWorkflowActivation
Properties(workflow, e.RunAsUserId, associationData, initiationData) };
...
}
Il appelle SPWorkflowActivationProperties, qui ressemble à ceci :
internal SPWorkflowActivationProperties(SPWorkflow workflow,
int runAsUserId, string associationData, string initiationData)
{
...
this.m_itemGuid = new Guid((string)
this.Item[SPBuiltInFieldId.GUID]);
...
}
Donc s'il prévoit la chaîne GUID comme attribut dans l'enquête (qui est apparemment supposée être intégrée) et que l'enquête n'a pas l'attribut pour le GUID de flux de travail, il ne peut jamais fonctionner.
Il y a une solution possible, donc vous êtes sur la bonne voie en pensant comme cela. La solution implique de créer une liste personnalisée qui déclenche un flux de travail et d'associer un destinataire d'événement à l'enquête avec ItemEventReceiver. Ce destinataire d'événement crée un élément dans la liste personnalisée, qui déclenche un flux de travail. Mais vous avez raison, ce n'est pas vraiment la même chose. Pour résumer, oui, vous aviez raison : il ne fonctionne pas en fait.
—Pav Cherny, chroniqueur, Au cœur de SharePoint, TechNet Magazine


Boîte à outils Nouveaux produits pour les professionnels de l’informatique
Greg Steen

Faites des annonces sur le réseau
NetSupport Notify
www.netsupportnotify.com
L'environnement de travail composé de PC est quasi omniprésent dans les entreprises. La plupart des utilisateurs sont devant leur écran pendant la journée et connectés à un réseau que vous aidez à administrer. Outre le transport pour les ressources partagées, les applications, et Internet, le réseau de votre entreprise peut être utilisé comme élément de la stratégie de votre entreprise pour la communication de messages importants aux utilisateurs. NetSupport Notifier, de NetSupport Limited, est un outil pouvant vous aider à remettre des messages aux utilisateurs sur les réseaux LAN et WAN.
Ce serveur d'applications léger vous procure une prise en charge de messagerie de diffusion rapide et fiable. Vous pouvez, par exemple, avertir facilement les utilisateurs d'une perte d'accès imprévue à une ressource partagée, informer des personnes que l'alarme de sécurité qu'ils entendent a été déclenchée par accident ou notifier les employés d'une situation d'urgence dans le bâtiment.
Certains outils de messagerie de diffusion simple peuvent s'avérer limités au réseau local sur lequel ils sont installés. NetSupport Notify, cependant, est basé sur un agent et avec son composant de passerelle de notification, il peut facilement traverser votre topologie de réseau, pour atteindre les clients Windows® et MAC, qu'ils soient directement connectés, sur une connexion sans fil ou connectés via un réseau privé virtuel.
Le service de notification s'exécute en tant que service Windows et vous vous connectez au service via la console de notification administrative, qui peut être installée sur le même ordinateur ou un ordinateur différent. Les notifications du service sont classées en trois niveaux de gravité : message, alerte ou critique. Une fois un message reçu par le client, une entrée de journal des événements est ajoutée et le serveur est notifié de la réception du message. Les autres options de message incluent l'émission d'un signal sonore s'ajoutant à l'affichage de la fenêtre, forçant la notification à toujours être visible, et la configuration d'un délai d'expiration automatique pour l'auto-fermeture du message.
Vous pouvez également choisir de cibler des groupes de notification spécifiques. La console de notification peut se connecter à plusieurs serveurs de notification et une console peut donc être le centre de diffusion de messages.
Outre le serveur et la console, NetSupport Notify inclut également un outil de déploiement qui vous permet de déployer à distance l'agent à vos utilisateurs finaux, en vous évitant de vous déplacer jusqu'à leur bureau. Vous pouvez spécifier des ordinateurs cibles en fonction d'une plage d'adresses IP ou avec la découverte de domaines réseau et groupes de travail Windows.
La console de déploiement vous donne également un aperçu rapide de votre réseau, vous indiquant la version de l'agent installée avec des informations d'identification telles que le nom DNS, l'adresse MAC, l'adresse IP, la plate-forme et si la console a accès à l'ordinateur distant. Si vous utilisez Active Directory®, vous pouvez gérer la configuration et le déploiement via la stratégie de groupe.
Pour la protection contre les diffusions non autorisées (telles que « Hé, c'est la fête dans mon bureau à 16h ! »), les agents et les consoles utilisent un code de sécurité similaire à une chaîne clé de Windows Management Instrumentation (WMI). Par ailleurs, vous pouvez contrôler la capacité à envoyer des alertes avec la stratégie Active Directory.
Prix : À partir de 180 USD pour une licence de 75 utilisateurs.
Remettez des annonces à vos employés avec NetSupport Notify
Remettez des annonces à vos employés avec NetSupport Notify (Cliquez sur l'image pour l'agrandir)

Contrôlez votre réseau
NetOptics : Teeny Tap
www.netoptics.com
Utilisées en combinaison avec une bonne application de surveillance, les prises robinet réseau passives peuvent constituer des outils vitaux pour le dépannage des réseaux douteux, résoudre les applications se comportant de manière incorrecte et atténuer les menaces potentielles envers votre infrastructure. Teeny Tap de NetOptics est une prise sur réseau pratique pour les réseau 10/100 qui a été portée à ma connaissance.
Ce « petit » appareil de 8x4 cm fournit une analyse du trafic en duplex complet à partir de la couche 1, vous permettant de facilement détecter ou surveiller en continu le trafic sur votre réseau 10/100. Le périphérique permet une analyse en duplex complet grâce à ses deux ports RJ45 de surveillance, ce qui vous procure un aperçu détaillé du trafic des deux côtés de ses ports réseau lorsque tous deux sont connectés à votre système de surveillance de réseau, votre analyseur de protocole, votre système de détection d'intrusion, de vérification de rendement ou autre.
Teeny Tap ne nécessite pas d'adresse IP. En vous isolant du réseau, vous pouvez rester invisible auprès de ceux qui peuvent utiliser votre présence comme signal pour arrêter de manipuler le réseau. Dans le même temps, la fonctionnalité de délai nul permet de s'assurer qu'une perte d'alimentation de la prise sur réseau n'affectera pas le flux du trafic au travers de celle-ci : aucune perte et aucun retard de paquets ne devraient se produire.
La prise sur réseau peut être alimentée par USB ou avec l'alimentation incluse. Vous pouvez utiliser les deux par souci de redondance, ce qui est une capacité remarquable pour un si petit appareil. Teeny Tap est également compatible avec les services Power over Ethernet, tels que les caméras réseau et les téléphones IP. Par conséquent, vous pourriez également contrôler le trafic sur ces points pour vous assurer que vos communications sont sécurisées.
Le kit Teeny Tap comprend la prise sur réseau, une alimentation universelle, deux câbles RJ45 croisés et deux droits, ainsi qu'une mallette de transport. Si vous recherchez quelque chose de plus puissant pour votre environnement, il peut être intéressant d'examiner les autres prises sur réseau proposées par NetOptics. La gamme de produits de la société couvre toute la portée, depuis les réseaux de petite entreprise jusqu'aux grands environnements d'entreprise pour les réseaux cuivre et fibre de 10 Mo/s à 10 Go/s.
Prix : 325 $ (achat direct).
Contrôlez votre réseau avec Teeny Tap
Contrôlez votre réseau avec Teeny Tap (Cliquez sur l'image pour l'agrandir)

Optimisez votre ordinateur
DTweak Pro
www.daoisoft.com
En tant que professionnel de l'informatique (et fan de technologie en général), vous avez sans aucun doute envie de bidouiller votre système, d'obtenir des performances aussi élevées que possible et une expérience personnalisée maximale pour vos activités quotidiennes. Il existe toute une gamme d'outils pour aider à optimiser et à personnaliser l'expérience utilisateur sur un ordinateur exécutant Windows Vista®. DTweak de Daoisoft est l'une des options bon marché. (il existe également une version pour Windows® XP et Windows Server® 2003.)
L'application offre plusieurs affichages permettant un accès rapide aux différents outils et personnalisations pour Windows Vista. Par exemple, dans la section des outils quotidiens, vous pouvez exécuter un nettoyeur de Registre, un utilitaire de nettoyage de fichiers, des outils de défragmentation de disque et de Registre, ainsi qu'un analyseur de performances de disque dur.
Avec DTweak, vous pouvez également facilement voir et adapter vos éléments de démarrage, obtenir des informations sur l'UC (y compris la référence d'UC, la vitesse de bus et la vitesse d'horloge), et rassembler des informations sur l'ordinateur, telles que le fournisseur, l'état de démarrage, la configuration mémoire et le type de système. Vous même pouvez ajuster votre mémoire cache d'E/S et la durée à attendre avant l'arrêt des programmes défaillants et des services bloqués.
La section d'outils d'interface utilisateur graphique fournit des liens vers les outils intégrés à Windows Vista, dont diskpart et la restauration du système, de même que des liens vers les outils réseau pratiques tels que finger, ping, netstat et nslookup. Les autres ajustements pratiques incluent le réglage de votre unité de transmission maximale, les paramètres TTL TCP/IP et les paramètres de délai d'attente maximal de DNS, ainsi que la limitation de votre bande passante avec le service Planificateur de paquets QoS.
Prix : 29,95 $ (téléchargement direct).
Ajustez et optimisez votre système avec DTweak
Ajustez et optimisez votre système avec DTweak (Cliquez sur l'image pour l'agrandir)

Critique
Microsoft Exchange Server 2007 Administrator's Companion
www.microsoft.com/mspress
La messagerie électronique peut être une bête farouche. Par exemple, vous ne possédez aucun contrôle sur le flux de messages entrants. Si vous essayez de conjurer une inondation entrante en interrompant votre serveur SMTP jusqu'à ce que ses files d'attentes soient réduites, vous risquez que l'expéditeur du message reçoive une notification de type « impossible de remettre le message ». L'analogie avec un système de plomberie est appropriée : l'eau coule toujours, et si vous fermez une vanne dans une section, vous risquez qu'une canalisation éclate dans une autre. Une infrastructure de message électronique bien planifiée, bien réglée et flexible est essentielle si vous voulez que votre entreprise fonctionne sans heurts.
Évidemment, Microsoft Exchange Server® 2007 a été conçu pour prendre en charge des volumes énormes de courrier et pour vous permettre d'adapter votre infrastructure aux besoins de votre organisation, ses besoins d'aujourd'hui comme de demain. Mais il existe beaucoup d'options et de décisions à prendre dans un déploiement Exchange 2007. Exchange couvre en outre beaucoup plus que la messagerie électronique, ce qui complique davantage la tâche.
Un ouvrage de référence ou deux sont véritablement nécessaires pour vous aider à prendre les bonnes décisions architecturales et d'administration. Microsoft Exchange Server 2007 Administrator's Companion est un ouvrage de référence qui peut s'avérer indispensable.
Ce livre couvre le cycle de vie de déploiement du produit, de la planification et du déploiement à la maintenance et la sécurité. Il aborde également les divers clients et les options de connectivité client disponibles pour Exchange 2007. Il commence par une présentation des différences entre les diverses versions et un examen des nouveautés d'Exchange 2007. Vous obtiendrez également une présentation complète des différents composants architecturaux d'Exchange Server 2007.
La section suivante explique comment planifier le déploiement d'Exchange et vous montre comment calculer vos besoins de stockage, vos exigences de serveur et processeur et ajouter la tolérance de pannes. Le livre couvre ensuite l'installation et le déploiement véritables, en vous montrant comment préparer votre serveur pour Exchange et comment installer les différents composants du logiciel. Vous obtiendrez même des informations de référence approfondies sur le regroupement de services d'Exchange pour obtenir un niveau de disponibilité plus élevé.
Le livre couvre ensuite les nombreux outils de gestion à votre disposition, comme le volet MMC d'Exchange et le nouveau shell d'administration basé sur Windows PowerShell™, Exchange Management Shell. Vous apprendrez ici également tout ce qui est nécessaire depuis la création de boîtes aux lettres jusqu'à la création de groupes de stockage et aux opérations de sauvegarde et restauration. L'un des autres atouts de cette section est qu'elle vous montre comment effectuer toutes ces opérations avec l'interface utilisateur graphique d'administration et via l'invite de commande avec Windows PowerShell.
Exchange 2007 possède plusieurs fonctionnalités de messagerie unifiées, qui vous permettent de gérer données et communications vocales avec un seul système. Le livre vous montre également comment configurer et utiliser la messagerie vocale, la messagerie par télécopie et l'accès vocal aux boîtes aux lettres, pour n'en nommer que quelques-uns.
En plongeant ensuite dans la maintenance, le livre couvre les techniques et les outils de dépannage essentiels, la récupération après incident et altération et le réglage des performances. La sécurité, évidemment, devrait être un souci essentiel de tout système de messagerie unifiée et l'ouvrage comporte des informations approfondies pour la sécurisation de votre déploiement. Vous découvrirez la stratégie et les recommandations de sécurité, les fonctionnalités antivirus et anti-courrier indésirable et l'infrastructure de clé publique.
Pour terminer, le livre explore les clients Exchange et comment prendre en charge d'autres clients POP3 et Internet Message Access Protocol dans votre organisation. Dans son ensemble, ceci est une bonne référence générale pour tout administrateur, qu'il planifie ou assure la maintenance d'une plate-forme de messagerie unifiée Exchange Server 2007 ou qu'il s'intéresse seulement à celle-ci.
Prix : 49,99 $ (liste).
(Cliquez sur l'image pour l'agrandir)

Greg Steen est un professionnel de l’informatique, dynamique et enthousiaste. Il est constamment à la recherche d’outils innovants destinés à faciliter les opérations, l'assurance qualité et le développement pour les professionnels de l’informatique.


Forum aux questions sur SQL& Erreurs d'E/S, mise en miroir de base de données et bien plus encore
Paul S. Randal

Q : J’ai commencé à effectuer régulièrement des vérifications de cohérence des bases de données que je gère et j'ai même ajouté certaines alertes de l'Agent SQL pour intercepter toutes les erreurs d'E/S que rencontrent les requêtes utilisateur. Je ne sais pas si la logique que j'ai implémentée pour les vérifications et les alertes fonctionnera car aucune de mes bases de données ne montre de problèmes d'altération. Comment puis-je créer une altération dans une base de données de test afin de m'assurer que tout ce que j'ai configuré fonctionne correctement ? Par ailleurs, puis-je faire quelque chose d'autre pour détecter les erreurs d'E/S ?
R : Dans SQL Server® 2000, la vieille astuce pour créer une base de données altérée pour le test consistait à supprimer une ligne de la table sysindexes d'une base de données de test. Mais avec SQL Server 2005, l'altération d'une table système d'une telle manière est très difficile. La meilleure façon d'altérer une base de données de test est d'utiliser un éditeur hexadécimal pour modifier un fichier de données pendant que la base de données est arrêtée. Voici comment faire :
  • Arrêtez la base de données afin que les fichiers de données ne soient pas verrouillés. (Veillez toutefois à ne pas détacher la base de données, car si vous altérez la mauvaise page, il est possible que ne puissiez pas la rattacher).
  • Choisissez un décalage de disons 100 pages dans le fichier (au moins 819 200 octets), mais assurez-vous qu'il est aligné sur une limite de 8 192 octets (une limite de page). Ceci évite les pages de métadonnées essentielles et les bitmaps d'allocation, ce qui vous permet de démarrer la base de données et d'exécuter DBCC CHECKDB sur celle-ci.
  • Écrivez quelques octets de zéros dans le fichier au décalage choisi. L'utilisation de cette technique garantit presque dans tous les cas l'introduction de certaines erreurs d'altération d'en-tête de page.
Ceci dit, la façon la plus rapide de créer une base de données de test altérée est d'en utiliser une créée par quelqu'un d'autre. Vous trouverez des exemples de bases de données SQL Server 2000 et SQL Server 2005 altérées (avec des explications) sur mon blog (go.microsoft.com/fwlink/?LinkId=115151).
En ce qui concerne votre deuxième question, ayant trait à ce que vous devez faire pour détecter les erreurs d'E/S, vous devez activer les sommes de contrôle de pages. Cette fonctionnalité a été introduite dans SQL Server 2005 afin de protéger une page de base de données entière des erreurs qui ont été introduites par le sous-système d'E/S.
En gros, lorsqu'une page est enregistrée sur le disque, la dernière chose effectuée par SQL Server est le calcul d'une somme de contrôle de l'intégralité des 8 ko de la page et la mise en place de la somme de contrôle sur la page. Lorsqu'une page est lue à partir du disque, si elle possède une somme de contrôle de page, la somme de contrôle est recalculée et comparée à celle qui est enregistrée sur la page. Si elles ne correspondent pas, un élément extérieur à SQL Server a altéré la page et une erreur 824 est signalée. L'erreur est affichée à la connexion qui a provoqué la lecture de la page, et consignée dans le journal d'erreurs de SQL Server et le journal des événements d'applications de Windows®.
Les sommes de contrôle de page sont activées par défaut pour toutes les bases de données créées avec SQL Server 2005 et SQL Server 2008. Cependant, elles doivent être activées manuellement pour les bases de données mises à niveau à partir des versions précédentes de SQL Server. Vous pouvez activer les sommes de contrôle de page avec ce code :
ALTER DATABASE mydb SET PAGE_VERIFY CHECKSUM;

Conseil : Changez le port par défaut de SQL Server
Par défaut, le port configuré pour les instances de SQL Server est 1433. Une fois ce port utilisé par une instance, il ne peut pas être occupé par une autre instance. Par conséquent, si vous installez une seconde instance (nommée) à l'écoute sur Internet avec tcp, elle aura besoin d'un autre port. Dans certains cas, l'administrateur peut souhaiter modifier le port pour des raisons de brouillage (bien que cette forme de brouillage soit mineure et puisse être facilement mise en échec par un scanneur de port). Bien entendu, vous devez alors configurer le client pour qu'il utilise un port différent. Il existe trois approches courantes pour effectuer ceci.
Premièrement, en supposant que l'administrateur ait changé le port d'une instance pour utiliser 5555, vous pouvez spécifier simplement le numéro de port de l'instance dans le nom de l'ordinateur auquel vous voulez vous connecter en utilisant la syntaxe MonNomDeServeur,5555. Si le port change à nouveau, les clients devront également changer leurs chaînes de connexion.
Une autre option consiste à utiliser des alias SQL Server, qui sont configurés sur le client. Outre le nom d'alias, le nom du serveur, le nom du port et un protocole doivent être spécifiés. Une fois configuré, l'alias peut être utilisé comme nom de serveur pour la connexion à l'instance de base de données. L'avantage de cette option est que les modifications de configuration de serveur peuvent être déployées par un administrateur de domaine, car les paramètres sont enregistrés dans le Registre.
La troisième option, pour les instances nommées avec lesquelles l'utilisateur connaît seulement le nom d'instance et spécifie le nom en utilisant Nomd'ordinateur\Nomd'instance dans la chaîne de connexion, consiste à utiliser le service SQL Server Browser. Ceci est déjà implémenté dans SQL Server 2000 dans un service exécuté. Cependant, dans SQL Server 2005, le service SQL Server Browser a été créé comme service séparé. Outre la découverte d'instances pour l'ordinateur, il répond également aux requêtes entrantes au protocole UDP (User Datagram Protocol) sur le port 1434, avec le numéro de port approprié pour l'instance demandée, en permettant le réacheminement pour le client et la prise en charge de connexion transparente.
—Jens K. Suessmeyer, consultant en base de données chez Microsoft

Q : Pour supprimer toute fragmentation de ma base de données, j'ai configuré un plan de maintenance nocturne qui reconstruit tous les index de la base de données de production. Il s'exécute sur SQL Server 2005 Enterprise Edition avec SP2. J'ai remarqué que ceci provoquait un accroissement excessif de la taille de la base de données et j'ai donc ajouté une étape pour la réduction de tout l'espace supplémentaire, car il n'y a pas beaucoup d'espace libre sur le disque. Il semble maintenant que l'étape de regénération ne fonctionne plus. Que se passe-t-il ?
R : Vous faites face à un problème courant auquel les gens sont confrontés lors de la mise en place d'un plan de maintenance. Vous êtes coincé dans un cycle réduction-accroissement-réduction-accroissement.
Lorsqu'un index est recréé, une nouvelle copie de l'index est créée avant que l'index existant soit supprimé. Cette procédure nécessite de l'espace supplémentaire dans les fichiers de base de données, habituellement une quantité d'espace équivalente à celle utilisée par l'index actuel. Dans SQL Server 2000, l'espace supplémentaire était également nécessaire pour trier les lignes d'index (à peu près 20% de la taille de l'index), mais cette exigence a été éliminée pour une regénération d'index simple dans SQL Server 2005.
Les administrateurs souhaitent parfois supprimer l'espace supplémentaire créé pendant la reconstruction d'index et ajoutent donc une opération de réduction au plan de maintenance après l'étape de reconstruction. Peu de gens savent cependant que cette réduction provoque également une fragmentation d'index en raison de la nature de son algorithme. Ceci signifie que l'index récemment reconstruit et défragmenté deviendra immédiatement fragmenté, en annulant l'effet de la regénération dont il a fait l'objet en premier lieu.
Étant donné que le fichier de base de données grossira de nouveau la prochaine fois qu'aura lieu une regénération d'index, il est préférable de permettre à la base de données d'avoir de l'espace supplémentaire et d'éviter entièrement l'opération de réduction. (En outre, l'accroissement et la réduction continus des fichiers de base de données provoqueront une fragmentation de fichiers au niveau du système d'exploitation, ce qui peut provoquer des performances passables, à l'image de la fragmentation d'index)
Pour terminer, il peut être souhaitable d'envisager de réduire la fréquence à laquelle vous regénérez les index. Il peut même être préférable d'utiliser une autre méthode, telle que le vieux DBCC INDEXDEFRAG que j'ai écrit pour SQL Server 2000 ou la syntaxe ALTER INDEX REORGANIZE plus récente dans SQL Server 2005 et SQL Server 2008.
Il existe un livre blanc utile qui a trait à la fragmentation d'index et fournit des recommandations pour la suppression de la fragmentation (à l'adresse go.microsoft.com/fwlink/?LinkId=115154). Bien que ce livre blanc ait été écrit pour SQL Server 2000, les concepts sont toujours les mêmes.

Q : Nous avons évalué la stratégie de récupération après incident dans mon entreprise et je pense que la mise en miroir de la base de données est l'approche à utiliser dans notre cas. Le serveur que j'essaie de protéger possède de nombreuses bases de données sans rapport (résultat d'un projet de consolidation des serveurs préalable) et j'aimerais utiliser la mise en miroir de la base de données pour toutes. La question à laquelle je m'efforce de répondre a trait au nombre de bases de données que je peux mettre en miroir avant que les performances ne commencent à se dégrader ?
R : La réponse à cette question est une réponse que j'utilise très fréquemment : Ca dépend ! Les recommandations publiées indiquent de ne pas mettre en miroir plus de 10 bases de données par instance, mais le nombre 10 est uniquement une supposition approximative du maximum qui correspondra à la plupart des utilisateurs. Vous devez prendre en compte les facteurs suivants pour votre configuration matérielle :
  • quelle est la taille de mémoire dont disposent les instances principale et mise en miroir ? (dans l'idéal, elle doit être identique pour les deux)
  • quelle est la configuration de processeur dont disposent les instances principale et mise en miroir ? (celle-ci doit également être identique)
  • de quelle bande passante le sous-système d'E/S dispose-t-il sur l'instance mise en miroir ? (elle doit être identique à celle de la base de données principale)
  • quelle est la quantité de journaux de transactions générée par la charge de travail sur chacune des bases de données ?
  • quelle est la bande passante réseau disponible entre les bases de données principale et l'instance mise en miroir ?
Ces deux derniers facteurs sont les plus essentiels. Si la bande passante réseau disponible entre les deux instances n'est pas suffisante pour gérer le taux de génération combiné par seconde de journaux de transactions de toutes les bases de données en miroir, les performances chuteront alors sur les bases de données principales. SQL Server 2008 contribue à réduire une partie de ce fardeau avec la compression de flux de journaux.
L'élément le plus essentiel à prendre en compte ensuite a trait aux exigences en termes de mémoire et de threads. Chaque base de données mise en miroir nécessite un thread plus de la mémoire. Sur les serveurs de basse capacité, un nombre important de bases de données mises en miroir peut apporter une charge trop importante sur le serveur lorsqu'elle est combinée à la charge de travail régulière.
Vous devez également prendre en compte la manière dont vous exécuterez la mise en miroir des bases de données. En mode synchrone, les transactions sur la base de données principale ne peuvent pas être validées avant que tous les enregistrements de journal des transactions aient été copiés vers le journal des transactions de la base de données mise en miroir. Par conséquent, tout délai provoqué par un réseau surchargé pourrait provoquer un problème de performances de charge de travail sur la base de données principale.
En mode asynchrone, les transactions peuvent être validées sur la base de données principale sans attendre, mais un délai sur le réseau pourrait provoquer un accroissement de la quantité de journal des transactions en attente d'envoi à la base de données en miroir. Ceci peut causer des problèmes de taille de journal des transactions. Pire, tout journal des transactions non envoyé sera perdu en cas de défaillance. Par conséquent, plus la taille de journal des transactions non envoyé est importante, plus grand est le risque de perte de données dans une situation de récupération.
Les scénarios peuvent varier considérablement, et j'ai vu certains exemples intéressants dans de véritables environnements de production. Par exemple, j'ai vu un environnement avec 150 bases de données, possédant toutes une activité réduite, non simultanée. Les 150 bases de données étaient mises en miroir sans aucun problème.
Par contre, j'ai vu une configuration avec seulement trois bases de données lourdement chargées, mais sans bonne connexion réseau. Dans ce scénario, il est à peine possible d'effectuer la mise en miroir d'une base de données avant que le manque de bande passante réseau provoque une dégradation de charge de travail.
L'élément clé du succès est, avant tout, d'effectuer un calcul de la création de journaux. S'il semble que la bande passante réseau disponible pourra prendre en charge le nombre de bases de données que vous voulez refléter, cela pourrait fonctionner. Testez votre configuration avant de la mettre en production et veillez à inclure toutes les opérations qui pourraient produire des transactions de journaux des transactions, en particulier toute maintenance de base de données que vous pourriez effectuer.

Paul S. Randal est directeur général de SQLskills.COM et MVP SQL Server. Il a travaillé sur le moteur de stockage de données de SQL Server chez Microsoft de 1999 à 2007. Paul a écrit DBCC CHECKDB/repair pour SQL Server 2005 et était responsable de Core Storage Engine pendant le développement de SQL Server 2008. Expert de la récupération après incident, de la haute disponibilité et de la maintenance de base de données, Paul présente fréquemment des conférences. Vous trouverez son blog à l'adresse SQLskills.com/blogs/paul.


Coup de projecteur sur les utilitaires Conseiller de mise à niveau vers Windows Vista
Lance Whitney

Il est grand temps de commencer à planifier la mise à niveau de votre entreprise vers Windows Vista® et, comme avec n'importe quelle mise à niveau, des questions se posent. Vos clients réseau répondent-ils aux exigences de matériel et de logiciel ? À quels problèmes de compatibilité ferez-vous face ? Pour aider à répondre à ces questions et à d'autres, Microsoft fournit gratuitement le Conseiller de mise à niveau vers Windows Vista. Cet utilitaire analyse tout matériel et logiciel installé sur un PC pour déterminer si une mise à niveau est faisable. Si c'est le cas, le conseiller recommande la version optimale de Windows Vista et révèle tout problème à résoudre avant la mise à niveau.
L'analyse du Conseiller de mise à niveau prend généralement plusieurs minutes. Pendant que l'analyse s'exécute, un graphique répertorie les différentes versions de Windows Vista, en comparant les fonctionnalités de chacune. Vous pouvez également sélectionner une édition particulière (Édition Intégrale/Édition Familiale Premium/Professionnel/Édition Familiale Basique) pour afficher une courte description et une liste des fonctionnalités principales. Une fois l'analyse terminée, l'écran Détails du rapport vous indique si votre PC est compatible Windows Vista et quelle version vous est conseillée. Les détails comprennent :
la configuration requise Ceci vous indique si votre matériel (UC, RAM, mémoire vidéo et lecteur de CD/DVD) est suffisant. Si ce n'est pas le cas, vous verrez le détail des éléments nécessaires à la mise à niveau de votre PC, par exemple, la quantité de mémoire que vous devez ajouter.
Périphériques Ceci examine tous les périphériques et pilotes externes, y compris le modem, l'imprimante, le scanneur, la carte son, le moniteur et la carte vidéo. Si un périphérique ne réussit pas le test de compatibilité, le rapport explique l'action à entreprendre, comme le téléchargement des derniers pilotes depuis le site Web du fabricant. Un lien pratique vers le site Web est fourni.
Le Conseiller de mise à niveau signale les problèmes de compatibilité connus et recommande des méthodes permettant d'y remédier
Le Conseiller de mise à niveau signale les problèmes de compatibilité connus et recommande des méthodes permettant d'y remédier (Cliquez sur l'image pour l'agrandir)
Programmes Ceci analyse les logiciels installés. Vous découvrirez les applications capables de s'exécuter sous Windows Vista dans l'état et celles qui sont incompatibles ou doivent être mises à niveau pour réussir le test.
Si l'un des composants ne réussit pas le test de compatibilité d'une version plus puissante de Windows Vista, comme Intégrale, vous pouvez revenir à l'écran d'introduction et sélectionner une autre version, comme Professionnel. Vous pourrez alors voir si votre PC répond à toutes les exigences de cette version.
Pour terminer, une liste de tâches décrit la configuration matérielle de votre PC et détaille les tâches que vous devez mener à bien avant et après avoir installé Windows Vista. Il récapitule les éléments des écrans précédents et offre des recommandations supplémentaires, comme le montre la capture d'écran. Vous pouvez imprimer la liste des tâches ou l'enregistrer en tant que fichier HTML.
Le Conseiller de mise à niveau s'exécute sous Windows Vista 32 bits ou Windows ® XP Service Pack 2 et nécessite Microsoft® .NET Framework 2.0 et MSXML 6.0. Pour en savoir plus et télécharger l'outil, visitez simplement microsoft.com/windows/products/windowsvista/buyorupgrade/upgradeadvisor.mspx.

Lance Whitney est consultant en informatique, formateur et rédacteur technique. Il a passé un nombre d'heures incalculable à affiner des postes de travail et serveurs Windows. Journaliste de formation, il s'est reconverti à l'informatique il y a 15 ans.


Au cœur de SharePoint Décentralisation de l'administration de site
Pav Cherny

Télécharger le code de cet article: SharePoint2008_06.exe (1160KB)

Microsoft Windows SharePoint Service (WS) 3.0 et Microsoft Office SharePoint Server (MOSS) 2007 prennent en charge une administration et un modèle de sécurité flexibles qui permettent aux entreprises informatiques de centraliser le contrôle des composants d'infrastructure, comme les serveurs Web et les serveurs de base de données, et de décentraliser le contrôle de
collections de sites et sites hébergés. La centralisation de l'infrastructure SharePoint® contribue à réduire la maintenance, à consolider la logique métier, à fournir un seul point d'accès aux ressources SharePoint et à éviter des investissements inutiles dans les technologies.
Simultanément, la décentralisation de l'administration de site vous permet de garantir que chaque département conserve un contrôle autonome de ses collections de sites, sites, bibliothèques de documents, listes, solutions de flux de travail et autres ressources SharePoint. Cependant, un effet secondaire de la délégation de l'administration de site aux différents départements est l'augmentation de la complexité de la maintenance pour le service informatique. Par exemple, comment assurer le suivi de l'utilisation des ressources, des sites SharePoint expirés et du contenu dépassé dans une infrastructure centralisée si vous n'avez pas accès aux collections de sites et aux sites au sein de votre environnement ?
Dans cet article, j'aborde le modèle de sécurité de WS 3.0, y compris ses avantages et implications lors de la délégation du contrôle administratif à différents départements sur des sites SharePoint tout en maintenant un contrôle administratif centralisé sur l'infrastructure SharePoint. J'y explique comment fonctionne l'administration déléguée de site, comment les autorisations d'accès et la suppression de sécurité au niveau site, liste et élément contribuent à préserver un environnement de travail sécurisé et convivial, et comment les administrateurs de batteries de serveurs Web peuvent accéder aux statistiques de site nécessaires sans autorisations SharePoint élevées.
Si vous souhaitez suivre mes explications dans un laboratoire de test, téléchargez le matériel associé à cette rubrique sur technetmagazine.com. Ce matériel comprend des instructions de déploiement détaillées pour une batterie de serveurs Web basée sur Windows Server® 2008 assez semblable à l'environnement de production d'une entreprise comptant plusieurs services.

Infrastructure SharePoint et administration de collection de sites
Vous pouvez générer une infrastructure SharePoint fondée sur un déploiement sur serveur unique ou un déploiement sur batterie de serveurs Web. En fait, les entreprises possèdent souvent les deux. Le déploiement sur serveur unique convient pour les services nécessitant une solution de collaboration rapide et directe. Les exigences en matière de performances et de fiabilité sont minimes. Les utilisateurs ont tendance à être compréhensifs si un serveur SharePoint de service (souvent déployé sur du matériel de poste de travail) est indisponible parce que la maintenance système relève de la responsabilité du service et que les utilisateurs de ce services ne sont, après tout, pas des administrateurs informatiques.
Il en va tout à fait différemment des ressources serveur maintenues par le service informatique. Les performances et la fiabilité deviennent des facteurs cruciaux, nécessitant souvent le déploiement de solutions à grande disponibilité pour garantir la conformité au contrat de niveau de service (SLA). Les déploiements de batteries de serveurs Web à équilibrage de charge, les clusters de basculement de SQL Server® et les bases de données enregistrés sur des réseaux SAN peuvent contribuer à répondre aux besoins en matière de performances et de grande disponibilité de votre entreprise. Voir la figure 1 pour une illustration de cette architecture.
Figure 1 Infrastructure SharePoint avec cluster de basculement SQL Server et SAN
Figure 1 Infrastructure SharePoint avec cluster de basculement SQL Server et SAN (Cliquez sur l'image pour l'agrandir)
Comme vous pouvez le voir à la figure 1, plusieurs types d'administrateurs doivent collaborer pour maintenir les ressources d'une infrastructure SharePoint centralisée. Toutefois, chacun de ces administrateurs appréhende l'environnement avec une perspective différente. Par exemple, les serveurs de l'infrastructure sont limpides pour les administrateurs de collection de sites. Les administrateurs de collection de sites travaillent avec l'interface utilisateur SharePoint standard. Cette interface ne change pas, que vous hébergiez les sites sur un ordinateur de poste de travail exécutant WSS 3.0 dans votre bureau ou sur une batterie de serveurs Web dans un centre de données.
L'infrastructure SharePoint est également limpide pour les administrateurs de base de données et les ingénieurs de stockage SAN. Pour ces administrateurs, les bases de données SharePoint ne sont pas différentes des autres bases de données SQL Server et les numéros d'unité logiques du cluster de basculement SQL Server ne différent pas d'un autre numéro d'unité logique. L'administrateur le plus directement concerné par l'infrastructure SharePoint est l'administrateur de batterie de serveurs Web, qui pourtant n'a aucun contrôle sur les collections de sites, les bases de données ou les numéros d'unité logiques.
Il est donc juste de dire que ces administrateurs de collection de sites de département ignorent généralement les détails d'infrastructure. Après tout, il n'est pas nécessaire de connaître ces détails pour configurer des sites et déléguer des autorisations d'accès aux équipes et groupes d'un service. Il est facile de créer un nouveau site et de commencer à collaborer et des sujets comme les coûts de stockage élevés associés à la technologie SAN viennent rarement à l'esprit.
Avec chaque projet et initiative, de nouveaux sites d'équipe apparaissent, des sites expirés subsistent et du contenu dépassé n'est pas supprimé. L'environnement SharePoint croît ainsi à un rythme impressionnant jusqu'à atteindre une ampleur que les administrateurs système ne peuvent plus ignorer. Par exemple, l'environnement interne SharePoint de Microsoft contenait plus de 180 000 sites avant que Microsoft IT lance une initiative de simplification en 2006.
La formation des administrateurs de collection de sites peut aider à conserver le contrôle dans une infrastructure SharePoint centralisée. Appliquer des quotas et des verrous de collection de sites est également utile, bien que ces méthodes ne soient pas très efficaces lorsqu'il s'agit de sites d'équipe dépassés et de contenu gaspillant de précieuses ressources de stockage et de sauvegarde.
Le contenu obsolète n'engendre pas nécessairement le dépassement du quota d'une collection de sites. Bien sûr, vous pouvez configurer SharePoint pour envoyer des notifications par courrier électronique aux propriétaires de collection de sites et supprimer automatiquement les collections de sites inutilisées après une période spécifique en utilisant la fonction Confirmer l'utilisation des sites et leur suppression sur le site d'administration centrale de SharePoint 3.0, mais cette fonction ne fonctionne pas au niveau des sites individuels. Une collection de sites peut contenir des sites actuels et désuets, mais la fonction Confirmer l'utilisation des sites et leur suppression ne fonctionne pas à ce niveau de granularité.
Plus tard, je vous montrerai comment identifier des sites inutilisés et du contenu obsolète en vérifiant la date de dernière modification des documents et d'éléments de liste, même sans autorisation d'accès à la collection de sites. Cette fonctionnalité de rapport n'est pas disponible d'emblée, mais n'est heureusement pas difficile à implémenter.

Administration de site SharePoint décentralisée
La délégation de privilèges d'administration de site SharePoint est très simple. En utilisant le site d'administration centrale de SharePoint 3.0, l'outil de ligne de commande Stsadm.exe, ou un outil de configuration personnalisé, vous pouvez créer des applications Web, des chemins gérés et des collections de sites dans l'infrastructure. En tant qu'administrateur de batterie de serveurs Web, vous pouvez spécifier des administrateurs de collection de sites primaires et secondaires lors de la création d'une collection de sites. Ces administrateurs de collection de sites peuvent être des utilisateurs de domaine réguliers. Ils n'ont pas besoin d'autorisations administratives sur la batterie de serveurs Web ou sur d'autres serveurs d'infrastructure. Ils utilisent leurs navigateurs Web pour exécuter les tâches d'administration de site directement dans l'interface utilisateur SharePoint.
La figure 2 illustre l'administration de site déléguée selon les instructions détaillées que vous trouverez dans les feuilles de travail du matériel associé. Dans cet exemple, l'administrateur de batterie de serveurs Web a configuré des collections de sites séparées pour le service des ressources humaines (HR) (http://sharepoint/hr) et le service informatique (IT) (http://sharepoint/it).
Figure 2 Administration déléguée de site SharePoint
Figure 2 Administration déléguée de site SharePoint (Cliquez sur l'image pour l'agrandir)
Les administrateurs HR et IT peuvent alors utiliser la fonction Sites et espaces de travail disponible dans le menu Actions du site dans l'interface utilisateur SharePoint pour créer des sites de niveau inférieur et appliquer des autorisations depuis le site parent ou définir de nouvelles autorisations administratives et utilisateur pour les sites de niveau inférieur. Notez qu'à moins d'une configuration clairement différente, l'administrateur de batterie de serveurs Web ne peut pas accéder à des sites de niveau supérieur ou inférieur, l'administrateur HR ne peut pas accéder aux sites IT, et l'administrateur IT ne peut pas accéder aux sites HR, bien que tous les sites soient hébergés dans le même environnement SharePoint.
La conception des collections et des hiérarchies de sites dépend des exigences organisationnelles. Dans l'exemple de la figure 2, je n'ai pas créé de site maître par-dessus de http://sharepoint/hr et http://sharepoint/it. En d'autres termes, il n'y a pas de collection de sites sur le chemin http://sharepoint. Mais vous pouvez facilement créer une collection de sites sur ce chemin ou utiliser d'autres chemins gérés, comme http://sharepoint/sites/hr et http://sharepoint/sites/it.
Vous pouvez également créer des applications Web distinctes pour HR et IT pour établir des URL de base plus intuitives, comme http://hr et http://it, configurer des sites de portail généraux pour les départements, puis utiliser des composants WebPart cumulés pour répertorier les informations des sites de niveau inférieur dans ces sites maîtres. Des collections de sites séparées facilitent une administration autonome, contribuent à limiter l'accès aux informations des services, offrent des capacités de personnalisation individuelle des pages maîtres, des mises en page, des modèles, des composants WebPart et des contrôles de navigation, peuvent être utilisées pour placer des données sensibles dans des bases de données de contenu dédiées séparées d'autres collections de sites et bases de données de contenu.

Rôles, autorisations de site et filtrage de sécurité
Une fois que les collections de sites existent et que les autorisations administratives ont été déléguées, un administrateur de collection de sites peut ouvrir un site de niveau supérieur et utiliser la fonction Paramètres du site du menu Actions du site pour gérer la collection de sites. Ceci comprend l'ajout (ou la suppression) d'autres administrateurs de collection de sites avec des autorisations complètes pour tous les sites de la collection de sites, la création de groupes, l'association de ces groupes à des rôles et l'ajout d'utilisateurs à ces groupes pour accorder des autorisations de lecture et de contribution. Cela inclut également la configuration de sites de groupe et d'équipe de niveau inférieur.
Bien que vous puissiez accorder individuellement des autorisations SharePoint à des utilisateurs, il vaut mieux créer des groupes SharePoint en fonction de rôles spécifiques. Par exemple, SharePoint compte trois groupes par défaut pour les rôles Visiteurs, Collaborateurs et Propriétaires. Les visiteurs ont un accès en lecture seule, les collaborateurs peuvent ajouter des éléments aux listes et bibliothèques de documents et personnaliser des pages Web et les propriétaires ont un contrôle total.
Autre fonction méritant votre attention : SharePoint exécute un filtrage de sécurité fondée sur le rôle d'utilisateur, ce qui signifie que les utilisateurs voient seulement les liens et éléments de l'interface utilisateur pour lesquels ils possèdent une autorisation d'accès. Si vous refusez à un utilisateur l'accès à une ressource, comme une liste (en configurant des autorisations explicites sous Paramètres de la liste) ou un élément de liste précis (en utilisant la commande Gérer les autorisations du menu contextuel de l'élément), la liste ou l'élément disparaît pour cet utilisateur. Si l'utilisateur saisit directement l'URL de l'élément dans le navigateur, il obtient la page Erreur : Accès refusé.
La figure 3 illustre le filtrage de sécurité en action. L'administrateur HR possède les autorisations complètes et peut accéder au menu Actions du site pour exécuter des tâches administratives. Le Visiteur HR, d'autre part, possède seulement des autorisations de lecture pour la collection de sites et ne voit pas ce menu.
Figure 3 Filtrage de sécurité fondé sur les rôles d'utilisateur dans l'interface SharePoint
Figure 3 Filtrage de sécurité fondé sur les rôles d'utilisateur dans l'interface SharePoint (Cliquez sur l'image pour l'agrandir)
Le filtrage de sécurité est utile car il masque les fonctions, liens et éléments inaccessibles, mais elle implique également que les administrateurs de batterie de serveurs Web ne peuvent pas utiliser l'interface utilisateur SharePoint pour répertorier des sites et des ressources de sites s'ils ne possèdent pas d'autorisations d'accès. Vous ne pourrez pas voir ces ressources dans les pages Web ou les composants WebPart. De plus, les ressources inaccessibles ne s'affichent pas dans les résultats de la recherche parce que SharePoint Enterprise Search exécute le filtrage de sécurité au moment de la requête selon l'identité de l'utilisateur soumettant celle-ci.

Et la ligne de commande ?
Si l'interface utilisateur graphique ne fournit pas d'accès aux informations désirées sans autorisations élevées au niveau de la collection de sites, l'outil de ligne de commande Stsadm.exe offre peut-être la solution. Par exemple, vous pouvez penser pouvoir utiliser la commande
Stsadm -o enumsites -url http://sharepoint
pour lister toutes les collections et tous les propriétaires de sites dans l'application Web http://sharepoint. Alors vous devriez pouvoir lister tous les sites de niveau inférieur en utilisant cette commande :
Stsadm -o enumsubwebs -url <site collection>
Pourtant, dans un environnement de batterie de serveurs Web, Stsadm.exe réagit généralement par un message d'erreur indiquant que les autorisations d'accès à cette base de données manquent. Stsadm.exe ne peut pas énumérer les collections de sites bien que vous soyez un administrateur de batterie de serveurs Web et puissiez gérer les collections de sites dans l'administration centrale de SharePoint 3.0. Le message suivant est le message d'erreur que vous obtenez si vous utilisez Stsadm.exe sur une batterie de serveurs Web sans les autorisations d'accès SQL Server :
C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN>stsadm -o enumsites -url http://sharepoint
<Sites Count="2">
<Site Error="Cannot open database &quot;WSS_Content&quot; requested by the login. The login failed.&#xD;&#xA;Login failed for user 'CONTOSO\SPAdmin'.">
<Site Error="Cannot open database &quot;WSS_Content&quot; requested by the login. The login failed.&#xD;&#xA;Login failed for user 'CONTOSO\SPAdmin'." />
L'administrateur de batterie de serveurs Web reçoit ce message d'erreur parce que Stsadm.exe s'exécute dans le contexte de l'utilisateur connecté, comme CONTOSO\SPAdmin, tandis que le site d'administration centrale de SharePoint 3.0 accède aux bases de données SharePoint dans le contexte du compte de système associé au pool d'applications de l'administration centrale de SharePoint v3, comme CONTOSO\WssConfigAdmin. Bien qu'attribuer les autorisations pour la base de données de contenu dans SQL Server à votre compte db_owner vous permette d'exécuter la commande Stsadm -o enumsites -url http://sharepoint, vous ne pouvez toujours pas énumérer les sites de niveau inférieur dans les collections de sites. La commande Stsadm -o enumsubwebs -url <site collection> induit le message Access is denied (Accès refusé). (Exception de HRESULT: 0x80070005 (E_ACCESSDENIED)) et vous retournez à la case Départ. Cependant, il existe une meilleure méthode ne nécessitant pas d'autorisations SQL Server élevées.

Informations de site dans des bases de données de contenu
Si vous ne pouvez pas obtenir les informations requises via les interfaces et outils SharePoint standard, vous devez accéder directement aux bases de données de contenu SharePoint. Mais tout d'abord un petit avertissement : cette méthode doit être utilisée en dernier recours ! Les bases de données de contenu reposent sur des schémas de propriété et des structures de base de données que Microsoft n'a que partiellement décrits dans les kits de développement logiciel WS 3.0 pour tenter de décourager les utilisateurs de travailler directement avec les bases de données. Si possible, vous devriez utiliser l'interface utilisateur SharePoint, les outils de ligne de commande, le modèle objet ou les services Web pour accéder aux informations désirées.
Si vous n'avez pas d'autre choix et devez accéder directement aux bases de données, vous devez au moins vous limiter à un accès en lecture seule. La modification du schéma ou des structures des bases de données n'est pas prise en charge et peut causer de graves problèmes qui pourraient vous obliger à restaurer des collections de sites à partir d'une sauvegarde ou à réinstaller la batterie de serveurs Web SharePoint.
Une alternative possible à l'implémentation d'une solution de création de rapports qui accède directement aux bases de données de contenu est de définir le compte d'administrateur de batterie de serveurs Web comme propriétaire secondaire dans la configuration de la collection de sites. Les administrateurs de batterie de serveurs Web peuvent effectuer cette étape sur le site d'administration centrale SharePoint 3.0. Vous pouvez trouver le lien des administrateurs de collection de sites sous Gestion des sites SharePoint sur la page Gestion des applications.
En tant qu'administrateur secondaire de collection de sites, vous pouvez ouvrir la collection de sites dans votre navigateur Web, affichez les Paramètres du site, puis cliquer sur le lien Rapport sur l'utilisation du site sous Administration du site, à condition d'avoir activé Traitement de l'analyse de l'utilisation dans l'administration centrale de SharePoint 3.0. Consultez le point Journalisation et création de rapports sur la page Opérations si vous voulez suivre les données d'utilisation dans des fichiers journaux sur vos serveurs SharePoint. La fonction Rapport sur l'utilisation du site est désactivée par défaut.
Toutefois, la création manuelle de rapports sur l'utilisation du site pour des collections de sites individuelles n'est pas pratique dans des environnements comptant un grand nombre de collections de sites ou présentant des exigences strictes vous empêchant d'octroyer les autorisations requises à des administrateurs de batterie de serveurs Web. Une approche plus pratique consiste à implémenter une application de création de rapports ASP.NET simple répertoriant toutes les collections de sites et tous les sites de la base de données de contenu avec les statistiques importantes, comme le nombre d'éléments, la taille totale combinée de tous les éléments et la date de dernière modification des éléments, comme illustré à la figure 4.
Figure 4 Obtenir directement des statistiques de site depuis une base de données de contenu
Figure 4 Obtenir directement des statistiques de site depuis une base de données de contenu (Cliquez sur l'image pour l'agrandir)
Si vous exécutez cette application sous l'identité du compte de pool d'applications de l'administration centrale SharePoint v3, vous pouvez obtenir l'accès aux bases de données de contenu sans autorisations SQL Server élevées. Comme nous l'avons dit plus haut, le compte Administration centrale possède déjà les autorisations SQL Server requises.
Le matériel associé inclut une solution de création de rapports simple qui utilise des requêtes SELECT à la base de données de contenu sur le serveur SQL, ainsi que des instructions détaillées pour déployer cette solution sur un serveur Web. Il est important de noter que je n'ai implémenté aucune vérification de sécurité. La solution s'exécute avec une authentification anonyme.
Il n'est pas nécessaire d'authentifier l'utilisateur parce que le compte Administration centrale fournit le contexte de sécurité nécessaire pour accéder aux bases de données de contenu. J'ai utilisé un port personnalisé pour le site Web de la solution, bloqué par le pare-feu Windows® sur Windows Server 2008, pour que seul un utilisateur local puisse ouvrir l'application Web. Cela répondait aux exigences de sécurité de mon environnement de test, mais dans un environnement de production, vous devez accroître la sécurité, par exemple en activant l'authentification Windows et en configurant des autorisations d'accès restreint au répertoire virtuel de l'application ASP.NET.

Conclusion
SharePoint offre des capacités flexibles de collections de sites et d'administration de site qui vous permettent de centraliser l'infrastructure SharePoint tout en décentralisant l'administration de site selon les besoins spécifiques de votre entreprise. Une infrastructure centralisée peut profiter à des entreprises de toute taille parce qu'un environnement consolidé contribue à réduire les coûts, facilite le partage d'informations dans et entre les services, fournit la base à l'exploitation ciblée de connaissances de pointe afin de maintenir l'environnement avec une sécurité, une fiabilité et une évolutivité élevées et offre aux utilisateurs un point d'accès unique aux sites et ressources SharePoint du réseau d'entreprise.
Simultanément, chaque service et division peut rester maître de ses ressources SharePoint. Les administrateurs de batterie de serveurs Web peuvent désigner des administrateurs de collection de sites qui exécutent alors des tâches d'administration de site dans leurs zones de responsabilité sans autre intervention du service informatique.
Toutefois, avec le transfert de contrôle aux services, les administrateurs de batterie de serveurs Web perdent également la possibilité de contrôler l'utilisation des ressources dans l'infrastructure à l'aide des fonctionnalités et outils SharePoint standard. Bien sûr, appliquer des quotas aux bases de données de contenu, envoyer des rappels par courrier électronique aux administrateurs de collection de sites et suivre les données d'utilisation pour créer des rapports peut atténuer le problème. Néanmoins, pour gérer efficacement l'infrastructure SharePoint, les administrateurs de batterie de serveurs Web ont besoin d'autres outils qui extraient les métadonnées de site requises directement dans les bases de données de contenu en mode de lecture seule.
Les options disponibles incluent le recours à SQL Server 2005 Reporting Services ou à une solution de création de rapports similaire au niveau de l'entreprise. Comme l'illustre l'exemple du matériel associé, vous pouvez également utiliser des requêtes SQL Server SELECT pour obtenir les informations requises.

Pav Cherny est un expert informatique et auteur spécialisé dans les technologies Microsoft pour la collaboration et la communication unifiée. Ses publications incluent des livres blancs, des manuels de produits et des livres avec un intérêt particulier pour les opérations informatiques et l'administration système. Pav est le président de Biblioso Corporation, une entreprise spécialisée dans la documentation gérée et les services de localisation.


Windows PowerShell Du beau boulot
Don Jones

Il n'est pas rare de souhaiter que des scripts produisent un résultat attrayant et l'on me demande souvent quelle est la meilleure façon de produire des choses telles que des tableaux. Il existe en fait deux façons d'y parvenir. La première étape consiste à écrire un script qui place les données que je souhaite afficher de façon formatée dans des variables appelées
$data1, $data2 et $data3. À présent, je peux passer au formatage des données.

La méthode texte
Sur le Web
Vous cherchez une démonstration rapide des techniques abordées dans l'article Windows PowerShell de ce mois-ci ? Visitez le site technetmagazine.com/video pour voir comment Don Jones utilise ces applets de commande.

En général, les gens tentent de réaliser cette tâche de la même façon que s'ils travaillaient dans un langage tel que VBScript, Perl, KiXtart ou un autre langage orienté texte. Je vais peut-être commencer par écrire une série d'en-têtes de colonnes à l'écran :
Write-Host "ColumnA'tColumnB'tColumnC"
Notez que `t est une séquence d'échappement spéciale dans Windows PowerShellTM qui insère un caractère de tabulation. Pour écrire chaque ligne de mon tableau, sans oublier que mes données sont dans $data1, $data2 et $data3, je dispose de plusieurs choix. L'un consiste simplement à écrire les variables, en comptant sur la capacité du shell à remplacer les variables par leurs contenus entre guillemets doubles :
Write-Host "$data1't$data2't$data3"
Une autre méthode légèrement plus attrayante pour y parvenir utilise l'opérateur –f. Cette technique sépare le formatage des données et produit ce qui est, selon moi, une ligne de code plus facile à lire et à gérer :
Write-Host "{0}'t{1}'t{3}" –f $data1,$data2,$data3
Cette approche pose cependant des problèmes importants. Tout d'abord, en comptant sur les taquets de tabulation fixes de la fenêtre de console, je peux m'attendre à des formatages étranges. Par exemple, si une ligne de tableau particulière a une valeur de 20 caractères dans la première colonne, je vais mettre en l'air tout le formatage de la ligne. De plus, comme j'obtiens ce texte via Write-Host, je suis quasiment limité à un affichage de console.
Il n'y a pas de méthode facile pour envoyer ce résultat vers un fichier ou pour le mettre dans d'autres formats, si jamais je le souhaitais. Plus important encore, cette approche basée sur le texte ignore complètement le shell basé sur les objets dans lequel je travaille. Elle ne tire pas parti des techniques et fonctionnalités incroyables qu'offre Windows PowerShell.

La méthode Windows PowerShell
Windows PowerShell est un shell orienté objets. Ceci signifie, dans l'idéal, que tout ce avec quoi vous travaillez doit se trouver dans des objets, ce qui permet au shell de transformer les choses en affichages texte lorsque c'est nécessaire. Mais comment créer des objets pour des éléments de données arbitraires ?
En gardant le même exemple, je commence par créer un objet personnalisé vide que j'enregistre dans une variable :
$obj = New-Object PSObject
Ceci me donne un nouvel objet vide à utiliser. J'ajoute ensuite mes données à l'objet sous la forme de propriétés. Pour ce faire, il me suffit de canaliser mon objet vers l'applet de commande Add-Member. J'ajoute quelque chose appelé NoteProperty, je donne un nom à la propriété (je vous recommande d'utiliser les en-têtes de colonnes comme noms de propriétés), puis j'insère les données comme valeurs des propriétés :
$obj | Add-Member NotePropertyColumnA $data1
$obj | Add-Member NotePropertyColumnB $data2
$obj | Add-Member NotePropertyColumnC $data3
À présent, je génère cet objet, pas sur la console, mais sur le pipeline :
Write-Output $obj
Je peux ensuite répéter alors ces étapes pour chacune des lignes de tableau que j'ai besoin de générer. Voici une fonction courte qui accepte une chaîne et génère une version en majuscules et en minuscules, ainsi que la chaîne originale :
functionStringVersions {
param([string]$inputString)
  $obj = New-Object PSObject
  $obj | Add-Member NoteProperty Original($inputString)
  $obj | Add-Member NoteProperty Uppercase($inputString.ToUpper())
  $obj | Add-Member NoteProperty Lowercase($inputString.ToLower())
  Write-Output $obj
}
$strings = @("one","two","three")
foreach ($item in $strings) {
StringVersions $item
}
Je commence par un tableau de variables de chaînes, que j'envoie une par une à la fonction. Et le résultat de la fonction est écrit dans le pipeline.
Notez qu'il y a des méthodes plus courtes pour écrire ce code, mais j'ai choisi cette technique parce qu'elle illustre clairement ce que je cherche à vous montrer. Le résultat, illustré à la figure 1, est un tableau parfaitement formaté. C'est parce que le shell sait déjà formater des objets dans un tableau.
Figure 1 Résultats Windows PowerShell affichés dans un tableau
Figure 1 Résultats Windows PowerShell affichés dans un tableau (Cliquez sur l'image pour l'agrandir)
Quand un objet a quatre propriétés (ou moins), Windows PowerShell choisit automatiquement un tableau. Ainsi, sans aucun travail de ma part, j'ai maintenant un superbe tableau.

Mais attendez, ce n'est pas tout !
Applet de commande du mois Get-Command
Je suis sûr que vous avez déjà utilisé Get-Command, ou son alias pratique (gcm), une fois ou deux pour passer en revue la liste d'applets de commande Windows PowerShell disponibles. Mais peut-être n'êtes-vous pas conscient de la flexibilité de gcm ? Ainsi, si vous voulez voir tout ce que Windows PowerShell peut faire avec un service, exécutez le service gcm-noun. Et si vous souhaitez voir toutes les options d'exportation Windows PowerShell, essayez l'exportation gcm -verb. Si vous avez juste besoin de voir quelles applets de commande ont été ajoutées par un composant logiciel enfichable particulier (par exemple PowerShell Community Extensions), essayez gcm -pssnapin pscx. (Vous pouvez remplacer « pscx » par n'importe quel nom de composant logiciel enfichable pour voir les applets de commande de ce composant logiciel enfichable).
Comme vous pouvez le voir, Get-Command joue un rôle primordial dans la détectabilité de Windows PowerShell. Elle vous permet de savoir quelle fonctionnalité est disponible sans avoir à consulter un manuel. Et notez que gcm représente une façon plus précise de découvrir des fonctionnalités que l'utilisation d'une commande telle que Help *. La fonction Help répertorie uniquement les rubriques d'aide disponibles. Toutes les applets de commande non accompagnées d'une aide n'y sont pas répertoriées, bien que les applets de commande soient à votre disposition si vous en avez besoin.

L'avantage de cette technique s'étend bien au-delà des tableaux. Lorsque vous travaillez avec des objets, Windows PowerShell sait comment faire une énorme quantité de choses. Vous souhaitez que vos données soient dans un fichier CSV ? Utilisez Export-CSV. Vous préférez un tableau HTML ? Transférez vos objets dans ConvertTo-HTML. Vous avez besoin d'un format de liste ? Transférez-les dans Format-List. En utilisant des objets, vous pouvez utiliser toutes les choses que le shell sait déjà faire. Voici un exemple révisé :
functionStringVersions {
  PROCESS {
   $obj = New-Object PSObject
   $obj | Add-Member NoteProperty Original($_)
   $obj | Add-Member NoteProperty Uppercase($_.ToUpper())
   $obj | Add-Member NoteProperty Lowercase($_.ToLower())
   Write-Output $obj
}
}
Cette fois, j'ai modifié la fonction pour accepter les entrées de pipeline. C'est toujours préférable lorsque vous travaillez avec des objets et pour effectuer la sortie sur le pipeline.
Cette fonction a maintenant son code à l'intérieur d'un scriptblock PROCESS. Ceci signifie que cette fonction acceptera les entrées de pipeline et qu'elle exécutera le scriptblock PROCESS une fois pour chaque objet transféré.
À l'intérieur du scriptblock PROCESS, la variable spéciale $_ se réfère à l'objet de pipeline actuel en cours de traitement. Résultat pratique : à présent, je peux simplement transférer un ensemble de chaînes :
@("one","two","three") | StringVersions
J'obtiens un tableau parce que la fonction met son résultat dans le pipeline. À la fin du pipeline, le shell sait qu'il doit appeler son sous-système de formatage, qui prend la décision d'utiliser un tableau parce que les objets du pipeline ont moins de cinq propriétés (pour plus de propriétés, le shell utilisera une liste par défaut).
Mais je ne suis pas obligé de compter sur le comportement par défaut. Je peux simplement transférer ces objets vers une autre applet de commande pour en faire autre chose :
@("one","two","three") | StringVersions | Format-List
@("one","two","three") | StringVersions | ConvertTo-HTML | Out-File "strings.html"
@("one","two","three") | StringVersions | Export-CSV "strings.csv"
@("one","two","three") | StringVersions | Select Uppercase,Lowercase -unique
La figure 2 montre le code HTML résultant du second exemple affiché dans un navigateur Web. En représentant simplement mes données de sortie dans des objets, plutôt qu'en tant que texte simple, j'ai maintenant un accès complet à de nombreuses fonctionnalités qui sont intégrées dans le shell : toute une gamme de dispositions de format, conversion HTML, options d'exportation, la possibilité de trier, filtrer et regrouper et bien plus encore.
Figure 2 Sortie de données Windows PowerShell au format HTML
Figure 2 Sortie de données Windows PowerShell au format HTML (Cliquez sur l'image pour l'agrandir)
C'est très puissant. En fait, j'irai même jusqu'à suggérer que chacun des scripts que vous écrivez produise un objet comme résultat afin que vous puissiez utiliser ce résultat d'autant de façons différentes possibles, le tout sans avoir à écrire une seule ligne de code supplémentaire.

Don Jonesest un expert dans l'automatisation administrative de Windows et a rédigé des ouvrages tels que Windows PowerShell: TFM and VBScript, WMI, and ADSI Unleashed. Vous pouvez le contacter par l'intermédiaire des forums du site ScriptingAnswers.com.


Hé, vous le scripteur ! Pas besoin de travailler dur pour être récompensé
Les scripteurs Microsoft

Télécharger le code de cet article: HeyScriptingGuy2008_06.exe (150KB)

Pendant des siècles, les gens ont pensé que le travail assidu était une récompense en soi, que la véritable satisfaction venait d'une journée de travail honnête...bref, vous voyez où je veux en venir. Travaillez dur et sans vous plaindre (pensez à Cendrillon), et, un jour, vous serez récompensé.
Remarque : Mais est-ce vraiment possible ? Si vous travaillez dur, non seulement vous serez plus heureux mais, un jour, vous serez récompensé pour vos efforts ? Pourquoi nous posez-vous une telle question ?
Bien sûr, Cendrillon a eu de la chance. Après tout, si vous habitez avec une belle-mère et quelques demi-sœurs malveillantes, vous avez toutes les chances de travailler dur. Mais qu'en est-il si vous n'est pas si chanceux ? Que se passe-t-il si vous ne vivez pas avec une belle-mère et quelques demi-sœurs malveillantes ? Comment êtes-vous supposé passer des journées de travail ingrates, exténuantes et interminables ? Vous pensez que vous allez vraiment trouver le bonheur ?
Eh bien, si vous souhaitez vraiment travailler comme un dingue, les scripteurs suggèrent que vous essayiez d'écrire un script qui affiche des données sous la forme d'un tableau net et agréable, comme les résultats affichés à la figure 1.
Figure 1 Résultats sous forme de tableau
Figure 1 Résultats sous forme de tableau (Cliquez sur l'image pour l'agrandir)
Comme nous l'avons dit, Cendrillon a eu beaucoup de chance : Elle nettoyait la maison du sol au plafond, et une fois ce travail terminé, s'asseyait parmi les cendres et la suie. Mais même Cendrillon aurait hésité avant d'écrire un script qui puisse afficher des données sous la forme d'un tableau. S'asseoir parmi les cendres et la suie, c'est une chose. Écrire un script qui affiche des données sous la forme d'un tableau est entièrement différent.
Remarque : À moins de devoir vous asseoir dans la cheminée pour écrire vos scripts ; il s'agit alors, à peu de chose près, de la même chose.
Pourquoi Cendrillon hésiterait-elle devant cette tâche ? Parce que c'est trop difficile. Le seul moyen d'afficher des données sous la forme d'un tableau dans VBScript consiste à faire ce qui suit :
  • Commencez par déterminer la taille maximale de chaque colonne. Par exemple, vous pouvez souhaiter que le nom d'affichage d'un service contienne 52 espaces de caractère.
  • Calculez ensuite le nombre d'espaces dans un élément de données. Par exemple, le nom d'affichage Adobe LM Service contient 16 caractères.
  • Si le nom d'affichage dépasse la limite de 52 caractères, déterminez le nombre d'espaces à supprimer à la fin de la chaîne pour que le nom entre dans l'espace attribué. Si le nom d'affichage ne dépasse pas 52 espaces de caractère, déterminez combien d'espaces vides doivent être ajoutés à la fin de la chaîne pour que la longueur soit exactement de 52 caractères.
  • Répétez cette procédure pour la série suivante de données. Et la suivante. Et ainsi de suite.
Si vous connaissez l'histoire de Cendrillon, alors vous savez qu'il est possible que votre bonne fée apparaisse de manière non annoncée, transforme une souris en un administrateur système (aucun commentaire sur la facilité d'exécution de cette tâche !), puis la souris écrira ce script à votre place. Mais ne comptez pas trop sur ce dénouement. Vous êtes probablement seul ici.
Cependant, si on regarde la vie du bon côté, vous serez la personne la plus satisfaite au monde. Parce que vous serez également la personne ayant travaillé le plus durement au monde. La personne ayant travaillé le plus durement, et de loin.
Bien sûr, certaines personnes souhaitent échanger une petite satisfaction contre la possibilité de ne pas avoir à travailler si dur. Si vous êtes une de ces personnes, vous pensez probablement, « Dieu merci, les scripteurs sont là. Ils vont me dire comment modifier une souris en un administrateur système, puis me dire comment obliger cette souris à formater mes résultats dans un tableau. » J'ai bien peur que nous ayons des mauvaises nouvelles pour vous : les scripteurs n'ont aucune idée sur la manière de transformer une souris en un administrateur système. (Bien que nous puissions transformer un administrateur système en une souris, si cela vous est utile.) Nous ne savons pas comment vous pouvez obtenir que quelqu'un d'autre écrive des scripts à votre place, des scripts qui afficheront des données sous la forme d'un tableau.
Mais peu importe. Tant que vous exécutez Windows® XP ou Windows Server® 2003 (ce qui est le cas pour beaucoup d'entre vous), vous n'avez pas besoin d'une souris pour écrire vos scripts à votre place. (Non, désolé, j'ai bien peur que ça ne fonctionne pas sur Windows Vista®.) À la place et avec un effort minimal, vous pouvez effectuer ceci grâce à l'objet Microsoft.CmdLib. Regardez le script d'exemple à la figure 2.
Figure 2 Création d'un affichage sous forme de tableau
Dim arrResultsArray()
i = 0

Set objCmdLib = _
  CreateObject("Microsoft.CmdLib")
Set objCmdLib.ScriptingHost = _
  WScript.Application

arrHeader = Array("Display Name", _
  "State", "Start Mode")
arrMaxLength = Array(52, 12, 12)
strFormat = "Table"
blnPrintHeader = True
arrBlnHide = Array(False, False, False)

strComputer = "."

Set objWMIService = GetObject("winmgmts:\\" _
  & strComputer & "\root\cimv2")

Set colServices = objWMIService.ExecQuery _
  ("Select * FROM Win32_Service")

For Each objService In colServices
  ReDim Preserve arrResultsArray(i)
  arrResultsArray(i) = _
  Array(objService.DisplayName, _
    objService.State,objService.StartMode)
  i = i + 1
Next
objCmdLib.ShowResults arrHeader, _
  arrResultsArray, arrMaxLength, _
  strFormat, blnPrintHeader, arrBlnHide
Au cas où vous vous poseriez la question, Microsoft.CmdLib est un objet COM expédié avec Windows XP et Windows Server 2003. Cet objet a plusieurs fonctionnalités différentes. Pour plus d'informations, tapez cmdlib.wsc /? à l'invite de commande et lisez les commentaires dans le fichier de script qui apparaît à l'écran. Aujourd'hui, nous nous intéressons uniquement à une seule fonctionnalité de Microsoft.CmdLib : la capacité d'afficher des données sous la forme d'un tableau.
Ceci mène à une question évidente : Comment afficher des données sous la forme d'un tableau ? Voyons si nous pouvons faire quelque chose. Comme vous pouvez le voir, notre script d'exemple commence par la définition d'un tableau dynamique appelé arrResultsArray :
Dim arrResultsArray()
Dans un script typique, les données sont renvoyées sur l'écran aussi rapidement qu'elles sont extraites. Mais pourquoi espériez-vous que les scripteurs fassent tout d'une manière typique ? Dans ce script, nous n'allons pas renvoyer les données comme elles ont été extraites. À la place, nous allons stocker toutes les données renvoyées dans un tableau, puis laisser Microsoft.CmdLib effectuer le formatage et l'affichage des données pour nous.
En d'autres termes, voilà pourquoi nous commençons par créer un tableau dynamique (c'est-à-dire un tableau qui peut être redimensionné tout au long du script). Après avoir défini le tableau, nous définissons la valeur d'une variable counter appelée i sur 0. Nous allons utiliser cette variable pour suivre la taille actuelle du tableau.
Au cas où vous vous poseriez la question, nous définissons la valeur i sur 0 parce que le premier élément dans un tableau reçoit toujours le numéro de référence 0. Par conséquent, lorsque nous ajoutons le premier élément dans le tableau, nous ajoutons l'élément 0 au lieu de l'élément 1.
Nous devons ensuite lancer notre instance de l'objet Microsoft.CmdLib. Voilà ce que représentent les deux lignes de code suivantes :
Set objCmdLib = _
CreateObject("Microsoft.CmdLib")
Set objCmdLib.ScriptingHost = WScript.Application
Et cela nous amène à ce petit bloc de code :
arrHeader = Array("Display Name", "State", "Start Mode")
arrMaxLength = Array(52, 12, 12)
strFormat = "Table"
blnPrintHeader = True
arrBlnHide = Array(False, False, False)
Ce que nous faisons ici, c'est définir quelques paramètres pour configurer nos résultats. Sur la première ligne, nous attribuons des valeurs à un tableau appelé arrHeader. Comme vous pouvez vous y attendre, elles correspondent à des en-têtes pour chaque colonne dans notre tableau de résultats. Pour ce script d'exemple, nous récupérons les informations sur les services s'exécutant sur un ordinateur, puis affichons les valeurs des propriétés DisplayName, State et StartMode pour chaque service.
Il n'est pas surprenant que nous attribuions à notre tableau les noms de colonne DisplayName, State et StartMode (bien que nous aurions pu facilement attribué à nos colonnes les noms A, B C, Pierre, Marie et Carine ou tout autre chose. Il n'est pas nécessaire que les noms de colonne soient identiques aux noms de propriétés).
Remarque : Il existe de nombreuses variations de l'histoire de Cendrillon, y compris les noms de ses demi-sœurs. Dans la version Disney de Cendrillon, les demi-sœurs s'appellent Javotte et Anastasie. Il se trouve que ces deux noms sont les premiers et deuxièmes prénoms de nos scripteurs !
Dans la deuxième ligne de code, nous attribuons les valeurs à un autre tableau, appelé arrMaxLength. Ce tableau contient la taille de chaque colonne dans le tableau. Dans nos résultats, nous souhaitons allouer 52 espaces de caractère à la colonne 1 (le nom d'affichage du service). Nous voulons ensuite allouer 12 espaces à l'état de service et 12 espaces au mode de démarrage. (Microsoft.CmdLib insère automatiquement un espace vide entre les colonnes.) Si nous souhaitons que les tailles de nos colonnes soient 52, 12 et 12 espaces de caractère (ce que nous faisons), nous utilisons le code qui ressemble à ce qui suit :
arrMaxLength = Array(52, 12, 12)
La troisième ligne spécifie le format des résultats de nos données. Nous souhaitons que les données s'affichent sous forme de tableau. Par conséquent, nous définissons la valeur strFormat (la variable qui contient le type de résultats) sur Table. Supposez plutôt que nous souhaitions afficher les données en tant que liste de valeurs séparées par des virgules. Dans ce cas, nous définirions le format sur CSV, comme suit :
strFormat = "CSV"
Et nous obtiendrions donc des résultats semblables à ce que nous avons ici :
"Display Name","State","Start Mode"
"Adobe LM Service","Stopped","Manual"
"Adobe Active File Monitor V4","Stopped","Manual"
"Alerter","Stopped","Manual"
"Application Layer Gateway Service","Running","Manual"
"Apple Mobile Device","Running","Auto"
"Application Management","Stopped","Manual"
Remarquez comment Microsoft.CmdLib a non seulement placé des virgules entre chaque article, mais a également inséré les valeurs individuelles entre guillemets. Il s'agit d'une fonctionnalité plus agréable que vous pourriez le penser. Après tout, pour faire ceci manuellement, vous devez utiliser le code suivant :
Wscript.Echo Chr(34) & objService.DisplayName & Chr(34) & "," & Chr(34) & objService.State & Chr(34) & "," & Chr(34) & objService.StartMode & Chr(34)
Mouais.
Qu'est-ce que c'est ? Vous n'aimez pas les tableaux et vous n'aimez pas le format CSV non plus ? Dans ce cas, essayez de définir le format sur List, ce qui vous offre des résultats semblables à ce qui suit :
Display Name: Adobe LM Service
State:        Stopped
Start Mode:   Manual
Display Name: Adobe Active File Monitor V4
State:        Stopped
Start Mode:   Manual
Mais nous nous éloignons... (ce que nous sommes enclins à faire de temps à autre !) Après avoir défini le format des résultats, nous définissons la valeur d'une variable appelée blnPrintHeader sur True :
blnPrintHeader = True
Nous utilisons blnPrintHeader pour demander à Microsoft.CmdLib d'imprimer les en-têtes de colonnes. Que se passe-t-il si nous ne souhaitons pas imprimer les en-têtes de colonnes ? Pas de problème. Dans ce cas, définissez blnPrintHeader sur False :
blnPrintHeader = False
Enfin, nous obtenons la ligne de code suivante :
arrBlnHide = Array(False, False, False)
Lorsqu'il est temps d'afficher vos données, Microsoft.CmdLib vous offre la possibilité d'afficher ou de masquer une colonne. Pour masquer une colonne (c'est-à-dire, supprimer les données pour une propriété particulière), définissez la valeur de cette propriété sur True. Pour afficher une colonne, définissez la valeur sur False.
Dans nos résultats, nous affichons les valeurs pour les propriétés DisplayName, State et StartMode, dans cet ordre. Nous utilisons donc les valeurs False, False, False dans notre tableau. Que se passerait-il si nous souhaitions afficher DisplayName, masquer State et afficher StartMode ? Dans ce cas, nous utiliserions la ligne de code suivante :
arrBlnHide = Array(False, True, False)
N'oubliez pas d'utiliser False pour afficher une colonne et True pour masquer une colonne.
À ce stade, nous sommes prêts à afficher certaines données ou nous le serions si nous disposions de quelques données. (Les scripteurs ont-ils un jour écrit un script qui n'a pas affiché de données, puis passé un temps incroyable à déboguer ce script, pour découvrir qu'ils avaient tout simplement oublié de récupérer des données ? Euh, bien sûr que non ! Qu'est-ce qui vous faire dire cela ?)
En gardant ceci à l'esprit, l'étape suivante consiste à effectuer la liaison avec le service Windows Management Instrumentation (WMI) sur l'ordinateur local, utilisez alors la méthode ExecQuery pour récupérer les informations sur tous les services installés sur cet ordinateur :
strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")

Set colServices = objWMIService.ExecQuery ("Select * FROM Win32_Service")
Il est nécessaire de noter que vous n'êtes pas obligé de travailler uniquement avec des données WMI ici. Comme vous pouvez vous y attendre, Microsoft.CmdLib peut fonctionner avec tout type de données. WMI est simplement une manière pratique de récupérer beaucoup de données.
Une fois que nous disposons de notre collection de données associées aux services, nous définissons une boucle For Each pour effectuer un cycle via tous les services dans la collection. Cependant, au lieu de renvoyer les valeurs de propriété pour chaque service, nous exécutons le code suivant :
ReDim Preserve arrResultsArray(i)
arrResultsArray(i) = Array(objService.DisplayName, objService.State,objService.StartMode)
i = i + 1
Que faire dans ce bloc de code ? À la ligne 1, nous redimensionnons notre tableau, avec la commande ReDim Preserve pour non seulement redimensionner le tableau mais également conserver toutes les données existantes de ce tableau. (sans le mot-clé Preserve, le tableau sera redimensionné, mais aucune donnée actuellement dans ce tableau ne serait effacée.)
Quelle taille du tableau souhaitons-nous ? La première fois par la boucle, nous créons un tableau de taille 0. En d'autres termes, nous créons un tableau contenant un élément. Et comment savons-nous à coup sûr que nous créons un tableau de taille 0 ? Parce que nous utilisons la variable counter i et que cette variable est égale à 0.
Par conséquent, si nous utilisons la variable i pour représenter la taille du tableau, est-ce que cela ne revient pas à définir la taille sur 0 ? Si mais à chaque fois que nous nous traversons la boucle, nous incrémentons la valeur de i de 1. Comme vous pouvez le constater, c'est ce que nous faisons à la ligne 3 de notre bloc de code.
Cela nous laisse avec une seule ligne de code :
arrResultsArray(i) = Array(objService.DisplayName, objService.State,objService.StartMode)
Il nous suffit de prendre les valeurs de propriété qui nous intéresse (DisplayName, State et StartMode) et de les ajouter au tableau arrResultsArray. Remarquez que nous n'ajoutons pas les valeurs de propriété de manière individuelle. À la place, nous les ajoutons comme un tableau de valeurs. Je vous l'accorde, c'est un peu insolite : ceci signifie que chaque élément dans le tableau arrResultsArray sera un autre tableau. Voilà comme Microsoft.CmdLib fonctionne.
Bien sûr, cela peut vous inquiéter. « Un tableau de tableaux ? Comment puis-je accéder à toutes les valeurs individuelles dans un tableau plein de tableaux ? » Ne vous affolez pas. C'est facile : Laissez Microsoft.CmdLib s'en occuper pour vous.
Remarque : Désolé, mais accéder à toutes les valeurs individuelles dans un tableau de tableaux, c'est à peu près la seule chose que Microsoft.CmdLib peut faire pour vous. Cependant, nettoyer les chambres de votre belle-mère malveillante, faire la vaisselle et repriser des vêtements de vos demi-sœurs diaboliques sont envisagés pour la version suivante de l'objet.
En fait, nous pouvons afficher nos données (sous la forme d'un tableau net) en appelant simplement la méthode ShowResults et transmettant la méthode de tous les tableaux et toutes les variables que nous avons configurées précédemment dans le script :
objCmdLib.ShowResults arrHeader, arrResultsArray, arrMaxLength, strFormat, blnPrintHeader, arrBlnHide
À quoi tout cela va-t-il ressembler ? Cela ressemblera aux résultats formatés que nous espérions obtenir lorsque nous regardions la figure 1.
Pas mal, non ? Vous obtenez des résultats agréables et vous avez à peine travaillé. (et votre script suivant sera encore plus facile, parce que tout ce que vous aurez à faire, ce sont quelques changements mineurs à ce premier script.)
Maintenant, il est vrai que vous n'obtiendrez pas la même satisfaction que Cendrillon qui était une esclave jour et nuit pour pouvoir afficher les résultats de script dans un tableau. Et, pour être honnête, vous n'épouserez probablement pas un prince non plus ! Mais, bon, ça, ça ne faisait pas partie du contrat ! Mais c'est un petit prix à payer pour obtenir des résultats agréables d'un script VBScript, surtout lorsque vous prenez en considération ce que sont les princes d'aujourd'hui.
Et qui sait : vous pourriez peut-être épouser quand même un prince. Après tout, même la royauté a besoin d'obtenir des informations sur tous les services installés sur leurs ordinateurs, n'est-ce pas ?

Les scripts embrouillés du Dr. Scripto
Le défi mensuel qui teste non seulement vos compétences de résolution des énigmes, mais également vos compétences d'écriture de scripts.

Juin 2008 : Chemin PowerShell
Dans chacun de ces jeux, reliez les lettres horizontalement, verticalement et en diagonale pour créer le nom d'une cmdlet Windows PowerShell. Chaque lettre ne peut être utilisée qu'une seule fois. Voici un exemple :
La cmdlet créée dans ce jeu est New-Alias. À votre tour. Voici trois jeux supplémentaires :

ANSWER:
Les scripts embrouillés du Dr. Scripto
Réponses : Chemin PowerShell, juin 2008

Read-Host

Set-AuthenticodeSignature

Les scripteurs Microsoft travaillent pour (enfin, sont employés par) Microsoft. Lorsqu’ils ne sont pas en train de jouer au base-ball, d’entraîner une équipe ou de regarder un match (ou de se livrer à de multiples autres activités), ils dirigent le Script Center TechNet. Vous pouvez le vérifier vous-même sur www.scriptingguys.com.


Histoires de Bureau Sécurité contre conformité
Wes Miller

En tant que professionnel de l'informatique, vous êtes confronté à des objectifs qui doivent se compléter, mais qui à la place se font concurrence. La sécurité et la conformité sont deux exemples d'objectifs organisationnels de ce type, pour lequel la réussite de l'un devrait améliorer l'autre. Ce n'est hélas habituellement pas le cas. Mon but, au travers de cet article, est de vous donner
un aperçu général des raisons pour lesquelles la sécurité n'est pas nécessairement synonyme de conformité aux initiatives exigées de vous, et des raisons pour lesquelles la conformité n'est souvent pas synonyme de sécurité, ou tout du moins de la sécurité obtenue si la conformité allait véritablement de pair avec la sécurité.

La sécurité n'est pas une case à cocher
Ressources SDL
  • The Security Development Lifecycle, par Michael Howard et Steve Lipner (Microsoft Press, 2006)
  • Le blog du Cycle de vie de développement de la sécurité
  • Un examen du Cycle de vie de développement de la sécurité chez Microsoft
  • Centre de sécurité pour développeurs
  • Le Cycle de vie de développement de la sécurité Trustworthy Computing

La conformité implique généralement des exigences (en termes de personnes, processus, infrastructure, technologie, etc.) imposées à une organisation, un secteur, une entreprise ou un produit extérieur. Parfois, la conformité a trait aux normes promulguées au sein du secteur (comme les normes de sécurité des données du secteur des cartes de paiement ou PCI-DSS). Dans l'idéal, il s'agit d'initiatives qui s'alignent sur la manière dont votre organisation fonctionne déjà, tout du moins jusqu'à un certain degré. Tandis que l'adoption d'une norme s'étend, vous vous retrouvez dans l'incapacité de l'ignorer, pour pouvoir continuer vos activités. En fin de compte, vous devez faire le saut et essayer d'en tirer profit au maximum.
C'est l'autre type de conformité qui pose habituellement plus de problèmes. Je fais ici référence aux initiatives mises en œuvre par le gouvernement, comme les lois Health Insurance Portability and Accountability Act (HIPAA) et Sarbanes-Oxley, pour lesquelles la mise en œuvre et la planification font rarement l'objet d'un choix.
Le point essentiel à comprendre en ce qui concerne la conformité aux réglementations est qu'elle est souvent synonyme d'une approche « de haut en bas ». Il existe généralement un modèle de forme complexe qui définit l'initiative et vous devez examiner vos produits et vos processus pour tâcher de voir dans quelle mesure ils peuvent s'adapter au modèle qui vous a été donné. Vous devez rester conscient non seulement des intentions de l'initiative de conformité mais, ce qui est peut-être plus important, des ramifications légales ou financières lorsque celle-ci n'est pas mise en œuvre ou n'est pas réussie (si celles-ci existent).
Bien que nous puissions tous être d'accord avec les intentions de nombreuses initiatives de conformité, leur mise en œuvre est souvent difficile et peut ne pas répondre à l'objectif désiré. Hélas, nombre d'entre elles n'ont aucun pouvoir (c'est-à-dire qu'aucune conséquence légale ou financière ne peut être imposée en cas d'échec).
Je peux par exemple vous dire que, en tant que patient, je ne peux pas décrire complètement les avantages directs pour moi du HIPAA. Ce que je peux vous dire, c'est qu'il est synonyme pour moi d'un travail administratif beaucoup plus important lorsque je rends visite à un docteur. Les conséquences imprévues peuvent être pires. Avez-vous déjà essayé de transférer des informations médicales d'un docteur ou cabinet médical vers un autre ? Sans autorisation écrite, cela ne se produira pas, quelle que soit l'urgence de la nécessité des informations.
Pour résumer, de nombreux points de vue, certaines initiatives de conformité deviennent des initiatives à cases à cocher. C'est-à-dire que vous concevez ou modifiez votre processus ou votre produit uniquement pour répondre aux initiatives de conformité. Comme je le demande souvent à mon enfant de trois ans, « Est-ce vraiment une bonne idée » ?
La sécurité, d'un autre côté, est une initiative du bas vers le haut, lorsqu'elle est effectuée correctement. Si vous concevez un produit logiciel ou l'architecture du nouveau réseau de votre entreprise, le concept essentiel est de se rappeler de prendre deux fois la mesure et de couper une seule fois. Lorsque vous concevez l'architecture d'un produit, par exemple, tout comme une bonne passe initiale décrirait la communication, la localisation, les versions, etc., vous devez décrire les éléments de sécurité qui doivent être intégrés à l'application dès le premier jour (et ceux que vous devez continuer à examiner et peaufiner tout au long du développement).
Si vous travaillez avec une application ou une architecture que vous avez héritée (je suis sûr que c'est le cas pour la plupart d'entre-vous), il est tout aussi essentiel d'effectuer le type d'examen de sécurité approfondi que je mentionne souvent dans cette rubrique. Si vous ne comprenez pas comment quelque chose fonctionne, comment pourriez-vous comprendre à quelque point il est ou non sécurisé ? Pour plus d'informations sur le Cycle de vie de développement de la sécurité Microsoft® (Security Development Lifecycle, SDL), voyez l'encadré « Ressources SDL ».

Une vue d'ensemble
Je me souviens avoir très tôt été instruit du fait que la sécurité ne se résume pas à implémenter simplement le chiffrement, les listes de contrôle d'accès (ACL) ou TLS, ou encore l'infrastructure de clé publique (PKI). La véritable sécurité est la compréhension de la vue d'ensemble : comprendre pourquoi cette version de ce protocole a été abandonnée ou n'a même jamais été prise en charge, pourquoi ce nouveau bout de plomberie arrête les attaques de type man-in-the-middle, en quoi votre mise en œuvre pour le produit version 2 est beaucoup plus sécurisée que la version 1, même si la version 1 était beaucoup plus rapide. Il est également nécessaire que vous compreniez comment s'assemblent toutes les parties de votre infrastructure.
La conformité, d'un autre côté, signifie prendre votre technologie et vous assurer que l'infrastructure que vous avez créée répond à certains critères. Certaines initiatives, telles que les normes de sécurité des données du secteur des cartes de paiement (PCI-DS) ou le North American Electric Reliability Council, ont un objectif louable et peuvent en fin de compte engendrer de véritables modifications de la sécurité. Mais en fin de compte, avec un plateau varié d'initiatives de conformité que vos devez broder à vos projets particuliers, ainsi qu'un nombre de ressources limité, les initiatives de sécurité perdent du terrain.
La sécurité a longtemps été l'enfant négligé du développement de logiciel. Nombre d'entre vous ont certainement déjà été dans une entreprise dans laquelle la sécurité était quelque chose « que nous ferons plus tard ». Eh bien, les initiatives de conformité sont maintenant appelées à demeurer, car cette croyance, que la sécurité peut attendre, ne fonctionne pas et n'a jamais fonctionné.

Suffisant
J'ai récemment changé d'emploi. Je travaille maintenant dans une startup d'Austin, au Texas, qui crée une technologie de création de liste d'applications autorisées quelque peu similaire à la technologie que nous avons créée à Winternals avec notre produit Protection Manager. Je trouve intéressant de savoir à quel point les clients pensent que leurs technologies actuelles sont sécurisées ou, plus particulièrement, à quel point ils estiment que l'ensemble de technologies qu'ils utilisent rend leur infrastructure sécurisée. Même s'il est probable que la plupart d'entre elles soient sécurisées et non remplies de failles ouvertes aux vulnérabilités de sécurité, la réponse que j'entends souvent et qui me fait quelque peu grimacer est qu'un système est « assez sécurisé ».
Les initiatives de conformité sont amusantes. Vous pouvez les respecter ou ne pas y arriver. Cette responsabilité vous appartient. Le coût du manquement à une initiative est habituellement une amende, une pénalité ou la résiliation d'une organisation. Il n'est souvent pas suffisant de s'assurer que quoi que ce soit change véritablement.
Dans le cas d'une initiative commandée par l'administration, je rencontre régulièrement l'attitude, « assez bonne pour plaire à l'auditeur, » ou la volonté de fonctionner sans mettre une infrastructure de conformité en place car la législation d'arrière-plan (à l'image de HIPAA) ne subventionne pas suffisamment la mise en œuvre, ce qui signifie qu'il est beaucoup moins coûteux de fonctionner sans assurance et de faire face aux conséquences potentielles plus tard.
La sécurité bute souvent sur le même barrage, mais je pense qu'elle est au moins plus concrète. Si vous, en tant que développeur ou en charge de la mise en œuvre, dites activement à votre administration que laisser la section X hors de la spécification rendra le produit beaucoup plus vulnérable, vous pourrez au moins après la sortie du produit ou une fois le déploiement terminé, dire « je vous l'avais dit ». En ce qui concerne les initiatives de conformité, j'ai souvent constaté que leur adoption s'effectue souvent trop rapidement, avec un budget aussi limité que possible. L'objectif est simplement de répondre au minimum requis par l'initiative, en répondant peut-être plus tard à l'objectif de l'initiative mais rarement à son esprit, à mon avis.

Décidez où vous vous trouvez
Ressources de sécurité et conformité
  • Recommandations de solutions de sécurité et conformité
  • Instructions de sécurité
  • Guide de planification de conformité aux normes PCI DSS
  • Conformité réglementaire et mises à jour de sécurité
  • À la poursuite de la conformité
  • Office for Civil Rights—HIPAA
  • PCI Security Standards Council
  • North American Electric Reliability Council

Bien qu'il puisse être idéaliste de ma part de dire que vous devriez rendre votre produit et votre organisation aussi sécurisés que possible, dans la réalité la plupart des initiatives de conformité sont en fait un compromis résultant d'une ingénierie passable, ou plus souvent, d'autosatisfaction. Nous vivons dans un monde dans lequel « suffisant » est, malheureusement, suffisant. Dans le monde de la sécurité, cependant, il est rarement sage de se contenter d'un « suffisant ». Nous autres professionnels de l'informatique pouvons prendre à cœur les initiatives de conformité et essayer d'y répondre dans l'esprit et la mise en œuvre, mais devons tout de même nous assurer que l'infrastructure que nous mettons en place n'est pas simplement aussi sécurisée que possible, mais aussi sécurisée qu'elle doit l'être. En d'autres termes, elle doit être conforme à une véritable sécurité et non répondre seulement à l'initiative.
Il est important de regarder en arrière et d'examiner la technologie que vous créez, qu'il s'agisse d'un élément de logiciel commercial ou d'un ensemble de technologies que vous cherchez à intégrer dans un système de plus grande taille. Je ne peux pas insister assez sur l'importance de la compréhension des parties complémentaires du système, de la manière dont les éléments fonctionnent ensemble et des plus grandes menaces auxquelles votre système doit faire face.
En fonction du secteur dans lequel vous travaillez, différentes initiatives de conformité peuvent jouer un rôle dans votre travail. Vous pouvez les rencontrer dans votre vie quotidienne ou seulement lorsque vous concevez de nouveaux projets ou technologies. Il est également possible qu'elles interviennent uniquement dans votre travail pendant des revues ou audits de conformité désignés spécifiquement. Peu importe. Je ne pense pas que ces initiatives de conformité devraient être ignorées, mais je vous mets au défi de défier le statu quo, et au lieu de chercher uniquement à répondre aux initiatives de conformité qui vous sont affectées, effectuez un examen complet de la sécurité pour comprendre votre technologie de bout en bout, et modelez-la pendant votre revue de conformité.

Qu'avez-vous à perdre ?
En fin de compte, les pénalités en cas de non-conformité à une initiative peuvent sembler ambiguës. Le manque de conformité vous met à la merci du scénario précis pour lequel l'initiative a été mise en place afin de vous protéger. Les conséquences peuvent sembler vagues ou distantes, mais elles sont vraies. Elles peuvent ne pas non plus être vos conséquences (personnelles). Soyez pragmatique, mais gardez toujours à l'esprit les scénarios les plus catastrophiques.
Si vous examinez le même espace, du point de vue strict de la sécurité, la menace doit être évidente et, ce qui est plus important, vous devriez être à même d'identifier tout de suite le coût potentiel de la vulnérabilité si elle reste ouverte.
De nombreuses personnes avec lesquelles j'ai discuté de ce sujet ont souligné le fait que ces initiatives de conformité sont mises au placard, puisque celles-ci laissent souvent une grande partie ouverte à l'interprétation. Une fois vous avez mené une revue de sécurité, cependant, cela ne devrait plus être vrai en ce qui concerne toute omission de sécurité. Les menaces immédiates de sécurité ignorées doivent être clairement visibles. Si elles ne le sont pas, il peut être souhaitable de réexaminer qui est impliqué dans les revues de sécurité. Il est possible que vous ayez besoin d'un membre clé pouvant aider à trouver les véritables problèmes de votre solution.

Se mordre la queue
Dans un article de l'année dernière portant sur la sécurité, j'ai parlé de « Comment ne pas perdre vos données » (technet.microsoft.com/magazine/cc162325). Dans le courant de l'année, davantage de systèmes ont été compromis, davantage de portables non chiffrés ont été perdus et davantage d'informations personnelles ont été placées entre des mains douteuses. Il est difficile de dire si un progrès quelconque a été effectué. Pourquoi sommes-nous toujours dans la même situation ? Les projets sont souvent en retard, avec un budget réduit, des ressources ridiculement surexploitées, en essayant de livrer trop de fonctionnalités en un temps trop court.
Ce type d'environnement, malheureusement, mène à un autre dans lequel le minimum de travail devient la norme. Cela n'est certainement pas une manière de garantir qu'une solution sera sécurisée ou conforme, et pas non plus fatal pour le planning ou les coûts d'un projet.
Personnellement, je crois fermement que :
  1. vous ne devriez pas créer une solution si vous n'êtes pas prêt à la sécuriser.
  2. Chaque fois que vous ajoutez de nouvelles fonctionnalités, vous devez concevoir leur sécurité avant de commencer.
  3. Si votre entreprise ne souhaite pas intégrer la sécurité en tant qu'étape de votre processus d'ingénierie, vous devez remettre en question votre entreprise ou ses objectifs organisationnels généraux.
Les entreprises possèdent de plus en plus de données personnelles de clients ou partenaires qu'elles ont la responsabilité de conserver en sécurité. Il est malheureux que nous vivions dans un monde dans lequel, trop souvent, la sécurité n'est pas un choix par défaut et dans lequel les employés n'osent pas remettre en question l'engagement de l'entreprise envers la qualité.
Un échec de la sécurité (et non de la conformité) devient bien trop souvent un signal indiquant « qu'il est grand temps de sécuriser le système » et « l'assurance contre l'usurpation d'identité » est devenue une tactique de responsabilité standard pour apaiser clients, élèves, patients et employés dont les données personnelles, et leur bien-être financier potentiel, ont été compromis.
On nous demande à tous trop souvent d'en faire beaucoup, souvent pour trop peu, et habituellement dans un temps trop court. Mais il est de notre responsabilité en tant que professionnels de l'informatique de nous interroger sur le fait que la sécurité n'est pas le point central, des raisons pour lesquelles trop souvent l'administration pense uniquement à la sécurité lorsqu'elle fait face à des initiatives de conformité ou, plus probablement, à une défaillance de la sécurité et ses menaces légales potentielles ou véritables (qui pourraient potentiellement gêner ou mettre à risque l'organisation).

Relevez mon défi
Plus que tout, je vous invite à défier le statu quo. S'il vous est seulement demandé de répondre aux objectifs de conformité, essayez de vous assurer, pendant que vous le faites, que vous ne gaspillez pas seulement du temps à respecter le concept de sécurité de quelqu'un d'autre. Assurez-vous, plutôt, que votre objectif est de sécuriser le système et, en cours de route, définissez une partie assez importante du processus ou de votre infrastructure pour respecter l'initiative de conformité. Pour plus d’informations sur ce sujet, consultez l’encadré « Ressources de sécurité et conformité ».
Pour résumer, rappelez-vous que cette conformité n'est pas nécessairement une voie vers la sécurité. La sécurité, cependant, si elle est mise en œuvre et utilisée correctement, peut souvent s'avérer être un chemin vers la conformité.

Wes Miller est responsable de produit technique pour CoreTrace (www.CoreTrace.com) à Austin au Texas. Il a auparavant travaillé chez Winternals Software et comme responsable de programme pour Microsoft. Vous pouvez contacter Wes à l’adresse suivante : technet@getwired.com.


L'informatique dans l'entreprise 10 façons de devenir un leader écologique
Michael Walsh and Eliza Walsh

Il semble que toutes les entreprises parlent de leurs efforts écologiques. L'informatique peut jouer un rôle clé : en créant une excellente opportunité d'initier un changement et devenir un leader d'opinion dans votre entreprise et secteur. Mais par où commencer ? Voici 10 façons de devenir un leader efficace en matière d'environnement et de développement durable.
Familiarisez-vous avec les problèmes
La première étape consiste à développer une expertise étendue et approfondie dans les domaines du développement durable et de l'informatique écologique. En tant que professionnel de l'informatique, vous devriez commencer par bien comprendre comment réduire l'impact écologique de l'informatique, notamment la gestion de l'alimentation, la consolidation matérielle et le traitement écologique des déchets.
En tant que leader écologique, vous devez également envisager de quelles façons les logiciels et le matériel peuvent aider à réduire l'impact des opérations au-delà du service informatique. Peut-être travaillez-vous en étroite collaboration avec des directeurs RH, des avocats et des responsables commerciaux pour définir des stratégies s'attaquant à l'impact écologique global de l'entreprise (qui peuvent aller des stratégies de voyages d'affaires aux règlements concernant les émissions de Co2).
Des individus à l'intérieur et à l'extérieur de votre entreprise s'attendront à ce que vous ayez une expertise technique dans les domaines de l'environnement, de l'entreprise et des secteurs dans lesquels votre entreprise opère. Vous devrez donc évaluer votre compréhension du développement durable et de l'informatique viable de même que les besoins uniques de votre entreprise à court et long termes.
Si vous êtes nouveau dans l'entreprise ou que vous occupez un nouveau poste, vous ferez probablement l'objet de pressions (réelles ou perçues) pour agir rapidement. C'est surtout le cas dans les entreprises qui n'ont pas encore vraiment fait leurs preuves dans le domaine de l'écologie (et souhaitent maintenant le faire).
Vous devez résister à la tentation d'avancer trop rapidement. Ceci peut vous coûter votre crédibilité et celle de l'entreprise. Concentrez-vous à court terme sur des problèmes urgents et remettez la communication d'initiatives stratégiques jusqu'à ce que vous soyez prêt ou jusqu'à ce que votre période d'échauffement soit terminée.

Évaluez votre entreprise de façon objective
L'étape suivante consiste à évaluer de manière critique le développement durable de votre entreprise ou de votre secteur. Pour ce faire, vous devrez engager des intervenants clés et d'autres personnes d'influence à l'intérieur et à l'extérieur de l'entreprise.
Vous devrez développer un réseau de contacts internes et externes : des gens qui peuvent vous permettre de définir l'écosystème des intervenants. Ils peuvent vous aider à comprendre la position de l'entreprise en ce qui concerne le développement durable.
En fonction de vos responsabilités, vous devrez peut-être rechercher la position de votre entreprise en ce qui concerne la conformité (actuelle et future) aux règlements, normes et lois écologiques. Vous devrez peut-être mesurer la position de votre entreprise sur le plan de vos attentes en matière de concurrence et d'analyse. Vous devriez également comprendre comment les clients, partenaires, organisations gouvernementales et défenseurs de clients influents perçoivent votre entreprise et ses efforts écologiques. Et vous pourriez avoir besoin de déterminer les contraintes technologiques, financières et écologiques actuelles et futures en ce qui concerne votre initiative.
En fonction de la taille et du budget de votre entreprise, il faudra peut-être envisager d'autres recherches. Les études internes, les groupes de discussion et recherches de tiers peuvent fournir des points de vue constructifs. Ils peuvent vous aider à mieux comprendre la satisfaction des employés en ce qui concerne les actions écologiques passées de l'entreprise, où se place votre entreprise par rapport à la concurrence et où il existe des opportunités de marché latentes. Cependant, la plus grande valeur potentielle ici est la possibilité pour les recherches de tiers de valider ou réfuter les opinions de vos intervenants clés.

Fixez-vous un objectif et un délai pour y parvenir
À présent, vous pouvez commencer à comprendre où votre entreprise doit se placer, à la fois à court terme et à long terme. Pour démarrer, vous pouvez vous fixer des délais d'un an et de cinq ans, respectivement, avant de commencer à ajuster ces délais en fonction de vos besoins spécifiques. Il faut surtout retenir que l'environnement n'est absolument pas un problème à court terme et ceux qui se placent uniquement à court terme rendent un très mauvais service à leur entreprise, leurs actionnaires, leurs partenaires et leurs clients.
Pour déterminer où votre entreprise doit se positionner à la fois d'ici un an et d'ici cinq ans, vous devez déterminer le paysage commercial actuel et futur auquel vous faites face. Ceci inclut la culture de l'entreprise, les objectifs commerciaux à court et long termes, les contraintes budgétaires actuelles et futures, les projets d'expansion géographique et les modifications de l'environnement légal et réglementaire de votre secteur.
Ainsi, un centre de données fournit un contexte sur le conflit opposant prise de décisions tactiques et positionnement stratégique. Auparavant, l'espace était le souci majeur pour la conception de centres de données. Cependant, au cours des dernières années, l'alimentation a remplacé progressivement l'espace comme facteur limitant la croissance et est devenu un coût opérationnel en augmentation. Les opérateurs de centres de données, se rendant compte des implications à long terme de l'importance croissante du pouvoir, ont pris des mesures pour atténuer les inefficacités d'énergie, en introduisant par exemple des changements radicaux dans la gestion des centres de données qui contredisaient le facteur décisionnel basé sur l'espace. Dans certains cas, les investissements faits pour atténuer les coûts d'alimentation entraînaient des frais à court terme considérables par rapport à la gestion du paradigme existant. Cependant, avec la hausse significative des prix de l'énergie, les opérateurs de centres de données qui ont modifié de manière proactive la gestion des centres de données il y a quelques années sont maintenant considérés comme des visionnaires et leurs entreprises ont plus que compensé les investissements initiaux.

Développez une vision et une stratégie
Il vous faut maintenant développer une vision et une stratégie. Évidemment, celles-ci doivent résulter de votre compréhension de la position actuelle et de la position souhaitée de l'entreprise. Lorsque vous définissez la vision et la stratégie, ne les considérez pas comme étant de nature perpétuelle. L'engagement de votre entreprise envers l'environnement sera sans doute durable, mais votre vision et votre stratégie ne le seront probablement pas. Elles feront face à des révisions majeures dues à des variables internes et externes, telles que des exigences réglementaires changeantes, des modifications de la perception des clients et une évolution des besoins de l'entreprise. Avec l'essor des initiatives écologiques d'entreprises, il est important d'aligner la vision informatique et la stratégie sur une plus grande vision et stratégie d'entreprise.
Lorsque vous définissez la vision, vous définissez la direction que doit prendre votre entreprise. Vous devez choisir vos mots soigneusement pour qu'ils soient intentionnels, concis et cohérents, sans être exhaustifs. La vision n'a pas pour but de couvrir tout ce que fera votre entreprise en matière d'environnement. Elle doit couvrir uniquement les problèmes qui doivent être mentionnés pour orienter correctement vos employés et partenaires. Une déclaration de mission (ou déclaration de vision) est souvent utilisée pour communiquer une vision. Il est essentiel que vous commenciez à communiquer votre vision durant les six premiers mois.
En définissant la stratégie, vous ne définissez pas simplement la direction, mais vous établissez également les objectifs de l'entreprise tout en indiquant les investissements qui seront faits pour atteindre ces objectifs. Il existe des modèles qui peuvent vous aider à formuler un plan stratégique. Deux des meilleurs modèles pour les problèmes de développement durable sont les modèles SWOT (Strengths, Weaknesses, Opportunities, Threats - Forces, Faiblesses, Opportunités et Menaces) et PESTLE (Politique, Economique, Social, Technologique, Légal et Ecologique). Vous pouvez ensuite définir la stratégie dans un document, tel qu'un plan stratégique.
Notez que les responsables qui sollicitent largement des commentaires sur leur vision et leur stratégie auprès d'opposants et de partisans avant la publication d'une déclaration ont plus de chances de réussir. C'est surtout vrai pour ceux qui répondent aux commentaires des opposants dans leur plan final.

Promotion des impératifs de l'entreprise
La promotion ne doit pas attendre que votre vision et votre stratégie soient publiées. Elle doit commencer le jour où vous prenez votre poste. Après la publication de votre vision et de votre stratégie, cependant, vous devrez occuper un rôle plus public, à la fois en interne et à l'extérieur. Au début, vous, ou un représentant, devrez communiquer votre vision aux groupes influents, tels que les employés, les analystes, les médias, les partenaires, les clients et les défenseurs de clients. Vous devrez les inspirer et les motiver pour qu'ils croient en votre vision et votre stratégie et les persuader que votre stratégie est dans le meilleur intérêt de votre entreprise et des publics visés.
Vous devrez déplacer votre attention sur les éléments individuels de la stratégie à un moment donné. Tout au long du processus, vous devez également tenir ces publics visés informés, en leur signalant des jalons significatifs preuves du succès, en communiquant des modifications de la stratégie et en parlant franchement des défis auxquels votre entreprise ou votre secteur dans son ensemble fait face.
Attendez-vous à ce que chaque public présente des intérêts et besoins différents. Bien que vous deviez vous adresser aux besoins et intérêts spécifiques de chaque public, votre vision et votre stratégie sous-jacentes doivent rester cohérentes. Ceci vous aidera à rallier plus efficacement les divers publics ciblés à votre cause.
Résistez à l'envie de communiquer des « besoins d'entreprise » contradictoires pour apaiser des publics différents. Les responsables qui agissent de cette manière n'obtiendront aucune crédibilité sur ces problèmes. Ceci peut restreindre votre efficacité dans l'introduction de changements. Au pire, ceci peut compromettre la crédibilité de toute l'entreprise. La figure 1 montre sept façons de faire passer votre message de manière efficace.
Figure 1 Sept façons de faire passer votre message
Figure 1 Sept façons de faire passer votre message (Cliquez sur l'image pour l'agrandir)

Gestion de votre message
Lorsque vous promouvez votre vision et votre stratégie, considérez le professionnalisme et l'intégrité de vos messages internes et externes. L'environnement et le développement durable sont autant liés à la responsabilité sociale de l'entreprise qu'au développement de produits, aux services, à la vente et à la commercialisation. Même si votre entreprise vous a attribué la direction écologique fonctionnellement, sans vous donner une responsabilité directe des efforts de citoyenneté en matière de développement durable, vous devez agir en supposant que vous serez soumis aux mêmes normes qu'un responsable de citoyenneté.
Ne sous-estimez pas la passion de votre public externe pour les problèmes écologiques et sa connaissance des pratiques écologiques de l'entreprise. Plus important encore, vous ne devez pas sous-estimer sa capacité à détruire votre communication si elle manque d'intégrité ou si elle promet trop ou trop peu. Autrement, votre entreprise risque d'être taxée d'hypocrite.
Par conséquent, il vous faut une stratégie de communications qui incorpore un processus de révision incluant des experts internes qui peuvent vous fournir des commentaires avant que vous ne preniez une position publique. Votre stratégie de communications doit encadrer les éléments clés de votre message, sous la forme, par exemple, d'une feuille d'information écologique d'entreprise, d'un cadre de messages, d'une liste de porte-parole approuvés et de points de conversation. La stratégie de communication, qui est la clé d'une structure et d'une cohérence claires, doit être complétée peu après le développement de votre vision et de votre stratégie. Il est avantageux de placer des responsabilités personnelles sur les principaux propriétaires des messages.

Gestion facilité par des mesures
Il est important que vous gériez les responsabilités qui rentrent dans le cadre de votre vision et de votre stratégie. Qu'il s'agisse d'opérations, de développement de produits ou des ventes et de la commercialisation, vous devez définir les facteurs qui ont un impact sur votre capacité à atteindre vos objectifs. Ces facteurs doivent être organisés dans une liste concise et mis en correspondance avec le plan stratégique global. Vous devrez ensuite utiliser ces facteurs comme base qualitative et/ou quantitative et établir des mesures de suivi qui permettent une analyse future. Ces mesures doivent être gérées activement.
Les responsabilités pour l'établissement de rapports sur ces mesures de suivi doivent être définies clairement et vous devriez organiser des réunions régulières incluant tous les intervenants clés. Les intervenants peuvent ensuite discuter de l'impact des mesures de suivi sur la santé du plan stratégique, ce qui est rendu possible par la mise en correspondance des mesures avec les facteurs et ensuite des facteurs avec les éléments individuels du plan stratégique.
Malheureusement, de nombreux responsables écologiques s'apercevront que leur entreprise n'est pas préparée pour prendre en charge de telles mesures de suivi avec les outils de mesure. Mais ces outils sont nécessaires pour fournir les données qualitatives et quantitatives dont vous avez besoin pour analyser et produire des rapports sur les efforts écologiques. Par conséquent, vous devez développer des outils de mesure spécialisés, que ce soit par une modification des processus de l'entreprise, par le déploiement d'une technologie de collaboration et de mesure ou par le développement d'outils internes personnalisés.
Sans le soutien de la direction en ce qui concerne les investissements de l'entreprise dans ces outils de mesure, vous ferez probablement face à des décisions coûts-avantages sérieuses pour savoir s'il faut que les bons outils de mesure aient la priorité sur le recrutement de personnel supplémentaire.

Analyse et rapport sur l'impact écologique
Le rassemblement des données quantitatives et qualitatives permet une analyse approfondie. Cette analyse est essentielle pour les organisateurs qui souhaitent comprendre le succès de leurs initiatives et l'impact de leurs actions sur la société ou son secteur.
Le paysage réglementaire, normalisateur, légal et de rapports en matière d'environnement est en constante mutation et place de plus en plus de pression sur les entreprises pour qu'elles publient des informations détaillées sur leurs problèmes écologiques. En ayant les outils et processus nécessaires en place pour prendre en charge la gestion, la mesure et l'analyse, vous facilitez le rassemblement des informations exigées pour les rapports annuels, les classifications requises et les rapports volontaires de l'entreprise sur le développement durable. Il est donc important que vous compreniez quelles sont vos exigences de rapports et ce qu'elle seront à l'avenir, pour que vous puissiez investir dans une infrastructure de gestion, mesure, analyse et rapports intégrée qui évoluera en même temps que les besoins de votre entreprise.
La technologie pour l'analyse et la création de rapports est très importante pour les entreprises cherchant à s'imposer en tant que leaders d'opinion. Les logiciels jouent un rôle essentiel dans ce domaine, en particulier les logiciels utilisés pour la gestion écologique, la conception de processus, la collecte de données, la manipulation de données, la détection à distance, la collaboration, la visualisation et la présentation.
Les logiciels disponibles dans le commerce doivent parfois être personnalisés pour des applications spécifiques dans l'espace écologique. Ainsi, des investissements significatifs dans le domaine de la technologie peuvent être nécessaires pour permettre une infrastructure de gestion, mesure, analyse et rapports intégrée.

Soyez un leader d'opinion
Le leadership d'opinion est une chose que chaque responsable écologique doit aspirer à atteindre. Il existe plusieurs types de leaders d'opinion (voir exemples à la figure 2), mais ils ont tous un point commun : leur expertise ne découle pas d'un titre mais plutôt de leur expérience dans la prise de mesures et l'introduction de changements avec intégrité et franchise.
Figure 2 Types de leaders d'opinion
Figure 2 Types de leaders d'opinion (Cliquez sur l'image pour l'agrandir)
L'écosystème de développement durable global compte sur des leaders d'opinion pour initier des changements. Avec un vaste réseau de contacts dans des organisations gouvernementales, non gouvernementales, industrielles et de défense des consommateurs, un leader d'opinion peut connecter des parties influentes pour résoudre des problèmes nécessitant une collaboration étroite. Un leader d'opinion connaît bien un grand nombre de problèmes écologiques émergents qui inquiètent la communauté mondiale et est capable de présenter ces problèmes à un public mondial.
Pour finir, un leader d'opinion prévoit des solutions à des problèmes importants qui doivent attirer l'attention de l'ensemble du secteur. Le développement de ces solutions peut nécessiter l'influence et la collaboration avec d'autres, y compris des concurrents, et peut pousser votre propre entreprise sur de nouveaux marchés, mais le résultat est que les leaders d'opinion peuvent initier des changements d'ordre global.

Restez à l'écoute de l'actualité
Il s'agit d'une discipline émergente et les connaissances changent régulièrement. Une crédibilité continue nécessitera une compréhension érudite des diverses perspectives scientifiques, stratégiques, légales, économiques, technologiques et commerciales promues par d'autres leaders écologiques. Elle ne requerra pas nécessairement une conformité aux opinions prédominantes du jour, mais plutôt la promotion de perspectives uniques basées sur une compréhension experte du développement durable et de l'informatique écologique. Cette intégrité fera la différence étant donné le nombre croissant de leaders écologiques (ou personnes prétendant être des leaders d'opinion) du secteur.
Un responsable confirmé doit également pouvoir confier des responsabilités à des subordonnés possédant les connaissances spécifiques sur un sujet particulier et référer les politiques de l'environnement à des représentants supérieurs lorsque cela est nécessaire. Si les réunions régulières avec vos supérieurs et les rapports garantiront que vous maintenez une connaissance complète des efforts de votre entreprise en matière de développement durable, il est essentiel que vous sachiez quand parler au nom de l'entreprise. Ceci nécessite une bonne compréhension de vos engagements fondamentaux et est une caractéristique reflétant la responsabilité sincère que vous avez de soutenir les convictions concernant l'environnement auxquelles s'attend votre public.

Michael Walsh est responsable de produit environnemental senior chez Microsoft.
Eliza Walsh est consultante en stratégies de communications et a auparavant occupé un poste de spécialiste en communications pour Microsoft en Chine.


Sur le terrain Split Screen
Kentaro Toyama

Étendre l'accès à un PC à autant de personnes que possible, c'est l'objectif louable de Microsoft Research Inde, qui a connu le succès avec MultiPoint (traité dans le numéro de TechNet Magazine du mois de mai 2008), un programme qui permet à de nombreux utilisateurs d'interagir avec un PC utilisant plusieurs souris.
Split Screen est une autre forme d'environnement d'accès partagé simultané conçue par Microsoft Research Inde. Le programme configure un seul PC avec deux claviers et deux souris, puis adapte les services Terminal Server pour partager le moniteur. Deux personnes peuvent alors partager le moniteur, exécutant des instances séparées du système d'exploitation et leur choix de logiciel de manière indépendante de chaque côté (research.microsoft.com/users/udaip/splitscreen.htm). Par exemple, une personne pourrait faire du traitement de texte pendant que l'autre travaille sur un tableur.
Pour activer Split Screen, nous utilisons trois instances séparées de Terminal Server s'exécutant sur Windows Server® 2003 (nous effectuons actuellement une mise à niveau vers Windows Server 2008). La première est un conteneur qui capture et redistribue tous les événements de souris et de clavier. Cette couche utilise la même astuce que nous avons utilisée pour MultiPoint, où tous les événements de souris et de clavier sont capturés, avec leurs numéros d'identification de périphériques (Windows® attribue automatiquement des numéros d'identification uniques aux périphériques USB lorsqu'ils sont branchés. Ceux-ci ne sont pas uniques pour le périphérique matériel, mais ils sont uniques dans l'instance actuelle de fonctionnement, juste ce qui est nécessaire pour savoir si deux clics de souris proviennent de la même souris ou de souris différentes. Le conteneur crée également les curseurs de souris.
Dans celui-ci, nous ouvrons deux instances supplémentaires de Terminal Server qui reçoivent chacun uniquement les événements pertinents pour un écran. Dans le mode par défaut, tous les événements de souris à partir de la souris portant la référence x, par exemple, finiront sur l'écran partagé de gauche alors que ceux de la référence y finiront sur l'écran partagé de droite.
Split Screen utilise les services Terminal Server pour partager le moniteur.
Split Screen utilise les services Terminal Server pour partager le moniteur. (Cliquez sur l'image pour l'agrandir)
Il est important d'avoir l'instance de conteneur de Terminal Server pour disposer du contrôle total des événements et de l'emplacement où ils ont lieu et activer des fonctionnalités plus avancées. Par exemple, nous pouvons autoriser le curseur de droite à passer sur l'écran de gauche et à pointer simplement (peut-être pour une utilisation de didacticiel), ou même à interagir avec l'autre fenêtre.
Dans ce cas, une partie des événements de souris de droite alimenterait également l'écran de gauche. Nous avions également envisagé d'utiliser la technologie de virtualisation dans Windows pour exécuter des fonctions similaires. C'est possible, mais nous avons découvert que cela utilisait plus de ressources.
Les chercheurs étaient préoccupés par le fait que les gens pourraient être frustrés de disposer seulement de la moitié d'un écran. Nous avons réalisé des études à Bangalore, Inde, avec la Fondation Hope qui enseigne à la jeunesse urbaine à faible revenu les principes fondamentaux des ordinateurs. Les étudiants semblaient apprendre tout autant avec Split Screen que lorsqu'ils disposaient d'un seul PC pour eux-mêmes, au moins pour le groupe limité de tâches de formation informatique. Nous avons également recherché des problèmes ergonomiques, mais il n'y en avait pas, même sur les écrans 14". Le plus important, c'est que le centre de formation informatique était heureux de pouvoir accueillir deux fois plus d'étudiants avec le même nombre de PC.
Microsoft Research Inde est en discussion avec les services Terminal Server et les autres groupes Microsoft pour déterminer si Split Screen est une technologie à lancer sur le marché. Si vous êtes intéressé par Split Screen, merci de nous indiquer dans quels scénarios vous aimeriez l'utiliser. Adressez-nous un courrier électronique à splitscr@microsoft.com.

Kentaro Toyama est Directeur général adjoint de Microsoft Research Inde (research.microsoft.com/india) et chef de recherche du groupe Technology for Emerging Markets (research.microsoft.com/research/tem), qui développe des technologies pour les communautés économiquement pauvres du monde entier.


La vie secrète de Windows Les deux pires PC jamais conçus
Raymond Chen

En mars 2007, lorsque PC World a publié sa liste des 10 pires PC de tous les temps, les deux premiers de la liste ont attiré mon attention parce que nous les utilisions au travail. Enfin, « utiliser » est un bien grand mot. Peut-être devrais-je dire que j'observais ces machines, car elles passaient la plupart de leur temps productif dans le bureau d'un employé de Microsoft.
Le PC Mattel Barbie classé comme deuxième pire dans la liste de PC World. Cet ordinateur constituait une grande amélioration par rapport aux ordinateurs bon marché d'une couleur ennuyeuse. C'était un ordinateur bon marché d'une couleur ennuyeuse que vous pouviez décorer avec des autocollants roses appliqués sur le boîtier, le moniteur, les haut-parleurs, vous voyez ce que je veux dire. Le logiciel Barbie était préinstallé sur celui-ci.
Nous en avons acheté un comme ordinateur de test et le pauvre testeur qui était collé à cet ordinateur avait au moins le sens de l'humour car il s'investissait avec un enthousiasme simulé, appliquant tous les autocollants et décorations fournis pour s'assurer que l'ordinateur était installé « comme prévu ». Celui-ci était installé sur une table bien visible du couloir et toute personne qui passait et voyait ce désastre de l'informatique rose brillant était bienvenu pour entrer et s'amuser avec.
Le Barbie PC était une source continue de divertissement. Quand la machine rencontrait des problèmes et que les développeurs devaient venir au bureau pour y effectuer un débogage, ils n'en croyaient pas leurs yeux et vous pouviez vous attendre à ce qu'ils crient « Super » ! dès qu'ils comprenaient sur quel type d'ordinateur ils devraient travailler. On m'a dit qu'un été les stagiaires d'une université ont installé une copie de Datacenter Edition de Windows Server® sur le PC Barbie, juste pour s'amuser.
En haut du classement, ou peut-être plus précisément en bas de cette liste, on trouve Packard Bell PC. Ah, souvenirs, souvenirs. Juste un exemple de la façon dont cet ordinateur est conçu : avec la configuration prête à l'emploi, tous les connecteurs d'extension étaient occupés. Peut-être ont-ils pensé, « Notre ordinateur est si parfait que vous n'aurez jamais besoin de le mettre à niveau » !
À l'époque du projet Windows® 95, un cadre supérieur en achetait un comme ordinateur personnel et y installait régulièrement la dernière version de Windows 95 dans le cadre de tests. Comme on pouvait s'y attendre, cet ordinateur rencontrait toutes sortes de problèmes et nécessitait des interventions fréquentes pour effectuer son débogage.
Le gestionnaire de développement du projet Windows 95 était un homme astucieux qui a adopté une approche résolument directe pour résoudre les problèmes. Par exemple, pour s'assurer que Windows 95 était livré avec une large couverture de compatibilité des applications, il conduisait sa camionnette au magasin informatique local et achetait une copie de tous les programmes de PC. Il déchargeait ensuite le logiciel sur les tables de la cafétéria et invitait l'équipe produit de Windows 95 à entrer et à prendre à deux logiciels, à la condition qu'ils installent et exécutent tous les logiciels qu'ils prenaient, ainsi que les listes de bogues sur toutes les machines qui ne fonctionnaient pas bien, même si c'était un problème mineur. En échange, ils pouvaient garder le logiciel. La scène dans la cafétéria était comme un marché aux puces, le personnel parcourant les tables pour trouver une bonne affaire et demandant avec enthousiasme à leurs collègues, « Qu'avez-vous trouvé » ?
Gêné par le nombre de fois que le cadre supérieur a dû apporter son ordinateur personnel pour un débogage, le gestionnaire de développement du projet Windows 95 a de nouveau adopté une approche directe. Il est allé au magasin informatique local et a acheté un PC Packard Bell identique à celui du cadre supérieur.
Le fait que deux de ces ordinateurs existaient n'était pas bon signe. Le pire c'est que le deuxième ordinateur m'a été donné avec la tâche d'y installer toutes les nouvelles versions de Windows 95 et de résoudre tous les problèmes qui se présentaient. Ainsi, la dernière version que le cadre supérieur installait sur son ordinateur personnel n'entraînerait aucun problème.
Si vous avez tout suivi et connecté les points, vous avez pu remarquer un obstacle à cette planification. Puisqu'il n'y avait pas de connecteurs d'extension ouverts sur le PC Packard Bell, il n'y avait aucun emplacement pour installer une carte réseau. J'ai dû avoir recours à d'autres moyens détournés pour obtenir une connectivité réseau. Je détestais vraiment cet ordinateur.

Raymond Chen, The Old New Thing, et son livre du même titre traitent de l’historique de Windows et de la programmation Win32.