8
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@shirok(Shiro Kobayashi)
in

OpenAI APIキーをOCI VaultとResource PrincipalでセキュアにしてSelect AIしてみてみた

8
Last updated at Posted at 2026-09-23

OCI Vault仕組み.jpg

以前、Autonomous AI DatabaseのSelect AIからOpenAI APIを呼び出し、自然言語でデータベースへ問い合わせてみました。

前回は、OpenAI APIを使ってSelect AIを「動かす」ところまでを確認しました。

実際に動かしたあとで、次に気になったのが、OpenAI APIキーをどこへ置き、どのように運用するかです。

既存の構成では、OpenAI APIキーをDBMS_CLOUD.CREATE_CREDENTIALのpasswordへ指定しています。

BEGIN
    DBMS_CLOUD.CREATE_CREDENTIAL(
        credential_name => 'OPENAI_CRED',
        username        => 'OPENAI',
        password        => '<OpenAI APIキー>'
    );
END;
/

作成されたCredentialはデータベース内へ暗号化形式で保存されます。

ただし、登録するときにはOpenAI APIキーそのものをSQLへ記述するため、次のような場所へ残らないように注意が必要です。

  • SQLスクリプト
  • SQLclやシェルの履歴
  • SQL Worksheetの実行履歴
  • ログ
  • Gitリポジトリ
  • Blog用のスクリーンショット

Select AIが動くところまで確認できても、APIキーがSQLやスクリプトに残る構成では、継続的な運用へ持っていきにくくなります。

以前、OCI Generative AIを利用したときは、Resource Principalを使用することで、OCIユーザーのAPI署名鍵をデータベースへ登録せずにSelect AIを実行できました。

一方で、OpenAI APIはOCI IAMのResource Principalでは直接認証できません。OpenAI APIキーそのものは引き続き必要です。

大事なのは、APIキーをなくすことではなく、APIキーを安全な場所へ分離し、必要な権限を持つAutonomous AI Databaseだけが参照できる構成にすることでした。

そこで今回は、OpenAI APIキーをOCI VaultのSecretへ保存し、Autonomous AI DatabaseからResource Principalを使用して参照します。

Select AIのプロバイダーとモデルは変更せず、既存Blogと同じOpenAI APIおよびgpt-4o-miniをそのまま使用します。変更するのは、OpenAI APIキーの管理方法だけです。

ということで、OpenAI APIキーをSQLへ直接記述せず、OCI VaultとResource Principalを使用してSelect AIしてみてみます。

■ 今回の構成

今回の認証経路は、Vault Secret Credentialの作成・更新時と、Select AIの実行時で分けて考えると分かりやすくなります。

[Vault Secret Credentialの作成・更新時]


Autonomous AI Database
   │
   │ Resource Principal
   ▼
OCI Vault Secret
 OpenAI APIキーの最新Version
   │
   ▼
OPENAI_VAULT_CRED
[Select AIの実行時]
SELECT AI
   │
   ▼
DBMS_CLOUD_AIプロファイル
 provider : openai
 model    : gpt-4o-mini
   │
   ▼
OPENAI_VAULT_CRED
DBMS_CLOUD Vault Secret Credential
   │
   │ Authorization: Bearer <OpenAI APIキー>
   ▼
OpenAI API
 api.openai.com

Resource Principalの役割は、OpenAI APIへ直接認証することではありません。

通信区間 認証方法
Autonomous AI DatabaseからOCI Vault OCI Resource Principal
Autonomous AI DatabaseからOpenAI API Vaultから取得したOpenAI APIキー

つまり、Resource PrincipalでOpenAI APIキーを不要にするのではなく、Resource Principalを使ってOCI VaultからOpenAI APIキーを安全に取得します。

なお、OCI VaultがSelect AIの実行ごとに参照されるわけではありません。

Vault Secret Credentialは、OCI Vaultに登録されたSecretを12時間ごとに更新します。Secret Versionをすぐに反映したい場合は、DBMS_CLOUD.REFRESH_VAULT_CREDENTIALを実行します。

■ 前提条件

今回の手順では、次の環境を使用します。

項目 内容
Database Autonomous AI Database
リージョン Japan East（Tokyo）／ap-tokyo-1
Select AI実行ユーザー ADB_USER
AI Provider OpenAI
Model gpt-4o-mini
Secret管理 OCI Vault／Secret Management
Network api.openai.comへ接続できるNetwork ACL

