Jak na PKI s pomocí Azure a MEM? - díl první

Jednou z běžných součástí bezpečného prostředí bývá certifikační infrastruktura. Jedná se o službu nebo soubor služeb, který zajišťuje vydávání, doručování a údržbu certifikátů. Obecně certifikáty používáme zejména pro identifikace, kde se určitý prvek prokazuje na základě vlastního důvěryhodného certifikátu, nebo pro šifrování, kde se certifikát použije pro zabezpečení komunikace nebo uložených dat. V každém případě toto celé funguje na principu důvěry – máte nějaký prvek, který představuje certifikační autoritu (CA) a ten považujete za dostatečně důvěryhodný. Každý platný certifikát, který byl vydaný nebo podepsaný touto autoritou je pro vás potom také důvěryhodný ve stejném rozsahu jako CA. Nakonec klient, který vlastní tento certifikát a jeho privátní klíč, je oprávněn jej použít k účelu, ke kterému byl vydán. Na základě toho potom vy důvěřujete tomuto klientovi, protože se prokazuje certifikátem od CA, které důvěřujete. Tento princip by se dal přirovnat známé situaci s řidičským oprávněním:

Úřad (certifikační autorita) – obecně důvěryhodná autorita, která vydává řidičské průkazy Řidičský průkaz (certifikát) – osvědčení, které jeho držitele na jednu stranu identifikuje a na druhou jej opravňuje k řízení vozidla určitého typu. Řidič (klient) – držitel řidičského oprávnění stanoveného řidičským průkazem.

Pokud řidič při silniční kontrole předloží svůj řidičský průkaz policistovi, tento policista je v tu chvíli schopen jednoznačně identifikovat řidiče a posoudit, zda je oprávněn řídit. A to z několika důvodů:

• Řidičský průkaz je platný – není poškozený nebo expirovaný.
• Průkaz je pravý, což je dáno jeho dostatečnými bezpečnostními prvky.
• Průkaz patří jednoznačně tomuto řidiči a ten má právo se jím prokázat.
• Policista důvěřuje vydavateli průkazu.

Jak to vypadá v on-prem infrastruktuře?

Pokud chcete používat certifikáty ve vlastním prostředí a zajistit si tak širší možnosti zabezpečení služeb máte k tomu zpravidla několik možností:

Self-signed certifikáty

Tento způsob je vhodný, pokud potřebujete zabezpečit spíše jednotky služeb nebo pouze testujete. Vytváříte certifikáty, které se neodkazují na žádnou certifikační autoritu a po vydání jsou následně podepsané samy sebou. Veškeré vztahy důvěry v tomto případě musíte nastavit ručně.

Pro vytváření těchto certifikátů je možné použít množství nástrojů jako je Powershell, Makecert, IIS, OpenSSL a řada dalších.

Certifikáty od externího vydavatele

Jednou z legitimních možností je také nevytvářet vlastní infrastrukturu, ale spolehnout se na externího vydavatele. Takový vydavatel vám zajistí obecně důvěryhodné certifikáty podle vašich požadavků a vy je budete moci instalovat a využívat bez potřeby vlastních serverů nebo specializovaných aplikací. Těchto vydavatelů je opět veliké množství a mohou zastupovat vlastní infrastrukturu z části nebo úplně. Za zmínku stojí, a to zejména pro začínající prostředí a malé produkce, např. certifikační autorita Let’s Encrypt. Jedná se o službu, která je poskytována zdarma a umožňuje vydávat obecně důvěryhodné certifikáty s platností na 90 dní. V průběhu platnosti lze ale tento certifikát automaticky obnovit a prodloužit tak jeho platnost.

Certifikační infrastruktura (PKI) s jednou certifikační autoritou (Stand-alone)

Jedná se o základní způsob, jak centrálně řídit vydávání certifikátů pro celé prostředí. V prostředí existuje jeden server, který se stará o vydávání a podepisování certifikátů pro všechny klienty. V takovém prostředí je pak pro ověřování třeba nastavit důvěru certifikátu tohoto CA. Nevýhodami tohoto řešení jsou ale omezené možnosti konfigurace a nemožnost integrace do domény a zajištění vysoké dostupnosti PKI.

Několikavrstvá PKI (Enterprise)

Robustní firemní řešení, které zajišťuje lepší správu, integraci s doménou a vyšší odolnost vůči selhání certifikační infrastruktury. Certifikaci v tomto případě již zajišťují minimálně dva servery, kde jeden zastává roli kořenové certifikační autority a další plní funkci vydávající certifikační autority. Kořenová CA má za úkol vydávat a podepisovat certifikáty pouze pro podřízené vydávající CA. Tato CA neobsluhuje žádné koncové klienty a při správné konfiguraci slouží i jako jakási záloha pro případ selhání vydávající CA. „Jakási záloha“ znamená, že sice nebudete moci rychle opravit padlý server, nicméně budete moci vyrobit nový server (třeba už ze skutečného backupu) a okamžitě zajistit jeho důvěryhodnost v rámci vaší domény díky novému certifikátu z funkční nadřazené CA. Navíc pro snížení výpočetního výkonu je možné kořenovou CA udržovat offline až do doby, kdy je opravdu potřeba, tzn. je třeba obnovit certifikát podřízeného CA nebo svůj vlastní, což je většinou v řádu roků.

