令和3年度 春期 情報処理安全確保支援士試験 午後Ⅱ 問2｜「各部が勝手に契約したSaaS」が招いた事故——情報処理安全確保支援士で学ぶクラウドセキュリティとシャドーITの実例

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

• 試験区分: 情報処理安全確保支援士
• 出典: 令和3年度 春期 情報処理安全確保支援士試験 午後Ⅱ 問2
• 主なテーマ: クラウドセキュリティ、シャドーIT、SaaS統制、IDaaS、SAML、802.1X、DHCP枯渇、リンクローカルアドレス、パスワード使い回し、プロキシ型クラウド

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

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

「便利だから、現場の判断でとりあえず使い始めた」——クラウドサービス（SaaS）の利用は、いまやこんな形で会社のあちこちに広がっています。情報システム部門が把握しないまま導入されたツールは「シャドーIT」と呼ばれ、利便性の裏で大きなセキュリティリスクを抱え込みます。

情報処理安全確保支援士試験の午後Ⅱで出題されたこの事例は、急成長中の投資コンサルティング会社を舞台に、統制のないSaaS利用と個人所有機器の持ち込みが二つのトラブルを引き起こし、そこから「次期ITをどう安全に設計するか」を考えていく物語です。一つ目はネットワーク障害、二つ目はチャットサービスのアカウント乗っ取り。どちらも、特別に高度な攻撃ではなく、「ルールがなかった」ことから生まれた事故でした。

この記事を読むと、169.254で始まる謎のIPアドレスの正体、パスワードの使い回しがなぜ乗っ取りに直結するのか、IDaaSやSAMLによるシングルサインオンの仕組み、そして「過剰に縛らずに、しかし守る」というクラウド時代の統制設計が見えてきます。受験者には論点の宝庫であり、SaaSを使う企業の経営者・管理職にとっては「現場の自由とガバナンスの両立」を考える格好の教材になるはずです。

インシデントの概要

舞台は、従業員150名の個人向け投資コンサルティング会社C社です。ファイナンシャルプランナーを中心とした事業部、営業部、企画部、経営管理部から成り、顧客の投資診断や運用提案を行うロボットアドバイザサービスが好調で、創立5年目にして売上高30億円を超えるまでに成長していました。

そのC社のCEOは、次期ITについて二つの方針を掲げます。一つは「サービスを向上させるためにITを積極活用し、特にSaaSを活用する」こと。もう一つは「働き方改革とパンデミック対策の観点から、テレワーク環境を整備する」ことでした。時代に即した、前向きな方針です。

しかし、現場の足元は危ういものでした。情報システムの管理を担うのは、経営管理部の総務グループ（総務G）のわずか5名。従業員には1人1台のPC（C-PC）を貸与していましたが、OSのドメインコントローラ（社内のPCやアカウントを一元管理する仕組み）は導入しておらず、従業員は各自のC-PCにローカルログインしていました。そして決定的だったのが、二つの「野放し」です。第一に、PCやスマートフォンなどの個人所有機器を社内LANに接続することを統制しておらず、多くの従業員が私物を社内ネットワークにつないでいました。第二に、業務でSaaSを新たに使う際の会社統一の承認ルールがなく、各部が独自の判断でSaaSの利用契約を結んでいたのです。

便利さを優先したこの状態は、「シャドーIT」と「私物の持ち込み」が同時に進行している、いわばセキュリティ上の地雷原でした。トラブルは、二つの形で表面化します。

何が起きたのか

最初のトラブルは、新入社員が配属されたある日に起きました。「C-PCで障害が発生している」という連絡が、総務Gに次々と入ってきたのです。総務GのAさんが調査すると、奇妙な状況が浮かび上がります。朝の時点では誰も異常を感じていなかった。ところが、営業部のUさんが13時に出張から戻ってC-PCを起動したところ、ローカルログインはできるのに、業務サーバにアクセスできず、メールの送受信もインターネット閲覧もできない。そして、その後に起動したC-PCや個人所有機器の多くで、同じ障害が起きていました。しかし、一部の機器では何も問題が起きていない。障害が出た機器と出ない機器に、これといった違いは見当たりませんでした。

