国内サーバー運用・多層防御・迷ったら閉じる

転送先の固定 ― トンネルを通り道にしない

WireCanal の最重要レイヤが 転送先の固定です。エージェントは、設定した転送先（既定はループバック）以外へは絶対に接続しません。だからトンネルが社内のオープンプロキシと化して、ほかのシステムへの通り道に使い回される、という事故を構造的に防ぎます。

入口を「専用線化」する

WireCanal の公開入口（Edge）は、正規の呼び出し元の固定 IP からのアクセスだけに限定できます。公開エンドポイントでありながら、実質は専用線。さらに呼び出し元のトークン認証が重なり、二重に守られます。「公開しているのに、公開していないに等しい」入口です。

転送先の固定を軸にした、多層防御

WireCanal は「fail-closed（迷ったら閉じる）」を前提にした多層防御です。数を掲げるより、実際に稼働している中核をそのまま並べます。目玉は 転送先の固定です。

このほか、canal ごとのアクセスログ（到達アクセスの記録・プランに応じ直近 1,000〜10,000 件・API／CSV で確認）、テナント分離（canal ごとに専用サブドメインと固有 ID・振り分けは詐称できない値で判定）、流量・停止（レート／サイズ／タイムアウトの上限、canal 単位の一時停止、社内側からの即時遮断）を備えています。

今後の対応として、監査ログの改竄検出（ハッシュチェーン）、証明書ベースの端末登録、セッション単位の人手承認（エンタープライズで個別相談）を計画しています。

アクセス保護 ― 全プランで使える

canal ごとに、公開側の入口へ 8 種類のアクセス保護をかけられます。全プランで全種類を開放しています。設定はダッシュボードの「アクセス保護」タブから（接続元／認証／公開範囲／防御動作の 4 分類）。

• check_circleIP アドレス制限 ― 許可した IP / CIDR からのアクセスだけを通す（接続ソケットの実 IP のみで判定・詐称不可）。
• check_circle国別制限 ― 列挙した国だけを許可、または列挙した国だけを拒否（ISO 3166-1 alpha-2）。
• check_circleBASIC 認証 ― ブラウザ向けのユーザー名・パスワード認証。
• check_circleBearer トークン認証 ― プログラム向けのトークン認証（複数本を併設可・BASIC とはいずれか合致で通過）。
• check_circle時間帯公開 ― 公開する曜日・時間帯を JST 固定で指定（それ以外は非公開）。
• check_circleパス制限 ― 公開する URL パスを完全一致／前方一致で限定（正規表現を使わない設計）。
• check_circle自動ブロック（fail2ban） ― 認証失敗が続く接続元を一定時間だけ自動遮断（既定 10 回/10 分 → 15 分・時間で自動解除）。
• check_circleステルスモード ― 遮断応答を一律 404 化し、canal の存在そのものを外から見えなくします。

AI（MCP）接続の認証 ― 標準プロトコルに準拠

Claude や ChatGPT などの AI サービスは、リモート MCP サーバーへの接続に OAuth による認証を要求します。 WireCanal は MCP Authorization 仕様（Model Context Protocol の認可仕様）に準拠した認可サーバーを内蔵しており、 canal を作って使う AI を選ぶだけで、標準どおりの認証つき MCP エンドポイントが手に入ります。 OAuth サーバーを自前で建てる必要はありません。事前のクライアント登録も不要（CIMD 対応）で、AI サービスは URL を出すだけで接続できます。 Claude / ChatGPT / Grok の実際の画面で接続と動作を確認済みです。

• check_circleOAuth 2.1 認可コードフロー ＋ PKCE（S256 必須） ― 認可コードの横取りを構造的に防ぎます。
• check_circleディスカバリ標準に対応 ― RFC 9728（OAuth 2.0 Protected Resource Metadata）と RFC 8414（Authorization Server Metadata）を canal ごとに応答します。AI サービス側は URL を貼るだけで認証設定を自動検出（OIDC ディスカバリ互換の応答にも対応。Claude・ChatGPT・Grok の自動検出で実証済み）。
• check_circleRFC 8707（Resource Indicators） ― アクセストークンを canal 単位に拘束（audience 検証）。1 つのトークンをほかの canal に使い回すことはできません。
• check_circleアクセストークンは短命の署名付き JWT（ES256・有効 1 時間） ― 公開鍵（JWKS）で検証するため、入口サーバーは中央に問い合わせず、その場で検証します。失効させればその時点で新しいトークンは発行されません。
• check_circleリフレッシュトークンはローテーション ＋ 再利用検知 ― 更新のたびに新しいトークンへ入れ替え、古いトークンの使い回しを検知した場合はその系列をまとめて失効します。
• check_circle事前のクライアント登録が要りません（CIMD） ― client_id にクライアントのメタデータ文書の URL を使う方式（Client ID Metadata Document）に対応。AI サービスは URL を出すだけで接続でき、登録の往復が不要です。動的登録（DCR・RFC 7591）にも対応します。
• check_circleクライアントを固定したい場合は事前発行も ― canal からクライアント ID／シークレットを自動発行できます（トークンエンドポイント認証は client_secret_post）。リダイレクト先は登録済みの URL だけを受け付けます。接続の許可は canal のオーナーが同意画面で明示的に行い、いつでも取り消せます。

アクセスログと、認証情報の非転送

アクセスログ：canal ごとに、到達したアクセスをプランに応じて直近 1,000 件（プレミアム / エンタープライズは 10,000 件）までダッシュボード（および公開 API）で確認できます。誰が・いつ・どこから来たかを、あとから追えます。ステルスモード時でも、所有者にはログ上で本来の遮断理由がそのまま記録されます。一覧は CSV でダウンロードでき、手元での集計・保管にも使えます。

認証情報の非転送：入口の認証（MCP の OAuth、またはアクセス保護の BASIC／トークン）は WireCanal が入口で検証し、その Authorization ヘッダは転送先へ渡しません。だから社内システムは認証を持たないまま手元で動かしておけばよく、「WireCanal を通したせいで認証が二重になる／すり抜ける」といったことが起きません。