セルフホスティング プライバシーチェックリスト
Guides · 9 分で読了
なぜ一度きりの設定よりチェックリストの方が優れているのか
セルフホスティングにおけるプライバシー面の失敗のほとんどは劇的なものではありません。何ヶ月もIPアドレスを静かに保持し続けるログファイル、ローテーションが面倒だと放置されたデフォルトのSSHポート、ノートパソコンに暗号化されずに保存されたバックアップスナップショット、いまだに本名を指し示すWHOISレコードなど、小さく積み重なる隙間です。どれも単体では緊急に見えません。だからこそ生き残るのです。
チェックリストが機能するのは、プライバシーを一度きりの設定手順ではなく、システムの継続的な性質として扱うからです。サーバーは徐々にずれていきます。パッケージがインストールされ、ちょっとしたテストのために開けたポートが閉じられないままになり、忘れていたサービスが冗長なログを書き始めます。毎月、あるいは何か変更があるたびに同じリストを見直すことで、そのずれが露出になる前に捕まえられます。
- プライバシー強化を立ち上げ時のタスクではなく保守作業として扱う
- 新しいサービス、パッケージ、設定変更のたびにリストを再確認する
- 確認するまではデフォルト設定は緩いものだと想定する
第一層:誰がアカウントを追跡できるか
ターミナルに触れる前に、アカウント自体がしばしば最も弱いリンクになります。軍事レベルの基準で保護されたVPSであっても、サインアップに本物のメール、カードの明細、身分証明書のスキャンが使われていれば追跡可能です。この層は、いかなる技術的な強化よりも先に、決済手段とサーバーとの間の連鎖を断ち切ることに関わります。
匿名サインアップの仕組みはこのために存在します。例えばVPS GOATは、プライバシー重視のVPNプロバイダーで使われているのと同じMullvad方式にならい、メールアドレスや身分証明書を収集する代わりに、サインアップ時に単一のハッシュ化されたアカウントキーを発行し、決済はOxaPay経由の暗号資産のみで完結します。取引レベルのプライバシーからMoneroが推奨され、Bitcoin、USDT、Litecoin、Ethereum、Tronにも対応しています。どのプロバイダーを使うにせよ、同じ問いを投げかけてください。サインアップは何の識別情報を収集するか、決済は何を明かすか、そしてそのデータの開示を強制された場合何が起きるか。
- 実際の身元に紐づく個人メールではなく、匿名アカウントキーや仮名メールを使用する
- 自分の名前に紐づくカードではなく、プライバシーを尊重する暗号資産で支払う
- 匿名プロジェクトと個人プロジェクトの間で、ユーザー名、PGP鍵、SSH鍵のフィンガープリントを使い回さない
- サインアップ前に、プロバイダーのアカウント作成フローが実際に何を保存するかを確認する
第二層:OSレベルでVPSを保護する方法
アカウントがクリーンになったら、次の層はオペレーティングシステム自体です。VPSを保護する第一歩は、明示的に必要としないアクセス経路をすべて排除し、残したものを固めることです。これは、日和見的なスキャナーが足場を得られるかどうかを最も直接的に左右するチェックリストの部分です。
SSHは、新規VPSに対するほぼすべての自動攻撃の最初の標的なので、最も注意を払うべきです。パスワード認証を完全に無効化し、鍵ペアに頼りましょう。理想的にはローカルで生成し、どこにもアップロードしないEd25519鍵です。SSHをポート22から移動させるのは、実質的なセキュリティ対策としてではなく、あくまでノイズを減らす程度の効果と考え、fail2banや同様のツールと組み合わせて総当たり攻撃を自動的に抑制しましょう。
- SSH経由のrootログインを無効化し、パスワード認証も無効化して鍵ベースのアクセスのみにする
- ufw、nftables、iptablesなどのファイアウォールを標準拒否のポリシーと明示的な許可ルールで運用する
- fail2banやcrowdsecを導入し、繰り返される失敗ログインを自動的にブロックする
- セキュリティ更新をスケジュールに沿って適用する。DebianやUbuntuではunattended-upgradesが自動で処理してくれる
- 日常管理用に非root権限のsudoユーザーを作成し、rootは例外的な場合のために温存する
- 使用していないサービスを無効化し、実際に稼働しているサービスに紐づかないポートは閉じる
第三層:セキュリティだけでなくプライバシーのためにサーバーを強化する
セキュリティとプライバシーは重なり合いますが同一ではありません。サーバーは侵入されにくい一方で、1年間すべての訪問者のIPアドレスを平文で記録し続けることもあり得ます。これはセキュリティ侵害ではありませんが、プライバシー面の失敗です。プライバシーのためにサーバーを強化するとは、標準的なセキュリティのベースラインに加えて、記録・保持するものを積極的に最小化することを意味します。
フルディスク暗号化(LinuxのLUKS)は、物理ドライブが押収されたり、スナップショットが無許可でコピーされたりした場合に静止データを保護します。VPS GOATのプランはインフラレベルで暗号化NVMeストレージを標準搭載しており、これはハードウェア層をカバーしますが、ゲストOS内であなたが管理する部分については、自分自身のディスク暗号化とアプリケーションレベルのログの規律も依然として重要です。暗号化に加えて、ウェブサーバー、メールサーバー、さらにはシェル履歴に至るまで、あらゆるサービスのデフォルトのログ記録動作を見直してください。これらは必要以上にIPアドレス、タイムスタンプ、クエリ文字列を長期間保持しがちです。
時刻同期とDNSの選択も重要です。タイムゾーンが誤っているサーバーや、すべての問い合わせをあなたのインフラに紐づけて記録するDNSリゾルバは、日常的な使用では目に見えないため見落としがちなメタデータの痕跡を生み出します。
- ゲストOS内でLUKSまたは同等のフルディスク暗号化により静止データを暗号化する
- 保持が不要な場合は、nginx、Apache、アプリケーションサーバーの冗長なアクセスログを切り詰めるか無効化する
- 無期限に蓄積するのではなく、短い保持期間のlogrotateなどでログを積極的にローテーション・失効させる
- アクセスISPのデフォルトの代わりに、DNS-over-TLSまたはDNS-over-HTTPS経由のプライバシー重視のDNSリゾルバを使用する
- 機密コマンドのシェル履歴を消去し、シークレットを扱う自動化スクリプトではbash履歴を無効化する
- NTPを物理的な所在地に紐づかない中立的な時刻源に設定する
バックアップ、スナップショット、そして復旧の罠
プライバシー強化が最も静かに崩れるのがバックアップです。稼働中のサーバーが完璧に強化されていても、その夜間スナップショットがサードパーティのストレージバケットに暗号化されずに置かれていたり、プロバイダーの自動スナップショット機能があなたの管理外のどこかにディスクイメージ全体を保存していたりすれば、あまり意味がありません。
解決策は、バックアップの暗号化を稼働中のディスクと同じくらい真剣に扱うことです。resticやborgのようなツールを使い、オフラインで保管した強力なパスフレーズで、サーバーから出る前にバックアップアーカイブをクライアント側で暗号化してください。そうすればバックアップ先が侵害されても、中身は読み取れないままです。プロバイダーが提供するスナップショット機能を使っている場合は、それがどこに保存され、元のボリュームと同じ暗号化を継承しているかどうかを把握しましょう。
- 保存先だけでなく、アップロード前にクライアント側でバックアップを暗号化する
- 定期的に復元テストを行う。テストされていないバックアップは希望であって計画ではない
- プロバイダー管理のスナップショットが暗号化されているか、物理的にどこに保存されているかを確認する
- 少なくとも1つのバックアップコピーを、稼働中のサーバーとは別の管轄区域に保管する
最後に確認すべきアプリケーション層の漏洩
アカウント、OS、バックアップをカバーしたら、最後の層は実際に稼働させているアプリケーションです。ここからはプライバシー強化がアプリケーション固有のものになります。セルフホスト型メールサーバー、静的ブログ、Torの隠しサービスはそれぞれ異なる漏洩面を持ちますが、ほぼ普遍的に当てはまるチェック項目もいくつかあります。
メタデータは最もよく見落とされるものです。アップロードされたファイルにはEXIFデータ、ドキュメントの作成者フィールド、タイムゾーンを明かすタイムスタンプが含まれることがあります。ウェブアプリケーションはサーバーヘッダー、ソフトウェアのバージョン、攻撃者にロードマップを渡してしまう冗長なエラーページを露出することがあります。修正自体が特別に難しいものではありませんが、デフォルトでは隠れてくれないため、それぞれの項目を明示的にチェックする必要があります。
- 公開する前に、ファイルや画像からEXIFやメタデータを取り除く
- 冗長なサーバーヘッダー(Server、X-Powered-By)を抑制し、本番環境では詳細なエラーページを無効化する
- 意図せず有効になっているIPログ記録がないか、お問い合わせフォームやコメントシステムを確認する
- クリアネットサイトと並行してTorの隠しサービスを提供している場合、TLS証明書やアナリティクススクリプトなど識別可能な資産を両者が共有していないか確認する
| 層 | 確認すべきこと | 一般的なツールや設定 |
|---|---|---|
| アカウント | サインアップ時の身元、決済の痕跡 | 匿名アカウントキー、OxaPay経由のMonero |
| アクセス | SSHの露出、総当たり攻撃リスク | 鍵限定SSH、fail2ban、標準拒否のファイアウォール |
| ストレージ | ディスクやスナップショットがコピーされた場合の静止データ | LUKSフルディスク暗号化、暗号化NVMe |
| ログ | IPアドレスとタイムスタンプの保持 | logrotateの短い保持期間、最小限のアクセスログ |
| バックアップ | バックアップ先が侵害された場合の露出 | resticやborgによるクライアント側暗号化 |
| アプリケーション | メタデータとヘッダーの漏洩 | EXIFの除去、サーバーヘッダーの抑制 |