Zenn
📕

Webの基礎 - Cyber Security Roadmap

2024/12/11に公開
Web
tech

Webの基礎

サイバーセキュリティとWeb

Webの存在により、多くの手間を省くことができるようになりました。例えば、ネットショッピングを利用する際、専用のソフトウェアをコンピュータにインストールする必要はありません。URLを一つ入力するだけで、その機能を簡単に利用できます。

これはほんの一例に過ぎないほど、Webは非常に便利な技術であり、インターネットの発展にも大きく寄与してきました。多くのサービスがWeb技術を基盤として生まれ、発展してきた結果、Webはインターネットの象徴的な存在といっても過言ではないと思います。

そして、多くのサービスがWeb技術に依存している現状があります。企業の収入においてもWebサービス一つで、数十〜数百の従業員の生活を支える収入が生まれ少なからず依存しています。僕自身もWebサービスを収入の源泉としており、それが崩れると生活に少なからず影響が出るでしょう。

困ったことに、サイバー攻撃の多くもインターネットを介して行われており、その主な対象はWebです。そのため、サイバーセキュリティにおいてWebは攻撃と防御の主戦場となっています。悪意のある攻撃者からシステムやデータを守るには、インターネットを通じて攻撃対象となるWebシステムの仕組みを正しく理解することが不可欠です。このことから、Webの技術を学ぶことは、サイバーセキュリティのスキルを磨くための強固な基盤と言えます。

Webとは？

Web
Web（ウェブ） は、「World Wide Web（ワールド・ワイド・ウェブ）」の略称で、インターネット上で情報を共有したり閲覧したりするための仕組みや技術を指します。具体的には、Webページやアプリケーションをブラウザを通じて提供するための技術基盤です。

Webとインターネットは密接に関連していますが、同じものではありません。インターネットが「通信のためのインフラ」であるのに対し、Webはその上で動作する「情報共有と閲覧の仕組み」です。Webは、OSIモデルでいうアプリケーション層に位置し、主にHTTP/HTTPSプロトコルを使ってインターネット上で動作します。

Webサイトとは？

Webサイト

Webサイトとは、主に情報を「提供」することを目的とした静的なコンテンツの集合体です。複数のWebページで構成され、それぞれがリンクで結び付けられています。ユーザーが情報を閲覧することがメインで、インタラクティブな動作は比較的少ない場合が多いです。

例:

  • 会社のホームページ
  • ポートフォリオ
  • ニュースサイト

Webアプリケーションとは？

Webアプリケーション

Webアプリケーションは、ユーザーとの相互作用（インタラクション）を重視した動的なコンテンツの集合体です。ユーザーがデータを入力したり操作することで、アプリケーションが処理を行い結果を返す仕組みを持ちます。Webアプリケーションでは、データベースやプログラム（バックエンドのロジック）を用いて、動的なページを生成することができます。

例:

  • インターネットバンキング
  • 掲示板
  • ECサイト

Webブラウザとは？

Webブラウザ

Webブラウザとは、WebサイトやWebアプリケーションを閲覧するためのソフトウェアです。インターネット上のサーバーからデータを取得し、それを視覚的にわかりやすい形で表示します。ユーザーがURLを入力したり、リンクをクリックすることで、ブラウザがコンテンツを取得します。

例:

  • Google Chrome
  • Safari
  • Firefox
  • Microsoft Edge

サーバーとは？

サーバー

サーバーは、特定のサービスを提供するコンピュータで、クライアント（ユーザーのデバイスやブラウザ）からのリクエストを受け取り、必要なデータや機能を提供します。WebサイトやWebアプリケーションの開発では、主にWebサーバー、データベースサーバー、アプリケーションサーバーなどが使用されます。サーバーには用途に応じて多種多様な種類があり、それぞれ異なる役割を果たしています。

