SERIES
Series 10｜金融機関のクラウド・SaaSリスク管理
全3回中3回・更新中
クラウドを使うかどうかは、もはや論点ではありません。問うべきは、クラウドやSaaSに移したあとも残る責任を、誰がどう管理するかです。事故の多くは基盤の脆弱性ではなく、利用者側のID管理、設定ミス、データの扱いから起きています。本シリーズでは、責任共有モデルから見た金融機関に残る責任、クラウド固有の典型リスクと対策、そして大規模障害や特定事業者への集中、撤退（Exit）まで含めたレジリエンスの設計を、全3回で解説します。
このシリーズの記事
- 第1クラウドに移すとセキュリティ責任はどう変わるのか「大手のクラウドに預けたから安全」も「クラウドは危ないから使わない」も、どちらも正しくありません。クラウドに移して任せられるのは物理基盤やOSといった土台の運用までで、データ、ID、アクセス管理、端末の責任は、どの利用形態でも自組織に残ります。本稿では、IaaS・PaaS・SaaSで変わる責任共有モデルの境界、SaaS特有の見えにくさ、金融庁ガイドラインが求めるクラウド利用時の対策、委託しても移らないガバナンス責任、そして責任分界表の作り方を解説します。
- 第2クラウド事故の主因は「脆弱性」よりID・設定・データにある2024年、クラウドデータサービスの利用企業約165組織が攻撃の影響を受けました。しかし基盤は破られていません。原因は、多要素認証のないアカウントと、何年も変更されていなかった盗まれた認証情報でした。本稿では、クラウドの脅威の上位が設定ミスとID管理である現実を示し、過剰な権限、弱い認証、公開設定の誤り、秘密情報、SaaSの共有設定、監査ログ不足という6つの典型リスクとコントロール、そして継続的な「態勢の管理」への転換を解説します。
- 第3クラウド障害・Exit Strategy・集中リスクをどう管理するか2025年10月、AWSの米国東部リージョンで約14時間半に及ぶ障害が起き、依存する多くのサービスに連鎖しました。どれほど大きな事業者でも止まります。本稿では、事業者の障害、特定事業者への集中、撤退（Exit）という自組織だけでは防げない3つのリスクを整理し、重要業務の耐性度に応じた冗長化の選び方、契約前の集中度評価、DORAが求める出口戦略と撤退計画の項目、そして依存の洗い出しから演習までの進め方を解説します。