EN

メールマガジン登録
資料ダウンロード
お問い合わせ

NRIセキュア ブログ

クラウドセキュリティの勘所|責任範囲の「ポテンヒット」を防げ

目次

    Businessman hand working with a Cloud Computing diagram on the new computer interface as concept

     企業におけるクラウドサービスの利用が当たり前になった昨今、導入前に「チェックリストによるセキュリティアセスメント」を行う手法は⼀般的になりつつあります。一方で、クラウドサービスの内容や用途が多様化する中で、果たして今のままのアセスメント手法で対応は十分なのでしょうか?

     

     クラウドサービスのチェックリストとアセスメントのプロセスを準備したことで安心していると、関係者の誰も把握していない責任範囲の『ポテンヒット』という落とし穴が待っています。

     

     本記事ではクラウドサービスのセキュリティアセスメントで陥りがちな落とし穴について、アセスメント実務の現場での実例を挙げながら解説します。

     

    日本企業におけるクラウドサービスの動向

     2006年、当時GoogleCEOであったエリック・シュミットが初めて「クラウドコンピューティング」と発言してから約10年。

     

     クラウドの概念が急速に認知され、システムを構築する際にクラウドを第一に検討・採用する「クラウドファースト」という考え方も広く浸透しました。

     

     日本でも業務効率化や導入容易性、またコスト削減等を目的として、クラウドサービスを積極的に導入または検討する企業が増えてきています。当社の調査結果では、82.6%の企業でOffice36577.1%の企業でDropBoxの利用が確認されています。

     

    クラウド利用の割合

    図.主なクラウドサービスの利用企業割合の推移

    (NRIセキュア 「サイバーセキュリティ傾向分析レポート2018」)

     

     クラウドサービスの利用が⼀般的になったことは、企業のビジネス部門にとって競争力向上のために喜ばしいことです。低コストかつ簡易なプロセスで使い始めることができるクラウドサービスは、近年広がりつつあるビジネス部門主導のITプロジェクトとの親和性が高く、ビジネス部門によるIT支出・利用の拡大というトレンドを力強く後押ししています。

     

     一方で、各企業の情報セキュリティ部門にとっては、システムを自ら管理する環境から外部の他社サービスで管理する環境に移行することになるため、情報セキュリティ面での細やかな目配り・配慮が⼀層重要になります。

     

     情報セキュリティ対策が不十分なクラウドサービスの導入が行われることのないよう、適切な選定基準を策定することがその第⼀歩となります。

     

     最近では「CASB (Cloud Access Security Broker)」というソリューションにより、クラウドのセキュリティリスクを、全社側で可視化してコントロールすることが、ある程度は可能となりました。しかしあらゆる状況に対して万能なソリューションというものはありません。リスクを最小化するためには、社内で共通のクラウドサービスの選定基準を定義するなど、選定・導入に関する「プロセス」を整備することは必須となるでしょう。

     

     

    シャドーITへの対策が難しい3つの理由|クラウド時代のセキュリティ管理 

    クラウドサービスのアセスメントに関する盲点

     クラウドサービスの形態は利用者とクラウド事業者が責任を持つ範囲の違いから、⼀般的に大きく3つに分類できます。本記事では、インフラからアプリケーションまでがクラウド事業者から⼀括して提供される 『SaaS』 と、クラウド事業者が提供するインフラ/プラットフォーム上でユーザーが自由にアプリケーションを開発できる 『IaaS/PaaS』、の 2つに分けて解説します。

     

    クラウドサービス形態毎の責任範囲の違い

     図. クラウドサービス形態毎のサービス提供の責任範囲の違い

     

     クラウドサービスは、データをインターネット経由で外部に預けるというサービスの性質上、十分なセキュリティ対策を実施している事業者を選定することが重要です。そのため、アセスメントの現場では事業者責任範囲(上図の点線部分)を対象として、社内の選定基準と適合しているかを確認します。

     

     その際、どのようなクラウドサービスでもアセスメントができるよう、網羅的で標準化された項目からなるチェックリストを準備する手法が⼀般的です。クラウド利用の形態が多様化し、迅速な選定プロセスが同時に求められている時代背景において、実に理にかなったアプローチと⾔えます。

     

     しかし、ここに落とし穴があるのです。事業者や利用者から提出されるチェックシートを単純に精査するアセスメントだけでは、本来把握すべきリスクの抜け漏れが生じる事例があります。

     

     これは従来のオンプレミスと比較して、クラウドサービスの責任範囲について利用者側で誤認識があることによって責任範囲のポテンヒットが生じることが原因です。

     

    この責任範囲のポテンヒットは大きく以下の2つに分けることができます。

     

    「管理コンソールに関する責任範囲の誤認識」

    「クラウドサービスで提供されるセキュリティ機能の責任範囲の誤認識」

     

    それではこの2つのポテンヒットをもう少し詳しく見ていきましょう。

    ポテンヒット① 管理コンソールに関する責任範囲の誤認識

     クラウドサービスのセキュリティは、「クラウド事業者」が管理責任を負う部分と、「クラウド利用者」が管理責任を負う部分で分けて考えたときに、以下のような三層構造で表現することができます。この三層構造に対して網羅的にセキュリティ対策状況を確認する必要があり、特に第二層目は、クラウド利用者の管理者によるコンソールの操作ミス等によってインシデントにつながるリスクがあります。

     

    クラウドサービスの三層構造

    図. クラウドサービスの三層構造

     

     管理コンソールは利用者にとってクラウドサービスを簡易に操作できる大変に便利なツールなのですが、その高い利便性が故に⼀つの操作ミスによって、すぐに影響の大きなインシデントに繋がるリスクがあります。

     

    例えば、

     

    ・本来クローズドな環境を想定していたシステムがクリック1回でインターネット上に公開されてしまう

    ・大量のデータがクリック1 回で特定の環境にダウンロードできてしまう

     

    といったケースが考えられます。

     

     当該リスクの重大性と⽐較して、利用者側、特に開発者の管理コンソールに対するリスク認識が⼗分に浸透しておらず、その結果として適切に管理されていないケースがありました。

     

     本来、管理コンソールは利⽤者が主体的に管理すべきものなのですが、当該機能自体はクラウド事業者が開発し提供しているため、クラウド事業者によりセキュリティが担保されていると誤認識したことが原因の⼀つと考えられます。少なくとも、第三層目と比較をして、管理主体としての当事者意識が希薄になりがちな点を見逃してはいけません。

     

    管理コンソールに関するリスクを排除するために情報セキュリティ部門は、

     

    ①平時より管理コンソールに対する対策重要性について社内の開発者に啓蒙すること

    ②アセスメントの際に管理コンソールに関する利用者の対策状況を入念に確認すること

     

    この2点が重要です。

     

    Closeup of young man in glasses with beard making blueprints on computer

    ポテンヒット② クラウドで提供されるセキュリティ機能の誤認識

     第二のポテンヒットは、クラウドサービスで提供されるセキュリティ機能が事業者によって異なるために発生します。

     

    ここでは、IaaS/PaaSでシステムを構築する際の代表的なサービスであるAmazon Web Services(以下 AWS)、Microsoft Azure以下 Azure)を例として考えてみます。

     

     これらの2つのサービスでは、システムを強固に防御するための様々なセキュリティ機能のオプションが提供されていいます。例えば、データバックアップ機能、データ暗号化機能、 ログ管理機能、アクセス制御機能等です。これらの機能のお陰で、IaaS/PaaS上で実際にシステムを構築する利用者側の開発者は、セキュリティ機能の詳細な実装を意識せずに開発に集中できるというメリットがあります。

     

     しかし、現在提供されるAWSAzure 以外のクラウドサービスでは、これらのセキュリティ機能のオプションが提供されていない場合も多いです。そのようなクラウドサービスを利用するケースにおいて、利用者側で「セキュリティ機能は事業者側で提供されるので、システム開発の際に意識する必要はない」と間違って認識していた場合、必要なセキュリティ機能が実装されないことになります。

     

     さらにアセスメントする情報セキュリティ部門でもその事実を把握できない可能性もあります。「データ暗号化機能」を例に、実際のアセスメント現場で生じた事例を見てみましょう。

     

     あるクラウド利用者の企業において、AWS/Azure 以外のクラウドサービスを利用してシステムを構築することになりました。情報セキュリティ部門は、当該サービスの事業者と社内の開発者の双方にチェックリストへの回答を依頼する形でアセスメントを行いました。

     

     その結果、当該サービスの事業者からは「データ暗号化については利用者の責任範囲」との回答があり、一方の社内の開発者は「データの暗号化は事業者が実装しているので対応予定なし」という回答をしていました。

     

     情報セキュリティ部門はアセスメントの際に事業者と利用者の双方の回答を付き合わせていたので、認識のギャップを確認でき、利用者側にデータ暗号化機能をアプリケーション側で実装することを指示することができましたが、危うく全てのデータがクラウドサービス上に平文で保管されたままリリースされるところでした。

     

     以上の事例のように、クラウドサービスが提供するセキュリティ機能が事業者によって異なることが、ポテンヒットの原因になります。

     

    このようなケースを防止するためには、

     

    ①利用するクラウドサービスにどのようなセキュリティ機能が実装されているか明示的に確認すること

    ②チェックリストによるアセスメント時に利用者、事業者双方の回答を統合して能動的に精査すること

     

    の2点が重要です。

     

    Business man pointing the text Checklist-1

    おわりに

     クラウドサービスが普及し、それに伴い自社内にクラウド利活用のノウハウ・ナレッジが溜まっていくことは、迅速な事業スピードが求められる現代において、大変望ましいことです。

     

     しかし、リスク評価プロセスを安易に、サービス毎の差異を考慮することなく、ショートカットすることは大変危険です。それは過去に発生したセキュリティ事故で、担当者が「できているはず」という勘違いが、セキュリティリスクの発見・是正を阻んでいたことからも明らかです。

     

     当社では、企業における旺盛なクラウド需要に対応するための、効率的かつ実効的なセキュリティアセスメントの実行支援を提供しています。現在行っている対応が網羅的な対処をできているか分からずお困りの場合は、ぜひご相談ください。

     

    新規CTA