TL;DR
- セキュリティ是正案件に途中参画したときは、最初から全体像が見えているとは限りません。
- 私がまず把握したかったのは、
対象範囲、何をもって是正完了とするか、どのサービスが対象か、誰と何を合意すべきかの4点でした。 - いきなり修正に入るより、最初に “判断材料” を集める方が後工程が安定します。
はじめに
2026年4月から、既存 AWS 環境のセキュリティ是正対応を進める案件に参画しました。
ただ、参画前の段階で案件の詳細がすべて分かっていたわけではありません。
そのため、最初から
- どのサービスがどれだけ使われているか
- 何が本当に是正対象か
- 何を直せば完了なのか
が明確だったわけではありませんでした。
むしろ実態としては、参画後に情報を集めながら、何を先に把握すべきかを整理していった という感覚に近いです。
この記事では、既存 AWS 環境のセキュリティ是正案件に入ったときに、私が最初に把握したかったことを整理します。
最初に感じたこと: いきなり是正はできない
セキュリティ是正案件という言葉だけを見ると、
- Security Hub の指摘を潰す
- 設定不備を直す
- ガバナンスを整える
といったイメージを持ちやすいです。
ただ実際には、参画直後の段階では
- 何が対象か
- どこまで直すのか
- 何を優先するのか
が整理されていないことも多いと思います。
その状態で動くと、
- 対象外まで調べてしまう
- 業務要件上必要な設定まで潰してしまう
- 顧客との認識がズレる
といったことが起こりやすいです。
そのため、私にとって重要だったのは、最初に修正案を考えることではなく、判断材料を揃えること でした。
1. まず把握したかったのは「対象範囲」
最初に把握したかったのは、当然ですが対象範囲です。
ただ、この「対象範囲」は単にアカウント一覧やサービス一覧を指すだけではありません。
見たかったのは、たとえば以下です。
- 対象アカウントはどこか
- 対象リージョンはどこか
- 本番だけか、検証環境も含むのか
- 共通基盤も対象か
- 監査対象と是正対象は同じか
ここが曖昧だと、後から
- そのリソースは今回対象外
- その環境は今回見なくてよい
- 本番だけ先に進めたい
という話が出て、手戻りしやすくなります。
2. 次に把握したかったのは「何をもって是正完了とするか」
次に重要だったのは、完了条件です。
セキュリティ是正という言葉は広いですが、現場では
- Security Hub の特定 Findings を解消する
- 顧客が決めた観点に合う状態にする
- 特定サービスの設定不備を一定数潰す
など、完了条件が案件ごとに違います。
ここが曖昧だと、
- Findings が消えれば完了なのか
- 一時保留は認められるのか
- 代替統制があれば対象外にできるのか
が判断できません。
そのため、私は最初に
- 完了の定義
- 対象外の扱い
- 保留の扱い
を把握したいと感じていました。
3. 「どのサービスが対象か」を早めに知りたかった
対象範囲が分かっても、サービスの濃淡が分からないと動きづらいです。
たとえば今回のようなデータ蓄積・分析系の基盤では、
S3KMSIAMCloudTrailEC2EBSEKSLambdaSecurity HubGuardDuty
のように対象が広くなりやすいです。
このとき重要なのは、「サービスを全部詳しく知ること」ではなく、
- どのサービスが主戦場か
- どのサービスは確認だけで済みそうか
- どのサービスは影響が大きいか
を早めに掴むことだと思っています。
4. 顧客とどこをすり合わせるべきかも早めに知りたかった
セキュリティ是正は、技術だけで完結しないことが多いです。
実際には、
- なぜそれが是正対象なのか
- 本当に直す必要があるのか
- 代替統制でよいのか
- 変更時の業務影響は何か
を顧客と合わせる必要があります。
そのため、最初に把握したかったのは
- 誰が最終判断するのか
- どこまで提案してよいのか
- 何をエビデンスとして出すべきか
でした。
ここが整理されていないと、技術的には正しい提案でも進まないことがあります。
5. 自分が最初に集めたかった情報
感覚的には、以下のような情報を早めに集めたいと思っていました。
- 対象アカウント / リージョン
- 対象サービス
- Security Hub や Config の有効状況
- 代表的な指摘の傾向
- 現場で触ってよい範囲
- 顧客に確認が必要な事項
この段階では、まだ「直し方」より「地図作り」に近いです。
6. 最初に全部分からなくてもよい
ここは自分でも重要だった感覚です。
途中参画だと、最初から
- 全体像
- 設計意図
- 過去の経緯
が全部見えることはあまりありません。
なので、
- 最初に全部理解しきれない
- まずは把握の優先順位を決める
- 見えたところから整理していく
という進め方で問題ないと思っています。
むしろ、見えていない状態で “分かったつもり” で動く方が危ないです。
自分なら最初にこう整理する
今の自分なら、参画直後は以下の順で整理します。
- 対象範囲を確認する
- 完了条件を確認する
- 対象サービスをざっくり掴む
- Security Hub / Config / CloudTrail の有無を確認する
- 顧客とすり合わせる論点を整理する
これでようやく、次に
- CLI で洗い出す
- Findings を読む
- 個別是正を考える
という流れに進みやすくなります。
まとめ
セキュリティ是正案件に途中参画したとき、最初から案件の全体像が見えているとは限りません。
私がまず把握したかったのは、
- 対象範囲
- 完了条件
- 対象サービス
- 顧客とすり合わせる論点
でした。
このあたりが見えてくると、その後の
- CLI での洗い出し
- Security Hub CSPM の確認
- コスト見積もり
といった作業がかなり進めやすくなります。
次の記事では、実際に対象リソースを洗い出すために使いやすかった AWS CLI コマンドのテンプレートを整理します。