Näin rakennetaan AI-agentille turvallinen verkkoalue Tailscalella

Edellisessä artikkelissamme käsittelimme 12 kontrollia, jotka yrityksen pitäisi toteuttaa ennen kuin tekoälyagentille annetaan pääsy todellisiin järjestelmiin. Näihin kuuluvat agentin oma identiteetti, rajatut verkkoyhteydet, työkalukohtainen valtuutus, ihmisen hyväksyntä, lokitus ja testattu pysäytysmekanismi. [1]

Tässä artikkelissa keskitymme yhteen näistä kerroksista: AI-agentin verkkopääsyn tekniseen rajaamiseen Tailscalella.

Tavoitteena ei ole rakentaa agentille pientä sisäverkkoa, jonka sisällä se voi liikkua vapaasti. Tavoitteena on rakentaa identiteettipohjainen mikrosegmentti, jossa agentille on olemassa vain ne yhteyspolut, joita sen tehtävä välttämättä edellyttää.

Verkkopääsyn vaatimukset

Tämä on paljon tarkempi turvallisuusominaisuus kuin yleinen väite siitä, että agentti on “VPN:n takana”.

Turvallinen verkkoalue ei ole sama asia kuin luotettu sisäverkko

Perinteinen verkkosegmentti rakennetaan usein VLANin, aliverkon tai palomuurivyöhykkeen ympärille.

Agentti voidaan esimerkiksi sijoittaa verkkoon:

10.40.20.0/24

Palomuuri voi estää liikenteen muihin aliverkkoihin, mutta saman verkkoalueen sisällä olevat työkuormat saattavat edelleen nähdä toisensa. Verkkopolitiikka perustuu ensisijaisesti IP-osoitteisiin ja verkkosijaintiin.

Tailscale-arkkitehtuurissa verkkoalue voidaan mallintaa toisin:

1. LähdeidentiteettiKuka tai mikä aloittaa yhteyden?
2. KohdeidentiteettiMihin nimettyyn resurssiin yhteys muodostuu?
3. VerkkokykyMikä protokolla ja portti sallitaan?

Tailscale Grants -politiikassa yhteys määritellään vähintään kolmella tiedolla:

src = kuka tai mikä saa aloittaa yhteyden
dst = mihin resurssiin yhteys saa muodostua
ip  = mitä protokollaa ja porttia saa käyttää

Grants-sääntömalli on deny-by-default: yhteyttä ei sallita, ellei täydellisestä politiikasta löydy siihen täsmäävää sääntöä. Uudessa tailnetissa voi silti olla valmiiksi täytetty laaja aloituspolitiikka, joten se pitää korvata ennen vähimmän oikeuden toteutumista. Tailscalen hallintataso jakelee laitteille identiteetti-, avain- ja politiikkatiedot, ja WireGuard-salattu dataliikenne pysyy datatasolla. Netmap trimming vähentää laitteelle jaettavia vertaistietoja, mutta laite voi silti nähdä sallitut kohteet, käytettävissä olevat exit nodet, saman käyttäjän tunnistamat laitteet sekä laitteet, jotka voivat aloittaa siihen yhteyden. [2] [21] [23]

Turvallinen verkkoalue on siten käytännössä sallittujen yhteyksien graafi:

Reachability(ai-agent) = {
  ai-llm-gateway:443,
  ai-tool-gateway:443
}

Kaikki muu jää graafin ulkopuolelle.

Reachability(ai-agent, prod-db:5432) = false
Reachability(ai-agent, prod-admin:22) = false
Reachability(ai-agent, erp-api:443) = false

Tämä vastaa Defense Firstin käyttämää pääsypolkuajattelua:

1. Tunnista
2. Mallinna
3. Toimeenpane
4. Todista

Ensin tunnistetaan todellinen liiketoimintatarve. Sen jälkeen yhteyspolku mallinnetaan, toimeenpannaan Grants-politiikalla ja todistetaan sekä sallituilla että estetyillä testeillä. [3]

Uhkamalli: oletetaan, että agentti toimii väärin

Referenssiarkkitehtuuria ei pidä suunnitella vain agentin normaalin toiminnan ympärille.

Arkkitehtuurin lähtöoletuksena pitäisi olla, että jokin seuraavista tapahtuu:

1. Agentti tulkitsee tehtävän väärin.
2. Agentti lukee prompt injection -hyökkäyksen sisältävän dokumentin.
3. Agentin käyttämä työkalu tai MCP-palvelin vaarantuu.
4. Agentin ohjelmistoriippuvuuteen tulee toimitusketjuhyökkäys.
5. Agentin työkuormaidentiteetti tai sovellustunnus varastetaan.
6. Agentin suoritusympäristöön saadaan koodinsuoritus.
7. Agentti yrittää tavoittaa järjestelmän, jota sen ei pitäisi käyttää.

OWASP tunnistaa agenttisten järjestelmien riskeiksi muun muassa agentin tavoitteen kaappaamisen, työkalujen väärinkäytön, identiteetti- ja käyttöoikeusväärinkäytökset, agenttisen toimitusketjun ongelmat sekä odottamattoman koodinsuorituksen. Kansainvälinen viranomaisohjeistus suosittelee siksi tarkasti rajattuja resursseja ja toimintoja, vähimmän oikeuden periaatetta, lyhytikäisiä tunnisteita, eristämistä ja asteittaista käyttöönottoa. [4] [22]

Verkkokerroksen turvallisuustavoite ei ole: agentti ei koskaan yritä tehdä mitään vaarallista.

Parempi tavoite on: vaikka agentti yrittäisi tehdä vaarallisen toiminnon, tarvittavaa verkkopolkua ei ole olemassa.

Tämän artikkelin referenssiarkkitehtuuri perustuu seuraaviin turvallisuusvaatimuksiin:

1. I1Agentilla ei ole suoraa yhteyttä tietokantaan.
2. I2Agentilla ei ole suoraa yhteyttä ERP-järjestelmään.
3. I3Agentilla ei ole SSH- tai hallintayhteyttä tuotantoon.
4. I4Agentti ei säilytä mallipalveluntarjoajan API-avainta.
5. I5Agentti käyttää liiketoimintajärjestelmiä vain työkalu- ja API-yhdyskäytävän kautta.
6. I6Lukeminen, hyväksyminen ja kirjoittaminen on erotettu toisistaan eri palveluihin ja identiteetteihin.
7. I7Julkiseen internetiin suuntautuva liikenne kulkee vain erikseen hallitun yhdyskäytävän kautta.
8. I8Jokainen sallittu ja estetty Tailscale-yhteys testataan.
9. I9Agentin verkkopääsy voidaan poistaa keskitetysti.
10. I10Agentin tekemät toiminnot voidaan yhdistää verkko-, työkalu- ja sovelluslokeihin.

Referenssiarkkitehtuuri

Alla oleva arkkitehtuuri soveltuu esimerkiksi laskuja, tukipyyntöjä, asiakasdataa tai muita sisäisiä liiketoimintaprosesseja käsittelevälle agentille.

Arkkitehtuurissa agentti on tietoisesti matalan luottamuksen työkuorma.

Agentti saa käsitellä epäluotettavaa sisältöä ja muodostaa ehdotuksia, mutta se ei saa suoraa yhteyttä korkean vaikutuksen järjestelmiin.

get_invoice(invoice_id)
get_supplier(supplier_id)
create_invoice_draft(invoice_data)
request_payment_approval(payment_data)

GET /invoices/7421

SELECT * FROM invoices;

{
  "action": "create-payment",
  "invoice_id": "7421",
  "recipient": "FI00 0000 0000 0000 00",
  "amount_eur": 1240.00
}

Agentin identiteetti ja tagirakenne

Tailscalessa palvelimet, kontit, automaatio ja muut ei-henkilökohtaiset laitteet voidaan tunnistaa tageilla.

Tagi ei ole vain kuvaileva etiketti. Sitä käytetään työkuorman identiteettinä ja Grants-politiikan lähde- tai kohdeselektorina. Kun laite merkitään tagilla, sitä käsitellään tagi-identiteettinä käyttäjän henkilökohtaisen identiteetin sijasta. [6]

Geneeristä tagia kannattaa välttää:

tag:ai-agent

Se ei kerro, mitä agentti tekee, missä ympäristössä se toimii, onko sillä luku- vai kirjoitusoikeuksia tai mihin järjestelmään se liittyy.

Parempi tagi voisi olla:

tag:ai-agent-invoice-prod

Tai vielä tarkemmin:

tag:ai-invoice-reader-prod
tag:ai-invoice-drafter-prod
tag:ai-payment-executor-prod

