Arquivo morto: requisitos de certificação para Aplicativos da Área de Trabalho do Windows v1.1

Versão do documento: 1.1

Data do documento: 26 de janeiro de 2012

Este documento contém os requisitos técnicos e qualificações de qualificação que um aplicativo da área de trabalho deve atender para participar do Programa de Certificação de Aplicativos da Área de Trabalho Windows 8. Para o Windows 7, esse programa era conhecido como Programa de Logotipo de Software do Windows.

Seja bem-vindo!

A plataforma Windows dá suporte a um amplo ecossistema de produtos e parceiros. Exibir o logotipo do Windows em seu produto representa uma relação e um compromisso compartilhado com a qualidade entre a Microsoft e sua empresa. Os clientes confiam na marca Windows em seu produto porque ela garante que ela atenda aos padrões de compatibilidade e tenha um bom desempenho na plataforma Windows. Passar com êxito na Certificação de Aplicativos do Windows permite que seu aplicativo seja exibido no Centro de Compatibilidade do Windows e também é uma etapa necessária para listar uma referência de aplicativo da área de trabalho na Windows Store.

O Programa de Certificação de Aplicativos do Windows é composto por requisitos técnicos e de programas para ajudar a garantir que aplicativos de terceiros que carregam a marca Windows sejam fáceis de instalar e confiáveis em computadores que executam o Windows. Os clientes valorizam a estabilidade, a compatibilidade, a confiabilidade, o desempenho e a qualidade nos sistemas que compram. A Microsoft concentra seus investimentos para atender a esses requisitos de aplicativos de software projetados para execução na plataforma Windows para computadores. Esses esforços incluem testes de compatibilidade para consistência de experiência, melhor desempenho e segurança aprimorada em computadores que executam o software Windows. Os testes de compatibilidade da Microsoft foram projetados em colaboração com parceiros do setor e são continuamente aprimorados em resposta aos desenvolvimentos do setor e à demanda do consumidor.

O Kit de Certificação de Aplicativos do Windows é usado para validar a conformidade com esses requisitos e substitui o WSLK usado para validação no programa logotipo de software do Windows 7. O Kit de Certificação de Aplicativos do Windows é um dos componentes incluídos no SDK (Software Development Kit) do Windows.

Qualificação do aplicativo

Para que um aplicativo se qualifique para Windows 8 a Certificação de Aplicativos da Área de Trabalho, ele deve atender aos critérios a seguir e a todos os requisitos técnicos listados neste documento.

  • Deve ser um aplicativo autônomo
  • Ele deve ser executado em um computador de Windows 8.1 local
  • Ele pode ser um componente cliente de um aplicativo certificado do Windows Server
  • Ele deve ser o código e o recurso concluídos

1. Os aplicativos são compatíveis e resilientes

Os momentos em que um aplicativo falha ou para de responder causam muita frustração do usuário. Espera-se que os aplicativos sejam resilientes e estáveis e eliminar essas falhas ajuda a garantir que o software seja mais previsível, mantenedível, com desempenho e confiável.

1.1 Seu aplicativo não deve usar uma dependência em modos de compatibilidade do Windows, mensagem AppHelp e ou quaisquer outras correções de compatibilidade
1.2 Seu aplicativo não deve assumir uma dependência no runtime do VB6
1.3 Seu aplicativo não deve carregar DLLs arbitrárias para interceptar chamadas à API win32 usando HKLM\Software\Microsoft\Windows NT\CurrentVersion\Windows AppInit_dlls.

2. Os aplicativos devem seguir as práticas recomendadas de segurança do Windows

Usar as práticas recomendadas de segurança do Windows ajudará a evitar a criação de exposição a superfícies de ataque do Windows. Superfícies de ataque são os pontos de entrada que um invasor mal-intencionado pode usar para explorar o sistema operacional aproveitando as vulnerabilidades no software de destino. Uma das piores vulnerabilidades de segurança é a elevação de privilégios.

