情報処理安全確保支援士 2017年 秋期 午後2 問02

　 　X社は、従業員数10,000名の生命保険会社である。X社では、業務担当者が契約の情報を管理するシステム（以下、K1システムという）を、15年前から運用している。K1システムは、X社データセンタに設置されており、次の4種類のサーバ及び共有ストレージで構成されている。 　・データベース（以下、DBという）サーバ：被保険者の氏名、生年月日、住所、電話番号、医療情報・健康情報など（以下、被保険者情報という）及び契約条件（以下、被保険者情報と契約条件を併せて契約情報という）を保管 　・Webアプリケーションサーバ：契約情報を管理する業務アプリケーションが稼働 　・LDAPサーバ：利用者IDとパスワードを保管 　・認証サーバ：リバースプロキシとして運用 　 　K1システムの論理構成を図1に示す。 　

〔K1システムの現在の運用〕 　現在、K1システムは、次のように運用されている。 　(1) 災害対策 　　・バックアップセンタには、K1システムと同じ論理構成のバックアップシステムが用意されており、通常時は開発環境・テスト環境として利用されている。 　(2) 本番環境における作業担当 　　・定型運用作業（K1システムの起動及び停止、DB及びファイルのバックアップなど）：オペレータが担当 　　・DBMS と Webアプリケーションサーバソフトウェアとを除いたミドルウェア及び OS の設定変更作業・非定型運用作業：システム管理者が担当 　　・DBMS, Webアプリケーションサーバソフトウェア及び業務アプリケーションの設定変更作業・非定型運用作業：業務アプリケーション管理者が担当 　(3) オペレータ及び管理者に付与される権限 　　・オペレータとシステム管理者には、DBMS と Webアプリケーションサーバソフトウェアとを除くミドルウェア及び OS 上の全ての操作権限が付与されており、その他の権限は付与されていない。 　　・業務アプリケーション管理者には、DBMS, Webアプリケーションサーバソフトウェア、業務アプリケーション、及び業務アプリケーションのログに関する全ての操作権限が付与されており、その他の権限は付与されていない。 　(4) リスク対策 　　X社では、契約情報の漏えい防止に最優先で取り組んでいる。そのため、K1システムでは、次のような対策を行っている。 　　・社内 PC 上のWebブラウザと Webアプリケーションサーバ間の通信は、TLS プロトコルによる暗号化通信である。 　　・Webアプリケーションサーバ上の業務アプリケーションと DB サーバ間は、Java プログラムから DB に接続するための API である JDBC の暗号化通信を利用している。 　　・契約情報は、業務アプリケーションが、共通鍵暗号方式で暗号化し、DB サーバに保管している。 　　・業務処理を行う際、業務アプリケーションは、DB サーバから契約情報を読み出して復号する。 　 〔K1システムにおける課題〕 　現在、X社は、K1システムの更改を計画している。更改後のシステム（以下、K2 システムという）では、契約者が PC のWebブラウザ及びスマートフォンのアプリからインターネットを介して K2 システムにアクセスし、契約情報の参照、被保険者情報の更新などを行えるようにする。また、K2 システムにおいても、K1システムにおける運用を引き継ぎ、契約情報の漏えい防止を最優先とした。 　X社は、K2システムの要件定義において、システム開発ベンダY社の支援を受けることにした。Y社がK1システムの仕様を確認したところ、DBサーバに保管する契約情報の暗号化及び復号の仕組みに問題があることが判明した。Y社は、X社に対して次の指摘を行った。 　指摘1　契約情報の暗号化に鍵長56ビットのDESアルゴリズム（以下、56bitDESという）が使われている。鍵長256ビットのAESアルゴリズムに変更すべきである。 　指摘2　契約情報の暗号化及び復号に用いる鍵が平文でファイルに保管されており、オペレータ及びシステム管理者に当該ファイルのアクセス権が付与されている状況である。安全な鍵管理の仕組みに変更すべきである。 　 　指摘1に関して、Y社から次の根拠が示された。 　aの安全対策基準（日本国内において金融機関などがよりどころとすべき共通の安全対策基準）では、b暗号リスト（電子政府における調達のために参照すべき暗号のリスト）などに記載されている暗号技術を採用するのが望ましいとしているが、当該暗号リストにおいて、56bitDESは推奨されていない。また、次の前提条件に基づいて試算した結果から、今日では、56bitDESの解読に必要なPCの台数は、攻撃者が現実的に調達可能な台数である。 　・1998年に開催された第2回DES解読コンテストにおいて、4万台のPCで56bitDESの全鍵空間の80%を探索し、40日で解読した。 　・解読所要時間はプロセッサのMIPS値に反比例する。 　・1998年のコンテストで使われたPCに搭載されたプロセッサのMIPS値を、540MIPSと仮定する。 　・2017年製のPCに搭載されたプロセッサのMIPS値を、133,920MIPSと仮定する。 　・40日間で鍵空間の80%を探索するために必要な、2017年製のPCの台数を試算する。 　 〔暗号方式の検討〕 　X社には、危たい化した暗号技術を使っているシステムがK1システム以外にも複数あった。そこで、Y社からの指摘を踏まえ、X社は、暗号技術を含む暗号方式の社内標準について検討した。その結果、契約情報を業務アプリケーションではなくDBMSで暗号化してDBに保管する方式（以下、DB暗号方式という）を社内標準として、X社の全システムに適用することにした。DB暗号方式の設計に当たって、X社は次のシステム標準と要件を定義した。 　システム標準1　業務アプリケーションはJavaで開発する。 　システム標準2　DBMSには、暗号化機能及びDBレプリケーション機能がある製品Dを採用する。

