Entity-based RBAC v GLPI: oddelenie prístupov medzi tímami a klientmi

GLPI rieši dva problémy prístupu súčasne. Profily hovoria, čo používateľ smie robiť — vytvárať tikety, schvaľovať zmeny, upravovať aktíva. Entity hovoria, kde to smie robiť — v ktorej organizačnej jednotke, oddelení alebo dokonca u ktorého klienta. Bez entít všetci používatelia vidia všetky tikety a všetky aktíva. Tento článok predpokladá znalosť základov profilov; ak ich nepoznáte, začnite s profilmi a oprávneniami v GLPI.

Kedy entity dávajú zmysel

Tri typické scenáre, kde sú entity nevyhnutné:

• Veľká organizácia s autonómnymi oddeleniami — IT bratislavskej pobočky nemá vidieť tikety pražskej pobočky. Každý prevádzkuje svoj helpdesk, ale využíva tú istú GLPI inštanciu.
• MSP, ktorý obsluhuje viacero klientov — váš tím prevádzkuje GLPI pre desať rôznych klientov. Klient A nesmie vidieť tikety klienta B, ale váš servisný tím vidí všetkých.
• Holdingová štruktúra — materská firma vidí dáta dcérskych spoločností pre konsolidovaný reporting, dcérske spoločnosti len svoje vlastné dáta.

Hierarchia entít

Entity v GLPI tvoria strom. Koreňová entita (Root entity) je vždy na vrchu. Pod ňou vytvárate ľubovoľne hlbokú hierarchiu:

Root entity
├── Bratislava
│   ├── IT
│   └── HR
├── Praha
│   ├── IT
│   └── HR
└── Klienti
    ├── Klient A
    └── Klient B

Tikety, aktíva, používatelia a takmer každý objekt v GLPI patria do konkrétnej entity. Tým je jasne dané, kto ich vidí.

Rekurzívne vs. nerekurzívne práva

Toto je najčastejší zdroj zmätku. Pri priradení profilu používateľovi v entite si vyberáte, či má profil pôsobiť rekurzívne (aj v podriadených entitách) alebo nie.

Príklad: regional manager v Bratislave má profil Manažér priradený v entite "Bratislava" rekurzívne. Vidí tikety v "Bratislava", "Bratislava → IT" aj "Bratislava → HR". Naopak, helpdesk technik má profil Technik v "Bratislava → IT" nerekurzívne — vidí len tikety IT oddelenia, nie HR.

Praktické pravidlo: rekurzívne práva pre vedúcich a manažérov, nerekurzívne pre špecialistov.

Jeden používateľ, viacero rolí

Ten istý používateľ môže mať rôzne profily v rôznych entitách. Toto je výkonné, ale často prehliadané:

• Mária je Vedúca tímu vo svojej domovskej entite "Bratislava → IT".
• Mária je zároveň Pozorovateľ s len-na-čítanie prístupom v "Praha → IT" — potrebuje vidieť tamojšie tikety na koordináciu, ale nesmie ich upravovať.
• Mária nemá žiadny prístup do "Klienti" — externé tikety ju netrápia.

Pri prihlásení si Mária vyberá, v ktorej entite práve pracuje. GLPI uplatňuje profil zodpovedajúci tejto entite.

MSP scenár v praxi

Najčastejšie nasadenie entít v multi-tenant prostredí vyzerá takto:

1. Vytvorte podentity pre každého klienta pod dedikovanou entitou "Klienti" (napríklad "Klienti → ABC s.r.o.").
2. Používateľov klienta (žiadateľov) priraďte do ich klientskej entity s profilom Self-Service. Vidia len svoje vlastné tikety.
3. Váš servisný tím dostane profil Technik v entite "Klienti" rekurzívne — vidí tikety všetkých klientov.
4. V Setup → Mail collectors nastavte mapovanie podľa cieľovej e-mailovej adresy: tikety prichádzajúce na klient-abc@vas-helpdesk.sk automaticky padnú do entity "Klienti → ABC s.r.o.".
5. SLA, kategórie a šablóny tiketov je možné definovať per-entita — každý klient má svoje vlastné podľa zmluvy.

Dynamické priradenie cez LDAP

Pri nasadení s LDAP alebo Active Directory nemusíte priraďovať entity manuálne. V Setup → Authentication → LDAP directories definujete LDAP atribút (napríklad department alebo memberOf) a v Administration → Rules → Rules for assigning a user to an entity namapujete jeho hodnoty na konkrétne entity GLPI.

Príklad: ak memberOf=CN=IT-Bratislava,..., používateľa priradiť do "Bratislava → IT" s profilom Technik. Pri ďalšom prihlásení sa pravidlo uplatní automaticky bez zásahu administrátora.

Časté chyby

Príliš plytká hierarchia

Začínate s "Bratislava" a "Praha", o rok pridáte "Brno", "Košice", "Klienti", "Externí dodávatelia" — a zistíte, že potrebujete poddelenia. Plánujte štruktúru entít aspoň o úroveň hlbšie, než dnes potrebujete; pridať podentitu neskôr je jednoduché, ale presúvať tikety medzi entitami je manuálna práca.

Zabudnutá rekurzia

Manažér s nerekurzívnymi právami vo vrchnej entite vidí len tikety priradené priamo k nej, nie k podentitám. Po reštrukturalizácii sa to zabudne aktualizovať a manažér prestane vidieť dáta svojho tímu — typicky to vyjde najavo až pri prvom report-meetingu.

Klient vidí klienta

Najhorší prípad pre MSP. Pri zlej konfigurácii rekurzie môže používateľ klienta A vidieť tikety klienta B. Vždy testujte z pohľadu používateľa cez tlačidlo Test v profile alebo prihlásením sa pod testovacím účtom — nikdy nespúšťajte multi-tenant produkciu bez tejto kontroly.

Kedy entity nestačia

Entity oddeľujú dáta, ale neoddeľujú konfiguráciu. Pluginy, business rules a niektoré globálne nastavenia platia naprieč všetkými entitami. Ak potrebujete úplne izolované prostredia (napríklad regulačne oddelené dáta zdravotnej a finančnej časti firmy), zvážte oddelené GLPI inštancie namiesto multi-tenant nasadenia v jednej.

Pre väčšinu organizácií je entity-based RBAC dostatočný — kombinácia entít, rekurzívnych práv a per-entitných profilov rieši typické prístupové scenáre, ktoré v praxi stretnete.