2.1 Seu aplicativo deve usar ACLs fortes e apropriadas para proteger arquivos executáveis 2.2 Seu aplicativo deve usar ACLs fortes e apropriadas para proteger diretórios 2.3 Seu aplicativo deve usar ACLs fortes e apropriadas para proteger chaves do Registro 2.4 Seu aplicativo deve usar ACLs fortes e apropriadas para proteger diretórios que contêm objetos 2.5 Seu aplicativo deve reduzir o acesso de não administrador a serviços vulneráveis à violação 2.6 Seu aplicativo deve impedir serviços com rapidez reinicia da reinicialização mais de duas vezes a cada 24 horas
**Observação: o acesso só deve ser concedido às entidades que o exigem.**

O Programa de Certificação de Aplicativos do Windows verificará se as Superfícies de Ataque do Windows não estão expostas verificando se as ACLs e os Serviços são implementados de uma maneira que não coloca o sistema Windows em risco.

3. Os aplicativos dão suporte a recursos de segurança do Windows

O sistema operacional Windows tem muitos recursos que dão suporte à segurança e privacidade do sistema. Os aplicativos devem dar suporte a esses recursos para manter a integridade do sistema operacional. Aplicativos compilados incorretamente podem causar estouros de buffer que podem, por sua vez, causar negação de serviço ou permitir a execução de código mal-intencionado.

3.1 Seu aplicativo não deve usar AllowPartiallyTrustedCallersAttribute (APTCA) para garantir o acesso seguro a assemblies de nome forte
3.2 Seu aplicativo deve ser compilado usando o sinalizador /SafeSEH para garantir a manipulação de exceções seguras
3.3 Seu aplicativo deve ser compilado usando o sinalizador /NXCOMPAT para impedir a execução de dados
3.4 Seu aplicativo deve ser compilado usando o sinalizador /DYNAMICBASE para randomização de layout de espaço de endereço (ASLR)
3.5 Seu aplicativo não deve ler/gravar as seções pe compartilhadas

4. Os aplicativos devem aderir às mensagens do gerenciador de reinicialização do sistema

Quando os usuários iniciam o desligamento, eles geralmente têm um forte desejo de ver o desligamento bem-sucedido; eles podem estar com pressa para sair do escritório e apenas querem que seus computadores desliguem. Os aplicativos devem respeitar esse desejo não bloqueando o desligamento. Embora, na maioria dos casos, um desligamento possa não ser crítico, os aplicativos devem estar preparados para a possibilidade de um desligamento crítico.

4.1 Seu aplicativo deve lidar com desligamentos críticos adequadamente
Em um desligamento crítico, os aplicativos que retornam FALSE para WM_QUERYENDSESSION serão enviados WM_ENDSESSION e fechados, enquanto aqueles que atingirem o tempo limite em resposta a WM_QUERYENDSESSION serão encerrados.

4.2 Um aplicativo gui deve retornar TRUE imediatamente em preparação para uma reinicialização
WM\_QUERYENDSESSION com LPARAM = ENDSESSION\_CLOSEAPP(0x1). Os aplicativos de console podem chamar SetConsoleCtrlHandler para especificar a função que manipulará as notificações de desligamento. Os aplicativos de serviço podem chamar RegisterServiceCtrlHandlerEx para especificar a função que receberá notificações de desligamento.
4.3 Seu aplicativo deve retornar 0 dentro de 30 segundos e desligar
WM\_ENDSESSION com LPARAM = ENDSESSION\_CLOSEAPP(0x1). No mínimo, o aplicativo deve se preparar salvando todos os dados do usuário e declarar as informações necessárias após uma reinicialização.
4.4 Os aplicativos de console que recebem a notificação CTRL\_C\_EVENT devem ser desligados imediatamente 4.5 Os drivers não devem vetar um evento de desligamento do sistema
**Observação: os aplicativos que devem bloquear o desligamento devido a uma operação que não pode ser interrompida devem explicar o motivo para o usuário.** Usar ShutdownBlockReasonCreate para registrar uma cadeia de caracteres que explica o motivo para o usuário. Quando a operação for concluída, o aplicativo deverá chamar ShutdownBlockReasonDestroy para indicar que o sistema pode ser desligado.

5. Os aplicativos devem dar suporte a uma instalação reversível limpo

Uma instalação limpo, reversível, permite que os usuários gerenciem (implantar e remover) aplicativos com êxito em seus sistemas.

