令和５年春　午後Ⅱ　問２

問2　ECサーバの増強に関する次の記述を読んで、設問に答えよ。

　Y社は、従業員300名の事務用品の販売会社であり、会員企業向けにインターネットを利用して通信販売を行っている。ECサイトは、Z社のデータセンター(以下、Z-DCという)に構築されており、Y社の運用PCを使用して運用管理を行っている。

　ECサイトに関連するシステムの構成を図1に示し、DNSサーバに設定されているゾーン情報を図2に示す。

[ECサイトに関連するシステムの構成、運用及びセッション管理方法]

•会員企業の事務用品購入の担当者(以下、購買担当者という)は、Webブラウザでhttps://ecsv.example.jp/を指定してECサーバにアクセスする。

•運用担当者は、運用PCのWebブラウザでhttps://ecsv.y-sha.example.lan/を指定して、広域イーサ網経由でECサーバにアクセスする。

•ECサーバに登録されているサーバ証明書は一つであり、マルチドメインに対応していない。

•ECサーバは、アクセス元のIPアドレスなどをログとして管理している。

•DMZのDNSサーバは、ECサイトのインターネット向けドメインexample.jpと、社内向けドメインy-sha.example.lanの二つのドメインのゾーン情報を管理する。

•L3SWには、DMZへの経路とデフォルトルートが設定されている。

•運用PCは、DMZのDNSサーバで名前解決を行う。

•FWzには、表1に示す静的NATが設定されている。

　ECサーバは、次の方法でセッション管理を行っている。

•Webブラウザから最初にアクセスを受けたときに、ランダムな値のセッションIDを生成する。

•Webブラウザへの応答時に、CookieにセッションIDを書き込んで送信する。

•WebブラウザによるECサーバへのアクセスの開始から終了までの一連の通信を、セッションIDを基に、同一のセッションとして管理する。

[ECサイトの応答速度の低下]

　最近、購買担当者から、ECサイト利用時の応答が遅くなったというクレームが入るようになった。そこで、Y社の情報システム部(以下、情シスという)のネットワークチームのX主任は、運用PCを使用して次の手順で原因究明を行った。

（1）購買担当者と同じURLでアクセスし、応答が遅いことを確認した。

（2）ecsv.example.jp及びecsv.y-sha.example.lan宛てに、それぞれpingコマンドを発行して応答時間
　　を測定したところ、両者の測定結果に大きな違いはなかった。

（3）FWzのログからはサイバー攻撃の兆候は検出されなかった。

（4）sshコマンドで①ecsv.y-sha.example.lanにアクセスしてCPU使用率を調べたところ、設計値を大
　　きく超えていた。

　この結果から、X主任は、ECサーバが処理能力不足になったと判断した。

[ECサーバの増強構成の設計]

　X主任は、ECサーバの増強が必要になったことを上司のW課長に報告し、W課長からECサーバの増強構成の設計指示を受けた。

　ECサーバの増強策としてスケール（　g　）方式とスケール（　h　）方式を比較検討し、ECサイトを停止せずにECサーバの増強を行える、スケール（　h　）方式を採用することを考えた。

　X主任は、②ECサーバを2台にすればECサイトは十分な処理能力をもつことになるが、2台増設して3台にし、負荷分散装置(以下、LBという)によって処理を振り分ける構成を設計した。ECサーバの増強構成を図3に示し、DNSサーバに追加する社内向けドメインのリソースレコードを図4に示す。

　ECサーバ増強後、購買担当者がWebブラウザでhttps://ecsv.example.jp/を指定してECサーバにアクセスし、アクセス先が既設ECサーバに振り分けられたときのパケットの転送経路を図5に示す。

　導入するLBには、負荷分散用のIPアドレスである仮想IPアドレスで受信したパケットをECサーバに振り分けるとき、送信元IPアドレスを変換する方式(以下、ソースNATという)と変換しない方式の二つがある。図5中の（ⅰ）〜（ⅵ）でのIPヘッダーのIPアドレスの内容を表2に示す。

[ECサーバの増強構成とLBの設定]

　X主任が設計した内容をW課長に説明したときの、2人の会話を次に示す。

X主任：LBを利用してECサーバを増強する構成を考えました。購買担当者がECサーバにアクセスする
　　　ときのURLの変更は不要です。

W課長：DNSサーバに対しては、図4のレコードを追加するだけで良いのでしょうか。

X主任：そうです。ECサーバの増強後も、図2で示したゾーン情報の変更は不要ですが、③図2中の項
　　　番5と項番11のリソースレコードは、図3の構成では図1とは違う機器の特別なIPアドレスを示す
　　　ことになります。また、④図4のリソースレコードの追加に対応して、既設ECサーバに設定され
　　　ている二つの情報を変更します。

W課長：分かりました。LBではソースNATを行うのでしょうか。

X主任：現在のECサーバの運用を変更しないために、ソースNATは行わない予定です。この場合、パ
　　　ケットの転送を図5の経路にするために、⑤既設ECサーバでは、デフォルトゲートウェイのIPア
　　　ドレスを変更します。

W課長：次に、ECサーバのメンテナンス方法を説明してください。

X主任：はい。まず、メンテナンスを行うECサーバを負荷分散の対象から外し、その後に、運用PCか
　　　ら当該ECサーバにアクセスして、メンテナンス作業を行います。

W課長：X主任が考えている設定では、運用PCからECサーバとは通信できないと思いますが、どうで
　　　しょうか。

X主任：うっかりしていました。導入予定のLBはルータとしては動作しませんから、ご指摘の問題が発
　　　生してしまいます。対策方法として、ECサーバに設定するデフォルトゲートウェイを図1の構成
　　　時のままとし、LBではソースNATを行うとともに、⑥ECサーバ宛てに送信するHTTPヘッダー
　　　にX-Forwarded-Forフィールドを追加するようにします。

