大量アクセスによる負荷を、配信基盤で抑える
大量アクセスによるサービス停止のリスクを下げるため、公開サイトはCloudflareのネットワークを経由して配信し、標準のDDoS防御を利用しています。入口で不要な負荷を抑え、通常のページは静的ファイルとして届ける構成です。
問い合わせでは、送信頻度、Origin、リクエスト形式、必須項目と文字数をサーバー側で検証します。Turnstileのトークンもサーバーから確認し、不正な投稿や過剰な送信によって、保存やメール通知の処理が不用意に増えないようにしています。
Security design
検証・保存・通知の責務を分ける
公開する入口は絞り、問い合わせを保存してから通知します。調査用ログと本文も分けて扱います。
受付を、メール配送の一時的な失敗に依存させない
問い合わせは、D1に本文と通知状態を保存してから受付成功を返します。その後、Queuesを使って通知を非同期に処理します。メール送信に失敗した場合は上限付きで再試行し、Queueへ登録できなかった未通知分も定期処理で回収します。
Queuesへ渡すのは受付IDだけです。本文は通知処理がD1から読み取り、送信元と宛先はサーバー側で固定します。入力によって任意の宛先へメールを送れる仕組みにはしません。受付成功とメールの到達は別の状態として扱います。
問い合わせには保管と削除の方針を設けています。保存期間と委託先での取り扱いは、プライバシーポリシーで案内しています。
どこで処理が止まったかを、後から追えるようにする
受付、保存後のQueue登録、通知、再試行などの結果を、受付ID・結果コード・処理時間で記録します。Workers Observabilityのログから、一時的な失敗なのか、再試行が必要なのかを調べられるようにしています。
アプリケーションログには、問い合わせ本文、メールアドレス、IPアドレス、検証トークンを出しません。調査に必要な状態と、個人情報を含む本文を分けて扱います。問い合わせ・完了ページにはGTMを読み込まず、入力内容を解析イベントへ渡しません。
変更も、確認する環境と手順を通して公開する
変更はPull Requestで確認し、テストとビルドを通したうえで、認証付きのPreviewへ配信します。PreviewはCloudflare Accessで保護し、本番のDB・Queue・メールを使いません。公開する前に、変更の内容と画面を確認できるようにしています。
CI / CD
同じ成果物を検証してから公開する
コードの確認、品質計測、Previewでのレビューを経て、本番へ反映します。
公開範囲と、変更できる権限を小さく保つ
配信するのは、ビルドの許可リストで選んだHTMLとアセットだけです。内部文書や秘密情報は公開対象へ含めず、取得できないことも検証します。GitHub ActionsはコミットSHAとロックファイルで依存を固定し、CIの認証情報は必要な権限に限定します。
ここで紹介するのは、このコーポレートサイトで実施している対策です。機能や設定を変えるときは、扱う情報と公開範囲を改めて確認します。個人情報の取り扱いは、プライバシーポリシーでも案内しています。
