MCP-palvelimesi on suojattu. Sen takana oleva pääkirja ei ole.

Unite.AI:ssa äskettäin julkaistussa kirjoituksessaan Gil Feig esitteli kuusi parasta käytäntöä suojatun MCP-palvelimen rakentamiseen. Ne ovat hyviä neuvoja, ja jokaisen MCP-palvelinta käyttöön ottavan kannattaa noudattaa niitä. Hänen suosituksensa antaa kullekin integraatiolle ”oma tarkasti rajattu rooli, jonka käyttöoikeudet rajoittuvat tiukasti tarpeellisiin” on aivan oikea. Se kuitenkin olettaa myös, että toisessa päässä olevassa järjestelmässä on tarkasti rajattuja rooleja. Tämä viittaa laajempaan, harvoin ääneen lausuttuun oletukseen: palvelimen taustalla olevat järjestelmät voidaan suojata yhtä korkeatasoisesti.

Yritysohjelmistoissa näin ei usein ole. Johdan suunnittelutiimiä, joka vastaa integraatiokerroksesta, joka yhdistää 32 kirjanpito- ja ERP-järjestelmään ja jonka päälle voidaan haluttaessa lisätä MCP-palvelin. Näemme säännöllisesti, kuinka meidän puolellamme hyvin tunnistetut, käyttöoikeuksiltaan rajatut ja lokitetut agentit kirjoittavat järjestelmiin, joilla ei ole mitään keinoa tietää, että agentti on ollut mukana.

Tässä kirjoituksessa käsitellään ongelman toista puolta: mitä taustajärjestelmät todellisuudessa tarjoavat, mitä integraatiokerroksesta käsin voi hallita ja missä tämän hallinnan rajat tulevat vastaan.

Missä MCP-määritys luovuttaa vastuun

MCP:n valtuutusmääritys määrittelee selkeästi oman rajansa. MCP-palvelin toimii asiakkaidensa OAuth-resurssipalvelimena. Kun se kutsuu taustajärjestelmän rajapintaa, se toimii erillisenä OAuth-asiakkaana, jolla on taustajärjestelmän myöntämä erillinen käyttöoikeustunnus. Asiakkaan käyttöoikeustunnuksen välittäminen sellaisenaan on nimenomaisesti kielletty.

Tämä on oikea toimintamalli. Samalla se tarkoittaa, että kaikki taustajärjestelmään kohdistuvaan kutsuun liittyvä – myös se, kenellä on oikeus tehdä mitä ja miten toiminta kirjataan – riippuu täysin taustajärjestelmästä. Määritys ei voi korjata sitä, mitä taustajärjestelmä ei tarjoa.

Sama pätee OWASP:n ohjeistukseen agenttien liiallisesta toimivallasta. Siinä suositellaan rajaamaan agentin laajennuksille muissa järjestelmissä myönnetyt käyttöoikeudet välttämättömään minimiin ja suorittamaan toiminnot sen käyttäjän nimissä, jonka puolesta agentti toimii. Molemmat ovat hyviä neuvoja. Kummassakin kuitenkin oletetaan, että toinen järjestelmä pystyy ilmaisemaan vähimmäiskäyttöoikeudet ja käyttäjän kontekstin.

Mitä taustajärjestelmät todellisuudessa tarjoavat

Tällaisilta näyttävät ne 32 kirjanpito- ja ERP-järjestelmää, joihin olemme yhteydessä, integraattorin näkökulmasta.

Kolmasosassa ei ole lainkaan OAuthia

32 järjestelmästä 21 käyttää OAuthia. Muut 11 perustuvat staattisiin tunnistetietoihin: API-avaimiin, käyttäjätunnukseen ja salasanaan tai kahden tunnisteen yhdistelmään. Osa näistä avaimista ei vanhene koskaan. Erään laajalti käytetyn järjestelmän dokumentaatiossa kerrotaan, että sen API-tunnukset ovat voimassa rajoituksetta niin kauan kuin käyttäjä on olemassa.

Pitkä voimassaoloaika, vähäiset mahdollisuudet peruuttaa

OAuthista on vähemmän apua kuin voisi toivoa. Eräs palveluntarjoaja myöntää päivitystunnisteita, joiden käyttöikä on noin 20 vuotta. Tällainen tunniste on suunniteltu kestämään kauemmin kuin sitä käyttävä agentti, agentin pohjana oleva kehys ja hyvinkin mahdollisesti henkilö, joka napsautti ”salli”. Toisessa järjestelmässä edes käyttöoikeustunnisteet eivät vanhene.

Kun tunnistetieto on kerran annettu, on kysyttävä, kuka voi poistaa sen käytöstä. Tätä koskeva standardi, OAuth-tunnisteen peruuttaminen (RFC 7009), on ollut olemassa vuodesta 2013. Silti noin neljässä kymmenestä järjestelmästä integraattorilla ei ole teknistä keinoa tunnistetietojen peruuttamiseen. Kaikki API-avaimiin perustuvat järjestelmät kuuluvat tähän ryhmään. Ainoaksi keinoksi jää pyytää asiakasta poistamaan käyttöoikeus itse käsin.

