Architektúra

Az Inshipia Security Gateway (ISG) egy daemon, az isg serve. Az operátorok lokális socketen vagy böngészőn át érik el; ő a célgépeket SSH-n éri el, a Web Access-szel pedig a webes admin-konzolokat HTTP(S)-en. Minden más — az identitásforrás, a levéltovábbító, az opcionális háttértárak — erről a daemonról lóg le, és elhagyható.

Egy gépen egy daemon a szállított alapértelmezés, és minden, ami itt következik, ezt írja le. Egyszerre több daemon is kiszolgálhatja ugyanazt az állományt, úgy, hogy az állapotukon osztoznak, nem a munkát osztják fel; hogy ez min változtat, azt a Több átjáró üzemeltetése fejti ki, és ezen az oldalon semmi más nem feltételezi sem az egyiket, sem a másikat.

Komponensek

Az átjáró az egyetlen dolog, ami hitelesítő adatot tart egy célgéphez, és mindegyiket percekig tartja. Egy operátor isg connect-je nem nyit maga SSH-kapcsolatot: átadja a kérést a daemonnak egy lokális UNIX socketen, a daemon pedig a kernelből állapítja meg, ki kérdez — nem abból, amit a kliens állít magáról. A böngésző ugyanazt a daemont éri el a saját TCP-portján az admin felületért és a jóváhagyási képernyőkért.

A Web Access ugyanez az átjáró a webes admin-konzolokhoz — BMC-felületekhez, monitoring- és tároló-konzolokhoz. A böngésző az átjáró alkalmazás-listenerét (apps.yaml: listen) éri el, az alkalmazás saját hosztnevén; az átjáró a felhasználót az alkalmazás csoportjaihoz, jóváhagyásához és az incidens-zárakhoz méri, minden kérést kiértékel a policy.yaml http_rules szabályai szerint, rögzíti a munkamenet átiratában, és csak utána továbbítja a konzolnak (upstream). A konzol egy aláírt assertionből tudja meg, ki a felhasználó (identity: jwt), semmiből (identity: none), vagy sehogy, mert az átjáró egy közös fiókkal lép be az OpenBao-ból (identity: credential — fejléc, basic belépés, vagy a konzol saját belépő űrlapja kind: form-mal). Űrlapos belépésnél a konzol munkamenet-sütijei az átjáró memóriájában maradnak: a böngészőnél csak az átjáró saját alkalmazás-sütije van.

Egy mode: isolated alkalmazás egyáltalán nem a felhasználó böngészőjében nyílik meg. Az átjáró egy izolációs (RBI) hoszton indít a munkamenetnek egy eldobható böngészőt, a felhasználónak csak a képét küldi Guacamole-protokollon (guacd, rbi.yaml: agents), és visszaveszi a bemenetét. Az izolált böngésző csak az átjárón át éri el a konzolt. Az RBI-agent kölcsönös TLS-sel a brókerek megújító listeneréhez kapcsolódik (rbi-agent.yaml: brokers): a parancsai, a böngésző forgalma és a felvétel feltöltése mind ezen megy, és az RBI-hoszton nincs hitelesítő adat és tároló-kulcs.

Három rendszer közönséges függőség, nem opció: a célgépek (SSH), az identitásforrás, ami egy operátort egy címtár-identitássá és a csoporttagságaivá old fel, és — ha a többfaktoros kódok e-mailben mennek, nem TOTP-vel — egy levéltovábbító. Az auditnapló lokális fájl, amit egy SIEM vagy naplószállító olvas; egy opt-in syslog-másolat (audit.yaml: syslog) minden bejegyzést ki is tolhat egy SIEM-be, de a fájl marad az audit-of-record mindkét esetben.

Egy negyedik külső rendszer opcionális, és csak a belépést adja: egy OIDC identity provider, az sso.yaml-ban megnevezve, az admin felület böngészős belépése és az átjárós bejelentkezés device flow-ja mögött. Az identitást és a jogosultságot sosem ő adja — a név, amit visszaad, keresőkulcs, és a címtár-kapu pontosan úgy áll, mint egy jelszavas belépésnél.

A szaggatottal rajzolt három háttértár ki van kapcsolva, hacsak egy konfigurációs fájl meg nem nevezi őket: egy OpenBao-példány a tanúsítvány-aláíróként a beépített helyett, PostgreSQL a munkamenet- és jóváhagyás-rekordok tárolójaként a lokális könyvtár helyett, és egy S3-kompatibilis objektumtár a munkamenet-felvételek archívumaként.

A szaggatott vonal egyetlen átjáró esetén jelent opcionálist. Többnél nem az: a PostgreSQL az, amin az átjárók osztoznak, az OpenBao pedig kötelezővé válik, nem csak elérhetővé. Az az átjáró, aminek neve van és PostgreSQL-t használ, de OpenBao-t nem, nem hajlandó elindulni — lásd Több átjáró üzemeltetése.

Kapcsolódás

Egy connect-et a daemon rögzített sorrendben dönt el, és pont a sorrend a lényeg. Elsőként a hívó identitása áll össze, a socket-kapcsolat kernel által tanúsított hitelesítő adataiból, és a címtár ellen oldódik fel. Ezután fut a két nem-interaktív hozzáférési kapu — a ca.yaml human_access-e, majd a hostgroup.yaml hosztonkénti megkövetelt csoportja —, hogy egy olyan kérés, amit soha nem engedtek volna át, ne kerüljön az operátornak egy többfaktoros kihívásába. Csak ezután megy ki a kihívás, és csak azután létezik egyáltalán hitelesítő adat, hogy sikerült.

Egy parancs jóváhagyása

Egy munkamenet minden parancsa önmagában értékelődik ki, a policy-fájl ellen, ahogy az abban a pillanatban szól — a policy.yaml parancsonként töltődik be, tehát egy szerkesztett policy a következő parancsnál lép életbe, az átjáró és a munkamenet újraindítása nélkül. Egy szabály vagy kereken megtagadja a parancsot, vagy egy második személyhez küldi. Az a parancs, ami semmire nem illeszkedik, lefut.

A beépített tiltó szabályok minden policy részei, beleértve egy olyan átjáró policyját is, amelynek egyáltalán nincs policy.yaml-ja, és egy felhasználói szabály nem írhatja felül őket: a fájl saját szabályai a beépített tiltások és a beépített jóváhagyási szabályok között értékelődnek ki, és az első találat nyer.

Egy webes konzol megnyitása

A felhasználó az admin felületen az Alkalmazásaim lapot nyitja meg — ez csak azokat az alkalmazásokat mutatja, amelyeket a csoportjai engednek —, és az alkalmazás linkjét követi. Az alkalmazás-hoszton még nincs munkamenete, ezért az a böngészőt egy egyszeri átadásra küldi az admin felülethez: ott a felhasználó már be van lépve, és az átadás újra megnézi a csoportokat, az incidens-zárakat és a licencet. Egy require_approval-os alkalmazás előbb időtartamot kér, és egy második személy döntésére vár (approval_mode: four_eyes), vagy indoklásra azonnal megnyílik (approval_mode: self); az ablaknak mindkét esetben vége van, és vele zárul az alkalmazás-munkamenet is. Onnantól minden kérésről külön születik döntés: egy incidens-zár, egy elveszett csoport vagy egy http_rules tiltás a konzol előtt elutasítja, egy step_up szabály friss második faktort kér, és minden kérés — engedett vagy sem — egy sor a munkamenet átiratában.

Állapot

Több átjáró üzemeltetése

Több átjáró is kiszolgálhatja egyszerre ugyanazt az állományt. Egyenrangúak: mindegyik minden szerepet visz — admin felület, munkamenet-brókerezés, CA-műveletek, jóváhagyások —, és egyik sem tartalék. Attól egyetlen rendszer és nem több, hogy az állapotukon osztoznak.

Amit ez ad, az az, hogy egy átjáró elvesztése nem zárja be az ajtót: az operátorok tovább nyitnak munkameneteket az állva maradtakon keresztül. Amit nem ad, az az elveszett átjárón már futó munkamenetek túlélése. Egy élő munkamenet egy SSH-folyam és egy PTY azon a bizonyos gépen; ha a gép elmegy, a folyam vele megy, és az operátor új munkamenetet nyit egy társon keresztül. A rekord viszont túléli — egy állva maradt átjáró lezártnak jelöli a munkamenetet, nem hagyja nyitva —, tehát az audit-nyomvonalon nincs rés.

