Account boundaries
ドメインとアプリの運用境界
公開入口とメール送信は既存側、サイトと問い合わせ・OCRの処理は専用側に置きます。
変更の責任をどこに置くか
コーポレートサイトを更新するたびに、会社のDNSやメールを管理する権限まで必要になると、認証情報の漏えいや設定ミスの影響が広がります。一方、サイトと一緒に提供するOCRは、利用量に応じて費用が変わります。そこで、会社のドメインを管理するアカウントと、コーポレートサイトを運用するアカウントに責務を分けました。
既存側はDNS、公開入口のWorker、送信ドメインと通知メールの送信を管理します。専用側はサイトの配信、問い合わせの保存と通知処理、OCR、レビュー用Previewを管理します。
配信権限と利用上限
専用側のCIに渡す権限は、配信とアプリのリソース操作に絞っています。DNSの編集権限は含めません。公開入口を更新するジョブには既存側の資格情報が必要なので、入口用とアプリ用を分けています。本番の中継、Previewの閲覧、CIのデプロイも用途ごとに認証を分けています。アカウントを分けたうえで、各資格情報に許可する操作を決めるのがセキュリティ上の要点です。 Cloudflareのアカウントロール
OCRでは日次の実行回数をアプリで制御し、AI Gatewayでは用途別の予算ルールを設定しています。回数制限は受付件数を抑える仕組みで、GatewayのルールはAI利用の推定費用を対象とします。Workersの基本料金やメール送信などを含めた請求全体は別に確認します。製品の利用枠がどの単位で適用されるかも、製品ごとに確認します。
分けきれなかった責務
公開ドメインを既存側で管理するため、公開入口から専用側のアプリへ認証付きHTTPSで中継しています。公開経路には二つのWorkerと、その間の認証が関わります。障害時は入口とアプリの応答を切り分け、認証情報の更新は両側の設定を揃える必要があります。
問い合わせの受付と通知の再試行は専用側に置きました。送信ドメインのDNSを既存側に置く構成では、Cloudflare Email Sendingの送信設定も既存側に属します。そのため専用側から既存側の送信APIを呼び、問い合わせが保存されたかと、通知が届いたかを別々に確認します。 Email Serviceのドメイン設定
どんなときに分けるか
プロジェクトごとに配信権限や予算の管理者を変えたいなら、アカウント境界を設ける意味があります。管理者と予算が共通で、処理やデプロイだけを分けたい場合は、同一アカウント内でWorkerを分け、Service Bindingsで接続できます。PixelCatでは、ドメインを管理する権限とサイトの配信権限を分けるために、アカウント間の中継とメール送信の依存を受け入れました。 Cloudflare Service Bindings
