portfolio-optimiser/docs/2026-08-18-vurdering-azure-omdoeping.md

Vurdering: skal Azure-ressursene døpes om?

Bestilt av ordre 20260818T103716Z-251212929 (fra .claude). Leveransen er en vurdering, ikke en omdøping — ingenting i Azure er rørt. Beslutningen er operatørens.

Alt under er enten målt i dette repoet eller verifisert mot Microsoft Learn. Der noe ikke er verifisert, står det. Kildene er listet i §6.

1. Hva røper koordinatene faktisk?

Koordinatene som nådde en ekstern organisasjon 14.08 (i dist/portfolio-optimiser-foundry-1.1.0.zip, bygget 14:24):

Verdi	Type
<resource-group>	ressursgruppe (ARM-planet)
<resource>	Foundry-ressurs = custom subdomain (DNS)
<project>	prosjekt (ARM + data-plan-sti)
eastus	region
https://<resource>.services.ai.azure.com/api/projects/<project>	prosjekt-endepunkt

De literale navnene er byttet mot plassholdere her, samme form som DEPLOY.md, auth-oppskriften og måleprotokollen etter 241b50d. Dokumentet handler om hva navnene er, ikke om hvilke de var — og innholds-gaten i tests/test_handover_package_loadbearing.py avviste førsteutkastet som bar dem.

Utledbart uansett — ikke lekket av oss:

• At det er en AIServices-ressurs med prosjekter. URL-formen …/api/projects/<project> ER den dokumenterte Foundry-prosjekt-endepunkt-formen. Enhver som ser en slik URL vet ressurstypen.
• Modell, versjon og deployment-navn (gpt-4.1-mini, 2025-04-14, GlobalStandard). Offentlig katalog-nomenklatur.
• Rolle-GUID-en 53ca6127-db72-4b80-b1b0-d745d6d5456d. Azures offentlige innebygde role definition id for Foundry User, identisk i hver tenant. Den står i Learn-dokumentasjonen. Den er ikke en koordinat, og skal ikke plassholdes.
• At vertsnavnet i det hele tatt er et globalt, gjettbart navnerom. Custom subdomain ligger under ett felles DNS-navnerom, og navnet er unikt på tvers av alle kunder — så eksistensen av et gitt navn kan enhver bekrefte ved å slå det opp. Lekkasjen fjernet gjettingen, ikke muligheten.

Kun kjent fordi navnene lekket:

• Ressursgruppenavnet. Det finnes ikke i DNS og ikke i noen data-plan-URL. Det er rent ARM-plan-informasjon.
• Regionen (eastus). Ikke utledbar fra vertsnavnet for *.services.ai.azure.com.
• Prosjektnavnet (<project>) — det står riktignok i endepunkts-URL-en, men URL-en er selv en del av lekkasjen.
• Koblingen mellom dem. Det operativt verdifulle er ikke ett navn, men at ressursgruppe, ressurs, prosjekt, region og rolle-scope kommer som ett ferdig sett.

Kort: dette er rekognoseringsinformasjon om ARM-planet. Det er ikke nøkler, og det er ikke tenant-id eller abonnements-id — ingen av de to sto i dokumentet (målt: 0 treff på /subscriptions/<guid> i hele treet og i den leverte pakka).

2. Hva skal til for å misbruke dem?

Det Entra faktisk stopper

Et kall mot prosjekt-endepunktet krever både et gyldig Entra-token for scopet https://ai.azure.com/.default og en RBAC-tildeling på ressurs- eller prosjekt-scope. Microsofts egen feilkode-tabell skiller de to: 401 = manglende/utløpt token, 403 = manglende rolletildeling. Å kjenne adressen gir altså i seg selv null inferens-tilgang.

Token-basert auth krever dessuten et custom subdomain — regionale endepunkter støtter ikke Entra i det hele tatt. Vi bruker custom subdomain, altså er Entra-stien tilgjengelig.

Det Entra ikke stopper

