Miksi tekoälypohjaisessa infrastruktuurissa tarvitaan näyttöä, ei pelkkää lupaa

Infrastruktuurin muutokset olivat aiemmin suoraviivaisia. Vanhempi kehittäjä kirjautui palvelimelle ja suoritti komennon, toivoen dokumentaation olevan ajan tasalla. Nyt tekoälyagentit hoitavat yhä monimutkaisempia tehtäviä – migraatioita, kapasiteetin säätöä ja tietoturvapäivityksiä. Siksi tarvitsemme keinoja varmistaa, että nämä toimenpiteet ovat turvallisia jo ennen niiden suorittamista.

Perinteiset suojausmallit eivät enää riitä.

RBAC ei vastaa tekoälyn aikakauden kysymyksiin

Nykyiset tuotantoympäristön suojaukset perustuvat usein kahteen asiaan:

RBAC määrittelee, kuka saa kirjoittaa tuotantoon. GitOps taas kertoo, mikä on tavoitetila.

Kumpikaan ei kuitenkaan vastaa olennaiseen kysymykseen: miksi juuri tämä muutos on turvallinen juuri nyt?

Ihmisellä on kokemusta ja harkintakykyä. Tekoälyagentilla ei ole. Kun agentti ehdottaa muutosta – erityisesti jotain peruuttamatonta kuten tietokannan migraatiota – järjestelmä tarkistaa vain oikeudet, ei perusteluja.

Tämä on ongelmallista etenkin tilallisissa toiminnoissa. Skeeman muutos tai datan siirto koostuu sarjasta riippuvuuksia ja aikarajoitteita, joita pelkkä käyttöoikeusjärjestelmä ei ymmärrä.

Näyttöön perustuva muutoksenhallinta

Parempi tapa on kääriä jokainen ehdotettu muutos kryptografiseen todisteeseen ennen suorittamista. Tätä voisi kutsua infrastruktuurin muutoksen allekirjoitukseksi.

Työnkulku etenee seuraavasti:

1. Agentti ehdottaa muutosta ja perustelee sen
2. Järjestelmä rakentaa kryptografisen todisteen muutoksen turvallisuudesta
3. Policy-moottori arvioi, täyttääkö muutos säännöt
4. Todiste varmennetaan – onko allekirjoitus ehjä, onko tietoa muutettu?
5. Muutos suoritetaan vain, jos kaikki tarkistukset läpäistään
6. Kaikki tallennetaan lokiin, josta toimenpide voidaan tarvittaessa toistaa

Todiste sisältää muun muassa:

• Kuivaharjoittelun tulokset oikeaa infrastruktuuria vastaan
• Poikkeamien havaitsemisen (onko tila odotettu?)
• Turvallisuustarkistukset ja SBOM-tiedot
• Kuvatiedostojen tiivisteet ja alkuperätiedot
• Vaikutusarvioinnin palvelutasotavoitteisiin
• Tapahtumaketjun eheyden tarkistuksen

Kaikki allekirjoitetaan, aikaleimataan ja tallennetaan julkaisutiedostojen yhteyteen.

Esimerkki: Oraclesta PostgreSQL:ään

Kuvittele tilanne, jossa tuotantokuormaa siirretään Oracle/APEX-järjestelmästä PostgreSQL:ään Kubernetes-ympäristöön. Kyse ei ole demosta, vaan oikeasta datan siirrosta.

Prosessi sisältää muun muassa:

• Klusterin valmiuden varmistamisen
• Muutosikkunan hyväksynnät
• Lähtöjärjestelmän jäädyttämisen
• Datan viennin ja palautuspisteiden luonnin
• Skeeman laajentamisen ja varjotaulujen asetuksen
• Rivikohtaisen tarkistuksen
• Liikenteen ohjauksen uudelleen
• Jälkivalidoinnin ja auditointilokin viennin

Tämä ei ole yksinkertainen kubectl apply. Kyseessä on monivaiheinen prosessi, jossa virheet eivät ole sallittuja.

Kun agentti pyytää tämän suorittamista, todiste sisältää 23 validointitarkistusta, 20 tapahtumaa ja 20 erillistä todistetta. Kaikki allekirjoitetaan ed25519-avaimella, ja myöhemmin voidaan tarkistaa komennolla torque proof verify --require-signature.

Kaksoistarkistus estää virheet

Pelkkä todiste ei kuitenkaan riitä. Järjestelmä vaatii myös eksplisiittisen luvan. Testeissä agentin pyyntö hylättiin kahdesti:

Ensimmäisellä kerralla puuttui sallittujen operaatioiden lista. Todiste oli kunnossa, mutta policy ei antanut lupaa.

Toisella kerralla joku oli muokannut todistetta. Allekirjoitus ei täsmännyt, ja muutos estettiin.

Tässä on kyse syvästä puolustuksesta tekoälyn aikakaudella. Sekä todiste että policy tarvitaan – kumpikaan yksinään ei riitä.

Mitä tämä tarkoittaa käytännössä

Perinteiset GitOps- ja RBAC-työkalut, kuten Argo CD ja Crossplane, on suunniteltu ennen autonomisten agenttien yleistymistä. Ne kertovat, kuka saa kirjoittaa ja mikä on tavoitetila, mutta eivät osaa perustella, miksi muutos on turvallinen juuri nyt.

Kun siirryt kohti tekoälyavusteisia käyttöönottoja, autonomista skaalausta tai monipilvimigraatioita, tarvitset infrastruktuurin, joka voi selittää jokaisen muutoksen kryptografisesti.

Seuraavat askeleet

Jos käytät Kubernetesia tuotannossa ja teet monimutkaisia migraatioita tai tekoälypohjaisia operaatioita, kannattaa harkita seuraavia asioita:

1. Miten järjestelmä voi luoda kryptografista näyttöä muutoksen turvallisuudesta?
2. Miten policy määritellään koodina eksplisiittisiksi sallittujen operaatioiden listoiksi?
3. Miten luodaan allekirjoitettuja ja toistettavia auditointilokeja?
4. Miten muutoksen turvallisuus voidaan mitata numeerisesti?

Infrastruktuurin maailma siirtyy kohti autonomisia operaatioita. Myös muutoksenhallinnan on muututtava – luvista näyttöön.