Azureアーキテクチャにおけるコンプライアンス的に最も重要な視点

山崎行政書士事務所
9月11日
読了時間: 9分

— データ管理 / セキュリティとアクセス制御 / 法規制の順守 / 監査対応と可視性 —

著者：山崎行政書士事務所クラウド法務・アーキテクチャ支援チーム

発行日：2025-09-11

]要旨（Abstract）

Azure を用いたエンタープライズ・アーキテクチャにおいて、コンプライアンスの核心は (1) データ管理（所在地・移転）、(2) セキュリティとアクセス制御、(3) 法規制の順守、(4) 監査対応と可視性 の 4 視点に集約される。本稿は、これらの視点を “実装できる設計” として落とし込む方法を体系化し、技術ガードレール（Azure Policy / Private Link / CMK / 機密計算 / Sentinel 等）と法務ガードレール（DPA／SCC／BAA／業界基準）を二重化することで、違反リスクを低減しつつ運用コストを抑える枠組みを提示する。最後に、運用品質（SLO/監査証跡）を高める構成証跡ドリブンの実務テンプレートを付す。

キーワード：Data Residency, Data Transfer, Microsoft Entra ID, Conditional Access, PIM, RBAC, Key Vault, CMK, Private Link, Confidential Computing, Microsoft Purview, Defender for Cloud, Microsoft Sentinel, Azure Policy, Tagging, DLP, TIA, DPA, SCC, PCI DSS, HIPAA, ISO/IEC 27001, FedRAMP, FISC

1. はじめに（問題設定）

クラウド・コンプライアンスは 「法務要件 × 技術要件 × 運用要件」 の合成最適化である。Azure は強力なセキュリティ機能を備えるが、設計／実装／運用のいずれか一段でも抜けると統制不全が起きる。そこで本稿は、4 つの視点を中核とする “コンプライアンス・バイ・デザイン” を Azure 上で実現するための 設計パターン・ガードレール・運用証跡を示す。

2. 4つの視点（全体像と責任分解）

視点A：データ管理（所在地・移転）目的：データの地理的統制（保存・移転・バックアップ）と閉域化。成果物：Data Residency 方針 / 移転基準 / TIA / DPA/SCC、および Region/Private Link/GRS 設定の証跡。
視点B：セキュリティとアクセス制御目的：最小権限・強固な認証と暗号化を Azure 標準機能で徹底。成果物：MFA/CA/PIM/RBAC/CMK/ネットワーク分離の実装証跡。
視点C：法規制の順守（業界適合）目的：事業ドメイン別規制（例：PCI DSS/HIPAA）と国際規格（ISO、FedRAMP、日本のFISC 等）への整合。成果物：準拠マップ・適合証明・運用基準書。
視点D：監査対応と可視性目的：可観測性・証跡の完全性（収集・保存・改ざん耐性）と早期検知。成果物：ログ収集アーキテクチャ / Sentinel 分析 / データ保持計画 / 監査対応手順。

責任分解（RACI） Responsible：クラウド運用（SRE/プラットフォーム） Accountable：CISO/CPO/情報セキュリティ統括 Consulted：法務・個人情報保護・内部監査 Informed：各事業部門

3. 視点A：データ管理（所在地・移転）

最重要問い：「データはどこに保存され、どこへ移転しうるのか？」

3.1 技術ガードレール

Region 戦略：機微/個人データは居住要件に適合するリージョンへ。業務系と解析系でリージョンを分離し、Cross-Region は要件ベースで最小化。
閉域化：Private Link によるデータ経路の私設化、Public Network Access = Disabled を原則。
暗号化：保存時暗号化は既定＋**CMK（Customer-Managed Keys）**で鍵責任を自社側へ。必要に応じ Managed HSM。
バックアップとレプリケーション：GRS 等の冗長化はレジデンシ要件に合致する構成のみ許容。
タグとポリシー：DataClass={PII|PHI|CARD|Internal}、Residency={EU|JP|US|...} のデータ分類タグで、Policy の適用対象を自動選別。

（サンプル）Azure Policy：リージョン制限（allowedLocations）

{
  "properties": {
    "displayName": "Allow only EU or Japan regions",
    "policyType": "Custom",
    "mode": "All",
    "parameters": {
      "listOfAllowedLocations": {
        "type": "Array",
        "metadata": { "displayName": "Allowed locations" },
        "defaultValue": [ "japaneast", "japanwest", "northeurope", "westeurope" ]
      }
    },
    "policyRule": {
      "if": { "field": "location", "notIn": "[parameters('listOfAllowedLocations')]" },
      "then": { "effect": "deny" }
    }
  }
}