Yksi identiteetti yhtä tarkoitusta varten

Kehitys-, testi- ja tuotantoympäristöjä ei pidä yhdistää samaan identiteettiin:

tag:ai-agent-invoice-dev
tag:ai-agent-invoice-test
tag:ai-agent-invoice-prod

Samoin luku- ja kirjoitustoiminnot kannattaa erottaa:

tag:ai-invoice-reader-prod
tag:ai-invoice-write-executor-prod

Tailscale-tagien oikeudet yhdistyvät additiivisesti. Jos laitteelle annetaan useita tageja, kaikkien tagien kautta saadut oikeudet voivat tulla voimaan. Tagien yhdistelmää ei voi tavallisessa säännössä käsitellä vaatimuksena “tagi A ja tagi B”, joten selkeitä yhdistelmätageja kannattaa käyttää epäselvien monen tagin yhdistelmien sijasta. [6]

tag:ai-agent
tag:production
tag:finance

tag:ai-finance-agent-prod

Tagin myöntämisoikeus on korkean riskin oikeus

tagOwners määrittelee, kuka saa liittää laitteen tiettyyn tagi-identiteettiin.

Jos hyökkääjä voi itse antaa työkuormalleen tagin:

tag:ai-write-executor-prod

hän voi mahdollisesti saada myös kyseiselle identiteetille kuuluvat verkkopolut.

Tagien myöntämisoikeudet pitää siksi rajata esimerkiksi tietoturvan ylläpitoryhmälle tai erilliselle hallitulle automaatiolle. tagOwners delegoi sen, kuka saa antaa identiteetin tavallisessa työnkulussa; tailnetin Owners-, Admins- ja Network admins -rooleissa toimivat ylläpitäjät voivat hallintaroolinsa perusteella antaa minkä tahansa tagin. Tagin omistajuus ei itsessään anna verkkopääsyä, vaan se määritetään erikseen Grants-osiossa. [6] [7]

Pienin toimiva Grants-toteutus

Ensimmäinen versio voidaan rakentaa yhdellä agentilla ja yhdellä yhdyskäytävällä.

Havainnollistava Tailscale-politiikka:

{
  "groups": {
    "group:security-admins": [
      "security-admin@example.com"
    ]
  },

  "tagOwners": {
    "tag:ai-agent-read-prod": [
      "group:security-admins"
    ],
    "tag:ai-tool-gateway-prod": [
      "group:security-admins"
    ],
    "tag:prod-db": [
      "group:security-admins"
    ],
    "tag:prod-admin": [
      "group:security-admins"
    ]
  },

  "grants": [
    {
      "src": [
        "tag:ai-agent-read-prod"
      ],
      "dst": [
        "tag:ai-tool-gateway-prod"
      ],
      "ip": [
        "tcp:443"
      ]
    }
  ],

  "tests": [
    {
      "src": "tag:ai-agent-read-prod",
      "proto": "tcp",
      "accept": [
        "tag:ai-tool-gateway-prod:443"
      ],
      "deny": [
        "tag:prod-db:5432",
        "tag:prod-admin:22"
      ]
    }
  ]
}

Politiikassa on kolme erillistä asiaa.

tagOwners

"tagOwners": {
  "tag:ai-agent-read-prod": [
    "group:security-admins"
  ]
}

Vain määritetty tietoturvaryhmä saa liittää laitteen agentin identiteettiin.

grants

{
  "src": [
    "tag:ai-agent-read-prod"
  ],
  "dst": [
    "tag:ai-tool-gateway-prod"
  ],
  "ip": [
    "tcp:443"
  ]
}

Agentti saa muodostaa TCP-yhteyden yhdyskäytävän porttiin 443.

Tämä sääntö ei anna agentille pääsyä muihin yhdyskäytävän portteihin, tietokantaan, ylläpitopalvelimelle tai muihin tailnetin laitteisiin.

tests

{
  "src": "tag:ai-agent-read-prod",
  "proto": "tcp",
  "accept": [
    "tag:ai-tool-gateway-prod:443"
  ],
  "deny": [
    "tag:prod-db:5432",
    "tag:prod-admin:22"
  ]
}

Testi osoittaa sekä sallitun että estetyt yhteydet.

