Exportar (0) Imprimir
Expandir Tudo
Expandir Minimizar

Guia de Segurança do Windows Server 2003

Capítulo 2: Mecanismos de proteção do Windows Server 2003

Atualizado em: 27 de dezembro de 2005

Nesta página

Visão geral
Protegendo o sistema com o Assistente de Configuração de Segurança
Protegendo servidores com a Diretiva de Grupo do Active Directory
Visão geral do processo
Resumo

Visão geral

Este capítulo apresenta os mecanismos que podem ser usados para implementar configurações de segurança no Microsoft® Windows Server™ 2003. O Service Pack 1 (SP1) do Windows Server 2003 fornece o Assistente de Configuração de Segurança (ACS), uma nova ferramenta baseada em função que você pode usar para tornar os servidores mais seguros. Quando usado em conjunto com Objetos de Diretiva de Grupo (GPO), o ACS permite maior controle, flexibilidade e uniformidade no processo de proteção.

Este capítulo se concentra nos seguintes tópicos:

  • Como o ACS é usado para criar, testar e instalar diretivas baseadas em função.

  • Como o serviço de diretório do Active Directory® facilita a proteção uniforme da empresa com o uso de GPOs.

  • Como os designs do domínio do Active Directory, da unidade organizacional (UO), da Diretiva de Grupo e do grupo administrativo afetam as implantações de segurança.

  • Como usar tanto o ACS como a Diretiva de Grupo para criar uma abordagem gerenciável baseada em função a fim de proteger servidores que executam o Windows Server 2003 com SP1.

Essas informações fornecem as bases e uma visão que você pode usar para evoluir de um ambiente Cliente Herdado (LC) para um ambiente Segurança Especializada – Funcionalidade Limitada (SSLF) em uma infra-estrutura de domínio.

Protegendo o sistema com o Assistente de Configuração de Segurança

A finalidade do ACS é fornecer um processo flexível, passo a passo, para reduzir a superfície de ataque em servidores que executam o Windows Server 2003 com SP1. O ACS é, na verdade, uma coleção de ferramentas combinada a um banco de dados de regras XML. Seu propósito é ajudar os administradores a determinar rápida e precisamente os recursos mínimos necessários às funções que servidores específicos devem desempenhar.

Com o ACS, os administradores podem criar, testar, solucionar problemas e implantar diretivas de segurança que desativam qualquer funcionalidade dispensável. Ele também possibilita reverter diretivas de segurança. O ACS fornece suporte nativo para gerenciamento de diretivas de segurança em servidores únicos, assim como em grupos de servidores que compartilham uma funcionalidade relacionada.

O ACS é uma ferramenta abrangente que pode ajudá-lo a:

  • Determinar qual serviços precisam estar ativos, quais devem ser executados quando necessário e quais podem ser desativados.

  • Administrar a filtragem de porta de rede em combinação com o Firewall do Windows.

  • Controlar quais extensões da Web do IIS são permitidas para servidores Web.

  • Reduzir a exposição do protocolo aos protocolos baseados em SMB (Server Message Block), NetBIOS, CIFS (Common Internet File System) e LDAP (Lightweight Directory Access Protocol).

  • Criar diretivas de auditoria úteis que capturem os eventos de seu interesse.

Instruções detalhadas sobre como instalar, usar e resolver problemas do ACS estão disponíveis em uma versão de download da documentação do Assistente de Configuração de Segurança em www.microsoft.com/downloads/details.aspx?FamilyID=903fd496-9eb9-4a45-aa00-3f2f20fd6171&displaylang=en (site em inglês).

Observação: o ACS só pode ser usado com o Windows Server 2003 com SP1. Ele não pode ser usado para criar diretivas para Windows 2000 Server, Windows XP ou Windows Small Business Server 2003. A fim de proteger um número considerável de computadores que executam esses sistemas operacionais, será preciso aproveitar os mecanismos de proteção baseados em Diretiva de Grupo, descritos mais adiante neste capítulo.

Criando e testando diretivas

Você pode usar o ACS para criar e testar diretivas de segurança rapidamente em vários servidores ou grupos de servidores a partir de um único computador. Esse recurso permite gerenciar diretivas em toda a empresa a partir de um único local. Essas diretivas fornecem medidas de proteção uniformes, compatíveis e apropriadas às funções desempenhadas pelos diferentes servidores na organização. Se você usar o ACS para criar e testar diretivas, deverá implantá-lo em todos os servidores de destino. Embora você crie a diretiva em uma estação de gerenciamento, o ACS tentará se comunicar com os servidores de destino a fim de inspecionar sua configuração e ajustar a diretiva resultante.

O ACS é integrado aos subsistemas IPsec e Firewall do Windows e, portanto, modificará essas configurações. A menos que seja impedido, o ACS configurará o Firewall do Windows de modo a permitir o tráfego de rede de entrada a portas importantes exigidas pelo sistema operacional ou por aplicativos de escuta. Se filtros de porta adicionais forem necessários, o ACS poderá criá-los. Como resultado, as diretivas criadas pelo ACS atendem à necessidade de scripts personalizados para definir ou modificar filtros IPsec para bloquear o tráfego indesejável. Esse recurso simplifica o gerenciamento da proteção da rede. A configuração de filtros de rede para serviços que utilizam RPC ou portas dinâmicas também pode ser simplificada.

O ACS também fornece a capacidade de personalizar significativamente as diretivas criadas. Essa flexibilidade o ajuda a criar uma configuração que permita a funcionalidade necessária, mas também ajude a reduzir os riscos de segurança. Além dos comportamentos e configurações de linha de base, você pode substituir o ACS nas seguintes áreas:

  • Serviços

  • Portas de rede

  • Aplicativos aprovados para o Firewall do Windows

  • Configurações do Registro

  • Configurações de IIS

  • Inclusão de modelos de segurança preexistentes (arquivos .inf)

O ACS aconselha o administrador sobre algumas das configurações mais importantes do Registro. Para reduzir a complexidade da ferramenta, os designers optaram por incluir somente as configurações que têm maior sobre a segurança. No entanto, este guia discute muitas outras configurações do Registro. A fim de superar as limitações do ACS, você pode combinar modelos de segurança com os resultados do ACS para criar uma configuração mais completa.

Quando você cria uma nova diretiva com o ACS, ele usa a configuração atual de um servidor como configuração inicial. Portanto, use como destino um servidor do mesmo tipo daqueles nos quais pretende implantar a diretiva, de modo que seja possível descrever com precisão a configuração das funções de servidor. Quando você usa a interface gráfica do usuário do ACS para criar uma nova diretiva, ele cria um arquivo XML e o salva na pasta %systemdir%\security\msscw\Policies por padrão. Depois de criar suas diretivas, você pode usar tanto a interface do ACS quanto a ferramenta de linha de comando Scwcmd para aplicá-las aos servidores de teste.

Ao testar as diretivas, pode ser necessário remover uma diretiva implantada. Você pode usar tanto a GUI quanto a ferramenta de linha de comando para reverter a última diretiva aplicada a um servidor ou grupo de servidores. O ACS salva as configurações anteriores em arquivos XML.

Para organizações que contam com recursos limitados para o design e teste de configurações de segurança, o ACS pode ser suficiente. As organizações que não contam com esses recursos não devem sequer tentar proteger os servidores, pois tais esforços geralmente resultam em problemas inesperados e perda de produtividade. Se a sua organização não conta com funcionários experientes e com tempo disponível para lidar com tais problemas, concentre-se em outras atividades importantes relacionadas à segurança, como a atualização de aplicativos e sistemas operacionais e o gerenciamento das atualizações.

Implantando diretivas

Há três opções diferentes que você pode usar para implantar suas diretivas:

  • Aplicar a diretiva com a GUI do ACS

  • Aplicar a diretiva com a ferramenta de linha de comando Scwcmd

  • Converter a diretiva do ACS em um Objeto de Diretiva de Grupo e vinculá-lo a um domínio ou UO

