Váš server MCP je zabezpečený. Účetní systém za ním ale ne.

V nedávném článku zde na Unite.AI Gil Feig představil šest osvědčených postupů pro vytvoření zabezpečeného serveru MCP. Jsou správné a měl by se jimi řídit každý, kdo nasazuje server MCP. Jeho rada, aby každá integrace měla „vlastní podrobnou roli s oprávněními omezenými striktně na nezbytné minimum“, je naprosto správná. Předpokládá ale také, že systém na druhé straně nabízí podrobně nastavitelná oprávnění. To poukazuje na širší, jen zřídka vyslovený předpoklad: že systémy, s nimiž server komunikuje, lze zabezpečit na stejné úrovni.

V podnikovém softwaru to často možné není. Vedu technický tým, který vyvíjí integrační vrstvu propojující 32 účetních a ERP systémů, nad níž lze volitelně provozovat server MCP. Pravidelně se setkáváme s agenty, kteří jsou na naší straně řádně ověřeni, mají přesně vymezená oprávnění a jejichž činnost se zaznamenává, ale zapisují do systémů, které nemají jak zjistit, že se na tom vůbec podílel agent.

Tento článek se zabývá druhou částí problému: tím, co upstream systémy skutečně nabízejí, co lze řídit z integrační vrstvy a kde tato kontrola končí.

Kde specifikace MCP předává odpovědnost

Specifikace autorizace MCPjasně vymezuje vlastní hranice. Server MCP je pro své klienty serverem prostředků OAuth. Při volání nadřazeného API vystupuje jako samostatný klient OAuth s odděleným tokenem vydaným nadřazeným systémem. Předávání tokenu klienta je výslovně zakázáno.

To je správný návrh. Zároveň to znamená, že vše, co se týká volání upstream systému, včetně toho, kdo smí co dělat a jak se jeho činnost zaznamenává, závisí výhradně na tomto systému. Specifikace nemůže napravit to, co upstream systém nenabízí.

Totéž platí pro doporučení OWASP, jak omezit nadměrnou autonomii. Doporučuje omezit oprávnění, která mají rozšíření agenta v jiných systémech, na nezbytné minimum a provádět akce v kontextu uživatele, jehož jménem agent jedná. Obojí je dobrá rada. V obou případech se předpokládá, že druhý systém dokáže vyjádřit minimální potřebná oprávnění i kontext uživatele.

Co upstream systémy skutečně nabízejí

Takto vypadá 32 účetních a ERP systémů, ke kterým se připojujeme, z pohledu integrátora.

Třetina z nich vůbec nepoužívá OAuth

OAuth používá 21 z 32 systémů. Zbývajících 11 spoléhá na statické přihlašovací údaje: klíče API, uživatelské jméno a heslo nebo dvojici tokenů. Platnost některých těchto klíčů nikdy nevyprší. Jeden široce používaný systém v dokumentaci uvádí, že jeho tokeny API mají neomezenou dobu platnosti, dokud existuje daný uživatel.

Dlouhá platnost, omezené možnosti odvolání

OAuth pomáhá méně, než byste čekali. Jeden poskytovatel vydává obnovovací tokeny s platností přibližně 20 let. Jde o přihlašovací údaj navržený tak, aby přežil agenta, který ho používá, framework, na němž byl agent vytvořen, a dost možná i člověka, který klikl na „povolit“. V jiném systému nevyprší ani platnost přístupových tokenů.

A když už se přihlašovací údaj dostane ven, je otázkou, kdo ho může zneplatnit. Standard pro tento postup, odvolání tokenu OAuth (RFC 7009), existuje od roku 2013. Přibližně čtyři z deseti systémů však integrátorovi neposkytují žádný technický způsob, jak přihlašovací údaje zneplatnit. Do této skupiny patří všechny systémy s klíči API. Jedinou zbývající možností je požádat zákazníka, aby přístup ručně odstranil.

Hrubě nastavená oprávnění, žádná identita agenta

