【アップデート】AWS Security Hub の『AWS 基礎セキュリティのベストプラクティス』に新たに7個のチェック項目が追加されました

2023.03.31

みなさん、こんにちは。

明るい笑顔がトレードマークの芦沢(@ashi_ssan)です。

みなさん、Security Hubの運用できていますか?

AWS Security Hubの『AWS 基礎セキュリティのベストプラクティス v1.0.0』に新たに 7個のチェック項目(コントロール)が 追加されました。

本エントリでは、新規追加されたコントロールに関する情報を簡単なコメント付きで紹介していきます。

新規コントロール一覧

  • [ElastiCache.1] ElastiCache for Redisクラスターでは、自動バックアップをスケジュールする必要があります。
  • [ElastiCache.2] ElastiCache for Redisキャッシュクラスターのマイナーバージョンの自動アップグレードが有効であること
  • [ElastiCache.3] ElastiCache for Redisのレプリケーショングループで、自動フェイルオーバーを有効にしてください
  • [ElastiCache.4] ElastiCache for Redisのレプリケーショングループで、保管時の暗号化を有効化する必要があります
  • [ElastiCache.5] ElastiCache for Redisのレプリケーショングループで、転送時の暗号化を有効化する必要があります
  • [ElastiCache.6] バージョン 6.0 より前の Redis レプリケーション グループ用 ElastiCache では、Redis AUTH を使用する必要があります
  • [ElastiCache.7] ElastiCache クラスターは、デフォルトのサブネットグループを使うべきではありません

ElastiCache

[ElastiCache.1] ElastiCache for Redisクラスターでは、自動バックアップをスケジュールする必要があります。

重要度: High

AWSドキュメント: [ElastiCache.1] ElastiCache for Redis clusters should have automatic backups scheduled

コメント:

  • 自動バックアップを有効化した場合、別途追加のコストが発生したり、バックアップ時にパフォーマンスに影響があるなど注意すべき点があります。システムの重要度と比較して検討してください。
  • コストやパフォーマンス劣化が許容できる場合、耐障害性を考慮して自動バックアップは有効化しておくことを推奨します。ただし、セッション等の一時的に消失しても問題ない情報のみを扱っている場合は無効化でも問題ありません。

[ElastiCache.2] ElastiCache for Redisキャッシュクラスターのマイナーバージョンの自動アップグレードが有効であること

重要度: High

AWSドキュメント: [ElastiCache.2] Minor version upgrades should be automatically applied to ElastiCache for Redis cache clusters

コメント:

  • ElastiCacheはバージョンアップグレード時に既存のデータをできるだけ保持するように設計されていますが、マイナーバージョンアップによってサービスへの影響が出てしまう可能性があります。
  • 本番環境などのサービス影響がクリティカルな環境においては自動バージョンアップを無効化し、バージョンを固定化しても問題ないです。 その他の環境(検証・開発など)では自動バージョンアップの有効化を推奨します。

[ElastiCache.3] ElastiCache for Redisのレプリケーショングループで、自動フェイルオーバーを有効にしてください

重要度: Medium

AWSドキュメント: [ElastiCache.3] ElastiCache for Redis replication groups should have automatic failover enabled

コメント:

  • 自動フェイルオーバーを有効化すると、プライマリノードのメンテナンスや障害時に利用可能なレプリカノードの1つをプライマリノードへ自動で昇格させます。
  • レプリカノードの昇格により、新しいプライマリへの書き込みをすぐに再開できるようになり全体的なダウンタイムが短縮されるため、有効化を推奨します。
  • Amazon ElastiCacheは昇格したレプリカのDNSの変更を伝達するため、アプリケーション側のエンドポイント変更は不要です。
  • マルチAZを有効化するとアベイラビリティーゾーンの耐障害性が向上するため、併用を推奨しています。

[ElastiCache.4] ElastiCache for Redisのレプリケーショングループで、保管時の暗号化を有効化する必要があります

重要度: Medium

AWSドキュメント: [ElastiCache.4] ElastiCache for Redis replication groups should be encrypted at rest

コメント:

  • 保管時の暗号化を有効化すると、保存されたデータが悪意のあるユーザーによってアクセスされるリスクを低減するメリットがあります。
  • ただし、バックアップオペレーションやノード同期オペレーション等のパフォーマンスに影響を与える可能性があります。 機密情報や個人情報等は含まれず、永続的なバックアップも不要な場合は、性能評価した上で保管時の暗号化の必要性をご検討ください。
  • 保管時の暗号化を有効にするには、レプリケーショングループを再作成する必要がある点に注意が必要です。

[ElastiCache.5] ElastiCache for Redisのレプリケーショングループで、転送時の暗号化を有効化する必要があります

重要度: Medium

AWSドキュメント: [ElastiCache.5] ElastiCache for Redis replication groups should be encrypted in transit

コメント:

  • 転送時の暗号化を有効化すると転送中のデータが盗聴されるリスクの低減やRedis AUTH 機能によるサーバー認証やクライアント認証を実装可能です。
  • ただし、エンドポイントでデータの暗号化と復号の処理が必要となり、パフォーマンスに影響を与える可能性がありますので、事前の検証が必要です。
  • キャッシュやセッション等の揮発性のあるデータのみの場合は、データの機密性やコンプライアンス要件の観点から転送時の暗号化の必要性をご検討ください。
  • 転送時の暗号化を有効にするには、レプリケーショングループを再作成する必要がある点に注意が必要です。

[ElastiCache.6] バージョン 6.0 より前の Redis レプリケーション グループ用 ElastiCache では、Redis AUTH を使用する必要があります

重要度: Medium

AWSドキュメント: [ElastiCache.6] ElastiCache for Redis replication groups before version 6.0 should use Redis AUTH

コメント:

  • Redis AUTHを使用することで、ユーザーにトークン (パスワード) の入力を要求できるため、セキュリティが向上します。 機密性の高いデータを Redis で保持する場合は設定を推奨します。
  • 設定する際は、合わせて定期的なキーのローテーションを行うとよりセキュアになります。
  • セキュリティグループ等の設定により外部の脅威に対する防御ができている場合や、機密性の高いデータが含まれていない開発環境では無効化にしても問題ないです。

[ElastiCache.7] ElastiCache クラスターは、デフォルトのサブネットグループを使うべきではありません

重要度: Medium

AWSドキュメント: [ElastiCache.7] ElastiCache clusters should not use the default subnet group

コメント:

  • デフォルトのサブネットグループは、デフォルト VPC のサブネットを使用するため、意図しない通信を許可する可能性があります。
  • 適切なサブネットでの ElastiCache クラスター起動を推奨します。

おわりに

以上、追加されたSecurity Hubの新規コントロールについて確認してみました。

重要度が高い(HIGH )のコントロールは、以下となっております。

  • [ElastiCache.1] ElastiCache for Redisクラスターでは、自動バックアップをスケジュールする必要があります。
  • [ElastiCache.2] ElastiCache for Redisキャッシュクラスターのマイナーバージョンの自動アップグレードが有効であること
  • [ElastiCache.7] ElastiCache クラスターは、デフォルトのサブネットグループを使うべきではありません

CRITICALの新規コントロールはありませんでしたが、HIGHで失敗しているものについては優先度を上げて確認しておきましょう。

ここまで読んでくださりありがとうございました。どなたかのお役に立てば幸いです。

以上、芦沢(@ashi_ssan)でした。

スペシャルサンクス

本記事の執筆にあたり、各コントロールのコメント等の精査に関して以下のメンバーにも協力いただきました!感謝します。