Skip to content

ネットワークとセキュリティの基礎

1. ホストマシンとポートフォワーディング

ポートフォワーディングとは

「あるポートに来た通信を、別の場所(別のIPやポート)に転送する」 仕組みです。 Docker Infrastructureでは、以下の2段階でポートフォワーディングが行われています。

  1. VirtualBox/UTM (ホスト -> ゲスト):
    • ホストPCの 4242 番を、VMの 4242 番へ。
    • これにより、外部(ホスト)から隔離されたVM内部へアクセス可能になります。
  2. Docker (VM -> コンテナ):
    • VMの 443 番を、Nginxコンテナの 443 番へ (ports: - 443:443)。
    • これにより、VMに届いたWebアクセスがコンテナに到達します。

また、SSHトンネル(別紙参照)もポートフォワーディングの一種です。

2. SSL/TLS証明書と仕組み

SSL (Secure Sockets Layer) / TLS (Transport Layer Security) は、インターネット通信を暗号化するプロトコルです。

TIP

詳細解説: SSL/TLSの仕組み、暗号化の技術的詳細、バージョンごとの違いについては、以下の独立したドキュメントで詳しく解説しています。 👉 SSL/TLSの仕組み (Deep Dive)

Docker Infrastructureでは「オレオレ証明書 (Self-signed Certificate)」を使っています。

  • 通常: 第三者機関 (CA) が「このサーバーは本物です」と署名します。
  • 今回: 自分で「俺は本物だ」と署名しています。そのためブラウザは「知らない署名者だ」と警告を出します。

3. Let's Encrypt とは

概要

Let's Encrypt は、無料で自動化されたオープンな認証局 (CA) です。 以前は証明書の発行には高額な費用と面倒な手続き(書類審査など)が必要でしたが、Let's Encryptによって「ドメインの所有確認」さえできれば数秒で発行できるようになりました。

特徴

  1. 無料: 誰でも無料で取得可能。
  2. 自動化: certbot などのツールを使えば、発行・更新(90日ごと)が全自動になります。
  3. DV (Domain Validation): 企業の実在証明などは行わず、「そのドメインをコントロールできているか(DNS設定やWebサーバーへのアクセス権があるか)」だけを機械的に検証します。

参考: How It Works - Let's Encrypt

参考: How It Works - Let's Encrypt

4. 図解: SSL証明書発行の各種パターン

なぜ今回は「オレオレ証明書」なのか? 他の方法と何が違うのか? を図解します。

A. Let's Encrypt の仕組み (本番環境)

「インターネットからアクセスできること」 を持って本人確認とします(HTTP-01チャレンジ)。

B. 今回使えない理由 (Docker Infrastructure環境)

「インターネットから届かない」 ため、検証フェーズで失敗します。

C. OpenSSL の仕組み (今回の課題)

誰の承認も得ず、「自分で署名する」 方式です。

D. mkcert の仕組み (ローカル開発の理想)

「自分のPCにだけ通用する最強の身分証」 を作ってインストールさせます。

※ 校舎PCでは 2. Trust の工程(OSの信頼リストへの追加)が制限されているため、使えません。

5. デプロイに向けたアドバイス

Q. デプロイを見据えて、今から Let's Encrypt 用の実装をすべき?

A. いいえ、今の Dockerfile に混ぜるべきではありません。

実運用(本番デプロイ)では、構成を以下のように切り替えるのが一般的です。

  1. 開発 (Docker Infrastructure):

    • 証明書: openssl で生成した静的ファイル。
    • Nginx: Dockerfile内で証明書を配置。
  2. 本番 (Deployment):

    • 証明書: certbot コンテナ(またはホスト上のcron)が動的に取得・更新。
    • Nginx: 証明書ディレクトリを volumes でマウントして共有(Dockerfileには焼き込まない)。
    • 構成変更: docker-compose.prod.yml など別のYAMLファイルで、certbot サービスを追加し、ポート80を開放する構成にします。

推奨アクション

「今の MakefileDockerfile は "開発用/Docker Infrastructure用" と割り切ってシンプルに保つ」 ことがベストです。 無理に一つの設定ファイルで両方に対応しようとすると、複雑怪奇なスクリプトになり、レビューでの減点対象(不要な複雑さ)になりかねません。 本番に行くときは、「本番用の docker-compose.prod.yml を新しく作る」のがスマートです。

Released under the MIT License.