5.1 Seu aplicativo deve implementar corretamente uma instalação limpo reversível
Se a instalação falhar, o aplicativo deverá ser capaz de revertê-lo e restaurar o computador para seu estado anterior.

5.2 Seu aplicativo nunca deve forçar o usuário a reiniciar o computador imediatamente
Reiniciar o computador nunca deve ser a única opção no final de uma instalação ou atualização. Os usuários devem ter a oportunidade de reiniciar mais tarde.
5.3 Seu aplicativo nunca deve depender de 8.3 nomes de arquivo curtos (SFN) 5.4 Seu aplicativo nunca deve bloquear a instalação silenciosa/desinstalação 5.5 Seu instalador de aplicativo deve criar as entradas corretas do Registro para permitir detecção e desinstalações bem-sucedidas
Ferramentas de inventário do Windows e ferramentas de telemetria exigem informações completas sobre aplicativos instalados. Se você estiver usando um instalador baseado em MSI, o MSI criará automaticamente as entradas do Registro abaixo. Se você não estiver usando um instalador MSI, o módulo de instalação deverá criar as seguintes entradas do Registro durante a instalação:
  • DisplayName
  • InstallLocation
  • Publisher
  • UninstallString
  • VersionMajor ou MajorVersion
  • VersionMinor ou MinorVersion

6. Os aplicativos devem assinar digitalmente arquivos e drivers

Uma assinatura digital do Authenticode permite que os usuários verifiquem se o software é original. Ele também permite que se detecte se um arquivo foi adulterado, como se tivesse sido infectado por um vírus. A imposição de assinatura de código no modo kernel é um recurso do Windows conhecido como CI (integridade de código), que melhora a segurança do sistema operacional verificando a integridade de um arquivo sempre que a imagem do arquivo é carregada na memória. A CI detecta se o código mal-intencionado modificou um arquivo binário do sistema. Também gera um evento de log de diagnóstico e auditoria do sistema quando a assinatura de um módulo de kernel falha ao verificar corretamente.

6.1 Todos os arquivos executáveis (.exe, .dll, .ocx, .sys, .cpl, .drv, .scr) devem ser assinados com um certificado Authenticode
6.2 Todos os drivers do modo kernel instalados pelo aplicativo devem ter uma assinatura da Microsoft obtida por meio do programa de Certificação de Hardware do Windows. Todos os drivers de filtro do Sistema de Arquivos devem ser assinados pela Microsoft.
6.3 Exceções e renúncias
As renúncias serão consideradas apenas para redistribuíveis de terceiros não assinados, excluindo drivers. É necessária uma prova de comunicação solicitando uma versão assinada dos redistribuíveis para que essa renúncia seja concedida.

7. Os aplicativos não bloqueiam a instalação ou a inicialização de aplicativos com base em uma versão do sistema operacional marcar

É importante que os clientes não sejam artificialmente impedidos de instalar ou executar seu aplicativo quando não houver limitações técnicas. Em geral, se os aplicativos foram gravados para o Windows Vista ou versões posteriores do Windows, eles não devem ter que marcar a versão do sistema operacional.

7.1 Seu aplicativo não deve executar verificações de versão quanto à igualdade
Se você precisar de um recurso específico, marcar se o recurso em si está disponível. Se você precisar do Windows XP, marcar para Windows XP ou posterior (>= 5.1). Dessa forma, seu código de detecção continuará funcionando em versões futuras do Windows. Os instaladores de driver e os módulos de desinstalação nunca devem marcar a versão do sistema operacional.

7.2 Exceções e renúncias serão consideradas para aplicativos que atendem aos critérios abaixo:
  • Aplicativos que são entregues como um pacote que também são executados no Windows XP, Windows Vista e Windows 7 e precisam marcar a versão do sistema operacional para determinar quais componentes instalar em um determinado sistema operacional.
  • Aplicativos que marcar apenas a versão mínima do sistema operacional (somente durante a instalação, não em runtime) usando apenas as chamadas de API aprovadas e que listam corretamente o requisito mínimo de versão no manifesto do aplicativo.
  • Aplicativos de segurança (antivírus, firewall etc.), utilitários do sistema (por exemplo, desfragm, backups e ferramentas de diagnóstico) que marcar a versão do sistema operacional usando apenas as chamadas de API aprovadas.

