Relações de Confiança no Active Directory Corporativo: Como Conectar Filiais, Terceiros e Processos de M&A com Segurança Máxima

Em um mercado corporativo cada vez mais dinâmico, poucas situações colocam tanta pressão sobre a liderança de Tecnologia da Informação quanto um processo de Fusão e Aquisição (M&A), a expansão acelerada para múltiplas filiais ou a necessidade urgente de integrar empresas parceiras e terceirizadas ao ecossistema produtivo.

A diretoria executiva e os investidores exigem sinergia operacional imediata: equipes comerciais precisam consultar o mesmo CRM, setores de compras precisam acessar o ERP unificado e analistas financeiros precisam consolidar relatórios hospedados em servidores de arquivos do outro lado do país. No entanto, enquanto os executivos enxergam apenas oportunidade de crescimento, a equipe de Infraestrutura e Cibersegurança enfrenta um dos maiores dilemas da gestão de identidades:

*”Como conceder acesso aos recursos críticos da nossa holding sem herdar as vulnerabilidades, os malwares, as contas zumbis e a dívida técnica da empresa adquirida ou da terceirizada?”*

A resposta tradicional — criar contas duplicadas e liberar túneis VPN irrestritos — é uma receita infalível para incidentes catastróficos de ransomware e sanções pesadas sob a LGPD.

A solução arquitetural definitiva e segura reside no domínio das Relações de Confiança (Trust Relationships) do Active Directory Domain Services (AD DS) configuradas sob o paradigma de Menor Privilégio (Least Privilege) e Autenticação Seletiva.

Neste artigo aprofundado, você entenderá a arquitetura corporativa das relações de confiança, aprenderá a desenhar conexões seguras para cenários de M&A e filiais, desmistificará a mecânica dos tíquetes Kerberos Inter-Realm e conhecerá os controles de Hardening (SID Filtering, Selective Authentication e AES-256) indispensáveis para passar em qualquer auditoria de conformidade (ISO 27001, SOC 2 e LGPD).

—

1. O Cenário Corporativo: O Dilema das Identidades Descentralizadas

Mesmo com a massiva adoção de nuvem híbrida e serviços SaaS, o Active Directory local (on-premises) continua sendo a espinha dorsal de controle de acesso a servidores de aplicação, bancos de dados legados, estações de trabalho e sistemas de arquivos em mais de 90% das médias e grandes corporações globais.

Quando duas organizações jurídicas ou divisões operacionais distintas precisam colaborar, a liderança técnica se depara com três caminhos:

A. O Modelo Amador: Proliferação de Contas Fantasma (Shadow Accounts)

Cria-se uma conta de usuário espelho na floresta da Matriz para cada colaborador da filial ou terceiro.

• O Risco Corporativo: Violação frontal da rastreabilidade. Quando um funcionário é desligado na empresa parceira, a TI da Matriz frequentemente não é notificada. Aquela credencial permanece ativa por meses — tornando-se um vetor primordial de invasão (stale credentials).

B. A Consolidação Imediata de Florestas (O Sonho Irrealista)

Migrar todos os usuários, computadores e servidores da empresa adquirida para a floresta principal em 30 dias.

• A Realidade Operacional: Projetos de consolidação de floresta levam de 6 a 24 meses em empresas de médio e grande porte. Exigem migração de perfis de usuário, reconfiguração de estações, ajustes em centenas de softwares legados e janelas de parada técnica com alto custo para o negócio.

C. A Arquitetura Federada via Relações de Confiança (Padrão Enterprise)

Manter as duas florestas ou domínios funcionando de forma independente e autônoma, estabelecendo uma ponte de autenticação criptograficamente assinada e rigorosamente auditável entre elas.

• A Vantagem: A empresa adquirida mantém a administração de suas contas locais, o ciclo de vida do usuário (provisioning/deprovisioning) permanece centralizado no seu respectivo RH, e a Matriz controla cirurgicamente quais servidores e pastas podem ser acessados através de Listas de Controle de Acesso (ACLs) granulares.

—

2. A Regra de Ouro da Confiança Corporativa: Inversão Vetorial de Fluxo

Para desenhar arquiteturas seguras e defender propostas técnicas perante a diretoria, o primeiro princípio inegociável é memorizar que a direção da confiança aponta no sentido rigorosamente inverso ao fluxo de acesso aos dados:

