AWS Security Hubで困ったこと - 電通総研テックブログ

こんにちは。電通国際情報サービス(ISID) X（クロス）イノベーション本部ソフトウェアデザインセンターセキュリティグループの山口です。

ISIDでセキュリティの担当をしていますが、AWSやAzure等のクラウドサービスを利用したシステム構築が一般的になり、オンプレミスでシステム構築をしていた頃よりも不用意な設定ミスによるセキュリティインシデントがより簡単に起こってしまう時代になったと感じています。このようなセキュリティインシデントを防止するための解決策の1つとして、AWS Security Hub¹があります。 Security Hubはセキュリティ情報を収集・チェック・評価を行うCSPM(Cloud Security Posture Management)機能を有するサービスです。今回は、Security Hubを使っていて困ったことや不明な点を詳しく調べたことについてご紹介します。

1. Secrets Managerを使用しても警告が出る件
2. NOT_AVAILABLE 問題
3. 消せないS3バケット問題
4. HTTPヘッダーの削除とDesync緩和モード
5. おわりに

1. Secrets Managerを使用しても警告が出る件

1.1. 対象のセキュリティ基準²

[CodeBuild.2] CodeBuild プロジェクト環境変数にクリアテキストの認証情報を含めることはできません

これは「CodeBuild 内で AWS_ACCESS_KEY_ID や AWS_SECRET_ACCESS_KEY などの認証情報はプレーンテキスト（クリアテキスト）で保存しないでください。」という内容です。

1.2. 設定方法

設定はビルドプロジェクトの作成時に行えます。

設定画面を見ると下記の3つの中から選択できることが分かります。 CodeBuild.2のアラートを検出されないようにするための正解は「パラメータ」です。 Systems Manager パラメータストアから認証情報を取得するようにできます。

プレーンテキスト（クリアテキスト）
パラメータ
Secrets Manager

1.3. 疑問点

プレーンテキストがセキュリティ上問題となることは分かりますが、Secrets Managerを使うのはよさそうに思えます。ですが、実際にSecrets Managerを指定するとCodeBuild.2でしっかりアラートが上がります。このことをAWS サポートに問合せしましたが、Security Hubの仕様とのことでアラートを検出させたくない場合は、対象のルール（セキュリティ基準）を無効化するしかないようです。

1.4.ちなみに

CodeBuildの実行環境からAWSリソースにアクセスしたい場合 AWS_ACCESS_KEY_ID や AWS_SECRET_ACCESS_KEY をCodeBuildの環境変数に設定するのではなく、CodeBuildプロジェクトのサービスロールに必要な権限を付与することで解決できます。

2. NOT_AVAILABLE 問題

2.1. 困ったこと

今回検証した環境では下図のように集約アカウントを準備して、複数の子アカウントの検出結果を集約アカウントで確認できるようにしました。

（Security Hubの動作イメージ）

ところが一部のアカウントに対して、特定のセキュリティ基準の検出結果で「NOT_AVAILABLE」と表示されていることに気が付きました。

2.2. 解決方法

AWS サポートに問い合わせたところ、「AWS ConfigにAWSリソースの設定詳細を取得するための権限が足りていないのではないか。」という回答でした。 Security HubはAWS ConfigにAWS リソースのチェックを代行してもらう動作のため、AWS Configに各種リソースへのアクセス権限が必要となります。今回はAWSの管理ポリシーAWS_ConfigRoleをAWS Configのロールに割り当てることで正常に検出結果が表示されるようになりました。

2.3. ちなみに

AWS Configの設定画面から「AWS Config サービスにリンクされたロールの作成」を選択するとAWSConfigServiceRolePolicyを含むロールがAWS Configに割り当てられます。

下記のリンクからも、分かるようにAWSConfigServiceRolePolicyとAWS_ConfigRoleはどちらを使用しても同じアクセス許可（2022年2月現在）となるため、その使い分けについては不明です。

https://docs.aws.amazon.com/ja_jp/config/latest/developerguide/security-iam-awsmanpol.html

3. 消せないS3バケット問題

3.1. 対象のセキュリティ基準[^2]

[S3.5] S3 バケットは、Secure Socket Layer を使用するためのリクエストが必要です

これは「S3 バケットのポリシーで、Secure Socket Layer (SSL) でのアクセスを必須に設定してください。」という内容です。

3.2. 設定方法

設定はS3バケットのバケットポリシーで行います。

{
  "Id": "ExamplePolicy",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowSSLRequestsOnly",
      "Action": "s3:*",
      "Effect": "Deny",
      "Resource": [
        "S3 バケットの ARN",
        "S3 バケットの ARN/*"
      ],
      "Condition": {
        "Bool": {
          "aws:SecureTransport": "false"
        }
      },
      "Principal": "*"
    }
  ]
}

3.3. 困ったこと

普段からHTTPSでアクセスしているため、上記の設定が有効になっているかを判断できなかったので、軽い気持ちでバケットポリシーを変更しました。

（変更前）"aws:SecureTransport": "false"

（変更後）"aws:SecureTransport": "true"

そうすると当然ですが、S3バケットに対するブラウザからのHTTPS通信は全て許可されなくなります。あわてて元に戻そうとするも下記のようにバケットポリシー自体にもアクセスできなくなってしまいました。

3.4. 解決方法

ルートアカウントでログインすればバケットポリシーを削除できるようですが、権限がなかったのでCloudShellから下記のコマンドを実行してバケットポリシーを削除しました。

aws s3api delete-bucket-policy --bucket "バケット名" --endpoint-url http://s3.ap-northeast-1.amazonaws.com

4. HTTPヘッダーの削除とDesync緩和モード

4.1. 対象のセキュリティ基準[^2]

[ELB.4] HTTP ヘッダーを削除するようにアプリケーションロードバランサーを設定する必要があります

これは「HTTP desync 攻撃を防ぐために、Application Load Balancerで無効な HTTP ヘッダー値をドロップするように設定してください。」という内容です。

4.2. 分からなかったこと

「ロードバランサー属性の編集」画面にて「無効なHTTPヘッダーを削除」チェックボックスをオンにすることで、セキュリティ基準はクリアできます。ここで、画面の上にある「Desync 緩和モード」という似たような目的に思えるチェックボックスがあったので違いをAWS サポートに聞いてみました。

4.3. 確認したこと

前提として、Desync 緩和モードは下記のURLにあるように、リクエストの分類とALBのモード設定に基づいて動作が決定します。詳細は下記のURLをご覧ください。

https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/application/application-load-balancers.html

2つのチェックボックスの違いを表にまとめると下記のようになります。

比較項目	無効なHTTPヘッダーを削除	Desync 緩和モード
設定パラメータ	routing.http.drop_invalid_header_fields.enabled	routing.http.desync_mitigation_mode
検査対象	HTTPヘッダー	HTTPリクエスト全体
不正なHTTPヘッダーの扱い	HTTPヘッダーを削除してリクエストをターゲットに転送	HTTPリクエストを破棄
評価順	先	後