はじめに

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

先日、ユーザ認証のバックエンドに 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 ごとではないので注意しましょう。)

CallCount と ThrottleCount の 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 を叩いて監視する必要があります。

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