Twój serwer MCP jest bezpieczny. Księga rachunkowa, na której się opiera, już nie.

W niedawnym artykule opublikowanym tutaj, w Unite.AI, Gil Feig przedstawił sześć najlepszych praktyk dotyczących budowania bezpiecznego serwera MCP. Są słuszne i powinien ich przestrzegać każdy, kto wdraża serwer MCP. Jego rada, by każdej integracji przypisać „własną, szczegółowo określoną rolę, ograniczoną ściśle do wymaganych uprawnień”, jest jak najbardziej trafna. Zakłada jednak również, że system po drugiej stronie obsługuje szczegółowo określone role. Wskazuje to na szersze, rzadko wypowiadane założenie: że systemy znajdujące się za serwerem można zabezpieczyć na tym samym poziomie.

W oprogramowaniu biznesowym często nie jest to możliwe. Kieruję zespołem inżynierów odpowiedzialnym za warstwę integracyjną, która łączy się z 32 systemami księgowymi i ERP, z opcjonalnym serwerem MCP na wierzchu. Regularnie spotykamy agentów, którzy po naszej stronie są prawidłowo uwierzytelnieni, mają odpowiednio ograniczone uprawnienia, a ich działania są rejestrowane, lecz zapisują dane w systemach, które nie mają żadnej możliwości sprawdzenia, czy brał w tym udział agent.

Ten artykuł dotyczy drugiej części problemu: tego, co faktycznie oferują systemy nadrzędne, nad czym można zapanować z poziomu warstwy integracyjnej i gdzie kończy się ta kontrola.

Gdzie specyfikacja MCP przekazuje odpowiedzialność

Własne granice jasno wyznacza specyfikacja autoryzacji MCP. Serwer MCP jest serwerem zasobów OAuth dla swoich klientów. Gdy wywołuje nadrzędne API, działa jako odrębny klient OAuth, z osobnym tokenem wydanym przez system nadrzędny. Przekazywanie dalej tokenu klienta jest wyraźnie zabronione.

To właściwe rozwiązanie. Oznacza ono również, że wszystko, co dotyczy wywołania systemu nadrzędnego — w tym tego, kto może wykonywać poszczególne działania i jak są one rejestrowane — zależy wyłącznie od tego systemu. Specyfikacja nie naprawi tego, czego nie oferuje system nadrzędny.

To samo dotyczy wytycznych OWASP dotyczących nadmiernej autonomii agentów. Zalecają one ograniczenie uprawnień, jakie rozszerzenia agenta mają w innych systemach, do niezbędnego minimum, a także wykonywanie działań w kontekście użytkownika, w którego imieniu agent działa. Obie rady są słuszne. Obie zakładają, że inny system pozwala określić minimalne uprawnienia i kontekst użytkownika.

Co faktycznie oferują systemy nadrzędne

Oto jak z perspektywy integratora wygląda 32 systemy księgowe i ERP, z którymi się łączymy.

Jedna trzecia w ogóle nie obsługuje OAuth

21 z 32 systemów korzysta z OAuth. Pozostałe 11 opiera się na stałych poświadczeniach: kluczach API, nazwie użytkownika i haśle albo parze tokenów. Niektóre z tych kluczy nigdy nie wygasają. Jeden szeroko stosowany system informuje w dokumentacji, że jego tokeny API są ważne bezterminowo, dopóki istnieje użytkownik.

Długi okres ważności, ograniczone możliwości unieważnienia

OAuth pomaga mniej, niż można by oczekiwać. Jeden z dostawców wydaje tokeny odświeżające o okresie ważności wynoszącym około 20 lat. To poświadczenie zaprojektowane tak, by przetrwać agenta, który z niego korzysta, platformę, na której agenta zbudowano, a całkiem możliwe, że nawet osobę, która kliknęła „zezwól”. W innym systemie nie wygasają nawet tokeny dostępu.

A gdy poświadczenie już zostanie wydane, pojawia się pytanie, kto może je unieważnić. Standard dotyczący unieważniania tokenów OAuth (RFC 7009) obowiązuje od 2013 roku. Mimo to mniej więcej cztery na dziesięć systemów nie dają integratorowi żadnej technicznej możliwości unieważnienia poświadczeń. Do tej grupy należą wszystkie systemy korzystające z kluczy API. Jedyną pozostałą możliwością jest poproszenie klienta, by ręcznie usunął dostęp.

Ograniczone zakresy uprawnień, brak tożsamości agenta

