Inshipia Security Gateway

Web Access-policy

Ki ér el egy webes konzolt az ISG-n át, és mit tehetnek a kérései. Hogy egy kérés milyen úton jár, az hogyan működik a Web Access lapon áll; az itteni szabályok identitásai és csoportjai az identitások, csoportok és zárolás lapon.

Ki ér el egy alkalmazást

A Web Access (apps.yaml, az alkalmazások beállítása szerint) ugyanazokat az identitásokat és csoportokat alkalmazza egy webes konzolra. A belépés a webUI-é: jelszó és második faktor, vagy SSO. Minden alkalmazásnak azonosítója van (APP-2026-000001); a jóváhagyás, a munkamenet, a zár és az audit-sor ehhez az azonosítóhoz tartozik, nem a névhez, így két azonos nevű alkalmazás sosem osztozik rajtuk. A felületek a barátságos nevet mutatják, utána az azonosítót. Utána alkalmazásonként:

Előbb a csoport: allow_groups

Aki a felsorolt csoportok egyikében sincs, azt elutasítja (APP_ACCESS_DENIED); nincs olyan alkalmazás, ami minden belépett felhasználónak nyitott.

Mit tud meg az alkalmazás a felhasználóról

Semmit, egy aláírt assertiont, vagy egy közös fiók titkát — lásd alkalmazások beállítása.

Jóváhagyás, időablakként

A require_approval mellett a felhasználó időtartamot kér (legfeljebb approval_max_grant_seconds, alapból 14400), és valaki más dönt róla a webUI-n — a saját kérelmét senki nem hagyhatja jóvá. A függő kérelem approval_timeout_seconds (alapból 300) után lejár. Az ablak a döntéskor nyílik; azon belül az alkalmazás újra megnyitható, a végén az alkalmazás-munkamenet is zárul. Az approval_single_use az első megnyitással elfogyasztja a jóváhagyást.

Önkiszolgáló hozzáférés indoklással

Az approval_mode: self mellett (alapból four_eyes) senki nem dönt: a felhasználó kiválasztja az időtartamot, megírja az indoklást, és az ablak azonnal nyílik. Az indoklás ilyenkor kötelező — legalább approval_reason_min_len karakter (alapból 10, legalább 1), és ha az approval_reason_pattern meg van adva, egy részének illeszkednie kell erre az RE2-mintára (keresés, nem teljes egyezés: ahhoz ^…$ kell). Ugyanez a két kulcs a négy-szem kérelem indoklását is kötelezővé teszi. A megadás egyetlen COMMAND_APPROVAL_GRANTED audit-sor approval_mode: self értékkel; az indoklás szövege nem kerül se az auditba, se a ticketbe, az utóbbi csak annyit mond, hogy a hozzáférés önkiszolgáló volt. Az ablak, az approval_single_use, az adminisztrátori lezárás és az ablak vége úgy működik, mint egy jóváhagyott kérelemnél; az ennél régebbi bróker a kulcsot nem ismeri, és helyette négy-szem jóváhagyást kér.

Mit tehet egy-egy kérés

Kérés-szintű szabályok

A policy.yaml http_rules szabályai alkalmazás, metódus, útvonal és szerep szerint ítélnek meg egy kérést. A szabály akciója deny (alapérték), step_up vagy allow; az illeszkedő szabályok közül a deny győz a step_up felett, a step_up az allow felett, a fájlbeli sorrendtől függetlenül, így egy korán írt, tág engedély nem írhat felül egy későbbi tiltást. A tiltott kérés 403-at kap (APP_REQUEST_DENIED); az alkalmazás meg sem kapja, a munkamenet megmarad. A szabály a WebSocketet felépítő kérést látja, a kereteket nem, és a kérés törzsében kódolt műveletet sem. Az ISG saját útjait (/_isg/) és az alkalmazás logout_paths útjait szabály nem ítéli meg.

Friss második faktor egy érzékeny útvonalon

Az action: step_up szabály (a kötelező valid_for-ral, 1m és 60m között) addig tartja vissza az illeszkedő kérést, amíg a felhasználó újra meg nem erősíti a második faktort: az oldalbetöltés a webes felületre kerül, amely a webes felület mfa_mode-ja szerinti kódot kéri — a hitelesítő alkalmazásét (vagy egy helyreállító kódot), illetve egy e-mailben küldöttet —, SSO-val belépett felhasználótól is. Utána az alkalmazás-munkamenet valid_for ideig átengedi a szabály kéréseit, de a munkamenet saját végén túl soha. A nem oldalbetöltő kérés (űrlapküldés, API-hívás, WebSocket-felépítés) 403-at kap a megerősítés címével, az X-ISG-Step-Up fejlécben is: a böngészőben kell megerősíteni, utána megismételni a műveletet. A megerősítés után nyitott WebSocketet a lejárat nem bontja. Akinek nincs használható faktora (mfa_mode: totp mellett nincs hitelesítő alkalmazása, email mellett nincs e-mail-címe), azt érthető üzenettel elutasítja, beiratkozásba nem viszi. Az audit APP_STEP_UP_REQUIRED, APP_STEP_UP_OK és APP_STEP_UP_FAILED sort ír. allow módban a step_up szabály a kéréseit engedélyezettnek is jelöli.

Engedélylista-mód, próbamóddal

