本記事は
AWSアワード受賞者祭り
20日目の記事です。
✨🏆
19日目
▶▶ 本記事 ▶▶
21日目
🏆✨
こんにちは、西内です。
この度、2025 Japan AWS Top Engineersおよび2025 Japan All AWS Certifications Engineersに選出していただきました。 社内には多くの猛者がいる中、まだまだ自分は未熟だと感じておりますが、名に恥じぬよう精一杯頑張りたいと思います。
私はお客様企業内のCCoEの方々向けにAWSマルチアカウント統制のサポートを行っています。 中でも、セキュリティ系サービスの有効化はとても重要な任務の一つです。
基本的にセキュリティ系サービスは全て有効化して、問題の発生を防いだり、問題が発生した場合には迅速に対応することが重要とされています。 しかし、何も考えず有効化を行うと既存のワークロードに影響を与えてしまう可能性もあります。 多くのAWSアカウントに対して有効化を行う場合、その影響は多大なものとなってしまいます。
今回は、セキュリティ系サービスを有効化する際に私が気をつけているポイントについて、Amazon GuardDutyを例に挙げてお話ししたいと思います。
CCoE導入における課題
まず前提として、CCoE部門がお客様の場合、メンバーアカウントを扱う部門と直接やり取りを行えないことがあるかと思います。 当然のことですが、CCoE部門とメンバーアカウント内で開発を行う部門は分かれており、連絡を取る際も CCoE部門を介す必要があるからです。
これがホールディングス系の会社様や、グループ会社を複数抱える企業様の場合、管理アカウントは親会社のCCoE部門が管理し、メンバーアカウントはグループ会社が利用しているというケースもあるでしょう。 そのような場合は、より一層メンバーアカウントのユーザーと連絡を取ることが難しくなります。
このように、CCoE部門の方とやり取りして管理アカウントにアクセスすることはできても、メンバーアカウントへのアクセス権は私たちには無いということが多々あります。 その場合、私たちがメンバーアカウント内でどのようなアーキテクチャを構築し、何のためのワークロードを運用しているかを把握することはできません。
また、アカウントの数が多いと、なおさらすべてのワークロードを把握することは困難になります。 今回の記事では、このような前提に立って話を進めたいと思います。
有効化に向けた進め方
先ほど、メンバーアカウント内のワークロードを把握することは難しいと述べました。 しかし、統制を利かせて均一にセキュリティを担保するためには、各種セキュリティサービスを導入する必要があります。 では、そのような中でセキュリティ系サービスを導入する際には、どのように進めるのが良いでしょうか。
まず念頭に置くべきなのは「既存ワークロードを止めない」という視点です。 セキュリティ向上のために実施した施策によってワークロードが停止することは、業務に影響が出るだけでなく、CCoE部門とメンバーアカウント側部門の関係性の悪化を招く可能性があります。
そのためにも、まずは導入するセキュリティサービスがどのAWSサービスに対してスキャンや監視を行うのか、また、それによってどのような影響があるのかを把握することが重要です。 そのうえで、サービスに影響があるものを絞り出し、対応を検討していく必要があります。
また、発生する費用の算出や予算との照らし合わせ、具体的な有効化方法（コンソール画面・CLI・IaCなど）の検討も重要な視点です。 本記事では「既存ワークロードを止めない」という点にフォーカスしているため、費用調整については割愛します。
ドキュメントの読み込み
当然のことではありますが、有効化を行うサービスについて「どのような機能を有効化できるのか」「各機能は何のサービスに対して監視やスキャンを行うのか」「その監視やスキャンによってどのような影響があるのか」を、ドキュメントを読み込んで把握することが重要です。
ここで、Amazon GuardDutyを例に挙げて説明したいと思います。 Amazon GuardDutyとはマネージド型の脅威検出サービスで、AWS アカウントとワークロードを継続的にモニタリングして悪意のあるアクティビティを検出します。 まずは GuardDuty の公式ドキュメントを見てみましょう。
ひとくちにGuardDutyといっても、複数の機能が存在することが分かります。 Runtime Monitoringはさらにその中で有効化対象サービス別に項目が存在しています。
- S3 Protection
- EKS Protection
- Malware Protection for EC2
- Malware Protection for S3
- RDS Protection
- Lambda Protection
- Runtime Monitoring
- Amazon EKS
- Amazon ECS
- Amazon EC2
では、各機能について何を行うのか、かなり大雑把ではありますが以下の表にまとめます。
| # | 機能名 | 何を行うのか | 既存ワークロード稼働への影響 |
|---|---|---|---|
| 1 | S3 Protection | CloudTrailの監視 | ログ監視のため重大な影響なし |
| 2 | EKS Protection | CloudWatchに遅れたEKSのログ監視 | ログ監視のため重大な影響なし |
| 3 | Malware Protection for EC2 | EBSスナップショットのスキャン | スナップショットへのスキャンのため重大な影響なし |
| 4 | Malware Protection for S3 | アップロードされたオブジェクトのスキャン | オブジェクトへのスキャンでありワークロードへの影響なし |
| 5 | RDS Protection | 不正なログインアクティビティの検知 | パフォーマンス影響なし（※ドキュメントにも明記されている） |
| 6 | Lambda Protection | Lambdaの各種ログの監視 | ログ監視のため重大な影響なし |
| 7 | Runtime Monitoring （Amazon EKS） | 新たなpodを作成して監視を行う | 監視用podがCPUやメモリを消費するため影響を及ぼす可能性あり |
| 8 | Runtime Monitoring （Amazon ECS） | サイドカーコンテナを作成して監視を行う | エージェントがCPUやメモリを消費するため影響を及ぼす可能性あり、またコンテナの再起動も必要 |
| 9 | Runtime Monitoring （Amazon EC2） | エージェントをインストールして監視を行う | エージェントがCPUやメモリを消費するため影響を及ぼす可能性あり |
影響のある機能をどう有効化するか
先述の表の「既存ワークロードへの影響」列を見てみましょう。 #1～6についてはワークロードに対して重大な影響はありません。 そのため、有効化を行う方針で問題ありません。
問題は#7以降のRuntimeMonitoringです。 #7~8は全てインスタンスのCPUやメモリを消費するため、ワークロードに影響を及ぼす可能性があります。 具体的にどのくらい消費するかもドキュメントに記載されています。
このようなワークロードへの影響を及ぼす機能については、どのように有効化するか方針を検討する必要があります。 この時にポイントとなるのは「トップダウン」と「個別最適化」の2点と考えます。
トップダウン
トップダウンは、CCoEが全アカウントへの導入を推し進めるというやり方です。 影響の少ないアカウントから順次有効化して様子を見つつ、最終的にすべてのアカウントを有効化することを目指します。
この考え方のメリットは、均一に統制を利かせることができるという点です。 最終的にはすべてのアカウントに対してセキュリティサービスを導入でき、ベストプラクティスに最も近い形でしょう。
一方で、CCoEがすべてのワークロードの詳細を把握できていない場合、有効化による影響度合いは計り知れません。 また、インシデントを回避するにはメンバーアカウントと有効化のタイミングを調整する必要があり、CCoE側の負担増加が予想されます。
個別最適化
もう一方の考え方は個別最適化です（※トップダウンの対義語はボトムアップですが、少し言葉の主旨が異なるため「個別最適化」としました）。 この考え方では、有効化の判断をメンバーアカウント側に委ねます。
既存ワークロードの重要度や、有効化しても問題ないタイミングはメンバーアカウント側が一番理解しています。 そのため、サービスの概要や有効化による影響をマニュアルとしてまとめてメンバーアカウント側に共有し、最適なタイミングで有効化を実施してもらいます。
この考え方のメリットは、既存ワークロードで問題が起きるリスクを最も抑えることができるという点です。ワークロードを最も把握しているメンバーアカウント側に有効化を委ねることで、最適なタイミングでの有効化や、懸念のあるワークロードへの有効化を行わないといった判断をすることが出来ます。
一方で、この手法取った場合有効化のタイミングはバラバラで、場合によっては有効化が行われず放置されることもあるでしょう。
どちらの方針に従うべきか
先ほどの2つの方針を表にまとめました。
| 手法 | メリット | デメリット |
|---|---|---|
| トップダウン | ・全アカウントに均一な統制を利かせられる ・最終的に全アカウントへ導入できる ・ベストプラクティスに近い |
・CCoEが全ワークロードの詳細を把握できていない場合、影響が読めない ・有効化タイミング調整などCCoE側の負担増加 |
| 個別最適化 | ・既存ワークロードへの影響リスクを最小化できる ・最適なタイミングで有効化可能 ・懸念のあるワークロードは除外できる |
・有効化のタイミングがバラバラになる ・場合によっては有効化されず放置されることもある |
どちらの方針にするかは、CCoE のセキュリティ施策の方針によります。 「強い意志を持って必ず全アカウントへセキュリティサービスを導入する」というのであれば、トップダウン的な進め方が良いでしょう。 そうではなく「あくまで既存ワークロードへ影響を与えないことが第一」という考えを重視するのであれば、個別最適化が良いでしょう。
どちらが正解ということはなく、ワークロードの状況を見ながら可能な限り全アカウントへの導入は目指していくことが重要です。
まとめ
セキュリティサービスの有効化方針について書きました。 GuardDutyを例に挙げましたが、他のセキュリティサービスにも当てはまる考え方だと思います。
ベストプラクティスはAWSによって明示されていますが、それが必ずしも今の環境に当てはめられるとは限りません。 また、GuardDutyのRuntimeMonitoringは管理アカウントからもメンバーアカウントからも有効化が行えますが、全てのセキュリティサービスがそうとは限りません。 影響範囲や有効化方法を網羅的に押さえたうえでトレードオフを考え、具体的な方針を固めていくこともエンジニアの腕の見せどころだと思います。
