Suggérer une traduction
Suggestions d'autres utilisateurs :

progress indicator
Aucune autre suggestion.
TechNet Magazine > Accueil > Tous les numéros > 2009 > TechNet Magazine Mai 2009 >  Introduction à la sécurité dans Windows 7
Affichage du contenu :  côte à côteAffichage du contenu : côte à côte
Ce contenu traduit automatiquement peut être modifié par les membres de la communauté. Nous vous invitons à améliorer la traduction en cliquant sur le lien « Modifier » associé aux phrases ci-dessous.
An Introduction to Security in Windows 7
Chris Corio
Parts of this article are based on prerelease code. All information herein is subject to change.
At a Glance:
  • Windows Biometric Framework
  • Extending Authentication Profiles
  • Bitlocker To Go
  • UAC Improvements
Windows Vista introduced a variety of new security technologies that had a significant impact on the Windows ecosystem. User Account Control made it clear that Microsoft wanted to make easy for users to run Windows without being in the Administrators group. BitLocker introduced full volume encryption for the Windows client. Protected Mode Internet Explorer helped to make browsing the Internet a safer experience.
In Windows 7, Microsoft has continued its investment in security by adding new technologies as well as enhancing many of the technologies introduced in Windows Vista. In this article, I will provide an overview of the new security features and enhancements you'll find in Windows 7.

Windows Biometric Framework
Windows Vista included a redesign of the Winlogon experience. This experience removed the GINA (Graphical Identification and Authentication) infrastructure and added the Credential Provider extension model. The Credential Provider infrastructure was a set of interfaces that allowed consistency when third parties extended the user experience around users entering credentials, and it integrates into the common Windows credential dialog.
For Windows 7, Microsoft has added the new Windows Biometric Framework (WBF). With fingerprint readers becoming far more common, it became clear that defining a common framework for exposing, managing, and using these technologies was necessary to drive development and reliability. The WBF is intended to make it easier to support biometric authentication devices. In Windows 7, WBF supports only fingerprint readers, but it can be expanded in the future.
The WBF core platform consists of these main components:
  • Windows Biometric Driver Interface (WBDI)
  • Windows Biometric Service (WBS)
  • WBF User Experience and Integration Points
  • WBF Management
The Windows Biometric Driver Interface (WBDI) is meant to provide a common driver interface for biometric devices. It consists of a variety of interfaces that expose the appropriate data structures and IOCTLs (Input/output controls) for biometric devices to integrate into the biometric framework. Drivers can be implemented in any of the common driver frameworks, including Windows Driver Model, Kernel Mode Driver Framework, and User-Mode Driver Framework (UMDF). UMDF, however, is the recommended driver framework for biometric devices because it provides the additional benefit of greater reliability for Windows in case a crash occurs in the biometric device driver.
The Windows Biometric Service (WBS) is the key component that ties together WBF. WBS interfaces with the biometric device drivers and also exposes the Windows Biometric Framework APIs, allowing applications to interact with these devices.
An important feature of WBS is that it never reveals a user's actual biometric data to unprivileged applications. This is important because, unlike a password, it's very difficult for someone to change their biometric signature once it's been compromised. Instead, the WBS exposes a handle (typically a GUID or a SID) that allows applications to work with the biometric data indirectly.
WBS also manages pools of biometric authentication devices. This enables you to control how biometric devices are used. Certain devices can be used with any Credential Dialog, such as the logon prompt or a UAC prompt. For example, you can set up Parental Controls on your home system, and when elevation is required on the system, you can simply swipe your finger to provide elevation. This pool of biometric devices is referred to as the System pool. There are two other pools of devices. There is the Private pool, which allows applications to offer authentication that is not integrated with the Windows authentication infrastructure. And there is the Unassigned pool, which is for devices that, as you might have guessed, fit neither of the previous two pools.
Each device that is part of a device pool is actually abstracted away by the WBS using a data class called a Biometric Unit. The Biometric Unit plugs into the WBS's Biometric Service Provider (BSP), which implements policies and behaviors specific to a set of biometric devices. The Biometric Unit allows the BSP to provide any facilities that a particular device might not support, such as storing fingerprint data or processing fingerprint data after it's been acquired by a device.
The third major component of the WBF is the set of APIs, also known as the WinBio* APIs, that can be used by applications and user mode components to directly interact with the devices. This includes interacting with a device during the original enrollment process for obtaining a user's fingerprint and correlating it with a particular user account, as well as the task of verifying a user for logon or UAC. These APIs also expose data about the specific biometric device and its characteristics. In addition, the WBF APIs can be extended to allow an application to interact with proprietary aspects of a particular device.
The WBF exposes two main ways to configure the use of biometric devices. For end users, there is a Control Panel applet, which is exposed in a few locations. You can find the Biometric Devices Control Panel under Hardware and Sound. From this location, the user can launch a third party fingerprint management application. Windows 7 does not provide a built-in fingerprint management application, so any third party vendor or OEM will have to write its own. (Note that the Windows Biometric Framework supports local and domain logon, as well as fingerprint-based UAC through the built-in Biometrics Credential Provider.)
The Windows Biometric Framework can also be managed through Group Policy. An administrator can enable or disable the entire framework, as well as manage what types of logons can use biometrics (for example, local and domain logons can be configured differently).

Extending Authentication Protocols
Windows 7 enhances the home and small network experience with a feature called Homegroup. Users can share data, such as media files, between computers in a home and use an online ID to authenticate between these computers. Users must explicitly link their Windows user account to an online ID in order for this functionality to work. Authentication is enabled by a new protocol called Public Key-based User to User or PKU2U.
Windows 7 also introduces an extension to the Negotiate authentication package, Spnego.dll. SpNego is the feature that decides which authentication protocol should be used when authenticating. Before Windows 7, it was typically a choice between Kerberos and NTLM (Windows Challenge/Response). The NegoEx extension is treated as an authentication protocol by Windows and it supports two Microsoft security support providers: PKU2U and Live. It's also extensible to allow for development of other security support providers.
Both of these features work when connecting to another computer in the Homegroup using an online ID. When one machine connects to another, the negotiate extension calls the PKU2U security support provider on the login computer. The PKU2U security support provider obtains a certificate from the certificate authority policy engine and exchanges the policy (along with other metadata) between the peer computers. When validated on the peer computer, the certificate is sent to the logon peer for validation, the user's certificate is mapped to a security token, and the logon process is completed.

