Oracle Cloud Infrastructureドキュメント

Oracle Exadata Database Service on Dedicated InfrastructureでのOracle DatabasesのMicrosoft Entra ID (MS-EI)ユーザーの認証および認可

Oracle Databaseは、Microsoft Entra IDのMicrosoft Azureユーザーがシングル・サインオン認証を使用して接続するように構成できます。

親トピック: ハウツー・ガイド

Oracle Exadata Database Service on Dedicated InfrastructureでのOracle DatabasesのMicrosoft Entra ID (MS-EI)ユーザーの認可について

Oracle Exadata Database Service on Dedicated Infrastructureのユーザーは、MS-EIサービスで集中管理できます。

Oracle DatabaseとMS-EIの統合は、オンプレミス・データベースおよびほとんどのOracle OCI DBaaSプラットフォームでサポートされています。

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

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

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

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

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

  • 多要素認証の有無にかかわらず、MS-EI認証画面へのMS-EI資格証明の入力

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

  • 対話型フロー(認可コード)。ブラウザを使用してユーザーの資格証明を入力できる場合に使用されます
  • クライアント資格証明。これは、エンドユーザーではなく自身で接続するアプリケーション用です
  • On-Behalf-Of (OBO)。ログイン・ユーザーのかわりにアプリケーションがアクセス・トークンをリクエストして、データベースに送信します
  • ROPCは、テストおよび開発環境でもサポートされています。

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

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

Oracle Database for Microsoft Entra ID (MS-EI)統合の構成

MS-EIとOracle Databaseインスタンスとの統合では、データベースがMS-EI公開キーをリクエストできるように、データベースをMS-EIに登録する必要があります。

MS-EIの構成、データベースの構成およびデータベース・クライアントの構成の詳細は、次を参照してください。

親トピック: Oracle Exadata Database Service on Dedicated InfrastructureでのOracle DatabasesのMicrosoft Entra ID (MS-EI)ユーザーの認証および認可

Microsoft Entra ID (MS-EI)認証の前提条件

Oracle DatabaseをMS-EIと統合するための前提条件を確認します。

Oracle Exadata Database Service on Dedicated Infrastructure上のOracle DatabaseとのMS-EI統合には、次のものが必要です。

  1. バージョン19.18以上のOracle Database。
  2. TLSポート2484のデータベースへの接続。TLS以外の接続はサポートされていません。
  3. データベースがMS-EI公開キーをリクエストできるように、MS-EIへのアウトバウンド・ネットワーク接続。
  4. MS-EIに登録するOracle Database。
  5. MS-EIトークンをリクエストする必要があるユーザーとアプリケーションは、MS-EIへのネットワーク接続も可能である必要があります。接続用のプロキシ設定を構成する必要がある場合があります。
  6. Oracle Exadata Database Service on Dedicated Infrastructureデプロイメントの場合、環境のHTTPプロキシ設定で、データベースでMS-EIを使用できるようにする必要があります。

    これらの設定は、クラウドExadataインフラストラクチャ・リソースを作成するにはの説明に従って、Oracle Exadata Database Service on Dedicated Infrastructureインフラストラクチャの作成時にフリート管理者が定義します。

    ノート

    HTTPプロキシを含むネットワーク構成を編集できるのは、Exadataインフラストラクチャが「アクティブ化が必要」状態になるまでです。いったんアクティブ化すると、それらの設定は編集できません。

    すでにプロビジョニングされているExadataインフラストラクチャのHTTPプロキシを設定するには、My Oracle Supportでサービス・リクエスト(SR)が必要です。詳細は、My Oracle Supportでのサービス・リクエストの作成を参照してください。

Microsoft Entra ID (MS-EI)認証のネットワークの前提条件

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. そのようなルールが存在しない場合は、「エグレス・ルールの追加」をクリックし、これらの特性を持つエグレス・ルールを追加します。

Microsoft Entra ID (MS-EI)トークンを使用するためのTLSの構成

データベース・クライアントからデータベース・サーバーにMS-EIトークンを送信する場合は、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を構成する方法の詳細は、次を参照してください:

自己署名証明書の使用およびウォレット関連の追加タスクを選択する場合は、次を参照してください: