Oracle Exadata Database Service on Dedicated Infrastructureのユーザーは、Microsoft Azure Active Directory (Azure AD)サービスで一元管理できます。

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

• オンプレミスのOracle Databaseリリース19.16以降(ただし、Oracle Database 21cは対象外)
• データベース・バージョン19.17以降のOracle Exadata Database Service on Dedicated Infrastructure。この機能は、Oracle Databaseリリース21cではサポートされていません。
• Oracle Base Database Service

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

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

管理者は、Azure ADでOracle Exadata Database Service on Dedicated Infrastructureインスタンスのアプリケーション登録(アプリ登録)を作成および構成します。また、データベース管理者は、Azure ADでデータベース・アプリケーション登録用のアプリケーション(アプリ)ロールを作成し、それらのロールをAzure ADのユーザー、グループおよびアプリケーションに割り当てます。これらのアプリケーション・ロールは、データベース・グローバル・スキーマおよびグローバル・ロールにマップされます。アプリケーション・ロールに割り当てられたAzure ADプリンシパルは、データベース・グローバル・スキーマまたはデータベース・グローバル・ロールにマップされます。Oracleグローバル・スキーマは、Azure ADユーザーに排他的にマップすることもできます。プリンシパルがゲスト・ユーザーまたはサービス・プリンシパルである場合、それらはAzureアプリケーション・ロールを介してのみデータベース・スキーマにマップできます。Oracleグローバル・ロールは、Azureアプリケーション・ロールにのみマップできます。

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

Azure ADユーザーは、次のような方法を使用して、Azure ADアプリケーション登録に登録されたクライアントとしてトークンをリクエストできます:

• コマンドライン、スクリプト、ファイルまたはその他のサポートされている方法でAzure ADのユーザー名とパスワードを渡します
• マルチファクタ認証の有無にかかわらず、Azure AD認証画面にAzure AD資格証明を入力します

Oracle Exadata Database Service on Dedicated Infrastructureでは、次のAzure AD認証フローがサポートされています:

• リソース所有者パスワード資格証明(ROPC)。これは、ポップアップ・ウィンドウを使用してユーザーを認証できない場合に、非グラフィック・ユーザー・インタフェース環境で使用されます。
• 認可コード。これは、ブラウザを使用してユーザーの資格証明を入力できる場合に使用されます
• クライアント資格証明。これは、エンドユーザーではなく自身で接続するアプリケーション用です
• On-Behalf-Of (OBO)。ログイン・ユーザーのかわりにアプリケーションがアクセス・トークンをリクエストして、データベースに送信します

Oracle Exadata Database Service on Dedicated Infrastructureは、次のAzure ADプリンシパルを表すトークンを受け入れます:

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

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

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

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

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

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

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

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

図5-1 Azure ADとOracle Database間の割当ておよびマッピング

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

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

Oracle Databaseでは、Microsoft Azure Active Directoryを使用してOracle Databaseインスタンスに接続するための4つのタイプのユース・ケースがサポートされています。

• OAuth 2.0認可フローを使用した接続: クライアントはリソース所有者を認可サーバーに転送し、認可サーバーは認可コードを使用してリソース所有者をクライアントに戻します。Microsoft Azureの記事のMicrosoft IDプラットフォームとOAuth 2.0認可コード・フローを参照してください。
• リソース所有者のパスワード資格証明を使用した接続: アクセス・トークンを取得するために、リソース所有者のパスワード資格証明(つまり、ユーザー名とパスワード)を直接使用できます。Azure ADでは、このフローに追加のクライアントIDとシークレットが必要です。(このシークレットはパブリック・クライアントには必要ありません。)Microsoft Azureの記事のMicrosoft IDプラットフォームとOAuth 2.0リソース所有者のパスワード資格証明を参照してください。
• クライアント資格証明を使用した接続: クライアントは、独自に動作するか(クライアントが同時にリソース所有者でもある場合)、認可サーバーで用意された認可に基づいて保護リソースへのアクセスをリクエストします。このフローは、サービス・プリンシパルのAzure OAuth2アクセス・トークンを取得するために使用されます。アプリケーションは、Azure ADのAzure AD OAuth2アクセス・トークンを直接リクエストし、それをデータベース・クライアントAPIを介して渡すこともできます。Microsoft Azureの記事のサービス・プリンシパルを使用したAzure ADトークンの取得を参照してください。
• On-Behalf-Of (OBO)トークンを使用した接続: Azureアプリケーションは、ログイン・ユーザーのOBOトークンをリクエストします。OBOトークンは、Azure ADユーザー・アイデンティティを持つデータベースと、データベースに割り当てられたアプリケーション・ロールのアクセス・トークンでもあります。これにより、Azure ADユーザーは、アプリケーションではなくユーザーとしてデータベースにログインできます。アプリケーションのみが、Azure ADユーザーのOBOトークンをリクエストし、APIを介してデータベース・クライアントに渡すことができます。