BitLocker Core Enhancements
With Windows Vista, Microsoft introduced BitLocker. This is a full volume encryption solution designed to protect the data on laptops and desktop machines, such as branch office servers, even if the machine is lost or falls into the wrong hands. In Windows 7, many enhancements have been made to the management of BitLocker. These include consistent enforcement through all interfaces (the UI, the manage-bde command line tool, and the WMI provider) and separate Group Policy settings for fixed data drives. There are also new Group Policy settings that allow you to update your passwords and integrate with Smart Cards on non-OS drives, and you can also change the behavior related to automatic unlocking.
In Windows Vista, there have been complaints about it being difficult to partition the OS drive to prepare for a BitLocker installation—especially when the operating system is already installed. This problem has been addressed with two enhancements found in Windows 7. First, by default during Windows 7 setup, users will get a separate active system partition, which is required for BitLocker to work on OS drives. This eliminates a second step that was required in many environments. In addition, you can partition a drive for BitLocker as part of BitLocker setup if you do not already have a separate system partition.(see Figure 1).
Figure 1 Preparing a Drive for BitLocker

BitLocker To Go
One of the most visible and most important additions is BitLocker To Go, which is designed to protect data on removable data drives. It allows you to configure BitLocker Drive Encryption on USB flash drives and external hard drives. Design goals for BitLocker To Go called for the feature to be easy to use, for it to work on existing drives, to allow for the recovery of data if necessary, and to enable the data to be usable on Windows Vista and Windows XP systems.
There are many management enhancements for IT managers to take advantage of with this feature. The most notable is a new Group Policy setting that lets you configure removable drives as Read Only unless they are encrypted with BitLocker To Go. This is an excellent step forward in ensuring that critical corporate data is protected when a USB flash drive is misplaced by an employee.
Also notable is the ability to recover data from any BitLocker To Go device when the data is inaccessible. This technology, called a Data Recovery Agent, was ported from the Encrypted File System (EFS) feature and allows easy recovery of corporate data on a portable drive using the key created by the enterprise.
Getting BitLocker To Go functionality to work on Windows XP and Windows Vista required some reengineering of the core BitLocker feature. To do this, the team refactored the method by which BitLocker protects FAT volumes. BitLocker behavior was modified to overlay a "discovery volume" onto the physical, original volume and virtualize the blocks overwritten. The discovery volume contains the BitLocker To Go Reader as well as a readme file. This is called a Hybrid BitLocker drive. By default, when a FAT drive is encrypted, a hybrid BitLocker drive is created. The discovery drive is visible only on the Windows XP and Windows Vista operating systems.
The reader will also be available on the Microsoft download center after Windows 7 is released. The application provides read-only access to BitLocker drives that utilize the password key protector. Note that smart card authentication is not available when using the BitLocker To Go Reader.

UAC Improvements
User Account Control (UAC) is an often misunderstood technology. First off, it's actually a collection of features rather than just a prompt. These features include File and Registry Redirection, Installer Detection, the UAC prompt, the ActiveX Installer Service, and more. These features are all designed to allow Windows users to run with user accounts that are not members of the Administrators group. These accounts are generally referred to as Standard Users and are broadly described as running with least privilege. The key is that when users run with Standard User accounts, the experience is typically much more secure and reliable.
Many developers have started to target their applications to work well for Standard Users. Businesses now have a clearer path toward deploying Standard User accounts, allowing these businesses to reduce support costs and the overall TCO (total cost of ownership) of its computers. In the home, families can use Standard User accounts for children along with Parental Controls to create a safer environment.
Windows 7 includes numerous enhancements to improve the Standard User experience, and new configuration settings provide more control over the User Account Control prompt when run in Administrator Approval Mode. The goal is to improve usability while continuing to make it clear to independent software vendors that the default security context they should be targeting is that of a Standard User. In practice, these changes mean that users are not prompted for common administrative tasks in Windows 7. This is the setting that says "Notify me only when programs try to make changes to my computer."
The way this works is fairly straightforward. During process creation, the policy is checked to see if this setting is enabled. If the process being created is part of Windows, which is verified by checking the Windows catalog files for its signature, the process is created without a prompt. This setting does not prompt when you change Windows settings but instead enables you to focus on administrative changes being requested by non-Windows applications (such as installing new software). For people who want greater control changing Windows settings frequently, without the additional notifications, this setting results in fewer overall prompts and enables users to zero in on the key remaining notifications that they do see.
The other significant change is that several components no longer require Administrator privileges. For example, users can configure whether their desktops should be displayed in High DPI mode, a commonly used feature as computer screens get larger and pixel sizes get smaller. Another example is that Standard Users can now reset their network connection when physically logged into the computer, a common request Microsoft has heard from both home users and enterprises.
Figure 2 User Account Control When Installing an ActiveX Control
Reducing prompts also means streamlining areas where multiple prompts were encountered for a single user action. On Windows 7, for instance, installing ActiveX controls in Internet Explorer is much smoother. On Windows Vista, Internet Explorer 7 would create the IEInstal.exe process to perform the installation of an ActiveX control. This resulted in a UAC prompt that asked if you wanted "Install an IE Add On" to run with Administrator privileges. This prompt didn't provide much context about exactly what was being installed and Internet Explorer would immediately prompt you to approve a particular control. On Windows 7 with Internet Explorer 8, the install process has been modified to use the ActiveX Installer Service, which will extract the ActiveX control's publisher information and display it during the installation experience (see Figure 2). The new approach also removes the second prompt during the installation of an ActiveX control.

