クラウドセキュリティはじめの一歩。観点と対策を「3つのポジション」「2つのテーマ」から考える。

話を聞いた人：豊田恵二郎 Flatt Security執行役員。車とサウナが好き。

回答した人：齋藤徳秀 Flatt Securityセキュリティエンジニア。ストラテジーゲームが好きで休日にやり込んだりします。好きなゲームパブリッシャーはParadox Interactive。

Amazon, Google, Microsoftにクラウドのセキュリティを丸投げできない理由

豊田：今回は「SaaSやスマホアプリといったWebサービスを提供する方がAWSやGCP、Azureといったパブリッククラウドのセキュリティにおいて意識すべきこと」をテーマに話を聞かせてください。そもそも、なぜクラウドのセキュリティをクラウド利用者が考える必要があるんでしょうか？AmazonやGoogle、Microsoftに丸投げできないんですか？

齋藤：結論から言うと、丸投げはできません。もちろんAmazon、Google、Microsoft等のクラウドプロバイダが部分的に責任を持ってくれる範囲も存在します。

例えばクラウドプロバイダの提供するPaaS(Platform as a Service)を使用する場合、ミドルウェアのバージョン管理などはクラウド利用者が行う必要はありません。セキュリティに関しても同様で、脆弱なミドルウェアバージョンであった場合、この管理はプロバイダが行うので、クラウド利用者は気にする必要がなく、「丸投げ」することが可能です。

クラウドプロバイダの責任がある一方、クラウド利用者にも責任を持たなければならない領域が明確に存在します。セキュリティの観点において、その最たる例は「データへのアクセス制御」です。ある権限を付与されたユーザがどのようなデータにアクセスできるかと言った、個々のデータへのアクセス制御はいかなるクラウドプロバイダにも丸投げすることはできません。多くの場合、クラウド利用者が主体的にアクセスの権限を定め、運用して行く必要があります。

また別の例としてIaaS(Infrastructure as a Service)を利用する場合について考えてみましょう。この場合、クラウドプロバイダが提供するネットワークレベルでのセキュリティやホストするOSはクラウド利用者が責任を持つ範囲です。一方、サーバーの物理的な管理に関してはクラウドプロバイダ側が管理を行うため、クラウドの利用者は気にする必要はありません。

先にあげた例のように、クラウドプロバイダとクラウド利用者が責任を持つ範囲は分かれています。多くのクラウドプロバイダでは、その境界線を明文化することでクラウド利用者を混乱させないように「責任共有モデル」という概念を利用し、責任分界点を明確にしてくれます。余談ではありますが、この責任分界点の呼称は各プロバイダによって異なりAWSとAzureでは「責任共有モデル」と呼ばれますがGCPでは「責任共有マトリクス」と呼ばれますね。

（画像出典：https://aws.amazon.com/jp/compliance/shared-responsibility-model/）

これによってクラウド利用者は管理すべきところ、管理しなくていいところがわかるので人的・金銭的リソースを正しく集中させることができるという恩恵を受けられます。

さて、クラウドプロバイダに丸投げはできないことがわかったので、その考え方を前提に「クラウドセキュリティを考える意義」を説明していきます。

昨今のAWS、GCP、 Azure等のパブリッククラウドは「サービスの下にあるアプリケーションのインフラ」というだけの存在ではなくなってきており、サービスの開発やサービスそのものに関連するさまざまな要素を内包するようになってきています。

具体的には、DevOps を実現するためのツールやサービス、データ保管のストレージ、ユーザの認証、アクセス制御なども内包するようになっています。

このようにパブリッククラウドが単なるサーバー以上の役割を持つようになっており、そのセキュリティを考える意義は大いにあります。パブリッククラウドのセキュリティは従来のセキュリティにおいても意識されてきた個人情報や製品情報の保護にも直結しますし、仮にこれらのインシデントが発生した場合、一時的な損失にとどまらず製品やサービスのブランドの毀損や株価の低下、会社イメージの低下などの長期的な影響にもつながってしまいます。

また、自社の損得以前にステークホルダーの情報を守ることは社会的な責務でもあります。クラウドセキュリティは間違いなくこの責務の一端を担っているのです。