このほか、OCI Vaultのマスター暗号化キー、OpenAI APIキー、既存のSelect AI用OpenAIプロファイルが必要です。

既存Blogで作成したOpenAIプロファイルを、そのまま利用します。

Provider : openai
Model    : gpt-4o-mini

■ OCI VaultへOpenAI APIキーを登録

● Vaultを作成

OCIコンソールから、OCI VaultのVaultを作成します。

すでに利用できるVaultがある場合は、新しく作成せず既存のVaultを使用できます。

01_Vault作成01.jpg

01_Vault作成02.jpg

01_Vault作成03.jpg

01_Vault作成05.jpg

● マスター暗号化キーを作成

Vault内に、Secretを暗号化するためのマスター暗号化キーを作成します。

マスター暗号化キーのProtection Modeには、SoftwareとHSMがあります。検証環境ではSoftware保護キーを使用でき、より高いセキュリティ要件がある場合はHSM保護キーを選択できます。キーの保護モードやローテーション方針は、組織のセキュリティ要件に応じて設定します。

02_Master鍵作成01.jpg

02_Master鍵作成02.jpg

02_Master鍵作成03.jpg

● Secretを作成

OpenAI APIキーを格納するSecretを作成します。

03_Secrets 作成01.jpg

03_Secrets 作成02.jpg

Secretの内容には、OpenAI APIキー文字列を登録します。

sk-proj-xxxxxxxxxxxxxxxxxxxxxxxx

Vault Secret Credentialでは、Secretから取得した値が通常のCredentialにおけるpasswordとして使用されるため、今回の用途では、次のようなJSON形式にはせず、APIキーの文字列だけを登録します。

{
  "api_key": "sk-proj-xxxxxxxxxxxxxxxxxxxxxxxx"
}
画面項目 設定値 補足
Create in compartment POC 検証ではADBと同じコンパートメントへ配置します。本番では組織の分離方針に従います
Name openai-select-ai-api-key 用途が分かる名前を設定します
Description 任意 例：OpenAI API key used by Select AI
Vault compartment POC Vault01が存在するコンパートメントです
Vault Vault01 Secretを格納するVaultです
Encryption key compartment POC ADW-Keyが存在するコンパートメントです
Encryption key ADW-Key Vault01内に作成した対称キーを指定します
Secret Generation Manual secret generation OpenAIが発行した既存APIキーを登録するため選択します
Secret Type Template Plain-Text Manualを選択すると表示されます
Secret Contents OpenAI APIキーそのもの sk-proj-...などをそのまま貼り付けます
Cross-region replication OFF 今回の検証では使用しません
Secret rotation 未設定 OpenAI側のAPIキー発行・無効化と合わせて管理します
Rules 未設定 今回の検証では使用しません

03_Secrets 作成04.jpg

作成後、SecretのOCIDを控えます。

ocid1.vaultsecret.oc1.ap-tokyo-1.xxxxxxxxxxxxxxxxx

03_Secrets 作成06.jpg

■ Dynamic Groupを作成

Autonomous AI DatabaseがResource PrincipalとしてOCI Vaultへアクセスできるように、Dynamic Groupを作成します。

OCIコンソールで、対象のAutonomous AI Databaseだけを含むMatching Ruleを設定します。

resource.id = '<Autonomous AI DatabaseのOCID>'

例:

resource.id = 'ocid1.autonomousdatabase.oc1.ap-tokyo-1.xxxxxxxxxxxxxxxxx'

コンパートメント内のすべてのAutonomous AI Databaseを対象にすることもできますが、今回は最小権限にするため、特定のAutonomous AI DatabaseのOCIDへ限定します。

Dynamic Group名の例は、次のとおりです。

ADB_OPENAI_VAULT_DG

04_DynamicGroups作成03.jpg

04_DynamicGroups作成01.jpg

04_DynamicGroups作成02.jpg

■ IAM Policyを作成

Dynamic Groupに対して、OCI VaultのSecretを読み取る権限を付与します。

今回は、OpenAI APIキーを格納した特定のSecretだけを読み取れるように制限します。

Allow dynamic-group ADB_OPENAI_VAULT_DG to read secret-bundles
in compartment <Secretを配置したCompartment名>
where target.secret.id = '<OpenAI APIキーを格納したSecretのOCID>'

