Denne browser understøttes ikke længere.
Opgrader til Microsoft Edge for at drage fordel af de nyeste funktioner, sikkerhedsopdateringer og teknisk support.
Besvar følgende spørgsmål for at tjekke din forståelse af API-administrationssikkerhed.
En sikkerhedsingeniør konfigurerer politikken validate-azure-ad-token på et partnervendt API i API Management. Hvad skal hver opkalder oplyse i politikken for at tillade anmodningen?
validate-azure-ad-token
Et gyldigt Microsoft Entra ID-adgangstoken i autorisationsheaderen, udstedt for det tilladte applikations-ID og lejer
En abonnementsnøgle i Ocp-Apim-Subscription-Key-headeren
Et klientcertifikat præsenteret under TLS-håndtrykket
En PKCE-kode-verificeringsenhed i autorisationsheaderen ved siden af tokenet
Contoso Retails partnerkontrakt tillader 10.000 API-opkald om måneden, men kræver også, at ingen partner må overstige 200 opkald i minuttet. Hvilken kombination af API-administrationspolitikker håndhæver begge krav?
Anvend takstbegrænsningspolitikken til at håndhæve minutgrænsen og kvotepolitikken til at håndhæve den månedlige grænse
Anvend takstbegrænsningspolitikken to gange—én gang med en fornyelsesperiode på 60 sekunder og én gang med en fornyelsesperiode på 2.592.000 sekunder
Anvend rate-limit-by-key-politikken med en tællenøgle sat på abonnements-ID'et for begge grænser
Konfigurer en enkelt kvotepolitik med to båndbreddetærskler—én til opkald og én til dataoverførsel
En API-gateway videresender partneranmodninger til et backend-API via HTTPS. Med standard TLS verificerer partnerens applikation backend-serverens certifikat. Hvad tilføjer mutual TLS (mTLS), som standard TLS ikke tilbyder?
Backend-serveren verificerer også klientens certifikat, så begge parter autentificerer hinandens identitet, før forbindelsen etableres
Forbindelsen bruger TLS 1.3 i stedet for TLS 1.2, hvilket giver stærkere forhandling i cipher suite-systemet
Servercertifikatet underskrives af en offentlig certifikatmyndighed i stedet for en privat CA, hvilket forbedrer tillidskædens verifikation
Sessionnøgler roteres oftere under forbindelsen for at reducere eksponering fra en kompromitteret nøgle
Contoso Retails Azure OpenAI-baserede produktanbefalings-API bør kun være tilgængelig for interne applikationer på virksomhedens private netværk – der er ikke tilladt offentlig internetadgang til API-administrationsgatewayen, der hoster dette API. Hvilken virtuel netværksintegrationstilstand opfylder dette krav?
Intern tilstand, som implementerer API-administration fuldt ud inde i det virtuelle netværk uden et offentligt endpoint
Ekstern tilstand, som placerer API-administration i det virtuelle netværk, mens en offentlig IP-adresse bevares
Konfigurer en netværkssikkerhedsgruppe (NSG) på API Management-subnettet til at blokere al indgående internettrafik
Aktivér det private endpoint for indgående adgang og deaktiver standard gateway-endpointet
Contoso Retail dirigerer Azure OpenAI-kald gennem API Management. En enkelt partnerabonnent sender lejlighedsvis en række komplekse dokumentopsummeringsanmodninger, som hver bruger 8.000 tokens pr. opkald. Hvorfor er azure-openai-token-limit-politikken mere effektiv end den standard rate-limit-politik til at styre denne abonnents forbrug?
AI-API-omkostningerne drives af tokenforbrug – nogle få tokenintensive kald kan udtømme provisioneret gennemstrømning lige så effektivt som et stort antal letvægtskald
azure-openai-token-limit-politikken gælder pr. API-operation, mens rate-limit kun gælder i produktomfang
Azure OpenAI returnerer HTTP 429-fejl, som rate-limit ikke kan opsnappe, men azure-openai-token-limit behandler disse, før de når frem til opkalderen
Rate-limit-politikken virker kun, når abonnementsnøgler er aktiveret, men azure-openai-token-limit fungerer uden abonnementsnøgler
Du skal svare på alle spørgsmål, før du kontrollerer dit arbejde.
Var denne side nyttig?
Har du brug for hjælp til dette emne?
Vil du prøve at bruge Ask Learn til at tydeliggøre eller guide dig gennem dette emne?