このページの本文へ

パロアルトネットワークスが考える「マルチクラウド時代に必要なセキュリティ対策」 第1回

マルチクラウド化の進展でさらに管理が難しくなるクラウドセキュリティ

“パブリッククラウドならでは”のセキュリティ脅威と課題とは?

2019年01月09日 08時00分更新

文● 大塚昭彦/TECH.ASCII.jp

提供: パロアルトネットワークス

  • この記事をはてなブックマークに追加
  • 本文印刷

 パブリッククラウドサービスの活用は、企業においてもすでに当たり前のものとして定着した感がある。ITの新規導入やシステム更新時の移行先としてパブリッククラウドが有力な選択肢となり、クラウド利用を最優先に考える「クラウドファースト」戦略を標榜する企業も増えている。

 さらには新たな動きとして、複数ベンダーのクラウドサービスを適材適所で使い分ける「マルチクラウド化」も始まっている。こうした積極的かつ戦略的なクラウド活用の動きは、企業規模を問わずこれからも続くだろう。

 しかし実は、パブリッククラウドの活用が進むにつれて“パブリッククラウドならでは”とも言える新たなセキュリティ脅威やインシデントも発生し始めている。まず今回は、旧来のセキュリティ常識で考えていると見落としてしまいがちな、この脅威について考えてみたい。

「誰でも使える」クラウドが 引き起こすセキュリティリスク

 パブリッククラウドの大きなメリットのひとつが、「誰でもすぐに環境をセットアップし、使える」ことだ。たとえばIaaSの場合、管理画面にログインしてリソースサイズなどを指定するだけで、ほんの数分で新たなサーバー環境が利用可能になる。これまでのように社内のIT部門に依頼し、何日も(何週間も)待たされてやっと使えるという不便さがなくなるため、開発部門や業務部門などが直接クラウドサービスを契約し、部門自身でパブリッククラウドを利用、運用するケースも増えている。

 だが、この「誰でも使える簡単さ」というメリットは、他方ではリスクも招く。ITインフラやクラウドの高度なスキルを持たなくてもセットアップができ、使えてしまうため、そこにひそむセキュリティの“穴”を見逃してしまいがちなのだ。

 実際に、近年ではパブリッククラウドの「設定ミス」や「設定漏れ」に起因する大規模なセキュリティ事故が多発している。

 最もわかりやすい例は、クラウド上に保存された機密データに対するアクセス権限の設定ミスだ。すでに米国では、大手の通信事業者や出版社、地方自治体などにおいて、数百万~数千万人規模の個人情報データが、URLさえ知っていれば誰でもアクセスできる「公開」状態でさらされていたという事故が報告されている。おそらくこれらは氷山の一角であり、まだ発覚していない(ユーザー自身も気付いていない)ものまで含めると、重大な情報漏洩につながる同様の事故は多くの企業で発生しているものと推測される。

重大な情報漏洩事故につながる例。本番環境は正しく設定できていても、管理者の異なる開発/テスト環境で設定ミス、設定漏れが起きることもある

 また、外部攻撃者によるアカウントの乗っ取り攻撃も頻発している。他人が契約しているクラウドリソースをひそかに乗っ取って仮想通貨のマイニングを行い、不正に金銭を稼ぐという犯罪だ。もちろん企業側は被害者なのだが、元を正せばユーザー側の設定ミスや設定漏れが大きな要因となっている。

 パブリッククラウドにはWebログイン、SSH、APIなど、いくつものアクセス手段が用意されており、本来はユーザー自身でそれらを個々に正しく設定、管理しなければならない。だが現実には、自分が使わないアクセス手段の管理はおろそかになりがちだ。また、開発者がAPIの認証キーをアプリケーションのソースコードにハードコードし、うっかりそのままGitHubで公開してしまってそれが悪用されるような事件も起きている。

 そのほかにも、パブリッククラウドにはセキュリティリスクになりかねない設定が多くある。だが、それに気付くような高度なクラウドスキルを身につけた人材は少なく、多くのユーザーはデフォルト設定のままで(最小限の設定変更だけで)使い始めてしまう。一方で、パブリッククラウドでは新機能や新サービスが次々に追加されるため、すべてを熟知して使いこなすというハードルはどんどん高くなっている。

