feat(ultraplan-local): v1.6.0 — /ultraresearch-local deep research command
Add /ultraresearch-local for structured research combining local codebase analysis with external knowledge via parallel agent swarms. Produces research briefs with triangulation, confidence ratings, and source quality assessment. New command: /ultraresearch-local with modes --quick, --local, --external, --fg. New agents: research-orchestrator (opus), docs-researcher, community-researcher, security-researcher, contrarian-researcher, gemini-bridge (all sonnet). New template: research-brief-template.md. Integration: --research flag in /ultraplan-local accepts pre-built research briefs (up to 3), enriches the interview and exploration phases. Planning orchestrator cross-references brief findings during synthesis. Design principle: Context Engineering — right information to right agent at right time. Research briefs are structured artifacts in the pipeline: ultraresearch → brief → ultraplan --research → plan → ultraexecute. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Kjell Tore Guttormsen
commit
baa2d0220b
488 changed files with 213221 additions and 0 deletions
|
|
@ -0,0 +1,749 @@
|
|||
# Security and Access Control in MLOps
|
||||
|
||||
**Kategori:** MLOps & GenAIOps
|
||||
**Dato:** 2026-02-04
|
||||
**Confidence:** HIGH — Basert på offisiell Microsoft Learn dokumentasjon (8 MCP-oppslag, 16 kilder)
|
||||
|
||||
---
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Security and access control utgjør fundamentet for enterprise-grade MLOps i Azure Machine Learning. Denne kunnskapsreferansen dekker identitetsstyring, nettverksisolasjon, datakryptering og tilgangskontroll gjennom hele ML-livssyklusen — fra treningsjobber til produksjons-endpoints.
|
||||
|
||||
**Hvorfor dette er kritisk for MLOps:**
|
||||
- Beskytter treningsdata, modeller og inferens-endepunkter mot uautorisert tilgang
|
||||
- Sikrer compliance med GDPR, ePrivacy-direktivet og norske personvernkrav
|
||||
- Reduserer risiko for data exfiltration i delte workspace-miljøer
|
||||
- Muliggjør audit trails og samsvarskontroll for regulerte virksomheter
|
||||
|
||||
I produksjonsmiljøer er sikkerhet ikke en tilleggsfunksjon, men en arkitekturell forutsetning.
|
||||
|
||||
---
|
||||
|
||||
## Kjernekomponenter
|
||||
|
||||
### 1. Identitetshåndtering med Managed Identities
|
||||
|
||||
Azure Machine Learning støtter to typer managed identities for service-to-service autentisering:
|
||||
|
||||
#### System-Assigned Managed Identity (SAI)
|
||||
- **Livssyklus:** Automatisk opprettet og slettet sammen med workspace/compute
|
||||
- **Bruksområde:** Standard for workspace → storage/keyvault/ACR kommunikasjon
|
||||
- **Permissions (workspace SAI):**
|
||||
- `Contributor` på workspace
|
||||
- `Storage Blob Data Contributor` på storage account
|
||||
- Full access til Key Vault keys/secrets/certificates
|
||||
- `Contributor` på Container Registry
|
||||
|
||||
```azurecli
|
||||
# Verifiser workspace identity
|
||||
az ml workspace show --name <workspace-name> \
|
||||
--resource-group <resource-group> \
|
||||
--query identity
|
||||
```
|
||||
|
||||
#### User-Assigned Managed Identity (UAI)
|
||||
- **Livssyklus:** Uavhengig av workspace — kan gjenbrukes på tvers av ressurser
|
||||
- **Bruksområde:** Multi-workspace scenarios, shared resources, least-privilege access
|
||||
- **Fordeler:**
|
||||
- Granular tilgangskontroll per compute cluster
|
||||
- Data isolation i delte storage accounts (via ABAC conditions)
|
||||
- Enklere key rotation og credential management
|
||||
|
||||
**Oppsett av UAI for workspace:**
|
||||
|
||||
```yaml
|
||||
# workspace-uai.yml
|
||||
identity:
|
||||
type: user_assigned
|
||||
user_assigned_identities:
|
||||
'<UAI-resource-ID-1>': {}
|
||||
'<UAI-resource-ID-2>': {}
|
||||
storage_account: <storage-account-resource-ID>
|
||||
key_vault: <key-vault-resource-ID>
|
||||
primary_user_assigned_identity: <UAI-resource-ID-1>
|
||||
```
|
||||
|
||||
```azurecli
|
||||
az ml workspace create -f workspace-uai.yml \
|
||||
--subscription <subscription-id> \
|
||||
--resource-group <resource-group> \
|
||||
--name <workspace-name>
|
||||
```
|
||||
|
||||
**RBAC-krav for UAI (minimum):**
|
||||
|
||||
| Ressurs | Rolle | Hvorfor |
|
||||
|---------|-------|---------|
|
||||
| Workspace | `Contributor` | Control plane operations |
|
||||
| Storage Account | `Storage Blob Data Contributor` | Data plane access (blob) |
|
||||
| Key Vault (RBAC-modell) | `Key Vault Administrator` | Data plane access |
|
||||
| Container Registry | `Contributor` | Image pull/push |
|
||||
| Application Insights | `Contributor` | Logging og metrics |
|
||||
|
||||
#### Compute Cluster Identity
|
||||
|
||||
Compute clusters støtter **enten** system-assigned **eller** user-assigned identities (ikke begge samtidig).
|
||||
|
||||
**Use case: Identity-based data access i treningsjobber**
|
||||
|
||||
```python
|
||||
# I treningsjobb — bruk compute cluster sin managed identity
|
||||
import os
|
||||
from azure.identity import ManagedIdentityCredential
|
||||
|
||||
client_id = os.environ.get('DEFAULT_IDENTITY_CLIENT_ID')
|
||||
credential = ManagedIdentityCredential(client_id=client_id)
|
||||
token = credential.get_token('https://storage.azure.com/')
|
||||
```
|
||||
|
||||
**Opprette compute cluster med UAI:**
|
||||
|
||||
```yaml
|
||||
# compute-cluster-uai.yml
|
||||
name: secure-cluster
|
||||
type: amlcompute
|
||||
size: STANDARD_D2_V2
|
||||
min_instances: 0
|
||||
max_instances: 4
|
||||
identity:
|
||||
type: user_assigned
|
||||
user_assigned_identities:
|
||||
- resource_id: "/subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<identity-name>"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 2. Role-Based Access Control (RBAC)
|
||||
|
||||
Azure Machine Learning bruker Azure RBAC for tilgangskontroll til workspace, data plane og compute resources.
|
||||
|
||||
#### Built-in roller
|
||||
|
||||
| Rolle | Tilganger | Bruksområde |
|
||||
|-------|-----------|-------------|
|
||||
| `AzureML Data Scientist` | Submit jobs, view data, manage models | Standard datavitenskapsrolle |
|
||||
| `AzureML Compute Operator` | Manage compute resources | Infrastruktur-team |
|
||||
| `Reader` | View workspace metadata | Audit og reporting |
|
||||
| `Contributor` | Full workspace access | Workspace administrators |
|
||||
|
||||
#### Custom Roles for MLOps
|
||||
|
||||
**Eksempel: Minste privilegium for production deployment**
|
||||
|
||||
```json
|
||||
{
|
||||
"Name": "MLOps Deployment Role",
|
||||
"Description": "Can deploy models to production endpoints",
|
||||
"Actions": [
|
||||
"Microsoft.MachineLearningServices/workspaces/onlineEndpoints/write",
|
||||
"Microsoft.MachineLearningServices/workspaces/onlineEndpoints/deployments/write",
|
||||
"Microsoft.MachineLearningServices/workspaces/models/*/read"
|
||||
],
|
||||
"NotActions": [],
|
||||
"AssignableScopes": [
|
||||
"/subscriptions/<subscription-id>/resourceGroups/<rg>/providers/Microsoft.MachineLearningServices/workspaces/<workspace>"
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
```azurecli
|
||||
az role definition create --role-definition mlops-deploy-role.json
|
||||
az role assignment create --assignee <identity-id> \
|
||||
--role "MLOps Deployment Role" \
|
||||
--scope "/subscriptions/<sub-id>/resourceGroups/<rg>"
|
||||
```
|
||||
|
||||
#### RBAC Best Practices for MLOps
|
||||
|
||||
1. **Separate Dev/Prod permissions:** Bruk forskjellige roller for utvikling og produksjon
|
||||
2. **Compute cluster access:** Grant `Storage Blob Data Reader` til compute identity for datastore access
|
||||
3. **Endpoint authentication:** Bruk Entra ID token-based auth fremfor static keys
|
||||
4. **Service principal rotation:** Bruk managed identities fremfor service principals med secrets
|
||||
5. **Just-in-time access:** Kombiner med Microsoft Entra PIM for privileged operations
|
||||
|
||||
---
|
||||
|
||||
### 3. Nettverksisolasjon
|
||||
|
||||
#### Managed Virtual Network (anbefalt for nye workspaces)
|
||||
|
||||
Azure ML Managed VNet tilbyr fully managed nettverksisolasjon uten manuell konfigurasjon.
|
||||
|
||||
**Støttede compute-typer:**
|
||||
- Serverless compute (inkl. Spark)
|
||||
- Compute cluster
|
||||
- Compute instance
|
||||
- Managed online endpoint
|
||||
- Batch endpoint
|
||||
|
||||
**Outbound-modi:**
|
||||
|
||||
| Modus | Beskrivelse | Use case |
|
||||
|-------|-------------|----------|
|
||||
| `Allow Internet Outbound` | Tillater all utgående trafikk | Dev/test miljøer |
|
||||
| `Allow Only Approved Outbound` | Kun godkjente private endpoints/FQDNs | Produksjon (anbefalt) |
|
||||
|
||||
**Oppsett:**
|
||||
|
||||
```azurecli
|
||||
az ml workspace create --name <workspace> \
|
||||
--resource-group <rg> \
|
||||
--managed-network allow_only_approved_outbound
|
||||
```
|
||||
|
||||
#### Private Endpoint for Workspace
|
||||
|
||||
Private endpoints reduserer attack surface ved å eksponere workspace kun via private IP-adresser i VNet.
|
||||
|
||||
**Opprett private endpoint:**
|
||||
|
||||
```azurecli
|
||||
az network private-endpoint create \
|
||||
--name <pe-name> \
|
||||
--vnet-name <vnet-name> \
|
||||
--subnet <subnet-name> \
|
||||
--private-connection-resource-id "/subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.MachineLearningServices/workspaces/<workspace>" \
|
||||
--group-id amlworkspace \
|
||||
--connection-name workspace \
|
||||
--location <location>
|
||||
```
|
||||
|
||||
**DNS-konfigurasjon (påkrevd):**
|
||||
|
||||
```azurecli
|
||||
# Opprett private DNS zone for workspace API
|
||||
az network private-dns zone create \
|
||||
--resource-group <rg> \
|
||||
--name privatelink.api.azureml.ms
|
||||
|
||||
az network private-dns link vnet create \
|
||||
--resource-group <rg> \
|
||||
--zone-name privatelink.api.azureml.ms \
|
||||
--name ml-dns-link \
|
||||
--virtual-network <vnet-name> \
|
||||
--registration-enabled false
|
||||
|
||||
az network private-endpoint dns-zone-group create \
|
||||
--resource-group <rg> \
|
||||
--endpoint-name <pe-name> \
|
||||
--name ml-zone-group \
|
||||
--private-dns-zone privatelink.api.azureml.ms \
|
||||
--zone-name privatelink.api.azureml.ms
|
||||
```
|
||||
|
||||
#### Storage Account Private Endpoints
|
||||
|
||||
For å unngå data exfiltration må storage accounts også isoleres:
|
||||
|
||||
**Påkrevde private endpoints:**
|
||||
- **Blob** (alltid)
|
||||
- **File** (alltid)
|
||||
- **Queue** (kun for Batch endpoints / ParallelRunStep)
|
||||
- **Table** (kun for Batch endpoints / ParallelRunStep)
|
||||
|
||||
**Trusted service exception:**
|
||||
|
||||
I Storage Account firewall, velg:
|
||||
- **"Selected networks"**
|
||||
- **Resource instances:** `Microsoft.MachineLearningServices/Workspace`
|
||||
- **Instance name:** `<your-workspace>`
|
||||
|
||||
Dette tillater workspace managed identity å kommunisere med storage selv bak firewall.
|
||||
|
||||
---
|
||||
|
||||
### 4. Datakryptering
|
||||
|
||||
#### Encryption at Rest
|
||||
|
||||
**Platform-managed keys (standard):**
|
||||
- Storage accounts: AES-256
|
||||
- Cosmos DB metadata: Microsoft-managed keys
|
||||
- Compute OS disks: Microsoft-managed keys
|
||||
|
||||
**Customer-managed keys (CMK):**
|
||||
|
||||
CMK gir ekstra kontroll over krypteringsnøkler, spesielt viktig for:
|
||||
- GDPR compliance
|
||||
- Regulerte sektorer (finans, helse, offentlig sektor)
|
||||
- "Bring your own key" (BYOK) policies
|
||||
|
||||
**Ressurser som bruker CMK:**
|
||||
- Azure Cosmos DB (workspace metadata)
|
||||
- Azure AI Search (workspace indexes)
|
||||
- Azure Storage (workspace artifacts)
|
||||
|
||||
**Oppsett av CMK-workspace:**
|
||||
|
||||
```azurecli
|
||||
# Opprett Key Vault med soft delete + purge protection
|
||||
az keyvault create --name <kv-name> \
|
||||
--resource-group <rg> \
|
||||
--enable-soft-delete \
|
||||
--enable-purge-protection
|
||||
|
||||
# Opprett RSA-nøkkel (minimum 3072-bit)
|
||||
az keyvault key create \
|
||||
--vault-name <kv-name> \
|
||||
--name workspace-cmk \
|
||||
--kty RSA \
|
||||
--size 3072
|
||||
|
||||
# Hent nøkkel-ID
|
||||
KEY_ID=$(az keyvault key show --vault-name <kv-name> \
|
||||
--name workspace-cmk --query key.kid -o tsv)
|
||||
|
||||
# Opprett workspace med CMK
|
||||
az ml workspace create --name <workspace> \
|
||||
--resource-group <rg> \
|
||||
--customer-managed-key $KEY_ID \
|
||||
--key-vault /subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.KeyVault/vaults/<kv-name>
|
||||
```
|
||||
|
||||
**Begrensninger:**
|
||||
- Nøkkelen må være i samme Azure subscription som workspace
|
||||
- Compute OS-disker kan **ikke** krypteres med CMK (kun Microsoft-managed keys)
|
||||
- Temporary disks på compute: Kun kryptert hvis `hbi_workspace=true`
|
||||
|
||||
#### High Business Impact (HBI) Workspace
|
||||
|
||||
Når `hbi_workspace=true`:
|
||||
- Lokal scratch disk på compute instance krypteres
|
||||
- Temporary disk på compute cluster krypteres
|
||||
- Reduserer telemetri som Microsoft samler inn
|
||||
- Ekstra kryptering i Microsoft-managed environments
|
||||
|
||||
```azurecli
|
||||
az ml workspace create --name <workspace> \
|
||||
--resource-group <rg> \
|
||||
--hbi-workspace true
|
||||
```
|
||||
|
||||
#### Encryption in Transit
|
||||
|
||||
All kommunikasjon bruker **TLS 1.2**:
|
||||
- Workspace ↔ Storage Account
|
||||
- Workspace ↔ Compute
|
||||
- Studio ↔ Workspace API
|
||||
- Inference clients ↔ Online endpoints
|
||||
|
||||
**For online endpoints:** Bruk TLS/SSL certificates for custom domains.
|
||||
|
||||
---
|
||||
|
||||
### 5. Data Exfiltration Prevention
|
||||
|
||||
**Risikoscenarier:**
|
||||
- Malicious actors med tilgang til workspace sender treningsdata til ekstern storage
|
||||
- Ukonfigurerte compute resources med åpen internett-tilgang
|
||||
|
||||
#### Mitigations
|
||||
|
||||
**1. Managed VNet med approved outbound:**
|
||||
|
||||
```azurecli
|
||||
az ml workspace update --name <workspace> \
|
||||
--managed-network allow_only_approved_outbound
|
||||
```
|
||||
|
||||
**2. Disable public network access:**
|
||||
|
||||
```azurecli
|
||||
az ml online-endpoint create --file endpoint.yml \
|
||||
--set public_network_access=disabled
|
||||
```
|
||||
|
||||
**3. Audit outbound dependencies:**
|
||||
|
||||
Dokumenter godkjente FQDNs/Service Tags:
|
||||
- `AzureActiveDirectory`
|
||||
- `AzureFrontDoor.FrontEnd`
|
||||
- `MicrosoftContainerRegistry`
|
||||
- `AzureMonitor`
|
||||
|
||||
**4. Private endpoints for all storage:**
|
||||
|
||||
Kombiner workspace private endpoint med storage private endpoints for full isolation.
|
||||
|
||||
---
|
||||
|
||||
## Arkitekturmønstre
|
||||
|
||||
### Mønster 1: Zero Trust MLOps Architecture
|
||||
|
||||
**Komponenter:**
|
||||
```
|
||||
[On-premises dev environment]
|
||||
↓ (Azure VPN Gateway / ExpressRoute)
|
||||
[Azure Virtual Network]
|
||||
↓ (Private Endpoint)
|
||||
[Workspace (private endpoint)]
|
||||
↓ (Managed Identity auth)
|
||||
[Storage (private endpoint)]
|
||||
[Key Vault (private endpoint)]
|
||||
[Container Registry (private endpoint)]
|
||||
↓ (Managed VNet compute)
|
||||
[Compute Cluster (no public IP)]
|
||||
↓ (Private endpoint)
|
||||
[Online Endpoint (public_network_access=disabled)]
|
||||
```
|
||||
|
||||
**Sikkerhetslag:**
|
||||
1. **Perimeter:** VPN/ExpressRoute (ingen direkte internett-tilgang)
|
||||
2. **Identity:** Managed identities + Entra ID MFA
|
||||
3. **Network:** Private endpoints + NSGs + Managed VNet
|
||||
4. **Data:** CMK + encryption in transit
|
||||
5. **Audit:** Azure Monitor + Log Analytics + Sentinel
|
||||
|
||||
### Mønster 2: Multi-Workspace Data Isolation
|
||||
|
||||
For organisasjoner med flere team som deler storage/keyvault/ACR:
|
||||
|
||||
**Enable data isolation:**
|
||||
|
||||
```azurecli
|
||||
az ml workspace create --name <workspace> \
|
||||
--resource-group <rg> \
|
||||
--enable-data-isolation \
|
||||
--storage-account <shared-storage-resource-id> \
|
||||
--key-vault <shared-kv-resource-id>
|
||||
```
|
||||
|
||||
**Effekter:**
|
||||
- Storage containers prefix: `{workspace-guid}-azureml-blobstore`
|
||||
- Key Vault secrets prefix: `{workspace-guid}-`
|
||||
- Container Registry images prefix: `{workspace-guid}/`
|
||||
- Workspace identity får ABAC condition som kun tillater tilgang til egne containere
|
||||
|
||||
**Default for workspace kinds:**
|
||||
|
||||
| Workspace Kind | Data Isolation Default |
|
||||
|----------------|------------------------|
|
||||
| `hub` | Enabled |
|
||||
| `project` | Enabled (arvet fra hub) |
|
||||
| `default` | Disabled |
|
||||
|
||||
### Mønster 3: User Identity Pass-through for Training Jobs
|
||||
|
||||
For fine-grained tilgangskontroll hvor ulike data scientists har ulike tilganger:
|
||||
|
||||
**Oppsett:**
|
||||
|
||||
```yaml
|
||||
# training-job.yml
|
||||
command: python train.py --input-data ${{inputs.data}}
|
||||
inputs:
|
||||
data:
|
||||
type: uri_folder
|
||||
path: azureml://datastores/secured-data/paths/team-a/
|
||||
environment: azureml://registries/azureml/environments/sklearn-1.5
|
||||
compute: azureml:secure-cluster
|
||||
identity:
|
||||
type: user_identity
|
||||
```
|
||||
|
||||
```azurecli
|
||||
az ml job create --file training-job.yml
|
||||
```
|
||||
|
||||
**Krav:**
|
||||
- Datastore må bruke identity-based authentication (ikke cached credentials)
|
||||
- User må ha `Storage Blob Data Reader` på storage account
|
||||
- Kun støttet via CLI/SDK v2 (ikke Studio)
|
||||
- Pipeline steps må konfigureres individuelt (ikke root-level)
|
||||
|
||||
**Fordeler:**
|
||||
- Audit trails viser hvilken bruker som aksesserte hvilke data
|
||||
- Reuse av eksisterende storage permissions
|
||||
- Segregation of duties mellom data scientists
|
||||
|
||||
---
|
||||
|
||||
## Beslutningsveiledning
|
||||
|
||||
### Når velge System-Assigned vs. User-Assigned Managed Identity?
|
||||
|
||||
**Velg System-Assigned når:**
|
||||
- ✅ Enkelt workspace med dedikerte ressurser
|
||||
- ✅ Prototype/dev miljøer
|
||||
- ✅ Minimal administrative overhead ønskes
|
||||
|
||||
**Velg User-Assigned når:**
|
||||
- ✅ Delte ressurser på tvers av workspaces
|
||||
- ✅ Least-privilege access per compute cluster
|
||||
- ✅ Data isolation i multi-tenant scenarios
|
||||
- ✅ Enklere key rotation / credential lifecycle management
|
||||
|
||||
### Når bruke Private Endpoints?
|
||||
|
||||
**Alltid bruk private endpoints når:**
|
||||
- ✅ Produksjonsworkloads med sensitive data
|
||||
- ✅ Compliance-krav (GDPR, NIS2, ISO 27001)
|
||||
- ✅ Cross-premises connectivity (hybrid cloud)
|
||||
- ✅ Zero-trust arkitektur implementeres
|
||||
|
||||
**Kan utelates i:**
|
||||
- ❌ Development/test workspaces uten sensitive data
|
||||
- ❌ Proof-of-concepts med syntetiske data
|
||||
|
||||
### Når bruke Customer-Managed Keys?
|
||||
|
||||
**Påkrevd for:**
|
||||
- ✅ Regulerte sektorer (bank, helse, offentlig sektor)
|
||||
- ✅ Contractual "bring your own key" krav
|
||||
- ✅ Data residency compliance (GDPR Article 44-50)
|
||||
|
||||
**Vurder kostnad/kompleksitet:**
|
||||
- ⚠️ Ekstra Azure-kostnader (Cosmos DB, AI Search)
|
||||
- ⚠️ Key rotation procedures må etableres
|
||||
- ⚠️ Disaster recovery kompleksitet øker
|
||||
|
||||
---
|
||||
|
||||
## Integrasjon med Microsoft-stakken
|
||||
|
||||
### Azure DevOps Integration
|
||||
|
||||
**Service connection med managed identity:**
|
||||
|
||||
```azurecli
|
||||
# Opprett service principal for Azure DevOps
|
||||
az ad sp create-for-rbac --name "azdo-ml-connection" \
|
||||
--role Contributor \
|
||||
--scopes /subscriptions/<sub-id>/resourceGroups/<rg>
|
||||
```
|
||||
|
||||
**Eller bruk workload identity federation (anbefalt):**
|
||||
|
||||
Azure DevOps → Project Settings → Service connections → Azure Resource Manager → Workload Identity federation
|
||||
|
||||
**Pipeline secret management:**
|
||||
|
||||
```yaml
|
||||
# azure-pipelines.yml
|
||||
variables:
|
||||
- group: ml-production-secrets # Hentet fra Key Vault
|
||||
|
||||
steps:
|
||||
- task: AzureCLI@2
|
||||
inputs:
|
||||
azureSubscription: 'ml-service-connection'
|
||||
scriptType: 'bash'
|
||||
scriptLocation: 'inlineScript'
|
||||
inlineScript: |
|
||||
az ml job create --file training-job.yml \
|
||||
--set environment_variables.STORAGE_KEY=$(storage-account-key)
|
||||
```
|
||||
|
||||
### GitHub Actions Integration
|
||||
|
||||
**OIDC authentication (ingen secrets):**
|
||||
|
||||
```yaml
|
||||
# .github/workflows/train-model.yml
|
||||
name: Train ML Model
|
||||
on: [push]
|
||||
|
||||
permissions:
|
||||
id-token: write
|
||||
contents: read
|
||||
|
||||
jobs:
|
||||
train:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: azure/login@v1
|
||||
with:
|
||||
client-id: ${{ secrets.AZURE_CLIENT_ID }}
|
||||
tenant-id: ${{ secrets.AZURE_TENANT_ID }}
|
||||
subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
|
||||
|
||||
- name: Submit training job
|
||||
run: |
|
||||
az ml job create --file job.yml \
|
||||
--workspace-name ${{ vars.WORKSPACE_NAME }}
|
||||
```
|
||||
|
||||
### Azure Monitor & Sentinel Integration
|
||||
|
||||
**Enable diagnostic logs:**
|
||||
|
||||
```azurecli
|
||||
az monitor diagnostic-settings create \
|
||||
--name workspace-diagnostics \
|
||||
--resource /subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.MachineLearningServices/workspaces/<workspace> \
|
||||
--logs '[{"category":"AmlComputeClusterEvent","enabled":true}]' \
|
||||
--workspace /subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.OperationalInsights/workspaces/<log-analytics>
|
||||
```
|
||||
|
||||
**Sentinel KQL query for anomaly detection:**
|
||||
|
||||
```kql
|
||||
AmlComputeClusterNodeEvent
|
||||
| where TimeGenerated > ago(24h)
|
||||
| where EventType == "NodeStateChange"
|
||||
| summarize NodeChanges = count() by NodeId, bin(TimeGenerated, 1h)
|
||||
| where NodeChanges > 10 // Anomali: Mer enn 10 state changes per time
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Offentlig sektor (Norge)
|
||||
|
||||
### Compliance-krav
|
||||
|
||||
**Krav fra Digitaliseringsdirektoratet:**
|
||||
|
||||
1. **Logging og sporbarhet (Referansekatalogen for IT-standarder):**
|
||||
- Bruk Azure Monitor med minimum 90 dagers retention
|
||||
- Integrer med Sentinel for security event monitoring
|
||||
- Implementer audit trails for alle data access operations
|
||||
|
||||
2. **Tilgangskontroll (NSM Grunnprinsipper for IKT-sikkerhet):**
|
||||
- Multifaktor autentisering for alle brukerkontoer (Entra ID MFA)
|
||||
- Principle of least privilege (RBAC custom roles)
|
||||
- Regular access reviews (Entra ID Access Reviews)
|
||||
|
||||
3. **Datakryptering:**
|
||||
- TLS 1.2/1.3 for data in transit
|
||||
- Customer-managed keys for data at rest (anbefalt for "Begrenset" og høyere)
|
||||
- Key rotation procedures (minimum årlig)
|
||||
|
||||
### Skytjenesteleverandør-vurdering (Difis krav)
|
||||
|
||||
**Azure Machine Learning oppfyller:**
|
||||
- ✅ Databehandleravtale (DPA) med Microsoft
|
||||
- ✅ ISO 27001, ISO 27018, SOC 2 Type II sertifiseringer
|
||||
- ✅ GDPR compliance (EU data residency)
|
||||
- ✅ Norway region availability (Oslo/Norway East)
|
||||
|
||||
**Ekstra tiltak for "Begrenset" klassifiserte data:**
|
||||
- Bruk customer-managed keys
|
||||
- Enable data isolation for multi-tenant scenarios
|
||||
- Implementer private endpoints + Managed VNet
|
||||
- Document data flows i ROS-analyse
|
||||
|
||||
---
|
||||
|
||||
## Kostnad og lisensiering
|
||||
|
||||
### Kostnadsdrivere for Security Features
|
||||
|
||||
| Feature | Ekstra kostnad | Estimat (NOK/måned) |
|
||||
|---------|----------------|---------------------|
|
||||
| Private Endpoint | Per endpoint | ~50 kr/endpoint + inbound/outbound data |
|
||||
| VPN Gateway (S2S) | Gateway + bandwidth | ~1500-5000 kr (avhengig av SKU) |
|
||||
| Customer-Managed Keys | Cosmos DB, AI Search | +30-50% av workspace cost |
|
||||
| Managed VNet | Inkludert | 0 kr (ingen ekstra kostnad) |
|
||||
| Azure Monitor logs | Per GB ingested | ~25 kr/GB (etter 5 GB free tier) |
|
||||
|
||||
### Lisensiering
|
||||
|
||||
**Ingen spesielle lisenser påkrevd for security features:**
|
||||
- Managed identities: Inkludert i Azure-abonnement
|
||||
- RBAC: Inkludert i Azure-abonnement
|
||||
- Private Link: Påløper kun infrastructure costs
|
||||
- Customer-managed keys: Krever Azure Key Vault (standard/premium)
|
||||
|
||||
**Microsoft Entra ID P2 (anbefalt for enterprise):**
|
||||
- Privileged Identity Management (PIM)
|
||||
- Conditional Access policies
|
||||
- Access Reviews
|
||||
- Identity Protection
|
||||
|
||||
---
|
||||
|
||||
## For arkitekten (Cosmo)
|
||||
|
||||
### Anbefalte decision points i arkitekturgesprekker
|
||||
|
||||
**1. Identity strategy:**
|
||||
- "Har dere delte storage accounts eller dedikerte per team?"
|
||||
- Delt → Bruk UAI + data isolation
|
||||
- Dedikert → SAI er tilstrekkelig
|
||||
|
||||
**2. Network isolation level:**
|
||||
- "Hvilken klassifisering har dataene?" (Åpen/Intern/Begrenset/Fortrolig)
|
||||
- Begrenset+ → Private endpoints obligatorisk
|
||||
- Intern → Vurder managed VNet med approved outbound
|
||||
|
||||
**3. Compliance requirements:**
|
||||
- "Har dere DPA med 3rd-party data processors?"
|
||||
- Ja → Implementer CMK for "data processor independence"
|
||||
- Nei → Vurder kostnad/kompleksitet trade-off
|
||||
|
||||
**4. User vs. compute identity for data access:**
|
||||
- "Trenger dere audit trails per data scientist?"
|
||||
- Ja → User identity pass-through
|
||||
- Nei → Compute managed identity (enklere)
|
||||
|
||||
### Red flags og mitigations
|
||||
|
||||
**🚨 Red flag:** "Vi har deaktivert firewall på storage account for å unngå connectivity issues"
|
||||
- **Risk:** Data exfiltration, unauthorized access
|
||||
- **Mitigation:** Implementer trusted service exception + private endpoints
|
||||
|
||||
**🚨 Red flag:** "Vi bruker storage account keys i environment variables"
|
||||
- **Risk:** Credentials leakage i logs/telemetri
|
||||
- **Mitigation:** Bytt til identity-based data access (no cached credentials)
|
||||
|
||||
**🚨 Red flag:** "Compute clusters har public IP for SSH-tilgang"
|
||||
- **Risk:** Brute force attacks, lateral movement
|
||||
- **Mitigation:** Disable public IP (`enableNodePublicIp=false`) + use Azure Bastion for mgmt
|
||||
|
||||
**🚨 Red flag:** "Vi har én workspace for både dev og prod"
|
||||
- **Risk:** Privilege escalation, accidental production changes
|
||||
- **Mitigation:** Separate workspaces med ulike RBAC policies + subscription boundaries
|
||||
|
||||
### Typical architectures — security maturity levels
|
||||
|
||||
**Level 1 — Prototype (minimal security):**
|
||||
- System-assigned managed identities
|
||||
- Public endpoints
|
||||
- Platform-managed keys
|
||||
- Default RBAC roles
|
||||
- **Use case:** PoC, hackathons, training environments
|
||||
|
||||
**Level 2 — Development (basic security):**
|
||||
- User-assigned managed identities
|
||||
- Managed VNet (allow internet outbound)
|
||||
- Platform-managed keys
|
||||
- Custom RBAC roles
|
||||
- Diagnostic logs → Log Analytics
|
||||
- **Use case:** Development teams, non-sensitive data
|
||||
|
||||
**Level 3 — Production (enterprise security):**
|
||||
- User-assigned managed identities + data isolation
|
||||
- Private endpoints + Managed VNet (approved outbound only)
|
||||
- Customer-managed keys
|
||||
- Conditional access policies
|
||||
- Azure Monitor + Sentinel integration
|
||||
- Regular access reviews
|
||||
- **Use case:** Regulated industries, sensitive data, compliance requirements
|
||||
|
||||
---
|
||||
|
||||
## Kilder og verifisering
|
||||
|
||||
**MCP Calls:** 8 (microsoft-learn docs search + fetch, code samples)
|
||||
**Primærkilder:**
|
||||
|
||||
1. [Enterprise security and governance for Azure Machine Learning](https://learn.microsoft.com/en-us/azure/machine-learning/concept-enterprise-security?view=azureml-api-2)
|
||||
2. [Set up authentication between Azure Machine Learning and other services](https://learn.microsoft.com/en-us/azure/machine-learning/how-to-identity-based-service-authentication?view=azureml-api-2)
|
||||
3. [Manage access to Azure Machine Learning workspaces](https://learn.microsoft.com/en-us/azure/machine-learning/how-to-assign-roles?view=azureml-api-2)
|
||||
4. [Azure security baseline for Machine Learning Service](https://learn.microsoft.com/en-us/security/benchmark/azure/baselines/machine-learning-service-security-baseline)
|
||||
5. [Customer-managed keys for Azure Machine Learning](https://learn.microsoft.com/en-us/azure/machine-learning/concept-customer-managed-keys?view=azureml-api-2)
|
||||
6. [Configure a private endpoint for an Azure Machine Learning workspace](https://learn.microsoft.com/en-us/azure/machine-learning/how-to-configure-private-link?view=azureml-api-2)
|
||||
7. [Secure an Azure Machine Learning workspace with virtual networks](https://learn.microsoft.com/en-us/azure/machine-learning/how-to-secure-workspace-vnet?view=azureml-api-2)
|
||||
8. [Data encryption with Azure Machine Learning](https://learn.microsoft.com/en-us/azure/machine-learning/concept-data-encryption?view=azureml-api-2)
|
||||
|
||||
**Sist verifisert:** 2026-02-04
|
||||
**Neste review:** Q2 2026 (ved nye identity/network features i Azure ML)
|
||||
|
||||
---
|
||||
|
||||
**Confidence markers i dette dokumentet:**
|
||||
- ✅ HIGH confidence: Offisiell dokumentasjon + kodeeksempler fra Microsoft Learn
|
||||
- ⚠️ MEDIUM confidence: Utledet fra best practices og architecture patterns
|
||||
- ❓ LOW confidence: Ikke aktuelt (alle påstander er verifisert mot offisiell dokumentasjon)
|
||||
Loading…
Add table
Add a link
Reference in a new issue