Limites de autoridade do Configuration Manager: mapear controlo

Porque a colocação numa OU não estabelece os limites de autoridade do Configuration Manager

Os limites de autoridade do Configuration Manager acompanham a autoridade administrativa: quem pode alterar um componente de gestão, que recursos um operador pode controlar e onde uma identidade de instalação possui direitos locais. O distinguished name de um computador AD é uma evidência útil de inventário, mas movê-lo para uma OU chamada Management não responde a essas perguntas.

Comece pelo computador candidato e siga a sua autoridade para fora. É um servidor de site, um anfitrião do SMS Provider, outro sistema de site ou apenas um cliente gerido com um nome de produto na descrição? Que pessoas e identidades de serviço o administram? Que sistemas podem essas identidades alcançar? Uma revisão dos limites fica incompleta enquanto o mesmo registo não ligar a infraestrutura de gestão aos seus alvos reais.

O modelo de administração por tiers do Active Directory e as sessões administrativas fornece os princípios gerais de separação. Esta revisão acrescenta um mapa de autoridade específico do produto. Mantenha os dois ligados: uma convenção de OU pode apoiar a aplicação de políticas, mas não substitui evidências sobre quem controla o Configuration Manager ou os sistemas que este gere.

Como funciona: acesso ao Provider, autoridade sobre a base de dados e alcance dos alvos

A Microsoft descreve camadas de segurança distintas. O SMS Provider expõe o acesso à base de dados do site através de WMI e do serviço de administração. O acesso ao Provider e as permissões sobre objetos geridos são questões diferentes. Local System e o Configuration Manager setup user têm, por predefinição, autoridade sobre todos os objetos da base de dados do site; os restantes utilizadores administrativos são regidos pela administração baseada em funções da consola. As funções, os âmbitos de segurança e as coleções definem, em conjunto, o que um utilizador pode ver e gerir. Estas distinções provêm dos fundamentos de segurança do Configuration Manager.

Para a revisão, registe três caminhos de forma independente:

• Controlo da infraestrutura: identidades capazes de administrar o anfitrião do Provider, o servidor de site ou a infraestrutura da base de dados.
• Administração do produto: principais de segurança cujas permissões atribuídas permitem operações sobre determinados objetos do Configuration Manager e coleções de destino.
• Autoridade de instalação: contas com direitos nos sistemas onde o produto instala um cliente ou um componente de sistema de site.

Este é um modelo de avaliação, não uma afirmação de que todos os operadores do Configuration Manager têm administração ilimitada do Windows. Para cada caminho, estabeleça a operação concedida e o recurso afetado. Não transforme a capacidade de consultar o Provider numa conclusão de que a identidade pode efetuar implementações em todos os dispositivos.

A referência de contas do Configuration Manager da Microsoft apresenta distinções concretas. SMS Admins é um grupo local nos computadores do Provider; as suas permissões WMI podem ser inspecionadas com o snap-in MMC WMI Control. O RBAC continua a determinar o acesso aos objetos da consola. A client push installation account requer pertença ao grupo local Administrators nos clientes de destino, não ao grupo Domain Admin; na ausência de uma conta configurada, o site tenta usar a sua conta de computador. A site system installation account, distinta, requer permissões administrativas locais e o direito de utilizador de acesso pela rede nos sistemas de site de destino. A network access account serve para aceder a recursos, não como contexto de execução de software, atualizações ou sequências de tarefas.

Estas contas merecem linhas separadas, mesmo quando a mesma identidade AD desempenha mais de uma função. Uma designação como «conta de serviço» oculta a distinção entre transferir conteúdo e administrar um alvo. Inversamente, nomes de conta diferentes não estabelecem separação se receberem direitos equivalentes sobre as mesmas máquinas.

Deteção: construir a matriz de autoridade a partir de evidências do produto

Passo 1: confirmar a função real do candidato

Preserve o resultado LDAP, o DN do computador, o campo de inventário que correspondeu à heurística e a data da revisão. Peça ao responsável pelo produto para identificar a função real do candidato e o site associado. Concilie essa resposta com a configuração do produto em funcionamento e com o inventário dos anfitriões. Se for apenas um cliente, registe porque foi identificado pela heurística; não invente uma função de gestão para justificar o resultado.

Para um componente de gestão confirmado, liste os anfitriões do Provider e da base de dados de que depende, as identidades de instalação e os responsáveis administrativos. Marque as relações por esclarecer como desconhecidas. Um inventário que omita um Provider ou um sistema de site remoto pode fazer um âmbito de gestão supostamente restrito parecer mais seguro do que é.

