![【Security Hub修復手順】[Cognito.2] Cognito アイデンティティプールでは、認証されていない ID を許可しないこと](https://images.ctfassets.net/ct0aopd36mqt/5HhaOnXgcaK80eorXpnxyD/57c471f47b2f7e9c65e7bc2f185a9184/aws-security-agent.png?w=3840&fm=webp)
【Security Hub修復手順】[Cognito.2] Cognito アイデンティティプールでは、認証されていない ID を許可しないこと
かつまたです。
本記事では、AWS Security HubによるAWS環境のセキュリティ状況スコアリングに該当する項目についての修復手順をご紹介します。
本記事の対象コントロール
[Cognito.2] Cognito アイデンティティプールでは、認証されていない ID を許可しないこと
[Cognito.2] Cognito identity pools should not allow unauthenticated identities
前提条件
本記事はAWS Security Hubで「AWS基礎セキュリティのベストプラクティススタンダード」を利用されている方向けの内容です。
AWS Security Hubの詳細についてはこちらのブログをご覧ください。
対象コントロールの説明
このコントロールは、Cognito IDプールでゲストアクセス（認証されていないID）が有効になっていないかチェックします。
ゲストアクセスを非アクティブ化する（AllowUnauthenticatedIdentities を false にする）と、成功します。
IDプールでゲストアクセスを有効にすると、どの認証プロバイダーでもログインしていないユーザーにも認証情報が発行されます。
対応が必要な理由
ゲストアクセスが有効なIDプールは、IDプールIDさえ分かれば誰でも一時認証情報を取得できます。
# 認証なしで実行できる（--no-sign-request は署名を付けずにAPIを呼ぶオプション）
aws cognito-identity get-id --identity-pool-id <IDプールID> --no-sign-request
aws cognito-identity get-credentials-for-identity --identity-id <ID> --no-sign-request
つまり、未認証ロールにアタッチした権限を、不特定多数に開放されたものとして扱う必要があります。
ゲストアクセスを有効にする理由がない場合は、匿名アクセスを塞ぐセキュリティ対応として環境を問わずの非アクティブ化が推奨されます。業務要件として匿名アクセスが必要な場合の選択肢は、後述します。
修復手順
修復手順: ゲストアクセスを非アクティブ化する
-
Amazon Cognitoコンソールを開き、左メニューから「IDプール」を選択します
-
対象のIDプールを選択し、「ユーザーアクセス」タブを開きます
-
「ゲストアクセス」の「非アクティブ化」を選択します。
-
ステータスが「非アクティブ」になったことを確認します
ゲストアクセスしか使っていないIDプールはコンソールから非アクティブ化できません
IDプールはゲストまたは認証されたアクセスのいずれかをアクティブにしておく必要があるため、IDプロバイダーを設定しておらず、認証されたアクセスが非アクティブのIDプールでは、非アクティブ化試行時に以下が表示され、実行できません。
CLIの場合
update-identity-pool でゲストアクセスを無効化します。
なお、このAPIは指定しなかった項目が初期値に戻ります。IDプロバイダーの紐付けなど他の設定を持つプールでは、describe-identity-pool で現在の設定を控えて同じ値をあわせて指定するか、コンソールで操作してください。
aws cognito-identity update-identity-pool \
--identity-pool-id <IDプールID> \
--identity-pool-name <IDプール名> \
--no-allow-unauthenticated-identities \
--region ap-northeast-1
{
"IdentityPoolId": "ap-northeast-1:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"IdentityPoolName": "my-identity-pool",
"AllowUnauthenticatedIdentities": false,
"IdentityPoolTags": {}
}
応答の AllowUnauthenticatedIdentities が false になっていれば修復完了です。
どうしても匿名アクセスが必要な場合
ログイン前のユーザーにAWSリソースへのアクセスを提供したい場合でも、IDプールのゲストアクセスを開ける以外の選択肢があります。
クライアントから直接AWSリソースを呼び出さず、API Gateway + Lambdaのようなバックエンドを挟む構成にすると、AWS認証情報をクライアントに渡さずに済み、レート制限やWAFによる保護も適用できます。
この場合、Cognito.2はFAILEDのまま残るため、検出結果を放置せずワークフローステータスの「抑制済み」への変更や、オートメーションルールによる自動抑制といった対応も必要になるかと思います。
最後に
今回は、Cognito.2の修復手順をご紹介しました。
修復操作そのものはコンソールで数クリックですが、ゲストアクセスに依存したアプリケーションがあると影響が出るのでアプリ側含めた事前環境把握が重要になると思います。
ご覧いただきありがとうございました。
