社内システムのクラウド化と
セキュリティ確保

0エグゼクティブサマリ

「社内システムを AWS EC2 に置いたまま、VPNアプライアンスも専用線も買わずにどうやってセキュリティを保つか」——その設計と、手を動かす手順と、動かし続けるための運用を1冊にまとめた文書です。

答えの骨格は多層防御（Defense in Depth）です。1つの製品で守るのではなく、境界の違う4つの層をそれぞれ塞ぎます。

結論を先に：この構成が成立する条件と、成立しない条件

着手前に必ず読む：本調査で判明した「前提のズレ」

(A) synon.co.jp の現状（公開DNSの実測結果・2026-08-15時点）

(B) 2026年の改称とダッシュボード再編

既存の日本語ブログ記事・技術記事の手順は、ダッシュボードのパスがほぼ通用しません。

(C) 2026年に「もう存在しない」設定

1全体アーキテクチャと脅威モデル

現状（As-Is）と目標（To-Be）

なぜ「WARP + Tunnel のプライベートネットワーク経路」なのか

認証方式：Google Workspace SSO を採用する

なぜ Google Workspace か

重要：Cloudflare には「Google」と「Google Workspace」の2つの統合がある

採用しない選択肢と、その理由

Google Workspace 採用に伴う3つの制約（必ず理解しておくこと）

フェーズ1で守れるもの／守れないもの

2実施順序とロードマップ

依存関係があるため、この順序を守ってください。特に ① → ②（DMARC Management は Cloudflare DNS 必須）と ③ → ④（DEX は Cloudflare One Client が動いていないとテストが走らない）は絶対です。

3Step 0 — 事前準備・権限設計

棚卸し（これを飛ばすと必ず事故ります）

Cloudflare アカウントの初期設定

権限設計（50名企業の推奨割当）

Cloudflare ダッシュボードのメンバーは8名以内に抑えます。50名全員を招待する必要はありません（社内システムの「利用者」であることと、ダッシュボードのアカウントは別物です）。

API トークンの作成ルール

パス：Manage Account > API Tokens > Create Token > Create Custom Token

4Step 1 — ① DNS移管 / WAF / DDoS / SSL

目的：synon.co.jp の権威DNSを Xserver から Cloudflare に移し、WAF・DDoS防御・CDN・SSL を一気に有効化する。同時に、②DMARC Management の前提条件を満たす。

移管の48時間前にやること

# 現在のレコードを全件記録（移管後の突合に使う）
dig NS  synon.co.jp +short
dig     synon.co.jp +short
dig MX  synon.co.jp +short
dig TXT synon.co.jp +short
dig www.synon.co.jp +short
dig DS  synon.co.jp +short          # ← 空であることを確認（DNSSEC未使用）

• Xserver 管理画面から BIND形式のゾーンファイルをエクスポート（これが正となるデータ）
• 対象レコードの TTL を 300秒（5分）まで下げる。SOA の MINIMUM フィールドも下げる
• 現行で DNSSEC が有効なら、レジストラ側の DS レコードを先に削除し、TTL失効（24〜48h）を待つ → synon.co.jp は DS なしを実測済みのためこの作業は不要
• メール送信元の棚卸しが完了していること

ダウンタイムを最小化する移管順序（公式推奨）

SSL/TLS を Full (strict) にする

Origin CA 証明書の発行と設置

パス：SSL/TLS > Origin Server > Origin Certificates > Create Certificate Free 可

server {
    listen 443 ssl;
    http2 on;
    server_name synon.co.jp www.synon.co.jp;

    ssl_certificate     /etc/ssl/cloudflare/origin.pem;   # 発行された Origin Certificate
    ssl_certificate_key /etc/ssl/cloudflare/origin.key;   # 秘密鍵（発行時のみ表示。必ず保存）

    ssl_protocols       TLSv1.2 TLSv1.3;
}

sudo chmod 600 /etc/ssl/cloudflare/origin.key
sudo chown root:root /etc/ssl/cloudflare/origin.key
sudo nginx -t && sudo systemctl reload nginx

Authenticated Origin Pulls（mTLS）

パス：SSL/TLS > Origin Server > Authenticated Origin Pulls > Zone-level を On Free 可

# 段階1：まず optional で検証が動くことを確認
ssl_verify_client optional;
ssl_client_certificate /etc/nginx/certs/cloudflare-origin-pull-ca.pem;

# 段階2：動作確認後に強制へ
ssl_verify_client on;

エッジ証明書の追加オプション（すべて Free 可）

WAF：Free で実際に使えるもの

Rate Limiting（1本しか作れない）

最も価値の高い場所 = ログインエンドポイントに使います。式は http.request.uri.path eq "/wp-login.php"、しきい値は10秒あたり20リクエスト、アクションは Block（Mitigation timeout 10秒）。

Bot Fight Mode：有効にする前に必ず読むこと

DDoS 防御

Step 1 の完了確認

# NS が Cloudflare になっているか
dig NS synon.co.jp +short

# apex がプロキシ済み（Cloudflare の anycast IP）か
dig synon.co.jp +short
curl -sI https://synon.co.jp | grep -i "server\|cf-ray"     # server: cloudflare

# MX と SPF が壊れていないか（移管前後で不変であること）
dig MX  synon.co.jp +short
dig TXT synon.co.jp +short | grep spf1

# HTTP → HTTPS リダイレクト
curl -sI http://synon.co.jp | head -1                        # 301 を期待

# 証明書チェーン
openssl s_client -connect synon.co.jp:443 -servername synon.co.jp </dev/null 2>/dev/null \
  | openssl x509 -noout -issuer -subject -dates

# 最小TLSバージョン（1.1 が拒否されること）
openssl s_client -connect synon.co.jp:443 -tls1_1 </dev/null   # handshake failure を期待

