はじめに

平素は大変お世話になっております。
クイックガードのパー子です。

先日、ユーザ認証のバックエンドに Amazon Cognito を利用されているお客様システムの監視について、設計からお任せいただく機会がありました。

そのときの知見を基に、Cognito をどのように監視したらいいのか改めて整理してみました。

Cognito とは

最初に、Cognito がどういうサービスなのか軽くおさらいします。

What Is Amazon Cognito? - Amazon Cognito

Cognito とは、Webアプリケーションやモバイル・アプリケーションのための認証、認可、アカウント管理をフルマネージドで提供するサービス (= いわゆる IDaaS) です。

大きく UserPool と IdentityPool の 2つのコンポーネントから構成され、それぞれ以下の機能を司ります。

コンポーネント 機能
UserPool 認証、アカウント管理
IdentityPool (AWSサービスに対する) 認可

これらのコンポーネントを活用することでどういったシナリオを実現できるのか、典型的な組み合わせ例 が紹介されています。

詳細は AWS Black Belt Online Seminar でわかりやすく解説されています。

何を監視できる?

監視可能なメトリクスをコンポーネントにマッピングしてみました。

(https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-scenarios.html#scenario-aws-and-user-pool の図に加筆)

コンポーネントごとに詳細を見ていきましょう。

UserPool

CloudWatch で以下 3系統のメトリクスを取得できます。

系統 説明
オペレーション サインアップ、サインインなどのオペレーション別の試行数
APIコール API別のコール数
セキュリティ オペレーション試行において検出されたセキュリティ上のリスク数

オペレーション系と APIコール系は標準で、セキュリティ系は Advanced security を有効化することでメトリクスを取得できます。

オペレーション

以下のオペレーションがカウントされます。

オペレーション 説明
SignUp サインアップ
SignIn Cognito自体の認証機構によるサインイン
TokenRefresh トークンの更新
Federation 外部IDプロバイダによるサインイン

各オペレーションにはサフィックスとして 〜Successes〜Throttles があります。

サフィックス 説明
〜Successes (Success と言いながら) 成否両方の試行数
〜Throttles クォータを超過したためにスロットリングされた数

〜Successes では、Statistic を切り替えることで成功数以外の値を確認できます。

指標 Statistic
成功割合 Average
失敗を含めた総数 (※) Sample Count
成功数 Sum
失敗数 (※) Sample Count - Sum

※ スロットリングも失敗とみなされるため、スロットリングされた試行数を含みます。

〜Throttles においては、Statistic:Sum (または Sample Count) がスロットリングされた試行数を表します。

これらのメトリクスは、Namespace:AWS/Cognito / Group:By UserPool and UserPoolClient に格納されます。

外部IDプロバイダの場合は Group:Federation Metrics です。

APIコール

  • UserCreation
  • UserAuthentication
  • UserRead

など、API の カテゴリ ごとにコール数がカウントされます。
(個々の API ごとではないので注意しましょう。)

CallCountThrottleCount の 2種類があります。

メトリクス 説明
CallCount コールされた総数
ThrottleCount クォータを超過したためにスロットリングされた数

値は Statistic:Sum で確認します。

格納場所は Namespace:AWS/Usage / Group:By AWS Resource で、Service名は Cognito User Pool です。

セキュリティ

以下の 2つの切り口で集計したメトリクスを取得できます。

集計 説明
オペレーション別 オペレーション別のリスクの検出数
タイプ別 リスクのタイプ別の検出数

「オペレーション別」では、サインアップやサインインなどのオペレーションごとに、リスクあり/なしと判定された試行数がそれぞれカウントされます。

メトリクス 説明
Risk Cognito に「セキュリティ上のリスクあり」と判定された試行数
NoRisk リスクが検出されなかった試行数

格納場所は Namespace:AWS/Cognito / Group:By Request Classification です。

「タイプ別」は、リスクの内容ごとの集計数です。

メトリクス 説明
CompromisedCredentialRisk 漏洩した認証情報を用いた試行
AccountTakeOverRisk アカウントの乗っ取りが疑われる試行
OverrideBlock 管理者の設定によりブロックされた試行 (※)

※ 未検証ですが、Advanced security の設定画面で認証を拒否する条件をいろいろと設定できるので、おそらくそのルールに引っかかった試行が該当すると思われます。

Group:By Risk Classification に格納されます。

なお、具体的にどの認証試行がリスクありと判定されたのかは ユーザの詳細ページ から確認できます。

IdentityPool

IdentityPool では APIコールのみ監視できます。
他に監視できそうな項目はありません。

UserPool とは異なり、個々の API ごとにカウントされます。

メトリクスの格納場所は UserPool と同じく Namespace:AWS/Usage / Group:By AWS Resource で、Service名は Cognito Identity Pools です。

何を監視すべきか?

ここまで監視対象となり得る項目を見てきました。

これらのうち、以下の指標を監視することをオススメします。

API の Rate limit

クォータ にどの程度の余裕があるのかの把握は必須なので、API のコール数を監視します。

スロットリングの発生が検知されたら即時の対応が必要でしょう。

系統 メトリクス
オペレーション 〜Throttles
APIコール ThrottleCount

併せて、コール数がクォータの天井に迫っていないかを監視します。

系統 メトリクス
APIコール CallCount

現在のクォータの設定値は Service Quotas で確認できます。

クォータに到達しそう、かつ、引き上げ可能な API の場合は値の引き上げを申請しましょう。
(Service Quotas や Service limit increase form から申請できます。)

なお、APIコール・レートのクォータ値が明記されているのは UserPool のみであり、IdentityPool にレートのクォータが設定されているのかは不明です。
なので、今のところは CallCount については UserPool のみ監視しておけばよさそうです。

オペレーションの成功割合

サインアップやサインインの成功割合も監視するとよいでしょう。

系統 メトリクス Statistic
オペレーション 〜Successes Average

平常時と比べてあまりに割合が低いようなら、攻撃に晒されている可能性があります。

リスク

リスクの検出数を監視して、セキュリティ上の脅威に備えます。

系統 メトリクス
セキュリティ Risk

RiskLevel (Low 〜 High) に応じた対処ルールを定めるとよいでしょう。
(例: Low の試行はまとめて一定間隔で監査する、High の場合はアカウントを即時無効化する、など。)

他には?

リソース使用量に対しても クォータ が設定されています。
ざっと眺めてみましたが、積極的に監視したい項目は見当たりませんでした。

例えばユーザ数の上限はデフォルトで 40,000,000アカウントとなっており、ちょっとした規模のサービスであれば充分すぎるほど余裕があると思われます。

ちなみに、もし監視したい場合は CloudWatch では取得できないので API を叩く必要があります。

$ aws cognito-idp describe-user-pool --user-pool-id '{{ USER_POOL_ID }}' --query 'UserPool.EstimatedNumberOfUsers'
23

Appendix: サンプル・コード

今回の記事を書くにあたって使用した実験用アプリのコードを GitHub で公開しています。

公式ドキュメントにおけるシナリオの分類としては UserPool と IdentityPool を併用したもの で、Hosted UI を使い、ログインしたら指定した S3 の中身を列挙するだけのささやかな Webアプリです。

https://github.com/quickguard-oss/cognito-example

git clone したら Configファイル (awsConfig.js) を自分の環境に合わせて書き換えてください。

$ git clone https://github.com/quickguard-oss/cognito-example
$ cd ./cognito-example/my-app/
$ cp ./src/awsConfig.js.example ./src/awsConfig.js  # +環境に合わせて書き換え
$ npm install
$ npm run start

まとめ

Amazon Cognito について、何を監視できるのか、何を監視すべきなのかを整理してみました。

特に以下 3点を監視しておくことをオススメします。

  • API の Rate limit
  • サインアップやサインインなどのオペレーションの成功割合
  • セキュリティ上のリスクの検出数

ユーザ数の上限は充分に余裕があると思いますが、もし監視したい場合は、CloudWatch では取得できないので自身で API を叩いて監視する必要があります。

今後ともよろしくお願い申し上げます。