Oracle Autonomous DatabaseとMicrosoft Entra IDの統合について

Microsoft Azure Active Directoryのアクセストークンは、OAuth 2.0規格に準拠しています。

データベース・クライアントからデータベースにアクセスするには、Entra IDアクセス・トークンが必要です(たとえば、SQLPlusまたはSQLclを使用)。Oracleクライアント(OCI、JDBC、ODPなど)は、ファイルの場所からEntra IDトークンを取得するように構成することも、データベース・クライアントAPIを介してトークンをクライアントに渡すこともできます。Azureユーザーは、スクリプト(Microsoftから入手できる例)を使用してトークンを取得し、データベース・クライアントが取得するファイルの場所に配置できます。アプリケーションは、Azure SDKを使用してアクセス・トークンを取得し、データベース・クライアントAPIを介してトークンを渡すことができます。Microsoft PowerShellやAzureコマンドライン・インタフェースなどのコマンドライン・ツールを使用して、アプリケーションがトークンを直接取得できない場合、Entra IDトークンを取得できます。

次の図は、OAuth2トークンを使用した、OAuth 2.0標準の一般的なフロー図です。サポートされている各フローの詳細は、Microsoft Entra IDドキュメントのMSALでの認証フローのサポートを参照してください。

図azure-authentication.epsの説明

認可コード・フローは、OAuth2標準であり、標準の一部として詳細に説明されています。フローには2つのステップがあります。最初のステップでは、ユーザーを認証し、認可コードを取得します。2番目のステップでは、認可コードを使用してデータベース・アクセス・トークンを取得します。

1. Azureユーザーは、リソース、Oracle Databaseインスタンスへのアクセスをリクエストします。
2. データベース・クライアントまたはアプリケーションは、Entra IDからの認可コードをリクエストします。
3. Entra IDはAzureユーザーを認証し、認可コードを返します。
4. ヘルパー・ツールまたはアプリケーションはEntra IDの認可コードを使用して、OAuth2トークンと交換します。
5. データベース・クライアントは、OAuth2アクセス・トークンをOracleデータベースに送信します。トークンには、データベースのためのEntra IDアプリ登録でユーザーが割り当てられたデータベース・アプリケーション・ロールが含まれています。
6. Oracle Databaseインスタンスは、Entra ID公開キーを使用して、アクセス・トークンがEntra IDによって作成されたことを確認します。

データベース・クライアントとデータベース・サーバーのどちらも、AzureポータルのAzure Active Directoryセクションで「app registrations」機能を使用して登録する必要があります。データベース・クライアントは、Entra IDアプリケーション登録で登録する必要があります。データベース・クライアントには、データベースのアクセス・トークン取得を許可する権限も付与する必要があります。

Microsoft Azureユーザーは、Oracle Databaseインスタンスに対して認証できるようになる前に、Oracle Databaseスキーマにマップされ、(ロールを介して)必要な権限を持っている必要があります。

Microsoft Azureでは、Entra ID管理者は、ユーザー、グループおよびアプリケーションをデータベース・アプリケーション・ロールに割り当てることができます。

Entra IDユーザーをデータベース・スキーマに排他的にマッピングするには、データベース管理者がこのユーザーのライフサイクル(参加、移動、退去)用のデータベース・スキーマを作成および管理する必要があります。データベース管理者は、ユーザーが組織に参加するときにスキーマを作成する必要があります。また、データベース管理者は、Azureユーザーが割り当てられているタスクに合わせて、データベース・スキーマに付与されている権限およびロールを変更する必要があります。Azureユーザーが組織を離れた場合、データベース管理者は、使用されていないアカウントがデータベースに残らないようにデータベース・スキーマを削除する必要があります。データベース・アプリケーション・ロールを使用すると、Entra ID管理者は、グローバル・スキーマとグローバル・ロールにマップされているアプリケーション・ロールにユーザーを割り当てることによってアクセスおよびロールを制御できます。このようにして、データベースへのユーザー・アクセスはEntra ID管理者によって管理されるため、データベース管理者がすべてのユーザーのスキーマを作成、管理および削除する必要はありません。

Azureユーザーは、排他的に、またはアプリケーション・ロールを介してデータベース・スキーマ(ユーザー)にマップできます。