Webサーバー

  • 役割: Webページのデータ（HTML、CSS、JavaScript、画像など）をブラウザに提供。
  • 代表的なソフトウェア:
    • Apache
    • Nginx
    • Microsoft IIS

データベースサーバー

  • 役割: データを保存・管理し、必要な情報をアプリケーションに提供。
  • 代表的なソフトウェア:
    • MySQL
    • PostgreSQL

アプリケーションサーバー

  • 役割: アプリケーションのロジック（データ処理、計算など）を実行。
  • 代表的なソフトウェア:
    • Apache Tomcat
    • WildFly
    • Node.js

サーバーの役割は、基本的に「リクエストを受け取り、必要なデータや機能を返す」ことに共通しています。しかし、具体的な役割や動作はインストールされたソフトウェアによって決まります。例えばサーバーにApacheをインストールすればWebサーバーとして動作するということです。

図書館に例えてWebの仕組みをイメージする

図書館

ここまで、WEBで存在感のあるWebブラウザ、Webサイト、Webアプリケーション、サーバーを紹介してきました。
これらの関係性を図書館に例えてイメージして、整理してみます。

Webブラウザ:
図書館の利用者といえます。
本を読んだり、借りたり、特定の本をリクエストするなどの操作を行います。

Webサイト:
本そのものです。
静的な情報を提供する存在で、本を読むようにその内容を閲覧できます。

Webアプリケーション:
図書館の受付や貸出システムに該当します。
利用者が図書館で「操作」することで、本を貸し出す、予約する、特定の本をリクエストするといった相互作用を通じて、動的に動作し目的を達成する仕組みです。

サーバー:
本を保管している図書館そのものに該当します。
図書館に本が保管されているように、データやシステムのすべてがここに保存されています。
保存するデータ（DBや画像ファイル）に応じて、保管場所を分け整理して管理することもあります。

Webブラウザの基礎

Webブラウザ

ここからは、より具体的にWebについて学んでいきます。まずはブラウザについてです。
ブラウザは、日常的に利用するインターネットの顔であり、ユーザーが情報を閲覧し、Webサイトと対話するための窓口となります。
普段、ユーザーとしてはあまり意識することなく利用できますが、その裏側には複雑な技術の仕組みがあります。

ブラウザの主な機能

ブラウザは、簡単にいうとWebリソースを取得し、それをユーザーにわかりやすい形で表示するためのツールです。

その主な機能は以下の通りです：

  1. Webリソースの取得と表示

    • ユーザーが入力したURL（URI）を基に、WebサーバーからHTML、CSS、JavaScript、画像などのリソースを取得し、それを画面上に表示します。

  2. HTMLとCSSの解釈

    • Webページの構造を定義するHTMLと、デザインやレイアウトを定義するCSSを解析し、視覚的にわかりやすい形に変換（レンダリング）します。

  3. 標準的なユーザーインターフェースの提供

    • ブックマーク、履歴、タブの管理、アドレスバーなど、ユーザーがWebを効率的に利用するための標準的な機能を提供します。

ブラウザの主な機能を支える技術

ブラウザの視点で、入り口からブラウザの主な機能を支える技術をチェックしていきましょう。
ブラウザの主なコンポーネントは次のとおりです。
図 1: ブラウザ コンポーネントweb.dev：ブラウザの仕組みより：図 1: ブラウザ コンポーネント

ブラウザユーザーインターフェース

ほとんどのブラウザには、アドレスバーやタブなど、共通のUI（ユーザーインターフェース）要素が備わっています。完全に共通化されているわけではありませんが、主要な機能については多くのブラウザで共通しているため、ユーザーは異なるブラウザを使用しても基本的な操作に大きな違いを感じることなく利用できます。また、ブックマークの登録などの処理はUIバックエンドを通じて実行されています（UIバックエンドの詳細は後述します）。