　要件1　製品DのDBに保管される情報を暗号化及び復号する機能（以下、表領域暗号化機能という）を用いて、DBに保管される契約情報を暗号化する。 　要件2　契約情報の暗号化及び復号に用いる鍵を、暗号モジュールを用いて保護する。 　

　暗号モジュールとは、暗号化、復号、乱数生成、鍵管理などの機能を提供するハードウェア又はソフトウェアのことである。NISTが定めたc140-2は、暗号モジュールに求められるセキュリティ要件を定義したものである。 　X社は、暗号モジュールに、Q社の製品Hを採用した。また、X社は、複数のサーバからネットワーク経由で1台の製品Hの機能を利用するために、Q社が提供しているソフトウェア製品であるHクライアントとHサーバも採用した。 　製品Hは、c140-2 Level 4の要件を満たすハードウェアの暗号モジュールであり、サーバに取り付けられるPCI Expressカードである。製品Hは、製品Hを取り付けたサーバ（以下、HSMサーバという）上で稼働するプログラム（以下、ローカルプログラムという）に対して独自のAPI（以下、API-Xという）を提供し、ローカルプログラムからAPI-Xを呼び出すことで、暗号化、復号、乱数生成、データの暗号化及び復号に使用する鍵（以下、データ鍵という）の生成、データ鍵の保管、並びに保管したデータ鍵の削除を行う。また、製品Hは、製品H、及び製品Hに保管するマスタ鍵を管理するプログラム（以下、ユーティリティプログラムという）を導入した専用の管理端末に対して、製品H自身に対する管理インタフェースを提供する。 　K2システムにおける契約情報の暗号化機能の概要を図2に示す。図2において、Hサーバはローカルプログラムに該当する。