The ability to control which applications a user, or set of users, can run offers significant increases in the reliability and security of enterprise desktops. Overall, an application lockdown policy can lower the TCO of computers in an enterprise. Windows 7 adds AppLocker, a new feature that controls application execution and makes it even easier to author an enterprise application lockdown policy.
Durga Prasad Sayana and I discussed application lockdown policies in last year's security issue in an article titled " Application Lockdown with Software Restriction Policies ." In the article, we detailed a number of challenges that an enterprise must overcome when creating such a policy. Some of these challenges include the following:
  • Understanding what software is used in your environment
  • Knowing which applications various users should be allowed to run
  • Knowing how to author the necessary policy
  • Determining whether a policy will work correctly when deployed
To address these hurdles, AppLocker offers a new approach that can audit how an application lockdown policy will work. It provides the ability to control how users run all types of applications—executables, scripts, Windows Installer files, and DLLs. And it offers new application lockdown policy primitives that are more specific and are not subject to break as easily when an application is updated. Windows 7 also includes support for legacy Software Restriction Policy (SRP) rules, but there is no support for the new AppLocker rules on Windows XP and Windows Vista.
The enforcement modes are all implemented on top of AppLocker's underlying enforcement agent, which is implemented in the appid.sys driver. This driver offers the ability to have kernel mode rule checking for such events as process creation and DLL loading. For applications that implement enforcement in User Mode, the legacy SaferIdentifyLevel API is used to determine whether an application can run. But Safer- IdentifyLevel will now hand the enforcement check over to a service to perform the actual verification of the binary and policy. This is a significant architectural enhancement over the legacy Software Restriction Policies feature.
AppLocker is meant to make it easy for IT pros to author a simple set of rules that express all of the applications that are allowed to run and ensure that the rules are resilient to application updates.
To author AppLocker policy, there is a new AppLocker MMC snap-in UX in the Group Policy Object Editor snap-in UX, which offers an incredible improvement in the process of creating AppLocker rules. There is a wizard that allows you to create a single rule, and another wizard automatically generates rules for you based on your rule preferences and the folder that you select (see Figure 3).
Figure 3 Automatically generate rules for AppLocker policy.
You can review the files analyzed and remove them from the list before rules are created for them. You can even get useful statistics about how often a file has been blocked or test AppLocker policy for a given computer.
In the previous Software Restriction Policies, it was particularly difficult to create policies that were secure but also wouldn't break from software updates. This was due to the lack of granularity of certificate rules and the fragility of hash rules that would break when an application binary was updated. To address this issue, AppLocker lets you author a rule that combines a certificate and a product name, file name, and file version. This makes it easy to specify that anything signed by a particular vendor for a specific product name can run.
AppLocker policies in Windows 7 have other benefits, as well, including separation between different types of execution (namely EXEs, DLLs, and MSI or script hosts). These file types are fit into four buckets called rule collections, and enforcement is configured separately for each. For example, administrators can enable AppLocker checks for executables without enabling checks of script files.
The AppLocker policy is stored under the HKLM\Software\Policies\Microsoft\Windows\SrpV2 key. The policy is stored in an XML format and is translated by the Application Identity (AppID) service. When policy is processed, the appid.sys driver is notified about new policy by the service through the IOCTL_SRP_POLICY and the driver will reload the policy.
The first task when approaching changes to your IT environment is to assess how the environment is currently functioning. Then you can carefully plan and test any changes to ensure they can be implemented smoothly. This is the purpose of the Audit only enforcement mode.
Auditing the enforcement of the App-Locker policy is extremely important. Not only does this let you test a policy before it's enforced, but it also offers you the ability to watch how the policy performs during its lifetime. You'd definitely want to know if a certain set of users needed an application to work at some point. This can be determined by connecting to a system and reviewing the AppLocker audit information to see whether an application lockdown policy was preventing a particular app from running.
The primary channel for AppLocker events is in the Applications and Service Logs that can be viewed in the Event Viewer (eventvwr.msc) application. In order to view these log entries, look for the EXE and DLL and the MSI and Script logs under the Microsoft\Windows\AppLocker\ event channel. Many different events can be generated, including whether an application was allowed or blocked and whether a policy was applied to a system.

DNSSec Validation
Over the past couple years, DNS-related exploits have become a more common problem on the Internet. There is a better understanding of how to poison DNS servers, and attackers are starting to make use of that information. What this means is that a user can potentially visit a Web site and not be absolutely sure that he isn't visiting a different, malicious Web site.
Windows Server 2008 R2 and Windows 7 introduce support for DNSSEC as per the current standards (RFC 4033, RFC 4034, and RFC 4035). Windows Server 2008 R2 will allow the DNS Server to provide origin authority and data integrity artifacts. Basically, a server will be able to attach digital signatures to DNS data in responses as well as validate data received from other DNS servers.
Windows 7 is the first client operating system to include the necessary pieces to allow the client to verify that it is communicating securely with a DNS server and verify that the server has performed DNSSEC validation on its behalf. This technology is currently being tested to ensure the maximum compatibility with current Internet infrastructure and aims to play a continuing role in securing DNS data in the future.
Global SACLs and Granular Auditing
Windows 7 extends previous auditing mechanisms to offer new features that let you manage auditing for users rather than just objects and to provide more information about AccessCheck failures for file objects. This enables new auditing scenarios and provides a significant paradigm change related to auditing.
In other versions of Windows, determining whether to audit object access was based on whether the security descriptor of an object included an access control entry (ACE) in its SACL specifying that it should be audited. This made it very easy to monitor a certain registry key or file to see what access was occurring on that object. Unfortunately, there was no method to watch what a particular user was accessing. If you wanted this scenario, you'd likely need to turn on auditing for every resource that the user could possibly interact with and thus every access by any user of the resource would end up in the audit log.
Enabling auditing on a wide enough data set to capture what a user could access is an incredibly arduous process. Each resource needs to be updated to include the audit policy within the SACL and any changes to this policy would require each SACL to be updated. To overcome this limitation, Windows 7 introduces Global Object Access Auditing, which is managed by auditpol.exe and is configurable using Group Policy.
The Global Ojbect Access Auditing includes a "Global SACL" that is an SDDL string stored in the registry with other data related to auditing. Two new APIs have been added to manage the Global SACL: AuditSetGlobalSacl and AuditQueryGlobalSacl. Updating the Global SACL requires the SeSecurityPrivilege, which protects the Global SACL from being updated by a user without administrator privileges.
Security auditing in Windows 7 also provides the ability to understand why access to an object failed or succeeded. This is important information if you're debugging an application failure or trying to understand whether your security policy is effective. Both the Global Object Access Auditing functionality and the inclusion of additional access audit data are implemented in a new kernel mode security API, SeAccessCheckEx. The two resource managers to consume this API will be NTFS and the Detailed File Share in Windows 7, and when enabled, the API will put information in the audit log about why an access attempt succeeded or failed. Thus these features apply to the file system and file shares for now and can be expanded to other resources managers in future versions of Windows.

