令和4年度 春期 情報処理安全確保支援士試験 午後Ⅱ 問2｜クラウド移行で認証はこう変わる——情報処理安全確保支援士で学ぶCDN・SSO・OAuth/OIDCの設計とリスク

この記事で扱うセキュリティ事例

• 試験区分: 情報処理安全確保支援士
• 出典: 令和4年度 春期 情報処理安全確保支援士試験 午後Ⅱ 問2
• 主なテーマ: クラウド移行、CDN、ドメインフロンティング、Kerberos認証とST偽造、SAML、OAuth 2.0（state／PKCE）、OpenID Connect（nonce／IDトークン）

この記事は「情報処理安全確保支援士 午後問題 全70問」シリーズの1本です。→ 全70問の一覧・テーマ別索引はこちら

導入: なぜこの事例が重要なのか

「サービスが人気になりすぎて、自社のサーバとインターネット回線が悲鳴を上げている」——成長企業にとっては嬉しい悲鳴ですが、ここから先の判断を誤ると、可用性とセキュリティの両方を同時に失いかねません。

情報処理安全確保支援士試験の午後Ⅱで出題されたこの事例は、明確な「攻撃された」インシデントの物語ではありません。むしろ、一社の情報サービス会社がクラウドへ移行していく過程で、次々と立ちはだかる「認証と通信の設計上のリスク」をどう検討していくか、という長い意思決定の物語です。CDN（コンテンツ配信網）の導入、社内シングルサインオンの作り替え、SaaSやスマホアプリとの連携——それぞれの場面で、攻撃者がどんな隙を突いてくるのかを先回りして潰していきます。

この記事を読むと、CDNを使うとなぜドメインフロンティングという厄介な攻撃が成立し得るのか、Kerberos認証のチケットがなぜオフラインで破られるのか、SAMLやOAuth 2.0、OpenID Connectで標準化された対策（state、PKCE、nonce）がそれぞれ何を守っているのかが、一本の線でつながって見えてきます。受験者にとっては認証・認可分野の頻出論点を物語として整理でき、システムを発注・運用する立場の経営者・管理職にとっては「クラウド移行で増える新しいリスクと、その実装要件」を理解する教材になります。

インシデントの概要

舞台は、従業員500名ほどの情報サービス会社、X社です。X社は5年前から、会員が動画を投稿・閲覧・評価できる動画投稿配信サービス（以下、動画サービス）を提供してきました。配信は自社の「X社動画サーバ」で行っています。

X社のシステム構成を少し具体的に描いておきましょう。インターネットとの境界にはFW（ファイアウォール。通信を許可・遮断する関所のような装置）が置かれ、その内側はいくつかの区画に分かれています。外部に公開する区画であるDMZ（非武装地帯。社外からアクセスされる前提のサーバを置く緩衝地帯）には、外部DNSサーバ、外部メールサーバ、プロキシサーバ、そしてX社動画サーバが置かれています。このプロキシサーバには、拒否リストに登録したFQDN（ドメイン名を含む完全なホスト名）宛ての通信を遮断する機能がありました。社内側のサーバセグメントには認証サーバ、内部DNSサーバ、内部メールサーバ、ファイルサーバ（FS）、グループウェア（GrW）サーバが並び、従業員が使う区画（PCセグメント）には会社貸与の業務用PC（XPC）が置かれています。

従業員の認証は認証サーバが一手に引き受け、XPC・GrWサーバ・FS・内部メールサーバへのアクセスをシングルサインオン（SSO。一度ログインすれば、複数のシステムに再ログインなしで入れる仕組み）で実現していました。

ところが動画サービスの人気が上昇し、会員が増えるにつれて、X社動画サーバの負荷が大きくなり、インターネット回線がひっ迫してきました。経営陣は「抜本的な対策を打て。同時にセキュリティも強化せよ」と指示します。担当することになったのは、システム部のCさん。そして助言役として、セキュリティサービスを提供するW社の情報処理安全確保支援士（登録セキスペ）であるF氏が加わりました。ここから、CさんとF氏の二人三脚で、クラウド移行をめぐる検討が始まります。

何が起きたのか