8. Os aplicativos não carregam serviços ou drivers no modo de segurança

O modo de segurança permite que os usuários diagnosticem e solucionem problemas do Windows. Drivers e serviços não devem ser definidos para serem carregados no modo de segurança, a menos que sejam necessários para operações básicas do sistema, como drivers de dispositivo de armazenamento ou para fins de diagnóstico e recuperação, como scanners antivírus. Por padrão, quando o Windows está no modo de segurança, ele inicia apenas os drivers e serviços que vieram pré-instalados com o Windows.

  • 8.1 Exceções e renúncias
    Drivers e serviços que devem ser iniciados no modo de segurança exigem uma renúncia. A solicitação de renúncia deve incluir cada driver ou gravação de serviço aplicável para as chaves do Registro SafeBoot e descrever os motivos técnicos pelos quais o aplicativo ou serviço deve ser executado no modo de segurança. O instalador de aplicativo deve registrar todos esses drivers e serviços usando essas chaves do Registro:
    - HKLM/System/CurrentControlSet/Control/SafeBoot/Minimal - HKLM/System/CurrentControlSet/Control/SafeBoot/Network

Nota: Você deve testar esses drivers e serviços para garantir que eles funcionem no modo de segurança sem erros.

9. Os aplicativos devem seguir as diretrizes de Controle de Conta de Usuário

Alguns aplicativos do Windows são executados no contexto de segurança de uma conta de administrador, e os aplicativos geralmente solicitam direitos excessivos de usuário e privilégios do Windows. Controlar o acesso aos recursos permite que os usuários estejam no controle de seus sistemas e os protejam contra alterações indesejadas. Uma alteração indesejada pode ser mal-intencionada, como um rootkit assumindo o controle do computador, ou ser o resultado de uma ação feita por pessoas que têm privilégios limitados.. A regra mais importante para controlar o acesso aos recursos é fornecer a menor quantidade de contexto de usuário padrão de acesso necessário para que um usuário execute suas tarefas necessárias. As diretrizes de UAC (controle de conta de usuário) a seguir fornecem ao aplicativo as permissões necessárias quando são necessárias pelo aplicativo, sem deixar o sistema constantemente exposto a riscos de segurança. A maioria dos aplicativos não exige privilégios de administrador em tempo de execução e deve ser apenas uma boa execução como um usuário padrão.

9.1 Seu aplicativo deve ter um manifesto que defina os níveis de execução e informe ao sistema operacional quais privilégios o aplicativo requer para executar
A marcação do manifesto do aplicativo só se aplica a EXEs, não a DLLs. Isso ocorre porque o UAC não inspeciona DLLs durante a criação do processo. Também vale a pena observar que as regras UAC não se aplicam aos Serviços windows. O manifesto pode ser inserido ou externo.
Para criar um manifesto, crie um arquivo com o nome <app_name>.exe.manifest e armazene-o no mesmo diretório que o EXE. Observe que qualquer manifesto externo será ignorado se o aplicativo tiver um manifesto interno. Por exemplo:
<requestedExecutionLevel level=""asInvoker | highestAvailable | requireAdministrator"" uiAccess=""true|false""/>

9.2 O processo de main do aplicativo deve ser executado como um usuário padrão (asInvoker).
Todos os recursos administrativos devem ser movidos para um processo separado que é executado com privilégios administrativos. Os aplicativos voltados para o usuário, como aqueles acessíveis por meio do grupo de programas no Menu Inicial e que exigem elevação, devem ser assinados pelo Authenticode.
9.3 Exceções e renúncias
Uma renúncia é necessária para aplicativos que executam seu processo de main com privilégios elevados (requireAdministrator ou highestAvailable). O processo de main é identificado como o ponto de entrada do usuário para o aplicativo. As renúncias serão consideradas para os seguintes cenários:
  • Ferramentas administrativas ou do sistema com nível de execução definido como mais alto Disponível e/ou requireAdministrator
  • Somente o aplicativo da estrutura de automação de interface do usuário ou acessibilidade define o sinalizador uiAccess como true para ignorar o isolamento de privilégios de interface do usuário (UIPI). Para iniciar corretamente a utilização do aplicativo, esse sinalizador deve ser assinado pela Authenticode e deve residir em um local protegido no sistema de arquivos, ou seja, Arquivos de Programas.