W課長：それで良いでしょう。ところで、図3の構成では、増設ECサーバにもサーバ証明書をインス
　　　トールすることになるのでしょうか。

X主任：いいえ。増設ECサーバにはインストールせずに⑦既設ECサーバ内のサーバ証明書の流用で対
　　　応できます。

W課長：分かりました。負荷分散やセッション維持などの方法は設計済みでしょうか。

 X主任：構成が決まりましたので、これからLBの制御方式について検討します。

[LBの制御方式の検討]

　X主任は、導入予定のLBがもつ負荷分散機能、セッション維持機能、ヘルスチェック機能の三つについて調査し、次の方式を利用することにした。

•負荷分散機能

　アクセス元であるクライアントからのリクエストを、負荷分散対象のサーバに振り分ける機能である。Y社のECサーバは、リクエストの内容によってサーバに掛かる負荷が大きく異なるので、ECサーバにエージェントを導入し、エージェントが取得した情報を基に、ECサーバに掛かる負荷の偏りを小さくすることが可能な動的振分け方式を利用する。

•セッション維持機能

　同一のアクセス元からのリクエストを、同一セッションの間は同じサーバに転送する機能である。アクセス元の識別は、IPアドレス、IPアドレスとポート番号との組合せ、及びCookieに記録された情報によって行う、三つの方式がある。IPアドレスでアクセス元を識別する場合、インターネットアクセス時に送信元IPアドレスが同じアドレスになる会員企業では、複数の購買担当者がアクセスするECサーバが同一になってしまう問題が発生する。⑧IPアドレスとポート番号との組合せでアクセス元を識別する場合は、TCPコネクションが切断されると再接続時にセッション維持ができなくなる問題が発生する。そこで、⑨Cookie中のセッションIDと振分け先のサーバから構成されるセッション管理テーブルをLBが作成し、このテーブルを使用してセッションを維持する方式を利用する。

•ヘルスチェック機能

　振分け先のサーバの稼働状態を定期的に監視し、障害が発生したサーバを負荷分散の対象から外す機能である。⑩ヘルスチェックは、レイヤー3、4及び7の各レイヤーで稼働状態を監視する方式があり、ここではレイヤー7方式を利用する。

　X主任が、LBの制御方式の検討結果をW課長に説明した後、W課長から新たな検討事項の指示を受けた。そのときの、2人の会話を次に示す。

W課長：運用チームから、ECサイトのアカウント情報の管理負荷が大きくなってきたので、管理負荷
　　　の軽減策の検討要望が挙がっています。会員企業からは、自社で管理しているアカウント情報
　　　を使ってECサーバにログインできるようにして欲しいとの要望があります。これらの要望に応
　　　えるために、ECサーバのSAML2.0(Security Assertion Markup Language 2.0)への対応について
　　　検討してください。

X主任：分かりました。検討してみます。

[SAML2.0の調査とECサーバへの対応の検討]

　X主任がSAML2.0について調査して理解した内容を次に示す。

•SAMLは、認証・認可の要求/応答のプロトコルとその情報を表現するための標準規格であり、一度の認証で複数のサービスが利用できるシングルサインオン(以下、SSOという)を実現することができる。

•SAMLでは、利用者にサービスを提供するSP(Service Provider)と、利用者の認証・認可の情報をSPに提供するIdP(Identity Provider)との間で、情報の交換を行う。

•IdPは、SAMLアサーションと呼ばれるXMLドキュメントを作成し、利用者を介してSPに送信する。SAMLアサーションには、次の三つの種類がある。

（a）利用者がIdPにログインした時刻、場所、使用した認証の種類などの情報が記述される。

（b）利用者の名前、生年月日など利用者を識別する情報が記述される。

（c）利用者がもつサービスを利用する権限などの情報が記述される。

•SPは、IdPから提供されたSAMLアサーションを基に、利用者にサービスを提供する。

•IdP、SP及び利用者間の情報の交換方法は、SAMLプロトコルとしてまとめられており、メッセージの送受信にはHTTPなどが使われる。

•z-DCで稼働するY社のECサーバがSAMLのSPに対応すれば、購買担当者は、自社内のディレクトリサーバ(以下、DSという)などで管理するアカウント情報を使って、ECサーバに安全にSSOでアクセスできる。

　X主任は、ケルベロス認証を利用して社内のサーバにSSOでアクセスしている会員企業e社を例として取り上げ、e社内のPCがSAMLを利用してY社のECサーバにもSSOでアクセスする場合のシステム構成及び通信手順について考えた。

　会員企業e社のシステム構成を図6に示す。

図6で示した会員企業e社のシステムの概要を次に示す。

•e社ではケルベロス認証を利用し、社内サーバにSSOでアクセスしている。

•e社内のDSは、従業員のアカウント情報を管理している。

•PC及び社内サーバは、それぞれ自身の共通鍵を保有している。

•DSは、PC及び社内サーバそれぞれの共通鍵の管理を行うとともに、チケットの発行を行う鍵配布センター(以下、KDCという)機能をもっている。

•KDCが発行するチケットには、PCの利用者の身分証明書に相当するチケット(以下、TGTという)とPCの利用者がアクセスするサーバで認証を受けるためのチケット(以下、STという)の2種類がある。

•認証連携サーバはIdPとして働き、ケルベロス認証とSAMLとの間で認証連携を行う。

　X主任は、e社内のPCからY社のECサーバにSAMLを利用してSSOでアクセスするときの通信手順と処理の概要を、次のようにまとめた。

　e社内のPCからECサーバにSSOでアクセスするときの通信手順を図7に示す。