Oracle管理者とMicrosoft Azure管理者の両方が、Oracle Exadata Database Service on Dedicated InfrastructureとMicrosoft Azure AD間の接続を構成する役割を果たします。

一般的なプロセスは次のとおりです:

1. Oracle管理者は、Oracle Database環境がMicrosoft Azure AD統合の要件を満たしていることを確認します。Microsoft Azure AD統合のためのOracle Databaseの要件を参照してください。
2. Oracle管理者は、データベース・インスタンスをMicrosoft Azure ADテナンシに登録し、Oracle Exadata Database Service on Dedicated InfrastructureとAzure ADエンドポイント間の接続を有効にします。

   登録プロセスの一環として、Oracle管理者またはAzure管理者は、Oracle DatabaseとMicrosoft Azureエンドポイント間のマッピングに使用するAzureアプリケーション・ロールを作成または指定します。

3. Oracle管理者は、グローバル・スキーマを作成して、Azure ADユーザー(排他スキーマ・マッピング)またはAzureアプリケーション・ロール(共有スキーマ・マッピング)にマップします。Azure ADユーザーまたはアプリケーションを1つのスキーマにマップする必要があります。
4. オプションで、Oracle管理者はグローバルOracle Databaseロールを作成し、Azureアプリケーション・ロールにマップします。
5. Oracle Exadata Database Service on Dedicated Infrastructureインスタンスに接続するAzure ADエンド・ユーザーは、クライアント・アプリケーションをAzure ADクライアントとして登録します(Oracle Databaseの登録方法と同様)。

   Azure ADクライアントは、アプリケーション・クライアントがパブリックでないかぎり、クライアント識別とクライアント・シークレットを持ちます。アプリケーション・クライアントがパブリックの場合、アプリケーション・クライアント識別のみが必要です。

6. Azure ADエンド・ユーザー(データベース管理者でも可能)は、PowerShellやAzureコマンドライン・インタフェースなどのユーティリティを使用して接続し、トークンを取得してローカル・ファイル・ディレクトリに格納します。アプリケーションは、Azure ADのAzure AD OAuth2アクセス・トークンを直接リクエストし、それをデータベース・クライアントAPIを介して渡すこともできます。Azure AD OAuth2トークンの受渡しの詳細は、次のOracle Databaseクライアントのドキュメントを参照してください:
   • JDBCシン・クライアント: 『Oracle Database JDBC開発者ガイド』
   • Oracle Call Interface (OCI): 『Oracle Call Interface開発者ガイド』
   • Oracle Data Provider for .NET (ODP): Oracle Data Provider for .NET Developer's Guide.Connecting to Oracle Database
7. Oracle Exadata Database Service on Dedicated Infrastructureインスタンスに接続したら、Azure ADエンド・ユーザーは必要に応じてタスクを実行します。

Exadata Cloud InfrastructureのデータベースでAzure AD認証を使用する前に、ネットワーキング・サービスを使用して、データベース・リソースが存在する仮想クラウド・ネットワーク(VCN)およびサブネットにサービス・ゲートウェイ、ルート・ルールおよびエグレス・セキュリティ・ルールを追加する必要があります。

1. OCIドキュメントのタスク1: サービス・ゲートウェイの作成の手順に従って、データベース・リソースが存在するVCN内にサービス・ゲートウェイを作成します。
2. サービス・ゲートウェイを作成したら、データベース・リソースが存在する各サブネット(VCN内)にルート・ルールおよびエグレス・セキュリティ・ルールを追加して、これらのリソースがゲートウェイを使用してAzure AD認証を使用できるようにします:
   1. サブネットの「サブネットの詳細」ページに移動します。
   2. 「サブネット情報」タブで、サブネットの「ルート表」の名前をクリックして、その「ルート表の詳細」ページを表示します。
   3. 既存のルート・ルールの表で、次の特性を持つルールがすでに存在するかどうかを確認します:
      • 宛先: 0.0.0.0/0
      • ターゲット・タイプ: NATゲートウェイ
      • ターゲット: VCN内に作成したNATゲートウェイの名前

      そのようなルールが存在しない場合は、「ルート・ルールの追加」をクリックし、これらの特性を持つルート・ルールを追加します。

   4. サブネットの「サブネットの詳細」ページに戻ります。
   5. サブネットの「セキュリティ・リスト」表で、サブネットのセキュリティ・リストの名前をクリックして、その「セキュリティ・リストの詳細」ページを表示します。
   6. サイド・メニューの「リソース」で、「エグレス・ルール」をクリックします。
   7. 既存のエグレス・ルールの表で、次の特性を持つルールがすでに存在するかどうかを確認します:
      • 宛先タイプ: CIDR
      • 宛先: 0.0.0.0/0
      • IPプロトコル: TCP
      • ソース・ポート範囲: 443
      • 宛先ポート範囲: すべて
   8. そのようなルールが存在しない場合は、「エグレス・ルールの追加」をクリックし、これらの特性を持つエグレス・ルールを追加します。