• AzureユーザーとOracle Databaseスキーマ間の排他的マッピングの作成。このタイプのマッピングでは、Azureユーザーに対するデータベース・スキーマを作成する必要があります。Azureユーザーが必要とするデータベース権限およびロールは、データベース・スキーマに付与する必要があります。データベース・スキーマは、Azureユーザーがデータベースに対して認可された場合に作成するだけでなく、付与された権限およびロールをEntra IDのロールおよびタスクの変更に応じて変更する必要があります。最後に、データベース・スキーマはAzureユーザーが組織を離れるときに削除する必要があります。
• Entra IDアプリケーション・ロールとOracle Databaseスキーマの間の共有マッピングの作成。このタイプのマッピングは排他的マッピングよりも一般的で、アプリケーション・ロールに直接割り当てられるAzureユーザーか、アプリケーション・ロールに割り当てられるEntra IDグループのメンバー用です。アプリケーション・ロールは、Oracle Databaseスキーマにマップされます(共有スキーマ・マッピング)。共有スキーマ・マッピングを使用すると、複数のAzureユーザーが同じOracle Databaseスキーマを共有できるため、新規ユーザーが組織に加わるたびに新しいデータベース・スキーマを作成する必要はありません。この運用上の効率により、データベース管理者は、新規ユーザーの構成、権限とロールの更新、およびアカウントの削除を行うことなく、データベース・アプリケーションのメンテナンス、パフォーマンスおよびチューニングのタスクに集中できます。

マップされたグローバル・スキーマに直接付与されているデータベース・ロールおよび権限に加えて、マップされたグローバル・ロールを介して追加のロールおよび権限を付与できます。同じ共有グローバル・スキーマにマップされた異なるAzureユーザーは、異なる権限およびロールが必要になる場合があります。Azureアプリケーション・ロールは、Oracle Databaseグローバル・ロールにマップできます。アプリケーション・ロールに割り当てられているAzureユーザーまたはアプリケーション・ロールに割り当てられているEntra IDグループのメンバーであるAzureユーザーには、データベースへのアクセス時にOracle Databaseグローバル・ロールが付与されます。

次の図は、使用できる様々なタイプの割当ておよびマッピングを示しています。

図azure_mappings.epsの説明

これらのマッピングは次のとおりです:

• Azureユーザーは、Oracle Databaseグローバル・スキーマ(ユーザー)に直接マップできます。
• Azureユーザー、Entra IDグループまたはアプリケーションはアプリケーション・ロールに割り当てられ、さらにOracle Databaseグローバル・スキーマ(ユーザー)またはグローバル・ロールのいずれかにマップされます。

Oracle Databaseでは、データベースへの接続にいくつかのユースケースをサポートしています。

• OAuth2認可コード・フロー:人間のユーザーに対して最も一般的なフローです。クライアントは、AzureユーザーにEntra IDで認可コードを取得するよう指示します。このコードは、データベース・アクセス・トークンの取得に使用されます。Microsoft Azureの記事のMicrosoft IDプラットフォームとOAuth 2.0認可コード・フローを参照してください。
• リソース所有者のパスワード資格証明(ROPC):このフローは、本番サーバーではお薦めしません。ポップアップ認証ウィンドウでは動作しないテスト・ソフトウェアで使用できます。これは、非グラフィックのユーザー・インタフェース環境でユーザーの認証にポップアップ・ウィンドウを使用できない場合に使用されます。
• クライアント資格証明:このフローは、アプリケーションがデータベースに接続するために使用されます。アプリケーションはEntra IDアプリケーションの登録によって登録する必要があり、クライアントIDとクライアント・パスワードが必要です。これらのクライアント資格証明は、アプリケーションがデータベースに接続するときのEntra IDからのデータベース・アクセス・トークン取得に使用する必要があります。アプリケーションは、ファイル・システムまたはデータベース・クライアントAPIを介してトークンを渡すことができます。
• ON-BEHALF-OF (OBO)トークン: Azureアプリケーションは、ログイン・ユーザーのOBIトークンをリクエストします。OBOトークンは、Azureユーザー・アイデンティティを持つデータベースと、データベースに割り当てられたアプリケーション・ロールのアクセス・トークンでもあります。これにより、Azureユーザーは、アプリケーションではなくユーザーとしてデータベースにログインできるようになります。アプリケーションのみが、AzureユーザーのOBIトークンをリクエストし、APIを介してデータベース・クライアントに渡すことができます。