it-swarm-eu.dev

Výhody klientských certifikátů pro autentizaci klientů?

Nejsem odborník na bezpečnost, proto se prosím zeptejte v komentáři, pokud jsem svou otázku nevyjasnil dost jasně na odpověď.

Scénář

Máme server provozující služby WCF a připojuje se řada klientů. Tito klienti jsou vlastně Linuxové počítače, které vytváříme. Potřebujeme navázat bezpečnou komunikaci mezi naším serverem a našimi klienty (znovu je budujeme a nasazujeme na zákaznické weby).

Klient důvěřující server

Toto provedeme tím, že klientovi umožní navázat důvěryhodné připojení k serveru prostřednictvím implementace SSL komunikace.

Server důvěřující klientovi

Nyní máme za úkol ověřit klienta. Zjevně se to provádí udržováním jakéhokoli pověření na klientovi. Jakmile je klient připojen, může odeslat pověření na server a server je může ověřit.

Jednou z možností pro tato pověření je uložit nějaký druh GUID nebo jiného ID/hesla, které je generováno aplikací založenou na WCF. Po přijetí pověření provede služba WCF vyhledávání v databázi a ověří, že jsou správné.

Další možností je použití Certifikační služby k vytvoření klientských certifikátů, které jsou před odesláním zkopírovány do klientského počítače. Po navázání zabezpečeného připojení klient odešle certifikát serveru, který ověřuje certifikát pomocí Certifikační služby.

Otázky

Jaké výhody má používání certifikátu k ověření klienta oproti uživatelskému jménu/GUID? Jaké má nevýhody?

Zvažte prosím:

  • Bezpečnostní
  • Složitost provádění
  • Složitost programování Integrace s aplikací. To zahrnuje pracovní postup vytváření autentizačního tokenu, přidružení vhodných (autorizačních/asociačních) metadat, správu autentizace, jako je zakázání přístupu atd.
34
Shaun Rowan

Nasazení klientských certifikátů by se zde hodilo. Výhody používání certifikátu oproti uživatelskému jménu jsou poněkud jednoduché. Uživatelské jméno může zadat kdokoli z klientského zařízení. Pokud používáte kombinaci uživatelského jména s GUID, pak „zabezpečení“ nebo ujištění, že se klient připojuje ze známého/autorizovaného klientského zařízení, závisí na síle a jedinečnosti GUID. Pokud existuje způsob, jak klonovat nebo spoofovat guid (mac adresy lze spoofed docela snadno), pak by se úroveň jistoty snížila.

Klientské certifikáty mohou být nasazeny na klienty s kontrolou platnosti i bez ní (kromě data platnosti, cn, ski/aki, otisků prstů atd.). Mechanismy kontroly platnosti na vyžádání, jako je ocsp, by vyžadovaly kontrolu serverové aplikace s ocsp serverem pokaždé, když se klient připojí/pokusí se ověřit. Ale z popisu jsem nečetl, že kontrola platnosti je stejně důležitá jako schopnost svázat certifikát k klientskému zařízení.

Jedním z důležitých detailů s klienty certs (certs obecně) je to, že je možné exportovat a většina implementací nezablokuje přenositelnost certifikátu. Bez ohledu na to, zda a jak budou klientské certifikáty ukládány, bez správných opatření lze certifikát snadno zkopírovat ze zařízení do zařízení. Některé implementace ukládají cert do souborového systému (soubory, které končí koncovkou .cer, .der, .key, .crt, obvykle označují, že jsou v souborovém systému uloženy certs). Silnější implementace (závislé na aplikaci) mohou ukládat klíče a klíče do úložiště klíčů (tj. Java úložiště klíčů). Úložiště klíčů může přidat další ochranu, například zajistit, že soukromý klíč nebude exportovatelný. ujištění, že klíč nebyl exportován, je pouze tak silná jako samotný klíčový obchod. Hardwarové klíčové obchody (tj. smart karty, usb hsm, ironkey atd.) nabízejí mnohem silnější záruku, že soukromý klíč nelze exportovat než úložiště softwarových klíčů.

