AWS Security Hub の『基礎セキュリティのベストプラクティス』に追加された 10個のコントロールを見てみる【2021/07アップデート】

はじめに

2021/07/30 に Security Hub の 『基礎セキュリティのベストプラクティス』に 新しくコントロールが追加された、とアナウンスされました。

AWS Security Hub has released 10 new controls for its Foundational Security Best Practice standard to enhance customers’ cloud security posture monitoring. These controls conduct fully-automatic checks against security best practices for Amazon API Gateway (APIGateway.4), Amazon CloudFront (CloudFront.5, CloudFront.6), Amazon EC2 (EC2.17, EC2.18), Amazon Elastic Container Service (ECS.1), Amazon Elasticsearch Service (ES.4), AWS Identity and Access Management (IAM.21), Amazon Relational Database Service (RDS.15), and Amazon Simple Storage Service (S3.8).

– 引用: AWS Security Hub adds 10 new controls to its Foundational Security Best Practices standard for enhanced cloud security posture monitoring

新しく ECSの項目が追加されたことが熱いですね。 コンテナワークロードのセキュリティチェックの充実もこれから期待できます。

さっそく見ていきましょう。

※1) 各コントロールのドキュメントリンクも載せていますが、 2021/08/03 現在日本語訳はありません。英語ドキュメントを御覧ください。

※2) 以前のアップデートで追加されたコントロールの紹介は↓にあります

• AWS Security Hub の『基礎セキュリティのベストプラクティス』に追加された 16個のコントロールを見てみる【2021/05アップデート】 | DevelopersIO
• 【アップデート】AWS Security Hub の『基礎セキュリティのベストプラクティス』に新たに25個のチェック項目が追加されました | DevelopersIO

(new) Amazon Elastic Container Service

[ECS.1] Amazon ECSのタスク定義には、安全なネットワークモードとユーザー定義が必要です

AWSドキュメント

重要度: HIGH

(コメント) ネットワークモードが host のタスク定義パラメータをチェックします。 『priviledged=false or 空』かつ『user=root or 空』 のとき非準拠となります。

privileged はコンテナに特権を与えるためのパラメータです。 hostモードで有効にできます。 これが false or 空 のときは unprivileged(権限が無い) と解釈されます。

user は コンテナ内で使用するユーザーを指定するパラメータです。 user=root とすると、もちろんルート権限が与えられます。 また、 user=空 の場合は rootと解釈されます 。

つまり、このチェックは『特権と与えていないつもり(priviledged=false)でも、 実は特権を与えてしまっていないか(user=root)』を確認します。

host モードのタスク定義がある場合は、必ず確認しておきたい項目です。

また、そもそも host モードを採用しないことも考えましょう。 hostモードは 1ホスト上で同じポートを利用するタスクを複数起動できなかったり、 上記のようなセキュリティ的懸念があるためです。 AWSとしては、特に制約がない限り awsvpc の使用を勧めています。

Amazon ECSでは、別のネットワークモードを使用する必要がない限り、 awsvpc ネットワークモードの使用をお勧めします。

– 引用: Amazon ECS タスクネットワーキング - Amazon Elastic Container Service

(参考)

• Amazon ECS タスクネットワーキング - Amazon Elastic Container Service
• タスク定義パラメータ #privileged - Amazon Elastic Container Service
• タスク定義パラメータ #user - Amazon Elastic Container Service

Amazon API Gateway

[APIGateway.4] API Gatewayは、AWS WAFのWeb ACLと関連付ける必要があります

AWSドキュメント

重要度: MEDIUM

(コメント) REST API Gateway は WAFとの連携が可能です。 SQLインジェクションやXSS攻撃など、一般的なウェブの脆弱性保護や、 特定IPアドレスからのリクエストのみ許可、といった制御ができます。 本番環境ではぜひ使いましょう。

(参考)

• AWS WAF を使用して API を保護する - Amazon API Gateway
• AWS WAFを完全に理解する 〜WAFの基礎からv2の変更点まで〜 | DevelopersIO

Amazon CloudFront

※ CloudFront は バージニア北部(us-east-1) 限定のコントロールです

[CloudFront.5] CloudFrontのディストリビューションはログを有効にする必要がある

AWSドキュメント

重要度: MEDIUM

(コメント) CloudFront のアクセスログをS3バケットへ保存しているか、チェックを行います。 S3バケットへの保存なので、そこまでコストにはならないでしょう(適切なライフサイクルポリシーが前提)。 入れておいて損はないと思います。

