平成30年度 秋期 情報処理安全確保支援士試験 午後Ⅱ 問1｜データはどこに置けるのか—情報処理安全確保支援士で学ぶハイブリッドクラウド移行のセキュリティ設計

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

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

• 出典: 平成30年度 秋期 情報処理安全確保支援士試験 午後Ⅱ 問1

• 主なテーマ: ハイブリッドクラウド環境のセキュリティ設計、GDPR・輸出管理規制・データの置き場所、SAML2.0/SPNEGOによるシングルサインオン、NIST CSF、エンドポイント管理、モバイル端末・VPN・リスクベース認証

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

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

「クラウドに移せば、運用が楽になり、コストも下がる」——。多くの企業がそう考えてクラウド移行に踏み出します。ところが、いざ設計を始めると、技術ではなく「法律」と「地理」の壁にぶつかることが少なくありません。このデータは海外のデータセンタに置いてよいのか。災害時に別の国へ切り替わる仕組みは、規制に違反しないのか。情報処理安全確保支援士の午後Ⅱで出題されたこの事例は、まさにその難しさを、グローバル製造業のシステム移行という舞台で立体的に描いています。

主役は、日本・米国・欧州に展開する従業員80,000名の製造会社、X社です。重要インフラ設備（電力や通信など社会を支える基盤に関わる設備）を作っているため、扱う情報には輸出管理規制（特定の製品や技術情報を国外に持ち出すことを制限する法令）がかかり、欧州事業ではGDPR（後述するEUの個人データ保護規則）も意識しなければなりません。そんな会社が、メールや業務システムをクラウドへ移そうとしたとき、何を悩み、どう設計を組み立てていったのか。

この事例には、攻撃者も、派手な情報漏えいも登場しません。けれど、現実のセキュリティ実務でいちばん多い「設計の判断」がぎっしり詰まっています。データをどこに置けるか、認証をどう一本化するか、社外に持ち出す端末をどう守るか——。情報処理安全確保支援士の受験者にとっては、クラウド時代の設計問題の見本市であり、クラウド移行を進める経営者にとっては「移行できないものがある」という現実を理解する教材になるはずです。

インシデントの概要

X社は、サーバ、ネットワーク機器、PCで構成される大規模なシステムを運用しています。日本国内だけで従業員は40,000名。東日本データセンタには、人事サーバ（Windows）、業務サーバ（Windows・Linux・商用UNIXが混在）、生産関連サーバ、そして二種類の認証サーバが置かれ、ファイアウォール（許可した通信だけを通す関門）とIPS（不正な通信を検知して遮断する装置）を経てインターネットにつながっています。社内WAN（拠点間を結ぶ自社の広域ネットワーク）で各地の工場や拠点、西日本データセンタが接続される構成です。

認証の要は二つのサーバでした。認証サーバA1は、社内PCやWindows業務サーバ、人事サーバへログオンするときの利用者認証（本人確認）を担い、人事サーバと連携して従業員情報を毎日反映しています。もう一つの認証サーバB1は、Linuxや商用UNIX上で動くWebアプリにアクセスするときの認証を担う「リバースプロキシ型」（利用者とサーバの間に立って認証を肩代わりする仕組み）の認証サーバで、A1のLDAP（利用者情報を一元管理するディレクトリサービス）を使って動いていました。

そしてX社には、絶対に守らなければならない「基本要件」がありました。これは三つの土台から成ります。一つ目は自社の情報セキュリティ標準。二つ目は輸出管理規制。三つ目は各国・各地域の個人情報保護に関する法規制です。とりわけ重要インフラ設備の設計・生産技術にかかわる「R&D情報」(基礎研究や開発中の最重要情報)は、物理的な入退室管理が行われたプロジェクトルーム内のサーバに保管し、そのルーム内の専用PCからしかアクセスさせない、という厳格なルールが課せられていました。生産関連サーバも、同じ国・地域内の2か所以上に分散配置しなければならない——これは輸出管理規制に由来する制約です。

この、がんじがらめに見える基本要件こそが、物語の主役です。X社がクラウド移行に踏み切ろうとしたとき、まず立ちはだかったのは外部の攻撃者ではなく、自分たち自身が守ると決めたこのルールでした。

何が起きたのか

X社の経営層は、ある決断を下します。米国でのビジネスを強化し、新しい事業を生み出すために、システム部門の役割を「運用」から「ビジネス企画・システム企画」へとシフトさせる。そのために、各国・各地域のシステムを思い切ってクラウドへ移そう、と。

