【全文公開・サンプル】平成29年度 秋期 情報処理安全確保支援士試験 午後Ⅱ 問2｜暗号化していたのに鍵は平文だった——情報処理安全確保支援士で学ぶDB暗号化と鍵管理の実例

この記事は、マガジン『情報処理安全確保支援士 午後問題・過去問インシデント解説』（2017年秋〜2025年秋、午後全66問）の一部です。問題文の丸暗記ではなく、「なぜその弱点が致命傷になるか」をストーリーで理解するシリーズです。WebアプリのXSS、サプライチェーンとSCADA、リモートワークのVPN、バッファオーバフロー、ランサムウェア、クラウド認証など、実務と直結するテーマを同じ体裁で収録しています。

午後問題は長文で、一度読んでも設問の意図が抜けがちです。本マガジンでは各問を事例記事化し、初出の専門用語には補足を入れ、試験で問われたポイントを後半に整理しています。独学で午後の読解に不安がある方、直前期に「対策の理由」まで復習したい方、実務のセキュリティ知識を棚卸ししたい方に向けています。

今回の全文を読んで「自分の弱点がわかった」と感じたら、続きはマガジンで一気に埋めてください。全問そろえると、年度をまたいだ出題のつながりも見えてきます（現在鋭意製作中、製作期間中は安く購入可能です）。合格のその先でも読み返せる、セキュリティの読み物として残る一冊です。まずはこの一篇を最後まで読み、マガジン購読で本編を手元にどうぞ。

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

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

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

• 主なテーマ: データベース暗号化、暗号鍵管理、HSM（ハードウェア暗号モジュール）、56bitDESの危殆化、CRYPTREC暗号リスト、耐タンパ性、しきい値秘密分散、内部者リスク

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

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

「契約情報は暗号化して保管しています」——。その一言を聞いて、私たちはつい安心します。しかし、暗号化されたデータと、それを開ける鍵が同じ場所に、しかも平文（暗号化されていない、そのまま読める状態）で置かれていたら、その暗号化に意味はあるでしょうか。情報処理安全確保支援士の午後Ⅱで出題されたこの事例は、まさにその「暗号化したつもり」の落とし穴を、生命保険会社の基幹システムを舞台に描いています。

15年前に作られた契約管理システムは、契約情報を暗号化していました。ところが、使っていた暗号アルゴリズムは今や安全とは言えない古いもので、しかも復号鍵は平文のファイルとして保管され、運用担当者が自由にアクセスできる状態でした。これは「外から破られる」より前に、「中の人が普通に読めてしまう」という、もっと根の深い問題です。

この記事を読むと、なぜ鍵長56ビットの暗号が「現実的に解読可能」と判断されるのか、暗号鍵を守るためのHSMという専用ハードウェアがどう働くのか、そして暗号化システムで本当に守るべき相手が「外部の攻撃者」だけではないことが見えてきます。受験者には頻出の鍵管理・暗号危殆化の論点が詰まっており、個人情報を大量に預かる事業の経営者には「暗号化＝安全」という思い込みを正す教材になります。

インシデントの概要

舞台は、従業員10,000名の生命保険会社であるX社です。X社では、業務担当者が契約の情報を管理するシステム——社内では「K1システム」と呼びます——を15年前から運用していました。生命保険ですから、扱う情報は極めて機微です。被保険者の氏名、生年月日、住所、電話番号、そして医療情報や健康情報まで。これらに契約条件を合わせて「契約情報」と呼び、漏えい防止を会社の最優先課題に掲げていました。

K1システムは、X社のデータセンタに置かれ、契約情報を保管するDBサーバ、業務アプリケーションが動くWebアプリケーションサーバ、利用者IDとパスワードを保管するLDAPサーバ（ディレクトリ情報を管理する仕組み）、そしてリバースプロキシ（利用者とサーバの間に立って通信を中継する装置）として動く認証サーバから成っていました。

