it-swarm-eu.dev

Jaká je běžná pragmatická strategie pro správu párů klíčů?

Mám několik různých pracovních stanic (plus klientských zařízení, jako je iPhone), které používám pro připojení k mnoha serverům pomocí SSH.

Původně, když jsem se dozvěděl o PKI, vytvořil jsem na své pracovní stanici jeden pár klíčů, který jsem začal okamžitě používat odkudkoli (což znamená, že jsem je zkopíroval do svého notebooku atd.) A použil jsem jej pro připojení ke všem svým serverovým účtům.

Od té doby jsem vyvinul názor, že se to všude podobá použití jediného hesla, a možná bude třeba přístup zrušit selektivně, např. pokud je některá z mých pracovních stanic ohrožena.

V podstatě se snažím vyvinout osobní strategii pro jednání s klíčovými páry:

Jaký je správný způsob, jak přemýšlet o klíčových párech bezpečně pro všeobecné použití, přičemž je pragmatický pro použitelnost? (tj. nemyslím si, že dvojice klíčů pro jedno použití pro každý bod připojení musí mít také smysl.)

Je špatné, aby dvojice klíčů reprezentovala osobní identitu globálně ze všech přístupových bodů („me-everywhere-id_rsa“), jak jsem to dělal v minulosti, nebo je podle mého názoru, že jedinečná kombinace klient-uživatel by měla být vždy reprezentována jeho vlastní klíč („me-on-my-personal-laptop-id_rsa“) vhodnější?

Znovu používáte stejný klíč pro připojení ke všem serverům nebo za jakých podmínek uvažujete o ražbě samostatného klíče?

48
Andrew Vit

Upřednostňuji jeden klíč na autentizační oblast. Takže pro každý pracovní počítač nebo server v práci (vše zcela fyzicky bezpečné a pod kontrolou jediné skupiny administrátorů) mám jeden soukromý klíč. Na svém novém domácím počítači používám stejný soukromý klíč jako můj starý domácí počítač. Používám různé klíče na notebookech a dalších mobilních zařízeních. Tento přístup umožňuje řízení jemnozrnných rizik: mohu odvolat klíče samostatně a omezit možnosti, aby se moje účty mohly zapojit do eskalované infiltrace tím, že neautorizuji určité klíče na určitých strojích (nedělám to tolik, ale je to možnost pro paranoid).

Dokud neuděláte nic složitého, kopírování veřejných klíčů není tak obtížné. Můžete si nechat jeden velký seznam autorizovaných klíčů a synchronizovat ho všude; zapsání zařízení znamená přidání jedné položky do tohoto seznamu a tlačení změny. Toto není mnohem víc práce, než tahání soukromého klíče, pokud máte na prvním místě centrální úložiště dat.

Všimněte si, že ačkoli nejviditelnější výhodou samostatných soukromých klíčů je možnost jednoho odvolat samostatně, mají také výhodu dostupnosti: pokud se správce systému na počítači A rozhodne zrušit klíč počítače C, na kterém právě pracujete, možná budete stále moci najít nějaký stroj B, který stále akceptuje C klíč a jehož klíč je akceptován A. Zdá se to, že je to spíše esoterické, ale stalo se mi to jednou (po Debian si uvědomil, že nevsadili svůj RNG) , byl jsem rád, že se nemusím spoléhat pouze na černou listinu klíče), zatímco jsem v nouzovém případě ještě nemusel klíč zrušit.

Vedení samostatného páru klíčů na strojový pár má dokonce teoretickou výhodu v tom, že umožňuje oddělené odvolání. Výhoda je však extrémně malá a správa je mnohem obtížnější (již nelze vysílat seznamy oprávnění). Zjednodušení správy klíčů je klíčovou výhodou kryptografie veřejných klíčů oproti sdíleným tajemstvím.

