SCIM vadītas komandas vadīklas AI API vārtejai: nodrošināt lietotājus, atsaukt atslēgas un uzturēt pakalpojumu kontus

Cilvēka izslēgšanai nevajadzētu kļūt par pārtraukuma treniņu. Daudzās komandās identitātes nodrošinātājs var ātri atspējot darbinieku, taču AI API vārtejai joprojām ir ilgstošas ​​izstrādātāja atslēgas, koplietoti skripti, ražošanas pakalpojumu konti, tālākpārdevēju nomnieki un norēķinu privilēģijas, kas nav tīri saistītas ar vienu cilvēka kontu. Praktiskā shēma ir izmantot SCIM kā dzīves cikla ievadi, pēc tam saglabāt autorizāciju, atslēgas īpašumtiesības, tēriņu ierobežojumus, modeļa piekļuvi un audita ierakstus kā skaidrus vārtejas objektus.

Problēma: identitātes izmaiņas nav tas pats, kas API autorizācija

SSO atbild, vai lietotājs var pierakstīties. SCIM palīdz automatizēt lietotāju un grupu nodrošināšanu. Neviens pats par sevi neatbild uz katru darbības jautājumu, kas AI vārtejai ir jāizpilda: kuru nomnieku šis lietotājs var administrēt, kādus modeļa profilus viņš var izmantot, kuras atslēgas ir personiskas, kuras atslēgas nodrošina ražošanu, kurš var apstiprināt budžeta palielinājumus un kuriem partneru API klientu objektiem var pieskarties?

Tīrā arhitektūrā identitāte tiek uzskatīta par dzīves cikla notikumu avotu, nevis kā pilnu autorizācijas modeli. Vārtejai jāsaņem lietotāju un grupu izmaiņas no identitātes nodrošinātāja, tās jānormalizē un jāpārvērš vārtejas vietējos ierakstos. Pēc tam šie ieraksti izpildlaikā ir jānovērtē attiecībā uz administratora darbībām, API atslēgas izveidi, piekļuvi modelim, tēriņu ierobežojumus, pakalpojumu konta īpašumtiesības un audita eksportēšanu.

Fakts: SCIM 2.0 ir IETF standarta protokols starpdomēnu identitātes pārvaldībai. Tā protokola darbība ir norādīta RFC 7644, un tā resursu shēmas ir norādītas RFC 7643. SCIM nodrošina komandām standarta veidu, kā izveidot, atjaunināt, deaktivizēt un grupēt lietotājus dažādās sistēmās.

Ieteikums: neievietojiet vārtejas autorizāciju tieši IDP grupu nosaukumos vai pieprasījumu ceļos. Izmantojiet SCIM grupas kā ievadi kontrolētā kartēšanas tabulā, pēc tam novērtējiet vārtejas lomas un politikas no vārtejai piederošajiem ierakstiem.

Pamatobjekti, kas jāpieder vārtejai

Vārtejai ir nepieciešams savs autorizācijas modelis, jo LLM piekļuve apvieno drošību, izmaksas un darbības nepārtrauktību. Definējiet šos ierakstus vismaz kā pirmās klases objektus:

• Identitāte: nodrošināts cilvēks, kas ir saistīts ar IDP tēmu, e-pastu, statusu un dalību grupā.
• Īrnieks vai darbvieta: administratīvā robeža lietotājiem, atslēgām, budžetiem, modeļu profiliem, integrācijām un lietojumam.
• Loma: vārtejas atļaujas, piemēram, izstrādātājs, nomnieka administrators, norēķinu administrators, modeļa administrators, auditors vai partnera API administrators.
• Modeļa profils: atļauta modeļu kopa, maršrutēšanas noteikumi, datu apstrādes ierobežojumi un funkciju vārti.
• Budžeta pilnvaras: kas var tērēt, palielināt ierobežojumus, izveidot augstas izmaksas vai apstiprināt pagaidu izņēmumus.
• Cilvēkam piederoša API atslēga: vienai personai izveidota atslēga, kas parasti tiek atsaukta vai apturēta, kad šī persona aiziet.
• Pakalpojuma konts: lietojumprogrammas identitāte ar īpašniekiem, mērķi, vidi, rotācijas metadatiem, pēdējo reizi izmantoto laikspiedolu un pievienoto politiku.
• Pārbaudes notikums: tūlītējs un minimāls ieraksts par identitāti, lomu, atslēgu, budžetu un pilnvarojuma lēmumiem.