運用の役割分担も、それなりに整っているように見えました。システムの起動停止やバックアップといった定型作業はオペレータが、OSやミドルウェアの設定変更はシステム管理者が、DBMSや業務アプリの設定変更は業務アプリケーション管理者が担当する。権限も、それぞれの担当範囲に応じて分けられていました。そして契約情報は、業務アプリケーションが共通鍵暗号方式（暗号化と復号に同じ鍵を使う方式）で暗号化し、DBに保管していました。

外見上は、相応にセキュリティを意識したシステムです。しかしX社は、このK1システムを更改し、契約者自身がインターネット経由でPCやスマートフォンから契約情報を参照・更新できる新システム（K2システム）を計画していました。インターネットに開く以上、暗号化の弱点はそのまま致命傷になりかねません。X社は、システム開発ベンダのY社に要件定義の支援を依頼します。そして、Y社がK1システムの仕様を確認したことから、「暗号化したつもり」の正体が明るみに出るのです。

何が起きたのか

Y社がK1システムの暗号化の仕組みを調べると、二つの重大な問題が浮かび上がりました。

第一の問題は、暗号アルゴリズムそのものでした。契約情報の暗号化には、鍵長56ビットのDESアルゴリズム（社内では「56bitDES」と呼びます）が使われていたのです。DESはかつて広く使われた暗号方式ですが、鍵が短すぎて、現在では総当たり（あらゆる鍵を片端から試す攻撃）で破られてしまいます。Y社は、鍵長256ビットのAESアルゴリズムへの変更を求めました。

Y社が示した根拠は、説得力のあるものでした。FISC（金融情報システムセンター）の安全対策基準——日本国内で金融機関などがよりどころとすべき共通の基準です——では、CRYPTREC暗号リスト（電子政府における調達のために参照すべき暗号のリスト）に記載された暗号技術を採用するのが望ましいとされており、56bitDESは推奨されていません。さらにY社は、具体的な数字で「もう破られる」ことを突きつけます。1998年に開かれたDES解読コンテストでは、4万台のPCを使って56bitDESの全鍵空間の80%を、わずか40日で解読しました。解読にかかる時間はプロセッサの計算能力（MIPS値）に反比例します。1998年当時のPCが540MIPSだったのに対し、2017年のPCは133,920MIPS——およそ248倍です。つまり、当時4万台でやっていたことが、いまやわずか162台で同じ40日でできてしまう。攻撃者が現実的に調達可能な台数です。暗号は、時間の経過とともに必ず弱くなる。56bitDESは、すでに「危殆化」（暗号の安全性が実用上失われた状態）していました。

しかし、より深刻だったのは第二の問題です。契約情報の暗号化・復号に用いる鍵が、平文のままファイルに保管され、しかもオペレータとシステム管理者にそのファイルへのアクセス権が付与されていたのです。

ここに、この事例の核心があります。考えてみてください。暗号化されたデータと、それを開ける鍵が、同じ運用担当者の手の届く場所にある。これは、頑丈な金庫を作り、その扉に鍵を貼り付けて置いているようなものです。オペレータやシステム管理者は、悪意がなくても、その気になれば暗号化された契約情報を鍵で復号し、中身を読み取り、持ち出すことができてしまう。外部の攻撃者がDESを解読するより、はるかに簡単で確実な「正面玄関」が、内部に開いていたのです。

X社が守りたかったのは契約情報の漏えい防止でした。それなのに、最も信頼して権限を与えているはずの内部の運用担当者に対して、契約情報は無防備だった。「暗号化している」という事実は、この内部者リスクの前ではほとんど意味をなしていませんでした。

X社は、この指摘を重く受け止めます。調べてみれば、危殆化した暗号技術を使うシステムは、K1以外にも社内に複数ありました。そこでX社は、対症療法ではなく、社内標準そのものを作り直すことにします。新しい方針は明快でした。契約情報の暗号化を、業務アプリケーションではなくDBMS（データベース管理システム）の側で行うこと——これを「DB暗号方式」と呼び、全システムに適用する。そして、暗号化・復号に使う鍵を、ただのファイルではなく専用のハードウェア（暗号モジュール）で保護することにしたのです。

