セキュリティおよびデータ取り扱い

TgWitnessは、ご自身のコンピュータまたはサーバー上で動作します。アカウントの接続、公開プロキシリストの維持管理、およびオプションの外部サービスについては、 明確なルーティングポリシーが定められています。通知、タイムスタンプ、オフサイトコピー、および証人機能は、 個別に設定されます。このページでは、何がどのように保護され、何が 運用者に委ねられているかを一覧で示しています。

脆弱性に関する報告については、セキュリティポリシーをご参照ください。

アクセスモデル#

メインパネルのトークンにより、完全な制御権が与えられます。他のユーザーには、対象を 限定したアクセス権を付与することができます。具体的には、選択したワークスペースやチャット、権限、有効期限、 IP制限、ログイン制限、および取り消し可能なセッションなどです。チャット限定のアクセス権を持つユーザーは、 たとえ権限にチェックが入っていても、ワークスペース全体の操作を行うことはできません。 ワークスペースはプロセスを共有しており、ホスト管理者からデータを隔離することはありません。

パネルはデフォルトでlocalhostをリッスンします。ブラウザでのサインインにより、アクセストークンが セッション認証情報と交換され、ブラウザはこれをベアラートークンとして送信します。これは、 認証クッキーではなく、sessionStorageに保存されます。ロックまたはサインアウトを行うと、 ブラウザのセッションがクリアされます。ブラウザを閉じたりセッションを終了したりしても、データの収集は停止しません。

発行されたトークンおよびセッション認証情報は、暗号化された保管庫内にハッシュとして保存されます。 失効処理を行うと、関連するセッションは終了します。権限の変更は、その後の リクエストに反映されます。ダウンロードされたファイルは取り消すことができません。管理者は 自身のブラウザセッションを制限することもできますが、メインパネルのトークンを直接使用するスクリプトは 完全なアクセス権を維持し、それらのブラウザセッションの制限をバイパスします。

認証失敗については、クライアントアドレスごとにレート制限が適用されます。IP制限には、 アプリケーションが認識するアドレスが使用されます。これを利用する前に、 リバースプロキシの動作を確認してください。Witnessの認証情報は、読み取り専用のチェックポイント／ヘルス認証情報として別途管理されています。

デモへのアクセス#

/api/demo-accessは、明示的に 開始された隔離された合成デモ用の、意図的に認証されていないブートストラップです。これは、プロセス存続期間に有効な個別の機能を発行しますが、 実際のパネルトークンやTGWITNESS_TOKENのオーバーライドを発行することは決してありません。 この機能の発行および使用には、 ループバックピアとホストが必要であり、ヘッダーの転送やクロスオリジンリクエストは行われません。追加の ワークスペースや認証済みセッションが存在する場合、このパスは無効になります。ライブワークスペースでは、 この機能は発行されません。このデモでは、アカウントの接続や収集設定の変更は行えません。

パネルの内容とエクスポート機能#

このパネルでは、外部フォント、分析ツール、CDNリソース、および埋め込みリモートメディアは一切使用していません。 Telegramから取得したテキストは、HTMLではなくテキストとして挿入されます。ダウンロードされた添付ファイルは バイナリ添付ファイルとして提供されます。JSONL形式でのエクスポートでは元の文字列が保持されますが、HTML形式では エスケープ処理が行われます。また、数式となる可能性のあるCSVのセルには、アポストロフィが接頭辞として付加されます。

エクスポートデータには認証および署名用の秘密鍵は含まれませんが、 収集されたソースメタデータ、識別子、および場合によっては個人情報や機密情報が意図的に含まれています。 Telegramのアクセスハッシュやファイル参照情報が、生のソースメタデータに含まれる場合があります。

保存中の機密情報#

Telegram APIの認証情報、StringSession、およびEd25519の秘密鍵は、 Fernetを使用して暗号化されます。デフォルトでは、その鍵は同じ保護されたデータディレクトリに保存されます。 これにより、誤って平文が露出するリスクを軽減できますが、ディレクトリ全体を読み取ることができる攻撃者に対する 保護策ではありません。メッセージの内容やメディアは、TgWitness によって暗号化されません 。ディスク暗号化と厳格な OS 権限設定をご利用ください。Unix の秘密鍵 ファイルはモード 0600 で作成され、新しく作成されるデータディレクトリはモード 0700 を使用します。 既存のディレクトリ権限は変更されません。WindowsではディレクトリのACLが継承されますので、 サービスアカウントおよび承認された管理者のみにアクセス権を制限してください。

外部マスターキー#

新しいデータディレクトリの場合、TGWITNESS_VAULT_KEY_FILE により外部のランダムな マスターキーを指定できます。 HKDF-SHA256と個別のランダムなソルトを用いて、ワークスペースごとに異なるFernetキーが 導出されます。復旧のためには、vault.external.jsonを保持しておく必要があります。マスターキーが欠落しているか、 誤っている場合は、処理が失敗します。既存のローカルボールトは、黙って移行されることはありません。 実行中のプロセスはキーにアクセス可能です。これはHSMによる隔離ではありません。パネルには 選択されたモードが表示され、メッセージやメディアの保存データはアプリケーションによって 暗号化されていないことが明示されています。完全な脅威モデルについては、「接続」、「プロキシ」、および「データ保護」 をご参照ください。

