Security WatchAssuntos e entidades de segurança

Jesper M. Johansson

Conteúdo

A tupla assunto/objeto/ação
Tipos de entidades de segurança
Serviços
Conclusão

No nível mais básico, tudo em segurança se resume a assuntos e objetos. Objetos são as coisas que você protege e assuntos são as coisas das quais você protege os objetos. Essas duas construções são usadas em autenticação (comprovando quem você é), autorização (concedendo acesso a algo) e auditoria (controlando quem acessa o quê). Fundamentalmente, esses conceitos são muito simples, como mostra a Figura 1.

Figura 1 Um usuário tenta ler um arquivo

Assuntos são coisas que fazem coisas, enquanto objetos são coisas para as quais eles são feitos. Além disso, às vezes, os objetos para os quais os assuntos fazem coisas são outros assuntos.

O Windows oferece suporte a uma semântica imensamente rica no que diz respeito à segurança, e ampliou muito as definições de assuntos e objetos. Um assunto pode ser muito mais do que apenas um usuário e a representação é muito mais complexa do que apenas um identificador de usuário básico.

Na linguagem do Windows, uma entidade de segurança envolve não somente o assunto característico (que você consideraria como um usuário) mas também grupos e computadores. Uma entidade de segurança é algo ao qual pode ser atribuído um identificador de segurança (SID) e dada permissão para acessar algo.

Nesta edição do Security Watch, estou introduzindo como os assuntos são representados e usados no Windows.

A tupla assunto/objeto/ação

O gerenciamento de segurança muito freqüentemente se resume à tupla assunto/objeto/ação. O assunto é o ator que está tentando realizar alguma ação em um objeto. Por exemplo, um usuário tenta acessar um arquivo, como mostra a Figura 1. Quando um usuário tenta ler o arquivo, o sistema operacional precisa verificar se permissões estão definidas no objeto (o arquivo) que permite que o assunto (o usuário) realize a ação (leitura) nesse objeto específico. Se as permissões estiverem em ordem, a solicitação de acesso será bem-sucedida. Se as permissões não estiverem em ordem, a solicitação de acesso será negada. Até agora, isso tudo é muito simples.

O uso de maiúsculas faz diferença

Na literatura do Windows, quando você vê as palavras "Administrador" ou "Administradores" com uma letra "A" maiúscula, isso geralmente se refere ao usuário ou ao grupo, respectivamente. Quando você vê a palavra toda em letras minúsculas – "administrador" – ela se refere a determinada conta ou pessoa que tem privilégios administrativos. O mesmo ocorre para outras entidades, como "Guest" e "guest".

Tipos de entidades de segurança

Assuntos – ou entidades de segurança, como devo me referir a eles daqui para a frente – em um sistema baseado em Windows e, por extensão, uma rede baseada em Windows, podem ser muito mais do que apenas usuários. No entanto, o usuário ainda é o conceito mais básico.

Usuários Um usuário é uma certa entidade distinta que faz logon em um computador. Fundamentalmente, todas as entidades de segurança são, pelo menos, relacionados a usuários. No Windows, pode haver dois tipos de usuários: local e de domínio. Um usuário local é definido no banco de dados SAM (Gerenciador de Contas de Segurança) em um computador. Cada computador baseado em Windows tem um SAM local, que contém todos os usuários nesse computador.

Geralmente se considera que controladores de domínio (DCs) não têm um SAM local e, portanto, não têm usuários locais. Mas isso não é verdade. Cada DC tem um SAM local, mas as contas em seu SAM pode ser usadas apenas no Modo de Restauração dos Serviços de Diretório.

O SAM local sempre contém pelo menos duas contas de usuário: o Administrador e o Convidado, e a conta Convidado está sempre desabilitada por padrão.

Em todas as versões do Windows Server 2008 (com exceção do Windows Small Business Server 2008), a conta Administrador é habilitada por padrão e você deve usar essa conta na primeira vez que fizer logon no computador. No Windows Vista, a conta Administrador é desabilitada por padrão e pode ser usada apenas em circunstâncias muito restritas.

Em qualquer um dos casos, você deve criar pelo menos duas contas para cada pessoa que administrará determinado computador. Se você estiver sujeito a praticamente qualquer tipo de regulamento (e provavelmente está), esse é um requisito. Para cada usuário, uma conta deve ser a conta administrativa pessoal do próprio usuário. A outra conta é a conta não administrativa pessoal do usuário para tarefas não administrativas.

