Deploya Azure OpenAI med CMK med Terraform

Varför kundhanterande nycklar är viktiga för Azure OpenAI

När du driftsätter Azure OpenAI Service i företagsmiljöer är kryptering i vila aktiverat som standard med Microsoft-hanterade nycklar. Dock behöver många organisationer som verkar under strikta efterlevnadsramverk — som GDPR, finansiella regelverk som PCI DSS eller krav på datasuveränitet — full kontroll över sina krypteringsnycklar.

Kundhanterande nycklar (CMK) ger dig den kontrollen. Med CMK lagras dina krypteringsnycklar i ditt eget Azure Key Vault, vilket innebär att du kan rotera, återkalla och granska nyckelåtkomst självständigt. Om en säkerhetsincident kräver omedelbar återkallning av dataåtkomst kan du inaktivera nyckeln och i praktiken göra datan oåtkomlig — något som inte är möjligt med plattformshanterade nycklar.

För organisationer som hanterar känsliga data genom Azure OpenAI — oavsett om det är kundkommunikation, finansiella dokument eller vårdhandlingar — är CMK inte valfritt. Det är ett efterlevnadskrav.

Vad är Azure Verified Modules?

Azure Verified Modules (AVM) är Microsofts officiella, förbyggda Terraform- och Bicep-moduler publicerade till de publika registren. Till skillnad från community-moduler är AVM-moduler:

Testade — Varje modul genomgår automatiserad testning inklusive enhetstester, integrationstester och end-to-end-valideringsdeployment
Underhållna — Microsofts team underhåller och uppdaterar aktivt modulerna för att anpassa sig till Azure API-ändringar
Konsekventa — Alla moduler följer samma gränssnittsmönster, namnkonventioner och bästa praxis
Stödda — Backed av Microsoft med GitHub-ärenden och regelbundna releasecykler

Att använda AVM-moduler minskar avsevärt mängden boilerplate Terraform-kod du behöver skriva och säkerställer att dina deployments följer Microsofts rekommenderade mönster.

Komplett Terraform-deployment

Följande Terraform-konfiguration driftsätter en Azure OpenAI Service med CMK-kryptering genom att använda Azure Verified Modules för både Key Vault och Cognitive Services-kontot:

Köra deploymentet

När du har Terraform-konfigurationen på plats, initiera och deploya:

Centrala designbeslut förklarade

Rensningsskydd krävs för CMK. Azure kräver detta — om ditt Key Vault har rensningsskydd inaktiverat kan du inte använda dess nycklar för CMK-kryptering. Den 90-dagars mjuka raderingsperioden säkerställer att även oavsiktlig nyckelradering inte omedelbart gör din OpenAI-data permanent oåtkomlig. Detta är ett hårt krav från Azure, inte ett förslag på bästa praxis.

Systemtilldelad hanterad identitet framför användartilldelad. En systemtilldelad hanterad identitet knyter identitetens livscykel direkt till OpenAI-resursen. När resursen raderas rensas identiteten automatiskt upp, vilket minskar spridningen av övergivna identiteter. För CMK-scenarier är detta det enklare och säkrare tillvägagångssättet — du behöver inte hantera en separat identitetsresurs.

Nätverks-ACL:er är som standard Neka. Konfigurationen börjar med en neka-allt-nätverkshållning och tillåter bara specifika IP-adresser. I produktion skulle du ersätta IP-regeln med privata slutpunkter för fullständig nätverksisolering. Att börja restriktivt och öppna efter behov är alltid säkrare än det omvända.

Azure Verified Modules minskar risken. Istället för att skriva råa azurerm-resurser med all CMK-koppling manuellt kapslar AVM-modulerna in korrekta resursrelationer, rolltilldelningar och konfigurationsmönster. Detta innebär färre möjligheter till felkonfiguration och en deployment som överensstämmer med Microsofts testade mönster.

Vidare läsning

För mer detaljer, se Azure OpenAI-dokumentation om hanterade identiteter och Azure Verified Modules-registret.