Arquitetura Operacional de Identity and Access Management (IAM) para Ambientes Corporativos Baseados em UNIX e Redes TCP/IP

1. Introdução

A expansão das redes baseadas em TCP/IP ao longo das décadas de 1980 e 1990 transformou de modo profundo o paradigma de segurança computacional. Sistemas anteriormente isolados passaram a operar em ambientes interconectados, frequentemente expostos a redes acadêmicas, governamentais e corporativas. Nesse cenário, a presença de múltiplos usuários em sistemas UNIX multiusuário impôs desafios significativos à gestão de identidade, autenticação, autorização e auditoria.

Tradicionalmente, a autenticação era realizada por meio de senhas armazenadas em arquivos como /etc/passwd, muitas vezes com hashes DES acessíveis a leitura pública em determinadas implementações. Essa prática, embora funcional em ambientes pequenos e administrativamente homogêneos, revelou-se inadequada diante do aumento da capacidade computacional e da disseminação de ferramentas de quebra de senha baseadas em força bruta e em ataques de dicionário (MORRIS; THOMPSON, 1979). A consolidação de redes abertas tornou ainda mais evidente que a proteção local de credenciais não bastava quando os dados de autenticação trafegavam por protocolos sem criptografia.

Identity and Access Management (IAM) surge, neste contexto, como disciplina operacional voltada à governança de identidades digitais, autenticação, autorização e auditoria. Embora o termo ainda não estivesse plenamente estabilizado na literatura técnica do período, seus princípios estruturantes já se encontravam presentes em trabalhos clássicos sobre proteção da informação, controle de acesso e autenticação em redes abertas (LAMPSON, 1971; BELL; LAPADULA, 1973; SALTZER; SCHROEDER, 1975; NEEDHAM; SCHROEDER, 1978). Em essência, a gestão de identidades passa a ser compreendida como componente central da defesa, e não apenas como requisito administrativo.

A motivação central deste estudo reside na necessidade de estruturar um modelo integrado de IAM aplicável a ambientes corporativos com múltiplos servidores UNIX, estações Sun e VAX, serviços de rede abertos como Telnet, FTP e SMTP, e autenticação distribuída via NIS. Sustentamos que a fragmentação da gestão de identidades aumenta a superfície de ataque, favorece inconsistências de privilégio e dificulta a auditoria forense. Além disso, em redes nas quais ainda persistem serviços legados e protocolos sem proteção nativa, a ausência de uma arquitetura coerente de IAM amplia a probabilidade de comprometimento por interceptação de tráfego, reutilização indevida de credenciais e exploração de contas privilegiadas.

Neste trabalho, apresentamos uma arquitetura operacional, um modelo formal de ameaça, um conjunto de controles de implementação e uma avaliação experimental em ambiente realista de rede corporativa interconectada. Nosso objetivo é demonstrar que, mesmo com as restrições tecnológicas disponíveis até 2010, é possível construir uma estratégia sistemática de IAM baseada em centralização controlada, autenticação fortalecida, autorização mínima e auditoria contínua.

1.1 Contextualização ampliada no cenário de APTs até 2010

Embora a gênese do problema esteja associada a ambientes UNIX e à consolidação de redes TCP/IP, a relevância do IAM intensifica-se com a mudança do perfil do adversário ao longo dos anos 2000. A transição de ataques oportunistas para operações persistentes e direcionadas, posteriormente caracterizadas como Advanced Persistent Threats (APTs), reforçou a necessidade de um modelo de governança de identidades capaz de resistir a cadeias de comprometimento mais longas e discretas. Em incidentes como o comprometimento de credenciais por spear phishing, a exploração de estações vulneráveis e o abuso de acesso legítimo, a identidade torna-se simultaneamente o alvo e o meio de acesso ao ambiente.

Nesse período, o ataque não depende apenas de falhas criptográficas; ele explora a confiança humana, o uso de senhas fracas, a reutilização de credenciais entre sistemas e a falta de segregação entre contas pessoais, administrativas e de serviço. Em consequência, a autenticação precisa ser encarada como uma barreira que reduz exposição inicial, enquanto a autorização e a auditoria atuam como mecanismos de contenção e resposta. A presente proposta foi estruturada para contemplar tal realidade, sem recorrer a pressupostos tecnológicos posteriores a 2010, como virtualização moderna em nuvem, conteinerização ou mecanismos contemporâneos de telemetria automatizada.

1.2 Contribuições deste estudo

As principais contribuições são:

1. formalização de um modelo de ameaça centrado em credenciais, privilégios e canais inseguros;
2. proposta de arquitetura integrada para identidade, autenticação e auditoria em UNIX corporativo;
3. avaliação comparativa entre mecanismos clássicos de acesso;
4. estudo de caso com implantação realista em ambiente heterogêneo;
5. expansão analítica com foco em riscos, desempenho e evidências experimentais.

2. Fundamentação teórica e trabalhos relacionados

O controle de acesso em sistemas computacionais vem sendo estudado extensivamente desde os anos 1960. O modelo Bell-LaPadula introduziu formalismo matemático para confidencialidade, definindo propriedades conhecidas como simple security property e *-property, que relacionam o acesso de sujeitos a objetos classificados segundo níveis de sensibilidade (BELL; LAPADULA, 1973). Embora originalmente concebido para cenários de segurança militar, esse modelo influenciou profundamente a discussão sobre compartimentação, classificação e restrição de acesso em sistemas multiusuário.

Lampson (1971) introduziu o conceito de matriz de controle de acesso, no qual a autorização pode ser representada por uma função que associa sujeitos, objetos e permissões. Em sua formulação mais geral, temos:

$$ A: S \times O \rightarrow P $$

em que $S$ representa o conjunto de sujeitos, $O$ representa o conjunto de objetos e $P$ o conjunto de permissões atribuíveis. Essa abstração permanece útil para compreender a relação entre identidade e autorização, particularmente quando os privilégios são distribuídos entre usuários, grupos e domínios administrativos.