• Domínio Confiante (Trusting Domain / Dono do Patrimônio): É o ambiente que detém os servidores de dados, o ERP ou as bases SQL. Ele decide confiar na atestação de identidade fornecida pelo parceiro.
• Domínio Confiável (Trusted Domain / Fonte de Identidades): É o ambiente onde estão os colaboradores, prestadores de serviços e suas respectivas estações. Ele valida quem é o usuário e atesta sua autenticidade.

+------------------------------------------------------------------------------------------------+
|                                DIRETRIZ VETORIAL DE ARQUITETURA                                |
+------------------------------------------------------------------------------------------------+

 [ MATRIZ: Recursos Críticos ]  ═════════ Direção da Confiança (Trust) ════════►  [ FILIAL: Contas ]
 [ MATRIZ: Recursos Críticos ]  ◄════════ Direção do Fluxo de Acesso ════════════  [ FILIAL: Contas ]

 Regra: A Matriz CONFIA na autenticação da Filial. Os usuários da Filial ACESSAM a Matriz.
+------------------------------------------------------------------------------------------------+

🏢 **Mnemônica Hora Nerd para CIOs e Gestores:** Imagine uma empresa contratando uma **empresa de transporte de valores terceirizada**. A holding (Recursos) *confia* na credencial emitida pela transportadora (Contas). O funcionário da transportadora pode entrar na sala de cofres autorizada da holding, mas nenhum funcionário da holding tem permissão para entrar nas garagens privadas da transportadora.

—

3. Arquitetura 1: Confiança Unidirecional para Prestadores de Serviço, Terceiros e Filiais de Risco

A relação de confiança unidirecional (One-Way Trust) é a ferramenta prioritária para aplicar o princípio de Defesa em Profundidade (Defense-in-Depth) e isolamento de perímetro.

flowchart LR
    subgraph Matriz["🏢 Matriz / Holding (Trusting / Recursos)"]
        direction TB
        ERP["🖥️ SAP / ERP Corporativo"]
        FS["📁 File Server Financeiro"]
    end

    subgraph Terceiro["🏭 Terceirizada / Filial Remota (Trusted / Contas)"]
        direction TB
        Prestador["👤 Consultor_Externo"]
        UserFilial["👤 Operador_Fabrica"]
    end

    Matriz -- "1. Trust Unidirecional (Matriz confia em Terceiro)" --> Terceiro
    Prestador -. "2. Acesso pontual restrito via ACL" .-> ERP
    UserFilial -. "3. Leitura autorizada" .-> FS

    style Matriz fill:#0f172a,stroke:#38bdf8,stroke-width:2px,color:#f8fafc
    style Terceiro fill:#0f172a,stroke:#f59e0b,stroke-width:2px,color:#f8fafc
    style ERP fill:#1e293b,stroke:#38bdf8,color:#f8fafc
    style FS fill:#1e293b,stroke:#38bdf8,color:#f8fafc
    style Prestador fill:#1e293b,stroke:#f59e0b,color:#f8fafc
    style UserFilial fill:#1e293b,stroke:#f59e0b,color:#f8fafc

Dinâmica de Proteção em Casos Reais:

1. Contenção Total do Raio de Explosão (Blast Radius): Se a empresa terceira for atingida por um ataque cibernético massivo ou ransomware em suas estações de trabalho, o atacante não consegue utilizar a relação de confiança para invadir a Matriz, porque o domínio do terceiro não confia na Matriz, e nenhuma conta da Matriz possui tíquete válido para transitar em direção ao terceiro.
2. Ambientes de Fábricas e Filiais sem Segurança Física: Filiais com servidores alocados em racks simples sem vigilância física armada ou biometria devem residir em domínios isolados. A Matriz consome dados deles ou disponibiliza sistemas centrais via confiança unidirecional, impedindo que o roubo físico de um controlador de domínio local comprometa as credenciais do conselho administrativo na Matriz.
3. Zonas DMZ e Aplicações Web B2B: Portais de fornecedores hospedados em DMZ nunca devem pertencer à floresta corporativa principal. Cria-se uma floresta de perímetro que estabelece trust unidirecional com o domínio interno.

—

4. Arquitetura 2: Confiança Bidirecional em Processos de M&A (Fusões e Aquisições)

Em aquisições societárias, onde ambas as empresas são maduras e precisam de cooperação simétrica e imediata entre diretorias, times jurídicos e plataformas compartilhadas, a confiança bidirecional (Two-Way Forest Trust) é o acelerador financeiro do negócio.

