Azureセキュリティ設計チェックリスト｜設計・運用の抜け漏れを防ぐ実践ガイド

「セキュリティ設定、一通りやってあります」——では、何をどこまでやったか、今すぐ説明できますか？

「やった気」と「確認済み」は全く別物です。MFAを設定したつもりが管理者アカウントだけ漏れていた・NSGを設定したつもりがRDPが開いたままだった・ログを有効にしたつもりが保存期間がデフォルトのままだった——こうした「つもり」の積み重ねがセキュリティの穴になります。

このチェックリストはAzure環境のセキュリティ設計・運用を体系的に確認するためのものです。新規環境の構築時・定期レビュー時・インシデント発生後の見直し時に活用してください。

クラウドセキュリティの全体像については「クラウドセキュリティとは？責任共有モデルから始める設計の全体像」を先にご覧ください。

チェックリストが必要な理由——「やった気」を「確認済み」に変える

クラウド環境のセキュリティ設定は、オンプレミスと異なり設定が可視化されにくいという特徴があります。物理的に見て確認できるわけではなく、ポータルの設定画面を一つひとつ確認する必要があります。

担当者が変わるたびに「前任者が設定した内容を誰も把握していない」状態になるリスクがあります。チェックリストを定期的に使うことで、環境の現状を客観的に把握し、抜け漏れを発見できます。

Defender for Cloudのセキュリティスコアも有効な確認手段ですが、Defender for Cloudでカバーされない設計上の問題（権限設計・運用ルール・インシデント対応準備など）はチェックリストでしか確認できません。Defender for Cloudの活用については「Azure Defender for Cloudとは？」を参照してください。

このチェックリストの使い方

このチェックリストは5つの領域で構成されています。

各項目は以下の優先度で分類しています。

• 🔴 高：未対応の場合、直接的な侵害リスクがある項目
• 🟡 中：未対応の場合、侵害時の被害が拡大するリスクがある項目
• 🟢 低：ベストプラクティスとして推奨される項目

【ID・アクセス管理】チェックリスト

IDとアクセス管理はすべてのセキュリティ設計の起点です。最小権限の設計については「最小権限の原則とは？実務での考え方と設計例」を、RBACの設計については「RBACとは？クラウド権限管理の基本とAzure RBACの仕組みをわかりやすく解説」を参照してください。

アカウント管理

• 🔴 [ ] グローバル管理者アカウントにMFAを設定している
• 🔴 [ ] すべての管理者ロールを持つアカウントにMFAを設定している
• 🔴 [ ] 退職・異動したユーザーのアカウントを無効化・削除している
• 🟡 [ ] 一般ユーザーにもMFAを設定している（または計画している）
• 🟡 [ ] サービスアカウント・アプリ登録の権限を最小限にしている
• 🟢 [ ] アカウントの定期棚卸し（月次または四半期）をスケジュール化している

権限設計

• 🔴 [ ] グローバル管理者のメンバーを5名以下に絞っている
• 🔴 [ ] 日常業務にグローバル管理者アカウントを使用していない
• 🟡 [ ] ロールは最小権限の原則に基づいて付与している（組み込みロールの適切な選択）
• 🟡 [ ] PIMでJITアクセスを実装している（または計画している）
• 🟡 [ ] ゲストユーザーのアクセス権を制限している
• 🟢 [ ] 権限付与の申請・承認フローを定めている

MFAの実装については「MFAとは？多要素認証の仕組みと実務での導入・運用ガイド」を、PIMについては「PIMとは？Azure特権アクセス管理の実務ガイド」を参照してください。

条件付きアクセス

• 🔴 [ ] 管理者ロールへのMFA強制ポリシーを設定している
• 🟡 [ ] リスクの高いサインインのブロックポリシーを設定している
• 🟡 [ ] 未管理デバイスからのアクセス制限ポリシーを設定している
• 🟢 [ ] 国・地域ベースのアクセス制限を設定している
• 🟢 [ ] 条件付きアクセスポリシーを定期的にレビューしている

ゼロトラストと条件付きアクセスの設計については「ゼロトラストとは？Azureでの実装パターン」を参照してください。

参考：条件付きアクセスとは | Microsoft Learn

【ネットワークセキュリティ】チェックリスト