(参考)

• 標準ログ (アクセスログ) の設定および使用 - Amazon CloudFront

[CloudFront.6] CloudFrontのディストリビューションはAWS WAFを有効にする必要があります

AWSドキュメント

重要度: MEDIUM

(コメント) CloudFront に WAFが関連付けられているかチェックを行います。 SQLインジェクションやXSS攻撃など、一般的なウェブの脆弱性保護や、 特定IPアドレスからのリクエストのみ許可、といった制御ができます。 本番環境ではぜひ使いましょう。

(参考)

• AWS WAFをCloudFrontに導入する | DevelopersIO
• AWS WAFを完全に理解する 〜WAFの基礎からv2の変更点まで〜 | DevelopersIO

Amazon EC2

[EC2.17] EC2インスタンスは複数のENIを使用してはならない

AWSドキュメント

重要度: LOW

(コメント) 複数ENIはネットワーク構成が複雑になるデメリットが大きいです。

(参考)

• AWS EC2におけるネットワークインターフェース構成を考える | DevelopersIO

[EC2.18] セキュリティグループは、許可されたポートに対する無制限の受信トラフィックのみを許可する必要がある

AWSドキュメント

重要度: High

(コメント) 本チェックでは「許可されたポート」は HTTP(80)および HTTPS(443)です。 これら以外のポート全開放が無いかチェックします。 リスクのあるセキュリティグループが存在しないか、チェックに活用できます。

ちなみに、SSH/RDP に関しては Security Hub の自動修復ソリューション で 自動で全開放を防ぐ仕組みを作ることができます。

(参考)

• 【神機能】Security HubでCISの違反を自動修復する仕組みが提供されたので試したりちょっと深堀りして理解してみた | DevelopersIO

Amazon Elasticsearch Service

[ES.4] Amazon Elasticsearch ServiceのドメインエラーのCloudWatch Logsへのロギングが有効であること

AWSドキュメント

重要度: MEDIUM

(コメント) 監査要件、可用性要件次第で対応するかどうか決定しましょう。

(参考)

• Monitoring Elasticsearch logs with Amazon CloudWatch Logs - Amazon Elasticsearch Service

AWS Identity and Access Management

[IAM.21] 作成したIAMカスタマーマネージメントポリシーでは、サービスに対するワイルドカードアクションを許可してはならない

AWSドキュメント

重要度: LOW

(コメント) Allow ステートメントで Action に "[service]:*" のようなワイルドカード指定が あった場合に非準拠になります。以下 ドキュメントにある非準拠例です。

{
  "Sid": "EC2-Wildcard",
  "Effect": "Allow",
  "Action": "ec2:*",
  "Resource": "*"
}

カスタマー管理ポリシーでも、上記のような書き方をするケースは多々あります (リソースを絞れる場合は絞る)。 重要度がLOWということもあり、この項目は無理に対応する必要は無さそうです。

対応する場合はポリシーの精査、例えば ec2:Describe* のように アクション名のプレフィクスで絞れないか検討しましょう。

Amazon Relational Database Service

[RDS.15] RDS DBクラスターは複数のアベイラビリティーゾーンに対して構成されるべきである

AWSドキュメント

重要度: MEDIUM

(コメント) [RDS.5] RDS DB instances should be configured with multiple Availability Zones のAuroraクラスター版です。 高可用性が求められる環境では対応しましょう。

(参考)

• Amazon Aurora の高可用性 - Amazon Aurora
• ちょっと待って！Auroraを使う時にMulti-AZが本当に必要ですか？ | DevelopersIO

Amazon Simple Storage Service

[S3.8] S3ブロックのパブリックアクセス設定はバケットレベルで有効にすべき

AWSドキュメント

重要度: HIGH

(コメント) [S3.1] S3 Block Public Access setting should be enabled がアカウント全体のブロックパブリックアクセス設定でしたが、 こちら( [S3.8] ) はバケット単位のチェックです。

パブリックアクセスが必要なバケットが有り [S3.1] を無効化せざるを得なかった 場合に、本チェックが役立つでしょう。 定期的にチェックしたい項目です。

(参考)

• Amazon S3 ストレージへのパブリックアクセスのブロック - Amazon Simple Storage Service

おわりに

以上、追加されたコントロールを見ていました。 どんどん増える『基礎セキュリティのベストプラクティス』、 頑張って追い続けてスコアを上げていきましょう。