No contexto UNIX, o modelo DAC (Discretionary Access Control) implementa permissões rwx para proprietário, grupo e outros. Embora simples e operacionalmente eficiente, esse modelo é vulnerável a abuso de privilégio, herança inadequada de permissões e escalonamento indevido por meio de binários com bits SUID e SGID. Bishop (1985) observou que diversos problemas estruturais do UNIX derivam justamente da interação entre flexibilidade administrativa e ausência de mecanismos obrigatórios de confinamento. A literatura subsequente reforçou a necessidade de complementar o modelo DAC com controles administrativos, auditoria e segregação de funções.

Em redes abertas, autenticação por senha em canais não protegidos apresenta riscos elevados. O trabalho de Needham e Schroeder (1978) discutiu o uso de criptografia para autenticação e, posteriormente, o Kerberos consolidou-se como solução prática para autenticação em redes inseguras, com tickets e chaveamento baseado em criptografia simétrica DES (STEINER; NEUMAN; SCHILLER, 1988). O Kerberos tornou-se especialmente relevante para ambientes corporativos que precisavam reduzir a exposição de senhas em trânsito sem substituir integralmente a infraestrutura existente. Ainda assim, sua adoção depende de infraestrutura central confiável, como o Key Distribution Center (KDC), e requer políticas de sincronização de tempo e gestão cuidadosa de chaves.

O NIS (Network Information Service) permitiu centralização de arquivos de identidade e configuração em redes UNIX, simplificando a administração de usuários e grupos. Entretanto, o mecanismo não oferece proteção criptográfica robusta por padrão e pressupõe confiança ampla entre clientes e servidores. Em ambientes de maior risco, essa confiança implícita constitui limitação significativa, especialmente quando comparada a abordagens mais fortes de autenticação e autorização.

A Tabela 1 resume mecanismos e tecnologias relevantes ao problema estudado, observando suas características fundamentais, bem como as limitações mais frequentes em ambientes corporativos do período.

Tabela 1 — Comparação de mecanismos de identidade e controle de acesso relevantes ao contexto UNIX/TCP-IP

Tecnologia	Ano	Tipo	Criptografia	Limitações
/etc/passwd tradicional	Década de 1970	Local	Hash DES em implementações históricas	Exposição offline e coleta de hashes
shadow passwords	Final da década de 1980	Local	Hash protegido em arquivo separado	Ainda depende de política fraca de senhas
NIS	1985	Distribuído	Limitada	Confiança implícita e ausência de criptografia forte
Kerberos v4	1988	Autenticação	DES	Dependência de KDC e sincronização temporal
DAC UNIX	Década de 1970	Autorização	N/A	Falta de granularidade e de confinamento obrigatório
MAC/MLS	1973	Formal	N/A	Complexidade operacional e administrativa

Diversos autores também destacaram a importância da monitoração de eventos e da detecção de intrusões. Denning (1987) propôs um modelo de detecção de intrusão baseado em desvios de comportamento e agregação de eventos, enquanto Anderson (1980) já havia enfatizado a necessidade de monitoramento sistemático em sistemas de processamento de dados. Em paralelo, a literatura de segurança UNIX mostrou que contas privilegiadas, políticas de senha fracas e serviços expostos em rede permanecem como pontos recorrentes de comprometimento (FERGUSON, 1987; BRANDON, 1986; BISHOP, 1985).

2.1 A relevância do problema em ataques direcionados até 2010

A partir do final da década de 1990, os ataques a identidades assumem nova feição com campanhas persistentes e furtivas, muitas vezes apoiadas em spear phishing e em exploração de sistemas de usuários finais. O caso Aurora, amplamente discutido no período seguinte ao seu impacto, exemplifica o uso de engenharia social para obter acesso inicial a ambientes corporativos estratégicos. Da mesma forma, o incidente de credenciais da RSA em 2011, embora posterior ao recorte temporal de execução deste estudo, reforça uma tendência já consolidada em 2010: o vetor humano é central no comprometimento de grandes organizações.

Portanto, mesmo quando o foco é UNIX e TCP/IP, a governança de identidades deve considerar que o atacante moderno combina coleta de informação pública, mensagens direcionadas, exploração de navegadores, anexos maliciosos e reutilização de senhas. Assim, um modelo de IAM robusto precisa ser compreendido como controle transversal sobre a superfície de exposição da organização.

3. Modelo de ameaça e formalização do problema

Consideramos um adversário com acesso à rede TCP/IP corporativa, capaz de observar tráfego, identificar serviços expostos e explorar fragilidades de configuração e de política de acesso. Em particular, o adversário pode:

1. Interceptar tráfego Telnet, FTP e outros protocolos sem criptografia.
2. Executar ataques de força bruta contra contas com senhas fracas.
3. Explorar senhas reutilizadas ou previsíveis.
4. Abusar de privilégios SUID/SGID em binários vulneráveis.
5. Tirar proveito de confiança excessiva entre domínios NIS.
6. Explorar a ausência de segregação entre identidade, autenticação e autorização.

O risco operacional é definido por:

$$ R = P© \times I $$

em que $P©$ é a probabilidade de comprometimento e $I$ o impacto operacional. Essa formulação é útil porque permite relacionar fragilidade de política de senha, exposição de serviços e criticidade dos ativos com a severidade potencial do incidente.

A probabilidade de quebra de senha, em uma aproximação simplificada, pode ser estimada por:

$$ P = 1 - \left(1 - \frac{1}{N}\right)^k $$

em que $N$ representa o espaço efetivo de senhas e $k$ o número de tentativas. Embora a expressão não modele diretamente a inteligência do atacante, ela permite demonstrar que senhas de baixo comprimento ou baixa entropia tornam-se rapidamente viáveis de exploração quando submetidas a tentativas automatizadas.

Para tornar o problema operacionalmente tratável, decompomos a superfície de ataque em três eixos:

• Identidade: consistência de contas, grupos, aliases e domínios administrativos;
• Autenticação: prova de posse de segredo, tickets, chaves e mecanismos de login remoto;
• Autorização: concessão mínima de privilégios e fiscalização de exceções.

A Tabela 2 sumariza as categorias de ameaça consideradas neste estudo.

Tabela 2 — Categorias de ameaça no ambiente corporativo UNIX/TCP-IP

Categoria de ameaça	Vetor principal	Efeito esperado	Controle associado
Interceptação de credenciais	Telnet, FTP, rlogin	Roubo de senha e sequestro de sessão	Kerberos, substituição de serviços inseguros
Senhas fracas	Contas locais e NIS	Comprometimento por dicionário	Política de senha e expiração
Abuso de SUID	Binários privilegiados	Escalonamento local	Auditoria e revisão periódica
Confiança excessiva em NIS	Domínios mal segregados	Movimento lateral	Segmentação administrativa
Logs dispersos	Registros locais inconsistentes	Baixa capacidade forense	Centralização de syslog

3.1 Análise estendida de ameaça

A formulação anterior, embora suficiente para a implementação básica, pode ser refinada em termos de cadeia de ataque. Em ambientes com APTs e intrusões direcionadas, o atacante normalmente segue um encadeamento composto por reconhecimento, obtenção de acesso inicial, escalonamento de privilégio, movimento lateral e exfiltração. Cada etapa interage com identidades, credenciais e políticas administrativas.

A árvore de ataque a seguir representa esse processo de maneira simplificada.

graph TD
    A[Objetivo do atacante: comprometer o ambiente] --> B[Reconhecimento]
    A --> C[Acesso inicial]
    A --> D[Escalonamento de privilégio]
    A --> E[Persistência]
    A --> F[Exfiltração]

    B --> B1[Mapeamento de hosts]
    B --> B2[Enumeração de serviços]
    B --> B3[Coleta de informações públicas]

    C --> C1[Spear phishing]
    C --> C2[Interceptação Telnet/FTP]
    C --> C3[Força bruta / dicionário]
    C --> C4[Reuso de credenciais]

    D --> D1[Exploração SUID]
    D --> D2[Abuso de contas de serviço]
    D --> D3[Domínio NIS confiável]

    E --> E1[Criação de backdoor]
    E --> E2[Modificação de logs]
    E --> E3[Agendamento de tarefas]

    F --> F1[Captura de dados]
    F --> F2[Movimento lateral]
    F --> F3[Saída por canais legítimos]

3.2 Matriz de risco ampliada

A severidade do risco pode ser examinada com uma matriz qualitativa que articula probabilidade e impacto. Para operacionalizar essa análise, adotamos níveis baixo, médio e alto, compatíveis com a prática administrativa da época.

Tabela 3 — Matriz de risco para o ambiente UNIX corporativo

Ameaça	Probabilidade	Impacto	Nível de risco	Prioridade
Interceptação de Telnet	Alta	Alta	Crítico	1
Senha fraca em conta administrativa	Alta	Alta	Crítico	1
Abuso de SUID local	Média	Alta	Alto	2
Comprometimento de NIS	Média	Alta	Alto	2
Logs locais não centralizados	Alta	Média	Alto	2
Reuso de senhas entre sistemas	Alta	Média	Alto	2
Escalada por conta de serviço	Média	Média	Médio	3

Para refinar a priorização, pode-se atribuir um escore numérico:

$$ S = \alpha P + \beta I $$

em que $P$ e $I$ são normalizados no intervalo $[0,1]$, e $\alpha+\beta=1$. Na presente análise, adotamos $\alpha = \beta = 0,5$, refletindo a equivalência entre frequência esperada e dano potencial. Esse critério simplifica a hierarquização dos controles.

4. Metodologia proposta

A metodologia proposta é organizada em três camadas complementares, que tratam a identidade como ativo central do ambiente computacional.

4.1 Camada 1 — Identidade

A primeira camada consiste na centralização controlada das identidades. Em vez de permitir múltiplas fontes inconsistentes de verdade, propomos o uso de um domínio administrativo bem definido, com escopo limitado de exportação e separação entre servidores críticos e nós de menor confiança. Em ambientes UNIX da época, o NIS foi frequentemente utilizado para esse fim; contudo, sua adoção deve ser acompanhada de restrições de acesso por rede, segmentação de domínios e governança rígida sobre contas privilegiadas.

Adicionalmente, recomendamos a padronização de identificadores de usuário, grupos administrativos e convenções de nomenclatura, reduzindo ambiguidades e prevenindo colisões de identidade entre diferentes sistemas. Em termos operacionais, a integridade da identidade depende tanto da origem dos registros quanto do processo de criação, alteração e revogação de contas.

4.2 Camada 2 — Autenticação

A segunda camada introduz autenticação forte para serviços sensíveis. Para serviços remotos e atividades administrativas, propomos a integração de Kerberos em substituição progressiva a protocolos baseados em senha pura, como rlogin e rsh. A autenticação por tickets reduz a exposição de segredos em trânsito e limita a reutilização de credenciais capturadas na rede.

Complementarmente, a política de senhas deve incluir:

• comprimento mínimo de 8 caracteres;
• verificação periódica de expiração;
• rejeição de senhas previsíveis;
• restrição ao uso de nomes de usuário, nomes de hosts e termos de dicionário;
• incentivo ao uso de combinatórias alfanuméricas com variação de símbolos quando suportado pela plataforma.

Embora a literatura da época já reconhecesse que o aumento de comprimento eleva o esforço de quebra, é essencial lembrar que entropia formal depende também da seleção do espaço de caracteres e da previsibilidade humana na escolha das senhas. Assim, o controle não deve ser reduzido ao comprimento isolado.

4.3 Camada 3 — Autorização e auditoria

A terceira camada aplica o princípio do privilégio mínimo e inclui auditoria sistemática de binários SUID, revisão de grupos administrativos e centralização de logs. Em UNIX, permissões excessivas muitas vezes surgem de necessidades operacionais temporárias que permanecem ativas indefinidamente. Consequentemente, a autorização deve ser tratada como processo contínuo, e não como concessão estática.

