平成23年度 秋期に実施された情報処理安全確保支援士試験
午後Ⅱの全2問（記述式）の全設問に，運営者が独自に書いた解説を付けています。事例本文のどこが根拠になるかを示し，IPA の解答例・採点講評と並べています。
問1 医療情報システムの要件定義と設計
医療情報システムの要件定義と設計に関する次の記述を読んで，設問1〜4に答えよ。
Z病院は，病床数300の私立総合病院である。Z病院では，今年度，医療のサービス向上を目的に，医療情報システムの導入を決定した。今回導入する医療情報システムでは，診療録（カルテと呼ばれる）及び診療諸記録の両者を含む種々の医療情報を電子化する（以下，電子化された医療情報を電子カルテという）。
医療情報システムでは，次の機能を実現する。
(1) 医療情報の記録，更新，保管，検索の機能（以下，これらの機能を電子カルテ機能という） (2) 検査や注射などの処置や薬の処方などの医師からの指示を担当部門に伝達する機能 (3) 診療費の会計処理などを行う医事会計システムに情報を伝達する機能 Z病院では，プロジェクトチーム（以下，Zチームという）を組織した。ZチームにはITに詳しいF医師がリーダとして，病院内組織から医師，看護師，薬剤師，医療事務員など医療従業者の職種ごとの代表者がメンバとして，また，医療情報システムの導入経験が豊富なコンサルタントのM氏がアドバイザとして，それぞれ参画することになった。
〔Z病院の情報セキュリティと個人情報保護に関する基本方針〕
Z病院の情報セキュリティ基本方針を図1に示す。
図1 Z病院の情報セキュリティ基本方針
カルテは，取扱いに注意が必要な個人情報を含み，機密性や完全性の確保が必要である上，災害時などの非常時も含め，医療を提供するときには参照が必要なので，可用性の確保も重要である。
Z病院は個人情報取扱事業者であり，図2に示す個人情報保護方針を策定している。
図2 Z病院の個人情報保護方針
〔現行のカルテに関する課題〕
Z病院では，紙のカルテは患者ごと，診療科ごとに作成され，診療科ごとに患者単位でファイリングされている。医師は，診療を担当する患者のカルテだけを参照する。担当する患者が他診療科で診療を受ける場合は，その診療科から要求があれば患者のカルテをその診療科に貸し出すことができる。各診療科において，他診療科へのカルテの貸出しは，各診療科の医療事務員が帳簿に付けて管理している。
しかし，これには，診療上の観点から認識されている問題点が幾つかある。大量にファイリングされているカルテを取り出す際に取り違えて，別のカルテが医師に届くことがある。患者が他診療科も受診している場合には，検査や投薬の重複が発生しないようにその診療科のカルテも参照するが，その診療科のカルテが届くまで，患者を長時間待たせる事態も発生している。また，患者が複数の診療科で受診しているかどうかは，患者本人の申告がないと分からない。さらに，セキュリティの観点から認識されている問題点としては，カルテを物理的にZ病院内で持ち回るので，紛失や情報漏えいの可能性が挙げられている。
電子カルテを導入することによってこれらの問題点を解決することが，Zチームの大きな目標である。紙のカルテは，電子カルテの導入後，スキャナで画像データ化を進め，医療情報システムで参照できるようにしたいと考えている。
〔電子カルテの保存に関する要件〕
カルテは医師法によって5年間の保存が義務付けられている。その電子媒体による保存も，厚生労働省の通知によって認められている。Zチームは，医療情報システムの要件を定義するために，関連する法令や，厚生労働省から公表されている“医療情報システムの安全管理に関するガイドライン”をはじめとする，省庁や業界団体による各種ガイドラインなどを調査した。
厚生労働省の通知では，カルテを電子保存する場合，真正性，見読性，保存性の確保が必要とされている。特に，カルテの真正性とは，正当な者が記録し，確認された情報に関して，記録の責任の所在が明確であり，かつ，故意又は過失による，虚偽入力又は誤入力，書換え，消去及び混同が防止されていることである。
そのため，電子カルテに対する全ての操作の前には，利用者の識別と認証が必要である。
また，電子カルテの入力などには，記録に対する責任の所在を明確にするため，正当な入力，追記，書換え，消去の後，医師による電子カルテへの記録の“確定”登録という操作が必要である。ただし，研修中の医師である研修医による診療内容の記録は，最終的な確定とせず，“仮”登録として記録する。
紙のカルテの場合は，書き換えられたとしても書換えの痕跡は保存され，発見されやすいが，単純に電子化した場合は，このような特性は失われるので，何らかの対策が必要である。
Z病院では，初診からの一連のカルテを診療終了後5年間保存する運用をしており，電子カルテの保存についても，同じ運用を続けることにした。
Zチームは，電子カルテの保存について，要件の検討を行った。厚生労働省などのガイドラインでは，必須対策と推奨対策が示されている。Z病院の情報セキュリティ基本方針及び個人情報保護方針に照らし合わせ，M氏のアドバイスを得ながら，電子カルテ機能の要件を整理し，表1にまとめた。
要件を踏まえ，具体的な実現方式の検討を行うとともに，導入するソフトウェアパッケージ（以下，パッケージという）を選定して，電子カルテの保存に関する運用管理規程の策定を行い，医療情報システムを構築することにした。
表1 Zチームが作成した電子カルテ機能の要件
〔医療情報システムのユースケース〕
Zチームは，現行業務を基に医療情報システムのユースケースを検討した。検討結果を表2に示す。
表2 医療情報システムのユースケース（抜粋）
〔医療情報システムで利用するICカードについての認証方式の検討〕
医療情報システムの利用者認証の方式は，要件に基づいて，パスワード及びICカードによる2要素認証とする。医療情報システムを利用するZ病院の医療従業者には，利用者認証に用いるICカードを配布する。配布されるICカードには，個人ごとにHPKIの認証局に登録して発行される電子証明書及び対応する秘密鍵が格納される。医師の電子証明書には，医師資格を保有していることを示す情報が含まれ，医師のICカードは利用者認証に加え，電子カルテや紹介状へのディジタル署名の付与にも用いることができる。ICカードは，通常，申請から入手するまで1週間ほど掛かる。
Zチームでは，ICカードの携帯を忘れた利用者に一時貸与するためや，破壊・紛失による再発行までの間に一時貸与するための予備ICカードを常時確保することにした。予備ICカードは，医療情報システムの利用者設定機能を用いて，臨時利用者属性を付けて一時的な利用者認証に利用することができる。臨時利用者属性のアクセス権限は，一部の機能に利用制限があるが，医療行為には支障を来さないように権限を設定する。予備ICカードで記録を“確定”登録することはできない。
〔医療情報システムのアクセス制御についての検討〕
紙のカルテは，医療事務員がキャビネットから取り出して，医師に渡している。電子カルテになると，システム設計によっては，担当外の患者の電子カルテの参照及び職務権限外のアクセスも容易にできるようになるので，アクセス制御の構築とアクセス証跡の保存が重要になる。
Zチームでは，アクセス制御についての検討を進めるために，現行のカルテをモデル化し，電子カルテの概念データモデル案を作成した。電子カルテの概念データモデル案を図3に示す。
図3 電子カルテの概念データモデル案（抜粋）
Zチームは，医療情報システムでの電子カルテに対するアクセス制御について，電子カルテの概念データモデル案に基づいて，ユースケースや課題を参照しながら検討を行った。
アクセス権限の設定については，アクセス制御の要件に基づいて，医療情報システムの利用者を職種などの観点で整理したアクタ種別と，電子カルテのデータ項目の組合せで制御する必要があるとの結論に至った。
各アクタ種別では，データ項目の追記（A），データ項目の参照（R），データ項目の書換え（U），データ項目の消去（D），データ項目の“確定”登録（F），電子カルテの印刷（P）のうちどのアクセス権限が必要かを検討した。再診の外来患者の電子カルテのデータ項目に対する，アクタ種別ごとのアクセス制御案を表3に示す。
表3 再診の外来患者の電子カルテのデータ項目に対する，アクタ種別ごとのアクセス制御案（抜粋）
表3によって，アクタ種別ごとのアクセス制御の整理はできたが，これで十分であるか検討したところ，傷病名によっては，患者又は家族などの意向によって，診療記録の記載内容の開示を“特定の診療科の医師に限定する”という要件のあることが判明した。これに対応するためには，②アクタ種別ごとではない別のアクセス制御の併用が必要である と判断した。
次に，アクセス証跡の保存について検討し，表1に示された要件を満たす実装方式を具体化した。
〔医療情報システムにおける真正性についての検討〕
Zチームは，電子カルテのデータ項目について，真正性を保証する仕組みとその実現手段に関して，どのような選択肢があるかを調べるために，まず，市場の医療情報システムのパッケージを調査した。
市場のパッケージでは，電子カルテのデータ項目にカーソルを置いた際に，③過去に確定した全ての記録を表示する方式 など，様々な方式が採られている。Zチームでは，後のパッケージ選定作業の際に，複数のパッケージの使い勝手を医療従業者の意見を聞きながら評価することにした。
次に，Zチームは，電子カルテの“確定”登録の際に表1のHPKIにおいて発行された電子証明書を用いて付与するディジタル署名について検討を行った。その結果，ディジタル署名は，電子カルテのデータ項目ごとに付与することにした。ただし，電子証明書の有効期限は約2年となっている。
法令に基づくカルテの保存要件を満たすために，タイムスタンプを付与することが要件になっている。Zチームが検討した医療情報システムのタイムスタンプ付与の仕組みの概要を図4に示す。
M氏は，タイムスタンプのサービスには，有効期限が10年など長期のものもあるが，10年以上継続して受診する患者がいるので，図4に示したタイムスタンプ付与の仕組みでは不十分であると指摘し，④このような患者の初診からの電子カルテの真正性を保証するために図4の仕組みを改善する案 を提案した。
図4 タイムスタンプ付与の仕組みの概要
F医師とM氏は，電子カルテの真正性を保証する仕組みについて漏れがないか検証作業を行った。次は，その際の会話である。
F医師：以上で，電子カルテの真正性を保証する仕組みについては，一通りの検討ができましたね。 M氏 ：そうですね。ただ一部未検討の点も残っていると思います。電子カルテの改ざんを検知するための前提となる仕組みについては検討済ですが，実際に検知する仕組みなどについて検討する必要があります。 F医師：なるほど，改ざんが発生した場合に，実際にそれを検知できないといけないですね。 M氏 ：加えて，“確定”登録が行われた電子カルテが改ざんされた場合に，単に検知するだけではなくて，⑤その後も，正しい電子カルテを用いて医療を提供する必要があります 。 F医師：それでは，その方法を引き続き検討しましょう。 Zチームでは，電子カルテの真正性を保証する仕組みに関する基本設計の検討を済ませ，パッケージ選定を行った。
〔Z病院の医療情報システムのシステム構成の検討〕
Zチームは，医療情報システムの稼働環境とシステム構成を検討した。医療情報システムのシステム構成の概要を図5に示す。
図5 医療情報システムのシステム構成の概要
Zチームは，医療情報システムのシステム構成の検討と並行して，医療情報システムのネットワークセキュリティについても検討を行った。
診療室，ナースステーション，調剤室，事務室，受付で利用する端末には，PCを採用する。また，病棟で使用する端末は，長時間のバッテリ駆動が可能なNPCを採用する。NPCは，入院患者の診療などに用いるために，医師，看護師などが，病棟内で移動しながら使用する。いずれの端末も，ICカード読取装置，光ディスクドライブ，USBインタフェースを備えた仕様とするとともに，故障時などを想定し，予備NPCを用意する。医療従業者へのICカードの発行や利用者IDの付与は管理者が事務室のPCで行う。また，紙のカルテの画像データ化作業用に作業用PCを1台，スキャナ及び5台のUSBディスクを用意する。
医療情報システムのために，PC用にイーサネットLANを，病棟を移動しながら利用するNPC用に無線LANをそれぞれ新たに構築する。
医療情報システムは，電子カルテサーバ，DBサーバ，外部ストレージ装置，テープバックアップ装置及びFWから構成される。DBサーバの外部ストレージ装置には，電子カルテ及びアクセス証跡を保存する。選定したパッケージでは，パッケージの機能によって，電子カルテ機能の各操作が可能であり，電子カルテのデータは，複数の表から構成される関係データベースに格納される。
ウイルス対策，不正侵入防御機能も必要であり，FWには，これらの機能を兼ね備えた製品を導入する。
〔非常時運用についての検討〕
医療情報システムに障害が発生すると，患者の電子カルテを参照できなくなるので，医療への影響が非常に大きい。災害時などの非常時に障害が発生すると，電子カルテを参照できないことに加えて，外来患者が増加することが考えられるので，更に影響は大きいと言える。Zチームは，非常時の対応を考慮した医療情報システムの機能，構成及び運用について検討した。次は，非常時運用についての議論の一部である。
F医師：医療情報システムの非常時運用を検討する前提として，非常時には，どのような事態があり得るのか，確認しておく必要があると思います。 M氏 ：主に二つの事態があり得ます。一つはサービスの停止です。その原因には，災害時の停電やサーバやネットワークの損壊，サイバー攻撃，システム障害などが考えられます。停電対策としては，Z病院は医療機関として非常用電源設備をもっているので，停電時でも，電子カルテの参照だけはできるよう，医療情報システムに電力が供給されるようにするという対策が考えられます。 F医師：なるほど，医療情報システムが非常用電源を利用することで，医療機器に対する電力供給可能時間に影響がないかを確認する必要がありますね。次に，サービス停止の事態に際してのデータ保全に関しては，日次に電子カルテのデータベースのバックアップを取ることで，復旧に備えることができると思います。 M氏 ：なるほど，そうですね。それだけではなく，システム障害の対策としては，電子カルテサーバの冗長化構成が考えられます。通常は，ここまででも十分なレベルの対策だと思います。ただし，冗長化構成を採ったとしても，電子カルテサーバ全てで同時に障害が発生する場合も考えられます。 F医師：なるほど，確かにあり得ますね。 M氏 ：今回はそういった，非常時に医療情報システムのサーバ類が全て稼働しない事態においても，⑥最低限，NPCでUSBディスクを活用して電子カルテを参照できるレベルの対策を講じる 方がよいと思います。 F医師：そうですね。具体的にどのように対応するのかを詳細に検討し，事業継続計画（BCP）に盛り込みたいと思います。 M氏 ：もう一つの事態は，災害時などに，医療情報システムが稼働できたとしても医療情報システムのアクセス権限をもった医療従業者が不在又は対応できない事態です。 F医師：⑦非常時には，外部から医療従業者が応援に駆け付けてくることがあります 。この場合でも，医療情報システムさえ稼働していて，管理者がいれば，何とか運用できますよね。 M氏 ：そうですね。ただし，医療情報システムは稼働していて，ICカードや利用者IDを付与する管理者もいるが，医師が応援者だけとなってしまった場合の対応が必要です。 F医師：では，それを検討して BCP に盛り込んでおきましょう。 Zチームは，以上の検討に基づき，運用管理規程とBCPの策定を行い，医療情報システムを構築し，予定どおりにサービスインの日を迎えた。
出題趣旨（IPA）
社会インフラを担う情報システムでは，非常時にも業務を継続することが求められる。BCP策定においては，情報システムに関する技術的な知識だけでなく，業務そのものに対する理解も必要となる。セキュリティ技術者には，こうした業務の観点からの取組みも求められるため，常日頃より幅広い視点でスキルの研さんと経験の積み重ねが要求される。本問では，医療情報システムを題材にして，業務要件に応じたアクセス制御や，長期に渡るデータの真正性確保に関する技術についての知識と応用力を問うとともに，情報システムの可用性に加え，業務の非常時への対応についての経験と対応力を問う。
採点講評（問全体・IPA）
問1では，医療情報システムを題材に，個人情報の取り扱い，ディジタル署名やタイムスタンプを用いたデータの完全性及び真正性，社会インフラにおける重要なシステムの事業継続について出題した。
設問と解答例
設問1(1)
25字以内
表1中の下線①について，秘密鍵がICカードの外部に読み出された場合に起こり得る，医療情報システムの安全管理に対する侵害行為は何か。25字以内で具体的に述べよ。
解答例
解説
本文の根拠
表1 (G)
ディジタル署名に用いる秘密鍵が，ICカードの外部に読み出されないこと。
〔電子カルテの保存に関する要件〕
正当な者が記録し，確認された情報に関して，記録の責任の所在が明確であり，かつ，故意又は過失による，虚偽入力又は誤入力，書換え，消去及び混同が防止されていることである。
解答例は“作成責任者以外の者による電子カルテへの署名”である。
表1の(G)は，記録を“確定”登録するときに，作成責任者の電子証明書を使ったディジタル署名を付けるとしている。ディジタル署名は，秘密鍵をもつ本人だけが作れることで，記録の責任の所在を示す。秘密鍵がICカードの外部に読み出されると，作成責任者以外の者が同じ秘密鍵で署名を付けられる。真正性の定義にある“記録の責任の所在が明確”であることが崩れ，ほかの人が確定したはずの記録が，作成責任者の署名付きで残ってしまう。
字数は21字で，制限の25字に収まる。誰が何を行えるのかを，“作成責任者以外の者”と“電子カルテへの署名”の二つで書く。
採点講評（IPA）
設問1(1)は，正答率が低かった。複数存在するアクタのうちどのアクタになりすますのかによって，発生するセキュリティ上のリスクが異なってくることを理解して解答してほしかった。(2)は，基礎的な技術に関する出題で，解答の多くは正しい技術用語で解答できていなかった。正しく理解し覚えてほしい。
設問1(2)
8字以内
表1中の下線①を実現するために，ICカードが備えるべき性質は何か。8字以内で述べよ。
解答例
解説
本文の根拠
表1 (G)
このディジタル署名には，鍵生成機能と署名機能付きのICカードを用いること。
表1 (G)
ディジタル署名に用いる秘密鍵が，ICカードの外部に読み出されないこと。
解答例は“耐タンパ性”である。
(G)は，鍵生成と署名をICカードの中で行うことを求めている。署名に使う秘密鍵が一度もカードの外に出なければ，外部に読み出されることはない。そのために，ICカードには，内部の情報を外部から不正に読み出したり，解析したりしにくい性質が要る。これを耐タンパ性という（tamper は“いじる”の意味）。
字数は5字で，制限の8字に収まる。“読み出されない”という要件を表す技術用語を，一語で答える。
採点講評（IPA）
設問1(1)は，正答率が低かった。複数存在するアクタのうちどのアクタになりすますのかによって，発生するセキュリティ上のリスクが異なってくることを理解して解答してほしかった。(2)は，基礎的な技術に関する出題で，解答の多くは正しい技術用語で解答できていなかった。正しく理解し覚えてほしい。
設問2(1)
45字以内
医療情報システムにおいて，電子カルテのディジタル署名を付与する仕組みの他に，医療従業者のアクセス証跡を保存する仕組みを整えるのは，どのような抑止効果を期待してのものか。45字以内で述べよ。
解答例
医療行為に必要な範囲を超えて患者の医療情報にアクセスすることを抑止する効果
解説
本文の根拠
表1 (N)
電子カルテに対する全ての操作についてのアクセス証跡を残すこと。
〔医療情報システムのアクセス制御についての検討〕
担当外の患者の電子カルテの参照及び職務権限外のアクセスも容易にできるようになるので，アクセス制御の構築とアクセス証跡の保存が重要になる。
図1 情報資産へのアクセス制御
情報資産に対するアクセスは，業務上，必要最小限の範囲で許可する。
解答例は“医療行為に必要な範囲を超えて患者の医療情報にアクセスすることを抑止する効果”である。
ディジタル署名は，記録の書換えや確定を行った人を確かめるための仕組みである。これに対してアクセス証跡は，参照を含む全ての操作を記録する。電子カルテでは，担当外の患者の記録や職務権限外の情報を容易に見られるようになるので，後から誰が何を見たかを確かめられる状態にしておけば，必要最小限の範囲を超えたアクセスをためらわせる効果がある。基本方針の“業務上，必要最小限の範囲で許可する”に沿った運用を，証跡で裏付ける形になる。
字数は37字で，制限の45字に収まる。“医療行為に必要な範囲を超えて”という限定と，“抑止する効果”の二つを入れる。
設問2(2)
解答欄1つ
表3中のa に入れる適切なアクセス制御案を，表3中のアクセス制御の記号に倣って答えよ。
解説
本文の根拠
表2 注1)
研修医による診療内容の記録は，“確定”登録にならず，“仮”登録になる。
表3
医師（研修医以外）：医学的背景情報は A, R, U, D, F, P。
〔医療情報システムで利用するICカードについての認証方式の検討〕
予備ICカードで記録を“確定”登録することはできない。
解答例は“A，R，U，D，P”である。
表3で，医師（研修医以外）の医学的背景情報には A, R, U, D, F, P が与えられている。研修医も診療内容を記録するので，追記（A），参照（R），書換え（U），消去（D），印刷（P）は必要である。一方，表2の注1)のとおり，研修医の記録は“確定”登録にならず“仮”登録になる。“確定”登録（F）は，指導する医師が内容を確認したうえで行う責任をもつので，研修医の権限からは外れる。
解答は6種のうちFだけを除いた5つを，表3の書き方に倣って並べる。
設問2(3)
40字以内
本文中の下線②にある，別のアクセス制御とはどのようなものか。アクセス制御のアクセス主体とアクセス対象の関係を示しながら，40字以内で述べよ。
解答例
個別の利用者ごとに，電子カルテのデータ項目ごとに行うアクセス制御
解説
本文の根拠
〔医療情報システムのアクセス制御についての検討〕
傷病名によっては，患者又は家族などの意向によって，診療記録の記載内容の開示を“特定の診療科の医師に限定する”という要件のあることが判明した。
〔医療情報システムのアクセス制御についての検討〕
医療情報システムの利用者を職種などの観点で整理したアクタ種別と，電子カルテのデータ項目の組合せで制御する必要がある
解答例は“個別の利用者ごとに，電子カルテのデータ項目ごとに行うアクセス制御”である。
表3のアクタ種別（職種）ごとの制御では，同じ職種の医師は全員が同じ権限になる。“特定の診療科の医師に限定する”には，同じ医師の中でも，ある医師には見せ，ほかの医師には見せない区別が要る。そこで，アクセス主体を職種ではなく個別の利用者にし，アクセス対象を患者の記録の項目にして，その組合せごとに許可するかどうかを決める必要がある。
字数は32字で，制限の40字に収まる。設問が“アクセス主体とアクセス対象の関係を示しながら”と指定しているので，主体（個別の利用者）と対象（データ項目）の両方を入れる。
採点講評（IPA）
設問2(3)は，“アクセス主体”の意味を正しく理解していない解答が多かった。アクタ種別ごとのアクセス制御では不十分なことを踏まえ，“アクセス主体”を更に細かな単位で制御する必要があることに着眼してほしい。
設問3(1)
解答欄2つ
本文中の下線③が示す実装方式は，表1中のどの要件を満たしていると考えられるか。表1中から該当する要件を二つ挙げ，(A)〜(Q)の記号で答えよ。
解説
本文の根拠
〔医療情報システムにおける真正性についての検討〕
電子カルテのデータ項目にカーソルを置いた際に，③過去に確定した全ての記録を表示する方式
表1 (J)(K)
(J) 記録に対する操作の履歴が後から確認でき識別できること。(K) 記録の内容を容易に確認できること。
解答例は①(J)，②(K)である。
カーソルを置くだけで過去に確定した全ての記録が表示される方式は，操作の履歴が残っていて，後から確認し識別できること（J）と，その記録の内容を容易に確認できること（K）の両方を満たす。“更新履歴の保存と参照”の分類には(I)〜(K)の3つが並ぶが，(I)は過去の記録が正しく保存されることを求めるもので，表示の方式とは関係がない。
設問は表1から二つを挙げるものなので，(J)と(K)を一つずつ書く。
設問3(2)
65字以内
本文中の下線④について，改善案を65字以内で述べよ。
解答例
電子カルテのディジタル署名の有効期限が切れる前に，署名検証に必要な情報を含むアーカイブタイムスタンプを付与する。
解説
本文の根拠
〔医療情報システムにおける真正性についての検討〕
電子証明書の有効期限は約2年となっている。
〔医療情報システムにおける真正性についての検討〕
10年以上継続して受診する患者がいるので，図4に示したタイムスタンプ付与の仕組みでは不十分であると指摘し
表1 (H)
ディジタル署名に対してタイムスタンプを付与し，法定保存期間中，タイムスタンプの有効性が継続されるようにすること。
解答例は“電子カルテのディジタル署名の有効期限が切れる前に，署名検証に必要な情報を含むアーカイブタイムスタンプを付与する。”である。
署名に使う電子証明書は約2年で期限が切れ，タイムスタンプのサービスの有効期限は10年などである。図4の仕組みは，署名のときに一度タイムスタンプを付けるだけなので，10年を超えて受診する患者の初診からの記録は，署名やタイムスタンプの有効性を保てなくなる。そこで，有効期限が切れる前に，署名の検証に必要な情報も含めて，もう一度タイムスタンプを付ける。RFC 3161 の4章も，TSA の鍵には寿命があるので，TSA が署名したトークンには再度タイムスタンプを付けるべきだとしている。
字数は56字で，制限の65字に収まる。“有効期限が切れる前に”と“アーカイブタイムスタンプを付与する”の二つが要点である。
採点講評（IPA）
設問3(2),(3)は，正答率が低かった。タイムスタンプ技術の目的と適用方法について，曖昧なまま理解している解答が多いように見受けられたので，基本的な技術を正確に理解してほしい。(4)は，改ざん検知後，電子カルテを回復する場合，どの時点の状態に戻るのかを認識して解答してほしい。
設問3(3)
解答欄1つ
図4中のb に入れる適切な字句を，10字以内で答えよ。
解説
本文の根拠
〔医療情報システムにおける真正性についての検討〕
ディジタル署名は，電子カルテのデータ項目ごとに付与することにした。
図4
変更があった各データ項目のb のハッシュ値を作成
表1 (H)
ディジタル署名に対してタイムスタンプを付与し
b は“ディジタル署名”である。
本文は，ディジタル署名を電子カルテのデータ項目ごとに付与すると述べている。表1の(H)は，そのディジタル署名にタイムスタンプを付与することを求めている。図4では，データ項目と“データ項目ごとの b ”が電子カルテに含まれ，変更があった項目の b のハッシュ値を作ってTSAに要求している。したがって b は，各データ項目に付くディジタル署名になる。タイムスタンプの要求にハッシュ値だけを送る点は，RFC 3161 の2.1節が“to only time-stamp a hash representation of the datum”と定めている。
字数は7字で，制限の10字に収まる。タイムスタンプは b のハッシュ値に付くもので，b そのものではない。
採点講評（IPA）
設問3(2),(3)は，正答率が低かった。タイムスタンプ技術の目的と適用方法について，曖昧なまま理解している解答が多いように見受けられたので，基本的な技術を正確に理解してほしい。(4)は，改ざん検知後，電子カルテを回復する場合，どの時点の状態に戻るのかを認識して解答してほしい。
設問3(4)
30字以内
本文中の下線⑤について，医療の提供を継続するために医療情報システムが備えるべき機能を30字以内で述べよ。
解答例
バックアップから改ざん前の電子カルテを復旧する機能
解説
本文の根拠
表1 (M)
改ざんが検知された場合は，バックアップなどを用いて回復できること。
〔医療情報システムにおける真正性についての検討〕
“確定”登録が行われた電子カルテが改ざんされた場合に，単に検知するだけではなくて，⑤その後も，正しい電子カルテを用いて医療を提供する必要があります
解答例は“バックアップから改ざん前の電子カルテを復旧する機能”である。
M氏は，改ざんを検知するだけでなく，その後も正しい電子カルテで医療を提供する必要があると述べている。表1の(M)は，改ざんを検知したときにバックアップなどを使って回復できることを要件にしている。回復で戻す先は，改ざんされた後の状態ではなく，改ざんされる前の電子カルテである。
字数は25字で，制限の30字に収まる。“バックアップから”“改ざん前の”“復旧する”の三つを入れ，どの時点の状態に戻るのかを明確にする。
採点講評（IPA）
設問3(2),(3)は，正答率が低かった。タイムスタンプ技術の目的と適用方法について，曖昧なまま理解している解答が多いように見受けられたので，基本的な技術を正確に理解してほしい。(4)は，改ざん検知後，電子カルテを回復する場合，どの時点の状態に戻るのかを認識して解答してほしい。
設問4(1)
解答欄2つ
本文中の下線⑥について，対策を講じる上で，日々行うべき業務及び災害時に行うべき業務を，それぞれ60字以内で具体的に述べよ。
〔日々行うべき業務〕解答例
患者ごとに，見読可能な画像データを電子カルテから生成し，USBディスクに書き出しておく。
〔災害時に行うべき業務〕解答例
電子カルテの画像データを保管したUSBディスクを端末に接続して，患者の電子カルテの画像データを医師に配布する。
解説
本文の根拠
〔非常時運用についての検討〕
最低限，NPCでUSBディスクを活用して電子カルテを参照できるレベルの対策を講じる
〔Z病院の医療情報システムのシステム構成の検討〕
いずれの端末も，ICカード読取装置，光ディスクドライブ，USBインタフェースを備えた仕様とするとともに，故障時などを想定し，予備NPCを用意する。
〔Z病院の医療情報システムのシステム構成の検討〕
紙のカルテの画像データ化作業用に作業用PCを1台，スキャナ及び5台のUSBディスクを用意する。
解答例は，日々行うべき業務が“患者ごとに，見読可能な画像データを電子カルテから生成し，USBディスクに書き出しておく。”，災害時に行うべき業務が“電子カルテの画像データを保管したUSBディスクを端末に接続して，患者の電子カルテの画像データを医師に配布する。”である。
サーバが全て止まると，電子カルテのデータベースも使えない。そこで，サーバが動いているうちに，患者ごとに，見読できる画像データを作ってUSBディスクに書き出しておく。災害時は，端末（NPCなど）はUSBインタフェースをもつので，そのUSBディスクを接続して画像データを開き，医師に渡せば，参照だけはできる。サーバやネットワークに頼らない手段である。
字数は日々が44字，災害時が55字で，制限は各60字である。何を（画像データ），どの単位で（患者ごと），どこに（USBディスク）が分かるように，日々と災害時を分けて書く。
採点講評（IPA）
設問4(1)は，緊急時にはシステム環境などに関する制約がある中で業務遂行上の優先順位付が必要になることを認識した上で，実行性のある方式を具体的に解答してほしい。(2)は，非常時に医療情報システムを利用する者の識別及び資格の有無など，アクセスの許可を判断する上で必要となる手続などを具体的に解答してほしい。
設問4(2)
解答欄2つ
本文中の下線⑦について，非常時に外部から応援に駆け付けてくる医師に，医療情報システムへのアクセスを許可する場合，BCPに盛り込むべき事項をセキュリティの観点から二つ挙げ，それぞれ40字以内で具体的に述べよ。
〔①〕解答例
本人確認の方法と，認証に用いるICカードの貸与及び利用者IDの付与の方法
〔②〕解答例
応援者の資格の確認方法と，応援者に付与するアクセス権限の内容と付与方法
〔備考〕二つの事項を答える（順不同）
解説
本文の根拠
〔非常時運用についての検討〕
医療情報システムは稼働していて，ICカードや利用者IDを付与する管理者もいるが，医師が応援者だけとなってしまった場合の対応が必要です。
図1 情報セキュリティ対策(4)
Z病院以外の医療従業者に医療情報の参照を許可する場合には運用手順による特別な対策を講じる。
〔医療情報システムで利用するICカードについての認証方式の検討〕
医師の電子証明書には，医師資格を保有していることを示す情報が含まれ
解答例は，①“本人確認の方法と，認証に用いるICカードの貸与及び利用者IDの付与の方法”，②“応援者の資格の確認方法と，応援者に付与するアクセス権限の内容と付与方法”である。
応援に来た医師は，Z病院のICカードも利用者IDももっていない。電子カルテの利用は，利用者の識別と認証が前提なので，まず本人かどうかを確認し，認証に使うICカード（予備ICカードなど）の貸与と利用者IDの付与の手順が要る。次に，Z病院の医師は電子証明書で医師資格が確かめられるが，応援者はそうではない。そこで，資格の確認方法と，どのアクセス権限をどう付与するかも決めておく。方針は，Z病院以外の医療従業者に参照を許可する場合は運用手順で特別な対策を講じるとしている。
字数は①が36字，②が35字で，制限は各40字である。二つは“誰かを確かめる”（本人確認，資格確認）と“何をさせるか”（ICカード・ID，アクセス権限）の組合せで，互いに異なる事項を書く。
採点講評（IPA）
設問4(1)は，緊急時にはシステム環境などに関する制約がある中で業務遂行上の優先順位付が必要になることを認識した上で，実行性のある方式を具体的に解答してほしい。(2)は，非常時に医療情報システムを利用する者の識別及び資格の有無など，アクセスの許可を判断する上で必要となる手続などを具体的に解答してほしい。
出典：平成23年度 秋期 情報処理安全確保支援士試験 午後Ⅱ 問1（表記を一部改変）
問2 ログ管理システムの設計
ログ管理システムの設計に関する次の記述を読んで，設問1〜4に答えよ。
A社は，従業員数20,000名の製造会社であり，東日本と西日本にそれぞれ10の支社をもっている。A社は，内部統制強化の一環として，システムの運用に関わる内部統制について外部監査人による監査を受けた。監査の結果，システムの特権を与えられた管理者やオペレータなど（以下，特権ID利用者という）の操作（以下，特権操作という）に対する監視について，次の2点が指摘された。
特権操作のログを取得していないシステムがある。 どのシステムにおいても特権操作のログに対する分析が行われていない。 これまで，A社情報システム部では，特権操作に対する監視方法をシステムごとに個別に検討，実装してきたことから，特権操作のログを取得，収集保存及び分析（以下，合わせてログ管理という）する方法がシステムごとに異なっていた。情報システム部は，監査における指摘を踏まえ，特権操作に対して全システム共通のログ管理方法を定め，共通のログ管理システムを構築することとし，システムのログ管理について，次のとおり計画した。
大量の個人情報又は財務データを処理している，本社営業管理システム，会計管理システム，経理システム及び支社営業管理システム（以下，主要4システムという）のログ管理のため，本年度中に，ログ管理システムを稼働させる。 主要4システムへの適用後の評価に従って，ログ管理システムの設計及び運用の見直しを行い，ログ管理システムを利用してログ管理を行うシステムを順次増やす。 〔A社のシステム環境〕
A社は，東京と大阪に自社のデータセンタ（以下，DCという）を構えており，東京DCでは本社及び東日本の支社における業務処理を，大阪DCでは西日本の支社における業務処理を行っている。両DC間は広域イーサネットで接続されており，本社及び各支社からは広域イーサネットを介して両DCのシステムを利用できる。
各DC内のマシン室には，汎用機が2台ずつ，UNIXサーバが150台ずつ，PCサーバが150台ずつ配置されている（以下，汎用機，UNIXサーバ及びPCサーバを合わせてサーバという）。両DCには，マシン室に隣接してオペレータ室があり，マシン室とオペレータ室はLANで接続されている。
各DCでは電源設備の定期保守作業のために，半年に1回，4時間程度，DC内の全サーバを停止する。電源設備の保守作業は，東京DCと大阪DCでは異なる日に行われるように調整されている。
〔特権IDの利用〕
特権ID利用者は，各個人に1台ずつ割り当てられた管理端末からネットワークを介して各サーバにアクセスしてシステム管理又は運用の作業を行っている。管理端末は，本社に200台，東京DCと大阪DCのオペレータ室にそれぞれ10台ずつ配置されており，利用者IDとパスワードによる認証機能によって，本人でなければ操作できない仕組みになっている。管理端末のIPアドレスは，東京DC及び大阪DCそれぞれにあるa サーバによって動的に割り当てられる仕組みになっており，同じ管理端末でも割り当てられるIPアドレスが異なることがある。
主要4システムにおいては，A社の情報セキュリティポリシに従い，マシン室の内部・外部間で個人情報又は財務データを通信する場合の暗号化，並びに個人情報又は財務データを外部記憶媒体に保管する場合の暗号化を行っている。特権ID利用者が管理端末から各サーバにアクセスする際の通信においても，暗号化を行っている。
サーバと管理端末の配置場所，時刻設定の方法及び特権ID利用者の利用者IDの割当て方法を表1に，特権ID利用者の役割名称，担当者，作業場所及び作業内容を表2に，それぞれ示す。
表1 サーバと管理端末の配置場所，時刻設定の方法及び特権ID利用者の利用者IDの割当て方法
表2 特権ID利用者の役割名称，担当者，作業場所及び作業内容
特権ID利用者は合計220名である。特権ID利用者は，定型のシステム運用以外に特権操作を含む作業を行う場合，事前に自分の氏名と所属，作業で使用する利用者ID，作業開始日時，作業時間，作業目的及び作業の概要を記載した作業申請書を自社の管理責任者に提出する。各社の管理責任者は，作業内容が業務上必要なものであることを確認し，承認印を押印する。通常時，各社の管理責任者は，担当者に対する作業指示や作業の管理を行っている。何かの事情で担当者の手が足りなくなった場合，各社の管理責任者が特権操作を行うことがあるので，各社の管理責任者は特権ID利用者を兼務しており，利用者IDが割り当てられている。
特権ID利用者のうち，情報システム部の従業員は，アプリケーション管理者又はインフラ管理者のどちらか一方を担当しており，自分が所属するグループの作業内容を詳しく理解している。各システムの構築はSIベンダに委託している。各システムのオペレータが行う運用手順は，手順の概要を記した引継ぎ資料と口頭説明によって委託先のSIベンダからオペレータに直接引き継がれてきた。さらに，情報システム部の従業員の中にオペレータの役割をもつ者がいないこともあり，オペレータが行うシステム運用の詳細を知っている者はいない。
〔設計の前提条件〕
情報システム部のX部長は，ログ管理システムの基本設計をY主任に指示した。Y主任がログ管理に関する十分な経験と知識をもっていなかったことから，X部長は，専門家の参加が必要と判断し，SIベンダのE社にログ管理システムの基本設計への参加を依頼した。E社の情報セキュリティスペシャリストのT氏は，最初にY主任から，ログ管理システムを開発することになった経緯やA社のシステム環境についての説明を受けた。後日，Y主任は，T氏の助言を受けながら，設計の前提条件を次のように整理し，X部長の承認を得た。
(1) ログ管理システムを次の三つの機能からなるシステムとする。 ログ取得機能：監視の対象とする特権操作について，記録すべきデータをログファイルとして出力する機能 ログ収集保存機能：複数のログファイルを収集し，フォーマットの変更を行って，一つのログデータベースに統合し，ログファイルと併せて保存する機能 ログ分析機能：与えられた条件に従い，ログデータベースから疑わしい特権操作のログを抽出する機能 (2) 監視の対象とする特権操作を，次の3種類とする。 特権操作1：特権ID利用者による各サーバへのログオン及びログオフ 特権操作2：各システムのデータベース（DB）に保管された個人情報及び財務データに対する参照及び更新 特権操作3：各サーバのOS及びミドルウェアのコマンド，スクリプト及びプログラムの実行，並びに設定情報の参照及び更新 主要4システムにおいて監視の対象とする特権操作を表3に示す。
表3 主要4システムにおいて監視の対象とする特権操作
(3) 各特権操作に対して記録すべきデータ項目は，次の五つとする。 ① 特権操作が行われた日時 ② 特権操作に利用された利用者ID ③ 特権操作が行われたサーバのホスト名又はサーバのIPアドレス ④ 特権操作の内容 ⑤ 特権操作の結果（成功又は失敗。エラーメッセージなどの補助的情報で成功と失敗が判別できる場合は，結果が記録されなくてもよい。） 主要4システムの各特権操作に対して記録すべき特権操作の内容を表4に示す。
表4 主要4システムの各特権操作に対して記録すべき特権操作の内容
(4) 構築費用を抑えるため，製品の標準機能を最大限に活用する。 〔利用する製品の仕様〕
T氏は，ログ管理システムに利用できる製品として，次の二つの製品を選んだ。
製品R：管理端末でログを取得し，収集保存及び分析をPCサーバで行う製品 製品S：各サーバのOS及びミドルウェアが取得したログをUNIXサーバで収集保存及び分析する製品 T氏は，OS及びミドルウェアの標準機能，製品Rの機能並びに製品Sの機能に関する調査を行った。主要4システムのOS及びミドルウェアの標準機能で共通に取得できるログのデータ項目を図1に，主要4システムのDBMSにおけるDBアクセスに関するログ取得機能を表5に，製品Rの仕様を図2に，製品Sの仕様を図3に，それぞれ示す。
図1 主要4システムのOS及びミドルウェアの標準機能で共通に取得できるログのデータ項目
表5 主要4システムのDBMSにおけるDBアクセスに関するログ取得機能
図2 製品Rの仕様
図3 製品Sの仕様
〔ログ取得機能の設計〕
以上の検討結果に基づき，T氏は，ログ取得機能の実装方法として，次の二つの案をY主任に説明した。
各サーバのOS及びミドルウェアの標準機能を利用する。 製品Rを利用する。 なお，製品Sはログ取得機能をもたないので，ログ取得機能には利用できない。
Y主任は，T氏の案以外にも，通信経路でログを取得する，ネットワークフォレンジックと呼ばれている案もあるのではないかと質問した。T氏は，通信経路でログを取得する案は採用できないことを説明した。
T氏は，図1を基に，主要4システムにおける特権操作1については，OS及びミドルウェアの標準機能で必要なログのデータ項目を取得できると判断した。一方，ログオフの操作に，パラメタなしの“exit”，“logoff”，“logout”といったコマンドが使われることから，製品Rでは必要なデータ項目が取得できず，分析の際にもそのデータ項目の値を判別できない場合があると判断した。
T氏は，これらの検討結果から，特権操作1について設計の前提条件を満たすためには，製品Rでなく，OS及びミドルウェアの標準機能を使うべきだと判断した。
次にT氏は，特権操作2に関するログ取得機能の実装方法を検討するために，主要4システムのDBMSが稼働している各サーバについて，サーバ資源の利用状況及びDBアクセス数全体に占める特権操作2の割合を調査した。T氏は，サーバ資源の利用状況から，DBMSの標準機能によってログを取得すると，各システムの業務処理への影響が大きいと考えた。また，T氏は，各システムのDBアクセス数は同程度で，その中での特権操作の割合が5％だったことから，システムによってはログの保存及び分析のために大量のディスク資源を追加する必要があると考えた。T氏は，これらの検討結果から，特権操作2に対しては，DBMSの標準機能よりも製品Rを使う方が適切と判断した。
さらに，T氏は，図1及び図2を基に，特権操作3に対しては，OS及びミドルウェアの標準機能よりも製品Rを使う方が適切と判断した。
Y主任は，T氏の案をまとめ，X部長の承認を得た。
〔ログ収集保存機能の設計〕
次に，Y主任とT氏は，特権操作1のログに対する収集保存機能の設計を行った。製品Rの収集保存機能は，製品Rで取得したログを対象とした機能である一方，製品Sの収集保存機能は，主要4システムの管理及び運用に使われているOS及びミドルウェアのログ全てに適用できることから，T氏は，製品Sを採用することを提案した。
そこで，Y主任は，東京DCにSサーバを配置し，両DCのログデータを一括して収集する方法（以下，案1という）を考えた。案1の構成を図4に示す。
図4 案1の構成
サーバの中には，ログデータに割り当てられたディスク領域が一杯になると，新しいログデータで古いログデータを先頭から上書きするものがある。このことから，T氏は，ログが収集できない時間帯が発生する案1では，特別な運用対策が必要となることを指摘し，そうした対策の必要がないように，DCごとにSサーバを配置してログデータを収集する方法（以下，案2という）を提案した。案2の構成を図5に示す。
図5 案2の構成
Y主任はT氏の指摘を認め，X部長も案2の構成とすることを承認した。
次に，Y主任とT氏は，特権操作2及び特権操作3のログに対する収集保存の方法を検討した。Y主任は，東京DCにRサーバを配置してログを収集保存する方法を考えた。図6に特権操作2及び特権操作3のログに対する収集保存の方法案を示す。
図6 特権操作2及び特権操作3のログに対する収集保存の方法案
T氏は，収集保存の対象となる特権操作2及び特権操作3のログが大量になることから，ログの最大データ量とログ収集に必要なネットワークの伝送速度を見積もり，現在のシステム環境への影響を評価することをY主任に提案した。Y主任は，見積りに関する基礎数値を設定し，①A社全体で発生する特権操作2及び特権操作3に対する30日分のログの最大データ量 と②製品Rを使って本社の管理端末200台から東京DCにログを収集するために必要なネットワークの伝送速度 を見積もった。見積りに関する基礎数値を図7に示す。
図7 見積りに関する基礎数値
Y主任とT氏は，見積結果から，現在のシステム環境への影響はないと判断し，東京DCにRサーバを配置してログを収集保存する方法について，X部長の承認を得た。
次に，Y主任は，ログファイル及びログデータベースのバックアップに関する運用規程を定める必要があると考え，現在のシステム運用を考慮して，その案を作成した。図8にログファイル及びログデータベースのバックアップに関する運用規程案を示す。
図8 ログファイル及びログデータベースのバックアップに関する運用規程案
T氏は，特権操作2に関するログのデータ項目の内容を考慮し，運用規程案に追加すべき点を指摘した。③Y主任は運用規程案に項目を追加 し，これまでの検討結果をまとめ，X部長の承認を得た。
〔ログ分析機能の設計〕
次にY主任とT氏は，ログ分析機能の設計を行った。Y主任は，他社で発生している情報漏えい事件の内容から，業務時間（月曜日から金曜日の9:00から17:00）外に行われた特権操作を優先的に監視する必要があると考えた。Y主任は，毎月第2金曜日に行われる運用報告会議において，前月のログに対する確認作業の結果を，各社の管理責任者がX部長に報告することを考えた。Y主任が考えたログ分析機能及び確認作業の内容は次のとおりである。
ログ分析機能：特権操作1に関するログから，業務時間外に行われた特権操作1のログを抽出する。 確認作業：抽出された特権操作1のログについて，関連する作業申請書と特権操作2及び特権操作3に関するログを基に，操作内容の必要性を確認し，確認者の氏名と確認結果を記録する。 Y主任は，情報システム部の従業員では一部の特権ID利用者について個々の操作内容の必要性を十分に確認できないことから，各社の管理責任者が確認作業を行う案に修正した。しかし，T氏は，その修正案には，特権操作の確認として不十分な点が別にあることを指摘し，改善案を提案した。Y主任は改善案に従って手順を修正し，これまでの検討結果をまとめ，X部長の承認を得た。
Y主任とT氏は引き続きログ分析機能の設計を行い，無事にログ管理システムの基本設計を完了した。
出題趣旨（IPA）
ログ管理システムの設計においては，セキュリティ技術だけでなく，既存システムの環境や運用全体を見渡す広い視野が必要になる。近年，実務を担当するセキュリティ技術者には，セキュリティに関する専門知識だけでなく，システムに求められる要件及び制約の一つとしてセキュリティをとらえ，多岐にわたる前提条件を収集整理した上で他の要件及び制約とのバランスをとりながら全体で最適となるセキュリティ機能を設計する能力が求められている。本問では，大規模システムにおける，ログ管理システムの全体設計に関する，これらの能力と経験を問う。
採点講評（問全体・IPA）
問2では，複数種類のサーバからなる既存システムに対して，統一したログ管理システムを適用する際の設計について出題した。全体として正答率は想定どおりであり，実務経験をもつ受験者にとっては，正解を導きやすい問題であったと思われる。
設問と解答例
設問1
解答欄2つ
本文中のa 及び表1中のb に入れるプロトコル名を，それぞれ英字4字以内で答えよ。
解説
本文の根拠
〔特権IDの利用〕
a サーバによって動的に割り当てられる仕組みになっており
表1 UNIXサーバ及びPCサーバ
社内のb サーバがインターネットのb サーバと時刻同期を行い，社内のサーバは社内のb サーバと時刻同期を行う。
a は“DHCP”，b は“NTP”である。
IPアドレスを動的に割り当てるサーバは，DHCP（Dynamic Host Configuration Protocol）のサーバである。RFC 2131 の1章は，DHCP の動的割当て（dynamic allocation）を，クライアントに一定期間IPアドレスを割り当てるものと説明している。管理端末が起動するたびに別のアドレスを受け取ることがあるのは，この仕組みによる。時刻同期は，NTP（Network Time Protocol）である。RFC 5905 の概要は，NTP を“コンピュータの時計をインターネット上で同期するために広く使われている”プロトコルとしている。社内のNTPサーバがインターネットのNTPサーバに合わせ，社内の各サーバが社内のNTPサーバに合わせる，という階層が表1の説明と合う。
字数は DHCP が4字，NTP が3字で，制限は英字4字以内である。
設問2(1)
30字以内
T氏が，通信経路でログを取得する案を採用しなかった理由を，30字以内で述べよ。
解答例
通信内容が暗号化されており，ログの内容が分析できないから
解説
本文の根拠
〔特権IDの利用〕
特権ID利用者が管理端末から各サーバにアクセスする際の通信においても，暗号化を行っている。
〔ログ取得機能の設計〕
T氏は，通信経路でログを取得する案は採用できないことを説明した。
解答例は“通信内容が暗号化されており，ログの内容が分析できないから”である。
ネットワークフォレンジックは，通信経路を流れるパケットを取得して，その中身から操作を調べる方法である。しかし本文は，特権ID利用者が管理端末から各サーバにアクセスする際の通信も暗号化していると述べている。経路で取得できるのは暗号化されたデータなので，どの操作をしたのかというログの内容を読み取れず，分析に使えない。
字数は28字で，制限の30字に収まる。“暗号化されている”という原因と，“ログの内容が分析できない”という結果の二つを書く。
設問2(2)
解答欄3つ
ログオフの操作について記録すべきデータ項目のうち，製品Rでは取得できないデータ項目は何か。25字以内で述べよ。その場合でも，ある条件の下では分析の際にそのデータ項目の値を判別できるが，それはどのような場合か。30字以内で述べよ。その際，判別の根拠となる情報は何か。45字以内で述べよ。
〔判別の根拠となる情報〕解答例
ログに記録された直前のログオン操作成功におけるサーバのホスト名又はサーバのIPアドレス
解説
本文の根拠
〔設計の前提条件〕(3)
③ 特権操作が行われたサーバのホスト名又はサーバのIPアドレス
〔ログ取得機能の設計〕
ログオフの操作に，パラメタなしの“exit”，“logoff”，“logout”といったコマンドが使われることから，製品Rでは必要なデータ項目が取得できず，分析の際にもそのデータ項目の値を判別できない場合があると判断した。
図2
複数ウィンドウを使って操作する場合は，取得したキーボード入力及び画面出力のテキストデータがどのウィンドウで入出力されたものか判別できない。
解答例は，データ項目が“サーバのホスト名又はサーバのIPアドレス”，判別できる場合が“一つのウィンドウだけを使って特権操作を行った場合”，判別の根拠が“ログに記録された直前のログオン操作成功におけるサーバのホスト名又はサーバのIPアドレス”である。
製品Rは画面の画像とキーボード入力・画面出力のテキストを取得する。“exit”のようにパラメタのないログオフの操作は，どのサーバからのログオフかが文字列に現れないので，記録すべき③（サーバのホスト名又はIPアドレス）が取得できない。ただし，図2は，複数のウィンドウを使うとテキストデータがどのウィンドウのものか判別できないと述べている。逆にいえば，ウィンドウが一つだけのときは，その直前にログオンしたサーバに対するログオフだと分かる。根拠は，ログに記録されている直前のログオン操作の成功の記録に含まれる，サーバのホスト名又はIPアドレスである。
字数は20字，24字，43字で，制限は25字，30字，45字である。3つを混ぜずに，取得できない項目，判別できる条件，判別の根拠の順に，それぞれ答える。
採点講評（IPA）
設問2(2)は，正答率が低かった。特権操作1に対して記録すべきデータ項目と製品Rの仕様とを比較することで，解答を導き出すことを期待したが，製品Rの仕様や本文中に記載されている条件を十分に理解していないと思われる解答が多かった。実装方法の検討においては，要件や制約の抽出及び整理を行う必要があることを再認識してほしい。また，設問の趣旨を誤解した解答も多かった。解答においては，設問の趣旨を十分に理解してほしい。
設問2(3)
30字以内
DBMSの標準機能によるログ取得を行った場合，各システムの業務処理への影響が大きいとT氏が考えたのはなぜか。サーバ資源という用語を用いて30字以内で述べよ。
解答例
DBMSのログ取得機能がサーバ資源を大量に消費するから
解説
本文の根拠
〔ログ取得機能の設計〕
T氏は，サーバ資源の利用状況から，DBMSの標準機能によってログを取得すると，各システムの業務処理への影響が大きいと考えた。
表5
各DBアクセスに対して，日時，利用者ID，実行したSQL文，SQL文の実行結果がログファイルに出力される。
解答例は“DBMSのログ取得機能がサーバ資源を大量に消費するから”である。
DBMSの標準機能は，各DBアクセスに対して日時，利用者ID，実行したSQL文，その実行結果をログファイルに出力する。DBアクセスのたびにこの処理が走り，ログの書出しが加わるので，業務処理に使うサーバ資源（CPU，メモリ，ディスク入出力など）が圧迫される。T氏が影響が大きいと考えたのは，サーバ資源の利用状況の調査結果からである。
字数は27字で，制限の30字に収まる。設問が“サーバ資源という用語を用いて”と指定しているので，ログ取得機能がサーバ資源を大量に消費するという原因を書く。
設問2(4)
解答欄3つ
DBMSの標準機能によるログ取得を行った場合，ログの保存及び分析に大量のディスク資源が必要になるシステムを，表3中の項番で二つ答えよ。また，その理由を30字以内で述べよ。
〔理由〕解答例
特権操作2以外のDBアクセスのログが大量に取得されるから
解説
本文の根拠
表5
本社営業管理システムと会計管理システム（G社製品H）は，ログ取得を行うか否かを表ごとに設定する。
表5
経理システムと支社営業管理システム（K社製品L）は，各利用者IDが所属するユーザグループを定義し，ログ取得を行うか否かをユーザグループごとに設定する。
〔ログ取得機能の設計〕
その中での特権操作の割合が5％だったことから，システムによってはログの保存及び分析のために大量のディスク資源を追加する必要があると考えた。
解答例は，システムが表3の項番1と2，理由が“特権操作2以外のDBアクセスのログが大量に取得されるから”である。
項番1・2は製品H（G社）で，ログ取得を行うかどうかを表ごとに設定する。個人情報や財務データを保管している表のログを取ると，特権ID利用者の操作だけでなく，通常の業務アプリケーションによるDBアクセスのログも全て記録される。特権操作は全体の5％なので，残りの95％は必要のないログである。項番3・4は製品L（K社）で，設定の単位が利用者IDのユーザグループなので，特権ID利用者のグループだけを対象にして，特権操作のログに絞り込める。
字数は28字で，制限の30字に収まる。講評が述べるとおり，大量のディスク資源が必要になる真の理由は，製品Hの仕様上の制約の結果，必要のないログが大量に取得されてしまうことである。
採点講評（IPA）
設問2(4)では，システムを正しく選択できているのに，理由を正確に記述できていない解答が多かった。大量のディスク資源が必要になる真の理由は，製品Hの仕様上の制約の結果，必要のないログが大量に取得されてしまうことである。ログ管理においては，ログの保存や分析のために大量のディスク資源が必要になるので，必要なログだけを取得する必要があることを理解しておいてほしい。
設問2(5)
記録すべき特権操作の内容のうち，特権操作3に対して，主要4システムのOS及びミドルウェアの標準機能では取得できないものは何か。表4中から該当するものを全て挙げ，(A)〜(H)の記号で答えよ。
解答例
解説
本文の根拠
図1
ファイルアクセスの内容（ファイル名，並びに作成，参照，更新及び削除の操作種別）
表4
(F) 参照された設定ファイルの内容又は更新された設定ファイルの内容，(G) 参照されたERP業務パッケージにおける利用者権限の内容又は更新されたERP業務パッケージにおける利用者権限の内容，(H) 参照されたバッチ処理のスケジュール又は更新されたバッチ処理のスケジュール。
解答例は“(F)，(G)，(H)”である。
表4の特権操作3は(E)〜(H)の4つで，図1のOS及びミドルウェアの標準機能で共通に取得できるのは，ファイルアクセスの内容（ファイル名と操作種別）と，コマンド，スクリプト及びプログラムの実行文である。(E)の実行文は取得できる。(F)は設定ファイルの“内容”なので，ファイル名と操作種別では足りない。(G)のERP業務パッケージにおける利用者権限と，(H)のバッチ処理のスケジュールは，図1のどの項目にも当たらない。
設問は該当するものを全て挙げる形なので，(F)，(G)，(H)の三つをそろえて書く。(F)は設定ファイルの“内容”を求めるので，ファイルアクセスの内容（ファイル名と操作種別）とは別のものである。
設問3(1)
20字以内
案1において，システムの障害発生時以外でログが収集できないのはどのようなときか。20字以内で答えよ。
解答例
解説
本文の根拠
〔A社のシステム環境〕
各DCでは電源設備の定期保守作業のために，半年に1回，4時間程度，DC内の全サーバを停止する。
図3
ネットワーク障害などでログデータの転送が失敗した場合，最大1時間再送を試行し，再送が成功しない場合は再送エラーとする。
図4
Sサーバは東京DCにだけ置かれている。
解答例は“東京DCの電源設備の保守作業のとき”である。
案1のSサーバは東京DCにだけあり，両DCのログを収集する。東京DCでは，半年に1回，4時間ほど全サーバが停止するので，その間，Sサーバが動かず，大阪DCのサーバはログを転送できない。Sエージェントは最大1時間しか再送を試みないため，保守作業が4時間続くと再送エラーになる。ディスクが一杯になって古いログを上書きするサーバもあるので，転送できなかったログは失われかねない。これが，案2でDCごとにSサーバを置く理由になる。
字数は17字で，制限の20字に収まる。大阪DCの保守作業のときは，Sサーバが動いているうえ大阪DCのサーバも止まっているので，ログが収集できないという問題は起きない。
設問3(2)
本文中の下線①について，見積もった最大データ量（Gバイト）を求めよ。
解答例
解説
本文の根拠
〔特権IDの利用〕
管理端末は，本社に200台，東京DCと大阪DCのオペレータ室にそれぞれ10台ずつ配置されており
図7
1台の管理端末を8時間使用した場合，その間のログの最大データ量は，画像データとテキストデータを合わせて70Mバイトである。
図7
各管理端末は，年間を通じて1日平均8時間利用されている。
解答例は“462”（Gバイト）である。
管理端末は，本社200台と，東京DC・大阪DCの各10台で，合計220台である。1日平均8時間使うので，1台1日あたりのログは最大70Mバイトになる。30日分では，70Mバイト × 30日 × 220台 = 462,000Mバイトで，1Gバイト＝1,000Mバイトなので，462Gバイトである。
下線①は“A社全体で発生する”ログなので，対象は220台である。単位も，Mバイトのまま書かず，設問どおりGバイトで答える。
設問3(3)
本文中の下線②について，見積もった伝送速度（Mビット／秒）を求めよ。
解答例
解説
本文の根拠
図7
製品Rを使って管理端末のログをRサーバに収集した場合，管理端末1台当たりに必要なネットワーク伝送速度は30kビット／秒である。
〔ログ収集保存機能の設計〕
製品Rを使って本社の管理端末200台から東京DCにログを収集するために必要なネットワークの伝送速度
解答例は“6”（Mビット／秒）である。
下線②は，本社の管理端末200台から東京DCへ，製品Rでログを収集するのに必要な伝送速度である。1台あたり30kビット／秒なので，30 × 200 = 6,000kビット／秒で，1Mビット／秒＝1,000kビット／秒より6Mビット／秒になる。
(2)と違い，下線②の対象は本社の管理端末200台だけである。
設問3(4)
15字以内
ログの保存にWORMテープを用いる目的を，15字以内で答えよ。
解答例
解説
本文の根拠
図8
ログを保存する際は，一度データを書き込むと再書込みが不可能な磁気テープ媒体（以下，WORM（Write Once Read Many）テープという）を用い，正副の二つの媒体に保存する。
解答例は“ログの改ざん防止のため”である。
図8の1.は，WORMテープを，一度データを書き込むと再書込みができない磁気テープ媒体と説明している。保存したログは，後から書き換えたり消したりできない。ログは，特権ID利用者の操作を後から確認するための証拠なので，保存後に特権ID利用者自身が書き換えられるようでは，監視の意味がなくなる。再書込みが不可能な媒体を使うのは，このためである。
字数は11字で，制限の15字に収まる。“ログの改ざん防止のため”は，WORMテープの性質（再書込みが不可能）と対応する。
設問3(5)
20字以内
本文中の下線③について，Y主任が，運用規程案に追加した項目の内容を，20字以内で述べよ。
解答例
解説
本文の根拠
〔特権IDの利用〕
並びに個人情報又は財務データを外部記憶媒体に保管する場合の暗号化を行っている。
表4
(C) 参照要求（又はSQL文）及び参照されたデータの内容，(D) 更新要求（又はSQL文）及び更新されたデータの内容。
解答例は“ログを保存する際は暗号化を行う。”である。
A社の情報セキュリティポリシは，個人情報又は財務データを外部記憶媒体に保管する場合の暗号化を求めている。特権操作2のログには，表4の(C)(D)のとおり，参照されたデータや更新されたデータの内容そのものが含まれる。ログに個人情報や財務データが入るため，それを保存するWORMテープにも同じ暗号化が必要になる。図8の案には，媒体の保管と運搬の記述はあるが，暗号化はなかったので，この項目を追加する。
字数は16字で，制限の20字に収まる。設問は，運用規程案に追加した項目の内容を問うているので，“暗号化を行う”という行為を，保存する対象（ログ）とともに書く。
設問4(1)
解答欄2つ
抽出した特権操作1のログに関連する，特権操作2及び特権操作3のログを，自動的に抽出できるようにログ分析機能を強化するためには，〔特権IDの利用〕における，サーバと管理端末の運用や利用の方法に関して変更又は追加が必要である。その内容を二つ挙げ，それぞれ25字以内で述べよ。
解説
本文の根拠
表1 管理端末
ドメイン管理サーバの時刻は，オペレータが，毎週月曜日の朝に，自分の腕時計を基に設定するが，時刻の正確さは重視されていない。
表1 管理端末
管理端末の利用者ID8桁のうち，上2桁がA社及び役割ごとの委託先各社に割り当てられており，各社の管理責任者が特権ID利用者個人に下6桁を割り当てている。
表1 UNIXサーバ及びPCサーバ
統一されたID体系が定義されており，情報システム部が各特権ID利用者個人に各サーバの利用者IDを割り当てている。
解答例は，①“管理端末と各サーバの時刻を同期させる。”，②“管理端末と各サーバのID体系を統一する。”である。
特権操作1のログ（サーバが取得）と，特権操作2・3のログ（製品Rが管理端末で取得）を自動的に結び付けるには，両方のログに共通する日時と利用者IDが同じ基準でなければならない。管理端末の時刻は，オペレータが毎週腕時計で合わせるだけで，正確さが重視されておらず，NTPで同期するサーバとずれる。利用者IDも，管理端末は上2桁が会社，下6桁が各社の管理責任者の割当てで，サーバは情報システム部が割り当てた統一IDなので，別の体系になっている。時刻は同期し，IDの体系は統一する。
字数は①が19字，②が20字で，制限は各25字である。講評が挙げるように，“管理端末に固定のIPアドレスを割り当てる”は，各特権操作で記録すべきデータ項目（日時，利用者ID，サーバのホスト名又はIPアドレスなど）の取り違えである。管理端末のIPアドレスは，記録すべき五つの項目に入っていない。
採点講評（IPA）
設問4(1)は，正答率が低かった。“管理端末に固定のIPアドレスを割り当てる”とした解答が多く，本文に記載されている，各特権操作に対して取得すべきデータ項目を，正確に理解していない受験者が多かった。ログ管理においては，どのようなデータ項目を取得し，どのような分析を行うかを要件として具体的に定義した上で，最適な実装方法を検討する必要があることを再認識してほしい。
設問4(2)
解答欄2つ
情報システム部の従業員では，どの特権ID利用者についての操作内容の確認が不十分となるか。表2中の役割名称で答えよ。また，その理由を，40字以内で述べよ。
〔理由〕解答例
情報システム部の従業員はオペレータの具体的な作業内容を知らないから
解説
本文の根拠
〔特権IDの利用〕
オペレータが行うシステム運用の詳細を知っている者はいない。
〔特権IDの利用〕
情報システム部の従業員は，アプリケーション管理者又はインフラ管理者のどちらか一方を担当しており，自分が所属するグループの作業内容を詳しく理解している。
解答例は，役割名称が“オペレータ”，理由が“情報システム部の従業員はオペレータの具体的な作業内容を知らないから”である。
特権操作の確認は，その操作が業務上必要だったかを，作業内容を理解したうえで判断する作業である。情報システム部の従業員は，アプリケーション管理者かインフラ管理者のどちらかの所属グループの作業内容を詳しく理解している。しかし，オペレータの役割をもつ従業員は情報システム部におらず，運用の手順も委託先のSIベンダからオペレータへ直接引き継がれたので，オペレータが行うシステム運用の詳細を知る者はいない。そのため，オペレータの操作の必要性は，情報システム部の従業員では確認できない。
字数は理由が33字で，制限の40字に収まる。アプリケーション管理者とインフラ管理者は，情報システム部の従業員がグループの中に含まれるので，確認不足にならない。
設問4(3)
解答欄2つ
各社の管理責任者が確認作業を行った場合，どのような特権操作に対する確認が不十分となるか。その操作を20字以内で述べよ。また，T氏が提案した改善案の内容を25字以内で述べよ。
解説
本文の根拠
〔特権IDの利用〕
何かの事情で担当者の手が足りなくなった場合，各社の管理責任者が特権操作を行うことがあるので，各社の管理責任者は特権ID利用者を兼務しており，利用者IDが割り当てられている。
〔特権IDの利用〕
各社の管理責任者は，作業内容が業務上必要なものであることを確認し，承認印を押印する。
〔ログ分析機能の設計〕
確認者の氏名と確認結果を記録する。
解答例は，操作が“各社の管理責任者が行う特権操作”，改善案が“特権操作を行った本人以外による確認”である。
各社の管理責任者は，特権ID利用者を兼務していて，手が足りないときには自ら特権操作を行う。一方，作業申請書の承認も，ログの確認作業も，各社の管理責任者が行う。そのため，管理責任者が行った特権操作は，自分で承認し自分で確認することになり，牽制が働かない。改善案は，その操作を，操作した本人以外の者が確認するようにする。
字数は操作が15字，内容が17字で，制限は20字と25字である。“管理責任者自身の操作”である点と，“本人以外が確認する”という対策を，それぞれの欄に分けて書く。
出典：平成23年度 秋期 情報処理安全確保支援士試験 午後Ⅱ 問2（表記を一部改変）
