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

はじめに

みなさん、セキュリティチェックしていますか？(挨拶

AWS Security Hub の『AWS 基礎セキュリティのベストプラクティス v1.0.0』に新たに 25個のチェック項目(コントロール)が 追加されました。AWS公式も以下のようにアナウンスしています。

この新しいチェック項目は Security Hub の [設定 > 一般 > 新しいコントロールの自動有効化] を ON に していると自動的に追加されます。 いつのまにか CRITICAL/HIGH の項目で失敗していて、大量に通知が飛んできた方もいらっしゃるかもしれません。

本ブログで新規追加されたコントロールを簡単なコメント付きで紹介していきます。 (コントロールの題目はまだ日本語化されていなかったので、 DeepLを活用して訳しています)

APIGateway

[APIGateway.1] API Gateway RESTとHTTP APIのロギングを有効にする必要があります

重要度: MEDIUM

• CloudWatch Logs を利用するため、費用と相談。本番環境であれば設定を推奨
• REST API の場合は "Kinesis Firehose → S3" 保存が可能。より安価にログ保存できます

DynamoDB

[DynamoDB.1] DynamoDBのテーブルは、需要に応じて自動的に容量をスケールする必要があります

重要度: MEDIUM

• 必須では有りませんが、コスト最適化、サービス稼働安定化のメリットがあります
• 使う場合の注意点は以下のとおり
  • オートスケールの挙動を理解して、設計する
  • スパイクに対しては事前にスループットを増やしたり、 Amazon DynamoDB Accelerator（DAX）を構成しておくべき

[DynamoDB.2] DynamoDBテーブルはポイントインタイムリカバリ(PITR)を有効にしておく必要があります

重要度: MEDIUM

• 本番環境では有効化を推奨
• PITR有効化により 過去35日間の任意の時点にリストアが可能になります
• AWS Backup で定期的なオンデマンドバックアップを取得している場合は必須ではありません

[DynamoDB.3] DynamoDB Accelerator (DAX)のクラスタは、安静時に暗号化されている必要があります

重要度: MEDIUM

• ディスクに保存されたデータが悪意のあるユーザーによってアクセスされるリスクを低減するメリットがあります
• 安静時暗号化を有効にするには、クラスタを再作成する必要がある点に注意

CloudFront

新しく CloudFront のチェック項目が追加されました。

(注) CloudFront のチェックは バージニア北部(us-east-1)でのみ可能です

[CloudFront.1] CloudFrontのディストリビューションでは、デフォルトのルートオブジェクトが設定されている必要があります

重要度: CRITICAL

• デフォルトのルートオブジェクトを定義していないい場合は、ルートへのリクエストはオリジンサーバへ渡されます
• 例えばオリジンサーバが S3バケットであった場合、 バケットポリシーのミスで「意図しない ListObjects 情報」がルートURLによって知られてしまうリスクがあります

[CloudFront.2] CloudFrontのディストリビューションでは、オリジンのアクセスIDが有効になっている必要があります

重要度: MEDIUM

• Origin Access Identity(OAI) は S3を公開状態にすることなく、 S3へのアクセスを CloudFrontからのリクエストに絞る仕組みです
• S3へのセキュアなアクセスを維持するメリットがあります

[CloudFront.3] CloudFrontのディストリビューションでは、トランジット時に暗号化が必要です

重要度: MEDIUM

• ケースバイケースですが、HTTPS要求(or HTTPSリダイレクト)とすることが好ましいです

[CloudFront.4] CloudFrontのディストリビューションでは、オリジンフェイルオーバーを設定する必要があります

重要度: Low

• 可用性を高める仕組みです
• 参考: アップデート: CloudFrontのみでオリジンフェイルオーバーが出来るようになりました！ | DevelopersIO

EC2

[EC2.9] EC2インスタンスはパブリックIPv4アドレスを持つべきではない

重要度: HIGH

• 意図しないパブリックIP付与 を検知するためにも有効化はしておくと便利です
  • デフォルトVPC上にインスタンスを立ててしまう
  • 設定ミスでサブネットのパブリックIP自動割当が有効になっている、など
• EIP による固定IP付与も非準拠になってしまいます
• 固定IP付与する理由の1つに 踏み台サーバがあると思います
  • 今では 踏み台サーバは必要なく SSMセッションマネージャによるアクセスが主流なので、 踏み台サーバを削除できないか検討しましょう
• どうしても「パブリックIP付与が必要なインスタンス」の場合は 抑制済み にして例外登録するのもアリです
  • その場合は ""SGは最小限に絞る"" など十分なセキュリティ対策を行いましょう

[EC2.10] Amazon EC2はVPCエンドポイントを使用するように設定する必要があります

重要度: MEDIUM

• VPCエンドポイント(ec2)を設置しているかどうかチェックを行います
• 本番環境VPC内で EC2 API を実行するワークロードがある場合は設置しましょう

EFS

EFS.2: Amazon EFSボリュームはバックアッププランに入れておくべき

重要度: MEDIUM

• EFSファイルのデータのバックアップは AWS Backup で管理できます
• 本番環境であれば設定を推奨

ELB

[ELB.3] Classic Load Balancer のリスナーは HTTPS または TLS 終端で設定する必要があります

重要度: MEDIUM

• ケースバイケースですが、HTTPSとすることが好ましいです

[ELB.4] Application Load Balancer が http ヘッダを削除するように設定されている必要があります

重要度: MEDIUM

• 有効でないリクエストヘッダーを除外する機能
• 例えばキーの文字列に「_」が含まれるリクエストヘッダーを除外できます
• 有効にする場合は検証環境でテストを行いましょう

[ELB.5] Application/Classic Load Balancer のロギングを有効にする必要があります

重要度: MEDIUM

• トラフィックの分析や問題のトラブルシューティングに役立ちます
• S3保存のため (バケットに適切なライフサイクル設定をしていれば) そこまでコストにはなりません
• 本番環境では設定を推奨

[ELB.6] Application Load Balancer の削除保護を有効にしてください

重要度: MEDIUM

• 予防的ガードレールとなります
• 意図しない削除の防止のためにも、本番環境では有効化を推奨

ES(Elasticsearch Service)

[ES.2] Amazon Elasticsearch ServiceのドメインはVPCである必要があります

重要度: CRITICAL

• 「転送中のデータへのアクセスを制限したい」制約がある場合は、VPCへの移行を推奨

[ES.3] Amazon Elasticsearchのドメインは、ノード間で送信されるデータを暗号化する必要があります

重要度: MEDIUM

• ドメインに機密データが含まれている場合は有効化を推奨
• 有効化する場合は HTTPS化によってパフォーマンスが低下する可能性があるため、十分にテストを行うこと

KMS

[KMS.3] AWS KMSのキーは意図せずに削除してはいけない

重要度: CRITICAL

• カスタマー管理CMKを削除する場合、7日〜30日の待機時間をスケジュールした後に削除されます
• 意図しない KMSキー削除スケジュールの検知のためにも有効化を推奨
• CMKは一度削除されると回復できず、 CMKで暗号化されたデータも永久に回復できないため影響が大きいです

RDS

[RDS.9] データベースのロギングを有効にする必要があります

重要度: MEDIUM

• RDSログが CloudWatch Logs に送信されているかどうかをチェックします
• 本番環境では有効化を推奨。アクセス監査や、トラブルシューティングに役立ちます

[RDS.10] RDSインスタンスに対してIAM認証を設定する必要があります

重要度: MEDIUM

• パスワード漏洩のリスクを無くせるメリットがあります
• 利用できる環境の場合は積極的に使っていきましょう

Redshift

[Redshift.1] Amazon Redshiftクラスタはパブリックアクセスを禁止すべき

重要度: CRITICAL

• 機密データが含まれている場合、パブリック公開するべきではありません
• パブリックアクセスを許容する場合は、セキュリティグループで必要最小限のソース/ポートに絞ること

[Redshift.2] Amazon Redshiftクラスタへの接続は、トランジット中に暗号化されている必要があります

重要度: MEDIUM

• 機密データが含まれている場合は有効化を推奨
• トラフィックの盗聴を防げます
• 有効化する場合は HTTPS化によってパフォーマンスが低下する可能性があるため、十分にテストを行うこと

[Redshift.3] Amazon Redshiftクラスタは自動スナップショットを有効にする必要があります

重要度: MEDIUM

• 自動スナップショットが有効になっているか、保持期間が 7日以上かどうかチェックします
• 本番環境では有効化を推奨

[Redshift.6] Amazon Redshiftはメジャーバージョンへの自動アップグレードを有効にすべき

重要度: MEDIUM

• 最新のメジャーバージョンアップデートがメンテナンスウィンドウ中にインストールされるようになります
• セキュリティパッチ/バグ修正や、新機能の実装などメリットがあるので有効化しておくと良いでしょう

[SNS.1] SNS トピックの保管時の暗号化を AWS KMS を使って有効化する必要があります

重要度: MEDIUM

• SNSトピックの内容次第で暗号化を検討しましょう
• ディスクへの物理的な不正アクセスに対する耐性が欲しい場合は AWS管理のキーで有効化
• IAMレベルで制御したい場合は、カスタマー管理型のキーを利用する

おわりに

以上、ざっと見てみました。

HIGH/CRITICAL の項目は以下のとおり

• CRITICAL [CloudFront.1] CloudFrontのディストリビューションでは、デフォルトのルートオブジェクトが設定されている必要があります
• HIGH [EC2.9] EC2インスタンスはパブリックIPv4アドレスを持つべきではない
• CRITICAL [ES.2] Amazon Elasticsearch ServiceのドメインはVPCである必要があります
• CRITICAL [KMS.3] AWS KMSのキーは意図せずに削除してはいけない
• CRITICAL [Redshift.1] Amazon Redshiftクラスタはパブリックアクセスを禁止すべき

CRITICAL で失敗しているものは早めに内容確認して、対応していきましょう。

以上、少しでもどなたかのお役に立てば幸いです。

参考

• AWS Foundational Security Best Practices controls - AWS Security Hub
• 新機能: Security HubがAWS基礎セキュリティのベストプラクティスについてコンプライアンスチェックできるようになったので詳細を解説しつつチューニングの考察してみた | DevelopersIO
• アップデート: 新たに7つのチェック項目が追加されたSecurity HubのAWS基礎セキュリティのベストプラクティスを確認してみた | DevelopersIO