Wrapping Up
Windows 7 enables new scenarios and makes using Windows a more secure experience. Many of these features have a strong focus on the user experience (for home users, business users, and IT professionals) and allow Windows 7 systems to work even better.

Chris Corio was a member of the Windows Security team at Microsoft for more than five years. His primary focus at Microsoft was application security technologies and management technologies for securing Windows. You can reach Chris at .

Introduction à la sécurité dans Windows 7
Chris Corio
Parties de cet article sont basés sur code préliminaire. Toutes les informations dans le présent document sont susceptibles d'être modifiées.
Vue d'ensemble :
  • Windows Framework biométrique
  • Extension de profils d'authentification
  • BitLocker pour atteindre
  • Améliorations de contrôle de compte d'utilisateur
Windows Vista introduit de nouvelles technologies de sécurité qui avait un impact significatif sur l'écosystème Windows divers. Le contrôle de compte d'utilisateur effectuée il désactivez Microsoft souhaitez faciliter aux utilisateurs d'exécuter Windows sans être dans le groupe Administrateurs. BitLocker introduit le chiffrement de volume complet pour le client Windows. Internet Explorer en mode protégé permis pour vous naviguez sur Internet une expérience plus sûre.
Dans Windows 7, Microsoft a continué ses investissements dans la sécurité par Ajout de nouvelles technologies et amélioration de la plupart des technologies introduits dans Windows Vista. Dans cet article, je présentent des nouvelles fonctionnalités de sécurité et améliorations, que vous trouverez dans Windows 7.

Windows Framework biométrique
Windows Vista inclus une nouvelle conception de l'expérience de Winlogon. Cette expérience supprimé de l'infrastructure GINA (Graphical Identification et authentification) et ajouter le modèle d'extension de fournisseur d'informations d'identification. L'infrastructure de fournisseur d'informations d'identification a un ensemble d'interfaces autorisé cohérence lorsque des tiers étendu l'expérience utilisateur autour d'entrer des informations d'identification des utilisateurs et il intègre la courantes boîte de dialogue Informations d'identification Windows.
Pour Windows 7, Microsoft a ajouté le nouveau Windows biométrique Framework (WBF). Avec l'empreinte lecteurs devient beaucoup plus courant, qu'il est devenu désactivez définissant une infrastructure commune pour exposer, gérer et à l'aide de ces technologies était nécessaire de développement de lecteur et la fiabilité. Le WBF est conçu pour faciliter la prend en charge les périphériques une authentification biométrique. Dans Windows 7, WBF prend en charge uniquement les lecteurs empreintes digitales, mais elle peut être développée à l'avenir.
La plate-forme de base WBF comprend ces composants principaux :
  • Windows biométrique interface du pilote (WBDI)
  • Windows service biométrique (WBS, Work Breakdown Structure)
  • Expérience utilisateur WBF et points d'intégration
  • Gestion WBF
