【AWS re:Invent 2024】CloudWatch を軸にセキュリティを対策する [COP340]

こんにちは、MSPの田所です。

AWS re:Invent 2024 が始まっていますね！
現場からイベント模様をお届けします。

セッション情報

Supercharging security & observability with Amazon CloudWatch

CloudWatch を利用してセキュリティインシデントに対応しましょう！

In the dynamic, evolving cloud landscape effective security observability is crucial to rapidly detecting, investigating, and responding to threats. Learn how Amazon CloudWatch can be leveraged to enhance your security posture, and how to configure CloudWatch to collect and aggregate security-relevant logs, create custom dashboards and widgets to visualize security trends, set up alarms and automated actions to detect and respond to security incidents, and integrate CloudWatch with other AWS security services for a holistic approach to threat management. This workshop provides a comprehensive understanding of how Amazon CloudWatch can power a journey toward robust security observability in the cloud. You must bring your laptop to participate.

CloudWatch ダッシュボードでセキュリティサービスの状況を確認し、セキュリティインシデントの調査と対応をしてみましょう！

Session types: Workshop

2時間のワークショップ

今回のまとめ

• セキュリティにおいてもオブザーバビリティは大事
• CloudWatch の機能を使いこなせば、セキュリティインシデントの切り分けが容易になる
• セキュリティインシデントを起こして、CloudWatch をチェックして、対策するワークショップを行った

セッションの詳細

1. 避けられないセキュリティインシデント

昨今のニュースを見ても、セキュリティインシデントが撲滅されることはありません。
要因は様々ですが、まずは予防することが大事。
そしていざセキュリティインシデントが起こった時に、根本原因の特定ができることも同じくらい大事です。
セキュリティインシデント発生後は、時間が経つにつれて金銭や評判のリスクが上がってしまいます。
ここで必要なのは、見たい情報が全て確認できるダッシュボードで、情報収集と整理にかける時間はできるだけ短縮したいものです。
今回のワークショップは CloudWatch を使って、セキュリティとオペレーションの洞察を基にセキュリティインシデントに対処するというものでした。

また今回ワークショップでの実践はありませんでしたが、CloudWatch Logs に関する新機能が発表されていました。

Amazon CloudWatch offers Zero-ETL with CloudWatch Logs

CloudWatch Logs がデータ変換なしで OpenSearch と統合できるようになりました。

 

2. AWS WAF

ワークショップのひとつ目は WAF で対策するセキュリティインシデントでした。
通販サイトに SQL インジェクション、DoS 攻撃、ブルートフォース攻撃を行い、CloudWatch で確認した上で対策します。

 

SQL インジェクション

通販サイトのログイン画面に「’ OR true –」を入力してログインすると、管理者権限でのログインに成功してしまいました。

WAF に SQL インジェクションに対するマネージドルールを追加します。

今度は SQL インジェクションが失敗しました。

CloudWatch ダッシュボードで WAF 関連のメトリクスを見ると、SQL インジェクションを 1 件防いだことが確認できました。

 

DoS 攻撃

大量のアクセスを行うと、ダッシュボード上で許可されたリクエストが大量にあったことが分かります。

CloudWatch Logs の Contributor Insights を利用すると、ロググループごとの集計データを見ることができます。
画像は、大量にアクセスされたパスのランキングです。

また Log Insights では、指定のロググループに対してクエリを実行することができます。
以下はアクセスを時系列で並べています。

WAF に DoS 対策のルールを追加していきます。

今度は大量アクセスがブロックされていることが分かります。

 

ブルートフォース攻撃

ありがちなパスワードを総当たりで試すスクリプトを実行すると、パスワードが「admin123」であることを特定できてしまいました。

WAF でレートベースのルールを設定して再度スクリプトを実行したところ、今度は失敗しました。

ダッシュボードで、アカウント乗っ取りの試みを 1,040 件防いだことが確認できました。

 

3. AWS CloudTrail

次に内部で設定が変更されてしまい、Webサイトが見られなくなってしまった時の対応です。

いくつか設定変更を行い、サイトが閲覧不可になっていることを確認します。

ダッシュボードでアプリケーションの状況を確認すると、Synthetics Canary の実行に失敗していることが分かります。

CloudFront のエラーレートも上がっています。

IAM、ルートテーブル、セキュリティグループ、NACL、VPC CIDR と色々と設定変更されていることも発見します。

設定を元に戻して、サイトが復旧したことを確認しました。

4. Amazon Inspector

Amazon Inspector でアプリケーションの脆弱性を発見します。

Inspector で引っかかりそうな Lambda 関数を作成します。

Inspector で Lambda のスキャンを有効化します。

EventBridge で Inspector で発見された脆弱性を CloudWatch に連携します。

ダッシュボードで、アプリの脆弱性検知を確認できました。

 

5. VPC Flow Logs

VPC Flow Logs の情報を細かく検索、分析します。

ダッシュボードでVPC Flow Logs の情報を見ることができます。

CloudWatch Logs の Contributor Insights で VPC Flow Logs の詳細情報を確認できます。
以下はリクエスト元、リクエスト先ごとのトラフィック数のランキングです。

Logs Insights でログをクエリ検索できます。

またクエリジェネレーターを使用すると、自然言語でクエリを作成することができます。

MSPとして

1. オブザーバビリティが含む意味

オブザーバビリティというとシステム状況のなぜを説明できる状態のことで、その手段としてインフラの負荷やアプリのパフォーマンスを測定するイメージでいました。
決して間違ってはいないのですが、今回セキュリティにおけるオブザーバビリティを学びました。
考えてみれば当然なのですが、セキュリティにもオブザーバビリティは重要です。
普段リソースやパフォーマンスの監視に目が向きがちだったため、新たな側面に出会った感覚です。
セキュリティの文脈も合わせて、今後オブザーバビリティはますます重要性が増してくる領域であると感じました。

2. セキュリティ監視への横展開

MSPの普段の業務ではリソース監視とその対応を主に行なっています。
そして今回のセッションで学んだセキュリティのオブザーバビリティも重要であると感じました。
弊社にはセキュリティのサービスメニューは数多くありますが、MSPとして行なっているリソースに対する監視運用のノウハウをもっと横展開したり、逆にセキュリティでの運用から取り入れられる点があるのではないかと思いました。
企業としてより高い価値を提供すべく、拡充できる部分を模索していきます。

おわりに

CloudWatch を上手に使えば、セキュリティインシデントが起きても細かく切り分けができることが分かりました。
オブザーバビリティという単語の存在感が徐々に増してきているのを感じています。

おしまい