Manter um ambiente mais seguro

Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2 e Windows Server 2012

Lei Número Sete: a tecnologia não é uma panaceia. - Dez leis imutáveis da administração de segurança

Quando você cria um ambiente gerenciável e seguro para seus ativos comerciais críticos, seu foco deve mudar para garantir que ele seja mantido com segurança. Embora você tenha recebido controles técnicos específicos para aumentar a segurança das instalações do AD DS, a tecnologia por si só não protegerá um ambiente no qual a TI não funciona em parceria com a empresa para manter uma infraestrutura segura e utilizável. As recomendações de alto nível desta seção devem ser usadas como diretrizes que você pode usar para desenvolver uma segurança e um gerenciamento eficaz do ciclo de vida.

Em alguns casos, sua organização de TI pode já ter uma relação de trabalho próxima com as unidades de negócios, o que facilitará a implementação dessas recomendações. Em organizações nas quais as unidades de TI e de negócios não estão intimamente vinculadas, talvez seja necessário primeiro obter o patrocínio executivo para esforços a fim de forjar uma relação mais próxima entre as unidades de negócios e de TI. O Resumo Executivo destina-se a ser útil como um documento autônomo para revisão executiva e pode ser disseminado para os tomadores de decisão na sua organização.

Como criar práticas de segurança centrada nos negócios para o Active Directory

No passado, a tecnologia da informação em muitas organizações era vista como uma estrutura de suporte e um centro de custo. Em geral, os departamentos de TI eram amplamente separados dos usuários de negócios, e as interações limitadas a um modelo de solicitação-resposta no qual os negócios solicitavam recursos e a TI respondia.

À medida que a tecnologia evoluiu e foi disseminada, a visão de "um computador em cada área de trabalho" efetivamente deixou de existir em grande parte do mundo e até foi obscurecida pela ampla gama de tecnologias facilmente acessíveis disponíveis hoje. A tecnologia da informação não é mais uma função de suporte, é uma função de negócios básica. Se a sua organização não podia continuar funcionando se todos os serviços de TI não estivessem disponíveis, os negócios da sua organização são, no mínimo, em parte, a tecnologia da informação.

Para criar planos efetivos de recuperação de comprometimento, os serviços de TI precisam trabalhar em estreita colaboração com as unidades de negócios na sua organização para identificar não apenas os componentes mais críticos do cenário de TI, mas as funções críticas exigidas pela empresa. Ao identificar o que é importante para sua organização como um todo, você pode se concentrar em proteger os componentes que têm mais valor. Essa não é uma recomendação para reduzir a segurança de dados e de sistemas de baixo valor. Em vez disso, assim como você define níveis de serviço para o tempo de atividade do sistema, considere a possibilidade de definir níveis de controle e monitoramento de segurança com base na importância do ativo.

Ao investir na criação de um ambiente atual, seguro e gerenciável, você pode mudar o foco para gerenciá-lo com eficiência e garantir que tenha processos eficazes de gerenciamento do ciclo de vida que não são determinados apenas pela TI, mas pela empresa. Para fazer isso, você precisa fazer parceria com a empresa e investir os negócios em "propriedade" de dados e sistemas no Active Directory.

Quando dados e sistemas são introduzidos no Active Directory sem proprietários designados, proprietários de negócios e proprietários de TI, não há uma cadeia clara de responsabilidade pelo provisionamento, pelo gerenciamento, pelo monitoramento, pela atualização e, eventualmente, pela desativação do sistema. Isso resulta em infraestruturas nas quais os sistemas expõem a organização a riscos, mas que não podem ser desativadas porque a propriedade não está clara. Para gerenciar efetivamente o ciclo de vida dos usuários, dos dados, dos aplicativos e dos sistemas gerenciados pela instalação do Active Directory, você deve seguir os princípios descritos nesta seção.

Atribuir um proprietário de negócios aos dados do Active Directory

