Sugerir tradução
Outras sugestões:

progress indicator
Sem sugestões.
TechNet Magazine > Home > Todas as edições > 2009 > TechNet Magazine Maio 2009 >  Uma introdução à segurança no Windows 7
Exibir Conteúdo: Lado a LadoExibir Conteúdo: Lado a Lado
Este é um conteúdo traduzido por máquina que os membros da comunidade podem editar. Incentivamos você a melhorar a tradução clicando no link Editar associado a qualquer sentença abaixo.
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 .

Uma introdução à segurança no Windows 7
Chris Corio
Partes deste artigo são baseadas no código pré-lançamento. Todas as informações aqui contidas estão sujeitas a alterações.
Visão geral:
  • Windows Biometric Framework
  • Perfis de autenticação extendidos
  • BitLocker To Go
  • Aprimoramentos do UAC
O Windows Vista introduziu uma variedade de novas tecnologias de segurança que tiveram um impacto significativo no ecossistema do Windows. O Controle de Conta de Usuário tornou claro que a Microsoft queria facilitar para os usuários executarem o Windows sem estarem no grupo de Administradores. O BitLocker introduziu a criptografia total da partição para o cliente do Windows. O modo protegido do Internet Explorer ajudou a tornar a navegação na Internet uma experiência mais segura.
No Windows 7, a Microsoft continuou seu investimento em segurança adicionando novas tecnologias, bem como melhorando muitas das tecnologias introduzidas no Windows Vista. Neste artigo, fornecerei uma visão geral dos novos recursos de segurança e aprimoramentos que você encontrará no Windows 7.

Windows Framework biométrica
O Windows Vista obteve um novo desenho através da experiência do Winlogon. Essa experiência removeu a infra-estrutura do GINA (Graphical Identification and Authentication - Identificação e Autenticação Gráficas) e adicionou o modelo de extensão do Provedor de Credenciais. A infra-estrutura do Provedor de Credenciais era um conjunto de interfaces que permitia consistência quando terceiros estendiam a experiência do usuário quando estes inseriam suas credenciais; e se integra à comum caixa de diálogo de Credenciais do Windows.
Para o Windows 7, a Microsoft adicionou o novo Framework Biométrico do Windows (WBF - Windows Biometric Framework). Com leitores de impressão digital se tornando cada vez mais comuns, ficou desmarque que define uma estrutura comum para expor, gerenciando e usando essas tecnologias era necessário para o desenvolvimento de unidade e confiabilidade. O WBF destina-se a facilitar o suporte a dispositivos de autenticação biométrica. No Windows 7, o WBF oferece suporte a apenas leitores de impressão digital, mas ele pode ser expandido no futuro.
A plataforma central do WBF consiste nestes componentes principais:
  • Interface do Driver Biométrico do Windows (WBDI)
  • Serviço Biométrico do Windows (EDT)
  • API do WBF
  • Experiência do Usuário e Pontos de Integração do WBF
  • Gerenciamento do WBF