Cada opção tem suas vantagens e desvantagens, descritas nas subseções a seguir.

Aplicar a diretiva com a GUI do ACS

A principal vantagem da GUI do ACS é sua simplicidade. A GUI permite aos administradores selecionar facilmente uma diretiva predefinida e aplicá-la a um único computador.

A desvantagem da GUI do ACS é que ela só permite aplicar diretivas a um único computador de cada vez. Essa opção não comporta as necessidades de ambientes de grande porte e não foi incluída neste guia.

Aplicar a diretiva com a ferramenta de linha de comando Scwcmd

Um meio de aplicar diretivas nativas do ACS a vários computadores sem o Active Directory é usar a ferramenta Scwcmd. Você também pode combinar o uso de Scwcmd com tecnologias de script para fornecer um nível de implantação automatizada de diretiva, talvez como parte de um processo existente usado para criar e implantar servidores.

A principal desvantagem da ferramenta Scwcmd é que ela não é automática. Você precisa especificar a diretiva e o servidor de destino, seja manualmente ou com alguma solução de script, o que potencialmente pode levar ao envio da diretiva errada para o computador errado. Se você tiver servidores em um grupo com configurações ligeiramente diferentes, precisará criar uma diretiva para cada um desses computadores e aplicá-la separadamente. Devido a essas limitações, este guia não usa esse método.

Converter a diretiva do ACS em um Objeto de Diretiva de Grupo

A terceira opção para implantação de diretiva do ACS é usar a ferramenta Scwcmd para converter a diretiva baseada em XML em um Objeto de Diretiva de Grupo (GPO). Ainda que à primeira vista essa conversão pareça ser uma etapa desnecessária, suas vantagens incluem:

  • As diretivas são duplicadas, implantadas e aplicadas com mecanismos familiares do Active Directory.

  • Como são GPOs nativos, as diretivas podem ser usadas com UOs, além de diretiva herdadas e incrementais, para ajustar a proteção de servidores que têm configurações semelhantes, mas não idênticas, àquelas de outros servidores. Com a Diretiva de Grupo, você coloca esses servidores em uma UO filha ou aplica uma diretiva incremental, ao passo que com o ACS você precisaria criar uma nova diretiva para cada configuração exclusiva.

  • As diretivas são aplicadas automaticamente a todos os servidores nas UOs correspondentes. As diretivas nativas do ACS devem ser aplicadas manualmente ou usadas em conjunto com alguma solução de script personalizada.

Protegendo servidores com a Diretiva de Grupo do Active Directory

O Active Directory permite que aplicativos encontrem, usem e gerenciem recursos de diretório em um ambiente de computação distribuído. Embora seja possível escrever um longo e detalhado livro inteiro sobre o design de uma infra-estrutura do Active Directory, esta seção discute brevemente esses conceitos a fim de estabelecer o contexto para o restante do guia. As informações de design são necessárias para esclarecer o uso da Diretiva de Grupo na administração segura dos domínios, dos controladores de domínio e das funções específicas de servidores da organização. Se a organização já tiver um design do Active Directory, este módulo poderá esclarecer alguns de seus benefícios ou possíveis problemas relacionados à segurança.

Este guia não oferece nenhuma orientação específica sobre como proteger o banco de dados do Active Directory. Para obter essa orientação, consulte o documento "Best Practice Guide for Securing Active Directory Installations" mencionado na seção "Mais informações" ao final deste capítulo.

Quando você cria uma infra-estrutura do Active Directory, deve levar em consideração os limites de segurança do ambiente. Se você fizer o planejamento adequado do agendamento de delegação e implementação de segurança, o resultado será um design do Active Directory mais seguro para a organização. Só será preciso reestruturar o design no caso de grandes alterações no ambiente, como uma aquisição ou reorganização.

Limites do Active Directory

Existem vários tipos diferentes de limites no Active Directory. Esses limites definem a floresta, o domínio, a topologia do site e a delegação de permissões, e são automaticamente estabelecidos quando se instala o Active Directory. No entanto, é preciso verificar se os limites de permissões incorporam os requisitos e as diretivas da organização. A delegação de permissões administrativas pode ser flexível o bastante para acomodar os requisitos das diferentes organizações. Por exemplo, para manter um equilíbrio adequado entre funcionalidade administrativa e segurança, você pode dividir os limites de delegação de permissão em limites administrativos e limites de segurança.

Limites de segurança

Os limites de segurança ajudam a definir a autonomia ou o isolamento de diferentes grupos de uma organização. É difícil equilibrar as vantagens e desvantagens entre uma segurança adequada (baseada na definição dos limites comerciais da organização) e a necessidade de se manter um nível uniforme de funcionalidade básica. Para atingir esse equilíbrio, pondere as ameaças contra a organização e as implicações de segurança para a delegação de permissões administrativas e de outras opções relacionadas à arquitetura de rede do ambiente.

A floresta é o verdadeiro limite de segurança do ambiente de rede. Este guia recomenda a criação de florestas separadas para se manter o ambiente protegido contra o comprometimento potencial por administradores de outros domínios. Essa abordagem também ajuda a garantir que o comprometimento de uma floresta não leve automaticamente ao comprometimento de toda a empresa.

Um domínio é um limite de gerenciamento do Active Directory, e não um limite de segurança. Em uma organização de indivíduos bem-intencionados, o limite de domínio fornece o gerenciamento autônomo de serviços e de dados em cada domínio da organização. Infelizmente, quando se trata de segurança, o isolamento não é algo que se consiga facilmente. Por exemplo, um domínio não isola completamente um ataque de um administrador de domínio desonesto. Esse nível de separação só pode ser alcançado no nível da floresta.

Dentro do domínio, a unidade organizacional (UO) fornece outro nível de limite de gerenciamento. As UOs fornecem um meio flexível de agrupar recursos relacionados e delegar acesso de gerenciamento ao pessoal apropriado sem fornecer-lhes a capacidade de gerenciar todo o domínio. Como os domínios, as UOs não são um limite de segurança verdadeiro. Ainda que você possa atribuir permissões a uma UO, todas as UOs no mesmo domínio autenticam recursos com relação aos recursos do domínio e da floresta. Ainda assim, uma hierarquia de UOs bem projetada ajudará no desenvolvimento, implantação e gerenciamento de medidas de segurança eficazes.

Talvez a organização precise considerar o controle administrativo dividido dos serviços e dados no design atual do Active Directory. Um design eficaz do Active Directory requer que você compreenda totalmente os requisitos de autonomia e isolamento tanto dos serviços quanto dos dados de sua organização.

Limites administrativos

Devido à possível necessidade de segmentar serviços e dados, você deve definir os diferentes níveis de administração exigidos. Além de administradores que podem executar serviços exclusivos para a organização, este guia recomenda considerar os seguintes tipos de administradores.

Administradores de serviços

Os administradores de serviços do Active Directory são responsáveis pela configuração e pelo fornecimento do serviço de diretório. Por exemplo, administradores de serviço mantêm servidores de controlador de domínio, controlam definições de configuração de todo o diretório e garantem a disponibilidade do serviço. Os administradores do Active Directory da organização devem ser considerados os administradores de serviços.