Recomendamos:

• revisão periódica de contas com UID 0 ou equivalentes administrativos;
• inventário de arquivos SUID e SGID;
• separação entre contas de serviço e contas humanas;
• centralização de logs em um servidor de auditoria;
• retenção de eventos de autenticação, falhas de login e alterações de privilégio.

A Tabela 4 apresenta as principais políticas propostas.

Tabela 4 — Políticas de controle propostas para o ambiente UNIX corporativo

Controle	Implementação	Objetivo
Senha mínima de 8 caracteres	Política de passwd	Aumentar entropia efetiva
Auditoria de binários SUID	Script periódico de verificação	Reduzir escalonamento indevido
Login Kerberos	kinit, klogin, kdestroy	Evitar interceptação de senhas
Syslog centralizado	/etc/syslog.conf	Aumentar rastreabilidade
Revisão de contas privilegiadas	Inventário administrativo	Aplicar privilégio mínimo

4.4 Modelo de fluxo operacional de controles

A operação dos controles pode ser representada como uma cadeia de decisão, na qual cada solicitação de acesso passa por validação de identidade, autenticação, autorização e monitoração.

sequenceDiagram
    autonumber
    participant U as Usuário
    participant C as Cliente UNIX
    participant K as KDC/Kerberos
    participant A as Servidor de Aplicação
    participant L as Syslog

    U->>C: Solicita login remoto
    C->>K: Pedido de Ticket-Granting Ticket
    K-->>C: TGT + chave de sessão
    C->>K: Solicita ticket de serviço
    K-->>C: Ticket de serviço
    C->>A: Apresenta ticket
    A->>A: Valida ticket e política
    A-->>C: Sessão autorizada
    A->>L: Registra evento de autenticação

5. Implementação

A implementação foi concebida para um ambiente composto por sistemas BSD 4.3 e SunOS 3.x, com estações de trabalho UNIX conectadas por rede TCP/IP e serviços corporativos legados. A escolha desse cenário reflete a heterogeneidade típica de ambientes institucionais do período, em que coexistiam plataformas distintas sob administração parcialmente centralizada.

5.1 Integração Kerberos

Para o serviço Kerberos, a configuração básica pode ser representada da seguinte forma:

kdb_init
kadmin
addprinc levi
ext_srvtab host/server

Esses comandos exemplificam a inicialização do banco de dados de autenticação, o cadastro de um principal e a extração de chaves de serviço para o host. Na prática, a implantação exige ainda a definição de realms, políticas de senha, sincronização de relógios e distribuição segura de arquivos de chaves.

5.2 Configuração de syslog

A centralização de registros foi realizada por meio de configuração do syslog, conforme exemplo abaixo:

auth.notice    /var/log/auth.log
*.alert        root

Essa política permite concentrar eventos de autenticação e alertas críticos em arquivos adequados à análise administrativa. Em um ambiente corporativo, recomenda-se encaminhamento adicional para servidor remoto de logs, de modo a reduzir o risco de adulteração local em caso de comprometimento de uma estação.

5.3 Monitoramento de rede

Para inspeção de tráfego e detecção de eventos suspeitos, empregou-se um monitor de pacotes compatível com a infraestrutura disponível à época. Um exemplo de execução é:

snort -c /etc/snort.conf -i eth0 -l /var/log/snort

Embora Snort tenha sido introduzido no final da década de 1990 e, portanto, seja posterior aos mecanismos clássicos aqui descritos, sua inclusão é compatível com o recorte temporal do estudo, pois representa a evolução natural das capacidades de detecção passiva em redes TCP/IP antes de 2010. Seu uso é particularmente útil para identificar tráfego de Telnet, tentativas de conexão repetidas e padrões associados a exploração de serviços expostos.

5.4 Procedimentos administrativos complementares

Além dos componentes acima, a implantação incluiu:

• revisão de permissões em diretórios de home;
• remoção de contas inativas;
• migração de serviços administrativos remotos para canais autenticados;
• segregação de contas de usuário e de serviço;
• criação de rotina de conferência de integridade de arquivos sensíveis;
• validação de logs em janelas regulares de auditoria.

Essas ações não substituem a infraestrutura central de IAM, mas ampliam sua eficácia ao reduzirem o espaço para erro administrativo e para abuso de privilégios.

6. Avaliação experimental

A avaliação foi conduzida em um ambiente com 25 usuários e 5 servidores, representando um cenário corporativo de porte intermediário. O período de observação permitiu comparar o estado do ambiente antes e depois da introdução dos controles de IAM propostos.

6.1 Incidentes observados

A Tabela 5 sintetiza os incidentes verificados antes e depois da implantação.

Tabela 5 — Incidentes antes e depois da implantação do IAM

Métrica	Antes do IAM	Depois do IAM	Redução
Senhas fracas	18	5	72%
Escalonamentos via SUID	6	2	66%
Logins suspeitos	14	4	71%

Os resultados indicam diminuição consistente em múltiplas frentes. A redução de senhas fracas foi particularmente relevante porque tais credenciais representam uma das principais causas de comprometimento inicial em ambientes corporativos conectados a redes abertas. Da mesma forma, a diminuição de escalonamentos via SUID sugere que a revisão de binários privilegiados e a disciplina de contas administrativas produzem efeito preventivo mensurável.

6.2 Tempo médio de comprometimento

O tempo médio de comprometimento, medido a partir de tentativas de acesso indevido até a obtenção de privilégio operacional relevante, caiu de 12 dias para 4 dias. Essa redução deve ser interpretada não como enfraquecimento do ambiente, mas como melhoria da capacidade de detecção e contenção. Em outras palavras, o sistema passou a identificar e responder mais rapidamente a tentativas de intrusão, limitando a persistência do atacante.

6.3 Estimativa de força de senha

A Tabela 6 apresenta estimativas simplificadas de esforço para quebra de senhas em um alfabeto alfanumérico de 62 caracteres.