# オリジン直叩きが遮断されているか（AOP 設定後）
curl -kI https://<オリジンIP>/ -H "Host: synon.co.jp"       # 400 / handshake error を期待

# 遮断ルールの動作確認
curl -sI https://synon.co.jp/xmlrpc.php                        # 403 を期待
curl -sI https://synon.co.jp/.env                              # 403 を期待

外部診断：SSL Labs（ssllabs.com/ssltest/）で A 以上を目標。

5Step 2 — ② DMARC Management

SPF の修正（現行の何が問題か）

DMARC の段階別レコード（2026年の DMARCbis 対応）

# フェーズ1：監視
v=DMARC1; p=none; rua=mailto:RUA_ID@dmarc-reports.cloudflare.net; fo=1; ri=86400; adkim=r; aspf=r

# フェーズ2：隔離
v=DMARC1; p=quarantine; sp=quarantine; rua=mailto:RUA_ID@dmarc-reports.cloudflare.net; fo=1; ri=86400; adkim=r; aspf=r

# フェーズ3：拒否
v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:RUA_ID@dmarc-reports.cloudflare.net; fo=1; ri=86400; adkim=s; aspf=r

12週間のランプアップ計画

集約レポートの読み方

MTA-STS（Cloudflare Workers で無料ホスト）

MTA-STS が守るのは synon.co.jp が受信するメール（外部 → Google Workspace の経路）です。自社が送るメールの保護ではありません。

// mta-sts policy server for synon.co.jp
const POLICIES = {
  "mta-sts.synon.co.jp": `version: STSv1
mode: testing
mx: aspmx.l.google.com
mx: alt1.aspmx.l.google.com
mx: alt2.aspmx.l.google.com
mx: alt3.aspmx.l.google.com
mx: alt4.aspmx.l.google.com
max_age: 86400
`,
};

export default {
  async fetch(request) {
    const url = new URL(request.url);
    if (url.pathname !== "/.well-known/mta-sts.txt") {
      return new Response("Not Found\n", { status: 404 });
    }
    const policy = POLICIES[url.hostname];
    if (!policy) return new Response("Not Found\n", { status: 404 });

    return new Response(policy, {
      status: 200,
      headers: {
        "Content-Type": "text/plain; charset=utf-8",   // RFC 8461 で必須
        "Cache-Control": "public, max-age=3600",
      },
    });
  },
};

やらないこと（判断の記録）

2026年の送信者要件

Step 2 の完了確認スクリプト

#!/bin/bash
D=synon.co.jp
echo "=== NS (Cloudflare移管の確認) ==="   ; dig +short NS $D
echo "=== MX (Google Workspace) ==="       ; dig +short MX $D
echo "=== SPF (1本だけであること) ==="      ; dig +short TXT $D | grep spf1
echo "=== DKIM ==="                        ; dig +short TXT google._domainkey.$D
echo "=== DMARC ==="                       ; dig +short TXT _dmarc.$D
echo "=== MTA-STS ==="                     ; dig +short TXT _mta-sts.$D
curl -sS https://mta-sts.$D/.well-known/mta-sts.txt
echo "=== TLS-RPT ==="                     ; dig +short TXT _smtp._tls.$D
echo "=== DNSSEC ==="                      ; dig +short DS $D

6Step 3 — ③ Gateway DNS フィルタ

目的：社員端末50台の DNS クエリを Cloudflare Gateway に流し、マルウェアのC2通信・フィッシング・DGA ドメインへの到達を 名前解決の段階で 遮断する。

方式選定：2つの経路と、なぜ両方使うのか

サービスモードの決定：1dot1 か warp か

Security Categories（即 Block してよい）

個別に選ばず、Security Categories in All security risks の1本で全部入ります。含まれるのは Command and Control & Botnet / Malware / Phishing / Spyware / DGA Domains / DNS Tunneling / Cryptomining / Compromised Domain / Brand Embedding / Scam など。

Content Categories（社内で揉めやすいもの）

ブロックページと証明書

パス：Zero Trust > Settings > Custom Pages > Account Gateway block page > Customize

50台へのロールアウト

MDM パラメータ（正確な値）

<dict>
  <key>organization</key>      <string>synon</string>
  <key>service_mode</key>      <string>1dot1</string>
  <key>onboarding</key>        <false/>
  <key>auto_connect</key>      <integer>1</integer>
  <key>switch_locked</key>     <false/>
  <key>display_name</key>      <string>シノン株式会社</string>
  <key>support_url</key>       <string>mailto:it-support@synon.co.jp</string>
</dict>

# Windows（Intune）サイレントインストール
msiexec /i "Cloudflare_WARP_2026.6.905.0.msi" /qn ORGANIZATION="synon" SUPPORT_URL="mailto:it-support@synon.co.jp"

デバイスプロファイル（ダッシュボード側）

パス：Zero Trust > Team & Resources > Devices > Cloudflare One Client > Configure（反映に最大10分）

動作確認

# 状態確認
warp-cli status                      # → Ok(Connected)
warp-cli -l status                   # 接続過程の詳細ログ
warp-cli settings                    # モード・プロファイルの確認
warp-diag                            # ログ・設定を一括収集

# DNSフィルタリングの実動作確認（公式手順）
dig malware.testcategory.com         # macOS/Linux
nslookup malware.testcategory.com    # Windows

日本のネットワーク環境における落とし穴

ログと労務上の配慮（実施前に必ず読む）

7Step 4 — ④ DEX 合成テスト

目的：「繋がらない」の第一報が社員からの申告になる状態をやめ、能動的に監視して先に気づく。

HTTP 合成テストの設定

パス：Insights > Digital experience > 「Tests」タブ > Add a Test

測定される指標：Resource fetch time（リクエスト全ステップの合計）/ Server response time / DNS response time / HTTP status codes