Com freqüência, a configuração de serviço do Active Directory é determinada por valores de atributos. Esses valores de atributos correspondem às configurações dos respectivos objetos armazenados no diretório. Conseqüentemente, os administradores de serviços do Active Directory também são administradores de dados. As necessidades da organização podem demandar que você considere outros grupos de administradores de serviços para o design de serviço do Active Directory. Veja alguns exemplos:

  • Um grupo de administração de domínio que seja responsável, principalmente, por serviços de diretório.

    O administrador da floresta escolhe o grupo que administrará cada domínio. Devido ao acesso de nível alto concedido ao administrador de cada domínio, esses administradores devem ser pessoas muito confiáveis. Os administradores de domínio controlam os domínios por meio do grupo Administradores de Domínio e de outros grupos internos.

  • Grupos de administradores que gerenciam o DNS.

    O grupo de administradores do DNS completa o design de DNS e administra a infra-estrutura de DNS. O administrador do DNS gerencia a infra-estrutura de DNS por meio do grupo Administradores DNS.

  • Grupos de administradores que gerenciam as UOs.

    O administrador da UO indica um grupo ou um indivíduo como gerente para cada unidade organizacional. Cada administrador de UO gerencia os dados armazenados na unidade organizacional designada no Active Directory. Esses grupos podem controlar o modo como a administração é delegada e o modo como a diretiva é aplicada a objetos das UOs. Os administradores de UO podem criar novas subárvores e delegar a administração das unidades organizacionais pelas quais são responsáveis.

  • Grupos de administradores que gerenciam servidores de infra-estrutura.

    O grupo responsável pela administração do servidor de infra-estrutura gerencia WINS, DHCP e potencialmente a infra-estrutura de DNS. Em alguns casos, o grupo encarregado do gerenciamento de domínio gerencia a infra-estrutura de DNS, pois o Active Directory é integrado ao DNS e é armazenado e gerenciado nos controladores de domínio.

Administradores de dados

Os administradores de dados do Active Directory gerenciam os dados armazenados no Active Directory ou em computadores associados ao Active Directory. Esses administradores não têm controle algum sobre a configuração ou o fornecimento do serviço de diretório. Os administradores de dados são membros de um grupo de segurança criado pela organização. Às vezes, os grupos de segurança padrão do Windows não são aconselháveis para todas as situações da organização. Portanto, as organizações podem desenvolver seus próprios significados e padrões de nomenclatura de grupos de segurança para melhor atender às necessidades do ambiente. Estas são algumas das tarefas comuns dos administradores de dados:

  • Controlar um subconjunto de objetos no diretório. Com o controle de acesso no nível de atributo herdável, os administradores de dados podem receber o controle de seções muito específicas do diretório, mas não o controle da configuração do serviço propriamente dito.

  • Gerenciar computadores membros no diretório e os dados contidos nesses computadores.

Observação: em muitos casos, os valores de atributo de objetos armazenados no diretório determinam a configuração do serviço do diretório.

Resumindo, permitir que os proprietários das estruturas de diretório e do serviço do Active Directory se associem a uma infra-estrutura de floresta ou de domínio requer que a organização confie em todos os administradores de serviço da floresta e de todos os domínios. Além disso, programas de segurança empresarial devem desenvolver procedimentos e diretivas padrão que realizem verificações dos antecedentes dos administradores. No contexto deste guia de segurança, confiar em administradores de serviço significa:

  • Acreditar que eles levarão em conta, em primeira instância, os interesses da organização. As organizações não deverão se associar a uma floresta ou a um domínio se os proprietários da floresta ou do domínio tiverem motivos legítimos para agir de forma mal-intencionada contra a organização.

  • Acreditar que eles seguirão as práticas recomendadas e restringirão o acesso físico aos controladores de domínio.

  • Compreender e aceitar os riscos para a organização. Esses riscos incluem a possibilidade de haver:

    • Administradores desonestos. Administradores confiáveis podem tornar-se desonestos e abusar de seus privilégios na rede. Um administrador desonesto dentro de uma floresta pode facilmente pesquisar o identificador de segurança (SID) de outro administrador em outro domínio. Em seguida, o administrador desonesto poderá usar uma ferramenta da API (interface de programação de aplicativo), um editor de disco ou um depurador para adicionar o SID roubado à lista Histórico SID de uma conta de seu próprio domínio. Depois que o SID roubado for adicionado ao Histórico SID do usuário, o administrador desonesto terá privilégios administrativos no domínio do SID roubado, além de tê-los em seu próprio domínio.

    • Administradores coagidos. Um administrador confiável pode ser coagido ou obrigado a executar operações que violam a segurança de um computador ou da rede. Um usuário ou administrador pode usar técnicas da engenharia social com os administradores legítimos de um computador, ou até ameaças físicas, entre outros, a fim de obter as informações que precisa para obter acesso ao computador.

Algumas organizações talvez aceitem o risco de violações de segurança realizadas por administradores de serviços desonestos ou coagidos provenientes de outra parte da organização. Essas organizações podem considerar que os benefícios colaborativos e econômicos resultantes de sua participação em uma infra-estrutura compartilhada superam os riscos. No entanto, existem organizações que não aceitam o risco, pois as possíveis conseqüências de uma violação de segurança são muito graves.

Active Directory e Diretiva de Grupo

Embora as UOs proporcionem uma maneira fácil de agrupar computadores, usuários, grupos e outros itens básicos de segurança, elas também fornecem um mecanismo eficiente de segmentar os limites administrativos. Além disso, as UOs fornecem uma estrutura crucial para a implantação de Objetos de Diretiva de Grupo (GPOs), pois podem dividir recursos por necessidade de segurança e permitir o fornecimento de níveis de segurança diferentes a diferentes UOs. O uso das UOs para gerenciar e atribuir diretivas de segurança com base na função do servidor é parte fundamental da arquitetura geral de segurança da organização.

Delegando administração e aplicando Diretivas de Grupo

As unidades organizacionais são recipientes dentro da estrutura de diretórios de um domínio. Esses recipientes podem conter qualquer elemento de segurança no domínio, embora normalmente sejam usados para conter objetos de um tipo específico. Para conceder ou revogar as permissões de acesso à UO de um grupo ou usuário individual, você pode definir listas de controle de acesso (ACLs) específicas na UO, e as permissões serão herdadas por todos os objetos na UO.

Você pode usar uma UO para fornecer privilégios administrativos por função. Por exemplo, um grupo de administradores pode ser responsável pelas UOs de usuário e de grupo, enquanto outro grupo gerencia as UOs que contêm os servidores. Você também pode criar uma UO para conter um grupo de servidores de recursos a ser administrado por outros usuários por um processo denominado delegação de controle. Essa abordagem fornece ao grupo delegado o controle autônomo de uma determinada UO, mas não o isola do restante do domínio.

Provavelmente, os administradores que delegam controle sobre UOs específicas são administradores de serviços. Em um nível mais baixo de autoridade, os usuários que controlam as UOs normalmente são administradores de dados.

Grupos administrativos

Os administradores podem criar grupos administrativos para segmentar clusters de usuários, grupos de segurança ou servidores em recipientes para administração autônoma.

Por exemplo, considere os servidores de infra-estrutura que residem em um domínio. Os servidores de infra-estrutura incluem todos os controladores que não são de domínio e que executam serviços básicos de rede, inclusive servidores que fornecem serviços WINS e DHCP. Geralmente, um grupo de operações ou um grupo de administração de infra-estrutura mantém esses servidores. Você pode usar uma UO para fornecer com facilidade recursos administrativos a esses servidores.

A ilustração a seguir apresenta uma visão geral dessa configuração de UO.

Figura 2.1 Delegação de administração de UO

Figura 2.1 Delegação de administração de UO

Quando o controle da UO de infra-estrutura é delegado ao grupo Admin. de Infra-estrutura, os membros desse grupo têm total controle da UO de infra-estrutura e de todos os servidores e objetos na UO. Esse recurso permite aos membros do grupo proteger as funções de servidor com a Diretiva de Grupo.

Essa abordagem é apenas uma das maneiras de usar as UOs para proporcionar a segmentação administrativa. Para organizações mais complexas, consulte a seção "Mais informações" ao final deste capítulo.

Observação: como o Active Directory é muito dependente do DNS, é prática comum executar o serviço DNS em controladores de domínio. Por padrão, os controladores de domínio são colocados na UO de Controladores de Domínio interna. Os exemplos neste guia seguem essa prática, de modo que a função de servidor de infra-estrutura não inclui o serviço DNS.

Aplicação da Diretiva de Grupo

Use a Diretiva de Grupo e delegue administração para aplicar configurações, direitos e comportamentos específicos a todos os servidores de uma UO. O uso de Diretivas de Grupo em vez de etapas manuais simplifica a atualização de vários servidores com quaisquer alterações adicionais necessárias.

