分かってみればどうということはない

サピックスα1で2024年中学受験を目指した息子と理系リーマンパパの生活雑記帳

セキスペ令和4年春午後2問2【情報処理安全確保支援士過去問解説】【CDN/SSO/OAuth2.0/OpenID】

令和4年春「情報処理安全確保支援士試験」午後2問2の振り返りメモになります。

問題全体のお話

動画投稿配信サービスを提供する会社が舞台です。クラウドに移行したい、他社クラウドと連携して従業員の要望を叶えたい思いがあり色々なサービスと連携する話が飛び交いました。

  • 会員の増加で自社サーバ負担増&インターネット回線逼迫のため、世界中に代理サーバを配置して高速化する「①CDN」を利用する話。
  • 一度認証すれば複数システムにログインできちゃう「SSO(シングルサインオン)」のお話。
    • ②ケルベロス認証のSSOと、③SAML認証のSSOが出ました。
  • 他社サービスと連携して色々な従業員の要望を叶える話。
    • ④OAuth2.0によるサービス連携(会議スケジュール調整サービスとの連携)
    • ⑤Opne ID Connectを使ったサービス連携(動画投稿したらメッセージ投稿サイトにも投稿するようにするの仕組み)

①CDNについて

CDN(Content delivery Network)とは?

ウェブコンテンツを「効果的に」「早く」配信するネットワークです。世界中に代理サーバを配置することで、ウェブコンテンツの提供を高速化します。

元サーバと代理サーバはDNSサーバの設定(CNAMEレコード)で紐づけておき、ユーザが元サーバにアクセスするリクエスト(HTTP)を送信すると、CDNは代理サーバに転送してくれます。

CDN関連でどんな問題が出た?

CDNに関する問題
  •  代理サーバの名称は?
    • キャッシュサーバ
  • アクセスしたいウェブコンテンツのFQDNを入れるヘッダは?
    • HOSTヘッダ
  • CDNってどんな脆弱性攻撃対策になる?
    • 分散配置するので大元のサーバの負荷が下がりDDOS攻撃対策にもなる
CDNの仕組みを悪用するドメインフロンティング攻撃の問題

HTTPリクエストのヘッダ指定したFQDNを別FQDNへ転送するCDNの便利な仕組みを悪用する「ドメインフロンティング攻撃」が出題されました。

この攻撃は、マルウェアに感染したPC(以下感染PC)が攻撃者サーバと通信して攻撃司令を受けたいときに、PCから攻撃者サーバと直通信しようとすると、FWなどでガードされてしまうため、CDNの転送機能を悪用するものです。

感染PCがCDNを利用するウェブサイトへ通信を試みて接続を確立させた後、HTTPリクエストのヘッダに(確立させたウェブサイトでなく)攻撃者サーバのFQDNを指定するとCDNは親切に転送してくれるので通信が可能になってしまいます。

その対策として、FWかプロキシサーバを通信をエンコード解析できる高性能なものにして、HTTPリクエストのHOSTヘッダの値と何を一致していることを検証するか?という問題が出ました。(解答速報では”接続先サーバ名”)

②ケルベロス認証によるSSOの話

ケルベロス(Kerberos)認証の流れざっくり

アクセスチケットをもらうため、2回認証を行うのが大きな流れです。

1回目認証サーバへIDパスワードによって、他のサーバへのアクセスを許可するチケット(TGT:Ticket Granting Ticket)を発行してもらいます。

2回めはチケット発行サーバ(TGS)へアクセスしたいサーバへ期限付きのサービスチケット(ST)を発行してもらいます。(このときTGTも一緒に送る)

発行してもらったSTを元にアクセスしたいサーバへアクセスします。

ケルベロス(Kerberos)認証でどんな問題が出たか?

ST偽造による不正アクセス

TGTは認証サーバ側で確認できますが(ST発行依頼のときにチェックできるため)、STは認証サーバ側で検証しないためST偽造を検知することができません。

STの奪取&サーバ管理者パスワード解読でサーバ乗っ取り

STが奪われても被害はユーザ利用者権限の情報範囲ですが、奪われた後サーバ管理者パスワードが解読されると、管理者権限でサーバ内情報が乗っ取られます。

この解読にパスワード総当り攻撃がログイン連続失敗ロックで防げない点が出題問題が出ました。

解答速報ではオフラインで実行されるためで、STさえ奪取されると、アクセス権限はPCに任せているのが弱点のもようです。

③SAML認証によるSSOの話

SAML認証によるSSOとは

ユーザがアクセス要求すると水面下でサービス側(SP:Service Provider)とID管理側(Idp:Identity Provider)がやりとりしてSSOを実現する方式です。ざっくり流れは以下。

  1. ユーザがSPにアクセスすると、SPがIdpに認証要求。
  2. IdPがユーザをチェックしてOKならトークン(アサーション)を発行。
  3. SPは「アサーション」に記載されたユーザは「大丈夫なユーザ」と判断してログイン可とする。 