図7中の、（ⅰ）～（ⅸ）の処理の概要を次に示す。

（ⅰ）購買担当者がPCを使用してECサーバにログイン要求を行う。

（ⅱ）SPであるECサーバは、⑪SAML認証要求(SAML Request)を作成しIdPである認証連携サーバに
　　リダイレクトを要求する応答を行う。

　　　ここで、ECサーバには、⑫IdPが作成するデジタル署名の検証に必要な情報などが設定され、
　　IdPとの間で信頼関係が構築されている。

（ⅲ）PCはSAML RequestをIdPに転送する。

（ⅳ）IdPはPCに認証を求める。

（ⅴ）PCは、KDCにTGTを提示してIdPへのアクセスに必要なSTの発行を要求する。

（ⅵ）KDCは、TGTを基に、購買担当者の身元情報やセッション鍵が含まれたSTを発行し、IdPの鍵で
　　STを暗号化する。さらに、KDCは、暗号化したSTにセッション鍵などを付加し、全体をPCの鍵
　　で暗号化した情報をPCに払い出す。

（ⅶ）PCは、⑬受信した情報の中からSTを取り出し、ケルベロス認証向けのAPIを利用して、STを
　　IdPに提示する。

（ⅷ）IdPは、STの内容を基に購買担当者を認証し、デジタル署名付きのSAMLアサーションを含む
　　SAML応答(SAML Response)を作成して、SPにリダイレクトを要求する応答を行う。

（ⅸ）PCは、SAML ResponseをSPに転送する。SPは、SAML Responseに含まれる⑭デジタル署名
　　を検証し、検証結果に問題がない場合、SAMLアサーションを基に、購買担当者が正当な利用者で
　　あることの確認、及び購買担当者に対して提供するサービス範囲を定めた利用権限の付与の、二
　　つの処理を行う。

　Ｘ主任は、ECサーバのSAML2.0対応の検討結果を基に、SAML2.0に対応する場合のECサーバプログラムの改修作業の概要をＷ課長に説明した。

　Ｗ課長は、Ｘ主任の設計したECサーバの増強案、及びSAML2.0対応のためのECサーバの改修などについて、経営会議で提案して承認を得ることができた。

設問１

図2中の（　a　）～（　b　）に入れる適切なリソースレコード名を、（　c　）～（　f　）に入れる適切なIPアドレスを、それぞれ答えよ。

図2には、DNSサーバに設定されている ゾーン情報 が示されています。

ゾーン情報は、ドメインに紐づくリソースレコード（RR, Resource Record）を定義するもので、各行の形式は以下の通りです。

ホスト名 クラス タイプ データ

ここで、タイプ（Type）には代表的に次のような種類があります。

• NS（Name Server）：ゾーンの権威DNSサーバを指定する
• MX（Mail eXchanger）：メール配送先サーバを指定する
• A：ホスト名に対応するIPアドレスを指定する

a の位置は「IN a ns.example.jp.」のように、ゾーンの権威DNSサーバを定義する部分なので、NS が入ります。

b の位置は「IN b 10 mail.example.jp.」のように、メールサーバの優先度とホスト名を記載する部分なので、MX が入ります。

c：100.α.β.1

項番4の ns.example.jp. は、外部からアクセスされる権威DNSサーバを示しています。

このDNSサーバはインターネット側から問い合わせを受けるため、ゾーン情報にはグローバルIPアドレスを設定する必要があります。

表1を見ると、DNSサーバは静的NATによって 192.168.1.1 とグローバルIP 100.α.β.1 が対応付けられています。

外部向けゾーンでは変換前のグローバルIPを記載するため、ここには 100.α.β.1 が入ります。

d：100.α.β.3

項番6の mail.example.jp. は、外部からメールを受け取るメールサーバを示しています。

このメールサーバもインターネット経由でアクセスされるため、ゾーン情報にはグローバルIPアドレスを設定します。

表1によれば、メールサーバのプライベートIP 192.168.1.3 に対応するグローバルIPは 100.α.β.3 です。

したがって、この欄には 100.α.β.3 が入ります。

e：192.168.1.1

項番10の ns.y-sha.example.lan は、社内向けの権威DNSサーバを示しています。

このレコードは、社内ネットワークから直接アクセスされるため、インターネット経由の通信やNAT変換は不要です。

図3および図4から、DNSサーバのプライベートIPは 192.168.1.1 であることが分かります。

したがって、この欄には 192.168.1.1 を設定します。

f：192.168.1.3

項番12の mail.y-sha.example.lan は、社内向けのメールサーバを示しています。

こちらも社内からのアクセスのみを想定しており、直接プライベートIPアドレスで指定します。

表4から、メールサーバのプライベートIPは 192.168.1.3 であることが分かります。

したがって、この欄には 192.168.1.3 を設定します。

設問２

[ECサイトの応答速度の低下]について答えよ。

URLをhttps://ecsv.y-sha.example.lan/に設定してECサーバにアクセスすると、TLSのハンドシェイク中にエラーメッセージがWebブラウザに表示される。その理由を、サーバ証明書のコモン名に着目して、25字以内で答えよ。

1. TLSハンドシェイクとサーバ証明書の役割

HTTPS通信では、接続開始時にTLSハンドシェイクが行われます。

この中で、サーバはサーバ証明書をクライアント（Webブラウザ）に提示し、「私はこのドメイン名の正当なサーバである」ということを証明します。

証明書には大きく以下の情報が含まれます。

• コモン名（CN）：証明書が有効なFQDN（例：ecsv.example.jp）
• Subject Alternative Name（SAN）：CN以外で有効なドメイン名のリスト（複数登録可能）
• 有効期限、発行者情報、公開鍵など