L'interface de pilote de biométrique (WBDI) de Windows est conçue pour fournir une interface de pilote courants pour les périphériques biométriques. Il est constitué d'une variété d'interfaces qui exposent les structures de données approprié et les IOCTL (contrôles d'entrée/sortie) pour les périphériques biométriques pour intégrer l'environnement biométrique. Pilotes peuvent être implémentées dans les les environnements pilote courants, notamment Windows Driver Model, cadre pour pilotes en mode noyau et User-Mode Driver Framework (UMDF). UMDF, cependant, est l'infrastructure de pilote recommandé pour les périphériques biométriques, car il offre l'avantage supplémentaire de fiabilité supérieure pour Windows au cas où un incident se produit dans le pilote de périphérique biométrique.
Le Windows biométrique service (WBS, Work Breakdown Structure) est le composant clé qui relie WBF. Codes WBS interagit avec les pilotes de périphérique biométrique et expose également les biométrique Framework API Windows, permettant d'applications d'interagir avec ces périphériques.
Une fonctionnalité importante de code WBS est qu'il révèle jamais des données de biométrique réel d'un utilisateur aux applications sans privilège. Il est important car, contrairement à un mot de passe, il s'agit très difficile pour une personne à modifier leur signature biométrique une fois qu'il est compromis. Au lieu de cela, la structure de répartition du travail expose une poignée (généralement un GUID ou un SID) qui permet aux applications de travailler avec les données biométriques indirectement.
WBS gère également les pools de périphériques une authentification biométrique. Ce permet de vous permet de contrôler périphériques biométriques comment sont utilisées. Certains périphériques utilisable avec toute boîte de dialogue Informations d'identification, telles que l'invite d'ouverture de session ou d'une invite de contrôle de compte d'utilisateur. Par exemple, vous pouvez configurer le contrôle parental sur votre système de base, et lorsque l'élévation est requise sur le système, vous pouvez simplement swipe votre doigt pour fournir une élévation. Ce pool de périphériques biométriques est appelé le pool système. Il existe deux autres pools de périphériques. Il existe la réserve privé, qui permet aux applications de proposer l'authentification qui n'est pas intégrée avec l'infrastructure de l'authentification Windows. Et le pool non attribué, c'est-à-dire pour les périphériques, comme vous l'avez peut-être deviné, ajuster ne les pools deux précédentes.
Chaque périphérique fait partie d'un pool de périphérique est en fait disparaît par la WBS en utilisant une classe de données appelée un point biométrique. L'unité biométrique s'intègre dans la WBS biométrique Service Provider (BSP), qui implémente des stratégies et des comportements spécifiques à un ensemble de périphériques biométriques. L'unité biométrique permet le BSP fournir des fonctionnalités qui prend un périphérique particulier ne peut-être pas en charge, tels que le stockage des données par empreinte digitale ou de traitement des données par empreinte digitale après été acquis par un périphérique.
Le troisième composant principal du WBF est l'ensemble d'API, également connu sous le nom les API de WinBio *, qui peuvent être utilisées par les applications et composants en mode utilisateur pour interagir directement avec les périphériques. Cela inclut l'interaction avec un périphérique pendant le processus d'inscription d'origine permettant d'obtenir empreinte digitale d'un utilisateur et de corrélation avec un compte d'utilisateur spécifique, ainsi que la tâche de vérification d'un utilisateur pour l'ouverture de session ou le contrôle de compte d'utilisateur. Ces API également expose les données sur le périphérique biométrique spécifique et ses caractéristiques. En outre, les API WBF peut être étendus à autoriser une application manipuler les aspects propriétaires d'un périphérique particulier.
Le WBF expose deux façons de configurer l'utilisation des périphériques biométriques. Pour les utilisateurs finaux, il est une applet le Panneau de configuration, qui est exposée dans plusieurs emplacements. Vous pouvez trouver le panneau périphériques biométriques sous Matériel et audio. À partir de cet emplacement, l'utilisateur peut lancer une application de gestion par empreinte digitale tiers. Windows 7 ne fournit pas une application de gestion des empreintes digitales intégré, pour que les fournisseurs tiers ou un OEM bénéficient d'écrire son propre. (Notez que le cadre biométrique Windows prend en charge local et ouverture de session de domaine, ainsi que UAC basé l'empreinte par le fournisseur d'informations d'identification biométrie intégré).
Le cadre biométrique Windows peuvent également être géré via la stratégie de groupe. Un administrateur peut activer ou désactiver la structure entière, ainsi que gérer les types de connexions peuvent utiliser biométrie (par exemple, local et le domaine ouvertures de session peut être configuré différemment).

Extension de protocoles d'authentification
Windows 7 améliore l'expérience de réseau domestique et petite par une fonctionnalité appelée Homegroup. Les utilisateurs peuvent partager des données, comme les fichiers multimédias entre les ordinateurs dans une maison et utiliser un ID en ligne pour s'authentifier entre ces ordinateurs. Les utilisateurs doivent explicitement lier leur compte d'utilisateur Windows à un code en ligne pour que cette fonctionnalité pour fonctionner. L'authentification est activée par un nouveau protocole appelé clé publique-en fonction utilisateur à utilisateur ou PKU2U.
Windows 7 présente également une extension le package d'authentification Negotiate, spnego.dll. SpNego est la fonctionnalité qui détermine quel protocole d'authentification doit à utiliser lors authentification. Avant Windows 7, il était généralement un choix entre Kerberos et NTLM (stimulation/réponse de Windows). L'extension NegoEx est considérée comme un protocole d'authentification par Windows et prend en charge deux fournisseurs de prise en charge de sécurité Microsoft : PKU2U et direct. Il est également extensible pour permettre le développement d'autres fournisseurs de prise en charge de sécurité.
Les deux de ces fonctionnalités fonctionnent lorsque se connecter à un autre ordinateur dans le Homegroup utilisant un numéro en ligne. Lorsqu'un ordinateur se connecte à un autre, l'extension de négociation appelle le fournisseur de prise en charge de sécurité PKU2U sur l'ordinateur d'ouverture de session. Le fournisseur de prise en charge de sécurité PKU2U récupère un certificat à partir du moteur de stratégie d'autorité de certificat et échange de la stratégie (avec les autres métadonnées) entre les ordinateurs homologues. Lorsque validé sur l'ordinateur homologue, le certificat est envoyé à l'homologue d'ouverture de session pour la validation, le certificat de l'utilisateur est mappé à un jeton de sécurité et le processus d'ouverture de session est terminé.

Améliorations de base BitLocker
Avec Windows Vista, Microsoft a introduit BitLocker. Il s'agit une solution de cryptage complet du volume conçue pour protéger les données de portables et les ordinateurs de bureau, comme les serveurs d'agence, même si l'ordinateur est perdu ou se situe dans les mains incorrects. Dans Windows 7, nombreuses améliorations apportées à la gestion de BitLocker. Celles-ci incluent la mise en œuvre cohérente par toutes les interfaces (l'interface utilisateur, l'outil de ligne de commande bde de gestion et le fournisseur WMI) et séparent les paramètres de lecteurs de données fixe stratégie de groupe. Il existe également des nouveaux paramètres de stratégie de groupe qui vous permettent de mettre à jour de vos mots de passe et d'intégrer avec cartes à puce sur les lecteurs du système d'exploitation non, et vous pouvez également modifier le comportement permettant le déverrouillage automatique.
Dans Windows Vista, il y a eu plaintes concernant est difficile à partitionner le lecteur du système d'exploitation pour préparer une installation de BitLocker, en particulier lorsque le système d'exploitation est déjà installé. Ce problème a été corrigé avec deux améliorations trouvées dans Windows 7. Tout d'abord, par défaut pendant l'installation de Windows 7, les utilisateurs obtiendront une partition distincte système active, qui est requise pour que BitLocker fonctionne sur les lecteurs du système d'exploitation. Cela élimine une deuxième étape qui a été requis dans de nombreux environnements. En outre, vous pouvez partitionner un disque pour que BitLocker dans le cadre de configuration BitLocker si vous n'avez pas déjà une partition système distinct. (voir figure 1 ).
Figure 1 Préparation d'un lecteur pour BitLocker