パブリッククラウド特有の 「責任共有モデル」を知る

 こうした事故が起きる背景には、パブリッククラウドの「責任共有モデル」に対する誤解があると考えられる。「パブリッククラウドを利用すれば、セキュリティ対策をすべてクラウドベンダーに任せられる」という考えは、端的に言って間違いだ。

 パブリッククラウドでは、IaaS/PaaS/SaaSのサービスごとに「クラウド事業者側で運用管理の責任を持つ範囲」と「ユーザーが責任を持つ範囲」が明確に定められている。たとえばIaaSであれば、データセンター/ネットワークなどのインフラ設備やコンピューティング/ストレージなどの機器の運用と保護については、SLA(サービスレベル保証)の対象としてクラウド事業者側が責任を負う。だが、ソフトウェアコンポーネント(OSやアプリケーション)の構築や設定、運用、データ保護などについては、原則としてすべてユーザー企業側の責任となる。

 セキュリティについても同様だ。たとえばAmazon Web Services(AWS)のIaaSでは「セキュリティグループ(ファイアウォール)」機能を提供しているが、それを正しく構成するのはユーザー側の責任範囲である。現在のパブリッククラウドではそのほかにも多様なセキュリティ機能が組み込まれ、提供されているが、責任の所在についてはいずれも同じであり、設定ミスや設定漏れでセキュリティ侵害が発生してもその責任はユーザー側にある。

パブリッククラウドの「責任共有モデル」(AWSの場合)。各種セキュリティ機能は提供されるが、それを正しく設定して使うのはユーザー側の責任だ

 クラウドユーザーがこうした自らの「責任」を見逃しがちなのは、これまではIT部門が代わりにその責任を負ってきたからだ。自社運用のデータセンター環境、オンプレミス環境の場合、IT部門がファイアウォールなどのセキュリティ機器を導入、設定して、全体を保護する“セキュリティの壁”を作ってきた。あらかじめそれに守られているため、たとえば開発者が開発環境において設定や使い方を誤っても大きな事故にはつながりにくかったわけだ。

 パブリッククラウドの場合、そうした“壁”はあらかじめ存在せず、ユーザー自身で設定、構築する責任がある。そうした意識を持たないままで、オンプレミス環境と同じようにパブリッククラウドを使えば、当然セキュリティリスクは高まることになる。