Šī atdalīšana padara atkāpšanos no borta deterministisku. Lietotājs var kļūt neaktīvs, neizdzēšot pakalpojumu kontus, kas bija pareizi reģistrēti kā lietojumprogrammu identitātes. Īrnieka administrators var zaudēt norēķinu pilnvaras, nezaudējot pamata tikai lasīšanas audita piekļuvi. Tālākpārdevējs var pārvaldīt piešķirtos klientu nomniekus, nevarot uzskaitīt nesaistītus nomniekus.

Nodrošināšanas plūsma: no SCIM notikuma līdz vārtejas piekļuvei

Noderīga nodrošināšanas plūsma pēc konstrukcijas ir garlaicīga. Tam vajadzētu paciest atkārtotus mēģinājumus, daļējus atjauninājumus un aizkavētu grupas sinhronizāciju. SCIM implementācijas atšķiras pēc laika, darbības dzēšanas pret deaktivizēšanu, atribūtu kartējumiem un grupu atbalsta, tāpēc vārtejai ir jāizvairās no trausliem pieņēmumiem.

1. Ievadiet un normalizējiet lietotāju

Kad vārteja saņem SCIM lietotāja izveides vai atjaunināšanas notikumu, tai ir jāatceļ identitātes ieraksts, izmantojot stabilu ārējo identifikatoru. Saglabājiet lietotāja statusu, parādāmo vārdu, e-pastu, nodaļu vai izmaksu centru, ja tas ir pieejams, un neapstrādātas IDP grupas atsauces normalizētā formā. Neizmantojiet e-pastu kā vienīgo nemainīgo identifikatoru; e-pasta adreses mainās.

Normalizētu identitātes lauku piemēri:

{
  "external_subject": "idp-user-12345",
  "e-pasts": "[email protected]",
  "aktīvs": patiess,
  "groups": ["llm-developers", "support-ai-prod"],
  "cost_center": "atbalsts",
  "last_scim_event_at": "2026-08-30T10:14:00Z"
}

2. Tulkot grupas vārtejas lomās

Izmantojiet vārtejas pārvaldītu tulkošanas tabulu. Katrai rindai ir jāsaista IdP grupas atsauce ar nomnieku, lomu un izvēles profiliem, piemēram, atļautajiem modeļiem vai budžeta klasēm. Nekartotām grupām nevajadzētu piešķirt neko. Priviliģētās kartēšanas ir jāpārskata, jo īpaši norēķinu administratoram, modeļa administratoram, nomnieka īpašniekam un partnera API administratoram.

{
  "idp_group": "support-ai-prod",
  "īrnieks": "atbalsts",
  "role": "izstrādātājs",
  "model_profile": "atbalsta-apstiprinātie modeļi",
  "budget_profile": "standarta komandas budžets",
  "requires_review": nepatiess
}

Ieteikums: nekartotām grupām izmantojiet noklusējuma aizliegumu. Jaunizveidotai grupai labāk ir neveidot AI piekļuvi, nevis nejauši mantot ražošanas modeli vai norēķinu iestādi, jo virkne atbilst ceļa prefiksam.

3. Īstenojiet efektīvu piekļuvi

Pēc grupas tulkošanas īstenojiet lietotāja efektīvu vārtejas piekļuvi: nomnieka dalības, lomas, modeļu profilus, atslēgu izveides atļaujas, budžeta pilnvaras un integrācijas atļaujas. Izpildlaika pārbaudēs ir jāizlasa šis materializētais skats vai stingri konsekvents autorizācijas pakalpojums, nevis jāparsē IDP grupas virknes pēc katra pieprasījuma.