DEX rules（どの端末がテストを実行するか）

アラート設定

その他の機能

8Step 5 — ⑤ Turnstile 標準部品化

目的：(1) 自社コーポレートサイトの問い合わせフォームのスパム対策、(2) 受託案件で使い回せる標準コンポーネント化。

クライアント側（プレーンHTML）

<script src="https://challenges.cloudflare.com/turnstile/v0/api.js" async defer></script>

<form id="contact-form" action="/contact/submit" method="POST">
  <label>お名前 <input type="text" name="name" required></label>
  <label>メールアドレス <input type="email" name="email" required></label>
  <label>お問い合わせ内容 <textarea name="message" required></textarea></label>

  <div class="cf-turnstile"
       data-sitekey="0x4AAAAAAA_YOUR_SITE_KEY"
       data-language="ja"
       data-theme="auto"
       data-size="flexible"
       data-action="contact-form"
       data-appearance="interaction-only"
       data-callback="onTurnstileSuccess"
       data-error-callback="onTurnstileError"
       data-expired-callback="onTurnstileExpired"></div>

  <p id="turnstile-error" role="alert" style="color:#c00;"></p>
  <button type="submit" id="submit-button" disabled>送信する</button>
</form>

<!-- JavaScript 無効時のフォールバック導線 -->
<noscript>
  <p style="color:#c00;">
    このフォームのご利用には JavaScript が必要です。<br>
    有効にできない場合は <a href="mailto:info@synon.co.jp">info@synon.co.jp</a> またはお電話にてご連絡ください。
  </p>
</noscript>

サーバ側検証（PHP・hostname / action の検証まで含む）

<?php
declare(strict_types=1);

function verify_turnstile(string $token, ?string $remoteIp = null): array
{
    $secret = getenv('TURNSTILE_SECRET_KEY');
    if ($secret === false || $secret === '') {
        error_log('[Turnstile] TURNSTILE_SECRET_KEY is not configured');
        return ['ok' => false, 'errors' => ['missing-input-secret']];
    }
    if ($token === '') {
        return ['ok' => false, 'errors' => ['missing-input-response']];
    }

    $payload = [
        'secret'          => $secret,
        'response'        => $token,
        'idempotency_key' => bin2hex(random_bytes(16)),   // 安全なリトライ用
    ];
    if ($remoteIp !== null) { $payload['remoteip'] = $remoteIp; }

    $ch = curl_init('https://challenges.cloudflare.com/turnstile/v0/siteverify');
    curl_setopt_array($ch, [
        CURLOPT_POST           => true,          // POST のみ。GET 不可（reCAPTCHA との差分）
        CURLOPT_POSTFIELDS     => http_build_query($payload),
        CURLOPT_RETURNTRANSFER => true,
        CURLOPT_TIMEOUT        => 10,
        CURLOPT_SSL_VERIFYPEER => true,
    ]);
    $raw = curl_exec($ch); $errNo = curl_errno($ch); curl_close($ch);

    if ($errNo !== 0 || $raw === false) {
        return ['ok' => false, 'errors' => ['internal-error']];
    }
    $result = json_decode((string) $raw, true);
    if (!is_array($result)) {
        return ['ok' => false, 'errors' => ['bad-request']];
    }
    if (($result['success'] ?? false) !== true) {
        return ['ok' => false, 'errors' => $result['error-codes'] ?? ['unknown']];
    }

    // ★ hostname / action のサーバ側検証（必須級）
    $allowedHosts = ['synon.co.jp', 'www.synon.co.jp'];
    if (!in_array($result['hostname'] ?? '', $allowedHosts, true)) {
        error_log('[Turnstile] hostname mismatch: ' . ($result['hostname'] ?? ''));
        return ['ok' => false, 'errors' => ['hostname-mismatch']];
    }
    if (($result['action'] ?? '') !== 'contact-form') {
        return ['ok' => false, 'errors' => ['action-mismatch']];
    }
    return ['ok' => true, 'errors' => []];
}

エラーコードと対処

開発用テストキー（受託案件の自動テストに組み込む）

受託案件への標準化（納品物としての整備）

• サイトキー／シークレットキーの管理場所と、ローテーション手順
• action の値と、その意味（フォームごとの一覧）
• 許可ホスト名（Hostname Management の登録内容）
• サーバ側検証の実装箇所とエラーハンドリングの仕様
• エラーコードごとの表示文言（顧客のブランドトーンに合わせる）
• JavaScript 無効時のフォールバック導線（メール・電話）
• Turnstile Analytics の見方（solve rate / challenge rate）
• React を使う場合は「@marsidev/react-turnstile はコミュニティ製であり、Cloudflare 公式の React パッケージは存在しない」ことを明記（メンテナンス停止リスクの共有）

CSP 設定とよくあるクライアント側エラー

script-src  https://challenges.cloudflare.com;
frame-src   https://challenges.cloudflare.com;
connect-src 'self';   /* Pre-clearance 使用時のみ */

9Step 6 — ⑥⑦⑧ Analytics / Cache / Security Center

Step 1（DNS移管）が完了していれば、この3つは合わせて1時間程度で完了します。

⑥ Web Analytics

パス：ダッシュボード（アカウントレベル） > Web Analytics > Add a site

プロキシ済みゾーンなら、ドロップダウンからホスト名を選んで Done するだけです（自動セットアップが既定で有効）。JSビーコンは Cloudflare が自動注入するため、オリジン側のコード変更は不要です。

両方使うのが正解です。副次的メリットとして、プロキシ済みなら送信先が自ドメインの /cdn-cgi/rum になるため、広告ブロッカーによる遮断を受けにくいです。

⑦ Tiered Cache

パス：Caching > Tiered Cache → トグルを On Free 可