どんな問題が出たか?

  • SP側から来る認証要求はHTTPリクエストのどこからIdPは取得するか?
    • クエリ文字列(サーバに送信する「データ」を指定するためURL末尾に加えた文字列)
  • 上記アサーションをデジタル署名する人はだれ?
    • IdP
  • デジタル署名検証でアサーションの何がないことを確認する?
    • 改ざん
  • 事前準備するものは?
    • SP側が認証要求を出すIdP側のURL
    • お互い(IdPはSP側のSPはIdP側)のデジタル証明書
      • 相手からリクエストが来たとき相手先が正しいか確認するため。
      • 逆にリクエスト発行時デジタル署名するものは秘密鍵なので共有NG

④OAuth2.0によるサービス連携

他社の会議スケジュール調整サービスと連携して、簡単にスケジュール調整するため、それをOAuth2.0を使って実現する話が出ました。

OAuthとは?

SNSやWebサービス連携する際にアクセス権限の認可を行うプロトコルです。

オーオースと読みます。

 

例えばインスタ投稿したらTwitterにも自動投稿したいシーン。

連携元のサービス(インスタ)に、連携先のサービス(Twitter)のIDパスワードも教えると、万が一悪い人がいたら連携先サービスをいじられる可能性があります。

このため、サービス連携時に部分的な情報(Twitterの投稿だけ)にだけ権限を限定するときに使われます。

 

処理のざっくり流れとしては、短命な認可コード(通行手形)を連携サービスがお互いやりとりしてから、アクセス範囲を限定したアクセストークンをやりとりします。

このため、攻撃者がアクセストークンを奪取しても認可コードがわからなければ攻撃できません。(認可コードも短命なので、例え盗まれても攻撃が難しい)

 

参考にしたサイトです。すごくわかりやすいです。

tech-lab.sios.jp

OAuthでどんな問題が出たか?

クロスサイトリクエストフォージェリ(CSRF)

ユーザが意図しない処理を実行させる攻撃です。(参考wikiこちら)

 

攻撃者アカウントで作られた認可コードを利用者に送りつけて、気づかないうちに利用者が攻撃者アカウントで意図せず操作してしまうもの。イワユル「乗っ取り」でなく「乗っ取られ」攻撃です。


対策として、サービスが連携する際にパラメタ(state)をつけて相手サービスに送り、自サービスもパラメタを攻撃者のセッションと紐づける内容が試験に出ました。

第三者が利用しようとしても、セッションが違うのでのっとられが避けられる流れです。

以下サイトがとても参考になりました。

tech-lab.sios.jp

スマホアプリ上での認可コード横取り

攻撃者が用意したスマホアプリを知らずにインストールして、OAuthでサービス連携すると認可コードを横取りされ、その認可コードで攻撃者アプリがアクセストークンを要求し結果的に不正アクセスされてしまいます。

 

この対策機能として、OAuthの拡張機能PKCE(Proof Key for Code Exchange)が出題されました。ピクシーと読みます。

 

サービス連携するときチャレンジコードを作成して認可サーバに送り認可サーバはハッシュで保存しておきます。攻撃者アプリはチャレンジコードをしらないので認可がはじかれる仕組みです。

以下記事がとても参考になりました。

qiita.com

⑤OpenID Connectを使ったサービス連携

動画サーバに投稿するとメッセージ投稿サイトにも自動投稿する仕組みをOpenID connectで実現するお話が出ました。

OpenID Connectとは?

めんどくさいIDパスワード認証を認証サーバ(IDprovider:Googleなど)にお任せして認証結果を受け取って認証する方式です。

IDトークン(認証チケット)を認証してくれるサーバ(IDprovider)からもらって認証します。

OAuth2.0の拡張機能で、OAuthはアクセス権限(認可)のプロトコルですが、この機能でユーザ認証もできるように拡張されました。

以下サイトがとても参考になりました。

tech-lab.sios.jp

OpenIDでどんな問題が出たか?

  • IDトークンは何で暗号化されている?
    • base64url ※知識問題
    • 64種の英数字+URLが含まれてもエンコードできるようにする方式
  • nonce値の検証について
    • Number used onceの略(ノンスと読む)
    • 一度だけ使用される数字の意味
    • リプレイアタック(認証データを盗聴し、そのデータをそのまま使ってなりすます攻撃)の防止に使う
    • 認証要求する際にnonce値も付けてIDproviderに送る。IDproviderから返ってきたIDトークンに含まれるnonce値を検証する仕組み。
    • 検証が終わったらすぐさまnonce値を削除する。そうすると攻撃者が後で傍受したIDトークンをリプレイアタックしても拒否れる

nonce値はここ参考にしました。このサイト分かりやすさが神ってます。

tech-lab.sios.jp

合わせて読みたい!

知識ほぼゼロから情報処理安全確保支援士を合格した勉強法とは?

合わせて読みたい!

他の過去問振り返りはこちら