1. Nøkkelbasert auth, hvis den er på. Entra blir eneste autorisasjonsmetode først når disableLocalAuth er satt til true — det er en eksplisitt handling (Azure Policy på abonnement/ressursgruppe, disableLocalAuth i ARM/Bicep, eller Set-AzCognitiveServicesAccount -DisableLocalAuth $true). Er den ikke satt, finnes det nøkler som omgår Entra fullstendig. Ikke verifisert for denne ressursen: az cognitiveservices account create-kommandoen i måleprotokollen (docs/2026-08-14-fase1b-forste-levende-kjoring.md §0) ba ikke om det, og om abonnementet har policyen er ukjent herfra. Dette er den ene sjekken som faktisk endrer risikobildet — se §4. Merk også at avslåing ikke slår inn momentant: endringen skjer i kontrollplanet med én gang, men gatewayen kan godta tidligere gyldige nøkler til cachen oppdateres — typisk minutter, opptil flere timer. Og allerede utdelte nøkler må regenereres separat; å slå av lokal auth tilbakekaller dem ikke.
2. Målrettet phishing og consent-phishing. Koordinatene gjør en henvendelse troverdig — avsender kan navngi ressursgruppe, ressurs og prosjekt riktig. Entra beskytter identiteten, ikke overtalelsen. Dette er den mest realistiske misbruksveien for denne typen lekkasje.
3. Kvote- og kostnadsmisbruk ved kompromittert identitet. Kvote tildeles per abonnement, per region, per modell og deployment-type, i tokens-per-minutt, og deles av alle deployments av samme modell i samme region i abonnementet. En misbrukt identitet med Foundry User på dette prosjektet spiser altså av en pott som er felles, og kan strupe andre deployments av samme modell i samme abonnement — ikke bare denne. Forbruket faktureres.
4. Nettverksflaten. publicNetworkAccess er en egenskap som må settes til Disabled for å stenge den offentlige inngangen. Er den ikke det, er endepunktet nåbart fra internett — det var sant før lekkasjen også. Forskjellen er at adressen nå er kjent, ikke at den ble nåbar.

Ikke verifisert: om et uautentisert kall skiller et eksisterende prosjektnavn fra et ikke-eksisterende (altså om <project> kan bekreftes uten token). Det ville krevd et faktisk kall mot en fremmed ressurs, og det er ikke gjort.

3. Hva koster omdøping?

I repoet: null

Målt på 6d2837f (= open/main = origin/main), nevner 327 sporede filer:

Sted	Treff på de tre literale navnene
Sporet tre (kode, tester, docs, env.template)	0
Usporet deck docs/presentasjon-portfolio-optimiser.html	0
shared/ (subtree)	0

De 18 gjenværende linjene med services.ai.azure.com er plassholderformen (<resource>.), wildcard-formen (*.) eller testdummies (x., platform., wrong.). env.template bærer variabelnavn, aldri verdier. Omdøping krever altså ingen redigering i repoet — 241b50d gjorde allerede den jobben.

I historikken og i den leverte pakka: kan ikke tilbakekalles

• Git-historikken: 3 linjer i 1 fil, i 3 commits (5bd8e1c, bb4807a, 241b50d). Publisert på open/main. Ordren forbyr å skrive om historikken, og vei B ble alt avvist 18.08.
• Den leverte pakka: 4 linjer, hos en tredjepart siden 14.08. En omdøping i Azure gjør ikke det usett.

I Azure: en full riving og gjenoppbygging

Et custom subdomain kan ikke endres. Microsoft er eksplisitt: navnet kan ikke endres etter at det er opprettet og knyttet til ressursen, og for å gjenbruke et navn må den eksisterende ressursen slettes. «Omdøping» finnes derfor ikke som operasjon — det er:

1. opprett ny AIServices-ressurs med nytt subdomain (+ --allow-project-management)
2. opprett nytt prosjekt
3. redeploy gpt-4-1-mini (ny kvotetildeling i regionen)
4. tildel Foundry User på nytt prosjekt-scope
5. oppdater PORTFOLIO_FOUNDRY_PROJECT_ENDPOINT og PORTFOLIO_MODEL_MAP lokalt
6. slett — og purge — den gamle ressursen (purge krever Contributor på abonnements-scope)
7. re-kjør stigen i måleprotokollen §1 for å bevise at auth/RBAC/endepunkt fortsatt komponerer

Ikke verifisert: om det gamle subdomain-navnet holdes reservert en periode etter sletting slik App Service og API Management gjør (anti-subdomain-takeover). Learn dokumenterer den mekanismen for de tjenestene, men ikke for Foundry-/Cognitive Services-subdomener. Ikke anta at navnet frigis — og ikke anta at det er låst.

4. Anbefaling — og hva hvert valg koster

Anbefalingen er: ikke døp om. Fjern i stedet den ene veien som ikke går gjennom Entra, og gjør misbruk synlig.

