Haastattelut
Jacob Ideskog, CTO of Curity – Haastattelusarja

Jacob Ideskog on identiteetin erikoisosaaja ja CTO Curityssa. Suurin osa ajastaan hän viettää työskentelemällä turvallisuusratkaisujen parissa API- ja web-tilassa. Hän on työskennellyt sekä OAuth- ja OpenID Connect -ratkaisujen suunnittelussa että toteutuksessa sekä suurten yritysten että pienien startup-yhtiöiden kanssa.
Curity on moderni identiteetin ja pääsytason hallintajärjestelmä (IAM), joka on rakennettu Curity Identity Serverin ympärille, joka on standardipohjainen ratkaisu, joka on suunniteltu suojelemaan todennusta ja valtuutusta sovelluksille, API:lle ja digitaalisille palveluille suuressa mittakaavassa. Se tukee protokollia kuten OAuth 2.0 ja OpenID Connect keskitettynä kirjautumisvirran hallintaan, hienojakoinen pääsykäytäntöjen pakottamiseen ja turvallisten tokenien myöntämiseen sekä ihmisille että koneille, mukaan lukien API:t ja palvelut. Alusta on suunniteltu joustavuutta ja skaalautuvuutta varten, jolloin organisaatiot voivat ottaa sen käyttöön pilvi-, hybridi- tai paikallisympäristössä, integroida sen olemassa oleviin järjestelmiin ja tarjota turvallisia, vaivattomia käyttökokemuksia ilman, että tarvitsevat mukautettua turvallisuusinfrastruktuuria.
Olet viettänyt suurimman osan urastasi identiteetin ja API-turvalisuuden järjestelmien rakentamisessa, Curityn perustamisesta sen CTO:na pilven, nyt AI:n nousun kautta. Miten tämä matka on muovannut näkemyksesi siitä, että AI-välikohteen tulisi kohdella ensisijaisesti digitaalisina identiteetteinä eikä vain ohjelmistona?
Koko urani aikana yksi asia on jatkuvasti nousanut esiin. Riippumatta siitä, työskentelenkö pilvilaskennassa tai nyt AI:ssa, jos ohjelmisto toimii jonkun tai jonkin muun järjestelmän puolesta, sinulla on identiteettiongelma.
Agenteille AI:n laajamittainen omaksuminen korostaa tätä ongelmaa. Heidän käyttäytyminen ei ole enää tiukasti kirjoitettu, ja he toimivat autonomian tasolla, jota yritykset eivät ole koskaan nähneet aiemmin. AI-välikohteet tekevät päätöksiä, kutsuvat API:ta ja ketjuja toimintoja useiden järjestelmien yli – usein ilman suoraa ihmisen valvontaa. Tämä käyttäytyminen luo identiteetti- ja pääsyhaasteita, jotka ovat perustavanlaatuisesti erilaisia kuin perinteinen ohjelmisto.
AI-välikohteiden käsittely ensisijaisina digitaalisina identiteetteinä on ainoa tapa, jolla voidaan puuttua tähän asianmukaisesti. Jos organisaatiot kohdeltavat niitä vain prosessina tai palvelutilinä, he menettävät nopeasti näkyvyyden ja valvonnan – ja se on resepti turvallisuuskriisille.”
Monet yritykset ovat innoissaan agenteista AI:sta, mutta jäävät jumiin kokeiluvaiheeseen. Mitä yleisimpiä identiteetti- ja hallintoaukkoja näet todellisissa käyttöönotoissa, jotka estävät organisaatioita skaalaamasta agentteja turvallisesti?
Suurin osa kokeilusta tapahtuu eristetyissä hiekkalaatikkoissa, jotka jättävät huomiotta, mitä tapahtuu suuressa mittakaavassa. Varhaisissa koekäytöissä tiimit usein antavat agenteille laajat API-avaimet, jaettuja tunnistetietoja tai pilven laajat käyttöoikeudet vain saadakseen asiat liikkeelle.
Tämä lähestymistapa hajoaa hetkeäkään, kun agentit otetaan käyttöön koekäytön ulkopuolella. Tämä johtuu siitä, että turvallisuustiimit eivät voi nähdä, mihin dataa agentti on käyttänyt, mitä toimintoja se on suorittanut tai voivatko ne ylittää tarkoituksensa – tahallisesti tai tahattomasti. Nämä sokeat pisteet tekevät siitä mahdottoman hallita agentteja turvallisesti, miksi monet organisaatiot kamppailevat siirtymisen kanssa koekäytöstä.
Olet väittänyt, että tiukat varotoimet ovat välttämättömiä agenteille AI:sta. Miltä “hyvä” identiteetin suunnittelu näyttää käytännössä AI-agenteille, ja mihin yritykset yleensä menevät väärään?
Hyvä identiteetin suunnittelu alkaa vähimmän etuoikeuden periaatteesta ja lupauksista, jotka liittyvät selkeään aikomukseen. Jokaisella AI-agentilla tulisi olla oma identiteetti, kapeat käyttöoikeudet ja selkeästi määritellyt luottamussuhteet (selkeät säännöt siitä, mitä järjestelmiä sille on sallittu vuorovaikuttaa). Perimmältään pääsy tulisi olla tarkoituksenmukainen, aikarajoitettu ja helppo perua.
Yritykset menevät väärään olettaessa, että sisäiset agentit ovat turvallisia oletuksena. Tämä oletus ei pidä paikkaansa todellisia uhkia vastaan. Vääräkäytössä olevat toimijat etsivät aktiivisesti juuri näitä heikkoja kohtia, ja AI-agentit lisäävät merkittävästi potentiaalisen vaikutusalueen, kun identiteetin suunnittelu on laiska.”
Curity on työskennellyt pitkään avoimien standardien kanssa, kuten OAuth ja OpenID Connect. Kuinka kriittisiä avoimet identiteettistandardit ovat agenteille AI:n tekemisessä yhteensopivaksi ja turvalliseksi monimutkaisissa yritysympäristöissä?
Avoimet standardit ovat ehdottoman kriittisiä. Yritykset johtavat jo monimutkaisia identiteettikankaita, jotka kattavat pilvi-alustat, SaaS-palvelut ja sisäiset API:t. Agenteille AI lisää monimutkaisuutta.
Ilman standardeja jokainen agentti muodostaa oman integraationsa ja pysyvän turvallisuuspoikkeuksen. Avoimien standardien avulla, kuten OAuth ja OpenID Connect, agentit voidaan todentaa, valtuuttaa ja tarkastella samalla tavalla kuin muut työkuormat. Tämä on ainoa lähestymistapa, joka voi mahdollistaa turvallisen skaalautuvuuden todellisissa yritysympäristöissä.”
Mitä tekee AI-agenteista perustavanlaatuisesti erilaisia kuin aiemmat ei-ihmisen identiteetit turvallisuuden näkökulmasta?
Avainero aiempiin ei-ihmisen identiteetteihin (NHI) on autonomia. Perinteinen palvelutili tekee vain sen, mitä sen koodi käskee, tiukasti sidottuna tehtäväänsä. AI-agentti tulkkaa ohjeita, sopeuttaa käyttäytymistään ja tekee toimintoja, joita ei koskaan kirjoitettu selkeästi – kaikki lisäävät potentiaalista vaaraa, jos sopivia varotoimia ei ole.
Pieni identiteetti- tai pääsyvirhe voi nopeasti muuttua katastrofiksi, koska agentti voi toimia nopeasti ja useiden järjestelmien yli. Turvallisuuden näkökulmasta tämä esittää suuren riskin.
Kuinka tärkeitä ovat audit-merkinnät ja identiteettiin perustuva lokitus agenteille AI:n hallitsemisessä, erityisesti säänteltyjen alojen yrityksissä?
Audit-merkinnät eivät ole “mukavia”. Niiden on oltava rakennettu alusta alkaen. Säänteltyjen ympäristöissä organisaatioiden odotetaan vastaavan yksinkertaisiin mutta kriittisiin kysymyksiin: mitä agentti on käyttänyt, milloin se tapahtui ja kuka valtuutti sen?
Identiteettiin perustuva lokitus on ainoa luotettava tapa saada seuraavuus. Se myös toimii avainroolissa ongelmanratkaisussa. Ilman selkeää identiteettikontekstia on lähes mahdotonta tietää, johtuuko ongelma huonosta agentista, murrettusta identiteetistä vai vain huonosta ohjeesta.
Mitä todellisia riskejä näet, kun organisaatiot käyttävät ylivaltuutettuja tai huonosti valvottuja AI-agenteja tuotannossa?
Yksi yleinen riski on hiljainen datakeräys. Ylivaltuutettu agentti voi kerätä arkaluontoista tietoa useista järjestelmistä (asiakastiedot, sisäiset asiakirjat, lokit) ja sitten paljastaa sen kautta ohjeita, yhteenvetoja tai ulkoisia integraatioita.
Toinen riski on, että agentit, joilla on hallinto-oikeudet, tekevät merkittäviä muutoksia koneen nopeudella, aiheuttaen paljon enemmän vahinkoa kuin ihminen voisi lyhyessä ajassa. Tämä voi käsittää pilviresurssien muuttamista, turvallisuuden estoja poistamista tai automaattisten työnkulkujen käynnistämistä ilman valvontaa.
Nämä tapahtumat voivat olla maliciouksia, mutta ne eivät välttämättä ole. Ylivaltuutettu tai huonosti valvottu agentti voi toimia vanhanaikaisilla tai virheellisillä oletuksilla, lisäten virheitä useiden järjestelmien yli ennen kuin kukaan huomaa.
Mutkikkaampi hyökkääjän näkökulma on, että murrettu agentin identiteetti on erittäin arvokas. Se mahdollistaa liikkeen API:iden ja palvelujen yli, usein käyttöoikeuksilla, joita ihmiselle ei koskaan myönnetä. Ilman vahvoja identiteettivalvontaa ja valvontaa organisaatiot usein havaitsevat nämä epäonnistumiset vasta kun todellinen vahinko on tehty.”
Mitä identiteetti- ja pääsypäätöksiä tulisi tehdä aikaisin välttääkseen kalliit uudelleensuunnittelut myöhemmin?
Organisaatioiden tulisi päättää aikaisin, miten agenteille myönnetään identiteetti, miten käyttöoikeudet hyväksytään ja miten pääsyä tarkastetaan ajan myötä, määrittäen identiteetin rajat etukäteen.
Identiteettivalvonnan sisääntulon jälkeen on lähes aina ongelmallista. Agentit ovat usein upotettu syvälle työnkulkuihin jaettujen tunnistetietojen ja laajojen roolien avulla, joten pääsyoikeuksien kiristäminen jälkikäteen rikkoo järjestelmän oletuksia, joista se riippuu. Tämä lopulta aiheuttaa työnkulun epäonnistumisen ja heikentää teknologian luottamusta. On paljon halvempi, ja mikä tärkeintä, turvallisempi, suunnitella oikeat identiteetit, laajuudet ja pääsyrajoitukset alusta alkaen.
Mihin identiteetin integrointi usein muodostuu pullonkaulaksi, kun otetaan käyttöön agenteille AI:ta, ja mitkä parhaat käytännöt auttavat vähentämään kitkaa?
Identiteetin hallinta voi muodostua pullonkaulaksi vain, kun sitä kohdellaan jälkikäteen. Tiimit keskittyvät ensin rakentamaan vaikuttavia agentin ominaisuuksia ja myöhemmin toteuttamaan niiden integroinnin IAM-järjestelmiin, API-porttiin ja lokitusjärjestelmiin turvallisuuden vuoksi.
Paras lähestymistapa on aloittaa selkeällä ymmärryksellä ja oikealla identiteettialustan toteutuksella ja suunnitella agentit sopimaan niiden kanssa. Organisaatioiden tulisi uudelleenkäyttää olemassa olevia standardeja ja infrastruktuuria sen sijaan, että ohittaa ne; leikata kulmia tulee väkisinkin aiheuttaa ongelmia myöhemmin. Kun identiteetti on rakennettu alusta alkaen, se kiihdyttää käyttöönottoa sen sijaan, että hidastaa sitä.
Mitä neuvoa antaisit turvallisuuden ja insinöörien johtajille, jotka haluavat omaksua agenteille AI:ta, mutta ovat huolissaan hallinnosta ja riskeistä, kun he suunnittelevat tiensä?
Hidasta vain tarpeeksi perustusten saamiseksi oikein. AI-agenteille on kohdeltava identiteetteinä, ja sinun on sovellettava samaa hallintaa, jonka odotat ihmisiltä, ja vaadittava näkyvyyttä alusta alkaen. Jos organisaatio tekee niin, agenteille AI:n skaalautuminen muuttuu turvallisuuden harjoitukseksi, eikä sokeaksi ja riskialttiiksi uskallukseksi.
Kiitos hienosta haastattelusta, lukijoille, jotka haluavat oppia lisää, suosittelemme vierailemaan Curity:ssa.