flowchart LR
    subgraph Holding["🏢 Holding Adquirente (Floresta A)"]
        direction TB
        HoldingData["🗄️ Datacenter Matriz & PowerBI"]
        HoldingUser["👔 Diretores & Engenheiros"]
    end

    subgraph Adquirida["🏢 Empresa Adquirida (Floresta B)"]
        direction TB
        AdquiridaData["🗄️ ERP Industrial & Legados"]
        AdquiridaUser["👔 Equipe Operacional"]
    end

    Holding <--> |"Relação de Confiança Mútua (Two-Way Forest Trust)"| Adquirida
    HoldingUser <.-.-> |"Colaboração Cruzada com Autenticação Kerberos"| AdquiridaData
    AdquiridaUser <.-.-> |"Acesso a Sistemas Centrais sob Governança"| HoldingData

    style Holding fill:#0f172a,stroke:#38bdf8,stroke-width:2px,color:#f8fafc
    style Adquirida fill:#0f172a,stroke:#10b981,stroke-width:2px,color:#f8fafc
    style HoldingData fill:#1e293b,stroke:#38bdf8,color:#f8fafc
    style HoldingUser fill:#1e293b,stroke:#38bdf8,color:#f8fafc
    style AdquiridaData fill:#1e293b,stroke:#10b981,color:#f8fafc
    style AdquiridaUser fill:#1e293b,stroke:#10b981,color:#f8fafc

Ganhos Estratégicos Imediatos:

• Tempo até a Geração de Valor (Time-to-Value): Em vez de paralisar as operações por meses aguardando consolidação, os funcionários da empresa adquirida começam a emitir faturamento e interagir com as lideranças no dia seguinte à homologação do trust.
• Transição Gradual sem Interrupção do Negócio: A equipe de infraestrutura ganha tranquilidade para planejar a migração de caixas postais, migração de arquivos e sincronização com o Microsoft Entra ID (antigo Azure AD) sem que a operação sofra apagões.

—

5. Sob o Capô: O Protocolo Kerberos e a Mecânica Inter-Realm

Uma das maiores dúvidas dos auditores de segurança é: “Se as duas empresas estão conectadas por trust, a senha do usuário da empresa B viaja pela rede da empresa A?”

A resposta é categórica: Não. O protocolo Kerberos v5 foi desenhado especificamente para impedir a trafegação de credenciais ou hashes de senha entre diferentes domínios. A autenticação cruzada ocorre por meio do mecanismo de Tíquetes de Referência Inter-Realm (Referral Tickets).

[ Usuário na Filial B ]
       │
       ├── 1. Requisita TGS para \\servidor.matrizA.local ─────────► [ KDC / DC Filial B ]
       │                                                                   │
       │◄── 2. Recebe TGT de Referência (Criptografado com Chave Trust) ───┘
       │
       ├── 3. Apresenta TGT de Referência ao DC da Matriz ────────► [ KDC / DC Matriz A ]
       │                                                                   │
       │◄── 4. Valida Chave Compartilhada e Emite TGS de Serviço ──────────┘
       │
       └── 5. Apresenta TGS assinado e acessa a aplicação ────────► [ Servidor da Matriz A ]

O Passo a Passo Técnico:

1. O usuário no Domínio B solicita ao seu Controlador de Domínio local (KDC B) um tíquete para acessar o recurso no Domínio A.
2. O KDC B percebe que o sufixo DNS pertence a outro domínio. Em vez de negar o acesso, ele verifica o objeto de trust e emite um TGT de Referência (Referral TGT). Esse tíquete é criptografado usando uma senha compartilhada exclusiva criada entre os dois domínios (a conta fiduciária interdomínio DOMINIO_A$).
3. O cliente do usuário entrega esse Referral TGT diretamente a um Controlador de Domínio do Domínio A.
4. O DC do Domínio A descriptografa o tíquete com sua cópia da chave do trust, verifica a identidade, aplica as regras de Filtragem de SID e emite o tíquete final de concessão de serviço (TGS).
5. O cliente apresenta o TGS ao servidor de destino, que valida a assinatura criptográfica e concede o acesso conforme a ACL local.

—

6. Hardening de Segurança e Conformidade: O Que Você NÃO Pode Negligenciar