Tailscale suorittaa politiikkatiedostoon määritellyt testit politiikkamuutosten yhteydessä. Jos testin oletus ei täyty, politiikkamuutos hylätään. Testit ovat erityisen tärkeitä, koska Grants-säännöt ovat additiivisia: jokin toinen liian laaja sääntö voi vahingossa antaa agentille enemmän pääsyä kuin sen oma tarkasti rajattu sääntö antaa ymmärtää. [7]

Tuotantotasoinen Grants-referenssipolitiikka

Seuraavassa esimerkissä toteutetaan koko referenssiarkkitehtuuri.

Käytetyt identiteetit ovat:

tag:ai-agent-invoice-prod
tag:ai-llm-gateway-prod
tag:ai-tool-gateway-prod
tag:ai-read-api-prod
tag:ai-approval-api-prod
tag:ai-write-executor-prod
tag:erp-api-prod
tag:prod-db
tag:prod-admin

Havainnollistava politiikka:

{
  "groups": {
    "group:security-admins": [
      "security-admin@example.com"
    ]
  },

  "tagOwners": {
    "tag:ai-agent-invoice-prod": [
      "group:security-admins"
    ],
    "tag:ai-llm-gateway-prod": [
      "group:security-admins"
    ],
    "tag:ai-tool-gateway-prod": [
      "group:security-admins"
    ],
    "tag:ai-read-api-prod": [
      "group:security-admins"
    ],
    "tag:ai-approval-api-prod": [
      "group:security-admins"
    ],
    "tag:ai-write-executor-prod": [
      "group:security-admins"
    ],
    "tag:erp-api-prod": [
      "group:security-admins"
    ],
    "tag:prod-db": [
      "group:security-admins"
    ],
    "tag:prod-admin": [
      "group:security-admins"
    ]
  },

  "grants": [
    {
      "src": [
        "tag:ai-agent-invoice-prod"
      ],
      "dst": [
        "tag:ai-llm-gateway-prod",
        "tag:ai-tool-gateway-prod"
      ],
      "ip": [
        "tcp:443"
      ]
    },
    {
      "src": [
        "tag:ai-tool-gateway-prod"
      ],
      "dst": [
        "tag:ai-read-api-prod",
        "tag:ai-approval-api-prod"
      ],
      "ip": [
        "tcp:443"
      ]
    },
    {
      "src": [
        "tag:ai-approval-api-prod"
      ],
      "dst": [
        "tag:ai-write-executor-prod"
      ],
      "ip": [
        "tcp:443"
      ]
    },
    {
      "src": [
        "tag:ai-write-executor-prod"
      ],
      "dst": [
        "tag:erp-api-prod"
      ],
      "ip": [
        "tcp:443"
      ]
    }
  ],

  "tests": [
    {
      "src": "tag:ai-agent-invoice-prod",
      "proto": "tcp",
      "accept": [
        "tag:ai-llm-gateway-prod:443",
        "tag:ai-tool-gateway-prod:443"
      ],
      "deny": [
        "tag:ai-read-api-prod:443",
        "tag:ai-approval-api-prod:443",
        "tag:ai-write-executor-prod:443",
        "tag:erp-api-prod:443",
        "tag:prod-db:5432",
        "tag:prod-admin:22"
      ]
    },
    {
      "src": "tag:ai-tool-gateway-prod",
      "proto": "tcp",
      "accept": [
        "tag:ai-read-api-prod:443",
        "tag:ai-approval-api-prod:443"
      ],
      "deny": [
        "tag:ai-write-executor-prod:443",
        "tag:erp-api-prod:443",
        "tag:prod-db:5432",
        "tag:prod-admin:22"
      ]
    },
    {
      "src": "tag:ai-approval-api-prod",
      "proto": "tcp",
      "accept": [
        "tag:ai-write-executor-prod:443"
      ],
      "deny": [
        "tag:erp-api-prod:443",
        "tag:prod-db:5432",
        "tag:prod-admin:22"
      ]
    },
    {
      "src": "tag:ai-write-executor-prod",
      "proto": "tcp",
      "accept": [
        "tag:erp-api-prod:443"
      ],
      "deny": [
        "tag:prod-db:5432",
        "tag:prod-admin:22"
      ]
    }
  ]
}

Grant 1: agentti saa tavoittaa vain kaksi yhdyskäytävää

{
  "src": [
    "tag:ai-agent-invoice-prod"
  ],
  "dst": [
    "tag:ai-llm-gateway-prod",
    "tag:ai-tool-gateway-prod"
  ],
  "ip": [
    "tcp:443"
  ]
}

