令和5年度 春期 情報処理安全確保支援士試験 午後 問2｜クラウド移行と外部連携の落とし穴—情報処理安全確保支援士で学ぶ責任共有モデル・OAuth・最小権限のセキュリティ事例

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

• 試験区分: 情報処理安全確保支援士

• 出典: 令和5年度 春期 情報処理安全確保支援士試験 午後Ⅱ 問2

• 主なテーマ: クラウド移行と責任共有モデル、委託先への最小権限、イベント検知ルール（監視）、OAuth 2.0 認可コードフロー、PKCE、ソースコードリポジトリのトークン漏えいとサプライチェーン

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

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

自社のサーバルームで動かしていたサービスを、クラウドに「引っ越し」する。いまや当たり前の選択です。ところが、この引っ越しには、オンプレミス（自社の建物の中で機器を持って運用する形態）の時代にはなかった種類の落とし穴が口を開けています。「どこまでが自分の責任で、どこからがクラウド事業者の責任なのか」が見えにくくなり、「誰に、どの操作までを許すのか」という権限の線引きが一気に複雑になるからです。

情報処理安全確保支援士試験の午後Ⅱで出題されたこの事例は、ブログサービスを運営する会社が日記サービスをクラウドへ移行し、さらに外部のSNS（ソーシャル・ネットワーキング・サービス）と連携して機能を拡張していく物語を通じて、その落とし穴を一つずつ照らし出します。クラウドの管理範囲（責任共有モデル）、運用委託先への権限付与、操作を見張るイベント検知の設計、OAuth 2.0という外部連携の認可の仕組み、そしてPKCEというトークン横取り対策。最後には、ソースコードを預けたリポジトリからトークンが漏れ、不正なコードが製品に混入するという、サプライチェーン（製品が作られて届くまでの供給網）型のインシデントにまで話は及びます。

この記事を読むと、クラウド移行のどこに設定ミスや認可の弱さが潜むのか、なぜOAuthの「認可コード横取り」が起きるのか、そして「最小権限」をサボると一枚のトークン漏れが製品全体の汚染につながるのかが、一本の流れとして見えてきます。受験対策としてはもちろん、クラウドや外部サービスを使う立場の経営者・管理者にとっても、「便利さの裏で何を握らせているのか」を確かめる判断軸が得られるはずです。

インシデントの概要

舞台は、従業員100名のブログサービス会社、W社です。W社は「日記サービス」というWebサービスを10年前から提供しています。会員は自分の食事に関する記事を投稿したり、摂取カロリーを管理したりできる、生活に密着したサービスです。

この日記サービスは長らくW社のデータセンター内で稼働してきました。サーバなどのハードウェア（物理的な機器）を調達するには1か月程度かかり、各機器の日々の運用は、D社という外部の運用会社に委託していました。D社の仕事は、機器の全ログ（動作記録）を外部メディアに定期的にバックアップすること、アプリ（アプリケーションプログラム。サービスを動かすソフトウェア）の障害を一次切分けすること、CPU稼働率や応答時間といった性能指標を監視すること、そして故障したハードウェアを交換することでした。なお、各機器からログを削除する作業だけはW社自身が行う、という線引きが定められていました。

ところが、この2、3年で会員が急増します。物理サーバの増設には毎回1か月。これでは成長に追いつけません。そこでW社は、日記サービスをクラウドサービスへ移行することを決めました。

移行先に選んだのは、L社が提供するクラウドサービス群です。仮想マシン（物理サーバの代わりに、ソフトウェア上で動く仮想的なサーバ）、関係データベース、ブロックストレージやオブジェクトストレージ（後で詳しく触れます）、性能を監視するモニタリングサービス、異常を知らせるアラートサービス、そしてネットワークを仮想的に組むサービス。これらを組み合わせて、日記サービスをそっくりクラウド上に再構築する計画です。移行とクラウドの設定はW社が行い、移行後の日々の運用は引き続きD社に委託する——ここまでは、よくあるクラウド移行の絵に見えます。

しかし、この「引っ越し」と、その後に控えた「機能拡張」の道のりで、W社はいくつもの設計判断を迫られることになります。そして、その一つひとつが、セキュリティの強さを左右していくのです。

何が起きたのか

物語は、W社がクラウド移行の検討を始める場面から動き出します。最初に突きつけられたのは、素朴ながら本質的な問いでした。「クラウドに移したあと、いったい何を自分たちで管理しなければならないのか」。