ブラウザはこの証明書を受け取り、アクセス先のURLのホスト名と、証明書のCN/SANを照合します。

2. 今回の状況

今回アクセスしたURLは

https://ecsv.y-sha.example.lan/

ですが、問題文からわかる通り、

• ECサーバにはサーバ証明書が1つだけ登録されている
• マルチドメインに対応していない（SANに複数ドメインが入っていない）

つまり、この証明書はおそらく ecsv.example.jp 用に発行されたもので、内部向けドメイン ecsv.y-sha.example.lan は証明書上のCNにもSANにも記載されていません。

3. ブラウザでエラーになる理由

TLSハンドシェイク中の証明書検証では、次のような照合が行われます。

1. ブラウザはURLからホスト名（ecsv.y-sha.example.lan）を取得
2. サーバから送られてきた証明書のCN/SANを確認（例：ecsv.example.jp）
3. ホスト名と証明書のCN/SANが一致しなければ、「名前の不一致エラー」と判定

今回のケースでは 1 と 2 が異なるため、ブラウザは警告画面を表示します。

代表的なエラーメッセージは以下のようなものです。

• Firefox：「警告: 潜在的なセキュリティリスクあり」
• Chrome：「この接続ではプライバシーが保護されません（NET::ERR_CERT_COMMON_NAME_INVALID）」

4. なぜこのような構成なのか

内部向けアクセス用URLと外部公開URLでドメイン名が異なるのは、

• ネットワークの経路やゾーン情報を分けるため
• 内部ではプライベートDNS名を使いたい場合があるため

しかし、証明書を1つしか用意せず、マルチドメイン対応をしていない場合は、内部用URLでアクセスするとこのようなCN不一致エラーが必ず発生します。

5. 解決策の例

• 内部用に別の証明書を発行する（ただし管理負担が増える）
• SAN拡張に内部ドメイン名も追加して再発行する
• 内部向けアクセスも外部公開ドメイン名で行うようDNSを調整する

本文中の下線①でアクセスしたとき、運用PCが送信したパケットがECサーバに届くまでに経由する機器を、図1中の機器名で全て答えよ。

下線①は、運用PCが https://ecsv.y-sha.example.lan/ を指定して ECサーバにアクセスする場面です。

運用PCは社内ネットワークにあり、ECサーバは Z社データセンター（Z-DC）のDMZに設置されています。

問題文にある通り、運用PCはDMZのDNSサーバで名前解決を行い、得られた内部向けドメインのIPアドレスを使って接続します。

では、なぜ「広域イーサ網」を経由する必要があるのでしょうか。

運用PCはY社のオフィス内にあり、ECサーバはZ社のデータセンタ（Z-DC）のDMZに設置されています。

両者は同じLANに属しているわけではないので、直接のL2接続では到達できません。

代わりに、Y社拠点とZ-DCを接続するために契約されている閉域網サービス＝広域イーサ網を通過する必要があります。

これにより、Y社の運用PCから見て、Z-DC内のECサーバまでが一つの延長LANのように接続されるわけです。

図1を見ると、運用PCからECサーバまでの通信経路は次のようになります。

1. 運用PCから最初に到達するのは社内側のL3SW（レイヤ3スイッチ）です。
   L3SWは社内LANとDMZをつなぐルーティングを担当します。
2. L3SWからDMZに出る際には、境界に設置されたFWz（ファイアウォール）を通過します。
   FWzは社内とDMZの間のアクセス制御を行います。
3. FWzを抜けると、DMZ内のスイッチであるL2SW（レイヤ2スイッチ）を経由し、最終的にECサーバへ到達します。

• DNSサーバは名前解決のために別途通信しますが、今回の設問は「アクセス時のパケット経路」を問うており、HTTP/TLSパケットが通る経路のみを答えます。
• インターネットや外部向けルータは経由せず、全て社内〜DMZ内の閉域経路で完結します。

この順序は図1の物理構成にも対応しており、他の機器を経由する可能性はありません。

設問３

[ECサーバの増強構成の設計]について答えよ。

本文中の（　g　）、（　h　）に入れる適切な字句を答えよ。

本文では、ECサーバの処理能力不足に対して「スケール（　g　）方式」と「スケール（　h　）方式」を比較検討しています。

一般に、スケールアップは既存サーバのCPU・メモリ・ストレージなどの垂直方向の拡張を指し、スケールアウトはサーバ台数を増やして水平方向に拡張することを指します。

本問の文脈では、「ECサイトを停止せずにECサーバの増強を行える方式」を採用したいとあります。

スケールアップは物理増設や再起動、メンテナンスウィンドウの確保が必要になりやすく、無停止での拡張は難しい場合が多いです。

これに対し、スケールアウトは新規サーバを順次追加し、負荷分散装置（LB）の配下に組み込むだけで処理能力を段階的に引き上げられ、既存サービスを止めずに対応しやすい方式です。

このため、（g）はアップ、（h）はアウトとなります。

• g：アップ（スケールアップ＝垂直拡張）
• h：アウト（スケールアウト＝水平拡張）

加えて、本文でもECサーバを3台構成＋LBで振り分ける設計が示されており、まさにスケールアウトの採用根拠になっています。

スケールアウトであれば、ヘルスチェックで不調サーバを自動的に対象外にしつつ、セッション維持機能を組み合わせることで、利用者影響を抑えながら計画的に増強・保守が可能です。

本文中の下線②について、2台ではなく3台構成にする目的を、35字以内で答えよ。ここで、将来のアクセス増加については考慮しないものとする。

本文では、X主任がECサーバの増強方法を検討する際に「2台構成でも処理能力は十分確保できるが、あえて3台構成にする」という判断をしています。

また、問題文には「将来のアクセス増加は考慮しない」という条件があるため、将来的な拡張性ではなく現在の安定稼働・可用性確保に着目する必要があります。

