secure-linux-web-hosting

概要

古いディストリビューション固有の知識や、Debian 10 時代の古いチュートリアルに頼らずに、クラウドサーバーを安全にアクセスできるウェブホストにするために、このスキルを使用します。

初心者向けサーバーガイドでおなじみの説明の流れを保ちつつ、再利用可能な運用ワークフローにまとめています。

1. 初期確認と振り分け
2. 前提条件
3. アクセスの保護
4. ファイアウォールと公開範囲
5. ウェブサーバーのセットアップ
6. 静的サイトまたはアプリのプロキシ
7. HTTPS
8. 検証
9. 任意の高度なチューニング

実行可能なコマンドを提示する前に、ディストリビューションの系統を特定し、ユーザーが使用するディストリビューションと選択したツールの公式ドキュメントで、最新のパッケージ名、サービスユニット、設定パス、ACME クライアントの手順を確認してください。

まず、フェーズの順序を確認するために references/workflow-map.md を開き、次に必要な範囲に絞ったリファレンスファイルを開いてください。

使用する場合

次のいずれかについてユーザーが言及した場合は、このスキルを使用してください。

• ホスティングに使いたいクラウドサーバー、VM、ドロップレット、その他の Linux ホスト
• ドメインや DNS A/AAAA レコードのサーバーへの接続
• SSH ログイン、SSH のセキュリティ強化、root ログイン、鍵、ポート、ファイアウォールの設定
• ウェブサイト向け Nginx のインストールまたは設定
• Linux でのシンプルな静的サイトの配信
• Nginx のリバースプロキシ配下での小規模アプリの公開
• HTTPS、Let's Encrypt、Certbot、acme.sh、証明書の更新、HTTP から HTTPS へのリダイレクト
• BBR などのセットアップ後に行う任意のパフォーマンスまたはネットワークのチューニング

次の場合は、このスキルを使用しないでください。

• Kubernetes、PaaS、またはコンテナーオーケストレーター全体のデプロイ設計
• Linux ホスティングが実際の問題ではない、アプリケーション固有のビルドまたは CI/CD に関する質問
• Windows または macOS ホストの管理
• より広範な SRE またはプラットフォーム設計の対応が必要な、公開されたマルチテナントの本番環境アーキテクチャレビュー

ワークフロー

1. 初期確認と現在の状態の分類

まず、次の点を特定します。

• ディストリビューションの系統またはイメージ名
• root 権限があるか、管理者ユーザーがあるか、または有効な SSH セッションが 1 つだけか
• DNS がすでにホストを指しているか
• 静的サイトとアプリのリバースプロキシのどちらが目的か
• ポートがすでに公開されているか
• HTTPS がすでに一部設定されているか

ディストリビューションが不明な場合は、具体的なパッケージまたはサービスのコマンドを提示する前に、ディストリビューションを尋ねるか、ユーザーに /etc/os-release を確認してもらいます。

2. 実行可能なコマンドを提示する前に最新のドキュメントを確認する

振り分けには同梱のリファレンスを使用し、現在のディストリビューションの挙動に依存するコマンドを提示する前に、最新の公式ドキュメントで詳細を確認してください。

必ず次の項目を確認します。

• パッケージマネージャーのコマンドとパッケージ名
• ファイアウォールのツールとサービス名
• SSH のサービスユニット名と設定のインクルードパス
• Nginx のパッケージと設定の構成
• 選択した ACME クライアントの最新の手順

詳細を確認できない場合は、その旨を伝え、古い Debian チュートリアルの手順がどの環境でも使えるかのように装わず、概要レベルの案内を提示してください。

3. フェーズの順序を守る

ユーザーが既存のセットアップのレビューまたは問題修正を明示的に求めている場合を除き、次の順序で進めます。

1. 前提条件
2. アクセスの保護
3. ファイアウォールと公開範囲
4. ウェブサーバー
5. ホスティング方法を 1 つ選択：静的サイトまたはアプリのプロキシ
6. HTTPS
7. 検証
8. 任意の高度なチューニング

静的サイトの分岐とリバースプロキシの分岐を、1 つの既定の回答にまとめないでください。ユーザーの目的に合った分岐を選択します。

4. 安全性の確認を徹底する

次の確認は必ず満たすべき条件として扱います。

• 2 つ目の SSH セッションで鍵ベースのログインが機能するまでは、SSH ポートの変更、パスワード認証の無効化、root の SSH ログインの無効化を推奨しないでください。
• DNS が意図したホストに解決され、HTTP サイトまたはプロキシ経由のパスが想定どおりに機能するまでは、証明書の発行を推奨しないでください。
• HTTPS が問題なく読み込まれるまでは、HTTP から HTTPS へのリダイレクトを強制しないでください。
• セキュアなホスティングが機能するまでは、BBR などのチューニングを提案しないでください。

必ず次の区別を明確にしてください。

• ローカルマシンで行う操作：SSH、DNS の確認、ブラウザでのテスト
• サーバーで行う操作：パッケージのインストール、設定ファイルの編集、サービスの再読み込み、ファイアウォールルールの設定

出力の要件

新規セットアップでは、以下を提示します。

• 現在の状態の簡潔な診断
• 現在のフェーズと、次に進む理由
• ローカルマシンでの手順とサーバーでの手順を分けて記載
• ドキュメントで確認した後にのみ、具体的なコマンドや設定スニペットを提示
• リスクのある変更のたびに検証手順を提示
• そのフェーズで起こりやすい間違いについて、「これが失敗した場合は、X を確認してください」という短い分岐を提示

セキュリティ強化やトラブルシューティングのレビューでは、以下を提示します。

• 最も可能性の高いリスクや問題を最初に提示
• 優先順位を付けた修正手順
• 次の設定変更に進む前に行う、最初の安全な検証手順

よくある間違い

• 古い記事の Debian 固有のコマンドを、すべての Linux で使えるものとして扱う
• 唯一のアクティブなセッションで SSH を強化し、ユーザーを締め出してしまう
• アプリをループバック上に維持せず、アプリケーションのポートを直接開放する
• 静的ファイルのホスティングに関する手順とリバースプロキシに関する手順を、1 つの設定に混在させる
• DNS または HTTP が正しく動作する前に ACME 発行を試みる
• HTTPS の動作確認前にリダイレクトを強制する
• BBR をセットアップの必須要件として扱い、後で行う任意の手順と見なさない
• あるディストリビューションでは Nginx がファイルを読み取れる一方、別のディストリビューションでは読み取れない場合に、SELinux や AppArmor の違いを無視する

リファレンスの使用方法

フェーズマップ、分岐ロジック、検証の順序については、references/workflow-map.md を使用してください。

ディストリビューションのファミリー、パッケージマネージャー、ファイアウォールツール、または設定レイアウトが関係する場合は、references/distro-routing.md を使用してください。

ユーザーに静的サイトの分岐またはリバースプロキシの分岐が必要な場合は、references/nginx-patterns.md を使用してください。

SSH のセキュリティ強化の手順、ファイアウォールの方針、証明書の発行と更新、リダイレクトのタイミングについては、references/security-and-tls.md を使用してください。