【Azure OpenAI × ゼロトラスト】あなたの生成AIアプリを鉄壁のセキュリティで守る実践ガイド

::: note
こちらの記事は投稿時点の情報です。
最新情報は公式ドキュメントMicrosoft Learnでご確認お願いいたします。
:::

Microsoft - Azure Developer Platform Team の D̷ELL です。[Microsoft for Startups](https://www.microsoft.com/ja-jp/startups) にて、エキスパート エンジニアとしてスタートアップ企業の方々の生成AIシステム立ち上げ支援／コンサルティングを行っています。

この記事を開いていただいた読者の方は、生成 AI アプリケーションの開発に携わる方が大半だと思います。ただ、それを支える基盤側の技術って、難しいですよね。

「どのように生成 AI アプリケーションの基盤を構築すればいいの？」という方も多いと思います。今回は、頻繁にお問い合わせをいただく「Azureにおける生成AIアプリケーションのセキュリティ ベストプラクティス」について、ゼロからご紹介したいと思います。

# TL;DR
* 生成 AI アプリケーション開発の知識はたまってきた。年末だし基盤を一気に学び直そう
* サンプルアプリ「Contoso Web App」のセキュリティ構成を商用レベルまで引き上げる
* どの Azure リソースが、どのタイミングで、なぜ必要なのか、順を追って理解する

# はじめに

Azure OpenAI Studio をご利用の方は、チュートリアルとして Azure OpenAI Web アプリを作成されたことが多いかと思います。Azure OpenAI Web アプリを使用すると、 Azure AI Studio、Azure OpenAI Studio、API、SDK に加えて、カスタマイズできるスタンドアロン Web アプリを使い、グラフィカル ユーザー インターフェイスで Azure OpenAI モデルを操作できます。 

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/419037/28be7bb2-5b20-d229-f90c-2d9a2f424515.png)

https://learn.microsoft.com/ja-jp/azure/ai-services/openai/how-to/use-web-app

この Azure OpenAI Web アプリでは、以下のように各種 Azure リソースとマネージド ID を組み合わせたトータルソリューションがサポートされています。
> * Azure AI 検索、プロンプト フローなど、豊富なクエリと検索拡張生成をサポートする複数のデータ ソースとの接続
> * Cosmos DB を使用した会話履歴とユーザー フィードバックの収集
> * Microsoft Entra ID を使用したロールベースのアクセス制御による認証
> * 環境変数を使用したユーザー インターフェイス、データ ソース、および機能のカスタマイズ (Azure portal 経由によるノー コード)
> * 基になる Web アプリケーションのソース コードをオープンソース リポジトリとして変更するためのサポート

ARM テンプレートによってデプロイされたアプリ構成を読み解くと、以下のような構成になっていることがわかります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/419037/8cef4f0f-c6f4-ead4-e6fb-2b1e0407e5fd.png)

:::note warn
こちらの構成図は GitHub リポジトリのARMテンプレートを参考に筆者が作成したものです。厳格に構成を記載しているものではないことにご留意ください。
:::

**今回は、この構成をベースにしつつ、以下のベストプラクティスに則り、 Azure 上でセキュアな LLM アプリケーションを構築する方法をご紹介します。**


https://techcommunity.microsoft.com/blog/azurearchitectureblog/security-best-practices-for-genai-applications-openai-in-azure/4027885



# Azure OpenAI Web アプリをセキュアに構成する

まず、既存の構成がどのように変遷していくか全体像を把握していただくため、以下のアーキテクチャ図をベースに見ていきたいと思います。解説は後ほど述べますので、まずはご一読くださいませ。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/419037/8cef4f0f-c6f4-ead4-e6fb-2b1e0407e5fd.png)

## Step 1. マネージド ID と Key Vault による ID セキュリティの実装 
このチュートリアルでは、環境変数に Azure OpenAI アクセスキーなどの機密情報が設定されています。これはセキュアとは言えません。そのため、以下の方法によって、サービス間の認証をセキュアに行います。