Už jste viděli hlavní bod: pokud je některý z vašich počítačů ohrožen, musí být soukromý klíč obsažený v tomto počítači „odvolán“: musíte nakonfigurovat všechny servery, na kterých se připojujete, aby pomocí tohoto klíče odmítli další pokusy o ověření (tj. Odeberete odpovídající veřejný klíč z .ssh/authorized_keys serverů). Existuje metoda zmírnění, která spočívá v zabezpečení soukromého klíče heslem (nebo heslem). To je spojeno s cenou, konkrétně musíte zadat heslo ( ssh-agent to může být docela užitečné); na druhou stranu to může útočníkovi dočasně odradit získávání soukromého klíče (záleží na druhu kompromisu, ale pokud se jedná o krádež kompletního počítače - věrohodný scénář s mobilními zařízeními), heslo zabrání okamžitý přístup k soukromému klíči a poskytne vám čas na opětovné nastavení serverů).


Lze si všimnout, že „PKI“ znamená „Veřejný klíč Infrastruktura“ a SSH je v tomto ohledu základní. V PKI s plným úderem by bylo použito osvědčení , s delegováním a centralizací zrušení. S certifikáty:

  • vytvořili byste jeden pár klíčů CA uložený někde bezpečně;
  • pro každý klientský počítač byste získali nový pár klíčů, přičemž veřejný klíč je podepsán CA;
  • servery by byly nakonfigurovány tak, aby automaticky přijímaly veřejný klíč libovolný veřejný klíč podepsaný CA (znají veřejný klíč CA, ale ne jednotlivé klíče klientského počítače);
  • cA by udržovala a pravidelně zveřejňovala informace o zrušení, tj. seznam veřejných klíčů, které již nesmí být akceptovány i když tyto klíče jsou podepsány CA (informace o zrušení musí být zaslány na servery, nebo na vyžádání).

Skvělá věc na certifikátech je, že centralizujete rozhodnutí, což v praxi znamená, že pokud se připojíte k 20 serverům z vašich klientských počítačů a poté přidáte nový klientský počítač, nemusíte ručně tlačit nový veřejný klíč do všech 20 serverů.

OpenSSH , od verze 5.4 (vydané 8. března 2010), má určitou podporu pro certifikáty; viz titulní část na manuálové stránce pro ssh-keygen . Certifikáty OpenSSH mají mnohem jednodušší formát než "obvyklé" certifikáty X.509 (jak se používají s SSL). Zjednodušení má také cenu: neexistuje podpora centralizovaného zrušení. Místo toho, pokud je ohrožen soukromý klíč, musíte na všech serverech stále zakázat odpovídající veřejný klíč a tento seznam je v OpenSSH whitelist (volba AuthorizedPrincipalsFile in sshd_config), která je obvykle pod kontrolou root. Zrušení tedy nefunguje dobře a stále musíte ručně konfigurovat věci na každém serveru, kdykoli vytvoříte nebo ztratíte klíč, což je přesně nepohodlné, které měl PKI zrušit.

Vy mohli stále vytváříte časově omezené klíče, protože certifikáty OpenSSH mohou vkládat časově omezené klíče. V takovém případě byste každému klientskému počítači dali klíč, který je vhodný například pro týden. S klíči, které zemřou po týdnu, a veřejným klíčem CA známým servery, máte hlavní dobrotu CA (není třeba nic tlačit na všechny servery, když je do klientského fondu přidán nový počítač), a pokud je soukromý klíč je ohrožen, poškození je „omezené“, za předpokladu, že jste měli klíčové heslo, které by pravděpodobně odolalo jednomu týdnu praskání (ale toto nebude fungovat, pokud je kompromis nepřátelským převzetím pomocí klíčového loggeru). Časově omezené klíče mohou časem být únavné a předpokládají, že všechny servery mají správně nastavené hodiny, což není vždy dané (bylo by nešťastné být uzamčen mimo server, protože serverové hodiny jsou divoce vypnuté a resetování hodiny vyžadují SSH přístup k serveru ...).

Dalším problémem s SSH je to, že je snadné přidat veřejné klíče na každý server. To znamená, že pokud útočník napadne soukromý klíč a získá přístup k serveru jednou, může přidat svůj veřejný klíč do .ssh/authorized_keys na tomto serveru a žádné množství odvolání to neopraví. Zrušení je ze své podstaty asynchronní proces. Nezavádí tedy dostatečně přísnou kontrolu poškození.