Passo 2: ler em conjunto as funções, os âmbitos e as coleções atribuídas

Siga o procedimento de configuração da administração baseada em funções da Microsoft. Na consola, abra Administration > Security > Administrative Users, selecione o principal de segurança e abra Properties. Inspecione Security Roles e Security Scopes, incluindo a associação configurada entre funções, âmbitos e coleções. Para inspecionar as permissões de uma função sobre objetos, aceda a Administration > Security > Security Roles, selecione a função, abra Properties e escolha o separador Permissions.

Para a autoridade sobre coleções, reveja as permissões da função sobre o objeto Collection e as coleções atribuídas ao utilizador administrativo. Inclua as coleções limitadas por essas coleções atribuídas. A Microsoft também identifica o Role-based administration and auditing tool para auditar utilizadores, coleções e âmbitos.

Use essas vistas como evidências, não apenas como capturas de ecrã de nomes descritivos. Registe identificadores, as ações permitidas relevantes, as atribuições através de grupos e a pertença dos dispositivos usada na revisão. Quando essa pertença muda, o mapa de autoridade precisa de nova revisão. Uma coleção chamada «Servers» não estabelece que todos os membros pertencem ao nível de confiança pretendido.

Passo 3: inspecionar a configuração de instalação e os direitos locais nos alvos

O procedimento de implementação de clientes Windows da Microsoft fornece o caminho da consola: Administration > Site Configuration > Sites, selecionar o site e depois Client Installation Settings > Client Push Installation. Inspecione o separador Accounts e, no separador General, as definições de instalação automática, os tipos de sistema selecionados e a seleção de controladores de domínio. O procedimento também documenta a instalação push iniciada para um dispositivo ou uma coleção individual.

Leia esta configuração antes de iniciar qualquer instalação. Uma seleção de alvos configurada é evidência sobre o processo de instalação; inspecione de forma independente onde cada identidade possui efetivamente direitos administrativos locais. Distinga a client push account configurada, o recurso à conta de computador e a site system installation account.

Registe separadamente as verificações bem-sucedidas e as falhadas. Se não for possível verificar a pertença aos grupos locais num alvo, marque-o como desconhecido. Não deduza a ausência de direitos de um anfitrião indisponível, nem direitos sobre todas as máquinas de uma verificação bem-sucedida num único dispositivo representativo.

Passo 4: ligar os principais de segurança aos sistemas geridos

Crie uma linha por caminho de autoridade. A tabela seguinte é um modelo de revisão, não um ambiente descoberto nem um conjunto de permissões predefinidas:

Leia a tabela na horizontal: principal de segurança → função/conta → site/coleção → sistemas geridos. Depois pergunte que linha une níveis de confiança anteriormente separados. Reveja as atribuições combinadas em vez de considerar cada função isoladamente. Mantenha uma entrada separada para um conjunto de alvos desconhecido; uma célula vazia nunca deve significar silenciosamente «sem acesso».

Correção: alinhar a autoridade antes de alterar a colocação na OU (Remediation)

Passo 1: decidir o limite pretendido e preservar a situação inicial

Com os responsáveis pela infraestrutura e pelas identidades, defina que sistemas geridos devem ficar juntos e que caminhos administrativos devem permanecer separados. Compare esse limite pretendido com cada linha da matriz. Registe o motivo de cada divergência, o seu responsável e a evidência necessária para a resolver.

Preserve as atribuições de funções existentes, a configuração de instalação, a pertença dos alvos e as dependências operacionais antes das alterações. Escolha um piloto que contenha tanto um alvo pretendido como um sistema que deva permanecer fora da autoridade do operador. Planeie um teste funcional aprovado e uma reversão para cada alteração.

Passo 2: restringir as permissões do produto através da consola suportada

Use as propriedades do utilizador administrativo já revistas para ajustar as associações relevantes entre funções, âmbitos e coleções. Se as funções existentes concederem autoridade excessiva, use o procedimento documentado da Microsoft para funções personalizadas: copie uma função em Administration > Security > Security Roles, inspecione as suas permissões sobre objetos e atribua apenas as permissões necessárias. As permissões das funções incorporadas não podem ser editadas. Estas operações são abrangidas pelo procedimento de configuração da administração baseada em funções.

A alteração deve remover uma operação indesejada específica ou uma relação com um alvo. Verifique que a administração pretendida continua a funcionar e que o sistema excluído está fora da autoridade concedida. Mantenha a administração da infraestrutura na revisão; restringir apenas uma atribuição na consola não resolve um caminho separado de administração do anfitrião ou da base de dados.

Passo 3: separar a autoridade de instalação quando o seu alcance atravessa o limite