監視、設定修正、ポリシー統一……、 マルチクラウド化でさらに複雑に

 冒頭で述べたとおり、パブリッククラウドを柔軟かつ自由に利用したいというニーズから、IT部門ではなく開発部門や事業部門などのユーザー部門が個別にクラウド事業者と契約、利用するケースも増えている。だが、こうした組織ではセキュリティ管理の問題が複雑なものとなる。

 部門ごとでクラウドを利用する場合、それぞれの部門に新たな“クラウド管理者”が生まれ、その管理者が構築や設定の作業を担うことになる。しかし、これらの管理者の持つ知識やスキルのレベルはまちまちであり、中には適切なセキュリティ設定ができないケースも出てくるだろう。

 IT部門が社内で利用されているすべてのクラウド環境を監視し、不適切な設定がなされていれば修正を促すという運用方法も考えられるが、現実にはかなり困難だ。個々の部門がクラウド事業者と直接契約すれば、その管理者アカウントも個別のものとなり、一元的な監視が難しくなる。さらに、構成や設定は部門ごとのニーズに応じて随時変更されるので、たとえリスクの高い設定がなされてもすぐには気付かない可能性もある。前述したような、機密情報が「公開」されたまま数週間、数カ月経ってしまう事故が発生すれば、事後の調査や対応の作業は大変なものになる。

 マルチクラウド化が進めば、この問題はいっそう複雑さを増す。そもそもセキュリティを確保するための設定項目は、クラウドサービスによってそれぞれ異なる。部門ごとに契約するクラウド事業者が異なれば、それぞれに応じた設定をしなければならない。セキュリティポリシーの統一も簡単ではないのだ。

 だからと言って、契約するクラウド事業者を統一し、設定から利用までIT部門がすべてを厳しく管理しようとすれば、クラウド本来の魅力であるアジリティは損なわれてしまうだろう。ユーザー部門から反発が起きるのは間違いない。

 もうひとつ、金融や通信、製造、医療など、業界によってはパブリッククラウドの利用時にコンプライアンス要件への対応も必須となる。これも頭の痛い問題だ。

 たとえばNIST(米国国立標準技術研究所)の定めるセキュリティ統制フレームワークにおいては、ステップごとに求められる対策が細かく定められているが、具体的にクラウドサービスのどの項目をどう設定すればよいのかはユーザー側で判断しなければならない。ほかのセキュリティ標準も同様であり、社内のクラウド管理者が「コンプライアンスのルール」と「パブリッククラウドの設定」の両方を熟知しておかなければならないことになる。さらには、クラウド管理が社内の各部門に分散していれば、監査対応のためのレポーティングなども非常に面倒な作業となるだろう。

* * *

 こうしたパブリッククラウドにまつわるさまざまなセキュリティ課題を解消するため、パロアルトネットワークスでは2018年10月に「RedLock」の買収意向を発表し、製品ポートフォリオへの統合作業を進めている。RedLockはAWS、Microsoft Azure、Google Cloud Platform(GCP)の各パブリッククラウドに対応した、クラウドセキュリティ分析とコンプライアンスの継続監視ツールである。

パロアルトネットワークスが買収を発表した「RedLock」の概要

 次回記事では、このRedLockが提供する新機軸の機能や利用メリットについて、詳しく見ていくことにしよう。

(提供:パロアルトネットワークス お問い合わせ:InfoJapan@paloaltonetworks.com )

カテゴリートップへ

本記事はアフィリエイトプログラムによる収益を得ている場合があります

この連載の記事

アクセスランキング

  1. 1位

    ITトピック

    情シス人材不足でも「採用予定なし」中小企業の意見/“従業員発のSNS炎上”6割の企業が懸念/「SNS疲れ」利用を減らす効果的方法、ほか

  2. 2位

    ビジネス・開発

    「Gemini Enterprise」に大規模導入の波 ― SOMPO・NTTデータ・Skyが描く“エージェント企業”への進化

  3. 3位

    ITトピック

    北米での成長率がすごすぎる NinjaOneとはいったい何者だ?

  4. 4位

    Team Leaders

    Power AutomateでSharePointリストにある申請データ一覧をメール送信する方法

  5. 5位

    sponsored

    無線APにデザインは不要ですか? ブラックスケルトンモデルは今どきのオフィスにめちゃなじむんです

  6. 6位

    YouTube

    ぶっちゃけ、あのSaaSってどう!? 情シスがガチ格付け! 本当に使えるツールを決める最強SaaSティア決定戦!!

  7. 7位

    ビジネス・開発

    脱・巨大プルリクエスト GitHub公式の「スタック型プルリクエスト」が登場

  8. 8位

    TECH

    プロテクティブDNSでDNSをセキュリティ基盤へ 福岡大学でも「運用課題なし」の実績

  9. 9位

    デジタル

    異常検知からロボット走行、車両制御まで —— 現場を遠隔化・自動化するSORACOM活用のIoTソリューション

  10. 10位

    ビジネス・開発

    情シスは「フィジカルAI」にどう向き合うべきか 実用化に不可欠な“現場×AI×経営”の橋渡し役に

集計期間:
2026年08月04日~2026年08月10日
  • 角川アスキー総合研究所