令和5年度 春期 情報処理安全確保支援士試験 午後 問3｜社外から守るか、社外でも守るか——情報処理安全確保支援士で学ぶクラウドと在宅勤務のセキュリティ設計の実例

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

• 試験区分: 情報処理安全確保支援士
• 出典: 令和5年度 春期 情報処理安全確保支援士試験 午後Ⅰ 問3
• 主なテーマ: SAML認証、IDaaS、送信元IP制限、在宅勤務のセキュリティ設計、SASE/SWG・CASB、TLSインスペクション、URLフィルタリング、多要素認証

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

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

「社内からのアクセスだけ許可しておけば安全」——クラウドとオフィスがセットだった時代には、この考え方が通用しました。しかし在宅勤務が当たり前になると、その前提は崩れます。従業員は自宅から、会社のシステムにも複数のクラウドサービスにもアクセスする。守るべき境界が、オフィスの壁の外へ広がってしまうのです。

今回の情報処理安全確保支援士試験の事例は、まさにこの転換期に立つ製造業の会社を描いています。前半は、クラウドサービスへのログインを束ねるSAML認証（一度の認証で複数サービスを使えるようにする仕組み）と、送信元IPアドレスの制限によってフィッシング被害を防ぐ、従来型の「境界で守る」設計。後半は、全社員の在宅勤務導入にともない、その境界が使えなくなる中で、どうやって安全を保つかという「境界の外でも守る」設計への移行です。

この記事を読むと、SAML認証の流れ、IPアドレス制限がなぜフィッシングを防げるのか、そしてSASEやCASBといった新しいクラウドセキュリティの考え方が見えてきます。受験者にはクラウド・認証分野の総合問題の解き方が、情シス担当者には「在宅勤務をどう安全に実現するか」の設計図が得られる事例です。

インシデントの概要

舞台は、工場がある本社と複数の営業所から成る、従業員1,000名の製造業Q社です。営業部、研究開発部、製造部、総務部、情報システム部があり、ネットワークは情報システム部のK部長とS主任を含む6名で運用していました。

Q社の従業員にはPCとスマートフォンが貸与されています。PCの社外持ち出しは禁止されており、PCのWebブラウザからインターネットへのアクセスは、本社のプロキシサーバ（社内から外部Webへの通信を中継するサーバ）を経由する仕組みでした。業務では四つのSaaS（SaaS-a〜d。インターネット経由で使う業務アプリ）と、LサービスというIDaaS（Identity as a Service。クラウド上で認証を一元管理する仕組み）を利用しています。

このうちLサービスは、SAML（異なるサービス間で認証情報を安全に受け渡す規格）で各SaaSと連携し、従業員が一度Lサービスで認証すれば各SaaSを使える、シングルサインオン（一度のログインで複数サービスを利用）の中核を担っていました。さらにLサービスには「送信元制限機能」があり、契約した顧客が設定したIPアドレス（Q社の場合は本社UTMのグローバルIPアドレス）からのアクセスだけを許可していました。

物語は、この堅牢な認証基盤が「在宅勤務」という新しい働き方の前で、見直しを迫られていく過程を追います。

何が起きたのか

最初の出来事は、同業他社のJ社で起きたフィッシング詐欺の報道でした。J社では、SaaS-aの偽サイトに誘導され、利用者IDとパスワードを盗まれる被害があったのです。

しかしQ社のS主任は、報道と同様の被害がQ社で起こるおそれは低いと考えました。なぜか——仮に同様のフィッシングメールを受けて、偽サイトにLサービスの利用者IDとパスワードを入力してしまう従業員がいたとしても、攻撃者がそのIDとパスワードを使って社外からLサービスを利用することはできないからです。Lサービスの送信元制限機能が、本社UTMのグローバルIPアドレスからのアクセスだけを許可していたため、攻撃者が自分の環境（＝許可されていないIPアドレス）からログインを試みても、はじかれてしまうのです。IDとパスワードが漏れても、それを使える場所が限られていれば被害は防げる——これがIPアドレス制限の力でした。

ところが、この「境界で守る」仕組みの前提が、大きく揺らぐ出来事が訪れます。Q社が全従業員を対象に在宅勤務を導入することになったのです。

在宅勤務では、リモート接続用PC（R-PC）を貸与し、各従業員宅のネットワークから本社のサーバにアクセスしてもらうことになりました。しかしここで二つの懸念が生じます。一つは、在宅勤務で本社への通信が増え、本社のインターネット回線がひっ迫すること。もう一つは、新たなセキュリティリスクが生じることです。従来は「本社のUTMを通る通信だけ」という前提で守れていたのに、従業員が自宅から直接クラウドにアクセスするようになれば、その前提が崩れます。

K部長は、ネットワーク構成の見直しに着手し、要件を整理しました。本社のインターネット回線をひっ迫させないこと。Lサービスに接続できるPCを、本社・営業所のPCとR-PCに制限すること。R-PCから本社サーバにアクセスできるようにしつつ、UTMには「インターネットからの通信を許可するルール」を追加しないこと。HTTPS通信の内容をマルウェアスキャンすること。SaaS-a以外の外部ストレージサービスへのアクセスを禁止し、SaaS-aへのアクセスは業務で必要な最小限の利用者に限定すること——。

これらの要件を満たすため、ベンダーが紹介したのが、P社のクラウドサービス（Pサービス）でした。Pサービスは、R-PC・社内・クラウドサービスの間の通信を中継するクラウド型のセキュリティ基盤です。Lサービス連携機能（PサービスのIPアドレスを送信元制限に使える）、マルウェアスキャン機能、URLフィルタリング機能（アクセス先URLの種類や利用者の組み合わせで許可/禁止を判定）、通信可視化機能、リモートアクセス機能などを備えていました。

特に重要なのがマルウェアスキャン機能の仕組みです。HTTPS通信は暗号化されているため、そのままでは中身を検査できません。そこでPサービスは、送信元からのTLS通信（暗号化通信）をいったん終端して復号し、マルウェアスキャンを行い、完了後に再暗号化して送信先へ送ります（TLSインスペクションと呼ばれる手法）。これを実現するため、Pサービスのサーバ証明書を発行する認証局の証明書を、信頼されたルート証明書としてPCにインストールします。こうすることで、PCは「Pサービスが間に入って復号・再暗号化している」ことを警告なしに受け入れられるのです。

S主任は、Pサービスを導入した新しいネットワーク構成と、要件を満たすための見直し案をまとめました。Lサービスでの送信元制限は、PサービスのIPアドレスからのアクセスだけを許可する形に変更。営業所からインターネットへのアクセス方法も見直し、フィッシング対策をさらに強化するため、Lサービスの多要素認証機能を有効にしてTLSクライアント認証（クライアント側の証明書で本人確認する方式）を選択。URLフィルタリングでは、研究開発部の従業員だけにSaaS-aへのアクセスを許可し、それ以外の外部ストレージサービスは全従業員に禁止する、という細かな制御を設計しました。

こうしてQ社は、上層部の承認を得て、6か月後に在宅勤務を開始します。「本社の境界で守る」設計から、「クラウドを起点に、どこからでも守る」設計へ——働き方の変化に合わせて、セキュリティの基盤そのものを作り替えた事例です。