Agentti voi käyttää hyväksyttyä mallipalvelua ja hyväksyttyjä työkaluja.

Se ei voi ottaa suoraa yhteyttä luku-APIin, hyväksyntäpalveluun, kirjoitustoimintojen suorittajaan, ERP-järjestelmään, tietokantaan tai ylläpitopalvelimeen.

Grant 2: työkalu-API saa lukea ja muodostaa hyväksyntäpyynnön

{
  "src": [
    "tag:ai-tool-gateway-prod"
  ],
  "dst": [
    "tag:ai-read-api-prod",
    "tag:ai-approval-api-prod"
  ],
  "ip": [
    "tcp:443"
  ]
}

Työkalu-API voi hakea rajattua tietoa ja jättää ehdotuksen hyväksyttäväksi. Se ei kuitenkaan voi suorittaa kirjoitusoperaatiota suoraan.

Grant 3: hyväksyntäpalvelu saa käynnistää kirjoitustoiminnon

{
  "src": [
    "tag:ai-approval-api-prod"
  ],
  "dst": [
    "tag:ai-write-executor-prod"
  ],
  "ip": [
    "tcp:443"
  ]
}

Vain hyväksyntäpalvelulla on verkkopolku kirjoitustoimintojen suorittajaan. Agentilla tai työkalu-APIlla ei ole tätä polkua.

Grant 4: suorittaja saa käyttää vain ERP:n rajattua APIa

{
  "src": [
    "tag:ai-write-executor-prod"
  ],
  "dst": [
    "tag:erp-api-prod"
  ],
  "ip": [
    "tcp:443"
  ]
}

Kirjoitustoimintojen suorittaja saa käyttää ERP:n APIa mutta ei tuotantotietokantaa tai ylläpitopalvelinta.

Tämän vuoksi ERP:n API voi toteuttaa toimintokohtaisen valtuutuksen, objektitason käyttöoikeuden, määrärajoitukset, idempotenssin, tapahtumalokin ja palautettavuuden.

Verkkopolitiikka ei korvaa sovelluksen valtuutusta

Tavallinen Tailscale Grant voi sallia yhteyden:

tag:ai-tool-gateway-prod
    →
tag:ai-read-api-prod:443

Grant ei yksin ratkaise, mitä HTTP-metodia tai API-operaatiota yhdyskäytävä saa käyttää:

GET    /invoices/7421
POST   /payments
DELETE /suppliers/91

Verkkokerros vastaa kysymykseen: saako lähde muodostaa verkkoyhteyden kohteeseen?

Sovelluskerros vastaa kysymykseen: mitä lähde saa tehdä yhteyden muodostamisen jälkeen?

Tailscale Grants tukee myös sovelluskohtaisia capability-määrittelyitä, mutta kohdesovelluksen pitää itse toteuttaa ja tulkita kyseiset oikeudet. Tailscale käsittelee sovelluscapabilityn parametreja läpinäkymättömänä JSON-datana eikä toimeenpane sovelluksen liiketoimintalogiikkaa. [2]

Turvalliseen kokonaisuuteen tarvitaan siksi vähintään kolme valtuutuskerrosta:

1. Tailscale-verkkopolitiikkaSaako agentti tavoittaa palvelun?
2. Työkalu- ja API-yhdyskäytävän politiikkaSaako agentti käyttää kyseistä työkalua kyseisillä parametreilla?
3. Kohdesovelluksen oma valtuutusSaako palvelu lukea tai muuttaa juuri tätä liiketoimintaobjektia?

Sulje Tailscalen ohittavat yhteyspolut

Tailscale-politiikka suojaa Tailscale-liikennettä. Se ei automaattisesti estä palvelua olemasta tavoitettavissa myös julkisella IPv4- tai IPv6-osoitteella, pilvipalvelun sisäverkossa, paikallisessa LAN-verkossa, Kubernetes-klusterin normaalissa palveluverkossa tai toisella verkkoliittymällä.

Tailscale Grants ei muuta sitä, mitä laite voi tavoittaa paikallisessa verkossa Tailscalen ulkopuolella. Jos tietokanta on saavutettavissa suoraan tavallisen aliverkon kautta, agentti saattaa ohittaa tarkasti rajatun tailnet-politiikan kokonaan. [8]

Sulje julkinen ingress