F氏が最初に示した方針は二つでした。一つは、X社動画サーバを自社の機械室からIaaS（事業者が用意したサーバやネットワークをインターネット越しに借りて使うクラウド形態）へ移すこと。もう一つは、CDN（Content Delivery Network。世界各地に配信用サーバを分散配置し、利用者に近いサーバから代理で配信する仕組み）を利用することでした。

CさんはCDNの仕組みをF氏に確かめます。CDNは各地に「キャッシュサーバ」（一度取得したコンテンツを一時的に保存しておくサーバ）を分散配置し、配信を要求した端末に最も近いキャッシュサーバから動画を返します。そのキャッシュサーバが動画を持っていれば代理で応答し、持っていなければX社動画サーバから取り寄せて応答する。多くの要求が代理応答で済むため、X社動画サーバの負荷は大きく減ります。Cさんは「その仕組みなら、大量の通信を一斉に送りつけてサービスを止めようとするDDoS攻撃（分散型サービス妨害攻撃）への耐性も上がりますね」と理解を深めます。多数のキャッシュサーバが要求を肩代わりするため、攻撃のアクセスも分散され、本体サーバが落ちにくくなるのです。

M社のCDNを使う手順はこうです。まずM社CDNがX社動画サーバ用のFQDN（仮にX-CDN-M-FQDNと呼びます）を発行します。次にX社の外部DNSサーバで、本来のX社動画サーバのFQDN（X-FQDN）とX-CDN-M-FQDNをCNAMEレコード（あるドメイン名を別のドメイン名の別名として対応づけるDNSの記録）でひも付けます。これで、会員がX-FQDN宛てにアクセスすると、実際にはM社CDNのキャッシュサーバが応答するようになります。

配信時の動きを分解すると、ここに後の攻撃の伏線が潜んでいます。会員端末が動画を要求するHTTPSリクエストを送るとき、暗号化通信の確立に使うTLS（通信内容を暗号化する仕組み）では、接続先のサーバ名がRFC 6066に基づいてSNI（Server Name Indication。これから接続したいサーバ名を、暗号化を始める前に相手へ伝えるTLSの拡張）として示されます。一方、HTTPリクエストの中では、RFC 7230に基づいてHostヘッダ（リクエストがどのサイト向けかを示す欄）にX-FQDNが指定されます。M社CDNのキャッシュサーバが動画を持っていない場合、CDNはこのHostヘッダの値を見て「どのサイト宛てか」を判断し、X社動画サーバへ転送します。

ここで初めて、攻撃の輪郭が見えてきます。ドメインフロンティングと呼ばれる手口です。

ある別のCDN（CDN-Uと呼びます）が、X社内から頻繁にアクセスされる複数の他社サイトで使われていたとします。そのうちの一つがY社のWebサイト（Y-FQDN。CDN-UはこれにY-CDN-U-FQDNを割り当てている）。そして同じCDN-Uを、攻撃者も自分のサーバ（Z-FQDN。CDN-UからはZ-CDN-U-FQDNを割り当てられている）で使っていたとします。CDN事業者は多数の顧客を同じインフラに相乗りさせるため、こうした「正規サイトと攻撃者が同じCDNに同居する」状況は珍しくありません。

いま、X社のXPCの1台がマルウェア（悪意あるプログラム）に感染したとします。マルウェアは攻撃者サーバと連絡を取りたい。しかし正面から攻撃者サーバへ通信すれば、FWやプロキシの拒否リストで止められてしまう。そこでマルウェアはこう動きます。まず、ごく普通に見えるY社サイトへのHTTPS通信を装うため、Y-FQDNの名前解決を行います。返ってくるのはY-CDN-U-FQDN。そのIPアドレスを持つCDN-Uのサーバとの間でTLS接続を確立します。ここまでは「Y社という有名サイトへの正常なアクセス」にしか見えません。ところが——HTTPリクエストを送る段になって、マルウェアはHostヘッダにこっそりZ-FQDN（攻撃者サーバのFQDN）を指定するのです。CDN-Uは、暗号化の中身であるHostヘッダだけを見て転送先を決めるため、この通信を攻撃者サーバへ流してしまいます。

