おれさまラボの実験ノート

実際に手を動かして理解を深めるブログ。

クラウドセキュリティの認識、正しいですか?

はじめに

Paloalto Networks社のCSO(Chief Security Officer)であるMatthew Chiodi氏が、世界中の何百もの企業と仕事をし、Unit 42 のクラウド脅威調査チームと一緒にペタバイトのデータを分析した結果得たという、クラウドセキュリティに関する知見がブログに出ていたので、読んでみました。

📰:3 Myths About Security in the Cloud and How to Defeat Them

この記事では、クラウドセキュリティにまつわる3つの俗説を否定し、クラウドネイティブなクラウドセキュリティプラットフォームを構築する必要性について論じています。クラウドセキュリティの認識を正していきましょう。

俗説1:パブリッククラウドはオンプレミスのデータセンターよりセキュリティが高い

正解? → △

サマリ

パブリッククラウドを使うことで、オンプレミスのデータセンターよりもセキュリティが高い構成を組むことは可能だが、多くの顧客がパブリッククラウドを使いこなせていない。これは統合された包括的なプラットフォームレベルの管理をクラウド利用者に提供できていないことが原因である。

補足情報

  • 共有責任モデルの安全性においてはクラウドサービスプロバイダー(CSP)の主張が正しいし、うまくいっている。

  • 2019年 Unit 42 の調査によれば、クラウドセキュリティに関するインシデントの65%が「設定ミス」によるものだったことが明らかになっている。

  • 多くの組織がクラウドセキュリティ対策を行う必要があることは理解しているものの、それを行うために必要なプロセスと管理を実施できていない

共有責任モデル

クラウドのセキュリティ(サービス提供に必要な物理機器やネットワークを守ること)はCSPが責任を負い、クラウドの中のセキュリティ(仮想サーバやアプリケーションを守ること)は顧客が責任を負うというモデル。AWSが詳しく紹介しているので、知らなかったという方は参考ページを参照することをオススメします。

参考:責任共有モデル | AWS

俗説2:DevSecOps = DevOps + Security or Scan

正解 → ×

サマリ

DevSecOpsを実現するには環境・人・プロセスに着目しなければならない。「環境」 = パブリッククラウドを利用してIaCを正しく運用すること。「人・プロセス」 = 開発者、セキュリティチーム、ITチームが仲良くしてセキュリティとコードを共に考えること。これらができてはじめてDevSecOpsが実現する。

補足情報

  • Matthew Chiodi氏の見解ではDevSecOps = パブリッククラウドとのこと。
  • プライベートクラウドとしてのオンプレミス(高度にカスタマイズされた特定の目的に特化したデータセンター、API駆動を特徴とする最先端の環境)であればDevSecOpsが可能
  • それ以外のオンプレミスではDevSecOpsはできない。

DevSecOpsとは

DevSecOpsとは、単にセキュリティスキャナを実行するという行為を指すのではなく、どのようにセキュリティ機能が計画され、実行されるのかという考え方を180度変えることを言う。

DevSecOps is about completely changing how security, as a function, is planned and executed.

引用:3 Myths About Security in the Cloud and How to Defeat Them

今日の組織の問題点

  • セキュリティチームと開発者の間には交流があまりない。(= セキュリティが孤立している

クラウドネイティブ時代にはセキュリティとコードが仲良くしていくことが必須となる。

→ IaCテンプレートはDevSecOpsの重要なコンポーネント。正しく使えば強い味方となるが、間違うと脆弱性を含んだ構成が大規模に再現されることに繋がってしまう

DevSecOpsの実現

  • セキュリティチーム、開発者、ITチームが皆、インフラストラクチャとセキュリティをコードとして提唱し、提供するときにはじめてDevSecOpsが成立する。
  • DevOps → DevSecOpsの転換には人とプロセスに注目することが大切。

→ 人とプロセスに注目するとういう点でPaloalto Networks社はBIG Cloud 5という戦略を発表している。

BIG Cloud 5

  1. 状況を認識してクラウドを詳細に監視する。
  2. クラウドの最も重大な設定ミスを自動で阻止する防壁を設定する。
  3. 標準を定めてから自動化に進む。
  4. コーディングするセキュリティ エンジニアをトレーニング/採用する。
  5. 開発パイプラインにセキュリティを組み込む。

参考:Big Cloud 5:包括的クラウド セキュリティ戦略

DevSecOpsを実現するツール

Infrastructure as Code (Iac)の考えを取り入れたImmutable Infrastructureを提供するツールとして以下3つが例示されている。

  • AWS CloudFormation
  • HashiCorp Terraform
  • Azure Resource Manager (ARM)

→ 2020年春に行われた Unit 42 の調査によれば、AWS CloudFormation テンプレートはセキュリティ的に脆弱であることがわかっている。(調査対象のテンプレートのうち42%に中~高レベルの脆弱性が発見された)

俗説3:クラウドに必要なセキュリティはCSPが提供してくれる

正解? → ×

サマリ

CSPは基本的なセキュリティをネイティブに提供してくれるがそれだけでは足りない。また、複数のパブリッククラウドを使うことが当たり前となった現代では複数のCSPをまたがる可視性とコントロールが必要である。

補足情報

  • たしかにCSPは新機能のリリースと同時に基本的なセキュリティを具備し、強化し続けているが、カスタマーはCSPがネイティブに提供できるセキュリティ以上のセキュリティを必要としている。
  • エンタープライズ・グレードのセキュリティには、ハイブリッド・クラウドだけでなく、複数のクラウド・プロバイダーにまたがる可視性とコントロールが必要。

まとめ

過去の常識にとらわれず、ゼロトラストを提唱し、IaCテンプレートによる自動化された拡張性の高いセキュリティを取り入れ、複数のパブリッククラウドを統合管理可能なセキュリティプラットフォームを採用することが大切。

補足情報

  • 過去の常識にとらわれてはいけない。

→ 俗説を事実と行動の両方で払拭する必要がある。

  • クラウドセキュリティに関する俗説はこれだけではない。

→ 注意しましょう。

クラウドネイティブな組織になるには?

  • ゼロトラストセキュリティモデルを提唱すること
  • IaCテンプレートを通じた自動化されたスケーラブルなセキュリティを促進し、奨励する
  • 複数のクラウドサービスプロバイダのAPIと連携し、パイプラインがどこにあっても開発パイプラインに有機的に統合できる、クラウドネイティブのセキュリティプラットフォームを採用する。

以上