Smart Tiered Cache は Free でも利用できます。レイテンシデータを用いてオリジンごとに最も近い上位層を1つ自動選択し、AWS / GCP / Azure のクラウドリージョンヒントに対応しているため、EC2 オリジンと相性が良い機能です。有効化しない理由がほぼありません。

# 1. 静的アセットの長期キャッシュ
(http.request.uri.path.extension in {"css" "js" "woff2" "woff" "svg" "png" "jpg" "jpeg" "webp" "avif" "ico"})
→ Eligible for cache / Edge TTL: 1ヶ月 / Browser TTL: 1週間

# 2. 静的HTMLページのエッジキャッシュ（頻繁に更新しないページのみ）
(http.request.uri.path eq "/" or starts_with(http.request.uri.path, "/company/")
 or starts_with(http.request.uri.path, "/service/"))
→ Edge TTL: 1〜4時間 / Browser TTL: respect origin
   # ※ 更新時にパージが必要。運用者に周知すること

# 3. 管理画面・APIのキャッシュ除外（明示的に）
(starts_with(http.request.uri.path, "/wp-admin") or starts_with(http.request.uri.path, "/api/")
 or http.cookie contains "wordpress_logged_in")
→ Bypass cache

⑧ Security Center

10Step 7 — Zero Trust 接続基盤（WARP + Tunnel）

目的：社内Webシステム（10.0.1.10:443）への到達経路を、AWS Client VPN から Cloudflare 経由に置き換える。EC2 のインバウンドは一切開けない。

EC2 のアウトバウンド要件

# 疎通のプレチェック（cloudflared 2026.5.2 以降は起動時に自動実行）
cloudflared tunnel diag
# DNS解決 / UDP・TCP 7844 疎通 / 管理API到達性を検査し、
# 「両方成功＝quic/http2どちらも可」「UDPのみ」「TCPのみ」「両方失敗＝パケットドロップ」を判定

cloudflared のインストール

# Amazon Linux 2023 / RHEL 系
curl -fsSl https://pkg.cloudflare.com/cloudflared.repo | sudo tee /etc/yum.repos.d/cloudflared.repo
sudo yum update -y
sudo yum install -y cloudflared
cloudflared --version

# Ubuntu / Debian
sudo mkdir -p --mode=0755 /usr/share/keyrings
curl -fsSL https://pkg.cloudflare.com/cloudflare-main.gpg \
  | sudo tee /usr/share/keyrings/cloudflare-main.gpg >/dev/null

echo 'deb [signed-by=/usr/share/keyrings/cloudflare-main.gpg] https://pkg.cloudflare.com/cloudflared any main' \
  | sudo tee /etc/apt/sources.list.d/cloudflared.list

sudo apt-get update && sudo apt-get install -y cloudflared

トンネルの作成：Remotely-managed を推奨

# ヘルスチェック
cloudflared tunnel info synon-aws-vpc-01
curl -s http://127.0.0.1:20241/metrics | grep -E 'cloudflared_tunnel_(ha_connections|total_requests|request_errors)'
# 監視は cloudflared_tunnel_ha_connections（正常時は 4/レプリカ）が 2 未満でアラート

# CIDR ルートの追加
cloudflared tunnel route ip add 10.0.1.0/24 synon-aws-vpc-01
cloudflared tunnel route ip show
cloudflared tunnel route ip get 10.0.1.10        # どのトンネルにルーティングされるか
cloudflared tunnel route ip delete 10.0.1.0/24   # ロールバック時

認証：Google Workspace SSO の構成

作業は Google Cloud Console → Google Admin Console → Cloudflare の3か所にまたがります。順序を守ってください。特に「Cloudflare で保存した後に生成されるリンクを Google Workspace 管理者が開いて認可する」ステップは最も脱落しやすく、これを飛ばすとグループが一切取得できません。

① Google Cloud Console 側（所要20分）

英語UI / 日本語UI 対訳

② Google Admin Console 側（所要5分・忘れやすい）

パス：https://admin.google.com → Security > Access and data control > API controls > Settings > Internal apps → 「Trust internal apps」にチェック

③ Cloudflare 側（所要10分）

パス：Zero Trust > Integrations > Identity providers > Add new identity provider > Google Workspace

# API で作成する場合（POST /accounts/{account_id}/access/identity_providers）
# 必要トークン権限: Access: Organizations, Identity Providers, and Groups Write
{
  "config": {
    "client_id": "<your client id>",
    "client_secret": "<your client secret>",
    "apps_domain": "synon.co.jp"
  },
  "type": "google-apps",
  "name": "Google Workspace (synon.co.jp)"
}

④ Google グループの設計

パス：Google Admin Console > ディレクトリ > グループ

⑤ デバイス登録権限

パス：Zero Trust > Team & Resources > Devices > Device profiles > Management > Device enrollment > Device enrollment permissions > Manage

Policies タブ

Login methods タブ：Google Workspace ✅ ON ／ One-time PIN ✅ ON（削除しない）／ Apply instant authentication ❌ OFF

⑥ break-glass アカウントの設計

⑦ 典型的な失敗と対処

⑧ 既に One-time PIN で運用開始している場合の移行手順

新規構築であれば上記の手順で最初から Google Workspace を構成すれば済みます。既に OTP で50台を展開済みの場合は、以下の並走カットオーバーで移行してください。

# 全員に再認証させる最も軽い方法（いずれか）
① ブラウザで https://synon.cloudflareaccess.com/cdn-cgi/access/refresh-identity を開く
   → セッションがリセットされ、最新のグループ情報が取得される（推奨）
② Cloudflare One Client の Profile > Account information > Re-authenticate
   （v2026.1 以前は Preferences > Account > Re-Authenticate Session）
③ Access 保護アプリからログアウトして再ログイン