Azure ADトークンをデータベース・クライアントからデータベース・サーバーに送信する場合、TLS接続を確立する必要があります。ExaDB-Dサービス・インスタンスのデータベース証明書を含むTLSウォレットは、WALLET_ROOTの場所に格納する必要があります。WALLET_ROOT/<PDB GUID>/tlsのようにtlsディレクトリを作成します。

データベース・クライアントとサーバー間にTLSを構成する場合は、いくつかのオプションを検討する必要があります。

• 自己署名データベース・サーバー証明書と、既知の認証局によって署名されたデータベース・サーバー証明書の使用の比較
• 一方向TLS (TLS)と相互または双方向TLS (mTLS)の比較
• クライアントのウォレットの有無

自己署名証明書

自己署名証明書を使用することは、内部でITリソースに接続する場合の一般的なプラクティスです。これらは独自に作成でき、無料であるためです。リソース(この場合はデータベース・サーバー)には、データベース・クライアントに対して自身を認証するための自己署名証明書があります。自己署名証明書とルート証明書は、データベース・サーバー・ウォレットに格納されます。データベース・クライアントがデータベース・サーバー証明書を認識できるようにするには、ルート証明書のコピーがクライアントにも必要です。この自己作成ルート証明書は、クライアント側のウォレットに格納することも、クライアント・システムのデフォルト証明書ストアにインストールすることもできます(WindowsおよびLinuxのみ)。セッションが確立されると、データベース・クライアントは、データベース・サーバーによって送信された証明書が同じルート証明書によって署名されていることを確認します。

既知の認証局

既知のルート認証局を使用すると、ルート証明書がすでにクライアント・システムのデフォルト証明書ストアに格納されている可能性が高いという点でいくつかの利点があります。一般的なルート証明書の場合、クライアントがルート証明書を格納するための追加のステップはありません。欠点は、通常、これに関連付けられたコストがあることです。

一方向TLS

標準のTLSセッションでは、サーバーのみがクライアントに証明書を提供し、自身の認証を行います。クライアントは、サーバーに対して自身を認証するために個別のクライアント証明書を必要としません(HTTPSセッションの確立方法と同様)。データベースにはサーバー証明書を格納するためのウォレットが必要ですが、クライアントに必要なのはサーバー証明書の署名に使用されるルート証明書のみです。

双方向TLS (相互TLS、mTLSとも呼ばれる)

mTLSでは、クライアントとサーバーの両方に、相互に提供されるアイデンティティ証明書があります。ほとんどの場合、同じルート証明書がこれらの証明書の両方に署名するため、データベース・サーバーおよびクライアントで同じルート証明書を使用して他の証明書を認証できます。mTLSは、ユーザー・アイデンティティが証明書を介してデータベース・サーバーによって認証されるため、ユーザーの認証に使用されることがあります。これは、IAMトークンを渡すためには不要ですが、IAMトークンを渡すときに使用できます。

ウォレットありのクライアント

クライアント証明書を格納するためにmTLSを使用する場合、クライアント・ウォレットは必須です。ただし、ルート証明書は、同じウォレットまたはシステムのデフォルト証明書ストアのいずれかに格納できます。

ウォレットなしのクライアント

次の条件でTLSを使用する場合、ウォレットなしでクライアントを構成できます: 1)クライアントに独自の証明書がない状態で一方向TLSが構成されており、2)データベース・サーバー証明書に署名したルート証明書がシステムのデフォルト証明書ストアに格納されています。サーバー証明書が一般的な認証局によって署名されている場合、ルート証明書はすでに存在している可能性があります。自己署名証明書の場合は、クライアント・ウォレットを使用しないように、システムのデフォルト証明書ストアにルート証明書をインストールする必要があります。

データベース・クライアントとデータベース・サーバー間のTLSを構成する方法の詳細(前述のオプションを含む)は、『Oracle Databaseセキュリティ・ガイド』のTransport Layer Security認証の構成を参照してください。

自己署名証明書の使用および追加のウォレット関連タスクの詳細は、『Oracle Databaseセキュリティ・ガイド』の公開キー・インフラストラクチャ(PKI)要素の管理を参照してください。

Microsoft Azure ADを使用してOracle Databaseインスタンスを構成する前に、現在の環境が特別な要件を満たしていることを確認する必要があります。

次に注意してください:

• Oracle Databaseサーバーは、Azure AD公開キーをリクエストできる必要があります。エンタープライズ・ネットワーク接続の設定によっては、プロキシ設定の構成が必要になる場合があります。
• Azure ADトークンをリクエストする必要があるユーザーおよびアプリケーションも、Azure ADへのネットワーク接続を持っている必要があります。接続用のプロキシ設定を構成する必要がある場合があります。
• トークンを安全に転送するため、Oracle DatabaseクライアントとOracle Databaseサーバーの間にTransport Layer Security (TLS)を構成する必要があります。このTLS接続は、一方向または相互のいずれかです。
• 自己署名または既知の認証局によって署名されるTLSサーバー証明書を作成できます。既知の認証局(CA)によって署名された証明書を使用する利点は、データベース・クライアントが、ルート証明書を使用してローカル・ウォレットを作成および保持するのではなく、Oracle Databaseサーバー証明書を検証できることです。これはLinuxおよびWindowsクライアントにのみ適用されることに注意してください。