Conectar florestas corporativas sem controles avançados de segurança é o equivalente a derrubar os muros do seu datacenter. Para atender às exigências de conformidade da LGPD (Art. 46 – Medidas Técnicas de Segurança), ISO/IEC 27001 (Controles A.9.1 e A.9.2) e CIS Controls v8, três proteções são de aplicação mandatória:

A. Filtragem de SID (SID Filtering / Quarentena) — A Defesa contra Golden Tickets

No Active Directory, as permissões são vinculadas ao SID (Security Identifier) do usuário e dos seus grupos. O atributo sIDHistory foi criado pela Microsoft para facilitar migrações, permitindo que um usuário retenha privilégios de seu domínio antigo.

Porém, se a quarentena de SIDs estiver desabilitada, um invasor que obtenha privilégio de Domain Admin na floresta da filial/parceira pode forjar um tíquete Kerberos injetando no sIDHistory o SID S-1-5-21-...-512 (Domain Admins da Matriz). Ao passar pelo trust, ele se tornaria Administrador da Matriz instantaneamente.

🛡️ **Diretriz de Conformidade:** Em qualquer relação de confiança externa ou entre florestas com empresas parceiras, **o SID Filtering deve permanecer estritamente habilitado** (`EnableSIDFiltering = $true`). Caso precise utilizar `sIDHistory` durante uma janela de migração de M&A, faça-o de forma temporária, controlada e monitorada por SIEM.

B. Autenticação Seletiva (Selective Authentication) — O Paradigma Zero Trust

Por padrão, ao criar um Forest Trust com a opção Forest-wide authentication, qualquer usuário autenticado da empresa parceira ganha automaticamente o grupo NT AUTHORITY\Authenticated Users dentro dos servidores da sua empresa. Isso permite que qualquer pessoa da outra ponta faça varreduras de rede, resolva nomes via LDAP e enumere recursos compartilhados.

Para ambientes corporativos que exigem isolamento regulatório:
1. Configure o trust com Autenticação Seletiva (Selective Authentication).
2. Com isso ativado, o Kerberos bloqueia preventivamente qualquer emissão de tíquete de serviço para contas externas.
3. Para liberar o acesso a um servidor específico (ex: SRV-SAP-01), o administrador da Matriz deve abrir o objeto de computador no console do AD, acessar a aba Segurança e conceder explicitamente ao grupo do parceiro a permissão especial “Permitido Autenticar” (Allowed to Authenticate).

C. Imposição de Criptografia AES-256 e Depreciação de RC4/NTLM

Trusts antigos frequentemente operam utilizando algoritmos legados como RC4-HMAC para compatibilidade com versões antigas do Windows Server. O RC4 é vulnerável a ataques offline de desassociação de hash (Kerberoasting e AS-REP Roasting).

• É mandatório habilitar a flag The other domain supports Kerberos AES Encryption em ambos os lados do trust.
• Rejeitar solicitações de autenticação baseadas exclusivamente em NTLM em favor de Kerberos assinado via AES-256.

—

7. Mão na Massa: Script PowerShell Corporativo para Auditoria e Diagnóstico de Trusts

Auditorias de segurança não aceitam respostas baseadas em suposições. O script abaixo foi desenhado para analistas seniores e consultores auditarem o estado de saúde, criptografia e segurança de todas as relações de confiança de um ambiente empresarial.

Salve o script como Auditoria-ADTrust-Enterprise.ps1 e execute em um Controlador de Domínio ou estação de gerenciamento com RSAT instalado:

<#
.SYNOPSIS
    Script de Auditoria Executiva de Relações de Confiança no Active Directory
.DESCRIPTION
    Verifica estado, direção, filtragem de SID, autenticação seletiva,
    algoritmos de criptografia e saúde do canal seguro (Secure Channel).
.AUTHOR
    Hora Nerd - Consultoria em Infraestrutura e Segurança
#>

[CmdletBinding()]
param()

Clear-Host
Write-Host "=================================================================" -ForegroundColor Cyan
Write-Host "      HORA NERD: AUDITORIA CORPORATIVA DE RELAÇÕES DE CONFIANÇA  " -ForegroundColor Cyan
Write-Host "=================================================================" -ForegroundColor Cyan
Write-Host "Executando em: $(Get-Date -Format 'dd/MM/yyyy HH:mm:ss')" -ForegroundColor DarkGray
Write-Host ""