Tādējādi administratoriem tiek sniegta izmantojama piekļuves pārskatīšana: “Parādiet man visus, kas atbalsta nomniekā var izveidot atslēgas”, “Parādiet man, kurš var palielināt ikmēneša tēriņu ierobežojumus” un “Parādiet man visus lietotājus, kuri var piekļūt dārgiem argumentācijas modeļiem”.

Atdaliet cilvēka atslēgas no pakalpojumu kontiem

Svarīgākā darbības atšķirība ir vienkārša: cilvēka atslēga attēlo personu; pakalpojuma konts apzīmē lietojumprogrammu. Apstrādājot abas kā vispārīgas API atslēgas, tiek radīts pārtraukšanas risks.

Cilvēkam piederošajām atslēgām ir jāmanto cilvēka lietotāja dzīves cikls. Kad lietotājs kļūst neaktīvs, vārtejai ir jābloķē jaunas atslēgas izveide un jāaptur vai jāatsauc personiskās atslēgas. Šīm atslēgām ir jābūt arī īpašnieka, nomnieka, modeļa profilam, budžeta profilam, pēdējā izmantotā laikspiedola un mērķa metadatiem, lai komandas varētu redzēt ļaunprātīgu izmantošanu pirms izslēgšanas dienas.

Pakalpojumu konta atslēgas nedrīkst piederēt vienam aizejošam darbiniekam tādā veidā, ka tiek pārtraukta ražošana. Pakalpojuma kontam ir jābūt vismaz diviem cilvēkiem īpašniekiem vai īpašumtiesību grupai, vides apzīmējumam, rotācijas politikai, pēdējoreiz izmantotajai redzamībai un politikas profilam. Tam vajadzētu palikt aktīvam, kad viens īpašnieks aiziet, ja pastāv cits derīgs īpašnieks vai stikla izsišanas process.

Fakts: galvenās mākoņdatošanas vadlīnijas parasti attur no nepārvaldītas ilgstošas pakalpojumu konta atslēgām un iesaka ierobežot izņēmumus. Tas pats princips attiecas uz AI vārtejas atslēgām: saglabājiet lietojumprogrammu identitātes nepārprotamas, tvēruma, pārskatītas un pagrieztas.

Ieteikums: ja personiskā atslēga tiek izmantota darbam bez uzraudzības, neglabājiet to klusībā, kad esat izkāpis no borta. Karantīnā, atzīmējiet to kā nepareizi klasificētu ražošanas lietojumu, pieprasiet īpašumtiesību nodošanu un aizstājiet to ar pakalpojuma konta atslēgu saskaņā ar politiku.

Designing deprovisioning as State Machine

Atcelšanai ir jābūt darbplūsmai, nevis atsevišķai dzēšanas komandai. Stāvokļa iekārta nodrošina vārtejai pietiekami daudz struktūras, lai ātri samazinātu risku, vienlaikus saglabājot pārbaudāmību un ražošanas nepārtrauktību.

1. stāvoklis: Saņemta deaktivizēšana

Vārteja saņem SCIM deaktivizēšanas, dzēšanas, grupas noņemšanas vai līdzvērtīgu dzīves cikla notikumu. Ierakstiet notikumu, tā avotu un iepriekšējo efektīvu piekļuvi. Tā kā IdP notikumus var mēģināt atkārtoti vai tie var notikt neregulāri, padariet šo darbību par idempotenu.

2. stāvoklis: lietotājs atzīmēts kā neaktīvs

Iestatiet vārtejas identitāti uz neaktīvu. Bloķējiet interaktīvu pierakstīšanos, administratora darbības, jaunas atslēgas izveidi, jauna pakalpojuma konta izveidi un budžeta izmaiņas. Tam vajadzētu notikt, pirms tiek veikti lēnāki tīrīšanas uzdevumi.

3. stāvoklis: personiskās atslēgas ir apturētas

Apturiet cilvēkiem piederošās atslēgas nekavējoties vai pēc īsa politikas noteikta labvēlības perioda. Drošāka noklusējuma darbība ir tūlītēja apturēšana. Lai nodrošinātu izstrādātāja pieredzi, vārteja var atgriezt skaidru autentifikācijas kļūdu, kas norāda administratorus uz neaktīvo īpašnieku, atslēgas ID, nomnieku un pēdējo veiksmīgo lietojumu.