まず、今回の構成図にマネージド ID と Azure Key Vault を追加します。各サービス間の通信はできる限りマネージド ID を使用しています。もちろん、チュートリアルですでに追加されているものが大半なので、今から追加で設定する必要があるところは限られます。
一方で、DEPLOYMENT_NAME、ENDPOINT、API_VERSION などの情報は、Azure Key Vault で管理します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/419037/afdf753d-96c6-e84b-d7bd-3686cb81fd3c.png)

https://learn.microsoft.com/ja-jp/azure/ai-services/openai/how-to/managed-identity

## Step 2. 仮想ネットワークの実装

続けて、ネットワークについてみていきましょう。基本的に Azure リソース間では内部の Azure ネットワークが使用されるものの、現在の構成ではパブリックアクセスが有効になっています。これでは、ゼロトラストの観点から、セキュアなネットワーク構成とはいえません。そのため、ネットワークセキュリティを構成し、セキュアなリソース間通信を実現します。

プライベート エンドポイントや Network Security Group、 Azure Firewall を導入するために、現在の構成に対して仮想ネットワークを追加します。Web アプリが稼働している App Service には、仮想ネットワーク統合という機能の準備があるため、こちらを利用します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/419037/6f1ea53b-3ff5-f8d5-9386-ac98e307e186.png)

https://learn.microsoft.com/ja-jp/azure/app-service/overview-vnet-integration

## Step 3. ネットワークセキュリティの実装（プライベートエンドポイント）
ゼロトラストアプローチを徹底するため、データの送信・取得経路を仮想ネットワーク内に閉じるよう、プライベートサブネット、およびプライベートエンドポイントを配置します。また、プライベートエンドポイントを有効化するためにプライベート DNS ゾーンも配置しています。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/419037/17c85fa0-0e3c-1f50-b009-b5880caf00bb.png)


## Step 4. ネットワークセキュリティの実装（NSG、Firewall Rule）
先ほど構成したプライベート エンドポイントにより、サービスは仮想ネットワーク内でのみアクセス可能になりました。これを厳格なファイアウォールルールで補完して、インバウンドトラフィックとアウトバウンドトラフィックを制御します。また、NSG を使用して、サブネット レベルまたは特定のリソースに対するきめ細かなトラフィック制御をさらに定義します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/419037/afd42287-9896-6e63-40a6-d422ec1fc90b.png)


## Step 5. 追加の保護レイヤーと負荷分散の実装（Application Gateway）
元記事では明言されていませんが、提示されている構成図に則り、Application Gateway を追加します。Azure サービスと暗号化メカニズムを利用して、保存時および転送中のデータを保護します。LLM アプリケーション内に保存されている機密データを暗号化し、データ転送には HTTPS/TLS などの安全な通信プロトコルを使用します。
Application Gateway は、HTTP(S)トラフィックを受け、内部リソースへ安全にルーティングするアプリケーション層（レイヤー7）のロードバランサです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/419037/616fab61-bfc7-e7be-628b-6217ce4d6a4c.png)

さらにセキュリティを強化するならば、VNet ピアリングを利用した Hub-and-Spoke トポロジの実装を検討しても良いかもしれませんが、Web App 単体の観点では、このような構成になると思われます。

それでは、なぜこのような構成になるのか、次の章で解説していきます。

---


# 1. アクセスと ID セキュリティ

先ほども記載した通り、このチュートリアルでは、メンテナンスがしやすいよう環境変数に Azure OpenAI アクセスキーなどの機密情報が設定されており、セキュアな構成ではありませんでした。そのため、 Azure のベストプラクティスに則って、マネージド ID と Key Vault を使用するように構成しました。

## 1-1. マネージド ID の使用
Azure マネージド ID を活用すると、キーや資格情報を手動で管理することなく、LLM アプリケーションを認証および承認します。これにより、アプリケーションは API キーを管理しなくても Azure OpenAI リソースにアクセスできます。アプリケーション コード内でキーや資格情報を利用する必要がない場合は、マネージド ID のご利用を強くお勧めします。

