NIST CSFの適合パックを普通に使おうと思ったときのチューニング案
こんにちは、臼田です。
みなさん、AWS環境のセキュリティチェックしていますか?(挨拶
今回は先日提供されたNIST CSFのConformance Packs(適合パック)について、一般的な環境で使おうと思ったときのチューニングについて考えてみました。
Conformance Packsとは
Conformance Packsは簡単に言うとConfig Rulesの集合体です。
Config RulesはAWS上の各種リソースの設定が、決められた基準を満たしているか確認するサービスです。
例えば不用意にSSHがセキュリティグループで全開放(0.0.0.0/0からのアクセスを許可)していたりしないか、MFAが設定されていないIAMユーザーはいないか、など様々なセキュリティ上の問題点などを発見することが可能です。(セキュリティ用途以外でも利用可能です)
Conformance Packsはそのようなセキュリティチェック項目を詰め込んだテンプレートを適用して展開することができるサービスです。
Conformance Packsで提供されているテンプレートは現状下記7種類があります。これらはサンプルテンプレートと呼ばれ、逆に独自に定義することも可能です。(ここ重要)
- AWS Control Tower 検出ガードレールコンフォーマンスパック
- Amazon DynamoDB 運用のベストプラクティス
- Amazon S3 運用のベストプラクティス
- AWS Identity And Access Management 運用のベストプラクティス
- CIS 運用のベストプラクティス
- NIST CIS 運用のベストプラクティス
- PCI-DSS 運用のベストプラクティス
実はConformance Packs以外にもSecurity Hubで同じような機能を提供しています。Security Hubのスタンダードというセキュリティチェック機能でも、PCI DSSやCISなどのチェックが行えます。
この機能との違いは、ルールを自分たちで変更できるかというところがあります。Security Hubでは展開したルールを変更したり削除することはできませんが(無効化ならできる)、Conformance Packsではテンプレートを任意に変更できるため、必要ないルールを除外したり、逆に追加したりも可能です。
また、今回対象としているNIST CSFのルールはSecurity Hubには無いため、利用できるルールにも違いがあります。
NIST CSFのテンプレートとは
NIST CSF(サイバーセキュリティフレームワーク)は今日よく参照されるセキュリティのベースラインでサイバーセキュリティのデファクトスタンダードになりつつあると言われています。
AWSからも、AWS上でCSFを適用していくためのホワイトペーパーが出ています。
CSFにはコアと呼ばれる 5 つのリスク管理機能があり、識別、防御、検知、対応、復旧があります。これらについてAWSでどのようなサービスを活用していけばいいか、AWSと利用者の責任範囲がどうなっているかなどの記載があります。
Conformance PacksのNIST CSFは、これを適用すればすべての項目がCSF準拠になるというようなことは全くありませんが、準拠するための設定や運用を行うための強力なサポーターになります。
ルールの一覧
NIST CSFのConformance Packsルールについては下記で紹介されています。
使い方なども含めて参照してください。
いくつかいいなーと思う項目を抜粋して紹介します。
- AcmCertificateExpirationCheck
- ACMで管理している証明書の期限が近くなるとアラートを出してくれる
- デフォルト14日だけど伸ばしてもいいかも
- IamPolicyNoStatementsWithAdminAccess
- IAMポリシーでAdministratorAccessと同じような設定が作られている場合に検知する
- 利用者が不適切に広いポリシーを作成した場合に検知できるのでいい
- IamRootAccessKeyCheck
- ルートユーザーのアクセスキーがある場合に検知する
- ルートアクセスキーは存在してはならないため要チェック
- IamUserMfaEnabled
- IAMユーザーのMFAが有効かチェックする
- MFAはすべてのユーザーで必須なため重要
- IamUserUnusedCredentialsCheck
- 一定期間利用されていないIAMユーザーのクレデンシャルを検知
- 棚卸し用に活用できる
- IncomingSshDisabled
- 無制限のSSH(0.0.0.0/0)設定を検知する
- 無制限のSSH対策は必須
- LambdaFunctionPublicAccessProhibited
- Lambdaがパブリックアクセス可能な場合に検知
- パブリックアクセス禁止は必須。必要なことは基本無い。
他にも有用なものが多いので見てみてください。
チューニング案
ここからが本題です。どのようなルール群も、すべての環境でいい感じに当てはまるものではありません。
Conformance PacksのNIST CSFテンプレートも例外ではなく、一般的な環境で利用しようと思うとやや強めだったりする項目とかがあります。
というわけで私が無効化してもいいかなと思うものを紹介します。あくまで環境によって異なるので自身の環境で適用する際の参考として見てください。
- ストレージの暗号化系
- これは特定のルールではないが、S3やRDS、EBSなどのストレージ暗号化のチェックルールがいくつかある
- 透過的な暗号化のため、主に物理的なアクセスに対する耐性のための設定であるため必須ではない
- とはいえ、簡単に暗号化できるため採用するのもあり
- AccessKeysRotated
- IAMユーザーのアクセスキーを定期的にローテートするための項目
- 一般的にローテートが必ずしもリスクを低減できるわけではなく管理が難しい
- アクセスキーのローテートが回せる場合はやってもいい。ただし管理は気をつける。
- Ec2InstanceNoPublicIp
- EC2にパブリックIPが割あたっていることを検知する項目
- 踏み台とかも有り難しいところはある。ただ基本プライベートは心がけたい
- InternetGatewayAuthorizedVpcOnly
- 許可されたVPCのみインターネットゲートウェイのアタッチがされていることをチェックする
- 管理しづらい。VPCが増えた際にそれを許可するかどうかの判定が毎回必要。
- 管理できるならやってもいい。
- RootAccountHardwareMfaEnabled
- ルートユーザーを物理MFA設定しているか確認する項目
- MFAは必須だが、ハードウェアMFAは一般的に必須ではない
- VpcFlowLogsEnabled
- VPCフローログが有効になっているか確認する項目
- すべてのVPCで取ると大変
- 主にログの量に対する課金が課題になる
- 必要なところだけ取るようにするところから検討する
まとめ
NIST CSFのConformance Packsについてのチューニング案を出してみました。大事なことは自身の環境でどうしたいかを考えることです。あとは一律にチェックが通っているからOK、チェックがダメだからNGとかでも無いということを意識しましょう。
是非参考にしてください。