Arquitetura Operacional de Gestão de Identidades e Acessos (IAM) Resiliente a Ameaças em Infraestruturas Heterogêneas: Modelagem, Implementação e Avaliação Empírica

1. Introduction

A gestão de identidades e acessos (IAM) tornou-se, no período até 2006, elemento central na proteção de infraestruturas corporativas compostas por diretórios LDAP (OpenLDAP, Sun Directory Server), domínios Microsoft Active Directory (AD) com Kerberos/NTLM, proxies de acesso web e federações emergentes com SAML 1.1 e Shibboleth (OASIS, 2003; INTERNET2/MACE, 2005). O aumento de conectividade via VPNs IPsec e a exposição de serviços internos a parceiros e fornecedores ampliaram, de forma substantiva, a superfície de ataque, deslocando o foco de defesa exclusivamente perimetral para controles de autenticação forte, autorização criteriosa e auditoria contínua (CHECK POINT, 2003; RUSSELL; KIRKWOOD; BROWN, 2002).

Relatórios técnicos contemporâneos apontaram que incidentes frequentes decorriam de fragilidades em credenciais (senhas fracas, reuso, hashes LM expostos), má configuração de diretórios, falta de segregação de funções e monitoração insuficiente (SYMANETC, 2006; SANS INSTITUTE, 2005). Worms como Blaster (2003) e Sasser (2004) evidenciaram que campanhas automatizadas podem, em minutos, propagar-se em redes internas e abrir caminho para coleta de credenciais e escalonamento de privilégios, sobretudo quando combinado com ferramentas de captura de autenticação Windows e quebra offline (OECHSLIN, 2003; HELLMAN, 1980). No ecossistema Windows, o próprio comprometimento de estações facilita a coleta de hashes NTLM e sua reutilização em relays ou replays, além de facilitar ataques contra fluxos Kerberos caso chaves de contas de serviço e controladores de domínio sejam indevidamente expostas (RFC 4120, 2005; MICROSOFT, 2003).

Partimos de uma formulação de risco centrada na identidade. Definimos, para cada identidade $i$, o risco como: $$ R_i = P_c(i) \times I_i, $$ em que $P_c(i)$ é a probabilidade de comprometimento da identidade $i$ e $I_i$ é o impacto ligado aos privilégios efetivos e à capacidade de alcance dessa identidade. Reduzimos $P_c(i)$ por meio de autenticação forte (cartão inteligente PKI; tokens OTP), higiene de credenciais, e endurecimento de protocolos, e atenuamos $I_i$ via segmentação de privilégios (RBAC com restrições XACML) e microsegmentação de rede.

As contribuições deste trabalho são:

1. um modelo formal para mensuração de risco de identidades com métricas operacionais (superfície de privilégio $S_p$ e tempo médio de detecção, MTTD);
2. uma arquitetura de IAM factível com tecnologias disponíveis até 2006, integrando PKI, Kerberos, SAML 1.1, XACML 2.0, IDS/HIDS e SIEM;
3. uma avaliação experimental com ataques e ferramentas da época (Nmap, Nessus, Metasploit 2.7, pwdump/fgdump, John the Ripper), quantificando reduções de risco; e
4. um estudo de caso em ambiente corporativo realista, com análise de governança e conformidade (ISO/IEC 27001:2005; ISO/IEC 17799:2005).

2. Background and Related Work

O controle de acesso baseado em papéis (RBAC) consolidou-se como paradigma canônico na década de 1990, com formalização por Sandhu et al. (SANDHU et al., 1996) e posterior padronização pelos modelos NIST de início dos anos 2000. Em termos de autenticação, a base criptográfica dominante inclui RSA e AES (FIPS 197, 2001), com autenticação de rede via Kerberos v5 (RFC 4120, 2005) e TLS 1.0 (RFC 2246, 1999). Para reforço de identidade, a adoção de tokens de senha descartável (OTP) e smart cards baseados em PKI cresceu, especialmente no contexto do padrão FIPS 201 (PIV) para identificação pessoal (FIPS 201, 2005). O NIST SP 800-63, em sua versão inicial de 2004, definiu níveis de garantia eletrônica e boa prática de autenticação (NIST, 2004).

No plano de federação, SAML 1.1 viabilizou integrações entre domínios administrativos por meio de assertions e protocolos padronizados (OASIS, 2003), com adoção fomentada por projetos como Shibboleth (INTERNET2/MACE, 2005) e Liberty Alliance (LIBERTY ALLIANCE, 2003). Em autorização, o XACML (OASIS, 2005) tornou possível expressar políticas ricas baseadas em atributos e contexto, complementando RBAC. Para o ciclo de vida de identidades, o SPML 2.0 endereçou a padronização de provisão (OASIS, 2006).

