Oracle Cloud Infrastructureドキュメント

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

Oracle Autonomous AI DatabaseおよびMicrosoft Entra IDは、ユーザーおよびアプリケーションがEntra ID資格証明を使用してデータベースに接続できるように構成できます。

Azureのユーザーおよびアプリケーションは、Entra IDシングル・サインオン(SSO)資格証明を使用してログインしてデータベースにアクセスできます。これは、ユーザーまたはアプリケーションがEntra IDから最初にリクエストするEntr ID OAuth2アクセス・トークンを使用して行われます。このOAuth2アクセス・トークンには、ユーザーIDおよびデータベース・アクセス情報が含まれ、データベースに送信されます。マルチファクタ認証およびパスワードレス認証の構成の詳細は、Microsoft社の記事Azure Active Directoryのパスワードレス認証オプションを参照してください。

この統合は次のOracle AI Database環境で実行できます:

  • オンプレミスのOracle AI Databaseリリース19.18以降(21cを除く)

  • すべてのOracle AI Databaseサーバー・プラットフォーム: Linux、Windows、AIX、SolarisおよびHPUX

  • Oracle Autonomous AI Databaseサーバーレス

  • 専用Exadataインフラストラクチャ上のOracle Autonomous AI Database

  • Oracle Autonomous AI Database on Exadata Cloud@Customer

  • Oracle Exadata Database Service on Dedicated Infrastructure

  • Oracle Exadata Database Service on Cloud@Customer

  • Oracle Base Database Service

Entra IDを構成する手順では、これらの環境を網羅するために「Oracle AI Database」という用語を使用します。

このタイプの統合により、AzureユーザーはOracle Autonomous AI Databaseインスタンスにアクセスできます。Azureユーザーおよびアプリケーションは、Entra IDシングル・サインオン(SSO)資格証明を使用してログインし、データベースに送信するEntra ID OAuth2アクセス・トークンを取得できます。

Entra ID管理者は、Oracle Autonomous AI 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 AI Database API for MongoDBなどのOracle Autonomous AI Databaseツールは、Entra IDトークンを使用してデータベースに接続することと互換性がありません。

EntraIDトークンをサポートするために更新されるツールおよびアプリケーションは、Entra IDを使用してユーザーを直接認証し、データベース・アクセス・トークンをOracle Autonomous AI Databaseインスタンスに渡すことができます。SQL*Plusなどの既存のデータベース・ツールを構成して、ファイルの場所からEntra IDトークンを使用できます。このような場合、Entra IDトークンはMicrosoft PowerShellやAzure CLIなどのツールを使用して取得し、ファイルの場所に配置できます。Entra ID OAuth2データベース・アクセス・トークンは、有効期限付きで発行されます。Oracle AI Databaseクライアント・ドライバは、トークンが有効な形式であり、期限が切れていないことを確認してからデータベースに渡します。トークンのスコープはデータベースです。つまり、そのトークンが使用されるデータベースに関する情報がトークン内に存在します。Entra IDプリンシパルがデータベースEntra IDアプリ登録で割り当てられたアプリケーション・ロールは、アクセス・トークンの一部として含まれています。Entra IDトークンのディレクトリの場所には、ユーザーがトークン・ファイルをその場所に書き込み、データベース・クライアントがこれらのファイルを取得するために十分な権限のみ(ユーザーによる読取りおよび書込みのみなど)を付与する必要があります。トークンによってデータベースへのアクセスが許可されるため、トークンはファイル・システム内で保護される必要があります。

Azureユーザーは、複数の方法を使用してEntra IDからトークンをリクエストし、Azureログイン・ウィンドウを開いてEntra ID資格証明を入力できます。

Oracle Autonomous AI Databaseは、次のEntra IDプリンシパルを表すトークンを受け入れます:

  • Azureユーザー(Entra IDテナンシに登録されているユーザー)

  • Entra IDテナンシでゲスト・ユーザーとして登録されているゲスト・ユーザー

  • サービス。これは、クライアント資格証明フローを使用してデータベースに自身で接続する登録されたアプリケーションです(接続プールのユース・ケース)

Oracle Autonomous AI Databaseでは、次のEntra ID認証フローがサポートされています:

  • Proof Key for Code Exchange (PKCE)を使用した対話型フロー(認可コード・フローとも呼ばれます)。ブラウザを使用してクライアント環境でEntra IDを認証するために(アプリケーションではなく)ヒューマン・ユーザーによく使用されます。

  • クライアント資格証明(エンド・ユーザーではなく、自身で接続するデータベース・アプリケーション用)

  • On-Behalf-Of (OBO)。ログイン・ユーザーのかわりにアプリケーションがアクセス・トークンをリクエストして、データベースに送信します

  • リソース所有者パスワード資格証明(ROPC)は、本番での使用には推奨されませんが、ポップアップ・ブラウザのユーザー認証を組み込むことが困難なテスト環境で使用できます。ROPCでは、Entra IDユーザー名およびパスワード資格証明がトークン・リクエスト・コールの一部である必要があります。

    ノート

    ノート: DBaaSとMicrosoft Entra IDの統合では、管理権限(SYSDBA、SYSOPER、SYSBACKUP、SYSDG、SYSKMおよびSYSRAC)を持つユーザーはサポートされません。

Microsoft Entra IDとOracle AI Databaseの統合のアーキテクチャ

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』を参照してください。

イメージの説明が続きます

図azure-authentication.pngの説明

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

  1. Azureユーザーは、リソース、Oracle AI Databaseインスタンスへのアクセスをリクエストします。

  2. データベース・クライアントまたはアプリケーションは、Entra IDからの認可コードをリクエストします。

  3. Entra IDはAzureユーザーを認証し、認可コードを返します。

  4. ヘルパー・ツールまたはアプリケーションはEntra IDの認可コードを使用して、OAuth2トークンと交換します。

  5. データベース・クライアントは、Oracle AI DatabaseにOAuth2アクセス・トークンを送信します。トークンには、データベースのためのEntra IDアプリ登録でユーザーが割り当てられたデータベース・アプリケーション・ロールが含まれています。

  6. Oracle AI Databaseインスタンスは、Entra ID公開キーを使用して、アクセス・トークンがEntra IDによって作成されたことを確認します。

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

Oracle AI DatabaseスキーマおよびロールへのAzureユーザーのマッピング

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

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

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

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

  • AzureユーザーとOracle AI Databaseスキーマ間の排他的マッピングの作成。 このタイプのマッピングでは、Azureユーザーに対してデータベース、スキーマを作成する必要があります。Azureユーザーが必要とするデータベース権限およびロールは、データベース・スキーマに付与する必要があります。データベース・スキーマは、Azureユーザーがデータベースに対して認可された場合に作成するだけでなく、付与された権限およびロールをEntra IDのロールおよびタスクの変更に応じて変更する必要があります。最後に、データベース・スキーマはAzureユーザーが組織を離れるときに削除する必要があります。

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

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

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

イメージの説明が続きます

図azure_mappings.pngの説明

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

  • Azureユーザーは、Oracle AI Databaseグローバル・スキーマ(ユーザー)に直接マップできます。

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

Entra IDを使用したOracle AI Databaseへの接続のユースケース

Oracle AI 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ユーザーのOBOトークンをリクエストし、APIを介してデータベース・クライアントに渡すことができます。

関連コンテンツ