クラウドセキュリティにおける「3つのポジション」と「2つのテーマ」

豊田：クラウドセキュリティを考える意義は理解したんですが、クラウドといってもとても広義な表現に感じてどこから着目すればいいのかわかりません。まずどのような出発点から考えればいいのでしょうか？

齋藤：クラウド利用において登場する3つのポジションから考えると良いと思っています。その3つのポジションというのは

• A：クラウド利用者
• B：サービス提供者
• C：サービス利用者

ですね。あえて分けて書いていますが、基本的にAとBは同じ登場人物「Webサービスの事業者」を指しています。この3つのポジションの間に、2つのテーマが存在します。

• A & B：クラウドサービスを利用する立場としての話
• B ↔︎ C: サービス提供者/利用者の信頼関係の話

この2つのテーマの中にそれぞれ固有のセキュリティ観点が存在するので、これから解説していきます。

A & B：クラウドサービスを利用する立場としての話

豊田：なるほど、3つの立場が存在し、その中で「クラウドサービスの利用」「サービスの提供」という2つのテーマが存在するんですね。おそらく読者の方が普段意識するのは後者の方が多いだと思うんですが、それだけだと不十分だと。どのようなセキュリティ観点を持つべきなのか、まずは前者から詳しく聞かせてください。

齋藤：はい、「A & B：クラウドサービスを利用する立場としての話」においては「クラウドリソースの不正利用を防ぐ」という観点を意識する必要があります。

まず第一にこれは会社の資産を守ることに直結します。クラウドリソースの不正利用に伴って料金が発生しますが、これは会社の有限な資産であり、本来はお客様のために使われるべきものです。お客様に直接影響が出ないからいいというものでもないですし、不正利用の事実が明るみに出れば評判が低下し、場合によっては非難の対象になる可能性もあります。

次に、第三者への二次被害を防ぐという社会的責任にもつながっています。例えばクラウドリソースを仮想通貨のマイニングに不正利用されてしまったら反社会的勢力等への資金提供に加担したことになりますし、他にもマルウェアの配信元になったり攻撃の足場にされてしまったりといったケースが考えられます。

また、これは次に説明する「B ↔︎ C: サービス提供者/利用者の信頼関係の話」にも関わってくるのですが、クラウドの不正利用がお客様に直接影響を与えるケースも存在します。基本的に不正利用は「クラウドの利用権限を付与されたユーザの認証情報の流出」によって発生することが多いですが、このユーザが氏名や住所等の顧客情報のデータにアクセスする権限も付与されていたとしたら、それは顧客情報の流出に直結してしまいますね。

国内でもAWSのアクセスキーとシークレットが不正利用され、大量のユーザに関する情報がアクセス可能となってしまったケースが存在します。

豊田：認証情報が流出するとさまざまな不正利用につながるのはある種当たり前の話ですが、IaaSやPaaSを特別視していると見落としがちな観点かもしれませんね。どちらも普段使っているようなSaaSと同様のアカウント管理の意識が必要ということですね。

B ↔︎ C: サービス提供者/利用者の信頼関係の話

安定したサービスの提供

豊田：2つ目のテーマの「サービスの提供」におけるセキュリティ観点に関しても教えてください。

齋藤：「B ↔︎ C: サービス提供者/利用者の信頼関係の話」においては「安定したサービスの提供」「情報の適切で安全な管理」という2つの観点を意識する必要があります。順に整理していきましょう。

まず「安定したサービスの提供」ですが、これは比較的シンプルな話です。コンピュータリソースのスケーリングがうまくいかないせいでサービスが重くなってしまうなど、サービス提供者を起因としてサービス利用者に不利益を与えてしまうことは避けたいですよね。

DDoS(Distributed Denial of Service)のような攻撃に対する対策も意識するといいでしょう。手段としてはCDNを活用したり、DoSへの保護サービスを採用したり、オートスケーリングの設定を正しく行う等でしょう。SaaSで同様の機能を持ったサービスがある場合、そのようなサービスを利用するのも一つの手ですね。