結果として、マルウェアと攻撃者サーバの通信が、正規CDNを隠れ蓑にして成立してしまう。外から見れば「Y社という信頼できるサイトへのHTTPS通信」にしか見えないため、従来の防御をすり抜けるのです。これがドメインフロンティングの怖さです。

ではどう止めるのか。CさんとF氏は対策を一つひとつ吟味します。攻撃者サーバに割り当てられたIPアドレス宛ての通信をFWで拒否しても、TLSの接続先はあくまでCDN-Uのサーバなので意味がありません。Z-FQDNをプロキシの拒否リストに登録しても、表向きの通信先はY社なので効きません。では、Y-CDN-U-FQDNを名前解決して得たIPアドレス宛ての通信をFWで拒否すればどうか。たしかに止まりますが、ここに副作用がありました（下線①）。CDN-Uは複数の顧客サイトを同じIPアドレスで提供しているため、そのIPを拒否すると、Y社サイトに相乗りしている他のサイトまで一斉に見られなくなってしまうのです。

通信内容を監視・遮断してくれるCDN事業者もありますが、そうでない事業者もあり、これだけに頼ることはできません。最終的にX社が検討したのは、FWまたはプロキシを「アウトバウンド通信（社内から外向きの通信）を復号して中身まで解析できる高機能なもの」に置き換え、TLSの接続先サーバ名（SNI）とHTTPリクエストのHostヘッダの値が一致しているかを検証し、食い違っていれば遮断する、という方法でした。正常な通信ではこの二つは一致するはずで、ドメインフロンティングはまさにこの二つをわざと食い違わせる攻撃だからです。

クラウドの可用性を高める検討は、こうして「クラウドだからこそ生まれる新しい通信の隙」を直視するところまで進みました。続いてF氏とCさんは、社内の認証基盤そのものに目を向けます。

社内SSOの足元——Kerberos認証のチケットが偽造される

X社の社内SSOは、Kerberos（ケルベロス）認証という方式で実現されていました。XPCからGrWサーバへアクセスする流れを追うと、その仕組みがよく分かります。

まずXPCが利用者IDとパスワードを認証サーバへ送ります。認証サーバはこれが正しければTGT（Ticket Granting Ticket。利用者のアクセス権限を示す「チケットを発行してもらうためのチケット」）を発行します。このTGTは、認証サーバに登録されたTGT発行用アカウントのパスワードのハッシュ値（元の値に戻せない形に変換した値）を鍵にして暗号化されています。XPCはこのTGTを保存しておきます。

次にXPCがGrWサーバを使いたくなると、保存したTGTを認証サーバへ提示します。認証サーバはTGTを復号して検証し、問題なければST（Service Ticket。アクセス対象のサーバごとに発行される入場券）を発行します。STは、アクセス先サーバの管理者アカウントのパスワードのハッシュ値を鍵にして暗号化されています。XPCはこのSTを保存し、GrWサーバへ提示します。GrWサーバはSTを復号して検証し、問題なければアクセスを許可する——これがKerberosのSSOの流れです。

F氏は、この仕組みへの攻撃を二つ挙げました。一つ目はTGTやSTの偽造です。チケットが偽造されれば、サーバが不正にアクセスされてしまいます。TGTの偽造については、現在は認証サーバ側で対策が進んでいます。問題はST。F氏は「STの偽造は、認証サーバ側では検知できないのです」と指摘しました（下線②）。理由はシンプルで、図に描かれた流れをたどると分かります。STはXPCからGrWサーバ（アクセス対象サーバ）へ直接渡され、認証サーバを一切経由しないのです。認証サーバはSTの中身を見る機会がないため、それが偽物かどうかを判定しようがありません。

二つ目は、サーバ管理者アカウントのパスワードを解読して不正ログインする攻撃です。仮にXPCからSTが奪われても、そのSTで入れる範囲は限定されます。しかし話はそこで終わりません。攻撃者は奪ったST——管理者アカウントのパスワードハッシュ値で暗号化されている——に対して、パスワードの総当たり攻撃（考えられる文字列を片端から試す攻撃）を仕掛けることができます。これが成功すると、その管理者アカウントでアクセスできるサーバが乗っ取られてしまいます。