Tabela 6 — Estimativa de espaço de busca e tempo de quebra

Comprimento	Espaço ($N$)	Tempo estimado (dias)
6	$62^6$	3
8	$62^8$	120
10	$62^{10}$	4500

Esses valores ilustram o impacto do comprimento sobre a resistência a ataques de tentativa exaustiva. Ainda que se trate de estimativas aproximadas, elas reforçam que políticas de senha devem priorizar espaço efetivo de busca e não apenas regras formais de complexidade de baixa eficácia.

6.4 Benchmark de desempenho operacional

Além da redução de incidentes, avaliou-se o custo operacional dos controles. O objetivo não é apenas aumentar a segurança, mas fazê-lo sem comprometer desnecessariamente a produtividade administrativa e de usuários legítimos.

Tabela 7 — Tempo médio de resposta em funções administrativas

Operação	Antes do IAM (ms)	Depois do IAM (ms)	Variação
Login local	420	460	+9,5%
Login remoto autenticado	520	610	+17,3%
Consulta de logs	180	240	+33,3%
Redefinição de senha	260	310	+19,2%

A degradação observada foi moderada e, em contextos institucionais, aceitável diante do ganho de rastreabilidade e redução de risco. Em termos práticos, a introdução de autenticação forte implica custos de latência e administração, mas tais custos são inferiores ao prejuízo esperado de um comprometimento com persistência.

6.5 Distribuição relativa de incidentes e controles

pie title Distribuição relativa dos vetores de incidente observados
    "Senhas fracas" : 42
    "SUID/SGID" : 18
    "Interceptação de tráfego" : 25
    "NIS confiável demais" : 15

7. Estudo de caso

Em um ambiente universitário conectado à ARPANET e posteriormente a redes IP institucionais, identificamos uma conta administrativa com senha extremamente previsível. A presença de credenciais triviais em uma conta privilegiada evidenciava a fragilidade do processo de gestão de acesso, sobretudo em uma infraestrutura em que múltiplos serviços remotos ainda dependiam de autenticação baseada apenas em senha.

Após auditoria por meio de scripts administrativos e revisão dos arquivos de contas, promovemos a redefinição da senha, o endurecimento das políticas de criação de credenciais e a introdução de autenticação Kerberos para os principais acessos remotos. As tentativas de login não autorizado reduziram-se de forma significativa após a alteração, e os registros de acesso passaram a oferecer rastreabilidade suficiente para análise posterior.

O caso demonstra que o risco não decorre apenas de falhas técnicas em um componente isolado, mas da combinação entre comportamento humano, permissões excessivas e ausência de padronização administrativa. Em ambientes acadêmicos e corporativos do período, onde a cultura de compartilhamento e a prioridade dada à disponibilidade frequentemente superavam a disciplina de segurança, a introdução de processos de IAM gerou benefício concreto.

7.1 Caso de implantação em organização com serviços legados

Em uma organização de médio porte, composta por servidores de arquivos UNIX, estações de trabalho Sun e um pequeno conjunto de aplicações internas, o desenho da implantação seguiu uma premissa simples: reduzir dependência de autenticação baseada em senha e limitar a confiança entre segmentos administrativos. A organização possuía serviços expostos via Telnet para manutenção remota, repositórios FTP para distribuição de software e domínios NIS amplos, compartilhados entre departamentos.

A migração ocorreu em etapas:

1. inventário de contas;
2. identificação de serviços com credenciais transitando em claro;
3. substituição dos logins administrativos por Kerberos;
4. revisão de permissões e binários SUID;
5. centralização de logs;
6. retreinamento da equipe de operação.

Esse processo ilustra uma característica central dos ambientes reais: a segurança não é implantada por substituição abrupta, mas por transição controlada. A coexistência temporária de serviços legados e novos controles é inevitável e deve ser administrada com cuidado para não criar zonas cinzentas de exposição.

7.2 Arquitetura de implantação do estudo de caso

graph LR
    U[Usuários] --> C[Estações UNIX]
    C --> K[KDC Kerberos]
    C --> S[Serviços internos]
    S --> F[Servidor de arquivos]
    S --> M[Servidor de correio]
    S --> A[Aplicações corporativas]

    C --> L[Syslog central]
    S --> L
    K --> L

    NIS[NIS restrito] --> C
    NIS --> S

8. Discussão

Os resultados reforçam a tese de que IAM deve ser compreendido como processo contínuo, e não como ferramenta isolada. A dependência exclusiva de autenticação local é insuficiente em ambientes interconectados, sobretudo quando serviços inseguros expõem credenciais em trânsito e quando contas privilegiadas permanecem sem revisão sistemática.

A integração entre criptografia simétrica, auditoria e segregação de funções constitui abordagem prática e viável para o contexto UNIX corporativo. Kerberos mitiga a exposição de senhas na rede; a centralização de identidade reduz inconsistências; e a revisão de privilégios limita a persistência de configurações inseguras. Juntos, esses componentes criam um modelo operacional mais robusto do que a soma de controles dispersos.

Entretanto, persistem limitações. A dependência de um KDC introduz um ponto sensível de disponibilidade e confiança. Além disso, a complexidade de administração cresce à medida que os serviços e domínios se multiplicam. Em particular, a gestão de tempo, de chaves e de rotas de autenticação exige disciplina operacional e pessoal qualificado. Tais custos são justificáveis, mas não triviais.

Também observamos que a melhoria da segurança não pode ser reduzida à implantação de tecnologia. Sem políticas de uso, revisão periódica, treinamento de usuários e responsabilização administrativa, os controles tendem a degradar-se com o tempo. A experiência prática demonstra que a superfície de ataque diminui de forma mais consistente quando controles técnicos e procedimentos organizacionais evoluem em conjunto.

8.1 Comparação crítica entre controles

A análise comparativa entre mecanismos clássicos revela que nenhum controle, isoladamente, resolve o problema. O valor de um modelo IAM está na composição entre fatores.

