ECサイトの負荷分散とSAML認証連携

読み：いーしーさいとのふかぶんさんとさむるにんしょうれんけい　／　英語表記：E-commerce load balancing and SAML identity federation

ECサイトの処理を複数のサーバへ分散し、企業の認証基盤と連携して利用者を受け入れるための設計である。NATと戻り経路、セッションの維持、TLSの終端、認証結果の署名検証を区別してサービス全体を成立させる。

イマシルちゃんの解説

買い物の途中で接続先のサーバが変わり、カートの中身が見えなくなったら困るね。
サーバを増やすときは、要求を分けるだけでなく、同じ利用者の処理をどう続けるかも決める必要があるんだ。
入口で通信を振り分けるロードバランサは、そのためにCookieなどの情報を使えるよ。
さらに会社のアカウントで買い物サイトへログインするなら、会社側の本人確認の結果をサイトへ伝える仕組みも必要になるね。
ここではSAMLという認証連携の規格を使うよ。
通信を運ぶ仕事と、利用者が誰かを確かめる仕事を分けると、複雑な構成でも順に追えるんだ。

より深い解説

サーバの増設だけではサービスは完成しない

処理能力の向上には、一台のCPUやメモリを増強するスケールアップと、複数台で処理を分担するスケールアウトがある。後者では利用者から見える入口と、実際に処理するサーバを分けるためにロードバランサを利用できる。

ただしサーバが三台になっても、共有するデータベースや回線が先に上限へ達することがある。セッション情報を一台のメモリだけで管理するアプリケーションも、そのままでは要求を自由に分散できない。

通常時に二台分の能力が必要で、一台の停止中も同じ負荷を処理したいなら、同等性能のサーバを三台用意する考え方がある。これは単なる余裕ではなく、故障後に残る能力から台数を決める設計である。

一台停止後の能力 ＝ (台数 − 1) × 一台当たりの能力
必要条件：一台停止後の能力 ≧ ピーク時の処理量

この式は均等に処理を分けられるという前提の概算である。負荷の偏りや共有資源の上限がある場合は、その条件も含めて評価する。ロードバランサ自体の冗長化と、設定・接続状態の引継ぎも別に検討する。

DNSの名前とサービスの入口を分ける

DNSのAレコードは名前に対応するIPv4アドレスを示す。NSレコードはゾーンの権威サーバ、MXレコードはメールの配送先を示すため、どれもWebサーバのアドレスを設定する同じ欄ではない。

負荷分散を導入するときは、実サーバの個別アドレスと、利用者がアクセスする仮想IPアドレスを区別する。後者をVIPとも呼ぶ。以前のサービス用アドレスをVIPとして引き継げる構成なら、外部から見える入口を保ちながら後ろのサーバを増やせる。

例えば公開DNSは引き続き同じ公開IPアドレスを答え、ファイアウォールがその宛先をLBのVIPへ変換する。一方、既存サーバ自身には別の実アドレスを割り当てる。公開名を維持することと、全機器のアドレスを変更しないことは同義ではない。

社内向けDNSで別のアドレスを返している場合は、その接続先も照合する。管理用の個別ホスト名、サービス名、公開側の変換設定を分けて一覧にすると、変更漏れを減らせる。

通過する装置ごとにIPヘッダーを書き直す

NATを使う構成では、パケットの送信元と宛先が途中で変わる。利用者が最初に指定したIPアドレスだけを見て、全区間の通信を説明してはいけない。

次は本稿独自の例である。クライアントを203.0.113.80、公開サービスを198.51.100.20とし、内部ではLBのVIPを10.10.20.2、LBの実アドレスを10.10.20.4、実サーバを10.10.20.5とする。ポート番号の変換は省略している。

応答では、この対応を逆向きにたどる。実サーバからLBへ返り、LBとFWが対応する変換を行うことで、クライアントが接続した公開サービスからの応答として戻せる。

NATはアドレスを書き換える仕事であり、認証や暗号化の代わりにはならない。各装置がどの区間で変換し、どの通信状態を保持するかを確認する。

送信元を保持すると戻り経路も設計する必要がある

LBが宛先だけを実サーバへ変え、元の送信元を保持する構成を考える。実サーバはクライアントへ応答するため、自分の経路表を参照する。デフォルトゲートウェイがFWであれば、応答がLBを通らずFWへ向かう可能性がある。

接続状態や逆向きの変換をLBに処理させる構成では、この迂回が問題になる。そこで実サーバの戻りをLBへ通す方法を検討する。ただし、LBをデフォルトゲートウェイにすれば常に解決するわけではない。

令和5年度の問題に登場するLBには、一般のルータとして通信を転送しないという条件がある。この条件で管理用通信までLBへ向けると、管理端末との通信が成立しなくなる。製品名から機能を補ってはいけない。