Karkeat käyttöoikeusrajaukset, ei agentin tunnistetta

Useimmat staattiset avaimet saavat yksinkertaisesti kaikki niiden luoneen käyttäjän käyttöoikeudet; vain muutamissa järjestelmissä avaimen käyttöoikeuksia voi rajata yksittäisiin päätepisteisiin. Monissa OAuth-järjestelmissä on käyttöoikeusrajauksia, mutta ne ovat yleensä karkeita, esimerkiksi ”kirjanpito: luku ja kirjoitus”. Emme myöskään löytäneet yhdestäkään 32 järjestelmästä tapaa kirjata API:n kautta samaan tapahtumaan sekä agenttia että henkilöä, jonka puolesta se toimii. Ulkoiset agentit näkyvät joko ne yhdistäneenä käyttäjänä tai yleisenä järjestelmäkäyttäjänä. Kuvaavaa on, että kun toimittaja on rakentanut agentteja omaan tuotteeseensa, kuten Microsoft on tehnyt Business Centralissa, se on luonut niille omat käyttäjätilit. Tämä on sama toimintamalli, jota suosittelen jäljempänä, mutta varattuna toimittajan omille agenteille.

Mitä integraatiokerros voi valvoa

Tämä ei tarkoita, että pitäisi luovuttaa. Agentin ja kirjanpitojärjestelmän välillä voit hallita lähes kaikkea:

• agenttikohtaiset tunnistetiedot omaan integraatiokerrokseesi
• omat käyttöoikeusrajaukset, esimerkiksi vain luku -oikeus laskuihin
• tarkastusloki kaikista agentin tekemistä kutsuista sekä tieto siitä, kenen puolesta agentti toimi
• idempotenssiavaimet, jotta uudelleen yrittävä agentti ei kirjaa samaa laskua kahdesti
• agenttikohtaiset käyttörajoitukset
• hyväksyntävaiheet ennen kirjoitustoimintoa

Mikään tästä ei riipu siitä, mitä kohdejärjestelmä tukee. Integraatiokerroksen tasolle on jo nyt mahdollista rakentaa tehokas käyttöoikeuskerros, ja jos agentit pääsevät lähellekään taloustietoja, sellainen kannattaa rakentaa.

Mihin asti hallinta ulottuu

Et voi kuitenkaan ulottaa tätä kerrosta järjestelmän rajojen yli. Siellä kolme asiaa pettää.

Tekijän tunnistaminen

Kirjanpitojärjestelmässä agentin tekemä kirjaus näkyy yhteyden valtuuttaneen käyttäjän tai teknisen käyttäjän tekemänä. Järjestelmää tarkastava näkee, että kirjauksen on tehnyt kyseinen käyttäjä. Hän ei voi tietää, tekikö sen ihminen vai agentti. Kirjanpidossa agentti, joka kirjaa 400 laskua kello 3 aamuyöllä, näyttää aivan samalta kuin erittäin tunnollinen talouspäällikkö. Tapahtumien selvittäminen edellyttää integraattorin lokien tutkimista, mikä on eri luottamusketju kuin varsinainen kirjanpitojärjestelmä. Tämä on heikko lähtökohta rikostutkinnalle tai auditoinnille.

Useimmat organisaatiot eivät ole tässä asiassa sen edellä. Cloud Security Alliancen kyselyssä vain 28 % vastaajista kertoi pystyvänsä luotettavasti jäljittämään agenttien toiminnan ihmiseen tai järjestelmään kaikissa ympäristöissä, ja 44 % käyttää tai aikoo käyttää agenteissaan staattisia API-avaimia.

Vähimmät oikeudet

Voit rajoittaa agentin lukemaan vain laskuja. Jos kohdejärjestelmässä ei kuitenkaan ole käyttöoikeusalueita, kerroksesi taustalla olevilla tunnistetiedoilla on silti täydet käyttöoikeudet. Jokainen, joka saa ne haltuunsa, voi ohittaa kerroksesi kokonaan ja samalla kaikki sen avulla määrittämäsi säännöt.

Käyttöoikeuden peruminen

Voit estää oman agenttisi toiminnan välittömästi. Siitä ei ole apua, jos itse kohdejärjestelmän tunnistetiedot vaarantuvat. Niissä neljässä kymmenestä järjestelmästä, joissa ei ole käyttöoikeuden perumisrajapintaa, hätäpysäytyksenä toimii asiakkaalle lähetettävä sähköposti.

Käytännön ratkaisu: agentille oma käyttäjätili

Hyödyllisintä, mitä voit tehdä tänään, ei ole kovin näyttävää. Luo agentille oma käyttäjätili kohdejärjestelmään ja yhdistä agentti järjestelmään ainoastaan tämän tilin kautta.

Tämä toimii kaikissa järjestelmissä, joissa voi luoda käyttäjätilejä, ja tarjoaa kolme etua, joita integraatiokerros ei voi tarjota:

• Tekijän tunnistaminen varsinaisessa järjestelmässä. Kirjaukset näkyvät ”AP-agentin” tekeminä, eivät talouspäällikön, joka napsautti ”Yhdistä” kuusi kuukautta sitten.
• Käyttöoikeuden perumismahdollisuus, vaikka siihen ei olisi API-rajapintaa. Asiakas voi poistaa käyttäjän käytöstä käyttöliittymässä, mikä toimii myös järjestelmissä, joissa ei ole käyttöoikeuden perumisrajapintaa.
• Osittainen vähimpien oikeuksien periaatteen toteuttaminen. Jos järjestelmässä on minkäänlaista roolipohjaista käyttöoikeusmallia, agentin käyttäjätilin oikeudet voi usein rajata moduuleihin, joita se todella tarvitsee.

Kustannukset ovat todellisia. Jonkun on luotava käyttäjätili käsin käyttöönoton yhteydessä, mikä lisää vaivaa juuri väärällä hetkellä. Noin puolet järjestelmistä veloittaa jokaisesta lisäkäyttäjästä: pienyrityksille tarkoitetuissa työkaluissa muutaman euron kuukaudessa ja täysimittaisessa ERP-järjestelmässä yli sata euroa kuukaudessa. Useissa muissa järjestelmissä käyttäjämäärä on rajattu paketin mukaan, joten yhden käyttäjän lisääminen voi pakottaa koko yrityksen vaihtamaan kalliimpaan pakettiin. Lisäksi palvelukäyttäjä, josta kukaan ei vastaa, muodostaa oman riskinsä ja kasvattaa muiden kuin ihmisten identiteettien hallitsematonta määrää, mistä Unite.AI on kirjoittanut aiemmin. Kuten kaikilla muillakin tileillä, sillä on oltava vastuuhenkilö ja tarkistuspäivämäärä.

Tämä ei myöskään ratkaise käyttöoikeusalueiden puuttumista järjestelmissä, joissa niitä ei ole. Se kuitenkin palauttaa tekijän tunnistamisen ja käyttöoikeuksien perumisen osaksi sitä järjestelmää, josta tarkastajat todella etsivät niitä.

Rakenteellinen ratkaisu: delegoitu identiteetti

Oikea ratkaisu on jo olemassa paperilla. OAuth 2.0 -tunnustenvaihto (RFC 8693)erottaa toisena henkilönä esiintymisen delegoinnista. Delegoinnissa agentti säilyttää oman identiteettinsä, ja tunnisteesta käy ”act”-väitteen avulla ilmi, että se toimii henkilön puolesta.

Kirjanpidossa tämä tarkoittaisi, että:

• kirjanpitoon merkitään, että tämä agentti teki kirjauksen tämän henkilön puolesta
• käyttöoikeusalueet myönnetään delegointikohtaisesti, ei käyttäjäkohtaisesti
• yksittäinen delegointi voidaan perua koskematta henkilön tiliin

Selvitykseni perusteella mikään 32 järjestelmästä ei tue mitään vastaavaa. Toistaiseksi se on siis tavoite, ei käytettävissä oleva vaihtoehto. Siksi asia on esitettävä kirjanpito- ja ERP-ohjelmistojen toimittajille eikä integraattoreille: agentit tekevät jo kirjauksia kirjanpitoonne, ja API-rajapintojenne pitäisi pystyä kertomaan siitä.

Mitä tehdä ennen kuin agentti pääsee käsiksi kirjanpitoon

Jos yhdistät agentteja kirjanpito- tai ERP-järjestelmiin, käy läpi tämä lyhyt tarkistuslista:

1. Selvitä kunkin kohdejärjestelmän tunnistetietomalli. Käyttääkö järjestelmä OAuthia vai staattista avainta, kuinka kauan tunnistetieto on voimassa, onko sillä käyttöoikeusalueita ja voiko sen mitätöidä?
2. Rakenna käyttöoikeuskerros joka tapauksessa. Agenttikohtainen identiteetti, käyttöoikeusalueet, idempotenssi ja hyväksynnät kuuluvat sinun vastuullesi kohdejärjestelmän tarjoamista ominaisuuksista riippumatta.
3. Käytä agentille omaa käyttäjätiliä aina, kun järjestelmä sen sallii. Hyväksy käyttöönoton vaatima työ ja lisenssikustannukset tekijän tunnistamisen hintana.
4. Pidä oma tarkastusketjusi peukaloinnin paljastavana. Monissa järjestelmissä se on ainoa merkintä siitä, että agentti oli mukana.
5. Kirjaa jäännösriski ylös. Jos järjestelmässä ei ole käyttöoikeusrajauksia eikä mahdollisuutta peruuttaa käyttöoikeuksia, kerro se asiakkaallesi ja merkitse se omaan riskirekisteriisi.

Raja on asian ydin

MCP-palvelimesi suojaaminen on välttämätöntä. Se ei kuitenkaan riitä. Pääkirjaan kirjauksia tekevän agentin turvallisuus ratkaistaan sinun kerroksesi ja virallisen tietojärjestelmän välisellä rajalla, ja nykyään tuon rajan määrittävät järjestelmät, eivät sinä.

Hyvä uutinen on, että puute on tarkasti rajattu. Standardit ovat olemassa. Niiden tuki puuttuu kirjanpitoa ylläpitävistä järjestelmistä.