Sisäisen API-palvelun ei pidä kuunnella avoimesti kaikilla verkkoliittymillä, kuten 0.0.0.0:443, ellei julkista yhteyttä ole erikseen tarkoitettu.

Palvelu voidaan sitoa localhostiin tai Tailscale-IP-osoitteeseen, suojata host-palomuurilla tai pilvipalvelun security groupilla, julkaista tailnetiin Tailscale Servellä tai liittää verkkoon sovellukseen upotetulla tsnet-identiteetillä.

Tailscale Serve voi tuoda localhostissa toimivan palvelun tailnetin sisäiseen käyttöön siten, että tailnetin pääsypolitiikka säilyy käytössä. Tailscale Funnel puolestaan julkaisee palvelun julkiseen internetiin, joten sitä ei pidä sekoittaa yksityiseen agenttiarkkitehtuuriin. [9]

Sulje tavallinen internet-egress

Tailscale Grant ei oletusarvoisesti säätele agentin tavallista, Tailscalen ulkopuolista internet-liikennettä. Jos agentin käyttöjärjestelmällä on normaali oletusreitti internetiin, se voi muodostaa HTTPS-yhteyden ulkoiseen kohteeseen ilman, että yhteys kulkee Tailscale-politiikan kautta.

Agentin internet-egress pitää rajata erikseen esimerkiksi pilvialustan tai käyttöjärjestelmän palomuurilla, Kubernetes NetworkPolicyllä, egress proxylla, erillisellä verkkonimiavaruudella, kontrolloidulla NAT gatewaylla tai hallitulla exit nodella ja sen takana olevalla palomuurilla.

AI-agentti
    │
    │ Tailscale
    ▼
Sisäinen LLM-yhdyskäytävä
    │
    │ hallittu egress
    ▼
Hyväksytty mallipalveluntarjoaja

Tällöin vain LLM-yhdyskäytävällä on oikeus muodostaa yhteys mallipalveluntarjoajaan.

Tailscale App Connectors voi reitittää määritettyjen SaaS-palveluiden liikennettä hallitun ulospääsyn kautta ja tarjota ennustettavan julkisen lähdeosoitteen. Pelkkä App Connector ei kuitenkaan tee reitistä pakollista, jos työkuormalla on edelleen toinen avoin internet-reitti. [10]

Exit node voi keskittää internet-liikenteen yhden pisteen kautta. Sen käyttöoikeus määritellään erikseen autogroup:internet-kohteen avulla, mutta varsinainen kohde- tai domain-rajaus pitää edelleen toteuttaa exit noden palomuurissa, välityspalvelimessa tai muussa egress-kontrollissa. [11]

Miten agentti liitetään Tailscaleen?

Toteutustapa riippuu agentin suoritusympäristöstä ja elinkaaresta.

Agenttikontti
      │
      │ localhost / konttiverkko
      ▼
Tailscale-sidecar
      │
      ▼
Tailnet

Sama fyysinen palvelin:

invoice-reader   → oma tsnet-identiteetti
invoice-writer   → oma tsnet-identiteetti
reporting-agent  → oma tsnet-identiteetti
admin-tool       → oma tsnet-identiteetti

Testaa politiikka kolmella tasolla

Pelkkä onnistunut demo ei osoita turvallista arkkitehtuuria. Testauksen pitää kattaa vähintään kolme tasoa:

1. Staattinen politiikkatestiToteuttaako Grants-politiikka tarkoitetun yhteysmatriisin?
2. Todellinen verkkoyhteystestiToimivatko sekä sallitut että estetyt polut oikeassa ympäristössä?
3. Sovellus- ja toimintotason testiRajataanko työkalut, objektit ja hyväksynnät oikein yhteyden jälkeen?

1. Tailscale-politiikkatestit

Politiikkatiedoston tests-osio varmistaa, että Grants-politiikka tuottaa tarkoitetun yhteysmatriisin.

{
  "src": "tag:ai-agent-invoice-prod",
  "proto": "tcp",
  "accept": [
    "tag:ai-tool-gateway-prod:443"
  ],
  "deny": [
    "tag:erp-api-prod:443",
    "tag:prod-db:5432",
    "tag:prod-admin:22"
  ]
}

Testi pitää ajaa osana jokaista politiikkamuutosta. Positiivisen testin lisäksi tarvitaan eksplisiittisiä negatiivisia testejä. Muuten jokin toinen laaja Grant voi sallia yhteyden ilman, että agentin oma sääntö muuttuu.