4. stāvoklis: nepieciešama īpašumtiesību nodošana

Atrodiet resursus, kas pieder neaktīvajam lietotājam: pakalpojumu kontus, nomniekus, modeļu profilus, integrācijas, norēķinu kontaktpersonas, partneru API akreditācijas datus un brīdinājumu kanālus. Automātiski nododiet īpašumtiesības, kad pastāv derīga īpašumtiesību grupa. Pretējā gadījumā ievietojiet resursu "nepieciešams īpašnieks" rindā.

5. stāvoklis: paziņojumi un pārskatīšana

Paziņojiet īrnieku īpašniekiem, drošības administratoriem vai norēķinu administratoriem. Paziņojumā jāiekļauj ietekmētās atslēgas, pēdējoreiz lietotie laikspiedoli, lietojums pēdējo 30 un 90 dienu laikā, pakalpojumu konti, kuriem nepieciešams jauns īpašnieks, un visas personīgās atslēgas, kas nesen apkalpoja produkcijas datplūsmu.

6. stāvoklis: pabeigšana

Pēc tam, kad saglabāšanas noteikumi to atļauj, pabeidziet lietotāja atribūtu dzēšanu vai anonimizāciju, vienlaikus saglabājot nepieciešamos audita ierakstus. Identitātes dzīves cikla auditēšanai parasti nav nepieciešamas neapstrādātas uzvednes. Saglabājiet uzvednes minimizētus notikumus, kas apraksta politikas lēmumu, objektu ID, dalībnieku, nomnieku, laikspiedolu un rezultātu.

Modeļa piekļuves un tēriņu ierobežojumi ietilpst vienā pārskatā

AI vārtejas autorizācija attiecas ne tikai uz to, kurš var izsaukt galapunktu. Lietotājam var būt atļauts izsaukt zemu izmaksu modeļus izstrādei, bet ne dārgus argumentācijas modeļus, mitinātos rīkus, pakešu darbus vai ražošanas aizstājvārdus. Lietotājam var būt atļauts tērēt no komandas budžeta, bet neapstiprināt budžeta palielināšanu.

Katrai efektīvai lomai definējiet saistītās izmaksas un modeļa atļaujas:

• Atļautie modeļu profili un iekšējie aizstājvārdi.
• Maksimālā aptuvenā maksa par pieprasījumu.
• Mēneša vai dienas budžeta profils.
• Atļauja izveidot personiskās atslēgas.
• Atļauja izveidot pakalpojumu kontus vai piederēt tiem.
• Atļauja izmantot mitinātos rīkus, failu apstrādi, reāllaika sesijas vai pakešu darba slodzi.
• Atļauja skatīt lietojuma analīzi, rēķinus vai izmaksu centru eksportus.

Ieteikums: izveidojiet vienu piekļuves pārskatīšanas eksportu, kas apvieno identitāti, vārtejas lomas, aktīvās atslēgas, pakalpojumu kontus, lietojumu pēdējo 30 un 90 dienu laikā, modeļa atļaujas un budžeta pilnvaras. Tas ir noderīgāks par vienkāršu lietotāju sarakstu, jo tajā ir parādīts operacionālais risks un pirktspēja kopā.

Partnera API un vairāku nomnieku autorizācija

Partner API automatizācija pievieno vēl vienu autorizācijas robežu. Aģentūra, tālākpārdevējs vai platforma var nodrošināt klientu nomniekus, lietotājus, atslēgas, budžetus un lietojuma eksportēšanu, izmantojot API. SCIM vadītiem iekšējiem lietotājiem nevajadzētu automātiski iegūt plašu klienta objektu piekļuvi tikai tāpēc, ka viņi administrē paša partnera nomnieku.