As Diretivas de Grupo são acumuladas e aplicadas na ordem mostrada na ilustração a seguir.

Cc163110.sgfg0202(pt-br,TechNet.10).gif

Figura 2.2 Hierarquia da aplicação de GPOs

Conforme mostra a ilustração, as diretivas são aplicadas primeiro no nível de diretiva local do computador. Depois disso, os GPOs são aplicados no nível do site e no nível do domínio. Se o servidor estiver aninhado em várias UOs, os GPOs existentes na UO de nível mais alto serão aplicados primeiro. O processo de aplicação de GPOs continua de cima para baixo na hierarquia da UO. O último GPO a ser aplicado será no nível da UO filha que contém o objeto de servidor. A ordem de prioridade do processamento da Diretiva de Grupo se estende da UO mais alta (mais afastada da conta de usuário ou computador) para a UO mais baixa (que de fato contém a conta de usuário ou computador).

Lembre-se das seguintes considerações básicas ao aplicar a Diretiva de Grupo:

  • Você deve definir a ordem de aplicação de GPO aos níveis de Diretiva de Grupo com vários GPOs. Se várias diretivas especificarem a mesma opção, a última diretiva aplicada terá precedência.

  • Configure uma Diretiva de Grupo com a opção Não Substituir se não quiser que outros GPOs a substituam. Se você usar o Console de Gerenciamento de Diretiva de Grupo (GPMC) para gerenciar seus GPOs, o nome dessa opção será Imposto.

Configuração do horário

Muitos serviços de segurança, especialmente a autenticação, dependem de um relógio de computador exato para executar seus trabalhos. Você deve assegurar-se de que a hora do computador esteja correta e que todos os servidores usem a mesma fonte de horários. O serviço W32Time do Windows Server 2003 fornece sincronização de horário para computadores baseados no Windows Server 2003 e no Microsoft Windows XP executados em um domínio do Active Directory.

O serviço W32Time sincroniza os relógios dos computadores com o Windows Server 2003 com os controladores de um domínio. Essa sincronização é necessária ao funcionamento correto do protocolo Kerberos e de outros protocolos de autenticação. Para funcionar corretamente, vários componentes da família Windows Server precisam que a hora seja precisa e sincronizada. Se os relógios não estiverem sincronizados nos clientes, o protocolo de autenticação Kerberos poderá negar acesso aos usuários.

Outro importante benefício da sincronização de horários é a correlação de eventos em todos os clientes da empresa. Relógios sincronizados nos clientes do ambiente garantem que você possa analisar corretamente eventos que se sucedem uniformemente nesses clientes em toda a organização.

O serviço W32Time usa o NTP (Network Time Protocol) para sincronizar relógios em computadores que executam o Windows Server 2003. Em uma floresta do Windows Server 2003, o horário é, por padrão, sincronizado da seguinte maneira:

  • O mestre de operações do emulador de PDC (controlador de domínio primário) no domínio raiz da floresta é a fonte de autorização de horário para a organização.

  • Todos os mestres de operação do PDC em outros domínios da floresta seguem a hierarquia de domínios ao selecionarem um emulador de PDC com que sincronizar seus horários.

  • Todos os controladores de domínio em um domínio sincronizam seus horários tendo o mestre de operações do PDC em seus domínios como parceiro de horário interno.

  • Todos os servidores e computadores de mesa clientes membros usam o controlador de domínio autenticador como parceiro de horário interno.

Para garantir que o horário seja exato, o emulador de PDC no domínio raiz da floresta pode ser sincronizado com uma fonte de horário autorizada, como uma fonte de NTP confiável ou um relógio altamente preciso na rede. Observe que essa sincronização de NTP usa o tráfego da porta UDP 123. Antes de sincronizar com um servidor externo, você deve ponderar os benefícios da abertura dessa porta com relação ao risco potencial de segurança.

Além disso, se você sincronizar com um servidor externo sobre o qual não tenha controle, correrá o risco de configurar seus servidores com o horário incorreto. O servidor externo pode estar comprometido ou falsificado por um invasor que queira manipular mal-intencionadamente os relógios em seus computadores. Como explicado anteriormente, o protocolo de autenticação Kerberos exige relógios de computador sincronizados. Se eles não estiverem sincronizados, uma negação de serviço poderá ocorrer.

Gerenciamento do modelo de segurança

Os modelos de segurança são arquivos baseados em texto que você pode usar para aplicar uma configuração de segurança a um computador. Você pode modificar os modelos de segurança com o snap-in Modelos de Segurança do MMC (Console de Gerenciamento da Microsoft) ou com um editor de texto, como o Bloco de Notas. Algumas seções dos arquivos de modelo contêm ACLs específicas escritas em SDDL (Security Descriptor Definition Language). Você pode encontrar mais informações sobre como editar modelos de segurança e SDDL na página "Security Descriptor Definition Language" (em inglês) do Microsoft MSDN® em http://msdn.microsoft.com/library/
en-us/secauthz/security/security_descriptor_definition_language.asp.

Por padrão, os usuários autenticados têm o direito de leitura de todas as configurações em um objeto da Diretiva de Grupo. Portanto, é muito importante armazenar os modelos de segurança de um ambiente de produção em um local seguro que só possa ser acessado pelos administradores que implementam a Diretiva de Grupo. A finalidade não é impedir a exibição de arquivos *.inf, mas impedir que alterações não autorizadas sejam feitas nos modelos de segurança originais.

Todos computadores que executam o Windows Server 2003 armazenam modelos de segurança na pasta local %SystemRoot%\security\templates. Essa pasta não é duplicada entre vários controladores de domínio. Portanto, será necessário designar um local para manter a cópia mestra dos modelos de segurança, de modo a evitar problemas de controle de versão com os modelos. Após ser modificado, o modelo localizado centralmente poderá voltar a ser implantado nos computadores apropriados. Essa abordagem garante que você modifique sempre a mesma cópia dos modelos.

Eventos bem-sucedidos de aplicação de GPO

Ainda que um administrador possa verificar manualmente todas as configurações para garantir que elas tenham sido corretamente aplicadas aos servidores da organização, um evento também deve aparecer no log de eventos para informar ao administrador que a diretiva de domínio foi baixada com êxito em cada um dos servidores. Um evento semelhante ao seguinte deve ser exibido no log do aplicativo com seu número exclusivo de identificação de evento:

Tipo: Informação

Identificação da origem: SceCli

Identificação do evento: 1704

Descrição: A diretiva de segurança nos objetos de diretiva de grupo foi aplicada com êxito.

Por padrão, as configurações de segurança são atualizadas a cada 90 minutos em estações de trabalho e servidores e a cada 5 minutos em controladores de domínio. Você verá esse tipo de evento se alguma alteração ocorrer entre esses intervalos. Além disso, as configurações são atualizadas a cada 16 horas, independentemente de alterações terem sido feitas ou não. Você também pode forçar manualmente a atualização das configurações de Diretiva de Grupo usando o procedimento descrito mais adiante neste capítulo.

Unidades organizacionais de funções de servidor

O exemplo anterior mostrou uma maneira de gerenciar os servidores de infra-estrutura de uma organização. Esse método pode ser ampliado de forma a abranger outros servidores e serviços na organização. Os objetivos são criar uma Diretiva de Grupo homogênea para todos os servidores e garantir que os servidores que residem no Active Directory atendam aos requisitos de segurança do ambiente.

Esse tipo de Diretiva de Grupo forma uma linha de base uniforme de configurações padrão para todos os servidores na organização. Além disso, a estrutura da UO e a aplicação de Diretivas de Grupo devem fornecer um design detalhado a fim de oferecer configurações de segurança para tipos específicos de servidores em uma organização. Por exemplo, serviços de IIS (Internet Information Server), de arquivos, de impressão, IAS (Serviço de Autenticação da Internet) e Serviços de Certificados são algumas das funções de servidor em uma organização que podem exigir Diretivas de Grupo exclusivas.

