Cobertura PSO por conta: verifique cada conta de serviço

O que a Cobertura PSO por conta deve comprovar

Cobertura PSO por conta é a evidência de que cada identidade de serviço no âmbito definido foi analisada segundo o seu modelo real de gestão de credenciais e a referência de palavras-passe aprovada. Para um utilizador de domínio tradicional que executa um serviço, isso significa consultar o Password Settings Object (PSO) resultante ou registar a política predefinida do domínio quando nenhum PSO se aplica. Encontrar uma política associada a uma conta de serviço não permite estabelecer a cobertura das restantes contas do conjunto.

O resultado prático é uma matriz: conta, serviço, responsável, PSO resultante, evidência da política predefinida do domínio e decisão sobre exceções. Mantenha as falhas de recolha visíveis nessa matriz. Uma política inacessível é uma lacuna de evidência por resolver; não deve transformar-se silenciosamente em «protegida» ou «sem política».

Esta distinção é relevante na interpretação de um resultado automatizado. A implementação do etc-collector analisada aqui verifica se alguma conta de serviço selecionada tem uma associação FGPP que satisfaça os critérios. Não responde se cada conta selecionada recebe uma política resultante aprovada. Um resultado sem alerta exige, por isso, uma análise de cobertura antes de fundamentar uma decisão de encerramento.

Como uma associação de política difere de uma política resultante

A referência de Get-ADUserResultantPasswordPolicy da Microsoft identifica msDS-ResultantPSO como o atributo da política resultante. As atribuições diretas têm prioridade sobre políticas associadas através de grupos. No nível aplicável, prevalece o menor valor de msDS-PasswordSettingsPrecedence; valores iguais são resolvidos pelo menor objectGUID, conforme o algoritmo de PSO resultante da Microsoft. Uma associação candidata de política não comprova, portanto, qual política prevalece.

A análise de cobertura deve preservar a identidade e as definições da política devolvida, em vez de inferir a vencedora a partir do nome de um grupo. Se uma política aparentemente forte associada através de um grupo coexistir com uma atribuição direta diferente, investigue o objeto resultante antes de aceitar o grupo como evidência de proteção. Este é um exemplo de raciocínio, não um relato de uma configuração incorreta observada.

Uma questão distinta é saber quais identidades pertencem à análise. As orientações da Microsoft sobre contas de serviço distinguem contas de serviço baseadas em utilizadores de domínio tradicionais de identidades geridas e virtuais. Descrevem a gestão automática de palavras-passe de gMSA e não estabelecem um comprimento mínimo universal para contas de serviço. A análise deve preservar essas distinções, em vez de tratar qualquer nome semelhante ao de um serviço como um utilizador comum com uma palavra-passe mantida manualmente.

Deteção e verificação: construir a matriz de cobertura

1. Acordar o conjunto de contas com os responsáveis pelos serviços

Comece pelo inventário de serviços e reconcilie-o com os candidatos do diretório. Registe o identificador estável da conta, os serviços associados, o responsável operacional, o estado de ativação, o tipo de identidade e a responsabilidade pela gestão de credenciais. Quando uma conta serve várias aplicações, preserve todas as dependências, em vez de escolher um nome de serviço conveniente.

A lista de candidatos do detetor é uma entrada útil, mas não constitui o inventário oficial de serviços. Uma heurística de nomes pode incluir utilizadores sem relação com serviços e omitir um serviço executado com um nome inesperado sem SPN. Resolva essas diferenças com os responsáveis. A nossa análise de nomes de contas e verificação de políticas efetivas explica por que os nomes selecionam candidatos sem comprovar uma palavra-passe fraca; utilize esse tutorial existente para a investigação mais ampla dos nomes.

Mantenha as contas desativadas visíveis com uma classificação separada: conservadas por um motivo documentado, com desativação definitiva pendente ou excluídas da referência de serviços ativos mediante aprovação. Não conte a política de uma conta desativada como evidência de que a população de serviços ativos está coberta. O detetor não faz essa distinção.

Para identidades geridas, a capacidade de filtragem documentada de Get-ADServiceAccount permite esta adaptação de inventário apenas de leitura:

Get-ADServiceAccount -Filter * -Server dc01.contoso.com

O comando devolve objetos de contas de serviço geridas, não um inventário completo de todos os serviços ou das contas de serviço tradicionais baseadas em utilizadores. Utilize a identidade e o tipo do objeto para reconciliar os resultados com o inventário de serviços. Não solicite material de palavras-passe geridas para esta análise. Registe as gMSAs no seu percurso de análise de credenciais geridas, em vez de as marcar como defeituosas apenas porque um campo PSO de utilizador tradicional está vazio ou não é aplicável.

2. Consultar uma política resultante para cada conta de utilizador tradicional

Execute a seguinte adaptação dos parâmetros de identidade e servidor documentados para cada conta de serviço tradicional aprovada baseada num utilizador, substituindo o DN e o controlador de domínio ilustrativos pelo destino verificado:

Get-ADUserResultantPasswordPolicy -Identity "CN=svc-sql,OU=Service Accounts,DC=contoso,DC=com" -Server dc01.contoso.com -ErrorAction Stop

A referência do cmdlet documenta estes parâmetros, o tratamento comum de erros e os erros de permissões do diretório. Preserve o comando, a identidade consultada, o servidor, a data e hora, o objeto devolvido e o registo de erro. Uma resposta bem-sucedida com um objeto de política fornece a identidade e as definições do PSO resultante. Um erro fornece evidência de uma leitura sem êxito; não fornece um veredito sobre a cobertura da política.

Repita a leitura para cada conta do conjunto de utilizadores tradicionais. Preserve as linhas bem-sucedidas quando outra conta falha e mantenha a linha com falha em aberto. Não converta uma chamada falhada num valor nulo de política numa exportação, nem omita as linhas com falha do denominador. Qualquer automatização utilizada para recolher a matriz deve conter um campo distinto de estado da leitura junto do campo da política.

3. Registar a política predefinida do domínio e explicar associações concorrentes

Utilize o exemplo de identidade e o parâmetro de servidor documentados em Get-ADDefaultDomainPasswordPolicy, adaptados ao domínio pretendido:

Get-ADDefaultDomainPasswordPolicy -Identity contoso.com -Server dc01.contoso.com

Conserve a política predefinida como evidência ao nível do domínio. Para uma leitura bem-sucedida de utilizador sem PSO devolvido, verifique a identidade e o contexto da consulta, depois registe a política predefinida aplicável e a sua avaliação face à referência. Deixe a linha por resolver se a completude da leitura ou as permissões continuarem incertas. Um campo PSO vazio, por si só, não constitui evidência suficiente para aprovar a linha.

Para investigar associações candidatas de políticas, utilize a capacidade de filtragem documentada de Get-ADFineGrainedPasswordPolicy:

Get-ADFineGrainedPasswordPolicy -Filter * -Server dc01.contoso.com

Analise os valores devolvidos de AppliesTo, Precedence e as definições em conjunto com o resultado por utilizador. O inventário de políticas explica atribuições candidatas; não substitui a leitura da política resultante. Guarde apenas as evidências de política e identidade necessárias para a análise.

Se um percurso de pertença a grupos aninhados for relevante, documente a cadeia da conta até ao grupo, o destino da política, a evidência autorizada de pertença e a política resultante devolvida. Identifique uma cadeia incompleta como não verificada. Não infira um PSO efetivo a partir de um diagrama com aspeto recursivo ou da comparação de membros diretos feita pelo detetor. Peça ao responsável pelo diretório que reconcilie evidências inconsistentes de pertença e política resultante antes de encerrar essa linha.

4. Utilizar resultados explícitos por linha

O esquema seguinte é uma sugestão de evidências, não uma amostra de contas reais ou resultados de testes:

Uma linha concluída pode ser aprovada através de um PSO resultante verificado, de uma política predefinida do domínio aprovada ou de um percurso de controlo para identidade gerida justificado separadamente. Estes são resultados diferentes. «Acesso negado», «falha» e «aplicabilidade pendente» continuam a ser lacunas de evidência em aberto. Uma exceção é uma decisão documentada, não uma aprovação automática.

Reconcilie a matriz com o conjunto de contas acordado antes de a resumir. Comunique explicitamente as leituras por resolver e as identidades excluídas. A ausência de um resultado automatizado não deve apagar essas linhas.

Resolver a lacuna de referência de cada conta (Remediation)

1. Aprovar definições segundo o contexto do serviço

Utilize a matriz para identificar quais contas tradicionais ficam aquém da referência aprovada. Peça aos responsáveis pelo serviço e pelo diretório que acordem as definições de palavras-passe exigidas, a compatibilidade operacional, a manutenção de credenciais e o plano de implementação. Analise as definições devolvidas como um todo; comparar apenas o comprimento mínimo é insuficiente para uma referência aprovada localmente.

O valor 20 do detetor é um limiar de implementação. Não o transforme num requisito da Microsoft para todos os serviços, nem copie definições de políticas demonstrativas como recomendações para produção. Mantenha a referência aprovada do serviço e a sua justificação junto da linha da conta.

2. Corrigir atribuições e lacunas de evidência de forma deliberada

Quando estiver prevista uma FGPP aprovada, planeie a correção necessária de atribuição ou precedência através do processo de alterações do diretório. Considere atribuições diretas concorrentes e outros consumidores da mesma política antes de efetuar a alteração. Evite criar uma única associação que satisfaça os critérios apenas para reduzir a contagem do detetor.

Uma leitura negada exige acesso autorizado ou outro percurso aprovado de recolha de evidências antes de decidir sobre a cobertura. Registe em conjunto o erro original e a leitura bem-sucedida posterior. Corrigir a recolha é um pré-requisito para interpretar a política; por si só, não corrige as credenciais da conta.