さらに、ブラウザの設定を変更することで、プライバシー保護やセキュリティ機能を向上させることが可能です。例えば、追跡防止機能を有効化したり、履歴データを定期的に削除したり、Cookieの設定を変更することなどが挙げられます。これらの設定に関しては、Chromeのサポートページなど、ブラウザが提供する公式ドキュメントを参考にすると良いでしょう。

また、多くのブラウザに共通するセキュリティ機能として、HTTPS対応のWebページでは「鍵アイコン」が表示される場合があります。このアイコンは、通信が暗号化されていることを示しており、ユーザーが安全にWebサイトを利用できる目安となります。ただし、ブラウザごとにアイコンのデザインや警告メッセージの表示方法には若干の違いがあります。

ブラウザエンジン

ブラウザエンジンは、Webブラウザ全体の中核的な部分であり、ブラウザの動作を制御する重要な役割を担います。カーネルがOS全体を統括してハードウェアリソースとアプリケーション間を仲介するのと同様に、ブラウザエンジンはブラウザ全体を制御します。
具体的には、Webページの取得、表示、ユーザー操作（ページの閲覧やリンクのクリックなど）を管理し、ブラウザの主要な機能を制御しています。

ブラウザエンジンの主な役割：

  • ネットワーキング：Webサーバーとの通信を管理。
  • JavaScriptの実行：Webページ内のスクリプトを処理。
  • UIバックエンドとの連携：ユーザー操作を解釈し、適切に処理。
  • レンダリングエンジンの制御：HTMLやCSSを解釈してページを描画。

代表的なブラウザエンジンには次のものがあります：

  • Blink（Google Chrome、Opera）
  • Gecko（Mozilla Firefox）
  • WebKit（Apple Safari）

これらのエンジンは、レンダリングエンジンやUIバックエンド、JavaScriptエンジンと連携して、ユーザーに快適な操作体験を提供します。

レンダリングエンジン

レンダリングエンジンは、ブラウザエンジンと連携し、Webページのコンテンツを解釈して視覚的な出力を行います。具体的には、HTMLやCSSの解析、ページのレイアウト計算、画像やテキストの描画などを担当します。

レンダリングエンジンの主なプロセス：

  1. HTML解析：HTMLコードを解析し、DOM（Document Object Model）ツリーを生成。
  2. CSS解析：CSSスタイルシートを解析し、各要素の見た目を決定。
  3. レンダリングツリーの構築：DOMツリーとCSS情報を組み合わせてレンダリングツリーを構築。
  4. レイアウト計算：要素のサイズ、位置、間隔を計算。
  5. ペイント：計算されたレイアウト情報をもとに、画面上にピクセル単位で描画。

このプロセスにより、ブラウザは動的なWebページを正確かつ効率的に描画します。

ネットワーキング

ブラウザのアドレスバーに「https://www.google.com」と入力し、エンターを押すと、例えば以下の様なネットワーキングプロセスが行われています：

  1. URLの解析：ブラウザがURLを解析し、プロトコル、ホスト名、パスなどの情報を分解。ホスト名がDNS解決の対象となります。
  2. DNS解決：ホスト名をIPアドレスに変換。キャッシュ確認後、ISPのDNSリゾルバーを介して権威DNSサーバーに問い合わせます。
  3. TCP接続の確立：IPアドレスに基づいてTCPハンドシェイク（SYN → SYN-ACK → ACK）を実行。
  4. TLSハンドシェイク：HTTPSの場合、暗号化通信を確立するためのTLSハンドシェイクを実施。
  5. HTTPリクエストの送信：GETリクエストをサーバーに送信し、必要なリソースを要求。
  6. レスポンスの受信：サーバーがHTML、CSS、JavaScript、画像などをブラウザに送信。
  7. レンダリング：受信したデータをもとにレンダリングエンジンがページを描画。
  8. 追加リソースの取得：ページ内で参照されている画像やスクリプトを必要に応じて取得。

JavaScriptエンジン

