Harness管理画面をCloudflare Accessで守る｜メールOTPとアクセスログ

Harness管理画面をCloudflare AccessのメールOTPで保護し、誰が入ったかをアクセスログで確認する手順です。 L Harness／IG Harnessのログイン画面へ到達する前に、許可メールだけへワンタイムPINを送ります。 許可・拒否・利用メール・時刻を確認し、Harness内の操作履歴と分けて記録します。

この記事はHarness Academyの教材データを基に、各Harnessの公式リポジトリにある実装箇所と照合して構成しています。秘密情報や本番データを記事・AIチャットへ貼らず、外部送信は必ず検証対象を限定してください。

最初に確認すること

• Harness管理画面をAccessのメールOTPで保護する: 管理画面URLを知っているだけの第三者をCloudflareの手前で止める
• 誰がHarnessへ入ったかAccessログで確認する: ログインの事実とHarness内で行った操作を混同せず、事故調査できる

Harness管理画面をAccessのメールOTPで保護する

L Harness／IG Harnessのログイン画面へ到達する前に、許可メールだけへワンタイムPINを送ります。

この工程のゴール: 管理画面URLを知っているだけの第三者をCloudflareの手前で止める

Cloudflare Accessは、HarnessのPages管理画面の外側へ置く入口です。許可されたメールアドレスへ一度だけ使えるPINを送り、認証に成功した人だけがHarnessのログイン画面へ進めます。Harness本体のスタッフAPIキー／セッション認証は残るため、二段階の入口になります。

Accessを付けるのは原則として管理画面Pagesです。Worker全体へ人間用OTPを付けると、LINE／Meta Webhook、LIFF、流入リンク、MCP、外部連携まで止まる可能性があります。APIはHarness側の署名、Bearerキー、HttpOnly cookie、CSRF、CORSで守ります。

Accessポリシーで『Login Methods = One-time PIN』だけをAllowにすると、任意の有効なメールアドレスが通れる設定になります。購入者ごとの正確なメールアドレスをIncludeへ登録し、退会・契約終了時に削除します。

独自ドメインだけをAccessで保護しても、元の*.pages.devが公開されたままなら迂回できます。独自ドメインとPages標準URLの両方を検査し、標準URLもAccess対象にするか独自ドメインへリダイレクトします。Preview URLも別設定で保護します。

手順

1. 保護対象を固定

対象のHarness、Pages project、管理画面URL、独自ドメイン、許可する利用者メールを確認します。

2. One-time PINを有効化

Zero TrustのIdentity providersでOne-time PINを追加し、メール到達を確認します。

3. 管理画面用Accessアプリを作る

Self-hosted applicationとして管理画面hostnameを登録し、Includeを購入者の正確なメールに限定します。

4. 二段階でログイン確認

未許可メール、許可メール、期限切れPIN、Harnessログイン、ログアウトを検証します。

5. 迂回経路を閉じる

pages.dev、独自ドメイン、Preview URLを直接開き、Accessなしで管理画面へ入れないことを確認します。

完了条件

• 未許可メールではHarnessログイン画面へ到達できない
• 許可メールのOTP後にHarness本体へログインできる
• Webhook・LIFF・MCP・流入リンクが止まっていない
• pages.devとPreview URLから迂回できない
• Accessログに許可・拒否が残る

注意: OTPメールのPINは10分で失効し一度だけ使用できます。新しいPINを発行すると古いPINは無効です。PINや許可メール一覧をチャットへ貼りません。

Academy教材: Harnessの入口とCloudflareを安全にする / Lesson 9-6

誰がHarnessへ入ったかAccessログで確認する

許可・拒否・利用メール・時刻を確認し、Harness内の操作履歴と分けて記録します。

この工程のゴール: ログインの事実とHarness内で行った操作を混同せず、事故調査できる

Access authentication logsでは、誰がどの管理画面へログインを試み、許可または拒否されたかを確認できます。ただし、管理画面内でどのボタンを押したかまではAccess認証ログだけでは分かりません。

Harness内の変更は、スタッフごとのAPIキー、アップデート履歴、配信・予約・Webhookなどの実装ログと突き合わせます。共用スタッフや共用APIキーを避け、利用者ごとに発行・停止できる状態にします。

調査時はメール、時刻、Access application、Ray ID、Harnessのstaff、対象アカウント、変更時刻を時系列に並べます。顧客本文やAPIキーは監査表へコピーしません。

手順

1. Accessの入場記録

Authentication logsでapplication、email、allow/deny、時刻、Ray IDを確認します。

2. Harnessの担当者を照合

スタッフ管理で個人別staffとAPIキーの有効状態を確認します。

3. 変更記録を照合

配信、シナリオ、予約、Webhook、アップデート履歴の対象と時刻を並べます。

4. 退職・契約終了処理

Access許可メール、Harness staff、MCP設定、端末内キーを同じ日に無効化します。

完了条件

• 許可・拒否を時刻付きで確認
• AccessメールとHarness staffを照合
• 入場ログと操作ログを区別
• 退会者の無効化漏れを確認

注意: AccessログだけでHarness内の操作実行者を断定しません。共用アカウントが残っている場合は個人別staffへ移行します。

Academy教材: Harnessの入口とCloudflareを安全にする / Lesson 9-7

公式ソース

• Cloudflare One / One-time PIN — OTPの設定、10分、有効回数
• Cloudflare One / Access policies — Include・Require・Excludeと危険なEveryone設定
• Cloudflare One / Common policies — OTPを正確なメール条件と組み合わせる
• Cloudflare Pages / Preview deployments — Preview URLのAccess保護
• L Harness / docs/ADMIN-AUTH.md — Harness本体のcookie・CSRF・CORS認証
• L Harness / apps/worker/src/middleware/admin-auth-config.ts — 管理画面とAPIのsame-site判定
• IG Harness / apps/web/src/app/login/page.tsx — IG Harness管理画面ログイン
• Cloudflare One / Access authentication logs — email・allow/deny・Ray ID・時刻
• Cloudflare One / Logs — プラン別のログ保持期間
• L Harness / apps/worker/src/routes/staff.ts — スタッフ作成・停止・APIキー再発行
• L Harness / apps/web/src/app/updates/page.tsx — Harnessアップデート履歴

関連ガイド

• Harnessシリーズ公式ガイド索引
• L Harness操作マニュアル