Három dolog hordozza ezt a közös állapotot, és két dolog lokális marad, akárhány átjáró van:

A közös sorok bármelyikének helyében egy lokális könyvtár egy-átjárós elrendezés, nem közös — és attól, hogy azt a könyvtárat hálózati fájlrendszerre teszed, még nem lesz közös: a serve.lease rögzíti, melyik gép birtokolja az állapotgyökeret, és egy másik gépen futó átjáró nem hajlandó elindulni rajta.

Minden átjáró saját nevet visel — a broker.yaml id-ja, egy-nyolc alfanumerikus karakter —, és rábélyegzi minden munkamenet-rekordra és minden auditsorra, tehát egy a közös tárból olvasott rekord megmondja, melyik átjáró állította elő. A flottát az isg system brokers listázza.

A Fail-closed posztúra indulási elutasításai közül kettő ezért az elrendezésért van. Az első az, hogy egy névtelen átjáró nem csatlakozik olyan tárhoz, amit egy másik átjáró már használ. A második az, hogy annak az átjárónak, ami egyszerre nevezett és PostgreSQL-re mutat, az aláíráshoz és a többfaktoros titkokhoz is OpenBaót kell használnia. Az ok az, hogy az alternatívák külön-külön helyesek, és együtt csendesen hibásak: a beépített aláíró folyamatonként számolja a tanúsítvány-sorszámokat, tehát két átjáró ugyanazt a sorszámot adhatja ki két különböző tanúsítványra, és egy visszavonási lista onnantól nem egyetlen tanúsítványt nevez meg; egy pedig az egyik átjáró lemezére írt többfaktoros titok nem létezik a társain, tehát az az operátor, aki az egyiken regisztrált, a másikon nem tud bejelentkezni. Mindkét hiba messze jelentkezne az okától — egy visszavonásnál, ami nem harap, egy bejelentkezésnél, ami nem működik —, és ezért történik az ellenőrzés inkább induláskor.

Néhány dolog szándékosan lokális marad. Minden átjáró a saját auditnaplóját írja: a fájl szerződés szerint csak hozzáfűzhető, és egy közös író ezt a szerződést cserélné kényelemre. A flottaszintű nézet a sorok exportálásából áll össze, nem a fájl összeöntéséből. Az esemény-ticketek kimenő sora ugyanezért lokális: egy közös sornak közös rekord kellene, amire a munkát akaszthatja, egy visszavonásnak pedig nincs ilyenje. Az az átjáró tehát, ami leáll, a saját esemény-ticketjeit ott hagyja, amíg vissza nem tér — késés, nem veszteség, és az auditnapló fedezi a rést. A munkamenet-ticketek a fordított eset: azok a közös munkamenet-rekordról lógnak, tehát egy megszakadtat tizenöt perc múlva felvesz egy társ.

Az operátor szempontjából két következményt érdemes betervezni. Az admin felület a bejelentkezési állapotát a közös tárban tartja, tehát az átjárók ülhetnek egy név vagy egy terheléselosztó mögött, ragadós munkamenet nélkül. És egy célgép felé a szondázási ráta az átjárók számával szorzódik: az az időköz, ami megakadályozza, hogy a szondák kiváltsák a célgép kizárását, szándékosan átjárónként van kikényszerítve, mert terhelési tulajdonság, nem helyességi.

Flotta-topológia

A fentiek egyetlen átjárót írnak le. Egy éles környezet kis flotta, amit az Ansible playbookok telepítenek: az átjárók, és a gépek, amelyek a közös állapotukat, az identitásforrásukat és a monitorozásukat hordozzák. Ez a szakasz megnevezi ezeket a gépszerepeket, és hogy melyik melyik portot nyitja, kinek. Az átjáró saját portjai és socketjei lent maradnak, a Hálózat és portok alatt.

Egy tipikus környezet: két bróker, egy közös tár, egy címtár-hoszt, egy monitoring-hoszt és tetszőleges számú célgép.

Gépszerepek

Minden bróker, tár-, címtár- és monitoring-hoszt megkapja a tűzfal-baseline-t (isg_firewall) és a node exportert (isg_node_exporter) is. A célgépek egyiket sem: azok az ügyfélé.

