マネージドサービス部 佐竹です。
AWS re:Inforce 2025 に現地参加してきましたので、そのログを順番に記述しています。
はじめに
2025年6月16日から18日にかけて、ペンシルベニア州フィラデルフィアで AWS のセキュリティに特化したカンファレンス「AWS re:Inforce 2025」が開催されました。
参加したセッションのまとめを「1日のまとめ」に書いていこうとしたらあまりにも文章量が増えすぎてしまったので小分けにしています。
本ブログは「【AWS re:Inforce 2025】現地参加レポート 1日目 6月16日(月) 佐竹版」より IAM221 Secure and scalable customer IAM with Cognito: Wiz's success story の解説です。
私の感想やコメントは解説の邪魔になると感じたので「脚注」として記載しています。
IAM221 Secure and scalable customer IAM with Cognito: Wiz's success story 解説
概要
このセッションでは、デジタルトランスフォーメーション (DX) における顧客 ID ・アクセス管理 (CIAM) の重要性と、そのための対応を Amazon Cognito を用いて如何に実行するのか、 Wiz 社の成功事例を交えて解説されました((CIAM は Customer Identity and Access Management の省略で、顧客の ID とアクセスを管理するシステムであり、認証認可の基盤のことを言います))。
なぜ今、CIAM が重要視されるのか？（課題）
セッションの冒頭では、なぜ今 CIAM がビジネスの中心的な課題となっているのかが、具体的なデータと共に示されました。
本スライドで示されている通り、ユーザー体験の悪化、またパスワード忘れといった問題は、直接的な収益損失に繋がります。以下はスライドの内容をまとめた一覧です。
88%のユーザーは、一度でも悪いオンライン体験をするとそのサービスに戻ってこない42%のユーザーは、パスワードを忘れたことが原因で購入を断念した経験がある*1- データ侵害の
74%には、認証情報の窃取が関わっている
これらの課題に加え、次のスライドでは 「What's Driving Organizations to Embrace CIAM?」 というタイトルが掲げられました。
直訳すると「何が組織を CIAM の導入へと駆り立てるのか？」となりますが、CIAM を単に導入する (adopt) のではなく、「積極的に受け入れる (Embrace)」という単語が使われている点が印象的です*2。
またその具体的な要因として、以下の4点が挙げられました。スライドにはシンプルにアイコンしかないため、口頭での補足をまとめています。
- Hyper-scale Demands (ハイパースケールへの要求): 数百万、数千万といったユーザー規模を捌くスケーラビリティが求められる*3
- Legacy Tools are Cumbersome (レガシーツールの煩雑さ): 既存の ID 管理ツールは、現代的な開発手法や要求に対応しきれない
- Compliance (コンプライアンス):
GDPRやCCPAなど、世界各国の規制への準拠が必須となっている - Threat Sophistication (脅威の高度化): 巧妙化するサイバー攻撃からユーザー情報を守る、より高度なセキュリティ対策が必要となる
解決策としての Amazon Cognito（解決策）
これらの課題に対応するための AWS のサービスが Amazon Cognito です。
Amazon Cognito は、アプリケーションへのサインアップ、サインイン、アクセスコントロールを迅速かつ簡単に追加できるフルマネージドの CIAM サービスです。
本スライドに示されている通り、高い可用性とスケーラビリティ、開発の複雑さのオフロード、各種コンプライアンス要件への対応、そして組み込みの脅威検知機能を提供します。
Cognito の脅威検知機能についての補足
スライド右上で触れられている Cognito の「ビルトインの脅威検知機能」は、かつては「Amazon Cognito の高度なセキュリティ機能 ( Advanced Security Features )」と呼ばれていたものの現在の名称です。
Threat protection, formerly called advanced security features, is a set of monitoring tools for unwanted activity in your user pool, and configuration tools to automatically shut down potentially malicious activity.
(翻訳)
脅威保護 (以前は高度なセキュリティ機能と呼ばれていました) は、ユーザー プール内の不要なアクティビティを監視するツールと、潜在的に悪意のあるアクティビティを自動的にシャットダウンする構成ツールのセットです。
https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-settings-threat-protection.html
本機能により、侵害された認証情報のチェックや、ログイン試行のリスクレベルに応じて多要素認証 ( MFA ) を要求するアダプティブ認証などを提供し、Cognito のセキュリティをさらに強化することが可能となります。
Advanced Security Features は 2017年に発表された比較的歴史のある機能となっており、標準機能とは別の追加の有料オプションとなっていました。
ただし、以下のブログにある通り2025年に料金体系にアップデートがありました。
January 28, 2025: The following blog post highlights how to add threat detection to your custom authentication flows by using Amazon Cognito. With the introduction of new Cognito feature tiers, threat protection features are now included as default features for Plus tier customers.
(翻訳)
2025年1月28日: 以下のブログ投稿では、Amazon Cognito を使用してカスタム認証フローに脅威検出機能を追加する方法について解説しています。Cognito の新機能ティアの導入により、Plus ティアのお客様には脅威保護機能がデフォルトで提供されるようになりました。 https://aws.amazon.com/jp/blogs/security/adding-threat-detection-to-custom-authentication-flow-with-amazon-cognito-advanced-security-features/
このアップデートによりコスト面にもメリットがあるため、現在 Cognito で高度なセキュリティ機能の利用を検討されている場合は、「Cognito の Plus ティア」を選択し、これら「脅威保護」機能を活用することが最新のベストプラクティスとなっています。
その他 Essentials と Plus ティアで利用ができるパスワードレスログインなど、最新の情報は以下のブログも合わせて確認してみてください。
CIAM 移行の4つの主要パターン
既存の ID 基盤から Amazon Cognito へ移行する際には、ビジネス要件に合わせて適切な戦略を選択する必要があります。セッションでは、主に4つのユーザー移行パターンが紹介されました。
それぞれのパターンの特徴を以下のテーブルにまとめます。
| 移行パターン | 概要 | メリット | デメリット等 |
|---|---|---|---|
| 1. 一括インポート | CSV ファイルなどを用いてユーザー情報を一括で Cognito にインポートする |
迅速に多数のユーザーを移行できる | 既存ユーザーはパスワードの再設定が必要になる |
| 2. 管理者作成 | 管理者がユーザーをプロビジョニングし、一時パスワードを発行する | B2B 環境など、管理者がユーザーを一元管理したい場合に有効 |
ユーザー自身のアクションを必要としないが、管理者の手間がかかる |
| 3. JIT 移行 | ユーザーが初めてログインするタイミングで、Lambda トリガーを利用して旧 ID 基盤で認証。成功した場合に、そのユーザー情報を Cognito に自動的にプロファイルを作成・移行する |
ユーザーはパスワードを意識することなく、シームレスに新基盤へ移行できる。最もユーザー体験が良い | 旧 ID 基盤と連携するための Lambda 実装が必要 *4 |
| 4. B2Bハイブリッド | 上記のパターンを複数組み合わせる。例えば、新規顧客は直接 Cognito で作成し、既存顧客は JIT で移行するなど |
ビジネスの複雑な要件に柔軟に対応できる | 設計や実装が複雑になる可能性がある |
- JIT は
Just-in-Timeの略で「必要な時に必要なだけ」という意味です - 「Just-in-time user migration」についてはこちらの AWS 公式ブログを合わせてご参考ください
導入事例: Wiz 社の Cognito 移行
本セッションのハイライトである、クラウドセキュリティプラットフォームを提供する Wiz 社の事例です。
同社は FedRAMP コンプライアンスの達成と SLA 99.9% の実現という高い目標を掲げ、Cognito への移行を執り行いました。
本スライドは Wiz が辿った実装の道のりをロードマップとして示しています。
本ロードマップの重要なポイントは、単に技術的な移行を進めるだけでなく、「M5-6: Dev focus on a productized migration (移行体験のプロダクト化への開発フォーカス)」というステップが含まれている点です。移行を一時的なプロジェクトではなく、継続的に改善されるプロダクトとして捉えるマインドセットが、成功の鍵でした。
この旅を経て、Wiz は1年で 1,000 以上の顧客テナント、100,000 以上のマシン ID を移行し、IAM 関連コストを 70% も削減したと報告されました。
Wiz が語る「もっと早く知っておきたかったこと」とは
セッションの最後に、Wiz は移行プロジェクトから得られた教訓を「もっと早く知っておきたかったこと ( What We Wish We Knew Earlier )」として共有しました。
- B2B ≠ B2C:
B2BとB2Cでは、求められる要件（例：ID フェデレーション、テナント管理など）が全く異なることを常に意識する。 - Put customers in control (顧客にコントロールを与える): 移行のタイミングや方法などを顧客自身が選択できるようにするなど、顧客に主導権を与える設計を心がける。
- Self-service is a must (セルフサービスは必須): 管理者に依頼しなくても顧客自身で移行作業を完結できる、セルフサービスな仕組みを提供する。これが「移行はプロジェクトではなくプロダクト」という考え方に繋がっています。
- Start with M2M in mind (M2Mを念頭に置く): マシン間 (M2M) 認証を後回しにしない。最初から人間とマシンの両方の ID を計画に含めることが、後の手戻りを防ぐ。
- Iterate, don't wait (反復し、待たない): 完璧を待たない。
80%の完成度でリリースし、フィードバックを得ながら反復的に改善していくアプローチが成功の鍵。
今後の展望
セッションの最後には、Wiz が Cognito への移行を完了した後の「今後の計画」についても触れられました。
本スライドでは、Wiz が Cognito と共に目指す未来として、以下の3点が挙げられました。
- SLA and RTO: さらなる
SLA(サービスレベルアグリーメント) の向上とRTO(目標復旧時間) の削減。基盤としての信頼性を継続的に高めていくことへの期待が示されています。 - M2M: マシン間認証のユースケースとスケールの強化。Wiz のビジネスで重要となるマシン ID の管理において、
Cognitoのさらなる機能拡張を望んでいることがわかります。 - Roadmap: 共有ロードマップにおける緊密な連携。Wiz のプロダクト計画と
Cognitoのサービス開発計画を連携させることで、将来必要な機能をスムーズに実現していくという、強力なパートナーシップを築いていく意志が示されました。
関連情報
セッションの動画
本ブログを見て興味が出た方は是非元の発表動画もどうぞ。
【Amazon Cognito】ユーザープールのアドバンスドセキュリティ機能(ASF:Advanced Security Feature)について
Adding threat detection to custom authentication flow with Amazon Cognito advanced security features
脅威保護による高度なセキュリティ
Approaches for migrating users to Amazon Cognito user pools
ユーザー移行の Lambda トリガー
まとめ
弊社のエンドユーザー様からも、実際に CIAM の管理をどのようにするべきかお問い合わせを受けることがあります。
この時、やはり Amazon Cognito を利用頂くのがベストプラクティスだと考えています。しかし、私にはあまり Cognito の実装経験がないため今回の LT は参考になる点が多かったです。
特にカスタマーサクセス（CSM）というロールでは、AWS の実装時の細かい設定よりかは、「何故それが必要なのか？」のストーリーや、将来を見据えた拡張性や運用を語る必要があります。
今回の事例は、Wiz が具体的な数字や、4パターンあるそれぞれの移行方法のメリットデメリットを紹介してくれたため、本事例を元にしてエンドユーザー様に案内するのに非常に役立ちそうです。
また、これは1本目のレポートにも記載したことなのですが、Wiz という急成長中の企業が具体的に Amazon Cognito を利用した事例を出してくれるのは説得力が大きく、顧客説明のシーンでは特にありがたいなと感じました。
では、またお会いしましょう。
*1:パスワードを忘れてもう使わなくなる、というのは言われて見れば確かに。私の感覚では「パスワードを忘れても頑張って使おうとするだろう」という思い込みがあったのですが、4割近いユーザーが断念するのは厳しい現実です
*2:「embrace」はビジネス英語において「受け入れる」や「積極的に取り込む」といった意味で、特に変化や新しいアイデア、機会などを前向きな姿勢で受け入れるニュアンスがあるそうです
*3:これは先に記載した Meta 社の事例と同様の理由ですね https://blog.serverworks.co.jp/reinforce2025-nis321
*4:https://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/user-pool-lambda-migrate-user.html
佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ
マネージドサービス部所属。AWS資格全冠。2010年1月からAWSを業務利用してきています。主な表彰歴 2021-2022 AWS Ambassadors/2020-2025 Japan AWS Top Engineers/2020-2025 All Certifications Engineers。AWSのコスト削減やマルチアカウント管理と運用を得意としています。
