Hardening de Sistemas Linux

1. Introdução e princípios fundamentais de hardening

O sistema operacional Linux sustenta a esmagadora maioria dos servidores corporativos, ambientes de computação em nuvem, orquestradores de contêineres e controladores de automação em infraestruturas críticas. Entretanto, a vasta maioria das distribuições padrão é concebida visando facilidade de instalação, compatibilidade abrangente de periféricos e conveniência imediata para o operador, ao invés de máxima blindagem defensiva.

Uma instalação típica recém-concluída inclui dezenas de utilitários auxiliares em execução, regras de filtragem de pacotes vazias ou permissivas, bibliotecas legadas e parametrizações de kernel que priorizam throughput imediato em detrimento da mitigação de falhas de memória. Essa condição estabelece uma ampla superfície de ataque, compreendida como a soma de todas as portas abertas, caminhos de execução, interfaces expostas e pontos vulneráveis onde um invasor pode tentar violar o sistema ou extrair dados sigilosos.

O processo de hardening (endurecimento de sistemas) consiste em configurar metódica e defensivamente o sistema operacional e suas camadas de sustentação para erradicar privilégios supérfluos, fechar caminhos residuais de ataque e estabelecer barreiras concêntricas de proteção. Os quatro pilares fundamentais que norteiam essa estratégia estão consolidados na Tabela 1.

2. Frameworks globais de conformidade (CIS e DISA STIG)

Para evitar configurações empíricas ou divergências entre administradores de sistemas, a indústria de segurança consolidou padrões normativos rigorosos, amplamente aceitos e auditáveis internacionalmente.

2.1 CIS Benchmarks (Center for Internet Security)

Desenvolvidos por meio de um consenso global entre pesquisadores de segurança, agências de governo e fabricantes, os guias do CIS (Center for Internet Security) são referências para o endurecimento de distribuições como RHEL (Red Hat Enterprise Linux), Debian, Ubuntu e Rocky Linux. Os benchmarks dividem as configurações em dois patamares de exigência:

• CIS Level 1: Conjunto fundamental de controles recomendados para todos os servidores. Oferece alta elevação de postura de segurança com mínimo impacto sobre a estabilidade operacional e compatibilidade de aplicações corporativas.
• CIS Level 2: Recomendações mais restritivas para ambientes de alto risco (serviços de pagamento, sistemas financeiros, infraestruturas críticas e órgãos de defesa). Exige planejamento criterioso pois pode desabilitar mecanismos de depuração e serviços de compatibilidade legada.

2.2 DISA STIGs (Defense Information Systems Agency)

Os STIG (Security Technical Implementation Guide) publicados pela DISA (Defense Information Systems Agency) são normas mandatórias para sistemas empregados no Departamento de Defesa dos Estados Unidos e órgãos de segurança pública. Classificam as fraquezas técnicas em três categorias de severidade:

• CAT I (Severidade Máxima): Falhas que permitem acesso root imediato ou execução de código remoto por agentes maliciosos não autorizados. Devem ser remediadas sem tolerância.
• CAT II (Severidade Média): Vulnerabilidades que facilitam escalonamento de privilégios locais ou ampliam o impacto de brechas intermediárias.
• CAT III (Severidade Baixa): Inconsistências de configuração, visibilidade excessiva de dados cadastrais ou ausência de banners legais de aviso.

2.3 Automação e Verificação com OpenSCAP

A verificação manual de centenas de parâmetros prescritos em um CIS Benchmark é inviável em escala. O padrão SCAP (Security Content Automation Protocol) foi concebido para resolver esse desafio, permitindo a expressão de políticas de segurança em formato legível por computadores. A ferramenta oscap (da suíte OpenSCAP) executa auditorias comparando a máquina contra perfis CIS ou STIG em segundos:

# Executando varredura automatizada de conformidade CIS Level 1
oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_cis \
  --results /var/log/oscap-results.xml \
  --report /var/log/oscap-report.html \
  /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

3. Segurança do kernel e parametrização com sysctl

O kernel Linux atua como mediador soberano de todos os recursos de hardware, memória, rede e processos do computador. O utilitário sysctl permite ajustar parâmetros dinâmicos em tempo de execução, localizados no pseudo-sistema de arquivos /proc/sys/.

Para garantir que as diretivas persistam entre reinicializações do sistema, os parâmetros de endurecimento devem ser inseridos em um arquivo dedicado, comumente denominado /etc/sysctl.d/99-security-hardening.conf, e aplicados imediatamente com o comando sysctl --system.

