1.はじめに
株式会社MICINのセキュリティチームのkurosawaです。
2024年6月にGuardDutyのRDSプロテクション機能がRDS for PostgreSQLにも対応しました。
これまでAuroraのみに対応していたため、RDS for PostgreSQLを多く利用しているMICINとしてはありがたいアップデートとなります。
この機会に、MICINのAWS環境におけるGuardDutyの保護プランを見直すことにしました。
本記事では、その際に直面したさまざまな課題についてお話しします。
GuardDutyとは
AWS環境において、セキュリティ的に疑わしい動作を自動的に検知するサービスです。
AWSを管理している人にとって、いちいち監査ログをチェックしなくても怪しい動きを教えてくれるGuardDutyは非常に頼もしく、おそらく多くの環境で有効化されているかと思います。
もちろんMICINでも有効化しており、何か怪しげな挙動があった時にはその内容がSlackに通知されるようになっています。
GuardDutyからのメッセージ例
GuardDutyが提供する保護プラン
有効化しておくだけでも色々な脅威を検知してくれるのですが、GuardDutyでは特定のサービスに対して、より詳細なモニタリングを行う機能も提供しています。
これらは保護プランと呼ばれ、以下のようなものがあります。
| 保護プラン | 概要 |
|---|---|
| S3プロテクション | S3に対するアクセスとアクティビティの脅威検知 |
| EKSプロテクション | EKS クラスターに対する監査ログの分析と脅威検知 |
| ランタイムモニタリング | ECS、EKS、EC2リソースでのラインタイムイベントの監査と脅威検知 Agent型で、有効化するとAgent（サイドカーコンテナ）が自動的に起動 |
| マルウェアプロテクション | EBS上でのマルウェアに対する脅威検知 EC2 や ECS on EC2 にアタッチされた EBS が対象 能動的な検知ではなく、あくまで怪しげな動きを行ったリソースに対してのチェック |
| RDSプロテクション | Auroraに対するログインアクティビティの脅威検知 2024年6月からPostgreSQLも対象に(NEW!) |
| Lambdaプロテクション | Lambda関数の不正利用に対する脅威検知 |
保護プランの詳細については以下の記事が参考になります。
GuardDuty紹介ページ（AWS）
Amazon GuardDutyの保護プランについてざっくり絵で起こしてみた（DevelopersIO）
2024年6月時点では、上記に加えてS3に対するマルウェアプロテクション機能も追加されています。（今回は有効化していません）
新機能S3マルウェアプロテクションの管理画面
2.GuardDutyを色々見直そう
MICINではGuardDutyは有効化されているものの、保護プランは放置気味だったこともあり、有効化されている機能とそうでない機能が混在した状態でした。
そこで今回、保護プランも一緒に整理することにしました。
保護プランの有効化方針
保護プランの有効化方針は以下のように定めました。
| 保護プラン | 方針 | 補足 |
|---|---|---|
| S3、Lambda、EKS | 全アカウントで有効化 | 有効化していてもコスト的に大きな影響はない（EKS環境もほぼ無い） |
| マルウェア、ランタイム、RDS | 本番アカウントのみ有効化 | データ保護に役立ちそうな機能は本番環境を優先的に有効化する |
ランタイムモニタリングとRDSプロテクションについては、他の機能と異なり、保護対象インスタンスのvCPU数に応じて利用料金が変動します。
データ保護はしたいものの、MICINのように大量のアカウントがあると、それにかかるコストも心配です。
そこでまずは、重要なデータが入っていて、保護するメリットが高い本番環境から有効化するという判断をしました。
GuardDutyのアカウント管理方法について
AWSのOrganizationsを利用したマルチアカウント環境では、GuardDutyの管理も管理アカウント・委任アカウントを利用した一元管理が一般的です。
一般的なGuardDuty管理イメージ
一方、MICINではAuditアカウントが個々のメンバーアカウントを招待し、その招待をメンバーアカウントが承諾することで、Auditアカウントが一元管理する状態となっていました。
MICINのGuardDuty管理イメージ
GuardDutyの有効化と検知メッセージの通知を1本化するだけであれば、この管理でも大きな問題はなさそうです。
ただ、保護プランの有効化や無効化といったアカウント毎の細かい設定を管理していくためには、Organizationsを利用して、メンバーアカウントも一元管理化しておきたいところです。
保護プランの整理とあわせて、Organizations管理の見直しも行うこととなりました。
理想のOrganizations管理を目指して
上のイラストにある通り、作業前の段階では、GuardDuty上のmasterアカウントが不在の状態でした。
そこでまず最初に行ったのは、masterアカウント上でのGuardDuty有効化でした。
これにあわせ、masterアカウントからauditアカウントを委任アカウントに指名することで、メンバーアカウントのタイプが招待経由から組織経由に自動的に変更されます。
管理方法の変更はこれだけです。楽勝です。
設定コードをterraform化
MICINでは、GuardDutyの設定もterraformで管理しているため、先に行ったmasterアカウントでのGuardDuty有効化といった作業もコード化しておく必要があります。
現状のterraformのコードから大きく変更する箇所は以下の通りです。
- masterアカウントでのGuardDuty有効化と、auditアカウントへの委任指定
- auditアカウントの招待＆メンバーアカウントの承諾設定削除
- auditアカウントでの各種保護プランの有効・無効設定
ところが、中途半端に手動で組織経由の管理に移行したため、terraformで管理しているステータスと実環境の設定に差分が発生し、terraformによる実装処理がエラーになってしまいました。
一旦組織経由で管理されているメンバーアカウントを招待経由に戻したのですが、今度は登録されているメンバーアカウントが管理アカウント上で見えなくなってしまいます。
試行錯誤を重ねるも、ひたすらエラーになるterraformでの実装処理を繰り返します・・・。
結局、作業前の状態に戻そうということになり、全メンバーアカウントを再招待＆メンバーアカウント側で再承諾するという予定外の作業が発生してしまいました。
メンバーアカウントの再招待後に、以下の流れをterraformで行うことで、どうにかOrganizations機能による管理をterraform化できました。
- 全てのアカウントでGuardDutyを無効化する
- masterアカウントでGuardDutyを有効化し、auditアカウントを委任アカウントに任命する
- auditアカウントで各保護プランを組織内で有効化する
作業後、auditアカウントのGuardDuty管理画面では、メンバーアカウントのタイプが全て組織経由(Via Organization)となり、新規および既存アカウントの自動有効化が設定されています。
委任アカウント側のGuardDuty管理画面
また、メンバーアカウントのGuardDuty管理画面では、委任アカウントによる管理が有効化されており、メンバーアカウント側での変更が行えなくなっています。
メンバーアカウント側のGuardDuty管理画面
これで、今後新規AWSアカウントが追加されても自動的にGuardDutyと一部保護プランが有効化されます。
ようやく管理方法の変更が完了しました。
保護プランの有効化・無効化をterraformで変更できない
管理方法が整理されたところで、保護プランの詳細設定も変更していきます。
ただ、2024年6月時点では、terraformの標準機能で設定できない部分がありました。
具体的には、前項の手順3で行ったような、組織内での保護プランの有効化・無効化は設定できるものの、アカウント毎に個々の保護プランを有効化・無効化できませんでした。
例えば組織全体で、RDSのプロテクション機能を有効化したり、新規メンバーアカウントで自動的に有効化するような設定はterraformで実施できます。
一方、特定のメンバーアカウントだけRDSプロテクション機能を有効化（あるいは無効化）するような設定はterraformだけでは行えません。
terraformの標準機能だけでは設定できない部分があるようです
ひとまず有効化できる部分のみterraform化し、それ以外の部分は管理コンソールから手動で有効化して対応しました。
3.保護プランを有効化してみて
GuardDutyを整理してから約1ヶ月が過ぎたので、設定後の運用状況について触れます。
検知されるアラートについて
幸いなことに、大量の脅威は検知されず、比較的平和な日々を過ごせています。
新たに監査対象となったEC2からのアラームがたまに通知されているくらいです。
EC2でリバースシェルが動いているというアラーム
ただ、このインスタンスは外部サービスへのデータ連携用に利用していることから、その通信を誤検知している可能性が高そうです。
通知されるメッセージについては、都度その内容を精査する必要がありそうです。
ランタイムモニタリングによるデプロイ処理への影響
ECSのランタイムモニタリングを有効化すると、GuardDuty用のセキュリティエージェントが各ECSタスクでサイドカーコンテナとして起動します。
このコンテナは、有効化後、タスクのデプロイを行ったタイミングで起動しますので、デプロイを行わない環境だとモニタリング開始までにタイムラグが生じる可能性があるため注意が必要です。
あるプロダクトの本番環境では、このコンテナの追加が原因で、ECSタスクの起動が遅くなるという事象が確認されました。
GuardDuty用のコンテナは起動するタスクのリソースに応じて、ハードウェアの利用上限が設定されます。
MICINの環境では、サイドカーコンテナに割り当てられるメモリの上限が125MBとなっているのですが、それでも何かしらの影響が出ているようです。
この事象は未だ解決にいたらず、タスクに割り当てるリソースの見直し等が必要と思われます。
タスクを確認するとguardduty用のコンテナを確認できます
コストの増加
現状では、保護プランの追加によってコストが大幅に増加している様子はなさそうです。
ただ、多くの保護プランには有効化後30日間の無償期間が設定されているため、実際にコストが増加してくるのはもう少し先になりそうです。
（試算では、現状のGuardDutyコストに対して月$100程度の増加を見込んでいます）
ちょうど有効化から1ヶ月が過ぎたくらいです
さいごに
本記事を最後までお読みいただきありがとうございました。
当初はGuardDutyの保護プランを整理する予定でしたが、図らずしも管理方法の見直しという課題にも対応できました。
今回有効化した保護プランは、どれもセキュリティ的に重要なものだと思うので、きちんと方針を決め、それに沿った管理が行えるようになったのも良かったと思います。
これから保護プランによるサービスへの影響や、その有効性は継続的に管理していく必要がありそうです。
Discussion