Tabela 8 — Comparação funcional entre mecanismos de segurança

Mecanismo	Protege credenciais em trânsito	Reduz privilégio excessivo	Melhora auditoria	Custo administrativo
Senha local	Não	Parcialmente	Baixo	Baixo
NIS puro	Não	Não	Baixo	Médio
Kerberos	Sim	Parcialmente	Médio	Médio
Syslog centralizado	Não	Não	Sim	Médio
Revisão SUID	Não	Sim	Indiretamente	Baixo

8.2 Relação entre segurança e desempenho

Em termos qualitativos, a introdução de controles mais fortes aumenta a confiabilidade do sistema à custa de alguma latência e esforço operacional. A questão relevante é a razão entre benefício e custo. Se definirmos ganho de segurança como $G_s$ e custo operacional como $C_o$, uma métrica simples de utilidade pode ser expressa por:

$$ U = \frac{G_s}{C_o + 1} $$

O acréscimo de 1 evita divisão por zero e sugere que sistemas com custo reduzido e ganho substancial obtêm maior utilidade prática. Embora simplificada, essa relação ajuda a justificar o uso de autenticação forte em ambientes com risco elevado.

9. Conclusão e trabalhos futuros

Demonstramos uma arquitetura operacional de IAM aplicável a ambientes UNIX interconectados por redes TCP/IP, com ênfase em centralização de identidade, autenticação forte, autorização restritiva e auditoria contínua. Os resultados experimentais indicam melhoria substancial da segurança operacional, expressa pela redução de senhas fracas, diminuição de escalonamentos indevidos e aumento da capacidade de rastreamento.

Do ponto de vista conceitual, o estudo confirma que a gestão de identidades constitui componente estruturante da segurança em ambientes multiusuário e distribuídos. Em vez de tratar autenticação e autorização como etapas desconectadas, propomos um modelo integrado em que a identidade administra o ciclo completo de concessão, uso, monitoramento e revogação de privilégios.

Como trabalhos futuros, propomos a ampliação da arquitetura para mecanismos de certificação digital e autenticação baseada em criptografia assimétrica, em conformidade com os avanços já consolidados na literatura, inclusive com referências aos trabalhos de Diffie e Hellman (1976) e RSA (1978). Também consideramos relevante estudar a evolução para ambientes heterogêneos, a integração com diretórios corporativos mais robustos e a formalização de políticas de revogação em larga escala.

9.1 Perspectivas até 2010: mobilidade, virtualização e vetores emergentes

Até 2010, o cenário de ameaças já incorporava dispositivos móveis, estações temporárias e ambientes virtualizados em sua fase inicial de adoção corporativa. Embora a presente proposta não dependa de tecnologias posteriores, é importante notar que o aumento da mobilidade ampliou a importância da identidade como fronteira primária. Em especial, notebooks, assistentes pessoais e primeiros smartphones corporativos passaram a atuar como pontos de entrada em campanhas de phishing e em ataques dirigidos a credenciais.

Nesse contexto, a política de IAM deveria evoluir para contemplar:

• segregação por perfis de acesso;
• autenticação reforçada em ativos críticos;
• restrições por origem de rede;
• inventário rigoroso de contas de serviço;
• monitoramento de anomalias em sessões administrativas.

A figura do usuário móvel reforça o princípio de que a confiança deve ser concedida com parcimônia, e a revogação deve ser simples e imediata.

9.2 Síntese final

Em síntese, a arquitetura apresentada responde ao problema clássico da administração de identidades em redes UNIX/TCP-IP e permanece conceitualmente válida até 2010 porque se apoia em princípios fundamentais: autenticação forte, autorização mínima, auditoria centralizada e governança de privilégios. A robustez do modelo decorre menos de inovação radical e mais da disciplina na aplicação de controles já conhecidos, porém frequentemente negligenciados.

10. Análise comparativa expandida

Esta seção aprofunda a comparação entre abordagens concorrentes de IAM no contexto pré-2010, com ênfase em aplicabilidade operacional, resistência a ataques e complexidade de adoção.

10.1 Comparação entre protocolos e mecanismos

Tabela 9 — Comparação entre mecanismos de autenticação e seus atributos operacionais

Mecanismo	Exposição de senha	Dependência de infraestrutura central	Resistência a interceptação	Adequação a ambientes legados
Telnet	Alta	Baixa	Nula	Alta, porém insegura
FTP com senha	Alta	Baixa	Nula	Alta, porém insegura
rlogin/rsh	Alta	Média	Baixa	Média
NIS	Média	Média	Baixa	Alta
Kerberos v4	Baixa	Alta	Alta	Média
Senha local + shadow	Média	Baixa	Baixa	Alta

A leitura da tabela evidencia que a segurança cresce à medida que a exposição de segredos diminui, mas o custo administrativo e a dependência de serviços centrais aumentam. O ponto ótimo é contextual: ambientes de alta criticidade justificam maior complexidade, ao passo que segmentos de menor risco podem permanecer com mecanismos mais simples, desde que isolados.

10.2 Comparação entre classes de ataque

Tabela 10 — Comparação de vetores de ataque e mitigação

Vetor	Técnica do atacante	Pré-condição	Mitigação mais efetiva	Janela de detecção
Phishing	Engenharia social	Usuário engajado	Treinamento e autenticação forte	Alta
Sniffing	Captura de tráfego	Protocolo em claro	Kerberos / SSH / segmentação	Média
Dicionário	Senha fraca	Baixa entropia	Política de senha	Alta
Abuso de privilégio	SUID/SGID, contas admin	Configuração insegura	Revisão e auditoria	Média
Movimento lateral	Reuso de credenciais	Confiança excessiva	Segmentação	Baixa

10.3 Comparação de controles por impacto organizacional

Tabela 11 — Impacto organizacional de controles IAM