3.1 Proteção de Memória e Mitigação de Exploits

# Habilitação de ASLR completa (Address Space Layout Randomization)
# Embaralha posições da pilha, memória virtual e mapeamento de bibliotecas
kernel.randomize_va_space = 2

# Ocultação de ponteiros internos de memória do kernel para usuários não privilegiados
kernel.kptr_restrict = 2

# Restrição de acesso ao buffer de mensagens do kernel (dmesg)
kernel.dmesg_restrict = 1

# Bloqueio de carregamento arbitrário de disciplinas de linha TTY
dev.tty.ldisc_autoload = 0

# Restrição de uso de ptrace apenas para processos com privilégios adequados
kernel.yama.ptrace_scope = 2

# Desativação de combinações de teclas SysRq que permitem reinicializações não autorizadas
kernel.sysrq = 0

3.2 Proteção de Sistema de Arquivos contra Abusos de Links e Pipes

# Impede criação de links simbólicos em diretórios públicos como /tmp
fs.protected_symlinks = 1

# Impede criação de hard links para arquivos pertencentes a outros usuários
fs.protected_hardlinks = 1

# Protege contra abuso de FIFOs (First-In, First-Out) em diretórios graváveis por todos
fs.protected_fifos = 2

# Protege contra abertura de arquivos comuns em diretórios públicos
fs.protected_regular = 2

# Eleva o limite de descritores de arquivos abertos para serviços protegidos
fs.file-max = 2097152

3.3 Blindagem da Pilha de Rede (IPv4 e IPv6)

# Desativação imediata de roteamento de pacotes (caso a máquina não seja roteador)
net.ipv4.ip_forward = 0
net.ipv6.conf.all.forwarding = 0

# Ativação de validação de rota reversa (anti-spoofing) em todas as interfaces
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# Rejeição de redirecionamentos ICMP (Internet Control Message Protocol)
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.default.accept_redirects = 0

# Não envio de mensagens de redirecionamento ICMP
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0

# Rejeição de pacotes com roteamento pela origem (Source Routing)
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0

# Mitigação de ataques de inundação SYN (SYN Flood DoS)
net.ipv4.tcp_syncookies = 1

# Registro em log de pacotes com endereçamento impossível (martian packets)
net.ipv4.conf.all.log_martians = 1
net.ipv4.conf.default.log_martians = 1

# Ignorar requisições de eco ICMP broadcast (mitigação de amplificação Smurf)
net.ipv4.icmp_echo_ignore_broadcasts = 1

4. Gerenciamento de autenticação e módulos PAM

O framework PAM (Pluggable Authentication Modules) padroniza como as aplicações no Linux autenticam identidades, gerenciam senhas e inicializam sessões interativas. O controle rigoroso do PAM impede abusos de força bruta e assegura senhas de alta entropia.

4.1 Políticas de Complexidade de Senhas com pam_pwquality

O módulo pam_pwquality.so substitui a antiga biblioteca cracklib e aplica regras estritas durante a definição ou troca de credenciais de usuário. No arquivo /etc/security/pwquality.conf:

# Comprimento mínimo absoluto de 14 caracteres
minlen = 14

# Exigência de pelo menos 1 dígito numérico
dcredit = -1

# Exigência de pelo menos 1 letra maiúscula
ucredit = -1

# Exigência de pelo menos 1 letra minúscula
lcredit = -1

# Exigência de pelo menos 1 caractere especial pontual
ocredit = -1

# Diferença mínima de 4 caracteres em relação à senha anterior
difok = 4

# Máximo de caracteres repetidos sequenciais permitidos
maxrepeat = 3

# Validação do dicionário para rejeitar senhas triviais e padrões comuns
dictcheck = 1

4.2 Proteção Contra Força Bruta com pam_faillock

O módulo pam_faillock.so monitora tentativas de login frustradas por usuário ou endereço, bloqueando a conta temporariamente para conter ataques automatizados de adivinhação:

# Em /etc/security/faillock.conf
# Bloqueio após 3 tentativas inválidas
deny = 3

# Duração do bloqueio: 900 segundos (15 minutos)
unlock_time = 900

# Janela temporal para contabilização das falhas consecutivas
fail_interval = 900

# Aplicação do bloqueio inclusive para tentativas no usuário root
even_deny_root = 1