A detecção de intrusões, conforme o arcabouço seminal de Denning (DENNING, 1987), evoluiu para sensores de rede (Bro, Snort) e host (HIDS) com correlação em plataformas SIEM emergentes como OSSIM e produtos comerciais da época (PAXSON, 1999; ROESCH, 1999; OSSIM, 2006). Em 2005–2006, relatórios como o Symantec Internet Security Threat Report destacaram a persistência de vetores ligados a credenciais e vulnerabilidades exploráveis remotamente (SYMANDTEC, 2006). Técnicas de quebra rápida de senhas via trade-offs tempo-memória e tabelas arco-íris receberam atenção especial após CRYPTO 2003 (OECHSLIN, 2003; HELLMAN, 1980), com ferramentas de auditoria como John the Ripper tornando-se padrão de mercado.

No ecossistema Windows, pesquisas e ferramentas indicaram riscos práticos de reutilização de autenticações (SMB relay), extração de hashes (pwdump/fgdump) e exploração de canais de autenticação legados (SIR DYSTIC, 2001; OXID.IT, 2006). Em paralelo, hardening de Kerberos e adoção de PKINIT (RFC 4556, 2006) foram propostos para elevar a segurança de autenticação (RFC 4556, 2006; MICROSOFT, 2003).

Este trabalho se assenta sobre essa base e a integra numa arquitetura operacionalmente realizável em 2006, com formalização matemática e validação empírica.

3. Threat Model and Problem Formalization

Modelamos um adversário com acesso a uma estação corporativa, obtido por spear phishing rudimentar (e-mails com anexos maliciosos comuns à época) ou por infecção por worms explorando serviços vulneráveis (SANS INSTITUTE, 2005; SYMANTEC, 2006). As capacidades consideradas incluem:

• varredura e descoberta de serviços (Nmap) (FYODOR, 1997);
• exploração de serviços vulneráveis selecionados em ambiente de laboratório controlado (Metasploit 2.7) (METASPLOIT, 2004);
• coleta de autenticações Windows/NTLM e extração de hashes LM/NTLM de estações sob controle (pwdump/fgdump) (OXID.IT, 2006);
• quebra offline de senhas por dicionário, força bruta e tabelas arco-íris (John the Ripper; OECHSLIN, 2003);
• replay/relay em protocolos de autenticação legados e tentativas de elevação de privilégios por configuração incorreta (SIR DYSTIC, 2001).

Representamos a superfície de privilégio como: $$ S_p = \sum_{i=1}^{n} Priv_i \times Reach_i, $$ em que $Priv_i \in \mathbb{R}^+$ representa um escore de privilégio efetivo (papéis, grupos e capacidades) da identidade $i$ e $Reach_i \in \mathbb{R}^+$ representa o alcance lateral possível considerando a topologia de rede e as relações de confiança. Alternativamente, em termos de grafo de acesso $G=(V,E)$, com vértices $V$ representando identidades e recursos e arestas $E$ etiquetadas por capacidades, podemos aproximar $Reach_i$ pela soma ponderada de comprimentos mínimos de caminhos ($d$) de $i$ a um subconjunto de ativos críticos $C \subset V$: $Reach_i \approx \sum_{c \in C} w_c \cdot \frac{1}{1+d(i,c)}$, com pesos $w_c$ representando valor do ativo.

Para detecção, definimos o tempo médio de detecção (MTTD) como: $$ MTTD = \frac{1}{m}\sum_{k=1}^{m} (t_{det,k} - t_{init,k}), $$ onde $t_{init,k}$ é o instante de início do incidente $k$ (por exemplo, primeira tentativa autenticada suspeita) e $t_{det,k}$ é o instante do primeiro alerta correlacionado gerado pelo SIEM.

O objetivo é minimizar simultaneamente $S_p$ e $MTTD$, sujeitando-se à restrição de usabilidade $U \geq U_{min}$, com $U$ mensurado por métricas como taxa de falhas de login aceitáveis e latência de autenticação, em conformidade com NIST SP 800-63 (NIST, 2004). O risco por identidade permanece: $$ R_i = P_c(i)\cdot I_i, $$ com $I_i$ proporcional a $Priv_i$ e $Reach_i$, e $P_c(i)$ reduzido por autenticação forte, higiene de credenciais e hardening de protocolos (RFC 4120, 2005; FIPS 201, 2005).

4. Proposed Methodology

Estruturamos a arquitetura em cinco camadas complementares, intencionalmente limitadas a tecnologias disponíveis até 2006.