JavaScriptエンジンは、ブラウザ内でJavaScriptコードを解析、実行するためのコンポーネントです。主な役割：

  • コードの解析：JavaScriptを効率的に実行できる形式（バイトコードなど）に変換。
  • 実行：Webページ内でスクリプトを実行し、動的な動作を提供。
  • 最適化：コードを高速化するためのコンパイルやキャッシュ。

代表的なJavaScriptエンジン：

  • V8（Google Chrome）
  • SpiderMonkey（Mozilla Firefox）
  • JavaScriptCore（Apple Safari）

UIバックエンド

UIバックエンドは、ブラウザのUI（アドレスバー、戻る/進むボタン、タブバーなど）とブラウザエンジンをつなぐ役割を果たします。

主な役割：

  • ユーザー操作の管理：クリックや入力などの操作を検知。
  • ブラウザの状態更新：タブ、ブックマーク、履歴などを制御。
  • エンジンとの連携：ネットワークリクエストやレンダリングエンジンとのやり取りを調整。

UIバックエンドは、ブラウザエンジンの一部として動作し、ブラウザの操作性を支えます。

セキュリティ機能

現代のブラウザは、セキュリティ機能を通じて安全なWeb体験を提供しています。
主なセキュリティ機能として、以下の様なものがあります：

  1. HTTPS対応：TLSで通信を暗号化し、盗聴や改ざんを防止。
  2. サンドボックス化：プロセスやアクセスを分離された環境で実行し、システムへの影響を制限。
  3. フィッシング・マルウェア防止：不審なサイトやダウンロードを検知して警告。
  4. 同一オリジンポリシー：異なるドメイン間でのデータアクセスを制限（サンドボックス化の一環）。
  5. 自動アップデート：セキュリティパッチを迅速に適用。

この様にブラウザは、ブラウザUIに始まり。ブラウザエンジンを主な司令塔として、レンダリングエンジン、JavaScriptエンジン、UIバックエンド、ネットワーキングなどが連携して動作しています。

Webサイト/Webアプリケーションの基礎

Webサイト

Webブラウザについて理解したところで、次にWebサイトやWebアプリケーションについて学びましょう。ここでは、ブラウザがWebサイトやWebアプリケーションにアクセスしてコンテンツを表示するまでのプロセスを見ていきます。

Webサイト

Webサイトは、サーバー上に保存されているHTML、CSS、JavaScriptといったファイルから構成されています。サーバーはインターネットに常時接続されており、ユーザーがページをリクエストすると、ネットワークを通じてそのデータを取得します。その後、ブラウザエンジンがレンダリングエンジンやJavaScriptエンジンを指揮し、ページを表示します。

クライアントとサーバー

ここで、クライアントとサーバーの関係を整理しましょう。

  • クライアント:
    私たちが使用するコンピュータやスマートフォン上のブラウザのことを指します。クライアントはページを閲覧するためにサーバーにリクエストを送信します。つまり、サービスを受ける側のデバイスを指します。

  • サーバー:
    Webサイトのデータ（HTML、CSS、画像など）を保管しているコンピュータのことです。サーバーはリクエストを受け取ると、対応するデータをクライアントに返します。サービスを提供する側のデバイスと考えるとよいでしょう。

このように、ユーザーのページリクエストはクライアントが行い、それに応答するのがサーバーの役割です。この通信モデルを「クライアント/サーバーモデル」（別名：C/Sモデル、クライアントサーバー型）と呼びます。

なお、「P2P（Peer-to-Peer）」モデルとは異なり、クライアント/サーバーモデルではサーバーとクライアントの役割が明確に分かれています。一方、P2Pでは主従関係が固定されず、対等な立場でデータをやり取りします。詳細は、P2Pネットワークの解説を参照してください。

HTTPリクエストとレスポンス

クライアントとサーバーは、「HTTPリクエスト」と「HTTPレスポンス」を通じてやり取りを行います。

  • HTTPリクエスト:
    クライアント（ブラウザ）がサーバーに送る「データをください」というリクエストです。
  • HTTPレスポンス:
    サーバーがリクエストに応じて「データを返す」処理です。これにより、ブラウザはリソースを受け取り、ページを表示します。

HTTPとは？

HTTP（HyperText Transfer Protocol）は、インターネット上で情報を交換するためのプロトコルです。このプロトコルにより、クライアントとサーバー間でWebページや画像、リソースを取得するためのリクエストとレスポンスのルールが定義されています。

HTTPリクエスト

ユーザーがブラウザを通じて特定のURLにアクセスすると、ブラウザはHTTPリクエストをサーバーに送信します。このリクエストには、取得したいリソースの情報や追加情報が含まれます。

リクエストの構造

  1. リクエストライン:
    • リクエストメソッド（例: GET, POST）、URL（URI）、プロトコルバージョンを記載します。
  2. ヘッダ:
    • 通信に必要な追加情報を提供します。例として以下が含まれます:
      • Host: サーバーの名前とポート番号を指定（必須）。
      • User-Agent: クライアントの環境情報。
      • Accept: クライアントが受け入れ可能なコンテンツ形式。
      • Content-Type: POSTやPUTで送信されるデータ形式。
      • Authorization: 認証情報。
  3. 空行:
    • ヘッダーとボディを区切るための空行。
  4. ボディ:
    • データを送信する際に使用されます（例: POSTリクエストでフォームデータを送信）。

主なリクエストメソッド

  • GET: リソースを取得します（最も一般的なメソッド）。
  • POST: サーバーにデータを送信します。
  • PUT: リソースを作成または更新します。
  • DELETE: 指定したリソースを削除します。

HTTPレスポンス

HTTPレスポンスは、サーバーがクライアントからのリクエストに応じて送信するデータのことです。レスポンスには、リクエストの結果を示すステータスコード、サーバーの情報、コンテンツデータ（HTML、画像、JSONなど）が含まれています。これにより、クライアントはリクエストしたリソースを取得し、ブラウザ上で表示します。

レスポンスの構造

HTTPレスポンスは、以下の要素で構成されています：

  1. ステータスライン

    • HTTPプロトコルのバージョン、ステータスコード、ステータスメッセージを記載します。
      例: HTTP/1.1 200 OK
      • HTTP/1.1: プロトコルバージョン
      • 200: ステータスコード（リクエスト成功）
      • OK: ステータスメッセージ

  2. ヘッダー

    • レスポンスに関する追加情報を提供します。主なヘッダーは以下の通りです：
      • Content-Type: 返されるコンテンツの形式（例: text/html、application/json）。
      • Content-Length: レスポンスデータのサイズ（バイト単位）。
      • Set-Cookie: クライアントに保存されるクッキーの情報。
      • Cache-Control: キャッシュの制御に関する指示。
      • Server: レスポンスを生成したサーバーの情報。

  3. 空行

    • ヘッダーとボディを区切るための空行。

  4. ボディ

    • リクエストに応じたデータが含まれます。例えば、HTMLコード、画像データ、JSON形式のAPIレスポンスなどがここに入ります。

ステータスコード

HTTPレスポンスのステータスコードは、リクエストの結果を表します。以下は主要なステータスコードの分類です：

  • 1xx（情報）
    リクエストの受信が開始されたことを示します。

    • 例: 100 Continue（処理を続行可能）

  • 2xx（成功）
    リクエストが正常に処理されたことを示します。

    • 例: 200 OK（リクエスト成功）

  • 3xx（リダイレクト）
    リソースが別の場所に移動したことを示します。

    • 例: 301 Moved Permanently（恒久的リダイレクト）、302 Found（一時的リダイレクト）

  • 4xx（クライアントエラー）
    クライアントのリクエストに問題があることを示します。

    • 例: 400 Bad Request（不正なリクエスト）、404 Not Found（リソースが見つからない）

  • 5xx（サーバーエラー）
    サーバー側で問題が発生したことを示します。

    • 例: 500 Internal Server Error（サーバー内部エラー）、503 Service Unavailable（サービス利用不可）

