メインコンテンツへスキップ

​
IDおよびアクセス管理とは？

適切な人が、適切なタイミングで、適切な理由に基づいて、適切なデジタルリソースにアクセスすることを保証します。

​
IAMの基本概念

IAMを理解するには、いくつかの基本的な概念を理解しておく必要があります。
  • デジタルリソース とは、コンピューターシステムにあるアプリケーションとデータのあらゆる組み合わせのことです。デジタルリソースの例として、Webアプリケーション、API、プラットフォーム、デバイス、データベースなどが挙げられます。
  • IAMの中心となるのはID（アイデンティティ） です。誰かがリソースへのアクセスを要求しているとします。その人は顧客かもしれないし、従業員や会員、参加者、あるいはそれ以外の人かもしれません。IAMでは、ユーザー アカウントがデジタルIDとなります。ユーザーアカウントは、ソフトウェアやIoTデバイス、ロボティクスなどの人間以外のものを表すこともできます。
ユーザーがリソースにアクセスしている簡単な図
IAMシステムがユーザーによるリソースへのアクセスを制御していることを示す簡単な図
  • 認証 は、デジタルIDを検証することです。誰か（または何か）が認証を行い、自分がユーザー本人であることを証明します。
  • 認可 は、ユーザーがアクセスできるリソースを決定するプロセスです。

​
認証と認可の違い

認証と認可は、ユーザーにとって単一の体験のように見えるため、混同されることがよくあります。しかし、これらは別のプロセスです。認証はユーザーのIDを証明するのに対し、認可は、あるリソースへのユーザーのアクセスを付与したり拒否したりします。 認証と認可は、オフィスビルのセキュリティシステムに例えることができます。ユーザーは建物に入ろうとする人です。人々がアクセスしようとしているリソースは、建物内の特定の階や部屋などです。 認証： 建物に入ると、警備員に写真付きのIDカードを見せる必要があります。警備員はカードの写真とあなたの顔を照合します。一致すると、警備員は入館を許可し、建物内の別のエリアにアクセスすることができます。しかし、警備員はどの部屋に入れるかを教えてはくれません。ただ、あなたが主張する人物であることの証明を求めるだけです。これが認証で、ユーザーIDを確認することです。
認証の仕組みが、建物の入り口で各人のバッジを確認する警備員に似ていることを示す図
認可： 次に、この建物内のエレベーターやドアには、移動したり開けたりするためのカードの読み取りセンサーがあります。あなたのIDカードにあるチップは、所属する企業が占有している1階へのアクセスのみを許可します。他の階に入ろうとIDカードをタッチしても、アクセスは拒否されます。また、自分の部屋に入ることはできますが、同僚の部屋に入ることはできません。備品室には入れますが、サーバールームには入れません。これが認可で、IDに基づいて異なるリソースへのアクセスを付与または拒否することです。
認可の仕組みが、建物の一部の部屋にしかアクセスできないようにするバッジと同じようなものであることを示す図
認証と認可について詳細は、「認証と認可」をお読みください。

​
IAMは何をするのか？

IDおよびアクセス管理は、ユーザーの検証とリソースへのアクセスを制御できるようにします。
  • ユーザーはどのようにシステムに加わるか
  • どのようなユーザー情報を保存するか
  • ユーザーはどのようにIDを証明するか
  • ユーザーがIDを証明しなければならないタイミングと頻度はどうするか
  • IDの証明体験をどのようにするか
  • 各リソースにアクセスできる人とできない人は誰か