https://learn.microsoft.com/ja-jp/entra/identity/managed-identities-azure-resources/overview

### ロールベースのアクセス制御 (RBAC) を実装する
RBAC を利用して、LLM アプリケーションにアクセスするユーザー、グループ、またはサービスに適切な権限を付与します。最小権限の原則に従い、各エンティティに必要な権限のみを付与します。
マネージド ID を使用すると、RBAC をより効率的に活用でき、手動の権限管理を軽減できます。RBAC とマネージド ID を組み合わせることで、動的な認証要件にも対応しやすくなります。

https://learn.microsoft.com/ja-jp/azure/role-based-access-control/overview

## 1-2. Azure Key Vault を利用して安全にキーを管理する
Azure Key Vault を使用してキーやエンドポイント、OpenAI API バージョン情報を安全に保存および管理することもできます。LLM アプリケーションのコード内にキーをハードコーディングしたり埋め込んだりすることは避けてください。
ただし、Azure のベストプラクティスに沿うならば、よりセキュアに情報を保つためにキーを定期的にローテーションして有効期限を切るなど、手動管理の手間が発生します。この観点より、アプリケーション コード内でキーや資格情報を利用する必要がない場合は、マネージド ID のご利用をお勧めします。

https://learn.microsoft.com/ja-jp/azure/key-vault/general/basic-concepts

## 1-3. マネージド ID と Azure Key Vault の併用
マネージド ID は、Azure AD と統合された認証手段を提供するため、Azure OpenAI など Azure サービスへのアクセスでコード内へのキー記載を不要にします。一方、Azure Key Vault は、暗号化キー、外部サービス向けのAPIキー、パスワード、証明書など、Azure AD統合では直接カバーできない「あらゆるタイプの機密情報」を安全に格納・管理するためのサービスです。

基本的にはマネージド ID による管理で問題ないですが、以下のようなケースでは、Azure Key Vault が依然として有効ですね。
* カスタム暗号化用の鍵や TLS/SSL 証明書など、独自に管理する必要がある機密情報
* Azure AD 統合を行えない外部APIや他社サービスへのアクセスに必要なシークレット
* コンプライアンス上、キー・シークレット管理に対する厳格な監査・ローテーションが求められる場合

つまり、マネージド ID は「Azureリソースへの認証資格情報管理不要化」、Key Vault は「幅広い機密情報の集中管理・ローテーション・監査」を担当し、両者を組み合わせることで、より安全かつ柔軟なセキュリティモデルが実現できると考えてもらえばわかりやすいかと思います。

## 補足：Azure OpenAI で Azure Key Vault を利用するケース
マネージド ID や、Azure Key Vault の設定方法を具体的に知りたい場合は、以下の Microsoft Learn をご一読ください。Azure OpenAI におけるシークレット情報の管理方法が掲載されています。

https://learn.microsoft.com/ja-jp/azure/app-service/deploy-intelligent-apps?pivots=openai-node#api-keys-and-endpoints

なお、一部抜粋すると、今回 App Service にて使用する Azure Key Vault の値は以下のようになります。

| 設定名            | Value                                                                                     |
|-------------------|-------------------------------------------------------------------------------------------|
| DEPLOYMENT_NAME   | @Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/mysecret/)          |
| ENDPOINT          | @Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/mysecret/)          |
| API_VERSION       | @Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/mysecret/)          |

# 2. ネットワークセキュリティ

続けて、ネットワークについてみていきましょう。ネットワーク セキュリティとは、LLM とそのサービスで使用されるネットワーク インフラストラクチャと通信チャネルの保護を指します。ネットワーク セキュリティには、ネットワーク トラフィックの分離、セグメンテーション、暗号化の確保、およびネットワーク攻撃の防止と検出が含まれます。

## 2-1. プライベート エンドポイントの活用

Azure Private Endpoint を用いて、LLM アプリケーションと Azure OpenAI リソース間の通信を Azure バックボーン ネットワーク経由に限定します。これにより、パブリック インターネットを経由しない内部的な通信が可能となり、盗聴や改竄のリスクを低減できます。

