機械翻訳について

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
  • Oracle Autonomous Database on Dedicated Exadata Infrastructure
  • 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、データベース・アクション、Oracle Graph Studio、MongoDB用のOracle Database APIなどのOracle Autonomous Databaseツールは、Entra IDトークンを使用してデータベースに接続することとは互換性がありません。

Entra IDトークンをサポートするように更新されるツールおよびアプリケーションは、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認証フローがサポートされています:

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

認可コード・フローは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「アクティブ・ディレクトリ」セクションの「アプリの登録」機能に登録されている必要があります。 データベース・クライアントは、Entra IDアプリケーション登録で登録する必要があります。 データベース・クライアントにデータベースのアクセス・トークンの取得を許可する権限も付与する必要があります。

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

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