Oracle Database用のMicrosoft Azure Active Directoryユーザーの認証および認可
Oracle Databaseインスタンスは、Microsoft Azure ADユーザーがAzure OAuth2
アクセス・トークンを使用して接続するように構成できます。
- Oracle Database用のMicrosoft Azure ADユーザーの認可の概要
Oracle Database用のMicrosoft Azure ADユーザーの認証および認可を開始する前に、そのプロセス全体を理解する必要があります。 - Microsoft Azure AD統合のためのOracle Databaseの構成
Microsoft Azure ADとOracle Databaseインスタンスを統合するには、データベースがAzure AD公開キーをリクエストできるように、データベースをAzure ADに登録する必要があります。 - Oracle Databaseスキーマおよびロールのマッピング
Azure ADユーザーは、1つのデータベース・スキーマにマップされ、オプションで1つ以上のデータベース・ロールにマップされます。 - Oracle DatabaseへのAzure ADクライアント接続の構成
Azure ADの登録済データベースに接続するようにクライアント接続を構成できます - Azure ADを使用したOracle Databaseクライアント接続のトラブルシューティングのためのトレース・ファイル
トレース・ファイルを使用して、Azure AD接続を使用したOracle Databaseクライアント接続をトラブルシューティングできます。
親トピック: ハウツー・ガイド
Oracle Database用のMicrosoft Azure ADユーザーの認可の概要
Oracle Database用のMicrosoft Azure ADユーザーの認証および認可を開始する前に、そのプロセス全体を理解する必要があります。
- Oracle Exadata Database Service on Dedicated Infrastructure用のMicrosoft Azure ADユーザーの認可について
Oracle Exadata Database Service on Dedicated Infrastructureのユーザーは、Microsoft Azure Active Directory (Azure AD)サービスで一元管理できます。 - Oracle DatabaseスキーマおよびロールへのAzure ADユーザーのマッピング
Oracle Databaseインスタンスに対して認証できるようにするには、Microsoft AzureユーザーをOracle Databaseスキーマにマップし、(ロールを介して)必要な権限を付与する必要があります。 - Azure ADを使用したOracle Databaseへの接続のユース・ケース
Oracle Databaseでは、Microsoft Azure Active Directoryを使用してOracle Databaseインスタンスに接続するための4つのタイプのユース・ケースをサポートしています。 - Microsoft Azure ADとOracle Exadata Database Service on Dedicated Infrastructureの統合の一般的なプロセス
Oracle管理者とMicrosoft Azure管理者の両方が、Oracle Exadata Database Service on Dedicated InfrastructureとMicrosoft Azure AD間の接続を構成する役割を果たします。
Oracle Exadata Database Service on Dedicated Infrastructure用のMicrosoft Azure ADユーザーの認可について
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テナンシにゲスト・ユーザーとして登録されています
- サービス。これは、クライアント資格証明フローを使用してデータベースに自身で接続する登録されたアプリケーションです(接続プールのユース・ケース)
Oracle Databaseスキーマおよびロールへの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グローバル・スキーマ(ユーザー)またはグローバル・ロールにマップされます。
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 ADOAuth2
アクセス・トークンを直接リクエストし、それをデータベース・クライアントAPIを介して渡すこともできます。Microsoft Azureの記事のサービス・プリンシパルを使用したAzure ADトークンの取得を参照してください。 - On-Behalf-Of (OBO)トークンを使用した接続: Azureアプリケーションは、ログイン・ユーザーのOBOトークンをリクエストします。OBOトークンは、Azure ADユーザー・アイデンティティを持つデータベースと、データベースに割り当てられたアプリケーション・ロールのアクセス・トークンでもあります。これにより、Azure ADユーザーは、アプリケーションではなくユーザーとしてデータベースにログインできます。アプリケーションのみが、Azure ADユーザーのOBOトークンをリクエストし、APIを介してデータベース・クライアントに渡すことができます。
Microsoft Azure ADとOracle Exadata Database Service on Dedicated Infrastructureの統合の一般的なプロセス
Oracle管理者とMicrosoft Azure管理者の両方が、Oracle Exadata Database Service on Dedicated InfrastructureとMicrosoft Azure AD間の接続を構成する役割を果たします。
一般的なプロセスは次のとおりです:
- Oracle管理者は、Oracle Database環境がMicrosoft Azure AD統合の要件を満たしていることを確認します。Microsoft Azure AD統合のためのOracle Databaseの要件を参照してください。
- Oracle管理者は、データベース・インスタンスをMicrosoft Azure ADテナンシに登録し、Oracle Exadata Database Service on Dedicated InfrastructureとAzure ADエンドポイント間の接続を有効にします。
登録プロセスの一環として、Oracle管理者またはAzure管理者は、Oracle DatabaseとMicrosoft Azureエンドポイント間のマッピングに使用するAzureアプリケーション・ロールを作成または指定します。
- Oracle管理者は、グローバル・スキーマを作成して、Azure ADユーザー(排他スキーマ・マッピング)またはAzureアプリケーション・ロール(共有スキーマ・マッピング)にマップします。Azure ADユーザーまたはアプリケーションを1つのスキーマにマップする必要があります。
- オプションで、Oracle管理者はグローバルOracle Databaseロールを作成し、Azureアプリケーション・ロールにマップします。
- Oracle Exadata Database Service on Dedicated Infrastructureインスタンスに接続するAzure ADエンド・ユーザーは、クライアント・アプリケーションをAzure ADクライアントとして登録します(Oracle Databaseの登録方法と同様)。
Azure ADクライアントは、アプリケーション・クライアントがパブリックでないかぎり、クライアント識別とクライアント・シークレットを持ちます。アプリケーション・クライアントがパブリックの場合、アプリケーション・クライアント識別のみが必要です。
- Azure ADエンド・ユーザー(データベース管理者でも可能)は、PowerShellやAzureコマンドライン・インタフェースなどのユーティリティを使用して接続し、トークンを取得してローカル・ファイル・ディレクトリに格納します。アプリケーションは、Azure ADのAzure AD
OAuth2
アクセス・トークンを直接リクエストし、それをデータベース・クライアントAPIを介して渡すこともできます。Azure ADOAuth2
トークンの受渡しの詳細は、次のOracle Databaseクライアントのドキュメントを参照してください:- JDBCシン・クライアント: 『Oracle Database JDBC開発者ガイド』
- Oracle Call Interface (OCI): 『Oracle Call Interface開発者ガイド』
- Oracle Data Provider for .NET (ODP): 『Oracle Data Provider for .NET開発者ガイド』のOracle Databaseへの接続に関する項
- Oracle Exadata Database Service on Dedicated Infrastructureインスタンスに接続したら、Azure ADエンド・ユーザーは必要に応じてタスクを実行します。
Microsoft Azure AD統合のためのOracle Databaseの構成
Microsoft Azure ADとOracle Databaseインスタンスを統合するには、データベースがAzure AD公開キーをリクエストできるように、データベースをAzure ADに登録する必要があります。
- Azure AD認証の前提条件
Exadata Cloud InfrastructureのデータベースでAzure AD認証を使用する前に、ネットワーキング・サービスを使用して、データベース・リソースが存在する仮想クラウド・ネットワーク(VCN)およびサブネットにサービス・ゲートウェイ、ルート・ルールおよびエグレス・セキュリティ・ルールを追加する必要があります。 - Azure ADトークンを使用するためのTLSの構成
Azure ADトークンをデータベース・クライアントからデータベース・サーバーに送信する場合、TLS接続を確立する必要があります。ExaDB-Dサービス・インスタンスのデータベース証明書を含むTLSウォレットは、WALLET_ROOT
の場所に格納する必要があります。WALLET_ROOT/<PDB GUID>/tls
のようにtls
ディレクトリを作成します。 - Microsoft Azure AD統合のためのOracle Databaseの要件
Microsoft Azure ADを使用してOracle Databaseインスタンスを構成する前に、現在の環境が特別な要件を満たしていることを確認する必要があります。 - Microsoft Azure ADテナンシへのOracle Databaseインスタンスの登録
管理者権限を持つユーザーは、Microsoft Azure ADを使用して、Oracle DatabaseインスタンスをMicrosoft Azure ADテナンシに登録します。 - Microsoft Entra ID v2アクセス・トークンの有効化
Microsoft Entra ID v2アクセス・トークンを有効にするには、Azureポータルのupn
属性を使用するように構成する必要があります。 - Azureエンドポイントのアクセシビリティのテスト
Oracle DatabaseインスタンスがAzure ADエンドポイントにアクセスできることを確認する必要があります。 - Microsoft Entra IDでのアプリケーション・ロールの管理
Entra IDでは、Azureユーザーおよびグループに割り当てられ、Oracle Databaseのグローバル・スキーマおよびロールにもマップされるアプリケーション・ロールを作成および管理できます。 - Oracle DatabaseのAzure AD外部認証の有効化
Oracle DatabaseでMicrosoft Azure AD外部認証を有効にできます。 - Oracle DatabaseのAzure AD外部認証の無効化
Oracle DatabaseインスタンスのAzure AD外部認証を無効にするには、ALTER SYSTEM
文を使用してパラメータを設定する必要があります。
Azure AD認証の前提条件
Exadata Cloud InfrastructureのデータベースでAzure AD認証を使用する前に、ネットワーキング・サービスを使用して、データベース・リソースが存在する仮想クラウド・ネットワーク(VCN)およびサブネットにサービス・ゲートウェイ、ルート・ルールおよびエグレス・セキュリティ・ルールを追加する必要があります。
- OCIドキュメントのタスク1: サービス・ゲートウェイの作成の手順に従って、データベース・リソースが存在するVCN内にサービス・ゲートウェイを作成します。
- サービス・ゲートウェイを作成したら、データベース・リソースが存在する各サブネット(VCN内)にルート・ルールおよびエグレス・セキュリティ・ルールを追加して、これらのリソースがゲートウェイを使用してAzure AD認証を使用できるようにします:
- サブネットの「サブネットの詳細」ページに移動します。
- 「サブネット情報」タブで、サブネットの「ルート表」の名前をクリックして、その「ルート表の詳細」ページを表示します。
- 既存のルート・ルールの表で、次の特性を持つルールがすでに存在するかどうかを確認します:
- 宛先: 0.0.0.0/0
- ターゲット・タイプ: NATゲートウェイ
- ターゲット: VCN内に作成したNATゲートウェイの名前
そのようなルールが存在しない場合は、「ルート・ルールの追加」をクリックし、これらの特性を持つルート・ルールを追加します。
- サブネットの「サブネットの詳細」ページに戻ります。
- サブネットの「セキュリティ・リスト」表で、サブネットのセキュリティ・リストの名前をクリックして、その「セキュリティ・リストの詳細」ページを表示します。
- サイド・メニューの「リソース」で、「エグレス・ルール」をクリックします。
- 既存のエグレス・ルールの表で、次の特性を持つルールがすでに存在するかどうかを確認します:
- 宛先タイプ: CIDR
- 宛先: 0.0.0.0/0
- IPプロトコル: TCP
- ソース・ポート範囲: 443
- 宛先ポート範囲: すべて
- そのようなルールが存在しない場合は、「エグレス・ルールの追加」をクリックし、これらの特性を持つエグレス・ルールを追加します。
Azure ADトークンを使用するためのTLSの構成
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の要件
Microsoft Azure ADを使用してOracle Databaseインスタンスを構成する前に、現在の環境が特別な要件を満たしていることを確認する必要があります。
- バージョン19.17以上のExaCSデータベース。
- TLSを使用したデータベースへの接続。TLS以外の接続はサポートされていません。
- データベースによるAzure AD公開キーのリクエストを可能にするAzure ADへのアウトバウンド・ネットワーク接続。
- Azure ADに登録するExaDB-Dデータベース。
次に注意してください:
- 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を使用して、Oracle DatabaseインスタンスをMicrosoft Azure ADテナンシに登録します。
Microsoft Entra ID v2アクセス・トークンの有効化
Microsoft Entra ID v2アクセス・トークンを有効にするには、Azureポータルのupn
属性を使用するように構成する必要があります。
- 使用しているEntra IDアクセス・トークンのバージョンを確認します。
- Microsoft Entra IDポータルにログインします。
- 「Entra ID」を検索して選択します。
- 「Manage」で、「アプリケーション登録」を選択します。
- シナリオおよび目的の結果に基づいてオプションの要求を構成するアプリケーションを選択します。
- 「Manage」で、「Token構成」を選択します。
- 「Add optional claim」をクリックし、「upn」を選択します。
- Entra IDアクセス・トークンのバージョンの確認
JSON WebトークンのWebサイトを使用すると、サイトで使用されているEntra IDアクセス・トークンのバージョンを確認できます。
関連トピック
Entra IDアクセス・トークン・バージョンの確認
JSON WebトークンのWebサイトを使用すると、サイトで使用されているEntra IDアクセス・トークンのバージョンを確認できます。
Azureエンドポイントのアクセシビリティのテスト
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)
- 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; /
- テストを再度実行します。
- 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; /
- ACLを次のように設定します。
データベースがAzure ADエンドポイントに接続できない場合、ACLポリシーを設定した後でも、ほとんどの場合、データベースのHTTP_PROXY
パッケージを設定する必要があります。デフォルトのOracle Database環境またはOracle Real Application Clusters RAC環境を使用しているかどうかに応じて、「関連トピック」にリストされているトピックを確認します。ネットワーク管理者は、正しいHTTP_PROXY
設定を通知できる必要があります。
Microsoft Entra IDでのアプリケーション・ロールの管理
Entra IDでは、Azureユーザーおよびグループに割り当てられ、Oracle Databaseのグローバル・スキーマおよびロールにもマップされるアプリケーション・ロールを作成および管理できます。
- Microsoft Azure ADアプリケーション・ロールの作成
Azure ADのユーザー、グループおよびアプリケーションがアプリケーション・ロールに割り当てられます。 - Microsoft Azure ADアプリケーション・ロールへのユーザーおよびグループの割当て
Microsoft Azure ADユーザーがOracle Databaseインスタンスにアクセスできるようにするには、最初にユーザーをOracle Databaseスキーマのユーザーまたはロールにマップされるアプリケーション・ロールに割り当てる必要があります。 - アプリケーション・ロールへのアプリケーションの割当て
Azure ADクライアント・アプリケーションをアプリケーション・ロールに割り当てることができます。
Microsoft Azure ADアプリケーション・ロールの作成
Azure ADのユーザー、グループおよびアプリケーションがアプリケーション・ロールに割り当てられます。
Microsoft Azure ADアプリケーション・ロールへのユーザーおよびグループの割当て
Microsoft Azure ADユーザーがOracle Databaseインスタンスにアクセスできるようにするには、最初にユーザーをOracle Databaseスキーマのユーザーまたはロールにマップされるアプリケーション・ロールに割り当てる必要があります。
- Azure ADのユーザーおよびグループをアプリケーション・ロールに割り当てる権限を持つ管理者としてAzure ADにログインします。
- 「Enterprise applications」で、登録したOracle Databaseアプリケーションにアクセスします。
- 「Directory + subscription」フィルタを使用して、Oracle接続を含むAzure Active Directoryテナントを検索します。
- 「Azure Active Directory」を選択します。
- 「Manage」で、「Enterprise applications」を選択し、以前に登録したOracle Databaseアプリケーション名を選択します。
- 「Getting Started」で、「Assign users and groups」を選択します。
- 「Add user/group」を選択します。
- 「Add assignment」ウィンドウで、「Users and groups」を選択して、ユーザーおよびセキュリティ・グループのリストを表示します。
- このリストから、アプリケーション・ロールに追加するユーザーおよびグループを選択し、「Select」をクリックします。
- 「Add assignment」ウィンドウで、「Select a role」を選択して、作成したアプリケーション・ロールのリストを表示します。
- アプリケーション・ロールを選択し、「Select」を選択します。
- 「Assign」をクリックします。
Oracle Databaseスキーマおよびロールのマッピング
Azure ADユーザーは、1つのデータベース・スキーマにマップされ、オプションで1つ以上のデータベース・ロールにマップされます。
- Microsoft Azure ADユーザーへのOracle Databaseスキーマの排他的マッピング
Microsoft Azure ADユーザーにOracle Databaseスキーマを排他的にマップできます。 - アプリケーション・ロールへの共有Oracleスキーマのマッピング
このマッピングでは、Oracleスキーマがアプリケーション・ロールにマップされます。 - アプリケーション・ロールへのOracle Databaseグローバル・ロールのマッピング
Azureアプリケーション・ロールにマップされたOracle Databaseグローバル・ロールによって、Azureユーザーおよびアプリケーションには、ログイン・スキーマを介して付与されたもの以上の追加の権限およびロールが付与されます。
Microsoft Azure ADユーザーへのOracle Databaseスキーマの排他的マッピング
Microsoft Azure ADユーザーにOracle Databaseスキーマを排他的にマップできます。
Oracle DatabaseへのAzure ADクライアント接続の構成
Azure ADの登録済データベースに接続するようにクライアント接続を構成できます
- Azure ADへのクライアント接続の構成について
Azure ADトークンを使用してOracle Databaseインスタンスに接続するようにクライアントを構成するには、多数の方法があります。 - Azure AD接続でサポートされるクライアント・ドライバ
Oracle Databaseでは、Azure AD接続で複数のタイプのクライアント・ドライバがサポートされています。 - PowerShellでのOracle DatabaseへのSQL*Plusクライアント接続の操作フロー
Azureユーザー、Azure ADおよびOracle Databaseインスタンス間の接続は、これらのコンポーネント全体でのOAuth2
トークンの受渡しに依存します。 - Azure ADアプリケーション登録へのクライアントの登録
このタイプの登録は、Azure ADアプリケーション登録へのOracle Databaseの登録と同様です。 - Azure AD OAuth2トークンの取得の例
これらの例は、Azure ADOAuth2
トークンを取得できる様々な方法を示しています。 - Azure ADアクセス・トークン用のSQL*Plusの構成
Azure ADデータベース・アクセス・トークンを一定の場所から取得し、/
スラッシュ・ログインの使用時にそれを使用するようにSQL*Plusを構成する必要があります。
Azure ADへのクライアント接続の構成について
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のインストール
Azure AD接続でサポートされるクライアント・ドライバ
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互換性を持っています
PowerShellでのOracle DatabaseへのSQL*Plusクライアント接続の操作フロー
Azureユーザー、Azure ADおよびOracle Databaseインスタンス間の接続は、これらのコンポーネント全体でのOAuth2
トークンの受渡しに依存します。
この例は、パブリック・クライアントでのリソース所有者パスワード資格証明(ROPC)フローの使用を示しています。ROPCの詳細は、Microsoft Azureの記事のMicrosoft IDプラットフォームとOAuth 2.0リソース所有者のパスワード資格証明を参照してください。
図5-2 パブリック・クライアントでのROPC操作フロー
- Azureユーザーは、PowerShellでデータベースのAzure ADアクセス・トークンをリクエストし、返されたトークンはファイルの場所にある
token
というファイルに書き込まれます。 - Azureユーザーは、
/
スラッシュ・ログインを使用してデータベースに接続します。sqlnet.ora
またはtnsnames.ora
の接続文字列は、Azure ADOAuth2
トークンが必要であり、指定されたファイルの場所からそれを取得するようにインスタント・クライアントに指示します。アクセス・トークンがデータベースに送信されます。 - データベースは、(Azure AD公開キーを使用して)アクセス・トークンがAzure ADから取得されたことを検証し、トークンで追加の要求がないか確認します。
- データベースは、スキーマ・マッピング(排他または共有)を検出し、セッションを作成します。データベースは、Azureユーザーがアプリケーション・ロールを介して割り当てられているグローバル・ロールも付与します。
Azure ADアプリケーション登録へのクライアントの登録
このタイプの登録は、Azure ADアプリケーション登録へのOracle Databaseの登録と同様です。
- 機密およびパブリック・クライアントの登録
ユース・ケースに応じて、データベース・クライアントを機密またはパブリックとしてAzureに登録できます。 - Azure ADへのデータベース・クライアント・アプリケーションの登録
クライアント・アプリケーション登録の作成は、Microsoft Azure ADテナンシでのOracle Databaseインスタンスの作成と同様です。
機密およびパブリック・クライアントの登録
ユース・ケースに応じて、データベース・クライアントを機密またはパブリックとしてAzureに登録できます。
認証フローおよびアプリケーション・シナリオの詳細は、Microsoft Azureの記事の認証フローとアプリケーションのシナリオを参照してください。
機密クライアント・アプリケーションを登録するには、クライアントIDに加えて、クライアントにシークレットが必要です。機密クライアント・アプリケーションは、Azure ADリクエストを行うときにクライアントIDとシークレットの両方を使用します。ただし、企業では、すべてのSQL*PlusおよびSQLclユーザーがそれぞれ独自のシークレットを使用して個別のアプリケーション登録を作成することは実用的ではありません。また、組織内でシークレットを共有し始めると、シークレットはシークレットではなくなります。単にパブリック・クライアント・アプリケーションを作成する方がはるかに便利です。パブリック・クライアント・アプリケーションにはシークレットがなく、クライアントIDのみがあります。すべてのデータベース・ツール・ユーザーは、Azure ADに接続するときにパブリック・クライアントIDを使用してアクセス・トークンを取得できます。Azure ADユーザーは、引き続き独自のユーザー資格証明を使用してAzure ADに対して認証する必要があります。
Azure AD OAuth2トークンの取得の例
これらの例は、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を使用してアクセス・トークンを取得し、そのトークンをファイルに書き込む方法を示しています。
例: リソース所有者パスワード資格証明を使用してトークンを取得するためのPowerShellの使用
この例は、PowerShellにより、リソース所有者パスワード資格証明(ROPC)を使用してAzure ADアクセス・トークンを取得する方法を示しています。
OAuth2
アクセス・トークンを取得できます。この構成には、生成された値、またはAzure ADにOracle Databaseインスタンスを登録したときに指定した値が複数必要です。
OAuth2
アクセス・トークンが取得され、ファイルとして格納されます。次のステップでは、SQL*Plusクライアントがストア・アクセス・トークンを使用して、それをデータベースに送信できるようにします。
親トピック: Azure AD OAuth2トークンの取得の例
例: 認可フローを使用したMicrosoft Authentication LibraryでのPythonの使用
Microsoft Authentication Library (MSAL)によるこの例はPythonにあるため、PowerShellやLinuxなどの様々なプラットフォームで実行できます。
OAuth2
認可フローが必要です。認可フローにはAzure ADへの2回のラウンドトリップが必要なため、MSALを使用して処理するのが最適です。MSALでPythonスクリプトを使用する方法については、Microsoftの記事のMicrosoft Authentication Libraryを使用したAzure ADトークンの取得を参照してください。これらの手順はDatabricksサービス用ですが、そのスコープは、DatabricksスコープではなくデータベースのアプリケーションID URIおよびスコープに変更されます。
親トピック: Azure AD OAuth2トークンの取得の例
例: リソース所有者パスワード資格証明フローでのCurlの使用
この例は、Azure AD APIに対してcurl
コマンドを使用して、パブリックAzure ADクライアントでリソース所有者パスワード資格証明(ROPC)フローを使用する方法を示しています。
親トピック: Azure AD OAuth2トークンの取得の例
例: 認可フローを使用したAzure CLI
この例は、Azure CLIを使用してアクセス・トークンを取得し、そのトークンをファイルに書き込む方法を示しています。
親トピック: Azure AD OAuth2トークンの取得の例
Azure ADアクセス・トークン用のSQL*Plusの構成
Azure ADデータベース・アクセス・トークンを一定の場所から取得し、/
スラッシュ・ログインの使用時にそれを使用するようにSQL*Plusを構成する必要があります。
TOKEN_AUTH
およびTOKEN_LOCATION
パラメータは、tnsnames.ora
およびsqlnet.ora
で指定できます。tnsnames.ora
接続文字列のTOKEN_AUTH
およびTOKEN_LOCATION
値は、その接続のsqlnet.ora
設定より優先されます。例:
(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"))
接続文字列をTOKEN_AUTH
およびTOKEN_LOCATION
で更新した後、Azureユーザーは次のコマンドを実行してSQL*Plusを起動し、Oracle Databaseインスタンスにログインできます。接続記述子自体を含めることも、tnsnames.ora
ファイルの記述子の名前を使用することもできます。
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")
TOKEN_AUTH
はsqlnet.ora
ファイルまたは接続文字列のいずれかですでに設定されているため、データベース・クライアントはAzure OAuth2
トークンを取得するようにすでに構成されています。データベース・クライアントは、OAuth2
トークンを取得し、トークンをOracle Databaseインスタンスに送信します。
Azure ADを使用したOracle Databaseクライアント接続のトラブルシューティングのためのトレース・ファイル
トレース・ファイルを使用して、Azure AD接続を使用したOracle Databaseクライアント接続をトラブルシューティングできます。
- 接続のトラブルシューティングに使用されるトレース・ファイルについて
2つのレベルのトレース・ファイルを生成して、クライアント側でのMicrosoft Azure AD接続をトラブルシューティングできます。 - トークン認証のクライアント・トレースの設定
クライアント側のsqlnet.ora
ファイルにEVENT
設定を追加して、クライアント・トレースを制御できます。
接続のトラブルシューティングに使用されるトレース・ファイルについて
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
が含まれる場合、その値が出力されます。 - トークンの期限が切れていない場合、メッセージが出力されます。