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