Nginx Dockerを使ってCasaOSで安全にウェブサイトをホスティングする

CasaOSではWebサイトをホストできますが、WebサイトとCasaOSの管理インターフェースは別々のサービスとして扱うべきです。2023年10月の短いスレッドで最も重要だった助言は、DockerでWebサーバーを実行するのは妥当である一方、CasaOSのダッシュボード自体をパブリックインターネットに直接公開するのは、まったく別の、はるかにリスクの高い判断だということでした。

シンプルな静的サイトには、公式イメージでHTML、CSS、JavaScript、画像のディレクトリをほとんど設定なしで配信できるため、Nginxは依然として優れたコンテナの選択肢です。

Webサイトを専用コンテナとして実行する

CasaOSは、基盤となるLinuxホスト上のDockerとファイルを管理するレイヤーです。したがって、WebサイトをCasaOSの管理サービス自体にインストールする必要はありません。

Webサーバーは専用のコンテンツディレクトリと必要なポートだけを備えた、独自のコンテナ内に分離してください。

公式Nginxイメージで静的コンテンツを直接配信できる

現在のNginx Dockerイメージでは、ローカルのWebサイトディレクトリを読み取り専用で次の場所にマウントできます。

/usr/share/nginx/html

この方式は、サーバープロセスがソースファイルを変更せずにコンテンツを読み取れるため、個人用の静的サイトに最適です。

2021年のチュートリアルにある古いサードパーティ製イメージをコピーするのではなく、静的コンテンツ向けの現在の公式Nginxコンテナ構成を使用してください。

Apacheも有効だが、選択自体がセキュリティ境界ではない

元の質問はApacheとNginxのどちらがよいかというものでした。どちらでもWebサイトを適切にホストできます。より重要なのは、コンテナをどのように更新するか、サイトファイルをどこに保存するか、TLSを設定するか、そしてどのネットワークポートを公開するかです。

NginxからApacheに変更しても、インターネットに公開された管理ダッシュボードが安全になるわけではありません。

CasaOSのダッシュボードを非公開に保つ

コミュニティの回答者は、CasaOS自体をWebに公開しないよう明確に警告していました。管理インターフェースからはファイル、コンテナ、その他のサーバー機能を操作できるため、限定的に設定したWebサイトコンテナを公開するよりも、はるかに大きな攻撃対象領域が生まれます。

管理アクセスはLAN内に限定するか、プライベートなリモートアクセスレイヤーの背後に置いてください。

管理にはプライベートネットワークを使用する

元のユーザーは、自宅でJellyfin用にCasaOSを使い、リモートからNextcloudにアクセスするためにTailscaleを使用することにしました。これは責任範囲を適切に分離した構成です。公開WebサイトへのトラフィックはWebコンテナに送る一方、管理サービスにはプライベートなオーバーレイネットワーク経由でのみアクセスできるようにします。

Webサイトを公開する必要がある場合は、TLSと明確な入口経路を追加する

公開サイトには通常、ドメイン名、HTTPS証明書、そしてルーターのポート転送または認証付きリバーストンネル構成が必要です。具体的な選択は、パブリックIPを持っているか、どの程度のインフラを運用したいかによって異なります。

サイトに必要なWebサーバーのポートだけを公開してください。CasaOSやDockerの管理に関係しないポートは転送しないでください。

Webコンテナとコンテンツスタックにパッチを適用する

最小構成の静的Nginxサイトは比較的攻撃対象領域が小さいものの、コンテナには引き続きセキュリティ更新が必要です。PHP、WordPress、Node.js、データベースを使う動的サイトでは、構成要素が大幅に増えるため、単なる静的ファイルとしてではなく、アプリケーションスタック全体として更新してください。