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.

30. 10. 2024 Matěj Smyčka DevOps

Bez popisku

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

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ří:

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ý:

Uvědomte si, že secrets se mohou nacházet také na následujících místech:

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ší:

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:

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:


Proč je považujeme za optimální řešení?

Výhody: 

Nevýhody:

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

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é.

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.

Používáte starou verzi internetového prohlížeče. Doporučujeme aktualizovat Váš prohlížeč na nejnovější verzi.

Další info