Para cada identidade de instalação, compare os seus direitos locais verificados com o conjunto de alvos pretendido. Proponha identidades separadas e com âmbitos adequados quando uma conta abrange vários níveis de confiança. Verifique a conta configurada no produto e as permissões concedidas em cada destino; alterar apenas um dos lados deixa a revisão incompleta.

A referência de contas da Microsoft recomenda negar explicitamente o início de sessão interativo local à client push account. Também documenta uma sequência de substituição: criar uma conta com outro nome, adicioná-la à lista configurada, dar tempo à replicação AD e depois retirar a conta antiga. Trate isto como uma migração coordenada com verificação dos direitos nos alvos, não como uma instrução para eliminar contas ou grupos em massa. A site system installation identity exige a sua própria revisão dos alvos. Siga os requisitos de conta documentados para a função efetivamente utilizada.

Passo 4: conciliar a colocação na OU, as sessões administrativas e os fluxos

Só depois de o mapa de autoridade ser coerente se deve comparar a colocação na OU, a delegação, as políticas e os pontos de entrada administrativos com o desenho pretendido. Considere em conjunto os anfitriões de gestão e as pessoas e contas que os controlam. Mover um único objeto de computador não corrige uma conta que mantém direitos sobre um conjunto de alvos não pretendido.

Reveja o transporte como um controlo separado. As verificações GPO para o transporte de metadados WSUS tratam da proteção dessa ligação; não estabelecem quem pode administrar o SMS Provider nem o que uma identidade de instalação pode controlar. Mantenha ambas as revisões, com evidências e conclusões separadas.

Passo 5: encerrar resultados com evidências e manter as exceções

Reconstrua a matriz depois do piloto e da implementação subsequente. Para cada linha alterada, anexe a nova atribuição, a pertença atual dos alvos, a evidência relevante de direitos locais e o resultado funcional. Uma exceção deve identificar a operação necessária, os sistemas afetados, o responsável, as medidas compensatórias e um evento que desencadeie nova revisão. Uma permissão por esclarecer ou um alvo inacessível permanece desconhecido.

Defina os eventos que exigem nova revisão: um novo anfitrião do Provider, sistema de site, atribuição de coleção, identidade de instalação ou nível de confiança gerido. Uma decisão sobre limites só continua defensável enquanto o mapa de autoridade que a sustenta corresponder ao ambiente em funcionamento.

Como a EtcSec deteta isto

A verificação etc-collector revista é ANSSI_R49_R50_MGMT_CATEGORIZATION, no commit do collector 15fc6399c215eabc415c370b762303cfcd7a353a. É uma heurística de inventário e de nomes, não uma auditoria de autorização do Configuration Manager.

Um computador torna-se candidato quando o seu DN corresponde a uma entrada no mgmt_systems opcional, ou quando a combinação de SAMAccountName, DNSHostName, Description e OperatingSystem, convertida para minúsculas, contém um destes marcadores: sccm, configmgr, wsus, mecm, defender, atp, mdatp, intune, jamf, ansible, salt, puppet, chef, tanium, bigfix, crowdstrike, carbonblack ou sentinelone.

Produz um resultado para candidatos cujo DN em minúsculas não contém nenhum de ou=tier0, ou=tier-0, ou=tier1, ou=tier-1, ou=admin, ou=mgmt ou ou=management. São testes de subcadeias de caracteres, não uma validação dos controlos reais de uma OU. Se nenhum candidato falhar esse teste, Detect() devolve nil.

A lista opcional mgmt_systems vem de tier0_groups.yaml. Se esse ficheiro estiver ausente, não é carregada qualquer personalização, a lista fica vazia e só se aplicam as heurísticas de nomes, sem aviso. Se o ficheiro for ilegível ou o seu YAML estiver malformado, o motor escreve um aviso em stderr e continua com os valores predefinidos. Uma entrada DN explícita acrescenta um candidato; não estabelece autoridade no produto nem substitui o teste de subcadeias da OU.

O Provider LDAP fornece os campos de inventário dos computadores. Esta verificação não recolhe permissões do SMS Provider, autoridade sobre a base de dados do site, atribuições RBAC, coleções de destino ou direitos de contas de instalação. Um nome de cliente pode corresponder; um sistema de gestão com poder real pode não ser identificado; um nome de OU pode satisfazer o teste de subcadeias sem impor isolamento.

Use o resultado para iniciar a revisão da autoridade. Resolva a questão arquitetural com as evidências do produto e dos alvos na matriz, mantendo os desconhecidos e as exceções mesmo quando a heurística de nomes já não produz um resultado.