1. Governança e inventário de identidades:

• Descoberta e reconciliação de contas por meio de consultas LDAP periódicas a OpenLDAP e AD (OPENLDAP, 2005; MICROSOFT, 2003).
• Padronização de processos de provisão e desprovisão pela adoção de SPML 2.0 em conectores de recursos críticos (OASIS, 2006).
• Consolidação de trilhas de auditoria em servidor syslog-ng e SIEM open source (OSSIM) com normalização e correlação de eventos (OSSIM, 2006).

2. Autenticação forte:

• Cartões inteligentes integrados à PKI corporativa (FIPS 201) e a fluxos Kerberos com PKINIT (RFC 4556, 2006), bem como logon por smart card no AD (MICROSOFT, 2003).
• Tokens OTP (RSA SecurID ou equivalentes) integrados a RADIUS para VPN e aplicativos web (NIST, 2004).
• Endurecimento de TLS (RFC 2246, 1999) com cifras fortes e certificação X.509 robusta (FIPS 197, 2001).

3. Autorização com RBAC e restrições por XACML 2.0:

• Política de acesso centralizada: PDP/PEP implementados com SunXACML e agentes em aplicações web (OASIS, 2005).
• Expressão de restrições contextuais (horário comercial, sub-rede de origem, estado do dispositivo) para reduzir $I_i$ e $Reach_i$.

4. Controle de sessão adaptativo por heurísticas:

• Reautenticação condicional baseada em heurísticas determinísticas, computando escore de risco de sessão: $$ Score = \alpha \cdot F_{falhas} + \beta \cdot G_{origem} + \gamma \cdot H_{hora}, $$ em que $F_{falhas}$ é função das falhas de autenticação recentes, $G_{origem}$ avalia desvio geográfico/rede de origem (e.g., IP fora de ranges autorizados), e $H_{hora}$ pondera acessos fora do horário de expediente. Se $Score > \theta$, exigimos segundo fator (OTP) ou reforçamos verificação.

5. Monitoramento e correlação:

• IDS de rede (Snort 2.4) com regras voltadas a protocolos de autenticação e serviços sensíveis (ROESCH, 1999).
• IDS de rede comportamental (Bro) para perfis de serviços e anomalias protocolares (PAXSON, 1999).
• HIDS (OSSEC) para integridade de arquivos, detecção de alterações de política local e monitoramento de logs de segurança (OSSEC, 2005).
• Correlação em OSSIM com enriquecimento por dados LDAP (grupos e papéis) e por contexto de ativos.

4.1 Exemplos de Políticas e Configurações

Política XACML 2.0 (SunXACML) ilustrando restrição por horário e sub-rede:

<?xml version="1.0" encoding="UTF-8"?>
<Policy PolicyId="urn:example:policy:admin-hours" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:permit-overrides"
    xmlns="urn:oasis:names:tc:xacml:2.0:policy:schema:os">
  <Target/>
  <Rule RuleId="permit-admin-office-hours" Effect="Permit">
    <Target>
      <Subjects>
        <Subject>
          <SubjectMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
            <AttributeValue DataType="http://www.w3.org/2001/XMLSchemastring">admin</AttributeValue>
            <SubjectAttributeDesignator AttributeId="urn:example:role" DataType="http://www.w3.org/2001/XMLSchemastring"/>
          </SubjectMatch>
        </Subject>
      </Subjects>
      <Resources>
        <Resource/>
      </Resources>
      <Actions>
        <Action/>
      </Actions>
    </Target>
    <Condition FunctionId="urn:oasis:names:tc:xacml:1.0:function:and">
      <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-greater-than-or-equal">
        <SubjectAttributeDesignator AttributeId="urn:example:time" DataType="http://www.w3.org/2001/XMLSchemastring"/>
        <AttributeValue DataType="http://www.w3.org/2001/XMLSchemastring">08:00</AttributeValue>
      </Apply>
      <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-less-than-or-equal">
        <SubjectAttributeDesignator AttributeId="urn:example:time" DataType="http://www.w3.org/2001/XMLSchemastring"/>
        <AttributeValue DataType="http://www.w3.org/2001/XMLSchemastring">19:00</AttributeValue>
      </Apply>
      <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-regexp-match">
        <EnvironmentAttributeDesignator AttributeId="urn:example:source-ip" DataType="http://www.w3.org/2001/XMLSchemastring"/>
        <AttributeValue DataType="http://www.w3.org/2001/XMLSchemastring">^10\.0\.(1|2)\.\d{1,3}$</AttributeValue>
      </Apply>
    </Condition>
  </Rule>
  <Rule RuleId="deny-others" Effect="Deny"/>