管理者権限を持つユーザーは、Microsoft Azure ADを使用して、Oracle DatabaseインスタンスをMicrosoft Azure ADテナンシに登録します。

1. アプリケーションを登録するためのMicrosoft Azure AD権限を持つ管理者として、Azureポータルにログインします。
2. Azure Active Directory管理センター・ページで、左側のナビゲーション・バーから「Azure Active Directory」を選択します。
3. 「MS - App registrations」ページで、左側のナビゲーション・バーから「App registrations」を選択します。
4. 「New registration」を選択します。
   「Register an application」ウィンドウが表示されます。
   
5. 「Register an application」ページで、次のOracle Databaseインスタンス登録情報を入力します:
   • 「Name」フィールドに、Oracle Databaseインスタンス接続の名前(Example Databaseなど)を入力します。
   • 「Supported account types」で、ユース・ケースに一致するアカウント・タイプを選択します。
     • Accounts in this organizational directory only (tenant_name only - Single tenant)
     • Accounts in any organizational directory (Any Azure AD directory - Multitenant)
     • Accounts in any organizational directory (Any Azure AD directory - Multitenant) and personal Microsoft accounts (e.g. Skype, Xbox)
     • Personal Microsoft accounts only
6. 「Redirect URI (Optional)」設定は省略します。リダイレクトURIを作成する必要はありません。
7. 「Register」をクリックします。
   「Register」をクリックすると、Azure ADにアプリケーション登録の「Overview」ペインが表示され、「Essentials」の下にアプリケーション(クライアント) IDが表示されます。この値は、Microsoft IDプラットフォームでのアプリケーションの一意識別子です。
8. 登録済アプリケーションの権限を設定するスコープを登録します。
   1. 左側のナビゲーション・バーで、「Expose an API」を選択します。
   2. 「Set the App ID URI」の「Application ID URI」フィールドに、次のフォーマットを使用してデータベース接続のアプリケーションID URIを入力し、「Save」をクリックします:

      your_tenancy_url/application_(client)_id

      この指定で:

      • your_tenancy_urlには、接頭辞としてのhttpsと、Azure ADテナンシの完全修飾ドメイン名を含める必要があります。
      • application_(client)_idは、Oracle DatabaseインスタンスをAzure ADに登録したときに生成されたIDです。これは、アプリケーション登録の「Overview」ペインに表示されます。

      例:

      https://sales_west.example.com/1aa11111-1a1z-1a11-1a1a-11aa11a1aa1a

   3. 「Add a scope」を選択し、次の設定を入力します:
      
      

      • 「Scope name」では、スコープの名前を指定します。次の名前を入力します:

        session:scope:connect

        この名前は任意のテキストにすることができます。ただし、スコープ名を指定する必要があります。データベースにアクセスするためにデータベース・クライアント・アプリケーションへの同意を提供する場合、後でこのスコープ名を使用する必要があります。

      • 「Who can consent」では、必要な権限を指定します。「Admins and users」を選択するか、制限を厳しくする場合は「Admins only」を選択します。
      • 「Admin consent display name」では、管理者のみが表示できるスコープの目的(Connect to Oracleなど)を説明します。
      • 「Admin consent display name」では、管理者のみが表示できるスコープの目的(Connect to Example Databaseなど)を説明します。
      • 「User consent display name」は、スコープの目的の簡単な説明(Connect to Example Databaseなど)で、「Who can consent」で「Admins and users」を指定した場合にユーザーが参照できます。
      • 「User consent description」は、スコープの目的の詳細な説明(Connect to Example Databaseなど)で、「Who can consent」で「Admins and users」を指定した場合にユーザーが参照できます。
      • 「State」では、接続を有効または無効にします。「Enabled」を選択します。

Microsoft Entra ID v2アクセス・トークンを有効にするには、Azureポータルのupn属性を使用するように構成する必要があります。

1. 使用しているEntra IDアクセストークンのバージョンを確認します。
2. Microsoft Entra IDポータルにログインします。
3. 「Entra ID」を検索して選択します。
4. 「管理」で、「アプリケーション登録」を選択します。
5. シナリオおよび目的の結果に基づいてオプション要求を構成するアプリケーションを選択します。
6. 「管理」で、「トークン構成」を選択します。
7. 「要求の追加」をクリックし、「upn」を選択します。

• Entra IDアクセス・トークンのバージョンのチェック
  JSON WebトークンのWebサイトを使用すると、サイトで使用されているEntra IDアクセス・トークンのバージョンを確認できます。

Oracle DatabaseインスタンスがAzure ADエンドポイントにアクセスできることを確認する必要があります。

