Azure セキュリティで最初に押さえるべき結論は、「Azureを使えば自動的に安全になる」のではなく、Microsoftが守るクラウド基盤と、利用者側が守るデータ・ID・設定・アプリケーションを分けて考えることです。Microsoft Learnの「Introduction to Azure security」は、Azureの多層防御、ID管理、ネットワーク保護、暗号化、監視、脅威検出を横断的に整理した公式ガイドであり、管理者は特に Azure Disk Encryptionの廃止対応、Microsoft Entra IDのアクセス制御、Defender for Cloudによる可視化、ネットワーク公開範囲の見直し を優先して確認する必要があります。(Microsoft Learn)
2026年5月16日時点で確認できる公式情報では、Azureセキュリティの考え方は単一の製品導入ではなく、ID・ネットワーク・データ・ワークロード・運用監視を組み合わせる「多層防御」が中心です。特に既存VMを運用している環境では、Azure Disk Encryptionが2028年9月15日に廃止予定であり、対象VMは期限前に encryption at host などへ移行計画を立てる必要があります。(Microsoft Learn)
Azure セキュリティ更新で押さえるべき全体像
今回の「Introduction to Azure security」は、Azure環境を守るための機能を個別サービスの説明としてではなく、クラウド運用全体の設計要素として整理しています。中心となる考え方は、物理データセンターからID、ネットワーク、アプリケーション、データ、監視まで複数の防御層を重ねることです。1つの設定が突破されても、別の層で被害を抑える構成を目指します。(Microsoft Learn)
管理者が読み取るべきポイントは、次の3つです。
| 確認ポイント | 実務上の意味 | 優先して対応すべき人 |
|---|---|---|
| 共有責任モデル | Microsoftが守る範囲と自社が守る範囲を明確にする | 情シス、クラウド管理者、セキュリティ担当 |
| 多層防御 | ID、ネットワーク、データ、監視を組み合わせて守る | Azure管理者、インフラ担当、開発リーダー |
| 既存構成の見直し | ADE廃止、RBAC、PIM、WAF、Private Link、Defender for Cloudなどを確認する | 運用担当、アプリ担当、SOC担当 |
特に重要なのは、Azureの標準機能だけに任せないことです。AzureにはDDoS対策、既定の暗号化、Microsoft Entra IDによる認証、脅威検出などの基盤的な保護がありますが、業務データの分類、アクセス権、アプリケーションの設定、監視ルールは利用者側の設計に大きく依存します。(Microsoft Learn)
共有責任モデルを誤解するとAzureのセキュリティ事故が起きやすい
Azure セキュリティで最も誤解されやすいのが、共有責任モデルです。オンプレミスではサーバー、ネットワーク、OS、アプリ、データまですべて自社が管理します。一方、Azureでは利用するサービス形態によってMicrosoftと利用者の責任範囲が変わります。(Microsoft Learn)
たとえば、Azure Virtual MachinesのようなIaaSでは、物理基盤はMicrosoftが管理しますが、OSのパッチ、VM上のアプリケーション、アカウント、アクセス制御、データ保護は利用者側の責任です。Azure App ServiceやAzure SQL DatabaseのようなPaaSではOS管理の負担は下がりますが、アプリケーション設定、コードの安全性、アクセス制御は引き続き利用者が確認する必要があります。(Microsoft Learn)
サービス形態別に見る管理者の確認範囲
| 利用形態 | Microsoftが主に管理する範囲 | 利用者が特に確認すべき範囲 |
|---|---|---|
| IaaS | 物理データセンター、物理ホスト、基盤ネットワーク、仮想化基盤 | OSパッチ、VM設定、NSG、暗号化、バックアップ、アプリ、ID |
| PaaS | OS、ランタイム、基盤運用の多く | アプリ設定、接続元制限、認証、データ保護、ログ、コード品質 |
| SaaS | アプリ基盤、OS、ネットワークの多く | ユーザー管理、条件付きアクセス、データ分類、共有設定、端末管理 |
実務では「PaaSだから安全」ではなく、「PaaSにしたことで自社が管理しなくてよくなる層」と「引き続き自社が管理すべき層」を分けて棚卸しすることが重要です。たとえばApp Serviceを使っていても、認証を無効のまま公開している、アプリ設定にシークレットを直接保存している、ログを収集していない、といった状態ではリスクが残ります。
管理者が優先確認すべき変更点と影響範囲
今回の公式情報から実務上特に確認したいのは、Azure セキュリティの「基本方針」だけでなく、既存環境に影響しやすい運用項目です。なかでもAzure Disk Encryptionの廃止予定は、VMを長期運用している組織にとって移行計画が必要な項目です。
| 領域 | 確認すべき内容 | 影響範囲 | 対応の優先度 |
|---|---|---|---|
| VM暗号化 | Azure Disk Encryptionが2028年9月15日に廃止予定 | ADE有効のWindows/Linux VM、バックアップ、復旧手順 | 高 |
| VM起動保護 | 新規作成のGeneration 2 VM/VMSSではTrusted launchが既定 | 新規VM、VMSS、IaCテンプレート | 高 |
| ID管理 | MFA、条件付きアクセス、PIM、RBACの見直し | 全ユーザー、管理者、サービスプリンシパル | 高 |
| ネットワーク | NSG、Azure Firewall、DDoS Protection、Private Link、VNet Manager | 公開エンドポイント、サブネット、拠点接続 | 高 |
| セキュリティ運用 | Defender for Cloud、Microsoft Sentinel、Azure Monitorの統合運用 | SOC、監査、インシデント対応 | 中〜高 |
| アプリ保護 | WAF、App Service認証、Managed Identity、Key Vault | Webアプリ、API、CI/CD | 中〜高 |
| ストレージ | RBAC、SAS、保存時・転送時の暗号化、CORS | Storage Account、Blob、File share | 中 |
Azure Disk Encryption廃止に向けた移行確認
Azure Disk Encryptionは2028年9月15日に廃止予定です。公式情報では、廃止日まではADEを継続利用できるものの、廃止後はADE有効ワークロードでVM再起動時に暗号化ディスクがアンロックできず、サービス停止につながる可能性があると説明されています。新規VMではencryption at hostの利用が推奨され、ADE有効VMは期限前に移行が必要です。(Microsoft Learn)
ADE移行で失敗しやすいポイント
ADEからencryption at hostへの移行は、単純な設定変更ではありません。公式の移行ガイドでは、インプレース変換はサポートされず、新しいディスクやVMの作成が必要とされています。また、LinuxのADE暗号化済みOSディスクはインプレースで無効化できないため、新しいVMを作成してデータや設定を移行する計画が必要です。(Microsoft Learn)
| 注意点 | なぜ重要か | 対応例 |
|---|---|---|
| インプレース変換できない | 既存VMをそのまま切り替える前提だと作業計画が破綻する | 新規ディスク・新規VM作成を前提に手順化する |
| ダウンタイムが必要 | ディスク操作やVM再作成で停止時間が発生する | 業務影響の少ない時間帯に移行枠を確保する |
| Linux OSディスクは特に注意 | ADE無効化の制約があり、別VMへの移行が必要になる場合がある | 事前にOS種別と暗号化対象を棚卸しする |
| ドメイン参加VMは追加作業が必要 | VM再作成後にドメイン再参加やDNS整理が必要 | OU、GPO、証明書、コンピューターアカウントを記録する |
| バックアップも対象になる | 本番VMだけ移行しても復旧時に古い暗号化方式が残る可能性がある | バックアップ、復旧手順、DR構成も確認する |
ADE対象VMを棚卸しする手順
最初にやるべきことは、移行作業ではなく対象の把握です。サブスクリプション単位でADE拡張機能が残っているVMを洗い出し、業務重要度、OS、ディスク構成、バックアップ有無、停止可能時間を整理します。
Azure Resource Graphを使う場合は、次のような考え方でVM拡張機能を確認します。
Resources
| where type =~ 'microsoft.compute/virtualmachines/extensions'
| where name in~ ('AzureDiskEncryption', 'AzureDiskEncryptionForLinux')
| project subscriptionId, resourceGroup, vmId=substring(id, 0, indexof(id, '/extensions')), extensionName=name移行後は、encryption at hostが有効かを確認します。公式ガイドでも、VMの securityProfile.encryptionAtHost を確認する方法が示されています。(Microsoft Learn)
az vm show \
--resource-group <resource-group> \
--name <vm-name> \
--query "securityProfile.encryptionAtHost"結果が true であれば、対象VMでencryption at hostが有効です。ただし、実務ではこの確認だけで完了にしないでください。アプリケーションがディスクを正しく参照できるか、バックアップから復元できるか、監視アラートが新VMにも紐づいているかまで確認する必要があります。
IDとアクセス管理はAzureセキュリティの最優先領域
クラウドでは、ネットワーク境界よりもIDが実質的なセキュリティ境界になります。Microsoft Learnでも、IDはクラウドコンピューティングにおける主要なセキュリティ境界であり、Microsoft Entra IDが認証、認可、MFA、条件付きアクセス、Identity Protection、PIM、Identity Governanceなどを提供すると整理されています。(Microsoft Learn)
管理者が確認すべき設定は、次の順番で進めると効率的です。
| 優先順位 | 確認項目 | 判断基準 |
|---|---|---|
| 1 | グローバル管理者の人数 | 常時権限を持つ人数を最小化し、日常作業用アカウントと分離する |
| 2 | MFA | 管理者、外部公開アプリ利用者、リスクの高いユーザーから必ず適用する |
| 3 | 条件付きアクセス | 場所、端末状態、リスク、アプリごとにアクセス条件を設計する |
| 4 | PIM | 特権ロールを常時付与せず、承認・時間制限付きで有効化する |
| 5 | RBAC | サブスクリプション全体のOwner付与を避け、リソースグループや役割単位に絞る |
| 6 | Managed Identity | アプリやVMにシークレットを埋め込まず、AzureリソースのIDで認証する |
よくある失敗は、開発・検証の便宜でOwner権限を広く付けたまま本番運用に移ることです。権限が広すぎると、認証情報の漏えいや誤操作が起きた際に、影響範囲がサブスクリプション全体へ広がります。RBACは「作業できるか」ではなく「その作業に必要な最小権限か」で判断してください。
ネットワーク保護は公開範囲の最小化から始める
Azureのネットワークセキュリティでは、NSG、Azure Firewall、DDoS Protection、User-Defined Routes、Private Link、Application Gateway、Azure Front Doorなど複数の選択肢があります。重要なのは、すべてを導入することではなく、通信経路ごとに「誰が、どこから、何へアクセスできるか」を明確にすることです。(Microsoft Learn)
ネットワーク設計で確認すべき実務ポイント
| 対象 | 確認内容 | よくあるリスク |
|---|---|---|
| NSG | 送受信ルール、優先度、Any許可、管理ポート公開 | RDP/SSHを広いIP範囲に公開している |
| Azure Firewall | 東西トラフィック、南北トラフィック、脅威インテリジェンス設定 | 拠点間通信やインターネット向け通信が可視化されていない |
| DDoS Protection | 公開IPを持つ重要システムの保護 | Web公開しているがDDoS対策の責任分界が曖昧 |
| Private Link | Storage、SQL DatabaseなどPaaSへの私設接続 | PaaSがパブリックエンドポイント経由で利用されている |
| VNet Manager | 複数VNetへの共通ルール適用 | 各チームのNSG設定がばらついている |
| WAF | OWASP Top 10相当の攻撃対策 | Webアプリごとに防御ルールが分散し、更新漏れが起きる |
Azure Virtual Network Managerのセキュリティ管理ルールは、NSGルールよりも優先して適用されます。全社共通で禁止したい高リスクポートや、必ず許可したい監視・管理通信がある場合は、個別NSGだけに頼るよりも中央管理の設計が向いています。(Microsoft Learn)
一方で、中央管理ルールを強くしすぎると、アプリチームが必要な通信を開けられず、障害対応時に原因調査が難しくなります。展開前に「共通で拒否する通信」「例外申請で許可する通信」「各チームに委任する通信」を分けておくことが重要です。
アプリケーション開発者が確認すべきAzureセキュリティ設定
Azure セキュリティは管理者だけの仕事ではありません。アプリケーション開発者は、認証、秘密情報、ログ、入力値、公開経路の設計に責任を持つ必要があります。
Microsoft Learnでは、App Service Authentication / Authorizationにより、バックエンドコードを大きく変更せずにサインイン機能を追加できること、Application GatewayのWAFがSQLインジェクションやクロスサイトスクリプティングなどの一般的なWeb攻撃からアプリを保護することが説明されています。(Microsoft Learn)
開発・展開時のチェックリスト
| チェック項目 | 推奨される対応 |
|---|---|
| アプリに認証が必要か | App Service認証、Microsoft Entra ID、外部ID連携を検討する |
| シークレットをどこに置くか | ソースコードや環境変数に直書きせず、Key VaultとManaged Identityを使う |
| APIを公開する必要があるか | Private Link、IP制限、WAF、認証必須化を組み合わせる |
| ログを収集しているか | Application Insights、Azure Monitor、Resource Logsを有効化する |
| IaCで同じ設定を再現できるか | ARM/Bicep/Terraformなどにセキュリティ設定を含める |
| 本番と検証で設定差分がないか | 手動変更を減らし、テンプレートとAzure Policyで管理する |
特に注意したいのは、開発中に一時的に入れた設定が本番へ残るケースです。たとえば「検証のためにCORSを広く許可した」「一時的にStorage Accountのパブリックアクセスを許可した」「デバッグ用の詳細ログに個人情報が含まれる」といった設定は、リリース前レビューで必ず確認してください。
ストレージとデータ保護ではRBAC、SAS、暗号化を分けて考える
Azure Storageでは、Azure RBACによるアクセス制御、SASによる期限付き委任アクセス、転送時の暗号化、保存時の暗号化、ログ分析などが重要です。SASはアカウントキーを共有せずに、特定のリソースへ期間限定・権限制限付きのアクセスを付与できる仕組みですが、発行範囲や有効期限が広すぎると漏えい時の影響が大きくなります。(Microsoft Learn)
データ保護の判断基準
| 領域 | 基本方針 | 実務での確認例 |
|---|---|---|
| アクセス制御 | RBACで最小権限を付与する | Storage Account Contributorを安易に広く付けない |
| 一時アクセス | SASは短い有効期限と必要最小権限にする | 読み取りだけでよい処理に書き込み権限を付けない |
| 転送時暗号化 | HTTPSやSMB 3.0暗号化を利用する | 古いクライアントや平文通信を許可していないか確認する |
| 保存時暗号化 | 既定の暗号化に加え、必要に応じてカスタマー管理キーを検討する | 規制対象データではKey Vault連携を確認する |
| ログ | 成功・失敗・SAS利用などを追跡する | 不審なアクセスや大量ダウンロードを検知できる状態にする |
データ保護で重要なのは、暗号化だけで満足しないことです。暗号化されていても、過剰な権限を持つアカウントや長期間有効なSASが漏えいすれば、データは読み取られます。暗号化、アクセス制御、ログ監視をセットで確認してください。
Defender for CloudとMicrosoft Sentinelで運用を可視化する
セキュリティ設定は、導入して終わりではありません。Azure環境ではリソース追加、権限変更、ネットワーク変更、アプリ更新が継続的に発生するため、構成のずれを検知する仕組みが必要です。
Microsoft Defender for Cloudは、クラウドネイティブアプリケーション保護プラットフォームとして、CSPM、DevSecOps、CWPPを組み合わせ、クラウド、オンプレミス、マルチクラウド環境のセキュリティ態勢を可視化します。また、Defenderポータルへの展開が進んでおり、クラウドとコード環境を横断した統合セキュリティ体験を提供する方向へ拡張されています。(Microsoft Learn)
Microsoft Sentinelは、SIEM/SOARとして脅威検出、可視化、ハンティング、対応を支援します。公式情報では、Microsoft SentinelがDefenderポータルで利用可能になり、Security Copilotとの連携により自然言語での調査やハンティングクエリ生成、調査自動化に活用できることも説明されています。(Microsoft Learn)
運用担当者が確認すべき設定
| 設定 | 確認ポイント |
|---|---|
| Defender for Cloud | サブスクリプションごとの有効化状況、推奨事項、セキュリティスコア |
| Defenderプラン | Servers、Containers、Storage、Databasesなど対象ワークロードに合うプラン |
| Azure Monitor | Activity Log、Resource Logs、アラート、通知先 |
| Microsoft Sentinel | データコネクタ、分析ルール、インシデント分類、対応プレイブック |
| Azure Advisor | セキュリティ、信頼性、コスト最適化の推奨事項 |
| MCSB | Microsoft cloud security benchmarkに沿った統制とAzure Policyの適用 |
注意点は、Defender for CloudやSentinelを有効化しても、通知先、担当者、初動手順が決まっていなければ運用に乗らないことです。アラートは「出す」だけでなく、「誰が、何分以内に、どの基準で判断し、どこに記録するか」まで決めてください。
Microsoft cloud security benchmarkを基準に設定のばらつきを減らす
Azure環境が大きくなるほど、チームごとの設定差分がセキュリティリスクになります。Microsoft cloud security benchmarkは、Azureやマルチクラウド環境のワークロード、データ、サービスのセキュリティ向上に向けた推奨事項を提供する基準です。公式情報では、Azure Policyなどを使って安全な構成を自動化・強制するガードレールとして活用できることが示されています。(Microsoft Learn)
実務では、次のように使うと効果的です。
| 活用シーン | 具体例 |
|---|---|
| 新規環境の標準化 | サブスクリプション作成時に、診断ログ、暗号化、タグ、ポリシーを標準適用する |
| 既存環境の改善 | Defender for Cloudの推奨事項と照らして、リスクの高い設定から修正する |
| 監査対応 | RBAC、ログ、暗号化、ネットワーク制御の証跡を継続的に確認する |
| 開発チームの自律運用 | 禁止事項だけでなく、許可される安全な構成パターンをテンプレート化する |
セキュリティ基準は、厳しくしすぎると現場で回避策が生まれます。たとえば、すべての通信を一律拒否するのではなく、標準テンプレート、例外申請、期限付き許可、レビュー期限をセットにして運用すると、開発速度と安全性を両立しやすくなります。
展開・移行前に確認したい実務チェックリスト
Azure セキュリティを見直す際は、いきなり個別機能を有効化するのではなく、影響範囲を洗い出してから段階的に展開してください。
| フェーズ | やること | 成果物 |
|---|---|---|
| 棚卸し | サブスクリプション、VM、PaaS、Storage、公開IP、管理者権限を確認 | 資産一覧、権限一覧、公開範囲一覧 |
| リスク分類 | インターネット公開、特権ID、重要データ、ADE利用VMを優先度付け | 対応優先順位 |
| 設計 | RBAC、PIM、条件付きアクセス、NSG、Private Link、ログ収集を設計 | セキュリティ設計書 |
| 検証 | 検証環境でポリシー、暗号化、監視、移行手順をテスト | 検証結果、ロールバック手順 |
| 展開 | IaCやAzure Policyで標準化し、本番へ段階適用 | 適用済みテンプレート、変更記録 |
| 運用 | Defender for Cloud、Sentinel、Azure Monitorで継続監視 | アラート運用手順、月次レビュー |
展開時にありがちな失敗は、セキュリティ強化を一括適用して業務通信を止めてしまうことです。特にNSG、Firewall、条件付きアクセス、Private Endpoint、CORS、WAFルールは影響が大きいため、検出モードや限定範囲で試し、ログを確認してから本番へ広げるのが安全です。
よくある質問
Azureの標準セキュリティだけで十分ですか？
十分とは言い切れません。Azureには基盤的な保護機能がありますが、データ、ID、アクセス管理、アプリケーション設定、監視、コンプライアンス対応は利用者側の設計と運用に依存します。共有責任モデルを前提に、自社が管理すべき範囲を明確にしてください。(Microsoft Learn)
まず何から確認すべきですか？
最初は、管理者権限、MFA、条件付きアクセス、公開IP、NSG、Storageのパブリックアクセス、ADE利用VMを確認してください。特にADE利用VMは2028年9月15日の廃止予定に向けて、早めに移行対象を棚卸しする必要があります。(Microsoft Learn)
Defender for Cloudを有効化すれば監視は完了ですか？
いいえ。Defender for Cloudは推奨事項や脅威検出を提供しますが、アラート対応フロー、担当者、通知先、例外管理、月次レビューがなければ運用として機能しません。必要に応じてMicrosoft SentinelやAzure Monitorと組み合わせ、検知から対応までの流れを作ることが重要です。(Microsoft Learn)
開発者が特に気をつけるべき点は何ですか？
シークレットをコードに埋め込まないこと、Managed IdentityとKey Vaultを使うこと、APIやStorageの公開範囲を最小化すること、WAFや認証を前提に設計することです。加えて、ログに機密情報を出さない、CORSを広く許可しない、検証用の緩い設定を本番に残さないことも重要です。
まとめ：Azureセキュリティは「設定の点検」から「継続運用」へ進める
Microsoft Azureのセキュリティ更新を実務に落とし込むには、まず共有責任モデルを理解し、自社が守るべきデータ、ID、アプリ、設定、監視範囲を明確にすることが出発点です。そのうえで、Microsoft Entra IDによるアクセス制御、RBACとPIM、ネットワーク公開範囲の最小化、Storageの権限管理、Defender for CloudとSentinelによる可視化を段階的に整備します。
特に既存VMがある環境では、Azure Disk Encryptionの利用状況をすぐに確認してください。2028年9月15日の廃止予定まで時間があるように見えても、対象VMの棚卸し、検証、ダウンタイム調整、バックアップ確認、ドメイン再参加、監視設定の再適用まで考えると、早期に計画化する価値があります。
次に取るべき行動は明確です。サブスクリプション単位で「特権ID」「公開ネットワーク」「ADE利用VM」「ログ未設定リソース」「Defender for Cloud未評価の推奨事項」を棚卸しし、重要度の高いものから改善計画に落とし込んでください。Azure セキュリティは一度の設定で完了するものではなく、標準化、監視、レビューを継続することで初めて強くなります。
コメント