もし2台構成で稼働している状況で、1台が故障・メンテナンス停止すると、残る1台に全てのアクセスが集中します。

ECサイトの利用者数は変わらないため、1台では処理能力が不足し、応答速度が顕著に低下する恐れがあります。

つまり、平常時は十分な性能を発揮できても、障害時にはサービス品質が著しく低下するというリスクがあります。

3台構成にしておけば、仮に1台が停止しても残りの2台で処理を分散できます。

今回の前提では「2台あれば処理能力は十分」という条件があるため、障害発生後も性能が低下せず、ユーザ体験を維持できます。

このような構成は、冗長性の確保やフォールトトレランス（障害耐性）の向上と呼ばれます。

システム設計では「N+1構成」という考え方があります。

• N台で必要な処理能力を満たす場合、N+1台用意することで1台が停止しても性能低下なく稼働できる
  今回のケースでは、必要台数N=2なので、N+1＝3台構成が該当します。

表2中の（　i　）～（　k　）に入れる適切なIPアドレスを答えよ。

表2は、図5のパケット転送経路（LBを経由して既設ECサーバにアクセスするケース）における、各区間のIPヘッダー情報を示しています。

問題の（i）〜（k）は、特定区間の宛先IPアドレス（または送信元IPアドレス）を問うもので、機器間の接続関係とNATの有無を理解していれば導けます。

i：100.α.β.2

（i）は、購買担当者のPCから見たときのアクセス先IPアドレスです。

購買担当者はブラウザで https://ecsv.example.jp/ を指定してアクセスしますが、このホスト名はDNSで解決され、グローバルIPアドレス 100.α.β.2 に変換されます。

このIPは、インターネット側からLB（負荷分散装置）を指す仮想IP（VIP）として機能します。

したがって、（i）には 100.α.β.2 が入ります。

j：192.168.1.2

（j）は、LBから既設ECサーバにパケットを転送するときの宛先IPアドレスです。

LBと既設ECサーバはどちらもDMZ内にあり、NAT変換を行わずにプライベートIPで通信します。

図3および表1から、既設ECサーバのプライベートIPは 192.168.1.2 であることが分かります。

そのため、（j）には 192.168.1.2 が入ります。

k：192.168.1.4

（k）は、LBがソースNATを行う場合に利用する送信元IPアドレスを問うものです。

LBはクライアントからのリクエストを受け取ると、内部のECサーバへ転送しますが、このとき送信元IPをそのままクライアントのIPにしてしまうと、ECサーバが応答を返す際にFWzに直接戻してしまう可能性があります。

これではLBを経由せず、セッション管理や負荷分散が成立しなくなります。

そこでLBは、ECサーバにリクエストを渡すとき、送信元IPアドレスを自分自身のものに書き換えます。

これがソースNATの動作であり、応答パケットが必ずLBを経由するようになるため、通信経路が安定します。

図4のリソースレコードを見ると、LBのDMZ側に割り当てられているIPアドレスは 192.168.1.4 です。

したがって、（k）には 192.168.1.4 が入ります。

こうすることで、ECサーバの応答は確実にLBを通り、外部クライアントとのやり取りが途切れずに成立します。

設問４

[ECサーバの増強構成とLBの設定]について答えよ。

本文中の下線③について、どの機器を示すことになるかを、図3中の機器名で答えよ。また、下線③の特別なIPアドレスは何と呼ばれるかを、本文中の字句で答えよ。

1. 下線③が登場する文脈

本文の該当部分では、X主任がW課長に対して「ECサーバの増強後も図2で示したゾーン情報の変更は不要」と説明しています。

ただし、その中で「図2中の項番5と項番11のリソースレコードは、図3の構成では図1とは違う機器の特別なIPアドレスを示すことになる」と補足しています。

2. 項番5と項番11の意味

• 項番5：インターネット向けドメイン ecsv.example.jp のAレコード
• 項番11：社内向けドメイン ecsv.y-sha.example.lan のAレコード

図1（増強前）では、これらのAレコードは直接、既設ECサーバのIPアドレスを指していました。

つまり、クライアントは名前解決をすると、そのままECサーバに接続していました。

3. 図3（増強後）の変化

増強後は、既設ECサーバに加えて増設ECサーバを導入し、その前面にLB（負荷分散装置）を設置します。

このとき、クライアントがアクセスすべき「宛先IP」はECサーバ個別のIPではなく、LBが持つ共通の受付口になります。

この共通の受付口が「特別なIPアドレス」であり、負荷分散用に使う仮想IPアドレス（VIP）です。

4. 仮想IPアドレス（VIP）の役割

仮想IPアドレスは、LBがクライアントからの接続要求を受け取るために持つ論理的なIPです。

クライアントはVIPに向けてアクセスしますが、実際の処理はLBが内部で各ECサーバに振り分けます。

これにより、

• クライアントから見たアクセス先は増強前と同じ（ゾーン情報を変更せずに済む）
• サーバを増減させてもクライアント設定は不要

というメリットが得られます。

5. まとめ

• どの機器：LB（負荷分散装置）
• IPアドレスの呼称：仮想IPアドレス（VIP）

この構成変更によって、外部からも内部からも同じFQDNでアクセスでき、LBが裏側で複数台のECサーバへ効率よく振り分けることが可能になります。

本文中の下線④について、ホスト名のほかに変更する情報を答えよ。

本文中の下線④は、図4のリソースレコード追加に伴い「既設ECサーバに設定されている二つの情報を変更する」と説明している箇所です。

この「二つの情報」のうち、一つはホスト名、もう一つが今回の設問で問われています。

ECサーバ増強後は、既設ECサーバも増設ECサーバもLB（負荷分散装置）の配下に入ります。