OracleデータベースでAzure ADのOAuth2トークンを受け入れるには、データベースがAzure ADエンドポイントから公開キーをリクエストする必要があります。

• 次のテストを実行して、データベースがAzure ADエンドポイントに接続できるかどうかを確認します:

  SET SERVEROUTPUT ON SIZE 40000
  DECLARE
    req UTL_HTTP.REQ;
    resp UTL_HTTP.RESP;
  BEGIN
    UTL_HTTP.SET_WALLET(path => 'system:');
    req := UTL_HTTP.BEGIN_REQUEST('https://login.windows.net/common/discovery/keys');
    resp := UTL_HTTP.GET_RESPONSE(req);
    DBMS_OUTPUT.PUT_LINE('HTTP response status code: ' || resp.status_code);
    UTL_HTTP.END_RESPONSE(resp);
  END;
  /

  このテストが成功すると、PL/SQLプロシージャが正常に完了しましたというメッセージが表示されます。

  次のメッセージが表示された場合は、データベース・ネットワーク・アクセス制御リスト(ACL)ポリシーによってテストがブロックされ、これをテストできるようにアクセス制御リスト・ポリシーを一時的に設定する必要があります。

  ORA-29273: HTTP request failed
  ORA-24247: network access denied by access control list (ACL)

  1. ACLを次のように設定します。

     BEGIN
     DBMS_NETWORK_ACL_ADMIN.APPEND_HOST_ACE(
       host => '*',
       ace  =>  xs$ace_type(privilege_list => xs$name_list('connect'),
                            principal_name => 'username_placeholder',
                            principal_type => xs_acl.ptype_db));
     END;
     /

     username_placeholderを、テストを実行しているデータベース・ユーザーのユーザー名に置き換えます。例:

     BEGIN
     DBMS_NETWORK_ACL_ADMIN.APPEND_HOST_ACE(
       host => '*',
       ace  =>  xs$ace_type(privilege_list => xs$name_list('connect'),
                            principal_name => 'DBA_DEBRA',
                            principal_type => xs_acl.ptype_db));
     END;
     /

  2. テストを再度実行します。
  3. ACLは不要になったため、削除します。たとえば、ユーザー名がdba_debraの場合:

     BEGIN
     DBMS_NETWORK_ACL_ADMIN.REMOVE_HOST_ACE(
       host => '*',
       ace  =>  xs$ace_type(privilege_list => xs$name_list('connect'),
                            principal_name => 'DBA_DEBRA',
                            principal_type => xs_acl.ptype_db));
     END;
     /

データベースがAzure ADエンドポイントに接続できない場合、ACLポリシーを設定した後でも、多くの場合、データベースのHTTP_PROXYパッケージを設定する必要があります。デフォルトのOracle Database環境またはOracle Real Application Clusters RAC環境のどちらを使用しているかに応じて、「関連トピック」にリストされているトピックを確認してください。ネットワーク管理者は、正しいHTTP_PROXY設定が何であるかを伝えることができる必要があります。

Entra IDでは、Azureユーザーおよびグループに割り当てられ、Oracle Databaseのグローバル・スキーマおよびロールにもマップされるアプリケーション・ロールを作成および管理できます。

• Microsoft Azure ADアプリケーション・ロールの作成
  Azure ADのユーザー、グループおよびアプリケーションがアプリケーション・ロールに割り当てられます。
• Microsoft Azure ADアプリケーション・ロールへのユーザーおよびグループの割当て
  Microsoft Azure ADユーザーがOracle Databaseインスタンスにアクセスできるようにするには、最初にユーザーをOracle Databaseスキーマのユーザーまたはロールにマップされるアプリケーション・ロールに割り当てる必要があります。
• アプリケーション・ロールへのアプリケーションの割当て
  Azure ADクライアント・アプリケーションをアプリケーション・ロールに割り当てることができます。

Oracle DatabaseでMicrosoft Azure AD外部認証を有効にできます。

1. ALTER SYSTEMシステム権限が付与されたユーザーとして、Oracle Databaseインスタンスにログインします。
2. 次のようにIDENTITY_PROVIDER_TYPEパラメータを設定します:

   ALTER SYSTEM SET IDENTITY_PROVIDER_TYPE=AZURE_AD SCOPE=BOTH;

3. IDENTITY_PROVIDER_TYPEパラメータが正しく設定されていることを確認します。

   SELECT NAME, VALUE FROM V$PARAMETER WHERE NAME='identity_provider_type';

   次の出力が表示されます。

   NAME                    VALUE 
   ----------------------  ------- 
   identity_provider_type  AZURE_AD