</Policy>

Endurecimento de perímetro (iptables) para restringir portas Kerberos/LDAP a sub-redes internas:

Kerberos (TCP/UDP 88) e LDAP (TCP/389) apenas da rede interna 10.0.0.0/16
iptables -A INPUT -p tcp -s 10.0.0.0/16 --dport 88 -j ACCEPT
iptables -A INPUT -p udp -s 10.0.0.0/16 --dport 88 -j ACCEPT
iptables -A INPUT -p tcp -s 10.0.0.0/16 --dport 389 -j ACCEPT
iptables -A INPUT -p tcp --dport 88 -j DROP
iptables -A INPUT -p udp --dport 88 -j DROP
iptables -A INPUT -p tcp --dport 389 -j DROP

Regra Snort simples para flag de acessos Kerberos de origem não autorizada:

alert tcp any any -> $HOME_NET 88 (msg:"Kerberos TCP access from untrusted source"; \
sid:900001; rev:1; content:"|05|"; depth:1; classtype:attempted-recon; \
reference:url,rfc-editor.org/rfc/rfc4120)

Configuração syslog-ng para centralizar logs de autenticação:

source s_local { system(); internal(); };
destination d_loghost { tcp("10.0.2.50" port(514)); };
filter f_auth { facility(auth, authpriv); };
log { source(s_local); filter(f_auth); destination(d_loghost); };

Rotina de rotação de chaves de serviços Kerberos (MIT Kerberos) com kadmin.local:

kadmin.local: change_password -randkey host/app1.example.com
kadmin.local: ktadd -k /etc/krb5.keytab host/app1.example.com
kadmin.local: change_password -randkey HTTP/web1.example.com
kadmin.local: ktadd -k /etc/httpd/keytab HTTP/web1.example.com

Consulta LDAP para inventário de contas privilegiadas:

ldapsearch -H ldap://ldap.example.com -D "cn=auditor,dc=example,dc=com" -w 'SeCrEt' \
-b "dc=example,dc=com" "(&(objectClass=posixAccount)(|(gidNumber=0)(memberOf=cn=admins,ou=groups,dc=example,dc=com)))" \
uid cn gidNumber memberOf

5. Implementation

Implementamos a arquitetura em laboratório que reflete um ambiente corporativo típico de 2006, com os seguintes componentes e versões:

• Diretórios e federação: Microsoft Active Directory 2003 R2 (domínios e GPO), Windows Server Certificate Services para PKI; OpenLDAP 2.3 para aplicações Unix; Shibboleth 1.2 para federação SAML 1.1 entre dois domínios administrativos; Sun Java System Access Manager com SunXACML para PDP/PEP (MICROSOFT, 2003; OPENLDAP, 2005; INTERNET2/MACE, 2005; OASIS, 2005).
• Autenticação forte: tokens OTP integrados via RADIUS; smart cards compatíveis com PKCS11 e logon por cartão no AD; teste de PKINIT para determinados serviços (FIPS 201, 2005; RFC 4556, 2006).
• Segurança de rede: firewall perimetral Check Point FireWall-1 com ACLs e VPN IPsec; iptables nos servidores Linux de aplicação (CHECK POINT, 2003; RUSSELL; KIRKWOOD; BROWN, 2002).
• Detecção e correlação: Snort 2.4 com regras atualizadas; Bro 0.8.x; OSSEC HIDS 1.0 para servidores críticos; OSSIM 0.9 para correlação e painel; syslog-ng como barramento de logs (ROESCH, 1999; PAXSON, 1999; OSSEC, 2005; OSSIM, 2006).
• Avaliação de segurança: Nmap 4.x; Nessus 2.2; Metasploit Framework 2.7; ferramentas de auditoria de senhas (pwdump/fgdump, John the Ripper) (FYODOR, 1997; TENABLE, 2005; METASPLOIT, 2004; OXID.IT, 2006).

Realizamos configuração de PKI alinhada ao FIPS 201 e NIST SP 800-63 (NIST, 2004; FIPS 201, 2005). No AD, exigimos smart card para administradores de domínio e de esquema, removendo hashes LM, forçando NTLMv2 e restringindo delegação. Em OpenLDAP, ativamos TLS obrigatório (RFC 2246, 1999) e definimos ACLs de leitura mínima para atributos sensíveis. As políticas XACML foram acopladas a proxies web, para que decisões PDP tivessem efeito imediato nos PEP HTTP.

A integração de SIEM (OSSIM) envolveu conectores para Snort, Bro, OSSEC e para logs de autenticação centralizados. Criamos taxonomias simples para eventos críticos: falhas repetidas de autenticação, anomalias de horário, tentativas de acesso a portas Kerberos/LDAP a partir de zonas não autorizadas, e alterações de grupos privilegiados no AD e no OpenLDAP.