そのため、既設ECサーバに設定されているホスト名は、新しい構成に合わせて変更する必要があります。

また、LBがECサーバにトラフィックを振り分けるためには、各サーバのIPアドレス設定も新構成に適合させなければなりません。

ホスト名の変更だけでは、サーバは新構成で正しく通信できません。

既設ECサーバはDMZ内でLBと直接やり取りするため、自身のIPアドレスをLB配下用のものに変更する必要があります。

このIPは、LBが背後の各サーバに振り分ける際に使うプライベートIPであり、仮想IP（VIP）ではなくサーバ固有のアドレスです。

下線④で求められている「ホスト名のほかに変更する情報」は、（自身の）IPアドレスです。

ホスト名とIPアドレスの両方を正しく設定することで、DNS名解決やLBの振り分けが意図通りに機能し、増強後もECサイトを安定稼働させることができます。

項目	増強前	増強後（既設ECサーバ）	増強後（増設ECサーバ）
外部向けホスト名	ecsv.example.jp	ecsv.example.jp（LBのVIPを指す）	―
内部向けホスト名	ecsv.y-sha.example.lan	ecsv.y-sha.example.lan（LBのVIPを指す）	―
グローバルIP	100.α.β.2（FWzでNATされる）	100.α.β.2（VIPとしてLBに集約）	―
プライベートIP	192.168.1.2（ECサーバ）	192.168.1.2（既設ECサーバ用）	192.168.1.4（増設1）、192.168.1.6/7（増設2,3）
補足	1台構成。直接FWz経由で到達	LB配下で動作し、VIPを通じて振り分けられる	LB配下で動作。直接は参照されずVIP経由

本文中の下線⑤について、どの機器からどの機器のIPアドレスに変更するのかを、図3中の機器名で答えよ。

デフォルトゲートウェイとは、そのサーバから見て「行き先が分からない通信を送る相手」であり、外部ネットワークに出るための“出口”のような役割を持っています。

増強前の構成では、既設ECサーバが外部（インターネットや社内LAN外のネットワーク）へ通信する際、必ずFWz（ファイアウォール）を通るように設定されていました。

ところが、ECサーバを増強してLB（負荷分散装置）を導入する構成に変えると、状況が変わります。

LBはクライアントからのアクセスを受け取り、複数台のECサーバに振り分ける役割を持ちます。

ソースNATを行わない構成では、クライアントの送信元IPアドレスをそのまま保持してサーバに渡すため、応答パケットも必ずLB経由で戻す必要があります。

もしデフォルトゲートウェイを従来通りFWzのままにしてしまうと、ECサーバからの応答は直接FWzに戻ってしまい、LBをバイパスする“抜け道”ができてしまいます。

これにより、クライアントからサーバへの通信だけでなく、サーバからクライアントへの応答もLB経由となり、負荷分散やセッション維持の機能が正しく動作します。

つまり、この設定変更は、LBをネットワークの正しい経路上に組み込み、増強後の構成を安定して運用するための重要なポイントなのです。

本文中の下線⑥について、X-Forwarded-Forフィールドを追加する目的を、35字以内で答えよ。

通常、クライアント（利用者）のPCやスマートフォンからECサーバにアクセスすると、そのパケットの送信元IPアドレスは「利用者のIPアドレス」になります。

ECサーバはこのIPをログに記録し、アクセス元の特定やセキュリティ分析、アクセス制御（国・地域別制限など）に利用します。

しかし、今回の増強構成ではECサーバの前にLB（負荷分散装置）が入り、さらに「ソースNAT」を行う設定を採用します。

ソースNATとは、パケットの送信元IPアドレスを別のIPに置き換える仕組みです。

LBがソースNATを行うと、クライアントのIPはLB自身のIPに書き換えられます。

HTTP通信には、追加の情報を載せられる「HTTPヘッダー」という領域があります。X-Forwarded-For（略してXFF）は、その中でも「本来のアクセス元IPアドレス」を記録するための非公式ながら広く使われているヘッダー項目です。

LBがリクエストをECサーバに転送するとき、HTTPヘッダーに

X-Forwarded-For: 203.0.113.45

のように、クライアントの元のIPアドレスを追記します。

こうしておけば、ECサーバ側のアプリケーションやログ解析ツールは、XFFの内容を参照して正しい利用者のIPを記録できます。

今回のECサーバは「アクセス元のIPアドレスなどをログとして管理している」と本文に記載があります。

つまり、アクセス元IPは運用やセキュリティにとって重要な情報です。

これを失ってしまうと、

• 不正アクセスやサイバー攻撃の発信元を追えない
• アクセス制御（IP単位の制限）が効かない
• ログの分析が役に立たない

といった問題が発生します。

X-Forwarded-Forはこれらを防ぎ、ソースNATを行っても運用に必要なIP情報を保持できるようにするための手段です。

言い換えると、「ECサーバが利用者のIPを把握できるようにするため」です。

本文中の下線⑦について、対応するための作業内容を、50字以内で答えよ。

下線⑦は、「増設ECサーバには新しいサーバ証明書を入れずに、既設ECサーバの証明書を流用する」という場面です。

HTTPS通信では、クライアント（利用者のPCやスマホ）とサーバの間でやり取りするデータを暗号化します。

この暗号化の仕組みを始めるときに使うのがサーバ証明書と秘密鍵のペアです。

サーバ証明書は「このサーバは正しい相手ですよ」と証明する役割を持ち、秘密鍵は暗号化の鍵交換や通信の安全性を保つために使われます。

この2つはセットで管理され、通常はサービスを提供するサーバごとにインストールされます。

LBがクライアントとTLSハンドシェイクを行い、暗号化通信を確立します。