　製品Hの仕様は次のとおりである。 　仕様1　初期化 　　管理端末上でユーティリティプログラムを起動し、製品H経由で鍵ストアファイルを作成した後、マスタ鍵を生成し、製品Hを利用可能な状態にする。 　　・マスタ鍵は、3人の鍵管理者が別々に管理端末から入力した256ビットの値（以下、部分鍵という）の排他的論理和によって生成され、製品Hのメモリ内に保持される。製品Hのメモリは、製品Hの内蔵バッテリによって駆動する。 　　・部分鍵は、管理端末に接続されたICカードリーダ／ライタを用いて、別々のICカードに保管することができる。その際、鍵管理者は6桁のPINを入力し、かつ、部分鍵を記録したICカードを別々に保管する必要がある。 　　・ICカードから部分鍵を読み出す際は、PINの入力が必要になる。 　仕様2　乱数の生成 　　ローカルプログラムから乱数を生成するAPI-Xを呼び出すと、製品Hが乱数を生成し、API-Xの出力値として返す。 　仕様3　鍵の生成 　　・ローカルプログラムが、データ鍵の識別子（以下、データ鍵IDという）をパラメタに設定して、データ鍵生成のAPI-Xを呼び出すと、製品Hがデータ鍵を生成する。 　　・生成されたデータ鍵は、製品Hにおいてマスタ鍵で暗号化され、データ鍵IDとともに鍵ストアファイルに保管される。 　　・既に鍵ストアファイルに存在しているデータ鍵IDを指定してデータ鍵を生成しようとすると、API-Xの処理結果はエラーとなる。 　仕様4 暗号化又は復号 　　・ローカルプログラムが、データ鍵ID、及び、暗号化又は復号を行うデータを、パラメタに設定して、暗号化又は復号のAPI-Xを呼び出す。 　　・製品Hは、鍵ストアファイルから暗号化されたデータ鍵を読み出してマスタ鍵で復号し、復号されたデータ鍵でデータの暗号化又は復号を行った後、暗号化又は復号されたデータを、API-Xの出力値として返す。データの暗号化又は復号は製品H内で行われ、復号されたデータ鍵は、製品H内だけに存在する。 　　・鍵ストアファイルに存在しないデータ鍵IDを指定して暗号化又は復号を行おうとすると、API-Xの処理結果はエラーとなる。 　仕様5 マスタ鍵のゼロ化 　　製品Hには、内蔵バッテリで駆動するセンサが内蔵されている。①センサが次のいずれかを検知すると、製品Hは、メモリ上に保持されているマスタ鍵をゼロ化するとともに、自身を使用不能で、かつ、元に戻せない状態にする。 　　(a) 電気的短絡（ショート）の発生などによる規定の範囲を超える電源電圧の発生 　　(b) 製品Hのカバーのこじ開け又は損傷 　　内蔵バッテリが切れそうな場合、製品HはHSMサーバを介して警告メッセージを出力し、早期のバッテリ交換を促す。内蔵バッテリの交換手順として、(a)の発生を回避する手順が提供されている。 　

　HクライアントとHサーバを用いると、HSMサーバとは別のサーバで稼働するプログラム（以下、リモートプログラムという）からネットワークを介して製品Hを利用できる。Hクライアントは、リモートプログラムが稼働するサーバに導入され、リモートプログラムに対してPKCS#11のAPIを提供する。HサーバはHSMサーバに導入され、TLS通信を介してHクライアントに製品Hの機能を提供する。 　HクライアントとHサーバの仕様は次のとおりである。

（1）API-Xの実行要求 　・リモートプログラムがHクライアントを呼び出すと、Hクライアントは、受け取ったPKCS#11のAPI呼出しをAPI-Xの実行要求に変換して、Hサーバに送信する。 　・API-Xの実行要求を受信したHサーバは、API-Xを呼び出し、その実行結果を応答としてHクライアントに返す。ただし、鍵生成の場合、Hクライアントは、内部でデータ鍵IDを0から順番に採番してHサーバにAPI-Xの実行要求を送信し、鍵生成が成功した場合にデータ鍵IDをAPI-Xの出力値としてリモートプログラムに返す。鍵生成が失敗した場合、Hクライアントはリモートプログラムにエラーを返す。 （2）Hサーバに対する負荷分散 　Hクライアントは、複数のHサーバにAPI-Xの実行要求を振り分ける負荷分散機能をもっている。負荷分散機能の概要は次のとおりである。 ・Hクライアントに、複数のHサーバのIPアドレス又はホスト名を登録する。 ・Hクライアントは、登録されたHサーバのうち稼働しているHサーバに、ラウンドロビン方式でAPI-Xの実行要求を送信する。　 　 　製品Dの表領域暗号化機能には、PKCS#11のAPIを提供する暗号モジュールが必要である。製品Dの表領域暗号化機能の仕様は次のとおりである。

仕様A DBを作成する際、表領域暗号化の設定が有効になっていると、製品DはPKCS#11のAPIを用いてDBマスタ鍵を生成する。この際、DBマスタ鍵及びDBマスタ鍵の識別子（以下、DBマスタ鍵IDという）が暗号モジュール内に保存され、DBマスタ鍵IDがAPIの出力として製品Dに返される。製品Dは、DBマスタ鍵IDを設定ファイルに保存し、同時にメモリ上に保持する。 仕様B 表領域を作成する際、表領域暗号化の設定が有効になっていると、製品DはPKCS#11のAPIを用いて乱数を生成する。生成された乱数は、データの暗号化鍵・復号鍵（以下、DBデータ鍵という）として、製品Dのメモリ上に保持される。同時に、製品DはPKCS#11のAPIを用いてDBデータ鍵をDBマスタ鍵で暗号化する。暗号化されたDBデータ鍵は、表領域の一部としてディスクに書き込まれる。 仕様C データをディスクに書き込む際、製品Dは、保持しているDBデータ鍵でデータを暗号化した後、ディスクに書き込む。 仕様D ディスクからデータを読み込む際、製品Dは、まず、ディスク上からデータを読み込んだ後、読み込まれた暗号化データを、保持しているDBデータ鍵で復号する。 仕様E 製品Dは、停止する際、メモリ上に保持しているDBデータ鍵をゼロ化する。 　