Aさんが障害の出ているC-PCのネットワーク設定を調べると、IPアドレスの上位2オクテット（先頭の2区切り）が「169.254」になっていることに気づきます。C社は雑居ビルの中にあり、誰でもオフィスに近づける環境。Aさんは「偽のDHCPサーバ（PCにIPアドレスを自動で割り当てる仕組み）が立ち上げられたのでは」とサイバー攻撃を疑い、経営管理部のE部長に報告しました。

ここで登場するのが、支援を依頼されたD社の情報処理安全確保支援士（登録セキスペ）のKさんです。Kさんの見立ては、Aさんの予想とは違っていました。「169.254で始まるIPアドレスは、DHCPサーバが正常に動作していないときに、機器が自分で仮に割り当てるアドレス（リンクローカルアドレス）です。偽のDHCPサーバの仕業ではなく、社内LANでの個人所有機器の利用が原因で問題が起きた結果でしょう」と。つまり、こういうことでした。多くの従業員が私物の機器を社内LANに次々とつないだ結果、DHCPサーバが配れるIPアドレスが足りなくなり（IPアドレスの枯渇）、新たに起動した機器がアドレスをもらえなくなった。アドレスをもらえなかった機器は、やむを得ず自分で169.254のリンクローカルアドレスを設定し、その結果、社内の他の機器とまともに通信できなくなっていたのです。出張から戻って遅れて起動したUさんのPCが障害に遭ったのも、すでにアドレスが枯渇していたからでした。Kさんは念のため「UTM以外にDHCPサーバが動いていないかも調べておくとよい」と助言し、Aさんが確認したところ、不正なDHCPサーバは見つかりません。攻撃ではなく、私物の持ち込みによるアドレス枯渇——これが真相でした。

このDHCPトラブル（トラブル1）が解決した直後、今度は別のトラブル（トラブル2）が襲います。企画部が最近使い始めた無料のビジネスチャットサービスR（サービスR）で、異変が起きたのです。企画部の部員Vさんのアカウントから、模造サングラスを売る不正サイトへ誘導するチャットが、連続して書き込まれていました。Vさん本人にはまったく身に覚えがありません。

調査を進めると、典型的な落とし穴が見えてきます。企画部では以前から、別のSNS「サービスW」でも公開情報を発信していました。Vさんを含む数名の部員は、会社のメールアドレスをサービスRとサービスWの両方の利用者IDとして登録し、しかも両方で同じパスワードを設定していたのです。あるとき、サービスWでパスワード漏えいの事故が発生。部員全員がサービスWのパスワードを変更しましたが、誰一人としてサービスRのパスワードは変えませんでした。結果、漏れたパスワードを使ってサービスRのアカウントが乗っ取られたのです。

さらに事態を悪化させたのが、無料SaaSの限界でした。外部の何者かがサービスR内の情報に不正アクセスして情報を持ち出していないかを調べようと、AさんはサービスRの提供会社にアクセスログの提供を問い合わせます。しかし返ってきた答えは「無料のサービスについてはログを提供できない」。何が見られたのかを確かめる手段が、そもそも存在しなかったのです。E部長は、仮に情報漏えいがあった場合に最大でどの程度の被害になり得るかを判断するため、「アクセスログ以外で実施できる調査」——具体的には、企画部の部員がアクセスできるチャットエリアで共有されていた情報を洗い出す調査——を指示しました。幸い大きな被害はありませんでしたが、E部長は強い危機感を抱きます。

この二つのトラブルを受け、E部長はCEOに「業務における個人所有機器とSaaSの利用を統制すべきだ」と提言しました。CEOは統制の必要性に同意しつつ、しかし重要な釘を刺します。「過剰に統制すると、従業員のビジネスマインドを阻害しかねない。統制レベルは慎重に検討してほしい」と。ここから、C社の本当の挑戦——「縛りすぎず、しかし守る」次期ITの設計——が始まりました。