4. 次の構文を使用してIDENTITY_PROVIDER_CONFIGパラメータを設定します:

   ALTER SYSTEM SET IDENTITY_PROVIDER_CONFIG =
   {
      application_id_uri : string , // from registered app, to be mapped in jwt "aud" claim; 
                                    // Domain qualified to support cross tenancy resource access
      tenant_id : string,           // from tenant config
      app_id: string                // from registered resource app
   }SCOPE=BOTH;

   例:

   ALTER SYSTEM SET IDENTITY_PROVIDER_CONFIG =
   {
     "application_id_uri" : "https://www.example.com/11aa1a11-aaaa-1111-1111-1111aa11111",
     "tenant_id" : 111a1111-a11a-111a-1a1a-1111111111a,
     "app_id" : 11aa1a11-aaaa-1111-1111-1111aa11111
   }SCOPE=BOTH;

Oracle DatabaseインスタンスのAzure AD外部認証を無効にするには、ALTER SYSTEM文を使用してパラメータを設定する必要があります。

1. ALTER SYSTEMシステム権限が付与されたユーザーとして、Oracle Databaseインスタンスにログインします。
2. 次のようにアイデンティティ・プロバイダ・パラメータを設定します:

   ALTER SYSTEM RESET IDENTITY_PROVIDER_CONFIG SCOPE=BOTH;
   ALTER SYSTEM RESET IDENTITY_PROVIDER_TYPE SCOPE=BOTH;

Microsoft Azure ADユーザーにOracle Databaseスキーマを排他的にマップできます。

1. CREATE USERまたはALTER USERシステム権限を付与されたユーザーとして、Oracle Databaseインスタンスにログインします。
2. Azure ADユーザー名を指定するIDENTIFIED GLOBALLY AS句を使用して、CREATE USERまたはALTER USER文を実行します。
   たとえば、peter_fitchという名前の新しいデータベース・スキーマ・ユーザーを作成し、このユーザーをpeter.fitch@example.comという名前の既存のAzure ADユーザーにマップするには:

   CREATE USER peter_fitch IDENTIFIED GLOBALLY AS 
   'AZURE_USER=peter.fitch@example.com';

3. CREATE SESSION権限をユーザーに付与します。

   GRANT CREATE SESSION TO peter_fitch;

このマッピングでは、Oracleスキーマがアプリケーション・ロールにマップされます。

1. CREATE USERまたはALTER USERシステム権限を持つユーザーとして、Oracle Databaseインスタンスにログインします。
2. Azureアプリケーション・ロール名を指定するIDENTIFIED GLOBALLY AS句を使用して、CREATE USERまたはALTER USER文を実行します。
   たとえば、dba_azureという名前の新しいデータベース・グローバル・ユーザー・アカウント(スキーマ)を作成し、それをAZURE_DBAという名前の既存のAzure ADアプリケーション・ロールにマップするには:

   CREATE USER dba_azure IDENTIFIED GLOBALLY AS 'AZURE_ROLE=AZURE_DBA';

Azureアプリケーション・ロールにマップされたOracle Databaseグローバル・ロールによって、Azureユーザーおよびアプリケーションには、ログイン・スキーマを介して付与されたもの以上の追加の権限およびロールが付与されます。

1. CREATE ROLEまたはALTER ROLEシステム権限を付与されたユーザーとして、Oracle Databaseインスタンスにログインします
2. Azure ADアプリケーション・ロール名を指定するIDENTIFIED GLOBALLY AS句を使用して、CREATE ROLEまたはALTER ROLE文を実行します。
   たとえば、widget_sales_roleという名前の新しいデータベース・グローバル・ロールを作成し、それをWidgetManagerGroupという名前の既存のAzure ADアプリケーション・ロールにマップするには:

   CREATE ROLE widget_sales_role IDENTIFIED GLOBALLY AS 
   'AZURE_ROLE=WidgetManagerGroup';

Azure ADトークンを使用してOracle Databaseインスタンスに接続するようにクライアントを構成するには、多数の方法があります。

現在の環境に最適なクライアント接続方法を選択してください。このガイドでは、Azure AD OAuth2アクセス・トークンを取得する様々な方法でSQL*Plusを接続する例を示します。すべてのOracle Databaseクライアント・バージョン19.16以上で、ファイルとして渡されるトークンを受け入れることができます。JDBCシン・ドライバ、Instant ClientドライバおよびODP.netドライバも、アプリケーションからデータベース・クライアントAPIを介してトークンを受け入れます。SQL*PlusなどのOracle Databaseツールではトークンを直接取得できないため、PowerShellやAzure CLIなどのツールを使用してAzure AD OAuth2アクセス・トークンを取得する必要があります。Azure ADトークンを取得するには、Azure ADアプリケーション登録プロセスを介してクライアントを登録する必要があります。クライアントの登録は、アプリケーション登録を使用したAzure ADへのOracle Databaseサーバーの登録と同様です。データベースとクライアントの両方をAzure ADに登録する必要があります。

クライアントがデータベースのアクセス・トークンを取得するための権限を取得できるように、データベースを登録する必要があります。信頼できるクライアントがアクセス・トークンを要求していることをAzure ADで認識できるように、クライアントを登録する必要があります。

Azure ADにクライアントを接続する方法の詳細は、次のMicrosoft Azureの記事を参照してください:

• クイックスタート: Web APIにアクセスするためのクライアント・アプリケーションの構成
• 適切なAzureコマンドライン・ツールの選択
• Microsoft Authentication Libraryを使用したAzure ADトークンの取得
• LinuxへのAzure CLIのインストール

Oracle Databaseでは、Azure AD接続で複数のタイプのクライアント・ドライバがサポートされています。

• JDBCシン: Oracle Database 19.16 (2022年7月)、Oracle Database 21.8 (2022年10月)
• OCI (Cドライバ): Oracle Database 19.16 (2022年7月)
• OCIに基づくOracle Instant Client
• Oracle Data Provider (コア): Oracle Database 19.16、Oracle Database 21.7
• Oracle Data Provider (管理対象外): OCIに基づく
• Oracle Data Provider (管理対象): Oracle Database 19.16、Oracle Database 21.7
• OCI上に構築された他のすべてのドライバはOCI互換性を持っています

Azureユーザー、Azure ADおよびOracle Databaseインスタンス間の接続は、これらのコンポーネント全体でのOAuth2トークンの受渡しに依存します。

この例は、パブリック・クライアントでのリソース所有者パスワード資格証明(ROPC)フローの使用を示しています。ROPCの詳細は、Microsoft Azureの記事のMicrosoft IDプラットフォームとOAuth 2.0リソース所有者のパスワード資格証明を参照してください。

図5-2 パブリック・クライアントでのROPC操作フロー

1. Azureユーザーは、PowerShellでデータベースのAzure ADアクセス・トークンをリクエストし、返されたトークンはファイルの場所にあるtokenというファイルに書き込まれます。
2. Azureユーザーは、/スラッシュ・ログインを使用してデータベースに接続します。sqlnet.oraまたはtnsnames.oraの接続文字列は、Azure AD OAuth2トークンが必要であり、指定されたファイルの場所からそれを取得するようにインスタント・クライアントに指示します。アクセス・トークンがデータベースに送信されます。
3. データベースは、(Azure AD公開キーを使用して)アクセス・トークンがAzure ADから取得されたことを検証し、トークンで追加の要求がないか確認します。
4. データベースは、スキーマ・マッピング(排他または共有)を検出し、セッションを作成します。データベースは、Azureユーザーがアプリケーション・ロールを介して割り当てられているグローバル・ロールも付与します。

このタイプの登録は、Azure ADアプリケーション登録へのOracle Databaseの登録と同様です。

• 機密およびパブリック・クライアントの登録
  ユース・ケースに応じて、データベース・クライアントを機密またはパブリックとしてAzureに登録できます。
• Azure ADへのデータベース・クライアント・アプリケーションの登録
  クライアント・アプリケーション登録の作成は、Microsoft Azure ADテナンシでのOracle Databaseインスタンスの作成と同様です。

これらの例は、Azure AD OAuth2トークンを取得できる様々な方法を示しています。

• 例: リソース所有者パスワード資格証明を使用してトークンを取得するためのPowerShellの使用
  この例は、PowerShellにより、リソース所有者パスワード資格証明(ROPC)を使用してAzure ADアクセス・トークンを取得する方法を示しています。
• 例: 認可フローを使用したMicrosoft Authentication LibraryでのPythonの使用
  Microsoft Authentication Library (MSAL)によるこの例はPythonにあるため、PowerShellやLinuxなどの様々なプラットフォームで実行できます。
• 例: リソース所有者パスワード資格証明フローでのCurlの使用
  この例は、Azure AD APIに対してcurlコマンドを使用して、パブリックAzure ADクライアントでリソース所有者パスワード資格証明(ROPC)フローを使用する方法を示しています。
• 例: 認可フローを使用したAzure CLI
  この例は、Azure CLIを使用してアクセス・トークンを取得し、そのトークンをファイルに書き込む方法を示しています。

Azure ADデータベース・アクセス・トークンを一定の場所から取得し、/スラッシュ・ログインの使用時にそれを使用するようにSQL*Plusを構成する必要があります。

1. Azure ADユーザー・アカウントを持っていることを確認します。
2. 次のいずれかについては、Azure AD管理者またはOracle Database管理者に確認してください:
   • Azure ADトークンの取得に使用できるアプリケーション・クライアントID。それを実行するAzure AD権限がある場合は、Azure ADテナンシへのOracle Databaseインスタンスの登録と同様に、独自のクライアント・アプリケーション登録を作成します。
   • データベースのグローバル・スキーマにマップされています。
3. Oracle Databaseクライアント・リリース19cの最新リリース更新を使用していることを確認します。
   この構成は、Oracle Databaseクライアント・リリース19.16以上でのみ機能します。Oracle Databaseリリース21cクライアントは、すべての機能範囲をサポートしていません。