LBで送信元NATを行えば、実サーバから見た相手はLB側のアドレスになる。同じサブネット上のLBへ応答させ、サーバのデフォルトゲートウェイは管理通信にも使えるFWのまま維持する構成を作れる。変換に使うアドレスとポートの資源、同時接続数も確認する必要がある。

X-Forwarded-ForはIPヘッダーを元へ戻さない

送信元を変換すると、実サーバの通信相手はLBに見える。利用者のIPアドレスをアプリケーションのログへ残すため、LBがHTTPのX-Forwarded-Forヘッダーへ元の情報を追加する方法がある。

これはHTTP内の付加情報である。IPヘッダーの送信元が元のクライアントへ戻るわけでも、その値を使ってルータが自動的に経路を選ぶわけでもない。

また、クライアント自身も同名のヘッダーを送れる。サーバは信頼するプロキシの範囲と、各段階で追記・上書きされる規則を確認しなければならない。文字列の先頭のアドレスを無条件に本人情報として採用するのは危険である。

複数プロキシを通る場合の値や設定例はAWSの転送ヘッダーの資料で確認できる。ここでの製品固有の処理を、全てのLBの共通動作として扱わない。

TLSを終端する装置と鍵を対応させる

HTTPSの内容をLBが読み、Cookieを使った振分けやヘッダー追加を行う構成では、LBがTLSを終端する。暗号化されたHTTPをそのまま転送する構成とは異なる。

証明書を使ってTLSのサーバ認証を行うには、サーバ証明書と対応する秘密鍵を利用できることが必要になる。公開情報である証明書のコピーだけを置いても、その持ち主として認証処理を行えるわけではない。秘密鍵を専用の保管装置で利用する実装もある。

利用者側のTLSをLBで終えた後、実サーバ側はHTTPにするか、別のTLS接続で再暗号化するかを決める。後半を暗号化する場合は、LBが実サーバの証明書を適切に検証できることも必要である。

令和5年度の設問には証明書のCNと接続先名の不一致を読む場面がある。一方、出題後の2023年11月に公開されたRFC 9525では、接続先の識別にSANを用い、CNを使う方法は認めていない。過去問の指定を読むことと、現在の証明書をCNだけで設計することは区別する。

名前の不一致を解決するために検証を無効化してはならない。利用するサービス名、提示する証明書、LBや実サーバが受け付ける名前を整合させる。

負荷を分ける指標と同じサーバへ戻す条件

ラウンドロビンは順に振り分け、最少接続数方式は接続数の少ないサーバを選ぶ。接続数が同じでも一件の処理負荷は異なるため、CPU使用率などを収集して判断する方式とは同じではない。

負荷の均等化とは別に、既存の利用者を同じサーバへ割り当てるパーシステンスを考える。アプリケーションがセッション情報を各サーバで管理する場合、途中の要求が別のサーバへ届くと前の状態を参照できないことがある。

一つの会社からのアクセスが同じIPアドレスに見える場合、IPアドレス単位の固定は一台への集中を招く。逆にポート番号まで使えば、一人のブラウザが持つ複数接続を同じセッションとして扱えない場合がある。ネットワーク接続の識別と、買い物の継続状態の識別は別である。

Cookieと振分け表の更新を追う

Cookieを利用する構成では、初回の要求時点に識別子が存在しない場合がある。そのときはLBがいずれかの実サーバを選び、応答で発行される識別子と実サーバの対応を記録する。

以後の要求に同じ識別子が付いていれば、その対応から実サーバを選べる。セッション識別子が新しくなった場合も、応答を返したサーバとの対応表への登録が必要になる。識別子を読むだけで対応が自然に分かるわけではない。

アプリケーションのCookieを参照する方式と、LBが独自のCookieを付ける方式は異なる。どの装置が値を作り、どの装置がそれを解釈するかを問題の条件に合わせて整理する。

同じサーバへ要求を戻す仕組みは、サーバ内の状態を複製する仕組みではない。そのサーバが停止した場合のカートやログイン状態を引き継ぐには、共有ストアや状態の複製などが別に必要になる。

サーバを監視して振分け先から外す

ICMPの監視ではネットワーク上の応答、TCPの監視では待受け、HTTPの監視では設定したアプリケーションの応答を確認する。どこまで監視するかによって発見できる故障が異なる。

故障を検知したサーバへ新規の要求を割り当てないようにし、復旧時には正常状態を確認して戻す。監視を一度失敗しただけで頻繁に参加・離脱を繰り返すと不安定になるため、判定回数や間隔も調整する。

計画停止では新規要求を止めた後、既存の処理を終わらせるドレインを利用できる場合がある。停止予定と突発的な故障では、維持できる通信が違う。監視による切替えと、セッション情報の継続を同じ機能として説明しない。

SAMLでは認証の結果を別のサービスへ伝える

