はじめに：クラウドインフラのセキュリティは、もはや境界防御だけでは不十分
従来のオンプレミス環境では、ネットワーク境界（ファイアウォール、DMZ）を堅牢にしておけば比較的安全でした。しかしクラウド、特に IaaS 環境では攻撃表面がはるかに広く多様です。アイデンティティ、ソフトウェアサプライチェーン、コントロールプレーン、ネットワーク、データが同時に標的になり得ます。
Azure IaaS はこのような現代の脅威に対応するため、多層防御 (Defense in Depth, DiD) アーキテクチャを採用しています。単一のセキュリティ制御に依存せず、複数の独立した保護レイヤーを積み重ねることで、1つのレイヤーが突破されてもシステム全体が崩壊しないように設計されています。
本記事では、Azure IaaS の多層防御構造を Secure by Design、Secure by Default、Secure in Operation の3つの SFI 原則で解説し、実務にすぐに活用できる具体的な設定とコード例を共有します。本内容は Azure 公式ブログシリーズ で解説されているベストプラクティスをベースに、日本のエンジニア向けに再構成しました。
💡 本記事は Azure IaaS シリーズの一部です。合わせて読みたい記事："UCP (Universal Commerce Protocol) 完全ガイド：エージェントコマースの標準が開かれる"
Secure by Design：設計段階でセキュリティを組み込む
Azure IaaS のセキュリティは 最も低いレイヤー（ハードウェア） から始まります。ソフトウェアだけでは防げないファームウェア攻撃、ブートキット、カーネルルートキットを根本的にブロックすることが重要です。
ハードウェアおよびホストレベルの信頼
Azure サーバーは TPM (Trusted Platform Module)、Secure Boot、Measured Boot により、ホストファームウェア、ブートローダー、OS が改ざんされていないことを検証します。さらに Azure Boost という専用ハードウェアでストレージ、ネットワーキング、管理操作をホスト OS から分離し、攻撃表面を削減します。
VM レベルの信頼：Trusted Launch + 機密コンピューティング
Azure VM では Trusted Launch をデフォルトで有効化することが推奨されます。Trusted Launch は Secure Boot、vTPM、整合性モニタリングを組み合わせ、VM を低レベル攻撃から保護します。
# Azure CLI で Trusted Launch を有効化した VM を作成
az vm create \
--resource-group myResourceGroup \
--name mySecureVM \
--image Ubuntu2204 \
--admin-username azureuser \
--security-type TrustedLaunch \
--enable-secure-boot true \
--enable-vtpm true
⚠️ Trusted Launch は Gen2 VM、サポート対象の OS イメージ、特定の VM サイズでのみ利用可能です。Portal、ARM、Bicep、Terraform、SDK など全てのデプロイ方法でサポートされています。
より高いセキュリティが必要なワークロードには Azure 機密コンピューティング (Confidential Computing) を検討してください。AMD SEV-SNP または Intel TDX ベースの TEE (Trusted Execution Environment) を使用して、使用中のデータ (In-use data) も暗号化します。ホストやハイパーバイザーでさえデータにアクセスできません。
# Terraform で機密 VM を作成 (AMD SEV-SNP)
resource "azurerm_linux_virtual_machine" "confidential_vm" {
name = "confidential-vm"
resource_group_name = azurerm_resource_group.example.name
location = azurerm_resource_group.example.location
size = "Standard_DC2as_v5"
admin_username = "adminuser"
network_interface_ids = [azurerm_network_interface.example.id]
admin_ssh_key {
username = "adminuser"
public_key = file("~/.ssh/id_rsa.pub")
}
os_disk {
caching = "ReadWrite"
storage_account_type = "StandardSSD_LRS"
}
source_image_reference {
publisher = "Canonical"
offer = "ubuntu-24_04-lts"
sku = "server"
version = "latest"
}
# 機密コンピューティングを有効化
vtpm_enabled = true
secure_boot_enabled = true
}
重要なインサイト： セキュリティは「後から追加する」ものではなく、アーキテクチャの設計属性であるべきです。Azure IaaS はハードウェアのルートオブトラストから VM、ネットワーク、データまで全てのレイヤーにセキュリティを組み込んでいます。
Secure by Default：摩擦のないデフォルトセキュリティ
「デフォルト値が最も安全な選択」となるように設計することが Secure by Default の核心です。ユーザーが別途セキュリティ設定を組み立てなくても、デフォルトで保護される必要があります。
ネットワーキングのデフォルト：ゼロトラストの原則
Azure IaaS の仮想ネットワーク (VNet) は デフォルトで分離 されています。VM へのインバウンドトラフィックは明示的に許可しない限り全てブロックされます。
# NSG ルールの例：SSH のみ許可
az network nsg rule create \
--resource-group myResourceGroup \
--nsg-name myNSG \
--name AllowSSH \
--protocol tcp \
--priority 1000 \
--destination-port-ranges 22 \
--access Allow \
--source-address-prefixes 203.0.113.0/24 # 特定の IP のみ許可
その他の Secure by Default 機能：
- Azure Private Link / Private Endpoint： パブリックインターネットに公開せずにサービスにアクセス
- Azure DDoS Protection： プラットフォームエッジで自動適用（別途設定不要）
- Azure Firewall： 集中ポリシー適用とトラフィック検査
暗号化のデフォルト：常にオン
Azure IaaS ストレージは デフォルトで保存データ (Data at Rest) 暗号化 を有効にします。プラットフォーム管理キーを使用し、必要に応じて Azure Key Vault または Managed HSM でカスタマーマネージドキーに切り替え可能です。
# ディスク暗号化設定の確認 (Azure CLI)
az disk show \
--resource-group myResourceGroup \
--name myOSDisk \
--query encryption.type
# 出力: EncryptionAtRestWithPlatformKey
転送中暗号化 (Encryption in Transit) は Azure バックボーンネットワークでデフォルト適用されます。別途設定なしでサービス間トラフィックが保護されます。
コンピューティング保護のデフォルト
以下は Azure テナントが 無効化できない デフォルトセキュリティです：
- 署名および測定された Azure ホストブート
- セキュアホスト OS の強化
- ホストレベルの監視とパッチ適用 (Microsoft が実施)
- ハイパーバイザーベースのテナント間分離
また Trusted Launch は、サポート対象の Gen2 VM、VM Scale Set において 新規作成時にデフォルトで有効化 されます。Portal、ARM、Bicep、Terraform、SDK など全てのデプロイ方法で適用されます。
💡 日本企業のクラウド移行現場では、「デフォルトが最善」という認識がまだ十分に浸透していないケースが多く見られます。セキュリティポリシーを策定する際は、「デフォルト有効」の項目を先に確認し、「無効化しなければならない例外」を最小限にする方向で進めることをお勧めします。
Secure in Operation：継続的なランタイム保護
セキュリティはデプロイで終わりません。運用中の継続的な監視、検出、対応 が必要です。
モニタリングと脅威検出
Azure はコンピューティング、ネットワーク、ストレージレイヤーのテレメトリーを Azure Monitor と Microsoft Defender for Cloud で集中収集します。これにより：
- 露出した管理ポートの特定
- 欠落したディスク暗号化の検出
- 安全でないネットワーク設定の検知
- 環境全体の脅威シグナルの相関分析
# Defender for Cloud のセキュリティスコア確認 (Azure CLI)
az security secure-scores list --query "[].{name:name, score:score.current}"
アイデンティティ中心の制御 (ゼロトラスト)
Azure IaaS は Microsoft Entra ID と統合し、アイデンティティベースのアクセス制御、最小権限、条件付きアクセスポリシーを適用します。特に JIT (Just-In-Time) VM アクセス は管理ポートを常時開放せず、承認されたアイデンティティが、必要な時だけ、制限時間付きで アクセスできるようにします。
# JIT VM アクセスポリシーを有効化 (Azure CLI)
az security jit-policy create \
--resource-group myResourceGroup \
--location eastus \
--vm-name mySecureVM \
--ports 22 3389 \
--max-request-access-duration 3h
日本市場における適用のポイント
日本企業のクラウド移行では、従来のオンプレミス運用スタイルをそのまま持ち込むケースが少なくありません。例えば：
- 管理ポート (SSH/RDP) を全 IP に開放
- Bastion Host を使わずパブリック IP で直接アクセス
- 定期的なセキュリティパッチを手動で実施
Azure IaaS の Secure in Operation 原則を適用するには：
- JIT VM Access を全ての管理者 VM に適用
- Azure Bastion でパブリック IP なしで VM にアクセス
- Defender for Cloud の推奨事項を週次でレビュー
- Azure Update Manager で自動パッチ管理を活用
まとめ：階層的で体系的なセキュリティが答え
Azure IaaS の多層防御アーキテクチャは単なる機能リストではなく、システムレベルのセキュリティ設計です。Secure by Design で設計段階からセキュリティを組み込み、Secure by Default で摩擦のないデフォルト保護を提供し、Secure in Operation で運用中の継続的な適応と対応を保証します。
この3つの原則が連携することで：
- 階層化： 単一の制御に依存しない
- 内在化： セキュリティがアドオンではなくプラットフォームアーキテクチャの一部
- 一貫性： デフォルトとポリシーが設定ドリフトを最小化
- 適応性： 継続的な監視と運用制御が脅威環境に対応
次のステップとしての学習方向：
- Azure IaaS Resource Center で Compute、Storage、Network 別のベストプラクティスを学習
- Azure Policy を活用したセキュリティ準拠の自動化
- Azure Landing Zone アーキテクチャでエンタープライズ級のセキュリティ設計
合わせて読みたい記事：