Skryť maržu v karte zákazky nestačí, ak ju ten istý používateľ získa cez export alebo AI asistenta. Prístup k údajom dnes vedie cez viac ciest: obrazovky, mobilné aplikácie, integrácie aj chat.
Oprávnenia preto patria k samotným pravidlám systému. Majú vyjadrovať, čo človek potrebuje pre svoju prácu, ktoré záznamy vidí a aké zmeny smie vykonať. Názov roly „manažér“ tieto otázky sám nezodpovie.
Kde sa musí kontrolovať požiadavka
- Používateľ alebo AI klient Identita človeka a požadovaná akcia
- API alebo MCP nástroj Overí, komu požiadavka patrí
- Pravidlá prístupu Rola, záznam, polia a aktuálny stav
- Dáta a operácie Vrátia iba povolené údaje alebo vykonajú povolenú zmenu
Štyri otázky za každým oprávnením
Prvé rozhodnutie je o funkcii: kto smie vytvoriť zákazku, schváliť zľavu alebo meniť používateľov. Druhé je o zázname: ktoré zákazky daný človek vidí. Tretie je o poli: či vidí aj maržu alebo internú poznámku.
Štvrté rozhodnutie závisí od stavu. Technik môže dopĺňať rozpracovaný výkaz, ale uzavretý výkaz sa opravuje cez kontrolovaný postup. Vedúci môže schváliť ponuku, pokiaľ ešte nebola nahradená novou verziou.
Tieto rozdiely majú oporu aj v bezpečnostných témach API. OWASP API Security Top 10 samostatne opisuje problémy autorizácie objektov, vlastností objektov a funkcií. Pri výbere preto žiadajte dôkaz pre každú úroveň, nie iba zoznam názvov rolí.
Čo všetko rozhoduje o povolenej akcii
| Príklad otázky | Hranica | |
|---|---|---|
| Funkcia | Smie schvaľovať zľavu? | Právomoc používateľa |
| Záznam | Patrí zákazka jeho pobočke? | Rozsah prístupu |
| Pole | Smie vidieť maržu? | Citlivá časť údajov |
| Stav | Je výkaz ešte rozpracovaný? | Povolený okamih zmeny |
Rola vychádza z práce, ktorú človek robí
Obchodník pripravuje ponuky a sleduje svojich zákazníkov. Na tieto úlohy nepotrebuje automaticky export všetkých pobočiek. Externému technikovi môže stačiť adresa a výkres bez celej obchodnej komunikácie.
Rozsah údajov má zodpovedať zodpovednosti. Vďaka tomu sa oprávnenia dajú vysvetliť ľuďom a overiť na konkrétnej zákazke.
Výnimkou býva zastupovanie. Dočasný prístup potrebuje začiatok, koniec a človeka, ktorý zaň zodpovedá. Trvalé rozširovanie roly pri každej dovolenke postupne odstráni hranice, ktoré firma pôvodne chcela zachovať.
Ochrana musí platiť aj mimo obrazovky
Rozhranie môže skryť údaj alebo tlačidlo, no o prístupe rozhoduje server pri samotnej požiadavke. Rovnaký záznam môže totiž otvárať mobilná aplikácia, export alebo integrácia.
Preto dobrá ukážka zahŕňa rovnakú zákazku pod rôznymi účtami aj priamy prístup k prílohe. Nestačí predpokladať, že používateľ nepozná adresu rozhrania.
Pri zmene pridelenia sa navyše mení okruh oprávnených ľudí. Systém musí mať jasné pravidlá pre ďalšie požiadavky, vyhľadávanie a čakajúce operácie. Už stiahnutý súbor tým však z počítača človeka automaticky nezmizne; aj táto hranica patrí k vysvetleniu návrhu.
AI asistent potrebuje vlastné hranice konania
Pri firemnom asistentovi sa pýtajte, pod akou identitou pracuje. Ak používa jeden účet s prístupom ku všetkému, technická integrácia môže obísť rozdelenie zodpovednosti medzi ľuďmi.
Navrhnite úzke nástroje podľa konkrétnych úloh. Vyhľadať vlastné zákazky, pripraviť koncept ponuky alebo načítať povolený výkaz sú zrozumiteľné oprávnenia. Všeobecná možnosť vykonať ľubovoľný dotaz sa posudzuje aj kontroluje oveľa ťažšie.
Oddelte čítanie, návrh a vykonanie zmeny. Asistent môže pripraviť zmenu termínu, ale systém musí pred zápisom overiť oprávnenie aj dostupnosť technika. Schválenie človekom nenahrádza kontrolu na serveri. Človek tiež nemôže schváliť operáciu, na ktorú nemá právo.
MCP opisuje spôsob prepojenia AI aplikácií s nástrojmi a zdrojmi. Tento účel uvádza oficiálny úvod. O vašich obchodných rolách však musíte rozhodnúť pri návrhu systému a konektora.
- Vy: Priprav zľavu pre môjho zákazníka a pošli novú ponuku.
- Volanie nástroja: Načítanie zákazníka a poslednej povolenej verzie ponuky
- Výsledok: Zákazník je priradený používateľovi. Odoslanie zmenenej ceny potrebuje schválenie vedúceho.
- AI: Pripravil som koncept. Návrh môžeš skontrolovať a poslať vedúcemu na schválenie.
- Ponuka sa neodoslala. Systém eviduje návrh aj dôvod požadovaného schválenia.
Schválenie potrebuje obsah a verziu
Vedúci potrebuje vedieť, ktorého zákazníka sa zmena týka, čo sa mení a aký bude následok. Pri odoslaní správy aj adresáta a konečný text. Samotné tlačidlo „Povoliť“ nestačí.
Ak kolega po schválení upraví cenu, vznikne iný návrh. Kontrola pred vykonaním má tento rozdiel zachytiť a podľa pravidiel vyžiadať nové posúdenie. Inak sa môže odoslať niečo, čo vedúci nikdy nevidel.
Uloženie konceptu a odoslanie zákazníkovi preto potrebujú odlišné podmienky. Vlastný systém ich vie navrhnúť podľa reálneho rozdelenia právomocí vo firme.
Schválenie platí pre konkrétnu verziu
- Návrh zmeny Pôvodná hodnota, nová hodnota a dôvod
- Oprávnený schvaľovateľ Potvrdí presný obsah a dôsledok
- Kontrola pred zápisom Práva, stav a verzia stále platia
- Zápis alebo zastavenie Pri neplatnej verzii vyžiadať nové posúdenie
Čakajúca úloha potrebuje aktuálne oprávnenie
Nie každá operácia vznikne kliknutím prihláseného človeka. Systém môže v noci zosynchronizovať zákazky alebo pripraviť ranný prehľad. Pri takýchto úlohách určite konkrétny účel, rozsah údajov a zodpovedného vlastníka.
Technický účet na načítanie stavov faktúr nepotrebuje meniť používateľov ani sťahovať všetky prílohy. Ak jeden integračný účet obsluhuje viac rôznych úloh, pýtajte sa, ako sa ich oprávnenia oddelia. Pohodlie pri prvom zapojení nie je dobrým dôvodom na trvalý prístup ku všetkému.
Osobitný prípad je AI požiadavka, ktorá čaká na spracovanie. Používateľ môže po jej zadaní zmeniť tím alebo stratiť prístup k zákazke. V návrhu určite, kedy systém oprávnenie znovu overí a komu výsledok sprístupní.
Na deme zadajte testovaciu úlohu, odoberte používateľovi prístup a až potom ju dokončite. Sledujte výsledok, odoslané upozornenie aj audit. Nech dodávateľ vysvetlí pravidlo, podľa ktorého systém postupoval.
Takéto scenáre zahrňte aj do ďalšieho rozvoja. Nová rola alebo nové prepojenie môže zmeniť hranice pôvodného návrhu. Pri každej významnej úprave sa oplatí zopakovať dohodnuté skúšky namiesto predpokladu, že raz nastavené oprávnenia ostanú navždy správne.
Dokument je podklad, nie nové pravidlo
Asistent môže čítať zákaznícky e-mail alebo prílohu, ktorá obsahuje text tváriaci sa ako pokyn pre systém. Pri návrhu preto oddeľte obsah dokumentov od pravidiel určujúcich povolené operácie.
Bezpečnostné odporúčania MCP riešia riziká spojené s prístupom a používaním MCP. Pri nákupe sa pýtajte na konkrétne opatrenia konektora a hostiteľskej aplikácie. Značka protokolu sama osebe neposkytuje dôkaz bezpečnosti.
Praktické overenie môže byť jednoduché: do testovacieho dokumentu vložte požiadavku na zakázanú akciu. Asistent ju nesmie vykonať ani po presvedčivom vysvetlení v texte. Výsledok testu musí zahŕňať stav dát, nie iba odpoveď v chate.
História musí vysvetliť aj neúspešný pokus
Pri riešení problému treba zistiť, kto použil aký nástroj, ktorého záznamu sa to týkalo a aký bol výsledok. Zamietnutá požiadavka a vykonaná zmena sú odlišné udalosti. Väzba na schválenie pomôže zrekonštruovať rozhodnutie.
Diagnostika pritom nemá zbytočne kopírovať celé dokumenty, heslá či prístupové tokeny. Aj záznamy o prevádzke potrebujú pravidlá prístupu.
Zrušenie účtu, odobratie roly a odpojenie AI klienta sú rôzne zmeny. Ich účinok treba poznať aj pre otvorené relácie a naplánované operácie, nielen pre ďalšie prihlásenie.
Scenáre na prevzatie oprávnení
- Cudzia zákazka Nedostupná cez obrazovku, API aj AI nástroj
- Skryté pole Nevráti sa v exporte ani v odpovedi asistenta
- Zmenené pridelenie Prístup sa upraví podľa dohodnutých pravidiel
- Uzavretý záznam Oprava prejde predpísaným postupom
- Odvolaný prístup Overíte relácie aj čakajúce operácie
- Audit zmeny Zistíte kto, čo a s akým výsledkom vykonal
Pravidlá musia zodpovedať firme
Ak máte pobočky, zastupovanie, externých partnerov a schvaľovanie podľa stavu zákazky, všeobecné roly nemusia stačiť. Pri hotovom produkte si všetky hranice nechajte predviesť. Zložité výnimky nenechávajte na ústnu dohodu s používateľmi.
Vlastný vývoj uprednostňujeme preto, že pravidlá prístupu možno navrhnúť spolu s procesom a dátami. Rovnaké pravidlá potom použijete v aplikácii aj pri AI nástrojoch. Súčasťou dodávky však musia byť aj prijímacie scenáre a zodpovednosť za ďalšie zmeny.
V Transfer International riešime prístup k pobočkám, skupiny oprávnení a viacfaktorové overenie. Pri internom systéme sa tieto pravidlá navrhujú spolu s pracovným postupom. Pripojený AI nástroj potom musí rešpektovať rovnaké hranice ako používateľ, pre ktorého pracuje.
Prejdime vaše pracovné roly a vyberme niekoľko situácií, ktoré má dodávateľ preukázať ešte pred rozhodnutím o systéme.
