Fórum Root.cz
Hlavní témata => Server => Téma založeno: vesterna12 02. 03. 2023, 18:10:49
-
Jakou používáte metodu na distribuci hesel a privátních klíčů pro aplikace ve Windows a Linux?
Aktuálně používáme "in-house" řešení, které si načte GPG soubory, které obsahují všechny hesla a klíče.
Všechna hesla jsou organizována do skupin a ke skupinám pak přiřazujeme jednotlivá oprávnění RBAC.
Klienti používají "wrappery", které se dotazují služby na hesla a ta je vrací podle autorizace klienta.
Služba je pochopitelně omezená jen na lokální síť (https), vyžaduje autentizaci certifikátem, heslem a jménem, ip filtrace aj..
Jde o aplikace mimo Docker/Kubernetes. Vše je "on-premise"
-
jako i privatni klice takto posilate? pokud jo, tak chapu, ze to je doma, ale je to spatne. do kanclu k sekretarce si ma kazdy dojit pro yubikey a je to.
-
Asi se ztracim, ale normalni certificate signing request nefunguje? I windows i linux umoznuji vyrobit CSR, privatni klic neopusti klienta a neni ho tak nutne kamkoliv posilat.
-
Jde o dva specifické případy, kdy máme klíče uložené v tomto řešení.
Pochopitelně pro jiné interní aplikace, které používají PKI, klíče neopouští klienta a ten jen posílá CSR na interní API PKI, který vystavuje podepsaný certifikát.
Ano, CRL máme taky (OCSP) a certifikáty mají krátkou životnost...
Možná pro usnadnění budeme předstírat, že jsem zmínil jenom ty hesla :D
-
Ja bych pouzil tohle: https://www.vaultproject.io/
-
A proc pak tedy ne hashicorp vault pokud se jedna jenom o hesla?
-
Také hlasuju pro HashiCorp Vault. Má to v sobě zabudované i to předávání hesel klientům nebo umí generovat jednorázová hesla – klient si požádá o heslo do nějakého systému a dostane vygenerované jednorázové heslo s omezenou platností.
-
me vzdy pobavi, jak se pri honbe za hyperbezpecnosti dojde do stavu, kdy se 'predavaji privatni klice' :D
-
řešení je velká řada, máte Doménu a můžete upravit aplikaci? Pro takové řešení je asi poměrně robustní použít kerberos z domény a ať si o hesla požádat až aplikace svým SPN, příjdou jí zašifrovaná, zůstanou pouze v paměti a neválí se nikde na disku.
me vzdy pobavi, jak se pri honbe za hyperbezpecnosti dojde do stavu, kdy se 'predavaji privatni klice' :D
mě zase vždy pobaví, když si lidé myslí, že bezpečnost se dá nejlépe řešit privátním klíčem uloženým persistentně na lokálním disku.
-
Díky Hashicorp vypadá dobře.
me vzdy pobavi, jak se pri honbe za hyperbezpecnosti dojde do stavu, kdy se 'predavaji privatni klice' :D
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íč.
Asi bych to tak neprožíval.
Ale možná mi něco uniká?
-
Vzdy je to o nakladech. Udelat superbezpecny system neni problem, problem je ho zaplatit.
-
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...
-
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...
Asi mi uniká podstata Vaší odpovědi v kontextu, ale Kerberos tiket bych tam asi neukládal. Spíš heslo uživatele, který po autentizaci ten tiket dostane....
-
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.
-
to je trochu nepřesné.
Njn, ako pises, ja som to zostrucnil.
-
Asi mi uniká podstata Vaší odpovědi v kontextu, ale Kerberos tiket bych tam asi neukládal. Spíš heslo uživatele, který po autentizaci ten tiket dostane....
Alebo skor keytab (man ktutil). Staci pre uzivatelov prihlasovanych automaticky nadefinovat prisnejsie pravidla z kade sa mozu prihlasit, ako pre fyzickych uzivatelov ktori natukaju heslo do klavesnice. V pripade kerbera ale automaticky prihlasovanych uzivatelov nepotrebujem. Totiz mi staci autentifikacia na klientovi. Napriklad pri poziadavku user@host1 -> http@host2 -> postgres@host3, mi staci prihlasenie na host1, host2 ziadne ulozene heslo pre host3 nepotrebuje, pouzije tiket z host1. Staci ak KDC vie kto z kade sa moze pripojit kam.
-
Jakou používáte metodu na distribuci hesel a privátních klíčů pro aplikace ve Windows a Linux?
Aktuálně používáme "in-house" řešení, které si načte GPG soubory, které obsahují všechny hesla a klíče.
Všechna hesla jsou organizována do skupin a ke skupinám pak přiřazujeme jednotlivá oprávnění RBAC.
Klienti používají "wrappery", které se dotazují služby na hesla a ta je vrací podle autorizace klienta.
Služba je pochopitelně omezená jen na lokální síť (https), vyžaduje autentizaci certifikátem, heslem a jménem, ip filtrace aj..
Jde o aplikace mimo Docker/Kubernetes. Vše je "on-premise"
Ale priamo k odpovedi, mimo sum ktory v diskusii vznikol:
Freeipa - uzivatel sa prihlasi cez kerbera. Distribucia hesiel tym odpada, uzivatel dostane pristup podla pravidiel ktore urcil spravca ktory je za to zodpovedny. Ak treba prihlasenie k externej sluzbe, ktora je mimo domenu, tak proxy, ktora udeli uzivatelovi pristup a externej sluzby sa dotazuje ulozenym heslom, ktore uzivatel nevidi.
Ad kluce. Distribucia privatneho kluca smerom ku klientovi je nezmysel. Kluc ma byt vytvoreny na klientovi a jeho verejna cast ma byt zverejnena.
-
Napriklad pri poziadavku user@host1 -> http@host2 -> postgres@host3, mi staci prihlasenie na host1, host2 ziadne ulozene heslo pre host3 nepotrebuje, pouzije tiket z host1. Staci ak KDC vie kto z kade sa moze pripojit kam.
Ospravedlňujem sa za offtopic vzhľadom k pôvodnej otázke vlákna, ale ako by host 2 na host 3 mal použiť ticket z host1?
Pokiaľ ma pamäť neklame, tak klient si Kerberos ticket od TGS žiada pre konkrétnu službu a ticket ktorý dostane, je zašifrovaný kľúčom danej služby. To, že ho služba rozšifruje sa považuje za časť overenia (t.j. služba vie, že token pripravil TGS ktorý pozná jej kľúč, takže potom verí obsahu tokenu). Ak by sa ale host2 snažil impersonovať klienta voči host3 prepoužitím tokenu, tak daný token host3 nerozbalí a neoverí, pretože je zašifrovaný kľúčom pre host2. Jedine, že by host2 a host3 mali identický kľúč, čo ale neviem, či je správne a žiadúce, pretože tento pattern by sa rozliezol a nakoniec by všetky služby (ktoré sa navzájom volajú) museli mať identické kľúče.
-
Ospravedlňujem sa za offtopic vzhľadom k pôvodnej otázke vlákna, ale ako by host 2 na host 3 mal použiť ticket z host1?
Host2 si od TGS vyziada dalsi tiket, na zaklade tiketu z host1 a pouzije ho pre host3.