Jogosultság — ki mit tehet, és hogyan bizonyíthatja

A Control Center két jogosultsági kérdésre ad választ, és ez a kettő valóban különbözik. A „Meghívhatja ez a személy ezt a műveletet?” az emberekről, a szerepekről és a repókról szól. A „Kiválthatja ez az ügynök ezt a hatást?” a műveletekről, az argumentumokról és a hatássugárról szól — ez utóbbi a Korlátok témája.

Ez az oldal az első kérdéssel foglalkozik, valamint azzal a nyommal, amelyet mindkettő maga után hagy.

Egyetlen döntési pont

Minden emberi oldali jogosultsági döntés egyetlen függvényen keresztül oldódik meg:

can(principal, permission, resource) → allow | deny + why

Egy engedély <domain>:<tier> alakú — tickets:write, members:administer, repos:read. A katalógus származtatott, nem kézzel írt: magából a műveletfelületből számítjuk ki (a művelet nevének előtagja adja a domaint, a már érvényesített szerepminimum adja a szintet), így mind a ~550 művelet rendelkezik engedéllyel anélkül, hogy bárkinek be kellene gépelnie egyet.

Ez a származtatás az a tulajdonság, amelyet érdemes megvédeni. Azt jelenti, hogy egy ÚJ művelet alapértelmezés szerint kapu mögé kerül — a kézzel annotált modell hibaesete az, hogy valaki elfelejti, és amit elfelejt, az épp a kapu. Egy racsnis teszt rögzíti a kapott domainhalmazt, így egy új előtag alá tartozó művelet hozzáadása emberi elnevezési döntés, nem baleset.

A négy szint pontosan megfelel a beépített szerepeknek:

Szint	Minimális szerep	Példa
read	Vendég	tickets:read
write	Tag	tickets:write
administer	Admin	members:administer
own	Tulajdonos	workspace:own

Szerepek

Öt beépített szerep — Tulajdonos, Admin, Tag, Megtekintő, Vendég — előbeállítás e katalógus felett. A tulajdonjog munkaterületenként egyetlen hely, amelyet kifejezetten a Tulajdonjog átadása funkcióval adnak át (a távozó tulajdonos egyébként eltávolíthatatlan: a SCIM-visszavonás minden munkaterület-tulajdonost megtagad — előbb adják át a tulajdonjogot).

Az egyéni szerepek kizárólag szűkítenek. Az egyéni szerep megnevez egy alapszintű előbeállítást (admin, member, viewer vagy guest — soha nem owner), valamint egy abból ELVETT engedélykészletet — „admin, de nem kezelheti a tagokat”. Soha nem adhat többet az alapjánál, és éppen ez teszi biztonságossá a bevezetésüket egy meglévő telepítésbe: minden meglévő ellenőrzés érvényes felső korlát marad. A tagok custom:<id> formában birtokolják ezeket, és egy olyan régi kliens, amely nem érti ezt az értéket, a vendég szerepre esik vissza, ahelyett hogy találgatna.

A szerepek alatt repónkénti hozzáférések állnak (none / read / review / write): a munkaterületi tagság soha nem biztosít csendben nagyobb jogosultságot, mint a kódhoszt. A kódot elérő felületek mindegyike ellenőrzi ezeket — azok is, amelyek oldalról érik el a kódot, például egy terminál vagy egy tér worktree-jére nyitott szerkesztő-munkamenet.

Szerverhatáskör

Egyes műveletek egyáltalán nem munkaterülethez kötődnek: telepítésszintű beállítások, SSO-konfiguráció, szolgáltatói hitelesítő adatok, modellek kezelése, a teljes telepítés mentései. Ezek szerverhatáskört deklarálnak, és mindenki számára elutasításra kerülnek, kivéve a telepítés üzemeltetőjét (a nyilvántartott szervertulajdonost). Szándékosan egyetlen üzemeltetői identitás és annak egyetlen definíciója létezik.

Az auditnapló

Minden jogosultsági döntés — az engedélyezés és az elutasítás is — egy munkaterületenkénti, hash-láncolt auditnaplóba kerül.

A csak elutasításokat tartalmazó napló megválaszolja, hogy „mit blokkoltunk?”, de azt nem, hogy „mit tett valójában ez az ügynök, és ki engedélyezte?”, pedig az incidensvizsgálat épp ezzel a kérdéssel kezdődik. Ezért minden bejegyzés rögzíti a teljes hozzárendelési láncot: a cselekvő szereplőt, az embert, akinek a nevében eljárt, a delegálást, amelyen keresztül érkezett, a műveletet és annak argumentumait (kivonat formájában), a döntést, valamint a döntést meghozó szabályt.

A bejegyzések láncot alkotnak: mindegyik hash-e lefedi az előzőét, így bármely sor szerkesztése, törlése vagy átrendezése megtöri az összes utána következő hash-t. A Lánc ellenőrzése újraszámítja a teljes láncot, és megnevezi az első láncszemet, amely nem állja meg a próbát. Az az auditnapló, amelyet nem lehet ellenőrizni, csak napló; amelyet újra lehet számítani, az bizonyíték.

Két következmény, amelyet érdemes ismerni:

• Az auditnapló táblája mentes az életkoron alapuló törlés alól. A hash-lánc nem csonkítható középen. A megőrzés exportálásból, majd csonkításból áll, és a csonkítás olyan ellenőrzőpontot hagy hátra, amely az eltávolított szakasz záró hash-ét hordozza, így a megmaradó rész továbbra is visszaigazolható egészen az elejéig.
• Az auditnapló a tevékenységi idővonal mellett helyezkedik el, nem afölött. Az idővonal azt mutatja, amit az emberek tettek; ez pedig azt, amit engedélyeztek és elutasítottak. Egy közös korrelációs azonosítóval ugyanaz a hívás mindkettőben visszakereshető.

Újsorokkal tagolt JSON formátumban exportálható, és streamelhető SIEM-rendszerbe (Splunk, Elastic, Sentinel — HTTP-végpont bearer tokennel). A streamelés szándékosan nem garantált: egy elérhetetlen SIEM soha nem akadályozhatja meg egy ügynök eszközhívását, a tartós és ellenőrizhető másolat pedig így is a lemezen van.

Munkamenetek

Egy telepítés beállíthat maximális munkamenet-élettartamot és inaktivitási időtúllépést. Mindkettő azon az eszközhitelesítő-ellenőrzésen érvényesül, amelyen minden hitelesített útvonal átfut — az olyan munkamenet-korlát, amelyet a kliens figyelmen kívül hagyhat, egy kérdőívre ad választ, nem egy támadóra. Egy telepítés az SSO-t is megkövetelheti, ami letiltja az új eszközök kézi párosítását (kizárás elleni védelemmel: mindaddig megtagadja, amíg nem létezik működő SSO-kapcsolat).

Mi ez nem

• Nem objektumszintű ACL-ek. Szándékosan nincs jegyenkénti vagy üzenetenkénti engedély. A repószintű elkülönítés az, amit a csapatok valóban kérnek, és létezik; az objektumszintű megosztás kombinatorikus felület, amelyre itt nincs bizonyított igény.
• Nem DSL-ben konfigurálható szabályzatmotor. A szókészlet szándékosan zárt, így a teljes szabályzat megjeleníthető, elmagyarázható és felsorolható.
• Nem érvényesül máshol, csak a szerveren. A kliensoldali ellenőrzések csak azt szolgálják, hogy ne kínáljunk fel olyan vezérlőt, amelyet úgyis elutasítanak. A mérvadó döntés mindig a szerveré.