Azure の「Azure security baseline for Azure OpenAI」は、Azure OpenAI を Microsoft cloud security benchmark に沿って安全に運用するための実装チェックリストです。結論から言うと、今回確認すべき中心は「新機能を使うかどうか」ではなく、公開ネットワークアクセス、Microsoft Entra ID 認証、Azure RBAC、マネージド ID、Key Vault、DLP、ログ、Azure Policy が本番環境で実装済みかを点検することです。
既存の Azure OpenAI リソースが直ちに停止するような変更ではありません。一方で、生成 AI を業務利用している組織では、プロンプト、回答、埋め込み、アップロードデータ、ファインチューニング用データなどを扱うため、通常の PaaS よりも「誰が、どこから、どのデータに、どの権限でアクセスできるか」を明確にしておく必要があります。Microsoft Learn の対象ページは Microsoft cloud security benchmark v1.0 を Azure OpenAI に適用する内容で、Defender for Cloud や Azure Policy による監視にもつなげられます。なお、対象ページの表示上の最終更新日は 2026年3月2日であり、2026年6月24日時点で社内展開する場合も、最新の Azure OpenAI 関連ドキュメントと合わせて確認するのが安全です。(Microsoft Learn)
Azure の新機能・変更点：「Azure security baseline for Azure OpenAI」でまず確認すべきポイント
Azure security baseline for Azure OpenAI は、Azure OpenAI のセキュリティ設定を「ネットワーク」「ID」「特権アクセス」「データ保護」「資産管理」「ログと脅威検出」といった観点で整理した公式ベースラインです。Microsoft cloud security benchmark の推奨事項を Azure OpenAI に当てはめ、実装すべき設定や運用上の確認ポイントを示しています。(Microsoft Learn)
特に重要なのは、Azure OpenAI のセキュリティプロファイルです。公式ベースラインでは、Azure OpenAI は AI+ML カテゴリのサービスであり、顧客はホスト OS にアクセスできず、顧客の仮想ネットワークにデプロイ可能で、保存時に顧客コンテンツを保持するサービスとして整理されています。つまり、OS 管理よりも、ネットワーク境界、ID、データ保護、ログ設計 が管理者側の主要な責任になります。(Microsoft Learn)
| 確認領域 | 公式ベースラインでの主な観点 | 管理者が取るべき初動 |
|---|---|---|
| ネットワーク | VNet 統合、Private Link、パブリックアクセス無効化 | 公開エンドポイントを許容していないか確認し、Private Endpoint と DNS を点検する |
| ID 管理 | Microsoft Entra ID、ローカル認証の制限、マネージド ID | キー認証に依存しているアプリを棚卸しし、RBAC とマネージド ID へ寄せる |
| 特権アクセス | Azure RBAC、Customer Lockbox | 管理者ロールとデータプレーンロールを分離し、サポートアクセス承認プロセスを確認する |
| データ保護 | 転送中暗号化、保存時暗号化、CMK、DLP | CMK が必要な範囲、送信先 URL の制限、保存データの扱いを確認する |
| 資産管理 | Azure Policy による監査・強制 | Policy の Audit、Deny、DeployIfNotExists をどこまで使うか決める |
| ログと検出 | Azure Monitor、リソースログ、診断設定 | Log Analytics、Event Hub、Storage へのログ転送を有効化する |
これは「移行」ではなく「セキュリティベースラインの再点検」と捉える
Azure security baseline for Azure OpenAI の確認で誤解しやすいのは、「すぐに移行しなければならない新バージョンが出た」と受け止めてしまうことです。公式ベースライン自体は、Azure OpenAI の API やモデルを置き換える移行手順ではありません。既存リソースに対して、Microsoft cloud security benchmark に沿った設定ができているかを確認するためのガイドです。
ただし、組織が Microsoft Defender for Cloud の規制コンプライアンス画面や Azure Policy を使っている場合、設定不備がセキュリティ推奨事項やコンプライアンス逸脱として見える可能性があります。特にグローバル企業、金融、医療、公共、製造業の研究開発部門などでは、監査証跡として「いつ、どの Azure OpenAI リソースを確認し、どの例外を承認したか」を残すことが重要です。
また、Microsoft cloud security benchmark v2 はプレビューとして提供されており、AI Security ドメインや 420 を超える Azure Policy 組み込み定義など、より新しい方向性が示されています。ただし、Azure OpenAI の当該セキュリティベースラインは v1.0 ベースであるため、実務では「現行ベースラインで設定を固める」「MCSB v2 の AI セキュリティ観点を今後の改善テーマとして取り込む」という二段構えが現実的です。(Microsoft Learn)
影響範囲：Azure OpenAI を本番利用するほぼすべての環境が対象
影響を受けるのは、Azure OpenAI リソースそのものだけではありません。Azure OpenAI に接続するアプリケーション、API Gateway、Azure Functions、App Service、AKS、仮想ネットワーク、Key Vault、Log Analytics、SIEM、CI/CD、運用チームの権限設計まで含めて確認が必要です。
| 対象 | 影響する理由 | 確認すべき具体例 |
|---|---|---|
| Azure OpenAI リソース | ネットワーク、認証、暗号化、ログの中心になる | パブリックアクセス、Private Endpoint、診断設定、CMK |
| 業務アプリケーション | API キーや接続先 URL を保持している可能性がある | キー直書き、環境変数、マネージド ID 対応状況 |
| 開発・検証環境 | 本番より緩い設定が残りやすい | IP 許可リスト、共有キー、過剰な Contributor 権限 |
| ネットワーク基盤 | Private Link や DNS 設定が接続可否を左右する | privatelink DNS、VPN、Bastion、Hub-Spoke 構成 |
| セキュリティ運用 | 検出・監査・証跡が必要になる | Defender for Cloud、Azure Policy、Log Analytics、Sentinel 連携 |
| グローバル利用部門 | データ処理場所やデータゾーンの確認が必要 | Global、DataZone、リージョン、データレジデンシー |
特にグローバル向けの Azure OpenAI 利用では、デプロイ種別の確認が重要です。Microsoft のデータ、プライバシー、セキュリティ文書では、Global デプロイでは関連モデルが展開されている任意の geography でプロンプトや応答が処理され得ること、DataZone デプロイでは指定されたデータゾーン内で処理され得ることが説明されています。一方、保存データは顧客が指定した geography に保存されるとされています。データ所在地の要件が厳しい組織では、モデルの性能や可用性だけでなく、処理場所の条件も設計レビューに含めるべきです。(Microsoft Learn)
ネットワーク設定：最初に見るべきは「公開されているか」
Azure security baseline for Azure OpenAI で最も優先度が高い確認項目はネットワークです。公式ベースラインでは、VNet 統合、Azure Private Link、パブリックネットワークアクセスの無効化が取り上げられています。ネットワーク規則を有効にすると、許可された仮想ネットワークサブネットや IP アドレス以外からの受信要求をブロックでき、まず既定で拒否し、必要なネットワークだけを許可する考え方が示されています。(Microsoft Learn)
実務では、次の状態を目標にします。
| 環境 | 推奨される考え方 | 注意点 |
|---|---|---|
| 本番環境 | Private Endpoint を使い、パブリックネットワークアクセスを無効化 | DNS が private endpoint を向いているか必ず確認する |
| 社内検証環境 | 必要に応じて限定 IP または VNet で制限 | 一時的な許可設定を放置しない |
| 開発者のローカル PC | VPN、Bastion、踏み台 VM 経由で接続 | 個人の固定 IP 許可を恒久設定にしない |
| 外部委託先 | 専用ネットワーク、期限付き権限、監査ログを組み合わせる | 共有 API キーでの運用を避ける |
Private Endpoint を作成しただけでは不十分です。Azure OpenAI リソース側でパブリックネットワークアクセスが有効なままだと、意図しない公開経路が残る可能性があります。Microsoft のネットワーク構成手順でも、Private Endpoint を排他的なアクセス経路にするため、Networking の Allow access from を Disabled にする手順が示されています。(Microsoft Learn)
ネットワーク確認で失敗しやすいポイント
よくある失敗は、Private Endpoint を作成したあとに DNS 確認を省略することです。アプリケーションから見た名前解決が公開 IP を返している場合、Private Link を構成したつもりでも、実際の通信が想定どおりになっていない可能性があります。
確認時は、接続元の VM や開発端末から nslookup で Azure OpenAI のエンドポイントを引き、さらに Test-NetConnection などで 443 番ポートの疎通を確認します。Microsoft の手順でも、名前解決と private IP への疎通確認がトラブルシューティングの基本として示されています。(Microsoft Learn)
ID 管理：API キー依存から Microsoft Entra ID と RBAC へ寄せる
Azure OpenAI は Microsoft Entra ID 認証をサポートしており、データプレーンアクセスにも利用できます。公式ベースラインでは、ローカル認証方法の利用を可能な限り避け、Microsoft Entra ID を既定の認証方法として使うことが推奨されています。(Microsoft Learn)
特に本番環境では、API キーをアプリケーション設定やソースコード、CI/CD の変数に置く運用はリスクが高くなります。キーが漏えいすると、誰が実行したかを個人やアプリ単位で追跡しにくくなり、最小権限の設計も難しくなります。
より安全な構成は、アプリケーションにマネージド ID を割り当て、Azure OpenAI リソースに対して必要なロールだけを付与する方法です。Microsoft の手順では、Azure OpenAI の推論 API 呼び出しにキー認証ではなく Microsoft Entra ID を使うため、Cognitive Services OpenAI User または Cognitive Services OpenAI Contributor ロールを割り当てる例が示されています。また、ロール割り当ての反映に数分かかる場合がある点も運用上の注意点です。(Microsoft Learn)
| 利用パターン | 避けたい状態 | 推奨される状態 |
|---|---|---|
| App Service から Azure OpenAI を呼ぶ | API キーをアプリ設定に保存 | App Service のマネージド ID に最小権限ロールを付与 |
| AKS ワークロードから呼ぶ | Kubernetes Secret に長期キーを保存 | ワークロード ID 連携やマネージド ID を使う |
| 開発者が検証する | 共有キーをチャットやメールで配布 | 個人アカウントに期限付き RBAC を付与 |
| CI/CD から構成変更する | サービスプリンシパルに広い Contributor 権限 | 専用 ID に必要操作だけを許可 |
ただし、キーアクセスを無効化する場合は影響確認が必要です。Azure Policy の組み込み定義では、Azure AI Services のキーアクセス無効化が推奨される一方で、開発やテストで使われる Azure OpenAI Studio はキーアクセスを必要とする場合があり、無効化すると機能しない可能性があると説明されています。まず本番からキー依存を減らし、開発環境については例外期限と代替手段を決めて進めるのが安全です。(Microsoft Learn)
特権アクセス：管理者権限と利用者権限を分ける
Azure OpenAI の運用では、「Azure リソースを管理する人」と「モデルを呼び出すアプリケーションや利用者」を分けることが重要です。公式ベースラインでは、データプレーン操作に対して Azure RBAC を利用できること、ユーザー、グループ、サービスプリンシパル、マネージド ID にロールを割り当てられることが示されています。(Microsoft Learn)
実務上は、次のように分けると運用しやすくなります。
| 役割 | 付与する権限の考え方 | 避けるべき状態 |
|---|---|---|
| Azure 基盤管理者 | ネットワーク、診断設定、Policy、Private Endpoint を管理 | モデル利用権限まで無条件に持つ |
| アプリ運用者 | アプリの接続、デプロイ、監視に必要な権限 | サブスクリプション全体の Owner |
| 開発者 | 検証リソースに限定した利用権限 | 本番 Azure OpenAI への直接キーアクセス |
| セキュリティ担当 | ログ閲覧、Policy 評価、Defender for Cloud 確認 | 設定変更権限と監査権限の混在 |
| 外部委託先 | 期限付き、スコープ限定、作業単位の権限 | 共有アカウントや共有キー |
Microsoft サポートがデータへアクセスする可能性がある支援シナリオでは、Customer Lockbox を利用して、Microsoft のアクセス要求をレビューし、承認または拒否する運用もベースラインに含まれています。規制対応が必要な業界では、サポートケース発生時の承認フローも事前に決めておくべきです。(Microsoft Learn)
データ保護：暗号化は既定で有効でも、CMK と DLP は設計が必要
Azure OpenAI では、転送中のデータ暗号化と、Microsoft 管理キーによる保存時暗号化が既定で有効です。公式ベースラインでも、これらは Microsoft 側で有効化され、追加構成は不要とされています。(Microsoft Learn)
ただし、これだけで十分とは限りません。規制、顧客契約、社内ポリシーによっては、カスタマー マネージド キー、DLP、データ処理場所、ログ保持期間まで含めた設計が必要です。
CMK は「必要な場合に使う」設定
カスタマー マネージド キーは、すべての組織で必須ではありません。Microsoft 管理キーによる暗号化が既定で提供されますが、より厳格な鍵管理、鍵のローテーション、鍵の無効化、監査が必要な場合に CMK を検討します。
Azure OpenAI の保存時暗号化ドキュメントでは、CMK を使う場合、Azure Key Vault に鍵を保存すること、Azure OpenAI リソースと Key Vault が同一リージョンかつ同一 Microsoft Entra テナントであること、Key Vault の Soft Delete と Do Not Purge を有効にすることなどが説明されています。(Microsoft Learn)
| 判断ポイント | CMK を使うべきケース | Microsoft 管理キーでよいケース |
|---|---|---|
| 規制要件 | 鍵の所有、監査、ローテーションが明示要件 | 暗号化方式のみ満たせばよい |
| 顧客契約 | 顧客から BYOK や鍵管理証跡を求められる | 契約上の個別要件がない |
| 運用体制 | Key Vault、鍵更新、障害時対応を運用できる | 鍵管理の専門体制がない |
| リスク許容度 | 鍵無効化によるアクセス遮断も統制に含めたい | 可用性とシンプルな運用を優先したい |
CMK の設定で特に注意すべきなのは、鍵へのアクセスを不用意に無効化しないことです。公式ドキュメントでは、アクティブな CMK へのアクセスを取り消すと、トレーニングデータや結果ファイルのダウンロード、ファインチューニング、新しいファインチューニング済みモデルのデプロイに影響する可能性があると説明されています。(Microsoft Learn)
DLP は送信先 URL の制御として考える
Azure OpenAI の DLP は、一般的な「ファイル内の機密情報を自動分類してブロックする」機能とは少し違います。公式ベースラインでは、Azure OpenAI リソースがアクセスを許可される送信先 URL のリストを構成できることが、データ損失を防ぐ追加コントロールとして説明されています。(Microsoft Learn)
Foundry Tools の DLP ドキュメントでは、restrictOutboundNetworkAccess を true にし、許可する FQDN を allowedFqdnList に指定する流れが示されています。allowedFqdnList は最大 1000 URL、FQDN 形式をサポートし、反映まで最大 15 分かかる場合があります。(Microsoft Learn)
az rest -m patch \
-u /subscriptions/{subscription-id}/resourceGroups/{resource-group}/providers/Microsoft.CognitiveServices/accounts/{account-name}?api-version=2024-10-01 \
-b '{"properties":{"restrictOutboundNetworkAccess":true,"allowedFqdnList":["contoso.com"]}}'DLP の導入では、先に「許可すべき外部接続」を洗い出します。RAG 構成で Azure AI Search、Storage、社内 API、監査基盤などへ接続する場合、必要な FQDN を整理しないまま制限を有効化すると、業務アプリケーションが突然外部データを取得できなくなる可能性があります。
ログと脅威検出：診断設定を作らなければ調査できない
Azure OpenAI を本番利用するなら、ログ設定は後回しにできません。公式ベースラインでは、Azure OpenAI がリソースログを生成でき、顧客が Storage Account や Log Analytics Workspace などの保存先へ送信できることが示されています。(Microsoft Learn)
注意点は、Azure Monitor のメトリックやアクティビティログは自動的に収集される一方で、リソースログは診断設定を作成し、保存先へルーティングしなければ保存・検索できないことです。Microsoft の監視ドキュメントでも、Azure Monitor resource logs は診断設定を作成して送信するまで収集・保存されないと説明されています。(Microsoft Learn)
| ログ・監視項目 | 目的 | 推奨される保存先 |
|---|---|---|
| メトリック | 可用性、遅延、利用量、PTU 使用率などの監視 | Azure Monitor、Log Analytics |
| リソースログ | セキュリティ調査、操作履歴、異常分析 | Log Analytics、Event Hub、Storage |
| アクティビティログ | リソース作成、削除、設定変更の追跡 | Azure Monitor Logs、SIEM |
| Defender for Cloud 推奨事項 | セキュリティ態勢と逸脱検出 | Defender for Cloud、Azure Policy |
| アラート | 障害や異常の早期検知 | Azure Monitor Alerts、Teams、メール、ITSM |
セキュリティ運用で最低限用意したいのは、診断設定、Log Analytics ワークスペース、アラートルール、ログ保持期間、インシデント時の調査クエリです。ログを取得していても、保持期間が短すぎる、SOC が参照できない、アプリログと相関できない状態では、事故発生時に原因を追えません。
Azure Policy と Defender for Cloud：監査だけで終わらせない
Azure security baseline for Azure OpenAI は、Defender for Cloud と Azure Policy による監視と相性が良い内容です。公式ベースラインでは、Defender for Cloud の Regulatory Compliance セクションでベースラインや推奨事項を監視でき、関連する Azure Policy 定義がある場合は準拠状況の測定に使えると説明されています。(Microsoft Learn)
Azure AI Services / Foundry Tools 向けの組み込み Policy には、キーアクセス無効化、ネットワークアクセス制限、Private Link、マネージド ID、CMK、診断ログ、承認済みモデルなどに関する定義があります。これらを使えば、個別リソースを人手で確認するだけでなく、サブスクリプションや管理グループ単位で継続的に監査できます。(Microsoft Learn)
| Policy の使い方 | 向いている場面 | 注意点 |
|---|---|---|
| Audit | まず現状把握したい | 逸脱を検出するだけで自動修正はしない |
| Deny | 新規作成時に危険な設定を禁止したい | 既存運用や検証環境を止めないよう例外設計が必要 |
| DeployIfNotExists | 診断設定などを自動展開したい | 保存先ワークスペースや権限設計を先に決める |
| Modify | 設定値を自動的に変更したい | 予期しない変更を避けるため段階導入が必要 |
最初から Deny を全社適用すると、開発チームの検証や既存デプロイが止まる可能性があります。おすすめは、まず Audit で対象リソースを洗い出し、例外が必要な環境を特定し、その後に本番サブスクリプションから Deny や DeployIfNotExists を適用する流れです。
管理者が確認すべき実務チェックリスト
Azure security baseline for Azure OpenAI を社内で確認する場合は、次の順序で進めると漏れが少なくなります。
| 順番 | 作業 | 合格基準 | 失敗しやすいポイント |
|---|---|---|---|
| 1 | Azure OpenAI リソースを棚卸しする | サブスクリプション、リージョン、用途、所有者が分かる | PoC 環境や個人検証リソースが残る |
| 2 | パブリックアクセスを確認する | 本番は原則 Private Endpoint 経由 | Private Endpoint 作成だけで満足する |
| 3 | DNS と疎通を確認する | 接続元から private IP に解決される | 開発端末だけ公開経路を使っている |
| 4 | API キー利用を棚卸しする | 本番アプリは Entra ID / マネージド ID 中心 | ソースコードや CI/CD 変数にキーが残る |
| 5 | RBAC を見直す | 利用者、管理者、監査者の権限が分離されている | Contributor や Owner を広く付与する |
| 6 | Key Vault と CMK を確認する | 必要な環境だけ CMK を使い、鍵運用手順がある | 鍵削除やアクセス拒否の影響を未検証 |
| 7 | DLP の送信先を整理する | 許可 FQDN が文書化されている | 必要な外部接続をブロックして障害化する |
| 8 | 診断設定を有効化する | Log Analytics などへログが保存される | リソースログが未収集のまま運用する |
| 9 | Azure Policy を割り当てる | Audit から開始し、本番へ段階適用する | いきなり Deny を全社適用する |
| 10 | 例外管理を記録する | 期限、理由、承認者、再評価日がある | 「一時対応」が恒久化する |
変更管理で押さえるべき移行期限の考え方
Azure security baseline for Azure OpenAI の確認自体に、特定の日付までに移行しなければならないという一律の期限は示されていません。したがって、モデル廃止や API バージョン廃止のような「期限付き移行」とは分けて管理する必要があります。
ただし、期限がないから後回しでよいわけではありません。生成 AI は利用部門が増えやすく、PoC から本番化するスピードも速いため、セキュリティ設定の未整備が後から大きな手戻りになります。社内では次のような期限を設定すると現実的です。
| 期限の目安 | 対象作業 | 理由 |
|---|---|---|
| すぐ | Azure OpenAI リソースの棚卸し、所有者確認、公開アクセス確認 | 露出リスクを早期に把握するため |
| 短期 | 診断設定、Log Analytics、Defender for Cloud 確認 | 事故発生時の調査不能を防ぐため |
| 中期 | API キー依存の削減、マネージド ID 化、RBAC 整理 | アプリ改修やテストが必要になるため |
| 中長期 | CMK、DLP、Azure Policy の Deny 適用 | 業務影響や例外設計が必要なため |
グローバル企業では、リージョンやデプロイ種別、データ処理場所に関するレビューも同じ変更管理に含めるべきです。とくに Global や DataZone の利用は、性能やキャパシティの面でメリットがある一方、データ処理場所の説明責任が必要になります。(Microsoft Learn)
よくある誤解と注意点
「暗号化されているから追加対策は不要」ではない
保存時暗号化と転送中暗号化は重要ですが、セキュリティ対策の一部にすぎません。実際の事故では、過剰権限、漏えいした API キー、公開ネットワークアクセス、ログ不足が問題になることがあります。暗号化の有無だけでなく、アクセス経路と操作権限を確認する必要があります。
Private Endpoint を作れば公開アクセスは自動で消えるわけではない
Private Endpoint は安全な接続経路を作る機能です。公開アクセスを閉じる設定、DNS、接続元ネットワークの制御まで合わせて確認しなければ、意図しない通信経路が残る可能性があります。
キー認証を止めると開発ツールに影響する場合がある
キーアクセスを無効化する方針は本番セキュリティ上有効ですが、開発・検証で使うツールや既存スクリプトが動かなくなることがあります。Azure OpenAI Studio などの影響を確認し、移行期間中は例外を期限付きで管理するのが現実的です。(Microsoft Learn)
CMK は強力だが、運用ミスの影響も大きい
CMK は鍵の制御性を高めますが、Key Vault の権限、鍵のローテーション、削除、無効化、テナント移動などを誤ると、機能停止やデータアクセス不能につながります。導入前に障害時の復旧手順まで用意しておくべきです。(Microsoft Learn)
DLP は「何でも自動で守る機能」ではない
Azure OpenAI の DLP は、許可された送信先 URL を制御する仕組みとして理解するのが実務的です。プロンプト内の機密情報分類、データカタログ、利用者教育、アプリ側の入力制御とは別に設計する必要があります。
まず着手すべきアクション
Azure security baseline for Azure OpenAI を確認する管理者は、最初に全 Azure OpenAI リソースの棚卸しを行い、本番・検証・PoC を分類してください。そのうえで、本番環境から順に、パブリックネットワークアクセス、Private Endpoint、Microsoft Entra ID 認証、マネージド ID、RBAC、診断設定、DLP、Azure Policy の状態を確認します。
特に優先すべきなのは、公開アクセスの有無、API キーの利用状況、ログ取得の有無です。この 3 点は、事故が起きたときの影響と調査可能性に直結します。Azure security baseline for Azure OpenAI は、単なるドキュメント更新として読むのではなく、生成 AI 基盤を本番運用するためのセキュリティ点検表として活用するのが最も実務的です。
コメント