例:

Allow dynamic-group ADB_OPENAI_VAULT_DG to read secret-bundles
in compartment MyCompartment
where target.secret.id = 'ocid1.vaultsecret.oc1.ap-tokyo-1.xxxxxxxxxxxxxxxxx'

このPolicyにより、対象のAutonomous AI Databaseは、指定したOpenAI APIキー用Secretだけを参照できます。

05_Policy作成01.jpg

05_Policy作成02.jpg

05_Policy作成03.jpg

■ Resource Principalを有効化

ADMINユーザーでAutonomous AI Databaseへ接続し、Resource Principalを有効化します。

SQL
BEGIN
    DBMS_CLOUD_ADMIN.ENABLE_RESOURCE_PRINCIPAL();
END;
/
SQL実行結果
PL/SQL procedure successfully completed.

Select AIをADB_USERで実行する場合は、対象ユーザーにもResource Principal Credentialへのアクセスを付与します。

SQL
BEGIN
    DBMS_CLOUD_ADMIN.ENABLE_RESOURCE_PRINCIPAL(
        username => 'ADB_USER'
    );
END;
/
SQL実行結果
PL/SQL procedure successfully completed.

OCI Generative AIのResource Principal検証と同じAutonomous AI Databaseおよび同じデータベース・ユーザーを使用している場合は、すでに設定済みの可能性があります。

必要に応じて、対象ユーザーへDBMS_CLOUDおよびDBMS_CLOUD_AIの実行権限を付与します。

GRANT EXECUTE ON DBMS_CLOUD TO ADB_USER;
GRANT EXECUTE ON DBMS_CLOUD_AI TO ADB_USER;

■ Vault Secret Credentialを作成

ADB_USERで接続し、OCI VaultのSecretを参照するCredentialを作成します。

OpenAI APIキーそのものではなく、SecretのOCIDを指定します。
このSQLにOpenAI APIキーは含まれません。

SQL
BEGIN
    DBMS_CLOUD.CREATE_CREDENTIAL(
        credential_name => 'OPENAI_VAULT_CRED',
        params          => JSON_OBJECT(
            'username'  VALUE 'OPENAI',
            'secret_id' VALUE
                'ocid1.vaultsecret.oc1.ap-tokyo-1.xxxxxxxxxxxxxxxxx'
        )
    );
END;
/
SQL実行結果
PL/SQL procedure successfully completed.

SQLスクリプトや実行履歴へ記録されるのは、OCI Vault SecretのOCIDだけです。

今回の手順では、Vault Secret CredentialとSelect AIプロファイルを同じADB_USERで作成・使用します。AIプロファイルの属性変更も、プロファイルを所有するユーザーで実行します。

● Vault Secret Credentialを即時更新

DBMS_CLOUD.REFRESH_VAULT_CREDENTIALは、OCI Vaultから最新VersionのSecretを即時取得し、Vault Secret Credentialを更新する処理です。

通常は12時間間隔で自動更新されるため、Vault側のSecretを変更した場合、Autonomous AI Databaseへ反映されるまで最大12時間かかることがあります。すぐに最新Versionを反映したい場合は、次を実行します。

SQL
BEGIN
    DBMS_CLOUD.REFRESH_VAULT_CREDENTIAL(
        credential_name => 'OPENAI_VAULT_CRED'
    );
END;
/
SQL実行結果
PL/SQL procedure successfully completed.

■ 既存のSelect AIプロファイルを変更

既存Blogで作成したSelect AIプロファイルのCredentialを、Vault Secret Credentialへ変更します。

ここでは、既存プロファイル名をOPENAIとします。

SQL
BEGIN
    DBMS_CLOUD_AI.SET_ATTRIBUTE(
        profile_name    => 'OPENAI',
        attribute_name  => 'credential_name',
        attribute_value => 'OPENAI_VAULT_CRED'
    );
END;
/
SQL実行結果
PL/SQL procedure successfully completed.

変更するのは、credential_nameだけです。

次の設定は変更しません。

{
  "provider": "openai",
  "model": "gpt-4o-mini"
}

そのため、持ち込みのOpenAI APIモデルgpt-4o-miniをそのまま利用できます。

● プロファイル設定を確認

プロファイルの属性を確認します。

SQL
SELECT attribute_name,
       attribute_value