Begrunnelsen er at omdøping løser feil problem. Det lekkasjen ga en motpart er målretting, ikke tilgang. Og målrettingen kan ikke trekkes tilbake: navnene ligger i publisert git-historikk og i en zip hos en tredjepart. En omdøping ville altså kjøpt at dagens ressurs ikke er den som ble navngitt — ikke at navngivingen forsvinner. Det er en reell, men liten gevinst, og den betales med en full riving av det eneste levende Foundry-oppsettet prosjektet har.

Valg A — behold navnene, herd oppsettet (anbefalt).

• Sjekk DisableLocalAuth på ressursen. Er den ikke true: regenerer begge nøklene og sett den. Dette er den eneste tiltaket som fjerner en autorisasjonsvei Entra ikke dekker.
• Sjekk at rolletildelingen står på prosjekt-scope og ikke bredere, og vurder Foundry Agent Consumer framfor Foundry User dersom kjøringene bare gjør inferens.
• Sett et kostnadsvarsel på abonnementet og hold TPM-tildelingen på deploymentet lav. Kvotemisbruk blir da både begrenset og synlig.
• Konsekvens: måleprotokollen forblir reproduserbar, ingen ny kjøring må betales, og navnene fortsetter å stå i historikken — som de ville gjort uansett.

Valg B — riv og bygg opp igjen med et intetsigende navn.

• Kjøper: at et navn en motpart eventuelt sitter og venter på, ikke lenger peker på noe levende.
• Koster: de sju stegene i §3, ny betalt verifiseringskjøring, og at docs/2026-08-14-fase1b-forste-levende-kjoring.md beskriver et oppsett som ikke finnes lenger.
• Kjøper ikke: at navnene forsvinner fra historikken eller fra den leverte pakka.
• Velg denne hvis vurderingen er at ressursgruppe- og prosjektnavnet i seg selv er sensitivt i organisasjonssammenheng — det er en vurdering operatøren kan gjøre og ikke jeg.

Valg C — gjør begge. Herdingen i A er verdt å gjøre uansett hvilket av A og B som velges; B uten A etterlater den samme nøkkel-veien åpen på en ny ressurs.

5. Hva denne vurderingen ikke dekker

• Ingenting i Azure er inspisert. Alle utsagn om denne ressursens faktiske konfigurasjon (disableLocalAuth, publicNetworkAccess, rolle-scope) er markert som uverifiserte over.
• Innholds-gaten fanger vertsnavnet, ikke ressursgruppe- og prosjektnavnet. Et vertsnavn har en struktur (<label>.services.ai.azure.com); en ressursgruppe heter hva som helst. De to andre navnene ble bare oppdaget fordi de sto i samme tabell som verten. En gate kan ikke lukke det gapet uten en navneliste, og en navneliste er den andre kopien av eksponeringsregelen.
• Ordre-teksten sa at koordinatene fortsatt sto i repoet. Det er ikke tilfelle per 6d2837f — målt, se §3. Premisset var riktig da ordren ble skrevet (10:37Z) og sluttet å være det 13:03.

6. Kilder

Alle verifisert 18.08.2026 mot Microsoft Learn:

• Custom subdomain kan ikke endres; må slette ressursen for å gjenbruke navnet — learn.microsoft.com/azure/ai-services/cognitive-services-custom-subdomains
• Entra-auth krever custom subdomain; 401 vs 403; scope https://ai.azure.com/.default — learn.microsoft.com/azure/foundry/concepts/authentication-authorization-foundry
• disableLocalAuth er en eksplisitt handling; propagering minutter til timer; nøkler må regenereres separat — learn.microsoft.com/azure/ai-services/disable-local-auth
• Rolle-id 53ca6127-db72-4b80-b1b0-d745d6d5456d = Foundry User, offentlig og lik i hver tenant; Foundry Agent Consumer som minste-privilegium for ren inferens — learn.microsoft.com/azure/foundry/concepts/rbac-foundry
• Kvote per abonnement/region/modell/deployment-type i TPM; deles av deployments i samme region — learn.microsoft.com/azure/foundry/openai/how-to/quota
• publicNetworkAccess / disableLocalAuth som ARM-egenskaper — learn.microsoft.com/azure/templates/microsoft.cognitiveservices/accounts
• Anti-subdomain-takeover-reservasjon (dokumentert for App Service / API Management, ikke for Cognitive Services) — learn.microsoft.com/azure/security/fundamentals/subdomain-takeover