IAMはアプリケーション、API、デバイス、データストア、その他のテクノロジーに統合して使用します。この際に、統合を非常に単純にすることも可能です。たとえば、認証をFacebookに完全に依存し、全か無かの認可ポリシーを持っているWebアプリケーションです。このアプリは単純なチェックを行い、ユーザーが現在のブラウザーでFacebookにログインしていない場合にはログインするように促します。認証したら、すべてのユーザーがアプリのすべての機能にアクセスできるようになります。 しかし、このように単純なIAMソリューションが、ユーザー、企業、業界、およびコンプライアンスの基準を満たすとは考えられません。現実世界のIAMは複雑です。ほとんどのシステムは、以下の機能を組み合わせて使う必要があります。
  • シームレスなサインアップとログイン体験： ブランドの外観と言語を使用したアプリ内で、スムーズかつプロフェッショナルなログインおよびサインアップ体験を実現します。
  • ユーザーIDの複数のソース： ユーザーは、多様なソーシャル（GoogleやLinkedinなど）、エンタープライズ（Microsoft Active Directoryなど）、その他のIDプロバイダーを使用してログインできることを期待します。
  • 多要素認証（）： パスワードが頻繁に盗まれる現代においては、追加のID証明を要求することが新たな標準となっています。一般的な認証方法の例としては、指紋認証やワンタイムパスワードが挙げられます。詳細については、「多要素認証（MFA）」をお読みください。
  • ステップアップ認証： 高度な機能や機密情報へのアクセスには、日常的なタスクやデータよりもさらに強力なIDの証明が必要です。ステップアップ認証は、選択された領域や機能に対する追加のID検証を要求します。詳細については、「ステップアップ認証を追加する」をお読みください。
  • 攻撃防御： システムへの不正侵入を防ぐために、ボットや不正者を排除することはサイバーセキュリティの基本です。詳細については、「攻撃防御」お読みください。
  • **Role-based Access Control（RBAC）：**ユーザー数が増えるに従い、個人単位でユーザーアクセスを迅速に管理することは非現実的になります。RBACでは、同じロールのユーザーが同じリソースへのアクセスを持つようになります。詳細については、「Role-Based Access Control」をお読みください。
  • （FGA）： リソースや技術へのユーザーアクセスを管理するためにより豊富なオプションが必要な場合は、ロールベースだけでなく、関係ベースのアクセス制御を使用できます。個人ユーザーに特定のリソースへのアクセスを与え、特定のユースケースに最適なソリューションを決定することができます。詳細については、「Fine-Grained Authorizationとは？
このような複雑さに直面した開発者の多くは、独自のソリューションを構築する代わりに、Auth0のようなIAMプラットフォームを頼り、活用しています。

​
IAMの仕組み

「IDおよびアクセス管理」は、明確に定義された単一のシステムではありません。IAMは、デジタルリソースへの安全なアクセスという課題を解決するための秩序であり、一つの枠組みです。IAMシステムを実装するためのアプローチの違いに制限はありません。このセクションでは、一般的な実装での要素と実践について説明します。

​
IDプロバイダー

かつては、IDおよびアクセス管理の標準として、システムが独自にユーザーのID情報を作成し、管理していました。ユーザーは、新たなWebアプリケーションを使い始めるたびに、アカウント作成フォームに入力します。そして、ログイン資格情報を含むすべての情報がアプリケーションに保存され、ユーザーがサインインするたびに独自の認証を行っていました。 インターネットが発展し、アプリケーションが増えるにつれ、多くの人々がそれぞれアカウント名とパスワードの異なる無数のユーザーアカウントを抱えるようになりました。今でもこの方法を取っているアプリケーションは少なくありません。しかし、多くのアプリケーションは、開発やメンテナンスの負担を軽減し、ユーザーの手間を減らすためにIDプロバイダーを活用しています。 IDプロバイダーは、ID情報を作成、維持、管理し、他のアプリケーションに認証サービスを提供することができます。たとえば、GoogleアカウントはIDプロバイダーの1つです。ユーザー名、氏名、役職、メールアドレスなどのアカウント情報を保存します。Slateのオンラインマガジンでは、Google（または他のIDプロバイダー）を使ってログインできるため、情報を新たに入力して保存する手間を省けます。
Screenshot of Slate magazine login
この認証情報がIDプロバイダーによって、それを利用しているアプリに共有されることはありません。たとえば、SlateはユーザーのGoogleパスワードを見ることはできません。Googleはただ、SlateにIDの証明ができたことを知らせるだけです。 他にもソーシャルメディア（FacebookやLinkedinなど）、エンタープライズ（Microsoft Active Directoryなど）、リーガル（Swedish BankIDなど）などのIDプロバイダーがあります。