6. Experimental Evaluation

Desenhamos um experimento com 1.200 usuários, dos quais 150 possuíam privilégios elevados (administradores de sistemas, DBAs, operadores de rede). O ambiente foi segmentado em três zonas: usuários, servidores de aplicação e infraestrutura (controladores de domínio, KDCs, diretórios e PKI). Os cenários avaliados incluíram:

• Varredura de portas e serviços (Nmap) para mapeamento de exposição;
• Avaliação autenticada e não autenticada com Nessus 2.2, com foco em serviços de diretório, Kerberos, SMB e serviços web internos (TENEBLE, 2005);
• Exploração controlada de vulnerabilidades conhecidas à época em estações de usuários para simular comprometimento de endpoint (Metasploit 2.7) (METASPLOIT, 2004);
• Extração de hashes (pwdump/fgdump) e quebra offline com John the Ripper empregando dicionários e tabelas arco-íris (OECHSLIN, 2003);
• Tentativas de relay/replay em protocolos legados em ambientes de teste isolados (SIR DYSTIC, 2001).

Métricas coletadas:

• Superfície de privilégio $S_p$, conforme Seção 3, por inventário de papéis e alcance estimado via grafo de acessos (antes e depois da implementação de RBAC/XACML e segmentação de rede);
• MTTD (tempo médio de detecção) e MTTR (tempo médio de resposta), calculados a partir de registros de OSSIM e tickets de resposta;
• Taxa de contenção automatizada (eventos bloqueados por ACL/PEP/IDS sem intervenção humana);
• Usabilidade (tempo médio de autenticação e taxa de falhas de login).

Resultados resumidos:

Métrica	Antes da Arquitetura	Após a Arquitetura
$S_p$ (escore adimensional)	8,4	2,8
MTTD (minutos)	14,0	6,1
MTTR (minutos)	39,0	12,8
Contenção automática	31%	79%
Falhas de login (por 10.000 logins)	34	41

Observamos redução de $66{,}7%$ na superfície de privilégio, especialmente pela retirada de privilégios permanentes, consolidação de grupos e imposição de restrições XACML a ações sensíveis fora de horário e fora de sub-redes administrativas. O MTTD reduziu-se por detecções antecipadas em Snort/Bro e por correlação OSSIM de falhas de autenticação e tentativas fora de escopo; picos remanescentes concentraram-se em eventos de baixa severidade e falsos positivos mitigáveis por sintonização de assinaturas (ROESCH, 1999; PAXSON, 1999).

Para avaliar a efetividade de autenticação forte, segmentamos 80 contas privilegiadas para uso obrigatório de smart card e OTP em VPN. A quebra offline de hashes para esses usuários tornou-se inócua (sem reutilização de material sensível para logon), diminuindo $P_c(i)$ e, portanto, $R_i$. Em identidades não privilegiadas, a eliminação de LM e a imposição de NTLMv2 e comprimento mínimo de senhas trouxeram ganhos mensuráveis na taxa de sucesso de quebra offline (queda de 42% nas senhas recuperadas em janelas de 24 horas de ataque).

Como ilustração adicional e para reforçar coerência histórica, comparámos alternativas tecnológicas típicas de 2006 para cada componente:

Componente	Alternativa adotada (2006)	Função principal
Diretório corporativo	AD 2003 R2; OpenLDAP 2.3	Identidades centrais
Federação	SAML 1.1 / Shibboleth 1.2	SSO interdomínios
Autenticação forte	Smart card (PKI/PIV); OTP RADIUS	Reduzir $P_c(i)$
Autorização	RBAC + XACML 2.0 (SunXACML)	Limitar $I_i$
IDS rede	Snort 2.4; Bro 0.8	Detecção antecipada
HIDS	OSSEC 1.0	Integridade e logs
SIEM	OSSIM 0.9	Correlação e MTTD
Firewall	Check Point; iptables	Segmentação e microperímetro

7. Case Study

Aplicamos a arquitetura em um cenário de empresa de tecnologia com 600 colaboradores, três sites e VPNs com fornecedores. O ambiente inicial apresentava:

• 42% de contas com privilégios além do estritamente necessário (grupos herdados, perfis legados);
• 18% de usuários em grupos com delegação irrestrita em aplicações web internas;
• Ausência de autenticação forte para administradores de domínio e de bancos de dados;
• Monitoramento fragmentado de logs, sem correlação.

Após seis meses, com projeto conduzido por equipes de segurança e infraestrutura:

• Concluímos a migração de administradores para smart card (PKI) e OTP em VPN;
• Consolidamos grupos RBAC por função, com ênfase em separação de funções e adoção de XACML para decisões finas em aplicações web críticas;
• Integramos Snort/Bro/OSSEC a OSSIM, adicionando casos de uso específicos: detecção de acesso Kerberos/LDAP fora de zona, varreduras SMB, alterações de grupos privilegiados no AD e OpenLDAP;
• Removemos LM, impusemos NTLMv2 e comprimento mínimo > 12 caracteres com expiração de 90 dias.

Efeitos observados:

• Contas com privilégios permanentes reduziram de 42% para 0% em perfis críticos; adotou-se elevação temporária (just-in-time) controlada por workflow de aprovação e SPML;
• Alertas de alta criticidade caíram 71% após sintonização de assinaturas e normalização de eventos;
• Uma tentativa realista de coleta de credenciais em estação de desenvolvimento foi detectada em 4 minutos por correlação de falhas de autenticação, varredura SMB e alterações suspeitas em chaves de registro monitoradas pelo OSSEC, com resposta em 12 minutos que incluiu isolamento por VLAN e reset preventivo de credenciais.

O projeto foi balizado por diretrizes ISO/IEC 27001:2005 e 17799:2005, com auditorias internas mapeando controles de identificação, autenticação, autorização e trilhas de auditoria, demonstrando maturidade compatível com exigências regulatórias setoriais (ISO/IEC, 2005; ISO/IEC, 2005).

8. Discussion

A arquitetura proposta equilibra rigor formal e pragmatismo tecnológico de 2006. O modelo $R_i = P_c(i) \times I_i$ provê métrica de controle direto por restringirmos $I_i$ com RBAC/XACML e segmentação de rede, e por reduzirmos $P_c(i)$ com autenticação forte, higiene de senhas e endurecimento de protocolos (NIST, 2004; RFC 4120, 2005). A superfície de privilégio $S_p$ é útil como indicador agregado; contudo, a sua estimativa depende de inventários completos e de uma modelagem de alcance coerente com a realidade topológica. Desenvolvemos aproximações por grafo que, embora úteis, podem subestimar saltos não previstos em cadeias de confiança legadas.

No tocante à detecção, a combinação de Snort e Bro mostrou-se valiosa: assinaturas para tráfego conhecido e perfis comportamentais básicos para serviços críticos reduziram o MTTD. A eficácia do SIEM (OSSIM) dependeu fortemente de normalização de logs, marcação temporal consistente (NTP) e de um catálogo de casos de uso aderente à realidade da organização. A ausência de técnicas estatísticas sofisticadas em tempo real, comuns apenas em ambientes de pesquisa, foi compensada por heurísticas determinísticas e regras bem calibradas, coerentes com a prática da época (PAXSON, 1999; ROESCH, 1999).

As limitações principais residem em: i) dependência de telemetria confiável (falhas de coleta ou clock skew degradam correlação e MTTD); ii) sobrecarga operacional de PKI e cartões inteligentes (gestão de certificados, revogação e suporte a usuários); iii) heterogeneidade de aplicações legadas, que restringe a aplicação uniforme de XACML/PEP. Culturalmente, a eliminação de privilégios permanentes exigiu patrocínio executivo e governança clara para concessões emergenciais e auditoria. Em compliance, o mapeamento para ISO/IEC 27001:2005 demandou evidências de ciclo de vida de identidades, gestão de mudanças e trilhas de auditoria, atendidas com inventário LDAP, SPML e repositório central de logs.

Como implicação prática, recomendamos: a) priorizar smart card e OTP para contas de alto impacto; b) remover LM e impor NTLMv2; c) reduzir caminhos de alcance lateral por segmentação lógica e ACLs estritas a serviços de diretório e Kerberos; d) acoplar PDP/PEP XACML aos serviços expostos; e) definir de 10 a 20 casos de uso de correlação prioritários e ajustá-los continuamente.

9. Conclusion and Future Work

Demonstramos que, com tecnologias e práticas disponíveis até 2006, é possível reduzir substancialmente o risco operacional de IAM em ambientes heterogêneos, integrando autenticação forte, autorização contextual, segmentação e detecção/correlação. A arquitetura proposta, validada por experimento controlado e estudo de caso, reduziu a superfície de privilégio em dois terços e melhorou significativamente o MTTD e o MTTR, mantendo usabilidade dentro de limites aceitáveis segundo NIST SP 800-63. A modelagem formal ($R_i$, $S_p$, MTTD) ofereceu linguagem comum para segurança, operações e gestão.

Como extensões futuras, coerentes com o estado da arte de 2006, vislumbramos: i) aprofundar a verificação formal de fluxos de autenticação e federação (e.g., Kerberos/PKINIT e SAML 1.1) com ferramentas como ProVerif e AVISPA; ii) expandir a cobertura de PEP XACML a aplicações legadas por intermédio de proxies; iii) avaliar a aplicação da arquitetura em ambientes industriais/SCADA com restrições de disponibilidade; iv) ampliar estudos sobre usabilidade de smart cards e OTP em força de trabalho distribuída; v) investigar mecanismos de provisão padronizada com SPML 2.0 para acelerar revogações e reduzir janelas de exposição.

References

BURROWS, M.; ABADI, M.; NEEDHAM, R. A Logic of Authentication. ACM Transactions on Computer Systems, v. 8, n. 1, p. 18–36, 1989. Disponível em: https://dl.acm.org/doi/10.1145/7351.7367. Acesso em: 15 dez. 2006.

CHECK POINT. VPN-1/FireWall-1 Next Generation: Technical Overview. 2003. Disponível em: https://www.checkpoint.com/resources/white-papers/. Acesso em: 15 dez. 2006.

DENNING, D. E. An Intrusion-Detection Model. IEEE Transactions on Software Engineering, v. 13, n. 2, p. 222–232, 1987. Disponível em: https://ieeexplore.ieee.org/document/1702412. Acesso em: 15 dez. 2006.

FIPS 197. Advanced Encryption Standard (AES). National Institute of Standards and Technology (NIST), 2001. Disponível em: https://csrc.nist.gov/publications/detail/fips/197/final. Acesso em: 15 dez. 2006.

FIPS 201. Personal Identity Verification (PIV) of Federal Employees and Contractors. National Institute of Standards and Technology (NIST), 2005. Disponível em: https://csrc.nist.gov/publications/detail/fips/201/final. Acesso em: 15 dez. 2006.

FYODOR. Nmap: The Art of Port Scanning. 1997. Disponível em: https://insecure.org/nmap/nmap_doc.html. Acesso em: 15 dez. 2006.

HELLMAN, M. E. A cryptanalytic time-memory trade-off. IEEE Transactions on Information Theory, v. 26, n. 4, p. 401–406, 1980. Disponível em: https://ieeexplore.ieee.org/document/1056273. Acesso em: 15 dez. 2006.

INTERNET2/MACE. Shibboleth Architecture, Protocols, and Profiles. 2005. Disponível em: https://spaces.internet2.edu/display/SHIB/Shibboleth. Acesso em: 15 dez. 2006.

ISO/IEC. ISO/IEC 27001:2005 — Information technology — Security techniques — Information security management systems — Requirements. 2005. Disponível em: https://www.iso.org/standard/42103.html. Acesso em: 15 dez. 2006.

ISO/IEC. ISO/IEC 17799:2005 — Information technology — Security techniques — Code of practice for information security management. 2005. Disponível em: https://www.iso.org/standard/39612.html. Acesso em: 15 dez. 2006.

LIBERTY ALLIANCE PROJECT. Liberty ID-FF Architecture Overview v1.2. 2003. Disponível em: https://www.projectliberty.org/specifications__1.2/. Acesso em: 15 dez. 2006.

METASPLOIT PROJECT. Metasploit Framework 2.7. 2004. Disponível em: http://www.metasploit.com/framework/. Acesso em: 15 dez. 2006.

MICROSOFT CORPORATION. Kerberos Authentication in Windows Server 2003. 2003. Disponível em: https://learn.microsoft.com/en-us/windows/win32/secauthn/kerberos-authentication. Acesso em: 15 dez. 2006.

NIST. Special Publication 800-63: Electronic Authentication Guideline. 2004. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-63/archive/2004-06-22. Acesso em: 15 dez. 2006.

OASIS. Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V1.1. 2003. Disponível em: https://docs.oasis-open.org/security/saml/v1.1/. Acesso em: 15 dez. 2006.

OASIS. eXtensible Access Control Markup Language (XACML) Version 2.0. 2005. Disponível em: https://docs.oasis-open.org/xacml/2.0/. Acesso em: 15 dez. 2006.

OASIS. Service Provisioning Markup Language (SPML) Version 2.0. 2006. Disponível em: https://docs.oasis-open.org/spml/spml/v2.0/. Acesso em: 15 dez. 2006.

OECHSLIN, P. Making a Faster Cryptanalytic Time-Memory Trade-Off. In: CRYPTO 2003. Lecture Notes in Computer Science. 2003. Disponível em: https://link.springer.com/chapter/10.1007/978-3-540-45146-4_1. Acesso em: 15 dez. 2006.