厄介なのは、この総当たりに対して、サーバ側でログイン連続失敗時のアカウントロック（一定回数失敗するとログインを一時的に止める仕組み）を有効にしても対策にならない点です（下線③）。なぜなら、攻撃者は奪ったSTを手元に持っており、自分のコンピュータの中でパスワード候補を次々に試し、「正しく復号できたかどうか」で当たりを判定するからです。これはオフライン（サーバへ問い合わせない手元での作業）で行われるため、サーバへのログインを一度も試みません。ログイン失敗が発生しないので、アカウントロックは永遠に発動しないのです。

社内SSOの土台にこうした弱点があると分かったところで、ちょうどX社はGrWとメールをSaaS（インターネット越しに使えるソフトウェアサービス）へ移す計画を立てていました。F氏は、この移行を機にSSOの方式そのものを見直すことを提案します。

SaaSでのSSO——SAML認証への作り替え

F氏が提案したのは、IDaaS（Identity as a Service。認証機能をクラウドサービスとして提供する仕組み）の利用でした。多くのIDaaSはKerberosではなくSAML（Security Assertion Markup Language。組織をまたいで認証情報を安全にやり取りするための標準仕様）認証をサポートしており、SaaS側がSAMLに対応していればSAMLでSSOが実現できます。

SAML認証では、認証を担う側をIdP（Identity Provider。ここではIDaaS）、サービスを提供する側をSP（Service Provider。ここではSaaS）と呼びます。流れを追うと、XPCがSaaSにサービスを要求すると、SaaSは「まずIDaaSで認証してきてください」とリダイレクト（別のURLへ自動転送すること)を返します。このとき、認証を要求するための「SAML Request」が一緒に運ばれます。XPCはそれを持ってIDaaSにアクセスし、IDaaSはSAML Requestを取り出して「これは信頼関係を結んだSaaSからの正当な要求か」を検証します。問題なければログイン画面を返し、利用者が認証情報を入力。認証に成功すると、IDaaSは利用者の身元を証明する「SAMLアサーション」と、それに対するデジタル署名（中身が本物で改ざんされていないことを証明する電子的な印）を含む「SAML Response」を生成し、XPC経由でSaaSへ届けます。SaaSはこの署名を検証し、署名が確かにIDaaSのものであること、そしてSAMLアサーションが偽造されていないことを確認したうえで、サービスを提供します。

F氏は「IDaaSとSaaSの間では、事前に情報を共有しておく必要があります」と補足しました。共有するのは、SAMLアサーションで用いる属性、リダイレクト先URLの生成に使うURL、そして署名の生成・検証に必要なデジタル証明書などです。こうした下準備があって初めて、組織をまたいだ認証連携が安全に成り立ちます。最終的にX社は、G社が提供するSaaS（GrW-G、メール-G）とIDaaS（IDaaS-G）への移行を決めました。

サービス連携の落とし穴——OAuth 2.0のCSRFと認可コード横取り

移行から3か月後、今度は「スケジュール調整を楽にしたい」という要望が上がります。S社のスケジュール調整サービス（Sサービス。SaaSで、スマホアプリかPCのWebブラウザから使える)を、移行済みのGrW-Gと連携させる案です。主催者がSサービスにアクセスすると、GrW-Gから主催者のスケジュールを取得して空き時間を表示し、候補を選んで参加者に可否を尋ね、日程を決めて招待メールを送り、GrW-Gのスケジュールに登録する——という便利な流れです。

この連携には、Sサービス・GrW-G・IDaaS-Gがいずれも対応しているOAuth 2.0（あるサービスが、利用者に代わって別のサービスのデータへアクセスする許可を、パスワードを渡さずに得るための認可の標準仕様）が使われます。OAuthでは、データを使いたい側を「クライアント」（ここではSサービス）、許可を出す「認可サーバ」（ここではIDaaS-G）、データを実際に持っている「リソースサーバ」（ここではGrW-G）という三者が登場します。利用者の端末を起点に、サービス要求→認可サーバへのリダイレクト→認可同意→認可コード（許可の引換券）の受け渡し→クライアントがその認可コードでトークン（アクセス許可を表す鍵）を取得→トークンを使ってリソースサーバから利用者情報（スケジュール）を取得、という流れで進みます。

