Amazon Web Services ブログ
[AWS Black Belt Online Seminar] Amazon Cognito 資料及び QA 公開
先日 (2020/06/30) 開催しました AWS Black Belt Online Seminar「Amazon Cognito」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。
20200630 AWS Black Belt Online Seminar Amazon Cognito
AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます）
Q. ユーザープール、Cognito ID プールはどこに保存されるのでしょうか？例えば貴社でご用意する Cognito 用インスタンスのローカル等に保存されるイメージでしょうか？
A. お客様が指定された AWS リージョン内の Amazon Cognito 環境内に保存されます。
Q. ユーザープールに登録した情報（usename、password、email, tel）のバックアップとリストアは、どのように行えばよいですか？
A. Cognito ユーザプールはバックアップやリストアの機能は提供していませんが、ユーザプールに登録された情報は、安全に保存されています。そのため、単一リージョン内での耐久性では不十分な場合や操作ミスからの復旧が、バックアップやリストアの目的になるかと思われます。
前者への対応としては、定期的に全ユーザの属性を読み取って S3 や DB 等に保存しておく、あるいはユーザの新規・変更時に都度 DB にも記録する、ログイン時に発行される ID トークンの内容を都度 DB に反映しておくといった事をしておき、それをさらに別リージョンにもコピーするという方法が考えられます。ただし、パスワードは取り出すことはできません。万が一リストアする際は、バックアップデータからユーザ情報を Cognito ユーザプールに再登録し、パスワードについてはユーザの方に再設定して頂くことになります。なお、構成によってはユーザの入力したパスワードを DB 等に記録しておくことも不可能ではありませんが、セキュリティ上おすすめしません。
後者の操作ミスへの対応は、内容次第ですが、バックアップからユーザ情報を再登録するという方法に加え、例えばユーザは削除せずに無効化するだけに留めておくなどの方法も考えられます。
Q. ユーザーがログイン時に入力する情報に関して質問があります。
- ユーザー名
ユーザーをプール内で一意に特定するためのIDという認識でよいでしょうか？
例）tanaka_taro
A. はい、ご認識のとおりです。 - 任意のユーザー名
各ユーザーが自由に設定できるユーザー名称という認識でよいでしょうか？
例）田中 太郎
A. 任意のユーザ名 (preferred_username) は、ログイン時にユーザがユーザ名として利用する事も可能にできる属性となっています。姓名は一意にならない場合もあり、ログイン時のユーザ名として使用することも一般的に少ないかと思います。姓名は name、family_name、given_name などをご利用頂くのが良いかと思います。
Q. ユーザのカスタム属性に応じた IAM ロールを割り当てる機能は今後実装される予定はありますか？
A. Cognito ID プールの ID プロバイダ設定で、【認証されたロールの選択】で 【ルールを使用してロールを選択する】を利用するとカスタム属性に設定されている値に応じて指定したロールを割り当てる事が既に可能です。詳細はこちらの「ルールベースのマッピングを使用してユーザーにロールを割り当てる」を参照ください。
Q. 秘密の質問みたいな機能もあるのでしょか？
A. Cognito ユーザプールに秘密の質問を行うような機能はありませんが、お客様にて実装して頂くことは可能です。事前に秘密の質問への回答をアプリケーションが使用するデータベースに登録したうえで、ユーザ認証にカスタム認証を利用して秘密の質問を CUSTOM_CHALLENGE として出し、返ってきた回答を検証してください。
Q. Cognito がサポートしない MFA を CUSTOM_AUTH でサポートしたい場合、すでに作成済みのユーザープールに対しても適用可能でしょうか？
A. そのように実装は可能かと思います。
Q. マネージドコンソールでユーザー登録を行った場合、登録に使用した E メールに確認コードや確認リンクは送信されず仮パスワードが送信されるのは仕様でしょうか？
A. 管理者がユーザを作成する際の挙動です。代わりに招待メールを送付する事が選択できる仕様となっています。
Q. クライアントシークレットを割り当てない場合、どのようなセキュリティホールが考えられますか？
A. クライアントシークレットが割り当てられていない場合は、第三者のソフトウェアがそのアプリクライアントとして振る舞う事が簡単にできます。その様な事があっても、大きな問題はないようにする必要があります。
一般的に、利用可能な認証フローや読み書き可能な属性が利用用途として問題ない最小限の範囲となっているか確認ください。例えばもしご利用の用途では、属性の値を書き込む際には確認すべき事がある場合は、アプリクライアントに書き込みは許可せず、書き込みはサーバサイドで確認を行ってから実際に書き込みするのが望ましいです。また、認可コードの横取り対策として PKCE を行うようにしてください。
Q. Javascript で cognito 認証を実装しようと考えているのですが、クライアントシークレットは発行しない場合、非 AdminAPI は使えないのでしょうか？
A. クライアントシークレットを発行しないアプリクライアントからも、非 Admin API を利用して認証を実装して頂けます。
Q. AdminAPI と非 AdminAPI の使い分けについて、非 AdminAPI は非 SPA から呼び出せないとか以外になにかわりますでしょうか？
A. Webinar の中で便宜上、非 Admin API と呼ばせて頂いた API もサーバサイドから呼び出して頂けます。サーバサイドからの呼び出しにはあまり制約はないのですが、逆にブラウザなどのクライアントからの呼び出しには Admin API は呼び出せないなどの制約があります。
Q. 一旦、払い出した idToken と AccessToken を無効化して指定のユーザからのアクセスを拒否したい場合、どのような仕組みを実装するのが良いでしょうか？
A. 幾つかの実装方法が考えられますが、各ユーザごとに最後にログアウトした時刻を記録しておき、アクセスを受け付けた時にトークンに含まれている iat 属性でログアウト後に発行されたものを確認するなどの方法が考えられます。
Q. ApiGateway のオーソライザー作成時に、Cognito ユーザープールのトークンのソースとトークンの検証の項目に何が入力できてどのような機能が実現できるのかがわかりません。具体的な入力値について説明してあるドキュメントはありますか？
A. こちらの URL に記載があります。
【トークンソース】は、API にアクセスするクライアントが ID トークンあるいはアクセストークンを入れる HTTP ヘッダ名を指定します。一般的に Authorization を利用する事が一般的です。【Token validation (トークン検証)】はアクセスを許可するトークンの aud フィールドに入っている値を正規表現で限定します。aud にはアプリクライント ID が入るため、特定のアプリクライアントで発行された ID トークンのみにアクセスを限定したい時に利用できる設定になります。
Q. ALB による Cognito 認証ですが、JWT のトークンの検証のみを判定し、成功したらリクエストを通す、失敗したら 401 を返す、ということも可能でしょうか？
A. ALB による Cognito 認証機能は、リクエストに含まれている JWT トークンの検証を行うような機能はありません。
Q. グループをユーザー属性として、アプリケーションから確認、変更する方法をもう少し詳しく知りたいです。資料などありますでしょうか？Amplify をやっているのですが、AdminQueries から、グループを確認、変更することはできなさそうで、困っています。
A. AdminQueries からユーザが所属しているグループを確認するには、listGroupsForUser が利用できます。また、変更するには addUserToGroup と removeUserFromGroup が利用できます。詳細はこちらを参照ください。また、ID トークンやアクセストークンの中にも記載されています。
Q. Amplify のログインは Cognito の Hosted UI と同じ画面になりますでしょうか？
A. Amplify からは Hosted UI も、Android, iOS 以外向けで提供されている Amplify 独自のサインイン UI も両方両方利用いただけます。両者が異なる物でデザインも異なります。
Q. Amplifyを利用して構築する場合は、 Identity Provider APIの利用となるのか、 Auth API の利用となるのか、どちらでしょうか。Amplifyが用意したUIのバックエンドで Identity Provider API が動くイメージであってますか？
A. 両方が利用可能です。
Q. 1時間で期限が切れたトークンの更新は、自分で実装する必要のある処理ですか？（JavaScript の場合）
A. AWS Mobile SDK や Amplify Library では、更新トークンを持っている場合に ID トークン、アクセストークンは自動更新されます。その他の SDK を使用している場合や SDK を使わずに実装している場合は明示的に呼び出して更新する必要があります。
Q. ブラウザにおいて、Cognito にログインして取得した idToken,AccessToken はどこに保存しておくのが安全なのでしょうか。localStorage に保存するのは危険だという記事を見たのですが、Cookie でやりとりすべきなのでしょうか？
A. どこに保存するか、どのように扱うかなどは、アプリケーションにとってのリスクを総合的に判断頂き、決定頂ければと思います。Amazon Cognito Identity SDK for JavaScript、Amplify Library を利用する場合、Local Storage のみならず、Session Storage、Cookie に加え、お客様が独自に定義したストレージクラス経由で任意の方法でデータを保持させる事が可能となっています。
Q. ユーザーの認証のアクティビティのログは、Cognito のコンソール画面からしか確認できないのでしょうか？監査ログなので改ざんされていないことを保証する必要があるためだと思いますが、CloudTrail のように外部から解析しやすい形で提供されるでしょうか？
A. 申し訳ありませんが、マネージメントコンソールの Cognito の画面から確認できるユーザの認証ログ等はありません。CloudTrail には保存されますので、CloudTrail を利用頂ければと思います。
Q. Cognito に対するクライアントアクセスのログとして、認証元の IP アドレスの記録はあるでしょうか？（アプリケーションのセキュリティログ監視の要件があるため）
A. Cognito の Identity Provider API を呼び出したアクセス元の IP アドレスは記録されます。API 呼び出しをサーバサイド経由で行う場合は、記録されるのはサーバの IP アドレスになります。また、セミナーがでご紹介したとおり、ユーザ名等は記録されません。
Q. Cognito ログ分析のために、Lambda トリガー連携を話されていましたが、Lambda 使わない場合はcloudtrail でも確認できないので、lambda で記録する方法しかない認識でしょうか？
A. Labmda を利用しない場合も、CloudTrail にはログが保管されます。そのため、CloudTrail に保管されるログ内容では不十分なときにのみ、Lambda で追加の情報を出力して記録する方法が考えられることを案内させていただきました。
Q. エンドユーザが Cognitoでユーザ作成時にメールを送信しますが、docomo や au などキャリアメールに送信する場合、キャリアのメールフィルタにブロックされます。この場合エンドユーザのホワイトリストにドメインを追加してもらうしかないのでしょうか？
A. メール送信には、デフォルトの 【Cognito を使用】 ではなく 【Amazon SES を使用】を設定し、利用されるドメイン名の DNS に SPF レコードを登録し、DKIM による署名も利用ください。デフォルトよりメールを受信頂ける可能性が高くなるかと思います。
Q. ユーザーを E メールで作成した場合、E メール検証をリンクや検証コードにした場合、有効期限が24時間ですが、この時間を経過した場合の復帰方法はありますでしょうか。また、この有効期限 (24時間) は Cognito の制限でこれ以上伸ばせないと言う認識で良いでしょうか？
A. 新たな有効期限の確認メールを ResendConfirmationCode で再送付可能です。また、有効期限は 24 時間から変更は行えません。
Q. Auth API は、OpenID Connect 1.0 と OAuth 2.0 に準拠しているという認識で合っていますでしょうか？
A. 準拠ではありませんが、これらの標準仕様の一部を沿った形でサービス提供しています。
—
今後の AWS Webinar | イベントスケジュール
直近で以下を予定しています。各詳細およびお申し込み先は下記URLからご確認いただけます。皆様のご参加をお待ちしております。
—
AWSome Day Online Conference
「AWSome Day Online」は、AWSの主要サービスや基礎知識を約 2.5 時間という短い時間で、ポイントを押さえて紹介いたします。技術的な面だけではなく、AWS クラウドを学ぶために必要となる知識を身に付けたい方、エンジニアのみならず、営業職、プリセールス職、学生まで幅広い方々におすすめします。
※この回ではAWSエキスパートによる技術的な内容についてチャット形式でのQ&Aを実施します。
※AWS サービスの導入に関するご相談も同時にチャット形式にて対応します。
※2020年は毎月第一水曜日に開催します。
日時：2020 年 8 月 5 日（水） 15:00 – 17:40 終了予定 | 詳細・お申込みについてはこちら≫
—
Amazon EC2 が最大72%割引になる柔軟な料金モデル『Savings Plans』のご紹介
『Savings Plans』は 1 年または 3 年の長期利用契約による、Amazon EC2、AWS Fargate のコストを最大 72 % 削減可能な料金体系です。本ウェビナーでは Savings Plans ご紹介後、購入方法、お客様の現在の利用状況に合わせたご提案の確認方法もご紹介します。
※本セミナーは 2020 年 3月の AWS Innovate オンラインカンファレンスで公開した内容と同じものとなります。見逃した方はこの機会にご覧ください。
日時： 2020 年 7 月 30 日（木）10:00 – 10:30 | 詳細・お申込みについてはこちら≫
—
AWS Black Belt Online Seminar
7 月のアジェンダは以下を予定しています。セミナー中は内容に関する疑問点を質問することができます。参加された方だけの特権ですので、ぜひこの機会にご視聴ください。
- 7/14（火）12:00-13:00 Amazon Neptune
- 7/15（水）18:00-19:00 Amazon Detective
- 7/21（火）12:00-13:00 AWS App Mesh
- 7/22（水）18:00-19:00 AWSアカウント シングルサインオンの設計と運用
- 7/28（火）12:00-13:00 What’s New in Serverless
- 7/29（水）18:00-19:00 Amazon Redshift Advanced Guide −最新ベストプラクティスとアップデート