ステートレス

HTTPは**ステートレス（Stateless）**なプロトコルです。これは、各リクエストとレスポンスが独立しており、サーバーがクライアントの状態を保持しないことを意味します。サーバーは、あるリクエストを処理した後、そのクライアントに関する情報（セッションや状態）を保持せず、次のリクエストは完全に新しいものとして扱います。

メリット

  1. シンプルな設計
    各リクエストは独立しているため、プロトコルや通信の設計がシンプルになります。
  2. スケーラビリティの向上
    サーバーはクライアントの状態を保持する必要がないため、複数のサーバー間でリクエストを簡単に分散できます（ロードバランシングが容易）。
  3. 柔軟性
    サーバーは特定のクライアントに依存しないため、新しいクライアントや異なるデバイスからのアクセスが簡単に可能になります。

デメリットや課題

  1. 状態管理の負担がクライアント側に移る
    サーバーが状態を保持しないため、セッションや認証情報などの状態をクライアントが再送信する必要があります。
  2. 通信量の増加
    毎回のリクエストで必要な情報（認証トークン、セッションIDなど）を送信するため、通信量が増える場合があります。
  3. 状態管理が必要な場合の工夫が必要
    ショッピングカートやログインセッションのような状態管理が必要な場合、クッキーやトークンを使用して、サーバー以外の方法で状態を追跡する必要があります。

状態を管理する方法（クッキー、セッション、トークン）

HTTPがステートレスなプロトコルであるため、状態管理が必要な場面では、以下のような技術を組み合わせてクライアントとサーバー間の状態を維持しています。

1. クッキー（Cookies）

クッキーは、クライアント（ブラウザ）に保存される小さなデータのことです。サーバーがクライアントに対して発行し、クライアントが次回以降のリクエストで自動的にそのデータを送信します。これにより、サーバーはクライアントごとの状態を追跡できます。

特徴

  • 保存場所: クライアントのブラウザ内（ローカルストレージの一部）。
  • 有効期限: クッキーには有効期限を設定できます。期限切れのクッキーは自動的に削除されます。

用途

  • ログイン情報（例: セッションID）
  • ユーザーの設定情報（例: 言語設定やテーマ）
  • トラッキング情報（例: 広告や分析データ）

例
サーバーからのレスポンスに以下のようなヘッダーが含まれると、クライアントにクッキーが保存されます：

Set-Cookie: session_id=abc123; Path=/; HttpOnly; Secure

このクッキーは、以降のリクエストに自動的に付与されます。

2. セッション（Sessions）

セッションは、サーバー側でユーザーの状態を保持する仕組みです。クライアントには一意のセッションIDが割り当てられ、これを利用して状態を管理します。セッションIDは通常、クッキーを通じてクライアントに保存されます。

特徴

  • 状態の保存: サーバー側に保存されるため、クライアントに大きなデータを保持させる必要がありません。
  • セッション管理ツール: Webフレームワーク（例: Express.js、Django）やライブラリで簡単に実装できます。
  • 有効期限: セッションには期限を設定でき、一定時間アクセスがなければセッションを無効化することが可能です。

用途

  • ショッピングカートの内容を管理。
  • ログインセッションの維持。
  • 一時的なユーザーデータの保存（例: フォームデータ）。

例
サーバーは、セッションIDをクッキーまたはリクエストの一部としてクライアントに渡します：

Set-Cookie: session_id=abc123; HttpOnly; Secure

サーバー側で、このIDに関連付けられたデータ（ショッピングカートの内容や認証情報など）を管理します。

3. トークン（Tokens）

