Pakalpojumu sniedzēja akreditācijas datu glabātuves vairāku modeļu AI vārtejām: atsevišķa izpildlaika, administratora, norēķinu un BYOK piekļuve

Pakārtotās API atslēgas un augšupējie pakalpojumu sniedzēja akreditācijas dati atrisina dažādas problēmas. Izstrādātāja atslēga, ko izsniedz jūsu vārteja, identificē lietotni, komandu, nomnieku, budžetu un politikas kontekstu. Augšējā nodrošinātāja atslēga ļauj vārtejai tērēt naudu un piekļūt modeļiem pakalpojumu sniedzēja kontā. Uzskatot tos par vienu un to pašu noslēpumu, komandas iegūst vienu neierobežotu atslēgu koplietotā projektā, administratora akreditācijas datus izpildlaika pakalpojumos un nav uzticama veida, kā atbildēt, kurš nomnieks izraisīja pakalpojumu sniedzēja maksu.

Praktiskais modelis ir nodrošinātāja akreditācijas datu glabātuve: īpaša vadības plakne, kas paredzēta akreditācijas datu importēšanai, klasificēšanai, glabāšanai, atlasei, pagriešanai un pārbaudei. Tai ir jāatrodas aiz maršrutētāja, norēķinu virsgrāmatas, politikas programmas un operāciju darbplūsmas — nevis lietojumprogrammas kodā, modeļa konfigurācijas failos, nomnieka ierakstos vai analītikas notikumos.

Lasītāju problēma: augšupējie akreditācijas dati kļūst par neredzamu infrastruktūru

Lielākā daļa vairāku modeļu izvietošanas sākas ar vienkāršu mērķi: vienu ar OpenAI saderīgu pieprasījumu novirzīt uz labāko pieejamo pakalpojumu sniedzēju. Pēc tam tiek parādīti vairāki konti: viens pakalpojumu sniedzēja projekts ražošanai, otrs novērtēšanai, Anthropic darbvieta biznesa vienībai, Google mākoņa projekts Gemini un vairākas klientu nodrošinātas atslēgas BYOK līgumiem.

Risks nav tikai slepena noplūde. Tas ir autorizācijas konteksta zaudējums. Derīga nodrošinātāja atslēga var tehniski izsaukt galapunktu, taču vārtejai joprojām ir jāzina, vai šī atslēga ir atļauta šim nomniekam, šai modeļu saimei, šai datu saglabāšanas politikai, šim budžetam, šim reģionam un šim automatizācijas ceļam.

Fakts: pakalpojumu sniedzēju platformas atklāj dažādas kontu robežas un akreditācijas datu veidus. OpenAI dokumentē projektus un pakalpojumu kontus un pakalpojuma konta API atslēgas atļaujas pēc noklusējuma, lai lasītu un rakstītu piekļuvi projekta API resursiem. OpenAI arī atklāj administratora API atslēgas objektus atsevišķi no parastā projekta/izpildlaika API lietojuma. Antropiski dokumentē darbvietas kā organizācijas robežu un norāda, ka Admin API galapunktiem ir nepieciešamas administratora API atslēgas, kas atšķiras no standarta API atslēgām; Anthropic arī atzīmē, ka API atslēgas ir piesaistītas darbvietai, kurā tās ir izveidotas, un tās nevar pārvietot starp darbvietām. Google Gemini API atslēgas dokumentācijā teikts, ka katra Gemini API atslēga ir saistīta ar Google Cloud projektu, un ieteikti API ierobežojumi, lai samazinātu bojājumus, ja atslēga tiek apdraudēta.

Ieteikums: neveidojiet vienu vispārīgu lauku “provider_key” un nesauciet to par pabeigtu. Izveidojiet akreditācijas datu krājumus, kas saglabā pakalpojumu sniedzējam noteiktās robežas, vienlaikus pakļaujot vārtejai normalizētu politikas modeli.

Pirms atslēgu pieņemšanas definējiet akreditācijas datu taksonomiju

Vetuvei ir jānoraida neskaidri akreditācijas dati. Importēšanas laikā operatoram vai automatizācijas darbplūsmai ir jāklasificē akreditācijas dati. Izmantojiet vismaz šīs kategorijas:

