Bezpečnost pro vývojáře
6 min

Jak bezpečně sdílet soubory .env a proměnné prostředí s týmem

Přestaňte posílat hesla k databázím a API klíče přes Slack. Takhle bezpečně sdílíte soubory .env s vývojářským týmem — od rychlých řešení po dlouhodobé postupy.

LOCK.PUB
Jak bezpečně sdílet soubory .env a proměnné prostředí s týmem

Jak bezpečně sdílet soubory .env a proměnné prostředí s týmem

Okamžik onboardingu, kterého se všichni bojíme

Do týmu nastoupí nový vývojář. Nastavuje si lokální prostředí a položí nevyhnutelnou otázku:

„Ahoj, může mi někdo poslat soubor .env?"

Co následuje, je až tristně předvídatelné. Seniorní vývojář zkopíruje celý obsah svého souboru .env — hesla k databázím, API klíče, tajné klíče třetích stran — a vloží ho do soukromé zprávy ve Slacku nebo do vlákna v iMessage. Ta zpráva teď leží někde na serveru, dohledatelná, navždy.

Všichni jsme to udělali. A je to mnohem větší riziko, než si většina týmů uvědomuje.

Proč je nebezpečné sdílet soubory .env nezabezpečeně

Váš soubor .env je v podstatě truhla s pokladem plná přihlašovacích údajů:

  • Připojovací řetězce k databázím — host, port, uživatelské jméno, heslo, název databáze
  • API klíče — Stripe, AWS, Firebase a další služby, jejichž zneužití stojí skutečné peníze
  • Tajné klíče třetích stran — OAuth client secrets, podpisové klíče webhooků, šifrovací klíče
  • Tokeny interních služeb — autentizace mezi mikroslužbami

Když je vložíte do Slacku nebo Messengeru, data se uloží na jejich serverech. Kdokoli s přístupem do workspace může tyto zprávy vyhledat a najít i za několik měsíců či let. A pokud se zařízení ztratí nebo je kompromitováno, jsou v ohrožení i tyto přihlašovací údaje.

Běžné (nebezpečné) způsoby, jak týmy sdílejí soubory .env

Způsob Proč je riskantní
Soukromá zpráva ve Slacku / Teams Uloženo na serverech poskytovatele, často i roky, a správci se k tomu dostanou přes exporty a eDiscovery
Příloha e-mailu Leží na poštovních serverech, lze ji přeposlat, v úložišti je zřídka šifrovaná
Google Docs Únik odkazu = přístup má kdokoli, historie verzí obsah uchovává
Commit do gitu I smazané commity žijí v historii git log, boti prohledají GitHub během vteřin
Notion / Confluence Stránky jsou ve výchozím stavu často viditelné celému workspace a bez omezení přístupu nevyprší

Scénář s commitem do gitu je obzvlášť krutý. Automatizovaní boti nepřetržitě prohledávají veřejné repozitáře na GitHubu a hledají odhalené přihlašovací údaje. Pokud omylem pushnete soubor .env, vaše klíče k AWS mohou být kompromitovány během několika minut.

Bezpečné způsoby, jak sdílet soubory .env

1. Správci tajných klíčů

Doppler, HashiCorp Vault a AWS Secrets Manager jsou vytvořené přesně pro tento účel. Centralizují vaše proměnné prostředí a nabízejí jemně nastavitelné řízení přístupu, auditní logy a automatickou rotaci. Pokud má váš tým víc než pár vývojářů, je to zlatý standard.

2. Týmoví správci hesel

1Password Teams i Bitwarden Organization podporují sdílené trezory, do kterých můžete obsah souboru .env uložit jako zabezpečené poznámky. Přístup se řídí pro každého uživatele zvlášť a vše je šifrováno end-to-end.

3. Jednorázové poznámky chráněné heslem

Pro rychlé jednorázové sdílení — třeba při onboardingu nového vývojáře — se hodí nástroj jako LOCK.PUB. Vložte obsah souboru .env do tajné poznámky, nastavte heslo, nastavte, aby se otevřela jen jednou nebo po určité době vypršela (Pro), a pak pošlete odkaz přes Slack a heslo jiným kanálem (například přes WhatsApp nebo telefonicky). Poté se odkaz přestane otevírat — ve Slacku zůstane nefunkční odkaz, ne vaše přihlašovací údaje. Nemáte Pro? Tajnou poznámku chráněnou heslem si můžete vytvořit i bez něj, jen bez jednorázového zobrazení a vypršení platnosti.

4. Soubory šifrované pomocí GPG

Týmy, které dbají na bezpečnost, mohou soubor .env před sdílením zašifrovat pomocí GPG. Nevýhodou je, že každý člen týmu musí spravovat GPG klíče, což přidává práci navíc.

Osvědčené postupy pro správu souborů .env

  1. Okamžitě přidejte .env do .gitignore — To by mělo být první, co uděláte při zakládání nového projektu.
  2. Udržujte soubor .env.example — Uveďte v něm každou proměnnou se zástupnou hodnotou, aby noví vývojáři věděli, co je potřeba.
  3. Pro každé prostředí používejte jiné přihlašovací údaje — Vývojové, staging a produkční prostředí by nikdy neměla sdílet stejné klíče.
  4. Pravidelně rotujte tajné klíče — Minimálně jednou za čtvrtletí.
  5. Když lidé odcházejí, odeberte jim přístup — Když člen týmu odchází, rotujte všechny tajné klíče, ke kterým měl přístup. Nejen jeho účet — samotné přihlašovací údaje.

Rychlé nastavení: .gitignore + .env.example

Přidejte tohle do svého .gitignore hned teď:

# Environment variables
.env
.env.local
.env.*.local

Pak vytvořte soubor .env.example, který poslouží jako dokumentace:

# .env.example
DATABASE_URL=postgresql://user:password@localhost:5432/mydb
STRIPE_SECRET_KEY=sk_test_xxxxxxxxxxxx
FIREBASE_API_KEY=your_firebase_api_key_here
NEXT_PUBLIC_BASE_URL=http://localhost:3000

Tento soubor commitněte do repozitáře. Každému novému vývojáři přesně řekne, jaké proměnné potřebuje, aniž by odhalil jakékoli skutečné hodnoty.

Přestaňte posílat tajné klíče jako prostý text

Sdílení souborů .env se může zdát jako drobný detail pracovního postupu, ale patří k nejčastějším zdrojům úniků přihlašovacích údajů. Ať už investujete do plnohodnotného správce tajných klíčů, nebo ke sdílení přihlašovacích údajů s datem vypršení použijete LOCK.PUB, důležité je zbavit se zvyku vkládat tajné klíče do chatových zpráv.

Zkuste to hned teď: vyhledejte ve svém workspace ve Slacku DATABASE_URL nebo API_KEY. Výsledky vás možná překvapí.

Vytvořit poznámku

Vytvořit poznámku

Klíčová slova

bezpečné sdílení souboru .env
sdílení proměnných prostředí v týmu
správa tajných klíčů pro vývojáře
Jak bezpečně sdílet soubory .env a proměnné prostředí s týmem | LOCK.PUB Blog