# Duração do bloqueio específica para a conta de superusuário
root_unlock_time = 300

4.3 Autenticação Multifator com TOTP e Chaves FIDO2

A dependência exclusiva de senhas alfanuméricas é insuficiente diante de ameaças contemporâneas de phishing e vazamento de credenciais. O Linux suporta autenticação em múltiplos fatores MFA (Multi-Factor Authentication) por meio de módulos especializados:

• TOTP (Time-based One-Time Password): Implementado via pam_google_authenticator.so, exigindo códigos numéricos rotativos gerados por aplicativo móvel a cada 30 segundos.
• FIDO2 / U2F (Universal 2nd Factor): Implementado através de pam_u2f.so, exigindo a inserção e toque físico em uma chave de segurança de hardware criptográfica, blindando o acesso contra interceptações intermediárias.

5. Controle de acesso mandatório: SELinux e AppArmor

O modelo clássico de permissões do Linux é o DAC (Discretionary Access Control), no qual o proprietário de um arquivo ou processo define livremente as permissões de leitura, escrita e execução (rwx) com base no padrão POSIX (Portable Operating System Interface). A fraqueza intrínseca do DAC é evidente: se um processo executado pelo usuário www-data for explorado por uma injeção de comandos, o invasor herda todos os direitos do usuário e pode ler qualquer arquivo cujo acesso pertença àquele grupo.

Os sistemas de MAC (Mandatory Access Control) solucionam essa deficiência impondo políticas compulsórias no núcleo do kernel, desacopladas da vontade do usuário individual. Mesmo que um atacante obtenha acesso shell através de um serviço web, o kernel impedirá que ele execute comandos externos ou acesse diretórios não contemplados na política do processo, como detalhado na Tabela 2.

6. Endurecimento do serviço OpenSSH

O protocolo SSH (Secure Shell) é a principal porta de entrada administrativa em servidores Linux. Devido à sua exposição frequente à Internet ou redes corporativas, ele constitui o alvo mais atacado por agentes maliciosos em campanhas de varredura e força bruta automatizada.

O endurecimento do daemon OpenSSH exige a edição minuciosa do arquivo /etc/ssh/sshd_config (ou de arquivos segregados em /etc/ssh/sshd_config.d/), desativando recursos legados e impondo criptografia robusta.

6.1 Configuração Recomendada de sshd_config

# Impedir acesso direto com a conta root; obriga uso de usuário nomeado e sudo
PermitRootLogin no

# Desativar autenticação por senha convencional
PasswordAuthentication no
PermitEmptyPasswords no

# Obrigar autenticação com chaves criptográficas modernas
PubkeyAuthentication yes

# Limitar o número máximo de tentativas de autenticação antes de encerrar o socket
MaxAuthTries 3

# Tempo limite para conclusão do processo de login (em segundos)
LoginGraceTime 30

# Desativar redirecionamento de interface gráfica (X11) e portas desnecessárias
X11Forwarding no
AllowTcpForwarding no
AllowAgentForwarding no

# Encerramento preventivo de sessões inativas (5 minutos sem resposta encerra)
ClientAliveInterval 300
ClientAliveCountMax 0

# Desativar autenticação baseada em host e compatibilidade com Rhosts
HostbasedAuthentication no
IgnoreRhosts yes

# Restringir os usuários autorizados a conectar via SSH
AllowGroups sysadmins devops-sec

6.2 Criptografia Forte e Desativação de Algoritmos Fracos

Padrões como CIS e DISA exigem a desativação de cifras fracas (como DES, 3DES, RC4 e qualquer variante CBC do AES), além de trocas de chave baseadas em RSA (Rivest-Shamir-Adleman) de tamanho reduzido ou curvas elípticas vulneráveis:

# Algoritmos recomendados para troca de chaves (KEX)
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512

# Cifras simétricas de alto desempenho e autenticadas (AEAD)
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com

# Códigos de autenticação de mensagem (MACs) íntegros
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

7. Segmentação de rede e firewall de host com nftables

O firewall local do servidor (firewall de host) atua como o último anel defensivo caso as proteções perimetrais de rede falhem ou caso ocorra um comprometimento lateral dentro do mesmo segmento de rede local.

A estrutura moderna de firewall no Linux é o nftables, que substituiu completamente a antiga e fragmentada família de ferramentas iptables, ip6tables e ebtables. O nftables oferece maior eficiência de processamento, regras combinadas para IPv4 e IPv6 em uma única tabela (família inet), e sintaxe unificada.

