AI

Azure OpenAIのセキュリティ設計:社内審査で問われる遮断・認証・フィルタの設定

Azure OpenAIのリソースを作った直後は、インターネット上のどのネットワークからでも接続を受け付ける状態です。2026年8月16日時点のMicrosoft Learnにも、Foundry Toolsリソースは既定で任意のネットワーク上のクライアントからの接続を受け入れると明記されています。社内審査で「閉じた環境で使っている」と説明するなら、既定値のどこが開いているかを先に把握してください。

本記事では、ネットワーク・認証・コンテンツフィルタ・監査の四層について、既定の保護と自分で構成する保護を切り分け、設定の順序と反映までの時間差を実装者が再現できる粒度で整理します。プライベートエンドポイントまで踏み込む条件と、要らない場面の線引きも示しました。

まとめ:既定のままでは開いたままになる三つの層と、閉じていく順序

先に結論を置きます。以降は、この六点の根拠と手順です。

  • 通信と保存時の暗号化は既定から有効です。自分で閉じるのはネットワーク・認証・ログの三層に絞られます。
  • ネットワーク規則は、既定アクションをDenyに変えて初めて効きます。規則を足しただけでは何も遮断されません。
  • Entra ID認証は既定から使えますが、APIキーも同時に生きています。止めるにはdisableLocalAuthを明示的に立てます。
  • キー認証の無効化は、ゲートウェイのキャッシュが更新されるまで従来のキーが通り続けます。通常は数分、最大で数時間です。
  • コンテンツフィルタは四つの危害カテゴリに重大度「中」で既定から動いています。厳しくするのは自由、弱めるには承認が要ります。
  • リソースログは既定では出力されません。監査証跡が要るなら、送信先の指定が最初の作業です。

順序を守らないと、設定したつもりで開いたままの箇所が残ります。ネットワークは「既定を拒否に倒す」が先、「経路を足す」が後。この順番だけは崩さないでください。

前提の切り分け:既定で守られる範囲と、自分で閉じる設定の境界

Microsoftが担う範囲と利用者が担う範囲を先に分けます。セキュリティベースラインは各機能に「既定で有効」と「設定の責任」の欄を持つため、作業対象がここで絞れます。

既定で有効な保護と既定で無効な保護を分けて把握するための一覧

ベースラインの記載を責任の所在で並べ替えました。設定作業が要るのは「Customer」の行だけです。

機能 既定で有効 設定の責任
転送中データの暗号化 有効 Microsoft
保存時の暗号化(プラットフォームキー) 有効 Microsoft
データプレーンのEntra ID認証 有効 Microsoft
仮想ネットワーク統合 無効 Customer
Azure Private Link 無効 Customer
パブリックネットワークアクセスの無効化 無効 Customer
マネージドID認証 無効 Customer
カスタマーマネージドキー暗号化 無効 Customer
リソースログ 無効 Customer

審査資料では上三行を「既定で担保されている項目」として引用し、残りを自社の設定証跡として示すと説明が短く済みます。ただしこの文書は旧版のベンチマークv1.0に基づき、古い記述を含む可能性があるという注記が付いています。個別の設定手順は製品ドキュメント側を正として確認してください。

カスタムサブドメインが認証とプライベート接続の前提になる理由

リソース作成時に決めるカスタムサブドメイン(リソース名.openai.azure.com)は、見た目の話ではありません。Entra ID認証にはこれが必須で、無いリソースはトークンを受け付けず401を返します。プライベートエンドポイント経由でも、クライアントはこれをベースURLに指定する決まりです。リージョン共通のエンドポイントで作ると、後からキーレス認証にも私設接続にも移行できません。全体像はAzure OpenAI Serviceとは?できること・料金・導入事例を解説で確認してください。

学習利用とログ保持の論点で本記事が扱わない範囲と、その参照先

社内審査でまず問われるのは「入力したデータが学習に使われないか」でしょう。プロンプトや補完が基盤モデルの学習に使われないことは既定の扱いとして明記されており、申請の有無とは関係しません。申請で止められるのは、不正使用の検出のため保存され人手で確認される経路のほうです。この区別と申請手順はAzure OpenAIのオプトアウト申請:不正使用監視のログ保持を止める条件と手順で扱うため、本記事では立ち入りません。

ネットワーク層:既定のDenyを先に立てないと規則が効かない構成順序

Foundry Toolsは階層型のネットワークセキュリティモデルを持ちます。手順を誤ると、規則を並べたのに素通りする状態になります。

既定アクションをDenyへ変える手順と、変更前に確認しておく事項