Para exceções conservadas, registe a dependência do serviço, o responsável, as medidas compensatórias, o aprovador e a próxima data de revisão. Mantenha a exceção da linha visível nos relatórios futuros de cobertura. Uma exceção sem responsável ou expirada deve voltar a ser analisada.

3. Separar decisões sobre contas geridas e desativação definitiva

Para um serviço elegível para gMSA, avalie uma migração para uma identidade gerida com o respetivo responsável e valide a compatibilidade e a obtenção autorizada de credenciais. Esta é uma alteração distinta de atribuir uma FGPP a uma conta tradicional. Mantenha a decisão de classificação e a evidência de migração na matriz.

Para identidades desativadas, resolva as dependências e o motivo da conservação antes da desativação definitiva. Não remova contas em massa por aparecerem numa análise de cobertura. Por outro lado, não permita que uma identidade sem uso que satisfaça os critérios oculte lacunas nos serviços ativos.

Quanto à exposição a ataques, o nosso guia de Kerberoasting sobre tickets de serviço e segredos de contas de serviço trata da investigação separada de tickets, segredos e privilégios. Esta matriz estabelece a cobertura da análise de políticas; não comprova resistência à quebra de palavras-passe offline nem a ausência de atividade maliciosa.

4. Repetir as leituras após alterações aprovadas

Volte a executar o comando de política resultante por utilizador e as leituras de inventário relevantes após a alteração aprovada. Anexe evidências anteriores e posteriores a cada linha afetada, depois peça aos responsáveis que validem o funcionamento do serviço e o plano de manutenção de credenciais. Um resultado PSO alterado comprova um resultado de política, não a qualidade de um segredo existente.

Como a EtcSec deteta este problema

A verificação SERVICE_ACCOUNT_WEAK_PASSWORD_POLICY do etc-collector tem a categoria Password e a severidade Medium. Esta descrição provém de public/internal/audit/detectors/ad/password/service-account-password-policy.go:39 no commit do collector 0423094759d50002457031317098417993e19510.

Seleciona utilizadores recolhidos com SPN ou um provável nome de serviço: prefixos svc_, svc-, sa_, sa-, sql, iis ou app, ou a subcadeia service, após converter sAMAccountName em minúsculas. As contas selecionadas têm de possuir um DN não vazio. O conjunto de DNs resultante é deduplicado sem excluir contas desativadas nem separar gMSAs.

A verificação procura depois FGPPs recolhidas cujo comprimento mínimo seja pelo menos 20. Uma correspondência direta de AppliesTo com qualquer conta selecionada, ou uma correspondência com a lista de Members diretos de um grupo que contenha essa conta, ativa o seu indicador de cobertura. A pesquisa termina após a primeira relação que satisfaça os critérios.

Consequentemente, Count=1 significa que existem contas selecionadas e não foi encontrada uma relação que satisfaça os critérios nos dados recolhidos. Count=0 significa que nenhuma conta foi selecionada ou que foi encontrada pelo menos uma relação que satisfaça os critérios. Count é binário, não o número de contas sem cobertura. Os detalhes incluem serviceAccountCount, que corresponde ao tamanho do conjunto de DNs selecionados, não a um total de cobertura.

A verificação não consulta msDS-ResultantPSO, não calcula a precedência efetiva, não expande grupos aninhados, não compara cada conta com uma referência, não inspeciona uma palavra-passe existente nem verifica MFA. O seu texto descritivo não deve ser tratado como evidência de que esses controlos foram testados.

A recolha também limita a conclusão. Em public/internal/providers/ldap/client.go:1835, GetFGPPs devolve nil, nil quando a pesquisa no contentor de políticas falha. O motor aceita um erro nil em public/internal/audit/engine.go:557; este percurso não distingue, para este detetor, um contentor inacessível de uma lista vazia de políticas. Com contas selecionadas, essa entrada vazia pode levar a Count=1. Investigue a recolha antes de afirmar que não existem políticas.

Decisões a registar antes do encerramento

Resolva três questões com os responsáveis:

1. Que identidades executam efetivamente serviços, incluindo contas desativadas e geridas, e que percurso de controlo se aplica a cada uma?
2. Como foram registadas e reconciliadas as leituras negadas, as consultas falhadas e as pertenças relevantes a grupos aninhados?
3. Que referência está aprovada para cada serviço, e que exceções conservadas têm um aprovador e uma data de revisão?

Guarde em conjunto a definição do conjunto de contas, as leituras de políticas, as explicações de pertença, as evidências de alterações e as decisões, sem exportar segredos. A declaração final de cobertura deve descrever as contas efetivamente analisadas e as lacunas ainda em aberto. Nunca deve inferir proteção universal a partir de uma única relação FGPP que satisfaça os critérios.