トークンは、クライアントがサーバーに対するリクエストで認証や認可を示すためのデータです。特にJSON Web Token（JWT）が一般的で、トークン自体に必要な情報（ペイロード）が埋め込まれているため、サーバー側で状態を保持する必要がありません。

特徴

  • 自己完結型: JWTは認証情報や有効期限を含むため、サーバーでの状態保存が不要。
  • 署名: トークンはサーバーによって署名されており、改ざんが防止されています。
  • 軽量: クライアントとサーバー間で効率的に状態を共有できます。

用途

  • REST APIやGraphQL APIでの認証。
  • シングルページアプリケーション（SPA）でのユーザーセッション管理。
  • サーバーレスアーキテクチャでの状態管理。

例
クライアントがログインに成功すると、サーバーは以下のようなトークンを返します：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjoxMjMsImV4cCI6MTYxNjM1MDk5OX0.sVl8aJwzQQ9wfxX4OC6PI5TnSmw6RN-u1hU9wL6-ljk

以降のリクエストでは、このトークンをヘッダーに含めて送信します：

Authorization: Bearer <トークン>

HTTPS

HTTPS（HyperText Transfer Protocol Secure）は、HTTPに暗号化機能を追加した通信プロトコルです。HTTPSは通信内容を暗号化することで、データの盗聴や改ざん、なりすましを防止します。主に、SSL/TLSプロトコルを使用して暗号化通信を実現します。

HTTPSの特徴

  1. データの暗号化

    • クライアントとサーバー間で送受信されるデータを暗号化するため、第三者が内容を盗聴することを防ぎます。

  2. データの改ざん防止

    • 通信中にデータが改ざんされていないことを確認する仕組み（メッセージ認証コード）を提供します。

  3. サーバー認証

    • サーバーが信頼できるものであることを証明するために、サーバー証明書を使用します。

SSL/TLSによる暗号化通信

SSL（Secure Sockets Layer）とTLS（Transport Layer Security）は、HTTPS通信における暗号化の仕組みを提供するプロトコルです。TLSはSSLの後継バージョンであり、現在のHTTPS通信では主にTLSが使用されています。TLSは、SSLに比べてセキュリティやパフォーマンスが向上しており、既知の脆弱性が修正されています。

TLSハンドシェイクの流れ

TLSハンドシェイクは、クライアントとサーバーが暗号化通信を開始するためのプロセスです。以下はその主な流れです：

  1. クライアントHello

    • クライアントは、TLSのバージョン、対応可能な暗号化方式（暗号スイート）のリスト、ランダムデータなどをサーバーに送信します。

  2. サーバーHello

    • サーバーは、暗号化方式（暗号スイート）の選択、セッションID、ランダムデータをクライアントに送信し、サーバー証明書を提供します。この証明書により、サーバーの身元が確認されます。

  3. 鍵交換とセッションキー生成

    • クライアントとサーバーは公開鍵暗号方式（例: RSAやECDHE）を使用してセッションキーを生成します。このキーは以降の通信を暗号化するために使用されます。

  4. 暗号化通信の開始

    • セッションキーが共有されると、以降の通信は共通鍵暗号方式（例: AES）を使用して暗号化されます。この方式は公開鍵暗号よりも高速で効率的です。

TLSのセキュリティ機能

  1. 暗号化

    • クライアントとサーバー間の通信内容を暗号化し、第三者による盗聴を防ぎます。例えば、オンラインショッピング時のクレジットカード情報の保護などに使用されます。

  2. 認証

    • サーバー証明書を使用してサーバーの正当性を確認します。一部のシステムではクライアントの認証も可能です（例: クライアント証明書を使用した企業内通信）。

  3. 完全性

    • メッセージ認証コード（MAC）を使用して、データが通信中に改ざんされていないことを保証します。たとえば、送信中にデータが変更された場合、クライアントとサーバーで不一致が検出されます。

TLSハンドシェイクの位置づけ