- Azure OpenAI や他の関連サービス（Storage Account、Key Vault、Azure Cognitive Searchなど）に対してプライベート エンドポイントを設定し、仮想ネットワーク内部に閉じた安全な接続を実現
- 不要な外部アクセスを遮断し、インバウンド・アウトバウンド両面で最小限かつ明確な通信経路を確保

https://learn.microsoft.com/ja-jp/azure/ai-services/cognitive-services-virtual-networks

## 2-2. Network Security Group (NSG) および Azure Firewall の導入

Network Security Group（NSG）を用いて、特定のサブネットやリソースに対するアクセス制御ルールを設定します。また、Azure Firewall や Azure Firewall Premium を適用し、アプリケーションレベルでのフィルタリングや宛先ベースの通信制御が可能になります。

- NSG による許可/拒否ルール設定で、特定ポート・プロトコル経由の通信を最小限に限定
- Azure Firewall で既知の悪意あるドメインや IP への通信をブロックし、LLM アプリケーションがアクセスするリソースを厳選

https://learn.microsoft.com/ja-jp/azure/firewall/overview

https://learn.microsoft.com/ja-jp/azure/virtual-network/network-security-groups-overview

## 2-3. セキュア プロトコル（HTTPS/TLS）の強制
LLM アプリケーションとバックエンド リソース間の通信は、すべて HTTPS/TLS を介して暗号化します。これにより、中間者攻撃や盗聴への耐性が高まり、データの機密性と完全性を維持できます。
今回使用したように、Application Gateway を用いて TLS 終端や SSL/TLS 証明書管理を集約することが可能です。また、すべての通信経路で暗号化を徹底し、機微情報がネットワーク上で平文にならないよう対策を講じることも有効です。

## 2-4. Hub-and-Spoke トポロジや VNet ピアリングの採用
ネットワーク設計は、Hub-and-Spoke トポロジを取り入れることで、ネットワークの管理や監視を中央集約化できます。Hub VNet に Azure Firewall、DNS、ネットワーク監視ツールを集約し、Spoke VNet に LLM アプリケーションや Azure OpenAI リソースを配置します。
Hub-Spoke トポロジは、複数のVNetを使い、中央の Hub VNet に共通基盤を集約し、Spokeとなる複数のVNetをハブに接続するアーキテクチャのことを指します。今回紹介した構成は、厳密には Hub-Spoke トポロジといえるものではなく、「一つのVNet内でサブネットを役割分けしているセグメンテーション戦略」であることにご注意ください。
> To secure AI Services within Azure, implementing a comprehensive network security strategy using private endpoints, firewall rules, Network Security Groups (NSGs), and a well-architected hub-and-spoke network topology is crucial. Start by configuring private endpoints for AI services; this ensures that the services are only accessible within your virtual network. Complement this with strict firewall rules to control inbound and outbound traffic. Use NSGs to further define fine-grained traffic control at the subnet level or for specific resources. At the landing zone level, adopt a hub-and-spoke topology where the hub serves as the central point of connectivity and hosts a Network Virtual Appliance (NVA) like Azure Firewall. Traffic routed through User Defined Routes (UDRs) in the hub allows for centralized inspection and governance. This layered approach provides a robust security posture for protecting AI workloads in Azure.

## 2-5. ネットワーク監視とログ収集
Azure Network Watcher や Azure Monitor、Azure Sentinel などを活用して、ネットワーク トラフィックを常時監視します。不審なアクティビティを早期発見し、アラートや自動応答ワークフローを実装することで、ネットワークレイヤでの攻撃を迅速に対処できます。
- トラフィックログ、フローログを定期的に分析し、セキュリティ ポリシーの改善に反映
- 監視結果を踏まえ、アクセス制御ルールや認可ポリシーを継続的に最適化
 