（サンプル）Storage の公開遮断と Private Endpoint 必須化（概念）

allowBlobPublicAccess = false
publicNetworkAccess = Disabled
Private Endpoint を Required にする DeployIfNotExists ポリシーで自動是正。

3.2 法務ガードレール

DPA（Data Processing Addendum）：Microsoft とのデータ処理契約。
SCC（標準契約条項）：域外移転時の適法性担保。**TIA（移転影響評価）**とセットで実施。
EU Data Boundary / 各国データレジデンシの適用可否をサービス別に確認。
記録管理（RoPA）：データ処理活動台帳と技術設計のひも付け。

実務ノート：リージョン／転送経路／暗号鍵の設置位置を「構成証跡（Evidence Pack）」として図式化し、DPA/SCC/TIA の条項番号と相互参照できるフォーマットで保管する。

4. 視点B：セキュリティとアクセス制御

最重要問い：「誰が、どのデータに、どの条件でアクセスできるのか？」

4.1 認証・認可の中核（Microsoft Entra ID）

MFA＋条件付きアクセス（CA）：場所・デバイス準拠・リスクに応じたアダプティブ制御。
PIM（特権 ID 管理）：特権ロールはJIT 付与／承認フロー／理由必須。
RBAC の最小権限：サブスクリプション境界・管理グループ境界で役割スコープを厳格化。
マネージド ID：アプリ／自動化に資格情報を埋め込まない。

4.2 データと鍵の防御

Key Vault / Managed HSM：秘密情報・鍵の集中管理。アクセスは Private Link＋Firewall。
CMK（二重化）：ストレージ／ディスク／データベースで顧客管理鍵を適用（必要に応じ二重暗号化）。
Confidential Computing：インメモリ保護（TEE）により演算中の機微データを防御。

4.3 ネットワーク境界

Private Link と NSG/Firewall：発着とも私設経路を原則。
Service Endpoints/UDR：既存ネットワークと整合しつつ外部露出をゼロへ。
Deny Public の既定化：Deny ポリシーで例外承認の仕組み（期限付例外＋再承認）。

5. 視点C：法規制の順守（業界ごとの適合）

最重要問い：「当社の事業ドメインに適合するか？」

5.1 規制・基準の扱い

国際規格：ISO/IEC 27001 等。
業界：PCI DSS（カード情報）、HIPAA（医療）、金融ガイドライン（日本 FISC など）、米国公的（FedRAMP）ほか。
法域：GDPR/CCPA などの個人データ法制（データ主体権、移転規律、透明性義務）。

5.2 Azure での実務ポイント

Azure Policy（イニシアチブ）：規制/基準マップと自動評価・是正。
Defender for Cloud：Regulatory Compliance ダッシュボードで継続監視。
Microsoft Purview：データカタログ／分類／DLP／eDiscovery によるデータ・ガバナンス。
設計の読み替え：旧称の機能（例：Security Center）は**新名称（Defender for Cloud）**で整理。Azure Blueprints は非推奨のため、Policy＋Bicep/Template Specs を採用。

注意（保持期間の神話）：GDPR は保持期間を固定的に規定しない。目的達成に必要な最小期間が原則で、業界・国別ガイドラインで長期保持が要求されるケース（金融の帳簿等）は個別根拠に基づくこと。

6. 視点D：監査対応と可視性

最重要問い：「監査人に“設計どおり運用できている”ことを反証可能か？」

6.1 収集アーキテクチャ（例）

[Azure Resource / Entra / PaaS 各種ログ]
           │ Diagnostic settings / DCR
           ▼
   [Log Analytics Workspace]  ─→  [Microsoft Sentinel 分析/アラート]
           │ Export / Capture
           ├─→ [Event Hubs → 他SIEM]
           └─→ [Azure Storage (WORM/Archive) 長期保管]

6.2 ログ保持と改ざん耐性

Log Analytics：ワークスペースごとに保持期間とアーカイブを設計。
WORM（変更不可）：Immutable Blob を用いた長期証跡。
チェックリスト：収集カバレッジ（AzureActivity / Resource Logs / Entra サインイン＆監査 / Key Vault / Storage / Databases）。

6.3 監査に効く KQL スニペット

// 特権ロールのアクティベーション（PIM）
AuditLogs
| where OperationName contains "Activate" and Result == "success"
| summarize count() by InitiatedBy, bin(TimeGenerated, 1d)

// Key Vault 機密の取得イベント
AzureDiagnostics
| where ResourceProvider == "MICROSOFT.KEYVAULT" and Category == "AuditEvent"
| where OperationName == "SecretGet"
| project TimeGenerated, CallerIPAddress, identity, ResultDescription

