Oracle Autonomous DatabaseとMicrosoft Entra IDの統合について
Oracle Autonomous DatabaseおよびMicrosoft Entra IDは、ユーザーおよびアプリケーションがEntra ID資格証明を使用してデータベースに接続できるように構成できます。
Azureのユーザーおよびアプリケーションは、Entra IDシングル・サインオン(SSO)資格証明を使用してログインし、データベースにアクセスできます。これは、ユーザーまたはアプリケーションがEntra IDから最初にリクエストするEntra ID OAuth2アクセス・トークンを使用して行われます。このOAuth2アクセス・トークンには、ユーザーIDおよびデータベース・アクセス情報が含まれ、データベースに送信されます。マルチファクタ認証の構成の詳細は、Microsoft社の記事Azure Active Directoryのパスワードレス認証オプションを参照してください。
この統合は、次のOracle Database環境で実行できます:
- オンプレミスOracle Databaseリリース19.18以降
- Oracle Autonomous Database Serverless
- 専用Exadataインフラストラクチャ上のOracle Autonomous Database
- Oracle Base Database Service
- Oracle Exadata Cloud Service(Oracle ExaCS)
- すべてのOracle Databaseサーバー・プラットフォーム: Linux、Windows、AIX、SolarisおよびHPUX
Entra IDを構成する手順では、これらの環境を含めるために「Oracle Database」という用語を使用します。
このタイプの統合により、AzureユーザーはOracle Autonomous Databaseインスタンスにアクセスできます。Azureユーザーおよびアプリケーションは、Entra ID Single Sign On (SSO)資格証明を使用してログインし、Entra ID OAuth2アクセス・トークンを取得してデータベースに送信できます。
Entra ID管理者は、Oracle Autonomous Databaseを作成し、Entra IDに登録します。Entra ID内では、これはアプリ登録と呼ばれ、アプリケーション登録の略です。これは、Entra IDを使用しているソフトウェアについてEntra IDが知っておく必要があるデジタル情報です。Entra ID管理者は、Entra IDのデータベース・アプリケーション登録のアプリケーション(アプリケーション)ロールも作成します。アプリケーション・ロールは、Azureユーザー、グループおよびアプリケーションをデータベース・スキーマおよびロールに接続します。Entra ID管理者は、Azureユーザー、グループ、またはアプリケーションをアプリケーションのロールに割り当てます。これらのアプリケーション・ロールは、データベース・グローバル・スキーマ、グローバル・ロール、またはスキーマとロールの両方にマップされます。アプリケーション・ロールに割り当てられたAzureユーザー、グループまたはアプリケーションは、データベース・グローバル・スキーマ、グローバル・ロール、またはスキーマとロールの両方にマップされます。Oracleグローバル・スキーマは、Azureユーザーに排他的にマップすることもできます。Azureゲスト・ユーザー(非組織ユーザー)またはEntra IDサービス・プリンシパル(アプリケーション)は、Entra IDアプリケーション・ロールを介してのみデータベース・グローバル・スキーマにマップできます。Oracleグローバル・ロールはAzureアプリケーション・ロールからのみマップでき、Azureユーザーからはマップできません。
Oracle APEX、データベース・アクション、Oracle Graph Studio、Oracle Database API for MongoDBなどのOracle Autonomous Databaseツールは、Entra IDトークンを使用したデータベースへの接続とは互換性がありません。
Entra IDトークンをサポートするように更新されるツールおよびアプリケーションは、Entra IDを使用してユーザーを直接認証し、データベース・アクセス・トークンをOracle Autonomous Databaseインスタンスに渡すことができます。ファイルの場所からEntra IDトークンを使用するように、SQL*Plusなどの既存のデータベース・ツールを構成できます。このような場合、Entra IDトークンを取得するには、Microsoft PowerShellやAzure CLIなどのツールを使用し、ファイルの場所を指定します。Entra ID OAuth2データベース・アクセス・トークンは、有効期限付きで発行されます。Oracle Databaseクライアント・ドライバは、トークンが有効な形式であり、期限が切れていないことを確認してからデータベースに渡します。トークンのスコープはデータベースです。つまり、トークンにはそのトークンが使用されるデータベースに関する情報が含まれています。Entra IDプリンシパルがデータベースEntra IDアプリ登録で割り当てられたアプリケーション・ロールは、アクセス・トークンの一部として含まれています。Entra IDトークンのディレクトリの場所には、ユーザーがトークン・ファイルをその場所に書き込み、データベース・クライアントがこれらのファイルを取得するのに十分な権限のみ(ユーザーによる読取りおよび書込みのみなど)を付与する必要があります。トークンによってデータベースへのアクセスが許可されるため、トークンはファイル・システム内で保護される必要があります。
Azureユーザーは、Entra IDの資格証明を入力するためにAzureログイン・ウィンドウを開くためのいくつかの方法を使用して、Entra IDからトークンをリクエストできます。
Oracle Autonomous Databaseは、次のEntra IDプリンシパルを表すトークンを受け入れます:
- Azureユーザー(Entra IDテナンシに登録されたユーザー)
- ゲスト・ユーザー。これは、Entra IDテナンシにゲスト・ユーザーとして登録されています
- サービス。これは、クライアント資格証明フローを使用してデータベースに自身で接続する登録されたアプリケーションです(接続プールのユース・ケース)
Oracle Autonomous Databaseでは、次のEntra ID認証フローがサポートされています:
- Proof Key for Code Exchange (PKCE)を使用した対話型フロー(認可コード・フローとも呼ばれる)で、ブラウザを使用してクライアント環境でEntra IDを認証するために、人間のユーザー(アプリケーションではない)に最もよく使用されます。
- クライアント資格証明。(エンド・ユーザーとしてではなく)それ自体として接続するデータベース・アプリケーションで使用されます
- On-Behalf-Of (OBO)。ログイン・ユーザーのかわりにアプリケーションがアクセス・トークンをリクエストして、データベースに送信します
- リソース所有者パスワード資格証明(ROPC)。本番環境での使用は推奨されませんが、ポップアップ・ブラウザでのユーザー認証の組込みが困難なテスト環境で使用できます。ROPCでは、Entra IDユーザー名とパスワード資格証明がトークン・リクエスト・コールの一部である必要があります。
Microsoft Enrtra IDとのDBaaS統合では、管理権限を持つユーザー(
SYSDBA、SYSOPER、SYSBACKUP、SYSDG、SYSKMおよびSYSRAC)はサポートされていません。
- Oracle DatabaseとMicrosoft Entra IDの統合のアーキテクチャ
Microsoft Azure Active Directoryアクセス・トークンは、OAuth 2.0標準とその拡張に従います。 - Oracle DatabaseのスキーマおよびロールへのAzureユーザーのマッピング
Oracle Databaseインスタンスに対して認証できるようにするには、Microsoft AzureユーザーをOracle Databaseスキーマにマップし、(ロールを介して)必要な権限を付与する必要があります。 - Entra IDを使用したOracle Databaseへの接続のユースケース
Oracle Databaseでは、データベースへの接続のユースケースをいくつかサポートしています。
Oracle 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での認証フローのサポートを参照してください。
認可コード・フローはOAuth2標準で、標準の一部として詳細に説明されています。フローには2つのステップがあります。最初のステップでは、ユーザーを認証し、認可コードを取得します。2番目のステップでは、認可コードを使用してデータベース・アクセス・トークンを取得します。
- Azureユーザーは、リソース、Oracle Databaseインスタンスへのアクセスをリクエストします。
- データベース・クライアントまたはアプリケーションは、Entra IDからの認可コードをリクエストします。
- Entra IDはAzureユーザーを認証し、認可コードを返します。
- ヘルパー・ツールまたはアプリケーションは、Entra IDの認可コードを使用して、それを
OAuth2トークンと交換します。 - データベース・クライアントは、Oracleデータベースに
OAuth2アクセス・トークンを送信します。トークンには、データベースのためのEntra IDアプリケーション登録でユーザーが割り当てられたデータベース・アプリケーション・ロールが含まれます。 - Oracle Databaseインスタンスでは、Entra ID公開キーを使用して、アクセス・トークンがEntra IDによって作成されたことを確認します。
データベース・クライアントとデータベース・サーバーの両方を、Azureポータルの「Azure Active Directory」セクションのアプリケーション登録機能に登録する必要があります。データベース・クライアントは、Entra IDアプリケーション登録で登録する必要があります。データベース・クライアントには、データベースのアクセス・トークン取得を許可する権限も付与する必要があります。
Oracle DatabaseスキーマおよびロールへのAzureユーザーのマッピング
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グローバル・ロールにマップできます。アプリケーション・ロールに割り当てられているか、アプリケーション・ロールに割り当てられているEntra IDグループのメンバーであるAzureユーザーには、データベースへのアクセス時にOracle Databaseグローバル・ロールが付与されます。
次の図は、使用できる様々なタイプの割当ておよびマッピングを示しています。
これらのマッピングは次のとおりです:
- Azureユーザーは、Oracle Databaseグローバル・スキーマ(ユーザー)に直接マップできます。
- Azureユーザー、Entra IDグループまたはアプリケーションがアプリケーション・ロールに割り当てられ、その後、Oracle Databaseグローバル・スキーマ(ユーザー)またはグローバル・ロールのいずれかにマップされます。
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アプリケーションは、ログイン・ユーザーのOBOトークンをリクエストします。OBOトークンは、Azureユーザー・アイデンティティを持つデータベースと、データベースに割り当てられたアプリケーション・ロールのアクセス・トークンでもあります。これにより、Azureユーザーは、アプリケーションではなくユーザーとしてデータベースにログインできます。アプリケーションのみが、AzureユーザーのOBOトークンをリクエストし、APIを介してデータベース・クライアントに渡すことができます。