A http_app_modes egy alkalmazást allow módba tesz: csak az a kérés megy át, amire allow szabály illik (és deny nem), minden más 403, http_mode:allow szabálynévvel. Az allow_audit mód a próbafutás: ugyanazok a kérések átmennek, de mindegyik APP_REQUEST_WOULD_DENY auditsort ír — ez az alkalmazás azon statikus fájljainak és API-hívásainak listája, amelyeket az engedélyek még nem fednek le. Egy alkalmazás allow_audit-tal induljon, és akkor váltson allow-ra, ha az audit elcsendesedett. Az isg system check figyelmeztet, ha egy allow módú alkalmazást egyetlen engedély sem nevez meg: minden kérése 403 lenne.

Feltételek

A szabály when blokkja a hét napjaira, napszakra (a vég kizárólagos, az ablak átnyúlhat éjfélen), dátumtartományra (mindkét vég benne van) és kliens-hálózatokra (CIDR, IPv4 és IPv6) szűkíti; a megadott feltételeknek mind teljesülniük kell. A napot és az órát a policy timezone kulcsa szerint olvassuk (alapból Europe/Budapest). A kliens címe a kapcsolat saját címe: az átjáró keepalived-cím mögött áll, nem proxy mögött. Egy élő WebSocketet nem bont, ha közben bezárul az ablak.

Előbb minden bróker frissüljön

Egy régi bróker az allow és a step_up szabályt tiltásnak olvassa, a when-t figyelmen kívül hagyja (mind szigorúbb), a http_app_modes-t viszont nem ismeri, így ott az engedélylista nem hat. Kivétel: a v0.547.0 az allow-t ismeri, a step_up-ot viszont betöltési hibának veszi, így egy v0.547.0-s brókeren egy step_up szabály az egész policy.yaml-t betölthetetlenné teszi, és ott minden Web Access-kérés 503 — step_up szabály csak akkor kerüljön be, ha már minden bróker v0.548.0 vagy újabb. Engedélylista csak akkor kerüljön a policy.yaml-ba, ha már minden bróker olyan változatot futtat, amely ismeri.

Mi kerül a felvételbe

Minden kérés

Minden kérés egy sor a munkamenet transcriptjében: metódus, útvonal, státusz, méret, idő — törzs alapból nem. A query-paraméterekből csak a nevek, hacsak az alkalmazás nem állítja be a record_query-t.

Kérés-törzsek, bekapcsolásra

Egy apps.yaml-beli (nem dinamikus) alkalmazás record_body: true mellett a POST, PUT, PATCH és DELETE kérései törzsét is a sorba teszi — csak amit az alkalmazás ténylegesen beolvasott, legfeljebb record_body_max_bytes bájtot (alap 4096, 256-tól 65536-ig), a teljes méretet mindig. Az elutasított kérés törzsét és a WebSocket-felépítést soha nem olvassuk. A törzs írás előtt maszkolódik, és a maszkolás nem kapcsolható ki: form- és JSON-törzsben minden olyan mező értéke ***, amelynek a nevében szerepel a password, passwd, pwd, secret, token, api_key, apikey, auth, authorization, credential, private_key, session, cookie, otp vagy totp (kis/nagybetűtől függetlenül; a record_body_mask_fields neveket ad hozzá, elvenni nem tud), és minden rögzített értékben a Bearer- és Basic-hitelesítő, a JWT és a PEM privát kulcs *** lesz. A multipart törzsből csak a részek neve, fájlneve és mérete látszik, minden más típusból csak a típus és a méret. Az elemezhetetlen törzs jelölést kap, a felvétel nem marad ki miatta. A törzs a transcriptben él, így pontosan úgy őrződik meg és archiválódik, mint a transcript (retention.yaml transcripts), és aki ma olvassa a transcriptet, ezt is olvassa. A törzs személyes adatot is hordozhat, és egy WORM-archívumban a maszkolás által elvétett érték utólag nem javítható — csak olyan alkalmazásnál kapcsold be, amelynek a módosításait az auditnak látnia kell.

Hogyan ér véget egy munkamenet, és ki kezeli az alkalmazásokat

Hogyan ér véget

A webUI-ból kilépés, a csoport elvesztése vagy egy adminisztrátor zárása minden brókeren lezárja az alkalmazás-munkamenetet, a kiszolgáló brókeren kb. 5 s alatt.

Ki kezeli az alkalmazásokat

Ha a dynamic_apps_domain be van állítva, a session_admin_group-kapun átjutó adminisztrátor a webUI Appok kezelése oldalán (/apps/manage) alkalmazásokat vesz fel, módosít és töröl; az auditor látja a listát, de írni nem tud, az elutasított írás SESSION_ADMIN_DENIED auditsort ír. Az apps.yaml alkalmazásai ott nem módosíthatók. A mentés megnevezi, ami hatástalan: a jóváhagyás nélkül kitöltött jóváhagyási mezőket nem menti, és szól a nem létező vagy tag nélküli csoportról; a mentés mindkét esetben megtörténik. A csoportok változása a következő kérésnél hat; egy alkalmazás törlése lezárja a munkameneteit (ok: app_deleted). Az auditnapló APP_CREATED, APP_UPDATED (a régi és az új csoportokkal, jóváhagyással és szinttel) és APP_DELETED sort ír.