はじめに
こんにちは。技術戦略室SREチームの koizumi です。
弊社では、今年からインフラ環境をはじめ、コンテナイメージやアプリケーションコードのセキュリティ対策をはじめています。 現在、その中でもAWS / Kubernetes環境のセキュリティ対策を実際に運用しており、今回はその内容を中心にお話しできればと思います。
背景
近年、様々なサービスで不正アクセスや情報漏洩といった事象が頻発しており、そういった重大なセキュリティインシデントが発生してしまうと、会社としての事業継続に直結してしまうと考え、本格的にセキュリティ対策を進めています。
ライブ環境のセキュリティ対策
現在、弊社では主に以下のセキュリティチェックツールを用いてAWSとKubernetesのライブ環境のセキュリティ対策を行なっています。
それぞれ使用目的が違うため、簡単に説明いたします。
AWS Security Hub
AWS環境のセキュリティ対策としてAWS Security Hubを使用しています。
AWS Security Hubは自社のAWS環境に対して、セキュリティのベストプラクティスに沿ってチェックを実施し、セキュリティ的に問題のある設定を検知するセキュリティチェックツールです。
以下のように、各AWSアカウント内の設定に対して横断的にセキュリティチェックを行い、Severity（重要度）ごとに一元的に可視化できます。セキュリティリスクのある対象リソースやRemediationもわかるのでありがたいです。
また、各AWSアカウントのSecurity Hubコンソールだけでなく、ひとつのAWSアカウントに各AWSアカウントの検出結果をまとめることもできます。
Kubescape
Kubernetes環境のセキュリティ対策としてKubescapeを使用しています。
KubescapeはArmosecが公開しているOSSプロジェクトで、Security Hubと同じくKubernetes環境に対してセキュリティのベストプラクティスに沿ってチェックを行うことができるツールです。
弊社では、各AWSアカウントのEKSクラスターに対してセキュリティスキャンを実施しています。以下のように、Severityごとにスキャン結果が可視化されます。
UIが非常にわかりやすく、例外設定も簡単にできるのも良い点だと思います。（モザイクが多く、見づらいですが...mm）
運用方法
弊社では、毎週プロダクトチームと「SLI/SLOアラートふりかえり会」というものを定例開催しています。ここでは、対象リソースのSLI/SLOを割っていないか、頻発しているDatadogのアラートが無いか等を振り返っています。
この「SLI/SLOアラートふりかえり会」にて新たにセキュリティの項目を追加し、以上のツール（Security Hub, Kubescape）で検出された項目を議題に挙げて共有しています。
プロダクトチームとの定例においてどのような形でまとめているかについて簡単にご紹介したいと思います。
AWS Security Hubは以下のように、SeverityがCritical or Highで指摘されていた項目をまとめて共有しています。（これもモザイクが多く、わかりづらいです…mm）
Kubescapeについても同じようにまとめて共有しています。
検出項目の対応方法としては、基本的に以下のようにしています。
- Severity = Critical : SREチームが対応
- Severity = High : プロダクトチームが対応
全てのSeverityをSREチームが対応する方針とすると、プロダクトチームがどの部分にセキュリティリスクがあるのかを把握できずに指摘事項が増え続けてしまいます。
反対に、全てのSeverityをプロダクトチームに一任してしまうと、セキュリティ対応に追われてしまい、プロダクトチームの本業である開発業務に支障をきたしてしまいます。
そこで、先の課題を少しでも解消できればと考え、現在は以上のような対応方針としています。
また、この指摘事項が放置されないよう、議題に上がった指摘事項についてはスプレッドシートで管理しています。
このスプレッドシートは各アカウントでシートを作成し、指摘事項の概要や対象リソース、解決方法のSuggestなどをSREで記載して、プロダクトチームとの定例で決定した対応方針やJIRAチケットのURLも記載しています。
現状の運用課題
以上のような対応を行なった結果、各プロダクトにおいて潜在していたセキュリティリスクが可視化され、その設定を改善することができました。
しかし、まだ運用課題もあります。
主な現状の課題としては、以下のようなものが挙げられます。
- セキュリティ対応のJIRAチケットを手動で作成している
- セキュリティ対応の管理シートを手動でメンテナンスしている
- 新たに検知されている項目がないか、目視で確認している
セキュリティ対応を依頼する際に、プロダクトチームにはJIRAチケットの作成を別途お願いしています。理想としては、セキュリティ項目が検知された段階で自動でJIRAチケットが作成されてほしいところです。（弊社の都合上、統合機能で実現できませんでした…）
また、セキュリティ対応の管理シートについては、新たな検知項目をダッシュボードにて目視で確認し、追記している状況となっています。こちらについても、新たにセキュリティ項目が検知された段階で通知されるようにし、かつ管理シートにも自動で追記できるようになると、更にセキュリティ運用が楽になるかなと考えています。
以上のような課題は今後解決していきたいと考えています。
シフトレフト（Shift-left）によるセキュリティ対策
最後に、シフトレフトによるセキュリティ対策についてもご紹介します。
「シフトレフト（Shift-Left）」は、元々仕様を満たしているか等の検証に対するソフトウェアテストの文脈で使われていた言葉のようですが、近年ではセキュリティの文脈でも非常に注目されています。
開発プロセスで、DevOpsにセキュリティ（Security）を透過的に組み込む「DevSecOps」が重要視されていますが、このDevSecOpsを実現するために「シフトレフト」を取り入れることが重要だと言われています。
具体的には、後工程で行なっていたようなセキュリティ確認のプロセスを、開発工程の早い段階で組み込むことによって、早期にセキュリティにおける課題を解決していこうという試みです。
先ほど、ご紹介したセキュリティチェックツールはすでに作成されているリソース（ライブ環境）に対するセキュリティリスクを検出してくれるものですが、このシフトレフトの概念を考慮すると、セキュリティリスクのあるリソースがデプロイされる前の開発工程で検出できれば、よりセキュリティに起因する問題を事前に潰すことができると思います。
そこで、弊社でもシフトレフトを考慮したインフラ環境のセキュリティ対策も行なっていこうと考えました。
弊社では、ほとんどのAWS / Kubernetes環境をTerraformでコード管理しています。
そこで、このIaCコードをスキャンして予めセキュリティリスクを検出できる、Snyk IaC と Trivy の導入をはじめています。
具体的には、Reviewdog を用いて、CIの中でIaCコードのセキュリティスキャンを実施し、Pull Requestの段階でセキュリティリスクのある項目を検出しています。
（モザイクの部分に指摘されているファイルのパスが表示されます）
Checksタブに表示され、セキュリティスキャンで引っかかったものがあれば、Findingsの中に表示され、CIが失敗するようになっています。
今後、IaCだけでなく、アプリケーションコードなどにも活用していきたいと考えています。
ただ、このシフトレフトによるセキュリティ対策だけでは、コード化されていないような動的に生成されるリソースもあるため、網羅することはできません。 そのため、このシフトレフトによるセキュリティ対策と、AWS Security HubやKubescapeを用いたライブ環境のセキュリティ対策の両方を活用していく必要があります。
おわりに
今回は弊社におけるセキュリティ対策の運用内容、ならびに運用課題とシフトレフトに関する取り組みについて書きました。しかし、上記のように改善していかなければいけない部分がまだあります。
これからも弊社においてDevSecOpsを推進していく中で、より良いセキュリティ運用を模索していきたいと思います。