シートは再消費されません。シートはユーザー（メールアドレス）単位で消費されるため、OTP でも Google Workspace でも user@synon.co.jp は同一ユーザーとして扱われます。ただし Phase 4 で必ず実測確認してください。

Split Tunnel —— この構成の最重要設定

Gateway ネットワークポリシー

前提：Zero Trust > Traffic policies > Proxy で TCP を ON（必須）、UDP・ICMP も推奨。これを ON にしないと Network ポリシーが評価されません。また identity セレクタを使うには、クライアントを Traffic and DNS モードで展開している必要があります（1dot1 では機能しません）。

# 順位1: 許可（グループベース）
curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/gateway/rules" \
  --request POST \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --json '{
    "name": "Allow internal-app-users to internal app",
    "description": "Google Workspace group based access to the internal web app on EC2",
    "enabled": true, "precedence": 100, "action": "allow", "filters": ["l4"],
    "traffic": "net.dst.ip in {10.0.1.0/24} and net.dst.port in {443}",
    "identity": "any(identity.groups.name[*] in {\"internal-app-users\"})"
  }'

# 順位2: キャッチオール遮断
curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/gateway/rules" \
  --request POST \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --json '{
    "name": "Block all other private network access",
    "enabled": true, "precedence": 900, "action": "block", "filters": ["l4"],
    "traffic": "net.dst.ip in {10.0.0.0/8}"
  }'

Gateway で使えるグループ系セレクタと式

デバイスポスチャ（段階導入）

社内アプリの名前解決

疎通確認：ping / traceroute を使ってはいけない

# 端末側の WARP 状態
warp-cli -l status              # → "Connected" / "Your Internet is protected"
warp-cli settings               # モードが Traffic and DNS であること
warp-cli registration show      # 登録状態とチーム名（synon）

# 正しい疎通確認（ping ではなく TCP で）
curl -vk https://10.0.1.10
curl -I  https://app.internal.synon.co.jp
nc -zv 10.0.1.10 443                        # Linux/macOS
Test-NetConnection 10.0.1.10 -Port 443      # Windows

# 経路の確認
netstat -rn | grep 10.0.1                   # macOS
ip route get 10.0.1.10                      # Linux
route print | findstr 10.0.1                # Windows

障害切り分けチェックリスト（公式10ステップ準拠）

1. Cloudflare One Client が Connected か
2. Insights > Logs > DNS query logs にプライベートホスト名のクエリがあるか
3. Insights > Logs > Network logs に宛先IP 10.0.1.10 が出ているか
4. ユーザーメール・イベント "Blocked"・時間帯で絞り、Gateway ポリシーで落ちていないか
5. 意図したポリシーがマッチしているか（評価順序。Allow が Block の上にあるか）
6. Traffic policies > Proxy で TCP・UDP・ICMP が有効か
7. トンネルのログストリームにリクエストが届いているか
8. cloudflared ホスト（EC2）から直接アプリへ到達できるか → ここで失敗するなら Cloudflare は無関係。EC2 間の SG / OS ファイアウォールの問題
9. アプリサーバ側のローカルファイアウォールが cloudflared の送信元IPを弾いていないか
10. TLS 検査が問題を起こしていないか（自己署名証明書の場合は Do Not Inspect ポリシー、または noTLSVerify: true）

11Step 8 — 移行と切り戻し

ロールバック手順

第1部の完了チェックリスト

Step 0 事前準備

• 棚卸し（DNSレコード / メール送信元 / 自宅LAN / オフィスIP / 既存VPN / 顧客契約制約）
• Cloudflare アカウントを共有可能なアドレスで作成
• 全メンバーの2FA有効化、2FA Enforcement を ON
• ロール割当（Super Admin は2名まで、メンバーは8名以内）
• API トークン（TTL 90日 / IP制限 / Secrets Manager 保管）

Step 2-A 先行実施（DNS移管を待たない）

• Google Workspace の DKIM 有効化（2048bit / セレクタ google）
• SPF 修正（include:_spf.google.com 追加、mx と冗長な a: を削除、1本にまとめる）
• TLS-RPT 設定

Step 1 ① DNS移管

• TTL を300秒に下げて48時間待機、ゾーンファイルをエクスポート
• Cloudflare にゾーン追加、レコードをインポートして MX/SPF/DKIM/DMARC を目視確認
• 全レコードをグレー雲で登録 → NS変更 → Active → Universal SSL 確認
• オリジンで Cloudflare IP レンジを許可 → apex/www をオレンジ雲へ
• SSL/TLS を Full (strict) に、Origin CA 証明書を設置、AOP を optional→on
• Always Use HTTPS / Automatic HTTPS Rewrites / Min TLS 1.2 / HSTS 1ヶ月から
• Custom Rules 5本（管理画面制限 / xmlrpc / 社内パス / 機微ファイル / 予備）
• Rate Limiting 1本（ログインパス）
• Bot Fight Mode の判断（API があるなら OFF）

Step 6 ⑥⑦⑧

• Web Analytics 追加（no-transform ヘッダがないことを確認）
• Tiered Cache を On、Always Online を On、Cache Rules 3本
• Security Center の週次レビューを運用カレンダーに登録

Step 2-B ② DMARC Management

• Email > DMARC Management > Enable
• dig で rua が正しく（セミコロン付きで）入ったか確認
• Google Postmaster Tools に登録
• 12週ランプアップの判定基準を運用台帳に記載

Step 7 Zero Trust基盤