2. Todelliset verkkoyhteystestit

Politiikan lisäksi yhteydet pitää testata oikeasta agentin suoritusympäristöstä.

3. Sovellustason testit

Toimiva verkkoyhteys yhdyskäytävään ei vielä todista, että sovellusvaltuutus toimii.

Tailscale-politiikkatestit osoittavat tailnetin verkkotason saavutettavuuden. Ne eivät testaa API:n liiketoimintalogiikkaa, kohdetietueiden käyttöoikeuksia tai ihmisen hyväksynnän oikeellisuutta.

Lokitus: mitä pitää pystyä todistamaan?

Yhdestä agenttiajosta pitäisi muodostua yhdistettävä tapahtumaketju. Sama korrelaatiotunniste, esimerkiksi run_id: ai-run-2026-07-28-000142, liitetään agentin suorituslokiin, LLM-yhdyskäytävän lokiin, työkalu-API:n lokiin, hyväksyntäobjektiin, kirjoitustoiminnon lokiin ja kohdesovelluksen tapahtumalokiin.

Tällöin voidaan jälkikäteen selvittää, kuka käynnisti tehtävän, mikä agentti suoritti sen, mitä mallia ja työkaluja käytettiin, mihin verkkokohteisiin muodostettiin yhteys, mitä tietoja luettiin, kuka hyväksyi toiminnon ja mitä järjestelmään muutettiin.

Tailscalen konfiguraatioauditointi

Tailscalen auditointiloki tallentaa hallinnollisia muutoksia: kuka muutti politiikkaa, mitä asetusta muutettiin, milloin muutos tehtiin sekä mikä oli politiikan aikaisempi ja uusi tila. Tämä auttaa osoittamaan, milloin agentin pääsyoikeuksia muutettiin ja kuka muutoksen teki. [15]

Network flow logs

Network flow logs tallentaa yhteyksien metadataa, kuten lähde- ja kohdesolmun, protokollan, portin ja siirretyn datamäärän. Se ei tallenna liikenteen sisältöä. Ominaisuus kuuluu tällä hetkellä Premium- ja Enterprise-paketteihin, Tailscale säilyttää uusimmat 30 päivää ja tiedon muodostuminen edellyttää tuettua telemetriaa lähettävää asiakasohjelmaa.

Flow-lokeja ei pidä käsitellä täydellisenä estettyjen yhteysyritysten lokina tai itsenäisenä IDS-, SIEM- tai reaaliaikaisena uhkien tunnistusjärjestelmänä. Estettyjen yritysten todentamiseen tarvitaan käyttötapauksen mukaan vastaanottavan laitteen paikallisia Tailscale-lokeja, host-palomuuria, egress-palomuuria tai yhdyskäytävän omia lokeja. [16]

Premium- ja Enterprise-paketteihin kuuluva log streaming voi lähettää tuetut auditointi- ja verkkolokit keskitettyyn säilytykseen tai SIEM-järjestelmään. [17]

Toteuta oikea pysäytysmekanismi

Agentin pysäyttäminen ei saa riippua siitä, vastaako agentti enää hallintakäskyihin. Pysäytyksen pitää olla agentin ulkopuolella.

1. Pysäytä agentin työkuorma.
2. Poista agentin Tailscale-laite tai sitä koskevat Grants-oikeudet.
3. Peruuta agentin sovellus- ja API-tunnukset.
4. Estä agentin internet-egress.
5. Estä uudet työkalukutsut yhdyskäytävässä.
6. Säilytä lokit tutkintaa varten.
7. Kierrätä tai peruuta paljastuneet auth key -avaimet, API-tokenit ja muut tunnistetiedot.
8. Palauta agentin tekemät muutokset.

Pelkkä alkuperäisen Tailscale auth keyn peruuttaminen ei automaattisesti poista sillä jo tailnetiin liitetyn laitteen oikeuksia. Auth key on laitteen rekisteröintiin käytetty tunniste; rekisteröidyllä solmulla on sen jälkeen oma erillinen laite- ja avainelinkaarensa. Solmu pitää tarvittaessa poistaa tai sen pääsypolitiikka muuttaa. [18]

Samoin Tailscale-verkkopääsyn poistaminen ei yksin peruuta agentin jo saamia sovellustunnuksia. Verkkoidentiteetti ja sovellustunnukset pitää pystyä peruuttamaan toisistaan riippumatta.

