クラウドの「設定ミス」を防ぐには?<br />~インシデント事例と対策~

クラウドの「設定ミス」を防ぐには?
~インシデント事例と対策~

テレワークの増加やDX推進の加速によって、多くの企業でクラウドサービスの利活用が進んでいます。

一方、クラウドサービスを安全に運用するためにはセキュリティが不安という課題をお持ちの企業様も多いのではないでしょうか。

本コラムでは、クラウドサービスを運用する企業が留意すべき、「人為的な設定ミス」によって生じるセキュリティインシデントの事例と、その対策ご紹介します。

クラウドサービスを安全に利活用するには

クラウドサービスの活用を考える企業には、クラウドサービスを安全に運用するためのノウハウが必要です。セキュリティを伴った運用がされないと、個人情報の漏洩などのインシデントリスクが高まります。

米国の大手IT調査会社であるガートナー社の予測では、2025年までにクラウドセキュリティインシデントの99%は顧客の過失によるものになるとされています。

クラウドのセキュリティ責任は利用企業にもあり

クラウド利用者(利用企業)側で特に注意すべきポイントとして、クラウドのセキュリティにはクラウド事業者側の責任範囲と利用企業側の責任範囲があり、利用企業側で設定可能な範囲は利用企業側の責任範囲となることを知っておく必要があります。

例えばパブリッククラウドであるAmazon Web ServicesAWS)では「責任共有モデル」にて責任範囲が定められています。

「責任共有モデル」では、例えば「IDとアクセス管理」、「サーバ上で動作させるアプリケーションについてのセキュリティ」などは利用する企業側の責任と定められています。

そのため、クラウド利用企業は、「クラウド事業者のサービスを利用するから安全」という考え方ではなく、「クラウドを安全に利用するためには利用者としてのセキュリティ責任を果たす必要があると考える必要があります。

責任共有モデル
責任共有モデル

  

企業が留意すべきセキュリティ考慮事項

クラウドを活用しようとする企業が確認すべき考慮事項として、総務省の「テレワークセキュリティガイドライン」では、以下の5つのポイントが記載されています。

テレワークへのクラウドサービス活用の考慮事項
出典:総務省ホームページ 総務省テレワークセキュリティガイドライン(第5版)を元にNTTテクノクロスが作成

本コラムでは、上記の中でも、特に利用者側の不注意や知識不足によってセキュリティ事故が発生しやすい「④適切なアクセス制御の実施」について、インシデント事例と対策例を紹介します。

事例1:オブジェクトストレージサービス(Amazon S3)の設定不備

まずは、AWSの主要サービスの1つであるAmazon S3の設定ミスによる起こりうるインシデント事例についてご紹介します。

インシデント概要

Webコンテンツの格納など、オブジェクトストレージとして幅広く利用されているS3バケットは使い勝手が良いサービスですが、過去には設定不備によって多数のインシデントを引き起こしています。主なパターンは以下の2通りになります。

  • S3バケットに保存されたコンテンツ(Webページ上の画像など)が第三者によって編集可能であったため、コンテンツが不正に書き替えられた
  • S3バケットに保存された、公開する意図のないデータ(顧客リストのExcelファイルなど)が誰でもダウンロード可能な状態になっており、機密情報が漏洩した

Amazon S3バケットの設定ミスへの攻撃
S3バケットの設定ミスへの攻撃

このようなインシデントの発生を防ぐための対策については、AWSなどのクラウド事業者側でもセキュリティ機能の追加や啓蒙活動などに取り組んでいますが、前述のとおり根本原因としてはクラウド利用者(利用企業)の設定不備に起因する問題であるため、最終的には利用者側で正しい知識を持ち、セキュリティが担保されているかどうかを確認する必要があります。

インシデント対策例

クラウド利用者側でまず検討すべき主な対策は以下のとおりです。

  1. Amazon S3設定の見直し

S3バケットのアクセス権限について、原則としてパブリックアクセスは全てブロックした状態を前提とし、必要に応じて、公開すべきコンテンツに対しては最小限の読み取り権限を与えるように設定できているかを確認しましょう。

  1. Amazon S3バケットの分離

異なる権限ポリシーを持つデータは同じバケットに置かない(公開すべきコンテンツと非公開コンテンツは別々のバケットに分ける)ように構成することで人為的ミスなどのリスクが減少します。

その他、サーバからのアクセスのみ許可する設定や、監視・通知などAWSの機能を利用する方法など、多数の対策が存在します。

事例2:インメモリキャッシュサーバ(memcached)の設定不備

続いて、WebサーバがDDoS攻撃の踏み台にされてしまう事例を紹介します。

インシデント概要

Webサイトの裏側では、データベースなどいろいろなアプリケーションが動いており、中でも負荷軽減やレスポンス高速化の手段としては「memcached」というインメモリキャッシュが多く利用されています。「memcached」は信頼された内部ネットワークで通信を行う前提で作られており、送信元の確認を伴わない手段(UDPポート)でリクエストを受け付けています。

この「memcached」が、インターネット上からアクセス可能であったために、IPアドレスをなりすまし、なりすまし先へ大量のトラヒックを送信するDDoS攻撃の踏み台にされてしまうケースが多発し、国内のクラウドサービスプロバイダなどでも被害が出るなど、大きな問題となりました。

memcachedを踏み台とした攻撃
memcachedを踏み台とした攻撃

被害にあったmemcachedサーバから大量のトラヒックが発生するため、パブリッククラウド環境を利用している場合、クラウド利用者(利用企業)は知らぬ間に追加料金が課金される可能性があります。

また、大量のトラヒックによってDDoS攻撃を受けた第三者にとっては、memcachedサーバから攻撃を受けているように見えますので、サービス停止に伴う損害賠償を請求されるリスクもあり、社としてのコンプライアンスを問われる事態となりえます。

インシデント対策例

以下のような対策を講じることで、攻撃を防止できます。

  1. UDPポートの外部公開の禁止

memcachedのリクエストを受け付けるUDPポートは、通常インターネットに開放する必要はないので、ポートの公開を止めることで対応可能です。

  1. バージョンを最新化する

memcachedに限った話ではありませんが、プログラムの脆弱性を突く攻撃を防ぐためには、最新版のセキュリティパッチを適用しておくことが有効な対策となります。

  1. WAFなどのセキュリティソリューションを導入する

WAF(Web Application Firewall)など、外部からの様々な攻撃を防ぐサイバー攻撃対策ソリューションによって対策することも可能です。

まとめ

いかがでしたでしょうか。クラウドサービスは便利な反面、セキュリティを伴った運用・利用の知識がないと思わぬセキュリティインシデントが発生しかねません。 

NTTテクノクロスでは、このようなクラウドを運用する上でのセキュリティガバナンスを自動的にチェックしてくれる「Dome9」を取り扱っております。製品トライアルによる実際のクラウド環境の検閲レポートの提供なども実施しておりますので、クラウドを活用され始めているお客様は是非お気軽にご相談ください。