Také už jste ale přemýšleli, jak toto celé rozumně provozovat v Azure?

S postupným přecházením služeb do cloudu ale může vyvstat otázka: „Jak vyrobit PKI co nejjednodušeji a s co nejnižšími náklady v cloudu?“ Vezměme například scénář, kdy chceme pro klientské počítače s Windows 10 distribuovat a udržovat certifikáty počítače pro použití na VPN. Takový certifikát musí být vydán stejnou autoritou jako SSL certifikát VPN serveru a musí být pravidelně obnovován.

V prostředí Azure máme samozřejmě možnost spustit celou infrastrukturu PKI jako IaaS, tedy na virtuálních strojích. Jaké komponenty proto ideálně potřebujete?

• Kořenová stand-alone CA
• Vydávající enterprise CA
• Doménový řadič – ideálně dva kvůli redundanci. Doménový řadič nese identity počítačů a je nezbytný pro funkčnost enterprise CA. Zároveň se díky němu dá zajistit distribuce certifikátů na zařízení pomocí GPO.

Zdroj: Microsoft

To je ale při implementaci v cloudu poněkud nedostačující vzhledem k tomu, že tato prostředí jsou z velké části o mobilitě, což nám závislost počítačů na doméně dosti omezuje. Abychom správně vkročili do cloudovéhu světa, potřebujeme tuto „on-premovou“ koncepci trochu rozšířit:

• Azure Active Directory – pro centrální správu identit v Azure
• Microsoft Endpoint Management (dříve Intune) – cloudová služba pro management koncových stanic. Zjednodušeně se jedná o moderní alternativu ke Group Policy Management známého z prostředí Windows domén.
• NDES – jedná se o službu, která je určena pro vydávání, obnovu a revokaci certifikátů pro síťová zařízení. Tato zařízení pak mohou samostatně se službou komunikovat prostřednictvím protokolu SCEP. Potřebují k tomu pouze prvotní autorizaci.
• Microsoft Intune NDES Connector – modul, který zajistí spojení NDES služby s MEM.

Zdroj: Microsoft

A jak to celé v tomto případě funguje?

Azure sám nativně vydávat certifikáty pro koncová zařízení jednoduše neumí. Rozlučte se s tím, že byste enterprise certifikační infrastrukturu, jak jí znáte z on-prem prostředí, přenesli do Azure jako PaaS. Nicméně, jak naznačuje obrázek výše, nějakým způsobem se zde s vlastními certifikacemi počítá. Samotný MEM zahrnuje několik konfiguračních možností, jak pracovat s certikáty. V našem případě využijeme konkrétně konfigurační profily:

• SCEP certificate - umožňuje definovat vlastnosti certifikačního požadavku a zasílá žádosti o vydání certifikátu na certifikační autoritu.
• Trusted certificate – instaluje na koncové stanice certifikát kořenové certifikační autority, pro zajištění důvěryhodnosti

MEM tedy zajišťuje distribuci certifikátů na spravované koncové stanice a komunikaci s certifikační autoritou. Je zde definována platnost certifikátu (validity period), použití (key usage), atributy předmětu (Subject name/Subject alternative name), hash algoritmus, síla klíče a samozřejmě URL SCEP serveru. SCEP server je v principu certifikační autorita, která je schopná komunikovat SCEP protokolem a vyřizovat tak požadavky MEM. V našem modelovém případě se jedná o Windows Servery s rolemi Active Directory Certification Services Enterprise Certification Authority (CA) a Network Device Enrollment Service (NDES). Když mluvíme o Windows Serveru, je z toho patrné, že tato část vyžaduje už vlastní virtuální stroje. Nedílnou součástí Enterprise CA je, na rozdíl od té Stand-alone CA, integrace s Active Directory, takže pokud stavíte nové prostředí čistě založené na cloudu, je nutné počítat i s implementací alespoň základní domény nutné pro provoz této CA. Stand-alone CA oficiálně není pro tyto účely podporovaná, nicméně z vlastní zkušenosti mohu říct, že s určitými změnami a omezeními je možné použít i tuto variantu.

Minimální množství virtuálních strojů potřebné pro toto PKI, je tedy:

1. VM s rolí AD DS a AD CS Enterprise CA

2. VM s rolí AD CS NDES

Upozornění:

Pokud byste chtěli ušetřit server a instalovat vše na jedno VM, toto řešení nedoporučuji. I přes zjevné bezpečnostní nedostatky vám toto možná bude ze začátku fungovat., s největší pravděpodobností ale během velice krátké doby začne docházet k výpadkům služby, která se neobejde bez rekonfigurace.

V druhém díle této krátké minisérie Jak na PKI pomocí Azure a MEM? - díl druhý si detailněji ukážeme implementační postup s použitím Enterprise CA