採用されたのは、Q社のハードウェア暗号モジュール「製品H」でした。製品Hは、FIPS 140-2 Level 4（NISTが定めた暗号モジュールのセキュリティ要件の、最も厳格な水準）を満たす、サーバに取り付けるPCI Expressカードです。鍵は製品Hの内部だけで扱われ、外に平文で出てこない。データを暗号化・復号する処理も製品Hの中で完結します。さらに製品Hには、内蔵バッテリで動くセンサが組み込まれていて、カバーをこじ開けようとしたり、規定を超える電源電圧をかけたりすると、それを検知して内部のマスタ鍵を瞬時にゼロ化（消去）し、自分自身を二度と使えない状態にする仕組みまで備わっていました。物理的にこじ開けて鍵を盗もうとしても、開けた瞬間に鍵は消える。これが「耐タンパ性」（物理的な攻撃に対して内部の秘密を守る性質）です。

マスタ鍵（すべてのデータ鍵を暗号化する大もとの鍵）の作り方にも、念入りな工夫がありました。マスタ鍵は、3人の鍵管理者がそれぞれ別々に入力した256ビットの値（部分鍵）の排他的論理和（XOR。複数の値を特定の規則で混ぜ合わせる演算）によって生成されます。つまり、1人や2人が結託しても、全員分の部分鍵がそろわなければマスタ鍵は復元できない。「中の人」一人の暴走を、鍵の作り方そのもので封じる設計です。X社は、暗号化の弱点を、暗号の強度だけでなく、鍵を扱う人と仕組みの両面から作り直そうとしました。

インシデントの流れを図で見る

原因はどこにあったのか

この事例の原因は、「暗号化を導入したこと」で安心してしまい、その質と運用を問い直さなかった点に集約されます。技術・運用・組織の三層で見ていきます。

技術的な原因は二つです。一つは、暗号アルゴリズムの危殆化を放置していたこと。56bitDESは15年前には通用したかもしれませんが、計算能力の向上により、いまや現実的なコストで解読できます。暗号は導入時に正しくても、時間とともに必ず弱くなる——この時間軸の視点が欠けていました。もう一つは、鍵の保管方法です。暗号化と復号に使う鍵を平文ファイルで持つことは、暗号化の効果を根本から無効化します。鍵こそが守るべき最重要資産だという原則が、運用に反映されていませんでした。

運用上の原因は、権限設計と鍵の置き場所のミスマッチです。オペレータやシステム管理者には、業務上必要なOS・ミドルウェアの操作権限が与えられていました。それ自体は妥当です。問題は、その権限の及ぶ場所に、契約情報の復号鍵が平文で置かれていたこと。担当者の権限と、守るべき秘密の置き場所が分離されていなかったため、本来「データを管理する人」が「データの中身を読める人」になってしまっていました。

組織的な原因は、内部者リスクの軽視です。X社は外部からの漏えいを警戒していましたが、最も強い権限を持つ内部者が脅威になり得るという視点が弱かった。性善説で運用が回っているうちは問題が表面化しませんが、ひとたび悪意や過失が生じれば、内部者は最短距離で情報にアクセスできます。この事例の再設計が「内部者（特にDBやサーバの管理者）にも中身を見せない」ことを目標に据えたのは、その反省の表れです。

重要キーワードと関連知識

暗号の危殆化と鍵長・CRYPTREC暗号リスト

暗号の危殆化とは、暗号アルゴリズムや鍵が、計算能力の向上や新たな攻撃手法によって、実用上の安全性を失った状態です。今回の56bitDESは、鍵長が短いために総当たり攻撃で破られる典型例でした。

