> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
> アイデンティティおよびアクセス管理というコンピューターソフトウェア分野の基本的な概要。これからこの分野を学ぶ方向け
# アイデンティティおよびアクセス管理（IAM）入門
## アイデンティティおよびアクセス管理 (IAM) とは？
アイデンティティおよびアクセス管理は、ユーザーの検証とリソースへのアクセスを制御するための仕組みです。一般に IAM と呼ばれるこの技術により、適切な人が、適切なタイミングで、適切な理由に基づいて、適切なデジタルリソースにアクセスできるようになります。
## IAM の基本概念
IAM を理解するには、いくつかの基本的な概念を把握しておく必要があります。
* **デジタルリソース** とは、コンピューターシステム内のアプリケーションやデータのあらゆる組み合わせを指します。デジタルリソースの例としては、Web アプリケーション、API、プラットフォーム、デバイス、データベースなどがあります。
* IAM の中核にあるのは **アイデンティティ** です。誰かがあなたのリソースへのアクセスを求めています。それは、顧客、従業員、メンバー、参加者などかもしれません。IAM では、**ユーザー** アカウントは デジタルアイデンティティ です。ユーザーアカウントは、ソフトウェア、IoT デバイス、ロボット工学など、人間以外の存在を表すこともあります。
* **認証** とは、デジタルアイデンティティを検証することです。誰か (または何か) が、自分がそのユーザー本人であることを証明するために認証を行います。
* **認可** とは、ユーザーがアクセスできるリソースを決定するプロセスです。
## 認証と認可の違い
認証と認可は、ユーザーにはひと続きの体験のように見えるため、混同されがちです。しかし、実際には別々の 2 つのプロセスです。認証はユーザーの身元を証明し、認可は特定のリソースへのアクセスを許可または拒否します。
認証と認可は、オフィスビルのセキュリティシステムにたとえるとわかりやすいでしょう。ユーザーは、そのビルに入ろうとする人です。人がアクセスしたいリソースは、ビル内のエリア、つまりフロアや部屋などにあたります。
**認証:** ビルに入るときは、警備員に顔写真付きの ID バッジを提示する必要があります。警備員は、バッジの写真とあなたの顔を見比べます。一致していれば、建物内のさまざまなエリアにアクセスできるか試せるよう、警備員がドアを通してくれます。警備員は、どの部屋にアクセスできるかまでは判断しません。確認するのは、あなたが名乗っている本人であることだけです。これが認証です。つまり、ユーザーの身元を確認することです。
**認可:** この例では、ビル内のエレベーターや出入口にアクセス用のセンサーがあると想像してください。あなたのバッジ内のチップによって、あなたの会社が使用している 1 階にのみアクセスできます。バッジをかざしてそれ以外の階に入ろうとすると、アクセスは拒否されます。自分の個室には入れますが、同僚の個室には入れません。備品室には入れますが、サーバールームには入れません。これが認可です。つまり、身元に基づいて異なるリソースへのアクセスを許可または拒否することです。
認証と認可の詳細については、[Authentication vs. Authorization](/ja/docs/get-started/identity-fundamentals/authentication-and-authorization) を参照してください。
## IAM は何をしますか？
アイデンティティおよびアクセス管理では、ユーザーの検証やリソースへのアクセスを制御できます。
* ユーザーをどのようにシステムに参加させるか
* どのユーザー情報を保存するか
* ユーザーがどのように本人確認を行うか
* ユーザーにいつ、どの程度の頻度で本人確認を求めるか
* 本人確認の体験をどう設計するか
* 誰がどのリソースにアクセスできるか、またはできないか
IAM は、アプリケーション、API、デバイス、データストア、その他のテクノロジーと統合して使用します。この統合は非常にシンプルな場合もあります。たとえば、Web アプリケーションが認証を完全に Facebook に依存し、認可ポリシーがすべて許可かすべて拒否かのどちらかであるようなケースです。アプリは単純なチェックを行います。現在のブラウザーでユーザーが Facebook にログインしていなければ、ログインするよう促します。認証が完了すると、すべてのユーザーがアプリ内のすべてにアクセスできます。
しかし、そのようなシンプルな IAM ソリューションで、ユーザー、組織、業界、またはコンプライアンス基準の要件を満たせる可能性は低いでしょう。実際の IAM は複雑です。ほとんどのシステムでは、次のような機能をいくつか組み合わせて必要とします。
* **シームレスなサインアップとログイン体験:** ブランドの見た目や言葉遣いに合わせた、スムーズでプロフェッショナルなログインおよびサインアップ体験をアプリ内で提供できます。
* **複数のユーザー ID ソース:** ユーザーは、さまざまなソーシャル (Google や LinkedIn など) 、エンタープライズ (Microsoft Active Directory など) 、その他の[IDプロバイダー](/ja/docs/authenticate/identity-providers)を使ってログインできることを期待しています。
* **多要素認証 (MFA):** パスワードが頻繁に盗まれる時代において、追加の本人確認を求めることは新たな標準になっています。指紋認証やワンタイムパスワードは、一般的な認証方法の例です。詳しくは、[Multi-Factor Authentication (MFA)](/ja/docs/secure/multi-factor-authentication) を参照してください。
* **ステップアップ認証:** 高度な機能や機密情報へのアクセスには、日常的なタスクやデータよりも強力な本人確認が必要です。ステップアップ認証では、特定の領域や機能に対して追加の本人確認を要求します。詳しくは、[Add Step-up Authentication](/ja/docs/secure/multi-factor-authentication/step-up-authentication) を参照してください。
* **攻撃保護:** ボットや 悪意のある第三者 によるシステム侵入を防ぐことは、サイバーセキュリティの基本です。詳しくは、[Attack Protection](/ja/docs/secure/attack-protection) を参照してください。
* **ロールベースのアクセス制御 (RBAC) :** ユーザー数が増えると、個々のアクセス権を管理することはすぐに現実的でなくなります。RBAC では、同じロールを持つ人は同じリソースへのアクセス権を持ちます。詳しくは、[Role-Based Access Control](/ja/docs/manage-users/access-control/rbac) を参照してください。
* **きめ細かな認可 (FGA):** リソースやテクノロジーに対するユーザーアクセスをより柔軟に管理する必要がある場合は、関係ベースのアクセス制御を使用して、ロールベースの制御を超えた管理が可能です。個々のユーザーに特定のリソースへのアクセスを付与し、ユースケースに最適なソリューションを実現できます。詳しくは、[What Is Fine-Grained Authorization?](https://docs.fga.dev/authorization-concepts#what-is-fine-grained-authorization) を参照してください。
このレベルの複雑さに対応するため、多くの開発者は独自のソリューションを構築する代わりに、Auth0 のような IAM プラットフォームを利用しています。
## IAM はどのように機能しますか？
「Identity and access management」は、明確に定義された単一のシステムではありません。IAM は、デジタルリソースへの安全なアクセスという課題に対処するための分野であり、フレームワークの一種でもあります。IAM システムの実装方法はさまざまです。このセクションでは、一般的な実装に共通する要素とプラクティスを紹介します。
### IDプロバイダー
以前は、アイデンティティおよびアクセス管理の標準的なあり方として、各システムが自らのユーザーのアイデンティティ情報を作成・管理していました。ユーザーが新しい Web アプリケーションを使うたびに、アカウント作成のためのフォームに入力していました。アプリケーションは、ログイン認証情報を含むそれらの情報を保存し、ユーザーがサインインするたびに独自に認証を行っていました。
インターネットが発展し、利用できるアプリケーションが増えるにつれて、ほとんどの人は、それぞれ異なるアカウント名とパスワードを覚えなければならない数多くのユーザーアカウントを持つようになりました。現在でもこの方式で動作するアプリケーションは数多くあります。しかし今では、開発や保守の負担とユーザーの手間を減らすために、IDプロバイダーを利用するものも多くあります。
IDプロバイダーは、アイデンティティ情報を作成、維持、管理し、他のアプリケーションに認証サービスを提供できます。たとえば、Google アカウントは IDプロバイダーです。Google アカウントは、ユーザー名、氏名、役職、メールアドレスなどのアカウント情報を保存します。オンライン雑誌の Slate では、新たに情報を入力して保存する手順を踏む代わりに、Google (または別の IDプロバイダー) でログインできます。
IDプロバイダーは、それを利用するアプリに認証情報を共有しません。たとえば、Slate が Google のパスワードを見ることはありません。Google は、あなたが本人であることが確認されたという事実だけを Slate に伝えます。
そのほかの IDプロバイダーには、ソーシャルメディア (Facebook や LinkedIn など) 、エンタープライズ (Microsoft Active Directory など) 、法的な本人確認プロバイダー (Swedish BankID など) があります。
### 認証要素
認証要素とは、ユーザーの身元を証明するための手段です。一般に、次の基本的な種類に分類されます。
| 要素の種類 | 例 |
| ---------------- | ------------- |
| 知識情報 (知っているもの) | PIN、パスワード |
| 所持情報 (持っているもの) | 携帯電話、暗号鍵デバイス |
| 生体情報 (本人自身であること) | 指紋認証、顔認証、虹彩認証 |
IAM システムでは、身元を確認するために 1 つ以上の認証要素が必要です。
### 認証と認可の標準
認証と認可の標準は、次の方法に関する指針を提供する公開仕様およびプロトコルです。
* ID とアクセスを管理する IAM システムを設計する
* 個人データを安全に移転する
* リソースへのアクセスを許可する対象を決定する
これらの IAM 業界標準は、最も安全で信頼性が高く、実装しやすいものと見なされています。
#### OAuth 2.0
OAuth 2.0 は、API へのアクセスに使用される委任プロトコルであり、IAM の業界標準プロトコルです。オープンな認可プロトコルである OAuth 2.0 を使用すると、ユーザーの認証情報を共有することなく、ユーザーに代わって他の Web アプリでホストされているリソースにアプリからアクセスできます。これは、サードパーティの開発者が Facebook、Google、Twitter などの大規模なソーシャルプラットフォームのログイン機能を利用できるようにする標準です。 詳しくは、[OAuth 2.0 Authorization Framework](/ja/docs/authenticate/protocols/oauth) を参照してください。
#### OpenID Connect
OAuth 2.0 の上に構築されたシンプルな ID レイヤーである OpenID Connect (OIDC) を使用すると、ユーザーの本人確認を容易に行い、IDプロバイダーから基本的なプロフィール情報を取得できます。OIDC もオープンスタンダードのプロトコルの 1 つです。詳細については、[OpenID Connect Protocol](/ja/docs/authenticate/protocols/openid-connect-protocol) を参照してください。
#### JSON Webトークン
JSON Webトークン (JWT) は、当事者間で情報をJSONオブジェクトとして安全にやり取りするための、コンパクトで自己完結した方法を定義するオープン標準です。JWTはデジタル署名されているため、検証可能で信頼できます。JWTは、認証されたユーザーのアイデンティティ情報を、IDプロバイダーと認証を要求するサービスの間で受け渡すために使用できます。また、署名や暗号化を行うこともできます。詳しくは、[JSON Web Tokens](/ja/docs/secure/tokens/json-web-tokens)を参照してください。
#### Security Assertion Markup Language (SAML)
Security Assertion Markup Language (SAML) は、オープン標準の XML ベースのデータ形式で、企業が従業員の利用する提携先企業やエンタープライズアプリケーションと、ユーザーの認証および認可に関する情報をやり取りできるようにします。 詳細については、[SAML](/ja/docs/authenticate/protocols/saml)を参照してください。
#### Web Services Federation (WS-Fed)
Microsoft が開発し、同社のアプリケーションで広く利用されているこの標準は、セキュリティ トークンを異なるエンティティ間でやり取りし、アイデンティティ情報と認可情報を交換する方法を定義しています。詳細については、[Web Services Federation Protocol](/ja/docs/authenticate/protocols/ws-fed-protocol) を参照してください。
## IAMプラットフォームを使用する理由
なぜ多くの開発者は、ゼロから独自のソリューションを構築するのではなく、アイデンティティおよびアクセス管理プラットフォームの利用を選ぶのでしょうか。
ユーザーの期待、顧客要件、コンプライアンス基準により、技術面では大きな課題が生じます。複数のユーザーソース、認証要素、オープンな業界標準に対応する必要があるため、一般的なIAMシステムの構築に必要な知識と作業量は膨大になりがちです。優れたIAMプラットフォームには、あらゆるIDプロバイダーと認証要素をサポートする機能があらかじめ組み込まれており、ソフトウェアと容易に統合できるAPIも用意されています。また、認証と認可には、業界で広く採用されている安全性の高い標準が使われています。
IAMソリューションを自社で構築するか購入するかをまだ決めていない場合は、[Build vs. Buy: Guide to Evaluating Identity Management](https://auth0.com/resources/whitepapers/build-vs-buy-evaluating-identity-management) が参考になります。