先前，我曾經透過 Autonomous AI Database 的 Select AI 呼叫 OpenAI API，並以自然語言查詢資料庫。

• 使用 OpenAI API 透過自然語言試用 Select AI

上一回，我確認了使用 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 或 Shell 的歷史紀錄
• 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 金鑰的最新版本
   │
   ▼
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 VaultOCI Resource PrincipalAutonomous AI Database 到 OpenAI API從 Vault 取得的 OpenAI API 金鑰也就是說，Resource Principal 並不是用來消除 OpenAI API 金鑰，而是用來安全地從 OCI Vault 取得 OpenAI API 金鑰。

另外，OCI Vault 並不是每次執行 Select AI 都會被參照。

Vault Secret Credential 會每 12 小時從 OCI Vault 同步一次 Secret。若想立即反映 Secret Version，則執行 DBMS_CLOUD.REFRESH_VAULT_CREDENTIAL。

■ 前提條件

這次的步驟使用以下環境。

項目內容DatabaseAutonomous AI Database區域Japan East（Tokyo）／ap-tokyo-1Select AI 執行使用者ADB_USERAI ProviderOpenAIModelgpt-4o-miniSecret 管理OCI Vault／Secret ManagementNetwork可連線到 api.openai.com 的 Network ACL此外，還需要 OCI Vault 的主加密金鑰、OpenAI API 金鑰，以及既有的 Select AI 用 OpenAI 設定檔。

既有 Blog 建立的 OpenAI 設定檔，直接沿用。

Provider : openai
Model    : gpt-4o-mini

■ 將 OpenAI API 金鑰註冊到 OCI Vault

● 建立 Vault

從 OCI Console 建立 OCI Vault 的 Vault。

如果已經有可用的 Vault，就不需要新建，可以直接使用既有 Vault。

● 建立主加密金鑰

在 Vault 內建立用來加密 Secret 的主加密金鑰。

主加密金鑰的 Protection Mode 有 Software 與 HSM 兩種。驗證環境可使用 Software 保護金鑰；若有更高的安全性需求，則可選擇 HSM 保護金鑰。金鑰的保護模式與輪替方針，請依組織的安全需求設定。

● 建立 Secret

建立用來儲存 OpenAI API 金鑰的 Secret。

Secret 的內容中，填入 OpenAI API 金鑰字串。

sk-proj-xxxxxxxxxxxxxxxxxxxxxxxx

在 Vault Secret Credential 中，從 Secret 取得的值會作為一般 Credential 的 password 使用，因此這次的用途不需要使用 JSON 格式，只要登錄 API 金鑰字串即可。

{
  "api_key": "sk-proj-xxxxxxxxxxxxxxxxxxxxxxxx"
}

畫面項目設定值補充Create in compartmentPOC驗證時與 ADB 放在同一個 Compartment。正式環境則依組織的分離方針配置Nameopenai-select-ai-api-key設定能看出用途的名稱Description任意，例如：OpenAI API key used by Select AIVault compartmentPOC放有 Vault01 的 CompartmentVaultVault01存放 Secret 的 VaultEncryption key compartmentPOC放有 ADW-Key 的 CompartmentEncryption keyADW-Key指定在 Vault01 內建立的對稱金鑰Secret GenerationManual secret generation因為要註冊 OpenAI 已發行的既有 API 金鑰Secret Type TemplatePlain-Text在選擇 Manual 後會顯示Secret ContentsOpenAI API 金鑰本身直接貼上 sk-proj-... 之類的字串即可Cross-region replicationOFF這次驗證不使用Secret rotation未設定與 OpenAI 端的 API 金鑰發行／停用一併管理Rules未設定這次驗證不使用

建立後，請記下 Secret 的 OCID。

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

■ 建立 Dynamic Group

為了讓 Autonomous AI Database 能以 Resource Principal 存取 OCI Vault，請建立 Dynamic Group。

在 OCI Console 中設定只包含目標 Autonomous AI Database 的 Matching Rule。

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

例如：

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

也可以把同一個 Compartment 中的所有 Autonomous AI Database 都納入，但這次為了最小權限原則，只限定為特定 Autonomous AI Database 的 OCID。

Dynamic Group 名稱範例如下：

ADB_OPENAI_VAULT_DG

■ 建立 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。

■ 啟用 Resource Principal

以 ADMIN 使用者連線到 Autonomous AI Database，並啟用 Resource Principal。

SQL

BEGIN
    DBMS_CLOUD_ADMIN.ENABLE_RESOURCE_PRINCIPAL();
END;
/

SQL 執行結果

PL/SQL procedure successfully completed.

如果要讓 ADB_USER 執行 Select AI，也必須把 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。

這裡指定的是 Secret 的 OCID，而不是 OpenAI API 金鑰本身。
這段 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 取得最新版本的 Secret，並更新 Vault Secret Credential。

一般來說會每 12 小時自動更新，因此如果你在 Vault 端修改了 Secret，Autonomous AI Database 最多可能要等 12 小時才會反映。若要立刻套用最新版本，請執行以下指令。

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 相同的結果，就表示已經成功從 OCI Vault 取得 OpenAI API 金鑰並執行 Select AI。

由於 OpenAI API 的連線目的地沒有改變，先前為 api.openai.com 設定的 Network ACL 仍然需要保留。

■ OpenAI API 金鑰輪替

使用 OCI Vault 的好處之一，就是可以把 OpenAI API 金鑰與 Select AI 設定檔分開管理。

當要更新 OpenAI API 金鑰時，請依照以下順序進行。

1）在 OpenAI 建立新的 API 金鑰

先在 OpenAI 端建立新的 API 金鑰。

2）在 OCI Vault 新增新的 Secret Version

把新的 OpenAI API 金鑰作為 Secret Version 加到既有的 Secret。

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 金鑰發行OpenAIAPI 金鑰的安全保管OCI Vault反映到 Autonomous AI DatabaseOCI 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 Management 功能。

Oracle AI Database 的 Database Vault，名稱雖然相似，但其實是不同的功能。

服務／功能主要用途OCI Vault儲存與管理加密金鑰與 SecretOracle AI Database Vault資料庫內的特權存取控制■ 與 OCI Generative AI 的差異

OCI Generative AI 與 OpenAI API 在 Resource Principal 的使用方式不同。

項目OCI Generative AIOpenAI APIAI 服務的驗證Resource PrincipalOpenAI API 金鑰是否需要 API 金鑰不需要需要API 金鑰的儲存位置無OCI Vault SecretAutonomous AI Database 到 Vault 的驗證不需要Resource PrincipalSelect AI 的 Provideroci``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 透過 Resource Principal 存取 OCI Vault
• Select AI 設定檔使用 Vault Secret Credential
• 不要把 OpenAI API 金鑰直接寫進 SQL
• 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 加以利用。

■ 參考資訊

• 使用 OpenAI API 透過自然語言試用 Select AI
• 將 Vault Secret Credentials 與 Autonomous Database 一起使用
• DBMS_CLOUD Package
• DBMS_CLOUD_AI Package
• 管理 Select AI 設定檔
• 在 Autonomous Database 啟用 Resource Principal
• Secret Management Service
• 建立主加密金鑰
• Vault、Key Management 與 Secret Management Service 的詳細資訊
• OpenAI API 金鑰安全最佳實務
• 指派 API 金鑰權限
• OpenAI Production Best Practices
• GPT-4o Mini 模型

■ 解說

■ 附錄

原文出處：https://qiita.com/shirok/items/a5f34349c0b6ba8f3f62