X

A blog about Oracle Technology Network Japan

クラウドセキュリティ責任共有モデルを明確にするための5つのステップ

Guest Author

※本記事は、Farah Mithaniによる"5 Steps Toward Clarity Around the Cloud Security Shared Responsibility Model"を翻訳したものです。

現代の脅威 2020年7月8日


企業のクラウドへの移行傾向は留まることを知らず、契約するクラウド・プロバイダの数も急速に増加しています。しかしそうした熱狂のなか、見落とされているものがひとつあります。 それがクラウド・セキュリティの共有責任モデルです。それどころか、オラクルとKPMGによる2020年度の脅威レポートであるOracle and KPMG Cloud Threat Report 2020によると、すべてのクラウド・サービスに対する共有責任モデルを完全に理解しているという人の割合が、2019年の18%から8%にまで減少していました。このような理解不足による混乱は、サイバー犯罪者にセキュリティ対策の穴を見つけられる要因にもなっています。つまりここがしっかりしていれば、クラウドのデータを保護できたかもしれません。

では、見落とされているものとは、具体的にどういうものなのでしょうか。たとえば、サブスクライバ・データを保護することはクラウド・プロバイダだけの責任ではないので、どの部分はクラウド・サービス・プロバイダ(CSP)が責任を持つべきで、担当者や企業、サブスクライバが責任を持つべきなのはどの部分なのかを把握しておく、という考え方も見落とされているもののひとつになります。責任がはっきりしないと、それはリスクにつながります。またセキュリティ侵害の件数が拡大していることからも、責任の所在をより明確にすることが極めて重要だということがわかります。

クラウド・セキュリティの共有責任モデルに、包括的なマニュアルはありません。これはクラウド・プロバイダやクラウド・サービスのタイプによって異なります。しかし、品質保証契約(SLA)について、そして個々のクラウド・サービス・プロバイダが責任を有するのはどの部分なのかについて、十分に議論をし、そのうえで契約書に署名をして、新しいクラウド・サービスをデプロイすること。それは誰もが実施できることです。

たとえば、ある担当者は、自身の仕事は自社のSaaSプラットフォームのデータ・セキュリティとアイデンティティ管理のみであり、それ以外の管理はクラウド・プロバイダの仕事だとおおまかに考えていたとしましょう。しかしクラウド・プロバイダの方は、そうした責任(およびその他も)は共有のものだと考えているかもしれません。

こうした混乱が具体的な問題に発展しても不思議ではありません。Oracle and KPMG Cloud Threat Report 2020では、回答者の約3分の2が、複数のベンダーが関与する自社のSaaSアプリケーションの共有責任モデルに大きな混乱が見られると答えていました。こうした理解不足があると、アクセスや構成におけるセキュリティ侵害の種が見落とされてしまうかもしれません。自社のクラウド・データはデフォルトで保護されていると無条件に仮定している企業も少なくありませんが、その仮定が常に正しいとは限りません。共有責任を適切に理解していないと、企業の財務情報や知的財産情報、顧客の個人情報を危険にさらすことにもなりかねないのです。

では、クラウド・プロバイダとの協働において、誰がどの部分に責任を有しているのかを適切に理解するには、どうすればよいのでしょうか。

 

1.クラウド・プロバイダとのコミュニケーションを絶やさない

クラウド・サービス・プロバイダは、クラウド・セキュリティ・プロバイダではありません。彼らのことは“クラウド・セキュリティ・パートナー”とみなすべきです。企業にも、クラウド・プロバイダにも、セキュリティ侵害を回避するという共通の目的があるからです。したがって企業は、主担当者がクラウド・プロバイダと常態的に協働していくことを義務付け、また企業自身も四半期に一度はクラウド・プロバイダとミーティングを持つようにする必要があります。これにより、クラウド・プロバイダがSLAに従っているかどうか、また契約や共有責任に変更が必要かどうかを把握しやすくなります。

 

2.社内に“セキュリティ・ファースト”の文化を醸成する

