設定ミスによる情報漏えい発生。あなたはどちらの担当者タイプ?
楽天、PayPayがSalesforceの設定ミスによって情報漏えいが発生した。ネット上では「設定ミスは怖い。自分も気をつけないと」という「利用者側も気をつけるべき」という声と、「セールスフォースが悪い」とする声が見られた。もし、自分が当事者だとしたら、あなたはどちらのパターンだろうか?
■管理者視点でどちらの担当者が好ましいか?
「御社が利用しているクラウドで情報漏えいが発生していますよ」。ある日突然そんな情報提供が届いたら、自社としてどう対応するだろうか?
通常、こういった情報提供があった場合には、対象クラウドサービスを調査し、情報漏えいの事実があったかを確認することになる。そして、本当に情報漏えいが発生していれば、情報漏えいの範囲や不正アクセスの有無、流出したデータの所有者に報告を行うことになる。
そして、情報漏えいの「原因調査」と「再発防止策」を検討することになる。このプロセスを実行する担当者AとBが存在したとする。しかし、二人の見解は全く異なるものになっていた。
真面目なAは、原因報告で「リリースノートを見落としていたこと、アクセス権限の不備があった」ことを認め、素直に謝罪した。
一方、普段からセキュリテイに詳しいと自負しているBは気が強いことでも知られている。Bは「セールスフォースが一方的に仕様変更したみたいなんです!リリースノートに書いてあったとか言ってるんですけど、リリースノートなんてしょっちゅう出てるし、あんなの見てる人間なんて居ませんよ!勝手に仕様を変えたセールスフォースが悪い!」と、あくまでセールスフォースが悪いと主張してきた。
そして、再発防止策の提示を求めると、Aは素直に「アクセス権限の見直しを早急に行います。リリースノートも今後は業務の一部として考え目を通すようにし、特にアクセス権限のような重要な変更があったさいには、メーカーにも確認するようにします。」と再発防止策を提示した。
一方Bは、相変わらず「セールスフォースが悪い」という主張を譲らず「勝手に仕様変更するようなSaaSは解約した方が良いです!」とまで言い出した。しかし、セールスフォースは経営企画室主体で導入しているため、セキュリテイ推進室の判断でサービスの解約等簡単に実現出来るわけもないし、代替案を検討する時間も予算もない。
セールスフォースの利用は今後も継続しなければならない。セールスフォースのセキュリティ強化を今後強化するとした場合、あなたが管理者だとした場合、担当者AとBのどちらに担当させたいだろうか?
■現実社会では殆どがAタイプ。ネットではBの意見が目立つ
当然のことながら、殆どの人が担当者Aを好むだろう。実際重要なシステムの担当者はAタイプであることが殆どであり、Bタイプは現実社会では出会ったことがない。
ところが、今回の騒動でネットでは「B担当者タイプ」の意見が一定の支持を得ているように見えた。そもそも、セールスフォースのどのような設定ミスが原因であり、なぜそのミスが発生したかは具体的に明らかになっているわけではないのだが…。
■オンプレミス時代には担当者Bでも通じたかもしれない
なぜ、B担当者の意見に支持が集まるのか?ひょっとすると、全てを自前で作っていたオンプレミス時代のシステム担当者はこういった考えの人がある程度存在していたのかもしれない。
オンプレミスが主流であった時代には、ハードウェアを買取り、システムをインストールして、自分たちで作り、自分たちが仕様変更しない限りは、仕様が変わらないのが当たり前だった。
そのような時代を経験してきた人達にとっては「勝手に仕様を変更するとは何事だ!」となるのかもしれない。
■クラウドは所有ではなく利用であり、仕様変更対応もユーザ責任
「クラウドは所有はなく利用」と良く言われるとおり、クラウドは他社が運用するサービスを利用することになる。
例えば映画を見る行為に例えると、自宅でホームシアターを作り自分のスタイルで映画を視聴するのがオンプレミスのシステムだ。自宅のホームシアターでは食べ物や飲み物、大声を出して笑ったり泣いたりするのは全て自由に出来る。
一方、クラウドは映画館で映画を見る行為に似ている。映画館で映画を見るには、視聴料を支払い映画館のルールに従う必要がある。映画チケットの申込時に「マスク着用が必須」と記載があったのにマスクを忘れた結果、視聴を断られたとしても、それは視聴者側の落ち度となる。
映画を見るという目的はどちらでも達成出来るが、全てを自由に出来るホームシアター(オンプレミス)とは異なり、映画館で決められた映画のみ視聴する(クラウド)場合では映画館のルールに従う必要がある。
映画館で快適な時間を過ごすためには、映画館は一定品質のサービスを提供する責任があるし、視聴する側もルールを守る責任がある。こういった両者で「責任を共有する」ことを「責任共有モデル」と呼び、クラウドセキュリテイの基礎となる。
常に最新技術を利用出来るのがクラウドのメリットであるが、裏を返せば機能追加や仕様変更も頻繁に発生する意味する。こういった仕様変更等に追随することは勿論大変だが、若い優秀なエンジニア程「責任共有モデル」の意味を理解し、最新の技術をキャッチアップすることに余念が無いだろう。
こういった若い優秀なエンジニアが多いAWS等のIaaS系のエンジニアにとって「責任共有モデル」という言葉は既に定着していると思う。
しかし、セールスフォースのようなSaaSは「責任共有モデル」のユーザの責任範囲がIaaSと比較して少なくなるため、ベンダー依存傾向のユーザーがIaaS系と比較して多いのかもしれない。
アクセス権限を設定する機能を提供するのが「セールスフォースの責任」であり、その機能を正しく設定するのは「ユーザー側の責任」だ。
今回、設定ミスが発生したのがたまたまセールスフォースだっただけであり、AWSやMS365では昔から頻繁に起きている事故なので、クラウドを活用していこうと考えているのなら他人事と考えず「責任共有モデル」の理解を深めることを推奨する。
■セールスフォースの設定ミスは今後も発見される可能性も
筆者がクラウドセキュリテイに従事し始めたのは2017年からであり、そこからクラウド系の情報漏えいは観察してきた。2017年頃に多かったのはAWSのS3の設定ミスであり、これは今でも変わらずIaaS上に意図せず公開されているデータベースが最も多い。
次にあるのがMS365であり、OneDriveやTeamsに起因した意図せぬ情報漏えいの報道を時折見かける。あまり報道ないが、Box等のクラウドストレージの共有リンクが意図せず公開されているといったケースもある。
筆者が観測してきた中ではSalesforceの設定ミスによる情報漏えいはこれまで見たことがなかった。(SalesforceのEC系サービスを利用しているユーザ不正アクセスを受けたといのはあったが、これは設定ミスではなく、単なる不正アクセスだった。)恐らく、楽天とPayPayが世界で初めてSalesforceの設定ミスによる情報漏えい事例として報道されたケースになるのではないだろうか。
ポイントは何故、今まで全く発見されることのなかったSalesforceの設定ミスが、相次いで発見され出したのか?という点だ。
関係があるかは分からないが、2020年10月にSalesforceのゲストユーザーの設定ミスが存在するサイトを検出する手法が公開され、セキュリテイ専門家の間で話題になっていた。楽天が外部から指摘を受けたのが2020年11月24日、PayPayが12月1日と、何れも10月以降なので、前述した手法によって判明した可能性も疑われる。
そして、この検出手法によって発見されたのであれば、他にも検出された企業が存在するしれない。※現時点では楽天、PayPayの詳細が明らかになっていないので筆者の推測にすぎない。
自社の設定が不安な企業は、セールスフォースに相談することを推奨する。
■関連記事