今回の例では Azure Monitor(Application Insights) しか使用しませんが、監視をより強めたい場合は Azure Network Watcher や Azure Sentinel の導入もご検討ください。

https://learn.microsoft.com/ja-jp/azure/azure-monitor/overview

https://learn.microsoft.com/ja-jp/azure/network-watcher/network-watcher-overview

https://learn.microsoft.com/ja-jp/azure/sentinel/overview?tabs=azure-portal


なお、今回の構成ではネットワーク分離のためにサブネットが細分化されていますが、Microsoft Learn では Key Services Subnet としてまとめられています。この場合はエンドポイントが一括で集約されるため、管理が楽になります。ただし、細分化された制御がしにくくなる点にご留意ください。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/419037/a593b27a-2a2e-7120-ca78-5046b28f854e.png)
https://learn.microsoft.com/ja-jp/azure/ai-services/openai/how-to/on-your-data-configuration

https://learn.microsoft.com/ja-jp/azure/well-architected/service-guides/azure-openai


補足ですが、 Azure AI Search から Azure Storage への通信は、以下の順序で解決されます。
Azure AI Searchサービス本体 ⇒ Data サブネット内の Azure Storage 用プライベートエンドポイント ⇒ Azure Storage

この流れは概念上「Azure AI Search ⇒（Storage用PE）⇒ Azure Storage」となりますが、実際にはAI Searchそのものが、ストレージアクセス時にストレージ用PEが紐づくVNet内のプライベートIPを解決し、そこへリクエストを出す形になります。


# 3. データセキュリティ

ここからはネットワーク セキュリティと一部重複しますが、データそのものの保護に焦点を当てます。LLM が扱うデータには、学習やクエリ時に使用される入力データ、生成された応答、会話履歴、およびこれらに関連するメタデータが含まれます。これらのデータが漏洩や改竄、誤用されないよう、データ分類や暗号化、アクセス制御、マスキング、バックアップ・ディザスタリカバリ(BC/DR)戦略などを統合的に適用することが重要となります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/419037/35c38de0-9b53-59c0-4057-ee278bfbdad1.png)

https://learn.microsoft.com/ja-jp/azure/search/search-security-overview

## 3-1. データ分類とラベル付け
まず、自分が扱うデータを用途や重要度をもとにラベル分けし、個人情報(PII)や財務データ、独自ノウハウなど、保護対象を明確化することにより、適切な暗号化やアクセス制御の適用が容易になります。
データの種別・ラベル分けをサポートしてくれるソリューションとして、Microsoft Purview が活用できます。
Microsoft Purview を用いると、データソースをスキャンして自動的に分類・ラベリングでき、データガバナンスとセキュリティ基盤を整えるのに役立ちます。

https://learn.microsoft.com/ja-jp/purview/purview

## 3-2. At Rest / In Transit における暗号化
At Rest / In Transit は、休止中／転送中を指します。言い換えると、保存中のデータ／転送中のデータということですね。Azure Storage、Cosmos DB、Azure AI Search などのサービスでは、保存時 (at rest) のデータは既定で暗号化されています。必要に応じてカスタマーマネージドキー(CMK)を Key Vault で管理し、より厳格な暗号化ポリシーを適用できます。

### At Rest における暗号化
なお、暗号化には「Azure Storage Service Encryption」と「Azure Disk Encryption」の 2 種類が利用できます。どちらも Azure 上でデータを暗号化して保護する仕組みですが、保護対象や利用シーンが異なります。たとえるなら、自宅の倉庫に保管する物品をまとめて安全にする方法（SSE）と、使っているパソコン本体のハードディスクを丸ごと暗号化する方法（ADE）のようなイメージを持っていただくとわかりやすいかと思います。

https://learn.microsoft.com/ja-jp/azure/storage/common/storage-service-encryption

https://learn.microsoft.com/ja-jp/azure/virtual-machines/disk-encryption

### In Transit における暗号化
通信経路上のデータは TLS によって暗号化し、盗聴や中間者攻撃を防ぎます。全ての接続先が TLS 対応であることを確認してください。