Importante: para simplificar, os exemplos neste capítulo pressupõem o uso do ambiente Cliente Corporativo. Caso esteja usando um dos outros dois ambientes, substitua os nomes de arquivo apropriados. As diferenças entre os três ambientes e sua funcionalidade são discutidas no Capítulo 1, "Introdução ao Guia de Segurança do Windows Server 2003".

Diretiva de Linha de Base de Servidor Membro

A primeira etapa para estabelecer UOs de função do servidor é criar uma diretiva de linha de base. Para criar tal diretiva, você pode usar o ACS em um servidor membro padrão para criar um arquivo de linha de base de servidor membro no formato .xml. Como parte da criação desse xml, use o ACS para incluir um dos modelos de segurança de Linha de Base de Servidor Membro fornecidos (LC-Member Server Baseline.inf, EC-Member Server Baseline.inf ou SSLF-Member Server Baseline.inf).

Depois que você gera a diretiva do ACS, esta é convertida em um GPO e vinculada à UO Servidores Membro. Esse novo GPO de linha de base aplicará as configurações da Diretiva de Grupo de linha de base a quaisquer servidores na UO Servidores Membro, assim como a quaisquer servidores em UOs filhas. A Diretiva de Linha de Base de Servidor Membro é discutida no Capítulo 4, "A diretiva de linha de base de servidor membro".

Você deve definir as configurações desejadas para a maioria dos servidores na organização na Diretiva de Grupo de linha de base. Embora existam alguns servidores que não devem receber a diretiva de linha de base, seu número não deve ser elevado. Se você criar sua própria Diretiva de Grupo de linha de base, torne-a tão restritiva quanto possível e segmente os servidores que precisem diferir dessa diretiva em UOs separadas específicas ao servidor.

Tipos de função do servidor e unidades organizacionais

Cada função de servidor identificada requer uma diretiva de ACS, um modelo de segurança e uma UO adicionais, além da UO de linha de base. Essa abordagem permite a criação de diretivas separadas para as alterações incrementais necessárias a cada função.

Em um exemplo anterior, os servidores de infra-estrutura foram colocados na UO Infra-estrutura, que é filha da UO Servidores Membro. A próxima etapa é aplicar a configuração apropriada a esses servidores. Três modelos de segurança são fornecidos com esta solução, um para cada ambiente de segurança: LC-Infrastructure Server.inf, EC-Infrastructure Server.inf e SSLF-Infrastructure Server.inf. Quando usados junto com o ACS, esses modelos de segurança o ajudarão a criar uma diretiva de segurança que contém os ajustes específicos necessários ao DHCP e WINS. A diretiva resultante é então convertida em um novo GPO e vinculada à UO Infra-estrutura.

Esse GPO usa a configuração Grupos restritos para adicionar os seguintes três grupos ao grupo Administradores locais de todos os servidores na UO Infra-estrutura:

  • Administradores de domínio

  • Administradores de empresa

  • Administradores de infra-estrutura

Como mencionado anteriormente neste capítulo, essa abordagem é apenas uma entre muitas maneiras de se criar uma estrutura de UO a ser usada para implantar GPOs. Para obter mais informações sobre como criar UOs para a implementação de Diretiva de Grupo, consulte "Designing the Active Directory Structure" (em inglês) e tópicos relacionados em www.microsoft.com/resources/documentation/Windows/2000/server/reskit/
en-us/deploy/dgbd_ads_heqs.asp?frame=true.

A tabela a seguir lista as funções do servidor Windows Server 2003 e os arquivos de modelo correspondentes definidos neste guia. Os nomes de arquivo dos modelos de segurança apresentam como prefixo a variável <Env>, substituída por LC (para Cliente Herdado), EC (para Cliente Corporativo), ou SSLF (para Segurança Especializada – Funcionalidade Limitada) conforme apropriado.

Tabela 2.1 Funções de servidor do Windows Server 2003

Função de servidor

Descrição

Nome do arquivo de modelo de segurança

Servidor membro

Todos os servidores que são membros do domínio e residem na UO Servidores Membro ou abaixo dela.

<Env>-Member Server Baseline.inf

Controlador de domínio

Todos os controladores de domínio do Active Directory. Esses servidores também são servidores DNS.

<Env>-Domain Controller.inf

Servidor de infra-estrutura

Todos os servidores WINS e DHCP bloqueados.

<Env>-Infrastructure Server.inf

Servidor de arquivos

Todos os servidores de arquivos bloqueados.

<Env>-File Server.inf

Servidor de impressão

Todos os servidores de impressão bloqueados.

<Env>-Print Server.inf

Servidor Web

Todos os servidores Web IIS bloqueados.

<Env>-Web Server.inf

Servidor IAS

Todos os servidores IAS bloqueados.

<Env>-IAS Server.inf

Servidor de Serviços de Certificados

Todos os servidores de autoridades de certificação bloqueados.

<Env>-CA Server.inf

Host bastião

Todos os servidores voltados para a Internet.

<Env>-Bastion Host.inf

Todos os arquivos de modelo, com exceção daqueles para os servidores de host bastião, são aplicados às UOs filhas correspondentes. Cada uma dessas UOs filhas requer a aplicação da configuração específica para definir a função que cada computador desempenhará na organização.

Os requisitos de segurança para cada uma dessas funções de servidor são diferentes. As configurações de segurança apropriadas para cada função serão discutidas em detalhes em capítulos posteriores. Observe que nem todas as funções têm modelos que correspondem a todos os ambientes. Por exemplo, considera-se que a função de host bastião esteja sempre no ambiente SSLF.

Importante: este guia pressupõe que os computadores que executam o Windows Server 2003 executarão funções especificamente definidas. Caso os servidores de sua organização não correspondam a essas funções ou você tenha servidores multifuncionais, use as configurações definidas aqui como diretrizes para seus próprios modelos de segurança. Porém, lembre-se que quanto mais funções o servidor desempenhar, mais vulnerável ele será a ataques.

Um exemplo de design final da UO para oferecer suporte às funções de servidor definidas no ambiente EC é mostrado na ilustração a seguir.

Cc163110.sgfg0203(pt-br,TechNet.10).gif

Figura 2.3 Exemplo de design de UO

Design de UO, GPO e Grupo

As UOs e diretivas recomendadas discutidas na seção anterior criam uma linha de base ou um novo ambiente para recriar a estrutura de UO existente para computadores que executam o Windows Server 2003. Os administradores usam seus limites de administração predefinidos para criar seus respectivos grupos administrativos. A ilustração a seguir mostra um exemplo de correlação entre esses grupos e as UOs que eles gerenciam.

Tabela 2.2 UOs e Grupos Administrativos

Nome da UO

Grupo administrativo

Controladores de domínio

Engenharia de domínio

Servidores membro

Engenharia de domínio

Infra-estrutura

Administradores de infra-estrutura

Arquivo

Administradores de infra-estrutura

Imprimir

Administradores de infra-estrutura

IAS

Engenharia de domínio

Web

Serviços da Web

CA

Administradores de empresa

Cada grupo administrativo foi criado como um grupo global do domínio pelos membros da Engenharia de domínio, que são responsáveis pela infra-estrutura e segurança do Active Directory. Eles usaram o GPO correspondente para adicionar cada um desses grupos administrativos ao grupo restrito apropriado. Os grupos administrativos listados na tabela serão membros somente do grupo Administradores locais dos computadores localizados nas UOs que especificamente contêm computadores relacionados às suas funções.

Por fim, os membros da Engenharia de domínio definem permissões em cada GPO de forma que apenas os administradores nesse grupo possam editá-los.

Observe que a criação e a configuração desses grupos faz parte do design geral do Active Directory e do processo de implementação. Não faz parte deste guia.

Visão geral do processo

Este guia combina as vantagens das abordagens baseadas no ACS e na Diretiva de Grupo. Essa abordagem híbrida permite criar e testar configurações de segurança mais facilmente, mas ainda fornece a flexibilidade e a escalabilidade necessárias a grandes redes do Windows.

