ダブルクリックで英日反転
Applied Sciences · Engineering
Safe Tenant-Scoped Writes to a Cloud Database
Writing to a shared (multi-tenant) cloud database safely requires three layers working together: a secure tunnel, secrets management, and tenant isolation — skipping any one layer risks cross-tenant data corruption.
Connect Safely
- Cloud SQL Auth Proxy: proxies DB traffic through Google auth — no exposed port, appears as localhost.
- ADC (Application Default Credentials): auto-selects credentials for the runtime environment; set up with `gcloud auth application-default login`.
- quota-project mismatch causes 403 errors — set it explicitly with `gcloud auth application-default set-quota-project`.
Handle Secrets
- Store passwords and API keys in Secret Manager (encrypted cloud vault), never in plaintext code or config.
- Fetch secrets at runtime only; never print, log, or hard-code them.
Isolate by Tenant
- Multi-tenant design: all tables carry a `customer_id` column; every operation must filter by it.
- RLS (Row-Level Security): DB policy auto-filters rows by tenant — application just does a plain INSERT.
- Without RLS, the app must add `WHERE customer_id = '<target>'` manually; omitting it risks overwriting other tenants' data.
Safe Write Discipline
- Self-check first: SELECT to confirm target tenant, table, and row count before any write.
- One-row test: write a single row, verify the result, then proceed in small batches.
- Audit log: record what was written, when, and how many rows — on your local machine.
- Production lockdown: destructive ops (DELETE/TRUNCATE/DROP) require explicit prior approval.
→ In a multi-tenant environment, one unchecked write touches every customer — connection, secrets, and filtering must all be correct before you touch production.
Applied Sciences · Engineering
クラウドDBへのテナント安全書き込み
マルチテナント（複数顧客が同一DBを共有する設計）のクラウドDBに安全に書き込むには、「安全な接続」「シークレット管理」「テナント分離」の3層が揃っている必要がある。どれか一つが欠けると他テナントのデータを汚染するリスクがある。
安全に接続する
- Cloud SQL Auth Proxy（＝Googleが提供するDB接続用の安全なトンネル）：ポートを公開せずlocalhostとして見えるようにする。
- ADC（Application Default Credentials＝実行環境に応じて認証情報を自動選択する仕組み）：`gcloud auth application-default login` で設定。
- quota-projectのズレは403エラーの原因になる。`set-quota-project` で明示的に設定する。
シークレットを扱う
- Secret Manager（＝パスワードやAPIキーを暗号化して保管するクラウドの金庫）を使い、コードやファイルに平文で書かない。
- シークレットは実行時にのみ取り出す。画面・ログ・スクリプト内への印字・ハードコードは禁止。
テナントを分離する
- マルチテナント設計では全テーブルに `customer_id` 列を持ち、操作のたびにこの列でフィルタリングする。
- RLS（Row-Level Security＝行レベルセキュリティ）が有効なら、DBポリシーがテナントを自動フィルタ。アプリ側は通常のINSERTだけでよい。
- RLSが無効な環境では、アプリ側で `WHERE customer_id = '<対象>'` を必ず付ける。条件なし書き込みは他テナントへの誤書き込みの原因になる。
安全な書き込み手順
- 事前自己確認：SELECTで対象テナント・テーブル・件数を目視してから書き込む。
- 1件テスト書き込み→確認→小バッチで進める。大量一括書き込みは禁止。
- 監査ログ：何を・いつ・何件書いたかをローカルに記録する。
- 本番ロックダウン：DELETE/TRUNCATE/DROPなど破壊的操作は事前に内容・影響範囲を示して承認を得てから実行する。
→ マルチテナント環境での1回のミスは全顧客に波及する。接続・シークレット・フィルタリングの3層が揃って初めて本番に触れてよい。
Applied Sciences · Engineering
Safe Tenant-Scoped Writes to a Cloud Database
Writing to a shared (multi-tenant) cloud database safely requires three layers working together: a secure tunnel, secrets management, and tenant isolation — skipping any one layer risks cross-tenant data corruption.
Connect Safely
- Cloud SQL Auth Proxy: proxies DB traffic through Google auth — no exposed port, appears as localhost.
- ADC (Application Default Credentials): auto-selects credentials for the runtime environment; set up with `gcloud auth application-default login`.
- quota-project mismatch causes 403 errors — set it explicitly with `gcloud auth application-default set-quota-project`.
Handle Secrets
- Store passwords and API keys in Secret Manager (encrypted cloud vault), never in plaintext code or config.
- Fetch secrets at runtime only; never print, log, or hard-code them.
Isolate by Tenant
- Multi-tenant design: all tables carry a `customer_id` column; every operation must filter by it.
- RLS (Row-Level Security): DB policy auto-filters rows by tenant — application just does a plain INSERT.
- Without RLS, the app must add `WHERE customer_id = '<target>'` manually; omitting it risks overwriting other tenants' data.
Safe Write Discipline
- Self-check first: SELECT to confirm target tenant, table, and row count before any write.
- One-row test: write a single row, verify the result, then proceed in small batches.
- Audit log: record what was written, when, and how many rows — on your local machine.
- Production lockdown: destructive ops (DELETE/TRUNCATE/DROP) require explicit prior approval.
→ In a multi-tenant environment, one unchecked write touches every customer — connection, secrets, and filtering must all be correct before you touch production.
Applied Sciences · Engineering
クラウドDBへのテナント安全書き込み
マルチテナント（複数顧客が同一DBを共有する設計）のクラウドDBに安全に書き込むには、「安全な接続」「シークレット管理」「テナント分離」の3層が揃っている必要がある。どれか一つが欠けると他テナントのデータを汚染するリスクがある。
安全に接続する
- Cloud SQL Auth Proxy（＝Googleが提供するDB接続用の安全なトンネル）：ポートを公開せずlocalhostとして見えるようにする。
- ADC（Application Default Credentials＝実行環境に応じて認証情報を自動選択する仕組み）：`gcloud auth application-default login` で設定。
- quota-projectのズレは403エラーの原因になる。`set-quota-project` で明示的に設定する。
シークレットを扱う
- Secret Manager（＝パスワードやAPIキーを暗号化して保管するクラウドの金庫）を使い、コードやファイルに平文で書かない。
- シークレットは実行時にのみ取り出す。画面・ログ・スクリプト内への印字・ハードコードは禁止。
テナントを分離する
- マルチテナント設計では全テーブルに `customer_id` 列を持ち、操作のたびにこの列でフィルタリングする。
- RLS（Row-Level Security＝行レベルセキュリティ）が有効なら、DBポリシーがテナントを自動フィルタ。アプリ側は通常のINSERTだけでよい。
- RLSが無効な環境では、アプリ側で `WHERE customer_id = '<対象>'` を必ず付ける。条件なし書き込みは他テナントへの誤書き込みの原因になる。
安全な書き込み手順
- 事前自己確認：SELECTで対象テナント・テーブル・件数を目視してから書き込む。
- 1件テスト書き込み→確認→小バッチで進める。大量一括書き込みは禁止。
- 監査ログ：何を・いつ・何件書いたかをローカルに記録する。
- 本番ロックダウン：DELETE/TRUNCATE/DROPなど破壊的操作は事前に内容・影響範囲を示して承認を得てから実行する。
→ マルチテナント環境での1回のミスは全顧客に波及する。接続・シークレット・フィルタリングの3層が揃って初めて本番に触れてよい。
Related notes
- Agentic Commerce — ACP and Visibility into Being 'Bought by AI'
- AI Search Evaluation: The 12 Metrics — Gateway
- AI Search Evaluation ①Citation Rate — How Many URLs Are Pulled In Per Answer
- AI Search Evaluation ②Source Diversity — How Unskewed the Cited Sources Are
- AI Search Evaluation ③Accuracy Score — How Often It Answers Factual Questions Correctly
- AI Search Evaluation ④Answer Length — How Many Characters It Returns to the User on Average