Os dados no Active Directory devem ter um proprietário de negócios identificado, ou seja, um departamento ou um usuário especificado que seja o ponto de contato para as decisões sobre o ciclo de vida do ativo. Em alguns casos, o proprietário de negócios de um componente do Active Directory será um departamento de TI ou um usuário. Provavelmente, os componentes de infraestrutura, como controladores de domínio, servidores DHCP e DNS e o Active Directory, pertencerão à TI. Para os dados adicionados ao AD DS para dar suporte à empresa (por exemplo, novos funcionários, novos aplicativos e novos repositórios de informações), uma unidade de negócios ou um usuário designado deve ser associado aos dados.

Se você usa o Active Directory para registrar a propriedade de dados no diretório ou se implementa um banco de dados separado para rastrear os ativos de TI, nenhuma conta de usuário deve ser criada, nenhum servidor ou estação de trabalho deve ser instalado e nenhum aplicativo deve ser implantado sem um proprietário de registro designado. Na melhor das hipóteses, pode ser complexo e, em alguns casos, impossível tentar estabelecer a propriedade dos sistemas depois que eles forem implantados em produção. Portanto, a propriedade deve ser estabelecida no momento em que os dados são introduzidos no Active Directory.

Implementar o gerenciamento do ciclo de vida orientados para os negócios

O gerenciamento do ciclo de vida deve ser implementado para todos os dados no Active Directory. Por exemplo, quando um novo aplicativo é introduzido em um domínio do Active Directory, o proprietário de negócios do aplicativo deve, em intervalos regulares, atestar o uso contínuo do aplicativo. Quando uma nova versão de um aplicativo é lançada, o proprietário do aplicativo deve ser informado e deve decidir se e quando a nova versão será implementada.

Se um proprietário de negócios optar por não aprovar a implantação de uma nova versão de um aplicativo, ele também deverá ser notificado sobre a data em que a versão atual não terá mais suporte e deverá ser responsável por determinar se o aplicativo será desativado ou substituído. Manter aplicativos herdados em execução e sem suporte não deve ser uma opção.

Quando as contas de usuário são criadas no Active Directory, os respectivos gerentes de registro devem ser notificados no momento da criação do objeto e obrigados a atestar a validade da conta em intervalos regulares. Ao implementar um ciclo de vida orientado aos negócios e o atestado regular da validade dos dados, as pessoas mais bem equipadas para identificar anomalias nos dados são as pessoas que revisam os dados.

Por exemplo, os invasores podem criar contas de usuário que pareçam ser contas válidas, seguindo as convenções de nomenclatura da sua organização e o posicionamento de objetos. Para detectar essas criações de contas, você pode implementar uma tarefa diária que retorna todos os objetos de usuário sem um proprietário de negócios designado para que você possa investigar as contas. Se os invasores criarem contas e atribuírem um proprietário de negócios, implementando uma tarefa que relata a criação de objeto para o proprietário de negócios designado, o proprietário de negócios poderá identificar rapidamente se a conta é legítima.

Você deve implementar abordagens semelhantes para grupos de segurança e distribuição. Embora alguns grupos possam ser grupos funcionais criados pela TI, criando cada grupo com um proprietário designado, você pode recuperar todos os grupos pertencentes a um usuário designado e exigir que o usuário ateste a validade das associações. Semelhante à abordagem adotada com a criação da conta de usuário, você pode disparar modificações de grupo de relatórios para o proprietário de negócios designado. Quanto mais costumeiro passa a ser para um proprietário de negócios atestar a validade ou a invalidade dos dados no Active Directory, mais equipado você está para identificar anomalias que podem indicar falhas de processo ou comprometimento real.

Classificar todos os dados do Active Directory

Além de registrar um proprietário de negócios para todos os dados do Active Directory no momento em que eles são adicionados ao diretório, você também deve exigir que os proprietários de negócios forneçam uma classificação para os dados. Por exemplo, se um aplicativo armazenar dados comercialmente críticos, o proprietário de negócios deverá rotular o aplicativo dessa forma, de acordo com a infraestrutura de classificação da organização.

