責任共有モデル：クラウドの大前提
クラウドセキュリティの根本的な概念が「責任共有モデル（Shared Responsibility Model）」だ。 クラウドプロバイダーは「クラウドのセキュリティ（of the Cloud）」——物理データセンター・ ハードウェア・ハイパーバイザー——に責任を持つ。一方、顧客は「クラウドにおけるセキュリティ （in the Cloud）」——OS・アプリ・データ・IAM設定——に責任を持つ。
この分担はサービスモデル（IaaS/PaaS/SaaS）によって変化する。 IaaS では顧客の責任範囲が広く、SaaS ではプロバイダーの責任範囲が広くなる。 オンプレミスはすべての責任が顧客にある。
| 責任範囲 | オンプレ | IaaS（クラウド） | PaaS（クラウド） | SaaS（クラウド） |
|---|---|---|---|---|
| データ・コンテンツ | 顧客 | 顧客 | 顧客 | 顧客 |
| アプリケーション | 顧客 | 顧客 | 顧客 | プロバイダー |
| ランタイム・ミドルウェア | 顧客 | 顧客 | プロバイダー | プロバイダー |
| OS・パッチ適用 | 顧客 | 顧客 | プロバイダー | プロバイダー |
| 仮想化・ハイパーバイザー | 顧客 | プロバイダー | プロバイダー | プロバイダー |
| 物理サーバー・ネットワーク | 顧客 | プロバイダー | プロバイダー | プロバイダー |
| 物理データセンター | 顧客 | プロバイダー | プロバイダー | プロバイダー |
⚠️ 最大のリスクは「設定ミス」
クラウドのセキュリティインシデントの大多数は、プロバイダーの脆弱性ではなく 顧客側の設定ミス（S3バケットの誤公開・過剰な IAM 権限等）が原因です。 クラウドに移行しても、設定管理・アクセス管理の徹底が最重要課題です。
データ主権とデータ所在
金融・医療・公共機関など規制の強い業種では、データが「どの国のサーバーに保存されるか」 が法的要件になる。日本の個人情報保護法・APPI や EU の GDPR はデータの越境移転を制限する。
各クラウドプロバイダーは日本国内にリージョンを保有しているが、 バックアップデータが海外に複製されるケースやサポートアクセスの海外経路など、 データ主権の観点では詳細な確認が必要だ。
| データ主権の観点 | オンプレ | AWS（東京/大阪） | OCI（東京/大阪） | Azure（東日本/西日本） |
|---|---|---|---|---|
| データ所在地コントロール | 完全コントロール | リージョン固定可能 | リージョン固定可能 | Sovereign Cloud で強化 |
| 日本政府向け | — | GovCloud（米国のみ） | 政府専用クラウドなし | Azure Government（米国）/ Azure for Operators |
| 国内専用クラウド | — | — | — | Azure Sovereign Japan（調達中） |
| サポートアクセス制御 | 完全内製 | AWS Nitro + Customer-initiated support | Customer Controls（顧客承認制） | Customer Lockbox for Azure |
IAM・アクセス管理の比較
Identity and Access Management（IAM）はクラウドセキュリティの核心だ。 「誰が何にアクセスできるか」を細かく制御できるかどうかで、ゼロトラスト実現の難易度が変わる。
| IAM の特徴 | AWS IAM | OCI IAM | Azure AD（Entra ID） |
|---|---|---|---|
| ポリシーモデル | JSON ポリシー（Allow/Deny） | コンパートメント + ポリシー文 | RBAC + Azure Policy |
| 最小権限の実現 | 非常に細かい権限設定可能 | コンパートメントで分離しやすい | 条件付きアクセスと組み合わせ |
| MFA 対応 | ◎ 仮想/ハードウェア MFA | ◎ TOTP/FIDO2 | ◎ 非常に充実（Authenticator/FIDO2） |
| SSO / フェデレーション | AWS SSO / SAML / OIDC | SAML 2.0 / OIDC | Entra ID（Azure AD）が業界最強クラス |
| サービスアカウント | IAM Role for EC2/Lambda | Instance Principal / Resource Principal | Managed Identity（SystemAssigned/UserAssigned） |
| Entra ID 連携 | Azure AD ≒ 外部 IdP として利用可 | Entra ID 連携可能 | ネイティブ統合（最強） |
💡 Microsoft 環境との親和性では Azure が圧倒的
Windows Server・Microsoft 365・Active Directory をすでに使っている企業では、 Entra ID（旧 Azure AD）との統合が自然に実現できる Azure が IAM 運用の観点で最も効率的です。 AWS・OCI でも Entra ID を外部 IdP として連携させることは可能ですが、追加設定が必要です。
暗号化とキー管理
保存データ（at-rest）と転送データ（in-transit）の暗号化は、現代のクラウドでは標準機能として提供される。 重要なのは暗号化キーをどちらが管理するかという点だ。
| 暗号化の観点 | AWS | OCI | Azure |
|---|---|---|---|
| デフォルト暗号化 | 多くのサービスで標準有効 | ブロックボリューム等で標準有効 | ほぼ全サービスで標準有効 |
| マネージドキー管理 | AWS KMS | OCI Vault | Azure Key Vault |
| BYOK（顧客管理キー） | Customer Managed Keys（CMK） | Customer-Managed Encryption Key（CMEK） | Customer-Managed Keys（CMK） |
| HSM（専用ハードウェア） | AWS CloudHSM | OCI KMS（Dedicated HSM） | Azure Dedicated HSM / Managed HSM |
| 転送暗号化 | TLS 1.2+ 標準 | TLS 1.2+ 標準 | TLS 1.2+ 標準 |
ゼロトラストネットワーク対応
ゼロトラストアーキテクチャ（ZTA）は「ネットワーク境界を信頼しない」という原則で、 内部からのアクセスにも継続的な認証・認可を求める。クラウドはそもそも境界型セキュリティが 機能しにくい環境であり、ゼロトラストへの親和性が高い。
| ゼロトラスト要素 | AWS | OCI | Azure |
|---|---|---|---|
| マイクロセグメンテーション | Security Group / NACLs | Security List / NSG | NSG / Azure Firewall |
| サービスメッシュ | App Mesh / Istio on EKS | Istio 対応 | Azure Service Mesh / Istio on AKS |
| CASB・SASE | AWS Network Firewall + パートナー | パートナー連携 | Defender for Cloud Apps（CASB）が強力 |
| Private Endpoint | VPC Endpoint / PrivateLink | Service Gateway / Private Endpoint | Private Endpoint / Private Link |
| 脅威検知 | GuardDuty / Security Hub | Cloud Guard / Security Zones | Microsoft Defender for Cloud（非常に強力） |
コンプライアンス認証の比較
業種ごとに求められる認証・規格が異なる。日本の金融・医療・公共系では 特定の認証取得が必要になるケースが多い。
| 認証・規格 | AWS | OCI | Azure | 対象業種 |
|---|---|---|---|---|
| ISO 27001 / ISMS | ◎ | ◎ | ◎ | 全業種 |
| SOC 1 / SOC 2 / SOC 3 | ◎ | ◎ | ◎ | 全業種 |
| PCI DSS | ◎ | ◎ | ◎ | クレジットカード・EC |
| FISC（金融情報システムセンター） | ◎ 安全対策実装状況提供 | 〇 参照実装提供 | ◎ FISC対応ガイダンス | 日本の金融機関 |
| HIPAA | ◎（BAA締結可） | 〇 | ◎（BAA締結可） | 医療（米国） |
| ISMAP（政府情報システム） | ◎ 登録済み | ◎ 登録済み | ◎ 登録済み | 日本政府機関 |
| FedRAMP | ◎（米国政府） | △（一部） | ◎（米国政府） | 米国政府機関 |
| CSA STAR | ◎ | ◎ | ◎ | 全業種 |
✅ 日本の金融機関では FISC 対応確認が重要
日本の銀行・証券・保険会社がクラウドを採用する際、FISC 安全対策基準への準拠は 金融庁のガイダンス上も強く求められます。AWS・Azure はFISCガイドラインに対する 実装状況を詳細に公開しており、対応実績も豊富です。OCI は日本金融機関での採用実績が 増えていますが、AWS・Azure と比べるとドキュメントの充実度で差があります。
セキュリティ軸のまとめ
| 観点 | オンプレ | AWS | OCI | Azure |
|---|---|---|---|---|
| データ主権 | ◎ 完全制御 | 〇 リージョン固定可 | 〇 リージョン固定可 | 〇 Sovereign Cloud対応 |
| IAM の充実度 | △ 自前実装 | ◎ 非常に充実 | 〇 コンパートメント設計が独特 | ◎ Entra ID が最強（Microsoft環境） |
| ゼロトラスト対応 | △ 追加投資必要 | ◎ | 〇 | ◎ Defender連携が強力 |
| コンプライアンス認証数 | — 自社取得必要 | ◎ 最多（140+） | 〇（成長中） | ◎（100+） |
| 日本の金融対応 | ◎ | ◎ FISC対応充実 | 〇 増加中 | ◎ FISC対応充実 |
✅ 次の章では…
PART 05 では 可用性・DR（Disaster Recovery） を比較します。 SLA の数字の意味・マルチAZ/マルチリージョン構成・RTO/RPO 目標の達成方法を解説します。