背景・目的
以前、Amazon Cognitoを試してみた(ユーザプール編)では、SAMLやOpenID Connectをサービスとしていて供しているAmazon Cognitoについて整理しました。
今回は、IDaaSと呼ばれるサービスの一つのAuth0について特徴を整理し、アカウントを開設してみます。
まとめ
下記にIDaaSや、Auth0、アイデンティティの特徴を整理します
特徴 | 説明 |
---|---|
IDaaSとは? | ・IDentity As A Serviceの略 ・複数のサービスのID、パスワードを一元管理できるクラウドサービス ・シングルサインオンや、多要素認証、ID連携などの機能を提供 |
アイデンティティとアクセス管理 | ID,アクセス管理はユーザの検証、リソースへのアクセスを制御する |
IAM | 下記のような機能を組み合わせて、ユーザ検証とアクセス制御を実現する ・シームレスなサインアップ、ログインエクスペリエンス ・複数のユーザIDソースのサポート ・MFA ・ステップアップ認証 ・攻撃からの保護 ・RBAC ・FGA(Fine-grained Access) |
アイデンティティプロバイダ(IdP) | アイデンティティ情報を作成、維持、管理し、他のアプリケーションに認証サービスを提供できる |
Auth0 | ・たった5分で、どんなアプリケーションにもAuth0を実装 ・Auth0は誰でも簡単に導入できる認証・認可プラットフォーム ・ID管理は単なるログイン画面ではない。下記のようなことができる |
概要
IDaaSとは?
まずは、IDaaSについて、整理します。
- IDentity As A Serviceの略
- 複数のサービスのID、パスワードを一元管理できるクラウドサービス
- シングルサインオンや、多要素認証、ID連携などの機能を提供
Auth0について
Auth0のトップページには、下記の特徴が書かれています
- たった5分で、どんなアプリケーションにもAuth0を実装
- Auth0は誰でも簡単に導入できる認証・認可プラットフォーム
- ID管理は単なるログイン画面ではない。下記のようなことができる
カテゴリ | 機能 |
---|---|
登録 | 匿名ユーザ |
ボット検知 | |
登録 | |
本人確認 | |
プロビジョニング | |
ログイン | ログインユニバーサルログイン |
ディレクトリー | |
SSO | |
ソーシャルログイン | |
MFA | |
パスワードレス | |
エンタープライズフェデレーション | |
アクセス | プログレッシブプロファイリング |
ポリシーエンジン | |
RBAC | |
委任管理 | |
トランザクション | 認証の設定 |
認証要素 | |
認証ファクター | |
ステップアップ認証 | |
RBAC | |
ABAC |
前提:アイデンティティの基礎
アイデンティティの基礎を基に整理します。
アイデンティティとアクセス管理 (IAM) の概要
アイデンティティおよびアクセス管理 (IAM) とは何ですか?
ID およびアクセス管理は、ユーザーの検証とリソースへのアクセスを制御します。一般に IAM と呼ばれるこのテクノロジーにより、 適切なユーザーが適切なタイミングで適切な理由で適切なデジタル リソースにアクセスできるようになります。
- ID,アクセス管理はユーザの検証、リソースへのアクセスを制御する
- 一般的にIAMと呼ばれる
- 適切なユーザが適切なタイミングで適切な理由で適切なデジタルリソースにアクセスできる
IAMの基本概念
IAM を理解するには、いくつかの基本的な概念を理解している必要があります。
- デジタルリソースとは、コンピュータ システム内のアプリケーションとデータの任意の組み合わせです。デジタル リソースの例には、Web アプリケーション、API、プラットフォーム、デバイス、データベースなどがあります。
- IAM の中核はアイデンティティです。誰かがリソースにアクセスしようとしています。それは顧客、従業員、メンバー、参加者などです。IAM では、ユーザーアカウントはデジタル アイデンティティです。ユーザー アカウントは、ソフトウェア、モノのインターネット デバイス、ロボットなど、人間以外のものを表すこともできます。
- デジタルリソース
- アプリケーション+データの組み合わせ
- 例えば、Webアプリケーション、API、プラットフォーム、デバイス、DBが挙げられる
- アイデンティティ
- ユーザアカウントはデジタルアイデンティティ
- ユーザアカウントは、ソフトウェア、IoTデバイス、ロボットなど人間以外も表す
認証とは、デジタル ID の検証です。誰か (または何か) が認証を行うことで、自分が主張するユーザーであることを証明します。
承認とは、ユーザーがアクセスできるリソースを決定するプロセスです。
- 認証
- デジタルIDの検証
- 誰かが認証を行うことで、自分が主張するユーザであることを証明する
- 承認
- ユーザがアクセスできるリソースを決定するプロセス
※出典:IAMの基本概念
認証と承認の違い
認証と承認は、ユーザーにとっては単一のエクスペリエンスのように見えるため、混同されることがよくあります。これらは 2 つの別々のプロセスです。認証はユーザーの ID を証明し、承認は特定のリソースへのユーザーのアクセスを許可または拒否します。
- ユーザにとって単一のエクスペリエンスに見えるので混同されがち。別々のプロセス
- 認証
- ユーザのIDを証明
- 承認(認可)
- 特定のリソースへのユーザのアクセスを許可/拒否する
認証と承認は、オフィスビルのセキュリティ システムと考えることができます。ユーザーとは、ビルに入ろうとする人々です。ユーザーがアクセスしようとするリソースとは、フロア、部屋などのビル内のエリアのことです。
認証:建物に入るときは、警備員に写真付き ID バッジを見せる必要があります。警備員はバッジの写真とあなたの顔を比較します。一致した場合、警備員はあなたをドアから通して、建物のさまざまなエリアへのアクセスを試みます。警備員はどの部屋にアクセスできるかは教えません。あなたが本人であることを証明することだけをします。これが認証、つまりユーザーの身元を確認することです。
承認:このシナリオでは、建物のエレベーターと出入り口にキー センサーがあり、そこにアクセスできるようにしているとします。バッジのチップにより、会社が入居している 1 階にのみアクセスできます。バッジをスワイプして他の階に入ると、アクセスは拒否されます。自分の個人オフィスにはアクセスできますが、同僚のオフィスにはアクセスできません。備品室には入ることができますが、サーバー ルームには入れません。これが承認です。つまり、ID に基づいてさまざまなリソースへのアクセスを許可または拒否します。
- オフィスビルのセキュリティ・システムと考える事が可能
- ユーザはビルに入る人
- アクセスしようとするリソースは、フロア、部屋、ビル内のエリア
- 認証
- 建物に入るときには、警備員に写真つきIDバッチを見せる必要がある
- 警備員はバッチの写真と顔を比較し、一致したらドアから通す
- 警備員は、どの部屋二アクセスできるかは教えない
- ユーザの身元を確認するだけ
- 建物に入るときには、警備員に写真つきIDバッチを見せる必要がある
- 認可
- バッチのチップにより入れる部屋と入れない部屋がある
IAM は何をしますか?
ID およびアクセス管理により、ユーザーの検証とリソース アクセスを制御できます。
- ユーザーがシステムの一部になる方法
- 保存するユーザー情報
- ユーザーが自分の身元を証明する方法
- ユーザーが身元を証明する必要がある時期と頻度
- 身元を証明する経験
- さまざまなリソースにアクセスできる人とアクセスできない人
ID、IAMにより、ユーザの検証とリソースアクセスを制御できる。
IAM をアプリケーション、API、デバイス、データ ストア、またはその他のテクノロジーと統合します。この統合は非常に簡単です。たとえば、Web アプリケーションが認証に完全に Facebook に依存していて、オール オア ナッシングの承認ポリシーを持っているとします。アプリは簡単なチェックを実行します。ユーザーが現在のブラウザで Facebook にログインしていない場合は、ログインするように指示します。認証されると、すべてのユーザーがアプリ内のすべてにアクセスできます。
このような単純な IAM ソリューションでは、ユーザー、組織、業界、コンプライアンス標準のニーズを満たすことはまずありません。現実には、IAM は複雑です。ほとんどのシステムでは、次の機能の組み合わせが必要です。
- シームレスなサインアップおよびログイン エクスペリエンス:ブランドの外観と言語を使用して、スムーズでプロフェッショナルなログインおよびサインアップ エクスペリエンスがアプリ内で実現します。
- 複数のユーザーIDソース:ユーザーは、さまざまなソーシャル(GoogleやLinkedInなど)、エンタープライズ(Microsoft Active Directoryなど)、その他のソースを使用してログインできることを期待しています
- 多要素認証(MFA):パスワードが盗まれることが多い時代に、追加の身元証明を求めることは新しい標準です。指紋認証やワンタイムパスワードは、一般的な認証方法の例です。
- ステップアップ認証:高度な機能や機密情報にアクセスするには、日常的なタスクやデータよりも強力な本人確認が必要です。ステップアップ認証では、特定の領域や機能に対して追加の本人確認が必要です。詳細については、以下をお読みください
- 攻撃からの保護:ボットや悪意のある人物によるシステムへの侵入を防ぐことは、サイバーセキュリティの基本です
- ロールベースのアクセス制御 (RBAC):ユーザー数が増えると、各ユーザーのアクセスを管理するのはすぐに困難になります。RBAC を使用すると、同じロールを持つユーザーはリソースに同じアクセス権を持ちます。詳細については、以下をお読みください。
- きめ細かな認可(FGA):リソースやテクノロジーへのユーザーアクセスを管理するためにより多くのオプションが必要な場合は、役割ベースのアクセス制御を超えて関係ベースのアクセス制御を使用できます。個々のユーザーに特定のリソースへのアクセスを許可し、特定のユースケースに最適なソリューションを決定できます。
下記のような機能を組み合わせて、ユーザ検証とアクセス制御を実現する。
- シームレスなサインアップ、ログインエクスペリエンス
- 複数のユーザIDソースのサポート
- MFA
- ステップアップ認証
- 攻撃からの保護
- RBAC
- FGA(Fine-grained Access)
IAM はどのように機能しますか?
「アイデンティティとアクセス管理」は、明確に定義された 1 つのシステムではありません。IAM は、デジタル リソースへの安全なアクセスという課題を解決するための規律であり、フレームワークの一種です。IAM システムを実装するためのさまざまなアプローチに制限はありません。このセクションでは、一般的な実装における要素と実践について説明します。
- アイデンティとアクセス管理は、フレームワークの一種
アイデンティティプロバイダー
これまで、アイデンティティとアクセス管理の標準は、システムがユーザーの独自のアイデンティティ情報を作成し、管理することでした。ユーザーは、新しい Web アプリケーションを使用するたびに、フォームに入力してアカウントを作成しました。アプリケーションは、ログイン資格情報を含むすべての情報を保存し、ユーザーがサインインするたびに独自の認証を実行しました。
インターネットが成長し、利用できるアプリケーションが増えるにつれて、ほとんどの人が数え切れないほどのユーザー アカウントを蓄積し、それぞれにアカウント名とパスワードを覚えるようになりました。この方法で動作し続けているアプリケーションは数多くあります。しかし、現在では多くのアプリケーションが、開発と保守の負担とユーザーの労力を軽減するためにID プロバイダーに依存しています。
アイデンティティ プロバイダは、アイデンティティ情報を作成、維持、管理し、他のアプリケーションに認証サービスを提供できます。たとえば、Google アカウントはアイデンティティ プロバイダです。ユーザー名、氏名、役職、メール アドレスなどのアカウント情報を保存します。Slate オンライン マガジンでは、情報を新たに入力して保存する手順を踏むのではなく、Google (または別のアイデンティティ プロバイダ) を使用してログインできます。
- アイデンティティプロバイダ(IdP)
- アイデンティティ情報を作成、維持、管理し、他のアプリケーションに認証サービスを提供できる
- GoogleアカウントはIdP。ユーザ名、氏名、役職、メール、アドレスなどのアカウント情報を保存する
認証要素
ユーザの身元を証明する方法。一般的に下記のタイプに分類される。
- Knowledge
- Pin、Password
- Possession
- Mobile Phone、encryption key device
- Inherence
- Fingerprint、facial recognition iris scan
認証および承認の標準
認証および承認の標準は、次の方法に関するガイダンスを提供するオープンな仕様およびプロトコルです。
- アイデンティティを管理するためのIAMシステムを設計する
- 個人データを安全に移動
- リソースにアクセスできるユーザーを決定する
以下の IAM 業界標準は、最も安全で信頼性が高く、実装に実用的であると考えられています。
- OAuth2.0
- API にアクセスするための委任プロトコル
- OpenID Connect
- OAuth 2.0の上にあるシンプルなアイデンティティレイヤー
- ユーザーのIDを簡単に確認し、アイデンティティプロバイダーから基本的なプロファイル情報を取得できる
- JWT
- JSON Web Token
- JSON オブジェクトとして関係者間で情報を安全に転送するためのコンパクトで自己完結的な方法を定義するオープン スタンダード
- デジタル署名されている
- 認証されたユーザーの ID を ID プロバイダーと認証を要求するサービス間で渡すために使用できる
- SAML
- Security Assertion Markup Language
- 企業がパートナー企業や従業員が使用するエンタープライズアプリケーションにユーザー認証と承認情報を伝達できるようにするオープンスタンダードのXMLベースのデータ形式
- WS-Fed
- Web Services Federation
- シングルサインオン(SSO)で使用されるXMLベースのプロトコル
IAM プラットフォームを使用する理由は何ですか?
なぜ多くの開発者は、独自のソリューションをゼロから構築するのではなく、ID およびアクセス管理プラットフォーム上に構築することを選択するのでしょうか?
ユーザーの期待、顧客の要件、コンプライアンス標準により、重大な技術的課題が生じます。複数のユーザー ソース、認証要素、オープンな業界標準があるため、一般的な IAM システムの構築に必要な知識と作業量は膨大になる可能性があります。強力な IAM プラットフォームには、すべての ID プロバイダーと認証要素のサポートが組み込まれており、ソフトウェアとの統合を容易にする API が提供され、認証と承認には最も安全な業界標準に依存しています。
- ユーザの期待値、顧客の要件、コンプライアンス標準により、重大な技術的課題が生じる。またオープンな業界標準が有り、作業量、知識は膨大になる
Auth0の概要
Auth0の概要を基に整理します。
Auth0 は、アプリケーションに認証および承認サービスを追加するための柔軟なドロップイン ソリューションです。チームや組織は、ユーザーを認証および承認するための独自のソリューションを構築することに伴うコスト、時間、リスクを回避できます。
- アプリケーションに認証、認可サービスを追加するための柔軟なドロップインソリューション
- チームや組織は、ユーザを認証、承認するための独自ソリューションを構築することに伴うコスト、時間、リスクを回避できる
- 使用例
- ログイン後にユーザーのプロファイルを取得して、UI をカスタマイズし、承認ポリシーを適用する
- OAuth2.0
- APIを構築し、それを保護したい
- SSO
- 複数のアプリがあり、実装したい
- JavaScript フロントエンド アプリとモバイル アプリを構築し、両方から API に安全にアクセスできるようにしたい
- SAML
- ウェブアプリでユーザー認証を行う
- パスワードが破られていると思われるため、電子メールまたは SMS で配信されるワンタイム コードを使用してユーザーがログインできるようにしたい
- 何らかのサイトで公開されているデータ侵害により、ユーザーのメール アドレスの 1 つが侵害された場合、通知を受け取り、ユーザーに通知したり、パスワードをリセットするまでアプリへのログインをブロックしたりする
- DDoS 攻撃を回避するために、疑わしい IP アドレスが連続してログインに失敗した場合に、その IP アドレスをブロックする
- 既存のエンタープライズ ディレクトリ サービスを統合して、従業員が既存のエンタープライズ資格情報を使用してさまざまな社内およびサードパーティのアプリケーションにログインできるようにしたい
- 独自のユーザー管理ソリューションを実装したくない (または実装方法がわからない)。パスワードのリセット、ユーザーの作成、プロビジョニング、ブロック、削除、そしてこれらすべてを管理するための UIがほしい
- MFA
- SOC2、GDPR、PCI DSS、HIPAA などの常に増え続けるコンプライアンス要件に対応するのに役立つ ID ソリューションを探してる
- サイトまたはアプリケーション上のユーザーを監視する
- このデータを使用してファネルを作成し、ユーザー維持率を測定し、サインアップ フローを改善する予定
- 強力な認可ポリシーで、ユーザーがリソースにアクセスできるようにしたい
実践
アカウント作成
-
サインアップをクリックします
-
Googleアカウントを選択します
-
下記を選択し、「Next」をクリックします
- Account Type:Company or Other
- I need advanced settings:別のリージョンに作る場合選択するとのこと
プロファイル
多要素認証(Google Authenticator)を設定しておきます。
考察
今回は、IDaaS、Auth0の基本について簡単に整理し、最後にアカウントを作成てみました。
次回からは、アプリケーションと接続を試してみます。
参考