既定の規則を拒否にしないとネットワーク規則が効力を発揮しない、という注意はIP規則の章と仮想ネットワーク規則の章の両方に繰り返し書かれています。作業順序は次のとおり。

  1. 許可すべき送信元(オンプレミスのNAT外向きIP、Azure側のサブネット)を洗い出す。ExpressRouteのMicrosoftピアリング経由なら、NATのIPを管理者に確認する。
  2. 許可規則を先に登録する。
  3. 最後に既定アクションをDenyへ切り替える。ポータルなら「選択したネットワークとプライベートエンドポイント」、CLIならnetworkAclsdefaultActionを指定する。
  4. 登録済みの送信元から推論を呼び、疎通を確認する。

切り替え後は、他のAzureサービス・Azureポータル・ログおよびメトリックサービスからの要求もブロック対象に含まれます。Azure Machine LearningやAzureの検索サービスから接続するなら、networkAclsbypassAzureServicesにして信頼されたサービスの例外を開けてください。構成操作は引き続き可能なので、締め出される心配はありません。

IP規則と仮想ネットワーク規則の上限件数・書式・除外される範囲

規則には制約があります。設計前に把握すると後戻りが減ります。

  • IP規則・仮想ネットワーク規則ともに1リソース最大100件で、両者は併用できます。
  • IPv4のみの対応です。
  • プレフィックス長31や32は受け付けられません。単一ホストは個別のIP規則として登録します。
  • IP規則にはパブリックIPしか登録できません。10.172.16.から172.31.192.168.で始まるプライベートアドレス空間は対象外です。

社内からの接続をプライベートIPで許可しようとして弾かれる例が起きがちですが、これは仕様どおりの挙動です。通すなら、サービスエンドポイント(Microsoft.CognitiveServices)を有効にしたサブネット単位の仮想ネットワーク規則か、プライベートエンドポイントを使ってください。

プライベートエンドポイント構成でDNSとベースURLを扱う際の注意

プライベートエンドポイントを作ると、リソースのDNS CNAMEレコードがprivatelinkプレフィックスのサブドメインへ更新され、プライベートDNSゾーンとAレコードがAzure側で自動作成されます。仮想ネットワークの内側から名前解決すればプライベートIPに、外側からならパブリックエンドポイントに解決される仕組みです。

ドキュメントには警告として、要求にはカスタムサブドメインをベースURLに指定し、内部のCNAME解決の途中に現れるprivatelink.openai.azure.comを直接呼ばないことが明記されています。Azure OpenAIは他のFoundry Toolsとは異なるプライベートDNSゾーンとフォワーダーを使う点にも注意が要ります。オンプレミスのDNSサーバーなら、privatelinkサブドメインを仮想ネットワークのプライベートDNSゾーンへ委任してください。

認証層:キーからEntra IDへ寄せるロール設計と反映待ちの扱い

ネットワークを閉じても、キーが漏れれば許可された経路の内側から呼ばれます。ベースラインにも、ローカル認証は可能な限り無効にするようあります。

推論で使うロールと管理操作で使うロールを分けて割り当てる基準

推論API(データプレーン)を呼ぶには「Cognitive Services OpenAI ユーザー」または「Cognitive Services OpenAI 共同作成者」を割り当てます。モデル一覧の取得のような管理操作(コントロールプレーン)は別のAPIで、「Cognitive Services 共同作成者」のような管理権限のロールが必要です。推論用のロールでコントロールプレーンへは入れない、と明記されています。

トークンの対象ユーザーも異なり、データプレーンはai.azure.com、コントロールプレーンはmanagement.azure.comを対象に発行されます。片方向けのトークンはもう片方では通りません。アプリの実行IDには推論用ロールだけを与える分け方が現実的です。割り当てが有効になるまで最大5分かかるため、直後の403はもう一度試してから原因を追ってください。

マネージドIDの三種類とサービスプリンシパルを選び分ける条件

認証に使うIDは、コードの実行場所で決まります。

ID 使う場所 管理するシークレット
開発者アカウント サインイン後のローカル環境 なし
システム割り当てマネージドID 単一のAzureリソース なし
ユーザー割り当てマネージドID 複数リソースで同一IDを共有 なし
サービスプリンシパル CI/CDパイプライン・Azure外のホスト クライアントシークレットまたは証明書

一つのリソースからのアクセスならシステム割り当て、複数リソースで同じ権限を共有するならユーザー割り当てを選びます。コードはDefaultAzureCredentialで共通化でき、ローカルではCLIのセッション、Azure上ではマネージドIDが自動的に選ばれます。複数のIDが割り当たっているときは、環境変数AZURE_CLIENT_IDで曖昧さを消してください。シークレットのローテーションが要るのはサービスプリンシパルだけなので、Azure内で完結する構成では外れます。

キー認証を無効化する二つの方法と、反映が遅れるまでの想定時間

