Software · Segurança & Identidade
Modelos Clássicos de Controle de Acesso: DAC, MAC e ACLs
A fundamentação teórica dos modelos de controle de acesso: Discretionary Access Control (DAC), Mandatory Access Control (MAC) e Listas de Controle de Acesso (ACLs) em sistemas operacionais e nuvem.
Neste artigo
Antes do surgimento do Role-Based Access Control (RBAC) e do Attribute-Based Access Control (ABAC) em aplicações web modernas, a ciência da computação desenvolveu modelos formais rigorosos para proteger arquivos e recursos contra acessos indevidos. Compreender os modelos DAC, MAC e ACLs é indispensável para operar sistemas Linux com SELinux e gerenciar permissões no sistema de arquivos NTFS ou em storages de nuvem.
flowchart TD
subgraph ModelosAcesso["Evolução dos Modelos Formais de Acesso"]
DAC["DAC (Discretionary Access Control)<br/>O dono do arquivo define as permissões livremente (chmod 777)"]
MAC["MAC (Mandatory Access Control)<br/>A política central do sistema manda; nem o dono pode burlar (SELinux)"]
ACL["ACLs (Access Control Lists)<br/>Matriz granular associando sujeitos a direitos específicos"]
end
DAC --> MAC
DAC --> ACL
MAC --> RBAC_ABAC["RBAC & ABAC Modernos"]
DAC: Controle de Acesso Discricionário
No DAC, todo recurso possui um usuário proprietário (owner). O dono tem discrição total para conceder ou revogar permissões de leitura, escrita e execução para outros usuários e grupos:
- Exemplo canônico: o sistema de permissões clássico POSIX no Linux (
rwxr-xr-x). - A fragilidade do DAC é óbvia: se um processo executado pelo usuário for infectado por um cavalo de Troia, o malware herda todos os direitos do usuário e pode abrir arquivos sigilosos para leitura pública sem que o sistema operacional impeça.
MAC: Controle de Acesso Mandatório
No MAC, nem os donos dos arquivos nem os usuários possuem poder para alterar regras de acesso por conta própria. Uma autoridade central de segurança define rótulos de segurança (labels) tanto para os sujeitos (processos) quanto para os objetos (arquivos, sockets, portas).
O exemplo mais emblemático em servidores modernos é o SELinux (Security-Enhanced Linux):
- Cada processo roda em um domínio específico (ex:
httpd_tpara o servidor web Apache). - Mesmo que um invasor execute um exploit de injeção e assuma a identidade de
rootno processo do Apache, a política mandatória do kernel bloqueia o acesso do domíniohttpd_ta qualquer arquivo fora de/var/www, como o arquivo/etc/shadow.
Listas de Controle de Acesso (ACLs)
As permissões tradicionais do Linux (dono, grupo e outros) são restritivas demais quando um projeto precisa dar acesso de escrita a três usuários distintos sem reuni-los em um novo grupo no sistema. As ACLs resolvem isso permitindo anexar regras explícitas a cada objeto:
# Configurando uma ACL POSIX no Linux para um usuário específico
setfacl -m u:marcos:rw- /var/projetos/financeiro/relatorio.xlsx
# Exibindo a ACL completa do arquivo
getfacl /var/projetos/financeiro/relatorio.xlsx
| Modelo | Autoridade que Define Regras | Flexibilidade | Nível de Segurança | Onde Encontrar Hoje |
|---|---|---|---|---|
| DAC | O próprio criador/proprietário do objeto | Altíssima | Médio/Baixo (vulnerável a erros do usuário) | chmod clássico em Linux e macOS |
| MAC | Política do kernel / Administrador de segurança | Baixa / Rígida | Altíssimo (blindagem contra escalada de privilégios) | SELinux, AppArmor, ambientes militares |
| ACLs | Administrador do arquivo ou diretório | Alta | Elevado | NTFS do Windows, POSIX ACLs, Azure Files |
Reconhecer esses modelos permite diagnosticar bloqueios crônicos de permissão em containers e pipelines de dados sem apelar para a prática perigosa do chmod 777.