Izolált böngésző

Egy apps.yaml-beli mode: isolated alkalmazás nem a felhasználó saját böngészőjében nyílik meg. A felhasználónak egy böngésző fut egy dedikált RBI-hoszton (az isg_rbi csoport), egy hálózat nélküli konténerben, és a felhasználó böngészője csak a képét kapja meg. A Web Access többi része változatlan: a kérés-szintű audit, a http_rules, a kind: form belépés és a bróker által tartott sütik. Hogy egy kérés milyen úton jár, az hogyan működik a Web Access lapon áll, egy alkalmazás beállítása az alkalmazások beállítása lapon.

Amit a felhasználó lát

Az alkalmazás a saját hosztnevén, a /_isg/rbi/view alatt nyílik meg. A lap a távoli böngésző képét mutatja, és továbbítja az egeret és a billentyűzetet. A vágólap mindkét irányban tiltott. A távoli böngésző felügyelt policyja tiltja a letöltést, a fájlválasztót, a nyomtatást, a fejlesztői eszközöket és a jelszókezelőt.

A távoli kijelző követi a felhasználó ablakának méretét: a távoli böngésző kitölti, és a vízjel a sarkaiban marad.

A kép fölötti sávban teljes képernyő gomb áll: a teljes nézetet teljes képernyőre kapcsolja, és vissza. Az F11, a böngésző saját teljes képernyője is működik: ez a billentyű a felhasználó böngészőjénél marad, a távoli böngészőhöz nem jut el.

A kép két sarkában vízjel áll: a felhasználó, az alkalmazás és a pontos idő, percenként frissítve. A távoli kijelzőre rajzolódik, így a felvételben is benne van, és a felhasználó a saját böngészőjéből nem tudja eltüntetni.

Hogyan fut egy munkamenet

• A felhasználót kiszolgáló bróker a legkevésbé terhelt élő agenten indítja a munkamenetet (isg rbi-agent run minden RBI-hoszton, ami mTLS-sel kérdezi a brókereket), és legfeljebb session_start_timeout_seconds ideig vár rá.
• A konténer egyetlen kifelé vezető útja egy munkamenetenkénti socket. Az agent minden rajta jövő kapcsolatot a munkamenetet birtokló brókerhez visz, és a kérést a bróker saját app-proxyja küldi az upstreamre. A policy, a jóváhagyás, a ticket és a kérésnapló így ugyanaz, mint egy közönséges Web Access-munkamenetnél.
• Ha a felhasználó bezárja a lapot, a böngésző még viewer_grace_seconds ideig fut (alapból 300; az alkalmazás saját, apps.yaml-beli viewer_grace_seconds-a felülírja, egy RDP-alkalmazás pedig 60 másodpercig vár). Aki ezen belül visszatér (újratöltés, megszakadt kapcsolat után), ugyanazt a böngészőt kapja. Utána a böngésző leáll, és vele együtt az app-munkamenet is véget ér (APP_RBI_SESSION_CLOSED, ok: viewer_gone). Az alkalmazás újranyitása új munkamenet; egy jóváhagyás-köteles alkalmazás újra jóváhagyást kér.
• Ha egy RBI-hoszt agent_stale_seconds ideig nem kérdez, a munkamenetei véget érnek (ok: agent_lost). Egy munkamenet nem költözik át másik hosztra.

Második faktor egy kérésre

Egy step_up szabály izolált alkalmazáson is működik. A távoli böngésző nem éri el a webUI-t, ezért a megerősítés a felhasználó saját böngészőjében történik: a távoli lap kiírja, hogy megerősítés kell, a nézet tetején megjelenik egy sáv, és a gombja a szokásos step-upot indítja. Utána a távoli lap magától újratöltődik, és a kérés átmegy. Az audit-sor APP_STEP_UP_REQUIRED, ahogy bármely más alkalmazásnál.

Felvétel

Minden izolált munkamenet képként rögzül, abban a Guacamole-formátumban, amit az RBI-hoszt ír. A billentyűleütések nem rögzülnek. Amikor a böngésző leáll, az agent elküldi a felvételt a munkamenetet birtokló brókernek, ami a munkamenet felvételeként tartja meg (APP_RBI_RECORDING_STORED). Innen úgy halad, mint egy terminál-felvétel: a felvétel-tárba archiválódik, ugyanaz a retention-szabály tartja meg és törli, és az isg storage verify ellenőrzi. Az RBI-hoszton nincs tároló-hozzáférés. Egy bróker-újraindítás vagy egy megszakadt feltöltés után az agent újrapróbája ugyanabba a felvételbe ér, egyszer.

A felvétel a webUI munkamenet-lapján játszható le, egy adminisztrátornak vagy a munkamenet gazdájának. Munkamenetenként legfeljebb recording_max_mb (alapból 2048) lehet.

Élő nézet és megszakítás

Egy adminisztrátor, aki munkamenetet zárhat, egy futó izolált munkamenetet a /sessions/live alatt nézhet, a munkamenet-táblából elérve. A nézet csak olvasható: a néző egere és billentyűzete nem jut el a távoli böngészőig. Azon a brókeren működik, amelyik a munkamenetet futtatja; egy másik bróker webUI-ja megmondja, hol fut. Minden nézés egy audit-sor (APP_RBI_LIVE_VIEW_STARTED és a vége). Ha ugyanabból a táblából lezárod a munkamenetet, a távoli böngésző is leáll.

Beállítás

• apps.yaml: mode: isolated az alkalmazáson.
• rbi.yaml a brókereken (lásd rbi.example.yaml): az agentek, a CA-fájlok, a fenti időzítések és a recording_max_mb. Az Ansible config-forrás akkor írja, ha az inventoryban van isg_rbi csoport.
• rbi-agent.yaml minden RBI-hoszton (lásd rbi-agent.example.yaml): a brókerek, az identitás, a recordings_dir és a munkamenetenkénti korlátok. Az isg_rbi role írja, és lépteti be az agentet.

Egy 4 vCPU-s, 8 GB-os RBI-hoszton mérve: egy konzol-jellegű lap munkamenetenként kb. 250 MB-ot és néhány százalék CPU-t használ, így a memória szab határt, kb. 25 munkamenetnél; egy videó-szerű lap egy mag nagy részét viszi, így a CPU szab határt, egy-két munkamenetnél.

Ami az izolált böngésző nem

• Nem rögzíti a billentyűleütéseket, és nem exportál videófájlt: a lejátszás a webUI-ban van.
• Nem visz fájlt egyik irányban sem, és nincs vágólapja.
• Nem éli túl az RBI-hosztja kiesését: a munkamenet véget ér.