会員企業のアカウントでECサイトを利用する場合、ECサイトが全企業のパスワードを預かる構成だけが選択肢ではない。企業側で本人確認を行い、その結果をECサイトが受け取る認証連携を使える。

SAMLでは本人確認を行う側がIdP、サービスを提供する側がSPである。認証した主体などを表すXMLの情報をアサーションと呼ぶ。ECサイトは、信頼する企業のIdPが発行した情報を検証して自分のサイトのログイン状態を作る。

ブラウザがアサーションを運ぶことと、ブラウザ自身が内容を保証することは違う。基本的な役割とブラウザSSOの流れはOASISの技術概要で確認できる。

ブラウザを経由した情報をそのまま信用しない

SPから認証を要求する代表的な流れでは、SPがIdPへの認証要求を作り、ブラウザをIdPへ移動させる。IdPは利用者の認証状態を確認し、応答をブラウザ経由でSPの受信先へ返す。

企業を選ぶ画面などがある場合も、利用者が自由に指定した任意のサイトを信頼するわけではない。事前に登録したIdPと鍵、受信先、識別情報に対応させる。

署名付きのアサーションを検証する場合、署名を作るのはIdPの署名用秘密鍵であり、SPは信頼したIdPの公開鍵を使う。SPが自分の公開鍵で他社の署名を検証するのではない。

デジタル署名で確認するのは発行元と改ざんの有無である。内容を第三者から隠す暗号化とは別の処理なので、通信を保護するTLSも必要になる。接続先へ許可される業務操作を決める認可も、認証結果の受取りとは別に行う。

署名に加えて対象・期限・要求との対応を検証する

正しいIdPの署名が付いていても、別サービス向けの結果や過去に使った結果をそのまま受け入れてよいわけではない。利用するプロファイルに従い、少なくとも次の関係を確認する。

時刻がずれると正しい応答でも検証に失敗し得るため、関係する装置の時刻を管理する。署名検証に使う証明書の更新では、新旧の鍵を扱う期間と切替えをIdP・SPで整合させる。

具体的な要求・応答の構造はMicrosoftのSAML実装資料でも確認できる。属性の取扱いには実装差があるため、例の設定を全製品へそのまま適用しない。

Kerberosのチケットとアサーションを取り違えない

会員企業内ではKerberosで利用者を認証し、その結果をIdPがSAMLへつなげる構成がある。KerberosとSAMLは同じ情報を別名で呼ぶものではない。

KerberosではKDCがチケットを発行する。PCがログオン時に得たTGTは、利用先ごとのサービスチケットを取得するために使う。IdPへ接続する場合は、IdPのサービスに対応するチケットを要求する。

1. PCが保存済みのTGTなどを使い、KDCへIdP向けのサービスチケットを要求する。
2. KDCがチケットと必要な鍵情報を返す。
3. PCがサービスチケットと認証子をIdPへ提示する。
4. IdPがKerberosの情報を検証して本人を確認する。
5. IdPがSAMLの認証結果を発行し、SPがその内容を検証する。

サービスチケットの暗号化部分は、対象サービス側の鍵で保護される。PCがチケットを運ぶからといって、その部分を自分の鍵で自由に復号できるわけではない。一方、PC自身が使うセッション鍵などはPC向けに保護された別の部分から得る。KDCの応答全体を一括して「PCには何も復号できない」と説明するのも誤りである。

チケットの取得と提示はMicrosoftのTGS交換とクライアント・サーバ交換に対応する。TGTやIdP向けチケットを、そのままECサイト用のアサーションとして提出するわけではない。

三種類の鍵を別々に管理する

どれも鍵という言葉が出てくるが、誰が持ち、何を検証するかが違う。LBへTLS用の証明書を配置しただけで、SAMLの信頼関係やKerberosのサービス登録まで完成するわけではない。

午後問題での問われ方

令和5年度午後Ⅱ問2は、通信の負荷分散と認証連携を一つのシステムとして読む問題である。図やシーケンスの各段階で、送信者、宛先、保持する状態、検証する情報を切り分けると整理しやすい。

本稿は公式問題を題材にした学習用の解説である。独自のアドレス例と原問題の数値を混ぜず、解答する際は問題で指定された名前と条件に戻して確認する。

参考資料

• IPA：令和5年度春期NW午後Ⅱ問題（問2）
• IPA：午後Ⅱの解答例
• IPA：午後Ⅱの採点講評
• AWS：LBが付加するHTTPヘッダー
• RFC 9525：TLSでのサービス名の検証
• OASIS：SAML 2.0の技術概要
• Microsoft：SAMLの認証要求と応答
• Microsoft：Kerberosのサービスチケットの取得
• Microsoft：Kerberosのクライアント・サーバ交換

実際の試験ではここに出る！全1問

ネットワークスペシャリスト

午後Ⅱ

• R5春 問2