キー認証を止める手段は主に二つ。Azure Policy「Foundry Toolsリソースでキーアクセスを無効にする必要がある」をサブスクリプションまたはリソースグループ単位で適用する方法と、リソース個別にdisableLocalAuthtrueにする方法です。後者はBicep・ARMテンプレート・Terraformのプロパティとして書けるほか、PowerShellならSet-AzCognitiveServicesAccount-DisableLocalAuthを付けて切り替えます。

ここに実務上の落とし穴があります。無効化はコントロールプレーンには即座に反映される一方、共有ゲートウェイはキャッシュが更新されるまで従来のキーを受け付け続けるのです。伝播は通常数分以内に完了するものの、リージョン・負荷・キャッシュの状態によっては最大で数時間かかりうる、とドキュメントに書かれています。緊急対応で即時に遮断されることを前提にしてはならない、という注意まで明記された点は押さえてください。効いたかどうかは、古いキーで要求を送り401が返ることで確認します。

フィルタ層:既定のしきい値と、変更に承認が要る範囲の切り分け

コンテンツフィルタは既定から動いています。設計の論点は「入れるかどうか」ではなく「既定の挙動をどう調整するか」です。

四つの危害カテゴリと重大度の四段階が示す既定の遮断範囲と挙動

フィルタリングシステムは、暴力・憎悪・性的・自傷行為の四カテゴリを、安全・低・中・高の四段階の重大度で検出します。既定の構成はプロンプトと入力候補の両方について、四カテゴリすべてでしきい値「中」。中または高と判定された内容は遮断され、低は通ります。安全と判定された内容は注釈にラベルが付くだけで、遮断の対象にもならず構成もできません。

低・中・高すべてを遮断する厳しい構成は、承認なしに誰でも設定できます。フィルタ構成はリソースレベルで作り、デプロイに関連付ける形です。用途の異なるアプリを同居させるなら、デプロイを分けて別々の構成を割り当ててください。要求ヘッダーx-policy-idで呼び出し単位の上書きもできますが、画像入力では指定が効きません。

追加フィルタの既定オンとオフを取り違えたときに生じる守備の穴

四カテゴリのほかに追加のフィルタがあり、既定の状態は異なります。2026年8月16日時点は次のとおりです。

フィルタ 提供状況 既定 適用先
プロンプトシールド(直接攻撃・ジェイルブレイク) GA オン ユーザープロンプト
プロンプトシールド(間接攻撃) GA オフ ユーザープロンプト
保護された素材(コード) GA オン 補完
保護された素材(テキスト) GA オン 補完
グラウンデッドネス プレビュー オフ 補完
個人を特定できる情報(PII) プレビュー オフ 補完

穴になりやすいのは間接攻撃のプロンプトシールドです。第三者が文書内に悪意ある命令を仕込む間接プロンプトインジェクションを検出する機能で、既定はオフ。社内文書やWebページを読ませる検索拡張生成では、これを見落とすと直接攻撃だけ守って間接攻撃が素通りします。PII検出も既定オフのプレビュー機能なので、個人情報の出力抑止を前提に審査資料を書くなら明示的な有効化が要ります。フィルタを弱める変更には承認が必要で、現時点では新たに管理対象顧客になれない旨も記載されました。切る前提の設計は立てないほうが無難です。

監査層:診断ログとキー管理を社内審査の資料に載る形へ落とす設定

審査で問われるのは設定値より、後から確認できる状態かどうか。ここは既定では何も残りません。

リソースログと鍵管理で審査の証跡を残すための設定と判断の条件

リソースログは「既定で有効:False/設定の責任:Customer」の機能です。診断設定を作り、Log Analyticsワークスペースかストレージアカウントへ送るまで証跡は蓄積されません。長期保存が目的ならストレージアカウント、異常検知やクエリを回すならLog Analyticsが向いています。ファイアウォールを有効にするとログおよびメトリックサービスからの要求もブロック対象に含まれるため、閉じた後に監視が欠測していないかを必ず確認してください。

保存時の暗号化はMicrosoft管理キーで既定から有効です。カスタマーマネージドキー(CMK)は、規制上、鍵のライフサイクルを自社で握る必要がある場合だけ検討します。要求が無いのに入れても、鍵の失効やローテーションの運用負荷が増えるだけです。採用するならKey Vaultの鍵をキーIDで参照する形にし、詳細はAzure Key Vaultとは?シークレット・キー・証明書の一元管理とRBAC・Managed HSMの違いを実装者目線で解説を参照してください。Microsoft側のアクセス可能性を問われる案件では、要求ごとに承認または拒否できるカスタマーロックボックスも設計に含めます。

導入判断:プライベートエンドポイントまで踏み込む条件と過剰になる場面

判断軸は扱うデータの機微度と接続元の形です。

プライベートエンドポイントまで実装すべき条件と、IP制限で足りる場面