ネットワーク設計の詳細については「Azureネットワークセキュリティ設計入門｜VNet・NSG・ファイアウォールの考え方」を参照してください。

VNet・サブネット設計

• 🟡 [ ] リソースをVNet内のサブネットに配置している
• 🟡 [ ] 役割ごとにサブネットを分割している（フロントエンド・バックエンド・データ・管理）
• 🟡 [ ] 開発環境と本番環境のVNetを分離している
• 🟢 [ ] VNetのIPアドレス範囲を設計段階で計画している

NSG設定

• 🔴 [ ] RDP（3389）・SSH（22）をインターネットに直接公開していない
• 🔴 [ ] 「送信元Any・ポートAny・Allow」の過剰な許可ルールがない
• 🟡 [ ] すべてのサブネットにNSGを関連付けている
• 🟡 [ ] アウトバウンドルールで不要なインターネット通信を制限している
• 🟢 [ ] NSGフローログを有効にして通信を記録している
• 🟢 [ ] NSGルールを定期的にレビューして不要なルールを削除している

管理アクセス

• 🔴 [ ] 管理アクセスはAzure Bastion・JITアクセス・VPNのいずれかで実現している
• 🟡 [ ] 踏み台サーバを使う場合、接続元IPを特定のアドレスに限定している
• 🟢 [ ] 管理操作のログを記録・監視している

【データ保護】チェックリスト

ストレージ・公開設定

• 🔴 [ ] ストレージアカウントへのパブリックアクセスを無効にしている
• 🔴 [ ] 意図せず公開されているBlobコンテナ・ファイル共有がないか確認した
• 🟡 [ ] 機密データを含むストレージに適切なアクセス制御を設定している
• 🟡 [ ] SASトークン（共有アクセス署名）の有効期限を適切に設定している
• 🟢 [ ] ストレージアカウントの定期監査をスケジュール化している

SASトークン（Shared Access Signature：共有アクセス署名） Azureストレージリソースへの制限付きアクセスを付与するトークン。有効期限・許可する操作・対象リソースを指定できる。期限切れ管理を怠ると不要なアクセスが継続するリスクがある。

暗号化

• 🟡 [ ] Azure Disk Encryptionを重要なVMに有効にしている
• 🟡 [ ] データベースのTransparent Data Encryption（TDE）が有効になっている
• 🟡 [ ] 転送中のデータにHTTPS・TLSを使用している
• 🟢 [ ] 重要な暗号化キーをAzure Key Vaultで管理している

Azure Key Vault 暗号化キー・シークレット・証明書を安全に保管・管理するAzureのマネージドサービス。アプリケーションのコードや設定ファイルに機密情報を直接書くことを避けるために使用する。

バックアップ

• 🔴 [ ] 重要なデータ・VMのバックアップを設定している
• 🔴 [ ] バックアップから実際に復元できるか定期的に検証している
• 🟡 [ ] バックアップの保存期間を要件に応じて設定している
• 🟡 [ ] バックアップデータへのアクセス権を最小限にしている

参考：Azure のデータ セキュリティと暗号化のベスト プラクティス | Microsoft Learn

【監視・ログ】チェックリスト

監視設計の詳細については「Azure Defender for Cloudとは？」、M365の監査ログについては「M365 Purview入門｜監査ログの取り方とインシデント調査への活用」を参照してください。

Defender for Cloud

• 🔴 [ ] Defender for Cloudを有効にしてセキュリティスコアを確認している
• 🔴 [ ] 深刻度「高」の推奨事項を対応済みにしている
• 🟡 [ ] 深刻度「中」の推奨事項を計画的に対応している
• 🟢 [ ] セキュリティスコアの定期確認（週次または月次）をスケジュール化している

監査ログ・アクティビティログ

• 🔴 [ ] Entra IDの監査ログを有効にしている
• 🟡 [ ] Azureアクティビティログを有効にして保存期間を設定している
• 🟡 [ ] 重要なリソースの診断ログを有効にしている
• 🟡 [ ] ログをLog Analytics Workspaceに集約している
• 🟢 [ ] ログの保存期間を要件に応じて設定している（最低90日以上推奨）

Log Analytics Workspace Azureの各リソースから収集したログを一元的に保存・クエリ・分析するサービス。Defender for CloodやAzure Monitorと連携して異常検知・アラート設定に活用する。

アラート設定