つまり、TLSの入口はLBであり、ECサーバはLBとの内部通信だけを行うため、その内部通信は必ずしも暗号化する必要がありません（もちろん、内部通信も暗号化する構成は可能ですが、今回の想定ではHTTPで良いという設計です）。

このため、証明書はLBだけにあれば十分です。新たに増設するECサーバに証明書を発行・設定する手間やコストをかける必要がなくなります。

実際の作業としては、既設ECサーバに入っているサーバ証明書と秘密鍵のペアをLBにコピーし、LB側で設定することで、クライアントは今まで通り安全にHTTPSアクセスができます。

こうすれば証明書の管理も一本化され、更新作業や有効期限管理がシンプルになります。

設問５

[LBの制御方式の検討]について答えよ。

本文中の下線⑧について、セッション維持ができなくなる理由を、50字以内で答えよ。

まず前提として、セッション維持とは、一度接続したクライアントからの一連のリクエストを常に同じサーバに振り分け続ける仕組みです。

例えば、ECサイトでログインして買い物かごを操作している最中に、サーバが変わってしまうとセッション情報が引き継がれず、ログアウトされたりカートの中身が消えたりする可能性があります。

ここで識別方法として「IPアドレス＋ポート番号」を使う場合、問題が起きます。

TCPコネクションは、クライアントとサーバ間で一度確立された後、切断されることがあります（例えば一定時間操作しなかった場合や、ページ遷移で新しい接続が必要になった場合）。

そして再度接続を確立するとき、クライアント側は送信元ポート番号を前回と同じにする保証はなく、多くの場合は新しいポート番号が割り当てられます。

LBはこの「IPアドレス＋ポート番号」の組み合わせをキーにしているため、ポート番号が変わるとLBから見れば「別のアクセス元」と見なされます。

つまり、ポート番号を含めた識別方法は、一見細かく区別できる利点があるように見えますが、TCP再接続のたびにポート番号が変わる可能性が高いため、セッション維持が崩れやすいのです。

本文中の下線⑨について、LBがセッション管理テーブルに新たなレコードを登録するのは、どのような場合か。60字以内で答えよ。

下線⑨は、LB（負荷分散装置）がCookieを使ったセッション維持方式を採用している場面に関する問題です。

Webシステムでは、ログインやショッピングカートなど、ユーザごとに状態を持つ処理があります。

これらは「セッション」と呼ばれ、同じユーザからの一連のアクセスは同じサーバで処理される必要があります。

Cookieを使った方式では、クライアントが最初にサーバへアクセスした際、サーバ側でランダムなセッションIDを生成します。

このセッションIDはHTTPレスポンスに含まれるCookieとしてクライアントに送られます。

クライアントは、その後の全てのリクエストにこのCookieを付けてサーバへ送信します。

LBは、このCookie内のセッションIDを見て「どのサーバに振り分けるべきか」を判断します。

LBはセッション管理テーブルという内部の管理表を持っており、ここに「セッションID」と「担当サーバ」のペアを記録します。

もし、サーバから返ってきたレスポンスに含まれるセッションIDが、このテーブルにまだ登録されていない場合、それは「新しいセッションの開始」を意味します。

そのためLBは新たにレコードを追加し、そのセッションIDと、今回振り分けたサーバの対応関係を記録します。

逆に、既にテーブルに同じセッションIDが存在している場合は、その既存の対応関係に従って振り分けを行い、新規登録は行いません。

こうした仕組みによって、TCPコネクションが切れても、CookieのセッションIDさえ一致していればセッション維持が可能になります。

したがって、LBがセッション管理テーブルに新しいレコードを登録するのは、サーバからの応答に含まれるCookie中のセッションIDが、セッション管理テーブルに存在しない場合です。

本文中の下線⑩について、レイヤー3及びレイヤー4方式では適切な監視が行われない、その理由を25字以内で答えよ。

まず、ヘルスチェックとは、LBが複数台のサーバの中から正常に稼働しているサーバを見極め、障害があるサーバを振り分け対象から外すための監視機能です。

チェック方式にはレイヤー3（L3）、レイヤー4（L4）、レイヤー7（L7）がありますが、それぞれ監視できる範囲が異なります。

典型的にはICMP（ping）でサーバのIPアドレスに対して応答があるかを確認します。

応答が返ってくれば「そのサーバはネットワーク的に到達可能」と判断します。

しかし、OSやネットワークが生きていても、その上で動くWebアプリケーションやサービスが停止している場合は検知できません。

TCPやUDPの特定ポートに対して接続を試み、応答があるかどうかを確認します。

たとえば、TCP 443番ポート（HTTPS）が開いていれば「正常」とみなします。

しかし、ポートは開いていても、実際のアプリケーションが異常を起こしてエラー画面を返している、または応答内容が壊れている場合でも、L4方式は正常と判定してしまいます。

そのため、サービスが落ちているにもかかわらず「正常」と誤認し、利用者がエラー画面や空白ページを見せられる、といった事態が発生します。

これに対してL7方式はアプリケーション層の監視であり、実際にHTTPリクエストを送り、期待するレスポンスやコンテンツが返ってくるかを確認します。

これにより、サービス自体の稼働状況まで把握できるため、より適切な監視が可能になります。

以上から、L3やL4方式では「サービスが稼働しているかどうか検査しないから」、適切な監視が行えないということになります。

設問６

[SAML2.0の調査とECサーバへの対応の検討]について答えよ。

本文中の下線⑪について、ログイン要求を受信したECサーバがリダイレクト応答を行うために必要とする情報を、購買担当者の認証・認可の情報を提供するIdPが会員企業によって異なることに着目して、30字以内で答えよ。

