機械翻訳について
  1. Exadata Database Service on Dedicated Infrastructure
  2. How-toガイド
  3. Oracle Exadata Database Service on Dedicated InfrastructureでのOracle DatabasesのMicrosoft Entra ID (MS-EI)ユーザーの認証および認可

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

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

親トピック: How-toガイド

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

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

MS-EIとのOracle Database統合は、オンプレミス・データベースおよびほとんどの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インスタンスに渡すことができます。 SQL*Plusなどの既存のデータベース・ツールを構成して、ファイルのロケーションからMS-EIトークンを使用するか、MS-EIから直接トークンを取得できます。 ユーティリティを使用してトークンを取得し、ファイルのロケーションを介してデータベース・クライアント・ドライバに渡す場合、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 Exadata Database Service on Dedicated InfrastructureでのOracle DatabasesのMicrosoft Entra ID (MS-EI)ユーザーの認証および認可

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

Oracle DatabaseインスタンスとのMS-EI統合では、データベースが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 Infrastructureが「アクティブ化が必要」状態になるまで編集できません。 アクティブ化した後は、これらの設定を編集できません。

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

関連トピック

親トピック: Microsoft Entra ID (MS-EI)統合のためのOracle Databaseの構成

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

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

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

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

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

関連トピック

親トピック: Microsoft Entra ID (MS-EI)統合のためのOracle Databaseの構成

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

データベース・クライアントからデータベース・サーバーにMS-EIトークンを送信する場合は、TLS接続を確立する必要があります。

ExaDB-Dサービス・インスタンスのデータベース証明書を含むTLSウォレットは、WALLET_ROOTのロケーションに格納する必要があります。 tlsディレクトリを作成: WALLET_ROOT/<PDB GUID>/tls.

データベース・クライアントとサーバー間のTLSを構成する場合、考慮すべきオプションがいくつかあります。

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

自己署名証明書

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

既知の認証局

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

一方向TLS

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

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

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

Walletを使用するクライアント

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

Walletを使用しないクライアント

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

データベース・クライアントとデータベース・サーバー間のTLSを構成する方法(前述のオプションを含む)の詳細は、次を参照してください:

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

親トピック: Microsoft Entra ID (MS-EI)統合のためのOracle Databaseの構成