※ 本記事は、Can Tuzlaによる”Store Your Credentials in an OCI Vault Secret When Making External Calls from Your Autonomous Database“を翻訳したものです。
2023年7月21日
Oracle Autonomous Database Serverless (ADB-S)は、外部データソースとのやり取り、Webサービスの呼出し、または以前のブログ投稿で確認した電子メールの送信を行う際に、シームレスなユーザー・エクスペリエンスを提供します。他のOracleまたはOracle以外のデータベースへのデータベース・リンクの作成、様々なクラウド・オブジェクト・ストアからのデータのロードまたは外部表の問合せ、UTL_HTTPまたはUTL_SMTPコールの実行は、このようなユースケースの例です。データベース・リンクを作成するか、Webサービス・コールを行うかに関係なく、認証という1つの共通点があります。この認証は、データベース・リンク用にターゲット・データベースに存在するデータベース・ユーザーとして認証するか、使用しているユースケースに応じてHTTP/SMTP認証として認証することを意味する場合があります。ただし、これらの場合はすべて、ユーザー名/パスワードのペアが必要です(オブジェクト・ストア・アクセスにリソース・プリンシパルまたはネイティブ認証を使用していない場合)。Autonomous Databaseでのこれらの資格証明の作成および格納は、DBMS_CLOUD.CREATE_CREDENTIALプロシージャによって処理されます。このブログ投稿では、このようなユースケース用のパスワードをデータベースに格納するのではなく、OCI Vault Secretに格納できる次のレベルに、この手順の機能を使用しない方法について検討します。
この新機能の詳細な説明に進む前に、ADB-Sユーザーにとっての利点を強調したいと思います。:
- ADB-Sインスタンスでパスワードをレプリケートする必要はありません。これらのパスワードは、すべてのADB-SインスタンスでポイントできるOCI Vaultシークレットに格納できます。
- 簡単で効率的なパスワード・ローテーション。OCI Vaultでパスワードを直接ローテーションするだけで、ADB-Sインスタンスに自動的に反映されます(ADBは12時間ごとに資格証明オブジェクトをリフレッシュするため、ローテーションがデータベースに反映されるまでに最大12時間かかることに注意してください)。
- セキュリティ。最後に、パスワードをOCI Vaultの独自のシークレットに格納し、独自の暗号化キーで暗号化します。
このブログ投稿の残りの部分では、2つのADB-Sインスタンス間にデータベース・リンクを作成するときに、この新機能の使用方法を確認します。次のステップに従います。:
- OCI Vaultにシークレットを作成し、ターゲット・データベース・ユーザーのパスワードを格納します
- ソースADB-Sインスタンスでリソース・プリンシパルを有効にします
- データベース・リンクの作成
OCI Vaultにシークレットを作成し、ターゲット・データベース・ユーザーのパスワードを格納
ターゲット・データベースへのデータベース・リンクを作成するには、ターゲット・データベースのユーザー名およびパスワード(スキーマ名およびパスワード)が必要です。ターゲット・データベース・パスワードをシークレットとしてOCI Vaultに格納します。Vaultを作成したら、次のようにターゲット・データベースのパスワードを保持するシークレットを作成します:
ソースADB-Sインスタンスでリソース・プリンシパルを有効に
次のステップは、ソース・データベースでリソース・プリンシパルを有効にして、OCI Vaultのシークレットにアクセスし、ターゲット・データベース・ユーザーのパスワードをフェッチできるようにすることです。以前のブログ投稿で既に説明したように、リソース・プリンシパルを有効にする前に、まず動的グループとポリシーを作成する必要があります。
動的グループの有効範囲は、この例のソース・データベースに制限されています。:
resource.id = 'ocid1.autonomousdatabase.oc1.us-sanjose-1.anzw*************'
また、ソース・データベースがテナンシ内のシークレットにアクセスできるようにする次のポリシーも追加します:
Allow dynamic-group ctuzlaDGforVault to read secret-bundles in tenancy
最後に、ソース・データベースでリソース・プリンシパルを有効にします。:
EXEC DBMS_CLOUD_ADMIN.ENABLE_RESOURCE_PRINCIPAL();
この時点では、これまで行ってきたすべての作業は1回のみであることに言及する価値があります。つまり、同じ資格証明を使用して別のデータベース・リンクを作成する必要がある場合、シークレットを作成し、リソース・プリンシパルを再度有効にする必要はありません。
データベース・リンクの作成
データベース・リンクを作成する前に、まずターゲット・データベースの資格証明オブジェクトを作成します。:
BEGIN
DBMS_CLOUD.CREATE_CREDENTIAL(
credential_name => 'OCI_SECRET_CRED',
params => JSON_OBJECT('username' value 'ADMIN',
'region' value 'us-sanjose-1',
'secret_id' value 'ocid1.vaultsecret.oc1.us-sanjose-1.amaa************')
);
END;
/
資格証明の作成時にパスワードを指定しなかったことに注意してください。かわりに、パスワードを格納するシークレットのリージョンおよびシークレットOCIDを指定しました。
データベース・リンクを作成する準備ができました。:
BEGIN
DBMS_CLOUD_ADMIN.CREATE_DATABASE_LINK(
db_link_name => 'financelink',
hostname => 'adb.us-sanjose-1.oraclecloud.com',
port => '1521',
service_name => 'qtr*****_finance_low.adb.oraclecloud.com',
credential_name => 'OCI_SECRET_CRED');
END;
/
select * from dual@financelink; D - X
まとめると、DBMS_CLOUDはOCI Vault統合をサポートするようになり、ADB-SユーザーはパスワードをOCI Vaultにシークレットとして格納できます。これは、データベース・リンクの作成、UTL_HTTPを介したWebサービス・コール、UTL_SMTPを介した電子メールの送信、クラウド・オブジェクト・ストアへのアクセスなど、ユーザー名とパスワードのペアを提供する必要があるユースケースに適用されます。パスワードをOCI Vaultにシークレットとして保存すると、独自の暗号化キーで暗号化できるだけでなく、各データベースのパスワード・レプリケーションを回避することで、パスワード管理(作成、ローテーションなど)が大幅に簡単になります。この機能の詳細は、ドキュメントを参照してください。