Azure Security
Azureのセキュリティ設計とチェックポイント
Azureはリソースグループ・サブスクリプション・管理グループという独自の階層構造を持ち、権限やポリシーの継承関係を理解していないと意図しない過剰権限を生みやすい環境です。このページでは、Entra ID・NSG・Blob Storage・Azure Monitor/Activity Log・Defender for Cloud・Key Vaultという主要サービスと、確認すべきセキュリティコントロールを整理します。
Shared Responsibility (recap)
Azureの責任共有モデル(要点)
AzureもShared Responsibility Modelに基づき、物理データセンターやホスト基盤の保護はMicrosoftが担う一方、Entra IDのロール割り当て、NSGルール、Blob Storageのアクセスレベル、暗号化キーの管理といった設定は利用者側の責任です。IaaS/PaaS/SaaSのどのサービス形態を使うかによって責任分界点は変わります。モデル全体の詳しい説明はCloud Security Fundamentalsを参照してください。
Core Services & Security Controls
主要サービスとセキュリティコントロール
| サービス | カテゴリ | 確認すべきセキュリティコントロール |
|---|---|---|
| Entra ID | Identity | ロール割り当ての最小権限化、Access Reviewsによる定期的な棚卸し |
| NSG (Network Security Group) | Network | RDP(3389)/SSH(22)などにAnyからのInboundルールを許可していないか |
| Blob Storage | Storage | コンテナの匿名アクセスレベルが「Private」になっているか |
| Azure Monitor / Activity Log | Logging | サブスクリプション全体のActivity Logが診断設定でLog Analyticsに送信されているか |
| Defender for Cloud | Detection | すべてのサブスクリプションでStandard/Defenderプランが有効化されているか |
| Key Vault | Encryption | 機密データに対してMicrosoft管理キーではなく顧客管理キー(CMK)を使用しているか |
Common Misconfigurations
よくある設定ミス
-
Blob Storageコンテナの匿名アクセス有効化 High Risk
コンテナの「パブリックアクセスレベル」が「Blob」や「Container」に設定されたままとなり、認証なしで外部から読み取り可能になる。
-
NSGの過剰開放 High Risk
RDP/SSHなど管理ポートへのInboundルールで送信元が
Any(0.0.0.0/0相当)のまま本番運用される。 -
Defender for Cloudの一部サブスクリプションのみ有効 Medium Risk
新規作成したサブスクリプションでDefenderプランが自動有効化されず、検知の空白が生まれる。
-
Entra IDの特権ロールにMFA未強制 High Risk
Global AdministratorなどのロールにConditional AccessによるMFA強制が設定されておらず、パスワード漏洩だけで乗っ取りが成立する。
bash
az storage container show-permission --name <container-name> --account-name <storage-account>
bash
az network nsg rule list --nsg-name <nsg-name> --resource-group <rg-name> --query "[?access=='Allow' && sourceAddressPrefix=='*']"
bash
az security pricing list --query "[?pricingTier=='Free']"
bash
az role assignment list --all --query "[?roleDefinitionName=='Owner']"
Where to go deeper