AWS Security Hub CSPM ガイドライン執筆の勘所 (CSPM上級者向け)

前述の通り 300 種類以上ある AWS Security Hub CSPM のコントロールを 1 つずつ、どのような対応方針としてガイドラインにまとめていくか考えていくのは非常に大変です。

しかし、コントロールとにらめっこしたことがある方はその多数あるコントロールの中で同じような性質のものが多いことに気づいているのではないでしょうか ? 効率的に方針を決めていくための鍵はそこにあります !

私はこれらのコントロールを下記 11 種類にカテゴライズして検討しています。

1. 通信の暗号化
2. 保管時の暗号化
3. ログ取得
4. 可用性
5. バックアップ
6. アクセス制御
7. 認証情報管理
8. 設定チェック
9. 保護
10. 脆弱性管理
11. コスト最適化

カテゴリが一覧で並ぶと、「そういえばこんな種類のコントロールがあるなぁ」と感じられるのではないでしょうか ?

なお、これは AWS が行っているカテゴライズではなく、あくまで執筆者個人のプラクティスであることはご留意ください。

AWS Security Hub CSPM の User Guide では、各コントロールのカテゴリとして NIST CSF をベースとした分類を行っています。

例えば、「[EC2.19] セキュリティグループは、リスクの高いポートへの無制限アクセスを許可してはいけません」では「保護 > 制限付きネットワークアクセス」、「[S3.11] S3 汎用バケットでは、イベント通知を有効にする必要があります」では「識別 > ログ記録」、「[AutoScaling.6] Auto Scaling グループは、複数のアベイラビリティーゾーンで複数のインスタンスタイプを使用する必要があります」では「リカバリー > 耐障害性 > 高可用性」などといった内容です。

これらの NIST CSF ベースのカテゴリは詳細な内容を把握するために活用できますが、対応方針を検討するうえで活用しようとするとやや細かいため、もう少しライトな分類を行うことが好ましいと私は考えています。

大事なことは、いずれのカテゴライズでも目的にあった使い方ができるようにすることです。今回の場合は各 AWS Security Hub CSPM のコントロールの対応方針を決めていくために分類していくため、最終的に自分たちの組織でそのカテゴリーが識別しやすく扱いやすい状態になっていることが好ましいです。私の提示したカテゴライズと、User Guide のカテゴライズ、2つを参考に、自分たちの組織ではどのような粒度で分類するとよいか、検討してみましょう。

コントロールをカテゴライズして大別できれば、大きく対応方針を決めていくことが可能です。私はこのカテゴリを大きく 2 つの環境に対して当てはめていきます。1 つは「本番環境」でもう 1 つは「本番以外の環境」です。

先程私が示したカテゴリーでは、「可用性」「ログ取得」「バックアップ」は「本番以外の環境」では必須ではありません。これはイメージが付きやすいのではないでしょうか ? 実際に開発環境などではこれらにまつわる設定は有効にしないと判断するケースが多いと感じられると思います。

この 3 つのカテゴリーは主にコストとトレードオフになります。従って、「本番以外の環境」ではコストを優先するケースを考慮して必須ではないという考え方になります。

逆に、「通信の暗号化」「保管時の暗号化」「アクセス制御」「認証情報管理」「保護」「脆弱性管理」は「本番以外の環境」でも必須です。これらは殆どの場合、セキュリティやガバナンスのために必須のコントロールであり、直接的にコストとトレードオフすべきではありません。

この環境の分類は組織の状態に合わせてもっと種類を増やしてもよいでしょう。

そしてコントロールのカテゴリーと環境の種類に合わせて、各コントロールの具体的な対応方針を決めていきます。

対応方針として、ここでは以下 3 種類としました。

• 対応必須
  - どのような場合でも必須なもの
  - あるいは組織全体のセキュリティガバナンスとして管理したいもの
  
  
• 通知のみ
  - 知っておいた方が良いが、組織全体のセキュリティガバナンスとしての管理が不要なもの
  - あるいは可用性要件など、本番環境では必須になるが本番環境以外の場合など
  
  
• 無効化
  - セキュリティの管理として必要ない、あるいは運用負荷が高いなど邪魔になると判断したもの

これももっと細かく定義してもよいですが、まずこのくらいの内容から決めていきましょう。

残りの「設定チェック」「コスト最適化」はかなりケースバイケースなのでカテゴリ単位では必須かどうかは定めません。

組織の体制により、全体のセキュリティガバナンスを定義する立場と、実環境の設定運用を行う立場以外にも様々な役割がステークホルダーに存在するため、取りうる対応方針も合わせて検討しましょう。


 

各コントロールごとに詳細な内容を記載していく場合、基本方針をベースに、「対応方針に盛り込むべき事項」にあるような該当 AWS サービスやコントロールに関する機能や設定固有の情報を付加していきます。

あまり深く考えずとも対応が必須である項目は、迷いようが無いためその必要性の強さのみテキストに落とし込めばよいですが、全体で決まった対応が示せない環境ごとに判断が分かれるコントロールはより丁寧な説明が必要です。

「可用性」「ログ取得」「バックアップ」はすべての環境で必須対応では無い分、利用者側での判断が多くなるためこの対象です。例えば「ログ取得」のコントロールでは、そのログでどのような情報が取得でき、どのように役立つかを説明したり、他のログでどこまで代替が効くか、ログの保存先として何が選択できるのか、コスト感や有用性とのバランスがどうなのかなど、最終的に対応するかを決定するための材料が沢山求められます。最初からすべてを盛り込むのは大変ですので、ステークホルダーと対話しながら逐次拡充していきましょう。

暗号化関連では KMS キーを利用する場合など、追加のコストがかかるかどうかは大事な判断基準の 1 つです。また、パフォーマンス影響や設定管理の難易度も合わせて盛り込むと良いです。

方針を決めていく中で絶対に禁止したい操作は AWS Organizations の SCP や Automated Security Response on AWS を利用して、操作のブロックや自動修復ができます。これらは非常に強力な強制力を働かせることができますので、導入や合意形成は大変ですが推進する価値があります。導入する際にはガイドラインに、禁止される理由や代替手法 (ベストプラクティス) を盛り込んでおきましょう。

そして、運用中には必ず例外も発生します。可能な限り例外の判断基準や代替のアプローチなども盛り込んでおきましょう。例えば「[EC2.8] EC2 インスタンスでは、Instance Metadata Service Version 2 (IMDSv2) を使用する必要があります」では IMDSv2 を必須とするコントロールですが、Amazon EC2 上でレガシーアプリケーションを稼働させ続けるために例外として受け入れる場合が考えられます。その際には、該当 EC2 への外部からのネットワーク的なアクセス経路が存在しないことや、アタッチされた IAM Role が最小権限でありかつ重要データにアクセスしない場合に限る、など前後のリスクに対する対策を条件に盛り込みましょう。