Správa secrets ve vývojovém cyklu software
Správa secrets je proces ukládání a distribuce hesel, API klíčů, certifikátů nebo cokoli jiného, co je citlivé a nemělo by být veřejně dostupné. Článek je úvodem do této problematiky a představuje důvody i možnosti toho, jak práci se secrets zavést.

Tento text popisuje různé možnosti správy tajemství (dále jen secrets). Nejedná se o úplný návod. Je to spíše soubor našich zkušeností a výzkumů. Očekává se vaše vlastní práce.
V první části si popíšeme, co je to správa secrets, motivatci pro zavedení a klíčové vlastnosti nástrojů, které nám mohou pomoci vytvořit bezpečné prostředí.
Druhá část se zabývá správou secrets v produkčním prostředí na vzdálených strojích, jako jsou servery. Dále tato část popisuje službu správy secrets (SMS) a představuje některé standardní nástroje.
Třetí část pojednává o nasazení pomocí Ansible a také o nástrojích, které mohou pomoci s redistribucí secrets mezi vývojáři. Některé ze zmíněných nástrojů dokáží šifrovat secrets, která lze následně nahrát do služeb, jako je Github a Gitlab, aniž by došlo k narušení bezpečnosti.
A konečně čtvrtá část pojednává o tom, proč byste neměli ukládat secrets v kompilovaných jazycích.
Tématu odhalování secrets se věnuje náš další návod Jak začít se správou secrets.
TLDR
- Začněte někde, i když to není dokonalé.
- Secrets v kódu jsou vždy špatné.
- Secrets v prostém textu by nikdy neměla být uložena v systému git.
- Mezi optimální produkční metody patří Hashicorp Vault, Azure Key Vault atd.
- Méně optimální, ale stále dobrá řešení jsou Ansible Vault, Pass, Gopass atd.
- Ať už používáte nástroj X nebo Y, cokoli je lepší než hesla v prostém textu v úložišti git.
- Něco musí ukládat secrets na disk nebo do paměti. V případě, že máte dostatečný přístup, je možné je extrahovat.
Co je správa secrets?
Správa secrets je postup, který vývojářům a správcům umožňuje bezpečně ukládat citlivé údaje, jako jsou hesla, klíče a tokeny, v zabezpečeném prostředí s přísnou kontrolou přístupu. Mezi nástroje pro správu secrets patří:
- Správci hesel (např. BitWarden, Passbolt, Pass).
- Služby pro správu secrets (např. Hashicorp Vault, Azure Key Vault, AWS Secrets Manager).
- Nástroje pro správu konfigurací (např. Ansible Vault, Puppet-labs hiera-eyaml).
Motivace
Snažíme se co nejvíce ztížit ohrožení celého systému. Mnohdy může útočník dosáhnout pouze částečného zneužití systému, například čtením souborů na webovém serveru (Local File Inclusion) nebo zjištěním hesla k databázi na Githubu dané organizace. To mu umožňuje pohybovat se mezi službami; útočník nyní může získat přístup k databázi a odtud dále rozšiřovat úroveň kompromitace systému. Je důležité si uvědomit, že správa secrets chrání službu pouze před určitou úrovní přístupu do systému. Jakmile útočník získá přístup k účtu s dostatečnými právy, nelze mu v získání secrets zabránit. Z podstaty problému není možné zajistit, aby legitimní služba měla přístup k secrets a zároveň jej neměl útočník se stejnými právy jako služba.
Pochopení správy secrets
Správa secrets je proces ukládání a distribuce hesel, API klíčů, certifikátů nebo cokoli jiného, co je citlivé a nemělo by být veřejně dostupné.
Pro správu secrets neexistuje optimální řešení. Každé řešení má své výhody a nevýhody. Vždy bude uloženo na pevném disku nebo v paměti, takže je vždy možné jej extrahovat. Cílem je, aby to bylo co nejtěžší. Ideální by měl být nástroj pro správu secrets, který:
- je snadno použitelný
- umožňuje snadnou distribuci secrets
- umožňuje snadnou rotaci secrets a správy přístupu k nim.
Uvědomte si, že secrets se mohou nacházet také na následujících místech:
- historie systému Git
- záznamy
- bash historie
Produkční nástroje (použití na vzdálených strojích)
Existuje více způsobů, jak v produkčním prostředí spravovat secrets. Tato část se zabývá těmi nejběžnějšími. O secrets by se měla starat automatizace, aby se omezil lidský faktor.
OWASP Secret management cheatsheet popisuje tři funkce, díky nimž jsou secrets bezpečnější:
- Secrets pipeline: Existuje postup pro správu secrets, který zajišťuje automaticky většinu souvisejících akcí (např. vytváření, rotace).
- Použití dynamických secrets: Aplikace by si při spuštění mohla vyžádat přístupové údaje do databáze, které budou dynamicky generované a poskytnuté pouze pro danou relaci. Dynamicky generované přístupové údaje zmenšují riziko jejich zneužití při znovupoužití. Jsou-li přístupové údaje odcizeny, jejich platnost vyprší.
- Automatická rotace statických secrets: Rotace klíčů je při ruční implementaci náročná a může vést k chybám. Je lepší rotaci klíčů automatizovat nebo alespoň zajistit dostatečnou podporu tohoto procesu.
Dosažení tohoto cíle vyžaduje práci. S tím vám však mohou pomoci služby správy secrets.
Služby správy secrets (SMS)
Služby, které lze použít pro správu secrets:
- Hashicorp Vault
- Azure Key Vault
- Cloud KMS
- AWS Secrets Manager
- Infisical
- Sops …
Tato řešení jsou optimální (nikoli dokonalá). Nemá však cenu vytvářet celý systém správy secrets bez infrastruktury, podpory a zdrojů pro tyto nástroje.
Vývojáři bez potřebné infrastruktury mohou využít:
- proměnné prostředí,
- soubory,
- šifrované soubory,
- nebo kombinaci předchozích.
Proč je považujeme za optimální řešení?
- Můžete kontrolovat přístup a také spravovat a obměňovat secrets podle potřeby.
- K ochraně secrets můžete použít vícefaktorové ověřování a další bezpečnostní opatření (například soukromý klíč + tajný token, whitelist IP atd.).
- Pro přístup k secrets aplikace používá tokeny.
Výhody:
- Můžete rotovat secrets, aniž byste měnili token a naopak.
- Přístup k secrets můžete zrušit.
- Přístup k secrets můžete auditovat.
- Kompromitovaný token neznamená hned kompromitaci služby.
- Snadnější distribuce a správa secrets.
Nevýhody:
- Tokeny musíte stále někde ukládat.
- Stále musíte být opatrní s odesíláním tokenů do gitu.
- Obvykle musíte za službu platit, nebo si infrastrukturu musíte vybudovat sami.
- Potřebujete server pro správu secrets a klienta.
Demo
Jako příklad použijeme Hashicorp Vault pro ukládání pověření PostgreSQL. Ukázka pochází z oficiální dokumentace.
# enable database secrets
vault secrets enable database
# configure database connection
vault write database/config/postgresql \
plugin_name=postgresql-database-plugin \
connection_url="postgresql://{{username}}:{{password}}@$POSTGRES_URL/postgres?sslmode=disable" \
allowed_roles=readonly \
username="root" \
password="rootpassword"
#configure role
tee readonly.sql <<EOF
CREATE ROLE "{{name}}" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}' INHERIT;
GRANT ro TO "{{name}}";
EOF
# create role
vault write database/roles/readonly \
db_name=postgresql \
creation_statements=@readonly.sql \
default_ttl=1h \
max_ttl=24h
Nyní se tajemství generují za běhu a jsou platná 1 hodinu. Stále je lze získat zpět, ale Hashicorp Vault ztěžuje jejich extrakci. Také je nelze použít okamžitě při načtení tokenu pomocí funkce Local File Inclusion. Seznam podporovaných databází naleznete zde.
Proměnné prostředí a soubory
Jedná se o nejjednodušší způsob ukládání secrets. Používání pouze proměnných prostředí není trvalé. Proto k ukládání secrets používáme soubory jako.env nebo config.yml. Tyto soubory by měl git ignorovat a měly by být distribuovány jiným způsobem, například pomocí Ansible, nebo ručně.
Bash
VAR1=secret1 VAR2=secret2 ./my_app
# Print variable
echo $VAR1
PowerShell
$Env:password="secret12321" ./my_app
# Print variable
get-item -path Env:password | select -exp Value
Načtení ze souboru .env nebo config.yml je specifické pro různé jazyky.
Je třeba mít na paměti, že použití souborů a proměnných prostředí je jen o málo lepší, než hesla uloženeá v prostém textu v git repozitáři.
Správa secrets ve Windows
Přestože můžete zmíněné nástroje používat prostřednictvím WSL, existují nástroje, které jsou pro systém Windows nativní.
PowerShell
SecretStore a SecretManagement moduly umožňují práci se secrets v prostředí PowerShell. Ve výchozím nastavení jsou secrets uložena lokálně prostřednictvím rozhraní Windows Data Protection API. Modul SecretManagement pomáhá s místními a vzdálenými trezory, které lze registrovat a odregistrovat pro použití při přístupu k secrets a jejich načítání.
Podporovány jsou následující správci:
Výhodou oproti proměnným prostředí je, že k získání secrets musí útočník získat uživatelský účet a soubory s secrets. Samotné čtení souborů nestačí.
Příklad použití
Register-SecretVault -Name SECRET_VAULT -ModuleName Microsoft.PowerShell.SecretStore -DefaultVault
Set-SecretStoreConfiguration -Scope CurrentUser -Authentication Password -PasswordTimeout 60 -Interaction None -Password $pass -Confirm:$false
Set-Secret -Name test_secret
$pass = Import-CliXml -Path "./encrypted_pass.xml"
Unlock-SecretStore -Password $pass
$secret=(Get-Secret -Name test_secret -asplaintext)
Poznámka: Pokud je tento modul používán v systémech podobných systému UNIX, jsou secrets uložena v prostém textu. Tyto moduly by se měly používat pouze v systému Windows.
Zdroje
- Tutoriál: běžné použití - https://devblogs.microsoft.com/powershell/secretmanagement-and-secretstore-are-generally-available/
- Tutoriál: použití v automatizacích - https://learn.microsoft.com/en-us/powershell/utility-modules/secretmanagement/how-to/using-secrets-in-automation?view=ps-modules
- Dokumentace SecretStore - https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.secretstore
- Dokumentace SecretManagement - https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.secretmanagement
- Github of the module - https://github.com/PowerShell/SecretManagement
Dotnet
Stejně jako PowerShell má i dotnet svůj vlastní velmi podobný modul pro správu secrets. Ta jsou uložena v prostém textu v souboru %APPDATA%\Microsoft\UserSecrets\<user_secrets_id>\secrets.json, ale to stačí k tomu, aby váš kód neobsahoval citlivé informace. Více o tomto tématu najdete v článku Bezpečné ukládání secrets při vývoji aplikací v ASP.NET Core.
Příklad
dotnet user-secrets init
dotnet user-secrets set "Movies:ServiceApiKey" "12345"
...
var builder = WebApplication.CreateBuilder(args);
var movieApiKey = builder.Configuration["Movies:ServiceApiKey"];
IIS Web konfigurace
K šifrování nebo dešifrování částí konfiguračního souboru webu můžete použít nástroj ASP.NET IIS Registration Tool (Aspnet_regiis.exe). ASP.NET automaticky dešifruje zašifrované konfigurační prvky při zpracování souboru Web.config. (Zdroj)
Poznámka: Webové konfigurační soubory je nutné po nasazení na konkrétním hostiteli dešifrovat, protože sdílení zašifrované konfigurace mezi více hostiteli nebude fungovat.
aspnet_regiis -pe "ApiKey" -app "/App" -prov "RsaProtectedConfigurationProvider"
Nástroje pro nasazení a vývoj (používané lokálně)
Služby správy secrets lze využít i ve fázích nasazení a vývoje.
Ansible vault
Ansible vault je nástroj příkazového řádku, který šifruje a dešifruje soubory. Jeho použití pro správu secrets v playboocích a rolích Ansible je velmi snadné.
- It is integrated with Ansible to encrypt variables in playbooks on the fly.
- You can encrypt any file, but it is most useful for encrypting variables.
- Ansible vault is included in the Ansible core.
- Vault is managed by only one password.
- There can be multiple vaults in one project.
- Deployment and source control with the ansible-vault is elegant, if you have a way, how to distribute the master passwords (passwords used to encrypt other passwords; Ansible vault masterpassword encrypts the entire vault) to all developers.
- Je integrován s aplikací Ansible a umožňuje šifrovat proměnné v playboocích za běhu.
- Umožňuje šifrovat libovolný soubor, ale nejužitečnější je pro šifrování proměnných.
- Je součástí jádra Ansible.
- Trezor (vault) je spravován pouze jedním heslem.
- V jednom projektu může být více trezorů.
- Nasazení a správa zdrojů pomocí ansible-vault je elegantní, pokud máte způsob, jak distribuovat hlavní hesla (hesla používaná k šifrování ostatních hesel; hlavní heslo Ansible vault šifruje celý trezor) všem vývojářům.
Příklad použití
Šifrování souboru
Vytvořete soubor vars.yml s následujícím obsahem:
---
password: heslo-je-maslo
Ansible vault
# Encrypt a file, you will be prompted for a password
ansible-vault encrypt vars.yml
# Show the encrypted file
ansible-vault view vars.yml
# Edit the encrypted file
ansible-vault edit vars.yml
Tím se vytvoří soubor s následujícím obsahem:
$ANSIBLE_VAULT;1.1;AES256
373263656562383930346536323230... # encrypted content
Šifrování hodnoty proměnné #
echo 'secr3t-Passw0rd12334' | ansible-vault encrypt_string --stdin-name 'password_value'
Tím získáte následující řetězec
password_value: !vault |
$ANSIBLE_VAULT;1.1;AES256
62346562393839613965323835666634306566616537393239626432353838326562326164303233
3831383861303463373432313662653139633237306162630a383163346236633065346138626263
34343363396236386335303534636530623632333432633334633538666233326365333732333731
3737383033373738380a623835336661343962386432363130633266666433616462666636636131
32353162636463373861336435373363623862613135336239663961373663666266
Zkopírujte jej do souboru vars.yml.
Použití v playbooku nebo roli
# Run ansible command
ansible localhost -m ansible.builtin.debug -a var="password_value" -e "@vars.yml" --ask-vault-pass
# Output
localhost | SUCCESS => {
"password": "heslo-je-maslo"
}
# Or run the playbook with pass in the file
ansible-playbook playbook.yml --vault-password-file ~/.ansible-prod-password.txt
Amber
Amber je alternativou k Ansible Vault. Je vhodnější pro použití na vzdálených počítačích. Taktéž používá jedno hlavní heslo a nevyžaduje žádné externí závislosti. Lze jej připodobnit k Pass nebo SecretManager pro PowerShell. Není však vyžadován žádný klíč GPG ani uživatelský účet.
Passbolt
Passbolt je open-source správce hesel pro týmy. Jedná se o webovou aplikaci, která umožňuje bezpečně sdílet a ukládat přihlašovací údaje. Passbolt má rozhraní REST API a klienta CLI. Pro použití v procesu automatizace však doporučujeme něco jiného než tento nástroj. Nelze vytvářet přístupové tokeny na úrovni skupin nebo objektů, pouze oprávnění na úrovni uživatelů, která nejsou vhodná pro jiné než ruční použití.
Pass
Pass je standardní správce hesel systému UNIX. Jedná se o nástroj CLI založený na ověřování GPG klíčů. Lze jej integrovat s gitem. Je velmi univerzální a umožňuje používat více GPG klíčů pro stejná i různá hesla. Pass je podobný Ansible Vault, integrace je však řešena pomocí zásuvného modulu vyvíjeného komunitou. Má také strmější křivku učení. Modul community.general.passwordstore poskytuje způsob, jak Pass v Ansible používat.
Integrace Pass s Ansible
# Setup GPG
gpg --full-generate-key
# Generate password
pass generate <password-name> <length>
# Show password
pass <password-name>
# To get encrypted variable in Ansible
ansible localhost -m ansible.builtin.debug -a var="password" -e "password={{ lookup('community.general.passwordstore', 'heslo') }}"
# Output
localhost | SUCCESS => {
"password": "jfKuBd0l4Nt3"
}
Gopass
Gopass je „o něco úžasnější standardní správce hesel UNIX pro týmy“. Jak název napovídá, je podobný Pass, ale řeší problémy, jako je nativní podpora více uživatelů a další funkce. Lze jej použít v automatizovaných postupech. Je kompatibilní s úložišti Pass, takže není nutné svá hesla migrovat. Plugin community.general.passwordstore pro Ansible je s Gopass kompatibilní.
Použití
# Spawn environment with secrets
gopass env <password-name> /usr/bin/bash -c "printenv <PASSWORD-NAME>"
# Output
jfKuBd0l4Nt3
Git-secret
Git-secret umožňuje šifrovat soubory v systému git pomocí veřejného klíče vybraných uživatelů.
Kompilované jazyky nejsou bezpečné
Můžete namítnout, že v kompilovaných jazycích, na rozdíl od těch interpretovaných (např. Python) nemusíte správu secrets řešit. Jazyky jako Go, Rust a C++ jsou kompilovány do strojového kódu a extrahovat secrets z binárního kódu je obtížnější. Nicméně je to stále možné. Můžete použít šifrování, ale pak musíte někde uložit klíč, což představuje stejný problém. Jedná se o zabezpečení skrze utajení, což není dobrá praxe. Jak je uvedeno v doporučení NIST SP800 (str. 15): “Bezpečnost systému by neměla záviset na utajení implementace nebo jejích součástí.”
Kontakt
Pokud chcete vědět více nebo potřebujete pomoci s nasazením, neváhejte nás kontaktovat na csirt@muni.cz.