[レポート]継続的なコンプライアンス対応によるクラウドセキュリティの拡張 #DEM22 #reinvent

オペレーション部　江口です。

本稿は、re:Invent2019で行われたセッション、「DEM22-S: Enhancing cloud security with continuous compliance」のレポートとなります。

概要

コンプライアンスへのチェックをコード化（Compliance as Code）することで、継続的なコンプライアンス対応を行いセキュリティを強化する、というプラクティスの紹介です。Chef社によるスポンサーセッションで、Chef社のコンプライアンスチェック用のツール「Inspec」による実現方法を紹介しています。

なお本講演の動画はYouTubeですでに視聴可能ですので、ご興味があればご確認ください。

講演者

Jeff Vogt - Senior Solution Architect, Chef Software

アジェンダ

• DevOps vs DevSecOps
• セキュリティベンチマークの標準
• （コンプライアンスに関する）世界の現状
• （コンプライアンスの）例外をハンドリングする
• 継続的Compliance as Code
• Q&A

セッション内容

DevOps vs DevSecOps

• DevOps: 開発者と運用者がアプリケーションのライフサイクルの変化に（自動化などを取り入れて）共に取り組むこと
• DevSecOps: セキュリティやコンプライアンスを、DevOpsと同様のプラクティス（パイプラインの導入、テストの自動化など）を利用して変更管理プロセスを組み入れること（たとえばコンプライアンスの自動テストなどを行う）。

セキュリティベンチマークの標準

• CIS、DISA、DevSec Hardening Framework, FINRAなど。CISとDISAがとくに著名で、(講演者Jeff氏の知る）90%の企業はこのどちらかを採用している

（コンプライアンスに関する）世界の現状

• 2017年には大規模な標的型攻撃は27%増えている
• 上記のような攻撃はゼロデイ脆弱性を突いてのものだと思われがちだが、実際のところ20000のよく知られたソフトウェアの脆弱性のうち、ゼロデイ脆弱性は14のみ。つまり既知の脆弱性を利用した攻撃が多い
  • つまり、脆弱性に対して定期的にコンプライアンスチェックやパッチングを行っていれば多くの攻撃を防げる可能性があるということ
  • とはいえ実際にはうまく取り組めていない企業が多いのが現状
• Compliance as Codeを実現するツール：Inspec
  • Continuous compliance as Codeを実現するツール
  • Chefが数年前に買収

• 上記のInspecコード例では、109行目以降が具体的なチェックポリシーのコードとなっている（パスワードの履歴のサイズが24以上であること）
• それ以外の部分の記述はレポートでの情報の補助のための記載
• このような形で誰でもチェックポリシーのコードを記述できる(Windows, Linuxで動作)

（コンプライアンスの）例外をハンドリングする

• コンプライアンスの例外のハンドリングは重要(※いわゆるソフトウェア的な例外ではなく、チェック時に諸事情で例外的に扱うべき事項を指しています)
• コンプライアンスのベースラインに対する例外というのはどの環境でも発生する
  • 無理やり100%コンプライアンスに準拠してしまうと運用上使えないシステムになってしまう、ということもありうる
  • そのため、例外として扱うべき事項を適切にハンドリングするべき
• Inspecなどを用いてにコンプライアンスチェックをコード化し、DevOpsのフローのようにプルリクエストやレビューなどのプロセスを行えれば、必要な関係者が何を例外として扱うべきか、をコードに組み込めるようになる
  • 例外事項をメールやスプレッドシートで管理するよりも効率的
  • Exception as Code

継続的Compliance as Code

• セキュリティベースラインのプロファイルを作成する
  • CIS, DISA, 企業の標準などをミックス
  • 定期的にすべてのサーバで実行
  • テストの結果は記録し保存
  • テスト失敗時にはアラートをだす
• SDLC（Software Development Lyfe Cycle/ソフトウェア開発のライフサイクル）内にコンプライアンステストを組み込む
• コンプライアンスのテストと、改善のテストのサイクルを回すようにする

Q&A

• Q: チェックの項目により、リスクは異なる。Inspecではリスクのレーティングはできるのか？
  • A: Inspecのコード内で、各テストでImpactというパラメータを設定する。これがリスクの影響度の値のため、これを利用すれば良い。

感想

継続的なコンプライアンスチェックにCompliance as Codeがなぜ必要なのか、ということをコンパクトにまとめて話しており分かりやすかったです。

チェックにおいて例外は必ず出てくるので、それをコード化し皆で管理することが重要、というのは「なるほどな」と思いました。例外的な事項の管理というのはどうしても一時的にはスプレッドシートなどで処理しがちですが、企業が大規模になりチェックが複雑になれば、それでは難しいでしょう。Compliance as Code、それによるDevSecOps、というのは今後重要になっていくのではと個人的に考えていますので、情報収集をこれからも行なっていきたいと思います。

以上、セッション「DEM22-S: Enhancing cloud security with continuous compliance」のレポートでした。