Algumas organizações implementam políticas de classificação de dados que rotulam dados de acordo com os danos que a exposição dos dados vão gerar se forem roubados ou expostos. Outras organizações implementam a classificação de dados que rotula dados por importância, por requisitos de acesso e por retenção. Independentemente do modelo de classificação de dados em uso na sua organização, você deve garantir que consiga aplicar a classificação aos dados do Active Directory, não apenas aos dados de "arquivo". Se a conta de um usuário for uma conta VIP, ela deverá ser identificada no banco de dados de classificação de ativos (seja implementando isso por meio do uso de atributos nos objetos do AD DS ou implantando bancos de dados de classificação de ativos separados).

No modelo de classificação de dados, você deve incluir a classificação para dados do AD DS, como a descrita a seguir.

Sistemas

Você deve classificar os dados e as respectivas populações de servidores. Para cada servidor, você deve saber qual sistema operacional está instalado, quais funções gerais o servidor fornece, quais aplicativos estão em execução no servidor, o proprietário do registro de TI e o proprietário de negócios do registro, quando aplicável. Para todos os dados ou aplicativos em execução no servidor, você deve exigir a classificação e o servidor deve ser protegido de acordo com os requisitos para as cargas de trabalho compatíveis e as classificações aplicadas ao sistema e aos dados. Você também pode agrupar servidores pela classificação das cargas de trabalho, o que permite identificar rapidamente os servidores que devem ser os mais monitorados e configurados de maneira mais rigorosa.

Aplicativos

Você deve classificar os aplicativos pela funcionalidade (o que eles fazem), pela base de usuários (que usa os aplicativos) e pelo sistema operacional no qual eles são executados. Você deve manter os registros que contenham informações de versão, status do patch e qualquer outra informação pertinente. Você também deve classificar os aplicativos pelos tipos de dados que eles processam, conforme já descrito.

Usuários

Independentemente de você chamá-los de usuários "VIP", contas críticas ou usar outro rótulo, as contas nas instalações do Active Directory que são mais propensas a serem atacadas por invasores devem ser marcadas e monitoradas. Na maioria das organizações, simplesmente não é viável monitorar todas as atividades de todos os usuários. No entanto, se você conseguir identificar as contas críticas na sua instalação do Active Directory, poderá monitorar essas contas quanto a alterações, conforme já descrito neste documento.

Você também pode começar a criar um banco de dados de "comportamentos esperados" para essas contas à medida que audita as contas. Por exemplo, se você descobrir que determinado executivo usa a estação de trabalho protegida para acessar dados comercialmente críticos no escritório e em casa, mas raramente em outros locais, se você observar tentativas de acessar dados usando a conta em um computador não autorizado ou em um local no meio do planeta em que você sabe que o executivo não está localizado no momento, poderá identificar e investigar mais rapidamente esse comportamento anormal.

Ao integrar informações comerciais à sua infraestrutura, você pode usar essas informações comerciais para ajudar a identificar falsos positivos. Por exemplo, se as viagens executivas forem registradas em um calendário acessível à equipe de TI responsável por monitorar o ambiente, você poderá correlacionar as tentativas de conexão com os locais conhecidos dos executivos.

Digamos que o Executivo A esteja normalmente localizado em Chicago e use uma estação de trabalho segura para acessar dados comercialmente críticos no escritório, e um evento é disparado por uma tentativa com falha de acessar os dados em uma estação de trabalho não segura localizada em Atlanta. Se você conseguir verificar se o executivo está atualmente em Atlanta, poderá resolver o evento entrando em contato com o executivo ou o assistente do executivo, a fim de determinar se a falha de acesso foi decorrente do fato de o executivo ter esquecido de usar a estação de trabalho protegida para acessar os dados. Ao construir um programa que usa as abordagens descritas em Planejamento para evitar o comprometimento, você pode começar a criar um banco de dados de comportamentos esperados para as contas mais "importantes" na sua instalação do Active Directory que podem ajudar você a descobrir e responder mais rapidamente aos ataques.