# Webship ウェブサーバー：デフォルトで安全な設定
安全なウェブサーバーは、午前2時にオペレーターがもう一つの設定を覚えていることに依存すべきではありません。それは保護された基準から始まり、危険な設定を拒否し、機密機能を公開する前に慎重な選択を必要とすべきです。
それは Webship の背後にあるモデルです。そのデフォルトの構成は、主要なリクエストおよびレスポンスの防御を有効にし、攻撃者が消費できるリソースを制限し、オプションの制御面を無効のままにします。実際のアプリケーションに合わせてこれらのデフォルトを調整することはできますが、最初のリクエストが到着する前にすべての保護を発見する必要はありません。
デフォルトで安全であることは、文脈なしで安全であることを意味するわけではありません。証明書、アプリケーションの認可、ネットワークポリシー、シークレット、インシデント対応は依然としてオペレーターの責任です。Webshipの仕事は、安全な出発点を明確に示すことと、偶発的に弱体化させることを困難にすることです。
有効に開始される保護
Webship は、基本構成で6層を有効にします：
| レイヤー | デフォルトの動作 | 減らす対象 | | --- | --- | --- | | ドットファイル保護 | ドットで始まる静的パスセグメントを拒否 | 環境ファイル、リポジトリのメタデータ、およびローカル設定の偶発的な露出 | | ウェブアプリケーションファイアウォール | 既知の攻撃パターンをブロック | SQLインジェクション、クロスサイトスクリプティング、トラバーサル、機密パスのプローブ、コマンドインジェクション、ヘッダースマグリング、サポートされていないリクエストエンコーディング | | DDoS対策 | 制限付きクライアント状態で通常モードで動作 | リクエストフラッド、無制限の追跡、回避可能なリソース枯渇 | | ボットチャレンジ | 署名付きチャレンジクッキーを使用 | 低コストの自動化された悪用および繰り返しスキャン | | レスポンスセキュリティヘッダー | 制限的なブラウザポリシーを追加 | MIMEの混同、フレーミング、リファラー漏洩、危険なブラウザ機能、および広範なコンテンツ読み込み | | APIシールド | API契約が定義されると、ブロックモードを使用し、未知のルートを拒否します | シャドウエンドポイント、意図しないメソッド、予期しないコンテンツタイプ、および認証要件の欠如 |
デフォルトの WAF は、検査範囲にも厳しい制限を設けています：32 KiB のリクエストヘッダー、2,048 バイトのパス、1 MiB のリクエストボディです。これらは任意のパフォーマンススイッチではなく、セキュリティ上の制限です。アプリケーションが正当により大きなリクエストを必要とする場合は、該当するアプリケーションの制限を引き上げ、グローバルに検査を無効にするのではなく、結果をテストしてください。
DDoS保護は通常モードで1分あたり600リクエストから開始され、クライアントキーごとに100のバースト許容量があります。そのクライアントステートテーブルは65,536エントリに制限されています。これらの値はベースラインであり、普遍的なトラフィックモデルではありません：パブリックAPI、ダウンロードサービス、および内部管理パネルは同じアプリケーション固有の制限を共有すべきではありません。
ブラウザの保護は基本部分の一部です
Webship のレスポンスヘッダーポリシーは、アプリケーションが自身のヘッダーを追加し忘れた場合でも有効です。デフォルトには以下が含まれます:
- X-Content-Type-Options: nosniff;
- フレーム拒否ポリシー
- リファラーポリシー: no-referrer;
- サブドメインを含む1年間のStrict-Transport-Security;
- コンテンツセキュリティポリシーは同一オリジンのコンテンツに限定され、フレーミングおよびベースURIの制限が適用されます。
- Permissions-Policyにより、位置情報、マイク、カメラへのアクセスが無効化されます。
これらのデフォルト設定は意図的に制限的です。サブドメインが完全にHTTPS対応でないドメインに適用する前に、HSTSを確認してください。アプリケーションが他のオリジンからスクリプト、スタイル、フォント、画像、接続を読み込む前に、Content-Security-Policyを確認してください。安全なデフォルトは、本番環境で密かに弱められるのではなく、デプロイ時に明確に失敗するべきです。
オプションの面は閉じたままにする
Webshipは、バイナリに含まれているからといってすべての機能を公開するわけではありません。リバースプロキシ、WebTransport、可観測性エンドポイント、自動TLS、レスポンスの由来、およびMCP制御エンドポイントはデフォルトで無効になっています。
MCP エンドポイントは有効化されるとループバックスコープとなり、明示的なセキュリティ構成が必要です。メトリクスと統計は、意図的に有効化するための計装が必要です。自動証明書管理では、オペレーターが ACME ディレクトリ、連絡先、ストレージ、および利用規約の承諾を選択する必要があります。これにより、運用上の機能が思わぬネットワーク面に現れることを防ぎます。
基本リスナーも127.0.0.1にバインドされます。オペレーターは公開アドレスを明示的に選択する必要があります。その単一の選択が、ファイアウォールのルール、サービスの権限、TLSの識別、デプロイメントのトポロジーに対する有用な確認ポイントを作ります。
リバースプロキシは信頼境界を保持します
リバースプロキシが有効になっている場合、TLSパススルーはデフォルトのままです。Webship は、アプリケーションの平文やアクティブなセッションキーを取得せずに暗号化されたトラフィックを転送します。オリジンサーバーはTLSおよび交渉されたプロトコルに対する責任を引き続き負います。
TLS終了は、Webship が HTTP リクエストを検査し、パスごとにルーティングし、WAF や API ポリシーを適用し、ヘッダーを書き換えたり、レスポンスをキャッシュしたりする必要がある場合にのみ有効にしてください。終了自体は本質的にセキュリティが低いわけではなく、信頼境界を移動させるに過ぎません。重要な決定は、どのマシンが平文を見ることを許可されるか、そしてその理由です。
パススルーには機能的な制限もあります。TCPルーティングはHTTPリクエストが暗号化されているため、ClientHello SNIに基づいて行われます。HTTP/3 のパススルーでは、ルートが1つのUDPオリジンを共有する必要があります。エッジでコンテンツ認識型のセキュリティが必要な場合は、そこでTLSを終了し、エッジからオリジンへのホップを別途保護してください。
確認できる生産基準
次の抜粋は、省略に頼るのではなく、重要なデフォルトを明示しています：
listen = "0.0.0.0:443"
deny_dotfiles = true
[tls]
unknown_sni = "reject"
[ddos]
enabled = true
mode = "normal"
requests_per_minute = 600
burst = 100
block_seconds = 60
max_tracked_clients = 65536
[security]
enabled = true
rate_limit_max_entries = 65536
[security.waf]
enabled = true
mode = "block"
sqli = true
xss = true
traversal = true
sensitive_paths = true
header_abuse = true
max_header_bytes = 32768
max_path_bytes = 2048
max_body_bytes = 1048576
[security.response_headers]
enabled = true
nosniff = true
frame_deny = true
referrer_no_referrer = true
hsts = "max-age=31536000; includeSubDomains"
content_security_policy = "default-src 'self'; frame-ancestors 'none'; base-uri 'self'"
permissions_policy = "geolocation=(), microphone=(), camera=()"マルチドメインリスナーでは、unknown_sni = "reject" は認識されないホスト名がリスナーのデフォルト証明書を受け取るのを防ぎます。Webship の自動TLSリスナーは、証明書が存在するまで未知の名前をすでに拒否します。
検証はセキュリティコントロールです
Webshipはリスナーをバインドする前に構成を検証します。未知のフィールド、無効な制限、不完全な識別情報、競合するリスナー、およびサポートされていないプロトコルの組み合わせは、特定のエラーで起動に失敗します。同じ検証は、ライブ構成がインストールされる前にも実行されます。リロードが失敗した場合、現在の構成がアクティブなまま残ります。
認証されたMCP構成パスは、もう一つのガードを追加します：アクティブなWAF、DDoSレイヤー、APIシールド、ボットチャレンジ、エッジ認証ポリシー、またはレスポンスヘッダーレイヤーを無効にするライブ変更を拒否します。バージョンチェックにより、管理者1人が新しい構成スナップショットを上書きすることを防ぎます。プロセスに結びつく設定は、部分的なライブ変更が成功したふりをするのではなく、再起動が依然として必要です。
これは有用な区別です。セキュアなデフォルトは新しいデプロイメントを保護します。トランザクション検証と保護された更新は、稼働中のデプロイメントを保護します。
どのオペレーターがまだ決定する必要があるか
インターネットにWebshipを公開する前に:
- 信頼できるTLSアイデンティティを設定し、秘密鍵を保護します。
- リスナートポロジーの不明なSNI処理を設定します。
- HSTS とコンテンツセキュリティポリシーがすべてのアプリケーションとサブドメインで一致していることを確認してください。
- APIシールドのエンドポイント、許可されているメソッド、コンテンツタイプ、および認証要件を定義します。
- グローバルなベースラインに頼るのではなく、ルートごとのレート制限を追加してください。
- 保護されたホストまたはパスに対してエッジ認証を有効にし、短時間有効なトークンを使用します。
- MCP とオブザーバビリティリスナーは、プライベートで認証済み、かつパブリックトラフィックとは分離して保持してください。
- Webship を、専用の権限のないアカウント、可能であれば読み取り専用のアプリケーションルート、必要なオペレーティングシステムの機能のみで実行してください。
- ロールアウト前に設定を検証し、その後、カナリア環境でブロックされたトラフィックと許可されたトラフィックをテストします。
- セキュリティ監査イベントを監視し、通常モードから攻撃中モードまたはロックダウンへの切り替えをリハーサルしてください。
より安全なデフォルトは出発点であり、主張ではない
どのウェブサーバーも、どのユーザーがあなたの請求書を見るべきか、どのオリジンがあなたのAPIを呼び出せるか、ビジネスエンドポイントがリクエストをどのくらいの速さで受け入れるべきかを決めることはできません。これらの制御にはアプリケーションの知識が必要です。
Webship は下位層を提供します：境界付きパーサー、厳格な設定、防御的なレスポンスヘッダー、リクエストの検査、悪用防止制御、閉じたオプションの表面です。その結果、「セキュリティが解決された」というわけではありません。サーバーを設置して責任を持って運用するまでのギャップが小さくなるだけです。
本番環境にデプロイする前に、Webship ドキュメント を完全に確認してください。構成スキーマと実行中のバイナリは、運用している正確なバージョンについての権威ある情報源となります。