鍵長は安全性の目安ですが、絶対ではありません。攻撃側の計算能力が上がれば、同じ鍵長でも破られやすくなります。だからこそ、信頼できる第三者の評価に従うことが重要です。日本では、CRYPTREC（Cryptography Research and Evaluation Committees。電子政府推奨暗号を評価・選定する活動）が暗号リストを公開しており、金融機関などがよりどころとするFISCの安全対策基準も、これに沿った暗号の採用を求めています。

試験では、空欄補充でFISC（解答a）とCRYPTREC（解答b）が問われ、さらに「2017年製PCなら何台で解読できるか」を計算させました。MIPS値が248倍（133,920÷540）になったので、1998年に4万台必要だった解読は、40000÷248＝161.3、切り上げて162台で可能になります（解答）。「鍵長が同じでも時間とともに安全性は下がる」という危殆化の本質を、数字で体感させる良問でした。

表領域（テーブルスペース）と表領域暗号化

表領域（テーブルスペース）は、DBMSがデータをディスク上に置くときの論理的な置き場の単位です。1つのデータベースの中に、用途や性能の違いに応じて複数の表領域を切り分けることがよくあります。たとえば「契約データ用の表領域」「索引（インデックス）用の表領域」のように分け、それぞれ別のディスク領域やファイルに対応させます。利用者から見える「表（テーブル）」は、この表領域の上に作られます。

日常のイメージで言えば、倉庫（データベース）の中に「A棚・B棚」（表領域）があり、実際の箱（表の行データ）が棚ごとに収められている、と考えると近いです。表領域という言葉は、主にOracleやDB2などでよく使われる用語ですが、本問では「どの単位で暗号化の鍵を割り当てるか」を示すために重要です。

本問の表領域暗号化は、表領域を新しく作る（または暗号化付きで作る）タイミングで、その表領域に専用のDBデータ鍵を割り当て、以降その表領域に書き込まれる行データを自動的に暗号化・復号する方式です。業務アプリケーションが自前で暗号化ルーチンを書く必要がなく、INSERTやSELECTのたびに製品Dが透過的に処理します。K1ではアプリが暗号化していたのに対し、K2では保存の単位（表領域）と暗号化の単位がDB側で一致するのがポイントです。

試験の設問3では、「DBα用の表領域1を作る」といった手順が出てきます。ここでいう表領域1は、データベースDBαの中に作る1つ目の暗号化対象領域の名前です。表領域を作る操作の裏では、HSM（製品H）にDBデータ鍵の生成を依頼し、できた鍵をDBマスタ鍵で包んで鍵ストアに保存する、という流れが動きます。だから「表領域」は単なるストレージの話ではなく、どのタイミングでDBデータ鍵が生まれるかを理解するためのキーワードです。

実務では、クラウドDBの「透過的データ暗号化（TDE）」や、エンタープライズDBの表領域単位の暗号化と同族の考え方です。アプリ改修を抑えつつ保存データを守れる一方、鍵管理（今回ならHSM）との連携設計が成否を分けます。

HSM（ハードウェア暗号モジュール）とFIPS 140-2

HSM（Hardware Security Module）は、暗号化・復号・乱数生成・鍵管理などを専用ハードウェアの中で安全に行う装置です。今回の製品Hがこれにあたります。鍵をHSMの内部だけで扱い、外部に平文で出さないことで、「鍵を盗まれる」リスクを大きく下げます。

その安全性の水準を示すのが、NISTが定めたFIPS 140-2（解答c＝FIPS）です。Level 1から4まであり、数字が大きいほど厳格です。製品HはLevel 4を満たし、物理的な侵入に対する強固な防御を備えています。

実務では、認証局の秘密鍵やデータベースの暗号鍵など、特に重要な鍵をHSMで保護します。クラウドでも、HSMサービスや鍵管理サービス（KMS）として同等の仕組みが提供されています。試験では、FIPS 140-2という用語と、HSMが鍵をどう守るか（鍵が外に出ない、処理が内部で完結する）を理解しているかが問われました。

