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以降(21cを除く)
- すべてのOracle Databaseサーバー・プラットフォーム: Linux、Windows、AIX、SolarisおよびHPUX
- Oracle Autonomous Database Serverless
- 専用Exadataインフラストラクチャ上のOracle Autonomous Database
- Exadata Cloud@Customer上のOracle Autonomous Database
- Oracle Exadata Database Service on Dedicated Infrastructure
- Oracle Exadata Database Service on Cloud@Customer
- Oracle Base Database Service
Entra IDを構成する手順では、これらの環境を網羅するために「Oracle Database」という用語を使用します。
このタイプの統合により、AzureユーザーはOracle Autonomous Databaseインスタンスにアクセスできます。Azureユーザーおよびアプリケーションは、Entra IDシングル・サインオン(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、Database Actions、Oracle Graph Studio、Oracle Database API for MongoDBなどのOracle Autonomous Databaseツールは、データベースとの接続にEntra IDトークンを使用する互換性がありません。
EntraIDトークンをサポートするために更新されるツールおよびアプリケーションは、Entra IDを使用してユーザーを直接認証し、データベース・アクセス・トークンをOracle Autonomous Databaseインスタンスに渡すことができます。SQL*Plusなどの既存のデータベース・ツールを構成して、ファイルの場所からEntra IDトークンを使用できます。このような場合、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認証フローがサポートされています:
- コード交換用証明キー(PKCE)を使用した対話型フロー(認可コード・ワークフローとも呼ばれます)は、ブラウザでクライアント環境でEntra IDに対して認証するために(アプリケーションではなく)ユーザーに最も一般的に使用されます
- クライアント資格証明。(エンド・ユーザーとしてではなく)それ自体として接続するデータベース・アプリケーションで使用されます
- On-Behalf-Of (OBO)。ログイン・ユーザーのかわりにアプリケーションがアクセス・トークンをリクエストして、データベースに送信します
- リソース所有者パスワード資格証明(ROPC)。本番環境での使用は推奨されませんが、ポップアップ・ブラウザでのユーザー認証を組込みが困難なテスト環境で使用できます。ROPCでは、トークン・リクエスト・コールの一部としてEntra IDユーザー名とパスワード資格証明が必要です。
Microsoft Entra IDとのDBaaS統合では、管理権限を持つユーザー(
SYSDBA
、SYSOPER
、SYSBACKUP
、SYSDG
、SYSKM
およびSYSRAC
)はサポートされていません。
トピック
- Oracle DatabaseとMicrosoft Entra IDの統合のアーキテクチャ
Microsoft Azure Active Directoryアクセス・トークンでは、OAuth 2.0標準と拡張に従います。 - Oracle DatabaseスキーマおよびロールへのAzureユーザーのマッピング
Microsoft AzureユーザーをOracle Databaseスキーマにマップし、(ロールを介して)必要な権限を所有してから、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ドキュメントの『Authentication flow support in MSAL』を参照してください。
認可コード・フローはOAuth2標準で、標準の一部として詳細に説明されています。フローには2つのステップがあります。最初のステップでは、ユーザーを認証し、認可コードを取得します。2番目のステップでは、認可コードを使用してデータベース・アクセス・トークンを取得します。
- Azureユーザーは、リソース、Oracle Databaseインスタンスへのアクセスをリクエストします。
- データベース・クライアントまたはアプリケーションは、Entra IDからの認可コードをリクエストします。
- Entra IDはAzureユーザーを認証し、認可コードを返します。
- ヘルパー・ツールまたはアプリケーションはEntra IDの認可コードを使用して、
OAuth2
トークンと交換します。 - データベース・クライアントは、
OAuth2
アクセス・トークンをOracleデータベースに送信します。トークンには、データベースのためのEntra IDアプリ登録でユーザーが割り当てられたデータベース・アプリケーション・ロールが含まれています。 - Oracle Databaseインスタンスは、Entra ID公開キーを使用して、アクセス・トークンがEntra IDによって作成されたことを確認します。
データベース・クライアントとデータベース・サーバーのどちらも、AzureポータルのAzure Active Directoryセクションで「app registrations」機能を使用して登録する必要があります。データベース・クライアントは、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グローバル・ロールにマップできます。アプリケーション・ロールに割り当てられているAzureユーザーまたはアプリケーション・ロールに割り当てられている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アプリケーションは、ログイン・ユーザーのOBIトークンをリクエストします。OBOトークンは、Azureユーザー・アイデンティティを持つデータベースと、データベースに割り当てられたアプリケーション・ロールのアクセス・トークンでもあります。これにより、Azureユーザーは、アプリケーションではなくユーザーとしてデータベースにログインできるようになります。アプリケーションのみが、AzureユーザーのOBIトークンをリクエストし、APIを介してデータベース・クライアントに渡すことができます。