10. Os aplicativos devem ser instalados nas pastas corretas por padrão

Os usuários devem ter uma experiência consistente e segura com o local de instalação padrão dos arquivos, mantendo a opção de instalar um aplicativo no local de sua escolha. Também é necessário armazenar dados do aplicativo no local correto para permitir que várias pessoas usem o mesmo computador sem corromper ou substituir dados e configurações uns dos outros. O Windows fornece locais específicos no sistema de arquivos para armazenar programas e componentes de software, dados de aplicativos compartilhados e dados de aplicativo específicos de um usuário

10.1 Seu aplicativo deve ser instalado na pasta Arquivos de Programas por padrão
Para aplicativos nativos de 32 bits e 64 bits em %ProgramFiles% e %ProgramFiles(x86)% para aplicativos de 32 bits em execução no x64. Os dados do usuário ou os dados do aplicativo nunca devem ser armazenados nesse local devido às permissões de segurança configuradas para essa pasta.

10.2 Seu aplicativo deve evitar iniciar automaticamente na inicialização
Por exemplo, seu aplicativo não deve definir nenhum dos seguintes procedimentos;
  • HKLM de chaves de execução do Registro e, ou HKCU, em Software\Microsoft\Windows\CurrentVersion
  • Chaves de execução do Registro HKLM e ou HKCU em Software\Wow6432Node\Microsoft\windows\CurrentVersion
  • Iniciar Menu AllPrograms > STARTUP
10.3 Seus dados de aplicativo, que devem ser compartilhados entre usuários no computador, devem ser armazenados no ProgramData 10.4 Seus dados do aplicativo que são exclusivos de um usuário específico e que não devem ser compartilhados com outros usuários do computador, devem ser armazenados em Usuários\\<nome de usuário>\\AppData 10.5 Seu aplicativo nunca deve gravar diretamente no diretório "Windows" e ou subdiretórios
Use os métodos corretos para instalar arquivos, como fontes ou drivers.
10.6 Seu aplicativo deve gravar dados do usuário na primeira execução e não durante a instalação em instalações por computador
Quando o aplicativo é instalado, não há um local de usuário correto no qual armazenar dados. As tentativas de um aplicativo de modificar comportamentos de associação padrão em um nível de computador após a instalação não serão bem-sucedidas. Em vez disso, os padrões devem ser reivindicados em um nível por usuário, o que impede que vários usuários substituam os padrões uns dos outros.
10.7 Exceções e renúncias
Uma renúncia é necessária para aplicativos que gravam nos aplicativos .NET do GAC (cache de assembly global) devem manter as dependências de assembly privadas e armazená-la no diretório do aplicativo, a menos que o compartilhamento de um assembly seja explicitamente necessário.

11. Os aplicativos devem dar suporte a sessões de vários usuários

Os usuários do Windows devem ser capazes de executar sessões simultâneas sem conflitos ou interrupções.

11.1 Seu aplicativo deve garantir que, ao executar em várias sessões local ou remotamente, a funcionalidade normal do aplicativo não seja afetada negativamente
11.2 As configurações do aplicativo e os arquivos de dados não devem persistir entre os usuários
11.3 A privacidade e as preferências de um usuário devem ser isoladas para a sessão do usuário
11.4 Suas instâncias do aplicativo devem ser isoladas umas das outras
Isso significa que os dados do usuário de uma instância não são visíveis para outra instância do aplicativo. Som em uma sessão de usuário inativa não deve ser ouvido em uma sessão de usuário ativa. Nos casos em que várias instâncias de aplicativo usam recursos compartilhados, o aplicativo deve garantir que não haja um conflito.

11.5 Os aplicativos instalados para vários usuários devem armazenar dados nas pastas corretas e nos locais do Registro
Consulte os requisitos do UAC.
11.6 Os aplicativos de usuário devem ser capazes de ser executados em várias sessões de usuário (Troca rápida de usuário) para acesso local e remoto 11.7 Seu aplicativo deve marcar outras sessões de TS (serviço de terminal) para instâncias existentes do aplicativo
**Observação:** Se um aplicativo não der suporte a várias sessões de usuário ou acesso remoto, ele deverá declarar isso claramente quando iniciado a partir desse tipo de sessão.

