Bezpieczeństwo MCP: bezpieczna konfiguracja, tożsamość i autoryzacja przez bramkę

Protokół nie jest sednem problemu; ryzyko bierze się z tego, jak zespoły go podłączają. MCP standaryzuje sposób, w jaki agent sięga po narzędzia i dane, i właśnie dlatego słabości wokół niego skalują się: szerokie tokeny, długowieczne klucze i narzędzia działające z większym dostępem, niż wymaga zadanie, nagle stają się osiągalne przez jeden jednolity interfejs. Innymi słowy MCP nie tworzy tylu nowych kategorii podatności, ile sprawia, że istniejące błędy autoryzacji i tożsamości łatwo popełnić wszędzie naraz. To wskazuje też lekarstwo. MCP nie czynisz bezpiecznym, porzucając standard — czynisz je bezpiecznym zdyscyplinowaną autoryzacją: zawężonymi, krótkowiecznymi poświadczeniami, decyzją polityki przed wrażliwymi akcjami oraz właścicielem i śladem audytowym dla każdej tożsamości maszynowej. Traktuj protokół jak instalację, a wysiłek bezpieczeństwa włóż w to, komu wolno co przez niego zrobić.

Tożsamość maszynowa (NHI) to cyfrowa tożsamość aktora maszynowego — agenta, usługi lub zadania — a nie człowieka. Tam gdzie człowiek loguje się nazwą i hasłem, agent uwierzytelnia się kluczem API, tokenem lub certyfikatem, i to poświadczenie jest jego tożsamością w Twoich systemach. Ma to znaczenie, bo większość zarządzania tożsamością zbudowano dla ludzi, wokół cyklu przyjęcie–zmiana–odejście, a agenci nie pasują do żadnego z tych etapów, mimo że potrafią odczytać bazy albo wysłać pocztę. Traktowanie NHI jako pełnoprawnych tożsamości — każda z nazwanym właścicielem, określonym zakresem, harmonogramem rotacji i śladem audytowym — jest istotą kontroli dostępu agentów. Organizacje, które to pomijają, kończą z tysiącami poświadczeń, których nikt nie jest właścicielem i nikt nie potrafi pewnie odwołać, a to jest dokładnie ten zasięg szkody, który dziedziczy atakujący.

Zacznij od inwentaryzacji, bo nie zarządzisz tożsamościami, których nigdy nie spisałeś. Wylicz każdy serwer MCP, każdego agenta i poświadczenia, które każde z nich trzyma, a potem oznacz te długowieczne, szeroko uprawnione lub niczyje — to Twoje natychmiastowe ryzyko. Z tej listy pierwsze konkretne ruchy to usunięcie lub rotacja najgorszych statycznych kluczy, zawężenie każdego pozostałego poświadczenia do minimalnych uprawnień i postawienie kontroli autoryzacji w czasie wykonania przed naprawdę wrażliwymi akcjami. Ta kolejność ma znaczenie: najpierw odkrycie, bo większość organizacji nie docenia, ile tożsamości maszynowych już ma, a potem ograniczanie, bo zawężone poświadczenie ogranicza szkodę każdego przyszłego przejęcia. Inwentaryzacja jest mało efektowna, ale to ona umożliwia wszystkie inne kontrole i niemal zawsze ujawnia kilka zapomnianych kluczy, które należało odwołać miesiące temu.

Długowieczny klucz API to stałe, często szeroko uprawnione poświadczenie, które samo nie wygasa, a dla agentów właśnie ta kombinacja jest najczęstszą słabością. Problemem jest czas trwania pomnożony przez zasięg: klucz działa bezterminowo, więc kopia wyciekła w logu, przez prompt injection lub przejętą zależność pozostaje ważna długo po incydencie, a zwykle niesie znacznie większy dostęp, niż potrzebuje pojedyncze zadanie. Ponieważ ten sam klucz bywa współdzielony przez wiele narzędzi, jeden wyciek kompromituje naraz wszystko, czego dotyka. Lekarstwem jest zastąpienie statycznych kluczy krótkowiecznymi, automatycznie rotowanymi tokenami zawężonymi do konkretnej tożsamości i akcji, tak by nawet skradzione poświadczenie szybko wygasło i niewiele sięgało. Połącz to z logowaniem audytowym per tożsamość, by wyciekły token dało się prześledzić i odwołać, a nie po cichu używać tygodniami. Krótkie i wąskie bije długie i szerokie za każdym razem.