https://learn.microsoft.com/ja-jp/azure/app-service/overview-tls

なお、先に案内した内容の再掲となりますが、TLS/SSL 証明書の管理には Key Vault を利用することをご検討ください。

https://learn.microsoft.com/ja-jp/azure/app-service/configure-ssl-certificate?tabs=apex%2CRBAC

## 3-3. RBACと最小権限原則によるデータアクセス制御
Step 1でも触れた RBAC (ロールベースアクセス制御) はデータレイヤーでも効果的です。ストレージ、Cosmos DB、AI Searchなどのデータソースに最小限の権限のみ付与し、マネージド ID と組み合わせることでキー管理なしで安全なデータアクセスが可能になります。  定期的な権限レビューを行うようにすると、より厳格な制限が可能になります。

## 3-4. データマスキングとテストデータの匿名化
本番データをテスト環境で利用する際は、機微情報をマスキングまたは匿名化し、万が一の流出や不正利用を防ぎます。先ほど案内した Azure Purview や、　Data Loss Prevention (DLP) ツールを活用することで、データ移行時にも機密情報を適切に保護できます。

https://www.microsoft.com/ja-jp/security/business/security-101/what-is-data-loss-prevention-dlp

補足ですが、 Azure AI Search にて PII 検出が実施できることも紹介しておきます。

https://learn.microsoft.com/ja-jp/azure/search/cognitive-search-skill-pii-detection

## 3-5. バックアップとディザスタリカバリ
Azure Backup や Azure Site Recovery や Geo 冗長レプリケーションを利用して、データ消失への備えを行います。定期的なバックアップと復旧テストにより、障害発生時にも速やかなリカバリが可能です。

https://learn.microsoft.com/ja-jp/azure/ai-services/openai/how-to/business-continuity-disaster-recovery

## 3-6. 脅威検知と監視
Azure Defender (Microsoft Defender for Cloud) や Microsoft Sentinel を用いて、データストアへの不審なアクセスや挙動を監視します。アラートや自動応答を設定し、インシデント発生時の初動を迅速化できます。

https://learn.microsoft.com/ja-jp/security/benchmark/azure/baselines/azure-openai-security-baseline

# 4. アプリケーションセキュリティ

ここまでで、ID・アクセス管理やネットワーク、データの安全性を高めましたが、次はアプリケーションそのもののセキュリティに着目します。アプリケーションセキュリティでは、LLMを取り巻くアプリケーションロジックや機能性が不正利用されないようにアプリケーションを構成します。

## 4-1. 入力バリデーションとセキュアコーディング
ユーザーが入力するプロンプトや外部ソースから取得する情報は、原則信頼できないデータとして扱います。  
SQL インジェクションや XSS などの攻撃を防ぐため、入力を検証・サニタイズし、フレームワークやライブラリを最新化します。

## 4-2. モデルトレーニング データのセキュリティ保護
LLM のトレーニングに使用されるトレーニング データを不正アクセスから保護し、データ保護規制への準拠を確保します。先に案内したデータ匿名化や差分プライバシーなどの技術を使用して、データ セキュリティをさらに強化します。

## 4-3. LLM コンポーネントを定期的に更新してパッチを適用する
潜在的な脆弱性を軽減するために、LLM フレームワーク、ライブラリ、依存関係を最新のセキュリティ パッチと更新プログラムで最新の状態に保ちます。例えば Lang Chain や LlamaIndex、 FaissAPIなど、Python アプリケーションの実装において様々なライブラリをご利用のことかと思いますが、それらの更新を忘れず実施してください。

## 4-4. LLMアクティビティの監視と監査
LLMへのクエリやレスポンスをログとして蓄積し、不審な使用パターンや大量アクセスを検出します。Application InsightsやAzure Monitorを組み合わせ、異常検知や通知機能を強化してください。

## 4-5定期的なセキュリティ テストの実施
ペネトレーションテストや脆弱性スキャンなどのセキュリティ評価を定期的に実行し、アプリケーションのセキュリティ上の弱点や脆弱性を特定して対処することを忘れないでください。これは一般的なアプリケーションと同様ですね。

