はじめに

奈良先端科学技術大学院大学修士1年の湯浅潤樹です。2022年10月より6週間の就業型インターンシップに参加させていただきました。Cloud SecurityチームにてAWS上の脅威検知および解決自動化を行うシステムの開発を行いました。Cloud Securityチームではパブリッククラウド、プライベートクラウド、SSL/TLS通信のための暗号鍵管理システム、コンテナプラットフォームなどを対象にセキュリティアーキテクチャの設計とシステムの実装・運用が行われています。

本記事では、6週間のインターンシップでの成果と感想を記します。

課題・背景

LINEではプライベートクラウドのVerdaを用いたサービスの運用が行われていますが、事業側の要件等によりパブリッククラウドを用いて運用がなされている箇所も例外的に存在しています。パブリッククラウドとしては主にAWSが用いられており、セキュリティ的脅威イベントが発生した場合にそのログが収集される機構が用意されています。CSIRTチームではXSOARを利用してAWSサービスの脅威についてモニタリングを進めていますが、Cloud Securityチームでも脅威やセキュリティに脆弱な設定変更についてモニタリングが必要な状況でした。

私はその状況を改善するため、脅威イベントを通知し、問題解決の自動化を行うシステムの開発を行いました。

システムについて

システムはAWSを用いて構築を行いました。以下はシステムのアーキテクチャ図です。

システムには大きく分けて、脅威検知機能、脅威通知機能、解決自動化機能の3つの機能があります。アーキテクチャ図にて各機能の該当箇所を点線の枠で示しています。

脅威検知機能

脅威検知機能は既に実装されていました。Amazon GuardDuty（以下、GuardDuty）を用いて脅威検知を行い、AWS Config（以下、Config）を用いてセキュリティグループやAmazon S3（以下、S3）などの設定上の不備を検知します。そして、LINEのAWS環境における全アカウントの脅威イベントがAWS Security Hub（以下、Security Hub）に収集されます。

以下は各アカウントの脅威イベントがSecurity Hubに収集されるイメージ図です。

脅威通知機能

脅威通知機能はEmailとSlackに脅威イベントの通知を行います。Amazon EventBridge（以下、EventBridge）を用いてSecurity Hubに収集されるイベントをAWS Lambda（以下、Lambda）に流します。そして、Lambdaはイベント情報を整形し、SlackとEmailに通知します。Emailの場合は、mazon Simple Notification Service（以下、SNS）を介して通知を行います。

SlackとEmailの通知は以下のようになされます（※ 実際に発生したイベントではなくサンプルの脅威イベントです）。

Slackにおいては脅威の深刻度をもとに、色付けを行いました。深刻度が低いものは灰色、中程度のものは黄色、高いものは赤色としています。また、簡潔に深刻度、イベントのタイプとその説明を情報として記載し、見やすいように心がけています。
EmailにおいてはSlackよりも情報をより多く記載しています。こちらも改行を随所に入れるなどして見やすくなるよう心がけました。

また、それぞれの通知にはClient AppのURLを記載しており、セキュリティ担当者はClient Appを利用することで脅威の解決自動化を行うことができます。

解決自動化機能

解決自動化機能は脅威イベントで発生した問題の解決を行います。Amazon API Gateway（以下、API Gateway）とLambdaを用いて構築したAPIを用いて解決自動化を行い、APIの認証・認可をAmazon Cognito（以下、Cognito）を用いて実装しています。

Cloud Securityチームの担当者はClient Appを用いてAPIを利用することで、通知の抑制機能を利用することができます。

通知の抑制

AWSを通常利用するにあたって、GuardDutyの検出ルールに引っ掛かってしまうことがあります。例えば、GuardDuty検出ツールのImpact:EC2/PortSweepはEC2インスタンスが、多数のIPアドレスのポートを調査する場合に検出されるものですが、EC2インスタンスを用いてヘルスチェックなどを行うなどのケースにも検出されてしまいます。このような場合に通知を抑制する機能を実装しました。各イベントごとと、脅威イベントの各タイプごとの2パターンの通知抑制を実装しました。

各イベントの通知抑制はSecurity Hubの BatchUpdateFindings を用いてワークフローのステータスをSUPPRESSEDに変更することで実施します。EventBridgeのEventPatternを用いて、ワークフローのステータスがSUPPRESSEDなものは通知の対象外とすることが必要です。以下の例では、ワークフローのステータスがNEWのイベントのみ通知するように設定しています。

脅威イベントの各タイプごとの通知抑制はEventBridgeのイベントパターンで特定のTypeを通知の対象外とすることで実施します。以下の例では、タイプTTPs/PenTest:IAMUser/KaliLinuxを通知の対象外としています。

インシデント対応・修復

インシデント対応・修復機能を当初は実装する予定でしたが、サービス運用の都合上、実装しないこととなりました。例として、IAMのアクセスキーが漏洩した場合にキーをローテーションすることや、EC2インスタンスが悪用された場合にインスタンスを削除することなどが考えられます。しかし、そのような操作を自動化してしまうと、サービスを停止してしまう可能性があり気軽に実装はできないということになりました。

デモンストレーション

デモとしてSlackへの通知を確認した後に通知を抑制することを行います。

まず、脅威イベントが発生するとSlackに通知が来ます。GuardDutyが Policy:IAMUser/RootCredentialUsage のイベントを検知しました。このイベントはAWSアカウントのルート認証情報を使用して、AWSのAPIが呼び出されたことを示すものです。

通知に記載されているClient AppのURLをクリックし、セキュリティ担当者が認証情報を使用してサインインすると、以下の画面が表示されます。

このイベントのみの通知を抑制したい場合はEvent Basedの通知抑制機能を利用します。通知に記載があったIdとProductArnを入力し、Suppressボタンをクリックします。

SecurityHubを確認すると、ワークフローのステータスがSUPPRESSEDに変わっています。Event BridgeのイベントパターンでワークフローのステータスがSUPPRESSEDのものは通知がなされないように設定されているため、以後、同内容のイベントが発生した際に通知は来ません。

このタイプのイベントの通知を全て抑制したい場合はType Basedの通知抑制機能を利用します。通知に記載があったTypeを入力し、Suppressボタンをクリックします。

Event Bridgeのイベントパターンを確認すると、TTPs/Policy:IAMUser-RootCredentialUsage が追加されています。anything-but は指定した値以外のものを対象とするため、タイプ TTPs/Policy:IAMUser-RootCredentialUsage のイベントは以後、通知の対象外となります。

おわりに

インターンを通じて、AWSのさまざまなサービスに触れることができ、AWS上の脅威についての知識も深めることができました。また、LINE及びCloud SecurityチームではWikiを書く文化が浸透しており、やったことや調べたこと、発生したイシューをWikiにまとめることの重要性を学びました。

インターンでやり残したこととして、APIの認証方式をLINEのIdPとSAML連携したものに変更すること、インシデント対応がサービス運用との兼ね合いであまり実装できなかったことがあります。LINEは会社規模が大きいため、他のチームとの連携が必要になる部分は手続きに時間を要します。しかし、早めに連携が必要なことに気づけていればインターンの期間内にできていたかもしれないので、そこは反省すべきところだと思っています。

また、今回のインターンは原則オンラインでしたが、1日だけ四谷のオフィスに出社させてもらいました。ランチの時にカフェで日本と韓国の食べ物が両方用意されていたのが印象的でした。LINEならではの日本と韓国の文化の交わりを体験できて良かったです。

充実した6週間を過ごせたのはメンターやマネージャーをはじめとするチームの皆さん、そしてアドバイスをくださったチーム外の皆さんのおかげです。ありがとうございました。