• EC2 SG アウトバウンド（TCP/UDP 7844 + TCP 443）、NACL 使用時はエフェメラルポートも
• cloudflared 導入、tunnel diag で疎通確認
• Networking > Tunnels でトンネル作成、service install
• 2台目（別AZ）に同一トークンで install → tunnel info で2件確認
• Networking > Routes に 10.0.1.0/24 を追加
• GCP: プロジェクト作成 → Admin SDK API 有効化 → OAuth同意画面(Internal) → OAuthクライアント作成
• GCP: redirect URI が https://synon.cloudflareaccess.com/cdn-cgi/access/callback と完全一致
• GCP: Client secret をパスワードマネージャに保存（再表示不可）／Contact は共有メールボックス
• Google Admin: Security > API controls > Settings > Internal apps > Trust internal apps を ON
• Google Admin: グループ internal-app-users@synon.co.jp を作成（表示名も同一・直接メンバー）
• Cloudflare: Identity providers に Google Workspace を追加（App ID / Secret / synon.co.jp）
• Cloudflare: 生成リンクを Google Workspace 管理者が開いて認可 → Test でグループが返ることを確認
• get-identity でグループの実データ形式（name/email/id）を確定
• Device enrollment: Emails ending in @synon.co.jp + Require Login Methods = Google Workspace
• Device enrollment: break-glass 1名の OTP 例外を追加
• Login methods: Google Workspace ON / One-time PIN ON / Apply instant authentication OFF
• break-glass アカウントで OTP ログインを実地確認
• Split Tunnels を Include モードに変更、6エントリを登録
• Traffic policies > Proxy で TCP/UDP/ICMP を ON
• Network ポリシー2本（Allow: User Group Names = internal-app-users → Block: 10.0.0.0/8 キャッチオール）
• Allow ポリシーに Enforce Cloudflare One Client session duration = 24h0m0s を設定
• Split Tunnel Include に accounts.google.com / www.googleapis.com を追加
• DNS に app.internal（DNS only / グレー雲）を追加、DNS-01 で証明書取得
• ポスチャ3種を作成し、まず観測のみ（1〜2週）

Step 3 ③ Gateway DNS フィルタ

• パイロット5台に手動インストール（1dot1）、macOSのダイアログと承認ペイロードを採取
• Security Categories = All security risks を Block
• 労使周知（説明会＋書面）、就業規則・規程の改定手続き開始
• MDM で残り45台へ配布、Captive portal detection を有効化
• Allowlist と Content Categories（Allow で監視）を追加
• 6週後に Content Categories を Block へ切替
• 段階2：service_mode を warp へ移行、証明書を配布

Step 4 / Step 5 / Step 8

• DEX HTTP テスト（15分間隔）、DEX rules で10台に限定
• DEX Traceroute テスト（10.0.1.10）※ warp モード移行後
• DEX Test Low Availability アラート（SLO 98.0）
• Turnstile を自社問い合わせフォームに適用（hostname / action のサーバ側検証まで）
• テストキー3種で自動テストを整備、受託標準テンプレート＋設計書記載項目を整備
• パイロット1週 → 全社展開2〜3週（Client VPN 併存）
• Client VPN 接続数ゼロを2週間確認 → Association のみ解除 → 1ヶ月後に削除

12この構成の運用を規定する「3つの制約」と体制

運用体制

13運用 — シート管理（最も高い運用リスク）

自動シート回収の有効化（必ず設定する）

パス：Zero Trust > Settings > Admin controls > Remove inactive users from seats

設定値は 1ヶ月〜1年で指定可能 → 推奨は 2〜6ヶ月（産休・育休・長期出張を考慮）。認証イベントと全デバイスの Last seen を毎日チェックし、指定期間非アクティブなユーザーのシートを自動解放します。

月次シート棚卸し

実施日：毎月第1営業日 / 所要：30分 / 担当：インフラ管理者（副）/ 承認：管理部門長

• Zero Trust > Team & Resources > Users でユーザー一覧を記録（またはAPIで取得）
• 現在の消費シート数を記録し、50 − 消費数 = 残枠 を算出
• 🔴 残枠が5未満なら即エスカレーション（管理部門長へ。翌月の入社予定者数と突合）
• 人事の在籍者名簿（当月1日時点）と Users 一覧を突合
• 在籍者名簿にない全ユーザーをリストアップ（退職者・元業務委託者・テストアカウント）
• Action > Remove users > Remove で削除。削除前に対象一覧をスクリーンショット保管（監査証跡）
• Last seen が60日以上前のユーザーを抽出 → 在籍・利用実態を確認 → 不要なら Remove
• Team & Resources > Devices で、在籍者に紐づかないデバイス登録を削除
• Manage Account > Audit Logs で当月の設定変更を確認
• 結果を運用台帳に記録し、管理部門長が確認署名

退職者オフボーディング（退職日当日・所要45分）

予防設定（在職中）：Lock WARP switch（ユーザーによるON/OFF禁止）、Allow device to leave organization を無効（勝手な組織離脱を禁止）、Auto connect を設定。

14運用 — ログの外部退避

必要なAPIトークンのスコープ

退避スクリプト（EC2 cron 想定・動作する形）

#!/usr/bin/env python3
# /opt/cf-export/export.py    cron: 0 */6 * * * /usr/bin/python3 /opt/cf-export/export.py
import os, sys, json, gzip, time, pathlib, datetime as dt
import urllib.request, urllib.error

API   = "https://api.cloudflare.com/client/v4"
TOKEN = os.environ["CF_API_TOKEN"]
ACCT  = os.environ["CF_ACCOUNT_ID"]
ZONE  = os.environ["CF_ZONE_ID"]
OUT   = pathlib.Path(os.environ.get("CF_EXPORT_DIR", "/var/log/cf-export"))

WINDOW_HOURS = 8   # 保持24hのため8時間分（cron 6時間毎＝2時間オーバーラップ）
now   = dt.datetime.now(dt.timezone.utc).replace(microsecond=0)
start = now - dt.timedelta(hours=WINDOW_HOURS)
ISO   = lambda d: d.strftime("%Y-%m-%dT%H:%M:%SZ")


