明確なオーナーを持たない部門横断的なチームで仕事をしたことがある人なら誰でも知っているように、「共有」責任や、「共同」責任は、しばしば、誰かが問題を処理していると思い込んでいることを意味します。チーム間に明確な取り組みがなければ、常に何かの問題が見落とされます。
責任共有モデルとクラウドサービスプロバイダー
クラウドサービスの「責任共有」モデルは、次のようなものです。
クラウドプロバイダーは、あるレベル以下のすべてのものを保護し（そのレベルとは一般に自社のソフトウェアのこと）、その保護に責任を持ちます。 これを家の土台に例えて考えてみましょう。 クラウド利用者であるあなたは、基礎の上にあるすべてのものを保護する、いわば家を守る責任があるのです。
しかし、家を見たことがある人なら、基礎とその上にあるものの間に必要なものを分ける単純な線が引けるわけではないことに気づくでしょう。 クラウドプラットフォームとその上で動作するアプリケーションの相互接続も同様です。
クラウドの設定ミスや複雑なツール
クラウドサービスをどのように設定するかは、その上で動作するアプリケーションの安全性に大きく影響します。 パブリッククラウドで構築していますか？ Lambda関数を一般に公開していませんか？ データレイクでLake Formationのアクセス制御を有効にしていないのでは？ AzureSqlDBServerで高度なデータセキュリティを有効にしていますか？GCPのクラウド関数で、パブリックな呼び出し権限があるものがないですか？
この問題は、IaaS(Infrastructure-as-a-Service)のパブリッククラウドサービスにとどまりません。 DDoS防御のためにコンテンツ配信ネットワークを使用している場合、オリジンのホスト名を予測不可能にすることを忘れてはいませんか？ SaaSサービス間のビジネス・アプリケーション・メッシュを統合する際、例えば財務部門だけが必要とするAPIを、誤ってどのユーザーにも呼び出させてはいないだろうか。
クラウド利用者が足元をすくわれる可能性は、たくさんあります。進んだクラウド・プラットフォームは、こうした見落としを少なくし、デフォルトの設定にならないようにするために多くのエネルギーを投入しています。 しかし、すべてのクラウド・サービスにおいて完璧なプロバイダーは無く、すべてのクラウド・プラットフォームが自社のシステムを安全に使用できるようにしているわけではありません。 さらに残念なことに、クラウドサービス提供者は、安全でないさまざまな設定の選択について顧客に伝えるインセンティブがないのです。
皮肉なことに、最も多くのセキュリティ・サービスを顧客に提供しているクラウド・プラットフォームは、そのサービスを利用する上で最も複雑な状況を生み出していることが多いです。 各ツールキットを正しく使用するには十分な知識が必要なため、クラウド・サービスを正しく設定するためのサービスを販売するビジネスが存在するほどです。
クラウドセキュリティを向上させるために
もしクラウド利用者がベンダーに、"これらのサービスの最も危険な使用方法と構成は何か？"と尋ねる方法があればいいのですが......。
残念ながら、ほとんどのクラウド利用者は、自社のクラウド・サービスの利用に焦点を当てるのではなく、ベンダーが正しく設定されているかどうかを確認するために、NIST CSFやBITS SIGに基づく質問を巨大なスプレッドシートで質問票にしてベンダーに回答させているのが実情です。
クラウド利用者はサードパーティのリスク管理プロセスを利用して、自社のセキュリティについて洞察に満ちた質問を始めるべき時なのかもしれません。
責任共有モデルで言えば、クラウドプロバイダーが素敵なズボンを履いていても、ベルトの締め方やシャツのサイズがクラウド利用者に完璧にフィットする可能性は低く、風通しが悪くなる服装だったり、最悪の場合、不愉快な姿をさらすことになり、それが責任共有モデルのクラウドサービスが意味するところとなります。
出典：The cloud security emperor has no pants
