Jak by měly stroje spravovat uživatele?

Pro externí M2M komunikaci a správu uživatelů strojů se věci stávají mnohem komplikovanějšími. Tajné sdílení je nedostatečné zabezpečení. Chcete-li to demonstrovat, zvažte následující příklad. Řekněme, že máme dvě služby – uživatelskou službu a e-mailovou službu. Chceme poslat e-mail uživateli. Ne všichni uživatelé mají nárok na e-maily. Pro správnou správu uživatele tedy aplikace musí mít povědomí o tom, který uživatel má právo na e-mail a který e-mail by měl být uveden u zpráv zasílaných tomuto uživateli. Tajemství se v tomto světě rychle hroutí.

JWT vs. přístupové tokeny vs. přihlašovací údaje klienta

Tento případ použití také zdůrazňuje, proč jsou webové tokeny M2M JSON (JWT) vhodnější než obecné M2M komunikační služby. Služba správy uživatelů pak musí vygenerovat token pro konkrétního uživatele nebo konkrétní organizaci. Token lze zrušit nebo nastavit tak, aby vyžadoval obnovení v určitých intervalech.

Dobře navržená politika životního cyklu tokenů a jejich operační systém umožňují službám zabezpečení a správy uživatelů rychle zrušit přístup nebo točit klíče bez přerušení provozu. Zásady se automaticky použijí prostřednictvím seznamů zneplatnění nebo obnovení certifikátu. 

Pokud jsou obnovy v relativně krátkých časových rozvrzích, je možné vyladit správu uživatelů tak, aby poskytovala M2M uživatelům téměř nulovou důvěru. JWT mohou nést více atributů, takže jsou zvláště užitečné pro kódování kontextu.

Druhý způsob, jak organizace zpracovávají externí ověřování, je prostřednictvím přístupového tokenu – kdy uživatel obdrží jeden řetězec hodnot. Přístupový token funguje takto:

1. Klient zadá požadavek na autorizační server a odešle tajný klíč klienta, ID klienta a požadované služby a rozsahy.
2. Autorizační server ověří požadavek a odešle odpověď s přístupovým tokenem.
3. Klient použije přístupový token k vyžádání zabezpečeného prostředku z příslušného koncového bodu služby (API).

Přístupový token je velmi dobrý pro jednoduché transakce, ale ve složitějších scénářích se může rozpadnout a vytvořit jediný bod selhání. Pokud například z nějakého důvodu není přístupový token ověřen, neexistuje žádný snadný opravný prostředek a žádný jiný mechanismus pro hodnocení důvěryhodnosti. 

Při provozu na architektuře mikroslužeb to znamená složitější tok, který je obtížnější spravovat. Uživatel stroje by potřeboval okamžité ověření na samostatném ověřovacím serveru a servisním kanálu. U JWT vše, co služba potřebuje vědět, je, zda má uživatel platný JWT, který ukládá veškerý přístupový kontext. K ověření není potřeba spouštět samostatný proces.

Třetí cestou jsou přihlašovací údaje klienta. Jedná se o sadu identifikačních informací poskytovaných aplikací, jako jsou ID klienta a tajný klíč, které se používají k ověření aplikace a autorizaci přístupu ke zdrojovému serveru. 

Pověření klienta často obsahují JWT a mají tu výhodu, že jsou bezpečnější, protože vyžadují dva kusy identifikace. A zatímco přihlašovací údaje klienta mohou být méně uživatelsky přívětivé, není to takový problém, když uživatel není člověk.

S pověřeními klienta však musí být systém navržen pečlivě, aby umožnil rychlé zmírnění selhání a také redukci slabých míst („bottlenecků“). To může být obzvláště náročné, když se spoléháte na jiné distribuované systémy, jako jsou Google nebo OAuth, nebo na cloudový certifikát nebo autoritu tokenů třetí strany. V tomto scénáři se může organizace spoléhat na JWT, který nevytváří ani neřídí.

Přečtěte si také:

Tucet chyb při hledání zaměstnání, které byste neměli udělat

Středem mezi přihlašovacími údaji klienta a řízením přístupu může být vzájemný TLS (mTLS). mTLS zajišťuje, že strany na každém konci síťového připojení jsou tím, za koho se vydávají, tím, že ověřuje, že obě mají správný soukromý klíč.

 To vrství další mechanismy ověřování důvěry v bodě handshake. Některé sítě služeb, reverzní proxy a brány API používají mTLS ve výchozím nastavení, ale synchronizace mTLS napříč celou vaší infrastrukturou vyžaduje skutečný návrh systému a pečlivé promyšlení.

Kroky ke strategii

Vzhledem k tomu, že počet služeb a mikroslužeb neustále roste a stále více aplikací je postaveno na API, stává se kritickým vývoj silné strategie správy uživatelů a praxe pro M2M interakce. To znamená:

• Vytváření map pracovních postupů všech prvků vašeho stacku správy uživatelů a všech služeb.
• Identifikace služeb, k nimž uživatelé strojů pravděpodobně přistupují, a jejich klasifikace podle kritičnosti, měřené podle obchodního a bezpečnostního rizika.
• Analýza a rozhodování, které z vašich M2M uživatelských služeb vyžadují jaké typy autentizace.
• Vybudování integrovaného balíčku správy uživatelů, který splňuje všechny požadavky na správu uživatelů, a to jak lidských, tak M2M.

Pamatujte, že stroje jsou také uživatelé. Budete s nimi muset zacházet jako s uživateli, abyste zajistili, že služby, které používají, jsou dostupné, rychlé, škálovatelné a bezpečné.