A Interface de driver de biometria (WBDI) do Windows tem como objetivo fornecer uma interface comum de driver para dispositivos biométricos. Ele consiste em uma variedade de interfaces que expõem as estruturas de dados apropriadas e IOCTLs (controles de entrada/saída) para dispositivos biométricos para integrar à estrutura biométrica. Drivers podem ser implementados em qualquer uma das estruturas de driver comuns, incluindo o Modelo de Driver do Windows, o Framework de Driver em modo Kernel e o Framework de Driver em modo Usuário (UMDF). UMDF, no entanto, é a estrutura de driver recomendada para dispositivos biométricos porque fornece a vantagem adicional de maior confiabilidade para o Windows no caso de uma falha ocorrer no driver de dispositivo biométrico.
O Serviço de Biometria do Windows (WBS) é o componente chave que vincula junto ao WBF. O WBS interage com os drivers de dispositivos biométricos e também expõe as APIs do Framework Biométrico do Windows, permitindo que os aplicativos interajam com esses dispositivos.
Um recurso importante do WBS é que ele nunca revela os dados biométrico reais de um usuário para aplicativos não privilegiados. Isso é importante porque, ao contrário de uma senha, é muito difícil para alguém alterar sua assinatura biométrica depois que ela foi cedida. Em vez disso, o WBS expõe um identificador (normalmente um GUID ou um SID) que permite que aplicativos trabalhem com os dados biométricos indiretamente.
WBS também gerencia conjuntos de dispositivos de autenticação biométrica. Isso lhe permite controlar como os dispositivos biométricos são usados. Determinados dispositivos podem ser usados com qualquer caixa de diálogo de Credenciais, como o prompt de logon ou um prompt do UAC. Por exemplo, você pode habilitar o Controle dos Pais no seu computador doméstico, e quando a elevação for necessária no sistema, você pode simplesmente passar o dedo para fornecer a elevação. Esse conjunto de dispositivos biométricos é conhecido como o conjunto do sistema. Há outros dois conjuntos de dispositivos. Há o conjunto particular, que permite que aplicativos ofereçam autenticação que não esteja integrada à infra-estrutura de autenticação do Windows. E há o conjunto não atribuído, que é para dispositivos que, como você deve ter adivinhado, não se encaixam em nenhum dos dois conjuntos anteriores.
Cada dispositivo que faz parte de um conjunto de dispositivos é, na verdade, abstraído pelo WBS usando uma classe de dados chamada de Unidade Biométrica. A unidade biométrica se conecta ao provedor de serviços biométricos do WBS (BSP), que implementa as diretivas e comportamentos específicos para um conjunto de dispositivos biométricos. A Unidade Biométrica permite que o BSP forneça quaisquer recursos que um determinado dispositivo possa não suportar, como armazenamento de dados de impressão digital ou processamento dos dados da impressão digital após sua obtenção por um dispositivo.
O terceiro componente principal do WBF é o conjunto de APIs, também conhecido como as APIs WinBio *, que pode ser usado por aplicativos e componentes no modo de usuário para interagir diretamente com os dispositivos. Isso inclui a interação com um dispositivo durante o processo de registro original para obter a impressão digital de um usuário e correlacioná-la com uma conta de usuário específica, bem como a tarefa de verificação de um usuário para logon ou o UAC. Essas APIs também expõem dados sobre o dispositivo biométrico específico e suas características. Além disso, as APIs do WBF pode ser extendidas para permitir que um aplicativo interaja com aspectos particulares de um determinado dispositivo.
O WBF expõe duas maneiras principais de configurar o uso de dispositivos biométricos. Para usuários finais, há um miniaplicativo no Painel de Controle que pode ser encontrado em alguns locais. Você pode encontrar o Painel de Controle de Dispositivos Biométricos em Hardware e Sons. Desse local, o usuário pode iniciar um aplicativo de terceiros de gerenciamento de impressões digitais. Windows 7 não fornece internamente um aplicativo de gerenciamento de impressões digitais, logo qualquer fornecedor ou OEM de terceiros terá de escrever seu próprio. (Observe que o Framework Biométrico do Windows dá suporte a logon local e de domínio, bem como UAC baseado em impressão digital através do provedor interno de credenciais biométricas.)
O Framework Biométrico do Windows também pode ser gerenciado por meio de Diretivas de Grupo (GPO). Um administrador pode ativar ou desativar a estrutura inteira, bem como gerenciar que tipos de logons podem usar biometria (por exemplo, logons locais e de domínio podem ser configurados diferentemente).