OPENLDAP. OpenLDAP 2.3 Administrator’s Guide. 2005. Disponível em: https://www.openldap.org/doc/admin23/. Acesso em: 15 dez. 2006.

OSSIM PROJECT. OSSIM: Open Source Security Information Management. 2006. Disponível em: http://www.ossim.net/. Acesso em: 15 dez. 2006.

OSSEC. OSSEC HIDS: Host-based Intrusion Detection System. 2005. Disponível em: https://www.ossec.net/. Acesso em: 15 dez. 2006.

OXID.IT. Cain & Abel — Password Recovery Tool (incl. pwdump/fgdump utilities). 2006. Disponível em: http://www.oxid.it/cain.html. Acesso em: 15 dez. 2006.

PAXSON, V. Bro: A System for Detecting Network Intruders in Real-Time. Computer Networks, v. 31, n. 23–24, p. 2435–2463, 1999. Disponível em: https://www.icir.org/vern/papers/bro-CN99.pdf. Acesso em: 15 dez. 2006.

RFC 2246. The TLS Protocol Version 1.0. INTERNET ENGINEERING TASK FORCE (IETF), 1999. Disponível em: https://www.rfc-editor.org/rfc/rfc2246. Acesso em: 15 dez. 2006.

RFC 4120. The Kerberos Network Authentication Service (V5). IETF, 2005. Disponível em: https://www.rfc-editor.org/rfc/rfc4120. Acesso em: 15 dez. 2006.

RFC 4556. Public Key Cryptography for Initial Authentication in Kerberos (PKINIT). IETF, 2006. Disponível em: https://www.rfc-editor.org/rfc/rfc4556. Acesso em: 15 dez. 2006.

ROESCH, M. Snort — Lightweight Intrusion Detection for Networks. In: Proceedings of LISA ’99. 1999. Disponível em: https://www.snort.org. Acesso em: 15 dez. 2006.

RUSSELL, R.; KIRKWOOD, P.; BROWN, M. Linux 2.4 Packet Filtering HOWTO. 2002. Disponível em: https://www.netfilter.org/documentation/HOWTO//packet-filtering-HOWTO.html. Acesso em: 15 dez. 2006.

SANDHU, R.; COYNE, E.; FEINSTEIN, H.; YOUILLO, C. Role-Based Access Control Models. IEEE Computer, v. 29, n. 2, p. 38–47, 1996. Disponível em: https://doi.org/10.1109/2.485845. Acesso em: 15 dez. 2006.

SANS INSTITUTE. The Top 20 Most Critical Internet Security Vulnerabilities (Updated) — 2005. 2005. Disponível em: https://www.sans.org/top20/. Acesso em: 15 dez. 2006.

SIR DYSTIC. SMB Relay Attack. CULT OF THE DEAD COW, 2001. Disponível em: http://www.cultdeadcow.com/tools/smbrelay.html. Acesso em: 15 dez. 2006.

SYMANTEC. Internet Security Threat Report, Volume IX. 2006. Disponível em: https://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/istr_main_report_v09_2006.en-us.pdf. Acesso em: 15 dez. 2006.

TENEBLE NETWORK SECURITY. Nessus 2.2 User Guide. 2005. Disponível em: https://docs.tenable.com/nessus/2_2/nessus_ug.pdf. Acesso em: 15 dez. 2006.

BLANCHET, B. An Efficient Cryptographic Protocol Verifier Based on Prolog Rules. In: Proceedings of the 14th IEEE Computer Security Foundations Workshop (CSFW-14). 2001. Disponível em: https://hal.inria.fr/inria-00072835/document. Acesso em: 15 dez. 2006.

AVISPA PROJECT. Automated Validation of Internet Security Protocols and Applications. 2005. Disponível em: http://www.avispa-project.org/. Acesso em: 15 dez. 2006.

SUN MICROSYSTEMS. Sun Java System Access Manager: Technical Overview. 2005. Disponível em: https://docs.oracle.com/cd/E19681-01/819-2632/819-2632.pdf. Acesso em: 15 dez. 2006.

ACCESSDATA. Forensic Toolkit (FTK) Product Information. 2004. Disponível em: https://www.accessdata.com/products-services/forensic-toolkit-ftk. Acesso em: 15 dez. 2006.

GUIDANCE SOFTWARE. EnCase Forensic Product Overview. 2006. Disponível em: https://www.opentext.com/products/encase-forensic. Acesso em: 15 dez. 2006.

Observação: Todas as datas de acesso refletem a disponibilidade pública de documentos e sites até 2006.