やるべきはツール導入の前に、セキュアな構成管理の徹底
さて、先述した2つのセキュリティ侵害事例は、いずれも「ユーザー側が適切な設定を施すべき立場であり、それを実施していないユーザー側の責任である」と考えられている。その点をいくつかの視点で紐解いていきたい。
まず、皆さんもおなじみのクラウドサービスにおける責任共有モデル（Shared Responsibility）を振り返ってみよう。図4は、総務省の『地方公共団体における情報セキュリティポリシーに関するガイドライン』（令和7年3月版）に掲載されている 、クラウドサービス事業者の責任（Responsibility）に関する一般的な考え方を表した図である。
先に述べた事例のうち、SaaSとして提供されているSalesforceでは、データ部分のみがユーザーの責任（Responsibility）範囲になっている。一方、AWSのS3はPaaSであるため、データとアプリケーションのみがユーザーの責任（Responsibility）範囲とされている。
ここで改めて考えてほしいのは、“Responsibility”の意味である。一般的には「責任」と訳されてしまうのだが、日本語でいうところの責任は、正しくは“Liability”であり、Responsibilityは「行動でサポートすること」という意味で解釈されるべきだ。
この考え方からすれば、SaaSであるSalesforceは、提供するアプリケーション・サービスのセキュアな設計・初期設定はSalesforce, Inc.が提供すべきで、“行動でサポートする範囲（Responsibility）”であると理解できる。
2019年に同社がAuraフレームワークをリリースした当初は、これを介したゲストユーザーのアクセス権限が、デフォルトでは比較的緩い設定でリリースされていた。当時、これに気付ける顧客は少なかったのではないかと想像する。仮に気付けたとしても、カスタマイズ性が高く、高度な運用知識やAuraセキュリティの知識を持ち合わせている顧客でなければ、アクセス制御の変更を自ら実施するのは難しかったのではないだろうか。この状態が、2020年初頭まで続いていたようだ。
その後、Salesforce, Inc.は2020年春以降、ゲストユーザーのアクセス権限を厳格に制御する方針を発表し、「Critical Update（重要な更新）」として顧客に注意喚起を開始した。なお、楽天の情報漏えいは2020年の年末に発覚している。この情報漏えいはいつから不正アクセスされ、いつから顧客情報が搾取されていたのか定かではない。
AWSの場合はどうか。S3のバケットはプライベートがデフォルトであった。バケットポリシーやアクセス制御リストによって容易にパブリックに変更できる設計ではあったが、利用者側が利便性や柔軟性を重視した結果、セキュリティ設定を誤るリスクが内在していた。
2017年以前は、多くのバケットが誤って公開設定され、FedEx、Verizon、Dow Jonesなどで情報漏えいが発生した。2018年には、AWS側がS3 Block Public Access機能を導入し、アカウントレベルやバケットレベルですべてのパブリックアクセスを遮断できるようにした。しかし、2019年から2020年にかけても、設定ミスによるインシデントは継続。やがて2021年以降、S3構成ミスを検出・修正するサードパーティ製品がリリースされると、それらの導入が広がっていった。
この2つの事例における、“行動でサポートする範囲（Responsibility）”の所在を改めて考えてみたい。SaaSであるSalesforceの場合は、Salesforce, Inc.側の行動でサポートすべき部分が大きいように思われる。しかし、責任共有の考え方からいえば、「セキュリティ・バイ・デフォルト」の原則を順守し、SaaS機能のアップデート時にユーザー側でのセキュアな構成管理が可能になるよう、「オンデマンドセルフサービスを提供する」ことがクラウド事業者のResponsibilityとなる。同時にユーザー側にも、当該SaaSが期待しているセキュアな構成になっているかを自ら確認するResponsibilityが求められる。
AWSの場合はPaaS/IaaSであるため、Responsibilityの分界点からいえば、設定変更の主体はユーザー側となる。ただし先述のとおり、S3バケットの誤った情報公開による漏えい事故はなかなか減らなかった。この背景には、当初のS3のセキュリティ設定や運用の複雑さもあった。
これを受けて、AWS側も本課題に対して2018年のS3セキュリティ強化や、2019年6月のAWS Control Tower（複数のAWSアカウントをセキュアかつスケーラブルに管理し、ガバナンスさせるための統合基盤）のリリースなどを通じて、S３バケット問題を未然に防ぐためのセキュリティ機能の強化を行ってきている。このように、AWS側もセキュリティ・バイ・デフォルトの原則に則って機能強化を行ってきたことは、Responsibilityの表れであると想像する。
まとめると、SalesforceのようなSaaSの事例を未然に防ぐためには、ユーザー側がセキュリティ・バイ・デフォルトな構成管理を遵守していくことが何より重要だったのではないかといえる。責任共有の観点から見れば、運用責任は常にユーザー側にある。一方、クラウド事業者のResponsibilityは、セキュリティ・バイ・デフォルトの原則のもとで安全な状態を初期設定時に提供することにある。継続利用の場合はその限りではないのだが、ユーザー側の視点で構成状態が“セキュアでない状態”に陥る可能性が高い場合には、積極的に注意喚起を行うことになる。
AWSと同じようなPaaS/IaaSにおける事象では、ベンダー側もさることながら、ユーザー側でもセキュリティ・バイ・デフォルトな構成管理を遵守していくことが重要だ。ベンダー側によるUIの仕様変更によってプライベートのACL権限が有効になってしまっているのは、ベンダー側のResponsibilityであるため、注意喚起を行わなければならない。
こうした仕様の変更が小刻みに行われるクラウドサービスにおいては、ユーザー側もセキュリティ・バイ・デフォルトな構成管理から逸脱された仕様のまま運用が開始されないように、それらを監視する仕組みが必要だ。また、ユーザー側の管理者が変更や退職になった場合などは特に注意が必要だ。ユーザー側が自らACLなどの設定を誤り、過剰な権限付与をしてしまう場合もある。気付けなければ、公開してはいけない機密情報が公開されてしまう恐れがある。こうしたリスクを、人手に寄らず常時監視しておく役割を担う製品がCSPMというわけだ。
