Microsoft Entra ID を定義する
Adatum 管理チームは同社の顧客のために、アプリケーションによって提供されるサービスに安全にアクセスする信頼性の高い手段を確保したいと考えています。 あなたは、Microsoft Entra ID の認証と承認の機能を利用してこの機能を実装するつもりです。 この目的を達成するために、クラウドネイティブ アプリケーション関連の機能に注力しつつ、Microsoft Entra ID の主要な機能と利点を調査することにしました。
認証では、ユーザーやデバイスなどのセキュリティ プリンシパルの ID が確認されます。 認可では、特定のアクションを実行したり特定のリソースにアクセスしたりするためのアクセス許可が、認証済みのセキュリティ プリンシパルに付与されます。
Microsoft Entra ID とは何であり、その利点は何ですか?
Microsoft Entra ID は、Microsoft のクラウドベースの ID およびアクセス管理サービスです。 ほとんどの Microsoft クラウド サービスおよび広範なサードパーティ SaaS (サービスとしてのソフトウェア) 製品との統合によって認証機能を提供し、承認を支援します。 業界標準の最新の認証プロトコルや承認プロトコルがサポートされています。
Note
また、Windows Server Active Directory との統合により、企業ネットワークやイントラネット上のアプリなどの社内リソースのほか、自社開発のクラウド アプリを保護する効果も Microsoft Entra ID にはあります。
Microsoft Entra ID が ID ストアとしての役割を果たすことで、組織のユーザー、グループ、デバイス用のアカウントを作成する機能が得られます。 また、取引先組織の ID を表すゲスト アカウントを作成することもできるため、企業間 (B2B) シナリオでも、安全かつ簡単にリソースを共有できます。 外部ユーザーが既存の資格情報でのサインアップを通じてアプリにアクセスできるようにすれば、企業-消費者間 (B2C) のシナリオでも Microsoft Entra ID を使用できます。また、これは最も一般的なソーシャル ID プロバイダーをサポートしています。
どのシナリオにおいても、潜在的脅威に対する保護のレベルを決めることになるコントロールを別途実装できます。 そうしたコントロールの例としては、多要素認証や条件付きアクセスの組み込みサポートが挙げられます。
Microsoft Entra ID では、そのオブジェクト (ユーザー、グループ、アプリなど) が、"テナント" と呼ばれるコンテナーにまとめて整理されます。 各テナントは、管理とセキュリティの境界を表します。 自分の組織に対して、テナントを 1 つまたは複数作成できます。 各 Azure サブスクリプションは Microsoft Entra テナントに関連付けられます。
クラウドネイティブ アプリケーションにおける Microsoft Entra ID の役割は何ですか?
アプリの開発者は、アプリケーションとそのデータに対するアクセスを認証、承認する目的で Microsoft Entra ID を使用できます。 Microsoft Entra ID は、カスタム アプリの作成に役立つプログラミングによる手段を提供します。 また、アプリケーションの登録やその個々のセキュリティ プリンシパルをサポートするなど、デジタル ID 関連の情報を一元的に格納する場所としての役割も果たします。 この機能によって、社内開発のアプリケーションに対する粒度の細かいアクセスを個々のユーザーやゲスト、グループに提供できるようになります。 また、Microsoft Entra ID で保護された他のリソースやサービス、アプリケーションにアクセスする際にも、アプリケーションが独立して、またはユーザーの代理で動作できるようにします。
クラウドネイティブ アプリケーションでは、セキュリティ プリンシパルの認証に、HTTP ベースのオープン プロトコルが利用されます。クライアントもアプリケーションも、どこで実行されるかわからず、実行場所となるプラットフォームやデバイスも不定であるためです。 クラウドネイティブの ID ソリューションとして、この機能を提供するのが Microsoft Entra ID です。その REST ベースのインターフェイスもそうした機能の 1 つであり、Graph API や OData ベースのクエリもサポートされます。
Microsoft Entra ID は、次のような、クラウドネイティブ アプリケーションの構築時に多く直面するさまざまなシナリオの実現を支援します。
- ユーザーが Web ブラウザーで Web アプリケーションにアクセスする。
- ユーザーがブラウザーベースのアプリからバックエンド Web API にアクセスする。
- ユーザーがモバイル アプリからバックエンド Web API にアクセスする。
- アプリケーションが、実際のユーザーやユーザー インターフェイスを介さずに、独自の ID を使用してバックエンド Web API にアクセスする。
- 他の Web API とやり取りするアプリケーションが、ユーザーから委任された資格情報を使用してユーザーの代理で動作する。
これらの各シナリオでは、承認されていない使用からアプリケーションを保護する必要があります。 その手順には最低でも、リソースへのアクセスを要求するセキュリティ プリンシパルの認証が必要となります。 その認証には、Security Assertion Markup Language (SAML) V2.0、WS-Fed、OpenID Connect など、いくつかある一般的なプロトコルのいずれかを使用できるでしょう。 Web API との通信には通常、OAuth2 プロトコルとそのプロトコルでサポートされるアクセス トークンが利用されます。