次の二つのどちらかに当てはまるなら、プライベートエンドポイントまで実装します。第一に、個人情報・診療情報・与信情報のように、外部に出た場合の影響が事業継続に及ぶデータをプロンプトに載せる場合。第二に、接続元がAzure上のアプリケーションで完結している場合です。後者は実装コストがほぼ増えないため、機微度が中程度でも入れる価値があります。踏み込むなら、パブリック側を閉じるところまでやり切ってください。作っただけでは口が開いたままで、既定アクションの拒否とセットにして初めて経路がAzureバックボーンに限定されます。

逆に、社内の固定グローバルIPからのみ接続し、扱うデータが公開情報や社内一般文書にとどまり、Azure側に常時稼働のアプリケーションを持たないなら過剰です。IP規則で送信元を列挙し、既定アクションを拒否に倒し、キー認証を無効化してEntra IDへ寄せるだけで攻撃面はほぼ塞がります。まずIP制限と認証で閉じ、本番設計でネットワーク分離を足す順序を推奨します。

実装の順序を誤ったときに起きる三つの失敗パターンと確認の漏れ

承認を前提としたフィルタの無効化を設計に組み込まないことは前章のとおりです。加えて、順序の誤りから起きる失敗が三つあります。規則を丁寧に並べたのに既定アクションがAllowのままで、誰でも接続できる状態のまま審査に出すケース。キー認証を無効化した直後に旧キーが通ることを確認せず「遮断済み」と報告し、後の監査で指摘されるケース。そしてネットワークを閉じた後に診断ログが届かなくなり、監視の欠測に数週間気づかないケースです。いずれも設定の有無ではなく、順序と確認の不足から起きています。

設計と実装を外部へ委託するときの分担と、受け入れ時の確認項目

社内にAzureのネットワーク設計者がいない場合、四層のうちネットワークと認証は委託し、フィルタと監査は自社で運用する分担が現実的です。フィルタのしきい値は業務ドメインの判断を含むため、外部が決め切れません。受け入れ時に確認する項目は四つ。既定アクションがDenyか、旧キーで401が返るか、診断設定の送信先が指定されログが届いているか、間接攻撃のプロンプトシールドが意図どおりか。これをCLIの出力で受け取ると再確認が楽になります。委託先は、AIセキュリティ対策のようにモデル利用側の脆弱性まで見る体制を持つところを選ぶと、ネットワークとアプリケーションの境界で漏れが出にくくなります。

Azure OpenAIのセキュリティ設定に関するよくある質問と実務回答

社内審査で繰り返し出る質問を、一次情報に沿って整理します。

Azure OpenAIに入力したデータは学習に使われますか?

使われません。プロンプト・補完・埋め込み・トレーニングデータが基盤モデルの学習に使われないことは既定の扱いとして明記されており、オプトアウト申請の有無とは関係しません。混同されやすいのは、不正使用の検出のためプロンプトと補完が保存され、人手で確認される経路の存在です。審査資料では両者を別項目として書き分けてください。

プライベートエンドポイントを作れば、ファイアウォールの設定は不要ですか?

不要にはなりません。プライベートエンドポイントは仮想ネットワークからの経路を追加するもので、パブリック側を閉じる機能ではないからです。ドキュメントでも、パブリック側のすべての接続をブロックするようファイアウォールを構成することが利用時の効果として挙げられています。既定アクションをDenyにして初めて、経路がプライベートリンクに限定されます。

APIキーを無効にすると、既存のアプリはすぐ動かなくなりますか?

すぐには止まりません。変更はコントロールプレーンには即座に反映される一方、共有ゲートウェイのキャッシュが更新されるまで従来のキーが受け付けられ続けます。通常は数分以内、リージョンや負荷、キャッシュの状態によっては最大で数時間かかる場合があるとドキュメントに書かれています。旧キーでの要求が401を返すことを実測し、切り替え完了と判断してください。

コンテンツフィルターを完全にオフにできますか?

承認された利用者に限られます。しきい値を低・中・高の範囲で調整することは誰でもできる一方、部分的または完全に無効化する変更と注釈のみの構成には限定アクセスレビューによる承認が要ります。2026年8月16日時点のドキュメントには、現時点では新たに管理対象顧客になれないと記載されました。しきい値の調整とプロンプト設計で対応する方針に切り替えてください。

ネットワークを制限したあとにAzureポータルから操作できなくなりました。原因は何ですか?

ファイアウォール規則の仕様どおりの挙動です。規則を有効にすると既定で受信要求がブロックされ、対象には他のAzureサービス・Azureポータル・ログおよびメトリックサービスからの要求が含まれます。プレイグラウンドなどを仮想ネットワークから使う場合は、CognitiveServicesManagementだけでなくAzureActiveDirectoryAzureFrontDoor.FrontendAzureResourceManagerCognitiveServicesFrontEndのサービスタグを許可してください。

関連記事

資料請求

RELATED POSTS 関連記事