Usuários que não são locais são usuários de domínio Esses usuários são definidos nos DCs do domínio. A diferença entre contas locais e de domínio é principalmente o escopo das contas. As contas de domínio podem ser usadas em qualquer computador no domínio, enquanto contas locais são válidas apenas no computador no qual são definidas. Além disso, as contas de domínio podem ter um número consideravelmente maior de propriedades associadas a elas em comparação com uma conta local (veja as Figuras 2 e 3 para ter uma comparação).

Figura 2 Janela Propriedades de uma conta local

Figura 3 Janela Propriedades de uma conta de domínio

As contas de domínio têm um conjunto mais rico de semântica, cobrindo uma variedade de atributos em um ambiente organizacional, como números de telefone, relações de gerenciamento e contas de email. As contas de domínio também são muito mais úteis em uma rede, pois elas podem ser usadas e ter permissões atribuídas em computadores na rede. Além disso, definir contas no domínio simplifica o gerenciamento, pois agora você precisa apenas manter contas vigentes.

Computadores Um computador é apenas outro tipo de usuário. No Active Directory, isso é especialmente verdadeiro e é gerado pelo modelo de herança. A estrutura de herança que leva a um computador é descrita na Figura 4.

Figura 4 A hierarquia de herança no Active Directory mostrando como usuários e computadores estão relacionados

Há várias coisas muito interessantes ilustradas na Figura 4. Primeiro, como você pode ver, todos os casos no Active Directory derivam de uma classe raiz denominada Top. Na verdade, mesmo Top é considerada uma subclasse de Top. Em segundo lugar, a classe User é derivada da classe organizationalPerson. Em terceiro lugar (e esse é o ponto mais interessante), a classe Computer é derivada da classe User. Em outras palavras, em linguagem orientada a objetos, um Computador é um tipo de usuário. Dar forma a computadores dessa maneira na verdade faz muito sentido, pois computadores precisam ser tratados como assuntos também e têm praticamente todos os mesmos atributos que uma pessoa.

Grupos Um assunto, você lembrará, é algo que tenta acessar um objeto. O sistema operacional verifica essa tentativa de acesso ao verificar as permissões do objeto. No início, os designers de SO descobriram que seria muito complicado atribuir permissões a cada objeto único para cada usuário único que precisasse dele. Para resolver esse problema, os designers permitiram que usuários fossem membros de grupos. Isso permite que você atribua permissões a grupos, além de usuários.

Um grupo pode não ser um usuário, mas um grupo ainda é um tipo de entidade de segurança, pois ele pode ter um identificador, assim como usuários e computadores. No Windows, um usuário pode ser um membro de muitos grupos e um objeto pode ter permissões atribuídas a muitos grupos. Grupos aninhados também são permitidos, com algumas restrições.

Um controlador que não seja de domínio tem apenas dois tipos de grupos: grupos embutidos e grupos locais que o administrador definiu. No entanto, no Active Directory, você encontrará seis tipos diferentes de grupos de segurança: grupos locais de domínio embutido, grupos globais embutidos, grupos universais embutidos, grupos locais de domínio definidos pelo usuário, grupos globais definidos pelo usuário e grupos universais definidos pelo usuário.

Grupos locais de domínio podem receber apenas permissões para recursos no domínio em que foram definidos. No entanto, eles podem conter usuários, grupos universais e globais de qualquer floresta ou domínio confiável, e grupos locais de domínio de seu próprio domínio.

Um grupo global pode conter apenas usuários e grupos globais do domínio no qual ele foi definido, mas pode receber permissões para recursos em qualquer domínio na floresta de que o domínio faz parte ou qualquer floresta confiável.

Um grupo universal pode conter usuários, bem como grupos globais e universais de qualquer domínio. Um grupo universal pode receber permissões para recursos em qualquer floresta ou domínio confiável. Em outras palavras, um grupo universal é um tipo de híbrido entre grupos globais e locais de domínio.

Enquanto uma estação de trabalho diz respeito a apenas dois grupos por padrão – Administradores e Convidados – um domínio diz respeito a um número relativamente grande, de todos os três tipos. A Figura 5 mostra os grupos padrão em um domínio. Todos são designados como grupos de segurança, o que significa que eles podem receber permissões. (Grupos de segurança não devem ser confundidos com grupos de distribuição, que são usados pelo Microsoft Exchange Server para agrupar usuários em listas de emails. Ambos são definidos no Active Directory.) Os grupos locais existentes em todos os computadores baseados em Windows são definidos no Active Directory em DCs.