FROM user_cloud_ai_profile_attributes
WHERE profile_name = 'OPENAI'
  AND attribute_name IN (
      'provider',
      'model',
      'credential_name'
  )
ORDER BY attribute_name;
SQL実行結果
ATTRIBUTE_NAME     ATTRIBUTE_VALUE
__________________ ____________________
credential_name    OPENAI_VAULT_CRED
model              gpt-4o-mini
provider           openai

■ Select AIを実行

使用するSelect AIプロファイルを設定します。

SQL
BEGIN
    DBMS_CLOUD_AI.SET_PROFILE('OPENAI');
END;
/
SQL実行結果
PL/SQL procedure successfully completed.

まず、自然言語から生成されるSQLを確認します。

SQL
SELECT AI SHOWSQL 顧客は全部で何人ですか？;
SQL実行結果
RESPONSE
_______________________________________________
SELECT COUNT("CUST_ID") AS "Total_Customers"
FROM "SH"."CUSTOMERS" c
WHERE "CUST_VALID" = 'Y'

続いて、Select AIを実行します。

SQL
SELECT AI 顧客は全部で何人ですか？;
SQL実行結果
   Total_Customers
__________________
                 0

既存Blogと同じ結果が返れば、OpenAI APIキーをOCI Vaultから取得してSelect AIを実行できています。

OpenAI APIへの接続先は変わらないため、既存Blogで設定したapi.openai.comへのNetwork ACLは引き続き必要です。

■ OpenAI APIキーをローテーション

OCI Vaultを利用するメリットの1つが、OpenAI APIキーをSelect AIプロファイルから分離して管理できることです。

OpenAI APIキーを更新するときは、次の順序で実施します。

1) OpenAIで新しいAPIキーを作成

OpenAI側で、新しいAPIキーを作成します。

2) OCI Vaultへ新しいSecret Versionを追加

既存のSecretへ、新しいOpenAI APIキーをSecret Versionとして追加します。
11_APIキーローテーション01.jpg

11_APIキーローテーション02.jpg

11_APIキーローテーション03.jpg

3) Vault Secret Credentialを更新

新しいSecret Versionを即時反映したい場合は、次を実行します。

SQL
BEGIN
    DBMS_CLOUD.REFRESH_VAULT_CREDENTIAL(
        credential_name => 'OPENAI_VAULT_CRED'
    );
END;
/
SQL実行結果
PL/SQL procedure successfully completed.

Vault Secretの変更は定期的に再取得されますが、ローテーション直後に動作確認する場合は明示的に更新します。

4) Select AIの動作を確認

SQL
SELECT AI SHOWSQL 顧客は全部で何人ですか？;
SQL実行結果
RESPONSE
_______________________________________________
SELECT COUNT("CUST_ID") AS "Total_Customers"
FROM "SH"."CUSTOMERS" c
WHERE "CUST_VALID" = 'Y'
SQL
SELECT AI 顧客は全部で何人ですか？;
SQL実行結果
   Total_Customers
__________________
                 0

5) OpenAI側で古いAPIキーを無効化

新しいAPIキーで正常に動作することを確認した後、OpenAI側で古いAPIキーを無効化します。

6) 古いAPIキーの無効化後に最終確認

古いAPIキーを無効化した状態で、もう一度Select AIを実行します。

SQL
SELECT AI SHOWSQL 顧客は全部で何人ですか？;

ここでもSQLが生成されれば、Vault Secret Credentialが新しいOpenAI APIキーへ切り替わったことを確認できます。

OCI VaultがOpenAI APIキーを自動発行するわけではありません。

役割分担は、次のようになります。

操作 実施するサービス
新しいAPIキーの発行 OpenAI
APIキーの安全な保管 OCI Vault
Autonomous AI Databaseへの反映 OCI Vault / DBMS_CLOUD
古いAPIキーの無効化 OpenAI

■ 旧Credentialを削除

Vault Secret Credentialへ切り替え、Select AIが正常に動作することを確認した後、OpenAI APIキーを直接登録していた旧Credentialを削除します。

SQL
BEGIN
    DBMS_CLOUD.DROP_CREDENTIAL(
        credential_name => 'OPENAI_CRED'
    );
END;
/
SQL実行結果
PL/SQL procedure successfully completed.

安全に移行するため、次の順序で実施します。

