V závěru je snad úplně jedno co za "tajemství" je tam uložené ne?
Důraz na zabezpečení je pro všechna uložená "tajemství" stejný.
Některé hesla mohou napáchat mnohem větší škody než privátní klíč.
No, tiket pre kerbera je unikatny pre kazdeho user@host. Cize je mozne definovat ze user@host1 sa dostane na user@host2, a user@host2 sa dostane na user@host3. Mozete si v tomto pripade kopirovat tikety ako chcete, user@host1 sa nedostane priamo na user@host3 a uz vobec sa neostane user@host4 na user@host2 alebo user@host3...
to je trochu nepřesné. V kerberosu většinou mám UPN ve stylu <user>@REALM, který nese identitu konkretního uživatele, poté mám SPN něco jako host/<hostname>@REALM, který nese identitu konkrétního zařízení nebo obecněji <service>/<hostname>@REALM, které identitu konkrétní služby na konkrétním zařízení. Přes policy/ACL poté mohu určit z jakých SPN akceptuji UPN pro uživatele, protože UPN není vázáno na hostname jako je SPN. Zbytek je pak v duchu jak píšeš, mohu si určit, kdo může komunikovat s kým, nikoliv ale na úroveň pouze hostname, ale i na úroveň služeb.
Uživatel pak třeba svůj UPN ticket (krbtgt) získává prokázáním své identity ať už jenom zprostředkovaně přes SPN ticket daného zařízení nebo aktivně zadáním hesla či potvrzením přes 2FA aplikaci. Ticket je vygenerován a podepsán pro každé takovéhle přihlášení znovu.
Pokud jde o aplikace, ty si mohou při spuštění od KMS (či třeba od Hashicorp vault nebo Directory service) vyžádá svůj SPN ticket, které je vázáno na host, z kterého žádost posílá, s ním pak může komunikovat s předem danými službami či si vyžádat další přístupové údaje (connection stringy do legacy systémů, např.). Výhoda tohohle řešení je, že ACL pro host můžeme nastavit v momentě deploymentu, kdy víme na které sítí a hostnamu bude daná služba, ta si poté může vyžádat další přihlašovací údaje, pokud by existoval MitM útok, nestačilo by mu komunikaci odposlechnout a udělat repply attack nebo komunikaci modifikovat. Přístupové údaje nejsou nikde na serverech persistované, nelze je vypátrat na disku, visí pouze v paměti a jsou platbné pouze pro konkrétní pár host/service - host/service.
Pokud někdo nemá či se nechce pitvat s kerberosem, lze využít jednorázové schránky s hesly. Podporuje třeba hashicorp vault jako wrapped response (počet použití 1 a TTL cca 1 minuta je ideální), v ní může být připravena celá sada hesel, které daná aplikace potřebuje, identifikátor dostane při jejím spuštění (env proměnná, argument), data si vyzvedne přes https požadavek, po vyzvednutí se smažou, případně se smažou sami do minuty. Nezůstávají tedy opět nikde persistentě žádné přihlašovací údaje na prostředních a třeba CI/CD je nikdy nevidí, vidí je až aplikace, ta si je nechá v paměti.
18 Odpovědí
5978 Zhlédnutí