Figura 5 Grupos padrão definidos no contêiner Usuários no Active Directory

Como com DCs, alguns não DCs têm também grandes números de grupos. A Figura 6 mostra 16 grupos embutidos em um computador de teste. O número exato de grupos em qualquer computador especificado irá diferir, dependendo das funções instaladas nesse computador.

Figura 6 Grupos embutidos em um não DC (clique na imagem para ampliá-la)

Se você não tentasse atribuir permissões a um objeto, você encontraria ainda mais grupos do que eu mostrei até agora. Na verdade, em um DC base, você encontraria não mais de 63 grupos e entidades de segurança embutidos, como mostra a Figura 7.

Muitos dos 63 grupos mostrados na Figura 7 são conceitos abstratos, que às vezes são conhecidos como “entidades especiais”, que representam um grupo dinâmico de entidades de segurança. Às vezes, eles também são referidos como Grupos de logon.

Grupos de logon Grupos de logon são grupos que representam determinado aspecto dinâmico de uma entidade de segurança, como o modo como um usuário ou outra entidade de segurança efetuou logon. Por exemplo, o grupo INTERACTIVE mostrado na Figura 7 inclui todos os usuários conectados ao console do computador e através dos Serviços de Terminal. Em contraste, o grupo NETWORK inclui todos os usuários conectados através da rede. Por definição, um usuário pode ser apenas um membro de um desses grupos por vez e a associação neles é atribuída no momento do logon. Você pode usar esses grupos para conceder permissões a todos os usuários efetuando logon de determinada forma, mas você não pode controlar quem se torna um membro desses grupos.

Figura 7 Um DC base não tem mais de 63 grupos e entidades de segurança embutidos

Também há outros grupos dessa natureza. De especial importância são os grupos Everyone e Authenticated Users. O grupo Everyone inclui, como o nome indica, todos os usuários acessando esse computador – com exceção de que, iniciando com o Windows XP, usuários não autenticados e totalmente anônimos não são incluídos. Em outras palavras, o usuário NULL incorreto não está incluído em Everyone em nenhum sistema operacional compatível baseado em Windows. Entretanto, os convidados estão incluídos.

O grupo Authenticated Users, embora seja preenchido automaticamente, inclui apenas os usuários que são de fato autenticados. Portanto, convidados não são incluídos em Authenticated Users. Essa é a única diferença entre esses dois grupos. Mas como a única conta de convidado que existe no sistema operacional está desabilitada, não há diferença funcional entre Authenticated Users e Everyone, a não ser que você tenha realizado etapas manuais para habilitar a conta Guest, sendo que, nesse caso, provavelmente, você deseja que Guests seja capaz de acessar recursos e, portanto, precisa do grupo Everyone intacto.

Apesar disso, muitos administradores têm perdido muitas horas de sono em relação ao fato de que "todo mundo têm permissões em meu servidor" e realizam etapas muito drásticas para modificar permissões para corrigir essa situação. Geralmente, essas modificações tiveram resultados totalmente desastrosos. Você não tem nenhum motivo para tentar substituir permissões para Everyone por Authenticated Users. Ou você quer que os convidados tenham permissões para o seu computador e habilita a conta Guest, ou você deixa a conta Guest desabilitada. Se você quiser que convidados tenham permissões, você precisa de permissões para Everyone. Caso não queira, o grupo Everyone não será diferente de Authenticated Users.

Algumas pessoas argumentam que fazer essas alterações são “defesa em profundidade”. Isso seria verdadeiro se você definisse “defesa em profundidade” como “alterações que você não pode justificar de outra forma”. O fato é que tais modificações fornecem pouca ou nenhuma melhoria de segurança e, ao mesmo tempo, apresentam muito risco. Deixe os padrões de lado.

Se esse argumento não for persuasivo o suficiente, indico o Artigo 885409 da Base de Dados de Conhecimento da Microsoft ("Suporte para orientação de configuração de segurança"). Ele declara, em resumo, que a substituição de permissões substanciais pode anular seu contrato de suporte. Quando você faz isso, você basicamente cria seu próprio sistema operacional e a Microsoft não pode mais garantir que ele funcionará.