Este é processo usado para criar, testar e implantar as diretivas:

  1. Crie o ambiente do Active Directory, inclusive grupos e UOs. Crie os grupos administrativos apropriados e delegue permissões de UO aos grupos correspondentes.

  2. Configure a sincronização de horário no controlador de domínio que hospeda o FSMO do Emulador PDC.

  3. Configure as diretivas de domínio.

  4. Crie as diretivas de linha de base com o ACS.

  5. Teste as diretivas de linha de base com o ACS.

  6. Converta as diretivas de linha de base em GPOs e vincule-as aos GPOs apropriados.

  7. Crie as diretivas de função com o ACS e os modelos de segurança incluídos.

  8. Teste as diretivas de função com o ACS.

  9. Converta as diretivas de função em GPOs e vincule-as aos GPOs apropriados.

As seções a seguir descrevem essas etapas em detalhes.

Observação: para simplificar, os exemplos neste capítulo supõem o uso do ambiente Cliente Corporativo (EC). Caso esteja usando um dos outros dois ambientes, substitua os nomes de arquivo apropriados. As diferenças entre os três ambientes e sua funcionalidade são discutidas no Capítulo 1, "Introdução ao Guia de Segurança do Windows Server 2003".

Criar o ambiente do Active Directory

Antes de poder iniciar o processo de proteção, você deve ter uma estrutura de domínio e de UOs do Active Directory funcionando. O procedimento a seguir lista as etapas da criação das UOs e grupos usados neste guia, e da sua configuração para o acesso administrativo apropriado.

  1. Abra o snap-in Usuários e Computadores do Active Directory do MMC (Dsa.msc).

  2. Na raiz do objeto de domínio, crie uma UO chamada Servidores Membro.

  3. Navegue para essa nova UO e crie nela uma UO filha chamada Infra-estrutura.

  4. Mova todos os servidores WINS e DHCP para a UO Infra-estrutura.

  5. Crie um grupo global de segurança denominado Administradores de Infra-estrutura e adicione a ele as contas de domínio apropriadas.

  6. Execute o Assistente para delegação de controle para conceder o controle total da UO ao grupo Administradores de Infra-estrutura.

  7. Repita as etapas 3 a 6 para as funções de servidor de arquivos, de impressão, Web, IAS e de Serviços de Certificados. Use as informações na Tabela 2.2 para obter os dados das UO e dos grupos apropriados.

Configurar a sincronização de horário

O procedimento a seguir garante que os controladores de domínio e os servidores membro estejam sincronizados com uma fonte externa de horário. Essa sincronização ajudará a garantir que a autenticação Kerberos funcione corretamente e permitirá manter o domínio do Active Directory sincronizado com quaisquer computadores externos.

  1. No controlador de domínio com o FSMO do Emulador de PDC, abra um prompt de comando e execute o comando a seguir, onde <PeerList> é uma lista de nomes DNS ou endereços IP das fontes de horário desejadas, separados por vírgulas:

    
    w32tm /config /syncfromflags:manual /manualpeerlist:<PeerList>
    
  2. Para atualizar a configuração, execute o seguinte comando:

    
    w32tm /config /update
    
  3. Verifique o log de eventos. Se o computador não puder alcançar os servidores, o procedimento falhará e uma entrada será gravada no log de eventos.

O uso mais comum desse procedimento é a sincronização da fonte de horário com autorização da rede interna com uma fonte de horário externa bastante precisa. No entanto, esse procedimento pode ser executado em qualquer computador com Windows XP ou membro da família Windows Server 2003. Normalmente, não é necessário sincronizar o relógio de todos os servidores com uma fonte externa que estiverem sincronizados com a mesma fonte interna. Por padrão, os computadores membro sempre sincronizam seus relógios com os controladores de domínio.

Observação: para garantir a análise exata dos logs, sincronize também os relógios de computadores de rede que executam sistemas operacionais que não sejam o Windows com o emulador de PDC do Windows Server 2003 ou com a mesma fonte de horário desse servidor.

Configurar a Diretiva de Domínio

O procedimento a seguir importa os modelos de segurança que acompanham este guia para a diretiva de nível de domínio. Essa diretiva é fornecida como um modelo de segurança, visto que o ACS não lida com diretivas de domínio. Antes de você implementar o procedimento a seguir, o arquivo (.inf) de diretiva específico deve estar localizado no computador.

Aviso: os modelos de segurança deste guia foram criados para aumentar a segurança do ambiente. É bastante provável que a sua instalação cause a perda de alguma funcionalidade no ambiente, além da falha de aplicativos críticos.

É essencial que você teste minuciosamente essas configurações antes de implantá-las em um ambiente de produção. Faça backup de todos os controladores de domínio e servidores do ambiente antes de aplicar novas configurações de segurança. Certifique-se de que o estado do sistema esteja incluído no backup, o que permitirá a restauração das configurações do Registro e dos objetos do Active Directory, se necessário.

Para importar os modelos de segurança de Diretiva de Domínio

  1. Em Usuários e Computadores do Active Directory, clique com o botão direito do mouse no domínio e selecione Propriedades.

  2. Na guia Diretiva de Grupo, clique em Novo para adicionar um novo GPO.

  3. Digite EC-Diretiva de Domínio e pressione ENTER.

  4. Clique com o botão direito do mouse em EC-Diretiva de Domínio e selecione Não Substituir.

  5. Selecione E-Diretiva de Domínio e clique em Editar.

  6. Na janela Editor de objeto de diretiva de grupo, clique em Configuração do computador\Configurações do Windows. Clique com o botão direito do mouse em Configurações de segurança e selecione Importar Diretiva.

  7. Na caixa de diálogo Importar diretiva de, navegue até "\Tools and Templates\Security Guide\Security Templates" e clique duas vezes em EC-Domain.inf.

  8. Feche a Diretiva de Grupo que foi modificada.

  9. Feche a janela Propriedades do Domínio.

  10. Se não quiser esperar pela aplicação agendada da Diretiva de Grupo, você poderá iniciar o processo manualmente. Para isso:

    • Abra um prompt de comando, digite gpupdate /Force e pressione ENTER.

  11. Verifique no log de eventos se a Diretiva de Grupo foi baixada com êxito e se o servidor pode se comunicar com os outros controladores do domínio.

Aviso: ao criar a Diretiva de Domínio do Cliente Corporativo, verifique se a opção Não Substituir está habilitada para que essa diretiva seja aplicada em todo o domínio. Essa Diretiva de Grupo é a única neste guia em que a opção Não Substituir deve ser ativada. Não habilite essa opção em nenhuma outra Diretiva de Grupo especificada neste guia. Além disso, não modifique a diretiva de domínio padrão do Windows Server 2003, pois talvez você precise retornar às configurações padrão.

Para garantir que essa nova Diretiva de Grupo tenha prioridade sobre a diretiva padrão, posicione-a de modo a receber a prioridade mais alta entre os links do GPO.

Importante: importe essa Diretiva de Grupo para quaisquer domínios adicionais na organização para garantir a aplicação uniforme da diretiva de senha. No entanto, não é difícil encontrar ambientes em que a diretiva de senha do domínio raiz seja muito mais rígida do que as dos outros domínios. Garanta também que todos os outros domínios que usarão essa diretiva tenham os mesmos requisitos comerciais. Como a diretiva de senha só pode ser definida no nível de domínio, talvez haja requisitos legais ou de negócios que segmentem alguns usuários em um domínio separado, simplesmente para impor o uso de uma diretiva de senha mais estrita nesse grupo.

Para limpar a opção de permissões herdáveis

