ゼロトラストセキュリティ入門｜オンプレ境界防御からクラウド時代の「信頼しない設計」へ移行する実践ガイド

「社内ネットワークに入れたら、もう安全」という前提で設計してきたオンプレの境界防御。でもクラウド時代に入り、その前提が根底から崩れつつあります。リモートワークが標準化し、SaaSの利用が広がり、境界そのものが曖昧になった今、旧来のVPN＋ファイアウォールモデルでは守り切れません。

そこで注目されているのが「ゼロトラスト（Zero Trust）」という設計思想です。「誰も信頼しない、何も信頼しない」というコンセプトは耳にしたことがあっても、具体的に何をどう変えればいいのかピンとこない方も多いはずです。

この記事では、オンプレ経験のあるインフラエンジニアを対象に、ゼロトラストの本質とAWS・Azureを使った実装パターンを現場目線で解説します。「何から手を付けるか」「よくある落とし穴」まで含めて一通り整理します。

なぜ境界防御では限界なのか？ゼロトラストが生まれた背景

オンプレ環境では、ファイアウォールで「内側（社内）」と「外側（インターネット）」を明確に分け、内側に入ったトラフィックは原則として信頼するという設計が長年の標準でした。この前提が崩れたのは、次の3つの変化が重なったからです。

・リモートワークの普及: 社員のPCが社内ネットワーク外から社内システムに接続する機会が激増。VPNの出口で一度だけ認証すれば、その後は「内側の人」として扱われる設計は、認証情報の漏えい一発で全崩れします。
・クラウド＆SaaSへの移行: メールはMicrosoft 365、ファイルはGoogle Drive、CRMはSalesforceと、守るべき資産がデータセンターの外に散在。「社内ネットワークが境界」という定義が成り立ちません。
・ラテラルムーブメントの脅威: 攻撃者が境界を突破した後、社内を横移動しながら特権を昇格させる手法が常套化。内側を「安全ゾーン」とみなす設計は、突破後の被害を最大化します。

ゼロトラストは2010年代にJohn Kindervag（当時Forrester Research）が提唱し、2020年にNISTがSP 800-207として標準化した設計哲学です。米国連邦政府が2021年の大統領令でゼロトラスト移行を義務化したことで、日本のエンタープライズにも急速に広まりました。

ゼロトラストの7原則（NIST SP 800-207準拠）

ゼロトラストは製品ではなく「考え方」です。NIST SP 800-207では以下の7原則が定義されています。現場での実装判断の拠り所にしてください。

ゼロトラスト実装の4ステップ（AWS・Azure対応）

ゼロトラストを一気に実現しようとすると費用も工数も膨大になります。現場では「ID管理 → デバイス → ネットワーク → 可視化」の順に段階的に整備するのが現実的です。

1. IDを中心に据える（Identity is the new perimeter）

ゼロトラストの出発点はIDの厳格な管理です。「誰が」「何に」「どんな権限で」アクセスするかを一元管理できていないと、他の施策が効果を発揮しません。

・AWS IAM Identity Center（旧AWS SSO）: マルチアカウント環境でシングルサインオンを実現し、各AWSサービスへの権限を一元管理します。外部IdP（Okta・Azure ADなど）とのSAML連携も可能です。
・Microsoft Entra ID（旧Azure AD）: 条件付きアクセス（Conditional Access）ポリシーで「場所・デバイス状態・リスクスコア」を組み合わせてアクセス許可を動的に制御します。MFAの強制も条件付きアクセスで設定します。
・多要素認証（MFA）の強制: どちらのクラウドでも、ルートアカウント・管理者ロールへのMFAは即日設定必須です。AWSではIAMポリシーでMFA未設定ユーザーの操作を制限できます。

# AWS CLI: MFA未設定のIAMユーザーを検出する（実行環境: AWS CLI v2）
aws iam generate-credential-report
aws iam get-credential-report --query 'Content' --output text | base64 -d | \
  awk -F',' 'NR>1 && $4=="true" && $8=="false" {print $1, "MFAなし"}'

# 上記コマンドでパスワードが有効（$4=true）かつMFA未設定（$8=false）のユーザーを抽出できる

2. デバイスの信頼を確立する

IDが正しくても、マルウェア感染したデバイスからのアクセスは拒否すべきです。デバイスの健全性をアクセス条件に組み込む仕組みが必要です。

・Microsoft Intune（Entra ID連携）: 管理対象デバイスの準拠状態（コンプライアンスポリシー）をEntra IDの条件付きアクセスに連携させ、「Intune登録済み＆準拠しているデバイスのみ許可」という制御を実現します。
・AWS Verified Access: VPNなしにAWS上のWebアプリにアクセス制御を適用するサービスです。Cedar言語のポリシーでユーザーID・デバイス状態・リクエスト属性を組み合わせてアクセス許可を動的に判断します（2026年6月時点）。
・エンドポイントセキュリティ（EDR）: Defender for EndpointやCrowdStrikeのリスクスコアをIdPに連携させ、EDRが「リスク高」と判定したデバイスのアクセスをリアルタイムでブロックします。

3. マイクロセグメンテーションでネットワークを細分化する

仮にIDとデバイスを突破された場合に備え、ネットワーク内の横移動を防ぐのがマイクロセグメンテーションです。「ワークロード間は原則拒否、必要なものだけ許可」という発想で設計します。

