ID およびアクセス管理とは
組織は、Active Directory、SharePoint、Oracle、Outlook、チーム、または単に Web アプリケーションのような複数のシステムを持つことができますし、これらのシステムにアクセスできる従業員や外部の組織のユーザーの数百または数千人を持つことができます。 すべてのユーザーのアカウントを管理し、それぞれのシステムに適切なアクセスを許可することは、アイデンティティとアクセス管理 (IAM) と呼ばれます。
組織が使用する各システム上のユーザーごとに、ユーザーの詳細、ログイン資格情報、アクセス情報を管理することを考えます。 このプロセスは、各システムに対して資格情報とユーザー アクセス情報を個別に保持する必要があるため、組織にとって面倒です。 このアプローチは従来のものであり、一部の組織でも使用されています。
しかし、ユーザーが日々成長すると、それらを処理し、管理することは困難な作業になり、見逃すことはできません。 この伝統的なアプローチの主な問題は、最初に設定し、その後スピードアップするために膨大な投資と時間がかかることです。
ID 管理がこの問題を解決する方法
組織のユーザーが使用するすべてのアプリケーションについて、すべてのユーザー資格情報とアクセス管理を 1 か所で一元的に行う場合を考えます。 ID 管理システムが各ユーザーに関する情報を取得するために使用する 1 つのデータベースでユーザーを一元管理できるようになりました。
今、彼らはすでにアイデンティティシステムで自分自身を検証しているので、ユーザーがしなければならないのは、単に彼らが誰であるかをアイデンティティシステムに伝えることだけです。 認証されると、すべてのアプリケーションにアクセスできます。 このアプローチの大きな利点の 1 つは、ID 管理システムがこのすべてを処理するため、さまざまなアプリケーションがユーザーの認証および承認機能について心配する必要がないことです。 一般的に使用される ID 管理システムの一部には、Microsoft Azure アクティブ ディレクトリ、 マイクロソフト ID 管理、および Oracle ID 管理などがあります。
組織が ID およびアクセス管理 (IAM) システムを使用する主な利点は何ですか。
- セキュリティの強化: IAM ソリューションは、セキュリティリスクの特定と軽減に役立ちます。 従業員や顧客に組織内の安全なアクセスを提供することは、困難な作業になる可能性があります。 ID 管理ソフトウェアを使用すると、信用詐欺など、あらゆる種類の個人情報の盗難から組織を保護できます。
- 使いやすさ. IAM コア機能は、シングルサインオン、多要素認証、アクセス管理の形式で提供することも、ID およびプロファイルデータストレージ用のディレクトリとして提供することもできます。 IAM は、アプリケーション所有者、エンドユーザー、システム管理者のサインアップ、サインイン、ユーザー管理プロセスを簡素化します。
- 生産性: IAM は ID およびアクセス管理ライフサイクルを一元化して自動化し、新しい採用者やロール移行などのシナリオの自動化ワークフローを作成します。 これにより、アクセスと ID の変更の処理時間が短縮され、エラーが減少します。
- IT コストの削減: IAM サービスは運用コストを削減できます。 フェデレーション ID サービスを使用すると、外部で使用するローカル ID は不要になります。これにより、アプリケーション管理が容易になります。 クラウドベースの IAM サービスは、オンプレミスインフラストラクチャの購入と保守の必要性を減らすことができます。
現在、急成長している ID 管理システムの 1 つが、Microsoft Azure アクティブ ディレクトリです。 Azure Active Directory は、クラウドアプリケーションとオンプレミスアプリケーションに安全かつシームレスにアクセスできるようにします。 また、組織がパスワードを管理する必要もありません。 エンド ユーザーは、Office 365 および他の数千のアプリケーションにアクセスするために 1 回サインインできます。 ID 管理のしくみを見てみましょう。
ID 管理システムで一般的に使用されるプロトコル
一般に
認証、許可、アカウンティング、または AAA
と呼ばれるこれらの ID 管理プロトコルは、アクセス管理を簡素化し、コンプライアンスを支援し、ユーザーとシステム間の相互作用を処理するための統一されたシステムを作成するためのセキュリティの標準を提供します。
プロトコル
SAML. セキュリティ アサーション マークアップ言語 (SAML) プロトコルは、シングル サインオン (SSO) によるアクセス制御方式を使用するシステムで最もよく使用されます。 SSO では、資格情報の 1 つのセットを使用して、ユーザーは複数のアプリケーションにアクセスできます。 この方法は、ユーザーがセッション中にアプリケーション間を移動する必要がある場合に最も役立ちます。 SSO は、各アプリケーションに対して個別のログインを要求するのではなく、セッションに対して既に認証済みのデータを使用して、アプリケーション間の切り替えを効率化します。 その結果、効率が向上することで、承認プロセスのボトルネックを防ぐことができます。 ドットコムモニタープラットフォームは、SAML 2.0 を使用して SSO をサポートしています
オープン ID. SAML と同様に、OpenID はウェブアプリケーションに使用され、このプロトコルの実装が SAML の実装よりも複雑でないため、さまざまなアプリケーションでアクセスしやすくなっている場合に、実際に見ることができます。
OAuth. Facebook、Google、Twitterなどの大規模な顧客向けプラットフォームは、OAuthに依存してサードパーティのアプリケーションをユーザーの許可に結び付けます。 OAuth は、承認されたアプリケーションが 1 つのサービスまたはプラットフォームからのログイン資格情報を使用して、別々のログインを必要とせずに追加のアプリケーションへのアクセスを提供できるようにすることで機能します。 承認は、ユーザーがいつでも許可または取り消しを行うことができます。
最近、最も一般的に使用される ID 管理システムでこれらのプロトコルの一部がどのように機能するかを見てみましょう。
Azure アクティブ ディレクトリを使用した ID 管理
Azure Active Directory (Azure AD) では、クラウドアプリケーションとオンプレミス アプリケーションに単一の ID システムを提供することで、アプリケーションの管理方法を簡素化します。 ソフトウェアをサービス (SaaS) アプリケーション、オンプレミス アプリケーション、および基幹業務 (LOB) アプリとして Azure AD に追加できます。 次に、ユーザーは、Office 365 やその他のビジネス アプリケーションと共に、これらのアプリケーションに安全かつシームレスにアクセスするために、1 回サインインします。 Dotcom-Monitor
プラットフォームは、Azure ADFS
との統合をサポートし、ユーザー認証とアクセスを設定します。
SAML 2.0 プロトコル
Azure Active Directory (Azure AD) は、アプリケーションがユーザーにシングル サインオン エクスペリエンスを提供できるようにする SAML 2.0 プロトコルを提供します。 SAML プロトコルでは、ID プロバイダー (Azure AD) とアプリケーションが自身に関する情報を交換する必要があります。
アプリケーションは、HTTP リダイレクト バインドを使用して認証要求要素 (ID プロバイダー) を Azure AD に渡します。 Azure AD は、HTTP ポスト バインディングを使用して、応答要素をクラウド サービスにポストします。
SAML 認証の認証フロー:
- ユーザーは、ブラウザーでアプリケーション URL を入力してアプリケーションにアクセスしようとします。
- アプリケーションは、この場合は SAML で構成された ID プロバイダーを検索します。
- アプリケーションは SAML 認証要求を生成し、ユーザーのブラウザーは Azure AD SAML シングル サインオン URL にリダイレクトされ、ユーザーは資格情報を使用してログインします。
- Azure AD は、有効な資格情報を確認し、ユーザーを認証し、SAML トークンを生成します。
- Azure AD は、トークンを含む SAML 応答を投稿し、応答にデジタル署名します。
- アプリケーションは、提供された証明書を使用して応答を検証し、ソースを確認します。
- アプリケーションは、ユーザーが有効であることを認識し、アプリケーション内でユーザーを許可する認証を完了します。
マイクロソフト ID プラットフォーム上の OAuth 2.0 および OpenID 接続プロトコル
ほぼすべての OAuth 2.0 および OpenID 接続フローでは、交換に関与する 4 つの関係者があります。
- 承認サーバー: Microsoft の ID システムであり、各ユーザーの ID を管理し、リソースへのアクセスを許可および取り消し、トークンを発行します。 ID プロバイダーとも呼ばれる承認サーバー。 ユーザーの情報、アクセス、およびフロー内の関係者間の信頼関係に関する情報を安全に処理します。
- リソース所有者: エンド ユーザーです。 データを所有し、第三者がそのデータまたはリソースにアクセスできるようにする権限を持つ当事者です。
- OAuth クライアント. これは、固有のアプリケーション ID によって識別されるアプリケーションです。 OAuth クライアントは通常、エンド・ユーザーが対話する当事者であり、許可サーバーからトークンを要求します。 クライアントには、リソース所有者がリソースにアクセスするためのアクセス許可が与えられている必要があります。
- リソース サーバー: リソースまたはデータが存在する場所。 承認サーバーを信頼して OAuth クライアントを安全に認証し、ベアラー アクセス トークンを使用して、リソースへのアクセスを確実に許可できます。
OpenID の認証フロー:
- ユーザーがブラウザーでアプリケーション URL を入力します。
- アプリケーションは Azure AD に登録され、一意のアプリケーション ID を持ちます。 アプリケーションは、アプリケーション ID を使用してユーザーを Azure AD にリダイレクトし、AD がアプリケーションを識別し、ユーザーにログイン画面を提供できるようにします。
- ユーザーは認証用の資格情報を入力し、アクセス許可に同意します。 OAuth はユーザーを検証し、トークンをユーザーのブラウザーに返します。
- ユーザーのブラウザーは、それぞれのアプリケーションの Azure AD に登録されているリダイレクト URI に提供トークンをリダイレクトします。
- アプリケーションはトークンを検証し、セッションを設定するため、ユーザーの認証を完了します。
- ユーザーは安全にサインインし、アプリケーションへのアクセスを許可されます。
概要: ID およびアクセス管理
IAM の目的は、権限のあるユーザーがデータベース、アプリケーション、システムなどの必要なリソースに安全にアクセスできるようにすることです。 IAM は、アプリケーション所有者、エンドユーザー、システム管理者のプロセスを簡素化し、必要な業務を迅速かつ効果的に実行できるようにします。 Dotcom-Monitor が
サードパーティのサービス統合
と、Dotcom-Monitor プラットフォーム内で
設定された SSO
を使用して IAM をサポートする方法について詳しくは、こちらの記事を参照してください。
