うわっ…私のセキュリティスコア低すぎ…？Security HubのCISベンチマークの俺流チューニングで100%準拠を目指す

Security HubのCISコンプライアンスチェック機能を私流にチューニングする方法を紹介します。CISベンチマークはやや厳し目のチェック項目なため、一般的にはチェックしなくても良い項目があるので、それは無効化してもいいかもしれません。検討するための要点を解説しています。

#セキュリティ

#AWS Config

#AWS Security Hub

#AWS

臼田佳祐

2020.03.11

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、臼田です。

皆さん、コンプライアンスチェックしてますか？(挨拶

Security Hubがリリースされて久しいですが、活用していますか？

Security Hubにはいくつか機能がありますが、その1つがコンプライアンスチェックです。下記を見てください。

こんな真っ赤に出されると流石にまずいなーと思いますよね？

でも実際にはそこまで対応しなくてもいいなって項目もぼちぼちあったりします。

この記事では、私の独断と偏見で無効化してもいいチェック項目を抜粋したり、無効化するかどうかの判断材料を提供していくことにより、100%対応を目指します。

その前に前提の話

そもそも、Security Hubってどんなサービスだっけ？CISベンチマークってどんなものなの？という疑問がある方もいそうなので軽く解説します。

Security Hubとは

Security Hubは2018年のre:Inventで発表されたインシデントやコンプライアンスの情報を一元的に管理するサービスです。

GuardDutyやInspectorなどのインシデントの情報をまとめたり、CISベンチマーク等のコンプライアンスチェックを行うことができます。

最近PCI DSS v3.2.1にも対応しました。

CISベンチマークとは

CISベンチマークはCISという非営利団体が作成しているセキュリティ標準です。

AWSについてはAWS CIS Foundations Benchmarkというものがあり、Security Hubではこの項目のチェックに対応しています。

一般的なコンプライアンス基準は、ある程度広く定義があり詳細なパラメータまで決まっていないことが多いですが、CISベンチマークは詳細なパラメータまで決められていることが特徴です。

そのため、評価が非常にしやすいです。

チェック項目一覧

AWS CIS Foundations Benchmarkは現在v1.2.0というバージョンが最新で、Security Hubもこのバージョンに対応しています。チェック項目の一覧と軽い解説を載せます。

CIS 1 Identity and Access Management

1.1 – 「ルート」アカウントの使用を避ける
- ルートアカウントは強い権限を持ちアクセス制御をかけられないことから基本的に封印するアカウントです。
1.2 – コンソールパスワードを持っているすべての IAM ユーザーについて多要素認証 (MFA) が有効にします。
- AWSのコンソールはインターネットからアクセスできるため認証にはMFAが必須です。
1.3 – 90 日間以上使用されていない認証情報は無効にします。
- 認証情報の定期的な棚卸しを行い不要なものは削除しましょう。
1.4 – アクセスキーは 90 日ごとに更新します。
- パスワードと同じような扱いで更新します。
1.5 – IAM パスワードポリシーには少なくとも 1 つの大文字が必要です
1.6 – IAM パスワードポリシーには少なくとも 1 つの小文字が必要です
1.7 – IAM パスワードポリシーには少なくとも 1 つの記号が必要です
1.8 – IAM パスワードポリシーには少なくとも 1 つの数字が必要です
1.9 – IAM パスワードポリシーは 14 文字以上の長さが必要です。
1.10 – IAM パスワードポリシーはパスワードの再使用を禁止しています
1.11 – IAM パスワードポリシーにより、パスワードは 90 日以内に有効期限が切れます
- これらは強固なパスワードの運用をサポートします。IAMの設定で行なえます。
1.12 – ルートアカウントキーが存在しないことを確認します
- ルートアカウントは強力なためアクセスキーを発行すべきではありません。
1.13 – 「ルート」アカウントで MFA を有効にします。
- ルートアカウントは強力なためMFAが必須です。
1.14 – 「ルート」アカウントでハードウェア MFA を有効にします
- ルートアカウントは強力なためハードウェアMFAを利用するとより強固に守れます。
[Security Hub未実装]1.15 – 秘密の質問が設定されていること
- 万が一の際に利用します。
- 例えばMFAデバイス障害などでAWSコンソールへのログインが不能となった際の問い合わせ時などです。
1.16 – IAM ポリシーはグループまたはロールのみにアタッチされます。
- IAMユーザーに直接ポリシーをアタッチすると管理が煩雑になるため、グループまたはロールにアタッチすべきです。
[Security Hub未実装]1.17 – 連絡先の情報更新
- 連絡先は、セキュリティ上の問題やAWSポリシー違反などの通知に利用されます。
[Security Hub未実装]1.18 – セキュリティに関する連絡先の登録
- 特に重要な連絡先のためセキュリティに関する連絡先の情報が最新になっているか確認すべきです。
[Security Hub未実装]1.19 – EC2でのAWSリソースへのAPIアクセスはIAMインスタンスロールを利用していること
- アクセスキーが漏洩することを防止するため、EC2にはIAMロールをアタッチして利用すべきです。
[Security Hub未実装]1.20 – 特定のユーザーにAWSサポートへの問い合わせ権限が付与されていること
- 特定の許可されたユーザーのみがAWSサポートへ問い合わせできるようにすべきです。
[Security Hub未実装]1.21 – 不要なアクセスキーの発行を避ける
- 利用していない認証情報は削除すべきです。
1.22 – 完全な「*:*」管理権限を許可する IAM ポリシーは作成されません。
- 最小権限を意識すべきです。

CIS 2 Logging

2.1 – CloudTrail はすべてのリージョンで有効になっています。
- CloudTrailはAWS上でのAPI履歴を管理する必須機能。確実に全有効化すべきです。
2.2.– CloudTrail ログファイルの検証は有効なっています。
2.3 – CloudTrail が記録する S3 バケットはパブリックアクセスできません。
2.4 – CloudTrail 証跡は Amazon CloudWatch Logs によって統合されています
- 適切にログを取得し、制御すべきです。
2.5 – AWS Config が有効になっていることを確認する
- AWS Configは変更管理を行う必須機能です。確実に全有効化すべきです。
2.6 – S3 バケットアクセスログ記録が CloudTrail S3 バケットで有効になっていることを確認します
- ログへのアクセス記録は重要です。
2.7 – CloudTrail ログは保管時に AWS KMS CMK を使用して暗号化されていることを確認します
- CMKによる暗号化で、鍵へのアクセス権限がないユーザが閲覧することができなくなります。
2.8 – カスタマー作成の CMK のローテーションが有効になっていることを確認します
- CMKはローテーション機能を活用することにより簡単にキーのローテーションが可能です。
2.9 – すべての VPC で VPC フローログ記録が有効になっていることを確認します
- VPC内のトラフィックの記録はVPCフローログで取得可能です。

CIS 3 Monitoring

3.1 – 不正な API 呼び出しに対してログメトリクスフィルターとアラームが存在することを確認します
3.2 – MFA なしの AWS マネジメントコンソールサインインに対してログメトリクスフィルターとアラームが存在することを確認します
3.3 – 「ルート」アカウントに対してログメトリクスフィルターとアラームが存在することを確認します
3.4 – MFA なしの IAM ポリシーの変更に対してログメトリクスフィルターとアラームが存在することを確認します。
3.5 – MFA なしの CloudTrail 設定の変更に対してログメトリクスフィルターとアラームが存在することを確認します
3.6 – AWS マネジメントコンソール認証の失敗に対してログメトリクスフィルターとアラームが存在することを確認します
3.7 – カスタマー作成の CMK の無効化またはスケジュールされた削除に対してログメトリクスフィルターとアラームが存在することを確認します
3.8 – S3 バケットの変更に対してログメトリクスフィルターとアラームが存在することを確認します
3.9 – AWS Config 設定の変更に対してログメトリクスフィルターとアラームが存在することを確認します
3.10 – セキュリティグループの変更に対するメトリクスフィルターとアラームが存在することを確認します
3.11 – ネットワークアクセスコントロールリスト (NACL) への変更に対するログメトリクスとアラームが存在することを確認します
3.12 – ネットワークゲートウェイへの変更に対するログメトリクスとアラームが存在することを確認します
3.13 – ルートテーブルの変更に対してログメトリクスフィルターとアラームが存在することを確認します
3.14 – VPC の変更に対してログメトリクスフィルターとアラームが存在することを確認します
- これらのアラームを設定することにより影響度の高い操作を検知できます。

CIS 4 Networking

4.1 – どのセキュリティグループでも 0.0.0.0/0 からポート 22 への入力を許可しないようにします
4.2 – どのセキュリティグループでも 0.0.0.0/0 からポート 3389 への入力を許可しないようにします
- 確実に特定の場所からのみアクセスを許可すべきポートです。
- 利用しない時は閉じておくのも1つの手です。
4.3 – すべての VPC のデフォルトセキュリティグループがすべてのトラフィックを制限するようにします。
- デフォルトのセキュリティグループはEC2等の設定を省略した際に自動的に割り当てられることがあるため、必要以上にアクセスできないようにすべきです。
[Security Hub未実装]4.4 – 必要最低限のVPCピアリング用のルーティングを追加すること
- ピアリングを行うことにより直接VPC間の通信が可能です。

無効化する項目

おまたせしました。ここからが本題です。

上記の項目一覧を見ていただくと分かる通り、若干微妙だなーと思う項目がちらほらあると思います。というわけで私が無効化すべきと思う項目を列挙します。

1.4 – アクセスキーは 90 日ごとに更新します。
- アクセスキーがどうしても必要な場合には、ローカルPCやSaaSでの利用などとなり、そこを90日毎に更新することはあまり現実的では無くなってきます。
- IAM Roleが利用できるSaaS製品を利用している場合などにはアクセスキーを発行しないようにするなど、アクセスキーを極力発行しない工夫を行ったあと、どうしてもアクセスキーが残る場合には無効化を検討します。
1.11 – IAM パスワードポリシーにより、パスワードは 90 日以内に有効期限が切れます
- 企業のパスワードポリシーに依存しますが、必須では無いと思います。
- パスワード管理ツールなどを利用していれば優先度は下がるため、ポリシー上問題なければ無効化します。
- もちろんMFAは利用している前提です。
1.14 – 「ルート」アカウントでハードウェア MFA を有効にします
- ハードウェアMFAの利用は簡単ではないため必須でなくてもいいと思います。
2.6 – S3 バケットアクセスログ記録が CloudTrail S3 バケットで有効になっていることを確認します
- 適切なアクセス制御ができていれば、バケットのアクセスログまでは無くてもいいと思います。
- 完全な証跡管理の要件がある場合には有効にしましょう。
2.7 – CloudTrail ログは保管時に AWS KMS CMK を使用して暗号化されていることを確認します
- 適切なアクセス制御ができていれば、そこまでしなくてもいいと思います。
- CMKを利用することにより、より厳重に管理することは可能です。
- 暗号化要件が特にない場合には無効化してもいいでしょう。
2.8 – カスタマー作成の CMK のローテーションが有効になっていることを確認します
- CMKを利用しないのであれば一緒に無効化でいいでしょう。
2.9 – すべての VPC で VPC フローログ記録が有効になっていることを確認します
- VPCフローログはぼちぼち費用のかかる機能です。
- 上位レイヤーのログが適切に取れていれば必ずしも必要ではないです。
- 有効にしつつRejectログのみ取得する、という方法もあります。この場合はログ量が少なくなるため現実的になります。