耐タンパ性とマスタ鍵のゼロ化

耐タンパ性（タンパーレジスタンス）は、機器を物理的にこじ開けたり、異常な電圧をかけたりする攻撃に対して、内部の秘密情報を守る性質です（設問2(4)の解答「耐タンパ性」、7字）。

製品Hは、内蔵バッテリで動くセンサで、カバーのこじ開け・損傷（仕様5の(b)）や、ショートなどによる規定を超える電源電圧の発生（仕様5の(a)）を検知します。検知すると、メモリ上のマスタ鍵を即座にゼロ化し、自分自身を使用不能で元に戻せない状態にします。鍵を盗もうとして開けた瞬間に、鍵が消える。これが耐タンパ性の具体的な働きです。

この性質ゆえに、製品Hの運搬時には静電気防止シートで覆うことが運用規程で定められていました。静電気の放電が規定を超える電源電圧を生じさせれば（事象）、センサがそれを検知して製品Hを使用不能で戻せない状態にしてしまう（機能）からです（設問2(5)）。せっかくの防御機能が、運搬中の事故で誤作動すれば、正規の鍵まで失われてしまう。耐タンパ性は強力なぶん、扱いに注意が要るということです。

しきい値方式による鍵の分割（部分鍵とXOR）

マスタ鍵を1人の管理者に握らせると、その1人が暴走したり、買収されたりしたときに防げません。そこで製品Hは、マスタ鍵を3人の鍵管理者が別々に入力する256ビットの部分鍵の排他的論理和（XOR）で生成します。全員の部分鍵がそろわなければ、マスタ鍵は復元できません。

設問2(2)は、この仕様1の効果を「1人の鍵管理者が三つの部分鍵を入力し、3枚のICカードで管理する場合」と比べて問うものでした。正解は「単独の鍵管理者ではマスタ鍵を復元できない」。1人が全部分鍵を持っていれば、その1人が裏切ればおしまいですが、3人に分ければ、単独犯では鍵を再現できなくなります。これは権限の分離（職務分掌）を、鍵そのものの構造で実現する考え方です。

設問2(3)は、ICカードに記録した部分鍵がいつ必要になるかを問いました。正解は「製品Hを交換した場合（場合）」に「マスタ鍵を復元するため（目的）」です。製品Hが故障・寿命などで交換されると、メモリ上のマスタ鍵は失われます。そのとき、ICカードに保管しておいた部分鍵を持ち寄って、新しい製品Hにマスタ鍵を復元する必要があるのです。

データ鍵・マスタ鍵による階層的な鍵管理

製品Hの鍵管理は、二段構えになっています。実際にデータを暗号化・復号するのが「データ鍵」、そのデータ鍵を暗号化して保護するのが「マスタ鍵」です。データ鍵はマスタ鍵で暗号化され、データ鍵IDとともに鍵ストアファイルに保管されます。復号が必要なときだけ、製品Hの内部でデータ鍵をマスタ鍵で復号して使い、処理が終われば製品H内だけにとどめます。

一般論として、この「鍵で鍵を守る」階層構造は、鍵管理の定石です。大量のデータ鍵を個別に厳重管理するのは大変ですが、それらをまとめてマスタ鍵で守れば、最も厳重に守るべきはマスタ鍵1つに集約できます。今回のK2システムでは、製品Dの「DBマスタ鍵」が製品Hの「データ鍵」に該当する、という入れ子の対応関係も理解のポイントでした。

試験で問われていたポイント

この問題は、暗号の危殆化、鍵管理、HSMの仕組み、複数システムでの鍵共有、そして内部者リスクへの対策まで、暗号化システムの設計を一気通貫で問う構成でした。公式の解答例に沿って、各設問の考え方を整理します。

設問1：暗号の危殆化と鍵管理の問題