• Izpildlaika secinājumu akreditācijas dati: vārteja izmanto, lai izsauktu modeļa secinājumu galapunktus, piemēram, tērzēšanu, atbildes, iegulšanu, regulēšanu, transkripciju vai attēlu ģenerēšanu atkarībā no pakalpojumu sniedzēja atbalsta.
• Administratora automatizācijas akreditācijas dati: tiek izmantoti, lai pārvaldītu nodrošinātāja puses organizācijas, darbvietas, projektus, lietotājus, atslēgas vai administratīvos resursus. Tie nekad nedrīkst atrasties izpildlaika pieprasījuma ceļā.
• Norēķinu un pārskatu akreditācijas dati: izmanto, lai izgūtu lietojuma, rēķinu, izmaksu vai organizācijas pārskatus, ja pakalpojumu sniedzēji atbalsta šīs API. Glabājiet tās atsevišķi no secinājumu atslēgām, lai ziņošanas uzdevumi nevarētu ģenerēt modeļa lietojumu.
• Tikai novērtēšanai paredzēti akreditācijas dati: izmanto etalonu, kvalitātes nodrošināšanas, migrācijas vai stadiju darbplūsmās. Tiem ir jābūt zemām kvotām, skaidrām vides etiķetēm un bez ražošanas atkāpšanās piemērotības.
• Klienta BYOK akreditācijas dati: klienta nodrošinātas atslēgas, kas saistītas ar konkrētu nomnieku, pakalpojumu sniedzēja kontu, līgumu un datu politiku. Tos nevajadzētu apvienot koplietojamā maršrutā, ja vien klients to nepārprotami nav izvēlējies.

Šī taksonomija nav tikai dokumentācija. Tam vajadzētu vadīt piekļuves kontroles, maršrutēšanas piemērotības, brīdināšanas un rotācijas darbplūsmas. Ja akreditācijas dati tiek importēti bez kategorijas, īpašnieka, pakalpojumu sniedzēja konta robežām un atļautās izmantošanas, tie ir jāatspējo.

Saglabājiet noslēpumus glabātavā, nevis produktu ierakstos

Selvei ir jābūt vienīgajam komponentam, kas var atšifrēt augšupējos akreditācijas datus. Citas sistēmas var saglabāt atsauces, jaucējus, statusa laukus un politikas metadatus, bet ne pašu akreditācijas datu vērtību.

Neglabājiet augšējos noslēpumus šajās vietās

• Īrnieka profila rindas.
• Modeļa maršrutēšanas konfigurācijas faili.
• Uzvedināt žurnālus vai izsekošanas posmus.
• Analytics notikumu lietderīgās slodzes.
• Izstrādātājiem paredzēti CI mainīgie.
• Atbalstiet biļetes, tērzēšanas rīkus vai ekrānuzņēmumus.

Izmantojamam velves dizainam ir divas plaknes. Slepenajā plaknē tiek glabāti šifrēti akreditācijas dati un tiek stingri kontrolētas atšifrēšanas darbības. Metadatu plaknē tiek glabāti neslepeni atribūti, ko izmanto maršrutēšanai un pārvaldībai. Maršrutētājam parasti ir nepieciešams tikai akreditācijas datu ID un īslaicīga noslēpuma izguve atmiņā, nevis plaša piekļuve datubāzei katrai pakalpojumu sniedzēja atslēgai.

Aizsargājiet glabātuvi kā augstvērtīgu infrastruktūru: aplokšņu šifrēšana vai pārvaldīta KMS, stingras pakalpojumu identitātes, stikla izjaukšanas procedūras, dublēšanas un atjaunošanas pārbaude, piekļuves pārskatīšana un brīdinājumi par neparastu atšifrēšanas apjomu. Centrālā glabātuve vienkāršo pārvaldību, bet arī koncentrē risku. Tas ir kompromiss.

Pievienojiet politikas metadatus katram akreditācijas datiem

Metadatu modelim ir jābūt pietiekami precīzam, lai vārteja varētu izlemt, vai akreditācijas dati ir piemēroti, pirms tie saskaras ar nodrošinātāja galapunktu.

Praktiskajā akreditācijas datu ierakstā ir iekļauts:

• credential_id: iekšējais nemainīgs identifikators.
• nodrošinātājs: OpenAI, Anthropic, Gemini, Azure OpenAI vai cits adapteris.
• provider_account_boundary: organizācija, projekts, darbvieta, mākoņprojekts, abonements vai līdzvērtīgs abonements.
• credential_class: izpildlaiks, administrators, norēķini, novērtējums vai BYOK.
• vide: ražošana, iestudēšana, izstrāde, novērtēšana, smilškaste.
• tenant_binding: koplietojami platformas akreditācijas dati, viens nomnieks, nomnieku grupa vai klienta BYOK nomnieks.
• allowed_model_families: piemēram, teksta ģenerēšana, iegulšana, vīzija, attēls, audio vai konkrētu modeļu profili.
• allowed_endpoints: normalizētas vārtejas iespējas, kas piesaistītas pakalpojumu sniedzēja galapunktiem.
• data_policy: atļautā saglabāšanas klase, reģistrēšanas klase, dzīvesvietas prasība un funkciju ierobežojumi.
• budget_scope: izmaksu centrs, tālākpārdevēja klients, iekšējā nodaļa vai līgums.
• īpašnieks: nosaukta komanda vai atbildīgā persona.
• izveidots_at., derīguma termiņš, rotācijas_due_at., pēdējais_lietots_at.
• health_status: nezināms, veselīgs, degradēts, neatļauts, kvota_izlietots, atspējots.
• emergency_disable: tūlītējas maršrutēšanas bloks neatkarīgi no parastā politikas stāvokļa.

Saglabājiet šo modeļa nodrošinātāju neitrālu, taču neizdzēsiet nodrošinātāja realitāti. Antropiskā darbvietas atslēga un Gemini atslēga, kas piesaistīta Google mākoņa projektam, nav savstarpēji aizvietojamas tikai tāpēc, ka abas var ģenerēt tekstu. Vārtejai ir nepieciešama šī izcelsme auditiem, atmaksai un drošai kļūmjpārlēcei.

Atsevišķa izpildlaika, administratora un norēķinu piekļuve

Svarīgākais noteikums ir vienkāršs: izpildlaika secinājumiem izmantotā atslēga nedrīkst pārvaldīt nodrošinātāja organizācijas, darbvietas, lietotājus, projektus vai administratīvos resursus.

Izpildes laika datplūsma ir liela un pakļauta vislielākajai darbības virsmai. Tas iet caur pieprasījumu maršrutētājiem, atkārtošanas loģiku, straumēšanas apdarinātājiem, modeļu adapteriem un incidentu darbplūsmām. Administratora akreditācijas datiem ir zema frekvence un liela ietekme. Viņiem ir jāatrodas aiz atsevišķa apstiprināšanas ceļa ar īsiem TTL — attiecīgā gadījumā — cilvēka apstiprinājumu, spēcīgu reģistrēšanu un bez izpildlaika maršrutēšanas piemērotības.

Arī norēķinu akreditācijas dati ir jānodala. Pārskatu izveides uzdevums, kas saskaņo rēķinus, nedrīkst ģenerēt pabeigšanas, un izpildlaika secinājumu atslēga nedrīkst būt vienīgais veids, kā izgūt lietošanas pārskatus. Ja pakalpojumu sniedzējs nepiedāvā precīzu atdalīšanu, veiciet kompensāciju vārtejā: izolējiet akreditācijas datus, ierobežojiet to, kura iekšējā pakalpojuma identitāte tos var izgūt, un reģistrējiet katru lietojumu.

Ieteikums: padariet akreditācijas datu klasi par stingru autorizācijas robežu, nevis iezīmi. Izpildlaika dispečeram nevajadzētu būt iespējai pieprasīt administratora akreditācijas datu atšifrēšanu pat tad, ja konfigurācijas kļūda norāda uz tā ID.

Izveidojiet akreditācijas datu atlases politikas programmu

Akreditācijas datu atlasei jānotiek pēc tam, kad vārteja autentificē pakārtoto zvanītāju un pirms tiek mēģināts zvanīt pakalpojumu sniedzējam. Politikas programmai ir jāapvieno vairākas ievades:

• Īrnieka ID un pakārtotās API atslēgas darbības joma.
• Pieprasītais modeļa profils vai pakalpojumu sniedzēja modeļa ID.
• Galapunkta iespējas: tērzēšana, iegulšana, attēls, audio, pakete, faili, rīki vai administratora automatizācija.
• Datu saglabāšanas un dzīvesvietas prasības.
• Budžets, kredīta rezervēšana un izmaksu centrs.
• Likmes ierobežojuma stāvoklis un kvotas spiediens.
• Akreditācijas datu metadati, veselība, vide un nomnieka saistīšana.

