「社内ネットワークに繋がっているから安全」——リモートワークとクラウドが当たり前になった今、この前提はすでに崩れています。
VPNで社内に接続している・オフィスのWi-Fiを使っている——それだけでは「安全」とは言えません。攻撃者が社内ネットワークに侵入すれば、その端末は「信頼された内側」として扱われます。内側に入ってしまえば横展開は容易です。
ゼロトラストは「どこから接続しているかではなく・誰が・何の端末で・何にアクセスしようとしているかを都度検証する」という設計思想です。この記事では、ゼロトラストの3つの原則とAzureでの具体的な実装パターンを解説します。
クラウドセキュリティの全体像については「クラウドセキュリティとは？責任共有モデルから始める設計の全体像」を先にご覧ください。
境界防御モデルの限界——「社内は安全」が通用しなくなった理由
従来のセキュリティモデルは「境界防御」を中心に設計されていました。ファイアウォールで社内ネットワークの外側を守り、内側は信頼するという考え方です。
境界防御モデル（Perimeter Security Model） 社内ネットワークと外部を明確に分け、境界をファイアウォール等で守ることでセキュリティを確保する従来型のアプローチ。「内側は安全・外側は危険」という前提に立つ。
このモデルが機能していたのは「社員が社内ネットワークで固定されたPCを使って業務する」前提があったからです。しかし現在の環境は大きく変わっています。
- 社員が自宅・カフェ・出張先から業務する
- データがクラウド（Microsoft 365・Azure）に存在する
- 私物デバイスや外部パートナーがアクセスする
- 攻撃者がフィッシングメールで社員の端末を侵害し「内側」に侵入する
境界の内側に入られた時点で、境界防御は機能しません。実際にAD環境での攻撃手法（Pass-the-Hash・横展開）は「内側に入った後」の動きを悪用します。詳しくは「AD攻撃手法と要塞化」を参照してください。
ゼロトラストとは何か——3つの原則で理解する
ゼロトラスト（Zero Trust） 「すべてのアクセスは信頼しない」を前提とし、ユーザー・デバイス・ネットワークの場所によらず毎回認証・認可を行うセキュリティモデル。Microsoftは「明示的に検証する・最小権限アクセスを使用する・侵害を想定する」の3原則を定義している。
原則①：すべてのアクセスを明示的に検証する
「社内ネットワークにいるから信頼する」ではなく、アクセスのたびにID・デバイス・場所・リスクスコアを検証します。
具体的には以下の情報を組み合わせてアクセスの可否を判断します。
- 誰がアクセスしているか（ユーザーID・グループ）
- どのデバイスからアクセスしているか（管理されたデバイスか・コンプライアンス準拠か）
- どこからアクセスしているか（国・IPアドレス・ネットワーク）
- 何にアクセスしようとしているか（アプリケーション・データの機密度）
- リスクスコアが高くないか（通常と異なる行動パターンか）
原則②：最小権限アクセスを徹底する
必要最低限の権限のみを付与し・常時特権を持たせず・使い終わったら権限を剥奪します。
JIT（Just-In-Time）アクセスはこの原則の実装です。PIMを使った特権アクセス管理については「PIMとは？Azure特権アクセス管理の実務ガイド」で解説しています。また最小権限の設計原則については「最小権限の原則とは？実務での考え方と設計例」を参照してください。
原則③：侵害を前提に設計する
「侵害されないようにする」だけでなく「侵害されても被害を最小化できる設計にする」という考え方です。
- ネットワークを細かく分割し横展開を阻止する（マイクロセグメンテーション）
- すべての操作をログに残し異常を検知できる状態にする
- インシデント発生時の対応手順を事前に整備する
インシデント発生時の対応については「セキュリティインシデント対応入門」で解説しています。
AzureでゼロトラストをどうAzureで実現するか——5つの実装要素
IDの検証——条件付きアクセスとMFA
ゼロトラスト実装の中核がIDの検証です。EntraID（Azure AD）の条件付きアクセスを使って「誰が・どんな条件で・何にアクセスできるか」をポリシーとして定義します。
条件付きアクセス（Conditional Access） Entra IDの機能。ユーザー・デバイス・場所・リスクスコアなどの条件に基づいてアクセスを許可・拒否・追加認証を要求するポリシー。ゼロトラスト実装の中核となる仕組み。
条件付きアクセスで実現できる代表的なポリシーは以下の通りです。
| ポリシー例 | 内容 |
|---|---|
| 管理者ロールにはMFAを必須にする | Domain Admins等の特権操作には必ず多要素認証を要求 |
| 未管理デバイスからはメールのみ許可 | 会社管理外のデバイスからのフルアクセスを制限 |
| リスクの高いサインインをブロック | 通常と異なる国・IPからのアクセスを自動ブロック |
| 準拠デバイス以外はアクセス不可 | IntuneでコンプライアンスポリシーをパスしたデバイスのみADへ接続 |
MFAの実装については「MFAとは？多要素認証の仕組みと実務での導入・運用ガイド」を参照してください。
参考：条件付きアクセスとは | Microsoft Learn
デバイスの検証——準拠デバイスのみを許可する
Intune（Microsoft Intune） MicrosoftのクラウドベースのMDM（モバイルデバイス管理）・MAM（モバイルアプリケーション管理）サービス。デバイスのコンプライアンスポリシーを定義し、条件付きアクセスと連携して準拠デバイスのみへのアクセスを許可できる。
「誰が」だけでなく「どのデバイスから」を検証することがゼロトラストのデバイス検証です。Intuneでデバイスのコンプライアンスポリシーを定義します。
コンプライアンスポリシーの例：
- OSのバージョンが最新か
- BitLockerによるディスク暗号化が有効か
- アンチウイルスが有効か
- 脱獄・ルート化されていないか
条件付きアクセスと連携することで「IntuneのコンプライアンスポリシーをパスしたデバイスのみMicrosoft 365にアクセスできる」という制御が実現できます。
ネットワークの分離——マイクロセグメンテーション
マイクロセグメンテーション（Micro-Segmentation） ネットワークを細かく分割し、セグメント間の通信を最小限に制限することで、侵害が広がるのを防ぐ手法。従来の大きなネットワーク分割より細かい粒度でアクセス制御を行う。
ゼロトラストのネットワーク設計は「内側に入ったら自由に動ける」状態をなくすことが目的です。AzureではVNetのサブネット分割とNSGで実現します。詳しくは「Azureネットワークセキュリティ設計入門」を参照してください。
アプリケーションへのアクセス制御
Microsoft Entra アプリケーションプロキシ オンプレミスの社内アプリケーションをインターネット経由で安全に公開するサービス。VPNなしでEntra IDの条件付きアクセスを通じてアクセス制御できる。
クラウドアプリケーションはEntra IDでシングルサインオン（SSO）を実装し、条件付きアクセスで保護します。オンプレミスのアプリケーションはMicrosoft Entra アプリケーションプロキシを使って安全に公開できます。
データ保護とログ監視
ゼロトラストの最後の要素はデータの保護と監視です。
- Microsoft Purview：データの分類・保護ラベルの適用
- Defender for Cloud：リソースの脅威検知・セキュリティスコア管理
- Azure Monitor / Sentinel：ログの収集・異常の検知
M365環境での監査ログ活用については「M365 Purview入門｜監査ログの取り方とインシデント調査への活用」で解説しています。
条件付きアクセスポリシーの設計パターン
基本的なポリシーの設計例
条件付きアクセスポリシーは「IF（条件）THEN（アクション）」の形式で設計します。
【ポリシー例①：管理者へのMFA強制】
IF ユーザーが「グローバル管理者」または「特権ロール管理者」
THEN MFAを要求する
【ポリシー例②：リスクの高いサインインのブロック】
IF サインインリスクが「高」
THEN アクセスをブロックする
【ポリシー例③：未管理デバイスへの制限】
IF デバイスがIntuneのコンプライアンスポリシー非準拠
AND アクセス先がSharePointまたはOneDrive
THEN アクセスをブロック（またはMFAを要求）
【ポリシー例④：海外からのアクセス制限】
IF サインイン場所が「許可された国」以外
THEN アクセスをブロックするリスクベースの条件付きアクセス
Identity Protection（Entra ID Identity Protection） Entra IDの機能。ユーザーのサインインパターンを機械学習で分析し、通常と異なる行動（普段と異なる国からのサインイン・漏洩した資格情報の使用等）をリスクスコアとして算出する。
Entra ID Identity Protectionと条件付きアクセスを組み合わせることで「リスクスコアが高い場合だけMFAを要求する」というリスクベースのポリシーが実現できます。
【リスクベースポリシーの例】
IF ユーザーリスクが「中」以上
THEN パスワードの変更を要求する
IF サインインリスクが「高」
THEN アクセスをブロックする参考：Entra ID Identity Protection の概要 | Microsoft Learn
よくある失敗パターン
① 条件付きアクセスポリシーを設定せずにEntra IDを使っている
Entra IDを導入しても条件付きアクセスポリシーを1つも設定していないケースがあります。この状態ではEntra IDはただの認証基盤であり、ゼロトラストの恩恵を受けられません。まず管理者へのMFA強制ポリシーから始めてください。
② すべてのユーザーに同じポリシーを適用している
管理者も一般ユーザーも同じポリシーでは、管理者に必要な追加の制御ができません。ユーザーのリスクレベル・ロール・アクセス先に応じてポリシーを分けて設計することが重要です。
③ 「レポート専用モード」のままポリシーを本番適用していない
条件付きアクセスポリシーはレポート専用モード（実際にはブロックしない）で動作確認してから本番適用することが推奨されます。テストせずに本番適用すると、正規ユーザーがアクセスできなくなる障害が発生する可能性があります。
④ ゼロトラストを「製品を導入すること」と捉えている
「ゼロトラスト製品を買えばゼロトラストになる」という誤解があります。ゼロトラストは製品ではなく設計思想です。条件付きアクセス・MFA・最小権限・ログ監視を組み合わせた設計の積み重ねがゼロトラストの実現です。
ゼロトラスト実装チェックリスト
IDとアクセス管理
- 全管理者アカウントにMFAを設定している
- 条件付きアクセスポリシーを少なくとも1つ設定している
- リスクの高いサインインのブロックポリシーを設定している
- PIMでJITアクセスを実装している（または計画している）
デバイス
- Intuneでデバイスのコンプライアンスポリシーを定義している
- 準拠デバイスのみにアクセスを制限する条件付きアクセスポリシーを設定している
ネットワーク
- VNetでサブネット分割を行い横展開を防ぐ設計にしている
- NSGで不要な通信を遮断している
- 管理ポートをインターネットに直接公開していない
監視
- Defender for Cloudでセキュリティスコアを定期確認している
- 監査ログを有効化して異常を検知できる状態にしている
- インシデント発生時の対応手順を整備している
まとめ——ゼロトラストは「製品」ではなく「設計思想」
ゼロトラストの本質は「信頼しない・都度検証する・侵害を前提にする」という考え方の転換です。特定の製品を導入すれば完成するものではなく、ID・デバイス・ネットワーク・アプリ・データの各層で設計を積み重ねることで実現します。
今日確認すべきことは1つです。Entra IDの条件付きアクセスポリシーを開き「グローバル管理者へのMFA強制ポリシーが有効になっているか」を確認してください。なければ今すぐ設定することを推奨します。管理者アカウントの侵害はすべての起点になります。
次のステップはAzureセキュリティ設計全体の棚卸しです。「Azureセキュリティ設計チェックリスト」でクラウド環境全体のセキュリティを確認できます。
あわせてご覧ください
- クラウドセキュリティとは？責任共有モデルから始める設計の全体像
- Azure Defender for Cloudとは？セキュリティスコアと推奨事項で守れる環境を作る
- Azureネットワークセキュリティ設計入門｜VNet・NSG・ファイアウォールの考え方
- MFAとは？多要素認証の仕組みと実務での導入・運用ガイド
- PIMとは？Azure特権アクセス管理の実務ガイド
- 最小権限の原則とは？実務での考え方と設計例
- AD攻撃手法と要塞化｜Pass-the-Hash・Kerberoasting・GoldenTicket・DCSyncを理解して守る
- セキュリティインシデント対応入門｜若手エンジニアが最初に知っておくべき対応フローと考え方
コメント