try {
    $CurrentDomain = (Get-ADDomain).DNSRoot
    Write-Host "[+] Domínio Atual Local: $CurrentDomain" -ForegroundColor Green
    
    $Trusts = Get-ADTrust -Filter *
    
    if (-not $Trusts) {
        Write-Warning "[!] Nenhuma relação de confiança detectada no domínio $CurrentDomain."
        return
    }

    $AuditReport = foreach ($Trust in $Trusts) {
        Write-Host "[-] Analisando trust com: $($Trust.Name)..." -ForegroundColor Yellow
        
        # Testar saúde do Secure Channel via nltest
        $NetlogonTest = & nltest /sc_query:$($Trust.Name) 2>&1
        $ChannelStatus = if ($LASTEXITCODE -eq 0) { "Saudável (OK)" } else { "Falha de Canal" }

        # Validar quarentena de SID (SID Filtering)
        $SIDFiltering = if ($Trust.SidFilteringQuarantined) { "Habilitado (Seguro)" } else { "DESABILITADO (Risco)" }
        
        # Validar Autenticação Seletiva
        $SelectiveAuth = if ($Trust.SelectiveAuthentication) { "Ativa (Zero Trust)" } else { "Forest-Wide (Padrão)" }

        # Validar Criptografia AES
        $AESEnc = if ($Trust.TGTDelegationEnabled -or $Trust.UsesAESKeys) { "AES Habilitado" } else { "Possível RC4 Legado" }

        [PSCustomObject]@{
            "Parceiro / Alvo"      = $Trust.Name
            "Direção"              = $Trust.Direction
            "Tipo de Confiança"    = $Trust.TrustType
            "SID Filtering"        = $SIDFiltering
            "Autenticação"         = $SelectiveAuth
            "Canal Seguro"         = $ChannelStatus
            "Criptografia"         = $AESEnc
        }
    }

    Write-Host ""
    Write-Host "[✓] RELATÓRIO EXECUTIVO DE CONFORMIDADE:" -ForegroundColor Green
    $AuditReport | Format-Table -AutoSize

    Write-Host "Dica de Mitigação:" -ForegroundColor DarkCyan
    Write-Host "Para forçar SID Filtering em um trust externo:" -ForegroundColor DarkGray
    Write-Host "netdom trust $CurrentDomain /domain:<NomeParceiro> /quarantine:yes`n" -ForegroundColor DarkYellow

} catch {
    Write-Error "Erro durante a auditoria: $_"
}

Interpretação dos Resultados para Relatório de Compliance:

• Canal Seguro com “Falha de Canal”: Indica que os controladores de domínio não estão conseguindo resolver nomes DNS ou as portas de RPC/Kerberos (porta 88 TCP/UDP, 389 TCP/UDP, 445 TCP e portas altas dinâmicas) estão bloqueadas por firewalls corporativos.
• SID Filtering “DESABILITADO”: Apontamento crítico de auditoria que deve ser corrigido imediatamente antes de qualquer assinatura de termo de homologação de M&A.

—

8. Matriz de Decisão Executiva para CTOs, CISOs e Gerentes de Infraestrutura

Utilize a tabela estratégica abaixo para embasar reuniões de planejamento de arquitetura e aprovações perante comitês de segurança:

—

9. Conclusão: A Confiança Técnica Sustenta a Expansão do Negócio

As Relações de Confiança no Active Directory não são apenas um recurso técnico do Windows Server: elas são viabilizadoras estratégicas de negócios.

Quando bem planejadas e implementadas com os controles de SID Filtering, Autenticação Seletiva e Criptografia AES-256, elas permitem que empresas adquiram concorrentes, abram novas filiais e terceirizem serviços críticos com velocidade recorde, mantendo conformidade integral com a LGPD e blindagem contra incidentes cibernéticos.

—

✓

Guilherme Nascimento

Especialista & Fundador

Especialista em Infraestrutura, Cloud/DevOps e Cibersegurança | +10 anos de experiência prática

Profissional com mais de uma década atuando no campo de batalha da tecnologia corporativa. Especialista em arquiteturas resilientes, automação com Docker/Kubernetes, Hardening de Active Directory, Linux avançado e observabilidade SRE. Criador do ecossistema Hora Nerd, dedicado a desmistificar a tecnologia para profissionais e estudantes.

Cloud & DevOps Active Directory Hardening Linux SysAdmin Docker & CI/CD Observabilidade SRE

Conectar no LinkedIn GitHub