プロキシとネットワーク経路#

プロキシ設定はVault内で暗号化されます。パスワードおよびMTProxyのシークレットは、 APIによって返されることも、証拠記録に書き込まれることもありません。各ワークスペースは、 Telegramのルーティング方法とIPモードを個別に選択します。

「IP非表示」モードでは、Telegramへの直接アクセスが拒否され、外部への HTTPリクエストにはプロキシが必要となります。「明示的に選択されたフォールバック」モードでは、遅延後にTelegramへの 直接アクセスが可能となります。「トンネル／VPN」モードでは、直接接続が許可されます。 トンネル モードを選択しても、VPNのインストールや検証は行われません。これらの設定は、マシン全体の トラフィック、ブラウザ、パッケージマネージャー、またはローカルプロキシホストによるDNS解決を制御するものではありません。

MTProxyはTelegramのトラフィックのみを転送します。外部リクエストについては、別の SOCKS5/HTTPプロキシ、ワークスペースのSOCKS5/HTTPルート、または許可された直接ルートを使用できます。 また、これらを無効にすることも可能です。独立したWitnessには独自のトランスポート設定があります。 通常のSOCKS5/HTTP CONNECT認証は、これらのプロキシ プロトコル自体によって暗号化されません。偽のTLS MTProxyシークレットは、引き続きサポートされていません。

サインインとセッションのインポート#

変換された .tgwitness-session ファイルには、 Vault に読み込まれて保存されるまで、平文の認証シークレットが含まれています。オフライン CLI は、検証済みの Telethon スキーマを受け付けます。 パネルインポートでは、さらにPyrogram SQLite、最新のシングルアカウント用TData ZIP、 およびドキュメント化されたJSON入力も受け付けます。認証が必要で、4ファイル／8 MiBに制限されており、 アーカイブの解凍や元のファイルの保存を行わずに、メモリ内でアップロードを処理します。 正規化された認証情報は、リクエストを行った認証済みブラウザにのみ返されます。 これらは、Telegramによる認証が成功した後、暗号化された保管庫に保存されます。 元のファイルおよび変換後のファイルを保護し、複数のクライアントによる認証情報の複製を防止してください。

データ処理では、コンテナのチェックサム、ローカルでの復号ハッシュ、および構造の 長さを検証します。指定されたデスクトップ版のローカルパスコードは一時的に使用されるのみで、保存されることはありません。 この限定的なパーサーは、すべてのデスクトップ版との互換性を保証するものではありません。 QR画像はローカルで生成され、短命なTelegramログイントークンを含んでおり、 外部のレンダリングサービスへ送信されることはありません。ロック、ワークスペースの切り替え、新規ログイン、 および経路の変更により、保留中のQR試行はキャンセルされます。タブの再読み込みや閉じ操作を行うと、 有効期限が切れるまで試行が保留されたままになる場合があります。QRログインに成功した場合でも、アカウントの紐付けは引き続き適用されます。 通常のAPIボディは16 KiBに制限されたままですが、認証済みインポートルートでは 最大12 MiBのエンコード済みJSONを受け付け、デコード後のファイルサイズの上限については別途適用されます。

ログインコードおよびTelegramの2段階認証パスワードは保存されません。電話番号およびコードのハッシュ値は、 認証処理中にメモリ内に保持されます。Telegramのセッションによりアカウントへのアクセスが許可されますが、 データディレクトリ、セッション、トークン、Vaultキー、または秘密署名鍵をGitHubにアップロードすることは決してありません。

ログと転送#

デフォルトのAPI検証レスポンスは、認証情報を 反映しないよう置き換えられています。アプリケーションのアクセスログ記録は無効化されています。リバースプロキシを 設定する際は、Authorizationヘッダーやリクエスト本文をログに記録しないようにしてください。HTTPではトークンやログイン シークレットが平文で送信されます。localhostから通信を行う際は、常にHTTPSまたはSSHトンネルをご利用ください。

完全性の制限#

ハッシュチェーン、データベーストリガー、および署名により、特定の変更を検出しますが、 ローカル管理者がジャーナルを書き換え、再署名することを防ぐものではありません。 署名付きチェックポイントと公開鍵のフィンガープリントは、別のシステムに保管してください。 エビデンスモードとオフサイトコピー（いずれもデフォルトではオフ）は、チェックポイントのハッシュを タイムスタンプサービスに送信し、暗号化されたコピーをS3互換のストレージに送信します。 エビデンス形式をご参照ください。透明性ログ、HSMによる署名、および正式な 保管の連鎖（チェーン・オブ・カストディ）の認証は実装されていません。

問題があると思われる場合#

元のデータディレクトリは保持し、分析には別のコピーを使用してください。 Telegramの非公開データや認証情報を公開のイシューに含めないでください。 独立したセキュリティ認証は主張しておりません。