(1)の空欄は、a＝FISC（英字4字）、b＝CRYPTREC（英字8字）。金融機関がよりどころとする安全対策基準を出すのがFISC、推奨暗号リストを出すのがCRYPTRECです。

(2)は計算問題。MIPS値が133,920÷540＝248倍になったので、1998年に4万台で40日かかった解読は、40000÷248≒161.3、切り上げて162台で同じ40日に達します。「鍵長が同じでも、計算能力の向上で安全性は下がる」ことを数値で示す設問でした。

(3)は記述式で、指摘2（鍵が平文でファイル保管され、運用担当者にアクセス権がある状態）によって生じるリスクを問うもの。正解は「オペレータ及びシステム管理者が、暗号化された契約情報を暗号化・復号に用いられる鍵を用いて復号し、取得するリスク」。誰が（オペレータ・システム管理者）、どうやって（鍵で復号して）、何を（契約情報を取得）するか、を具体的に書けるかがポイントです。

設問2：HSMの仕組みと耐タンパ性

(1)はc＝FIPS。NISTのFIPS 140-2が暗号モジュールのセキュリティ要件を定めます。

(2)は、部分鍵を3人で分ける仕様1の効果で「単独の鍵管理者ではマスタ鍵を復元できない」。職務分掌を鍵の構造で実現する発想です。

(3)は、ICカードの部分鍵が必要になる場面で「製品Hを交換した場合（場合）／マスタ鍵を復元するため（目的）」。製品H交換時にマスタ鍵を再現するための保険、という位置づけを読み取ります。

(4)は、こじ開け検知でマスタ鍵をゼロ化する性質で「耐タンパ性」。(5)は、静電気防止シートで運搬する理由で、事象は「静電気の放電による規定の範囲を超える電源電圧の発生」、機能は「事象をセンサが検知し、製品H自身を使用不能で戻せない状態にする」。耐タンパ性の防御が、運搬中の静電気で誤作動しないようにする配慮だと読み取れるかが問われました。

設問3：複数システムでの鍵共有とデータ鍵IDの重複

(1)は、DB・表領域の作成手順で、本来HSMサーバ1台で行うべきところを、HSMサーバ1と2の両方を稼働させてしまった場合にエラーとなる手順を問うものです。ここがこの問題の最難関でした。

ポイントは、Hクライアントがデータ鍵IDを「0から順番に採番する」ことと、負荷分散で「ラウンドロビン方式で複数のHサーバに振り分ける」ことです。HSMサーバを2台動かすと、鍵生成の要求が両方に交互に振り分けられ、DBマスタ鍵がHSMサーバ1の鍵ストアファイルに作られたり、HSMサーバ2のほうに作られたりと、ばらけてしまいます。手順(iii)(iv)でDBαとDBβのDBマスタ鍵を作り、(v)でDBαに対応する表領域1を作ろうとすると、表領域作成時にはDBデータ鍵をDBマスタ鍵で暗号化する処理が必要です（暗号化API-Xの呼び出し）。しかし、そのときに使うべきDBαのDBマスタ鍵が、振り分けの都合で別のHSMサーバ（鍵ストアファイル2）側にあって、いま処理しているHSMサーバの鍵ストアファイルには存在しない、という事態が起こり得ます。

正解は、エラーとなる手順が「(v)」、API-Xのコマンドが「暗号化(DBαのDBデータ鍵，DBαのDBマスタ鍵ID)」、エラーの原因が「DBαのDBマスタ鍵が鍵ストアファイル2に存在しないこと」。仕様4で「鍵ストアファイルに存在しないデータ鍵IDを指定するとエラー」と決まっているため、鍵のある場所と処理する場所がずれるとエラーになる、という論理です。だからこそ手順(i)で「HSMサーバ1だけを稼働させる」と決められていたわけです。