12. Os aplicativos devem dar suporte a versões x64 do Windows

À medida que o hardware de 64 bits se torna mais comum, os usuários esperam que os desenvolvedores de aplicativos aproveitem os benefícios da arquitetura de 64 bits migrando seus aplicativos para 64 bits ou que as versões de 32 bits do aplicativo sejam executadas bem em versões de 64 bits do Windows.

12.1 Seu aplicativo deve dar suporte nativo a 64 bits ou, no mínimo, aplicativos baseados no Windows de 32 bits devem ser executados perfeitamente em sistemas de 64 bits para manter a compatibilidade com versões de 64 bits do Windows
12.2 Seu aplicativo e seus instaladores não devem conter nenhum código de 16 bits ou depender de nenhum componente de 16 bits
12.3 Sua configuração do aplicativo deve detectar e instalar os drivers e componentes adequados para a arquitetura de 64 bits
12.4 Todos os plug-ins de shell devem ser executados em versões de 64 bits do Windows
12.5 O aplicativo em execução sob o emulador WoW64 não deve tentar subverter ou ignorar mecanismos de virtualização Wow64
Se houver cenários específicos em que os aplicativos precisem detectar se estão em execução no emulador WoW64, eles devem fazer isso chamando IsWow64Process.

Conclusão

À medida que esses requisitos evoluem, observaremos as alterações no histórico de revisão abaixo. Requisitos estáveis são essenciais para fazer o seu melhor trabalho, portanto, vamos buscar garantir que as alterações que fazemos sejam sustentáveis e continuem a proteger e aprimorar seus aplicativos.

Obrigado novamente por ingressar em nosso compromisso de oferecer ótimas experiências ao cliente.

Histórico de revisão

Data Versão Descrição da revisão Link para o documento
20 de dezembro de 2011 1,0 Rascunho inicial do documento para Versão Prévia.
26 de janeiro de 2012 1,1 Atualize para a seção nº 2. 1,1

Saiba mais sobre a certificação de aplicativos da área de trabalho