Szolgáltatás, port és forrás

Minden sor forrásonkénti tűzfal-szabály, amit a portot birtokló role nyit. Az üres forráslista semmit sem nyit — sosem azt jelenti, hogy „mindenkinek".

A brókerről a célgépre menő SSH a célgép tűzfalán múlik, az pedig az ügyfélé. A Grafana a saját gépén, localhost-on éri el a Prometheust, ahhoz nem kell szabály.

Háló

A telepítésnek egyetlen hálózati bemenete van: négy érték és egy kapcsoló a környezet group-változói közt.

Minden más cím az inventoryból jön: a brókerek címei és a monitoring-hoszt. A gépnevek bármilyen névfeloldón át feloldódhatnak, a role-ok által használt címek azonban nem függnek tőle: kimondva állnak az inventoryban. A host-cert IP-principálját a futás nem tudja a gépen felderíteni, és egy több hálózati lábú gépen az alapértelmezett cím nem feltétlenül az, amelyiken a bróker tárcsáz.

Hálózat és portok

A portok a szállított alapértelmezések; mindegyik vagy egy flag az isg serve-ön, vagy egy kulcs egy konfigurációs fájlban. Az átjáró saját lokális socketjei velük együtt vannak felsorolva, mert egy operátor szemszögéből ugyanolyan dolgok: ajtó a daemonba. Ahol több átjáró fut, ott mindegyik a saját példányát köti be az alábbi minden sorának.

A fenti socket-útvonalak a rendszerszolgáltatás-elrendezéshez tartoznak. Ha az XDG_RUNTIME_DIR be van állítva — felhasználónkénti daemon, jellemzően kiértékelés közben —, a daemon helyette az $XDG_RUNTIME_DIR/isg/<name>.sock-ot köti be, a CLI pedig előbb a /run/isg/<name>.sock-ot keresi, és arra esik vissza.

E portok közül kettő alapból a hálózat felé néz, kettő pedig nem, és a különbség szándékos. Az admin felület a loopbackre köt, amíg ki nem szélesíted, a kiszélesítés pedig elutasításra kerül, ha nincs a helyén a hitelesítés és a TLS is (lásd lentebb: Fail-closed posztúra). A megújítási végpont minden interfészre köt, mert egy megújító ügynök definíció szerint máshol fut; a védelme a kölcsönös TLS, nem a bind-cím. A diagnosztikai figyelő loopbacken van és ki van kapcsolva, abból kiindulva, hogy a monitorozó ügynök ugyanazon a gépen fut.

A tanúsítványok életciklusa

Az átjáró saját hitelesítésszolgáltatót üzemeltet, amit egyszer kell inicializálni az isg ca init-tel. Négy különböző dolgot ír alá, négy különböző élettartammal, és a különbségek abból következnek, hogy melyik hitelesítő adat mire való.

Az emberi hozzáférési tanúsítvány az, amire egy munkamenet ténylegesen épül. Amikor egy connect minden kapun átjut, a daemon friss ed25519 kulcspárt generál a saját memóriájában, aláír fölé egy SSH-felhasználói tanúsítványt, és azzal tárcsázza a célgépet. Pontosan tíz percig érvényes — a kiadás mindkét oldalán öt percig, egy olyan ablak, ami a kézfogás alatti órajel-eltérésre van méretezve, és semmi másra —, a permit-pty kiterjesztést hordozza és semmi többet, és sosem íródik lemezre. Sem a kulcs, sem a tanúsítvány nem kerül soha az operátor kezébe.

Egy szolgáltatásfiók-hozzáférési tanúsítvány (isg ca issue --account <account> --host <host>) ennek a gépi megfelelője: alapból egy óra, vagy amennyit a ca.yaml service_accounts[].ttl_seconds mond arra a fiókra.

Egy megújítható identitás az az X.509 kliens-tanúsítvány, amit egy szolgáltatás-gép tart, hogy az ügynöke megújíthassa a hozzáférési tanúsítványokat a kölcsönös TLS-végponton. Egy egyszer használatos csatlakozási token beváltásával adódik ki (isg ca join-token redeem --token <token>; maga a token alapból tizenöt perc), és harminc napig él, hacsak a ca.yaml renewable_ttl_days-e mást nem mond. A privát kulcs a szolgáltatás-gépen generálódik, és sosem kerül át az átjáróra.