既存のOPENAI_CREDを残す
        ↓
OPENAI_VAULT_CREDを新規作成
        ↓
Select AIプロファイルを切り替える
        ↓
Select AIの動作を確認する
        ↓
旧OPENAI_CREDを削除する

最初に旧Credentialを削除するよりも、新しいCredentialの動作を確認してから削除する方が、問題発生時に切り戻しやすくなります。

■ セキュリティ上のポイント

今回の構成では、次のように権限と利用範囲を限定します。

  • OpenAI側ではSelect AI専用のProject APIキーを使用する
  • OpenAI APIキーの権限を必要最小限にする
  • OpenAI側で利用上限やUsageを監視する
  • Dynamic Groupは特定のAutonomous AI Databaseへ限定する
  • IAM Policyは特定のVault Secretへ限定する
  • DBMS_CLOUDとDBMS_CLOUD_AIの権限を必要なユーザーだけに付与する
  • OpenAI APIキーをSQL、Git、ログ、スクリーンショットへ記録しない
  • APIキーを定期的にローテーションする

また、今回利用しているのは、OCI VaultのSecret管理機能です。

Oracle AI DatabaseのDatabase Vaultとは、名前が似ていますが別の機能です。

サービス／機能 主な用途
OCI Vault 暗号化キーやSecretの保管・管理
Oracle AI Database Vault データベース内の特権アクセス制御

■ OCI Generative AIとの違い

OCI Generative AIとOpenAI APIでは、Resource Principalの使用方法が異なります。

項目 OCI Generative AI OpenAI API
AIサービスへの認証 Resource Principal OpenAI APIキー
APIキー 不要 必要
APIキーの保管先 なし OCI Vault Secret
Autonomous AI DatabaseからVaultへの認証 不要 Resource Principal
Select AIのProvider oci openai

OCI Generative AIでは、Resource PrincipalがAIサービスへの認証に直接使用されます。

OpenAI APIでは、Resource PrincipalはOCI Vaultへアクセスするために使用され、OpenAI APIへの認証にはVaultから取得したOpenAI APIキーを使用します。

■ まとめ

今回は、既存Blogで使用したOpenAI APIおよびgpt-4o-miniを変更せず、OpenAI APIキーの管理方法だけをOCI Vaultへ変更しました。

今回確認できたポイントは、次のとおりです。

  • OpenAI APIキーそのものは引き続き必要
  • OpenAI APIキーをOCI VaultのSecretへ保存
  • Autonomous AI DatabaseからOCI VaultへResource Principalでアクセス
  • Select AIプロファイルではVault Secret Credentialを使用
  • SQLへOpenAI APIキーを直接記述しない
  • APIキーのローテーション時にSelect AIプロファイルを作り直す必要がない
  • IAM Policyによって参照できるAutonomous AI DatabaseとSecretを限定できる

Resource PrincipalでOpenAI APIキーが不要になるわけではありません。

それでも、APIキーをSQLやスクリプトからOCI Vaultへ分離し、誰が参照できるのかをIAM Policyで制御し、ローテーション時にはCredentialだけを更新できるようになりました。

今回あらためて感じたのは、AI機能を「使えるようにする」ことと、「運用できる形に整える」ことは別だということです。

Select AIで自然言語からSQLを生成できても、APIキーをどこへ置き、誰が参照でき、どのようにローテーションするのかまで整理して、ようやく実際の運用へ近づきます。

また、Oracleだけですべてを閉じるのではなく、データとSQLはAutonomous AI Database、AIモデルはOpenAI、Secret管理はOCI Vaultと、それぞれの得意なところをつなげて使えるのも、今回面白いと感じたところです。

Oracle Databaseを長く触ってきた立場から見ると、AIが動くことだけでなく、既存のCredentialやIAMの仕組みを使って運用まで組み立てられるところには、かなりグッとくるものがあります。

DBMS_CLOUDのVault Secret Credentialは、OCI Vaultだけでなく、Azure Key Vault、AWS Secrets Manager、GCP Secret Managerにも対応しています。

今回はOCI Vaultで検証しましたが、次回はこの仕組みをMulti Cloudへ広げ、それぞれのCloudで管理しているSecretをAutonomous AI Databaseからどのように利用できるのか、試してみてみたいです。

■ 参考情報

■ 解説

■ おまけ

おまけ.jpg

8
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
8
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?