Jak bezpečně sdílet SSH klíče a certifikáty s týmem

„Pošli mi ten SSH klíč na Slacku.“ Tohle slyšel každý vývojářský tým. Přístup k serveru je potřeba hned, nový člen týmu si musí nastavit prostředí, nasazení je za pár minut a někomu chybí klíč.

Právě tahle jediná žádost ale může být začátkem vážného bezpečnostního incidentu.

Proč je sdílení SSH klíčů obzvlášť nebezpečné

SSH klíče nejsou jako běžná hesla. Dávají úplný přístup k serveru.

Faktor	Heslo	SSH klíč
Rozsah	Konkrétní účet	Celý server
Dopad při úniku	Daný účet	Veškerá data na serveru
Náročnost výměny	Okamžitá změna	Nové vygenerování klíče + aktualizace všech serverů
Podpora 2FA	K dispozici	Samotný klíč je ověřením

Uniklý SSH klíč odhalí každý soubor, každou databázi a každý kus kódu na serveru. To je zásadně jiné než únik jednoho hesla.

Kdy týmy potřebují sdílet SSH klíče

Realisticky existují legitimní důvody ke sdílení.

• Sdílený přístup k serveru: Stagingové nebo produkční servery, které potřebuje celý tým
• Deploy klíče: Klíče používané v CI/CD pipelinech
• SSL certifikáty: Obnova certifikátů při změně odpovědností
• API tajné klíče: Přihlašovací údaje pro integrace třetích stran
• Přihlašovací údaje k databázím: Nouzová reakce na incidenty

Nebezpečné způsoby sdílení

1. DM ve Slacku nebo Discordu

Ani jedna služba nepoužívá koncové šifrování a historie chatu se ve výchozím nastavení uchovává na jejich serverech dlouhou dobu. Kdokoli z konverzace může vyhledat „ssh“ nebo „key“ a najít dříve sdílené klíče. Když zaměstnanec odejde, jeho účet lze deaktivovat, ale klíče, které přijal a odeslal, zůstávají v historii pracovního prostoru.

2. E-mail

Trvale archivovaný na poštovních serverech a po přeposlání nekontrolovatelný. Jediný průnik do poštovního serveru odhalí každý klíč, který kdy byl odeslán.

3. Sdílený Google Drive nebo Notion

Podrobné řízení přístupu je obtížné. Při synchronizaci souborů zůstávají lokální kopie v zařízeních. Dohledat všechny kopie, když někdo z týmu odejde, je prakticky nemožné.

4. Commit do Git repozitáře

Nejnebezpečnější způsob. Klíče zůstávají v historii Gitu navždy. I smazané soubory lze z historie obnovit. Pokud je repozitář veřejný, klíč je odhalen celému světu.

Bezpečné způsoby sdílení

Způsob 1: Tajná poznámka LOCK.PUB (nejlepší pro jednorázové předání)

Nejpraktičtější řešení, když potřebujete klíč předat jednou.

1. Vytvořte tajnou poznámku na LOCK.PUB
2. Vložte obsah SSH klíče nebo certifikátu
3. Nastavte silné heslo
4. Nastavte co nejkratší platnost (1–4 hodiny)
5. Odkaz pošlete přes Slack, heslo sdělte telefonicky
6. Až si příjemce klíč uloží lokálně, platnost odkazu vyprší

Výhody:

• Klíč není na žádném serveru trvale uložen v prostém textu
• Po vypršení platnosti je nedostupný
• V historii chatu není klíč v prostém textu

Způsob 2: Správci tajných údajů (pro větší týmy)

Použijte specializované nástroje jako HashiCorp Vault, AWS Secrets Manager nebo Google Secret Manager.

• Řízení přístupu a auditní logy jsou součástí
• Možnost automatické výměny klíčů (vestavěná ve Vaultu a AWS; Google Secret Manager posílá jen upozornění na výměnu, takže samotnou výměnu si musíte vytvořit sami)
• Nevýhodou jsou náklady a složitost nastavení

Způsob 3: SSH certifikační autorita (dlouhodobé řešení)

Místo sdílených klíčů provozujte SSH CA, která každému uživateli vydává individuální certifikát.

• Úplně odpadá potřeba sdílet klíče
• Správa přístupu pro každého uživatele zvlášť
• Vyšší počáteční náklady na nastavení

Způsob 4: Klíče pro každého uživatele (nejvíce doporučeno)

Kdykoli je to možné, vydávejte individuální klíče místo sdílení jednoho klíče v celém týmu.

Princip: Sdílený klíč < Individuální klíče
Únik sdíleného klíče → Zasažen celý tým
Únik individuálního klíče → Zasažen jen daný uživatel

Kontrolní seznam, když sdílet musíte

Pokud individuální klíče nepřipadají v úvahu a sdílení se nelze vyhnout, držte se tohoto kontrolního seznamu.

Před předáním

• Nastavili jste pro klíč minimální rozsah oprávnění?
• Nestačil by klíč jen pro čtení?
• Můžete použít omezení podle IP adresy?

Během předání

• Posíláte klíč a heslo různými kanály?
• Nastavili jste nejkratší prakticky použitelnou platnost?
• Může odesílatel po potvrzení příjemcem smazat originál?

Po předání

• Ověřte, že příjemce klíč bezpečně uložil
• Zkontrolujte, že platnost sdíleného odkazu/poznámky vypršela
• Sledujte logy používání klíče

Harmonogram výměny klíčů

Pravidelná výměna klíčů omezuje dobu, po kterou je případně kompromitovaný klíč použitelný.

Typ klíče	Doporučená výměna
Klíče k produkčním serverům	90 dní
Deploy klíče	90 dní
SSL certifikáty	Při každé obnově
API tajné klíče	90 dní
Vývojové/stagingové klíče	180 dní

Bezpečnostní kontrolní seznam pro DevOps týmy

• Používají se pro všechny servery individuální SSH klíče?
• Pokud existují sdílené klíče, je nastavené omezení podle IP?
• Deaktivují se klíče odcházejících zaměstnanců okamžitě?
• Existuje harmonogram výměny klíčů?
• Byly někdy SSH klíče commitnuty do Git repozitáře?
• Jsou v historii chatu uložené nějaké klíče v prostém textu?
• Používá se pro předávání tajných údajů kanál s vypršením platnosti?

Shrnutí

SSH klíče a certifikáty jsou páteří bezpečnosti serverů. Posílat je přes DM ve Slacku nebo e-mailem je jako připíchnout klíč od domu na veřejnou nástěnku. Kdykoli je to možné, vydávejte individuální klíče. Když se sdílení nelze vyhnout, použijte tajnou poznámku s co nejkratší platností.

Vytvořte si tajnou poznámku a předejte SSH klíče bezpečně.

Vytvořit tajnou poznámku