CloudNative Security Conference 2022開催。オイシックスが紹介するAWSでのアラート削減の経験談を紹介

8月5日、CloudNative Security Conference 2022がオンラインで開催された。今回の記事では、オイシックスのSREによるセッションを紹介しよう。内容はAWS上でセキュアな本番環境を実装した経験を解説である。

タイトルは「AWS Security Hubの警告数"34,326"から始めたクラウドセキュリティ対策」というもので、プレゼンターはオイシックス・ラ・大地株式会社のSREである林如弥氏と岡本真一氏だ。

セッションを担当するのは2人のSREチームのエンジニア

セッションのタイトルにあるように、これまでオンプレミスで稼働していた本番環境をAWS上に移行した際、AWSからの警告が合計3万件を超えていたという状況に対して、いかにセキュアな本番環境を作り上げたかという部分を解説している。前半の移行前に関する話を林氏が、後半のAWS上のセキュアなシステム実装に関する話を岡本氏が担当して解説するという分担作業となっている。

動画：AWS Security Hubの警告数”34,326”から始めたクラウドセキュリティ対策

AWS Security Hub導入直後のアラート数を紹介

このスライドでAWS Security Hubの画面を見せてクリティカルな警告が970、その他の警告が3万件以上という状態を紹介。これがタイトルにある数字の由来であることを説明した。これはAWS Security Hubの導入初期にAWSが発見したセキュリティに関する警告の数である。

2021年7月以前のシステムの棲み分けを紹介

このスライドではテスト環境、データ分析のインフラストラクチャーはAWS上に構築されていたが、本番環境はオンプレミスと国内のクラウドサービスの上で稼働していたことを紹介。ここでは作成されてから時間が経ってしまっているリソースなどについては自動化がされておらず、インフラストラクチャーアズアコード（Infrastructure as Code）も実現できていなかったことを説明した。当然だが、本番環境についてはシステムの稼働を落とす可能性のある変更がしづらいという状況だったという。

番環境もAWSに移行したもののAWSの勧めるアーキテクチャーへの移行は困難

AWSにすべてのインフラストラクチャーを移行したものの、AWSが勧めるアーキテクチャーへの移行が進まなかったという。その時点ですでにセキュリティについては要点として挙げられており、その経緯として「セキュリティ改善プログラム」の実施を提案され、一緒に実行したというのが流れだ。

AWSの「セキュリティ改善プログラム」とは？

AWSの提供するセキュリティ改善プログラムは、AWSのスペシャリストとユーザーがQ＆Aに答える形で評価を行うプログラムであると説明。終るまでに数時間必要であるという。またエンタープライズサポートを導入しているユーザーであれば無償で実施可能である点を高く評価している。

セッションを終えた後の評価は「予想以上に低い」結果に

しかし実際に評価してみると思っていた以上に厳しい結果となったが、可視化が可能になったことは前進であるとまとめて、この状態から改善していくための作業の説明については岡本氏に譲った。

継続的にセキュリティを向上させるためには自社だけで実行可能な可視化が必要

岡本氏はAWS上のシステムのセキュリティを可視化するためのサービスとして、AWS Security Hubの導入について解説を行った。Security Hubの運用は2022年7月に開始されたもので、本セッションの時点でまだ1ヶ月程度の時間が経過したに過ぎないことを説明した上で、Security Hubについて簡単に解説を行った。

AWS Security Hubについて解説

AWS Security HubはAWS上のセキュリティに関してのベストプラクティスを使って可視化するためのサービスであるとして、AWS上の複数のサービスにおけるセキュリティ上の警告などを集約できることを説明し、AWS Config、Amazon Inspectorなどを例に挙げた。

Security Hubが検知できるサービスの一部

またオイシックスとしては、AWS上のアカウントの構成とリージョンを意識したサービス構成になっていることを説明。ここではあくまでもオイシックスとしての使い方の解説に留め、警告をどうやって減らしたのか？ という核心の説明はこの後に例にそって解説を行った。

導入後から大量に発生したアラートについては、ノイズとして管理の妨げになるとしてアラートの本質的な原因をなくすよりも、ノイズを減らすためにポリシーやルールの変更を行ったと説明した。

導入当初は、アラートが大量に発生してどこから手を付ければ良いのかわからない状態になってしまったと言う。またレガシーなアプリケーションにおいては、特定リポジトリーより実行されるイメージから50万件のアラートが発生したことも紹介。リポジトリーへの検査のルールを変えてアラートを抑制しながら、デベロッパーにパッケージの更新を依頼するなどして火消しを行ったことを説明した。現状での結果としてセキュリティスコアがまだ43％しか達成されていないと語り、今後も継続した活動が必要であることを説明した。

AWS上のリソース設定がオイシックスの使い方に合っていない例を説明

ここではAWSが推奨するベストプラクティスがオイシックスの使い方に合ってない場合にポリシー側を変更することでアラートを減らしたと説明。ベストプラクティスが実態に沿っていないという現実的な運用チームの悩みがストレートに表れていたと言える。

岡本氏は、結果として3万件以上のアラートは1か月の運用後に1.5倍から2倍に増えているとして減るのではなく増えてしまっていることを説明した。しかし可視化という目的自体は達成できているとして今後の計画について説明を行った。

ワークフローの強化が次の目標

今後の予定としてワークフロー機能の強化、特に通知されたアラートをトラッキングすることができるようになることが必要だと説明した。また自動修復するための機能を導入することなどを挙げた。

まとめとして示された「継続的な改善の必要性」

まとめとして「優先度を決めて対応していくこと」「継続的な改善の仕組みが必要」だとしてプレゼンテーションを終えた。

タイトルの「3万4千件のアラート」がどうなったか？という点については、数値的な改善はできていないとしながらも、今後の取り組みについてはワークフロー、自動修復などのキーワードを使いながら、今後の改善に期待できる内容となっていると言えるだろう。来年のプレゼンテーションが楽しみだ。