(2)は、複数システムが1台のHSMサーバを共有するためにHクライアントIDを付け加える機能の意義。これがないと何が起きるかを問い、正解は「複数のHクライアントが送信したデータ鍵IDが重複した場合」。各Hクライアントが独立に0から採番すると、別システムのデータ鍵IDがぶつかってしまう。HクライアントIDを前置することで、IDの一意性を保つわけです。

設問4：内部者リスクへの対策

(1)は、対策1（業務アプリのログを週次で監視し、業務時間外や大量アクセスをチェック）が、誰のどんなリスクへの対策かを問うもの。正解は「業務担当者及び契約者が業務アプリケーションを利用して持ち出すリスク」。正規の利用者が、正規の機能を使って不正に情報を持ち出す行為を、ログ監視で検知するという発想です。

(2)は、対策2（メモリダンプの出力・アクセス・媒体利用・消去の履歴を残す）が対象とするリスク。正解は「オペレータ及びシステム管理者が、メモリダンプから平文の契約情報を読み出し、持ち出すリスク」。DB暗号化で守っても、処理中の契約情報はメモリ上では平文です。メモリダンプ（メモリの内容をファイルに書き出すこと）を取れば、そこから平文を読み取れてしまう。だから、ダンプ操作そのものを履歴として残し、抑止と追跡を効かせるのです。

この問題全体を解くうえで忘れてはいけない視点

受験者として押さえるべきは、「暗号化した」で思考を止めないことです。この問題は一貫して、暗号アルゴリズムの強度（危殆化）、鍵の保管場所（平文ファイルか、HSMか）、鍵を扱う人の権限（単独か、分割か）、そして処理中の平文（メモリダンプ）まで、暗号化の「周辺」に潜むリスクを問うています。守るべき相手が外部の攻撃者だけでなく、強い権限を持つ内部者でもあるという視点を持てるかが、合否を分けます。

経営者が読み取るべきポイント

この事例の本質は、「対策を入れたかどうか」ではなく「その対策が本当に効いているか」を問い直す姿勢にあります。経営者・管理職の視点で読むと、いくつもの示唆が浮かびます。

第一に、暗号化は「入れて終わり」ではないこと。暗号アルゴリズムは時間とともに必ず弱くなります。導入時に最新でも、数年後には危殆化し得る。暗号方式やシステムを定期的に棚卸しし、危殆化したものを計画的に更新する仕組み——いわば暗号の保守——を経営として持つ必要があります。

第二に、最大の脅威は外ではなく内かもしれないこと。最も強い権限を持つ運用担当者が、その気になれば最短距離で情報にアクセスできる。性善説に頼った運用は、ひとたび悪意や過失が生じれば崩れます。鍵を3人に分ける、管理者にも中身を見せない暗号化を設計する、メモリダンプの操作履歴を残す——こうした内部統制は、従業員を疑うためではなく、組織と従業員双方を守るための投資です。

第三に、鍵管理は専用の仕組みに投資する価値があること。HSMのような専用ハードウェアは安価ではありませんが、鍵が漏れれば暗号化のすべてが無意味になります。守るべき情報の価値（生命保険なら極めて機微な個人情報）に見合った鍵管理コストを、リスクとの比較で判断するのが経営の役割です。

第四に、インターネットに開く前にこそ設計を見直すべきこと。X社は、社内に閉じたK1のままなら問題が表面化しなかったかもしれません。しかし契約者がインターネットからアクセスするK2に踏み出すなら、内側の弱点は外側の脅威に直結します。サービスの利便性を広げる経営判断は、セキュリティ設計の見直しとセットでなければなりません。

再発防止策

技術・運用・組織の三つの観点で整理します。

技術面では、危殆化した暗号（56bitDESなど）を、CRYPTREC暗号リストに沿った強い暗号（AES-256など）へ更新すること。暗号化・復号に使う鍵を平文ファイルで持たず、HSMなどの暗号モジュールで保護すること。鍵はデータ鍵とマスタ鍵の階層構造で管理し、マスタ鍵は耐タンパ性のあるハードウェアで守ることです。