BTW, výše uvedený bod také ovlivňuje klíče serveru. Většina implementací ukládá soukromý klíč do úložiště softwarových klíčů a je obvykle označena jako exportovatelná. Soukromý klíč dále obvykle není chráněn heslem, takže kdokoli s přístupem na server může soukromý klíč odejít. Pokud lze certifikát zkopírovat, pak nenabízí odmítnutí.

Chcete-li odpovědět na vaši otázku, existuje-li dobrý způsob využití hardwarového id druhu (GUID, sériové číslo, certifikát uložený v HSM atd.), Bude pravděpodobně poskytovat větší jistotu než použití softwarového id (včetně klientských certifikátů) . Použití klientských certifikátů s povolenou ochranou heslem pro přístup soukromého klíče poskytuje trochu silnější ověření, protože klient potřebuje nejen přístup k soukromému klíči, ale také heslo, aby jej mohl použít.

Pokud se rozhodnete používat klientské certifikáty, musíte vybudovat nebo použít existující infrastrukturu PKI. Prodejci jako Codomo, Entrust, Symantec (dříve vrsn, thawte a geotrust), Godaddy a mnoho dalších nabízejí veřejnou i soukromou infrastrukturu k použití. Náklady na implementaci softwarového certifikátu klienta však budou pravděpodobně vyšší než použití hardwarového id softwaru nebo možná dokonce jedinečného hardwarového id.

Pokud něco, určete úroveň jistoty, kterou chcete mít, a rozhodněte, zda je software, software + heslo nebo hardware dostatečný.

19
bangdang

Při ověřování klientským certifikátem tajný klíč (soukromý klíč) nikdy neopouští klienta a nejde na server. Ať už serveru důvěřujete nebo ne (přesto byste to měli nejdříve zkontrolovat), váš soukromý klíč nebude únikem. To je výhoda oproti tradičnímu ověřování na základě formulářů nebo HTTP Basic.

Můžete dokonce použít některé hardwarové kryptografické tokeny/čipové karty navržené tak, aby soukromý klíč nikdy neopouštěl token (podpisy zahrnuté v handshake TLS se stávají na palubě).

Pokud používáte klientské certifikáty v rámci infrastruktury veřejných klíčů (s největší pravděpodobností), můžete také těžit z výhod, které nabízí PKI. To je užitečné zejména pro velké struktury, ale můžete:

  • Uvědomte si totožnost uživatelů, které jste dosud nezaregistrovali.

    Pro to jsou certifikační autority. Pokud důvěřujete certifikační autoritě, důvěřujete certifikátu, který vydává. Pokud se neznámí uživatelé přihlásí k vašemu systému bez dříve existujícího účtu a pokud předloží certifikáty, kterým důvěřujete, budete moci rozpoznávat jejich totožnosti, jak je zaručeno CA. Možná budete chtít získat další podrobnosti od uživatele, ale hlavní identita bude uplatněna u CA a zanechá tam administrativní stopu.

  • Stejná identita uvedená v certifikátu může být použita na více nezávislých webech (za předpokladu, že důvěřují stejné certifikační autoritě), případně jako forma jednotného přihlášení.

  • Kompromitovaný certifikát může certifikační autorita odvolat přímo.

  • Prostřednictvím CÚ oddělujete problém prokazování identity uživatele od poskytování samotné služby. Tento cíl také dosahují jiné metody, jako je OpenID, ale jen stěží poskytují stejnou úroveň jistoty, jakou mohou CA dělat (pokud CA vykonávají svou práci správně). Úroveň jistoty se bude lišit v závislosti na kvalitě CA.

    Výhodou je, že můžete znovu vydat nový certifikát stejnému uživateli pomocí různých klíčů (pokud platnost předchozího certifikátu vypršela nebo pokud byl soukromý klíč ohrožen) a zachovat stejný identifikátor (předmět) ve všech systémech, kterým tomu důvěřujete CA.

(Můžete také použít klientské certifikáty mimo kontext PKI, ale musíte definovat svá vlastní pravidla důvěryhodnosti, což může být docela únavné.)