4. ExaDB-Dデータベース・サーバーとのTLS接続を使用するようにデータベース・サーバーおよびクライアントを構成します。
5. クライアントのsqlnet.oraファイルで次のパラメータを設定します:
   • パラメータSSL_SERVER_DN_MATCH = ONをチェックして、DN一致が有効であることを確認します。
   • TOKEN_AUTHパラメータを設定して、クライアントがAzure ADトークンを使用できるようにします。トークンの場所を指すTOKEN_LOCATIONパラメータを含めます。例:

     TOKEN_AUTH=OAUTH 
     TOKEN_LOCATION="token_location" 

     デフォルトの場所がないことに注意してください。トークンがtokenという名前の場合は、ファイル・ディレクトリ(/test/oracle/aad-tokenなど)を指定するだけです。トークン名がtokenと異なる場合(azure.tokenなど)、その名前をパスに含める必要があります(/test/oracle/aad-token/azure.tokenなど)。

(description= 
  (retry_count=20)(retry_delay=3)
  (address=(protocol=tcps)(port=1522)
  (host=example.us-phoenix-1.oraclecloud.com))
  (connect_data=(service_name=aaabbbccc_exampledb_high.example.oraclecloud.com))
  (security=(ssl_server_cert_dn="CN=example.uscom-east-1.oraclecloud.com, 
     OU=Oracle BMCS US, O=Example Corporation, 
     L=Redwood City, ST=California, C=US")
  (TOKEN_AUTH=OAUTH)(TOKEN_LOCATION="/test/oracle/aad-token"))

connect /@exampledb_high

connect /@(description= 
  (retry_count=20)(retry_delay=3)
  (address=(protocol=tcps)(port=1522)
  (host=example.us-phoenix-1.oraclecloud.com))
  (connect_data=(service_name=aaabbbccc_exampledb_high.example.oraclecloud.com))
  (security=(ssl_server_cert_dn="CN=example.uscom-east-1.oraclecloud.com, 
     OU=Oracle BMCS US, O=Example Corporation, 
     L=Redwood City, ST=California, C=US") (TOKEN_AUTH=OAUTH)(TOKEN_LOCATION="/test/oracle/aad-token")

2つのレベルのトレース・ファイルを生成して、クライアント側でのMicrosoft Azure AD接続をトラブルシューティングできます。

生成できるトレース・ファイルには、次の2つのレベルがあります:

• 低レベル・トレースでは、次のような障害の発生時にトレースが出力されます:
  • TCPSがAzure AD接続用に設定されていない場合、プロトコルがTCPSである必要があるというメッセージが出力されます。
  • SSL_SERVER_DN_MATCHがTRUEに設定されていない場合、値がFALSEであるというメッセージが出力されます。
  • TOKEN_LOCATIONが指定されていない場合、トークンの場所が存在しないというメッセージが出力されます。
  • 指定されたTOKEN_LOCATIONにトークンが存在しない場合、メッセージが出力されます。
  • アプリケーションがOCI_ATTR_TOKEN_ISBEARERをTRUEに設定せずにトークンを渡した場合、欠落している属性に関するメッセージが出力されます。
  • アプリケーションがOCI_ATTR_TOKEN_ISBEARERをTRUEに設定してトークンを渡さない場合、欠落している属性に関するメッセージが出力されます。
  • トークンが期限切れの場合、メッセージが出力されます。
• 高レベル・トレースでは、前述のような障害の発生時にトレースが出力されます。さらに、次のような成功時にトレースが出力されます:
  • SSL_SERVER_DN_MATCHが存在する場所(tnsnames.oraまたはsqlnet.ora)が出力されます。また、TRUEに設定されている場合は、TRUEの値も出力されます。
  • トークンとOCI_ATTR_TOKEN_ISBEARER=trueの両方がアプリケーションによって設定されている場合、メッセージが出力されます。
  • TOKEN_AUTHに正しい値OAUTHが含まれる場合、その値が出力されます。
  • トークンの期限が切れていない場合、メッセージが出力されます。

クライアント側のsqlnet.oraファイルにEVENT設定を追加して、クライアント・トレースを制御できます。

• 次の方法のいずれかを使用します:
  • 次の設定をクライアント側のsqlnet.oraファイルに追加します:
    • EVENT_25701=14 (低レベル・トレースの場合)
    • EVENT_25701=15 (高レベル・トレースの場合)
  • 環境変数EVENT_25701を設定します:
    • EVENT_25701=14 (低レベル・トレースの場合)
    • EVENT_25701=15 (高レベル・トレースの場合)
  次の場所にクライアント・トレース・ファイルが作成されます:

  • Linux: $ORACLE_HOME/log/diag/clients
  • Windows: %ORACLE_HOME%\log\diag\clients

  クライアント側のsqlnet.oraのADR_BASEパラメータを使用して、トレース・メッセージが格納されるディレクトリを指定できます。ディレクトリ・パスが有効で、書込み権限があることを確認します。DIAG_ADR_ENABLEDパラメータがFALSEに設定されていないことを確認します。

  ADR_BASEの設定例は次のとおりです:

  ADR_BASE=/oracle/oauth2/trace