Egy hoszttanúsítvány (isg ca host-cert issue --host <host> --key <file>) az, amitől az átjáró fel tudja ismerni a célgépet. A célgép meglévő publikus hosztkulcsa fölé íródik alá — a CA a gép privát kulcsát sosem látja —, és alapból egy évig él (ca.yaml: host_cert_ttl). A célgép oldalán nincs megújító ügynök, tehát itt a modell a hosszú élettartam plusz a visszavonás, nem a rövid életű rotáció.

Az egész mögött álló aláírót a ca.yaml signer kulcsa választja ki: builtin, ami az átjárón nyitja meg a CA privát kulcsát, vagy vault, ami az aláírást az OpenBaóra delegálja, és lokális kulcsot egyáltalán nem nyit meg. Az átjáró saját TLS-kiszolgáló-tanúsítványai — az admin felülethez és a megújítási végponthoz — ugyanabból a CA-ból származnak, és kilencven napig élnek.

Hogy mi történik lejáratkor, az hitelesítő adatonként más, és az egyik eset meglepetést szokott okozni. Az SSH kizárólag a kézfogás alatt nézi meg egy tanúsítvány érvényességét. Az a munkamenet tehát, amelyik a tíz perces ablakán belül kapcsolódott, utána korlátlanul tovább működik; nincs megújítás és nincs munkamenet-közbeni újrakiadás, tervezetten. Egy ember elvágásának a kara a következő kiadás megtagadása — ezt teszik a hozzáférési kapuk —, nem egy már használatban lévő tanúsítvány érvénytelenítése. A hosszú életű hitelesítő adatoknál ez fordítva van: az isg ca revoke --account <account> és az isg ca host-cert revoke egy sorszámot tesz az átjáró visszavonási listájára, amit minden megújítási kérésnél és minden tárcsázásnál megnéz, elavulni képes gyorsítótár nélkül.

Az ábra szétválasztja azt, amit a fenti bekezdések szükségszerűen összefolyatnak. A bal oszlop egyetlen kapcsoló és mindaz, ami alatta van. A jobb oszlop egy olyan hitelesítésszolgáltató, amit ez a kapcsoló soha nem mozdít — ezért van az, hogy egy OpenBaón keresztül aláíró átjáró is tart saját privát kulcsot a lemezén. A szaggatott sáv egy harmadik CA, és azért van mindkét oszlopon kívül rajzolva, mert ott is él: egy olyan gépen, amit ez az átjáró nem ér el, és amelynek az aláírásait soha nem állítja elő.

Adatok nyugalomban

Minden, amit az átjáró perzisztál, egyetlen könyvtár alatt él: az $ISG_HOME alatt, ami a rendszerszolgáltatás-elrendezésben a /var/lib/isg. A konfiguráció és az állapot ezen osztozik. Minden konfigurációs fájl opcionális — a fájl nélküli állapotgyökér érvényes első-futás állapot —, és minden betöltő maga definiálja, mit jelent a saját fájlja hiánya. A konfigurációs referencia minden fájlt és bennük minden kulcsot felsorol.

Az állapot, szemben a konfigurációval:

Egy kind: form fiók upstream munkamenet-sütijei szándékosan nincsenek ezen a listán: csak az átjáró memóriájában élnek, alkalmazás-munkamenetenként, és egy újraindulás vagy egy másik átjáróra kerülés után az átjáró újra belép.

Hogy ezek közül melyik hagyja el a könyvtárat egy közös tár felé, és melyik soha, azt a Több átjáró üzemeltetése alatti tábla mondja ki. A retention.yaml bekapcsol egy időszakos söprést, ami törli a lejárt artifactokat — 24 óránként, hacsak a sweep.interval mást nem mond, és teljesen kikapcsolva, hacsak a sweep.enabled nincs beállítva. Hogy a flottában mely átjárók élnek, az egy rekord a közös tárban, és az isg system brokers az, ami olvassa.

Az auditnapló mindennek a kivétele. Sosem söpri semmi, sosem íródik újra és sosem kerül máshová: szerződés szerint csak hozzáfűzhető, a szerződést pedig — egy sor JSON-alakját, a fájl módját, azt a rotálási viselkedést, amit egy begyűjtő ügynöknek el kell viselnie — az auditnapló-séma írja le.