Estendendo os protocolos de autenticação
O Windows 7 melhora a experiência de redes pequenas e domésticas com um recurso chamado Grupo Doméstico (HomeGroup). Os usuários podem compartilhar dados, como arquivos de mídia, entre computadores de uma casa e usar uma identificação online para se autenticarem entre esses computadores. Os usuários devem vincular explicitamente sua conta de usuário do Windows a uma identificação online para que essa funcionalidade passe a funcionar. A autenticação é habilitada por um novo protocolo chamado de 'Public Key-based User to User' ou PKU2U.
O Windows 7 também introduz uma extensão ao pacote de autenticação de negociação, Spnego.dll. SpNego é o recurso que decide qual protocolo de autenticação deve ser usado durante a autenticação. Antes do Windows 7, era geralmente uma escolha entre Kerberos e NTLM (Convite/Resposta do Windows). A extensão NegoEx é tratada como um protocolo de autenticação pelo Windows e oferece suporte a dois provedores de suporte a segurança da Microsoft: PKU2U e Live. Também é extensível para permitir o desenvolvimento de outros provedores de suporte a segurança.
Ambos os recursos funcionam quando se conecta a outro computador no Grupo Doméstico usando uma identificação on-line. Quando um computador se conecta a outro, a extensão de negociação chama o provedor de suporte a segurança PKU2U do computador de login. O provedor de suporte a segurança PKU2U obtém um certificado do mecanismo de diretiva de autoridade de certificado e troca a diretiva (junto com outros metadados) entre os computadores. Quando validado no computador de mesmo nível, o certificado é enviado para o ponto de logon para validação, o certificado do usuário é mapeado para um token de segurança e o processo de logon for concluído.

Aprimoramentos principais de disco BitLocker
Com o Windows Vista, a Microsoft introduziu o BitLocker. Essa é uma solução de criptografia de volume completo criada para proteger os dados em laptops e computadores desktops, como servidores de escritório de filial, mesmo se o computador for perdido ou ficar em mãos erradas. No Windows 7, muitos aprimoramentos foram feitos para o gerenciamento de disco BitLocker. Essas incluem a aplicação consistente através de todas as interfaces (a interface do usuário, a ferramenta de gerenciamento-bde linha de comando e o provedor WMI) e separam as configurações de diretiva de grupo para unidades de dados fixa. Também existem novas configurações de diretiva de grupo que permitem que você atualize suas senhas e integrar com cartões inteligentes em unidades de não-OS e você também pode alterar o comportamento relacionado ao desbloqueio automático.
No Windows Vista, houve reclamações sobre ele sejam difíceis de particionar a unidade de sistema operacional para se preparar para uma instalação do BitLocker, especialmente quando o sistema operacional é já instalado. Esse problema foi abordado com dois aprimoramentos encontrados no Windows 7. Em primeiro lugar, por padrão durante a instalação do Windows 7, os usuários receberão uma partição separada do sistema ativo, o que é necessária para o BitLocker funcione em unidades de sistema operacional. Isso elimina uma segunda etapa era necessária em muitos ambientes. Além disso, você pode particionar uma unidade para o BitLocker como parte da instalação BitLocker se você já não tiver uma partição separada do sistema. (veja a Figura 1 ).
Figura 1 Preparando-se uma unidade de disco BitLocker