Por padrão, a nova estrutura de UO herdará muitas configurações de segurança de seu recipiente pai. Para cada UO, limpe a caixa de seleção Permitir que as permissões herdáveis do pai sejam propagadas a este objeto e a todos os objetos filho.

  1. Abra Usuários e Computadores do Active Directory.

  2. Clique em Exibir e em Recursos avançados para selecionar a exibição Avançado.

  3. Clique com o botão direito do mouse na UO apropriada e clique em Propriedades.

  4. Clique na guia Segurança e no botão Avançado.

  5. Limpe a caixa de seleção Permitir que as permissões herdáveis do pai sejam propagadas a este objeto e a todos os objetos filho. Incluí-las nas entradas especificamente definidas aqui.

Remova todos os grupos desnecessários adicionados previamente pelos administradores e adicione o grupo de domínio que corresponde a cada UO de função de servidor. Mantenha a configuração Controle Total para o grupo Administradores de Domínio.

Criar as diretivas de linha de base manualmente usando o ACS

A próxima etapa é usar o ACS para criar a diretiva de linha de base de servidor membro.

Use uma nova instalação do sistema operacional para começar seu trabalho de configuração, o que ajuda a garantir que não haja configurações ou software herdados de configurações anteriores. Se possível, use hardware semelhante àquele usado na implantação a fim de ajudar a garantir tanta compatibilidade quanto possível. A nova instalação é chamada computador de referência.

Durante as etapas de criação da diretiva de linha de base de servidor membro (MSBP), observe que você remove a função de servidor de arquivos da lista de funções detectadas. Essa função é geralmente configurada em servidores que não a exigem e pode ser considerada um risco à segurança. A fim de ativar a função de servidor de Arquivos em servidores que a requeiram, aplique uma segunda diretiva mais tarde neste processo.

Para criar a diretiva de Linha de Base de Servidor Membro

  1. Crie uma nova instalação do Windows Server 2003 com SP1 em um novo computador de referência.

  2. Instale o componente de Assistente de Configuração de Segurança no computador usando Painel de Controle, Adicionar ou Remover Programas, Adicionar/Remover Componentes do Windows.

  3. Adicione o computador ao domínio.

  4. Instale apenas os aplicativos obrigatórios que devam constar de cada servidor no ambiente. Exemplos incluem agentes de gerenciamento e de software, agentes de backup em fita e utilitários antivírus ou antispyware.

  5. Inicie o ACS, selecione Criar nova diretiva e aponte para o computador de referência.

  6. Remova a função de servidor de Arquivos da lista de funções detectadas.

  7. Assegure-se de que os recursos de cliente detectados sejam apropriados para o ambiente.

  8. Assegure-se de que as opções administrativas detectadas sejam apropriadas para o ambiente.

  9. Assegure-se de que quaisquer serviços adicionais necessários à linha de base, como agentes de backup ou software antivírus, sejam detectados.

  10. Decida como lidar com serviços não especificados no ambiente. Para obter segurança extra, você pode definir essa configuração como Desativar. Teste esta configuração antes de implantá-la na rede de produção, visto que ela poderá causar problemas se seus servidores de produção executarem serviços adicionais que não sejam duplicados no computador de referência.

  11. Revise as configurações de rede e verifique se as portas e aplicativos apropriados foram detectados e serão configurados como exceções para o Firewall do Windows.

  12. Pule a seção "Configurações do Registro".

  13. Pule a seção "Diretiva de Auditoria".

  14. Inclua o modelo de segurança apropriado (por exemplo, EC – Linha de Base de Servidor Membro.inf).

  15. Salve a diretiva com um nome apropriado (por exemplo, Linha de Base de Servidor Membro.xml).

Para criar a diretiva Controlador de Domínio

Você deve usar um computador configurado como controlador de domínio para criar a diretiva Controlador de Domínio. É possível usar um controlador de domínio existente ou criar um computador de referência e usar a ferramenta Dcpromo para transformar o computador em um controlador de domínio. No entanto, a maioria das organizações não quer adicionar um controlador de domínio ao seu ambiente de produção, visto que isso pode transgredir sua diretiva de segurança. Caso esteja usando um controlador de domínio existente, não aplique a ele nenhuma configuração com o ACS nem modifique sua configuração.

  1. Instale o componente de Assistente de Configuração de Segurança no computador usando Painel de Controle, Adicionar ou Remover Programas, Adicionar/Remover Componentes do Windows.

  2. Instale apenas os aplicativos obrigatórios que devam constar de cada servidor no ambiente. Exemplos incluem agentes de gerenciamento e de software, agentes de backup em fita e utilitários antivírus ou antispyware.

  3. Inicie a GUI do ACS, selecione Criar nova diretiva e aponte para o computador de referência.

  4. Assegure-se de que as funções detectadas sejam apropriadas para o ambiente.

  5. Assegure-se de que os recursos de cliente detectados sejam apropriados para o ambiente.

  6. Assegure-se de que as opções administrativas detectadas sejam apropriadas para o ambiente.

  7. Assegure-se de que quaisquer serviços adicionais necessários à linha de base, como agentes de backup ou software antivírus, sejam detectados.

  8. Decida como lidar com serviços não especificados no ambiente. Para obter segurança extra, você pode definir essa configuração de diretiva como Desativar. Teste esta configuração antes de implantá-la na rede de produção, visto que ela poderá causar problemas se seus servidores de produção executarem serviços adicionais que não sejam duplicados no computador de referência.

  9. Revise as configurações de rede e verifique se as portas e aplicativos apropriados foram detectados e serão configurados como exceções para o Firewall do Windows.

  10. Pule a seção "Configurações do Registro".

  11. Pule a seção "Diretiva de Auditoria".

  12. Inclua o modelo de segurança apropriado (por exemplo, EC - Controlador de Domínio.inf).

  13. Salve a diretiva com um nome apropriado (por exemplo, Controlador de Domínio.xml).

Testar as diretivas de linha de base com o ACS

Depois que as diretivas de linha de base tiverem sido criadas e salvas, a Microsoft recomenda enfaticamente sua implantação no ambiente de teste. Idealmente, os servidores de teste terão as mesmas configurações de hardware e software que os servidores de produção. Essa abordagem permitirá localizar e corrigir problemas potenciais, como a presença de serviços inesperados exigidos por dispositivos de hardware específicos.

Há duas opções disponíveis para o teste das diretivas. É possível usar os recursos de implantação do ACS ou implantar as diretivas por meio de um GPO.

Ao começar a produzir suas diretivas, considere o uso dos recursos de implantação nativos ao ACS. É possível usar o ACS para enviar as diretivas para um único servidor de cada vez, ou usar Scwcmd para enviá-las para um grupo de servidores. O método nativo de implantação oferece como vantagem a capacidade de reverter facilmente as diretivas implantadas do ACS. Esse recurso pode ser muito útil quando várias alterações são feitas às diretivas durante o processo de teste.

As diretivas são testadas para se garantir que sua aplicação aos servidores de destino não afetarão negativamente as funções críticas. Depois de aplicar as alterações à configuração, comece a verificar a funcionalidade central do computador. Por exemplo, se o servidor estiver configurado como uma autoridade de certificação (CA), verifique se os clientes podem solicitar e obter certificados, baixar uma lista de revogação de certificados, e assim por diante.

Quando estiver seguro quanto às configurações da diretiva, use Scwcmd, conforme mostrado no procedimento a seguir, para converter as diretivas em GPOs.

Para obter informações mais detalhadas sobre como testar diretivas do ACS, consulte o "Guia de Implantação do Assistente de Configuração de Segurança" em www.microsoft.com/technet/prodtechnol/windowsserver2003/
library/SCWDeploying/5254f8cd-143e-4559-a299-9c723b366946.mspx  (site em inglês) e a versão de download da Security Configuration Wizard Documentation em http://go.microsoft.com/fwlink/?linkid=43450 (site em inglês).

Converter as Diretivas de Linha de Base em GPOs