7.1 Modelo de Negação por Padrão (Default Drop)

A diretriz elementar consiste em rejeitar qualquer pacote de entrada ou encaminhamento por padrão, liberando unicamente as conexões comprovadamente necessárias para a missão do host, conforme ilustrado no arquivo /etc/nftables.conf:

#!/usr/sbin/nft -f

# Limpar regras anteriores
flush ruleset

table inet filter {
    # Conjunto para limitação de taxa contra abusos na porta SSH
    set ssh_flood {
        type ipv4_addr
        flags dynamic
        timeout 1m
        size 65535
    }

    chain input {
        type filter hook input priority filter; policy drop;

        # 1. Permitir tráfego na interface local de loopback
        iifname "lo" accept

        # 2. Rejeitar pacotes com estados inválidos
        ct state invalid drop

        # 3. Permitir conexões já estabelecidas e relacionadas
        ct state { established, related } accept

        # 4. Aceitar ICMP para diagnóstico básico com limitação de taxa
        ip protocol icmp icmp type { echo-request, destination-unreachable, time-exceeded } limit rate 5/second accept
        ip6 nexthdr icmpv6 accept

        # 5. Acesso SSH condicionado a rate-limiting preventivo
        tcp dport 22 meter flood { ip saddr ct count over 5 } drop
        tcp dport 22 ct state new accept

        # 6. Serviços autorizados (exemplo: Servidor Web Seguro)
        tcp dport { 80, 443 } ct state new accept

        # 7. Descarte explícito de todo o restante com contagem
        counter drop
    }

    chain forward {
        type filter hook forward priority filter; policy drop;
    }

    chain output {
        type filter hook output priority filter; policy accept;
    }
}

8. Auditoria contínua do sistema com auditd

A rastreabilidade de eventos é indispensável para responder a incidentes e identificar invasões com precisão. O subsistema auditd opera integrado ao kernel Linux, interceptando chamadas de sistema (syscalls), alterações em arquivos críticos e trocas de identidade de processos em tempo real.

8.1 Regras Essenciais de Auditoria

As regras de auditoria devem ser estruturadas em arquivos sob /etc/audit/rules.d/audit.rules. Elas recebem identificadores temáticos (-k chave) para facilitar a pesquisa subsequente:

# Monitoramento de alterações em contas e credenciais de usuários
-w /etc/passwd -p wa -k identity_changes
-w /etc/shadow -p wa -k identity_changes
-w /etc/group -p wa -k identity_changes
-w /etc/gshadow -p wa -k identity_changes
-w /etc/security/opasswd -p wa -k identity_changes

# Monitoramento de privilégios e delegação administrativa
-w /etc/sudoers -p wa -k privileged_actions
-w /etc/sudoers.d/ -p wa -k privileged_actions

# Auditoria de inicialização de processos com bits SUID e SGID
-a always,exit -F arch=b64 -S execve -C uid!=euid -F euid=0 -k elevated_execution
-a always,exit -F arch=b32 -S execve -C uid!=euid -F euid=0 -k elevated_execution

# Auditoria de modificação de data e relógio (mitigação de adulteração forense)
-a always,exit -F arch=b64 -S adjtimex -S settimeofday -S clock_settime -k time_modification
-w /etc/localtime -p wa -k time_modification

# Proteção da própria configuração do subsistema de auditoria
-w /etc/audit/ -p wa -k audit_config
-w /var/log/audit/ -p wa -k audit_logs

# Travar as regras contra alterações em tempo de execução sem reboot
-e 2

Para extrair informações dos registros gravados em /var/log/audit/audit.log, utilizam-se os utilitários ausearch (pesquisa parametrizada por chaves, usuários ou chamadas de sistema) e aureport (geração de sumários consolidados de anomalias e falhas de login).

9. Criptografia de dados em repouso com LUKS e TPM 2.0

Servidores físicos instalados em data centers remotos ou filiais estão sujeitos a riscos de roubo físico de unidades de armazenamento ou adulterações diretas durante o ciclo de transporte e descarte de mídias. A criptografia de dados em repouso impede que informações confidenciais sejam acessadas fora do ambiente autorizado.

9.1 LUKS e dm-crypt

