Egy régi rendszergazdai kulcs még mindig a projektmappában van. Több szerveren működik, de senki sem tudja pontosan, kinek van belőle másolata. A jelszavakról SSH-kulcsokra váltás ekkor megváltoztatta a bejelentkezést, a felelősséget azonban nem tisztázta.
A használható SSH-kezelés egyéni identitásokat, megfelelő céljogosultságokat és megbízható visszavonást kapcsol össze. A környezettől függően elegendő lehet a gondozott nyilvánoskulcs-állomány pontos leltárral. Nagyobb vagy gyakran változó környezetekben előnyt jelenthetnek a rövid élettartamú SSH-tanúsítványok. Mindkét út fenntartható üzemeltetést igényel.
Négy dolog, amelyet nem szabad összekeverni
A privát felhasználói kulcs lehetővé teszi a saját identitás igazolását. Védetten tároljuk, nem osztjuk meg chaten, e-mailben vagy védtelen projektmappában. A hozzá tartozó nyilvános kulcs az érintett célrendszereken rögzíthető az engedélyezett hozzáféréshez. Ujjlenyomata segíti az egyértelmű hozzárendelést a leltárban.
A hostkulcs ezzel szemben az elért szervert azonosítja. A host ellenőrzése megakadályozza, hogy a kapcsolat észrevétlenül rossz végponthoz vezessen. Egy SSH-tanúsítvány aláírt állítással egészíti ki a nyilvános kulcsot, például az identitásról és az érvényességről. Az OpenSSH-tanúsítványok saját formátumot használnak, nem szokásos TLS-/X.509-tanúsítványok.
A személyes bejelentkezést és a technikai feladatokat külön kell választani
Az adminisztratív munkát személyekhez és engedélyezett feladataikhoz rendeljük. Egy közösen használt, hosszú élettartamú rootkulcs szükségtelenül megnehezíti a kilépést, a rotációt és a nyomon követhetőséget. Jobb alapot adnak az egyéni bejelentkezések megfelelően szabályozott adminisztrátori jogokkal.
Egy mentési vagy telepítési feladatnak saját technikai identitás és dokumentált felelős kell. Ahol lehet, a hozzáférést a konkrét funkcióra korlátozzuk, például előírt paranccsal és megfelelő továbbítási szabályokkal. Egy dolgozó privát kulcsa nem válhat észrevétlenül egy automatikus feladat állandó előfeltételévé.
A kulcsleltártól a rövid élettartamú tanúsítványokig
Kevés rendszer esetén elegendő lehet a nyilvános kulcsok szabályozott terítése. A leltár rögzíti a személyt vagy szolgáltatást, az ujjlenyomatot, a célrendszereket, a hatókört és a tervezett ellenőrzési vagy csereidőpontot. Döntő, hogy a jogosultságokat minden érintett célon megbízhatóan karbantartsuk.
Egy SSH-hitelesítésszolgáltató ehelyett korlátozott időre és meghatározott identitásokhoz írhat alá nyilvános kulcsokat. A szerverek megbíznak a kijelölt CA-ban, és ellenőrzik további szabályaikat. A privát bejelentkezési kulcsot ehhez nem kell átadni a CA-nak. A CA kulcsait és kiadási szabályait különösen védeni kell.
A rövid érvényesség csökkenti a kiadott igazolás használhatóságának időtartamát. Nem zárja le azonban a már futó munkamenetet, és nem helyettesíti a visszavonási folyamatot. Kilépés után az új tanúsítványok kiadását is meg kell akadályozni. Egy központi titokkezelő platform lehetséges üzemeltetési forma; ténylegesen támogatnia kell a konkrét SSH-folyamatot.
| Kezelési mód | Mire alkalmas | Üzemeltetési követelmények |
|---|---|---|
| Nyilvános kulcsok karbantartása | Áttekinthető, jól leltározott célrendszer-állomány. | Terítés, régi jogok eltávolítása és helyettesítés. |
| SSH-tanúsítványok kiadása | Korlátozott érvényesség és meghatározott identitások. | CA-védelem, kiadási szabályok, szerverbizalom és visszavonás. |
| Technikai identitások | Automatizálás egyértelmű feladattal. | Korlátozott céljogok, felelős és csereeljárás. |
| Agent vagy hardverkulcs | Megfelelő személyes bejelentkezési módok. | Továbbítási korlátok, verzióellenőrzés és helyreállítás. |
Az agent és a hardverkulcs tudatos használata
Az SSH-agent a betöltött kulcsokkal úgy teszi lehetővé a bejelentkezést, hogy a privát kulcsfájlt nem kell minden célszerverre másolni. Az agent továbbítása ugyanakkor hozzáférést ad egy távoli rendszernek az aláírási képességeihez. Az OpenSSH kifejezetten figyelmeztet: az adott rendszerhez megfelelő hozzáféréssel rendelkező támadó a kulcsanyag kiolvasása nélkül is bejelentkezhet a betöltött identitásokkal.
Az agenttovábbítást ezért csak a szükséges útvonalra állítjuk be. A támogatott időbeli vagy célhoz kötött korlátozások további határokat szabhatnak. A hardveres biztonsági kulcsok megfelelő interaktív hozzáférésekhez kínálnak másik lehetőséget. A kliensnek, szervernek, kulcstípusnak és érintési vagy PIN-követelménynek illeszkednie kell; egy felügyelet nélküli feladat igényei eltérnek a személyes bejelentkezéstől.
A rotációnak és visszavonásnak el kell érnie a célt
A kulcs lecserélése a notebookon még nem távolítja el a régi hozzáférést a szerverről. Rögzített nyilvános kulcsoknál minden érintett cél jogosultságait frissíteni kell. Tanúsítványokhoz további tiltási mechanizmusok, például OpenSSH Key Revocation Lists is alkalmazhatók. A tiltás csak akkor hatásos, ha a kijelölt szerverek helyesen figyelembe veszik.
Az eljárás az elveszett eszközt, a kompromittált kulcsot és a kiesett kezelési szolgáltatást is lefedi. A független vészhozzáférést védjük, dokumentáljuk és ellenőrzött módon teszteljük. A helyreállítás nem függhet éppen attól a hozzáférési úttól, amely meghibásodott.
Eltérően kell kezelni a Linux- és Proxmox-környezeteket
Vegyes környezetekben felmérjük a verziókat és a ténylegesen támogatott OpenSSH-funkciókat. Egy aktuális kézikönyv nem garantálja ugyanazokat a lehetőségeket minden meglévő Linux-telepítésen. Az új szabályokat kijelölt teszthozzáféréssel és ellenőrzött visszaúttal vezetjük be.
A Proxmox VE saját klaszterfunkcióihoz is használ SSH-t, például bizonyos konzol-, migrációs és replikációs útvonalakon. Ezeket a technikai bizalmi kapcsolatokat a személyes rendszergazdai hozzáférésektől külön vizsgáljuk. A kulcsfájlok általános tisztítása vagy felülírása megzavarhatja a működést. A változtatásokat ezért a telepített verzió dokumentációjához ellenőrizzük.
Mit tartalmaz egy áttekinthető kezdő lépés
A DAXS felméri a meglévő SSH-hozzáféréseket, kijelöli a felelősségeket és megtervezi a megfelelő kezelési módot. A pilot során bejelentkezést, jogokat, visszavonást, naplózást és helyreállítást tesztelünk. Önmagában egy sikeres bejelentkezés nem elég átvételi feltételnek. A puszta bejelentkezési naplók sem jelentenek automatikusan teljes felvételt minden végrehajtott parancsról.
Az infrastruktúra-szolgáltatások és a Proxmox vállalati használatáról szóló cikk az üzemeltetési hátteret mutatják be. Közös portáloknál a széfekről, szerepkörökről és kilépésről szóló cikk egészíti ki a képet. Kérheti az adminisztratív hozzáférések felmérését.
Gyakori kérdések
Megoszthatom a nyilvános kulcsot?
A nyilvános rész megfelelő terítésre szolgál. Ettől még ellenőrizni kell a helyes személyhez és célhoz rendelést. A privát részt védjük, nem adjuk körbe közös hozzáférési fájlként.
Elég egy rövid élettartamú tanúsítvány az azonnali visszavonáshoz?
Nem. A kiadást, a hátralévő érvényességet, a tiltásellenőrzést és a már futó munkameneteket együtt kell vizsgálni. A rövid időtartam nem helyettesíti ezt a folyamatot.
Mindig szükséges központi hitelesítésszolgáltató?
Nem. A megfelelő megoldást a méret, a változások gyakorisága, az automatizálás és az üzemeltetési képesség határozza meg. Egy áttekinthető állománynál a gondosan karbantartott kulcskezelés megfelelő lehet.
Források: OpenSSH: bejelentkezés és engedélyezett kulcsok (külső hivatkozás) · OpenSSH: tanúsítványok és visszavonási listák (külső hivatkozás) · OpenSSH: szerveroldali bizalmi és visszavonási szabályok (külső hivatkozás) · OpenSSH: agenttovábbítás (külső hivatkozás) · OpenSSH: agentkulcsok és korlátozások (külső hivatkozás) · Proxmox VE: adminisztrációs kézikönyv, SSH a klaszterben (külső hivatkozás)
Koncepcionális útmutatás; a konkrét funkciókat a telepített verziók és a tervezett kezelés határozza meg.