運用面では、暗号方式とシステムを定期的に棚卸しし、危殆化を検知して計画的に更新する保守プロセスを回すこと。鍵管理者を複数に分け、単独ではマスタ鍵を復元できないようにすること。製品Hの交換に備えて部分鍵をICカードで分散保管し、運搬時の耐タンパ性の誤作動（静電気など）にも配慮することです。

組織面では、運用担当者の権限と、復号鍵・契約情報の置き場所を分離すること。正規利用者による持ち出しを業務アプリのログ監視で検知し、メモリダンプなど平文に触れ得る操作には履歴を残すこと。そして、守るべき情報の価値に見合った鍵管理への投資を、経営判断として明確に位置づけることです。

受験対策としての学び

この問題から、次に似た問題を解くための着眼点を三つ持ち帰ってください。

一つ目は、暗号化が出てきたら「アルゴリズムの強度」「鍵の保管場所」「鍵を扱う人」の三点をセットで点検すること。暗号化していても、鍵が平文で運用者の手元にあれば守れません。危殆化（CRYPTREC・FISC・鍵長と計算能力の関係）は記述・計算の両方で問われやすい頻出論点です。

二つ目は、HSMと鍵管理の用語を整理しておくこと。FIPS 140-2、耐タンパ性、マスタ鍵とデータ鍵の階層、部分鍵の分割（職務分掌の実現）といった言葉を、それぞれ「何を守るための仕組みか」とセットで説明できるようにしておくと、空欄補充も記述も取りこぼしにくくなります。

三つ目は、「内部者リスク」と「処理中の平文」に敏感になること。DB暗号化で保存時のデータは守れても、メモリ上では平文に戻ります。メモリダンプ、業務アプリ経由の持ち出しといった内部者の経路を問う設問は、午後問題で繰り返し登場します。「保存」「通信」「処理（メモリ）」のどの段階の話かを切り分けて考える癖をつけましょう。

まとめ

この事例が教えてくれるのは、「暗号化しています」という言葉が、それだけでは何の保証にもならないということです。X社のK1システムは確かに暗号化していました。しかし、その暗号は危殆化した56bitDESであり、復号鍵は平文ファイルとして運用担当者の手の届く場所に置かれていました。金庫を作って、扉に鍵を貼っていたのと同じです。

暗号アルゴリズムをCRYPTREC準拠の強いものへ更新する。鍵を平文で持たず、耐タンパ性のあるHSMで守る。マスタ鍵を複数人に分割し、単独では復元できないようにする。そして、保存時だけでなく処理中の平文（メモリダンプ）や正規利用者の持ち出しにも目を配る——この「アルゴリズム・鍵・人・運用」の四点を一体で設計することが、情報処理安全確保支援士に問われている視点です。暗号化は導入がゴールではなく、危殆化と内部者リスクに抗い続ける終わりのない運用です。この事例は、その当たり前を、生命保険という最も機微な情報を扱う現場を通して、静かに突きつけています。

参考・出典

• 平成29年度 秋期 情報処理安全確保支援士試験 午後Ⅱ 問2（独立行政法人情報処理推進機構：IPA）

• 平成29年度 秋期 情報処理安全確保支援士試験 午後Ⅱ 解答例（IPA）

• IPA 情報処理安全確保支援士試験 過去問題 公開ページ

この記事は生成AI記事をもとに私自身がハルシネーションに注意しています。少しでもお役に立てば幸いですが間違いや、気に入った点があれば「スキ」や、コメントをいただければ嬉しいです。

次に読む

• 前の問題: 平成29年度 秋期 午後Ⅱ 問1｜出荷時のパスワードが残ったネットワークカメラ
• 次の問題: 平成30年度 秋期 午後Ⅰ 問1｜たった一行のコピーが乗っ取りを招く
• 全70問の一覧・テーマ別索引