O mecanismo LUKS (Linux Unified Key Setup) é a especificação padrão para criptografia de dispositivos de bloco no ecossistema Linux. Ele opera por meio do módulo de kernel dm-crypt, provendo transparência total para o sistema de arquivos superior e aplicando cifras de fluxo ou bloco como AES-XTS com chaves de 256 ou 512 bits.

9.2 Desbloqueio Seguro Medido via TPM 2.0

A digitação manual de senhas de boot (passphrases) em servidores remotos introduz entraves operacionais severos durante reinicializações. A solução moderna para conciliar automação e segurança consiste em vincular a chave de descriptografia do volume LUKS ao chip TPM (Trusted Platform Module) 2.0 presente na placa-mãe.

Utilizando a integração com systemd-cryptenroll, a chave só é liberada se o firmware do computador, o carregador de inicialização (GRUB), os módulos do kernel e a linha de comando de boot estiverem perfeitamente íntegros e não tiverem sofrido adulteração, condição mensurada através dos registradores de configuração de plataforma PCR (Platform Configuration Register):

# Registrando a partição criptografada no TPM 2.0 associada aos PCRs 0, 2 e 7
# PCR 0: Firmware/BIOS original; PCR 2: Código de boot; PCR 7: Estado do Secure Boot
systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=0+2+7 /dev/nvme0n1p3

10. Higiene de arquivos, privilégios e binários SUID

O sistema de privilégios do Linux conta com bits especiais de execução que podem introduzir riscos severos se concedidos a binários desnecessários:

• SUID (Set Owner User ID): Faz com que o arquivo executável rode temporariamente com as permissões do seu proprietário, habitualmente o usuário root. Exemplos comuns incluem passwd e su.
• SGID (Set Group ID): Faz com que o arquivo execute com as permissões do grupo atribuído, permitindo acesso compartilhado a determinados recursos locais.

Se um binário com bit SUID contiver falhas de estouro de buffer (buffer overflow) ou permitir a chamada de comandos shell externos sem saneamento, um atacante local pode explorar o executável para obter privilégios integrais de superusuário instantaneamente.

10.1 Mapeamento e Remoção de Bits SUID Excessivos

# Localização de todos os binários com SUID no sistema
find / -perm /4000 -type f -exec ls -ld {} + 2>/dev/null

# Remoção do bit SUID de binários frequentemente desnecessários em servidores dedicados
chmod u-s /usr/bin/chfn /usr/bin/chsh /usr/bin/wall /usr/bin/mount /usr/bin/umount

10.2 Endurecimento de Pontos de Montagem em /etc/fstab

Diretórios que recebem arquivos temporários ou dados graváveis por múltiplos usuários (como /tmp, /var/tmp e /dev/shm) devem ser montados em partições segregadas com sinalizadores estritos de restrição:

# Em /etc/fstab
# /tmp montado sem permissão de execução e sem herança de bits SUID
tmpfs   /tmp        tmpfs   defaults,nosuid,nodev,noexec,mode=1777   0 0

# /dev/shm (memória compartilhada) restrito
tmpfs   /dev/shm    tmpfs   defaults,nosuid,nodev,noexec             0 0

# /var montado com nodev
/dev/mapper/vg-var  /var  ext4  defaults,nodev                       0 2

11. Automação de conformidade e gestão contínua de vulnerabilidades

Manter a configuração segura de dezenas ou centenas de nós operacionais requer disciplina automatizada. Políticas estáticas aplicadas manualmente degradam ao longo do tempo conforme novas aplicações são instaladas ou correções pontuais são implementadas em momentos de crise.

11.1 Automação de Patches Críticos de Segurança

A aplicação de atualizações do kernel e pacotes com vulnerabilidades conhecidas deve ser contínua. Em ambientes Debian e Ubuntu, o pacote unattended-upgrades deve ser programado exclusivamente para aplicar pacotes do canal de segurança. Em ambientes RHEL, o utilitário dnf-automatic executa função correlata com mínima perturbação.

11.2 Ferramentas de Auditoria Contínua: Lynis

O Lynis é uma ferramenta leve, modular e de código aberto para auditorias de segurança em sistemas baseados em Linux e Unix. Ele verifica centenas de itens operacionais, avaliando desde configurações de inicialização até parâmetros de rede e integridade de arquivos, gerando um índice de conformidade denominado Hardening Index:

# Executando auditoria rápida com Lynis
lynis audit system --quick --warnings-only

