はじめに

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

先日、ユーザ認証のバックエンドに 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サインアップ
SignInCognito自体の認証機構によるサインイン
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つの切り口で集計したメトリクスを取得できます。

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

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

メトリクス説明
RiskCognito に「セキュリティ上のリスクあり」と判定された試行数
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
オペレーション〜SuccessesAverage

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

リスク

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

系統メトリクス
セキュリティ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 を叩いて監視する必要があります。

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