​
認証要素

認証要素は、ユーザーIDを証明する方法です。一般的に以下の基本的なタイプに分類されます。
要素のタイプ例
知識（知っていること）PIN、パスワード
所持（持っているもの）携帯電話、暗号鍵デバイス
特徴（自分自身を表すもの）指紋、顔認証、虹彩スキャン
IAMシステムは1つまたは複数の認証要素を要求してIDを検証します。

​
認証と認可の標準

認証と認可の標準は、以下の方法のガイダンスを提供するオープンな仕様とプロトコルです。
  • ID管理をするようにIAMシステムを設計する
  • 個人データを安全に移動する
  • 誰がリソースにアクセスできるか決定する
以下のIAM業界標準は、最も安全で信頼性が高く、実装に実用的だと考えられています。

​
OAuth 2.0

は、APIへのアクセスの委任プロトコルで、IAMの業界標準プロトコルです。オープンな認可プロトコルであるOAuth 2.0は、アプリがユーザーの資格情報を共有することなく、ユーザーに代わって他のWebアプリがホストするリソースにアクセスできるようにします。サードパーティ開発者がFacebook、Google、X（Twitter）などの大規模なソーシャルプラットフォームのログインを活用できるようにする標準です。詳細については、「OAuth 2.0認可フレームワーク」をお読みください。

​
Open ID Connect

OAuth 2.0の上に位置するシンプルなIDレイヤーである Connect（OIDC）は、ユーザーのIDを確認し、IDプロバイダーから基本的なプロファイル情報を取得するのを容易にします。OIDCは、もう一つのオープン標準プロトコルです。詳細については、「OpenID Connectプロトコル」をお読みください。

​
JSON Web Token

（JWT）は、オープン標準であり、JSONオブジェクトとして当事者間で情報を安全に送信するためのコンパクトで自己完結型の方法を定義しています。JWTは、デジタルで署名されているため、検証および信頼できます。認証されたユーザーのIDをIDプロバイダーと認証の要求元であるサービス間で渡すために使用できます。これらは認証や暗号化することもできます。詳細については、「JSON Web Token」をお読みください。

​
Security Assertion Markup Language（SAML）

（SAML）は、企業がパートナー企業や、従業員が使用する企業アプリケーションに、ユーザー認証・認可の情報を伝達できるようにする、オープン標準のXMLベースのデータ形式です。詳細については、「SAML」をお読みください。

​
Web Services Federation（WS-Fed）

Microsoftが開発し、そのアプリケーションで幅広く利用されているこの標準は、異なるエンティティ間でセキュリティトークンを転送し、IDと認可情報を交換する方法を定義しています。詳細については、「Webサービスフェデレーションプロトコル」をお読みください。

​
IAMプラットフォームを利用する理由

なぜ多くの開発者が、独自のソリューションを一から構築せずに、IDおよびアクセス管理プラットフォームを選ぶのでしょうか？ ユーザーの期待、顧客の要件、コンプライアンス基準は、技術的な課題を増大させます。複数のユーザーソース、認証要素、オープン業界標準への準拠が必要となるため、一般的なIAMシステムを構築するために必要な知識や作業量は膨大です。強力なIAMプラットフォームは、すべてのIDプロバイダーや認証要素に対応し、ソフトウェアとの簡単な統合を可能にするAPIを提供しています。また、認証と認可に関して、最も安全な業界標準に基づいています。 IAMソリューションの構築や購入の検討をしている方は、ぜひ「構築と購入：ID管理評価のガイド」をご参照ください。