オンプレミスの時代は単純でした。ハードウェアからOS（基本ソフト）、ミドルウェア（OSとアプリの橋渡しをするソフト）、アプリ、データまで、すべて自分たちのものであり、すべて自分たちの責任でした。ところがクラウドでは、利用形態によって「事業者が面倒を見てくれる範囲」が変わります。IaaS（Infrastructure as a Service。仮想サーバやネットワークといった基盤だけを借りる形態）、PaaS（Platform as a Service。OSやミドルウェアまで用意された土台を借りる形態）、SaaS（Software as a Service。完成したアプリそのものを使う形態）。同じ「クラウドを使う」でも、自分が管理する範囲はまるで違うのです。W社は、構成要素ごとに「IaaS/PaaS/SaaSで自分たちが管理・運用する必要があるか」を一つずつ整理しました。これを世間では「責任共有モデル」と呼びます。

次に直面したのが、運用を委託するD社に「どこまでの操作を許すか」という問題でした。クラウドの世界では、操作の許可は「権限」という単位で細かく付与されます。一覧を眺めるだけの権限、中身を見る権限、作って消して書き換える権限——L社のサービスは、これらを別々に設定できるようになっていました。W社は「D社に渡す権限は、必要最小限にする」という方針を立てます。D社がやるのは監視とログのバックアップであって、日記サービスのデータベースを書き換えることではない。ならば、データベースを操作する権限は渡すべきではない。当たり前のようでいて、ここを曖昧にすると、委託先のうっかりや、委託先アカウントの乗っ取りが、そのまま本番データの破壊につながります。

そして三つ目が、「誰が、何をしたか」を見張る仕組みです。L社にはアラートサービスがあり、特定の利用者による操作やシステム構成の変更を検知して、メールで知らせてくれます。検知のルールはJSON形式（人にもプログラムにも読みやすい、データの書き方の一種）で書きます。「どのシステムで」「どの利用者が」「どのサービスの」「どんなイベントを」起こしたら知らせるか、という四つの条件を指定するのです。しかも、システムIDや利用者IDには正規表現（文字列のパターンを記号で表す書き方。たとえば`[0-9]`は数字一文字を表す）が使えるため、「利用者IDが1110から1199までのいずれか」といった範囲指定もできます。

ここでW社は、ある重要な検知ルールを作りました。「D社の運用者が、日記サービスのログを削除したときに、それを検知してアラートを飛ばす」というものです。ログはインシデントの調査に欠かせない証拠です。その証拠を、運用委託先が——たとえ正規の権限の範囲内であっても——消す動きをしたら、すぐに気づけるようにしておく。監視とは、外部からの攻撃だけでなく、内部の正規利用者の動きにも目を配ることなのだと、この一手は教えてくれます。

移行が無事に完了し、運用が始まったあと、W社は次の野心に進みます。機能拡張です。会員が記事を投稿するとき、他社のSNSにも同時に投稿できるようにしたい。そのために、T社のSNS（サービスT）と連携することにしました。ここで登場するのが、OAuth 2.0（オーオース。あるサービスが、利用者のパスワードを預からずに、別のサービスの一部機能を代行利用するための認可の仕組み）です。

OAuthの認可コードフロー（authorization code grant）は、一見すると回りくどい手順を踏みます。会員が新日記サービスで「サービスTにも投稿する」と操作すると、ブラウザはいったんサービスTの認可サーバ（誰に何を許すかを判断するサーバ）へリダイレクト（自動的に別の場所へ飛ばすこと）されます。会員がそこで「この新日記サービスに、私の代わりに投稿することを許可します」と同意すると、認可サーバは「認可コード（code）」という短命の引換券を発行し、ブラウザ経由で新日記サービスに渡します。新日記サービスは、この引換券と、自分が正規のサービスであることを示す秘密の合言葉（クライアントIDとクライアントシークレット）を使って、認可サーバから「アクセストークン」を受け取ります。アクセストークンは、いわば期間限定の入館パスです。これを持っていれば、サービスTのリソースサーバ（実際のデータや機能を持つサーバ）に対して、会員に代わって記事を投稿できるのです。