Também é válido mencionar a diferença entre Users, que é um grupo embutido, e Authenticated Users. A diferença é o fato um tanto óbvio de que Authenticated Users inclui cada usuário que foi autenticado no computador, incluindo usuários em diferentes domínios, usuários que são membros de grupos locais além de Usuários, e usuários que não são membros de quaisquer grupos de forma alguma (sim, isso é possível). Isso significa que o grupo Users é muito mais restritivo que o Authenticated Users.

Apesar disso, tenho visto organizações destruírem suas redes na tentativa de substituir permissões para Users com permissões por Authenticated Users, na tentativa de “proteger seus sistemas”. Argumentei incansavelmente com auditores PCI/DSS que declaram que a indústria de cartões de pagamento requer que você substitua todas as permissões para Users por Authenticated Users. Isso simplesmente não é verdade.

Eu também defendi organizações de consultores no mundo inteiro que parecem ver a substituição de ACL (lista de controle de acesso) como uma excelente forma de obter horas cobráveis. Não é necessário dizer, você pode esperar que quaisquer tentativas de substituição substancial de Users ou Everyone por Authenticated Users não tenham êxito em relação à segurança e à estabilidade.

Serviços

O Windows Vista e o Windows Server 2008 oferecem suporte a um novo tipo de entidade de segurança: um serviço. Para compreender como essas entidades são importantes, considere o debate contínuo sobre firewalls baseados em host. Muitas pessoas, com o apoio ávido de fornecedores vendendo os produtos, argumentam que firewalls baseados em host devem filtrar o tráfego de saída para que sejam válidos, pois isso protege o restante da rede de um computador comprometido. Mentes mais objetivas indicam que se um computador estiver comprometido, o malware estará presente no computador e, portanto, o malware tem a capacidade de desviar ou desabilitar totalmente firewalls baseados em host.

Para compreender por que esse é o caso, considere dois serviços em execução como a entidade principal. O serviço A tem permissão para se comunicar através do firewall, o serviço B não. Se o serviço B estiver comprometido, o invasor poderá ignorar essa restrição simplesmente ao realizar outro processo executando essa entidade de segurança, o serviço A, por exemplo, e comunicar-se a partir desse processo.

Para resolver esse problema, a Microsoft precisou de uma forma para aplicar permissões a um processo ou, mais especificamente, a um serviço. Para essa finalidade, os serviços se tornaram entidades de segurança por seu próprio direito. E, conseqüentemente, cada serviço agora tem um identificador que pode ser usado para aplicar permissões em relação a ele. Você pode executar o comando "sc showsid" da linha de comando para ver o SID do serviço para qualquer serviço.

Com SIDs de serviço, é possível restringir o acesso a recursos para processos específicos, em oposição a restringir apenas o acesso a usuários específicos. Essa alteração torna os filtros de firewall baseados em host de saída significativos em algumas situações. A natureza exata dessas situações está além do escopo desta discussão, mas se você estiver interessado em ler mais sobre isso, sugiro que você leia o artigo que escrevi sobre o firewall do Windows Vista na edição de junho de 2008 da TechNet Magazine (consulte "Gerenciando o firewall do Windows Vista").

Conclusão

As entidades de segurança dão tanto suporte à segurança do Windows que é essencial que qualquer administrador tenha pelo menos um conhecimento básico de como os vários tipos de entidades de segurança funcionam e de como são usados. Somente compreendendo esses tópicos você poderá criar com eficiência uma estratégia de segurança que efetivamente use essas entidades de segurança. Esse conhecimento será útil quando você precisar ouvir argumentos inúteis de pessoas que não compreendem totalmente as entidades de segurança e esperam que você coloque em risco a integridade de sua rede com alterações desnecessárias e inadequadas.

Esta coluna é baseada em material do meu livro Windows Server 2008 Security Resource Kit (Microsoft Press).

Jesper M. Johansson é arquiteto de segurança de entidade para uma empresa renomada da lista Fortune 200. Ele trabalha com estratégia de segurança e visão de segurança baseada em riscos. Ele também é editor-colaborador da TechNet Magazine. Seu trabalho consiste em garantir a segurança em alguns dos maiores e mais distribuídos sistemas do mundo. Ele possui Ph.D. em sistemas de informações sobre gerenciamento, tem mais de 20 anos de experiência em segurança e é MVP Microsoft em segurança corporativa. Seu livro mais recente é o Windows Server 2008 Security Resource Kit.