副題:「任せた部分」と「残る部分」を見極める

想定読者:CISO、クラウドCoE、IT企画、システムオーナー、リスク管理

勘定系の周辺システム、営業支援、メール、文書管理。金融機関でもクラウドやSaaSの利用は当たり前になりました。それでも社内では、「大手のクラウドに預けたのだから安全だ」という声と、「クラウドは危ないから使うべきでない」という声が、いまだに交錯しています。どちらも正しくありません。本稿では、クラウドに移すとセキュリティの責任がどう変わり、何が自組織に残るのかを整理します。

1. 責任共有モデル ― 任せられるのは「土台」まで

クラウドのセキュリティは、事業者と利用者が責任を分け合う責任共有モデル(Shared Responsibility Model)で考えます。事業者はクラウド基盤そのものを守り、利用者はその上に置いたものを守ります。

どこまでを事業者に任せられるかは、利用形態によって変わります。Microsoftが公開している責任分担を整理すると、次のようになります。

層

オンプレミス

IaaS

PaaS

SaaS

物理基盤・データセンター

自組織

事業者

事業者

事業者

OS

自組織

自組織

事業者

事業者

ネットワーク制御

自組織

自組織

共有

事業者

アプリケーション

自組織

自組織

共有

共有

端末

自組織

自組織

自組織

共有

ID・利用者

自組織

自組織

自組織

自組織

データ

自組織

自組織

自組織

自組織

SaaSに近づくほど事業者に任せる範囲は広がります。しかし、表の下の2行はどの形態でも変わりません。

2. どの形態でも利用者に残る4つの責任

図1 責任共有モデル ― 形態が変わっても利用者に残る責任(© ProSol)

Microsoftは、利用形態にかかわらず利用者が常に負う責任として次の4つを挙げています。

  • データ:分類、保護、暗号化の判断、データガバナンスへの準拠
  • 端末:クラウドにアクセスするPCやスマートフォンの保護
  • アカウント:利用者アカウントの作成、管理、削除
  • アクセス管理:権限の設計、多要素認証、条件付きアクセス

つまり、誰が、どのデータに、どこから、どの権限でアクセスできるかは、クラウドに移しても自組織が決めて管理し続けなければなりません。次回詳しく扱いますが、クラウドの事故の多くはまさにこの領域で起きています。

3. SaaSほど「見えにくく」なる

SaaSは任せる範囲が広いぶん、運用は楽になります。一方で、注意すべき点が増えます。

  • 設定と共有は利用者の責任:外部共有の範囲や公開設定を誤れば、事業者の基盤が堅牢でも情報は漏れます。
  • 仕様は事業者の都合で変わる:機能の追加や既定値の変更で、守っていたはずの設定が変わることがあります。
  • 部門が勝手に使い始める:申し込みが容易なため、承認されていないSaaS(シャドーIT)が生まれやすくなります。

4. 金融庁ガイドラインが求めること

2024年10月の金融庁「金融分野におけるサイバーセキュリティに関するガイドライン」は、クラウドサービス利用時の対策を独立した項目として定めています。

テーマ

ガイドラインの主な記載

責任の範囲

責任共有モデルを理解し、クラウド事業者との責任範囲等を明確にする(基本的な対応事項)

設定の確認

情報公開等の設定にミスがないか確認する(基本的な対応事項)

仕様の変更

責任分界に応じて、サービス仕様が変わる際には影響を確認する(基本的な対応事項)

利用終了時

利用終了時のクラウド上のデータの取扱い(論理的な廃棄)を確認する(基本的な対応事項)

監視

責任分界に応じて、監視の対象にクラウドサービスも含める(基本的な対応事項)

シャドーIT

未承認のクラウドサービスの利用を特定し、適切に対応する(対応が望ましい事項)

さらにサードパーティリスク管理の項目では、重要度に応じて、契約やSLAに役割分担・責任分界、監査権限、第三者保証報告書の提出などを明記することを求めています。Series 02で扱った外部委託先の管理の考え方が、クラウドにもそのまま当てはまります。

5. 委託しても移らない「ガバナンス責任」

運用の作業はクラウド事業者に任せられても、顧客と当局に対する説明責任は金融機関に残ります。具体的には、次のような責任です。

  • クラウドに何を載せるかを、リスク評価に基づいて決め、承認する責任
  • 事業者の統制が機能していることを、第三者保証報告書などで確認する責任
  • 事業者で障害が起きても、重要業務を継続する責任
  • 利用をやめるとき、データを確実に引き取り、消去させる責任

このうち、障害時の継続と撤退(Exit)は、第3回で詳しく扱います。

6. 責任分界表を作る

責任共有モデルを「理解する」だけでは不十分です。システムごとに、誰が何をするのかを表にして合意しておきます。

項目

確認すること

IDと権限

管理者権限を誰が持ち、誰が定期的に棚卸しするか

設定の監視

公開設定や共有設定の誤りを、誰がどう検出するか

ログ

どのログを、どれだけの期間、誰が保管し監視するか

暗号鍵

鍵を事業者と自組織のどちらが管理するか

バックアップと復元

誤削除やランサムウェアからの復元を、誰の責任で、どこまで行えるか(契約により異なる)

インシデント

事業者側で事故が起きたとき、いつ、どの範囲まで通知されるか

社内でも、クラウドの共通基盤を担う部署、システムオーナー、セキュリティ部門の間で責任を分けておかないと、「事業者がやっているはず」「隣の部署がやっているはず」という空白が生まれます。

まとめ

クラウドに移して任せられるのは、物理基盤やOSといった土台の運用です。データ、ID、アクセス管理、端末、そしてガバナンスの責任は、どの形態でも自組織に残ります。「クラウドだから安全」でも「クラウドだから危険」でもなく、残る責任を見極めて管理できるかが問われています。

次回は、クラウド事故の主因であるID、設定、データの典型的なリスクと対策を扱います。

主要出典

  1. Microsoft「Shared responsibility in the cloud」
  2. 金融庁「金融分野におけるサイバーセキュリティに関するガイドライン」(2024年10月)
  3. FISC(安全対策基準 第14版の告知)

本記事は公開情報に基づく一般的な解説です。責任分担は事業者、サービス、契約によって異なります。実際の責任範囲は、各事業者の公開情報と契約内容で確認してください。