Azure security fundamentals documentationは、Azure上のクラウドソリューションを安全に設計・運用するための公式ガイド群です。2026年5月13日に更新された公式情報で注目すべき点は、単なる用語整理ではなく、ID、ネットワーク、暗号化、運用監視、AI、Azure Integrated HSMまでを含めて、Azureセキュリティを見直す入口が整理されたことです。
管理者がまず確認すべきなのは、すべてのAzure環境に一律で緊急対応が必要かどうかではありません。重要なのは、現在の環境が「共有責任モデル」「Microsoft Entra IDによるアクセス制御」「Defender for Cloudによる推奨事項」「暗号化キー管理」「VM展開時のセキュリティ設定」に沿っているかを棚卸しすることです。特に、暗号化処理の負荷が高いWindows VMを使っている場合は、Azure Integrated HSMの要件と制限を確認する価値があります。
Azure security fundamentals documentationとは
Azure security fundamentals documentationは、Microsoft Azureのセキュリティ設計を理解するためのMicrosoft Learn公式ドキュメントです。Azureのセキュリティ概要、クラウドの共有責任、セキュリティサービス、脅威対策、ネットワーク、IaaS、ID管理、PaaS、データ暗号化、運用セキュリティ、AIセキュリティなどへの導線がまとめられています。(Microsoft Learn)
このページは「個別機能の設定手順だけを調べる場所」ではなく、Azure環境全体をどう守るかを整理するハブとして見ると分かりやすいです。たとえば、管理者はMicrosoft Defender for CloudやAzure Policyを使った継続的なセキュリティ評価を確認し、開発者はID、シークレット、PaaS、アプリケーション保護の設計を確認する、という使い方ができます。
公式ドキュメントでは、Azureのセキュリティを防御層で考える「多層防御」と、Microsoftと利用者の責任を分けて考える「共有責任モデル」が重視されています。Azureは物理データセンターや基盤インフラの保護を担いますが、データ、ID、アクセス管理、アプリケーション設定などは利用者側の責任として残ります。(Microsoft Learn)
2026年5月13日更新で押さえるべき主な変更点
今回の更新で実務上見逃せないのは、Azure security fundamentals documentation配下で、Azure Integrated HSMの概要と展開手順が確認しやすくなっている点です。日本語版のAzure Integrated HSM概要ページと展開手順ページはいずれも「Last updated on 2026-05-13」と表示されています。(Microsoft Learn)
Azure Integrated HSMは、仮想マシン上の暗号化操作のセキュリティと性能を高めるためのHSMキャッシュおよび暗号化オフロード機能です。Microsoftの説明では、AMD Dシリーズ v7およびAMD Eシリーズ v7以降のAzureサーバーハードウェアにMicrosoft設計のHSMチップが組み込まれ、FIPS 140-3 Level 3に対応するハードウェア境界内でキーを保護するとされています。(Microsoft Learn)
ただし、これはすべてのAzure VMに自動適用される汎用機能ではありません。サポート対象のVM SKU、vCore数、OS、セキュリティタイプ、展開時タグなど、満たすべき条件があります。展開後にタグを追加してもAzure Integrated HSMは利用できないため、既存VMへ後付けする前提で計画すると失敗します。(Microsoft Learn)
| 確認項目 | 2026年5月13日更新情報から読み取れるポイント | 実務での判断 |
|---|---|---|
| ドキュメントの位置づけ | Azureセキュリティ全体の入口として、ID、ネットワーク、IaaS、PaaS、AI、HSMなどを整理 | まず環境全体のセキュリティ棚卸しに使う |
| Azure Integrated HSM | 暗号化負荷の高いWindows VM向けに、HSMキャッシュと暗号化オフロードを提供 | 対象ワークロードが限定されるため、全VM移行ではなく候補選定から始める |
| 展開条件 | サブスクリプションの登録、対応SKU、Trusted Launch、Secure Boot、デプロイ時タグが必要 | IaCや展開テンプレートに条件を組み込む |
| 影響範囲 | 既存のAzure利用者全体に概念整理の影響がある一方、HSM機能は対象VMに限定 | セキュリティ基準の見直しと、該当VMの個別検証を分けて進める |
影響範囲：全Azure利用者が見るべき点と、該当環境だけでよい点
今回の情報は、Azureを使うすべての組織に同じ作業を求めるものではありません。影響範囲は大きく2つに分けると判断しやすくなります。
すべてのAzure管理者が確認すべき範囲
まず確認すべきなのは、Azure環境全体のセキュリティ運用です。Azure security fundamentals documentationでは、共有責任、Microsoft Defender for Cloud、ID管理、ネットワーク、暗号化、運用監視などが体系的に整理されています。(Microsoft Learn)
特に共有責任モデルでは、データ、構成と設定、IDとユーザーは、IaaS、PaaS、SaaSのいずれでも利用者側の責任として残ります。PaaSを使っているからセキュリティ設定が不要になるわけではありません。(Microsoft Learn)
たとえばAzure App ServiceやAzure Functionsを使う場合、OS管理の負担は軽くなりますが、認証方式、アクセス制御、ネットワーク公開範囲、アプリケーションコードの脆弱性、シークレット管理は引き続き確認が必要です。
Azure Integrated HSMの対象になり得る範囲
Azure Integrated HSMは、暗号化処理を多用するWindows VMで特に検討価値があります。公式ドキュメントでは、Windowsゲストのみ、WS2025またはWS2022のWindowsゲストイメージ、Dasv7、Dadsv7、Easv7、Eadsv7シリーズ、8 vCores以上、Trusted Launchセキュリティタイプが条件として示されています。Linux対応は「coming soon」とされていますが、現時点で本番計画に組み込む場合は、正式対応状況を都度確認する必要があります。(Microsoft Learn)
対象になりやすいのは、次のようなワークロードです。
- 暗号化・復号・署名処理が多い業務アプリケーション
- キー操作のレイテンシを下げたいWindows VM
- 規制要件や内部基準により、ハードウェア境界でのキー保護を重視するシステム
- Windows Server 2022またはWindows Server 2025ベースで新規VM展開を計画している環境
一方で、Linux VM、StandardセキュリティタイプのVM、Confidential VM、8 vCores未満のVM、非対応SKUのVMは、そのままでは対象外です。既存VMにタグを後から付けるだけでは利用できない点も重要です。(Microsoft Learn)
管理者が最初に確認すべき設定
Azureのセキュリティ確認は、個別サービスの設定から始めると抜け漏れが出やすくなります。まずは「ID」「ネットワーク」「データと暗号化」「監視」「ガバナンス」の順に確認するのが実務的です。
IDとアクセス制御
AzureではIDが主要なセキュリティ境界になります。公式のベストプラクティスでも、Microsoft Entra IDを中心に、シングルサインオン、条件付きアクセス、多要素認証、RBAC、特権アカウントの露出低減などが挙げられています。(Microsoft Learn)
確認すべきポイントは次のとおりです。
| 確認項目 | 見るべき設定 | 失敗しやすいポイント |
|---|---|---|
| 管理者権限 | Azure RBAC、Microsoft Entraロール、PIM | 常時グローバル管理者や所有者権限を付与したままにする |
| サインイン保護 | MFA、条件付きアクセス、リスクベースポリシー | 一部ユーザーだけ例外化し、その例外が放置される |
| 外部ユーザー | B2B、ゲストアカウント、アクセスレビュー | 退職者・取引終了ユーザーのアクセスが残る |
| アプリ認証 | マネージドID、サービスプリンシパル、証明書 | クライアントシークレットをコードや設定ファイルに保存する |
特に開発チームでは、接続文字列やAPIキーをソースコードに埋め込まないことが基本です。Azureリソースから他のAzureサービスへアクセスする場合は、可能な限りマネージドIDとRBACを使い、シークレットの配布範囲を減らします。
ネットワーク公開範囲
ネットワークでは、インターネットに公開してよい通信と、プライベート接続にすべき通信を分けます。Azureのセキュリティサービス一覧では、Azure Virtual Network、Network Security Groups、Azure Firewall、WAF、Azure DDoS Protection、Private Link、VPN Gateway、ExpressRoute、Network Watcherなどが整理されています。(Microsoft Learn)
管理者は、次の順で確認すると効率的です。
| 優先度 | 確認内容 | 具体例 |
|---|---|---|
| 高 | パブリックIPを持つリソースの棚卸し | VM、App Service、Storage、SQL、Application Gateway |
| 高 | NSGやFirewallルールの最小化 | 0.0.0.0/0 のRDP・SSH許可をなくす |
| 中 | PaaSのプライベート接続 | Private Link、サービスエンドポイント、ファイアウォール規則 |
| 中 | Webアプリ保護 | WAF、Front Door、Application Gateway |
| 中 | 可視化 | Network Watcher、NSGフローログ、接続診断 |
よくある失敗は、「開発中だけ」のつもりで開けた管理ポートやストレージの公開設定が、本番移行後も残ることです。Azure Resource GraphやAzure Policyを使い、公開リソースを定期的に検出する仕組みを作ると、手作業の見落としを減らせます。
Defender for Cloudとセキュリティ推奨事項
Microsoft Defender for Cloudは、Azureリソースのセキュリティ状態を継続的に分析し、構成上の弱点に対する推奨事項を提示します。公式ドキュメントでは、Defender for CloudがAzureサブスクリプションに対する統合的なセキュリティ監視とポリシー管理を提供し、リスクの検出と対応を支援すると説明されています。(Microsoft Learn)
管理者が見るべきなのは、アラートの有無だけではありません。推奨事項のうち、次のような項目を優先します。
- インターネット公開されている管理ポート
- MFAや条件付きアクセスが不足している管理者アカウント
- 暗号化やバックアップが不十分なリソース
- 脆弱なコンテナー、VM、データベース構成
- 監査ログや診断ログが未設定のリソース
重要なのは、推奨事項を「一覧で見るだけ」で終わらせないことです。重大度、影響範囲、修正工数、業務影響を付けて、チケット化・期限設定・再確認までを運用に組み込みます。
開発者が確認すべき設計ポイント
Azure security fundamentals documentationは管理者向けだけではありません。開発者も、アプリケーションの認証、シークレット、ログ、PaaS構成、データ保護を確認する必要があります。
シークレットをコードに置かない
アプリケーションでデータベース接続文字列、APIキー、証明書、ストレージキーを扱う場合、コードやリポジトリに保存しない設計が基本です。Azure Key VaultやマネージドIDを使い、アプリケーションが必要なときに安全に取得できるようにします。
実務では、次のようなルールを決めておくと運用しやすくなります。
| ルール | 推奨される実装 |
|---|---|
| 本番シークレットはリポジトリに置かない | Key Vault、環境変数、CI/CDの保護済み変数を使う |
| アプリからAzureリソースへアクセスする | マネージドIDとRBACを優先する |
| 長期の共有キーを減らす | Entra ID認証や短期資格情報を使う |
| シークレット変更に備える | ローテーション手順と影響確認を事前に作る |
PaaSでも「設定責任」は残る
PaaSはOS管理やミドルウェア管理の負担を下げますが、アプリケーション設定、認証、ネットワーク制限、診断ログ、データ保護は利用者側で確認が必要です。共有責任モデルでは、PaaSでもデータ、構成、ID、アクセス管理は利用者側の責任として残ります。(Microsoft Learn)
たとえばAzure App Serviceでは、次のような設定が確認対象になります。
- 認証・認可をEntra IDなどで統制しているか
- HTTPSのみ許可しているか
- 管理用エンドポイントが不要に公開されていないか
- アプリケーションログ、診断ログ、監査ログを取得しているか
- Key Vault参照やマネージドIDを使っているか
- 本番・検証・開発環境で権限や接続先が分離されているか
Azure Integrated HSMを検討する場合の要件
Azure Integrated HSMを導入する前に、対象VMが要件を満たすかを確認します。公式ドキュメントでは、Windows VMに適用される機能として説明され、デプロイ時に特定タグを含める必要があるとされています。デプロイ後にタグを追加しても利用できません。(Microsoft Learn)
| 項目 | 要件・注意点 |
|---|---|
| 対象OS | Windowsゲストのみ。WS2025またはWS2022のWindowsゲストイメージが対象 |
| VM SKU | Dasv7、Dadsv7、Easv7、Eadsv7シリーズ |
| VMサイズ | 8 vCores以上 |
| セキュリティタイプ | Trusted Launchのみ。StandardとConfidentialは対象外 |
| Secure Boot | Azure Integrated HSMをサポートするにはTrusted LaunchとSecure Bootが必要 |
| 有効化方法 | サブスクリプションでAzure Integrated HSMフラグを登録し、VMデプロイ時にタグを付与 |
| 既存VMへの後付け | デプロイ後のタグ追加では利用不可 |
| キーの永続性 | ローカルキャッシュされたキーはVM再起動や割り当て解除をまたいで永続化されない |
| Linux対応 | 公式情報ではWindowsサポートのみ。Linuxは今後対応予定とされている |
Azure CLIで展開する場合、公式手順ではVM作成時に次のタグを含めることがポイントです。実際の運用では、CLIで直接作るよりも、Bicep、ARMテンプレート、TerraformなどのIaCに組み込んで、環境ごとの設定差分を管理する方が安全です。
--security-type TrustedLaunch \
--enable-secure-boot true \
--enable-vtpm true \
--tags platformsettings.host_environment.AzureIntegratedHSM=Trueここで注意すべきなのは、Azure Integrated HSMをKey VaultやManaged HSMの完全な置き換えとして扱わないことです。公式ドキュメント上の説明は、HSMキャッシュおよび暗号化オフロードであり、キーライフサイクル全体の管理、アクセス制御、監査、ローテーション設計は引き続き整理が必要です。(Microsoft Learn)
移行・展開時に失敗しやすいポイント
Azure security fundamentals documentationを読んだ後に実務で起きやすい失敗は、「機能を知った段階で、すぐ本番に適用してしまう」ことです。特にセキュリティ機能は、正しく使えば防御力を高めますが、要件や制限を誤ると可用性や運用に影響します。
既存VMにタグだけ追加してしまう
Azure Integrated HSMは、VMデプロイ時にタグを含める必要があります。展開後にタグを追加しても利用できないため、既存VMで使いたい場合は、新規VMとして再展開し、アプリケーション、データ、ネットワーク、監視、バックアップの移行計画を立てる必要があります。(Microsoft Learn)
再起動後の動作を検証しない
Azure Integrated HSMはローカルキーキャッシュとして設計されており、VMの再起動や割り当て解除をまたいでキーは永続化されません。アプリケーションが「ローカルに保持されたキーが再起動後も使える」と仮定している場合、障害や復旧時に問題が出る可能性があります。(Microsoft Learn)
本番前には、次のテストを行います。
| テスト | 確認内容 |
|---|---|
| 通常起動 | 暗号化処理、署名処理、認証処理が期待通り動くか |
| 再起動 | キー再取得や初期化処理が失敗しないか |
| 割り当て解除・再起動 | ローカルキャッシュ非永続を前提に復旧できるか |
| スケールアウト | 複数VMで同じ設計が成り立つか |
| リージョン障害想定 | 別リージョンや別SKUで代替できるか |
暗号化まわりの移行期限を見落とす
Azureのセキュリティ概要では、Azure Disk Encryptionが2028年9月15日に廃止予定であり、新しいVMではencryption at hostを使うこと、既存のADE有効VMは廃止日までに移行が必要であることが示されています。ADE有効ワークロードは廃止日後も動き続ける可能性がありますが、VM再起動時に暗号化ディスクのロック解除が失敗し、サービス影響につながると説明されています。(Microsoft Learn)
Azure Integrated HSMの検討と同時に、VM暗号化の方式も棚卸ししてください。特に長期稼働しているIaaS環境では、古い暗号化方式、古いOSイメージ、古い運用手順が残っていることがあります。
Microsoft Cloud Security Benchmarkもあわせて確認する
Azure security fundamentals documentationを読むだけでは、実際の設定値までは統制できません。設定を継続的に確認するには、Microsoft Cloud Security Benchmark、Azure Policy、Defender for Cloudの規制コンプライアンスダッシュボードを組み合わせるのが現実的です。
公式のベストプラクティスページでは、Microsoft Cloud Security BenchmarkがID、ネットワーク、コンピューティング、データ保護、管理レイヤーにまたがる包括的なセキュリティベストプラクティスを提供すると説明されています。また、MCSB v2プレビューではAIセキュリティの新しい制御ドメインやAzure Policy対象範囲の拡大にも触れられています。(Microsoft Learn)
実務では、次のように使い分けると運用しやすくなります。
| 目的 | 使う機能 | 実務での使い方 |
|---|---|---|
| セキュリティ基準を決める | Microsoft Cloud Security Benchmark | 組織の標準設定や監査基準に反映する |
| 設定違反を検出する | Azure Policy | 未暗号化、公開設定、タグ不足などを監査する |
| リスクを継続評価する | Defender for Cloud | 推奨事項とセキュリティスコアを定期確認する |
| 対応を運用に乗せる | チケット管理、変更管理 | 重大度と期限を付けて修正する |
| 例外を管理する | 例外申請、期限付き承認 | 恒久的な例外放置を防ぐ |
管理者・開発者向けの確認チェックリスト
最後に、今回の更新を受けて確認すべき項目を実務向けに整理します。
| 担当 | 確認項目 | 次に取る行動 |
|---|---|---|
| Azure管理者 | サブスクリプション、管理グループ、RBACの棚卸し | 所有者権限、不要な管理者、外部ユーザーを整理する |
| セキュリティ担当 | Defender for Cloudの推奨事項 | 重大度が高い項目からチケット化する |
| ネットワーク担当 | パブリック公開、NSG、Firewall、Private Link | 不要な公開設定を閉じる |
| VM管理者 | ADE、encryption at host、Trusted Launch | 古い暗号化方式とVMセキュリティタイプを確認する |
| 開発者 | シークレット、認証、ログ、PaaS設定 | Key Vault、マネージドID、Entra ID認証を優先する |
| アーキテクト | Azure Integrated HSMの適用可否 | 対応SKU、OS、vCore、再起動時挙動を検証する |
| DevOps担当 | IaCテンプレート | セキュリティ設定を手作業ではなくコード化する |
今回のAzure security fundamentals documentationの更新は、特定の機能だけを追いかけるよりも、Azure環境全体のセキュリティ設計を見直すきっかけとして使うべきです。まずは共有責任モデルに沿って、自社が管理すべきデータ、ID、設定、アクセス制御を棚卸しします。そのうえで、Defender for CloudとAzure Policyで継続的に検出し、暗号化負荷の高いWindows VMについてはAzure Integrated HSMの要件を満たすかを検証してください。
次に取るべき行動は、すべての設定を一度に変更することではありません。最初の1週間で公開リソース、管理者権限、Defender for Cloudの重大な推奨事項を確認し、次にVM暗号化方式とAzure Integrated HSMの対象候補を洗い出す。この順番で進めると、業務影響を抑えながらAzureのセキュリティ水準を現実的に引き上げられます。
コメント