Yleisimmät virheet

Valinnainen jatkokehitys: vakaa palveluidentiteetti

Tuotantoympäristössä työkalu-APIsta tai LLM-yhdyskäytävästä voi olla useita rinnakkaisia instansseja. Tailscale Services mahdollistaa vakaan palveluidentiteetin erottamisen yksittäisistä palvelimista.

{
  "src": [
    "tag:ai-agent-invoice-prod"
  ],
  "dst": [
    "svc:ai-tool-gateway"
  ],
  "ip": [
    "tcp:443"
  ]
}

Agentti käyttää vakaata palvelunimeä, ja palvelu voidaan toteuttaa usealla tagilla tunnistetulla ja hyväksytyllä isännällä. Tämä helpottaa instanssien vaihtamista ja korkean käytettävyyden rakentamista ilman, että agentin politiikka sidotaan yhteen palvelimeen. Tailscale Services tukee tällä hetkellä TCP-palveluita, joten protokolla-, asiakasversio- ja isäntien hyväksyntävaatimukset pitää tarkistaa ennen mallin käyttöönottoa. [19]

Milloin agentin verkkoalue on tuotantovalmis?

Agentin verkkoalue ei ole tuotantovalmis vain siksi, että Tailscale on asennettu. Uuden tailnetin alkuperäinen oletuspolitiikka voi sallia laitteiden välisen liikenteen laajasti. Vähimmän oikeuden Grants-politiikka, tagien omistajuus ja politiikkatestit pitää suunnitella erikseen. [3] [23]

Tuotantovalmiudesta pitäisi pystyä osoittamaan vähintään seuraavat asiat:

• Agentilla on oma tarkoitussidonnainen työkuormaidentiteetti.
• Kehitys-, testi- ja tuotantoympäristöt on erotettu.
• Tagien myöntämisoikeudet on rajattu.
• Agentilla on vain nimetyt kohteet, protokollat ja portit.
• Agentilla ei ole suoraa tietokanta- tai ylläpitoyhteyttä.
• Luku-, hyväksyntä- ja kirjoituspolut on erotettu.
• Sovellusvaltuutus toimii verkkopolitiikan lisäksi.
• Julkiset ja paikallisen verkon ohitusreitit on suljettu.
• Internet-egress on rajattu erillisellä kontrollilla.
• Politiikassa on sekä hyväksyviä että estäviä testejä.
• Testit kattavat koko politiikan additiiviset vaikutukset.
• Todelliset end-to-end-yhteydet on testattu.
• Verkko-, agentti-, työkalu- ja sovelluslokit voidaan yhdistää.
• Pysäytys ja tunnusten peruutus on testattu.
• Muutokselle on dokumentoitu palautustapa.
• Agentin pääsypolulla on nimetty omistaja.

Turvallinen verkkoalue on vahingon raja

AI-agentin turvallisuutta ei voida rakentaa sen oletuksen varaan, että malli ymmärtää aina käyttäjän tarkoituksen, tunnistaa kaikki haitalliset ohjeet ja valitsee kaikissa tilanteissa turvallisen toiminnon.

Verkkokerroksessa voidaan kuitenkin toteuttaa deterministinen raja:

Tailscale toteuttaa tässä arkkitehtuurissa työkuorman identiteetin, salatun yhteyskerroksen ja tarkasti rajatun verkkosaavutettavuuden. Sovellus, API gateway, hyväksyntäpalvelu, palomuuri ja valvonta toteuttavat muut kerrokset.

Tailscale ei korvaa sovelluksen autentikointia, datan käyttöoikeuksia, haavoittuvuuksien hallintaa, EDR-järjestelmää, SIEM-ratkaisua tai poikkeamiin reagointia. Asiakas vastaa myös laitteiden päivityksistä, identiteetinhallinnasta, tagien ja ryhmien hallinnasta sekä tarkoituksenmukaisesta pääsypolitiikasta. [3]

Hyvä ensimmäinen toteutus on tarkoituksella pieni:

Defense First tunnistaa asiakkaan todellisen pääsypolun, mallintaa tavoitetilan, toteuttaa sen Tailscale Grants -politiikalla ja tuottaa sekä sallittujen että estettyjen yhteyksien testit, dokumentaation ja palautussuunnitelman. [20]