• 🔴 [ ] グローバル管理者へのロール付与をアラート対象にしている
• 🟡 [ ] 異常なサインイン（国外・深夜等）をアラート対象にしている
• 🟡 [ ] リソースの削除操作をアラート対象にしている
• 🟢 [ ] アラートの通知先（担当者・チャンネル）を設定している

【インシデント対応準備】チェックリスト

インシデント対応の全体フローについては「セキュリティインシデント対応入門」を参照してください。

対応準備

• 🔴 [ ] インシデント発生時の連絡・報告フローを定めている
• 🔴 [ ] 対応の役割分担（指揮・技術対応・対外連絡）を決めている
• 🟡 [ ] インシデント対応手順書を作成・最新化している
• 🟡 [ ] Break Glassアカウントを設置し、使用時のアラートを設定している
• 🟢 [ ] 定期的な対応訓練・シナリオ演習を実施している

復旧準備

• 🟡 [ ] 重要システムの復旧手順を文書化している
• 🟡 [ ] バックアップからの復旧時間（RTO）を把握している
• 🟡 [ ] 許容できるデータ損失範囲（RPO）を定義している
• 🟢 [ ] 復旧手順を定期的にテストしている

RTO（Recovery Time Objective：目標復旧時間） インシデント発生からサービスが復旧するまでの許容時間。バックアップ設計・復旧手順の整備においてRTOを基準に設計する。

RPO（Recovery Point Objective：目標復旧時点） インシデント発生時に許容できる最大のデータ損失量を時間で表したもの。バックアップの頻度設計の基準になる。

優先度別——まず今日やるべきこと

すべてを一度に対応するのは現実的ではありません。優先度「高（🔴）」の項目から着手し、段階的に対応していくことを推奨します。

今すぐ対応（深刻度：高）

直接的な侵害リスクがある項目です。未対応であれば今日中に確認・対応してください。

1. グローバル管理者へのMFA設定 → Entra ID管理センター → ユーザー → 多要素認証
2. RDP/SSHのインターネット公開確認 → Defender for Cloud → 推奨事項で確認
3. ストレージのパブリックアクセス確認 → ストレージアカウント → 構成 → パブリックアクセス
4. バックアップの設定確認 → Azure Backup → バックアップジョブ
5. Defender for Cloudのセキュリティスコア確認 → Defender for Cloud → 概要

今週中に対応（深刻度：中）

侵害時の被害拡大を防ぐ項目です。1週間以内に計画・着手してください。

1. 条件付きアクセスポリシーの設定（リスクサインインのブロック）
2. NSGルールの全体レビュー（過剰な許可ルールの削除）
3. サブネット分割の見直し（役割ごとの分離）
4. 監査ログの有効化と保存期間の設定
5. 不要なアカウント・権限の棚卸し

今月中に対応（深刻度：低）

ベストプラクティスとして推奨される項目です。今月中に計画を立てて進めてください。

1. PIMの導入検討
2. Azure Key Vaultへのシークレット移行
3. インシデント対応手順書の作成
4. 定期レビュースケジュールの設定
5. NSGフローログの有効化

まとめ——チェックリストは「一度やって終わり」ではない

セキュリティ設計は「設定して完了」ではありません。環境は変化し続け、新しいリソースが追加され、メンバーが入れ替わります。チェックリストを定期的に使い続けることで、その変化に対応できます。

推奨する運用サイクルは以下の通りです。

今日確認すべきことは1つです。Defender for Cloudを開き、深刻度「高」の推奨事項が何件あるかを確認してください。そこから優先順位をつけて対応を始めることがAzureセキュリティ改善の最初の一歩です。

あわせてご覧ください

• クラウドセキュリティとは？責任共有モデルから始める設計の全体像
• Azure Defender for Cloudとは？セキュリティスコアと推奨事項で守れる環境を作る
• Azureネットワークセキュリティ設計入門｜VNet・NSG・ファイアウォールの考え方
• ゼロトラストとは？Azureでの実装パターン
• 最小権限の原則とは？実務での考え方と設計例
• MFAとは？多要素認証の仕組みと実務での導入・運用ガイド
• PIMとは？Azure特権アクセス管理の実務ガイド
• セキュリティインシデント対応入門｜若手エンジニアが最初に知っておくべき対応フローと考え方