Requisito Descrição Mais detalhes
Compatibilidade e resiliência & Falhas são uma grande interrupção para os usuários e causam frustração. Espera-se que os aplicativos sejam resilientes e estáveis, eliminando essas falhas ajuda a garantir que o software seja mais previsível, mantenedível, de alto desempenho e confiável. Sistemas operacionais Windows Vista, Windows 7 e Windows 8
Verificador de Aplicativos
AppInit DLLs
Aderir às práticas recomendadas de Segurança do Windows Usar as práticas recomendadas de segurança do Windows ajudará a evitar a criação de exposição a superfícies de ataque do Windows. Superfícies de ataque são os pontos de entrada que um invasor mal-intencionado pode usar para explorar o sistema operacional aproveitando as vulnerabilidades no software de destino. Uma das piores vulnerabilidades de segurança é a elevação de privilégio. Analisador de superfície de ataque
Listas de Controle de Acesso
Recursos de suporte Segurança do Windows O sistema operacional Windows implementou muitas medidas para dar suporte à segurança e à privacidade do sistema. Os aplicativos devem dar suporte a essas medidas para manter a integridade do sistema operacional. Aplicativos compilados incorretamente podem causar estouros de buffer que, por sua vez, podem causar negação de serviço ou fazer código mal-intencionado ser executado. Referência da ferramenta BinScope
Aderir às mensagens do Gerenciador de Reinicialização do Sistema Quando os usuários iniciam o desligamento, na grande maioria dos casos, eles têm um forte desejo de ver o desligamento bem-sucedido; eles podem estar com pressa para sair do escritório e "apenas querem" que seus computadores desliguem. Os aplicativos devem respeitar esse desejo não bloqueando o desligamento. Embora, na maioria dos casos, um desligamento possa não ser crítico, os aplicativos devem estar preparados para a possibilidade de um desligamento crítico. Alterações de desligamento do aplicativo no Windows Vista
Desenvolvimento do Gerenciador de Reinicialização
Instalação reversível limpa Uma instalação limpo, reversível, permite que os usuários gerenciem (implantem e removam) aplicativos com êxito em seus sistemas. Como instalar pré-requisitos com um aplicativo ClickOnce
Instalação do aplicativo em sistemas de 64 bits
Assinar arquivos e drivers digitalmente Uma assinatura digital Authenticode permite que os usuários verifiquem se o software é original. Ele também permite detectar se um arquivo foi adulterado, por exemplo, se foi infectado por um vírus. A imposição de assinatura de código no modo kernel é um recurso do Windows conhecido como CI (integridade de código), que melhora a segurança do sistema operacional verificando a integridade de um arquivo sempre que a imagem do arquivo é carregada na memória. A CI detecta se o código mal-intencionado modificou um arquivo binário do sistema. Também gera um evento de log de diagnóstico e auditoria do sistema quando a assinatura de um módulo de kernel falha ao verificar corretamente. Assinaturas digitais para módulos de kernel no Windows
Não bloquear a instalação ou a inicialização do aplicativo com base na versão do sistema operacional marcar É importante que os clientes não sejam artificialmente impedidos de instalar ou executar o aplicativo quando não houver limitações técnicas. Em geral, se os aplicativos foram escritos para o Windows Vista ou versões posteriores, eles não devem ter nenhum motivo para marcar a versão do sistema operacional. Controle de versão do sistema operacional
Não carregar serviços e drivers no modo de segurança O modo de segurança permite que os usuários diagnostiquem e solucionem problemas do Windows. A menos que seja necessário para operações básicas do sistema (por exemplo, drivers de dispositivo de armazenamento) ou para fins de diagnóstico e recuperação (por exemplo, scanners antivírus), os drivers e os serviços não devem ser definidos para serem carregados no modo de segurança. Por padrão, o modo de segurança não inicia a maioria dos drivers e serviços que não vieram pré-instalados com o Windows. Eles devem permanecer desabilitados, a menos que o sistema os exija para operações básicas ou para fins de diagnóstico e recuperação. Determinando se o sistema operacional está em execução no modo de segurança
Siga as diretrizes do UAC (Controle de Conta de Usuário) Alguns aplicativos do Windows são executados no contexto de segurança de uma conta de administrador e muitos exigem direitos de usuário excessivos e privilégios do Windows. Controlar o acesso aos recursos permite que os usuários controlem seus sistemas contra alterações indesejadas (uma alteração indesejada pode ser mal-intencionada, como um rootkit assumir furtivamente o computador ou uma ação de pessoas que têm privilégios limitados, por exemplo, um funcionário instalando software proibido em um computador de trabalho). A regra mais importante para controlar o acesso aos recursos é fornecer a menor quantidade de acesso de contexto de usuário padrão necessário para que um usuário execute suas tarefas necessárias. As diretrizes de UAC a seguir fornecem ao aplicativo as permissões necessárias quando necessário, sem deixar o sistema constantemente exposto a riscos de segurança. Controle de conta de usuário
UAC: Diretrizes de atualização de aplicativo
Instalar as pastas corretas por padrão Os usuários devem ter uma experiência consistente e segura com o local de instalação padrão dos arquivos, mantendo a opção de instalar um aplicativo no local escolhido. Também é necessário armazenar dados do aplicativo no local correto para permitir que várias pessoas usem o mesmo computador sem corromper ou substituir os dados e as configurações uns dos outros. Resumo dos requisitos de instalação/desinstalação
Suporte a sessões de vários usuários Os usuários do Windows devem ser capazes de executar sessões simultâneas sem conflitos ou interrupções. Diretrizes de programação dos Serviços de Área de Trabalho Remota
Suporte a versões x64 do Windows À medida que o hardware de 64 bits se torna mais prevalente, os usuários esperam que os desenvolvedores de aplicativos aproveitem os benefícios da arquitetura de 64 bits migrando seus aplicativos para 64 bits ou que as versões de 32 bits do aplicativo sejam executadas bem em versões de 64 bits do Windows. Compatibilidade de aplicativos: Windows Vista de 64 bits

Confira também