方針は二段構えでした。まず、メールシステムはM社のSaaS（インターネット越しに使うソフトウェアサービス）であるQへ、業務システムのうち二つはS社のSaaS Sへ、1年以内に移す。次に、その他のシステムは、H社のIaaS（仮想サーバなどの基盤をインターネット越しに借りるサービス）Cの上に、5年かけて段階的に移す。IaaS C上のOSやミドルウェアの運用は、SIベンダのJ社の運用サービスに任せる——。一見、すっきりした計画でした。

ところが、システム部門が設計に着手すると、最初の壁にぶつかります。「移してはいけないもの」「移すと基本要件を満たせなくなるもの」が、次々と見つかったのです。

象徴的だったのが、プロジェクト専用サーバでした。ここに保管されるR&D情報は、「物理的な入退室管理が行われたプロジェクトルーム内のサーバに保管する」という基本要件で縛られています。クラウドに置いた瞬間、そのサーバはもう「入退室管理されたプロジェクトルーム内」には存在しません。要件を満たせなくなるのは明らかでした。担当者は、これは移せない、と判断します。

さらに頭を悩ませたのが、生産関連サーバです。IaaS Cには魅力的なオプションがありました。日本国内のデータセンタが被災した場合、シンガポールのデータセンタへ自動的に切り替えてサービスを継続してくれる、という災害対策サービスです。事業継続の観点では、喉から手が出るほど欲しい機能でした。ところが、ここで輸出管理規制が牙をむきます。「同じ重要インフラ設備を製造する工場および生産関連サーバは、同一の国または地域内の2か所以上に配置する」。災害時に勝手にシンガポールへ切り替わってしまえば、データは国境を越え、この要件に真っ向から反することになります。事業継続のための機能が、規制違反の引き金になる——担当者は、生産関連サーバも現状のまま残すしかないと結論づけました。

こうしてX社は、「移すシステム」と「移せないシステム」が混在する状態、すなわちオンプレミス（自社で保有・運用する設備）とクラウドが共存するハイブリッドクラウド環境へと進んでいきます。ここから、設計の難しさは加速します。

第二の難所は、認証でした。オンプレミスのサーバ、IaaS C上のサーバ、SaaS QとSaaS S——利用者が使うシステムの置き場所がバラバラになると、ログインの仕組みもバラバラになりかねません。システムごとにIDとパスワードを入力させるのでは、利用者は悲鳴を上げます。そこでX社は、これらをひとつの認証基盤でつなぐことを目指しました。IaaS C上のWindows業務サーバ用には、A1と同じ製品の認証サーバA2をクラウドに新設し、A1とSAML2.0（システム間で認証情報を安全にやりとりする標準仕様）で連携させる。認証サーバB1はバージョンアップし、SPNEGO（Webブラウザの認証情報を裏側で受け渡すプロトコル)でA1と通信させ、A1が発行したトークン（認証済みを証明する電子的な切符)で利用者を認証する。SaaS QとSaaS Sも、B1とSAML2.0で連携させ、B1が発行したトークンで認証する——。

この設計には、明確な狙いがありました。利用者が一度ログインすれば、オンプレミスのシステムも、クラウドのシステムも、SaaSも、すべてに追加のログインなしでアクセスできる。いわゆるシングルサインオン（SSO。一度の認証で複数のシステムを使える仕組み)の実現です。

ただし、認証サーバB1をどこに置くかは、悩ましい問題でした。現行どおりオンプレミスに置く案と、IaaS Cへ移す案。どちらにも一長一短があります。社内PCからオンプレミスの業務サーバへアクセスするなら、B1も近くにあったほうが通信は短くて済む。けれど、IaaS C上の業務サーバが増えてくれば、B1もクラウド側にあったほうが効率的になるかもしれない。X社は初期段階ではオンプレミスに置く案を選び、社内PCと各業務サーバ間の通信量を定期的に測りながら、移す時期を見極めることにしました。

そして第三の難所が、端末でした。X社は、出張先や自宅でも働けるよう、従業員にモバイルPCとスマートフォン(あわせてモバイル端末)を貸与する計画を立てます。社外から社内システムやクラウドにアクセスできれば便利ですが、その分、情報漏えいやマルウェア感染のリスクが跳ね上がります。しかも、ちょうどX社は自社の情報セキュリティ標準を、NIST CSF(米国国立標準技術研究所が定めた、重要インフラのサイバーセキュリティを高めるためのフレームワーク)を基に改定しようとしていたところでした。端末をどう管理し、どう守るか——この問いが、物語の最終幕を形づくっていきます。