また、万全を期すには火事や地震といった災害に対するクラウドプロバイダ側の対策も確認するといいと思います。例えば利用するサービスにおいてユーザーによりAZ(Availability Zone)やRegionを跨いだバックアップができるかなど。それがない場合は自ら構築する選択肢もあります。

豊田：なるほど、物理的な災害などは対策が難しそうですがそれでも手がないわけではないんですね。

情報の適切で安全な管理

豊田：「情報の適切で安全な管理」に関してはどのようなことを意識すればいいでしょうか。

齋藤：個人情報・顧客情報・製品情報が管理されておらず漏洩すると、それらが公開されてしまったり、転売されたりします。顧客や消費者保護の観点からも絶対に防がないといけないですし、ブランド毀損や競合企業へ戦略的に重要な情報が渡ることによる自社の競争力低下を招きます。

しかし、残念ながら情報漏洩の経路は多種多様です。全てを守るのは相当難しいことです。それでもサービス提供者は可能な限り多くを守らないといけないという社会的責任を持っています。

主要な漏洩経路をざっとリストアップすると以下のような感じでしょうか。

• 利用しているサービスの設定不備
• 利用しているソフトウェアの設定不備
• アプリケーションの脆弱性
• 過剰な権限の付与
• 通信経路上での盗聴
• 内部犯行による情報の漏洩

具体的にイメージするためにいくつか事例を見てみましょう。

「利用しているサービスの設定不備」だと例えばAWSのS3のケースがあります。S3はオブジェクトストレージであり、そのアクセス制御はACL(Access Control List)によって行われますが、この設定を誤るとストレージ内のデータがインターネット上の誰でも閲覧可能になってしまいます。

2017年7月には海外企業の保有する1,400万人の個人情報がS3バケットのURLさえわかれば 誰でもアクセスできる状態になっていた という事例が話題になりました。

また、「アプリケーションの脆弱性」や「利用しているサービスの設定不備」を経由してIaaSに攻撃を行なった事例もあります 。このようなケースではまず何らかの方法でSSRF(Server Side Request Forgery)攻撃を成立させ、IMDS(Instance Metadata Service)等のエンドポイントにアクセスし、インスタンスに付与された権限で操作可能な認証情報を取得します。このとき、インスタンスに過剰な権限が付与されていると、その権限によっては様々な被害につながっていきます。

長くなってしまいましたが、個人的にはこれまで話したような観点でクラウドを運用するとセキュリティをより網羅的に考えられると思っています。改めて観点は図にまとめたので、見ていただければ。

豊田：「情報の安全で適切な管理」「安定したサービスの提供」の2つが守るべき目標として与えられるんですね。後者を保てず失ったユーザは努力次第で戻ってきてもらうことも可能ですが、前者によって情報漏洩などが起きてしまうとそれは不可逆な過失なので非常に恐ろしいなと個人的には思いました。

クラウドセキュリティの実践に向けて

豊田：さて、これらの観点に対してどのようなアプローチをしていけばいいのか、対策方法を教えてください。

齋藤：アプローチは大きく分けて3つあります。これらの実践によってセキュアなサービス提供が行えるのではないかと思います。

アーキテクチャレベルでの対策

齋藤：1つ目に、アーキテクチャレベルでの対策です。多層防御やガードレールの考え方がこれに当たります。多層防御に関して説明すると、これは境界線防御のような古くからある考え方を発展させたもので、ネットワークの入り口の防御を行ったり、データの暗号化を行ったり、複数の防御機構を階層ごとに組み合わせるものです。テーマとしては「B ↔︎ C」に当たりますね。

クラウドにおける多層防御も大きく変わりません。クラウドサービスのベストプラクティスを守るというのも大事ですが、従来通りの手法も有効です。サーバーのセキュリティ対策を行ったり、保存するデータは暗号化を徹底したり、アプリケーションを攻撃から守るためにWAFを採用したり、利用監視のためにパブリッククラウドのロギングを有効化したり...

また、ガードレールについても解説すると、これはクラウドの利用に関して近年AWSが提唱している概念です。アカウントへの固すぎる制限を設けるのではなく、できるだけ自由を確保しつつ望ましくない領域のみ制限や発見する仕組みを構築する考え方です。テーマとしては「A & B」に当たりますね。