// グローバル管理者のサインイン（国外アクセス）
SigninLogs
| where UserPrincipalName has "@"
| where UserId in (externaldata(u: string)["<CSV of GA IDs>"])
| where Location !in ("JP", "EU")

7. 構成証跡ドリブン運用（Configuration-as-Evidence）

Evidence Pack：
1. アーキ図（データ流と鍵の位置）
2. Policy/イニシアチブ定義（JSON/Bicep）
3. 運用 Runbook（例外承認、鍵ローテーション、DR 手順）
4. ダッシュボード出力（Defender/Sentinel の評価スクリーンショット）
5. 法務資料（DPA/SCC/TIA 抜粋と設計項目の対応表）
テスト証跡：DR 演習、PIM 承認ワークフロー、CA テンプレの動作証跡を四半期ごとに蓄積。
メトリクス：SLO（例：重大警告への初動時間、例外の期限切れ率、鍵のローテ完了率）を監査 KPIとして可視化。

8. アンチパターン（よくある落とし穴）

“Public ON がデフォルト” のまま：publicNetworkAccess=Enabled を放置。
CMK のみで満足：鍵が誰の責任か、どこに置くかまで設計しない。
リージョン要件の属人判断：タグ＋Policy で自動判定・自動是正に。
ログの長期保存がストレージ任せ：改ざん耐性（WORM）と検索性の両立を設計。
Blueprint をそのまま踏襲：現行は Policy/Template Specs で再設計。
“GDPRは6ヶ月” といった固定観念：目的限定・必要最小限が原則。
PIM を監査でしか使わない：日常運用で特権常設を撲滅。

9. 実装テンプレ（抜粋）

9.1 ストレージの閉域化と CMK（Bicep スケッチ）

param rgName string
param saName string
param keyVaultId string
param keyUri string

resource sa 'Microsoft.Storage/storageAccounts@2023-01-01' = {
  name: saName
  location: resourceGroup(rgName).location
  sku: { name: 'Standard_GRS' } // 要件に応じて RA-GRS/Zone 冗長等に調整
  kind: 'StorageV2'
  properties: {
    allowBlobPublicAccess: false
    minimumTlsVersion: 'TLS1_2'
    allowSharedKeyAccess: false
    publicNetworkAccess: 'Disabled'
    encryption: {
      services: {
        blob: { enabled: true }
        file: { enabled: true }
      }
      keySource: 'Microsoft.Keyvault'
      keyVaultProperties: {
        keyVaultUri: keyUri
      }
    }
    networkAcls: {
      defaultAction: 'Deny'
      bypass: 'AzureServices'
    }
  }
}

9.2 条件付きアクセス（設計の要点）

要件：機微データへは準拠デバイス＋MFA＋国内/指定拠点。
例外：臨時プロジェクトはグループ単位で有効期限付き例外。
証跡：ポリシー設定のJSON エクスポート＋変更履歴を Evidence Pack へ。

10. まとめ（実務の勘所）

設計：リージョン／鍵／ネットワークを先に固め、タグ＋Policy で自動化。
実装：Entra（MFA/CA/PIM）＋CMK＋Private Link を標準化。
運用：Sentinel／Defender で継続評価し、Evidence Pack を更新。
法務：DPA/SCC/TIA を設計書と相互参照し、監査に即応。

11. 山崎行政書士事務所のご支援（PR）

「技術」と「法務」を一体で設計・実装・証跡化します。

データレジデンシ／越境移転（DPA・SCC・TIA）と、Azure Policy/Private Link/CMK/Sentinel の技術ガードレールを 同じチームで設計。
準拠マップ（ISO/PCI/HIPAA/FISC ほか）とAzure 実装をコントロール単位で対応付け、監査で使えるEvidence Packまで作り切ります。
既存環境は**差分是正計画（例外の棚卸し／期限付与／再評価ループ）**から着手できます。

初回ディスカッションの論点例 当社データ分類×レジデンシの設計方針は？ Private Link/CMK の責任分界と鍵運用（ローテ・退避）は？ Policy イニシアチブで強制すべき最小セットは？ Evidence Pack の構成と、監査時の提示フローは？

TL;DR（冒頭要約用カット）

データ管理：居住要件と閉域化（Private Link／CMK／Region 制御）。
アクセス制御：Entra（MFA/CA/PIM）と RBAC 最小化。
規制順守：Policy イニシアチブ＋Defender＋Purview で継続評価。
監査対応：Log Analytics／Sentinel／WORM 保存＋Evidence Pack。

参照リンク集