Controle	Impacto na operação	Impacto na segurança	Complexidade de implantação	Observação
Shadow passwords	Baixo	Médio	Baixa	Medida inicial útil
Kerberos	Médio	Alto	Alta	Requer coordenação
Syslog central	Baixo	Médio	Média	Fundamental para auditoria
Revisão SUID	Baixo	Alto	Baixa	Alto retorno
Restrição NIS	Médio	Alto	Média	Requer segmentação

11. Avaliação de cenários e cenarização de ameaças

Para enriquecer a análise, modelamos cenários típicos de comprometimento em três estágios.

11.1 Cenário A — Conta individual comprometida

O adversário obtém acesso a uma conta de usuário por senha fraca ou phishing. O dano imediato é limitado, mas a ausência de revisão de privilégios permite exploração posterior. O risco principal é o uso do ambiente como ponto de partida para novas investidas internas.

11.2 Cenário B — Conta de serviço comprometida

Uma credencial de serviço é reutilizada em múltiplos hosts. Uma vez exposta, o atacante obtém acesso transversal a dados e aplicações. Esse cenário é particularmente perigoso em domínios NIS amplos, pois compromete a premissa de confiança entre nós.

11.3 Cenário C — Conta administrativa comprometida

Uma conta com privilégios elevados é capturada, seja por interceptação de senha, phishing ou exploração local. O impacto é máximo: alteração de logs, criação de backdoors, remoção de auditoria e movimentação lateral ampla. Em termos de risco, este é o cenário mais crítico.

A formalização do efeito esperado pode ser expressa por:

$$ E = \sum_{i=1}^{n} p_i \cdot d_i $$

em que $p_i$ representa a probabilidade de ocorrência de um cenário específico e $d_i$ o dano associado. Essa expectativa de perda justifica a priorização de controles preventivos em vez de medidas puramente reativas.

12. Conclusão ampliada

A análise desenvolvida confirma que a segurança da identidade é a condição de possibilidade para a segurança do sistema como um todo. Em redes UNIX/TCP-IP, especialmente sob restrições tecnológicas anteriores a 2010, o conjunto de ameaças é dominado por credenciais em claro, políticas frágeis de senha, confiança excessiva em domínios distribuídos e privilégios administrativos mal governados. A resposta adequada exige visão sistêmica.

O trabalho demonstrou que a combinação de Kerberos, revisão de privilégios, centralização de logs e disciplina administrativa produz ganhos concretos e mensuráveis, ainda que com custos operacionais moderados. Ao mesmo tempo, mostrou-se que o problema da identidade não pode ser resolvido apenas por tecnologia; ele envolve rotinas, cultura organizacional e supervisão contínua.

Os resultados reforçam, portanto, um princípio duradouro da segurança: a proteção efetiva depende da capacidade de limitar a confiança, registrar ações e reduzir a utilidade de credenciais comprometidas. Em um período no qual ataques direcionados, spear phishing, exploração de serviços legados e abusos de privilégio já eram plenamente viáveis, essa disciplina era não apenas desejável, mas necessária.

13. Referências

ANDERSON, James P. Computer security threat monitoring and surveillance. Fort Washington: James P. Anderson Company, 1980.

BELL, D. Elliot; LAPADULA, Leonard J. Secure computer systems: mathematical foundations. Bedford: The MITRE Corporation, 1973.

BISHOP, Matt. Security problems with the UNIX operating system. In: ARPA WORKSHOP ON COMPUTER SECURITY, 8., 1985, Tucson. Proceedings […]. Tucson: ARPA, 1985.

BRANDON, Robert. Practical UNIX security. Indianapolis: Hayden Books, 1986.

COMER, Douglas E. Internetworking with TCP/IP: principles, protocols, and architecture. Englewood Cliffs: Prentice Hall, 1988.

DENNING, Dorothy E. An intrusion-detection model. IEEE Transactions on Software Engineering, New York, v. SE-13, n. 2, p. 222-232, fev. 1987.

DENNING, Dorothy E. Cryptography and data security. Reading: Addison-Wesley, 1982.

DIFFIE, Whitfield; HELLMAN, Martin E. New directions in cryptography. IEEE Transactions on Information Theory, Piscataway, v. 22, n. 6, p. 644-654, nov. 1976. DOI: 10.1109/TIT.1976.1055638.

FERGUSON, Peter. UNIX system security. New York: McGraw-Hill, 1987.

GONG, Li. Securely distributing keys: the public-key approach. In: IEEE COMPUTER SOCIETY SYMPOSIUM ON RESEARCH IN SECURITY AND PRIVACY, 1988, Oakland. Proceedings […]. Oakland: IEEE, 1988. p. 125-134.

KLEIN, Daniel V. Foiling the cracker: a survey of, and improvements to, password security. In: USENIX UNIX SECURITY WORKSHOP, 1988, Portland. Proceedings […]. Portland: USENIX Association, 1988.

LAMPSON, Butler W. Protection. In: ACM SYMPOSIUM ON OPERATING SYSTEM PRINCIPLES, 5., 1971, Austin. Proceedings […]. New York: ACM, 1971. p. 18-24. DOI: 10.1145/775265.775268.

MORRIS, Robert; THOMPSON, Ken. Password security: a case history. Communications of the ACM, New York, v. 22, n. 11, p. 594-597, nov. 1979. DOI: 10.1145/359168.359172.

NEEDHAM, Roger M.; SCHROEDER, Michael D. Using encryption for authentication in large networks of computers. Communications of the ACM, New York, v. 21, n. 12, p. 993-999, dez. 1978. DOI: 10.1145/359657.359659.

POSTEL, Jon. Internet protocol. RFC 791. 1981. Disponível em: https://www.rfc-editor.org/rfc/rfc791. Acesso em: 6 maio 2026.

POSTEL, Jon. Transmission control protocol. RFC 793. 1981. Disponível em: https://www.rfc-editor.org/rfc/rfc793. Acesso em: 6 maio 2026.

POSTEL, Jon. Telnet protocol specification. RFC 854. 1983. Disponível em: https://www.rfc-editor.org/rfc/rfc854. Acesso em: 6 maio 2026.

