はじめに
2020/1/15 の Updateにより AWS Secuirty Hub のセキュリティ標準機能で
各ルールセット内の個別のチェック項目を無効化できるようになりました。
AWS Security Hub releases the ability to disable specific compliance controls
https://aws.amazon.com/jp/about-aws/whats-new/2020/01/aws-security-hub-releases-ability-disable-specific-compliance-controls/
個人的に待ち望んでいた機能であったため、CIS AWS Foundations Benchmarkのチェックを例にまとめます。
CIS AWS Foundations Benchmark とは
米国の非営利団体である CIS (Center for Internet Secuirty) が公開している
AWSアカウントの基本的なセキュリティを実装するための技術的なベストプラクティスです。
CISのベンチマークは PCI DSS などのコンプライアンス要件で業界標準のベストプラクティスとの
記載があった場合などに参照されます。
CIS Amazon Web Services Foundations Benchmark v1.2.0 - 05-23-2018
https://d1.awsstatic.com/whitepapers/compliance/AWS_CIS_Foundations_Benchmark.pdf
CIS AWS Foundations Benchmarkのv1.2.0では49項目の推奨事項があり、以下のような構成になっています。
- Identity and Access Management (22項目)
- アカウントやユーザーIDのアクセス管理に関する推奨事項
- 主にルートアカウントやIAMユーザーおよびそれらに紐づくアクセスキーを管理するための内容
- Logging (9項目)
- アカウント内のログの取得と管理方法に関する推奨事項
- 主にCloudTrailおよびConfigによるアクティビティの記録およびその保護に関する内容
- Monitoring (14項目)
- アカウントに関連するアクティビティのモニタリングに関する推奨事項
- 意図しないアクティビティをCloudTrailによって記録し、CloudWatchによってモニタリングする
- Networking (4項目)
- VPCのセキュリティに関する推奨事項
- VPCフローログの取得、セキュリティグループの設定、VPCピアリング時のルートテーブルの設定
AWS Security Hubによるコンプライアンスの自動チェック
AWS Security Hub は AWS環境全体のセキュリティとコンプライアンスの状況を確認可能なサービスです。
Security Hubのセキュリティ標準機能を利用すると、CIS AWS Foundations に
定義されている各項目を自動的かつ継続的にチェック※することができます。
※以下の6項目は外部からチェックできないため、Security Hubではサポートされていません。
- 1.15 秘密の質問がAWSアカウントに登録されていることを確認する
- 1.17 現在の連絡先を最新の状態に維持する
- 1.18 セキュリティ連絡先情報が登録されていることを確認する
- 1.19 インスタンスからのAWSリソースアクセスにIAMインスタンスロールが使用されていることを確認する
- 1.21 コンソールパスワードを持つIAMユーザーの初期セットアップ中にアクセスキーを設定しない
- 4.4 VPCピアリングのルーティングテーブルが「最小アクセス」であることを確認する
これらを除いた全43項目のチェックが行われるわけですが、今回のアップデートで
項目単位でチェックを無効化できるようになりました。
個別に無効化できると何が嬉しいのか
CIS Benchmarkで提供されるベストプラクティスは推奨事項ですので
あらゆる環境で必ず全て準拠しなければならないというものではありません。
特に以下のような場面で活用が期待できます。
1.Identity and Access Management に関わる項目
パスワードポリシーに関連する項目は組織やシステムレベルで既にルールが決まっているケースもあります。
例えば、
「1.9 IAM パスワードポリシーで 14 文字以上の長さが要求されていることを確認する」
という推奨事項があります。
これはコンソールアクセス時のパスワードに対する総当たり攻撃への対策となりますが
一方で
「1.2 コンソールパスワードを持っているすべての IAM ユーザーについて多要素認証 (MFA) を有効にする」
ではコンソールパスワードの他に多要素認証(MFA)の使用を推奨しています。
1.2を必須とし、安全対策が十分と判断できるのであれば、組織やシステム環境によっては
14桁以上のパスワードは必須ではないと考えることができる場合もあります。
2. Loggingに関わる項目
AWS Security Hubはリージョナルサービスです。
つまり、AWSアカウント全体のコンプライアンスを可視化するには
リージョンごとにSecurity Hubを有効化する必要があります。
しかしながら、Loggingや後述するMonitoringに関する推奨事項は
実運用を考えると、全てのリージョンで完全な準拠を目指すことは難しくなります。
例えば
「2.1 CloudTrail がすべてのリージョンで有効であることを確認する」という推奨項目と
これに関連して
「2.3 CloudTrail ログを保存するために使用される S3 バケットが一般にアクセス可能ではないことを確認する」
「2.6 CloudTrail S3 バケットで S3 バケットアクセスログが有効であることを確認する」
という推奨項目があります。
2.1 の推奨項目ではCloudTrailでマルチリージョンの証跡が有効化されているかどうかを確認します。
具体的には証跡設定の「証跡情報全てのリージョンに適用」という項目を はい に設定する必要があります。
東京リージョンでマルチリージョンの証跡を有効化する場合、ログを保存するS3バケットも
東京リージョン作成することになります。
一方、2.3および2.6を確認する際、Security Hubは自分と同じリージョンのバケットしか参照できません。
つまり東京リージョン以外のSecuirty Hubは証跡が保存されているS3バケットの設定を確認できません。
この場合、東京リージョン以外のSecurity Hubは以下のように対象のリソースが見つからないという
「警告」という結果を返します。
複数アカウントのログを1つのバケットに集約しているような場合も同じような状況になります。
このような場合ではマルチリージョンの証跡を取得しているリージョンやアカウント以外では
チェックを無効化することができるでしょう。
3. Monitoringに関わる項目
Loggingと同様の理由です。
Monitoringの全14項目に準拠するにはCloudTrailのログをCloudWatchでモニタリングし
特定の操作が発生した場合に、SNSによってメール通知する設定が必要です。
東京リージョンでマルチリージョン証跡を有効化している場合は
東京リージョンのCloudWatch/SNSにモニタリングの設定を行う必要があります。
その他のリージョンのSecurity Hubは東京リージョンのモニタリングの設定を
確認することはできないので以下のように「警告」のステータスとなります。
全てのリージョンでCloudTrailを設定し、モニタリングの設定を行うこともできなくはないですが
- 同じ内容のログが複数のリージョンで取得される
- 1つのアラーム結果がリージョンの数だけ重複して通知される
などかなり冗長な設定となります。
セキュリティ標準の準拠率をあげるために冗長なログを取得してコストをかけるというのは本末転倒です。
このような場合はモニタリングを行うリージョン以外では3.Monitoringの14項目を
全て無効化してしまうほうが運用しやすいはずです。
また「1.1「ルート」アカウントの使用を避ける」に関しても、チェックの際は
「3.3 「ルート」アカウントの使用に対してログメトリクスフィルタとアラームが存在することを確認する」
の定義が適切に設定されていることを確認するため、
その他のリージョンでは同じく結果は「警告」となります。
実際に無効化してみる
コンソールから無効化
無効化を行う手順はとても簡単です。
各チェック項目に表示されている「無効化」を選択します。
無効化時は必ずチェックを無効にする理由を入力する必要があります。
理由を入力後、無効化をクリックします。
この操作によりチェックの対象外となり、準拠率の計算からも外されるようになります。
誰でも簡単に無効化できないように、IAMユーザーに渡す権限には注意する必要があります。
CLIから無効化
コンソールから簡単に無効化できるとはいえ、全てのリージョンで無効化を行いたい場合
画面ポチポチでリージョンを切り替えて操作するのはとても辛いと思います。
その場合、CLIやSDK経由で一括で無効化してしまうのがよいかと思います。
CLIの場合、以下のようなコマンドで無効化/有効化を切り替えることができます。
アカウントIDの箇所は読み替えてください。
# 専用のAPIが追加されているため、AWSCLIの場合、Version 1.17.3 以降が必要
$ aws --version
aws-cli/1.17.3 Python/3.6.0 Windows/10 botocore/1.14.3
# バージニア北部リージョンで、CIS 1.9 を無効化するコマンド例
$ aws securityhub update-standards-control --control-status DISABLED \
--disabled-reason "CIS1.2のMFA有効化によりリスクを低減できるため、対象外とする" \
--standards-control-arn "arn:aws:securityhub:us-east-1:0123456789012:subscription/cis-aws-foundations-benchmark/v/1.2.0/1.9" \
--region us-east-1
# 無効化→有効化に戻すパターン
$ aws securityhub update-standards-control --control-status ENABLED \
--standards-control-arn "arn:aws:securityhub:us-east-1:0123456789012:subscription/cis-aws-foundations-benchmark/v/1.2.0/1.9" \
--region us-east-1
本来であれば CloudFormation で必要な項目を一括設定できるのが理想なのですが、
残念ながら2020年1月時点ではセキュリティ標準に関連する操作には対応していません。
複数アカウントで結果を統合している場合の挙動
Security Hubは複数アカウント出力結果を1つのマスターアカウントに連携して管理することができます。
マスターアカウント、メンバーアカウントでそれぞれを無効化した場合、以下のような挙動になります。
メンバーアカウントで項目を無効化した場合
マスターアカウントは各メンバーアカウントの結果を統合して確認することができます。
メンバーアカウントで項目を無効化すると、そのアカウントの情報はマスターアカウント側の
結果一覧から除外されます。反映は即時ではなく、一定の時間がかかります。
以下は実際に複数アカウントを接続しているマスターアカウントからみたセキュリティ標準の結果です。
13アカウントで利用中ですが、CIS 1.9 の結果については1つのメンバーアカウントで
無効化を行ったため、合計が12アカウントとなっていることがわかります。
マスターアカウントで項目を無効化した場合
マスターアカウントで項目を無効化すると、メンバーアカウントの結果も確認できなくなります。
また個々のメンバーアカウントでは引き続きチェックが行われます。
マスターからメンバーアカウントへ無効化の設定が自動で引き継がれることはありません。
参考
Disabling Individual Compliance Controls - AWS Security Hub User Guide
https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards.html#securityhub-controls-disable
securityhub update-standards-control - AWS CLI Command Reference
https://docs.aws.amazon.com/cli/latest/reference/securityhub/update-standards-control.html
以上です。
参考になれば幸いです