【要約】Autonomous AI Databaseの Resource Principalで、API署名鍵を使わずにSelect AIしてみてみた [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
開発者がSelect AIを用いてOCI Generative AIと連携させる際、認証情報の管理が大きな負担となっていた。従来の方式では、人間が管理するOCIユーザーの権限をデータベースに委ねる必要があった。
- ・OCIユーザーのAPI署名秘密鍵をデータベースCredentialに保存しなければならない。
- ・User OCID、Tenancy OCID、Fingerprint等の複数情報の管理が必要である。
- ・秘密鍵の漏洩リスクや、手動でのローテーション作業が運用上のペインポイントとなる。
// Approach
認証主体を「人間」から「リソース自身」へ切り替えるアプローチを採用した。これにより、データベースが直接OCIのアイデンティティとして振る舞う構成を実現する。
- ・Dynamic Groupを作成し、対象ADBのOCIDをメンバーとして定義する。
- ・IAM Policyで、Dynamic Groupに対しGenerative AIのChat API実行権限を付与する。
- ・ADB側で
DBMS_CLOUD_ADMIN.ENABLE_PRINCIPAL_AUTHを実行し、Resource Principalを有効化する。 - ・Select AI Profileの
credential_nameにシステム定義のOCI$RESOURCE_PRINCIPALを指定する。
// Result
API署名鍵を一切使用せずに、Select AIからOCI Generative AI（Cohere Command A）の呼び出しに成功した。
- ・秘密鍵のダウンロード、保存、SQLへの貼り付け作業が完全に不要となった。
- ・認証情報のライフサイクル管理をOCI側に完全に委ねることが可能になった。
- ・Dynamic GroupとPolicyにより、特定のADBに対して最小権限でのアクセス制御を実現した。
Senior Engineer Insight
> 鍵管理の「排除」こそが真のセキュリティである。従来の「安全に保管する」という考え方から、「そもそも存在させない」という設計思想への転換は、運用コストとリスクを劇的に下げる。特に、認証主体と処理実体を一致させることで、IAM設計が極めてシンプルになる点は、大規模環境でのガバナンス維持において非常に強力な武器となる。実戦投入時には、Resource Principalのトークンキャッシュ（最大2時間）による反映遅延に留意すべきだ。