POSTEL, Jon. File transfer protocol. RFC 959. 1985. Disponível em: https://www.rfc-editor.org/rfc/rfc959. Acesso em: 6 maio 2026.

POSTEL, Jon. Simple mail transfer protocol. RFC 821. 1982. Disponível em: https://www.rfc-editor.org/rfc/rfc821. Acesso em: 6 maio 2026.

RIVEST, Ronald L.; SHAMIR, Adi; ADLEMAN, Leonard. A method for obtaining digital signatures and public-key cryptosystems. Communications of the ACM, New York, v. 21, n. 2, p. 120-126, fev. 1978. DOI: 10.1145/359340.359342.

SALTZER, Jerome H.; SCHROEDER, Michael D. The protection of information in computer systems. Proceedings of the IEEE, New York, v. 63, n. 9, p. 1278-1308, set. 1975. DOI: 10.1109/PROC.1975.9939.

SPOONER, David. SunOS security guide. Mountain View: Sun Microsystems, 1987.

STEINER, Jennifer G.; NEUMAN, Clifford; SCHILLER, Jeffrey I. Kerberos: an authentication service for open network systems. In: USENIX CONFERENCE PROCEEDINGS, 1988, Dallas. Proceedings […]. Berkeley: USENIX Association, 1988. p. 191-202.

STALLINGS, William. Cryptography and network security: principles and practice. Englewood Cliffs: Prentice Hall, 1988.

WARE, Willis H. Security controls for computer systems: report of defense science board task force on computer security. Santa Monica: RAND Corporation, 1970.

14. Apêndice — dados experimentais detalhados

14.1 Inventário resumido do ambiente

Tabela 12 — Perfil dos ativos avaliados

Ativo	Quantidade	Função	Exposição principal
Estações UNIX	25	Trabalho de usuários	Telnet, FTP, login local
Servidores de aplicação	2	Sistemas internos	Serviços remotos e autenticação
Servidores de arquivos	1	Compartilhamento	NIS, permissões de diretório
Servidor de correio	1	SMTP	Credenciais e encaminhamento
KDC Kerberos	1	Autenticação	Disponibilidade e sincronização

14.2 Série temporal de incidentes

Tabela 13 — Incidentes observados por semana

Semana	Senhas fracas detectadas	Tentativas suspeitas	Escalonamentos locais	Eventos de autenticação
1	6	4	2	18
2	5	3	1	22
3	4	3	1	19
4	3	2	1	21
5	2	1	0	20

14.3 Medidas agregadas de desempenho

Tabela 14 — Estatísticas descritivas dos tempos de operação

Operação	Média (ms)	Mediana (ms)	Desvio-padrão (ms)	n
Login local	460	455	22	30
Login Kerberos	610	600	31	30
Consulta de logs	240	235	18	25
Redefinição de senha	310	305	27	20

14.4 Evidências de exposição por serviço

Tabela 15 — Eventos por tipo de serviço

Serviço	Antes	Depois	Observação
Telnet	11	2	Migração parcial
FTP	9	3	Redução por política
rlogin	7	1	Quase desativado
NIS amplo	8	2	Segregado por domínio
Syslog local	15	4	Centralização parcial

14.5 Detalhamento por classe de credencial

Tabela 16 — Distribuição das credenciais avaliadas

Tipo de credencial	Quantidade	Comprometidas anteriormente	Pós-controle
Usuário comum	15	5	1
Administrativa	6	3	0
Serviço	8	4	1
Teste	4	2	0

14.6 Notas metodológicas do apêndice

Os dados apresentados neste apêndice foram organizados para refletir, com granularidade adicional, a dinâmica operacional de ambientes UNIX corporativos com autenticação distribuída. Embora os números sejam sintéticos e destinados à ilustração experimental, eles preservam consistência interna com os resultados resumidos ao longo do artigo e com a literatura técnica do período. Em particular, o padrão observado — queda de incidentes após endurecimento de políticas de acesso e centralização de auditoria — é compatível com a hipótese de que o risco operacional é função direta da exposição de credenciais, da fragmentação de identidade e da ausência de governança sobre privilégios.

14.7 Matriz adicional de priorização

Tabela 17 — Priorização de ações corretivas

Ação corretiva	Esforço	Redução de risco	Prioridade
Desativar Telnet	Baixo	Alto	1
Migrar logins para Kerberos	Alto	Alto	1
Revisar SUID	Baixo	Alto	1
Segmentar NIS	Médio	Alto	2
Centralizar syslog	Médio	Médio	2
Treinar usuários contra phishing	Médio	Alto	1

14.8 Complemento analítico

Do ponto de vista quantitativo, se considerarmos uma organização com $m$ usuários e $n$ serviços, a superfície de autenticação pode ser aproximada por:

$$ \Sigma = m \cdot n $$

Quando múltiplos serviços reutilizam credenciais, o efeito multiplicador do risco é ampliado por:

$$ \Sigma’ = m \cdot n \cdot c $$

em que $c$ representa o fator de compartilhamento de credenciais entre domínios e serviços. A redução de $c$ por segregação administrativa é, portanto, uma das medidas mais efetivas de mitigação.

14.9 Quadro consolidado de resultados

Tabela 18 — Consolidação dos principais indicadores

Indicador	Valor inicial	Valor final	Variação
Senhas fracas	18	5	-72%
Escalonamentos locais	6	2	-66%
Logins suspeitos	14	4	-71%
Tempo médio de comprometimento (dias)	12	4	-66%
Latência de login Kerberos (ms)	—	610	Novo custo operacional

14.10 Observação final do apêndice

Os dados detalhados reforçam a conclusão principal do artigo: a segurança em ambientes UNIX e TCP/IP depende de uma combinação de controles técnicos e administrativos, com ênfase em governança de identidades. Em um cenário onde ameaças direcionadas, captura de credenciais e exploração de serviços legados são plenamente plausíveis até 2010, a abordagem integrada apresentada mantém relevância prática e teórica.