BitLocker pour atteindre
Un des ajouts plus visibles et plus importants est BitLocker À atteindre, qui est conçu pour protéger les données sur les lecteurs amovibles données. Elle permet de configurer le chiffrement de lecteur BitLocker sur les lecteurs flash USB et des disques durs externes. Objectifs de conception pour BitLocker À aller appelée pour la fonction soit facile à utiliser, pour qu'il fonctionne sur les lecteurs existants, pour permettre la récupération de données si nécessaire et pour activer les données soient utilisable sur les systèmes Windows Vista et Windows XP.
Il existe de nombreuses améliorations de gestion pour les responsables INFORMATIQUES tirer parti de cette fonctionnalité. Le plus notable est un nouveau paramètre de stratégie de groupe qui vous permet de configurer des lecteurs amovibles comme en lecture seule à moins que qu'ils sont chiffrés avec BitLocker À accéder. Il s'agit d'une étape excellente avant de s'assurer que les données critiques d'entreprise sont protégées lorsqu'un lecteur flash USB est mal placé par un employé.
Aussi notable est la capacité à récupérer des données à partir de n'importe quel périphérique BitLocker À aller où les données sont inaccessibles. Cette technologie, appelée un agent de récupération des données, a été intégralement de la fonctionnalité chiffré système de fichiers EFS et permet facilement de récupération des données d'entreprise sur un lecteur portable à l'aide de la clé créée par l'entreprise.
Obtention des fonctionnalités de BitLocker pour accéder à travailler sur Windows XP et Windows Vista requis certains reengineering de la fonctionnalité BitLocker principaux. Pour ce faire, l'équipe refactorisé la méthode par lequel BitLocker protège les volumes FAT. Comportement de BitLocker a été modifié pour superposer « volume découverte » sur le volume physique, d'origine et virtualiser les blocs remplacés. Le volume de découverte contient le BitLocker À atteindre lecteur ainsi qu'un fichier Lisezmoi. On parle d'un lecteur BitLocker hybride. Par défaut, lorsqu'un lecteur FAT est chiffré, un hybride lecteur BitLocker est créé. Le lecteur de découverte est visible uniquement sur les systèmes d'exploitation Windows XP et Windows Vista.
Le lecteur sera également disponible sur le Centre de téléchargement Microsoft après le lancement Windows 7. L'application permet d'accéder en lecture seule aux lecteurs BitLocker qui utilisent le protecteur de clé mot de passe. Notez que l'authentification carte à puce n'est pas disponible lorsque vous utilisez le BitLocker À atteindre lecteur.

Améliorations de contrôle de compte d'utilisateur
Le contrôle (compte d'utilisateur est une technologie souvent mal comprise. Tout d'abord, il est en fait une collection de fonctionnalités plutôt que simplement une invite de commandes. Ces fonctionnalités sont fichier et la redirection de Registre, détection de l'installeur, l'invite de contrôle de compte d'utilisateur, le ActiveX installer Service et plus. Ces fonctionnalités sont tous conçues pour permettre aux utilisateurs de Windows de s'exécuter avec les comptes d'utilisateur qui ne sont pas membres du groupe Administrateurs. Ces comptes sont généralement appelés utilisateurs standard et sont largement décrites comme exécution avec moindre privilège. La clé est que lorsque les utilisateurs exécutent avec des comptes utilisateur standard, l'expérience est de généralement beaucoup plus sécurisée et fiable.
De nombreux développeurs ont commencé à cibler leurs applications fonctionnent bien pour les utilisateurs standard. Les entreprises possèdent maintenant un chemin d'accès plus clair à déployer des comptes utilisateur standard, autorisant ces aux entreprises de réduire les coûts de support et le TCO (coût total de possession) globale de ses ordinateurs. À la maison, familles peuvent utiliser comptes d'utilisateur standard pour les enfants avec les contrôles parentaux pour créer un environnement plus sûr.
Windows 7 comprend de nombreuses améliorations pour améliorer l'expérience utilisateur standard et nouveaux paramètres de configuration fournir plus de contrôle sur l'invite de contrôle de compte d'utilisateur lorsque exécutez en mode Approbation administrateur. L'objectif est d'améliorer la facilité d'utilisation tout en continuant à rendre désactivez aux fournisseurs de logiciels indépendants que le contexte de sécurité par défaut, qu'ils doivent être ciblage est celle d'un utilisateur standard. Dans la pratique, ces modifications signifient que les utilisateurs pas invitera tâches administratives courantes dans Windows 7 à. Il s'agit le paramètre qui indique « avertir m'uniquement lorsque programmes tentez d'effectuer des modifications sur mon ordinateur. »
La façon dont il fonctionne est relativement simple. En cours de processus de création, la stratégie est activée pour voir si ce paramètre est activé. Si le processus en cours de création fait partie de Windows, qui est vérifié en vérifiant les fichiers de catalogue Windows de sa signature, le processus est créé sans une invite de commandes. Ce paramètre n'invite pas lorsque vous modifiez les paramètres de Windows mais au lieu de cela vous permet vous concentrer sur les modifications administratives demandées par les applications non Windows (tels que l'installation de nouveaux logiciels). Pour les personnes supérieur contrôle modification Windows fréquemment, sans les notifications supplémentaires, ce paramètre entraîne moins invites globales et permet aux utilisateurs de zéro dans sur la clé restant notifications ils voient.
Le autre changement important est que plusieurs composants ne nécessitent plus des privilèges d'administrateur. Par exemple, les utilisateurs peuvent configurer si leurs bureaux doit être affiché en mode haute résolution, une fonctionnalité couramment utilisée comme ordinateur écrans obtenir plus et formats de pixel obtenir de plus petites. Un autre exemple est que les utilisateurs standard peut maintenant réinitialiser leur connexion réseau lorsque physiquement connectés à l'ordinateur, une demande courants Microsoft a entendu les utilisateurs à domicile et entreprises.
La figure 2 contrôle de compte d'utilisateur d'installation d'un contrôle ActiveX
Réduction des invites signifie également rationalisation des zones où plusieurs invites se sont produites pour une action utilisateur unique. Sur Windows 7, par exemple, l'installation de contrôles ActiveX dans Internet Explorer est beaucoup plus lisse. Sur Windows Vista, Internet Explorer 7 créerait le processus IEInstal.exe pour effectuer l'installation d'un contrôle ActiveX. Cela a entraîné une invite de contrôle de compte d'utilisateur qui demande si vous souhaitiez « installer un Internet Explorer ajouter sur » pour exécuter avec des privilèges d'administrateur. Ce message n'a pas fournir beaucoup contexte sur exactement ce qui a été installé et Internet Explorer est immédiatement vous invite à approuver un contrôle particulier. Sur 7 Windows avec Internet Explorer 8, le processus d'installation a été modifié pour utiliser le service Installer ActiveX, qui l'extraire des informations publisher le contrôle ActiveX et l'afficher lors de l'expérience d'installation (voir figure 2 ). La nouvelle approche supprime également l'invite de deuxième lors de l'installation d'un contrôle ActiveX.