A Tabela 3 resume os principais pontos de verificação periódica que devem ser checados em rotinas de homologação de novos nós ou auditorias mensais de conformidade.

12. Conclusão

O endurecimento de sistemas operacionais Linux não se resume a restringir funcionalidades indiscriminadamente, mas a alcançar um equilíbrio deliberado entre estrita segurança e disponibilidade dos serviços corporativos.

A adoção de guias consolidados pela indústria, como CIS Benchmarks e DISA STIGs, aliada à automação via ferramentas como OpenSCAP, Ansible e nftables, confere previsibilidade técnica à infraestrutura. Ao eliminar configurações padrão frágeis e estabelecer camadas defensivas em profundidade, a organização assegura que uma eventual falha em um componente periférico não comprometa o núcleo de suas operações nem exponha seus dados mais críticos a ameaças cibernéticas.

Glossário

ASLR (Address Space Layout Randomization)

Técnica de segurança do kernel que distribui aleatoriamente as posições dos componentes de memória de um processo, impedindo que invasores prevejam endereços-alvo para exploração de vulnerabilidades de buffer overflow.

CIS (Center for Internet Security)

Organização sem fins lucrativos reconhecida globalmente por desenvolver benchmarks rigorosos e orientações prescritivas para configuração segura de tecnologias de informação e comunicação.

DAC (Discretionary Access Control)

Modelo clássico de controle de acesso no qual o dono do objeto (usuário) decide as permissões concedidas a outros usuários ou grupos através dos bits de leitura, escrita e execução.

DISA (Defense Information Systems Agency)

Agência do Departamento de Defesa dos Estados Unidos encarregada de fornecer e manter os sistemas e padrões de segurança técnica da informação das forças armadas.

FIFO (First-In, First-Out)

Canal nomeado de comunicação entre processos no sistema de arquivos Linux que funciona de forma unidirecional baseada em filas de dados temporárias.

FIDO2 (Fast Identity Online 2)

Conjunto de padrões abertos de autenticação que viabilizam o login seguro sem senhas ou com múltiplos fatores através de dispositivos físicos de criptografia de chave pública.

LUKS (Linux Unified Key Setup)

Padrão oficial do ecossistema Linux para gerenciamento de discos e partições criptografadas de bloco em conjunto com a infraestrutura dm-crypt.

MAC (Mandatory Access Control)

Mecanismo no qual as permissões de acesso são decididas centralmente por uma autoridade do sistema operacional através de políticas aplicadas pelo kernel, independentemente da vontade do usuário criador do arquivo.

PAM (Pluggable Authentication Modules)

Camada modular que oferece serviços de autenticação, verificação de contas, alteração de senhas e abertura de sessões para aplicações no sistema Linux.

PCR (Platform Configuration Register)

Registradores de hardware invioláveis localizados no chip TPM utilizados para armazenar medições criptográficas acumuladas da integridade do firmware, bootloader e kernel.

SCAP (Security Content Automation Protocol)

Conjunto integrado de especificações padronizadas pelo NIST para expressar, verificar e avaliar automaticamente a conformidade com regras de segurança em sistemas computacionais.

SGID (Set Group ID)

Bit de permissão especial que força a execução de um arquivo com os privilégios do seu grupo proprietário ou faz novos arquivos em um diretório herdarem o grupo do diretório-pai.

STIG (Security Technical Implementation Guide)

Guias de configuração mandatórios desenvolvidos pela DISA para assegurar que sistemas, servidores e aplicações operem dentro dos requisitos mais rígidos de segurança governamental.

SUID (Set Owner User ID)

Permissão especial atribuída a arquivos executáveis que permite ao processo rodar temporariamente com os privilégios do proprietário do arquivo, habitualmente o usuário root.

TOTP (Time-based One-Time Password)

Algoritmo de geração de códigos numéricos de uso único baseados na sincronização do relógio atual entre o servidor de autenticação e o aplicativo do usuário.

TPM (Trusted Platform Module)

Microcontrolador criptográfico dedicado integrado à placa-mãe projetado para fornecer armazenamento inviolável de chaves, medições de integridade e funções de atestação de hardware.

Apêndice A, checklist operacional de auditoria e validação técnica

O checklist a seguir foi desenhado para equipes de engenharia de infraestrutura e analistas de segurança realizarem a validação final de conformidade em servidores Linux antes de sua liberação para o ambiente de produção.

Cartilha CiberLab · Ciência Embarcada · Lucas Rayan Guerra