O BitLocker para ir
Uma das adições mais visíveis e mais importantes é o BitLocker para viagem, criado para proteger dados nas unidades de dados removível. Ele permite que você configurar a criptografia de unidade de disco BitLocker em unidades flash USB e unidades de disco externas. Metas de design para BitLocker ir chamada para o recurso para ser fácil de usar, para que isso funcione em unidades existentes, para permitir a recuperação de dados se necessário e habilitar os dados a ser usado em sistemas Windows Vista e Windows XP.
Há muitos aprimoramentos de gerenciamento para os gerentes de TI aproveitar com esse recurso. O mais relevante é uma nova configuração de diretiva de grupo que lhe permite configurar unidades removíveis como somente leitura, a menos que eles são criptografados com BitLocker ir. Isso é uma etapa excelente frente em assegurar que os dados corporativos críticos sejam protegidos quando uma unidade flash USB é mal colocada por um funcionário.
Também notável é a capacidade de recuperar dados de qualquer dispositivo de disco BitLocker ir quando os dados são inacessíveis. Essa tecnologia, denominada um agente de recuperação de dados, foi portada do recurso de sistema de arquivos criptografados (EFS) e permite a fácil recuperação de dados corporativos em uma unidade portátil usando a chave criada da empresa.
Obter a funcionalidade de disco BitLocker ir trabalhar no Windows XP e Windows Vista necessário alguns reengineering do recurso de disco BitLocker principal. Para fazer isso, a equipe refatorar o método pelo qual o BitLocker protege volumes FAT. Comportamento de BitLocker foi modificado para sobrepor "volume descoberta" no volume físico, original e virtualizar os blocos substituídos. O volume de descoberta contém o BitLocker para ir Reader, bem como um arquivo Leiame. Isso é chamado de uma unidade BitLocker híbrida. Por padrão, quando uma unidade FAT é criptografada, um unidade de disco BitLocker híbrido é criado. A unidade de descoberta está visível somente nos sistemas operacionais Windows XP e Windows Vista.
O leitor também estará disponível no Centro de download Microsoft após o lançamento do Windows 7. O aplicativo fornece acesso somente leitura para unidades de disco BitLocker que utilizam o protetor de chave de senha. Observe que autenticação de cartão inteligente não está disponível ao usar o BitLocker para ir Reader.

Aprimoramentos do UAC
Controle de conta de usuário (UAC) é uma tecnologia freqüentemente mal compreendida. Primeiro, é realmente um conjunto de recursos em vez de apenas um prompt. Esses recursos incluem arquivos e o redirecionamento do registro, detecção do instalador, o prompt do UAC, o serviço do ActiveX Installer e mais. Todos esses recursos são projetados para permitir que os usuários Windows executem com contas de usuário que não são membros do grupo Administradores. Essas contas são geralmente chamadas de usuários padrão e são amplamente descritas como executando com privilégios mínimos. A chave é que quando os usuários executam com contas de usuário padrão, a experiência é geralmente muito mais seguro e confiável.
Muitos desenvolvedores começaram direcionar seus aplicativos funcionem bem para usuários padrão. As empresas agora tem um caminho mais claro para implantação de contas de usuário padrão, permitindo que essas empresas para reduzir os custos de suporte e o TCO (custo total de propriedade) geral de seus computadores. Em casa, famílias podem usar contas de usuário padrão para crianças juntamente com os controles dos pais para criar um ambiente mais seguro.
Windows 7 inclui vários aprimoramentos para melhorar a experiência do usuário padrão e novas configurações fornecem mais controle sobre prompt de controle de conta de usuário quando executado no modo de aprovação de administrador. O objetivo é aumentar a usabilidade enquanto continua a torná-lo desmarque para fornecedores independentes de software que o contexto de segurança padrão deve ser direcionamento é de um usuário padrão. Na prática, essas alterações significam que os usuários não são solicitados para tarefas administrativas comuns no Windows 7. Esta é a configuração que diz "Avisar apenas quando programas tenta fazer as alterações para o meu computador."
A maneira que isso funciona é bastante direta. Durante a criação do processo, a diretiva é verificada para se essa configuração está ativada. Se o processo que está sendo criado é parte do Windows, que é verificada, verificando os arquivos de catálogo de sua assinatura, Windows o processo será criado sem um prompt. Essa configuração não solicita quando você alterar as configurações do Windows mas em vez disso, permite que você focalizar alterações administrativas que está sendo solicitadas pelo aplicativos não-Windows (como o novo software é instalado). Para as pessoas que desejar maior controle alteração as configurações do Windows com freqüência, sem as notificações adicionais, essa configuração resulta em menos solicitações gerais e permite que os usuários zero na chave restante notificações que eles estiver vendo.
A outra alteração significativa é que vários componentes não mais exigem privilégios de administrador. Por exemplo, os usuários podem configurar se suas áreas de trabalho devem ser exibidas no modo de DPI alta, um recurso comumente usado que aumentam as telas de computador e tamanhos de pixel ficam menores. Outro exemplo é que usuários padrão agora pode redefinir a sua conexão de rede quando conectado fisicamente ao computador, uma solicitação comum Microsoft tenha ouvido do usuários domésticos e empresas.
A Figura 2 controle de conta de usuário ao instalar um controle ActiveX
Reduzir prompts também significa simplificando áreas onde vários avisos foram encontrados para uma ação de usuário único. No Windows 7, por exemplo, instalando controles ActiveX no Internet Explorer é muito mais suave. No Windows Vista, Internet Explorer 7 criaria o processo de IEInstal.exe para executar a instalação de um controle ActiveX. Isso resultou em um prompt do UAC que perguntado se você quisesse "instalar um IE adicionar em" Executar com privilégios de administrador. Esse prompt não forneceu muito contexto sobre exatamente o que estava sendo instalado e Internet Explorer deve imediatamente solicitará que você para aprovar um controle específico. No Windows 7 com o Internet Explorer 8, o processo de instalação foi modificado para usar o serviço de Installer ActiveX, que irá extrair informações do editor do controle ActiveX e exibi-lo durante a experiência de instalação (veja a Figura 2 ). A nova abordagem também remove o segundo prompt durante a instalação de um controle ActiveX.