def _req(url, method="GET", body=None):
    req = urllib.request.Request(url, method=method)
    req.add_header("Authorization", f"Bearer {TOKEN}")
    req.add_header("Content-Type", "application/json")
    data = json.dumps(body).encode() if body is not None else None
    for attempt in range(5):                        # 429/5xx は指数バックオフ
        try:
            with urllib.request.urlopen(req, data, timeout=60) as r:
                return json.loads(r.read())
        except urllib.error.HTTPError as e:
            if e.code in (429, 500, 502, 503, 504) and attempt < 4:
                time.sleep(2 ** attempt * 5); continue
            sys.stderr.write(f"[ERROR] {url} -> {e.code} {e.read()[:500]}\n")
            raise
    raise RuntimeError("unreachable")


def write(name, records):
    """日付階層で gzip JSONL 保存。S3側で Object Lock + ライフサイクルを掛ける前提。"""
    d = OUT / now.strftime("%Y/%m/%d")
    d.mkdir(parents=True, exist_ok=True)
    path = d / f"{name}_{now.strftime('%H%M%SZ')}.jsonl.gz"
    with gzip.open(path, "wt", encoding="utf-8") as f:
        for rec in records:
            f.write(json.dumps(rec, ensure_ascii=False) + "\n")
    print(f"[OK] {path} ({len(records)} records)")
    return path


def account_audit_logs():
    """アカウント監査ログ v2（保持18ヶ月 / 権限: Account Settings Read）"""
    recs, page = [], 1
    while True:
        url = (f"{API}/accounts/{ACCT}/logs/audit"
               f"?since={ISO(start)}&before={ISO(now)}&per_page=1000&page={page}")
        batch = _req(url).get("result") or []
        recs += batch
        if len(batch) < 1000:
            break
        page += 1
    return recs


def access_audit_logs():
    """Access 認証ログ（保持24h / 権限: Access: Audit Logs Read）"""
    url = (f"{API}/accounts/{ACCT}/access/logs/access_requests"
           f"?since={ISO(start)}&until={ISO(now)}&direction=desc&limit=1000")
    return _req(url).get("result") or []


def graphql(query, variables):
    res = _req(f"{API}/graphql", "POST", {"query": query, "variables": variables})
    if res.get("errors"):
        sys.stderr.write(f"[GraphQL ERROR] {json.dumps(res['errors'], ensure_ascii=False)}\n")
    return res.get("data") or {}


Q_GATEWAY_DNS = """
query($acct:string!,$s:Time!,$e:Time!){ viewer{ accounts(filter:{accountTag:$acct}){
  gatewayResolverQueriesAdaptiveGroups(limit:10000,
    filter:{datetime_geq:$s, datetime_leq:$e}, orderBy:[count_DESC]){
    count dimensions{ queryNameReversed resolverDecision datetimeHour }
}}}}"""


def main():
    OUT.mkdir(parents=True, exist_ok=True)
    failures = []

    for name, fn in [("account_audit", account_audit_logs),
                     ("access_audit",  access_audit_logs)]:
        try:
            write(name, fn())
        except Exception as ex:
            failures.append(f"{name}: {ex}")

    try:
        d = graphql(Q_GATEWAY_DNS, {"acct": ACCT, "s": ISO(start), "e": ISO(now)})
        write("gateway_dns", d["viewer"]["accounts"][0]["gatewayResolverQueriesAdaptiveGroups"])
    except Exception as ex:
        failures.append(f"gateway_dns: {ex}")

    if failures:
        # 🔴 保持24時間のため、静かに失敗すると証跡が永久に消える。必ず気づける形にする。
        sys.stderr.write("[FAILED] " + " | ".join(failures) + "\n")
        sys.exit(1)


if __name__ == "__main__":
    main()

15運用 — 監視とアラート

通知の配信経路（Free の壁）

Free で設定できるアラート

パス：Notifications → Add → 種別選択 → 宛先入力 → Create

認証異常の検知（自作が必須）

Access の不審ログインを通知する Cloudflare ネイティブのアラートは Free にはありません。退避スクリプトを拡張して自前で検知します。

16運用 — インシデント対応 / break-glass

(b) 不審なログイン（Google アカウント侵害）【Sev2】

検知：自作アラート（第15章）／ Google Admin Console のセキュリティ アラート ／ 本人からの「身に覚えのないログイン通知」

一次対応（15分以内・順序厳守）

1. Google Admin Console でアカウント即時停止＋全セッション強制ログアウト（これが最優先）
2. Users → 対象 → Action > Revoke > Revoke sessions ← 🔴 手順1だけでは Cloudflare は切れません
3. Devices → 身に覚えのないデバイス登録を Delete
4. Manage Account > Audit Logs → 当該期間にダッシュボード操作がないか確認（あれば管理者権限侵害 = Sev1 に格上げ）
5. Manage Account > API Tokens → 不審な新規トークンがないか確認、あれば即削除
6. 退避済みログから当該ユーザーの直近アクセス先を洗い出し、情報持ち出しの有無を評価
7. Google 側の証跡も確保（Admin Console > レポート > 監査と調査 > ログインログ）。Cloudflare のログは Free で24時間しか残らないため、Google 側のログのほうが長く残ります

復旧：Google パスワードリセット ＋ 2SV の再登録（セキュリティキー必須化）→ 端末のマルウェアスキャン → アカウント再有効化 → Cloudflare 側で再認証させてグループが正しく載ることを確認

エスカレーション：管理部門長 → 顧客データへのアクセス痕跡があれば即・経営会議（受託開発では顧客への報告義務が契約上生じる可能性が高い）

事後：check_session の設定値が妥当か再評価。個人データ漏えいの疑いがあれば第18章の法令フローへ

(c) マルウェア感染端末の検知【Sev2】

