Security Hub Automation Rules で CONTAINS と NOT_CONTAINS を利用できるようになりました。
何が変わったか
Automation Rules は Security Hub の各検出結果のステータス等を特定条件で変更できる機能です。
条件を設定する際のオペレータとして、これまでは下記 4 つしか利用できませんでした。
- Equals(完全一致)
- Not Equals(完全一致ではない)
- Prefix(前方一致)
- Prefix not equals(前方一致ではない)
今回、CONTAINS( 特定文字列を含む ) と NOT_CONTAINS ( 特定文字列を含まない ) を条件指定に利用できるようになりました。
Add support for CONTAINS and NOT_CONTAINS comparison operators for Automation Rules string filters and map filters
AWS SecurityHub - 9 updated api methods
何が嬉しいか
より柔軟かつ便利に Automation Rules で条件を指定可能になりました。
例えば、リソース名のプレフィクスを指定して自動抑制したい場合を考えます。
この際、ResourceId として ARN を指定できるので、こちらを利用して条件を設定することとします。
S3 なら arn:aws:s3:::バケット名 のような形なので、PREFIX( 前方一致 ) を使って arn:aws:s3:::バケットのプレフィクス名 を指定すれば問題ありません。
ECR の場合、ARN は arn:aws:ecr:リージョン名:アカウント名:repository/リポジトリ名 となります。
単一アカウントの場合はアカウント名も含めて PREFIX で指定すれば良いですが、複数アカウントに同一のルールを適用させたい場合は、完全一致か前方一致しか選べないことでアカウント数分ルールを作成する必要がありました。
多くのアカウントを集約している場合は単純に面倒ですし、ルール数の上限が 100 個であることも意識する必要もありました。
今回 ARN の中に文字列を含むかどうかで条件を作成可能になったので、アカウントに関係なく一つのルールで条件を作成することができるようになりました。(厳密にはプレフィクスで無くなりますが、多くのケースで問題無いと思っています。)
もちろん、リソース名内のプレフィクスでない一部を指定することも可能です。
[補足]マルチアカウント/マルチリージョンで Automation Rules を利用する場合の挙動
リージョンに関しては利用している全てのリージョンで Automation Rules を設定する必要があります。
アカウントについては、 Security Hub の集約設定を行うことでメンバーアカウントにおける検出結果にも Automatin Rules を適用可能です。
Security Hub 管理者アカウントのみが自動化ルールを作成、削除、編集、表示できます。管理者が作成したルールは、管理者アカウントとメンバーアカウントの検出結果に適用されます。
メンバーアカウント ID を基準として定義することで、Security Hub 管理者は自動化ルールを使用して特定のメンバーアカウントの検出結果を更新したり、検出結果に対してアクションを実行したりすることもできます。
自動化ルール
Automation Rules を利用して CDK Bootstrap で作成されるリソースを自動抑制してみた
CDK Bootstrap で自動作成されるリソースが Security Hub で違反扱いになっていたので、まとめて自動抑制してみました。
これらのリソースはテンプレートを用意することで設定変更可能ですが、デフォルトの構成から変更することで今後のデプロイに影響を与える可能性を考えてできれば変更したくないと考えました。
よって、違反項目を全て抑制することとします。
この際、集約しているメンバーアカウントについても自動抑制の対象とします。
ちなみに、違反しているのは下記コントロールでした。
- [ECR.1]ECR プライベートリポジトリでは、イメージスキャンを設定する必要があります。
- [S3.9]S3 バケットサーバーアクセスログ記録を有効にする必要があります
- [S3.11]S3 バケットでは、イベント通知を有効にする必要があります
Security Hub の集約設定を実施している状態で、管理者アカウント側で Automation Rules を設定します。
ルールテンプレートとして Elevate severity of findings that relate to important resources を使用しました。
ReourceId に cdk-hnb659fds を含むリソースを指定します。
厳密にはプレフィクスを cdk-hnb659fds にしないケースも想定されますが、私の場合は特に変更したことが無かったのでこちらを指定しました。
ブートストラップスタックのすべてのリソースの名前に追加される文字列です。修飾子を使用すると、を使用して同じ環境で複数のブートストラップスタックをプロビジョニングするときに、リソース名の衝突を回避できます--toolkit-stack-name。デフォルトはですhnb659fds (この値には意味がありません)。
ブートストラッピング
今回は実施していないですが、特定コントロールで自動抑制する場合は GeneratorId としてコントロール名を指定することができます。
また、CONTAINS と NOT_CONTAINS を利用する場合は、条件に一致する検出結果のプレビューを利用することができません。
ワークフローステータスに SUPPRESSED を指定して、ルールを作成します。
この状態で、管理者アカウントとメンバーアカウントで cdk bootstrap を実行してみました。
[ECR.1]ECR プライベートリポジトリでは、イメージスキャンを設定する必要があります。 で確認すると、 2 つのアカウントで指定したリソースが自動抑制されていました。
まとめ
Security Hub Automation Rules が一気に便利になったように感じています。
抑制したい検出結果がある方は是非活用してみて下さい！
0
