この記事では、Oracle Database@Azure上の Exadata Database Service 用の Oracle Transparent Data Encryption (TDE) マスター暗号化キー (MEK) を格納および管理する方法について説明します。 Azure Key Vault (AKV) サービスの 3 つのレベルすべてを使用できます。
- AKV Standard
- AKV Premium
- AKV Managed HSM
この統合により、Oracle Database@Azureのお客様は、ソフトウェア ベースのキー ストレージからシングルテナント、FIPS 140-3 レベル 3 の検証済みハードウェア セキュリティ モジュールまで、さまざまな セキュリティ、 コンプライアンス、およびキー 管理 のニーズを満たすことができます。
[前提条件]
統合を開始する前に、次の前提条件が満たされていることを確認します。
Oracle Database@Azureプロビジョニング済み: Azure Virtual Network 内の委任されたサブネットにデプロイされた Exadata VM クラスターがあり、管理のために Oracle Cloud Infrastructure (OCI) コンソールにアクセスできます。
高度なネットワークを有効にする:まだ構成されていない場合は、 Oracle Database@Azureのネットワーク計画に従って高度なネットワーク機能が有効になっていることを確認します。 |Managed HSM と Azure Arc に必要な Private Link 接続を有効にする Microsoft Learn ガイド。
Azure Key Vault のプライベート接続: Azure Key Vault の DNS 構成を使用するプライベート エンドポイントは、Exadata によって構成され、到達可能です。 詳細については、 Key Vault と Azure Private Link の統合に関するページを参照してください。 |Microsoft Learn
NAT ゲートウェイ: Identity Connector セットアップが Microsoft Entra パブリック エンドポイントにアクセスするには、送信インターネット接続が必要です。 この接続は、Oracle デプロイと同じ VNET に存在しない場合は、Azure NAT ゲートウェイ、Azure Firewall、またはネットワーク仮想アプライアンス (NVA) を使用して、またはハブ/スポーク トポロジを使用している場合は共有ハブ内で実現できます。
Azure Arc のプライベート リンク スコープとプライベート エンドポイントの構成 (省略可能): Azure Arc エージェントのインストールに Private Link を使用する場合は、Azure Arc Private Link スコープとプライベート エンドポイントを構成し、Exadata から到達可能にする必要があります。 DNS も構成し、エンドポイントを Exadata から解決できる必要があります。
Azure サブスクリプションとアクセス許可: 十分な Azure アクセス許可があります。
- Key Vault が作成されるサブスクリプションまたはリソース グループの Azure ロール 所有者/共同作成者 (リソースを作成してロールを割り当てるため)。
- アクセス許可を管理するためのセキュリティ グループを作成する場合は、Microsoft Entra ID ユーザー管理者 (またはそれと同等)。
- Azure 全体管理者 は必要ありませんが、Arc 登録用の Microsoft Entra ID アクセス トークンを取得できる必要があります (手順 3 で説明)。
OCI 特権: Oracle Cloud Infrastructure (OCI) コンソールで、マルチクラウド統合を管理するアクセス許可があることを確認します。 Oracle では、OCI テナントで次のような IAM ポリシーが推奨されます。
- 任意のユーザーがテナントで oracle-db-azure-vaults を管理できるようにする
- where request.principal.type = 'cloudvmcluster'
この IAM ポリシーを使用すると、Exadata VM クラスター リソースで Key Vault の関連付けを管理できます。
注
クラウド管理者が既にこれを設定している可能性があります。それ以外の場合は、Azure Key Vault を使用するようにデータベースを構成する前に、OCI 管理者が追加する必要があります。
手順 1: Azure Key Vault を作成して準備する
Oracle データベース暗号化キーを保持するように Azure Key Vault を設定します。 適切な Key Vault とキーが既にある場合は使用できますが、この目的のために専用または適切にセキュリティ保護されていることを確認してください。
Azure Key Vault を作成する: Microsoft Azure portal または Azure CLI を使用できます。
- AKV Standard: Azure Key Vault CLI のクイック スタートに従う
- AKV Premium: Standard と同じですが、Premium SKU を選択します
- Managed HSM: Managed HSM のクイック スタートに従う
Key Vault のリージョンが、Oracle Exadata Database@Azureがデプロイされているリージョンと一致していることを確認します (パフォーマンスとコンプライアンスのため)。 Standard レベルまたは Premium レベルを選択できます (両方とも統合がサポートされます)。 Premium は HSM によってサポートされています。 専用 HSM クラスターが必要な場合は、Managed HSM を使用します (その場合は、上記のように作成コマンドが異なります。セキュリティで保護されたアクセスとアクセス制御を強化するために、ManPrivate エンドポイントが強く推奨されていることを覚えておいてください)。
コンテナーにキーを作成する: Oracle TDE では、コンテナーに暗号化キー (マスター暗号化キー) が存在する必要があります。 ここで少なくとも 1 つのキーを作成します。 Oracle では、この目的で RSA キーがサポートされています (2048 ビットが一般的です)。
または、特定の要件 (BYOK) がある場合はキーをインポートできますが、ほとんどの場合、Azure で新しい RSA キーを生成するのが最も簡単です。 キーが有効になっていることを確認し、キー名をメモします。 (Oracle は、後でデータベースをリンクするときに Azure 名でこのキーを参照します)。
キーを今すぐ作成する理由 コンテナーの登録時に、Oracle コントロール プレーンは、コンテナーに少なくとも 1 つのキーが存在することを確認します。 何も見つからない場合、コンテナーの登録は失敗します。 事前にキーを作成すると、その問題が回避されます。
(Managed HSM の場合):Managed HSM を選択した場合は、プロビジョニング後に HSM をアクティブ化し (まだない場合)、その中にキーを作成する必要があります。
az keyvault key create --hsm-name <HSM_Name> -n $KEY_NAME ...Managed HSM では、別のアクセス許可モデル (ローカル HSM ロール) が使用されることに注意してください。 次の手順では、ロールの割り当てについて説明します。
この時点で、Oracle TDE に使用されるマスター キーを使用して、Azure Key Vault (または HSM) を準備できました。 次の手順では、Oracle Exadata VM クラスターがこのコンテナーとキーに安全にアクセスできるようにアクセス許可を設定します。
手順 2: Key Vault アクセス用に Microsoft Entra ID アクセス許可を構成する
Oracle Exadata VM クラスターが、特にその VM の Azure Arc ID を使って、キー コンテナーにアクセスし、特権を過度に与えることなく、キー操作（キーのラップ解除、新しいキー バージョンの作成やローテーションなど）を実行できるようにします。 これは、Microsoft Entra ID Role-Based アクセス制御 (RBAC) を使用して実現できます。 一般的なアプローチは次のとおりです。
- Microsoft Entra ID でセキュリティ グループを作成します。
- Oracle VM クラスターが Arc 対応になった後 (次の手順) に、マシンのマネージド ID をこのグループに追加します。
- Key Vault ロールをグループに割り当てます。
これにより、複数のデータベース VM またはクラスターがある場合は、グループ メンバーシップとロールを使用してアクセスを管理できます。
Microsoft Entra ID セキュリティ グループを作成 します (省略可能、推奨)。
- Azure portal (Microsoft Entra ID ブレード > グループ > 新しいグループ) または CLI を使用してグループを作成できます。
$GROUP_OBJECT_ID を書き留めます。 現時点では、このグループは空のままです。 Arc コネクタのセットアップ後、[手順 3](#Step 3: Oracle Identity Connector のセットアップ) でメンバーを追加します。Arc コネクタへのアクセスに必要な ID は、そのプロセスで作成されます。
Azure Key Vault ロールの割り当て: Key Vault のセキュリティ プリンシパル (この場合はグループ) に 2 つのロールを割り当てます。
- Key Vault 暗号化責任者 – キーの管理 (キーの作成、削除、キー バージョンの一覧表示) と暗号化操作のパフォーマンス (ラップ解除/暗号化解除など) を許可します。
- Key Vault リーダー – Key Vault のプロパティの表示を許可します
Azure CLI を使用して、Key Vault スコープにこれらのロールを割り当てます。
注
RBAC の代わりに Key Vault アクセス ポリシーを使用する場合は、az keyvault set-policy を使用して、Entra ID プリンシパルが "nwrap キー" および "et key" 操作を実行できるようにします。 ただし、RBAC の方法は最新のアプローチであり、Oracle の文書化されたロールに沿っています。
- Managed HSM の場合:
- Azure RBAC では、異なるロール のセットが使用されます。 Oracle のガイダンスに従って、Managed HSM の場合は、HSM リソースに Azure RBAC 閲覧者ロールを割り当てる必要があります。 次に、HSM ローカル RBAC を使用して、"Managed HSM Crypto Officer" と "Managed HSM Crypto User" をプリンシパルに割り当てます。 これは、Azure portal の Managed HSM アクセス制御ページで行うことができます。 セキュリティ グループは、これらの割り当てにも使用できます。 少なくともプリンシパルが HSM 暗号化責任者として追加されていることを確認します。 Crypto Officer はローテーション用に新しいキー バージョンを生成でき、Crypto ユーザーはキーを使用できます。
手順 3: Oracle Identity Connector を設定する
Oracle Identity Connector を設定します。 これにより、Azure ID を使用して Azure サービス (Key Vault) との通信を許可するように Azure Arc エージェントが自動的に構成されます。
OCI コンソールを使用して Identity Connector を作成すると、クラスター内の各 VM が Azure サブスクリプションに Azure Arc 対応サーバーとして登録されます。 これにより、Key Vault アクセスに適用される Microsoft Entra ID (マネージド ID) の ID が VM に付与されます。
コネクタを作成する方法を次に示します。
Azure アクセス トークンを取得する: OCI コンソールは、Arc インストールを承認するための Azure アクセス トークンを要求します。 このトークンは、指定したサブスクリプション/リソース グループに Azure Arc マシンを登録するアクセス許可を持つ Azure アカウントを使用して取得する必要があります。 通常、リソース グループの所有者/共同作成者で十分です。
Azure CLI を使用する (適切なユーザーとしてログイン):
AZURE_TOKEN出力を保存します (長い JSON Web トークン文字列です)。 また、Azure テナント ID (GUID) も書き留めます。OCI コンソールには必要です。 サブスクリプション ID は Exadata VM クラスター情報から自動検出されますが、念の場合は注意してください。
セキュリティのヒント: アクセス トークンは機密性が高く、限られた期間有効です。 パスワードのように扱います。 接続を確立するために 1 回だけ使用されます。
OCI コンソールで Identity Connector を作成する:
OCI Console for Oracle Database@Azureにログインします。 Exadata VM クラスター リソースに移動します。 (メニュー: Oracle Database > 専用インフラストラクチャ上の Oracle Exadata Database Service > Exadata VM クラスター > クラスター名をクリックしてください。)
VM クラスターの詳細ページで、[マルチクラウド情報] セクションを見つけます。 Identity Connector フィールドが表示されます。これは、まだ設定されていない場合は "なし" と表示される可能性があります。
[コネクタの作成またはセットアップ] を選択します。 フォームが表示されます。
- コネクタ名、Exadata VM クラスター、Azure サブスクリプション ID、Azure リソース グループ名の各フィールドが自動入力されます。 これらは、Exadata がプロビジョニングされたときから発生します。Oracle は、使用した Azure サブスクリプションとリソース グループを認識します。
- Azure テナント ID を入力します。 上記のTENANT_ID値からコピーします。
- 取得したAZURE_TOKEN文字列であるアクセス トークンを入力します。
[詳細オプション] で、Arc にプライベート接続を使用する場合:
- Arc のプライベート リンクを設定するときに、Azure portal から作成した Azure Arc Private Link スコープ名を入力します。たとえば、 Microsoft.HybridCompute/privateLinkScopes 型のリソース名です。
- Microsoft のドキュメントに従って、プライベート リンクに必要な DNS またはネットワークが配置されていることを確認します。よりシンプルな NAT アプローチを使用している場合は、空白のままにしておくことができます。
[作成] をクリックして ID コネクタを作成します。
Oracle プラットフォームでは、トークンを使用して Arc エージェントを登録します。
- クラスター内の各データベース VM に Azure Arc エージェントがインストールされます。
- VM は Azure Arc に登録されます。Azure portal では、Azure Arc > サーバーで、指定したリソース グループの下に 2 つの新しい Azure Arc リソース (RAC に 2 つの DB ノードがある場合) がすぐに表示されます。 それぞれに VM の名前のような名前があります。
- Oracle のコンソールに Identity Connector の状態が表示されます。 Database Multicloud Integrations > Identity Connectors に移動して、コネクタが存在することを確認します。 [VM クラスター] ページで、[Identity Connector] フィールドに "None" ではなくコネクタ名が表示されます。
トラブルシューティングのヒント
コネクタの作成に失敗した場合は、トークン (有効期限が切れている可能性があります - 新しいものを生成する) とテナント ID を再確認します。 また、表示される Azure サブスクリプション ID とリソース グループが正しいことを確認します。 トークンを生成するユーザーには、Arc リソースを作成する権限が必要です。 Azure では、Arc エージェントのサービス プリンシパルが自動的に作成されます。 Azure リソース プロバイダー Microsoft.HybridCompute がサブスクリプションに登録されていることを確認します。
Microsoft Entra ID グループに Arc マシン ID を追加する: コネクタが起動すると、Exadata VM はそれぞれ Microsoft Entra ID のマネージド ID を持つようになりました。 これらの ID に Key Vault アクセス権を付与する必要があります ([手順 2](#Step 2: Key Vault アクセスの Microsoft Entra ID アクセス許可を構成する) で設定します。 セキュリティ グループを使用した場合:
- 新しい Arc サーバー ID のオブジェクト ID を検索します。 Azure portal で、エンタープライズ アプリケーションまたは Azure Arc リソース>エンティティ> Microsoft Entra ID ブレードに移動します。プリンシパル オブジェクト ID が一覧表示される場合があります。 簡単な方法: Azure CLI を使用して Azure Arc に接続されたマシンを一覧表示し、そのプリンシパル ID を取得します。
各 Arc マシンには、principalId を持つアイデンティティがあります。 また：
システム割り当て ID の principalId (オブジェクト ID) を持つ JSON が表示されます。
- 手順 2 で作成した Microsoft Entra ID グループのメンバーとして、各 Arc マシンの principalId を追加します。 これは、Microsoft Entra ID ポータル (グループ > メンバー > 追加) または CLI で行うことができます。
グループを使用しなかった場合は、代わりに、上記のような az role assignment create を使用して、VM のマネージド ID の各 principalId に Key Vault ロールを直接割り当てることができます。ただし、assignee-principal-type ServicePrincipal と principalId を使用します。 グループの使用は、複数のノードに対してよりクリーンです。
この時点で、Oracle VM クラスターは Arc 対応であり、その Azure ID には、グループ メンバーシップまたは直接割り当てによる Key Vault に対するアクセス許可が与えられます。 "プランギング" が整っています。データベース VM は NAT またはプライベート リンクを介して Azure Key Vault サービスエンドポイントに到達でき、Azure がキーアクセスを認識して認証するマネージド アイデンティティを持っています。
手順 4: VM クラスターで Azure Key Vault キー管理を有効にする
Exadata VM クラスター レベルで Key Vault 統合をアクティブ化します。 これにより、データベースでキーストアとして Azure Key Vault を使用できる必要な Oracle ライブラリ/プラグインがクラスター VM にインストールされます。
OCI コンソールで次の手順を実行します。
- コネクタを作成した Exadata VM クラスターの詳細ページに移動します。
- [マルチクラウド情報] セクションで、Azure キー ストアまたは Azure キー管理の状態を見つけます。 現在、"無効" と表示されます。
- Azure キー ストアの横にある [有効にする] を選択します。
- 表示されるダイアログでアクションを確認します ([有効] を選択します)。
このアクションにより、クラスター VM への Oracle ソフトウェア ライブラリのインストールがトリガーされます。 これは、Azure Key Vault とのインターフェイス方法を知っている Oracle の TDE ウォレット ソフトウェアの拡張機能である可能性があります。 1~ 2 分しかかかりません。 完了すると、OCI コンソールに Azure キー ストア (VM クラスターで有効) が表示されます。
これで、Azure Key Vault をサポートするようにクラスターが構成されました。 重要なことに：
- この設定はクラスター全体ですが、AKV を使用するようにデータベースを自動的に切り替えるわけではありません。 このオプションを使用できるようにします。 このクラスター上のデータベースでは、従来の Oracle ウォレットまたは Azure Key Vault をサイド バイ サイドで使用できます。 たとえば、AKV を有効にしてから、一度に 1 つのデータベースを移行できます。
- 何らかの理由で無効にする必要がある場合は、[無効にする] をクリックすると、ライブラリがアンインストールされます。 ただし、AKV をアクティブに使用しているデータベースがある場合は無効にしないでください。データベースのキーへのアクセスが失われるので、再度機能させるために再度有効にする必要があります。
この段階では、コア セットアップが完了しました。Azure 側は準備完了で、Oracle 側 (クラスター) の準備が整いました。 残りの手順では、実際の Oracle データベースを Key Vault キーに接続します。
手順 5: OCI に Azure Key Vault を登録する (必要に応じて省略可能)
目標: Azure Key Vault の存在について Oracle のシステムに通知し、使用できるように準備します。 多くの場合、これはデータベースのキー ストアを作成または切り替えるときに自動的に行われますが、特に複数のクラスターで同じコンテナーを使用する予定の場合は、明示的に行う方法を知ると便利です。
Oracle では、OCI コンソールで Azure Key Vault を登録できます。
Database Multicloud Integrations>Microsoft Azure Integration に移動します。
Azure Key Vault をクリックする
- [Azure キー ボールトの登録] をクリックします。 ダイアログで次の手順を実行します。
- Exadata VM クラスターがあるコンパートメントであるコンパートメントを選択します。
- 検出に使用する Identity Connector を選択します。 手順 3 で作成したコネクタを選択します。
- [検出] をクリックします。 システムは Arc コネクタを使用して Azure にクエリを実行し、そのコネクタからアクセスできるサブスクリプション/リソース グループ内の Key Vault を一覧表示する必要があります。 手順 1 で作成したボールトは、その名前で識別されて表示されるようになります。
- 一覧からコンテナーを選択し、[登録] をクリックします。
登録後:
- 保管庫は OCI に一覧表示されており、状態は「使用可能」である可能性があります。また、AKV や Managed HSM などの種類や、Azure リソース グループなどの詳細が含まれます。
- このコンテナーと検出に使用した Identity Connector の間に、既定の関連付けが自動的に作成されます。 これを表示するには、コンテナー名をクリックし、[ID コネクタの関連付け] をオンにします。
- 同じ Key Vault を使用する必要がある異なるコネクタを持つ複数の Exadata VM クラスターがある場合は、追加の関連付けを手動で作成する必要があります。[関連付けの作成] をクリックし、コンテナーを別の Identity Connector にリンクします。 このシナリオは高度です (たとえば、1 つの一元化されたボルトを使用する異なるリージョンにあるプライマリ クラスターとスタンバイ クラスターが、ネットワーク接続が適切であることを確認します)。
Oracle OCI は Azure Key Vault について認識し、クラスターのコネクタに関連付けられています。つまり、データベースで使用するパスが明確になります。
手順 6: Azure Key Vault を使用するように Oracle データベースを構成する
最後に、TDE キー ストレージに Azure Key Vault を使用するように Exadata VM クラスター上の 1 つ以上の Oracle データベースを構成する必要があります。 これを行うには、新しいデータベースのデータベースの作成時に、または既存のデータベースを Oracle ウォレットを使用して Azure Key Vault に移行します。
シナリオ A: Azure Key Vault を使用して新しいデータベースを作成する
OCI コンソールを使用して Exadata VM クラスターに新しい Oracle データベースをプロビジョニングする場合:
- [データベースの作成] ウィザードを起動します。 これは、データベースを格納するデータベース ホームがクラスターに少なくとも 1 つ存在することを前提としています。
- [キー管理] または [暗号化] のオプションがフォームに表示されます。 Oracle で管理されるウォレットではなく、ドロップダウンから Azure Key Vault を選択します。
- 次に、ボールトとキーを選択します。
- コンテナーが登録されたコンパートメントを選択します。
- そのコンテナーの名前を選択します。
- キーを選択します。 手順 1 で作成したキーは名前で表示されます。
- 他のデータベース作成パラメーター (DB 名、PDB 名、文字セットなど) を続行して送信します。
プロビジョニング プロセスは、選択したキーを Azure Key Vault からフェッチし、そのキーを使用して新しいデータベースの TDE を設定します。 データベースの作成が完了したら、OCI のデータベースの詳細ページに移動し、[暗号化] セクションまでスクロールできます。 キー管理 : Azure Key Vault が表示され、キー名またはその Azure 識別子、およびキーの OCI 内部識別子が表示されます。 これにより、新しいデータベースの TDE マスター暗号化キーが、ローカル ウォレットではなく Azure Key Vault に格納されていることが確認されます。
シナリオ B: 既存のデータベースを Azure Key Vault に移行する
現在 TDE キー用の既定の Oracle ウォレットを使用している VM クラスターで既に実行されている Oracle データベースの場合は、Azure Key Vault を使用するように切り替えることができます。
OCI コンソールの使用:
- VM クラスターのデータベースの一覧にある特定の [データベース リソース] ページに移動します。
- [データベース情報] タブで、[暗号化/ キー管理] セクションを見つけます。 まだ変更されていない場合は、現在 Oracle ウォレットを使用していることを示すはずです。
- [キー管理] フィールドの横にある [変更] リンクをクリックします。
- ダイアログまたはフォームが [キー管理の変更] に表示されます。 次を指定します。
- 新しいキー管理: Azure Key Vault を選択します。
- コンテナー コンパートメント。次に、コンテナーを選択します。
- キー コンパートメント (コンテナーと同じである可能性があります) を選択し、ドロップダウン リストからキーを選択します。
- [変更の保存] または [OK] をクリックして確定します。
Oracle はキーの移行を実行します。
- 選択した Azure Key Vault キーがデータベースに関連付けられます。
- バックグラウンドで、データベースは Arc コネクタと設定されたアクセス許可を使用して Azure キーを取得し、その TDE ウォレットを再暗号化します。 基本的に、ウォレットにあった現在の TDE マスター キーを受け取り、Azure Key Vault に安全に転送します。 または、新しいキーを選択した場合は、それを新しいマスター キーとして設定し、それを使用してデータ暗号化キーを再暗号化します。
- 通常、この操作には数秒かかります。 データベースをシャットダウンする必要はありません。 TDE マスター キー操作はオンラインで実行できます。 ただし、スイッチ中に、新しい暗号化/復号化操作が短時間一時停止される可能性があります。
完了したら、[データベース] ページを更新し、キー管理に Azure Key Vault が表示され、新しく作成された DB と同様にキー名/OCID が一覧表示されることを確認します。
Von Bedeutung
Azure Key Vault から Oracle Wallet への切り替えは、OCI コンソールまたは API ではサポートされていません。 Oracle は外部 KMS への移動を一方向として扱いますが、技術的には手動でキーをエクスポートし、必要に応じてウォレットに再インポートすることができます。 コンソールでは、AKV からローカル ウォレットへの変更は明示的に許可されていません。
プラグ可能データベース (PDB): CDB に TDE が有効な複数の PDB が含まれている場合、CDB のマスター キーが既定で使用されます。 Oracle 19c には、CDB ごとに 1 つの TDE マスター キーがあります。 Oracle 21c 以降では、PDB ごとのキーがサポートされています。 ただし、すべての PDB が設定を継承するため、通常は CDB レベルでのみキー管理を実行する必要があります。
個々の PDB に個別のキーを使用する場合は、PDB リソースごとにキー管理プロセスを繰り返す必要があります。 Oracle のインターフェイスには、PDB ごとのキー (該当する場合) が一覧表示されます。
これで、Oracle データベースは、すべての暗号化操作に Azure Key Vault のキーを使用しています。 次に、すべてが正常に動作していることを確認しましょう。
手順 7: 統合とセキュリティを確認する
Azure Key Vault を使用するように構成されたデータベースでは、すべてが機能し、セキュリティで保護されていることを確認することが重要です。
データベースの状態: Oracle データベースに接続し、暗号化されたデータの読み取りと書き込みができることを確認します。 通常、TDE が正しく構成されている場合、これはユーザーに対して透過的です。 ただし、データベースがキーにアクセスできない場合は、データベースを開こうとしたときにエラーが表示されます。たとえば、ORA-28374、"マスター キーで保護されていません" などです。 上記の手順に従っていると仮定すると、データベースは AKV キーを使用してシームレスに開く必要があります。
OCI コンソールの確認: OCI のデータベースの詳細ページで、キー ストアとして Azure Key Vault が表示され、キー名/OCID が一覧表示されたことを確認します。 これは、データベースがその外部キーに関連付けられていることを Oracle のコントロール プレーンが認識していることを示します。
Azure Key Vault の監視: Azure で、Key Vault に移動します。
- [キー] にキーが表示されます。 たとえば、OracleTDEMasterKey です。 関連付けからの変更だけが表示されない場合がありますが、Key Vault のログを確認できます。 Azure Key Vault の診断ログをまだ有効にしていない場合は有効にし、データベースが開かれたか、キーが設定された日時に対応する "キーの取得" または "キーの復号化/ラップ解除" イベントを確認します。 これにより、Oracle データベースが Azure のキーにアクセスしたことを確認できます。 Azure のログには、キーにアクセスしたプリンシパルが表示されます。これは Azure Arc マシンのマネージド ID であり、GUID によって識別可能である必要があります。これは Arc principalId と一致する必要があります。
- 次の手順でローテーションを実行すると、この一覧に新しいキー バージョンが表示されます。
キーを削除しないでください 。 これは繰り返し検討する価値があります。 データベースで使用されている Key Vault キーは削除しないでください。 Azure でキーを削除すると、データベースはデータの暗号化を解除する機能をすぐに失い、基本的にデータベースがブロックされます。 OCI コンソールでは、キー情報を確認すると、Oracle によって実際に警告が表示されます。 キーの使用を停止する必要がある場合は、古いキーを削除する前に、データベースを新しいキーに移行 (ローテーション) するのが適切な手順です。 Azure Key Vault では、キーのバージョン管理がサポートされています。 古いバージョンは、不要になるまで削除するのではなく、無効のままにすることができます。
テスト フェールオーバー/再起動: 運用セットアップの場合は、データベースの再起動をシミュレートして、起動時にキーを取得できることを確認します。 Oracle データベースをシャットダウンして起動します (または、必要に応じて VM クラスターを再起動します。RAC では、一度に 1 つのノードをバウンスします)。 データベースは手動で介入せずに開始し、プロセス内の AKV からキーをプルする必要があります。 正常に開始された場合、統合は確実です。 ウォレットを自動的に開けなければ、手順 2 (アクセス許可) と手順 3 (Arc 接続) を再確認してください。
これらの検証を完了することで、Oracle Exadata Database@Azure-Azure Key Vault の統合が機能し、データにアクセスしてセキュリティで保護された状態が維持されることを確信できます。
手順 8: 継続的な管理とベスト プラクティス
統合が整ったので、進行中の操作については次のことを検討してください。
キーのローテーション:
セキュリティ ポリシーに従って、TDE マスター キーを定期的にローテーションします。 たとえば、毎年、または数日後やイベントの後などです。 Azure で直接ではなく、常に Oracle 側 (OCI コンソールまたは API) からローテーションを実行します。
- OCI コンソールを使用してローテーションするには、[データベースの詳細] ページの [暗号化] セクションに移動し、[回転] をクリックします。 Key Vault が使用中の場合は、キー情報の横に表示されます。 回転を確認します。 これにより、Azure Key Vault に新しいキー バージョンが生成されます。 Azure のキーで新しいバージョンを確認し、新しいバージョンを使用するようにデータベースを更新できます。
OCI API/CLI を使用したローテーション: Oracle は、この目的のために API RotateVaultKey を提供します。 oci CLI を使用すると、oci db データベース rotate-vault-key --database-id <OCID> などのコマンドを使用して行うことができます (正確な構文については、Oracle の CLI ドキュメントを確認してください)。 これにより、同じ操作がトリガーされます。
Azure Key Vault のキー ローテーション ポリシーを使用してローテーションしたり、Oracle の関与なしに Azure で新しいバージョンを手動で作成したりしないでください。 Azure では新しいバージョンが作成されますが、Oracle のデータベースは認識されておらず、マスター キー識別子として格納されているため、古いバージョンを引き続き使用しようとしています。 常に、Azure と連携する Oracle 側から開始します。
キーローテーションのログを保持します。 Azure は新しいキー バージョンの作成をログに記録し、Oracle は新しいキーが使用中であることをログに記録します。 ローテーション後に問題が発生した場合は、Oracle を使用して以前のキー バージョンにロールバックするオプションがあります。 ただし、新しいキーが侵害されたと疑われる場合を除き、通常は必要ありません。
キー ライフサイクル管理: Azure でキーのライフサイクルを管理します。
- 保持: 古いキー バージョンをすぐに消去しないでください。 Oracle TDE では最新バージョンのみを使用できますが、古いバックアップやアーカイブ ログを開くには古いバージョンが必要になる場合があります。 古いキー バージョンは無効にしたまま、一定期間は回復可能にしておくことをお勧めします。
- バックアップ: Azure Key Vault (Standard/Premium) の場合、Microsoft は高可用性と復旧を管理します。 Managed HSM の場合、必要に応じて HSM をバックアップする必要があります。 該当する場合は、HSM バックアップに関する Azure のガイダンスに従ってください。
- 職務の分離: 通常、DBA は Oracle 側を処理し、セキュリティ管理者は Azure Key Vault 側を処理します。 Azure Key Vault アクセス ポリシー/RBAC を使用して、DBA がデータベース経由でキーを使用する以外にキーを改ざんできないようにし、逆に Microsoft Entra ID 管理者はデータベース データを直接読み取ることはできません。キーのみを管理します。 Key Vault にアクセスできるユーザーを定期的に監査します。
ディザスター リカバリー (DR):
- Managed HSM: Managed HSM ディザスター リカバリー ガイドに従います。 可用性を向上するには、 Azure Managed HSM でマルチリージョン レプリケーションを有効にします。
- Standard と Premium: ペアになっているリージョンに対して自動レプリケーションが有効になっています。 詳細については、「Azure Key Vault の可用性と冗長性」を参照してください。
2 つの Oracle Exadata Database@Azure VM クラスター間で DR 用 Oracle Data Guard を使用する場合は、DR サイトが同様に構成されていることを確認します (リージョン間データガード シナリオは現在サポートされていません)。
- DR Exadata VM クラスターでも手順 1 から 5 を実行します。 DR リージョンで 同じ Azure Key Vault を使用できます。
- プライマリとスタンバイの両方に同じ Key Vault を使用する場合は、前に説明したように、コンテナーを登録し、スタンバイの ID コネクタとの関連付けを作成します。
- スタンバイ データベースも AKV キーを使用するように構成されていることを確認します。 通常、AKV を使用しているプライマリにスタンバイを追加すると、スタンバイ クラスターでは、スタンバイを作成する前に ID コネクタとキー ストアが有効になっていることが想定されます。 そのため、コネクタを設定し、DR で Azure キー ストアを有効にしてから、Data Guard を設定します。 スタンバイが起動し、かつスタンバイが Key Vault に到達できる場合、プライマリのキー情報は Data Guard 経由でスタンバイに共有されます。 Oracle のドキュメントでは、これについて軽く言及しています。ギャップを避けるために、プライマリおよびスタンバイの両方が TDE を使用する場合、AKV が有効になっている必要があります。
- スイッチオーバーまたはフェールオーバーをテストして、スタンバイが Key Vault キーで個別に開くことができることを確認します。 これは重要な DR テストです。
修正プログラムの適用と更新:
Oracle は、Exadata インフラストラクチャと Arc エージェントの更新をマネージド サービスの一部として処理します。 Key Vault 統合機能の変更については、Oracle Cloud のお知らせに注目してください。 たとえば、新しくサポートされているリージョンや、必要なロールやサポートされているキーの種類の変更などです。 Oracle が ID コネクタやライブラリの更新などのアクションを必要とする更新プログラムを発行する場合は、それに応じてスケジュールします。
一般的な問題のトラブルシューティング
登録中に Key Vault が見つかりません: 少なくとも 1 つのキーを作成し、Arc ID にリスト/取得アクセス許可があることを確認します。 検出時に正しいコネクタとコンパートメントが選択されていることを確認します。
アクセス許可拒否エラー: データベースがキーの取得に失敗した場合。 たとえば、ORA-28417 "承認が拒否されました" など、Azure ロールの割り当てを確認します。 マネージド ID には、キーに対する Crypto Officer ロールまたは Crypto User ロールがない可能性があります。 RBAC またはアクセス ポリシーを修正してから、再試行します。 変更キー管理操作の再実行が必要になる場合があります。
Arc コネクタの問題: Arc 対応サーバーが切断済みと表示されている場合、データベースが Key Vault に到達しない可能性があります。 VM が login.microsoftonline.com と Key Vault エンドポイントに到達できることを確認します。 接続/DNS をテストするには、VM の curl または類似を使用します。 Private Link を使用している場合は、DNS 解決がプライベート エンドポイントの IP を指しているかどうかを確認します。 Oracle VM では、Arc エージェントの状態 (sudo systemctl status azauremeeting または同様のサービス) を確認することもできます。
コネクタのセットアップ中のトークンの有効期限: 手順 3 の Azure トークンは有効期間が短いです。 生成が早すぎて、フォームを時間内に送信しなかった場合は、期限切れになる可能性があります。 使用後数分以内に常に新しいトークンを使用します。
複数の Key Vault: たとえば、新しいコンテナーに移行する場合に、データベースを別の Key Vault に移動する必要がある場合、Oracle は現在、コンソールを使用して外部 KMS から別の KMS に直接変更することをサポートしていません。 1 つのコンテナーが、ローテーションを処理するキー バージョンを使用して長期的にその目的を果たすことができるようにアーキテクチャを計画します。
ベスト プラクティス
運用ワークロード: 運用環境レベルの Oracle Database@Azure環境では、AKV Premium または Managed HSM を強くお勧めします。 Azure Key Vault と Exadata VM クラスターは、同じテナントと同じリソース グループ内に存在する必要があります。 これは既知の問題であり、修正に取り組んでいます。
パフォーマンスとコンプライアンス: FIPS コンプライアンスのニーズ、キーの種類のサポート、およびセキュリティ分離の要件に基づいて、適切なレベルを選択します。
プライベート リンクの要件: Managed HSM の場合、セキュリティで保護されたアクセスには Private Link の統合が必須です。 Private Link 接続は、すべての Azure Key Vault と Oracle Database@Azure統合に推奨されます。
AES キーのサポート: Oracle Database@Azureのお客様は、可能な限り AES キーを使用することをお勧めします。 AES 形式で TDE MEK を管理するには、Managed HSM を使用する必要があります。
監視と監査: Azure 診断ログを有効にして、すべてのレベルのキー アクセスと使用状況イベントを監視します。
専用コンテナー: Oracle 環境ごとに専用の Key Vault または専用キーを使用します。 異なるデータベースに同じキーを再利用しないでください。各 CDB には独自の TDE マスター キーが必要です。 Oracle では、これを適用します。 1 つのコンテナー (DB ごとに 1 つ) に複数のキーを保持できます。これは問題ありません。
最後に、この統合によって 2 つのクラウド サービスがブリッジされるので、Oracle と Microsoft とのサポート 契約が確実に整っていることを忘れないでください。 どのような問題でも、共同サポートの利点があります。両方の企業は、このセットアップを実行しているお客様を支援するパートナーシップを結んでいます。 Oracle のサポート ドキュメントと Azure のドキュメントを参照して、既知の問題のトラブルシューティングを行うことができます。
リファレンス
Azure Key Vault の概要について説明します
Managed HSM のドキュメントについて説明します