La possibilité de contrôler quelles applications un utilisateur ou ensemble d'utilisateurs, peut exécuter offre important augmente en la fiabilité et la sécurité des bureaux d'entreprise. En général, une stratégie de verrouillage des applications peut réduire le TCO d'ordinateurs dans une entreprise. Windows 7 ajoute AppLocker, une nouvelle fonctionnalité Contrôle de l'exécution d'une application et facilite encore créer une stratégie verrouillage application d'entreprise.
Durga Prasad Sayana et abordées application des stratégies de verrouillage dans problème de sécurité l'année dernière dans un article intitulé » Verrouillage des applications avec les stratégies de restriction logicielle ." Dans l'article, nous avons détaillés un certain nombre de défis une entreprise doit surmonter lorsque vous créez une telle stratégie. Ces défis quelques-uns des opérations suivantes :
  • Comprendre quels logiciels sont utilisé dans votre environnement
  • Savoir quelles applications différents utilisateurs devrait être autorisé à exécuter
  • Savoir comment créer la stratégie nécessaire
  • Déterminer si une stratégie fonctionne correctement lorsqu'il est déployé
Pour résoudre ces obstacles, AppLocker offre une approche nouvelle que vous pouvez auditer fonctionne une stratégie de verrouillage des applications. Permet de contrôler la façon dont les utilisateurs exécutent tous les types d'applications, exécutables, scripts, des fichiers Windows Installer et des DLL. Et il offre des primitives de stratégie qui sont plus spécifiques et ne sont pas soumis à saut dans facilement lorsqu'une application soit mis à jour nouvelle application verrouillage. Windows 7 inclut également prise en charge des règles de stratégie de restriction Security Rollup Package logiciel hérité, mais il n'existe pas de prise en charge pour les nouvelles règles AppLocker sur Windows XP et Windows Vista.
Les modes de mise en œuvre sont tous implémentés d'agent mise en œuvre sous-jacente du AppLocker, qui est implémentée dans le pilote appid.sys. Ce pilote offre la possibilité pour que règle de mode noyau recherche de ces événements que création d'un processus et du chargement des DLL. Pour les applications qui implémentent l'application en mode utilisateur, l'API SaferIdentifyLevel héritée sert à déterminer si une application peut s'exécuter. Mais IdentifyLevel safer-transmettre maintenant la vérification de l'application via à un service pour effectuer la vérification réelle du fichier binaire et stratégie. Cette est une amélioration architecturale significative sur la fonctionnalité stratégies de restriction logicielle héritée.
AppLocker est destiné à facilitent l'informatique à créer un simple ensemble de règles qui expriment toutes les applications qui sont autorisées à exécuter et vérifiez que les règles de résister aux mises à jour de l'application.
Pour créer la stratégie AppLocker, est un nouveau UX de composant logiciel enfichable MMC AppLocker le UX de composant logiciel enfichable Éditeur d'objets de stratégie de groupe, qui offre une amélioration incroyable dans le processus de création AppLocker règles. Il y a un Assistant qui vous permet de créer une seule règle, et un autre Assistant génère automatiquement des règles pour vous en fonction de vos préférences de règle et le dossier que vous sélectionnez (voir figure 3 ).
La figure 3 générer automatiquement des règles de stratégie AppLocker.
Vous pouvez consulter les fichiers analysés et les supprimer de la liste avant de créer les règles. Vous pouvez encore obtenir des statistiques utiles sur la fréquence à laquelle un fichier a été bloqué ou test AppLocker stratégie pour un ordinateur donné.
Dans les stratégies de restriction logiciel précédent, il était particulièrement difficile à créer des stratégies ont été sécurisées, mais également ne pas rompre de mises à jour logicielles. Il a en raison de l'absence de granularité de règles de certificat et la fragility des règles de hachage qui fonctionneraient lorsqu'une application binaire a été mis à jour. Pour résoudre ce problème, AppLocker vous permet de créer une règle qui combine un certificat et un nom de produit, nom de fichier et version du fichier. Cela facilite spécifier que quoi que ce soit signé par un fournisseur particulier d'un nom de produit spécifique peut être exécutée.
Stratégies AppLocker dans Windows 7 ont autres avantages, ainsi, notamment la séparation entre les différents types d'exécution (à savoir EXE, DLL et MSI ou hôtes de script). Ces types de fichiers sont entrent dans quatre compartiments appelés des collections de règle, et l'application est configurée séparément pour chaque. Par exemple, les administrateurs peuvent activer AppLocker recherche les fichiers exécutables sans activer les vérifications de fichiers de script.
La stratégie AppLocker est stockée sous la clé HKLM\Software\Policies\Microsoft\Windows\SrpV2. La stratégie est stockée dans un format XML et est traduite par le service d'identité de l'application (AppID). Lorsque stratégie est traitée, le pilote appid.sys est notifié sur la nouvelle stratégie par le service via le IOCTL_SRP_POLICY et le pilote Recharger la stratégie.
La première tâche quand l'approche de modifications à votre environnement informatique consiste à évaluer comment l'environnement fonctionne actuellement. Puis vous pouvez soigneusement planifier et tester les modifications pour vous assurer qu'ils peuvent être implémentées correctement. Cela est l'utilité du mode de mise en œuvre d'audit uniquement.
L'application de la stratégie d'application-Locker d'audit est extrêmement important. Non seulement ne vous autorise cette à tester une stratégie avant qu'il est appliqué, mais il également offre vous la possibilité d'observer le fonctionnement de la stratégie lors de sa durée de vie. Vous seriez sans aucun doute amené à savoir si un certain ensemble d'utilisateurs nécessaire à une application pour travailler à un moment donné. Cela peut être déterminée en connexion à un système et en vérifiant les informations d'audit AppLocker pour voir si une stratégie de verrouillage des applications a été empêche une application particulière en cours d'exécution.
Le canal principal pour les événements AppLocker se trouve dans les applications et les journaux de service qui peuvent être affichés dans les événements application Observateur (eventvwr.msc). Pour afficher ces entrées de journal, recherchez le fichier EXE, DLL et les journaux MSI et script sous le canal d'événements Microsoft\Windows\AppLocker\. Nombreux différents événements peuvent être générés, y compris si une application a été autorisée ou bloquée et si une stratégie a été appliquée à un système.