Padariet katru partnera API darbību aptvertu gan zvanītāja, gan klienta nomnieka ziņā. Nodrošināšanai jābūt idempotenai: izveidojot vienu un to pašu klientu nomnieku, grupas kartēšanu vai lietotāju divas reizes, vajadzētu konverģēt uz vienu paredzamo stāvokli. Uzskaitīšanas galapunktiem ir jāatgriež tikai tie objekti, kurus zvanītājam ir nepārprotami atļauts administrēt.

Tas ir svarīgi, jo objekta līmeņa un objekta īpašuma autorizācijas kļūmes ir izplatīti API riski. AI vārtejā atklātie objekti ir jutīgi: nomnieku ieraksti, API atslēgas, lietošanas virsgrāmatas, budžeti, modeļu atļaujas, dalībnieku saraksti un pakalpojumu konti. Vārtejai ir jāpārbauda šie ceļi ar vairākām identitātēm un vairākiem nomnieka ID, nevis tikai ar laimīgā ceļa administratoru.

Noderīgi testi ietver:

• Īrnieka A administrators mēģina nolasīt, pagriezt vai atsaukt īrnieka B atslēgas.
• Apturētais lietotājs izmēģina veco personisko API atslēgu.
• Tālākpārdevēja administrators mēģina uzskaitīt nepiederošos klientu nomniekus.
• Projekta dalībnieks mēģina mainīt norēķinu iestatījumus.
• Pakalpojuma konta īpašnieks mēģina piešķirt sev norēķinu administratoru.
• Partnera API akreditācijas dati mēģina mainīt modeļu profilus ārpus atļautā klienta darbības jomas.

Revīzija bez tūlītējas uzkrāšanas

Identitātes dzīves cikla izmeklēšanām parasti ir jāzina, kurš mainīja piekļuvi, kura politika tika novērtēta, kāds objekts tika ietekmēts un vai darbība bija veiksmīga. Viņiem parasti nav vajadzīgas neapstrādātas uzvednes. Saglabājiet atsevišķu audita straumi identitātes un politikas lēmumiem.

Reģistrējiet notikumus, piemēram:

• Lietotājs ir nodrošināts, atjaunināts, deaktivizēts vai dzēsts.
• Grupa ir kartēta, nav kartēta vai noraidīta.
• Piešķirta, mainīta vai noņemta vārtejas loma.
• Personiskā atslēga ir izveidota, apturēta, atsaukta vai izmantota pēc deaktivizēšanas.
• Mainīts pakalpojuma konta īpašnieks.
• Budžeta pilnvaras ir piešķirtas vai noņemtas.
• Modeļa profils ir pievienots vai atdalīts.
• Partnera API pieprasījums ir noraidīts nomnieka darbības jomas dēļ.

Katrā notikumā ir jāietver dalībnieks, subjekts, nomnieks, objekta veids, objekta ID, avota sistēma, lēmums, iemesla kods un laikspiedols. Neapstrādāta uzvednes satura vietā izmantojiet stabilus ID. Ja nepieciešama informācija par kravnesību, uzglabājiet strukturētus politikas metadatus, nevis modeļa ievadi.

Ieviešanas kontrolsaraksts

Izmantojot šo kontrolsarakstu, ieviešot SCIM vadītas komandas vadīklas AI vārtejā:

• Definējiet vārtejas vietējos objektus nomniekam, lomai, lietotājam, atslēgai, pakalpojuma kontam, modeļa profilam, budžeta profilam un integrācijas piekļuvei.
• Saglabājiet ārējo IDP tēmu atsevišķi no e-pasta.
• Padariet SCIM lietotāju un grupu pārveidotājus idempotentus.
• Izmantojiet pārskatītu grupu uz lomu tulkošanas tabulu ar noklusējuma aizlieguma darbību.
• Nepieciešama nepārprotama apstiprināšana priviliģētu lomu kartēšanai.
• Shēmā un lietotāja saskarnē nošķiriet cilvēkiem piederošās atslēgas no pakalpojumu konta atslēgām.
• Bloķēt neaktīviem lietotājiem pierakstīšanos, administratora darbības, atslēgu izveidi un budžeta izmaiņas.
• Apturēt personiskās atslēgas deaktivizēšanas laikā.
• Pārvietojiet vai novietojiet karantīnā resursus, kas pieder neaktīviem lietotājiem.
• Pieprasīt, lai pakalpojumu kontiem būtu īpašnieka metadati, mērķis, vide, pēdējais izmantotais laikspiedols un rotācijas metadati.
• Pievienojieties piekļuves pārskatiem, izmantojot lietojuma analīzi un budžeta iestādi.
• Pārbaudiet objekta līmeņa autorizāciju starp nomniekiem, klientiem, lietotājiem, atslēgām un norēķinu objektiem.
• Pēc noklusējuma identitātes audita ieraksti ir jāsamazina līdz minimumam.