SAML認証の基本的な流れでは、利用者がSPにアクセスすると、SPはその利用者を認証できるIdPにリダイレクトし、IdPが利用者の認証・認可情報を提供します。

ここで重要なのが、ログイン要求を送ってきた利用者がどの会員企業に所属しているのかという情報です。

この情報があれば、その会員企業がどのIdPを利用しているかを事前に設定された対応表やディレクトリから引き出し、適切なIdPに対してSAML認証要求（SAML Request）を送ることができます。

例えば、A社の購買担当者はA社が運営するIdPにリダイレクトし、B社の購買担当者はB社のIdPにリダイレクトする必要があります。

これを実現するには、SP側でアクセス元の購買担当者がどの企業に所属しているかを特定できる仕組みが必要です。

特定方法としては、事前にユーザ登録情報を持っておく、アクセス元IPアドレス帯域から推定する、初期入力画面で企業名を選択させるなど、複数の方法が考えられますが、いずれにしても企業所属情報がキーになります。

本文中の下線⑫について、図7の手順の処理を行うために、ECサーバに登録すべき情報を、15字以内で答えよ。

SAML認証では、利用者がSPにアクセスすると、SPはIdPに認証を委託し、IdPが認証結果をSAMLアサーションとしてSPに返します。

このSAMLアサーションには利用者の認証情報や属性情報が含まれますが、送信途中で改ざんされる危険を防ぐために、IdPはアサーションにデジタル署名を付与します。

デジタル署名は「この情報は確かにIdPが発行したものであり、内容が改ざんされていない」ということを証明する仕組みです。

IdPは自分の秘密鍵を使って署名を行い、SPは事前に登録された公開鍵でその署名を検証します。

公開鍵は単体でも使えますが、信頼性を確保するためには、通常は公開鍵を含む公開鍵証明書の形で配布されます。

この証明書には、公開鍵に加えて発行者や有効期限などの情報が含まれ、改ざん防止のためにさらに認証局（CA）の署名が付けられています。

ECサーバ（SP）は、この「IdPの公開鍵証明書」を事前に登録しておくことで、SAMLレスポンスを受信した際に、そのデジタル署名を正しく検証できます。

これはセキュリティ上の重大なリスクとなります。

これにより、SPはIdPとの信頼関係を技術的に保証し、安全なシングルサインオン環境を構築できます。

本文中の下線⑬について、取り出したSTをPCは改ざんすることができない。その理由を20字以内で答えよ。

まず前提として、STは会員企業内で利用しているケルベロス認証の仕組みに基づいて発行されるチケットです。

STの中には、利用者の身元情報（ユーザIDなど）や利用するサービスに関する情報、そしてセッション鍵が含まれています。

このSTは、サービス側（ここではIdP：認証連携サーバ）だけが復号できるように、IdPの秘密鍵で暗号化されています。

PCがKDCからSTを受け取るとき、PCは自分の鍵で保護された部分を復号してSTを取り出しますが、STそのものの暗号化はIdPの秘密鍵で施されているため、PCはその中身を直接読むことも変更することもできません。

もしPCが内容を改ざんしようとした場合、暗号化されたデータを復号できないまま適当に書き換えることになりますが、その結果は暗号化構造が壊れ、IdP側で復号したときに正しい情報として認識されず、認証は必ず失敗します。

また、仮にPCが暗号化を解いて改ざんしたうえで再暗号化しようとしたとしても、それにはIdPが持っている秘密鍵が必要になります。

秘密鍵はIdPの内部で厳重に管理され、外部に渡ることはありません。

そのため、PCは暗号化されたままのSTを改ざんする術を持っていないのです。

このように、STがIdPの秘密鍵によって暗号化されていることが、PCによる改ざんを不可能にしています。

したがって答えは、「IdPの鍵を所有していないから」となります。

これはケルベロス認証のセキュリティ設計の重要なポイントであり、第三者によるチケットの偽造や改ざんを防ぐ根幹の仕組みです。

本文中の下線⑭について、受信したSAMLアサーションに対して検証できる内容を二つ挙げ、それぞれ25字以内で答えよ。

ここではSAMLアサーションに含まれるデジタル署名が重要な役割を果たします。

SPは事前にIdPの公開鍵証明書を登録しており、この公開鍵を使って署名を検証します。

1. 信頼できる発行元であることの確認

まず一つ目の検証は、「そのSAMLアサーションが信頼関係を構築しているIdPによって発行されたものであるか」という確認です。

SPは受け取った署名を、自分が事前に登録しているIdPの公開鍵で検証します。

公開鍵が一致すれば、その署名は間違いなく登録済みのIdPが持つ秘密鍵で作られたものであることが証明されます。

逆に、登録されていない公開鍵や一致しない鍵であれば、不正な第三者が発行した可能性があるため拒否します。

これにより、SPは発行元の真正性を保証できます。

2. 改ざんされていないことの確認

二つ目の検証は、「SAMLアサーションが送信途中で改ざんされていないか」という確認です。

デジタル署名はアサーションの本文全体に基づいて生成されているため、アサーションが途中で一文字でも変更されれば、署名検証は必ず失敗します。

これにより、悪意のある第三者がアサーションの中の利用者情報（例えば利用者IDや権限）を改ざんしようとしても、その改ざんは検知されます。

つまり、この仕組みは完全性の保証を担っています。

まとめ

SAMLアサーションの署名検証によって、SPは次の2つを確認できます。

① 信頼関係のあるIdPが生成したものであること（発行元の真正性）
② SAMLアサーションが改ざんされていないこと（完全性の保証）

これらの確認は、SAMLを用いたシングルサインオンの安全性を支える重要なステップであり、もしどちらかが担保されなければ、不正ログインや権限のなりすましといった重大なセキュリティリスクにつながります。