F氏はここでも二つのセキュリティ上の確認を行いました。

一つ目はCSRF（Cross-Site Request Forgery。利用者が気づかぬうちに、意図しない操作を実行させられる攻撃)です。攻撃者があらかじめGrW-Gに自分のアカウントを登録し、そのアカウントにアクセスするための認可コードを利用者に送りつけたとします。もし連携の実装にCSRFの脆弱性があり、利用者のブラウザが攻撃者の作った認可コードをそのまま受け付けてしまうと、利用者は気づかないうちに「攻撃者のアカウント」で会議日程を登録させられてしまいます。これを防ぐのがstateパラメータ（クライアントが毎回ランダムに作る、通信の連続性を確かめるための合言葉）です。適切な実装では、クライアントが認可要求を出すときにstateを付けて送り、認可サーバから戻ってきた値と突き合わせます。両者が一致しなければ「これは自分が始めた通信ではない」と判断し、攻撃を検知できます。

二つ目は、Sサービスをスマホアプリで使う場合に起こり得る、認可コードの横取り攻撃です。攻撃者が不正なスマホアプリを仕込み、GrW-Gアクセス用の認可コードを途中で奪い取る手口です。これを防ぐのがPKCE（Proof Key for Code Exchange。「ピクシー」と読む)という仕組みでした。Sサービスのスマホアプリが、ランダムな「検証コード」と、その値をもとに作った「チャレンジコード」を生成します。認可要求にはチャレンジコードを添えて送り、後のトークン要求には検証コードを添えて送ります。認可サーバはこの二つを突き合わせて検証するため、検証コードを知らない攻撃者がたとえ認可コードを横取りしても、トークンを得ることはできません。この仕組みはPKCEとして標準化されています。

他社サイトとの連携——OpenID Connectとnonce

さらに企画チームから、T社のメッセージ投稿サイト（T社投稿サイト)との連携要望が出ます。T社投稿サイトの認証機能を使ってX社動画サーバにログインできるようにし、さらにX社動画サーバに動画を投稿すると、その「動画の概要」がT社投稿サイトへ自動投稿されるようにしたい、というものです。つまり、T社投稿サイトのアカウントを持つ会員は、T社にログインすればX社動画サーバも使え、動画投稿が自動でT社にも流れる。

F氏が提案したのはOpenID Connect（OIDC。OAuth 2.0を土台に、「利用者が誰であるか」という認証情報を安全に受け渡せるよう拡張した標準仕様)でした。OIDCでは、連携を要求する側（RP／クライアント。ここではX社動画サーバ)、認証を担う側（OP。ここではT社投稿サイトの認証サーバ)、APIで投稿を受け付けるリソースサーバ（T社投稿サイトの投稿サーバ）が登場します。OAuthと似た認可コードフローで進み、利用者の本人確認はIDトークンという仕組みで行われます。

F氏は要点を説明しました。認可コードフローの場合、IDトークンはトークン応答でクライアントへ送られます。IDトークンはJSON Web Token（JWT。「ジョット」と読む。やり取りする情報を、改ざん検知のための署名付きでまとめた形式)で、ヘッダ・ペイロード（中身のデータ)・署名の三部構成です。署名は、ヘッダとペイロードに対してT社投稿サイトの認証サーバの秘密鍵で作られ、署名アルゴリズムはヘッダで指定されます。そしてヘッダ・ペイロード・署名は、それぞれbase64url（URLで安全に扱えるよう調整したBase64エンコード方式)でエンコードされます。

さらにF氏は注意を促します。「ハイブリッドフローを用いる場合は、stateのほかにnonce（ナンス。一度きりしか使わないランダムな値)を実装しているか確認すべきです」。nonceを生成して認証要求に含めて送り、戻ってきたIDトークンの中のnonceと照合する。この一致を確かめることで、攻撃者が古いIDトークンを使い回す不正利用（リプレイ）を防げるのです。

CDNから始まったクラウド移行の検討は、こうして社内認証の作り替え、サービス間連携、他社サイト連携へと広がり、その一つひとつで「標準化された対策をきちんと実装すること」の重要性が浮かび上がっていきました。