Vzhledem k nedostatkům podpory SSH pro certifikáty neexistuje rozumný systém, který by v některých situacích zamezil nutnosti provádět nějakou konfiguraci na všech serverech. Když tedy přidáte nový klientský počítač, máte v zásadě následující možnosti:

  1. Zkopírujete soukromý klíč z jiného klientského počítače (to právě děláte). To nevyžaduje žádnou další konfiguraci na serverech.

  2. Pro tento stroj vytvoříte nový pár klíčů. Veřejný klíč musíte poslat na všechny servery.

V případě kompromisu s klíčem se musíte připojit ke všem serverům a odebrat odpovídající veřejný klíč ze všech .ssh/authorized_keys. To je nevyhnutelné (abyste se tomu vyhnuli, museli byste používat certifikáty a SSH není v certifikátech dobrý, viz výše). Potom pokud jste použili volbu 1, pak musíte také vytvořit nový pár klíčů a poslat je všem klient = stroje, které používaly kopii ohroženého soukromého klíče.

Volba 1 tedy znamená méně práce s konfigurací než volba 2 v normálním případě, ale pokud dojde ke klíčovému kompromisu, dojde ke změně situace. Vzhledem k tomu, že kompromisy jsou obvykle vzácné události, upřednostňuje by se volba 1 (což je to, co již děláte). Navrhuji tedy, abyste svůj soukromý klíč chránili silným heslem a zkopírovali jej do všech svých klientských systémů.

Poznámka: ve všech výše uvedených případech jsem předpokládal, že se chcete připojit k seznamu serverů pomocí SSH a že byste chtěli získat přístup k některému ze serverů z kteréhokoli z vašich klientských počítačů. možná chcete omezit přístup, například přístup k danému serveru pouze z jednoho nebo dvou konkrétních klientských počítačů. To lze provést pomocí více klientských klíčů, ale složitost konfigurace se zvyšuje kvadraticky.

22
Tom Leek

V podstatě se snažím vyvinout osobní strategii pro jednání s klíčovými páry

Pokud jste primárně zodpovědní za příslušné servery, důrazně doporučujeme, abyste zvážili hledání nástrojů pro správu konfigurace, jako je loutka/šéfkuchař. Oba mají metody distribuce klíčů SSH na vaše stroje.

Důvody, proč jsem začal používat loutku, byly konkrétně proto, že jsem chtěl dobrý způsob, jak rychle změnit klíč na mých ~ 60 Linuxových serverech, když se personál změnil.

Pokud máte k dispozici nástroj pro správu konfigurace pro správu vašich klíčů, je mnohem snazší mít mnoho párů klíčů. Namísto ručního rušení klíče v každém poli nebo přidání nového klíče v každém poli jednoduše přidáte veřejný klíč do hlavního serveru konfigurace a klienti aktualizují seznamy oprávnění v libovolném intervalu dotazování, který jste nastavili pro správu konfigurace. nářadí.

To znamená, že dáváte spoustu důvěry ve správu konfigurace Host není ohrožen. Protože obvykle provádí úlohy s oprávněními root na každém počítači, ke kterému je konfigurujete, musíte se ujistit, že je pevně uzamčen a má spoustu auditů. Pokud by útočník ohrozil hlavní konfigurační soubor, mohl by udělat cokoli, jako je přidání nových klíčů, přidání nových účtů atd.

10
Zoredache

Používám jeden klíč na říši a na stroj. 4 vzdálené ovladače přístupné ze 2 pracovních stanic => 8 soukromých klíčů. Nikdy nekopírujte soukromý klíč z hostitele na jiný. Pokud je jedna pracovní stanice ohrožena, zrušte všechny tyto klíče.

Protože vytváření klíčů a konfigurace SSH pro jejich použití je docela únavné, napsal jsem nástroj věnovaný správě svých klíčů SSH pro přístup ke Githubu: github-keygen .

0
dolmen