Klientské certifikáty lze také použít nezávisle na protokolu běžícím nad SSL/TLS. Můžete je dokonce použít například pro S/MIME, je-li to možné.

Další výhodou je to, že protože k autentizaci nedochází na úrovni HTTP, je to ve skutečnosti bez státní příslušnosti, pokud pro vás záleží na architektonickém stylu REST).

Některé webové služby to mohou také použít pro zabezpečení na úrovni zpráv, a tím případně opustit audit trail pro nevypovědení určitých zpráv, pokud je to nutné.

Hlavní nevýhodou je, že budete muset uživatele poučit o základních koncepcích kryptografie s veřejným klíčem. To je zvláště důležité, pokud nepoužíváte hardwarové tokeny (ale pouze uchováváte certifikáty a soukromý klíč v uživatelském softwaru).

  • Na rozdíl od hesel si uživatelé nebudou pamatovat soukromý klíč/cert. Budou muset použít stroj, na kterém je nainstalován certifikát (nebo kde je vhodná čtečka karet pro hardwarová řešení). Pro zkracování rohů mohou být v pokušení nestarat se o své soukromé klíče tak pečlivě, jak by měli (obvykle jsou sami chráněni heslem).

  • Při vysvětlování může být pojem „certifikát“ matoucí. Dokonce i experti někdy zkracují věty. Pokud řeknete „přihlaste se pomocí certifikátu“, máte na mysli „použít soukromý klíč a certifikát k přihlášení“: tento výraz je zahrnut do soukromého klíče. Naproti tomu, pokud vám někdo řekne „pošlete mi svůj certifikát“, neměli byste pak používat svůj soukromý klíč. Pokud se podíváte na dokumentaci, najdete řadu odkazů na soubory PKCS # 12 (.p12 nebo .pfx) a soubory certifikátů PEM (.pem nebo .crt, typicky). První obvykle obsahuje soukromý klíč, zatímco druhý ne (ačkoli to také může). Všechny tyto pojmy zaměří uživatele, pokud nebudou vědět, co dělají.

  • Uživatelské rozhraní prohlížeče pro klientské certifikáty jsou obvykle velmi špatné. Z pohledu uživatelského rozhraní je docela obtížné odhlásit se z webového serveru, na kterém jste se například autentizovali pomocí klientského certifikátu (například HTTP Basic). (Je to ještě důležitější pro ochranu CSRF.) Pokud jsou vaši klienti „stroji“ a ne uživatelé prostřednictvím prohlížeče, nejedná se o problém.

Pokud jde o infrastrukturu, pokud nejste ochotni využívat služeb komerční certifikační autority pro své klientské certifikáty, budete muset nasadit vlastní certifikační autoritu. Všimněte si, že certifikační úřad používaný k ověřování klientů může být nezávislý na certifikačním úřadu používaném k ověřování serveru. Můžete spustit web s certifikátem vydaným známou certifikační autoritou, ale nechat si důvěřovat klientským certifikátům od své vlastní certifikační autority. Existují různé nástroje pro správu CA, včetně těch s otevřeným zdrojovým kódem . Někteří mohou dokonce generovat klíče v prohlížeči, takže soukromý klíč je připraven v prohlížeči (nevýhodou je, že uživatel musí znovu použít stejný prohlížeč k importu certifikátu po jeho vydání).

Konfigurace serverů vyžaduje jisté porozumění tomu, co certifikáty (certifikáty CA, certifikát serveru), ale ve skutečnosti to není tak složité. Většina serverů tak či onak podporuje.

Klientské certifikáty poskytují pouze ověření. Možná budete muset získat další atributy (např. Z LDAP nebo databáze proti subjektům certifikátů). Určitě budete muset mít autorizační logiku, stejně jako u jakéhokoli jiného ověřovacího systému. Je typické mapovat DN subjektu na místní identifikátor ve vašem systému.

(Existují pokročilejší způsoby použití, kde můžete delegovat autentizaci pomocí proxy certifikátů nebo předat autorizační tokeny prostřednictvím atributových certifikátů, ale ty jsou neobvyklé a nejsou akceptovány všemi softwarovými balíčky.)

19
Bruno