1. Gateway ログで Device ID / User email / 宛先ドメイン / 発生時刻・頻度を特定（PII表示には Zero Trust: PII Read が必要）
2. 単発か継続かを判定（継続的なビーコン通信は感染確定に近い）
3. 同一宛先に他の端末も通信していないか（横展開の確認）
4. 該当端末をネットワークから物理的に隔離（有線抜線・Wi-Fi切断）。🔴 電源は落とさない（メモリ上の証跡が消えるため）
5. 利用者からヒアリング → セッションを Revoke → EDR / ウイルス対策でフルスキャン
6. 駆除が確認できても、業務端末は原則クリーンインストール。当該ユーザーの全パスワード・トークンをリセット

(d) Cloudflare 自体の障害【Sev1・自社で復旧不能】

# 自社起因か Cloudflare 起因かを2分で判定
curl -s https://www.cloudflarestatus.com/api/v2/status.json | jq '.status, .page.updated_at'
curl -sv --resolve app.synon.co.jp:443:<オリジンIP> https://app.synon.co.jp/healthz
# オリジンが正常応答するのに Cloudflare 経由が 5xx なら Cloudflare 起因確定

(f) break-glass（Cloudflare 障害時の代替経路）

(e) DDoS 攻撃【Sev2】

1. Unmetered DDoS Protection は Free でも有効。L3/L4 は基本的に自動緩和される
2. Under Attack Mode を有効化 —— Free で使える最強の緊急手段（ゾーン Overview > Quick Actions）
3. Rate Limiting Rule（1本）で該当パスを保護
4. 全レコードが Proxied（オレンジ雲）であることを確認 —— グレー雲だとオリジンIPが露出し、Cloudflare を迂回して直撃される
5. オリジンの SG でインバウンド443を Cloudflare の公開IPレンジのみに制限（未実施なら平時に必ず設定）

17運用 — 定常運用カレンダー

18運用 — 法令・社内規程（日本）

従業員の通信ログ取得（個人情報保護委員会 Q5-7 の5要件）

個人情報保護法：越境移転が最大の論点

規程／プライバシーポリシーへの記載例

※ Cloudflare は「メタデータは米国およびEUのデータセンターに保存され得る」旨を公表しています。「保存国が完全には特定できない」ケースに該当し得るため、上記③の書き方を併用するのが安全です。

漏えい等発生時の報告義務

情報セキュリティ基本方針への反映

19運用 — SLA・SPOF・投資判断

SLA の正確な事実

20導入初期に必ず実機検証すべき未確定事項

主要な参照先

Cloudflare 公式

• Cloudflare One（Zero Trust）: developers.cloudflare.com/cloudflare-one/
• Zero Trust ログ保持期間: developers.cloudflare.com/cloudflare-one/insights/logs/
• シート管理: developers.cloudflare.com/cloudflare-one/team-and-resources/users/seat-management/
• Split Tunnels: developers.cloudflare.com/cloudflare-one/team-and-resources/devices/cloudflare-one-client/configure/route-traffic/split-tunnels/
• Tunnel（プライベートネットワーク）: developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/private-net/
• MDM パラメータ: developers.cloudflare.com/cloudflare-one/team-and-resources/devices/warp/deployment/mdm-deployment/parameters/
• Google Workspace IdP 連携: developers.cloudflare.com/cloudflare-one/integrations/identity-providers/google-workspace/
• 汎用 Google（グループ非対応）: developers.cloudflare.com/cloudflare-one/integrations/identity-providers/google/ / One-time PIN: .../one-time-pin/
• Gateway の identity セレクタ: developers.cloudflare.com/cloudflare-one/traffic-policies/identity-selectors/
• セッション管理: developers.cloudflare.com/cloudflare-one/access-controls/access-settings/session-management/
• デバイス登録: developers.cloudflare.com/cloudflare-one/team-and-resources/devices/device-registration/
• Google: OAuth クライアントの管理（6ヶ月未使用削除・シークレットのローテーション）: support.google.com/cloud/answer/15549257
• Google: 内部アプリ／サードパーティアプリのアクセス制御: knowledge.workspace.google.com/admin/apps/control-which-apps-access-google-workspace-data
• DEX: developers.cloudflare.com/cloudflare-one/insights/dex/ / DMARC Management: developers.cloudflare.com/dmarc-management/
• Turnstile: developers.cloudflare.com/turnstile/ / WAF: developers.cloudflare.com/waf/ / SSL: developers.cloudflare.com/ssl/
• 通知 / Webhook: developers.cloudflare.com/notifications/get-started/configure-webhooks/
• 障害報告: blog.cloudflare.com/18-november-2025-outage/ / blog.cloudflare.com/5-december-2025-outage/
• Cloudflare Status API: www.cloudflarestatus.com/api / APPI 対応: www.cloudflare.com/trust-hub/appi/

日本語・公的機関

• IPA 中小企業の情報セキュリティ対策ガイドライン 第4.0版: www.ipa.go.jp/security/guide/sme/about.html
• 経済産業省／IPA サイバーセキュリティ経営ガイドライン Ver3.0: www.meti.go.jp/policy/netsecurity/downloadfiles/guide_v3.0.pdf
• 個人情報保護委員会 Q5-7（従業者モニタリング）/ Q7-53（クラウド例外）/ Q10-25（外的環境の把握）: www.ppc.go.jp/all_faq_index/
• 同 漏えい等報告の義務化: www.ppc.go.jp/news/kaiseihou_feature/roueitouhoukoku_gimuka/
• 総務省 DMARC ガイドライン案: www.soumu.go.jp/main_content/000941399.pdf
• JPCERT/CC インシデント報告: form.jpcert.or.jp/ / Google 送信者ガイドライン: support.google.com/a/answer/81126

用語集