Tratamento seguro de segredos e higiene do ambiente
Mantenha credenciais fora das listagens de processos e dos registros usando a entrada padrão, arquivos e ambientes limpos.
Tratamento seguro de segredos e higiene do ambiente é uma aula grátis de DevOps Bootcamp no CoddyKit. Esta é a aula 2 de 4. Você pode ler a aula completa abaixo gratuitamente — depois pratica ao vivo no navegador com um editor de código integrado e um tutor de IA 24/7. Faz parte do caminho de aprendizado de DevOps Bootcamp, e seu progresso é sincronizado entre a web e o app CoddyKit. O curso de DevOps Bootcamp inclui 4 aulas no total.
Por que a higiene de segredos é importante
Segredos — chaves de API, senhas e tokens — são os dados mais sensíveis de qualquer sistema. O manuseio inadequado deles em scripts Bash é um dos erros de segurança mais comuns e prejudiciais.
- Listagens de processos: argumentos passados a comandos aparecem em
ps aux,/proc/<pid>/cmdlinee registros de auditoria do sistema — visíveis a todos os usuários do host. - Histórico do shell: comandos digitados interativamente (e, às vezes, scripts) são registrados em
~/.bash_history. - Arquivos de registro: rastreamentos de
set -x, registros de aplicações e saídas de CI/CD podem capturar valores de variáveis. - Vazamento pelo ambiente: processos filhos herdam todo o ambiente do processo pai, incluindo quaisquer segredos exportados.
Um script protegido trata os segredos como material radioativo — minimize o tempo de exposição, limite a superfície de exposição e higienize tudo antes de liberar os dados.
A superfície de ataque das listagens de processos
Quando você passa um segredo como argumento de linha de comando, todos os usuários do sistema podem lê-lo imediatamente por meio de ps. Isso não é algo meramente teórico — é explorado rotineiramente em ambientes de hospedagem compartilhada e contêineres.
O trecho abaixo demonstra o problema e a correção lado a lado.
#!/usr/bin/env bash
# DANGEROUS: password visible in 'ps aux' output
# curl -u "admin:SuperSecret123" https://api.example.com/data
# SAFE: pass credentials via stdin or a flag that reads from a file
# Many tools support reading secrets from stdin with '-' or dedicated flags:
# Option 1 — pipe the secret so it never appears in argv
echo 'SuperSecret123' | curl -u 'admin' --password-stdin \
https://api.example.com/data 2>/dev/null || true
# Option 2 — write a temporary netrc and point curl at it
# (covered in a later scene)
echo 'Secret never touches the command line this way'Lendo segredos da entrada padrão
O padrão interativo mais seguro é ler um segredo durante a execução usando read -rs. O sinalizador -s impede a exibição dos caracteres, e -r evita a interpretação de barras invertidas.
Pontos principais:
- A variável nunca é exportada, portanto os processos filhos não podem vê-la por meio de
/proc/<pid>/environ. - Após o uso, desfaça a variável imediatamente para reduzir a janela de exposição.
- Evite
echo "$SECRET"— useprintf '%s'para impedir que uma quebra de linha final corrompa o valor e para mantê-lo invisível nos rastreamentos.
#!/usr/bin/env bash
set -euo pipefail
# Prompt on stderr so stdout stays clean for piping
read -rsp 'Enter API token: ' API_TOKEN <&2
printf '\n' >&2
# Use the secret — printf keeps it out of argv
response=$(printf '%s' "$API_TOKEN" | curl -sS -X POST \
-H 'Content-Type: application/json' \
--data-binary @- \
https://httpbin.org/post 2>/dev/null) || true
echo "Request sent."
# Scrub immediately — unset removes it from shell memory
unset API_TOKENSegredos em Arquivos: Permissões e Propriedade
Quando um segredo precisa persistir no disco (por exemplo, uma chave de conta de serviço), as permissões do arquivo são sua principal defesa.
- Modo 0600 — legível e gravável somente pelo proprietário. Sem acesso para o grupo ou para outros usuários.
- Modo 0400 — somente leitura para o proprietário. Prefira este modo para chaves que nunca devem ser sobrescritas acidentalmente.
- Armazene os arquivos de segredos em um diretório dedicado, como
~/.secrets/ou/run/secrets/(este último é um tmpfs apoiado por RAM em muitos sistemas Linux e persiste somente até a reinicialização). - Nunca coloque arquivos de segredos dentro de um diretório rastreado pelo git sem um
.gitignorerealmente seguro.
#!/usr/bin/env bash
set -euo pipefail
SECRETS_DIR="${HOME}/.secrets"
mkdir -p "$SECRETS_DIR"
chmod 700 "$SECRETS_DIR" # directory: only owner can list contents
KEY_FILE="${SECRETS_DIR}/api_token"
# Write secret — atomically restrict permissions before writing content
install -m 0600 /dev/null "$KEY_FILE"
printf '%s' 'my-super-secret-token' > "$KEY_FILE"
echo "Permissions:"
ls -la "$KEY_FILE"
# Read back safely — no subshell, no echo
API_TOKEN=$(< "$KEY_FILE")
echo "Token length: ${#API_TOKEN} chars (value not printed)"
unset API_TOKENUsando um Arquivo .netrc com curl
curl é compatível com um arquivo ~/.netrc (ou com um caminho arbitrário por meio de --netrc-file) que associa nomes de host a credenciais. Isso mantém os dados de autenticação completamente fora da linha de comando e do corpo do script.
O formato do arquivo é simples:
machine api.example.com
login admin
password s3cr3tBoas práticas:
- Sempre defina
chmod 0600 ~/.netrc— em alguns sistemas, o curl recusa o arquivo se ele puder ser lido por outros usuários. - Use
--netrc-file /run/secrets/netrcpara apontar para um segredo apoiado por tmpfs ou injetado no contêiner. - Limpe os arquivos netrc temporários com um
trapem EXIT.
#!/usr/bin/env bash
set -euo pipefail
TMP_NETRC=$(mktemp)
chmod 0600 "$TMP_NETRC"
# Trap ensures cleanup even on error or signal
trap 'rm -f "$TMP_NETRC"' EXIT
# Write credentials to the temp netrc
cat > "$TMP_NETRC" <<'EOF'
machine httpbin.org
login myuser
password mypassword
EOF
curl -fsS --netrc-file "$TMP_NETRC" \
https://httpbin.org/basic-auth/myuser/mypassword \
-o /dev/null -w 'HTTP %{http_code}\n' || true
# trap fires here: $TMP_NETRC is deleted
echo 'Temp netrc cleaned up by trap.'Higiene das Variáveis de Ambiente
As variáveis de ambiente são uma forma popular de injetar segredos em scripts (aplicações de 12 fatores, pipelines de CI/CD). No entanto, elas vazam para todos os processos filhos e aparecem em /proc/<pid>/environ durante toda a duração do processo.
Padrões de defesa:
- Importe imediatamente o segredo para uma variável local e remova a variável de ambiente para que os processos filhos não possam herdá-la.
- Passe segredos para comandos específicos usando
env -iou uma atribuição inline, em vez de usar todo o ambiente herdado. - Nunca
exportuma variável de segredo — quando possível, use somente uma atribuição (semexport).
#!/usr/bin/env bash
set -euo pipefail
# Simulate a secret arriving via environment (e.g., from CI system)
export DB_PASSWORD='hunter2' # set by CI — we did not choose this
# Capture locally, then strip from environment immediately
db_password="$DB_PASSWORD"
unset DB_PASSWORD
# Verify the env var is gone before spawning any child process
if printenv DB_PASSWORD 2>/dev/null; then
echo 'ERROR: DB_PASSWORD still in environment!' >&2
exit 1
fi
echo 'Secret captured and env var scrubbed.'
echo "Password length: ${#db_password}"
unset db_passwordImpedindo que Segredos Apareçam nos Rastreamentos de set -x
set -x (xtrace) é inestimável para depuração, mas imprime o valor de toda variável que expande — inclusive os segredos — na saída de erro padrão. Esses rastreamentos frequentemente acabam nos registros de CI ou no syslog.
Estratégias para proteger os segredos e manter o rastreamento útil:
- Desative temporariamente o rastreamento ao redor de operações sensíveis com
{ set +x; } 2>/dev/null. - Reative-o depois com
set -x. - Redirecione a saída do xtrace para um descritor de arquivo separado, direcionado a um arquivo de registro protegido, e não ao fluxo de registro público.
#!/usr/bin/env bash
set -euo pipefail
set -x # tracing ON — safe for non-sensitive sections
echo 'Building application...'
SRC_DIR='/tmp/build'
mkdir -p "$SRC_DIR"
# Disable xtrace around secret handling (suppress the set +x line itself)
{ set +x; } 2>/dev/null
read -rsp 'Token (hidden from trace): ' SECRET_TOKEN <&2
printf '\n' >&2
token_len=${#SECRET_TOKEN}
unset SECRET_TOKEN
set -x # tracing back ON
echo "Token captured (length=$token_len). Continuing build..."
ls "$SRC_DIR"Removendo Segredos dos Arquivos de Registro
Mesmo quando você é cuidadoso, às vezes os segredos acabam na saída de registro — especialmente em scripts detalhados ou antigos. Uma função de registro que oculta padrões conhecidos acrescenta uma camada de segurança.
Este padrão usa uma substituição baseada em expressão regular em toda a saída de registro. É uma camada de último recurso, não um substituto para as outras práticas de higiene já apresentadas.
#!/usr/bin/env bash
set -euo pipefail
# A logging function that scrubs common secret patterns before writing
log() {
local line
# Replace anything that looks like key=VALUE or password=VALUE
line=$(printf '%s\n' "$*" \
| sed -E 's/(password|token|secret|key)=[^[:space:]]*/\1=***REDACTED***/gi')
printf '[%s] %s\n' "$(date -u '+%T')" "$line"
}
# Usage:
log 'Connecting to database with password=hunter2'
log 'Loaded API token=sk-abc123xyz secret'
log 'Build step completed successfully' # unchangedAmbientes Isolados com env -i
env -i inicia um comando com um ambiente completamente vazio, impedindo que quaisquer variáveis herdadas — inclusive segredos acidentais — cheguem ao processo filho. Em seguida, você passa explicitamente somente o que é necessário.
Isso é especialmente útil ao executar scripts não confiáveis, ferramentas de compilação ou utilitários de terceiros que possam exfiltrar dados do ambiente.
#!/usr/bin/env bash
set -euo pipefail
# Polluted parent environment (simulating a CI runner)
export AWS_SECRET_ACCESS_KEY='AKIAIOSFODNN7EXAMPLE'
export GITHUB_TOKEN='ghp_faketoken123'
export HOME="$HOME"
export PATH="$PATH"
echo '--- Child sees full environment:'
env | grep -E 'AWS|GITHUB' | head -5
echo '--- Sanitised child (env -i) sees nothing secret:'
env -i HOME="$HOME" PATH="$PATH" TERM="${TERM:-dumb}" \
bash -c 'env | grep -E "AWS|GITHUB" || echo "No secrets visible"'
unset AWS_SECRET_ACCESS_KEY GITHUB_TOKENArquivos Temporários de Segredos em tmpfs
tmpfs é um sistema de arquivos apoiado por RAM. Os arquivos gravados nele nunca são descarregados para o disco, eliminando o risco de os segredos persistirem na área de troca, no cache do disco ou em instantâneos.
- No Linux,
/dev/shme/run/user/<uid>normalmente são montagens tmpfs. - Sempre combine o uso de tmpfs com um
trap EXITpara excluir os arquivos quando o script terminar. - Em contêineres (Docker, Kubernetes), os segredos podem ser montados diretamente como volumes tmpfs em
/run/secrets.
#!/usr/bin/env bash
set -euo pipefail
# Prefer /run/user/$UID (user-owned tmpfs) or /dev/shm (world-readable dir!)
if [[ -d "/run/user/$UID" ]]; then
TMPFS_DIR="/run/user/$UID"
elif [[ -d '/dev/shm' ]]; then
TMPFS_DIR='/dev/shm'
else
# Fallback: warn that disk will be used
echo 'WARNING: No tmpfs available; using /tmp (disk-backed)' >&2
TMPFS_DIR='/tmp'
fi
SECRET_FILE=$(mktemp "${TMPFS_DIR}/secret.XXXXXX")
chmod 0600 "$SECRET_FILE"
trap 'shred -u "$SECRET_FILE" 2>/dev/null || rm -f "$SECRET_FILE"' EXIT
printf '%s' 'my-runtime-token' > "$SECRET_FILE"
echo "Secret stored in: $SECRET_FILE"
df -T "$SECRET_FILE" | awk 'NR==2 {print "Filesystem type:", $2}'
# Use the secret...
token=$(< "$SECRET_FILE")
echo "Token length: ${#token}"
unset token
# trap fires on exit: file shreddedReunindo Tudo: um Script de Implantação Reforçado
O script a seguir combina todas as técnicas desta lição em um auxiliar de implantação realista. Observe como cada camada de defesa reforça as demais:
- leitura de stdin com
-s— sem eco no terminal - arquivo de segredo em tmpfs com limpeza por
trap - limpeza do ambiente — segredo removido antes de qualquer subprocesso
- proteção contra xtrace — rastreamento pausado ao redor do código sensível
- ocultação no registro — expressão regular de segurança antes da gravação no registro
#!/usr/bin/env bash
set -euo pipefail
### 1. Redacting logger
log() {
local msg
msg=$(printf '%s' "$*" \
| sed -E 's/(password|token|secret|key)=[^[:space:]]*/\1=***/gi')
printf '[%s] %s\n' "$(date -u +%T)" "$msg"
}
### 2. tmpfs secret store
TMPFS_DIR="${XDG_RUNTIME_DIR:-/tmp}"
SECRET_FILE=$(mktemp "${TMPFS_DIR}/deploy_token.XXXXXX")
chmod 0600 "$SECRET_FILE"
trap 'rm -f "$SECRET_FILE"; log "Secret file cleaned up."' EXIT
### 3. Read secret without trace
{ set +x; } 2>/dev/null
read -rsp 'Deploy token: ' _tok <&2; printf '\n' >&2
printf '%s' "$_tok" > "$SECRET_FILE"
unset _tok
set -x
### 4. Scrub inherited env vars before subprocess
unset DEPLOY_TOKEN 2>/dev/null || true
log 'Starting deployment...'
# Simulate deploy using secret from file (token never in argv)
# curl -H "Authorization: Bearer $(< $SECRET_FILE)" https://api.example.com/deploy
log 'Deployment complete. token=hidden_by_redactor'
echo 'Done.'Verificação de Conhecimento: Exposição de Segredos por Listagem de Processos
Teste sua compreensão de como os segredos vazam por meio das listagens de processos e de como impedir isso.
Recapitulação da Lição: Tratamento Seguro de Segredos
Você concluiu Tratamento Seguro de Segredos e Higiene do Ambiente. Veja uma referência concisa de tudo o que foi abordado:
- Listagens de processos: nunca passe segredos como argumentos da linha de comando — eles aparecem em
ps auxe/proc/<pid>/cmdline. Use um canal de stdin ou--netrc-file. - Leituras de stdin: use
read -rspara coletar segredos interativamente sem eco no terminal nem exposição ao histórico do shell. - Permissões de arquivos: os arquivos de segredos devem usar
chmod 0600(ou0400). Useinstall -m 0600para uma criação atômica. - Arquivos netrc: delegue as credenciais a um arquivo temporário indicado por
--netrc-file; limpe-o comtrap EXIT. - Higiene do ambiente: use imediatamente
unsetnas variáveis de ambiente secretas depois de capturá-las localmente; nunca useexportnelas sem necessidade; useenv -ipara isolar os processos filhos. - Proteção contra xtrace: envolva o código sensível em
{ set +x; } 2>/dev/null ... set -xpara impedir que os rastreamentos de depuração vazem valores. - Ocultação no registro: use um registrador baseado em
sedcomo rede de segurança de último recurso. - tmpfs: armazene os segredos de execução em
/run/user/$UIDou/dev/shmpara que nunca toquem no disco; destrua-os ao sair.
A defesa em profundidade é a mentalidade fundamental: nenhuma medida isolada é suficiente, mas combiná-las em camadas torna o vazamento de segredos extremamente difícil.
Perguntas Frequentes
A aula “Tratamento seguro de segredos e higiene do ambiente” é grátis?
Sim — o texto completo de “Tratamento seguro de segredos e higiene do ambiente” é grátis para ler aqui na web. Para praticá-la interativamente (um editor de código integrado e um tutor de IA 24/7) e desbloquear o restante do curso de DevOps Bootcamp, atualize para CoddyKit PRO. O curso de DevOps Bootcamp inclui 4 aulas no total.
O que vou aprender em “Tratamento seguro de segredos e higiene do ambiente”?
Mantenha credenciais fora das listagens de processos e dos registros usando a entrada padrão, arquivos e ambientes limpos. Você pratica DevOps Bootcamp com código prático que executa diretamente no navegador, e um tutor de IA 24/7 responde suas dúvidas enquanto trabalha na aula.
Preciso ter experiência prévia para começar DevOps Bootcamp?
Nenhuma experiência prévia é necessária. DevOps Bootcamp no CoddyKit é estruturado para alunos iniciantes até avançados, então você pode começar aqui ou desde o início e aprender no seu ritmo. Esta é a aula 2 de 4.
Quanto tempo leva a aula “Tratamento seguro de segredos e higiene do ambiente”?
A maioria das aulas CoddyKit leva cerca de 5–10 minutos. Cada uma é compacta e interativa, então você faz progresso constante e retoma exatamente de onde parou entre web e app.
Posso escrever e executar código nesta aula de DevOps Bootcamp?
Sim. Cada aula de DevOps Bootcamp inclui um editor de código integrado, então você escreve e executa código real direto no navegador e recebe feedback de IA instantaneamente — nenhuma configuração local necessária.
Todas as aulas deste curso
- Prevenção de injeção de comandos e argumentos
- Tratamento seguro de segredos e higiene do ambiente
- Execução com privilégios mínimos e disciplina no sudo
- Análise estática e auditoria com ShellCheck