# 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 | |---|---| | `` | ressursgruppe (ARM-planet) | | `` | Foundry-ressurs = **custom subdomain** (DNS) | | `` | prosjekt (ARM + data-plan-sti) | | `eastus` | region | | `https://.services.ai.azure.com/api/projects/` | 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/` 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** (``) — 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/` 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 `` 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 (`.`), 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 (`