前述したネットワーキングの項の通り、TLSハンドシェイクはTCP接続の確立後に行われます。
TLSハンドシェイクが無事に完了すると、クライアントとサーバーは暗号化されたセッションキーを共有し、安全な通信を確立します。その後、ブラウザはHTTPSリクエストを送信し、暗号化されたレスポンスを受け取ります。これにより、通信全体が保護され、データの盗聴や改ざんのリスクが軽減されます。

Webサーバーの基礎

Webサーバー

Webサーバーの動作原理

Webサーバーは、クライアント（ブラウザ）からのリクエストを受け取り、適切なレスポンス（HTMLファイルや画像など）を返す役割を果たします。

  1. リクエストの受信

    • クライアントから送信されたHTTPリクエストを受け取ります。

  2. リクエストの解析

    • リクエストライン（メソッドやURL）やヘッダー情報を解析し、どのリソースを提供するべきかを判断します。

  3. レスポンスの生成

    • 静的ファイルの場合は、指定されたファイルを読み込み、レスポンスとして返します。
    • 動的コンテンツの場合は、バックエンド（アプリケーションサーバーやデータベース）との連携によりデータを生成します。

  4. レスポンスの送信

    • 必要なリソースをレスポンスとしてクライアントに送信します。

Webサーバーの種類

  1. 静的Webサーバー

    • HTMLや画像などの静的コンテンツをそのまま配信します。
    • 例: Apache HTTP Server、Nginx

  2. 動的Webサーバー

    • WEBアプリケーションを配信するためのサーバーです。
    • リクエストに応じて動的にコンテンツを生成します（バックエンドと連携）。
    • 例: Node.js、Apache Tomcat

ホスティングとの関係

Webサーバーはホスティングサービスと密接に関連しています。ホスティングサービスは、Webサイトをインターネット上で公開するために、Webサーバーやその周辺環境を提供します。

  1. 共有ホスティング

    • 複数のWebサイトが1つのサーバーを共有します。コストは低いですが、リソースが他のサイトと共有されるため、パフォーマンスに影響が出る場合があります。

  2. VPS（仮想専用サーバー）

    • 1台の物理サーバーを仮想化して複数の独立したサーバーとして提供。柔軟性とパフォーマンスが向上します。

  3. 専用サーバー

    • サーバー1台を1つのユーザーが専有するサービス。高いパフォーマンスと自由度が特徴です。

  4. クラウドホスティング

    • 必要に応じてリソースを動的にスケールできる柔軟なホスティングサービス。Amazon Web Services（AWS）やMicrosoft Azureが代表例です。

適切なホスティングには、自身がWebサーバーに求めるパフォーマンス、コスト、セキュリティや拡張性などを分析し適したホスティングの種類とそのプロバイダーを選択する必要があります。

まとめ

この様にしてWebの技術と進化に伴い、多様なサービスが提供されています。ユーザーに快適で安全なサービスを提供するためには、ここで解説した技術以外にもさまざまな対策が必要です。セキュリティ対策を講じる際には、エンジニアはプログラミングだけでなく、ブラウザから始まるユーザーの行動を想定したり、悪意のあるユーザーがどのようにリクエストを送り、どの経路でサーバーに到達するかを複数のシナリオで考慮し、適切な対策を講じる必要があると思います。

個人的な経験則では、実際の開発現場でセキュリティ意識が希薄になりがちであり、人為的なミスが脆弱性を生むことがあります。詐欺が減らないのは、騙される人がいるからであり、同様にサイバーセキュリティの問題も、人為的な脆弱性が原因で被害が発生することが多いです。タスクの締め切りに追われる中でセキュリティ意識を持ち続けるのは難しいかもしれませんが、セキュリティテストの実施や補助的なセキュリティソフトウェアの導入など、何らかの工夫を凝らす知識や発想が必要なのかもしれません。この投稿が、そのきっかけになれば幸いです。

Discussion