Entra Agent ID käytännössä: Oikean kuvion valitseminen ja turvallisten oletusarvojen luominen
Skaala on todellinen ongelma
Useimmilla tiimeillä ei ole vaikeuksia luoda ensimmäistä agenttia. Heillä on vaikeuksia luoda viidettäkymmentä.
Ensimmäinen agentti on koontiversio. Viideskymmenes on identiteettiympäristö. Siinä vaiheessa vaikein osa ei olekaan "miten saamme agentin toimimaan", vaan "miten pidämme sen hallittavissa, kun se leviää tiimien, tuotteiden ja ympäristöjen välillä". Juuri siksi Microsoft määrittelee agenttien käyttöönoton elinkaareksi, jossa hallinta ja tietoturva tulevat ennen koontiversiota ja käyttöä.
Rakenne voittaa sankarin muistin
Pienessä mittakaavassa voit muistaa, mikä on olemassa. Yritystasolla tarvitset rakenteen. Microsoftin agenttien identiteettialusta on suunniteltu tätä rakennetta varten: piirustukset, agenttien identiteetit ja valinnaiset agenttien käyttäjät. Tavoitteena ei ole uutuus. Tavoitteena on toistettavuus ja hallinta.
Tämä on siirtyminen "jokainen tiimi keksii oman identiteettimallinsa" -ajattelusta jaettuun malliin, joka mahdollistaa löytämisen, periytymisen ja vastuullisuuden. Kun agentteja on paljon, tarvitaan johdonmukainen tapa vastata samoihin kysymyksiin joka kerta: mikä tämä agentti on, kuka seisoo sen takana, mihin se käyttää tietoja ja miten se voidaan poistaa käytöstä nopeasti, jos se toimii virheellisesti. Alustan suunnittelun tarkoituksena on tehdä näistä vastauksista standardoituja, ei räätälöityjä.
Suunnitelma ensin: Luo ohjauspinta
Aloita suunnitelmasta. Microsoftin mallissa agentin identiteettisuunnitelma on uudelleenkäytettävä malli agenttien identiteeteille. Se tallentaa yhteiset ominaisuudet ja toimii säilönä, jotta järjestelmänvalvojat voivat ottaa käytännön käyttöön kerran ja vaikuttaa kaikkiin siitä luotuihin identiteetteihin. Ratkaisevasti suunnitelmat sisältävät todennuksessa käytettävät tunnistetiedot. Agenttien identiteeteillä itsellään ei ole omaa tunnistetietojoukkoa. Tämä on merkittävä muutos perinteisestä palvelupääomien hajanaisuudesta.
Microsoft on mekaniikasta selkeä: agentin identiteetin todentamiseen käytettävät tunnistetiedot konfiguroidaan suunnitelmassa, ja suunnitelma pyytää käyttöoikeustunnuksia Entralta. Tämä vähentää klassista hajautumisongelmaa, jossa jokaisella instanssilla on oma salaisuutensa, oma rotaatiovelkansa ja oma pitkäaikainen käyttöoikeutensa, johon kukaan ei halua koskea, koska "se saattaisi rikkoutua". Suunnitelma on myös luonnollinen paikka standardoida käytäntöjen periytyminen ja pitää säätimet yhdenmukaisina koko agenttiluokan osalta.
Yksi agentin identiteetti käyttöönotettua instanssia kohden
Sitten luot agentti-identiteetin jokaiselle käyttöönotetulle instanssille. Microsoft määrittelee agentti-identiteetin erityiseksi palvelupäänimeksi, jonka suunnitelma on luonut ja jonka suunnitelma on valtuuttanut henkilöllisyyden käyttämiseen. Sitä voidaan käyttää sekä autonomisissa toiminnoissa että käyttäjien delegointitilanteissa agentin toimintatavasta riippuen.
Kaksi yksityiskohtaa on tässä tärkeä. Ensinnäkin agentti-identiteetillä ei ole omia tunnistetietoja, mikä on suunniteltu. Toiseksi suunnitelma voi hankkia tokeneita agentti-identiteetin puolesta, kun oikea suostumus on olemassa. Näin Microsoft tekee vanhemman ja lapsen välisestä suhteesta täytäntöönpanokelpoisen käytännössä, ei vain dokumentaatiossa.
Agenttikäyttäjät ovat valinnaisia
Luo agenttikäyttäjä vain tarvittaessa. Microsoft on yksiselitteisesti todennut, että agenttikäyttäjät ovat valinnaisia ja suunniteltu tilanteisiin, joissa agentin on toimittava digitaalisena työntekijänä, mukaan lukien postilaatikot ja chat-käyttöoikeus, tai hän tarvitsee API-rajapintoja, jotka ovat käytettävissä vain käyttäjäidentiteeteille. He saavat tokeneita, joiden idtyp=user-määrityksellä, heidät voidaan lisätä ryhmiin ja heille voidaan myöntää lisenssejä. Juuri tämän kätevyyden vuoksi agenttikäyttäjät tulisi pitää harvinaisina ja hallittuina.
Agenttikäyttäjät muuttavat hallintotapaansa, koska he näyttävät ja käyttäytyvät kuin vuokralaisen sisällä olevat ihmiset. Tämä voi olla välttämätöntä Microsoft 365 -työnkuluissa, mutta se myös lisää elinkaarikurin, tiukemman laajuuden määrittelyn ja selkeämpien todisteiden tarvetta. Kun jollakin on käyttäjämäinen läsnäolo, se yleensä leviää yhteistyöpintoihin ja ihmisille suunnattuihin prosesseihin, mikä tekee omistajuudesta ja tarkastelusta entistä tärkeämpää.
Käytännön kaavanvalitsin
Jos agentti suorittaa taustatehtäviä ja kutsuu API-rajapintoja sovellusoikeuksilla, olet yleensä agentin identiteettialueella. Jos agentti toimii sisäänkirjautuneen käyttäjän puolesta, olet käyttäjän delegointialueella, jossa käyttäjäkontekstin on pysyttävä näkyvissä valtuutusketjussa. Jos agenttia on käsiteltävä tiimin jäsenenä järjestelmissä, jotka vaativat käyttäjäobjektin ehdottomasti, siirryt agentin käyttäjäalueelle ja hyväksyt siihen liittyvät hallintakustannukset.
Väärän mallin valitseminen näkyy yleensä myöhemmin auditointikipuina ja toiminnallisena kitkana. Sovellusmäiset agentit tarvitsevat selkeät käyttöoikeusrajat ja -rajoitukset. Käyttäjän delegoimat agentit tarvitsevat jäljitettävyyttä, joka säilyttää käyttäjän tarkoituksen. Digitaalisten työntekijöiden agentit tarvitsevat tiukempia elinkaaren hallintakeinoja, koska heille voi kertyä ihmisen viereisiä käyttöoikeuksia ajan myötä.
Missä voitat tai häviät
Nyt turvalliset oletusasetukset.
Laajassa mittakaavassa oletusarvoista tulee kulttuuri. Jos ”nopea” tarkoittaa ”yli-etuoikeutettuja”, yli-etuoikeutettuja agentteja on kaikkialla. Jos ”nopea” tarkoittaa ”standardoituja ja hallittuja”, tiimit liikkuvat nopeasti kaiteiden sisällä sen sijaan, että liikkuisivat nopeasti niiden ympäri.
Vastuullisuus ei ole valinnaista
Vastuullisuus ei ole tässä mallissa valinnaista. Sponsorit, omistajat ja päälliköt ovat ensiluokkaisia hallinnollisia suhteita. Sponsori vaaditaan agentti-identiteetin tai agenttisuunnitelman luomisessa. Tällä on merkitystä, koska se estää orpoidentiteetit jo suunnittelun, ei käytäntömuistion, kautta.
Microsoftin hallintamalli on yksiselitteinen: sponsorit vaaditaan luonnin yhteydessä agenttien identiteeteille ja piirustuksille, piirustusten päähenkilöt vapautetaan luonnin yhteydessä, kun taas omistajat ja päälliköt ovat valinnaisia. Tämä erottelu on käytännöllinen. Omistajat voivat hallinnoida. Sponsorit voivat tehdä liiketoiminnan elinkaareen liittyviä päätöksiä ilman teknisiä oikeuksia. Se on sisäänrakennettu mekanismi, joka pitää "miksi tämä on olemassa" kiinni identiteetissä, vaikka tiimit vaihtuisivat.
Valtakirjat eivät ole kätevyys
Tunnuksia tulisi käsitellä tietoturvatuotteena, ei kehittäjän kätevyytenä. Microsoftin ohjeet tunnuksen hankkimiseksi varoittavat asiakassalaisuuksista tuotannossa ja viittaavat vahvempiin lähestymistapoihin, kuten yhdistettyihin tunnistetietoihin ja -varmenteisiin. Lähtötilanteen tulisi olla linjassa sen kanssa, ja poikkeuksista tulisi tehdä sitten tuskallisia.
Syy on yksinkertainen: salaisuudet leviävät. Ne kopioidaan prosessiin, skripteihin ja kolmannen osapuolen työkaluihin, ja sitten niistä tulee vaikeita kierrättää keskeyttämättä tuotantoa. Vahvemmat tunnistetietomallit vähentävät mahdollisuutta, että yhdestä vuotaneesta salaisuudesta tulee pysyvä käyttöoikeuspolku. Agenttimaailmassa, jossa identiteetit voivat olla pitkäaikaisia ja itsenäisiä, tämä riski lisää identiteettien sekoittumista.
Löytö ja todisteet
Lopuksi suunnittele löytäminen ja todisteet. Microsoft kuvailee agenttirekisteriä keskitetyksi metadatan tietovarastoksi ja löytämismekanismiksi. Microsoftin laajemmat hallintaohjeet korostavat agenttien toiminnan näkyvyyttä ja organisaationlaajuisia hallintakeinoja tiedonhallinnan, havainnoitavuuden ja tietoturvan osalta. Jos et pysty löytämään agentteja ja todistamaan heidän tekojaan, et voi käyttää heitä turvallisesti.
Microsoft menee pidemmälle kuin "inventaarioon". Rekisteriä kuvataan yhtenäiseksi metatietovarastoksi, joka voi tarjota näkyvyyttä Microsoftin ja muiden ekosysteemeissä, ja antamasi metatiedot määrittävät, miten muut järjestelmät, agentit ja käyttäjät voivat löytää agenttisi ja olla vuorovaikutuksessa sen kanssa. Tämä tekee löydettävyydestä turvallisuusriskin, ei dokumentointitehtävän.