A capacidade de controlar os aplicativos que um usuário ou conjunto de usuários, pode executar oferece significativo aumenta na confiabilidade e segurança de áreas de trabalho da empresa. Em geral, uma diretiva de bloqueio de aplicativo pode reduzir o TCO de computadores em uma empresa. Windows 7 adiciona AppLocker, um novo recurso que controla a execução do aplicativo e torna ainda mais fácil criar uma diretiva de bloqueio de aplicativo empresarial.
Durga Prasad Sayana e discutido diretivas de bloqueio de aplicativo no problema de segurança do ano passado em um artigo chamado" Bloqueio de aplicativo com as diretivas de restrição de software ." No artigo, nós detalhadas vários desafios que uma empresa precisa ser superadas ao criar uma diretiva. Alguns desses desafios incluem o seguinte:
  • Noções básicas sobre qual software é usado em seu ambiente
  • Saber quais aplicativos vários usuários deve ter permissão para executar
  • Saber como criar a diretiva necessária
  • Determinar se uma diretiva funcionará corretamente quando implantado
Para resolver essas dificuldades, AppLocker oferece uma nova abordagem que pode fazer a auditoria como uma diretiva de bloqueio de aplicativo funcionará. Ele fornece a capacidade de controlar como os usuários executar todos os tipos de aplicativos, arquivos executáveis, scripts, arquivos do Windows Installer e DLLs. E oferece bloqueio de aplicativo novos primitivos de diretiva que são mais específicos e não estão sujeitos a interrupção como facilmente quando um aplicativo é atualizado. Windows 7 também inclui suporte para regras de diretiva de restrição de software (SRP) herdado, mas não há suporte para as novas regras de AppLocker no Windows XP e no Windows Vista.
Todos os modos de aplicação são implementados na parte superior de agente de imposição subjacente do AppLocker, o que é implementado no driver appid.sys. Esse driver oferece a capacidade para que regra de modo kernel verificando tais eventos como a criação do processo e carregamento de DLL. Para aplicativos que implementam aplicação no modo de usuário, a API herdada SaferIdentifyLevel é usado para determinar se um aplicativo pode ser executado. Mas IdentifyLevel Safer-será agora entregar a verificação de aplicação para um serviço para executar a verificação real de binários e de diretiva. Este é um aprimoramento de arquitetura significativo sobre o recurso de diretivas de restrição de software herdado.
AppLocker deve facilitar para profissionais de TI criar um conjunto simples de regras que expresse todos os aplicativos que são permissão para executar e garantir que as regras sejam resistentes a atualizações de aplicativos.
Para criar diretiva AppLocker, há um novo UX snap-in do MMC AppLocker in the UX de snap-in Editor de objeto de diretiva de grupo, que oferece um aperfeiçoamento incrível no processo de criação de regras de AppLocker. Há um assistente que permite que você crie uma única regra e outro Assistente gera automaticamente as regras com base em suas preferências de regra e a pasta que você selecionar (veja a Figura 3 ).
A Figura 3 Gerar automaticamente regras de diretiva de AppLocker.
Você pode examinar os arquivos analisados e removê-los da lista antes que as regras sejam criadas para eles. Você pode até mesmo obter estatísticas úteis sobre a freqüência um arquivo foi bloqueado ou testar AppLocker diretiva para um determinado computador.
Nas diretivas de restrição de software anteriores, era particularmente difícil criar diretivas que foram seguro, mas também não quebrar de atualizações de software. Isso foi devido à falta de granularidade de regras de certificado e a fragilidade de regras de hash que poderia interromper quando um aplicativo binário foi atualizada. Para resolver esse problema, AppLocker permite que você criar uma regra que combina um certificado e um nome de produto, nome de arquivo e versão do arquivo. Isso facilita especificar que qualquer assinado por um fornecedor específico para um nome de produto específico pode executar.
As diretivas de AppLocker no Windows 7 têm outros benefícios, além disso, incluindo a separação entre diferentes tipos de execução (como EXEs, DLLs e MSI ou script de hosts). Esses tipos de arquivo são ajustam quatro classificações chamadas conjuntos de regra, e imposição é configurada separadamente para cada um. Por exemplo, os administradores podem permitir AppLocker procura arquivos executáveis sem ativar verificações de arquivos de script.
A diretiva AppLocker é armazenada na chave HKLM\Software\Policies\Microsoft\Windows\SrpV2. A diretiva é armazenada em um formato XML e é convertida pelo serviço de identidade do aplicativo (AppID). Quando diretiva é processada, o driver appid.sys é notificado sobre a nova diretiva pelo serviço por meio a IOCTL_SRP_POLICY e o driver será recarregar a diretiva.
A primeira tarefa quando se aproximando de alterações para o ambiente de TI é avaliar como o ambiente está funcionando no momento. Em seguida, você pode planejar cuidadosamente e testar quaisquer alterações para garantir que eles podem ser implementados sem problemas. Essa é a finalidade do modo de aplicação apenas auditoria.
Auditoria a aplicação da diretiva Bloqueador de aplicativo é extremamente importante. Não apenas isso permitem testar uma diretiva antes que ela é aplicada, mas ele também oferece você a capacidade para observar como a diretiva executa durante sua existência. Definitivamente, você vai querer saber se um determinado conjunto de usuários necessário um aplicativo funcione em algum momento. Isso pode ser determinado conectando-se a um sistema e revisar as informações de auditoria AppLocker para ver se uma diretiva de bloqueio de aplicativo foi impedindo um aplicativo específico em execução.
O canal primário para eventos de AppLocker está nos aplicativos e logs de serviço que pode ser exibido em eventos aplicativo Visualizador (eventvwr.msc). Para exibir essas entradas do log, procure no EXE e DLL e os logs MSI e scripts no canal de evento Microsoft\Windows\AppLocker\. Muitos eventos diferentes podem ser gerados, incluindo se um aplicativo foi permitido ou bloqueado e se uma diretiva foi aplicada a um sistema.