・AWSセキュリティグループ: EC2・RDS・Lambdaなどのリソース単位でインバウンド／アウトバウンドルールを設定します。「同一VPC内の全通信を許可」ではなく、「WebサーバーからDBポート3306への通信のみ許可」と絞り込みます。
・AWS Network Firewall: VPC間のトラフィックにステートフルな検査ルールを適用できます。Transit Gateway経由のマルチVPC環境でも一元的にポリシーを管理できます。
・Azure NSG（ネットワークセキュリティグループ）+ Azure Firewall: サブネット単位のNSGに加えて、Azure FirewallをハブVNetに配置してスポークVNet間の通信を強制検査する構成が標準的なマイクロセグメンテーション設計です。

# AWS CLI: セキュリティグループで「0.0.0.0/0からのインバウンド」を許可しているルールを検出
aws ec2 describe-security-groups \
  --query 'SecurityGroups[?IpPermissions[?IpRanges[?CidrIp==`0.0.0.0/0`]]].[GroupId,GroupName]' \
  --output table

# ゼロトラスト設計では、このリストを0件にすることを目指す

4. ログの一元収集と継続的な可視化

ゼロトラストの最後の柱は「継続的な監視」です。すべてのアクセスを記録し、異常を検知する仕組みがないと、ポリシーが機能しているかどうか確認できません。

・AWS CloudTrail + Amazon GuardDuty: CloudTrailで全APIコールを記録し、GuardDutyが機械学習で異常な振る舞い（通常と異なるリージョンからのアクセス・クレデンシャルの不正利用など）を自動検知します。
・Microsoft Sentinel: AzureネイティブのSIEM/SOARです。Entra IDのサインインログ・Azure Monitorのリソースログ・Defender製品のアラートを一元収集し、KQLで横断的な脅威ハンティングが可能です。
・AWS Security Hub: AWS WAF・Inspector・Macie・GuardDutyなど複数のセキュリティサービスのアラートを集約し、ASFF（Amazon Security Finding Format）で標準化して管理します。

AWSとAzureのゼロトラスト関連サービス対応表

実務でよくあるつまずきポイントと対処法

【落とし穴1】「ゼロトラスト製品を入れれば完成」という誤解

ゼロトラストは設計思想であり、単一製品を導入すれば達成されるものではありません。SASE製品（Zscaler・Netskope・Prisma Accessなど）を導入しても、IDの棚卸しやログの収集体制ができていなければ効果は半減します。「何を守りたいのか」「誰がアクセスすべきか」の整理から始めてください。

【落とし穴2】IDの棚卸しを後回しにする

ゼロトラスト移行でもっとも時間がかかる作業が「IDの棚卸し」です。退職者のアカウントが残っていたり、共有アカウントが乱立していたりするケースは珍しくありません。まずAWS IAMの認証情報レポートやEntra IDのユーザーリストを出力し、現状把握から着手するのが正解です。

【落とし穴3】MFAを管理者だけに適用して一般ユーザーを見落とす

権限が低い一般ユーザーのアカウントでも、フィッシングで奪取されラテラルムーブメントの起点になり得ます。MFAは全ユーザーへの適用が原則です。AWSではサービスコントロールポリシー（SCP）でMFA未設定ユーザーのAPI操作を組織全体でブロックする方法が有効です。

【落とし穴4】ログはあるが見ていない

CloudTrailやAzure Monitorを有効にしただけで満足してしまい、定期的なレビューや異常検知の仕組みが整っていないケースが多々あります。GuardDutyやSentinelのアラートをSlackやメールに通知し、対応フロー（誰が何分以内に確認するか）まで決めて初めて「監視している」と言えます。

【落とし穴5】クラウドへの移行と同時にゼロトラストを完全実装しようとする

クラウド移行とゼロトラスト化を同時に進めると工数が爆発します。移行フェーズでは「最小限のIAM権限とMFA適用」に絞り、安定稼働後にデバイス信頼やマイクロセグメンテーションを段階的に強化するほうが現実的です。

本記事のまとめ

ゼロトラストの要点を整理します。

・前提の転換: 「社内ネットワーク＝安全」をやめ、「すべてのアクセスを検証する」へ発想を変える。
・ID管理が最優先: AWS IAM Identity Center・Microsoft Entra IDでID棚卸しとMFA強制が出発点。
・段階的に実装: ID → デバイス → マイクロセグメンテーション → ログ可視化の順に整備する。
・継続的な監視: GuardDuty・Sentinelでログを自動分析し、アラートの対応フローを整えて完成。
・製品導入より設計思想: SASE・EDRを入れても、IDの棚卸しや運用フローがなければ意味がない。

オンプレの境界防御が「城壁」だとすれば、ゼロトラストは「すべての扉に錠前と顔認証を付ける」イメージです。クラウド移行のタイミングは、セキュリティ設計を根本から見直す絶好の機会でもあります。まずIDの棚卸しとMFA適用から始めて、着実にゼロトラストへ移行していきましょう。

クラウドのセキュリティ設計で参照すべき責任共有モデルについては、当サイトのクラウドセキュリティの責任共有モデルとは？もあわせてお読みください。Linuxサーバー上でのセキュリティ強化については、姉妹サイトLinuxMaster.JPで詳しく解説しています。