ガードレールには2つの種類が存在します。「望ましくない領域への操作の制限をかける予防的ガードレール」と「望ましくない領域への操作がなされた場合、それを検知する、発見的ガードレール」です。

先にあげた多層防御に関しても言えることではありますが、環境への侵入後に攻撃者により望ましくない行動がなされた場合、このようなガードレールの仕組みを導入することにより変更されては困る領域への操作を防ぐことができます。

アクセス制御に関する対策

齋藤：2つ目がアクセス制御に関する対策です。

「B ↔︎ C」のテーマにおいてはサービスの設定不備をなくすことが大切です。先ほども紹介した通り、S3をはじめとするSaaSではアクセス制御に不備があった場合、攻撃者によって重要なデータがアクセスされてしまう可能性があります。そのようなデータに関しては、できる限りアクセス権限を絞り公開することが大事だと考えています。

また、「A & B」のテーマにおいてはIAMの取り扱いが重要です。AWSをはじめとするクラウドサービスでは、多くの場合IAMを介してユーザの認証や認可、サービスへのアクセス制御を行います。それゆえに、IAMはクラウドサービスを利用する際に根幹をなすサービスであり、この取扱いは慎重に行う必要があります。

IAMの適切な取扱いのためには「最小権限の原則」と「認証情報の保護」を意識すると良いでしょう。前者は利用者に与えるアクセス権限をその作業に必要な最小限の権限を与えると言う概念です。この「最小権限の原則」を守ることにより、認証情報が漏洩した場合にも被害の範囲を最小化することができます。

後者は当たり前の話ですが、利用している認証情報を漏洩させないことも大切です。具体的な対策としてはgit-secretsのような認証情報をリポジトリに含めないようにするためのツールを利用したり、AWS EC2のSSRF攻撃の緩和策としてIMDSv2を利用したりすることが挙げられると思います。

また、強大なアクセス権限を有しているIAMユーザに対しては多要素認証の有効化を特に推奨します。

セキュリティ専門家によるアドバイス/診断

齋藤：最後に、専門家の力を借りるという選択肢があります。 パブリッククラウドの利用にあたり、セキュリティにおいて不安な点がある場合、弊社をはじめとするセキュリティベンダーやセキュリティの専門家にアドバイスや診断を依頼することも一つの手段だと思っています。

例えば、パブリッククラウドを利用しているが、セキュリティ上の課題の把握や問題点がわからない場合や、自社で対策したセキュリティ対策を第三者から評価してもらいたいなどの場合は、このような手段をとってもいいかと思います。

弊社でこのような対策のために提供しているのが AWS・GCP・Azure診断 になります。構成や設定ミスを洗い出す診断を中心に外部から直接アクセス可能な範囲の診断やクラウドにデプロイされているアプリケーションも加えてのペネトレーションテストなどご希望やご予算に合わせたご提案が可能です。

まだわからないことが多く具体的に検討できないという方向けに 無料の相談会 も実施しておりますので、お気軽にお問い合わせください。

豊田：クラウドセキュリティの意義から観点・対策まで幅広く知れて良かったです！ありがとうございます。今後は対策のさらに具体的なところまで聞いていきたいですね。

まとめ

• クラウドセキュリティはAmazon、Google、Microsoft等のクラウドプロバイダに丸投げはできない。クラウド利用者が責任を持つ範囲が存在する。
• 「クラウドサービスを利用する立場としての話」と「サービスの利用者/提供者の信頼関係の話」の2つがテーマとして存在する。
• 「クラウドサービスを利用する立場としての話」においてはクラウドリソースの不正利用を防ぐことが重要。
• 「サービスの利用者/提供者の信頼関係の話」においては「安定したサービスの提供」「情報の適切で安全な管理」という2つの観点を意識する必要がある。
• 2つのテーマにおいてセキュリティを実践するために以下の3つが対策として推奨される。
  • アーキテクチャレベルでの対策
  • アクセス制御に関する対策
  • セキュリティ専門家によるアドバイス/診断