Validação de DNSSec
Nos últimos dois anos, relacionados ao DNS explorações tornaram um problema mais comum na Internet. Há uma melhor compreensão sobre como suspeitas servidores DNS e os invasores estão começando a fazer uso de informações. Isso significa que um usuário pode não ter certeza absoluta de que ele não é visitar um site diferente, mal-intencionado e potencialmente visitar um site.
O Windows Server 2008 R2 e o Windows 7 apresenta suporte para DNSSEC de acordo com os atuais padrões (RFC 4033, RFC 4034 e RFC 4035). O Windows Server 2008 R2 permitirá que o servidor DNS fornecer os artefatos de integridade de autoridade e dados de origem. Basicamente, um servidor poderão anexar assinaturas digitais a dados DNS nas respostas bem como validar os dados recebidos de outros servidores DNS.
Windows 7 é o primeiro sistema de operacional do cliente para incluir as partes necessárias para permitir que o cliente verificar se ele está se comunicando com segurança com um servidor DNS e verificar que o servidor executou DNSSEC validação em seu nome. Essa tecnologia no momento está sendo testada para garantir a compatibilidade máxima com infra-estrutura da Internet atual e visa desempenham um papel contínuo na proteção de dados DNS no futuro.
As SACLs globais e completas de auditoria
Windows 7 estende anteriores mecanismos de auditoria para oferecem novos recursos que permitem que você gerenciar a auditoria de usuários em vez de apenas objetos e fornecer mais informações sobre falhas de AccessCheck para objetos de arquivos. Isso permite novos cenários de auditoria e fornece uma mudança de paradigma significativa relacionada a auditoria.
Em outras versões do Windows, determinar se será feita uma auditoria de acesso a objetos foi baseado em se o descritor de segurança de um objeto incluída uma entrada de controle de acesso (ACE) no seu SACL especificando que devem ser auditada. Isso facilitou muito monitorar certos chave do Registro ou arquivo para ver o acesso foi ocorrendo no objeto. Infelizmente, não havia nenhum método para observar que um usuário específico foi acessar. Se você quisesse nessa situação, provavelmente seria necessário ativar a auditoria para cada recurso que o usuário, possivelmente, pode interagir com e, portanto, cada acesso por qualquer usuário do recurso acabaria no log de auditoria.
Ativando a auditoria em um nível suficiente conjunto de dados para capturar o que um usuário pode acessar é um processo extremamente árduo. Cada recurso precisa ser atualizado para incluir a diretiva de auditoria dentro a SACL e quaisquer alterações nessa diretiva pode ser necessário cada SACL ser atualizado. Para superar essa limitação, Windows 7 apresenta global objeto acesso auditoria, que é gerenciado pelo auditpol.exe e é configurável usando a diretiva de grupo.
A auditoria de acesso de Ojbect global inclui uma "SACL global" que é uma seqüência SDDL armazenada no registro com outros dados relacionados à auditoria. Duas APIs novos foram adicionados ao gerenciar a SACL global: AuditSetGlobalSacl e AuditQueryGlobalSacl. Atualizando a SACL global requer SeSecurityPrivilege, que protege a SACL global sejam atualizados por um usuário sem privilégios de administrador.
Auditoria de segurança no Windows 7 também permite para entender o porquê acesso a um objeto falha ou bem-sucedida. São informações importantes se você estiver depurando uma falha de aplicativo ou tentando compreender se a diretiva de segurança é eficaz. Tanto a funcionalidade de auditoria de acesso de objeto global e a inclusão de dados de auditoria de acesso adicionais são implementadas em um novo kernel modo segurança API, SeAccessCheckEx. Os gerentes de dois recursos para consumir essa API será NTFS e o compartilhamento de arquivos detalhadas no Windows 7, e quando ativado, a API será colocada informações no log de auditoria sobre por que uma tentativa de acesso com êxito ou falha. Assim, esses recursos se aplicam aos compartilhamentos de sistema e o arquivo do arquivo por enquanto e podem ser expandidos para outros gerenciadores de recursos em futuras versões do Windows.

Quebra automática para cima
Windows 7 permite novos cenários e faz usando o Windows uma experiência mais segura. Muitos desses recursos tem um foco forte na experiência do usuário (para usuários domésticos, usuários comerciais e profissionais de TI) e permitir que sistemas Windows 7 funcione melhor.

Chris Corio foi membro da equipe de Segurança do Windows na Microsoft por mais de cinco anos. Seu foco principal na Microsoft foi tecnologias de segurança de aplicativos e tecnologias de gerenciamento para proteger o Windows. Você pode acessar Chris em .

Page view tracker