Izmaiņas

SCIM samazina manuālās piekļuves novirzi, taču neatceļ vajadzību pēc vārtejas autorizācijas. Dažādi identitātes nodrošinātāji atšķirīgi apstrādā grupu sinhronizāciju, dzēšanu, deaktivizēšanu, atkārtotus mēģinājumus un atribūtu kartēšanu. Vārtejai vajadzētu izturēt daļēju informāciju un droši konverģēt.

Tūlītēja personiskās atslēgas atsaukšana samazina izslēgšanas risku, taču var tikt atklāta slikta darbības higiēna, ja izstrādātāja atslēga tika izmantota bez uzraudzības. Tas nav iemesls, lai personas atslēgas būtu dzīvas bezgalīgi. Tas ir iemesls, lai laikus atklātu personīgās atslēgas ražošanas izmantošanu un migrētu to uz pakalpojumu kontiem, pirms darbinieks aiziet.

Smalki grupu kartējumi var izteikt precīzu pārvaldību, taču pārāk daudz grupu kļūst grūti pārbaudīt. Ar mazāku vārtejas lomu kopu kopā ar modeļu profiliem un budžeta profiliem parasti ir vieglāk darboties.

Pakalpojumu konti nodrošina lietojumprogrammu darbību, taču tie var kļūt nepiederoši vai tiem var tikt piešķirtas pārāk lielas tiesības. Nepieciešami īpašnieki, pārskatīšanas datumi, rotācijas metadati, tvēruma modeļu profili, tvēruma budžeti un pēdējoreiz izmantotā analīze.

Prognoze: AI vārtejas piekļuves pārskatos arvien vairāk vienā pārskatā tiks apvienotas identitātes, lietojuma, izdevumu pilnvaras un modeļa atļaujas. Pārskatīšana “kam ir piekļuve”, neparādot, “ko viņi var tērēt un kuras atslēgas joprojām ir aktīvas”, būs pārāk sekla komandām, kas veic ražošanas AI darba slodzi.

Apstrīdams secinājums

Noturīgs modelis ir ļaut SCIM un SSO vadīt dzīves ciklu, pēc tam ļaut vārtejai pašai autorizēt. Nodrošiniet lietotājus no identitātes nodrošinātāja, tulkojiet grupas, izmantojot pārskatītas kartēšanas, materializējiet nomnieka lomas, skaidri sasaistiet modeļu un budžeta profilus un apstrādājiet cilvēku atslēgas savādāk nekā pakalpojumu kontiem.

Lai izietu no borta, izmantojiet statusa mašīnu: saņemiet identitātes notikumu, atzīmējiet lietotāju kā neaktīvu, bloķējiet jaunu piekļuvi, apturiet personiskās atslēgas, pārsūtiet vai ievietojiet karantīnā piederošos resursus, paziņojiet īpašniekiem un pabeidziet dzēšanu pēc tam, kad saglabāšanas noteikumi to atļauj. Tas nodrošina drošības komandām ātru atsaukšanu, nodrošina platformu komandām ražošanas nepārtrauktību un sniedz finansēm un auditoriem skaidru uzskaiti par to, kam bija tiesības pār modeļiem, tēriņiem, atslēgām un nomniekiem.

Saistīta informācija

• komandas API atslēgu pārvaldības modeļi
• aģenta rīku pārvaldība un tvēruma apstiprinājumi
• Partner API nomnieka nodrošināšanas vadīklas