Dzinējai ir jāatgriež viens no trim rezultātiem: atļaut ar atlasītu akreditācijas datu, noraidīt ar politikas iemeslu vai pieprasīt apstiprinājumu. Atteikumiem ir jābūt pietiekami precīziem, lai operāciju komandas varētu atrisināt problēmu, neatklājot izstrādātājiem slepenu materiālu.

Lēmuma piemērs:

{
  "īrnieka_id": "īrnieks_42",
  "requested_profile": "fast-text-prod",
  "endpoint": "chat.completions",
  "data_policy": "no_prompt_logging",
  "credential_requirements": {
    "class": "izpildlaiks",
    "vide": "ražošana",
    "tenant_binding": "īrnieks_42",
    "allowed_model_family": "teksts",
    "health_status": "veselīgs"
  },
  "lēmums": "atļaut",
  "credential_id": "cred_8f2...",
  "audit_reason": "īrnieka BYOK akreditācijas dati atbilst izpildlaika teksta profilam un datu politikai"
}

Neieviesiet atkāpšanos kā “izmēģiniet nākamo atslēgu”. Atkāpšanās politika ir jāatkārto. Koplietotās platformas akreditācijas dati var būt derīgi pakalpojumu sniedzēja piekļuvei, bet nederīgi klientam, kuram ir tikai BYOK. Akreditācijas datiem citā projektā var būt kvota, taču tas var pārkāpt izmaksu attiecinājuma vai saglabāšanas prasības.

Apstrādājiet BYOK kā īrniekam piederošu piekļuvi, nevis rezerves jaudu

BYOK maina uzticamības modeli. Klients iesniedza akreditācijas datus, lai no viņa trafika varētu iekasēt maksu, pārvaldīt to vai izolēt no pakalpojumu sniedzēja konta. Šiem akreditācijas datiem jābūt saistītiem ar klienta īrnieku un pakalpojumu sniedzēja konta izcelsmi.

Ieteicamās BYOK vadīklas:

• Viens glabātuves ieraksts katram klientam, pakalpojumu sniedzējam, konta robežai un videi.
• Nav starpīrnieku maršrutēšanas, izmantojot BYOK akreditācijas datus.
• Neizmantot kā kopīgu rezerves jaudu, ja vien klients to nepārprotami nav izvēlējies.
• Klientam redzams veselības stāvoklis, kas neatklāj neapstrādāto atslēgu.
• Atsevišķa rotācijas darbplūsma, kas ļauj klientam pievienot nomaiņu, pirms vecā atslēga tiek atspējota.
• Notīriet attiecinājumu lietojuma analīzē un rēķinos: vārtejas nomnieks, pakalpojumu sniedzēja konta robeža, akreditācijas datu ID, modeļa profils un pieprasījuma izsekošanas ID.

Aģentūrām, tālākpārdevējiem un partneru API automatizācijai BYOK var būt sarežģītāks, jo pakalpojums var programmatiski nodrošināt nomniekus un akreditācijas datus. Joprojām ir spēkā tas pats noteikums: automatizācija var importēt un saistīt akreditācijas datus, taču tai nevajadzētu aizmiglot nomnieka īpašumtiesības.

Pievienojiet pirmslidojuma veselības pārbaudes bez uzvedņu noplūdes

Akreditācijas dati var neizdoties daudzu iemeslu dēļ: atsaukta atslēga, nepareiza darbvieta, trūkst piekļuves modelim, atspējoti norēķini, kvotas izsmelšana, galapunkta ierobežojums, reģionālās politikas neatbilstība vai pakalpojumu sniedzēja darbības pārtraukums. To atklājot tikai pēc ražošanas pieprasījuma saņemšanas, rodas trokšņaini incidenti.

Izmantojiet veselības pārbaudes, kas apstiprina iespējas, nesūtot klienta uzvednes. Sintētiskā pārbaude var izsaukt minimālo beigu punktu, attiecīgā gadījumā uzskaitīt atļautos modeļus vai nosūtīt nekaitīgu fiksētu uzvedni, ja tā ir vienīgā praktiskā iespēja. Saglabājiet šos čekus lētus, ierobežotus tarifus un apzīmējiet kā sintētisku trafiku telemetrijas un norēķinu jomā.

Veselības pārbaudes jāveic:

• Importējot akreditācijas datus.
• Pirms akreditācijas datu iespējošanas ražošanas maršrutēšanai.
• Pēc pakalpojumu sniedzēja puses ierobežojumu izmaiņām.
• Rotācijas pārslēgšanas laikā.
• Periodiski, lai iegūtu akreditācijas datus, kas ir piemēroti ražošanai.

Kompozīcija: automatizētās pārbaudes agri konstatē atslēgas, kurām beidzies derīguma termiņš vai kurām ir nepietiekams tvērums, taču slikti izstrādātas pārbaudes pakalpojumu sniedzēja darbības pārtraukumu laikā var radīt nevajadzīgus pakalpojumu sniedzēja zvanus, norēķinu troksni vai viltus trauksmes. Saglabājiet veselības rezultātu ar laikspiedolu, pakalpojumu sniedzēja kļūdu klasi, pārbaudīto beigu punktu un pārbaudīto modeļu saimi. Neglabājiet slepenas vērtības vai sensitīvas uzvednes.

Rotējiet ar diviem slotiem, nevis vienu riskantu nomaiņu

Akreditācijas datu rotācija nedrīkst būt dzēšanas un lūgšanas darbība. Izmantojiet divu slotu rotācijas modeli:

1. Importējiet rezerves akreditācijas datus kā neaktīvus, ar pilniem metadatiem un īpašnieku.
2. Palaidiet sintētiskās veselības pārbaudes paredzētajiem galapunktiem, modeļu saimēm un konta robežām.
3. Iespējojiet ēnu piemērotību nelielai drošas sintētiskas vai zema riska datplūsmas daļai, ja nepieciešams.
4. Pakāpeniski pārslēdziet ražošanas trafiku no vecajiem akreditācijas datiem uz jauniem.
5. Pārraugiet kļūdas, latentumu, kvotu un izmaksu attiecinājumu pēc akreditācijas datu ID.
6. Iesaldējiet veco akreditācijas datu atkāpšanos, kad jaunie akreditācijas dati ir stabili.
7. Atsauciet vecos akreditācijas datus no pakalpojumu sniedzēja un atzīmējiet glabātuves ierakstu kā atsauktu.
8. Pārbaudiet, vai pēc atsaukšanas nenotiek atšifrēšana vai pakalpojumu sniedzēja izsaukumi, izmantojot vecos akreditācijas datus.

Rotācijas termiņiem jābūt redzamiem operāciju skatos un brīdinājumos. Ārkārtas rotācijai ir nepieciešams īsāks ceļš: atspējojiet akreditācijas datus, bloķējiet maršrutēšanu, iespējojiet apstiprinātu nomaiņu un saglabājiet visus audita ierakstus incidentu pārskatīšanai.

Ierobežojiet nodrošinātāja atslēgas, ja pakalpojumu sniedzējs to atbalsta

Vārtejas politika ir nepieciešama, taču pakalpojumu sniedzēja ierobežojumi samazina sprādziena rādiusu, ja atslēga tiek apdraudēta vai ļaunprātīgi izmantota. Gemini un citām mākoņa platformas API atslēgām izmantojiet API/pakalpojumu ierobežojumus un piemērotus lietojumprogrammu ierobežojumus, ja tie ir pieejami. Pakalpojumu sniedzēju projektiem, darbvietām un pakalpojumu kontiem izvairieties no plašām organizatoriskām privilēģijām, ja pietiek ar projekta darbības jomas izpildlaika atslēgu.

Ieteikums: katrai akreditācijas klasei uzturiet pakalpojumu sniedzēja ierobežojumu kontrolsarakstu. Kontrolsarakstam ir jābūt importa apstiprinājuma un rotācijas apstiprinājuma daļai, nevis atsevišķam drošības uzdevumam, kas var tikt izlaists zem spiediena.

Kompozīcija: pakalpojumu sniedzēja ierobežojumi palielina darbības izmaksas. Jauniem galapunktiem, modeļu saimēm, reģioniem vai automatizācijas līdzekļiem var būt nepieciešamas politikas un ierobežojumu izmaiņas. Tas ir vēlams, nevis atklāt pēc noplūdes, ka viena atslēga var piekļūt katrai koplietotā projekta darba slodzei.

Saglabājiet tikai pievienošanas akreditācijas datu audita žurnālu

Revīzijas izsekojamībai ir jāatbild, kas importēja akreditācijas datus, ko tam bija atļauts darīt, kuri maršrutēšanas lēmumi to atlasīja, kad tas neizdevās un kad tas tika pagriezts vai atsaukts.