Depois de testar rigorosamente as diretivas de linha de base, siga estas etapas para convertê-las em GPOs e vinculá-las às UOs apropriadas:

  1. Em um prompt de comando, digite o seguinte:

    
    scwcmd transform /p:<PathToPolicy.xml> /g:<GPODisplayName>
    

    e, em seguida, pressione ENTER. Por exemplo:

    
    scwcmd transform /p:"C:\Windows\Security\msscw\Policies\Infrastructure.xml" 
    /g:"Infrastructure Policy"
    

    Observação: as informações a serem inseridas no prompt de comando estão exibidas aqui em mais de uma linha devido às limitações de exibição. Essas informações devem ser inseridas em uma única linha.

  2. Use o Console de Gerenciamento de Diretiva de Grupo para vincular o GPO recém-criado à UO apropriada.

Observe que se o arquivo de diretiva de segurança do ACS contiver configurações do Firewall do Windows, o Firewall do Windows deverá estar ativo no computador local para que esse procedimento seja concluído com êxito. Para verificar se o Firewall do Windows está ativo, abra o Painel de Controle e, em seguida, clique duas vezes em Firewall do Windows.

Agora é preciso executar um teste final para verificar se o GPO aplica as configurações desejadas. Para completar esse procedimento, verifique se as configurações apropriadas foram feitas e se a funcionalidade não foi afetada.

Criar as diretivas de função usando o ACS

A próxima etapa é usar o ACS para criar as diretivas de função de cada função de servidor.

As etapas para criar as diretivas específicas à função são semelhantes àquelas para a criação da MSBP. Mais uma vez, use um computador de referência para ajudar a garantir que não haja nenhuma configuração herdada ou software de configurações anteriores.

Para criar as diretivas de função

  1. Crie uma nova instalação do Windows Server 2003 com SP1 em um novo computador de referência.

  2. Instale o componente de Assistente de Configuração de Segurança no computador usando Painel de Controle, Adicionar ou Remover Programas, Adicionar/Remover Componentes do Windows.

  3. Adicione o novo servidor ao domínio.

  4. Instale os aplicativos obrigatórios que devam constar de cada servidor no ambiente. Exemplos incluem agentes de gerenciamento e de software, agentes de backup em fita e utilitários antivírus ou antispyware.

  5. Configure as funções apropriadas para o computador. Por exemplo, se os servidores de destino executarão DHCP e WINS, instale esses componentes. Eles não precisam ser configurados exatamente como os servidores implantados, mas as funções devem ser instaladas.

  6. Inicie o ACS.

  7. Selecione Criar nova diretiva e aponte para o computador de referência.

  8. Assegure-se de que as funções detectadas sejam apropriadas para o ambiente.

  9. Assegure-se de que os recursos de cliente detectados sejam apropriados para o ambiente.

  10. Assegure-se de que as opções administrativas detectadas sejam apropriadas para o ambiente.

  11. Assegure-se de que quaisquer serviços adicionais necessários à linha de base, como agentes de backup ou software antivírus, sejam detectados.

  12. Decida como lidar com serviços não especificados no ambiente. Para obter segurança extra (e funcionalidade reduzida), você pode definir essa configuração de diretiva como Desativar, o que desativará qualquer novo serviço que não tenha sido explicitamente permitido pelo ACS. Teste esta configuração antes de implantá-la na rede de produção, visto que ela poderá causar problemas se seus servidores de produção executarem serviços adicionais que não sejam duplicados no computador de referência.

  13. Confirme todas alterações de serviço listadas.

  14. Revise as configurações de rede e assegure-se de que o ACS tenha detectado as portas e aplicativos apropriados a serem configurados como exceções para o Firewall do Windows.

  15. Pule a seção "Configurações do Registro".

  16. Pule a seção "Diretiva de Auditoria".

  17. Se o servidor estiver configurado com a função de servidor Web, siga as etapas na seção “Serviços de Informações da Internet” para assegurar-se de que o ACS esteja configurado de forma a oferecer suporte aos recursos IIS necessários.

  18. Clique em Incluir Modelos de Segurança para adicionar o modelo de segurança apropriado.

  19. Salve a diretiva com um nome apropriado.

Testar as diretivas de função usando o ACS

Assim como acontece com as diretivas de linha de base, há duas maneiras diferentes de testar as diretivas. É possível usar os recursos nativos de implantação do ACS ou implantar as diretivas por meio de GPOs. Mais uma vez, a Microsoft recomenda enfaticamente a implantação das diretivas de função em um ambiente de teste antes de seu uso na produção. Essa abordagem ajudará a reduzir o tempo de inatividade e as falhas no ambiente de produção. Depois de testar rigorosamente a nova configuração, você pode converter as diretivas em GPOs, conforme mostrado no procedimento a seguir, e aplicá-los à UO apropriada.

Converter as diretivas de função em GPOs

Depois de testar rigorosamente as diretivas de função, siga estas etapas para convertê-las em GPOs e vinculá-las às UOs apropriadas:

  1. Em um prompt de comando, digite o seguinte:

    
    scwcmd transform /p:<PathToPolicy.xml> /g:<GPODisplayName>
    

    e, em seguida, pressione ENTER. Por exemplo:

    
    scwcmd transform /p:"C:\Windows\Security\msscw\Policies\Infrastructure.xml" 
    /g:"Infrastructure Policy"
    

    Observação: as informações a serem inseridas no prompt de comando estão exibidas aqui em mais de uma linha devido às limitações de exibição. Essas informações devem ser inseridas em uma única linha.

  2. Use o Console de Gerenciamento de Diretiva de Grupo para vincular o GPO recém-criado à UO apropriada e certifique-se de movê-lo acima da diretiva padrão de controladores de domínio de modo que ele receba a prioridade mais alta.

Observe que se o arquivo de diretiva de segurança do ACS contiver configurações do Firewall do Windows, o Firewall do Windows deverá estar ativo no computador local para que esse procedimento seja concluído com êxito. Para verificar se o Firewall do Windows está ativo, abra o Painel de Controle e, em seguida, clique duas vezes em Firewall do Windows.

Resumo

Os administradores de segurança precisam entender os pontos fortes e fracos do ACS em comparação com os métodos de proteção convencionais baseados em Diretiva de Grupo, de modo a poderem selecionar a metodologia correta para seu ambiente. O ACS e a Diretiva de Grupo podem ser usados em conjunto, o que oferece a capacidade de criar rápida e consistentemente protótipos de diretivas fornecidos pelo ACS, juntamente com a implantação escalável e os recursos de gerenciamento da Diretiva de Grupo.

Várias considerações de design estão envolvidas na revisão do design de floresta, domínio e UO para a proteção de um ambiente.

É importante pesquisar e documentar todos os requisitos específicos de autonomia e isolamento da organização. Autonomia política, isolamento operacional e isolamento legal ou regulador são motivos válidos para se considerar designs de florestas complexos.

É importante que você entenda como controlar os administradores de serviço. Administradores de serviços mal-intencionados podem representar um grande risco para uma organização. Em um nível inferior, os administradores de domínios mal-intencionados podem acessar dados em qualquer domínio da floresta.

Apesar de não ser fácil alterar o design da floresta ou do domínio em uma organização, isso pode ser necessário para remediar alguns riscos de segurança. Também é importante planejar a implantação da UO na organização de forma a acomodar as necessidades tanto dos administradores de serviço quanto dos administradores de dados. Este capítulo forneceu informações detalhadas sobre como criar um modelo de UO que ofereça suporte ao uso de GPOs para o gerenciamento contínuo de diferentes funções de servidor na organização.

Mais informações

Os links a seguir fornecem informações adicionais sobre tópicos relacionados à proteção de servidores que executam o Windows Server 2003 com SP1.


Neste artigo

Download

Obtenha o Guia de Segurança do Windows Server 2003

Notificações de atualizações

Inscreva-se para informar-se sobre atualizações e novos lançamentos

Comentários

Envie-nos seus comentários ou sugestões



Isso foi útil para você?
(1500 caracteres restantes)
Agradecemos os seus comentários
A Microsoft está realizando uma pesquisa online para saber sua opinião sobre o site do MSDN. Se você optar por participar, a pesquisa online lhe será apresentada quando você sair do site do MSDN.

Deseja participar?
Mostrar:
© 2014 Microsoft