なぜ、わざわざ「引換券（code）」を一度はさむのか。ここがこの仕組みの肝です。もし攻撃者が、新日記サービスの秘密の合言葉（クライアントIDとクライアントシークレットを連結してエンコードした値。本文ではこれが後に漏えいします）を手に入れたとしても、それだけではアクセストークンを取れません。アクセストークンを要求するには、その会員に紐づいた認可コードが必要であり、認可コードは会員のブラウザを経由して正規のサービスにしか渡らないからです。攻撃者は、特定の会員の認可コードを横から奪うことができない。だから、合言葉だけを握っても、なりすましのトークン取得は困難になる——これが、認可コードフローが守ろうとしている境界線でした。

ところが、ここに新たな緊張が走ります。要件として、スマートフォン用のアプリ（スマホアプリ）を提供する計画があったのです。スマホアプリでは、認可サーバからアプリへ戻ってくるときに「カスタムURLスキーム」という仕組みがよく使われます。ところがこのスキーム、同じ「呼び出し名」を別のアプリも登録できてしまう。つまり、会員が正規アプリと、攻撃者が用意した偽アプリの両方を端末に入れてしまうと、本来は正規アプリに戻ってくるはずの認可コードが、偽アプリに横取りされる恐れがあるのです。認可コードを奪われれば、攻撃者はアクセストークンを取得し、会員になりすまして投稿できてしまう。せっかくの「引換券方式」が、スマホ特有の事情で破られかけるのです。

この弱点をふさぐのが、PKCE（ピクシー。Proof Key for Code Exchange。認可コードの横取り対策の仕組み）でした。PKCEは、認可の要求を始める前に、乱数から二つの値を作ります。一つは「検証コード（code_verifier）」、もう一つはそれをSHA-256（入力から固定長の要約値を作る一方向のハッシュ関数）で変換した「チャレンジコード（code_challenge）」です。最初の認可要求ではチャレンジコードを送り、後のアクセストークン要求では検証コードを送る。認可サーバは、受け取った検証コードを自分でSHA-256ハッシュ化してbase64url（URLでも安全に使える形式の文字列符号化）で表した値が、最初に受け取ったチャレンジコードと一致するかを確かめます。一致しなければトークンは出さない。仮に偽アプリが認可コードを横取りしても、最初に乱数から作られた検証コードを知らなければ、アクセストークンは取得できないのです。

そしてここから、物語はもっとも苦い展開を迎えます。連携機能のモジュール（部品となるプログラム。Rモジュール）の実装は、新技術に積極的なIT企業F社に委託されました。F社は単体テスト（部品ごとの動作確認）まで終えてソースコードを納品。ところが、W社とT社が結合テスト（部品を組み合わせた確認）を始めたところ、Rモジュールから外部のホストへ、見覚えのない通信が発生していたのです。

調べると、ソースコードに「不正コードM」が紛れ込んでいました。不正コードMは、OSの環境変数（プログラムに設定値を渡す仕組み）の一覧を盗み取り、外部へ送信するものでした。よりによって、新日記サービスでは、OAuthの秘密の合言葉（先ほどのエンコード値）が、その環境変数に設定されていた。つまり、外部連携の認証情報そのものが、攻撃者の手に渡っていたのです。

では、不正コードMは、どうやってソースコードに混入したのか。F社の調査が、最後の謎を解きます。F社はソースコードをサービスEというリポジトリ（ソースコードを保管・履歴管理する場所）で管理していました。そのうち、外部に公開されたOSSリポジトリ（誰でも閲覧できる、オープンソース用の保管場所）の上に、「ファイルZ」というファイルが一度アップロードされ、すぐ削除されていたことが判明します。このファイルZには、外部サービス連携用のトークン（Xトークン）など、機微な情報が含まれていました。

経緯はこうでした。F社の開発者の一人が、誤ってファイルZをアップロードして承認し、直後にミスに気づいて削除。開発リーダーに連絡しました。リーダーは「ファイルZはもう削除されている」「アップロードから削除までの間にダウンロードされた記録はない」ことを確認し、問題なしと判断したのです。安心したように見えました。しかし——その判断には、致命的な見落としがありました。リポジトリは、削除という操作さえも「変更履歴」として残します。そして、このOSSリポジトリは誰でも変更履歴をダウンロードできた。攻撃者は、削除されたはずのファイルZを、変更履歴をたどって取り出せたのです。こうしてXトークンが漏れ、攻撃者はそのトークンで本番のリポジトリに不正アクセスし、不正コードMをソースコードに忍ばせた。一枚のトークンの漏れが、製品の汚染と、連携用認証情報の流出にまで連鎖した瞬間でした。