Reģistrējiet šos notikumus:

• Izveidoti vai importēti akreditācijas dati.
• Mainīti metadati, tostarp atļautie galapunkti, nomnieka saistīšana vai datu politika.
• Veselības pārbaude veikta un rezultāts reģistrēts.
• Pieprasījuma maršrutēšanas politikā atlasītie akreditācijas dati.
• Iekšējā pakalpojuma identitāte pieprasa akreditācijas datu atšifrēšanu.
• Pakalpojumu sniedzēja izsaukums neizdevās autentifikācijas, autorizācijas, kvotas vai ierobežojuma kļūdas dēļ.
• Sākta rotācija, mainīta satiksme, atsaukti vecie akreditācijas dati.
• Avārijas atspējošana ir iespējota vai notīrīta.
• Piekļuve administratora vai stikla akreditācijas datiem.

Neievietojiet neapstrādātas akreditācijas vērtības revīzijas pasākumos. Izmantojiet akreditācijas datu ID, pakalpojumu sniedzēja kontu robežas, pieprasījumu izsekošanas ID, dalībnieku identitātes un politikas lēmumu iemeslus. Liela apjoma izpildlaika datplūsmai varat izmantot detalizētu telemetrijas atšifrēšanas paraugu, taču maršruta atlasei un izmaksu attiecināšanai ir jāpaliek pietiekami pilnīgai, lai varētu veikt rēķinus un reaģēt uz incidentiem.

Ieviešanas kontrolsaraksts

• Izveidojiet akreditācijas datu taksonomiju un noraidiet neklasificētu importu.
• Pārvietojiet visus pakalpojumu sniedzēja noslēpumus uz īpašu šifrētu glabātuvi.
• Uzglabājiet maršrutēšanas metadatus atsevišķi no slepenā materiāla.
• Padariet izpildlaika, administratora, norēķinu, novērtēšanas un BYOK akreditācijas datus atsevišķas autorizācijas klases.
• Saistiet BYOK akreditācijas datus ar nomnieka un pakalpojumu sniedzēja konta izcelsmi.
• Pieprasiet politikas dzinēja apstiprinājumu, pirms atlasāt jebkādus akreditācijas datus.
• Nekavējoties veiciet drošas veselības pārbaudes pirms ražošanas piemērotības.
• Izmantojiet divu vietu rotāciju ar pakāpenisku datplūsmas maiņu un pakalpojumu sniedzēja puses atsaukšanu.
• Piemērojiet pakalpojumu sniedzēja ierobežojumus visur, kur tie ir pieejami.
• Uzturiet tikai pievienošanas audita žurnālus importēšanai, lietošanai, kļūmēm, rotācijai un atsaukšanai.
• Saglabājiet administratora akreditācijas datus aiz nolaužamām vadīklām: īss TTL, nosaukts apstiprinājums, spēcīga reģistrēšana, bez izpildlaika lietošanas.

Lietojams secinājums

Sāciet, inventarizējot katru augšupējo pakalpojumu sniedzēja akreditācijas datus, ko pašlaik izmanto vārteja, skriptus, CI darbus, novērtēšanas sistēmas un partneru automatizāciju. Katram no tiem piešķiriet klasi, īpašnieku, nodrošinātāja konta robežu, nomnieka saistīšanu, atļautos galapunktus, atļautās modeļu saimes, rotācijas termiņu un ārkārtas atspējošanas statusu. Viss, ko nevarat klasificēt, ir jāatspējo vai jāievieto karantīnā, līdz tam ir skaidrs mērķis.

Pēc tam izpildiet vienu arhitektūras noteikumu: pakārtotie izstrādātāji saņem vārtejas tvēruma atslēgas; tikai vārteja kontrolē augšupējo pakalpojumu sniedzēja piekļuvi. Šī nodalīšana ļauj saglabāt vismazākās privilēģijas, nomnieka attiecinājumu, norēķinu precizitāti, datu politikas maršrutēšanu un drošu automatizāciju pat tad, ja pakalpojumu sniedzēji, projekti, darbvietas un BYOK klienti vairojas.

Saistītā informācija

• komandas API atslēgas pārvaldība un reaģēšana uz noplūdi
• data-retention-aware maršrutēšanas politikas
• virsgrāmatas un izmaksu attiecinājuma vadīklas