Fail-closed posztúra

Az átjáró inkább nem indul el, mint hogy olyan állapotban induljon el, ami helyesnek látszik, de nem az. Ez tudatos csere: az elutasítást látja az az operátor, aki az újraindítást végzi, míg egy csendben kikapcsolt kontrollt addig senki nem lát, amíg nem számít.

Az isg serve nem jön fel, ha:

• egy konfigurációs fájlban olyan felső szintű kulcs van, amit nem ismer. Bármelyik regisztrált fájlban, minden más megnyitása előtt ellenőrizve, kimenekülő kapcsoló nélkül. Egy elgépelt kulcs, amit csendben figyelmen kívül hagyna, olyan átjárót eredményezne, ami tisztán elindul, és mást kényszerít ki, mint amit a fájl mond.
• a retention.yaml nem értelmezhető. Az a megőrzési szabály, amit senki nem tud elolvasni, rosszabb, mintha nem lenne szabály, mert úgy néz ki, mintha lenne.
• egy másik daemon már birtokolja az állapotgyökeret. Két daemon egy könyvtár fölött nem rontja el egymás rekordjait; a második csendben eldobja az első munkameneteit. A bérlet az, ami ezt megelőzi, és az isg system lease status az, ami megmagyarázza az elutasítást.
• egy névtelen átjáró olyan tárhoz próbál csatlakozni, amit egy másik átjáró használ. Egy broker.yaml id nélküli átjáró rekordjai utólag nem különböztethetők meg a társaiétól, és a közös tár pontosan az a hely, ahol ez számít.
• egy átjáró nevezett és PostgreSQL-t használ, de OpenBaót nem. A ca.yaml signer-je és az mfa.yaml store-ja is vault kell legyen ebben az elrendezésben. Az üzenet egyszerre nevezi meg az összes sértést — a fájlt, a jelenlegi értéket, a megköveteltet és az okot —, nem újraindításonként egyet. Hogy egyébként mi romlik el, azt a Több átjáró üzemeltetése mondja el.
• az auditnapló nem nyitható meg, vagy az audit.yaml nem értelmezhető.
• egy megnevezett háttértár nem építhető fel. Az a records.backend vagy recordings.backend, amit az ISG nem tud megkonstruálni, elutasítás, nem csendes visszaesés lokális tárolásra — az az elkülönítés, amit az operátor kért, vagy létezik, vagy az átjáró kimondja.
• az mfa.yaml nem létező módot nevez meg, vagy a többfaktoros titok-tár nem építhető fel.
• a connect.yaml ismeretlen host_key_check értéket nevez meg. Megengedő beállításra való visszaesés nincs.
• nem-loopback --bind-ot kérnek hitelesítés nélkül vagy TLS nélkül. A kettő együtt kötelező; bármelyik hiánya olyan elutasítás, ami megnevezi, mi hiányzik.

További két eset kérésidejű elutasítás, nem indulási. Ha egy kért --as principal címtár-lekérdezése infrastrukturális okból hiúsul meg — nem „nincs ilyen felhasználó", ami túlélhető —, a daemon megtagadja a munkamenetet, ahelyett hogy üres csoporttagságokkal folytatná, és abban reménykedne, hogy valamelyik szabály átengedi. A break-glass pedig, az a mechanizmus, ami megkerüli a négy szem elvének kapuját, mindenkitől meg van tagadva, ha nincs breakglass_group konfigurálva; nincs olyan olvasata a „nincs beállítva"-nak, amitől megengedő lenne.

Két dolog nem végzetes. Az első az inicializálatlan CA: a daemon elindul, kimondja, és nem nyitja meg a megújítási végpontot; a CA-adminisztrációs műveletek addig maradnak elérhetetlenek, amíg az isg ca init le nem futott. A második az induláskor elérhetetlen identity provider: a daemon SSO nélkül indul — a jelszó-űrlap web: required mellett is megmarad —, és az isg system check SSO (OIDC) sora ezt mondja, amíg a provider vissza nem tér. Hogy bárki beléphet-e egy futó átjáróba, az nem múlhat azon, hogy egy JSON-dokumentum letölthető-e.