SCIM-põhised meeskonna juhtelemendid AI API lüüsi jaoks: kasutajate varustamine, võtmete tühistamine ja teenusekontode töös hoidmine
Kasutage elutsükli sisenditena SCIM-i ja SSO-d, seejärel laske lüüsil jõustada selgesõnalisi rolle, mudeliprofiile, kuluvolitusi, võtmeomandiõigust ja teenusekonto ülekandereegleid. Eesmärk on kiire väljalülitamine ilma tootmisrakendusi rikkumata.
Inimese pardalt lahkumisest ei tohiks saada katkestusõppus. Paljudes meeskondades saab identiteedipakkuja töötaja kiiresti keelata, kuid AI API lüüsil on endiselt pikaealised arendajavõtmed, jagatud skriptid, tootmisteenuste kontod, edasimüüjate rentnikud ja arveldusõigused, mis ei sobitu puhtalt ühe inimkontoga. Praktiline muster on kasutada SCIM-i elutsükli sisendina, seejärel säilitada autoriseerimine, võtme omandiõigus, kululimiidid, mudeli juurdepääs ja auditikirjed selgesõnaliste lüüsiobjektidena.
Probleem: identiteedi muudatused ei ole samad, mis API autoriseerimine
SSO annab vastuse, kas kasutaja saab sisse logida. SCIM aitab automatiseerida kasutajate ja rühmade ettevalmistamist. Kumbki ei vasta iseenesest igale tööküsimusele, mida AI lüüs peab jõustama: millist rentnikku saab see kasutaja hallata, milliseid mudeliprofiile ta saab kasutada, millised võtmed on isiklikud, millised võtmed käitavad tootmist, kes saab eelarve suurendamise heaks kiita ja milliseid Partner API kliendiobjekte nad saavad puudutada?
Puhas arhitektuur käsitleb identiteeti elutsükli sündmuste allikana, mitte täieliku autoriseerimismudelina. Lüüs peaks identiteedipakkujalt vastu võtma kasutajate ja rühmade muudatused, normaliseerima need ja tõlkima lüüsi omakirjeteks. Seejärel tuleks neid kirjeid käitamise ajal hinnata administraatoritoimingute, API-võtme loomise, mudelile juurdepääsu, kululimiitide, teenusekonto omandiõiguse ja auditi eksportimise osas.
Fakt: SCIM 2.0 on IETF-i standardprotokoll domeenidevahelise identiteedi haldamiseks. Selle protokolli käitumine on määratletud standardis RFC 7644 ja selle ressursiskeemid on määratletud standardis RFC 7643. SCIM annab meeskondadele standardviisi süsteemides kasutajate loomiseks, värskendamiseks, desaktiveerimiseks ja rühmitamiseks.
Soovitus: ärge pange lüüsi autoriseerimist otse IDP rühmade nimede või päringuteede sisse. Kasutage SCIM-rühmi kontrollitud vastendatava sisenditena, seejärel hinnake lüüsile kuuluvate kirjete lüüsi rolle ja eeskirju.
Põhiobjektid, mis peaksid lüüsile kuuluma
Lüüsil on vaja oma autoriseerimismudelit, kuna LLM-i juurdepääs ühendab turvalisuse, kulud ja toimimise järjepidevuse. Määrake need kirjed vähemalt esmaklassiliste objektidena:
- Identiteetti: loodud inimkasutaja, mis on lingitud IDP teema, e-posti aadressi, oleku ja grupiliikmesustega.
- Üürnik või tööruum: kasutajate, võtmete, eelarvete, mudeliprofiilide, integratsioonide ja kasutuse halduspiir.
- Roll: lüüsi õigused, nagu arendaja, rentniku administraator, arvelduse administraator, mudeliadministraator, audiitor või partner API administraator.
- Mudeli profiil: lubatud mudelite komplekt, marsruutimisreeglid, andmetöötluspiirangud ja funktsiooniväravad.
- Eelarve volitus: kes saab kulutada, limiite tõsta, kõrge hinnaga võtmeid luua või ajutisi erandeid heaks kiita.
- Inimesele kuuluv API-võti: ühe inimese jaoks loodud võti, mis tavaliselt tühistatakse või peatatakse, kui see inimene lahkub.
- Teenusekonto: rakenduse identiteet koos omanike, eesmärgi, keskkonna, pööramise metaandmete, viimati kasutatud ajatempli ja lisatud poliitikaga.
- Auditeerimissündmus: identiteedi, rolli, võtme, eelarve ja autoriseerimisotsuste viivitamatult minimeeritud kirje.
See eraldamine muudab pardast lahkumise deterministlikuks. Kasutaja võib muutuda passiivseks ilma teenusekontosid, mis olid korralikult registreeritud rakenduse identiteetidena, kustutamata. Üürniku administraator võib kaotada arveldusvolituse, kaotamata kirjutuskaitstud auditi põhijuurdepääsu. Edasimüüja saab hallata määratud kliendiüürnikke, ilma et ta saaks loetleda sõltumatuid üürnikke.
Ettevalmistamise voog: SCIM-sündmusest lüüsi juurdepääsuni
Kasulik varustamisvoog on oma ülesehituselt igav. See peaks taluma korduskatseid, osalisi värskendusi ja hilinenud rühma sünkroonimist. SCIM-i juurutused erinevad ajastuse, kustutamise ja desaktiveerimise käitumise, atribuutide vastendamise ja rühmatoe poolest, seega peaks lüüs vältima hapraid eeldusi.
1. Sisestage ja normaliseerige kasutaja
Kui lüüs saab SCIM-i kasutaja loomise või värskendamise sündmuse, peaks see muutma identiteedikirje stabiilse välisidentifikaatori abil. Salvestage normaliseeritud kujul kasutaja olek, kuvatav nimi, e-posti aadress, osakond või kulukeskus, kui need on saadaval, ja töötlemata IDP-rühma viited. Vältige meili kasutamist ainsa muutumatu identifikaatorina; meilid muutuvad.
Näited normaliseeritud identiteediväljade kohta:
2. Tõlgi rühmad lüüsirollideks
Kasutage lüüsi hallatavat tõlketabelit. Iga rida peaks siduma IdP-rühma viite rentniku, rolli ja valikuliste profiilidega, nagu lubatud mudelid või eelarveklassid. Kaardistamata rühmad ei tohiks midagi anda. Privilegeeritud vastendused, eriti arveldusadministraator, mudeliadministraator, rentniku omanik ja partner API administraator, peaksid vajama ülevaatamist.
Soovitus: kasutage vastendamata rühmade puhul vaikekeelamist. Vastloodud rühmal on parem AI-juurdepääsu mitte luua, kui tootmismudeli või arveldusvolituse kogemata pärida, kuna string vastas tee prefiksile.
3. Tõhusa juurdepääsu realiseerimine
Pärast grupi tõlkimist realiseerige kasutaja tõhus juurdepääs lüüsile: rentniku liikmesused, rollid, mudeliprofiilid, võtmete loomise load, eelarvevolitused ja integreerimisload. Käitusaja kontrollid peaksid lugema seda materialiseeritud vaadet või tugevalt järjepidevat autoriseerimisteenust, mitte sõeluma iga päringu korral IDP-rühma stringe.
See annab administraatoritele ka kasutatava juurdepääsu ülevaate: „näidake mulle kõiki, kes saavad tugiüürniku võtmeid luua”, „näidake mulle, kes saavad igakuiseid kululimiite tõsta” ja „näidake mulle kõiki kasutajaid, kellel on juurdepääs kallitele arutlusmudelitele”.
Inimese võtmed teenusekontodest eraldada
Kõige olulisem operatiivne eristus on lihtne: inimvõti esindab inimest; teenusekonto tähistab rakendust. Mõlema käsitlemine üldiste API-võtmetena tekitab väljalülitamise riski.
Inimestele kuuluvad võtmed peaksid pärima inimkasutaja elutsükli. Kui kasutaja muutub passiivseks, peaks lüüs blokeerima uue võtme loomise ja peatama või tühistama isiklikud võtmed. Nendel võtmetel peavad olema ka omaniku, rentniku, mudeliprofiili, eelarveprofiili, viimati kasutatud ajatempli ja eesmärgi metaandmed, et meeskonnad näeksid väärkasutust enne pardalt lahkumise päeva.
Teenusekonto võtmed ei tohiks kuuluda ühele lahkuvale töötajale viisil, mis rikub tootmist. Teenusekontol peab olema vähemalt kaks inimomanikku või omanike grupp, keskkonnasilt, rotatsioonipoliitika, viimati kasutatud nähtavus ja poliitikaprofiil. See peaks jääma aktiivseks, kui üks omanik lahkub, eeldusel, et on olemas teine kehtiv omanik või klaasi purustamise protsess.
Fakt. Suured pilvepõhised juhised takistavad üldiselt haldamata pikaajalise kasutusega teenusekonto võtmeid ja soovitavad piirata erandeid. Sama põhimõte kehtib ka tehisintellekti lüüsi võtmete kohta: hoidke rakenduse identiteedid selged, hõlmatud, üle vaadatud ja pööratud.
Soovitus: kui isiklikku võtit kasutab järelevalveta töö, ärge hoidke seda vaikselt pardast väljumise ajal. Pange see karantiini, märgistage see valesti klassifitseeritud tootmiskasutuseks, nõudke omandiõiguse üleandmist ja asendage see eeskirjade alusel teenusekonto võtmega.
Provisjoni eemaldamine olekumasinana
Provisjoni eemaldamine peaks olema töövoog, mitte üks kustutamiskäsk. Olekumasin annab lüüsile piisavalt struktuuri, et riske kiiresti vähendada, säilitades samal ajal auditeeritavuse ja tootmise järjepidevuse.
Olek 1: eraldamine vastu võetud
Lüüs saab SCIM-i desaktiveerimise, kustutamise, rühma eemaldamise või samaväärse elutsükli sündmuse. Salvestage sündmus, selle allikas ja eelmine tõhus juurdepääs. Kuna IDP sündmusi saab uuesti proovida või need saabuvad järjekorras, muutke see samm idempotentseks.
Olek 2: kasutaja on märgitud passiivseks
Määrake lüüsi identiteet mitteaktiivseks. Blokeerige interaktiivne sisselogimine, administraatoritoimingud, uue võtme loomine, uue teenusekonto loomine ja eelarvemuudatused. See peaks juhtuma enne aeglasemate puhastustoimingute käivitamist.
Olek 3: isiklikud võtmed on peatatud
Peatage inimestele kuuluvad võtmed kohe või pärast lühikest poliitikaga määratud ajapikendusperioodi. Turvalisem vaikeseade on kohene peatamine. Arendaja kogemuse huvides võib lüüs tagastada selge autentimisvea, mis juhib administraatorid passiivse omaniku, võtme ID, rentniku ja viimase eduka kasutuse juurde.
Olek 4: omandiõiguse üleandmine on nõutav
Leidke mitteaktiivsele kasutajale kuuluvad ressursid: teenusekontod, rentnikud, mudeliprofiilid, integratsioonid, arvelduskontaktid, Partner API mandaat ja hoiatuskanalid. Andke omandiõigus automaatselt üle, kui on olemas kehtiv omanikerühm. Vastasel juhul asetage ressurss "vajab omanikku" järjekorda.
Olek 5: teated ja ülevaatus
Teavitage üürnike omanikke, turbeadministraatoreid või arveldusadministraatoreid. Teatis peaks sisaldama mõjutatud võtmeid, viimati kasutatud ajatempleid, kasutust viimase 30 ja 90 päeva jooksul, teenusekontosid, mis vajavad uut omanikku, ja kõiki isiklikke võtmeid, mis hiljuti tootmisliiklust teenindasid.
Olek 6: lõpetamine
Pärast seda, kui säilitamisreeglid seda võimaldavad, viige kasutaja atribuutide kustutamine või anonüümseks muutmine lõpule, säilitades samal ajal nõutavad auditikirjed. Identiteedi elutsükli auditeerimine ei nõua tavaliselt töötlemata viipasid. Salvestage viipega minimeeritud sündmused, mis kirjeldavad poliitikaotsust, objekti ID-sid, osalejat, rentnikku, ajatemplit ja tulemust.
Juurdepääs mudelile ja kululimiidid kuuluvad samasse arvustusse
AI lüüsi autoriseerimine ei seisne ainult selles, kes saab lõpp-punktile helistada. Kasutajal võidakse lubada arenduseks kutsuda odavaid mudeleid, kuid mitte kõrge hinnaga arutlusmudeleid, hostitud tööriistu, partiitöid ega tootmisaliaseid. Kasutajal võidakse lubada kulutada meeskonnaeelarvest, kuid mitte heaks kiita eelarve suurendamist.
Iga tõhusa rolli jaoks määrake seotud kulu ja mudeli load:
- Lubatud mudeliprofiilid ja sisemised aliased.
- Maksimaalne hinnanguline kulu taotluse kohta.
- Kuu- või päevaeelarve profiil.
- Isiklike võtmete loomise luba.
- Teenusekontode loomise või omamise luba.
- Luba kasutada hostitud tööriistu, failitöötlust, reaalajas seansse või paketttöökoormust.
- Luba vaadata kasutusanalüüsi, arveid või kulukeskuse eksporti.
Soovitus: looge üks juurdepääsuülevaate eksport, mis ühendab identiteedi, lüüsirollid, aktiivsed võtmed, teenusekontod, viimase 30 ja 90 päeva kasutuse, mudeli load ja eelarvevolitused. See on kasulikum kui lihtne kasutajaloend, kuna see näitab operatsiooniriski ja kulujõudu koos.
Partner API ja mitme rentniku autoriseerimine
Partner API automatiseerimine lisab veel ühe autoriseerimispiiri. Agentuur, edasimüüja või platvorm võib API kaudu pakkuda klientidele rentnikke, kasutajaid, võtmeid, eelarveid ja kasutuseksporti. SCIM-põhised sisekasutajad ei tohiks automaatselt saada laiaulatuslikku juurdepääsu kliendiobjektidele ainult seetõttu, et nad haldavad partneri enda rentnikku.
Määrake iga Partner API toimingud nii helistaja kui ka kliendi rentniku poolt. Ettevalmistus peaks olema idempotentne: sama kliendi rentniku, grupi vastendamise või kasutaja kaks korda loomine peaks koonduma ühte eeldatavasse olekusse. Loendi lõpp-punktid peaksid tagastama ainult objekte, mida helistajal on selgesõnaliselt lubatud hallata.
See on oluline, kuna objekti tasemel ja objekti atribuudi autoriseerimise tõrked on tavalised API riskid. AI-lüüsis on avatud objektid tundlikud: rentniku kirjed, API-võtmed, kasutusreskontrad, eelarved, mudeliõigused, liikmete loendid ja teenusekontod. Lüüs peaks testima neid teid mitme identiteedi ja mitme rentniku ID-ga, mitte ainult õnneliku tee administraatoriga.
Kasulikud testid on järgmised:
- Üürniku A administraator proovib rentniku B võtmeid lugeda, pöörata või tühistada.
- Peatatud kasutaja proovib kasutada vana isiklikku API-võtit.
- Edasimüüja administraator püüab loetleda mittekuuluvad kliendiüürnikud.
- Projekti liige proovib arveldusseadeid muuta.
- Teenusekonto omanik proovib määrata endale arveldusadministraatori.
- Partner API mandaat üritab mudeliprofiile muteeruda väljaspool lubatud klientide ulatust.
Audit ilma kiire kogumiseta
Identiteedi elutsükli uurimisel on tavaliselt vaja teada, kes muutis juurdepääsu, millist poliitikat hinnati, millist objekti see mõjutas ja kas toiming õnnestus. Tavaliselt ei nõua need töötlemata viipasid. Hoidke identiteedi ja poliitikaotsuste jaoks eraldi auditivoogu.
Logi sündmused, näiteks:
- Kasutaja on ette valmistatud, värskendatud, desaktiveeritud või kustutatud.
- Rühm on kaardistatud, kaardistamata või tagasi lükatud.
- Lüüsi roll on antud, muudetud või eemaldatud.
- Isiklik võti on loodud, peatatud, tühistatud või kasutatud pärast deaktiveerimist.
- Teenusekonto omanik on muutunud.
- Eelarve volitus on antud või eemaldatud.
- Mudelprofiil on lisatud või eemaldatud.
- Partner API taotlus lükati rentniku ulatuse tõttu tagasi.
Iga sündmus peaks sisaldama osalejat, subjekti, rentnikku, objekti tüüpi, objekti ID-d, lähtesüsteemi, otsust, põhjuse koodi ja ajatemplit. Kasutage tooresisu asemel stabiilseid ID-sid. Kui vajate kasuliku koormuse üksikasju, salvestage mudelisisendite asemel pigem struktureeritud poliitika metaandmed.
Rakendamise kontroll-loend
Kasutage seda kontroll-loendit, kui rakendate AI-lüüsis SCIM-põhiseid meeskonna juhtelemente.
- Määratlege rentniku, rolli, kasutaja, võtme, teenusekonto, mudeliprofiili, eelarveprofiili ja integratsioonijuurdepääsu lüüsi algobjektid.
- Säilitage väline IDP teema meilist eraldi.
- Muutke SCIM-i kasutajad ja grupid idempotentseks.
- Kasutage üle vaadatud grupi-rolli tõlketabelit vaikimisi keelamise käitumisega.
- Privilegeeritud rollide vastendamiseks on vaja selgesõnalist heakskiitu.
- Skeemis ja kasutajaliideses eristage inimesele kuuluvaid võtmeid teenusekonto võtmetest.
- Blokeerige passiivsed kasutajad sisselogimise, administraatoritoimingute, võtme loomise ja eelarve muutmise eest.
- Peatage isiklikud võtmed eraldamise ajaks.
- Teisaldage või pange passiivsetele kasutajatele kuuluvad ressursid karantiini.
- Nõuge teenusekontodelt omaniku metaandmete, eesmärgi, keskkonna, viimati kasutatud ajatempli ja pööramise metaandmete olemasolu.
- Liituge kasutusanalüütika ja eelarvevolitustega juurdepääsuülevaatustega.
- Testige üürnike, klientide, kasutajate, võtmete ja arveldusobjektide objektitaseme volitusi.
- Hoidke identiteediauditi kirjed vaikimisi minimeeritud.
Kauplemised
SCIM vähendab käsitsi juurdepääsu triivi, kuid see ei eemalda vajadust lüüsipõhise autoriseerimise järele. Erinevad identiteedipakkujad käsitlevad rühmade sünkroonimist, kustutamist, desaktiveerimist, uuesti proovimist ja atribuutide vastendamist erinevalt. Lüüs peaks taluma osalist teavet ja turvaliselt lähenema.
Kohe isikliku võtme tühistamine vähendab pardalt lahkumise riski, kuid see võib paljastada halva tööhügieeni, kui arendaja võtit kasutati järelevalveta tööl. See ei ole põhjus isiklikke võtmeid lõputult elus hoida. See on põhjus isikliku võtme tootmiskasutamiseks varakult tuvastada ja enne töötaja lahkumist teenusekontodele üle viia.
Rühmade täpsed vastendused võivad väljendada täpset juhtimist, kuid liiga paljusid rühmi on raske kontrollida. Väiksemat lüüsirollide komplekti koos mudeliprofiilide ja eelarveprofiilidega on tavaliselt lihtsam kasutada.
Teenusekontod hoiavad rakendusi töös, kuid need võivad muutuda omandituks või üleprivilegeeritud. Nõuavad omanikke, ülevaatamise kuupäevi, pööramise metaandmeid, ulatusega mudeliprofiile, ulatusega eelarveid ja viimati kasutatud analüüse.
Prognoos: AI lüüsi juurdepääsu ülevaatused ühendavad üha enam ühes aruandes identiteedi, kasutuse, kulutuste volitused ja mudeli load. „Kellel on juurdepääs” ülevaatamine ilma, et näidataks, „mida nad saavad kulutada ja millised võtmed on endiselt aktiivsed”, on tootmis-AI-töökoormust kasutavate meeskondade jaoks liiga pinnapealne.
Tehtitav järeldus
Püsiv muster on lasta SCIM-il ja SSO-l elutsüklit juhtida, seejärel lasta lüüsil enda autoriseerimine. Varustage kasutajaid identiteedipakkujalt, tõlkige rühmi läbi vaadatud vastenduste, realiseerige rentnike rolle, siduge mudeli- ja eelarveprofiilid selgesõnaliselt ning käsitlege inimvõtmeid teenusekontodest erinevalt.
Pardast väljumiseks kasutage olekumasinat: võtke vastu identiteedisündmus, märkige kasutaja passiivseks, blokeerige uus juurdepääs, peatage isiklikud võtmed, teisaldage või pange omanduses olevad ressursid karantiini, teavitage omanikke ja viige kustutamine lõpule pärast seda, kui säilitamisreeglid seda võimaldavad. See tagab turvameeskondadele kiire tühistamise, tagab platvormimeeskondadele tootmise järjepidevuse ning annab finants- ja audiitoritele selge ülevaate selle kohta, kellel oli volitus mudelite, kulutuste, võtmete ja rentnike üle.