Data/Locales/checks/pt/TierZeroChecks.json
|
{ "_family": "TierZeroChecks.json", "ADTIER-001": { "name": { "value": "Auditoria da conta de sincronização do Azure AD Connect (MSOL_)", "status": "machine-draft" }, "description": { "value": "Quando o Azure AD Connect é instalado em modo Express, cria uma conta de domínio com o nome MSOL_<hex-aleatório> e concede-lhe os direitos Replicating Directory Changes + Replicating Directory Changes All no contexto de nomenclatura do domínio, ou seja, direitos de DCSync. A conta é efetivamente Tier-0, mas por predefinição reside no contentor Users predefinido, tem uma validade de palavra-passe de 10 anos e raramente aparece nas ferramentas de enumeração de grupos privilegiados, pois obtém o seu poder através de uma ACL direta e não da pertença a grupos. O comprometimento desta conta equivale, na prática, a uma tomada de controlo do domínio.", "status": "machine-draft" }, "recommendedValue": { "value": "Todas as contas MSOL_ estão inventariadas, com a palavra-passe rodada nos últimos 180 dias, colocadas numa OU Tier-0 com direitos de início de sessão restritos, e o próprio servidor AAD Connect está protegido como um sistema Tier-0.", "status": "machine-draft" }, "remediationSteps": { "value": "Localize a conta MSOL_: Get-ADUser -Filter {sAMAccountName -like 'MSOL_*'}. Confirme que tem direitos de DCSync: dsacls 'DC=domain,DC=com' | findstr MSOL_. Mova-a para uma OU de administração Tier-0. Rode a palavra-passe utilizando as ferramentas do AAD Connect (NÃO efetue o reset através das ferramentas padrão: utilize Add-ADSyncADDSConnectorAccount no módulo PowerShell ADSync no servidor AAD Connect). Aplique um GPO de restrição de início de sessão para que a conta só possa iniciar sessão localmente no próprio servidor AAD Connect. Trate o anfitrião do AAD Connect como Tier-0: restrinja quem pode aceder-lhe por RDP ou administrá-lo.", "status": "machine-draft" } }, "ADTIER-002": { "name": { "value": "Contas de serviço de software de cópia de segurança em grupos privilegiados", "status": "machine-draft" }, "description": { "value": "O software de cópia de segurança (Veeam, Commvault, Rubrik, Cohesity, NAKIVO, Backup Exec, Vembu, Acronis) pede normalmente uma conta de serviço com permissões muito elevadas. A documentação sugere frequentemente Domain Admin para facilitar a configuração, e muitos administradores cumprem. Assim que um atacante compromete o servidor de cópia de segurança (um vetor frequente de acesso inicial de ransomware), herda o Domain Admin através da conta de serviço. Este é o caminho de elevação de ransomware nº 1 nos dados de resposta a incidentes de 2023 a 2025.", "status": "machine-draft" }, "recommendedValue": { "value": "Nenhuma conta de serviço de software de cópia de segurança é membro de Domain Admins, Enterprise Admins, Schema Admins ou Backup Operators. Utilize contas de privilégio mínimo documentadas pelo fornecedor e credenciais de cópia de segurança isoladas.", "status": "machine-draft" }, "remediationSteps": { "value": "Identifique o produto de cópia de segurança em uso e siga o respetivo guia de privilégio mínimo (Veeam: apenas administrador local do servidor de cópia de segurança + conta de AD com leitura de objetos; Rubrik: principal de serviço dedicado numa função exclusiva da cloud; etc.). Remova a conta de cópia de segurança de Domain Admins. Migre para um gMSA sempre que suportado. Coloque o servidor de cópia de segurança numa OU Tier-1 com direitos de início de sessão restritos. Se for genuinamente necessário DA completo para uma carga de trabalho específica, documente-o e isole essa parte da cópia de segurança na sua própria conta, separada da principal.", "status": "machine-draft" } }, "ADTIER-003": { "name": { "value": "Contas de serviço de hipervisor / virtualização em grupos privilegiados", "status": "machine-draft" }, "description": { "value": "As integrações do vCenter / Hyper-V / SCVMM / Citrix / Nutanix com o AD utilizam frequentemente uma conta de serviço configurada durante a instalação. Se essa conta for um Domain Admin, o comprometimento do plano de gestão do hipervisor (ou da base de dados de SSO do anfitrião) propaga-se em cascata para o AD. O hipervisor já é conceptualmente Tier-0; a sua identidade no AD deve corresponder a isso.", "status": "machine-draft" }, "recommendedValue": { "value": "As contas de serviço do hipervisor têm apenas os direitos documentados pelo fornecedor (normalmente leitura para inventário + escritas específicas numa OU se a integração VM-AD estiver em uso). Não estão em Domain Admins.", "status": "machine-draft" }, "remediationSteps": { "value": "Reveja a conta de serviço de AD de cada produto de hipervisor. Aplique as orientações de privilégio mínimo do fornecedor. Para o vCenter: utilize o padrão documentado de origem de identidade SSO em vez de mapear um Domain Admin. Para o Hyper-V/SCVMM: limite os direitos da conta de serviço às OU que alojam as contas de computador das VM. Trate o anfitrião de gestão do hipervisor como Tier-0 no seu modelo administrativo.", "status": "machine-draft" } }, "ADTIER-004": { "name": { "value": "Contas de serviço de gestão de configuração em grupos privilegiados", "status": "machine-draft" }, "description": { "value": "As plataformas de gestão de configuração (SCCM/MECM, Intune Connector, Jamf, KACE, Lansweeper, ManageEngine, Ivanti, BigFix) distribuem software a todos os endpoints por definição: são já uma plataforma privilegiada de movimento lateral. O SCCM, em particular, tem primitivas de abuso bem conhecidas (exposição da Network Access Account, coerção NTLM até ao servidor de site, client push). Uma conta de serviço de gestão de configuração em Domain Admins dá a um atacante que aterre em qualquer endpoint gerido as chaves do domínio.", "status": "machine-draft" }, "recommendedValue": { "value": "As contas de serviço de gestão de configuração estão limitadas aos direitos mínimos documentados e nunca em Domain Admins / Enterprise Admins. A Network Access Account do SCCM é uma identidade dedicada não privilegiada.", "status": "machine-draft" }, "remediationSteps": { "value": "Identifique o produto de gestão de configuração e reveja os direitos da conta de serviço. Para o SCCM: garanta que a Network Access Account é não privilegiada (NÃO é um Domain Admin); garanta que a conta de máquina do servidor de site não é um Domain Admin; reveja as contas de serviço da hierarquia quanto ao privilégio mínimo. Mova os servidores de site e os pontos de gestão para uma OU Tier-0 com inícios de sessão restritos.", "status": "machine-draft" } }, "ADTIER-005": { "name": { "value": "Contas de serviço de SQL / base de dados em grupos privilegiados", "status": "machine-draft" }, "description": { "value": "As contas de serviço de SQL Server / MySQL / PostgreSQL em Domain Admins são comuns em ambientes onde a equipa de DBA instalou o SQL com a orientação predefinida 'Use existing AD account' e escolheu uma conta de administrador por conveniência. Assim que o servidor de base de dados fica acessível na rede, um comprometimento de credenciais de SQL ou uma vulnerabilidade do SQL Server dá ao atacante Domain Admin diretamente.", "status": "machine-draft" }, "recommendedValue": { "value": "As contas de serviço de base de dados são executadas como gMSA ou como identidades de serviço dedicadas sem pertença a grupos privilegiados.", "status": "machine-draft" }, "remediationSteps": { "value": "Migre as contas de serviço de SQL para gMSA sempre que suportado. Para as contas que têm de permanecer baseadas em utilizador, remova a pertença a grupos privilegiados e conceda apenas os direitos locais de que o motor de base de dados necessita (Log on as a service, Bypass traverse checking, Adjust memory quotas for a process: consulte a documentação da Microsoft para os direitos específicos).", "status": "machine-draft" } }, "ADTIER-006": { "name": { "value": "Contas de administração Tier-0 fora de uma OU Tier-0 dedicada", "status": "machine-draft" }, "description": { "value": "Se os seus Domain Admins residirem na mesma OU que os utilizadores normais, todos os GPO que visam utilizadores (scripts de início de sessão, política do browser, unidades mapeadas, etc.) também se aplicam aos seus Domain Admins: isto significa que qualquer pessoa que possa editar esses GPO pode executar código como Domain Admin no próximo início de sessão. O modelo em camadas da Microsoft recomenda uma OU de administração Tier-0 dedicada com autoria de GPO restrita e direitos de início de sessão restritos.", "status": "machine-draft" }, "recommendedValue": { "value": "Todos os membros de Domain Admins, Enterprise Admins e Schema Admins estão numa OU Tier-0 dedicada (normalmente OU=Tier-0,OU=Admin) com autoria de GPO restrita.", "status": "machine-draft" }, "remediationSteps": { "value": "Crie OU=Tier-0,OU=Admin se não existir. Mova para ela todos os membros de Domain/Enterprise/Schema Admins. Restrinja a autoria de GPO nessa OU (apenas os próprios administradores Tier-0). Aplique um GPO de restrição de início de sessão dedicado para que as contas Tier-0 só possam iniciar sessão em anfitriões Tier-0. Bloqueie a herança na OU.", "status": "machine-draft" } }, "ADTIER-007": { "name": { "value": "Contas de serviço com direitos de início de sessão interativo através de grupo privilegiado", "status": "machine-draft" }, "description": { "value": "As contas de serviço que são membros de Domain Admins (ou de qualquer grupo a que seja concedido 'Permitir início de sessão local' através da pertença predefinida a grupos privilegiados) podem ser utilizadas interativamente. Os atacantes adoram isto: capturam a palavra-passe de uma conta de serviço (Kerberoasting, registo, scripts no SYSVOL), utilizam-na interativamente numa estação de trabalho, extraem o LSASS e fazem pivô. As contas de serviço não devem conseguir iniciar sessão interativamente em nada além do anfitrião que servem.", "status": "machine-draft" }, "recommendedValue": { "value": "Às contas de serviço (heurística: sAMAccountName começa por svc/sa/service ou tem SPN + sem início de sessão interativo recente) são explicitamente negados 'Permitir início de sessão local' e 'Permitir início de sessão através dos Serviços de Ambiente de Trabalho Remoto' através da Política de Controladores de Domínio Predefinida e de um GPO de restrição de início de sessão Tier-1/Tier-2 dedicado.", "status": "machine-draft" }, "remediationSteps": { "value": "Identifique as contas de serviço (com SPN, por convenção de nomenclatura ou por inventário de negócio). Aplique um GPO de Política de Domínio Predefinida: Configuração do Computador > Definições do Windows > Definições de Segurança > Políticas Locais > Atribuição de Direitos de Utilizador > 'Negar início de sessão local' = <grupo-de-contas-de-serviço>. Adicione as mesmas contas a 'Negar início de sessão através dos Serviços de Ambiente de Trabalho Remoto'. Adicione-as a Protected Users onde for suportado (Server 2012 R2+).", "status": "machine-draft" } } } |