　K2システムのDB暗号方式では、製品Dの表領域暗号化機能に必要な暗号モジュールとして製品Hが用いられる。また、製品Dの表領域暗号化機能の仕様におけるDBマスタ鍵及びDBマスタ鍵IDが、それぞれ、製品Hの仕様におけるデータ鍵及びデータ鍵IDに該当する。 　K2システムのDB暗号方式におけるDBの初期化処理の概要を、図3に示す。図3中では、製品Dの表領域暗号化機能の仕様のうち、仕様Aと仕様Bを記載している。

　 〔DBサーバ及びHSMサーバの構成設計〕 　X社は、K2システムのサーバ構成について、Y社に次の要件で設計を依頼した。 　・DBサーバをアクティブ・スタンバイの2台構成にする。 　・災害対策として、製品DのDBレプリケーション機能を用いて、X社データセンタのDBからバックアップセンタのDBに、定期的にデータをコピーする。 　・HSMサーバは、K2システム以外のシステムのDBサーバを含めた全DBサーバからも共有できるようにする。 　 　Y社が設計したK2システムのサーバ構成を図4に示す。

　Y社は、K2システムにおけるDB及び表領域の作成手順を次のように設計した。 (i) HSMサーバ1だけを稼働させ、他のHSMサーバは停止させておく。 (ii) DBサーバ1だけを稼働させ、他のDBサーバは停止させておく。 (iii) 製品D-1上で、DBαを作成する。 (iv) 製品D-1上で、DBβを作成する。 (v) 製品D-1上で、DBαに対応する表領域1を作成する。 (vi) 製品D-1上で、DBβに対応する表領域2を作成する。 (vii) 全てのHSMサーバ及び全てのDBサーバを停止させる。 (viii) 鍵ストアファイル1を、鍵ストアファイル2及び鍵ストアファイル3にコピーする。 (以下、省略) 　 　Y社は、DB暗号方式において、Hクライアント及びHサーバの仕様では複数システムのDBサーバから1台のHSMサーバを共有することはできないとX社に伝えた。そこで、X社が開発元のQ社に問い合わせたところ、Q社からは、来月リリースされる新しいバージョンのHクライアント及びHサーバに次の機能を追加するという回答を得た。 　・Hクライアントを一意に識別する識別子（以下、HクライアントIDという）を設定し、Hサーバに鍵生成を要求する際に従来のデータ鍵IDにHクライアントIDを付け加えて送信する。 　・Hサーバは、Hクライアントから送信された鍵生成要求を処理する際、HクライアントIDと従来のデータ鍵IDを結合した、新たなデータ鍵IDをパラメタとして、鍵生成のAPI-Xを呼び出す。Hクライアントは、新たなデータ鍵IDをDBマスタ鍵として製品Dに返す。 　 　複数の業務システムのDBサーバが1台のHSMサーバを共有する場合の構成を、図5に示す。

　 〔K2システムにおけるリスク対策の補完〕 　X社は、DB暗号方式を実装したK2システムについて、契約情報の漏えいリスクを分析した。リスク分析の結果、次の対策を追加することになった。 　対策1 不審なアクセスがないか監視する。具体的には、週次で、業務アプリケーションのログから、業務時間外のアクセス及び大量の契約情報へのアクセスがないかチェックし、もしあれば、その内容を確認する。 　対策2 DBサーバ又はWebアプリケーションサーバのメモリダンプをファイルに出力した場合、次の作業に対して、作業者、作業日時及び作業内容を履歴として残す。 　　・メモリダンプのファイルへの出力 　　・メモリダンプファイルへのアクセス 　　・メモリダンプファイルを保管した外部記憶媒体の利用 　　・メモリダンプファイルの消去 　 　K2システムの設計を終えたX社は、更改作業に向けて準備を開始した。