情報処理安全確保支援士 2023年 春期 午後II 問題

共通の文章

Webセキュリティに関する次の記述を読んで,設問に答えよ。 A社グループは,全体で従業員20,000名の製造業グループである。技術開発や新 製品の製造・販売を行うA社のほか,特化型の製品の製造・販売を行う複数の子会社 (AE,グループ各社という)がある。A社及びグループ各社には,様々なWebサイ トがある。A社では,資産管理システムを利用し,IT資産の管理を効率化している。 Webサイトの立上げ時は,資産管理システムへのWebサイトの概要,システム構成, IPアドレス,担当者などの登録申請が必要である。 A社には,CIS0が率いるセキュリティ推進部がある。セキュリティ推進部の業務は 主に次の三つである。 ・A社の情報セキュリティマネジメントを統括する。 -A社のWebサイトの脆弱性診断(以下,脆弱性診断を診断という)を管理する。例 Ald,社の会員サイトなど,重要なWebサイトについて,診断を新規リリース前 に実施し,その後も年1回実施する。なお,診断は,セキュリティ専門業者のB社 に委託している。 ・グループ各社に対して,情報セキュリティポリシーやセキュアコーディング規約 を配布する。なお,診断の実施有無や内容はグループ各社の判断に任せている。 IoT製品の市場拡大によってグループ各社による新規Webサイト開発の増加が予想 されている中,A社の経営陣は,グループ各社のWebサイトのセキュリティが十分か どうかを懸念し始めた。そこで,グループ各社の重要なWebサイトも,A社のセキュ リティ推進部がグループ各社と協議しつつ診断を管理することになった。 セキュリティ推進部がB社に診断対象となるWebサイトのリリーススケジュールを 伝えたところ,同時期に多数の診断を依頼されても対応することができない可能性 があるとのことだった。ELC,グループ各社の一部のWebサイトに対する診断をA 社グループ内で実施できるようにするための内製化推進プロジェクト(UF,Sプロ ジェクトという)2S LV, セキュリティ推進部のZさんは,Sプロジェクトを担当することになった。Zさん はこれまでもB社への診断の依頼を担当しており,診断の準備から診断結果の報告ま で,診断全体をおおむね把握していた。 [Sプロジェクトの進め方〕 Sプロジェクトは,B社の支援を得ながら,表1のとおり進めることにした。B社か らは,セキュリティコンサルタントで情報処理安全確保支援士(登録セキスペ)で HOY氏の支援を受けることになった。 表1 Sプロジェクトの進め方 作業内容 診断項目の決定診断項目を決める。 診断ツールを選定する。 フェーズ3|ZさんとB社での診断|A社グループであるK社の製品のアンケートサイト(以 の実施と結果比較下,UF RMという)について,ZさんとB社がそれぞれ 診断を実施する。Zさんは,B社の診断結果との差異を評 価する。 フェーズ4|A社グループの診断手|フェーズ3の評価を基に,A社グループの診断手順案を 順案の作成作成する。 フェーズ5|診断手順案に従った|K社の会員サイト(以下,サイトNという)に対し,A 診断の実施グループの診断手順案に従って,診断を実施する。 フェーズ6|A社グループの診断手|フェーズ5の診断で残った課題についての対策を検討し 順の制定KETC,A社グループの診断手順を制定する。 [フェーズ1:診断項目の決定〕 Sプロジェクトでは,診断項目を決めた。 [フェーズ2:診断ツールの選定〕 B社がWebサイトの診断にツールVを使っていることもあり,A社はツールVを購 入することに決めた。ツールVの仕様を図1に示す。 a I し3— 1.機能概要 Dynamic Application Security Testing(DAST)のツールである。パラメータを初期値から何 通りもの値に変更したHTTPリクエストを順に送信し,応答から脆弱性の有無を判定する。 2.機能 (1)プロジェクト作成機能 (1-1)プロジェクト作成機能:診断対象とするWebサイトのFQDNを登録してプロジェクトを作 成する。 (2)診断対象URLの登録機能 (2-1)診断対象URLの自動登録機能:探査を開始するURLを指定すると,自動探査によって,指 定されたURLの画面に含まれるリンク,フォームの送信先などをたどり,診断対象URLを 自動的に登録していく。診断対象URLにひも付くパラメータ!)とその初期値も自動的に登 録される。 (2-2)診断対象URLの手動登録機能:診断対象URLを手動で登録する。診断対象URLにひも付く パラメータとその初期値は自動的に登録される。 (2-3)診断対象URLの拡張機能:診断対象URLごとに設定できる。本機能を設定すると,診断対 象URLの応答だけでなく,別のURLの応答も判定対象になる。本機能を設定するには,診 断対象URLの拡張機能設定画面を開き,拡張機能設定に,判定対象に含めるURLを登録す る。 (3)拒否回避機能 (3-1)拒否回避機能:特定のパラメータが同じ値であるリクエストを複数回送信すると拒否され てしまう診断対象UNULについては,URLごとに本機能を設定することで,拒否を回避でき る。 (4)URLにひも付くパラメータの設定機能 (4-1)パラメータ手動設定機能:パラメータの初期値を,任意の値に手動で修正して登録する。 (5)診断項目の設定機能 (5-1)診断項目設定機能:診断項目を選択して設定する。 (6)アカウント設定機能 (6-1)利用者IDとパスワードの設定機能:ログイン機能があるWebサイトの場合は,ログイン 後の画面のURLに対して診断するために,診断用のアカウントの利用者IDとパスワード を設定する。 (6-2)アカウントの拡張機能の設定:診断用のアカウントを複数設定できる。 (7)診断機能 (7-1)診断機能:診断項目について診断を行う。診断用のアカウントが設定されている場合は, それらを順番に使う。 (8)レポート出力機能 (8-1)レポート出力機能:診断結果をPDF CHATS. 注HA,検索画面から検索結果が表示される画面に居移するURLが診断対象URLの場合,診 断時に送信される検索ワードを含むパラメータを指す。 図1ツールVの仕様(抜粋) 診断対象URLの自動登録機能及び手動登録機能の特徴を表2に示す。 mis 4 isis 表2診断対象URLの自動登録機能及び手動登録機能の特徴 自動登録機能の特徴手動登録機能の特徴 ・登録に作業者の工数がほぼ不要である。・登録に作業者の工数が必要である。 ・常に一定の品質で登録できる。・Webブラウザを使ってトップページから順に ・Webサイトによっては,登録が漏れる場合が|手動でたどっても,登録が漏れる場合があ ある。例えば,BRIO URLがJavaScriptる。Webサイトの全てのURLを診断対象とす などで動的に生成されるような場合である。る場合,①診断対象URLを別の方法で調べる ・必須入力項目に適切な値を入力できず,正常必要がある。 に乱移できないことがある。 A社は,診断項目のうち,ツールVでは診断ができないものは手動で診断を実施す ることにした。 [フェーズ3:ZさんとB社での診断の実施と結果比較〕 ZさんとBEE,サイトMに対して診断を実施した。サイトMの画面乱移を図2に 示す。 aeアンケートアンケートアンケートアンケート トピックhike’?トピック、 図2サイトMの画面乱移(抜粋) Zさんは,Zさんの診断結果とB社の診断結果とを比較した。その結果,TXAM 弱性の一部を検出できていないことが分かった。検出できなかった脆弱性は,アン ケート入力1の画面での入力値に起因するクロスサイトスクリプティング(以下,ク ロスサイトスクリプティングをXSSという)と,トピック検索の画面での入力値に起 因するSOLインジェクションであった。サイトMのアンケート入力1からの画面居移 を図3に示す。 _5 i アンケート入力1アンケート人入力2アンケート確認アンケート送信完了 We商品のデザインが山田太郎 名好き。会員はいありがとう はいいいえ|i il|商品のデザインが|ii|ございました。 会員©O好き。 注記画面遷移時にWebブラウザから送られたパラメータの値は,次のとおりである。 i:last_name=%E5%B1%B1放7%94%B98first_name=%E5%A4%AA%E9%83%8E8member=Y ii:text=%E5%95%86%E5%93%81旗3%81%AE%E3%83%87%E3%82%B6旗3%82%A4放3%83%B3衝3%81%8C衝 5%A5%BD%E3%81%8D%E3%80%82 iii:submit=Yes M3 tH khMOrve—-haADA1YOOHHES トピック検索の画面で検索条件として入力した値の処理に関する診断でて,ツールV が送ったパラメータと検索結果の件数を表3に示す。なお,トピック検索の画面で検 索条件として入力した値は,パラメータkeywordに格納される。 表3ツールVが送ったパラメータと検索結果の件数(抜粋) 検索結果の件数 eeっ| ee|sw| 注記1 B社はパラメータkeywordの初期値をmanualとしている。 注記2 Zさんはパラメータkeywordの初期値をxyzとしている。 ツールVは,B社の診断では,keyword=manual[aとkeyword=manual |b ]の検索結果を比較してSOLインジェクションを検出できたが,7さんの診 断ではSOLインジェクションを検出できなかった。 _6_— Zさんは,検出できなかった二つの脆弱性について,どうすれば検出できるのかを Y氏に尋ねた。次は,その際のY氏とZさんの会話である。 Y氏 :XSSについては,入力したスクリプトが二つ先の画面でエスケープ処理され ずに出力されていました。XSSの検出には,ツールVにおいて図1中の の②設定が必要でした。S0Lインジェクションについては, keywordの値が文字列として扱われる仕様となっており,SQLの構文エラー が発生するような文字列を送ると検索結果が9件で返ってくるようです。そ こで,③keywordの初期値としてSLインジェクションを検出できる “manual”のような値を設定する必要がありました。 Zさん:なるほど。ツールV ld,Webサイトに応じた初期値を設定する必要があるの ですね。 その後,Zさんは,Y氏とともに,フェーズ3での診断結果を分析した。その際, 偽陽性を除いてから開発者に報告することは難しいことが問題となった。 ECT,Zさんは,"開発者への報告の際に,診断結果の報告内容が脆弱性なのか 偽陽性なのか,その判断を開発者に委ねる。一方,診断結果の報告内容における脆 弱性の内容,リスク及び対策について,開発者がB社に直接問い合わせる。"”という 案にした。なお,B社のサポート費用は,問合せ件数に比例するチケット制である。 グループ各社がB社とサポート契約を結ぶが,費用は,当面A社がまとめて支払い, 後日グループ各社と精算する。 aこれまでの検討を踏まえて,Zさんは,フェーズ4でA社グループの診断手順案を -作成した。 [フェーズ5:診断手順案に従った診断の実施〕 Y氏の協力の下,Zさんは,診断手順案に従ってサイトNの診断を実施することに した。サイトNは既にリリースされている。サイトNの会員(以下,会員Nという) は,幾つかのグループに分けられており,申し込むことができるキャンペーンが会 員の所属しているグループによって異なる。サイトNの画面乱移を図4に示す。 ーィテー ページトップページ変更入力変更確認変更完了 キャンペーンene 4キャンペーン 一覧申込み申込み完了 nae©)製品情報 yo D よくある|(E)よくある 質問検索aki 新規会員新規会員新規会員 登録申込み登録URLを送付情報入力情報確認登録完了 注記1一つのキャンペーンに対して,会員Nは1回だけ申込みできる。 注記2既に登録されているメールアドレスでは,新規会員登録の申込みはできない。 注記3ログインすると,SBNが所属しているグループを識別するためのgroup_codeというパラ メータがリクエストに追加される。 注記4よくある質問検索の画面で検索する際に,次の画面に乱移するURLがJavaScriptで動的に 生成される。 注りパスワードを連続5回間違えるとアカウントがロックされる。ログイン時に発行されるセッ ションIDであるJSESSIONIDはcookieに保持される。ログイン後しばらくアクセスしないと セッション1Dは破棄され,再度ログインが必要になる。 注?新規会員登録の申込み時に電子メールで送付された登録URLにアクセスすると表示される。 図4サイトNの画面大移(抜粋) まず,Zさんは,診断対象URL,アカウントなど,診断に必要な情報をK社に確認 した。しかし,サイトNについては診断に必要な情報が一元管理されていなかったの で,確認の回答までに1週間掛かった。診断開始までに要する時間が課題として残った。 Ric,Zさんは,アカウントの設定を行った後,④探査を開始するURLに図4のト ップページを指定してツールVの診断対象URLの自動登録機能を使用したが,一部の URLは登録されなかった。その後,登録されなかったURLを手動で登録した。診断を 実施してもよいか,Y氏に確認したところ,注意点の指摘を受けた。具体的には,© 特定のパラメータが同じ値であるリクエストを複数回送信するとエラーになり,= 移できない箇所があることに注意せよとのことであった。適切な診断を行うために ツールVの拒否回避機能を設定して診断を実施した。診断では,次に示す脆玉性が検 出された。 ・XSS ・アクセス制御の回避 —8— Zさんは,これらの脆弱性について,サイトNの開発部門(LAF,開発部Nという) に通知し,偽陽性かどうかの判断,リスクの評価及び対策の立案を依頼した。 [XSS] XSSの脆弱性は,複数の画面で検出された。開発部Nから,“cookieにHttpOnly属 性が付いていると,| d|が茜止される。そのため,cookieが漏えいすること はなく,修正は不要である。"という回答があった。Zさんは,この回答を受けてY氏 に相談し,“XSSを悪用してもcookieを盗めないのは確かである。LAL,⑥XSSを 悪用してcookie以外の情報を盗む攻撃があるので,修正が必要である。"と開発部N に伝えた。 [アクセス制御の回避]〕 Zさんは,手動で診断し,アクセス制御の回避の脆弱性を,図4中のキャンペーン 一覧の画面などで検出した。ある会員Nが⑦アクセス制御を回避するように細工され たリクエストを送ることで,その会員Nが本来閲覧できないはずのキャンペーンへの リンクが表示され,さらに,リンクをたどってそのキャンペーンに申し込むことが 可能であった。正常なリクエストとそのレスポンスを図5に,脆弱性を検出するのに 使ったリクエストとそのレスポンスを図6に示す。 [リクエスト] POST/campaignSearch HTTP/1.1 Host:site-n.AAAA.jp Cookie:JSESSIONID=KCRQ88ERH2G8MGT319E50SMOAJFDIVEM group_code=0001&keyword=new [レスポンス] <html> (省略) くh1>申込み可能キャンペーン</h1> <a href="/a_campaign1">1 A社キャンペーン1</a> <a href="/a_campaign2”>2 A社キャンペーン2</a> くh1>注意事項<h1> (省略) 注記1リクエストヘッダ部分は,設問に必要なものだけ記載している。 注記2レスポンスは,レスポンスボディから記載している。 図5正常なリクエストとそのレスポンス =9— [リクエスト] POST/campaignSearch HTTP/1.1 Host:site-n.AAAA.jp Cookie:JSESSIONID=KCRQ88ERH2G8MGT319E50SMOAJFDIVEM keyword=new [レスポンス] <html> (省略) くh1>申込み可能キャンペーン</h1> <a href="/a_campaign1">1 A社キャンペーン1</a> <a href="/a_campaign2”>2 A社キャンペーン2</a> <a href="/b campaign1">3 B社キャンペーン1</a> <a href="/c_campaign1">4 C社キャンペーン1</a> (省略) <a href="/z_campaign2”>30 Z社キャンペーン2</a> くh1>注意事項<h1> (省略) 注記1リクエストヘッダ部分は,設問に必要なものだけ記載している。 注記2レスポンスは,レスポンスボディから記載している。 図6脆弱性を検出するのに使ったリクエストとそのレスポンス 開発部Nは。サイトNへ送られてきたリクエスト中の| e|から,ログイン している会員Nを特定し,その会員Nが所属しているグループが| f|の値と 一致するかを検証するように,ソースコードを修正することにした。 開発部Nは,B社の支援によって対応を終えることができたが,B社へ頻繁に問い 合わせることになった結果,B社のサポート費用が高額になった。サポート費用をど う抑えるかが課題として残った。 [フェーズ6:A社グループの診断手順の制定] Zさんは,フェーズ5の診断で残った二つの課題についての対策を検討し,グルー プ各社から同意を得た上で,A社グループの診断手順を完成させた。 セキュリティ推進部は,制定したA社グループの診断手順をグループ各社に展開し Fee

共通の文章

Webサイトのクラウドサービスへの移行と機能拡張に関する次の記述を読んで,設 問に答えよ。 W社は,従業員199名のブログサービス会社であり,日記サービスというWebサー ビスを10年前から提供している。日記サービスの会員は,自分の食事に関する記事 の投稿及び摂取カロリーの管理ができる。 日記サービスは,W社のデータセンター内で稼働している。ハードウェアの調達に は1か月程度を要する。W社は,日記サービスが稼働している各機器の運用をD社に 委託している。D社に委託している運用を表1に示す。 表1 D社に委託している運用(概要) ログ保全・定期的に,日記サービスが稼働している各機器の全てのログを外部メ ディアにバックアップする。 ・外部メディアにバックアップする前に,ログを一時的にD社作業用端 末にダウンロードする。 ・D社作業用端末でのバックアップ作業後に,D社作業用端末からログ を削除する。なお,各機器からログを削除する作業はW社が行う。 2障害監視・アプリケーションプログラム(WE,アプリという)の問題の一次切 分けを行う。アプリの問題は!,ログを監視しているソフトウェアによ って検知される。 ・ログを確認して一次切分けを行う。その際に,サーバの一覧を参照す る。 ・W社への連絡は,電子メール(以下,メールという)と電話で行う。 3|性能監視・W社が定めた,CPU稼働率,処理性能及び応答時間に関わる指標(以 下,性能指標という)を監視する。 ・異常を検知すると,一次切分けを行う。その際に,サーバの一覧を参 照する。 ・必要に応じて,W社への連絡をメールと電話で行う。 4|機器故障対応・交換対象のハードウェアの発注を行う。 ・故障機器のハードウェア交換作業を行う。 この2,3年,会員が急増しているので,W社は,日記サービスをクラウドサービ スに移行することにした。 ーー13ーー [移行先のクラウドサービス選定〕 W社は,クラウドサービスへの移行時及び移行後の管理,運用について,検討を開 始した。 まず,クラウドサービスへの移行時及び移行後に,W社が何を管理,運用する必要 があるかを調べたところ,表2のとおりであった。 表2 W社が管理,運用する必要のある範囲 構成要素クラウドサービスの分類 ハードウェア。ネットワーク = 注記“O〇O"はW社が管理,運用する必要があるものを示し,“X”は必要がないものを示す。 クラウドサービスへの移行及びクラウドサービスの設定はW社が行い,BTR,表 1の項番1一項番3の運用をD社に委託する計画にした。 移行先のクラウドサービスとして,L社のクラウドサービスを選定した。L社が提 供しているクラウドサービスを表3に示す。 表3 L社が提供しているクラウドサービス クラウドサービス名 仮想マシンサービス・利用者が09やアプリを配備することによって,物理サーバと同じ 機能を実行するための仮想化基盤である。 データベース(以下,DB|・関係DB CHS, という)サービス・容量の拡張,バックアップなどは,自動で実行される。 ブロックストレージサー|・固定長のブロックという論理単位で管理できるストレージである。 ビス仮想マシンサービスのファイルシステムとして割り当てることが可 能である。 オブジェクトストレージ|・データをオブジェクトとして扱い,各オブジェクトをメタデータで 義一区スズ管理できるストレージである。 ・オブジェクトの保存のために必要なサーバの資源管理,容量の拡張 などは,自動で実行される。 モニタリングサービス・利用者が利用しているL社の各クラウドサービスについて,性能指 標を監視する。 表3 L社が提供しているクラウドサービス(続き) アラートサービス・L社のクラウドサービスの環境!でイベント?が発生したときに, そのイベントを検知してアラートをメールで通知する。 仮想ネットワークサービ|・レイヤー2スイッチ(以下,L2SWという),ファイアウォール(以 R下,FWという),ルータなどのネットワーク機器を含むネットワー クを仮想的に構成でき,インターネットとの接続を可能にする。 $90 L社の各クラウドサービスを利用して構築したシステム及びネットワークを指す。 注?特定の利用者による操作,システム構成の変更,設定変更などである。 イベント検知のルールはJSON形式で記述する。そのパラメータを表4に示す。 表4イベント検知のルールに記述するパラメータ service検知対象とするクラウドサービス名|・仮想マシンサービス ・オブジェクトストレージサービス ・モニタリングサービス event検知対象とするイベントeventの取り得る値は,serviceの値によっ て異なる。 ・仮想マシンサービスの場合 -仮想マシンの起動 -仮想マシンの停止 -仮想マシンの削除 ・オブジェクトストレージサービスの場合 -オブジェクトの作成 -AVFVIAbOMRmE -オブジェクトの削除 -オブジェクトの閲覧 -オブジェクトのダウンロード ・モニタリングサービスの場合 -監視する性能指標の追加 -監視する性能指標の削除 注記systemとaccountの取り得る値には正規表現を利用できる。正規表現は次の規則に従う。 [912]は,9,1又は2のいずれか数字1文字を表す。 [9-9]は,9から9までの連続する数字のうち,いずれか数字1文字を表す。 *は,直前の正規表現の9回以上の繰返しを表す。 +は,直前の正規表現の1回以上の繰返しを表す。 仮想マシンサービスを利用して構築した,システムIDが0991のシステムにおいて, 利用者IDが1999である利用者が仮想マシンを停止させた場合の,イベント検知のル ールの例を図1に示す。 1:{ 2:“system”:”0001”, 3:“account”:"1000", 4:"service’:"仮想マシンサービスリ, 5・“event”:UBAB ZY Y OBIE” 6:} 図1イベント検知のルールの例 [日記サービスのL社のクラウドサービスへの移行〕 移行後の日記サービスの仮想ネットワーク構成を図2に,図2中の主な構成要素を 表5に示す。 ここごインターネットDO PDMZ!ルータ「内部セグメント! !|公開Webサーバ||昌記pBD| |[権威DNSサーバ|ログ保管ストレージ?|! 仮想ネットワーク 注り日記サービスのデータを管理するDB 32日記サービスのログを保管するストレージ 図2移行後の日記サービスの仮想ネットワーク構成 表5図2中の主な構成要素 構成要素利用するL社のクラウドサービス 1000公開Webサーバ・仮想マシンサービス ・ブロックストレージサービス 2000権威DNSサーバ・仮想マシンサービス ・ブロックストレージサービス ログ保管ストレージ|・オブジェクトストレージサービス 仮想ネットワーク・仮想ネットワークサービス 注記日記サービスでは,モニタリングサービスとアラートサービスを利用する。 W社は,L社のクラウドサービスにおける,D社に付与する権限の検討を開始した。 [L社のクラウドサービスにおける権限設計〕 L社の各クラウドサービスにおける権限ごとに可能な操作を表6に示す。 表6 L社の各クラウドサービスにおける権限ごどとに可能な操作(抜粋) 一覧の閲覧権限閲覧権限編集権限 仮想マシンサービス仮想マシン一覧の関|仮想マシンに割り当|・仮想マシンの起動,停 覧てだファイルシステデテ止,削除 ム上のファイルの関|・仮想マシンへのファイル 覧システムの割当て ・仮想マシンに割り当てた ファイルシステム上のフ ァイルの作成,編集,削 除 ・仮想マシンの性能の指定 DBサービススキーマ一覧及びテ|テーブルに含まれる|・テーブルの作成,編集, ーブル一覧の閲覧データの閲覧削除 ・テーブルに含まれるデー タの追加,編集,削除 ブロックストレージ|生成したストレージ|ストレージの使用済|・ストレージの生成 サービス一覧の閲覧み容量及び空き容量|・ストレージの容量の指定 の閲覧 オブジェクトストレ|オブジェクト一覧の|オブジェクトの閲覧・オブジェクトの作成,編 ージサービス閲覧集,削除 ・オブジェクトのダウンロ iF モニタリングサービ|監視している性能指|過去から現在までの|・監視する性能指標の追 pe標一覧の閲覧性能指標の値の閲覧加,削除 W社は,D社に付与する権限が必要最小限となるように,表7に示すD HAV OK 限のセットを作成した。 表7 D社向けの権限のセット(抜粋) D社に付与する権限 オブジェクトストレージサービス一覧の閲覧権限,閲覧権限,編集権限 さらに,W社は,OD社の運用者がシステムから日記サービスのログを削除したと きに,そのイベントを検知してアラートをメールで通知するための検知ルールを作 成した。 W社は,L社とクラウドサービスの利用契約を締結して,日記サービスをしL社のク ラウドサービスに移行し,運用を開始した。 [機能拡張の計画開始〕 W社は,サービス拡大のために,機能を拡張した日記サービス(以下,新日記サー ビスという)の計画を開始した。新日記サービスの要件は次のとおりである。 要件1:会員が記事を投稿する際,他社のSNSにも同時に投稿できること 要件2:スマートフォン用のアプリ(以下,スマホアプリという)を提供すること W社は,要件1を実装した後で要件2に取り組むことに決めた。その上で,要件1 を実現するために,T社のSNS(以下,サービスTという)と連携することにした。 [サービスTとの連携の検討] OAuth 2.0を利用してサービスTと連携した場合のサービス要求から記事投稿結果 取得までの流れを図3に,送信されるデータを表8に示す。 Webサーバ認可サーバリジースサーバパ (1)サービス要求 |(3)ERAT SER (4認可同意処理| 、 |(5リダイレクト|| | (7)アクセストークン要求 eee(9)記事投入 (16)記事投稿結果取得|| 図3サービス要求から記事投稿結果取得までの流れ 表8送信されるデータ(抜粋) 送信されるデータ [||GET/authorize?response_type=code&client_id=abcd1234&redirect_uri=https: //A AKA.com/callback HTTP/1.1! Ca]POST/oauth/token HTTP/1.1 Authorization:Basic YWJjZDEyMzQ6UEBzc3dvcmQ=2) grant type=authorization code&code=5810f68ad195469d85f59a6d96e51e96& redirect_uri=https://AAA.com/cal lback 注記AAA.comは,新日記サービスのドメイン名である。 注"クエリ文字列中の“abcd1234”は,英数字で構成された文字列であるクライアントIDを示す。 注?“YWJjZDEyMzQ6UEBzc3dvcm0=”は,クライアントIDL,英数字と記号で構成された文字列で あるクライアントシークレットとを,“:”で連結してbase64でエンコードした値(以下,エン コード値6という)である。 各リクエストの通信でTLS 1.2及びTLS 1.3を利用可能とするために,②暗号スイ ートの設定をどのようにすればよいかを検討した。また,サービスTとの連携のため のモジュール(以下,Rモジュールという)の実装から単体テストまでを社に委託 することにした。『社は,新技術を積極的に活用しているIT企業である。 (CF社の開発環境] F社では,Rモジュールの開発は,取りまとめる開発リーダー1名と,実装から単 体テストまでを行う開発者3名のチームで行う。システム開発において,顧客から開 発を委託されたプログラムのソースコードのリポジトリと外部に公開されているOSS リポジトリを利用している。二つのリポジトリは,サービスEというソースコードリ ポジトリサービスを利用して管理している。 サービスEの仕様と,Rモジュールについての「社のソースコード管理プロセスは, 表9のとおりである。 ー19一 RIサービスEの仕様とF社のソースコード管理プロセス 利用者認|・利用者IDとパスワードによる認証,及び他|・利用者認証には,F社内で運用してい 証及びアのIdPと連携したSAML認証が可能である。る認証サーバと連携した,SAML認証を クセス制|・リポジトリごとに,利用者認証の要・不要利用する。 御を設定できる。・Rモジュール開発向けのリポジトリ ・サービスEは外部に公開されている。(以下。リポジトリWという)には, ・IPアドレスなどで接続元を制限する機能は利用者認証を"要”に設定する。 ない。 バージョ|・ソースコードのアップロードリ,承認,ダウ|・開発者は,静的解析と単体テストを実 ン管理ンロード,変更履歴のダウンロード,削除施する。開発者が,それら二つの結果 が可能である。とソースコードをアップロードして, ・新規作成,変更,削除の前後の差分をソー開発リーダーに承認を依頼するルール スコードの変更履歴として記録する。とする。ただし,静的解析と単体テス ・ソースコードがアップロードされ,承認さトについてリスクが少ないと開発者が れると,対象のソースコードが新バージョ判断した場合は,開発者自身がソース ンとして記録され,変更履歴のダウンローコードのアップロードとその承認の両 ドが可能になる。方を実施できるルールとする。 権限管理|・設定できる権限には,ソースコードのダウ|・開発者,開発リーダーなど全ての利用 ンロード権限,ソースコードのアップロー者に対して,設定できる権限全てを与 ド権限,アップロードされたソースコードえる。 を承認する承認権限がある。 |・利用者ごとに,個別のリポジトリの権限を 設定することが可能である。 ・変更履歴のダウンロードには,ソースコー ドのダウンロード権限が必要である。 ・変更履歴の削除には,アップロードされた ソースコードを承認する承認権限が必要で ある。 ・外部のX社が提供している継続的インテグレ ーションサービス9?(以下,X社CIという) と連携するには,ソースコードのダウンロ ード権限をX社CIに付与する必要がある。ーー サービス|・別のクラウドサービスと連携する際に,権|・X社CIと連携する。 連携限を付与するトークン(以下,Eトークンと|・X社CIに発行するEトークン(以下, いう)を,リポジトリヘアクセスしてきたXトークンという)には,リポジトリ 連携先に発行することができる。Wの全ての権限が付与されている。 ・Eトークンの有効期間は1か月である。Eト ークンの発行形式や有効期間の変更はでき ない。 注記0SSリポジトリには,利用者認証を“不要”に設定している。また,0SSリポジトリのソースコー ドと変更履歴のダウンロードは誰でも可能である。 注!ソースコードのアップロードには,関連するファイルの新規作成,BH,削除の操作が含まれる。 注2アップロードされたソースコードが承認されると,ビルドと単体テストを自動実行するサービス である。 —20— [悪意のある不正なプログラムコードの混入〕 F社は,Rモジュールの実装について単体テストまでを完了して,ソースコードを W社に納品した。その後,W社とT社は結合テストを開始した。 結合テスト時,外部のホストに対する通信がRモジュールから発生していることが 分かった。調べたところ,不正なプログラムコード(以下,不正コードMという)が ソースコードに含まれていたことが分かった。不正コードMは,0Sの環境変数の一 覧を取得し,外部のホストに送信する。新日記サービスでは,エンコード値GがOS の環境変数に設定されていたので,その値が外部のホストに送信されていた。 W社は,漏えいした情報が悪用されるリスクの分析と評価を行うことにした。それ と並行して,不正コードMの混入の原因調査と.プログラムの修正を『F社に依頼し Tes 〔W社によるリスク評価〕 W社は,リスクを分析し,評価した。評価結果は次のとおりであった。 ・エンコード値Gを攻撃者が入手した場合,|m|のWebサーバであると偽っ てリクエストを送信できる。しかし,図3のシーケンスでは,③攻撃者が特定の会 員のアクセストークンを取得するリクエストを送信し,アクセストークンの取得 に成功することは困難である。 次に,W社は,近い将来に要件2を実装する場合におけるリスクについても,リス クへの対応を検討した。 そのリスクのうちの一つは,スマホアプリのリダイレクトにカスタムURLスキーム を利用する場合に発生する可能性がある。W社が提供するスマホアプリと攻撃者が用 意した偽のスマホアプリの両方を会員が自分の端末にインストールしてしまうと, 正規のスマホアプリとサーバとのやり取りが偽のスマホアプリに横取りされ,攻撃 者がアクセストークンを不正に取得できるというものである。この対策として PKCE(Proof Key for Code Exchange)を利用すると,偽のスマホアプリにやり取り が横取りされても,アクセストークンの取得を防ぐことができる。 要件2を実装する場合のサービス要求から記事投稿結果取得までの流れを図4に示 す。 ー21一 —し Webサーバ認可サーバリソースサーバ (1)サービス要求 ||(3)認可要求 (4認可同意処理|| |5)リダイレクト| — (7)アクセストークン要求 |(9)記事投入 (16)記事投稿結果取得|| 図4要件2を実装する場合のサービス要求から記事投稿結果取得までの流れ PKCEの実装では,乱数を基に,チャレンジコードと検証コードを生成する。(3)の リクエストにチャレンジコードとcode challenge methodパラメータを追加し,(7) のリクエストに検証コードパラメータを追加する。最後に,④認可サーバが二つの コードの関係を検証することで,攻撃者からのアクセストークン要求を排除できる。 CF社による原因調査] F社は,不正コードMが混入した原因を調査した。調査の結果,.サービスEのOSS リポジトリ上に,Xトークンなどの情報が含まれるファイル(以下,ファイルZとい う)がアップロードされた後に削除されていたことが分かった。 F社の開発者の1人が,ファイルZを誤ってアップロードし,承認した後,誤って アップロードしたことに気付き,ファイルZを削除した上で開発リーダーに連絡して| いた。開発リーダーは,ファイルZが0SSリポジトリから削除されていること,ファ イルZがアップロードされてから削除されるまでの間にダウンロードされていなかっ たことを確認して,問題なしと判断していた。 F社では,⑤第三者がXトークンを不正に取得して,リポジトリWに不正アクセス し,不正コードMをソースコードに追加したと推測した。そこで,Feld,Xトー クンを無効化し,次の再発防止策を実施した。 ・表9中のバージョン管理に関わる見直しと⑥表9中の権限管理についての変更 ・Xトークンが漏えいしても不正にプログラムが登録されないようにするための,⑦ 表9中のサービス連携に関わる見直し ソースコードには他の不正な変更は見つからなかったので,不正コードMが含まれ る箇所だけを不正コードMが追加される前のバージョンに復元した。 W社は,『社が改めて納品したRモジュールに問題がないことを確認し,新日記サ ービスの提供を開始した。