Většina statických klíčů jednoduše přebírá veškerá oprávnění uživatele, který je vytvořil; jen několik systémů umožňuje omezit klíč na jednotlivé koncové body. Mnohé systémy OAuth používají rozsahy oprávnění, ty však bývají hrubě nastavené, například „účetnictví, čtení a zápis“. V žádném z 32 systémů jsme navíc nenašli způsob, jak prostřednictvím API zaznamenat u jedné transakce agenta i osobu, jejímž jménem jedná. Externí agenti se zobrazují buď jako uživatel, který je připojil, nebo jako obecný systémový uživatel. Výmluvné je, že když dodavatel zabudoval agenty do vlastního produktu, jako to udělal Microsoft v Business Central, přidělil jim samostatné uživatelské účty. Jde o stejný přístup, který doporučuji níže, vyhrazený však pouze agentům daného dodavatele.

Co může vynutit integrační vrstva

To všechno neznamená, že se musíme vzdát. Mezi agentem a účetním systémem máte pod kontrolou téměř vše:

• přihlašovací údaje pro každého agenta zvlášť vůči vaší vlastní vrstvě
• vlastní rozsahy oprávnění, například přístup k fakturám pouze pro čtení
• protokol auditu každého volání agenta včetně záznamu o člověku, jehož jménem jednal
• klíče idempotence, aby agent při opakování požadavku nezaúčtoval stejnou fakturu dvakrát
• limity počtu požadavků pro každého agenta
• schvalovací kroky před jakýmkoli zápisem

Nic z toho nezávisí na tom, co cílový systém podporuje. Schopnou vrstvu pro řízení přístupu na úrovni integrace lze vytvořit už dnes, a pokud agenti mají jakkoli pracovat s finančními údaji, měli byste ji vybudovat.

Kde to končí

Co ale udělat nemůžete, je rozšířit tuto vrstvu za hranice systému. Tam selhávají tři věci.

Atribuce

V účetním systému se zápis agenta zobrazuje jako zápis osoby, která připojení autorizovala, nebo jako zápis technického uživatele. Každý, kdo tento systém kontroluje, vidí zápis provedený tímto uživatelem. Nemůže zjistit, zda ho vytvořil člověk, nebo agent. Z pohledu účetní knihy vypadá agent, který ve tři ráno zaúčtuje 400 faktur, úplně stejně jako velmi svědomitý finanční manažer. Aby bylo možné zjistit, co se stalo, je třeba využít záznamy integrátora, což představuje jiný řetězec důvěry než samotný evidenční systém. Z hlediska forenzního šetření nebo auditu je to slabá pozice.

Většina organizací na tom není o mnoho lépe. V průzkumu Cloud Security Alliance pouze 28 % respondentů uvedlo, že dokážou spolehlivě sledovat činnost agentů až ke konkrétnímu člověku nebo systému napříč všemi prostředími, a 44 % používá statické klíče API pro své agenty, nebo jejich používání plánuje.

Princip nejnižších oprávnění

Můžete zajistit, aby agent pouze četl faktury. Pokud však cílový systém nepodporuje rozsahy oprávnění, přihlašovací údaje, na nichž vaše vrstva stojí, stále poskytují plný přístup. Každý, kdo je získá, vaši vrstvu i všechna pravidla, která jste s ní nastavili, zcela obejde.

Odvolání přístupu

Svému agentovi můžete přístup okamžitě zablokovat. To ale nepomůže, pokud dojde ke kompromitaci samotných přihlašovacích údajů k cílovému systému. A u čtyř z deseti systémů, které nemají koncový bod pro odvolání přístupu, představuje nouzové vypnutí e-mail zákazníkovi.

Pragmatické řešení: samostatný uživatelský účet pro agenta

Nejužitečnější věc, kterou dnes můžete udělat, není nijak oslnivá. Vytvořte agentovi v cílovém systému samostatný uživatelský účet a připojujte agenta výhradně prostřednictvím něj.

Funguje to v každém systému, který umožňuje vytvářet uživatelské účty, a přináší to tři výhody, které integrační vrstva zajistit nedokáže:

• Atribuci v evidenčním systému. Zápisy se zobrazují jako „AP agent“, nikoli jako zápisy finančního manažera, který před šesti měsíci klikl na „připojit“.
• Možnost odvolat přístup, i když pro to neexistuje rozhraní API. Zákazník může účet deaktivovat přímo v rozhraní, což funguje i v systémech, které nemají koncový bod pro odvolání přístupu.
• Částečné uplatnění principu nejnižších oprávnění. Pokud systém vůbec nabízí nějaký model rolí, lze uživatelský účet agenta často omezit na moduly, které skutečně potřebuje.

Náklady jsou skutečné. Během zavádění systému musí někdo účet vytvořit ručně, což přidává další překážku právě v tu nejméně vhodnou chvíli. Přibližně polovina systémů účtuje poplatek za každého dalšího uživatele, od několika eur měsíčně u nástrojů pro malé firmy až po více než sto eur u plnohodnotného ERP systému. Několik dalších systémů omezuje počet uživatelů podle tarifu, takže jeden další uživatel může pro celou firmu znamenat nutnost přejít na dražší tarif. A servisní účet, za který nikdo nenese odpovědnost, představuje samostatné riziko a přispívá k množení ne-lidských identit, o němž už Unite.AI psala. Stejně jako každý jiný účet musí mít svého správce a stanovený termín kontroly.

Neřeší to ani chybějící rozsahy oprávnění v systémech, které je nemají. Přesouvá to však atribuci a možnost odvolat přístup zpět do systému, který auditoři skutečně kontrolují.

Strukturální řešení: delegovaná identita

Správné řešení už existuje alespoň na papíře. Výměna tokenů OAuth 2.0 (RFC 8693) rozlišuje mezi zosobněním a delegováním. Při delegování si agent zachovává vlastní identitu a token zaznamenává, že jedná jménem určité osoby, a to prostřednictvím deklarace „act“.

V účetnictví by to znamenalo, že:

• účetní kniha zaznamená, že tento agent provedl zápis jménem této osoby
• rozsahy oprávnění se udělují pro každou delegaci, nikoli každému uživateli
• jednotlivou delegaci lze odvolat, aniž by bylo nutné zasáhnout do účtu dané osoby

Pokud se mi podařilo zjistit, žádný z těchto 32 systémů nic podobného nepodporuje. Zatím tedy jde o směr, kterým se lze vydat, nikoli o dostupnou možnost. Je proto třeba obrátit se s požadavkem na dodavatele účetního a ERP softwaru, nikoli zadávat práci integrátorům: agenti už zapisují do vašich účetních knih a vaše rozhraní API by to měla umět zaznamenat.

Co udělat, než agentovi umožníte přístup k účetní knize

Pokud připojujete agenty k účetním nebo ERP systémům, projděte si tento stručný seznam:

1. Zmapujte model přihlašovacích údajů každého cílového systému. Používá OAuth, nebo statický klíč? Jak dlouho jsou přihlašovací údaje platné? Mají nastavené rozsahy oprávnění a lze je odvolat?
2. Vlastní vrstvu řízení přístupu vytvořte tak jako tak. Identita pro každého agenta, rozsahy oprávnění, idempotence a schvalování patří na vaši stranu bez ohledu na možnosti cílového systému.
3. Všude, kde to systém umožňuje, používejte pro agenta samostatný uživatelský účet. Náklady na zavedení a licenci berte jako cenu za možnost přiřadit zápisy konkrétnímu uživateli.
4. Veďte vlastní auditní stopu tak, aby bylo možné odhalit její neoprávněné změny. U mnoha systémů to bude jediný záznam o zapojení agenta.
5. Zaznamenejte zbytkové riziko. Pokud systém nemá rozsahy oprávnění ani možnost jejich odvolání, uveďte to zákazníkovi i ve vlastním registru rizik.

Právě v tom spočívá význam hranice

Zabezpečení vašeho serveru MCP je nezbytné, ale samo o sobě nestačí. O bezpečnosti agenta, který zapisuje do účetní knihy, rozhoduje hranice mezi vaší vrstvou a systémem, který je zdrojem pravdy. Dnes tuto hranici určují systémy, nikoli vy.

Dobrou zprávou je, že tento nedostatek je přesně vymezený. Standardy existují. Chybí jen jejich podpora v systémech, které vedou účetní knihy.