Pokud uživateli chybí lidské vlastnosti a nemá moc osobnosti, může to mít dobrý důvod. Uživatel může být stroj.
V dnešní době více než 90 % internetového provozu probíhá mezi stroji. Ve skutečnosti jsou stroje, které využívají vaši B2B SaaS aplikaci, také uživateli – jen jiným typem uživatelů. To je důvod, proč dnes každá online a SaaS aplikace musí zahrnovat promyšlené postupy a zásady správy uživatelů speciálně navržené tak, aby zvládaly různé výzvy a požadavky interakcí mezi stroji (M2M).
Je vaš cloud bezpečný?
Na základě dlouholetých zkušeností, které pomáhají B2B SaaS společnostem zvládat M2M interakce, jsem sestavil rychlého průvodce s osvědčenými postupy pro efektivní, efektivní a bezpečnou správu uživatelů mezi stroji. Pojďme se na ně podívat.
Poznejte své M2M uživatele a jejich případy použití
Kontext může být kritický pro správu lidských uživatelů, ale pro stroje je ještě důležitější, protože strojoví uživatelé nabízejí mnohem méně informací o svém stavu, situaci a záměru. Strojoví uživatelé často přistupují pouze k jedné službě nebo k malému počtu služeb, zatímco lidští uživatelé mají přístup k mnoha dalším.
Interakce mezi stroji nenesou užitečná vodítka, jako je agent prohlížeče, adresa MAC či NIC nebo geolokační údaje. Je pravděpodobnější, že se jedná o API call v běžně používaném protokolu s minimem identifikačních charakteristik. Kontext kolem požadavků na služby, které strojový uživatel vznese, by měl určovat, jak jsou aplikovány zásady a jak je navržena správa uživatelů.
Pro správu M2M uživatelů musí každá služba vědět, jak může komunikovat s ostatními službami a se kterými službami by měla komunikovat. Všechny služby potřebují vědět, jak komunikují s jinou službou a s klíčovými službami, ke kterým musejí mít oprávnění k přístupu. To je částečně to, co mohou poskytnout brány API a sítě služeb, ale ani jedno z toho nemá přístup zaměřený na uživatele (dokonce i pro M2M uživatele).
Zabezpečení bez vícefaktorové autentizace
Pro lidské uživatele je dnes MFA kritickou součástí procesu ověřování zabezpečení. Pro strojové uživatele není MFA životaschopnou alternativou. M2M transakce přitom obvykle probíhají v milisekundách, protože stroje mohou interagovat mnohem rychleji než lidé. To vytváří novou oblast pro útok, kterou se nyní mnoho kyberzločinců snaží aktivně zneužít prostřednictvím útoků na API.
Video ke kávě
Máte čas na rychlé a informativní video?
Pro týmy SecDevOps, které provozují procesy správy uživatelů proti M2M interakcím, to znamená, že je třeba věnovat mnohem přísnější pozornost dalším bezpečnostním mechanismům, jako jsou omezení IP adres, omezení počtu požadavků, rotace certifikátů nebo klíčů a v ideálním případě buď lidmi nebo strojově generovanými politikami, které rozpoznávají anomální vzorce používání.
Interní strojoví uživatelé vs. externí strojoví uživatelé
Podle toho, zda požadavek pochází od interního stroje nebo externího uživatele, by mělo dojít k velmi odlišným úvahám o zabezpečení. Pokud je požadavek interní a přichází z clusteru Kubernetes z jedné služby do druhé, pak se autentizace použije interně a obvykle s lehčí úpravou.
Sítě služeb se například používají k nastavení zásad, ke kterým službám se může daná interní služba připojit. Ve skutečnosti mnoho organizací stále neověřuje interní interakce mezi stroji, ale CISO a týmy pro řízení rizik tvrdě tlačí na implementaci základního ověřování všude.
K dnešnímu dni mnoho operací na platformě a týmů SecDevOps používá naivní ověřování pro vnitřní zabezpečení – tedy sdílená tajemství. Naivní autentizace však vyžaduje silný proces, který snadno nahradí tajemství, která byla porušena nebo nějak odhalena. Bez tohoto procesu výměny tajemství riskuje organizace výpadek, zatímco jsou vytvářena a sdílena nová tajemství. Změny tajných informací, které je nutné synchronizovat mezi páry nebo trojicemi uživatelů strojů, znamenají ve velkém měřítku spoustu práce. Takže i pro interní M2M komunikaci existují technologické výzvy.
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:
- Klient zadá požadavek na autorizační server a odešle tajný klíč klienta, ID klienta a požadované služby a rozsahy.
- Autorizační server ověří požadavek a odešle odpověď s přístupovým tokenem.
- 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í.
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é.
CIO Business World si můžete objednat i jako klasický časopis (v tištěné i v digitální podobně) Věnujeme se nejnovějším technologiím a efektivnímu řízení podnikové informatiky. Přinášíme nové ekonomické trendy a analýzy a zejména praktické informace z oblasti podnikového IT se zaměřením na obchodní a podnikatelské přínosy informačních technologií. Nabízíme možná řešení problémů spojených s podnikovým IT v období omezených rozpočtů. Naší cílovou skupinou je vyšší management ze všech odvětví ekonomiky.
PŘEDPLATNÉ
ČLÁNKY DO MAILU