The Harness ／公式情報・ツール比較

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

· 執筆: The Harness 編集部
THE HARNESS LAB
Harness管理画面をCloudflare Accessで…

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

    公式ソース

    関連ガイド

    Academy会員はコピペ実行用プロンプトと演習を開くと、同じ手順をAIへ渡して実機で進められます。