Większość stałych kluczy po prostu dziedziczy pełne uprawnienia użytkownika, który je utworzył; tylko nieliczne systemy pozwalają ograniczyć klucz do konkretnych punktów końcowych. Wiele systemów OAuth obsługuje zakresy uprawnień, ale są one zwykle dość ogólne, na przykład „księgowość — odczyt i zapis”. W żadnym z 32 systemów nie udało nam się znaleźć sposobu na rejestrowanie za pośrednictwem API, w ramach tej samej transakcji, zarówno agenta, jak i osoby, w imieniu której działa. Zewnętrzni agenci są widoczni albo jako użytkownik, który ich połączył, albo jako ogólny użytkownik systemu. Co znamienne, gdy dostawca wbudował agentów we własny produkt, tak jak zrobił to Microsoft w Business Central, przypisał im dedykowane konta użytkowników. To ten sam model, który zalecam poniżej, z tą różnicą, że jest zarezerwowany dla agentów własnego dostawcy.

Co może wymusić warstwa integracyjna

Nie oznacza to, że należy się poddawać. Między agentem a systemem księgowym niemal wszystko pozostaje pod twoją kontrolą:

• poświadczenia przypisane do poszczególnych agentów w twojej własnej warstwie
• własne zakresy uprawnień, na przykład dostęp do faktur wyłącznie do odczytu
• dziennik audytowy każdego wywołania agenta, z informacją, w imieniu jakiej osoby działał
• klucze idempotencji, dzięki którym ponawiający próbę agent nie zaksięguje tej samej faktury dwa razy
• limity liczby żądań dla poszczególnych agentów
• etapy zatwierdzania przed każdą operacją zapisu

Żadne z tych rozwiązań nie zależy od tego, co obsługuje system docelowy. Już dziś można stworzyć sprawną warstwę kontroli dostępu na poziomie integracji; jeśli dopuszczasz agentów do danych finansowych, powinieneś ją zbudować.

Gdzie kończy się kontrola

Nie można jednak rozszerzyć tej warstwy poza granice systemu. W tym miejscu pojawiają się trzy problemy.

Atrybucja

W systemie księgowym zapis agenta widnieje jako zapis osoby, która autoryzowała połączenie, albo jako zapis użytkownika technicznego. Każdy, kto przeprowadza audyt tego systemu, widzi księgowanie wykonane przez tego użytkownika. Nie może stwierdzić, czy dokonała go osoba, czy agent. Z perspektywy księgi agent, który o 3 w nocy księguje 400 faktur, wygląda dokładnie tak samo jak niezwykle pilny kierownik finansowy. Odtworzenie przebiegu tych działań wymaga dostępu do logów integratora, co oznacza inny łańcuch zaufania niż w przypadku systemu będącego źródłem ewidencji. Z punktu widzenia analizy kryminalistycznej lub audytu to słaba sytuacja.

Większość organizacji również nie wyprzedza tych zmian. W badaniu Cloud Security Alliance tylko 28% respondentów stwierdziło, że potrafi wiarygodnie przypisać działania agentów do osoby lub systemu we wszystkich środowiskach, a 44% używa lub planuje używać statycznych kluczy API dla swoich agentów.

Zasada najmniejszych uprawnień

Można wymusić, by agent miał dostęp wyłącznie do odczytu faktur. Jeśli jednak system docelowy nie obsługuje zakresów uprawnień, dane uwierzytelniające używane przez warstwę pośrednią nadal zapewniają pełny dostęp. Każdy, kto je zdobędzie, całkowicie ominie tę warstwę i wszystkie skonfigurowane w niej reguły.

Unieważnianie dostępu

Można natychmiast odciąć własnego agenta. Nie pomoże to jednak, jeśli dojdzie do przejęcia danych uwierzytelniających samego systemu docelowego. A w przypadku czterech na dziesięć systemów, które nie udostępniają punktu końcowego do unieważniania dostępu, wyłącznikiem awaryjnym jest wiadomość e-mail do klienta.

Pragmatyczne rozwiązanie: dedykowany użytkownik agenta

Najbardziej użyteczna rzecz, jaką można dziś zrobić, nie jest efektowna. Należy utworzyć dedykowanego użytkownika dla agenta w systemie docelowym i łączyć agenta wyłącznie za pośrednictwem tego użytkownika.

To rozwiązanie działa w każdym systemie, w którym można tworzyć użytkowników, i zapewnia trzy rzeczy, których nie może zapewnić warstwa integracyjna:

• Atrybucja w systemie będącym źródłem ewidencji. Księgowania są przypisywane do „agenta ds. zobowiązań”, a nie do kierownika finansowego, który sześć miesięcy temu kliknął „Połącz”.
• Możliwość unieważnienia dostępu, nawet bez API. Klient może wyłączyć użytkownika w interfejsie, co sprawdza się w systemach, które nie udostępniają punktu końcowego do unieważniania dostępu.
• Częściowe zastosowanie zasady najmniejszych uprawnień. Jeśli system w ogóle obsługuje role, użytkownika agenta często można ograniczyć do modułów, których rzeczywiście potrzebuje.

Koszty są realne. Podczas wdrażania ktoś musi ręcznie utworzyć użytkownika, co powoduje dodatkowe utrudnienia w najmniej odpowiednim momencie. Około połowa systemów pobiera opłatę za każdego dodatkowego użytkownika — od kilku euro miesięcznie w narzędziach dla małych firm po ponad sto euro w pełnowymiarowym systemie ERP. W kilku innych liczba użytkowników jest ograniczona w zależności od planu, więc dodanie kolejnego może oznaczać konieczność wykupienia droższego planu dla całej firmy. Użytkownik serwisowy, za którego nikt nie odpowiada, staje się odrębnym zagrożeniem i częścią rozrostu tożsamości nie-ludzkich, o którym Unite.AI już pisało. Tak jak każde inne konto, wymaga właściciela i terminu przeglądu.

Nie rozwiązuje to również problemu braku zakresów uprawnień w systemach, które ich nie obsługują. Przywraca jednak atrybucję i możliwość unieważnienia dostępu w systemie, do którego zaglądają audytorzy.

Rozwiązanie systemowe: tożsamość delegowana

Właściwe rozwiązanie już istnieje na papierze. Wymiana tokenów OAuth 2.0 (RFC 8693) rozróżnia podszywanie się pod inną osobę od delegowania uprawnień. W przypadku delegowania agent zachowuje własną tożsamość, a token zapisuje, że działa w imieniu danej osoby, za pomocą deklaracji „act”.

W księgowości oznaczałoby to, że:

• księga odnotowuje, że ten agent dokonał księgowania w imieniu tej osoby
• zakresy uprawnień są przyznawane dla każdej delegacji, a nie dla każdego użytkownika
• pojedynczą delegację można unieważnić bez ingerowania w konto danej osoby

Z tego, co udało mi się ustalić, żaden z 32 systemów nie obsługuje podobnego rozwiązania. Na razie pozostaje więc ono kierunkiem rozwoju, a nie dostępną opcją. To postulat skierowany do dostawców oprogramowania księgowego i ERP, a nie zadanie dla integratorów: agenci już zapisują dane w waszych księgach, a wasze interfejsy API powinny to odzwierciedlać.

Co zrobić, zanim agent uzyska dostęp do księgi

Jeśli łączysz agentów z systemami księgowymi lub ERP, skorzystaj z krótkiej listy kontrolnej:

1. Sprawdź model danych uwierzytelniających każdego systemu docelowego. Czy korzysta z OAuth, czy ze statycznego klucza? Jak długo dane uwierzytelniające pozostają ważne? Czy mają przypisane zakresy uprawnień i czy można je unieważnić?
2. Niezależnie od tego zbuduj własną warstwę kontroli dostępu. To po twojej stronie powinny znaleźć się tożsamość przypisana do każdego agenta, zakresy uprawnień, idempotencja i zatwierdzanie działań — niezależnie od możliwości systemu docelowego.
3. Wszędzie tam, gdzie system na to pozwala, używaj dedykowanego użytkownika agenta. Potraktuj nakład pracy związany z wdrożeniem i koszt licencji jako cenę za możliwość przypisania działań do ich sprawcy.
4. Zadbaj o to, by własny dziennik audytowy był odporny na manipulacje. W przypadku wielu systemów będzie to jedyny zapis potwierdzający udział agenta.
5. Zapisz ryzyko resztkowe. Jeśli system nie obsługuje zakresów uprawnień ani ich unieważniania, powiedz o tym klientowi i uwzględnij to we własnym rejestrze ryzyka.

Granica jest tu kluczowa

Zabezpieczenie własnego serwera MCP jest konieczne, ale niewystarczające. O bezpieczeństwie agenta zapisującego dane w księdze decyduje granica między twoją warstwą a systemem będącym źródłem danych, a dziś o tej granicy decydują systemy, nie ty.

Dobra wiadomość jest taka, że ta luka została jasno określona. Standardy już istnieją. Brakuje jedynie ich obsługi w systemach, w których prowadzi się księgi.