Validation DNSSec
Au cours de ces quelques années, menaces liées DNS sont devenus un problème plus courant sur Internet. Il y a mieux comprendre comment les messages incohérents DNS serveurs, et pirates démarrent faire utiliser ces informations. Cela signifie qu'un utilisateur peut potentiellement accéder à un site Web et ne pas être absolument sûr qu'il n'est pas visitent un site Web différent et malveillant.
Windows Server 2008 v2 et Windows 7 présente prise en charge de DNSSEC par les normes actuelles (RFC 4033, RFC 4034 et RFC 4035). Windows Server 2008 R2 autorise le serveur DNS pour fournir origine artefacts intégrité autorité et de données. En fait, un serveur va pouvoir associer des signatures numériques à données DNS de réponses ainsi que de valider des données provenant d'autres serveurs DNS.
Windows 7 est le premier système de d'exploitation client pour inclure les éléments nécessaires pour permettre au client de vérifier qu'il est en toute sécurité communique avec un serveur DNS et vérifiez que le serveur a exécuté la validation DNSSEC en son nom. Cette technologie est actuellement en cours testée pour garantir la compatibilité maximale avec infrastructure Internet actuelle et vise à jouer un rôle continue dans la sécurisation des données DNS dans le futur.
SACL global et Audit précis
Windows 7 étend précédentes mécanismes d'audit offre nouvelles fonctionnalités qui vous permettent de gérer l'audit pour les utilisateurs au lieu d'objets uniquement et pour fournir plus d'informations sur AccessCheck échecs pour les objets fichier. Cette permet de nouveaux scénarios d'audit et offre un changement de paradigme significative lié à l'audit.
Dans d'autres versions de Windows, déterminer si vous souhaitez auditer l'accès aux objets portait sur Si le descripteur de sécurité d'un objet inclus une entrée de contrôle l'accès (ACE) dans sa SACL indiquant qu'il doit être audité. Cela rendait très facile de suivre une clé de Registre ou de fichier pour voir les accès a été se produisant sur cet objet. Malheureusement, ne survenu aucune méthode pour regarder ce qui accédait un utilisateur particulier. Si vous vouliez ce scénario, vous avez probablement deviez activer l'audit pour chaque ressource que l'utilisateur peut interagir avec et par conséquent chaque accès par n'importe quel utilisateur de la ressource est finissent dans le journal d'audit.
L'activation de l'audit sur une à l'échelle suffisamment jeu de données pour capturer les un utilisateur peut accéder est un processus très compliquée. Chaque ressource doit être mis à jour pour inclure la stratégie d'audit dans la liste SACL et les modifications apportées à cette stratégie est nécessitent chaque SACL mise à jour. Pour contourner cette limitation, Windows 7 introduit le principal objet Access Audit, qui est géré par auditpol.exe et est configurable à l'aide de la stratégie de groupe.
L'audit de Access Ojbect global comprend un SACL principal qui est une chaîne SDDL stockée dans le Registre avec d'autres données liées à l'audit. Deux nouvelles API ont été ajoutés à gérer la liste SACL global : AuditSetGlobalSacl et AuditQueryGlobalSacl. Mise à jour de la liste SACL principal nécessite le SeSecurityPrivilege, ce qui empêche la SACL global de mis à jour par un utilisateur sans droits d'administrateur.
L'audit de sécurité dans Windows 7 permet également de comprendre pourquoi l'accès à un objet a échoué ou a réussi. Cela est des informations importantes si vous vous déboguer une erreur d'application ou tente de comprendre si votre stratégie de sécurité est efficace. À la fois la fonctionnalité globale objet Access audit et l'inclusion de données d'audit accès supplémentaires sont implémentés dans un nouveau noyau en mode sécurité API, SeAccessCheckEx. Les gestionnaires de ressources deux pour utiliser cette API sont NTFS et le partage de fichiers détaillées dans Windows 7, et lorsqu'il est activé, l'API placera informations dans le journal d'audit sur les raisons tentative d'accès réussi ou a échoué. Par conséquent ces fonctionnalités s'appliquent aux partages de fichiers système et fichiers pour l'instant et peuvent être développées aux autres responsables de ressources avenir versions de Windows.

Windows 7 permet nouveaux scénarios et permet à l'aide de Windows un environnement plus sécurisé. La plupart de ces fonctionnalités sont un actif fort de l'expérience utilisateur (pour les utilisateurs à domicile, aux utilisateurs professionnels et informatique) et permettent Windows 7 systèmes fonctionnent encore mieux.

Chris Corio était un membre de l'équipe Windows Security chez Microsoft pour plus de cinq années. Son principal objectif de Microsoft était technologies de sécurité des applications et des technologies de gestion pour la sécurisation de Windows. Vous pouvez contacter Chris à .

Page view tracker