# 5. ガバナンスセキュリティ

最後に、ガバナンス（統制）に関するセキュリティ対策を取り上げます。ガバナンスセキュリティでは、LLMが生成するコンテンツの倫理的・社会的影響や、法的・規制要件への準拠についてご案内します。

## 5-1. LLM利用ポリシーと法規制準拠
Azure OpenAI の利用規約やガイドラインに従い、LLMの使用範囲を明確化します。GDPR や HIPAA などのコンプライアンス要件に対応するため、Azure Compliance を活用して現状の遵守状況を確認します。

https://learn.microsoft.com/ja-jp/azure/compliance/

https://www.ppc.go.jp/enforcement/infoprovision/EU/

https://www.mhlw.go.jp/shingi/2010/06/dl/s0616-4g.pdf


## 5-2. Responsible AI フレームワークの活用
Azure Responsible AI フレームワークを用いて、公平性や透明性、説明責任を確保します。モデルのバイアス検出や不適切な出力防止など、LLMがもたらす社会的リスクに備えてください。Microsoft では、責任ある AI の標準として、公平性、信頼性と安全性、プライバシーとセキュリティ、包括性、透明性、説明責任の 6 つの原則に従って AI システムを構築するためのフレームワークを準備しています。ぜひご利用ください。

https://learn.microsoft.com/ja-jp/azure/machine-learning/concept-responsible-ai?view=azureml-api-2

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/419037/be2dcb01-6509-f409-68d9-b69588ed2d78.png)


## 5-3. Azure Policy / Azure Security Center の活用
Azure Policy や Azure Security Center を用いて、リソース構成やセキュリティ標準への準拠状況を自動的に評価・修正できます。これにより、セキュリティポリシーや運用ルールを一貫して適用し続けることが可能になります。

https://learn.microsoft.com/ja-jp/azure/ai-services/policy-reference

https://learn.microsoft.com/en-us/legal/cognitive-services/openai/data-privacy?tabs=azure-portal

---

# まとめ
今回はセキュリティ面とインフラ面に焦点をあてて、Azure OpenAI におけるセキュリティ戦略を紹介させてもらいました。最後に、Azure OpenAI Service 上の Azure Well-Architected フレームワークの分析観点 のページをご紹介させていただきたいと思います。

https://learn.microsoft.com/ja-jp/azure/well-architected/service-guides/azure-openai

また、今回ご紹介した構成に近いものが、以下のリポジトリにて紹介されています。良ければご利用くださいませ。

https://learn.microsoft.com/ja-jp/azure/architecture/ai-ml/architecture/baseline-openai-e2e-chat

https://github.com/Azure-Samples/openai-end-to-end-baseline

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/419037/928c4628-31cf-ca1d-63e0-a70594b1305c.png)

この記事がみなさまのご理解のお役に立てれば幸いです。

## 参考文献

https://techcommunity.microsoft.com/blog/azurearchitectureblog/demystifying-azure-openai-networking-for-secure-chatbot-deployment/3932802

https://techcommunity.microsoft.com/blog/azurearchitectureblog/security-best-practices-for-genai-applications-openai-in-azure/4027885


# おわりに
**＊本稿は、個人の見解に基づいた内容であり、所属する会社の公式見解ではありません。また、いかなる保証を与えるものでもありません。正式な情報は、各製品の販売元にご確認ください。**

ご覧いただき、ありがとうございました。なにかありましたら [X](https://x.com/xqdior) までご連絡ください。

## スタートアップ企業様向けのお知らせ
日本マイクロソフトでは、スタートアップ企業様向けに、ビジネスを支援するプログラムをご提供しています。Azure の無料クレジット 最大 $150,000 や、私を含むマイクロソフトのエキスパート エンジニアによる技術支援がもらえます。是非チェックしてみてください。

https://zenn.dev/microsoft/articles/microsoft_foundershub