Azureのセキュリティとは？
Microsoftが提供するAzureのセキュリティは、単一の防御策に依存せず、複数の層を重ねて脅威を防ぐ「多層防御（Defense in Depth）」の考え方に基づいて設計されています。
これにより、クラウド利用に伴う多様なリスクを、防御・監視・ガバナンスの各層から体系的に管理・最小化する統合的な仕組みが実現されています。
この仕組みは、技術的な対策の集合体ではなく、Microsoftが掲げる信頼できるクラウドという理念に基づいています。この理念は、セキュリティ、プライバシー、コンプライアンス、透明性という4つの基本原則を柱としており、Azureのすべてのサービス設計と運用に反映されています。
また、クラウド環境には、利用者が直接管理できない領域が存在します。この課題に対応するため、Azureでは責任共有モデルという概念を採用しています。このモデルにより、企業はインフラ基盤の保護という負担から解放され、自社のデータやアプリケーションといった、よりビジネスに近い領域の保護に集中することが可能になります。
「信頼できるクラウド」と「責任共有モデル」とは？
このセクションでは、前述した「信頼できるクラウド」と「責任共有モデル」の2つの概念について詳しくご説明します。
信頼できるクラウド
企業の重要な資産であるデータや業務システムを外部のクラウドサービスに預けるには、その提供者に対する信頼が不可欠です。Microsoftは、この信頼を達成するためのコミットメントとして以下の4つの基本原則を定めています。
信頼できるクラウド(参考：Microsoft）
セキュリティ
Microsoftは、世界中から収集される数兆件もの脅威シグナルをAIで分析し、脅威の検知と対応を迅速化しています。
プラットフォーム自体の堅牢性を高めるとともに、顧客が利用できる高度なセキュリティツール（Microsoft Entra IDやMicrosoft Defender for Cloudなど）を提供しています。
プライバシー
Microsoftは、顧客が自らのデータをコントロールできることを保証し、データの保存場所や利用方法について明確な情報を提供します。
データは保存時も転送中も暗号化によって保護され、Microsoftが顧客のデータを広告目的などで利用することはありません。
コンプライアンス
Azureは、ISO 27001やSOC、GDPR（EU一般データ保護規則）など、100を超える世界各国のコンプライアンス認証を取得しており、広範なカバレッジを提供しています。
これにより、企業はコンプライアンス要件を効率的に満たすことができます。
透明性
Microsoftは、自社の運用に関する情報を積極的に公開することで、高い透明性を維持しています。
これには、データ開示要求に関するレポートの公開などが含まれ、顧客がMicrosoftのサービスを安心して利用できるための判断材料を提供しています。
責任共有モデル
責任共有モデルは、セキュリティ対策の責任範囲をMicrosoftと顧客の間で明確に定義するものです。
この責任分担の比率は、利用するクラウドサービスの形態、SaaS（Software as a Service）、PaaS（Platform as a Service）、IaaS（Infrastructure as a Service）によって変動します。 クラウドへの移行によって、物理的なインフラに関する責任はMicrosoftに移管されます。オンプレミス環境では顧客がデータセンターの物理的なセキュリティからサーバーの管理まですべてを担っていましたが、Azureを利用することでこれらの責任から解放されます。
以下に、サービスモデルごとの責任分担の概要をまとめた表を示します。
責任共有モデル （参考：Microsoft）
表からわかるように、どのようなサービス形態であっても、顧客が常に責任を負う領域が存在します。具体的には、データそのもの、デバイス（PCやスマートフォンなど）、アカウントの管理などが挙げられます。
Azure AIサービスのセキュリティ
AIの利活用が進む中、多くの企業にとって「機密情報や独自データをAIに入力しても安全か」、「AIの出力が不正確であったり、有害な内容を含んだりするリスクはないか」といった懸念は、導入をためらう大きな要因となっています。Microsoftはこうした懸念や企業が求める安全性に応えるため、Azure上で提供するAIサービスにおいて、技術的な安全対策と倫理的なガバナンスを両立させる多層的なアプローチを採っています。
このアプローチの根幹にあるのが、Microsoftが掲げる責任あるAIの原則と、それを具現化するためのAIのための責任共有モデルです。
これは、AIシステムの開発から運用、利用に至るまでの各段階で、クラウド提供者、アプリケーション開発者、そして最終利用者がそれぞれ果たすべき責任を明確にしています。
Microsoftの責任あるAI （参考：Microsoft）
本セクションでは、企業がビジネスシーンでAzureのAIサービスを安心して活用できる具体的な根拠を、技術的な仕組みとそれを支える企業姿勢の両面から詳細に解説します。
「責任あるAI」と「AIのための責任共有モデル」とは？
Microsoftは、2018年に「責任あるAI」の原則を策定し、AIシステムの開発と展開における指針としています。これには、公平性、信頼性と安全性、プライバシーとセキュリティ、包括性、透明性、人間による監視と説明責任といった要素が含まれます。
この原則を実際のワークロードに適用するためのフレームワークが、「AIのための責任共有モデル」です。
これは、AIアプリケーションを以下の3つの機能レイヤーに分解し、それぞれのセキュリティ責任を定義するものです。
AIのための責任共有モデル （参考：Microsoft）
AI利用層
エンドユーザーがAIアプリケーションを実際に使用する層です。ユーザーは、AIを倫理的かつ適切に使用する責任を負います。
AIアプリケーション層
開発者がAIプラットフォームを利用して構築する具体的なアプリケーションの層です。
開発者は、アプリケーションのロジック、データ連携、ユーザーインターフェースなどのセキュリティを確保する責任を負います。
AIプラットフォーム層
AIモデルそのものや、それを実行するインフラストラクチャーの層です。Microsoftは、この層のセキュリティを確保する責任を負います。
このモデルは、AIの安全性が単一の技術で実現されるものではなく、関係者全員がそれぞれの役割を果たすことで初めて確立されるという考え方を示しています。
データの隔離とプライバシー
企業が生成AIの利用を検討する際の主要な懸念事項の一つに、入力したプロンプトや独自データがAIモデルの再学習に使われたり、他の利用者に漏洩したりするリスクが挙げられます。
Azure OpenAI Serviceでは、この点に関して明確なポリシーが定められています。顧客が送信するプロンプト、AIによる出力、埋め込みデータ、そしてそれらのログを含むすべての顧客データは、Microsoftが提供する大規模言語モデル（LLM）の学習には一切使用されません。また、他の顧客と共有されることも、開発元であるOpenAIに提供されることもありません。データは顧客のAzureテナント内で完全に隔離され、Microsoftの厳格なクラウドセキュリティ基準の下で保護されます。
「データが残らない、使われない、漏れない」という設計思想と明確な規約は、金融、医療、公共機関といった特に機密性の高い情報を扱う業界でもAzure AIサービスが採用される大きな理由となっています。
有害コンテンツとハルシネーションへの対策
AIの安全性確保には、入力データの保護だけでなく、AIからの出力内容を適切に制御することも不可欠です。
この課題に対処するためのサービスが、Azure AI Content Safetyです。
Azure AI Content Safety （参考：Microsoft)
Azure AI Content Safetyは、AIが生成する、あるいはユーザーが入力するテキストや画像に含まれる有害なコンテンツを検出し、フィルタリングするサービスです。ヘイトスピーチ、性的コンテンツ、暴力といったカテゴリを識別し、その深刻度をスコアリングします。また、生成AIの大きな課題の一つに、事実に基づかないもっともらしい情報を生成してしまう「ハルシネーション」があります。
この問題に対処するため、Azure AI Content Safetyには「Groundedness Detection」という機能がプレビュー提供(2025年9月現在)されています。これは、AIの回答が、開発者によって事前に提供された特定の情報源（社内文書や製品マニュアルなど）に基づいているかを検証する仕組みです。情報源と矛盾する内容や、情報源に記載のない内容をAIが生成した場合、それを検知することができます。
データ主権と機密性
グローバルに展開する企業や、特定の規制下にある業界では、データの保存場所や処理方法に関する要件が課せられることが少なくありません。Azure AIサービスは、こうした高度なコンプライアンス要件にも対応できる柔軟なオプションを提供しています。
Azure OpenAI Data Zonesによるデータ処理地域の保証
Azure OpenAI Data Zonesは、顧客データが特定の地理的境界内（例えば、EU域内や米国内）でのみ処理されることを保証するデプロイメントオプションです。これにより、GDPRのような地域固有のデータ保護規制への準拠が容易になります。
Azure Confidential Computingによる処理中のデータの保護
従来の暗号化技術は、保存中や転送中のデータを保護するものでしたが、データが実際にCPUやGPUで処理されている間は、メモリ上で平文の状態になる瞬間がありました。
Azure Confidential Computingは、この処理中のデータをハードウェアレベルで保護する技術です。
Azure Confidential Computingでは、Trusted Execution Environmentと呼ばれる、ハードウェアによって暗号化されたメモリ領域を生成し、その中でコードとデータを実行する仕組みを採用しています。これにより、クラウドの管理者を含む特権ユーザーであっても、処理中のデータにアクセスすることはできません。
これらの仕組みは、Azure AIサービスが、企業の厳格なセキュリティ・コンプライアンス要件に応えられるAIプラットフォームとして設計されていることを示しています。
認証基盤のセキュリティ
クラウドサービスのセキュリティにおいて、「誰が、何に、どのようにアクセスできるか」を厳格に制御する認証基盤は、重要な要素の一つです。物理的な境界が存在しないクラウド環境では、ネットワークではなくIDがセキュリティの境界線となります。
Azureでは、ID中心のセキュリティモデルを実現するため、Microsoft Entra ID（旧称：Azure Active Directory）を中核とした、統合的なID管理とアクセス制御の仕組みが整備されています。
【関連記事】
▶︎Microsoft Entra IDとは？Azure ADとの違い、機能、ライセンスを徹底解説
Microsoft Entra IDによる統合ID管理
従来、Azureの認証基盤として知られていたAzure ADは、現在Microsoft Entra IDという名称に変更されています。
これは、ID管理とアクセス制御の機能を、Microsoft 365やサードパーティのクラウドサービスにも拡張し、統合的なID管理サービス「Microsoft Entra」の中核製品として位置づけるための変更です。
これにより、ユーザーが一度のサインインで連携するすべてのサービスにアクセスできるシングルサインオン（SSO）が実現し、利便性が向上しています。
多要素認証（MFA）と条件付きアクセスによる多層防御
Microsoft Entra IDの条件付きアクセス （参考：Microsoft）
IDベースの攻撃、特にパスワード漏洩による不正アクセスは、深刻なセキュリティ課題です。Microsoft Entra IDでは、ゼロトラストの原則に基づいた多層的な防御機能を提供しています。
ゼロトラストとは、「決して信頼せず、常に検証する」という考え方で、社内ネットワークからのアクセスであっても無条件に信頼せず、すべてのアクセス要求をその都度検証するセキュリティモデルです。
このモデルを具現化する主要な機能が、多要素認証（MFA）と条件付きアクセスです。
多要素認証（MFA）
従来のパスワードに加え、スマートフォンアプリへの通知や生体認証といった複数の要素を組み合わせて本人確認を行う仕組みです。
万が一パスワードが漏洩しても、攻撃者は第二の認証要素を突破できないため、不正アクセスを効果的に防ぐことができます。
【関連記事】
▶︎Microsoft Entra IDの多要素認証を徹底解説：認証方法の比較から運用ポイントまで
条件付きアクセス
条件付きアクセスは、リソースへのアクセスを動的に制御するポリシーエンジンです。
管理者は、「もし〜ならば、〜を実行する（If-Then）」形式のルールを柔軟に設定できます。例えば、以下のようなポリシーを定義できます。
- もし、管理者が特権ロールでサインインしようとしたならば、常にMFAを要求する。
- もし、ユーザーが会社の管理外のデバイスからアクセスしようとしたならば、アクセスをブロックする。
- もし、ユーザーが社外ネットワークから機密データを含むアプリケーションにアクセスしようとしたならば、MFAを要求し、セッション時間を制限する。
上記のように、ユーザーの属性、アクセス元のIPアドレス、利用アプリケーションといった様々な条件を評価し、その都度最適なアクセスポリシーを適用します。
【関連記事】
▶︎Microsoft Entra ID 条件付きアクセスとは？ポリシー設計と設定手順を解説
最小権限の原則を実現するロールベースアクセス制御（RBAC）
ゼロトラストのもう一つの重要な原則が、最小権限の原則です。これは、ユーザーやシステムに必要最小限の権限のみを付与するという考え方です。
Azureでは、この原則を実装するための仕組みとして、ロールベースアクセス制御（RBAC）が提供されています。
Azure RBACでは、「誰が（プリンシパル）」「何を（ロール定義）」「どこで（スコープ）」実行できるかを定義します。
- プリンシパル：ユーザー、グループ、マネージドIDなど、アクセスを要求する主体。
- ロール定義：「所有者」「閲覧者」といった組み込みロールや、「仮想マシン共同作成者」のように特定の操作に限定されたロールなど、許可される操作の集合。
- スコープ：ロールが適用される範囲
RBACを適切に設計・運用することで、万が一アカウントが侵害された場合でも、攻撃者がアクセスできる範囲を限定し、被害の拡大を防ぐことができます。
このように、Azureの認証基盤は、Entra IDを中心とした統合的な仕組みによって、ゼロトラストの原則に基づいた堅牢かつ柔軟なセキュリティを実現しています。
運用基盤のセキュリティ
クラウド環境における新たな脆弱性の発見、構成の変更、進化する攻撃手法に対応するためには、日々の運用を通じてセキュリティ状態を継続的に監視し、リスクを早期に発見して対処する体制が不可欠です。
Azureでは、こうした一連のセキュリティ運用を支援するためのサービス群がプラットフォームに統合されており、セキュリティの可視化、監視、対応の自動化をシームレスに行うことができます。
Microsoft Defender for Cloudによる統合的な監視
Microsoft Defender for Cloud （参考：Microsoft）
従来Azureのセキュリティ状態の監視と防御を担っていた「Azure Security Center」および「Azure Defender」は、Microsoft Defender for Cloudという単一のサービスに統合されました。
このサービスは、Azureだけでなく、AWSやGCPといったマルチクラウド環境やオンプレミスサーバーまでを統合的に保護する、より広範な役割を担っています。主な機能は以下の通りです。
セキュリティ体制の可視化とスコア化
Microsoft Defender for Cloudは、接続されているすべてのリソースを継続的に評価し、現在のセキュリティ状態をセキュアスコアとして数値化します。これにより、組織全体のセキュリティレベルを一目で把握し、どの領域に改善が必要かを特定できます。
クラウドセキュリティ体制管理（CSPM）
評価に基づき、構成の誤りやセキュリティ上のベストプラクティスからの逸脱を検出し、具体的な修正手順とともに推奨事項として提示します。
クラウドワークロード保護プラットフォーム（CWPP）
仮想マシン、コンテナ、ストレージ、データベースといった個々のワークロードに対する高度な脅威検出機能を提供します。
これには、マルウェア対策、脆弱性スキャン、ファイル整合性の監視などが含まれ、既知および未知の脅威からリソースを保護します。
Microsoft Defender for Cloudによって、セキュリティの専門家でない担当者でも、自社のクラウド環境に潜むリスクを理解し、優先順位をつけて対策を講じることが可能になります。
Microsoft Sentinelによる高度な脅威検出と対応（SIEM/SOAR）
より高度な脅威分析やインシデント対応が求められる組織では、Microsoft Sentinelがその役割を担います。
Microsoft Sentinelは、AzureネイティブのSIEM（Security Information and Event Management）およびSOAR（Security Orchestration, Automation, and Response）ソリューションです。
SIEMとしての機能
Microsoft Sentinelは、組織内のあらゆるソースから大量のログデータ（Azureのアクティビティログ、Microsoft Entra IDのサインインログ、ファイアウォールの通信ログなど）を収集します。
そして、組み込まれた機械学習やユーザー行動分析を用いて、これらの膨大なデータの中から、個別のログだけでは見つけにくい攻撃の兆候や異常な振る舞いをリアルタイムに検出します。
SOARとしての機能
脅威が検出された後の対応プロセスを自動化するのがSOARの役割です。プレイブックと呼ばれるワークフローを定義することで、特定の種類のインシデントに対して自動的な対応を実行できます。
Azure Policyによるガバナンスとコンプライアンスの強制
セキュリティ運用において、技術的な監視だけでなく、組織として定められたガバナンスを一貫して適用し、コンプライアンスを維持することも重要です。Azure Policyは、このガバナンスをコードとして定義し、自動的に強制するためのサービスです。
Azure Policyを使用すると、以下のようなルールを定義し、Azure環境全体に適用できます。
- リソース作成の制限：「リソースは日本のリージョンにのみデプロイを許可する」「料金が一定額を超える仮想マシンSKUの使用を禁止する」
- 構成の強制：「すべてのストレージアカウントでHTTPSによる安全な転送を必須にする」「すべてのSQLデータベースで監査を有効にする」
- タグ付けの強制：「すべてのリソースに『コストセンター』タグを付与することを強制する」
ポリシーは、違反する操作を「拒否」することも、単に「監査」して準拠していないリソースを報告するだけにすることも可能です。
さらに、DeployIfNotExistsという機能を使うことで、準拠していないリソースに対して必要な設定（例：診断ログの有効化）を自動的にデプロイすることもできます。
これらのポリシーは、Microsoft Defender for Cloudのコンプライアンスダッシュボードと連携し、ISO 27001やNISTといった業界標準に対する準拠状況をリアルタイムで評価するためにも利用されます。
このように、Azureの運用基盤は、Microsoft Defender for Cloud、Microsoft Sentinel、Azure Policyという3つのサービスが緊密に連携することで、継続的なセキュリティ改善のサイクルを形成しています。
まとめ
本記事で解説してきたように、Azureのセキュリティは、個別の技術や製品の集合体ではなく、設計思想、運用プロセスを含めた包括的なフレームワークです。Microsoftは、顧客が安心してクラウドとAIの恩恵を享受できるよう、信頼される基盤を提供することを事業戦略の一つとして位置づけています。また、認証基盤の強化、運用基盤の統合管理、そしてMicrosoft Defenderシリーズによる多層防御を通じて、クラウド環境における安全性と利便性を両立しています。
加えて、近年注目を浴びるAIサービスでは、責任あるAIの原則やデータの隔離、コンテンツの安全性確保といった高度なセキュリティ対策が講じられており、生成AIの活用における懸念にも対応しています。
これらの取り組みを通じて、Azureは企業が安心してクラウドを活用し、DXやAIを活用するための信頼できる基盤を提供しています。
東京エレクトロンデバイスでは、Microsoft Azureを活用したセキュリティ設計やAI導入のご支援を行っております。お気軽にご相談ください。
