Bezpečná distribuce hesel a privátních klíčů

[Death Walker]

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.

[Reklama]

[Death Walker]

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.

[pangolin]

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.

[Death Walker]

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.