結局のところ、セキュリティで重要なのは従業員一人ひとりの行動です。そしてリモート・ワークが増えるなか、その重要性を感じる場面も増えています。だからこそ、脆弱性を回避するには、セキュリティ・ファーストの文化が不可欠なのです。また現在は、クラウド・ベンダーやクラウド・プラットフォーム、クラウド・アプリケーションの数もますます増えています。そのためIT部門が自社のセキュリティのすべてを監督しているような従来型モデルでは、いずれIT部門が限界を迎え、共有責任に隙間が生じてしまいます。

この問題に対処する主な方法は2つで、それはクラウド・セキュリティ・アーキテクト(CSA)の採用とビジネス情報セキュリティ・オフィサー(BISO)の採用です。CSAは、企業によるクラウド・セキュリティ戦略の構築を後押しすること、およびすべての事業部門がセキュリティ・ガイドラインを遵守するようにすることをその役割としています。BISOは、最高情報セキュリティ責任者と各事業部門との橋渡し役として、セキュリティ・ルールに関する事業部門とのコミュニケーション不足を補います。またBISOは、各事業部門の目的や目標を考慮しつつ、セキュリティ・ファーストを遂行していく役割も担います。

 

3.クラウド・セキュリティの共有責任モデルのエキスパートになる

企業は、共有責任モデルのエキスパートを採用し、その定着を図るなど、人材投資を実施する必要があります。またクラウド・セキュリティの共有責任モデルに関する専門知識を必要とするのはIT部門だけではないことも、理解する必要があります。誰もが自社のデータを保護する責任を負っていることを社内の一人ひとりが認識すべきなのです。そのためには、自社と顧客のデータの安全性およびセキュリティをそのアクセス方法を問わずどのように管理していくかについて、社内の全員に定期的なトレーニングを実施していく必要があるでしょう。

 

4.セキュリティを自動化する

自動化は非常に重要な要素です。これにより、反復的なプロセスや手作業を減らし、ITチームが他のタスクに注力できるようになるからです。また自動化を採用すれば、クラウド・セキュリティの共有責任モデルのエキスパートになれる従業員も増えることになります。自動化の例としては、自動化および機械学習を活用して不正アクセスが可能なエリアを特定し、その情報に基づいて是正措置を実施し、同様の構成を持つ他のプラットフォームやサービスにも不正アクセスの機会がないかを確認する、といったことがあります。さらに自動化では人的ミスのリスクを減らせるため、企業のセキュリティ上の隙間を防ぐことができます。

 

5.ビジネス詐欺にまつわるリスクを十分に理解する

Oracle and KPMG Cloud Threat Report 2020によると、回答者の39%に、過去2年以内にビジネス・メールによる不正アクセスで被害を受けた経験がありました。ビジネス・メールによる不正アクセスは攻撃手段として現在非常によく用いられています。またここから他の攻撃へと派生することもあります。具体的にいえば、すべての攻撃の91%が電子メールを起点としていました(昨年のレポートで紹介)。ビジネスクリティカルなアプリケーションが電子メールとつながっている場合、こうした攻撃は極めてリスクの高いものになります。したがって外部との接点にどのようなリスクがあるのか、そしてそれを回避するにはどのような施策をとるべきなのかを理解していくことが非常に重要になります。その点、Oracle and KPMG Cloud Threat Report 2020は、セキュリティ上の最新のトレンドを理解する非常に有益なソースになります。

共有責任は、クラウド・セキュリティのなかでも誤解している人の多い分野です。しかし社内全体でクラウド・セキュリティの共有責任モデルをしっかりと理解していくことができれば、セキュリティ上の不備や脆弱性の回避にも効果的でしょう。

組織は、幹部からエンドユーザーまで組織全体にセキュリティ・ファーストの意識が浸透するよう、継続的に努力していく必要があります。このような文化を醸成し、このモデルに関する知識を増やしていけば、次に来るかもしれない大規模なセキュリティ侵害から組織を保護することができるでしょう。クラウド・セキュリティの共有責任モデルに関する詳細は、Oracle and KPMG Cloud Threat Report 2020 series:Demystifying the Cloud Shared Responsibility Model(クラウドの共有責任モデルの解説)の2回目のレポートをご覧ください。

 
 

 

 

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.