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

共通の文章

問2データ暗号化の設計に関する次の記述を読んで,設問1こ4に答えよ。 X社は,従業員数10,000名の生命保険会社である。X社では,業務担当者が契約 の情報を管理するシステム(以下,K1システムという)を,15年前から運用してい る。K1システムは,X社データセンタに設置されており,次の4種類のサーバ及び 共有ストレージで構成されている。 ・データベース(以下,DBという)サーバ:被保険者の氏名,生年月日,住所,電 話番号,医療情報・健康情報など(以下,被保険者情報という)及び契約条件 (以下,被保険者情報と契約条件を併せて契約情報という)を保管 (Webアプリケーションサーバ:契約情報を管理する業務アプリケーションが稼働 ・LDAPサーバ:利用者IDとパスワードを保管 ・認証サーバ:リバースプロキシとして運用 K1システムの論理構成を図1に示す。 (Fa eee ia)|| |ee BT—URE:広域イーサネットサービス網 Bl Kiシステムの論理構成 〔K1システムの現在の運用〕 BE,K1システムは,次のように運用されている。 ①)災害対策 ・バックアップセンタには,K1システムと同じ論理構成のバックアップシステム が用意されており,通常時は開発環境・テスト環境として利用されている。 (2)本番環境における作業担当 ・定型運用作業(K1システムの起動及び停止,DB及びファイルのバックアップ など):オペレータが担当 cs 1= ・DBMSとWebアプリケーションサーバソフトウェアとを除いたミドルウェア及 びOSの設定変更作業・非定型運用作業:システム管理者が担当 ・DBMS,Webアプリケーションサーバソフトウェア及び業務アプリケーションの 設定変更作業・非定型運用作業:業務アプリケーション管理者が担当 (3)オペレータ及び管理者に付与される権限 ・オオペレータとシステム管理者には,DBMSとWebアプリケーションサーバソフ トウェアとを除くミドルウェア及び0S上の全ての操作権限が付与されており, その他の権限は付与されていない。 ・業務アプリケーション管理者には,DBMS,Webアプリケーションサーバソフト ウェア,業務アプリケーション,及び業務アプリケーションのログに関する全 ての操作権限が付与されており,その他の権限は付与されていない。 (4)リスク対策 X社では,契約情報の漏えい防止に最優先で取り組んでいる。そのため,K1シ ステムでは,次のような対策を行っている。 ・社内PC上のWebブラウザとWebアプリケーションサーバ間の通信は,TLSプ ロトコルによる暗号化通信である。 ・Webアプリケーションサーバ上の業務アプリケーションとDBサーバ間は,Java プログラムからDBに接続するためのAPIであるJDBCの暗号化通信を利用して いる。 ・契約情報は,業務アプリケーションが,共通鍵暗号方式で暗号化し,DBサーバ に保管している。 ・業務処理を行う際,業務アプリケーションは,DBサーバから契約情報を読み出 して復号する。 (KIシステムにおける課題] 現在,X社は,KIシステムの更改を計画している。更改後のシステム(UF,K2 システムという)では,契約者がPCのWebブラウザ及びスマートフォンのアプリ からインターネットを介してK2システムにアクセスし,契約情報の参照,被保険者 情報の更新などを行えるようにする。また,K2システムにおいても,K1システムに おける運用を引き継ぎ,契約情報の漏えい防止を最優先とした。 ー17一 X社は,K2システムの要件定義において,システム開発ベンダY社の支援を受け ることにした。Y社がK1システムの仕様を確認したところ,DBサーバに保管する 契約情報の暗号化及び復号の仕組みに問題があることが判明した。Y社は,X社に対 して次の指摘を行った。 指摘1契約情報の暗号化に鍵長56ビットのDESアルゴリズム(以下,56bitDES という)が使われている。鍵長256ビットのAESアルゴリズムに変更すべき である。 Hi 2契約情報の暗号化及び復号に用いる鍵が平文でファイルに保管されており, オペレータ及びシステム管理者に当該ファイルのアクセス権が付与されてい る状況である。安全な鍵管理の仕組みに変更すべきである。 指摘1に関して,Y社から次の根拠が示された。 |。|の安全対策基準(日本国内において金融機関などがよりどころとすべ き共通の安全対策基準)では,| b|障号リスト(電子政府における調達のた めに参照すべき暗号のリスト)などに記載されている暗号技術を採用するのが望ま しいとしているが,当該暗号リストにおいて,56bitDESは推奨されていない。また。, 次の前提条件に基づいて試算した結果から,今日では,56bitDESの解読に必要なPC の台数は,攻撃者が現実的に調達可能な台数である。 ・1998年に開催された第2回DES解読コンテストにおいて,4 HAO PCT 56bitDESの全鍵空間の80%を探索し,40日で解読した。 ・解読所要時間はプロセッサのMIPS値に反比例する。 ・1998年のコンテストで使われたPCに搭載されたプロセッサのMIPS値を,540 MIPSと仮定する。 ・2017年製のPCに搭載されたプロセッサのMIPS値を,133,920 MIPSと仮定する。 ・40日間で鍵空間の80%を探索するために必要な,2017年製のPCの台数を試算す る。 〔暗号方式の検討] X社には,危たい化した暗号技術を使っているシステムがK1システム以外にも複 数あった。そこで,Y社からの指摘を踏まえ,XH,暗号技術を含む暗号方式の社 ー18一 内標準について検討した。その結果,契約情報を業務アプリケーションではなく DBMSで暗号化してDBに保管する方式(以下,DB暗号方式という)を社内標準と Lt,X社の全システムに適用することにした。DB暗号方式の設計に当たって,X 社は次のシステム標準と要件を定義した。 システム標準1業務アプリケーションはJavaで開発する。 システム標準2 DBMSには,暗号化機能及びDBレプリケーション機能がある製品 Dを採用する。 要件1製品DのDBに保管される情報を暗号化及び復号する機能(以下,表領域暗 号化機能という)を用いて,DBに保管される契約情報を暗号化する。 要件2契約情報の暗号化及び復号に用いる鍵を,暗号モジュールを用いて保護する。 暗号モジュールとは,暗号化,BS,乱数生成,鍵管理などの機能を提供するハ ードウェア又はソフトウェアのことである。NISTが定めた| c|i4o-2は,量 号モジュールに求められるセキュリティ要件を定義したものである。 X社は,暗号モジュールに,Q社の製品Hを採用した。また,X社は,複数のサ ーバからネットワーク経由で1台の製品Hの機能を利用するために,Q社が提供し ているソフトウェア製品である耳クライアントと耳サーバも採用した。 製品Hは,140-2 Level 4の要件を満たすハードウェアの暗号モジュー VCH),サーバに取り付けられるPCI Expressカードである。製品Hは,製品H を取り付けたサーバ(以下,HSMサーバという)上で稼働するプログラム(以下, ローカルプログラムという)に対して独自のAPI(以下,APIXという)を提供し, ローカルプログラムからAPLXを呼び出すことで,暗号化,AS,乱数生成,デー タの暗号化及び復号に使用する鍵(以下,データ鍵という)の生成,データ鍵の保 管,並びに保管したデータ鍵の削除を行う。また,製品Hは,製品H,及び製品H に保管するマスタ鍵を管理するプログラム(以下,ユーティリティプログラムとい 5)を導入した専用の管理端末に対して,製品H自身に対する管理インタフェース を提供する。 K2システムにおける契約情報の暗号化機能の概要を図2に示す。図2において, Hサーバはローカルプログラムに該当する。 ー19一 aクーションmake oF tl投Hが鐘を保稼管理するファイル BBC HSMサーバ DBサーバAPI-Xの実行要求/応答 製品D PKCS#11(HTTP over TLS) SARE S(CAE r pp」vas ープログラム 図2 K2システムにおける契約情報の暗号化機能の概要 製品Hの仕様は次のとおりである。 仕様1初期化 管理端末上でユーティリティプログラムを起動し,製品H経由で鍵ストアファ イルを作成した後,マスタ鍵を生成し,製品HHを利用可能な状態にする。 ・マスタ鍵は,3人の鍵管理者が別々に管理端末から入力した256ビットの値(LA 下,部分鍵という)の排他的論理和によって生成され,製品Hのメモリ内に保 持される。製品古のメモリは,製品HHの内蔵バッテリによって駆動する。 ・部分鍵は,管理端末に接続されたICカードリーダプライタを用いて,別々の1IC カードに保管することができる。その際,鍵管理者は6 HO PINを入力し,か つ,部分鍵を記録したICカードを別々に保管する必要がある。 ・ICカードから部分鍵を読み出す際は,PINの入力が必要になる。 仕様2乱数の生成 ローカルプログラムから乱数を生成するAPI-Xを呼び出すと,製品Hが乱数を 生成し,API-Xの出力値として返す。 仕様3鍵の生成 ・ローカルプログラムが,データ鍵の識別子QAR,データ鍵IDという)をパラ メタに設定して,データ鍵生成のAPI_Xを呼び出すと,製品Hがデータ鍵を生 成する。 ・生成されたデータ鍵は,製品においてマスタ鍵で暗号化され,データ鍵TDと ともに鍵ストアファイルに保管される。 ・既に鍵ストアファイルに存在しているデータ鍵IDを指定してデータ鍵を生成し ーBi ようとすると,APIXの処理結果はエラーとなる。 仕様4暗号化又は復号 ・ローカルプログラムが,データ鍵ID,及び,暗号化又は復号を行うデータを, パラメタに設定して,暗号化又は復号のAPI-Xを呼び出す。 ・製品Hは,鍵ストアファイルから暗号化されたデータ鍵を読み出してマスタ鍵 で復号し,復号されたデータ鍵でデータの暗号化又は復号を行った後,暗号化 又は復編されたデータを,APLXの出力値として返す。データの暗号化又は復号 は製品H内で行われ,復号されたデータ鍵は,製品H内だけに存在する。 ・鍵ストアファイルに存在しないデータ鍵IDを指定して暗号化又は復号を行おう とすると,APIXの処理結果はエラーとなる。 仕様5マスタ鍵のゼロ化 製品HHには,内蔵バッテリで駆動するセンサが内蔵されている。①センサが次 のいずれかを検知すると,製品lk,メモリ上に保持されているマスタ鍵をゼロ 化するとともに,自身を使用不能で,かつ,元に戻せない状態にする。 (a2)電気的短絡(ショート)の発生などによる規定の範囲を超える電源電圧の発 生 (b)製品HHのカバーのこじ開け又は損傷 内蔵バパッテリが切れそうな場合,製品はHSMサーバを介して警告メッセージ を出力し,早期のバッテリ交換を促す。内蔵バッテリの交換手順として,MOK 生を回避する手順が提供されている。 耳クライアントとHサーバを用いると,HSMサーバとは別のサーバで稼働するプ ログラム(以下,リモートプログラムという)からネットワークを介して製品Hを 利用できる。Hクライアントは,リモートプログラムが稼働するサーバに導入され, リモートプログラムに対してPKCS#11のAPIを提供する。HサーバはHSMサーバ に導入され,TLS通信を介してHTクライアントに製品Hの機能を提供する。 HHクライアントと耳サーバの仕様は次のとおりである。 (1)APIXの実行要求 ・リモートプログラムがHクライアントを呼び出すと,Hクライアントは,受け 取ったPKCS#11のAPI呼出しをAPI-Xの実行要求に変換して,Hサーバに送 ー91一 信する。 ・API-Xの実行要求を受信したHHサーバは,APLXを呼び出し,その実行結果を応 答として是クライアントに返す。ただし,鍵生成の場合.HHクライアントは, 内部でデータ鍵IDを0から順番に採番してHサーバにAPI-Xの実行要求を送信 し,鍵生成が成功した場合にデータ鍵IDをAPI-Xの出力値としてリモートプロ グラムに返す。鍵生成が失敗した場合,HHクライアントはリモートプログラム にエラーを返す。 2)HHサーバに対する負荷分散 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ディスクからデータを読み込む際,製品lk,まず,ディスク上からデー ー22一 タを読み込んだ後,読み込まれた暗号化データを,保持しているDBデータ鍵 で復号する。 仕様E製品Dは,BLT SIR,メモリ上に保持しているDBデータ鍵をゼロ化す る。 K2システムのDB暗号方式では,製品Dの表領域暗号化機能に必要な暗号モジュ ールとして製品Hが用いられる。また,製品Dの表領域暗号化機能の仕様における DBマスタ鍵及びDBマスタ鍵ID A,それぞれ,製品Hの仕様におけるデータ鍵及 びデータ鍵IDに該当する。 K2システムのDB暗号方式におけるDBの初期化処理の概要を,図3に示す。図 3中では,製品Dの表領域暗号化機能の仕様のうち,仕様Aと仕様Bを記載してい る。 業務アプリケー ション管理者 起動コマンド 動完アメッセージ DB作成コマンド 鍵生成() データ鍵IDの採番 鍵生成(データ鍵TD 鍵生成(データ鍵TD) データ鍵2の生成, マスタ鍵によるデータ鍵の暗号化, データ鐘D及び暗号化されたデータ鍵の保存 Fogo fe OK データ鍵IDをDBマス タ鍵Dとして保存 DB作成完了メッセージ 表領域作成コマンド 乱数生成() __ie__fe--ポピーーー-ドーーデビーーー 乱数 |乱数をDBデータ鍵として保持 暗号化(DBデータ鍵,DBマスタ鍵ID) 暗号化(DBデータ鍵,DBマスタ鍵D) 暗号化CDBデータ鍵,DBマスタ鍵TD) DBマスタ鍵でDBデータ鍵を暗号化 号化されたDBデータ鐘 晴号化されたDBデータ氏| 暗号化されたDBデータ鍵コマンド の人放リメッセツジー ピー.ーーーー一ws:コマンド呼出メッセージ 嗜号化されたDBデーペーーーーー:コマンド応答メッセージ 鍵を表令域に保存コマンド(パラメタ1,パラメタ2、…) 表領域作成完了メッセージ——>:API呼出メッセージ |HAG,又は応答メッセージ ーーーーー:API応答メッセージ 注記1製品DとHHクライアント間のコマンドは,PKCS#11のAPIを意味する。 注記2 HHクライアントとHサーバ間のコマンドは,API-Xの実行要求を意味する。 注記3 HHサーバと製品H間のコマンドは,API-Xを意味する。 SED製品HHの初期化は既に行われている。 2製品量によって生成されたデータ鍵は,DBマスタ鍵として扱われる。 図3 K2システムのDB暗号方式におけるDBの初期化処理の概要 [DBサーバ及びHSMサーバの構成設計〕 X社は,K2システムのサーバ構成について,Y社に次の要件で設計を依頼した。 ・DBサーバをアクティブ・スタンバイの2台構成にする。 ・炎害対策として,製品DのDBレプリケーション機能を用いて,X社データセン タのDBからバックアップセンタのDBに,定期的にデータをコピーする。 ・HSMサーバは,K2システム以外のシステムのDBサーバを含めた全DBサーバか らも共有できるようにする。 Y社が設計したK2システムのサーバ構成を図4に示す。 X社データセンタバックアップセンタ Webアプリケーションサーバ1||Webアプリケーションサーバ2 Webアプリケーションサーバ3 業務アプリケーション業務アプリケーション業務アプリケーション ーーニューーメ 製品D-1[maps aアント3 |——||IDBサーバ2ー m3 3 4 HクライHクライ Paes oh 11 [nr]i [=a| 11 HSMサーバ3 a.LS Fーーー| ーーSea eo I ts IDBy||ラテァィル3 '|共有ストレージ1 1共有ストレージ2 ーー:通常時の通信 ーーー-:障害発生時の通信 ----->:災害対策のためのデータコピーの流れ 注記1製品D-2は,製品D-1に対するスタンバイ構成である。 注記2 DB及びDB yyには被保険者情報が保管され,DBB及びDBSには契約条件が保管される。 図4 K2システムのサーバ構成(抜粋) Y社は,K2システムにおけるDB及び表領域の作成手順を次のように設計した。 G HSMサーバ1だけを稼働させ,他のHSMサーバは停止させておく。 Gi)DBサーバ1だけを稼働させ,他のDBサーバは停止させておく。 Gi)製品D-1 EC,DBgを作成する。 (iv)製品D-1上で,DBBを作成する。 (v)製品D-1 EC,DBgwに対応する表領域1を作成する。 (vi)製品D-1上で,DBAに対応する表領域2を作成する。 (vii)全てのHSMサーバ及び全てのDBサーバを停止させる。 (vii)鍵ストアファイル1を,鍵ストアファイル2及び鍵ストアファイル3にコピー する。 (以下,省略) Y社は,DB暗号方式において,HI ITF VE RUサーバの仕様では複数シス テムのDBサーバから1台のHSMサーバを共有することはできないとXX社に伝えた。 そこで,X社が開発元のQ社に問い合わせたところ,Q HMO,来月リリースさ れる新しいバージョンの耳クライアント及びHサーバに次の機能を追加するという 回答を得た。 ・是クライアントを一意に識別する識別子(以下,廿クライアントID EWS)を設 定し,Hサーバに鍵生成を要求する際に従来のデータ鍵ID ICH ZIT 7 Yb ID を付け加えて送信する。 “HUA,耳クライアントから送信された鍵生成要求を処理する際,Hクライ アントTDと従来のデータ鍵IDを結合した,新たなデータ鍵IDをパラメタとして, BEE RO APLXを呼び出す。Hクライアントは,新たなデータ鍵IDをDBマスタ 鍵として製品Dに返す。 -複数の業務システムのDBサーバが1 BO HSMサーバを共有する場合の構成を, 5に示す。 ー26= VシステムのDBサーバ HHクライアントYロロ K2システムのDBサーバZシステムのDBサーバ HクライアントK2 ies HクライアントZロ 鍵ストアファイル マスタ鍵で暗号化された製品D-K2のDBマスタ鍵(データ鍵ID:K2.nnnnnnnn) マスタ鍵で暗号化された製品D-VのDBマスタ鍵(データ鍵ID:V.nnnnnnnn) マスタ鍵で暗号化された製品D-ZのDBマスタ鍵(データ鍵ID:Z.nnnnnnnn) 図5複数の業務システムのDBサーバが1台のHSMサーバを共有する場合の構成 [K2システムにおけるリスク対策の補完] X社は,DB暗号方式を実装したK2システムについて,契約情報の漏えいリスク を分析した。リスク分析の結果,次の対策を追加することになった。 対策1不審おアクセスがないが監視する。具体的には,週次で,業務アプリケーシ ョンのログから,業務時間外のアクセス及び大量の契約情報へのアクセスが ないかチェックし,もしあれば,その内容を確認する。 対策2 DBサーバ又はWebアプリケーションサーバのメモリダンプをファイルに出 力した場合,次の作業に対して,作業者,作業日時及び作業内容を履歴とし て残す。 ・メモリダンプのファイルへの出力 ・メモリダンプファイルへのアクセス ・メモリダンプファイルを保管した外部記憶媒体の利用 ・メモリダンプファイルの消去 K2システムの設計を終えたX社は,更改作業に向けて準備を開始した。