OCI VaultのシークレットとObject Storageの使い方を図解：動的グループで読み、Service Gateway経由で置く

※当ページにはAmazonアソシエイト等の広告リンクを含みます。

1. 全体の流れ：Computeに鍵を置かない

今回のCompute 2台は、起動時にVaultからDBのパスワードを読み、領収書をObject Storageへ置きます。どちらも同じ仕組みで動きます。動的グループの節で見たとおり、インスタンスがグループの一員となり、ポリシーで権限を受け取ります。

2. パスワードをVaultに置き、動的グループで読む

シークレットを保管する

シークレットの機能は、公式では Secret Management Service として案内されています。

security コンパートメントにVaultを置きます。Vaultの種類は作成後に変更できません。今回は専用のパーティションが要る要件がないので、仮想プライベート・ボールトにはしません。

1. Vaults の一覧で Create Vault を選びます。Make it virtual private vault は選びません。
2. Vaultの中でマスター暗号化キーを作ります。Key Shape: Algorithm は AES にします。シークレットには対称キーが必要で、非対称キーは使えません。保護モードも作成後に変更できません。Always Free の枠は HSM のキー・バージョンが計20個、Software は無制限です（2026-11-01確認）。シークレットで選べるモードは画面で確かめます。
3. Secrets の一覧で Create secret を選びます。名前は expense-db-password とし、同じVaultのキーを選びます。
4. Manual secret generation を選び、Secret Contents にDBのアプリ用ユーザーのパスワードを入れます。コンソールなら平文で入れられ、base64へ自動で変換されます。

動的グループとポリシーを作る

まず動的グループ dg-expense-app を作ります。一致ルールは、app コンパートメントのインスタンスを指定します。OCIDは自分の環境の値に置き換えます。

instance.compartment.id = '<app_compartment_ocid>'

次に、読むシークレットを1つに絞ったポリシーを書きます。

Allow dynamic-group dg-expense-app to read secret-bundles in compartment security where target.secret.name = 'expense-db-password'

中身を返すAPIの権限は read secret-bundles です。read secrets はメタデータを読む権限で、パスワードは取れません。

Computeにログインして、キーなしで読めるか確かめます。OCI CLIが入っていなければ、先に入れます。画面やログにパスワードを残さないよう、結果は捨てて成否だけを見ます。

oci secrets secret-bundle get-secret-bundle-by-name \
  --secret-name expense-db-password \
  --vault-id <vault_ocid> \
  --auth instance_principal > /dev/null && echo OK

アプリではSDKのインスタンス・プリンシパルの認証を使います。返された内容はbase64でエンコードされているので、デコードして使います。

3. 領収書のバケットを閉じ、キーなしで書き込む

バケットの公開設定を切る

領収書は社員の個人情報も含むので、公開しません。app コンパートメントにバケット expense-receipts を作ります。新しいバケットは既定で非公開です。作成後に、設定を確かめる手順も入れておきます。

oci os bucket get -ns <namespace> --bucket-name expense-receipts | grep "public-access-type"

NoPublicAccess なら非公開です。もし公開になっていたら、バケットの Actions から Edit visibility で Private にするか、次のコマンドで戻します。

oci os bucket update --name expense-receipts --public-access-type NoPublicAccess

キーなしで書き込む

アプリの動的グループに、このバケットだけの権限を渡します。manage objects に条件を付けて、必要な権限だけにします。

Allow dynamic-group dg-expense-app to read buckets in compartment app where target.bucket.name = 'expense-receipts'
Allow dynamic-group dg-expense-app to manage objects in compartment app where all {target.bucket.name = 'expense-receipts', any {request.permission = 'OBJECT_CREATE', request.permission = 'OBJECT_INSPECT', request.permission = 'OBJECT_READ'}}

Computeから試します。

oci os object put -bn expense-receipts --file ./test.jpg --name 2026/11/test.jpg --auth instance_principal

アプリでも鍵ファイルは置かず、SDKのインスタンス・プリンシパルで呼び出します。

4. Service Gateway経由にする

private-app からObject Storageへ行く経路を、インターネットを通らない形にします。Service Gatewayの通信は、同じリージョンのOracleのサービスへOracleのネットワーク内で届きます。

設定は3か所です。

1. Service Gatewayに All NRT Services in Oracle Services Network を設定します。
2. private-app のルート表に、宛先がこのラベル、ターゲットがService Gatewayのルールを足します。
3. ComputeのNSGの送信ルールで、宛先に同じラベル、TCP 443を許可します。ステートレスのルールなら受信ルールも必要です。

より強く絞りたいときは、ネットワーク・ソースを使って、指定したVCNのService Gateway経由の要求だけをバケットで許可するIAMポリシーを書けます。ただし、公式の注記のとおりコンソールからバケットを見られなくなります。小規模な最初の構成では、運用の手間と比べて判断します。

5. ライフサイクルは小さく始める

領収書の量を見積もります。社員30人が月に10枚、1枚2MBなら月600MB、年7.2GBです。Always Freeは合計20GBで、有料アカウントかクレジットの残るFree Trialでは階層ごとに10GB、APIは月5万回です（2026-11-01確認）。最新は公式で確認してください。

Allow service objectstorage-ap-tokyo-1 to manage object-family in compartment app where any {request.permission = 'BUCKET_INSPECT', request.permission = 'BUCKET_READ', request.permission = 'OBJECT_INSPECT', request.permission = 'OBJECT_UPDATE_TIER', request.permission = 'OBJECT_DELETE', request.permission = 'OBJECT_VERSION_DELETE'}

次に読むページ

• ロードマップの次の項目：LBの後ろにComputeを置く
• 動的グループの基本：Dynamic Groupの節
• 全体の順番：学習ロードマップ