情報処理技術者試験 セキュリティスペシャリスト 午後2 簡易解説（自作なのでbugあると思います）

H21.春

問1

設問1
ハッシュ関数は256bitより長いSHA-2へ切替されている。
f.はウエブブラウザでオレオレ証明書を利用する時と同様。インターネット上のCA局へ公開鍵の検証ができないので、ルート証明書を予め導入しておく必要がある。むろん、このルート証明書は安全に届けられたものを導入しないと意味が無い。

設問2
ウイルス定義ファイルは極力最新化したいが、PCを社外へ持ち出す前提ではPCを社内ネットワークへ接続しないと定義ファイルが更新されない。
そのため、インターネットへ接続可能であれば、そちらの経路から定義ファイを取得する。

設問3
PKIの証明書や暗号鍵が流出した場合は容易になりすましが可能となる。
そのため、証明書と暗号鍵を管理外のPCへ導入しないこと、PCの盗難、紛失、他人の利用を防止することが必要となる。

設問4
問題文に記載されているように、公開鍵から秘密鍵を計算できた場合、以下の手順で受信者に改ざんしたデータを送信者を偽っても気付かれずに出来る。

本来のデータを改ざんする
改ざんしたデータのハッシュ値を求める
ハッシュ値に対して計算した秘密鍵で電子署名
送信元を偽って相手に届ける

送信者の公開鍵で電子署名からハッシュ値を取り出す
データからハッシュ値を生成する
比較する
この場合、電子署名は正しく復号されハッシュ値が一致し、受信者からはデータが改ざんされておらず、送信者は公開鍵の発行元と見える。

設問5
(1)設問3と同様にPKIではCA局の秘密鍵があれば、攻撃者の証明書に正当なものであると署名できる。このような偽証明書を作成された場合、CA局の公開鍵で確認しても正しい証明書を判断してしまうので、大変危険である。

(2)CA局の中身を細かく見ていくと、証明書を発行して良いか判断するRA局と実際に発行するIA局に機能が大別される。問題文を見ると「RA局の役割を社員が担う」とあるので、対応する作業工程を選択すれば良い。

(3)公開鍵暗号では利用者も秘密鍵と公開鍵の鍵ペア作成が必要となる。問題文では利用者に鍵ペア作成までさせるのは荷が重いのでCA局で行うとしている。よって、CA局に利用者の秘密鍵が残るので、これを破棄、または安全に管理する必要がある。

設問6
所謂オレオレ証明書では証明書の確認ができない問題。自営CA局のルート証明書を配布して導入すれば良いのだが、社外では予め済ませておくことは難しい。また、証明書を安全に配布する必要もある。


問2


H21.秋

問1


問2

設問1
IP電話はRTPがIP電話のデータ本体、SIPがIP電話の制御のサービスである。通話開始前はSIPによりSIPサーバと制御通信を行い、通話相手と接続後は直接RTPで音声データを交換する。

設問2
動的にポート開放を行えないTネットワークで使用しているFWはIP電話導入に伴い、多数のポートを常時開放する必要がある。そのためFWxと比較してDoS攻撃に使われるポートの通信も通過させてしまう可能性が高くなる。

設問3
開発、製造LANには機密情報が格納されているため、相対的に重要度が低い工場LANからの接続は避けるべきである。そのため開発、製造LANはFWxで工場LANと隔離している。よって、工場LANに位置する箇所へ情報共有サーバを設置するのが望ましい。

設問4
(1)テンペスト攻撃や、ケーブルへのPC接続攻撃の防御。

(2)SPCは機密区画である執務エリアに設置されている。しかしながら、元は製造LANに接続しており、製造サーバへアクセスして製造装置に製造データを投入する役割がある。そして製造サーバには極秘情報が格納されるようになってきている。
表1セキュリティポリシーでは機密区画は「例外的に（製造サーバにある）極秘情報を保有（中略）適切な対処を施す」としている。

SPCは本来極秘区画に設置するのが最適であるが、上述のように機密区画に設置している。
SPCを製造LANに接続すればアクセス制御はできない。
そのため、次善の策として工場LANへ接続しFWxによりアクセス制御する。

設問5

(1)
(2)PEAPはパスワードを利用者が入力する事により、利用者を認証している。EAP-TLSはクライアント証明書を端末が保有しているかで認証しているので、利用端末を認証している。
(3)NPCは共有端末となっているので、誰が何時、どの端末を利用したかが判らない。




H22.春

問1
難易度は低いが、セキュリティ周りの基本技術が全て盛り込まれている。

設問1
(1)SSHでは接続先の証明書を確認することで、接続先が正しい接続先か確認できる。PGP署名の仕組みと同様にフィンガプリントを見るだけでは真正の確認は出来ない。別途、安全な方法で通知されたフィンガプリントと比較することで、正しい接続先かが確認できる。
（そういう意味では「公開鍵が正しい」という解答例は微妙である。「正しい」というのは何が正しいのか明記していないからだ）
(2)リモートメンテナンスのノートPCは接続プロバイダから固定IPアドレス割当を受けることで、Y社サーバ側で接続元IPアドレス制限を行い、より安全な接続元制限が可能となる。

設問2
(1)社内DNSキャッシュサーバは社外上位DNSへ問い合わせを行う。問い合わせ応答時に偽装した応答を送りつけられて、これを正しい応答として受信する可能性がある。自分の問い合わせに対する応答かをデジタル署名により確認するのがDNSSECの考え方になっている。
(2)DNSキャッシュが汚染されると、正しい接続先ではなく汚染された接続先へ接続してしまう。
(3)上記(1)の様にデジタル署名による問い合わせ応答の確認が望ましいが、双方での対応が必要で普及しているとは言い難い。問い合わせの偽装応答は、送信元ポートへ送りつけられる。それであれば問い合わせポートをランダムに変更すれば受信する可能性を減らせる。

設問3
(1)迷惑メール受信拒否には、怪しい送信元から送出されたメールを受け取らないという方法がある。メールエンベロープの送信元ドメインが実在していない、エンベロープと異なるドメインから送信されている、というメールは怪しいので受信拒否をすれば良い。
(2)p.7を確認すると「catalog.y-sha.co.jpのサブドメイン名を使ったメール送信元は無い」と判る。全てのメールは「y-sha.co.jp」が送信元となる。よって、catalog.y-sha.co.jpのドメイン名で送出するメールサーバは無いので、SPF TXTレコードでは+ip4:x.y.z.nの部分は記載せず、-allのみ設定する。
(3)SMTPオープンリレー防止方法の問題。自社社外SMTPサーバは自社宛のメールを受信するのみで、他者宛のメールを「社外から」受信する事はありえない。（社内SMTPサーバから受信して、相手先ドメインのSMTPサーバへ届けるのみ）
(4)spam送信はTO:へ相手先を記載して送信する以外に、FROM:へ届けたい宛先を記載しTO:は適当に記載してエラー返信を使って送信する方法がある。

設問4
(1)(2)(3)表5を確認すると「問い合わせ元:すべて」の非再帰的な問い合わせ（このDNSに対して他社の社外DNS経由ではなく、インターネットへ直接接続したPC等からの問い合わせ）には応答すると判る。次に表6を確認すると、「キャッシュ領域の保持されているY社管理ドメイン名以外のドメイン」問い合わせはキャッシュを用いて応答する（「左に同じ」）とある。社外からの問い合わせは非再帰、再帰を問わず、Y社管理ドメインのものしか応答する必要は無い。


H.22秋

問1
開発問題を含むのでパス。


問2

設問1
午前2の知識で良いが、b.のみ初見。
LDIF(LDAP Data Interchange Format)はLDAP用の書式と思えば良い様子。
http://gihyo.jp/admin/serial/01/ldap/0002


設問2
(1)チャレンジ&レスポンス認証はチャレンジ（=乱数）が毎回変化するため、チャレンジとパスワードから生成されるレスポンスが毎回変化する特徴がある。この特徴のため、通信を盗聴されてレスポンスを認証に再利用されても認証されない。しかし、問題文のようにチャレンジが同一ならば、必要なレスポンスは同一になってしまう。そのため、同一レスポンスで認証できることになってしまう。
個人的には「リプレイ攻撃」の和訳「反射攻撃」は好みではない。「リフレクション攻撃」の和訳も「反射攻撃」であり、違いが分かりにくい。「反復攻撃」が適切と思う。

https://ja.wikipedia.org/wiki/%E5%8F%8D%E5%B0%84%E6%94%BB%E6%92%83

(2)WindowsのActive DirectoryもKerberos認証を利用しており、問題文にあるとおり有効期限切れのチケットが悪用されないように、ドメイン参加サーバはActive Directoryサーバと時刻同期を行う。

設問3
(1)問題文p.17を見ると、クッキーが暗号化されていること、暗号化方式は共通鍵のトリプルDESで、共通鍵を各業務サーバへ配布している事が判る。

(2)A-SSOはcookieを利用したエージェント型のSSOである。SSOサーバがcookieを端末へ発行、端末がcookieをログオン先のサーバへ渡し、ログオン先のサーバが確認する。
処でcookieは「同一ドメイン」のみ有効である。どこの馬の骨とも判らないドメインが発行したcookieはセキュリティ上受け入れないという思想になっているため、問題文の様にSSOサーバとログオン先のサーバが同一ドメイン上に配置される必要がある。
問題文p.20の図9を見るとcookieに相当するものはSAML responseと判る。

設問4
(1) 図1(2)の指摘事項はシステム毎のパスワードルールが同一ではない、というもの。統合認証環境を用意する事でこれを解消する。回答要旨としては以下3点があれば良い。
パスワードルールの決定
IDMでの一元管理
これを各システムへ自動反映

(2)設問3(2)で示されている通り、SAML型SSOでは顧客企業のSSOサーバとA社のサービスとが別ドメイン上にあっても統合可能となる。これにより、SSOサーバ側でのID&パスワード管理とA社のサービスとを分離、運用できる。

設問5
(1)(2)製品サポート部、製品開発部のシステムリプレースは2014年になっているため、2014年までにA-SSOを移行すれば良い。
一方、問題文p.13の表によればイントラ系のサーバマシン群のベンダサポートは2012年終了とあるので、A-SSOは2012年中に移行を済ませる必要がある。


H.23春

問1

設問1
メールサーバ類の基本知識。

設問2
(1)(2)MUA（メールソフト）のFrom行は利用者が任意に設定できる事に留意する。

設問3
(1)mail以外の外部への通信はプロキシ経由となる。FWのログは接続元がプロキシになるので、当該時刻の通信ログを見ても誰のPCかを判別できない。
(2)図2(3)の参照。サーバ、端末両端でウイルス検知が望ましい。

設問4
(1)図4メールソフト機能を参照すると、ドメイン単位の送信先警告が可能とある。さらに表2の警告除外リストを見るとサブドメイン単位でも判別可能と判る。それであれば、社外メンバが登録されている場合は別のサブドメンとして、表2の警告除外リスト外とすればメールソフトで警告が表示される。
(2)ウイルススキャンを社内メールサーバで実行するが、表7の設定ではML用のメールは社内メールサーバを素通りしている。
(3)p.4 [メールシステムの概要]では「社内メールサーバの許可アドレスリストにはPCネットワークのIPアドレスブロックが登録されている」とある。MLサーバはブロック外なので別途追加が必要となる。
(4)汚染されたシステムを連絡に用いる事は適切ではない。
(5)典型的なML管理問題。MLではP社外所属者は社外の所属会社が送信元となり、社外の送信元ホストの情報を持つ。これをMLで社外へ配信した場合、MTAのSPFでは送信元ホストがP社ではないと判断する。そのため、メールエンベロープのFromのみP社のML管理者にして、メールヘッダのFromは元の送信者の物としておくと迷惑メールとして判定されない。またMUAでも元の送信者が送信元として表示される。

設問5
(1)(2)省略


H.23秋

問1


問2

設問1
基本問題。ログ監査、解析を含む問題ではNTPによるサーバ時刻同期有無、同期設定の追加を問われる設問があるので、NTP設定状況を意識すること。

設問2
(1)p.16で「特権ID利用者が管理端末からの各サーバにアクセスする際の通信においても暗号化」とある。
(2)図2 を参照すると製品Rはキーキャプチャ方式のログ取得と判る。入力した文字は全てキャプチャされるが、複数ウインドで作業する場合は、どのウインドで入力しているのかは区別できない。ログオフ操作は明示的に「〜サーバからログオフする」というコマンド書式ではないので、複数ウインドで作業している場合はどのウインドでログオフ操作をしたのか判別できない。
(3)p.22-23で「ログの保存及び分析のために大量のディスク資源を追加する必要がある」とある。
(4)表5にてシステム1,2でログ取得は表単位、3,4はユーザ単位と判る。システム1,2では一般ユーザ（特権操作をしない）の操作も同一表であれば全て記録されてしまう。
(5)R製品の特性から表4(E)(F)(G)(H)のどれが取得可能か考える。
（(F)は設定ファイルの内容なので、理解できるが(G)(H)の様に参照更新をコマンドで文字列として入力しているのか、設定ファイルを用いているのか判らない設問では回答が困難かと思う）

設問3
(1)p.16 「電源設備の定期保守」を参照
（データセンタで停止必要なのは如何なものかと思うが）
(2)(3)計算問題
(4)ログの改竄防止方法
(5)ログに機密情報を含むので、安全にバックアップを運搬、盗難時のリスク低減をする必要がある。

設問4
(1)表1より、管理端末の時刻同期が十分でないこと、ID体系が統一されていない事が判る。端末は各社の管理者が自社要員へ任意にIDを割当てているので、A社でIDを割当てているサーバとの整合性を取るのが難しい。
(2)p.18「運用手順は、手順の概要を記した引継ぎ資料と口頭説明」を参照。
（設問の日本語は今一つ良く判らなかった）
(3)監査と被監査とは分離するという原則。




H.24春

問1

設問1
基本問題

設問2
(1)(2)マルウエア活動の確認方法。当該は特定Webへ直接、プロキシ経由両方で通信を試行する。「活動がなかったこと」の確認なので、通信に失敗するがFWでPCから特定Webへの直接通信有無も確認が必要。
(3)常識問題
（回答例は当たり前なのだが、他のマルウエアで通信が妨害されているというのもあるのでは？）
(4)p.3「出張先で他の従業員のPCを借用して」を参照。

設問3
(1)迷惑メール対策の送信ドメイン認証にSPFを用いる。DR時には外部メールDRサーバがメール送信を行なうのでTXTレコードに予め記述しておく。
(2)
（回答例は判らないのでもないが、それを防止するために図6(1)の運用ではなく設問3(1)を予め実行しておくのでは...）
(3)表2 FW-Iのルール設定を参照。

設問4
(1)(2)DR時はイントラ等への情報参照が殺到するので文字主体の情報提供に努め、帯域を使うコンテンツへのアクセスを絞る。

設問5
(1)DRへの切替、切戻し手順の考え方。DR系を通常系とパッチ等を同期させる必要がある。図4 (5)で修正プログラム適用は常時行なう旨あるので、他に必要な物が何かを探す。DR系へ切り替え中は通常系にパッチ等が適用できないので、これを適用する。




H.24秋

問2

設問1
(1)(2)(3)無線LANの基本。事前共通鍵での認証は自宅等の接続者が変化しない環境では運用が容易だが、企業の様に後日使用を禁止したい場合は運用負荷が高い。

設問2
(1)MACアドレスは容易に変更できる。SSIDをステルス化しても、SSIDを明示的に指定してプローブ要求（動的スキャン）すれば応答有無でSSIDが判る。
（解答例の「SSIDは傍受可能」というのはパッシブスキャンを指している気がする。パッシブスキャンされないためにSSIDのステルス化をしているのだと思うが...）
(2)p.17 (2)会議室利用環境に関する要望より、会議室からWebサイト閲覧が要件と判る。

設問3
(1)表1 のセキュリティ周りの機能要件を参照する。
(2)表2そのまま
（当たり前すぎて良く判らなかった）
(3)PCを使用しないときはスクリーンロックまたはログオフする。

設問4
(1)簡単
(2)p.18で端末認証にクライアント証明書を端末へ導入していると判る。来客者向けに証明書発行と導入を行なうのは運用負荷が高いので、本設問では事前共有鍵（パスワード入力）としている。
(3)簡単




H.25春

問2

設問1
基本問題

設問2
(1)メール経由のウイルス感染はPC単体の対策も必要だが、メールサーバでのウイルススキャンも必要である。外部から内部へのメールスキャンも必要だが、内部から外部、内部間でのウイルス対策にも留意する。
(2)(3)オープンリレー対策

設問3
POP before SMTPで送信許可は接続元IPアドレスでの認証である。DHCP運用ではIPアドレス回収、配賦で同一IPアドレスが他の端末に配賦される可能性がある。

設問4
(1)メール添付書類が暗号化されていた場合、FW、ウイルススキャンでは検知されない。Webメールでhttps通信を利用している場合も同様。
(2)bccではメールヘッダに宛先は記載されない。しかしメールエンベロープにはbccであっても届け先のメールアドレスが記載される。
(3)アーカイヴ対象の特許情報メールは社外から届く事はありえない。よって、外部メールサーバの拒否リスト宛先として登録する。
(4)送信メールアーカイヴと持ち出し牽制。

設問5
(1)タイムスタンプの効用。スタンプ時（以前に）に存在していたこと、改竄された場合判ること。改竄の防止ではない点に留意する。
(2)バックアップデータの安全な運搬と暗号化。H.23秋 設問3と同様。
(3)鍵の脆化問題。計算機性能が向上すると将来的には鍵は破られてしまう。




H.25秋

問1

設問1
(1)ウイルス感染時の対処は、先ずLANケーブルを抜き二次被害を防止する。その後は証拠保全のためPC内のファイル、設定等を変更せず保持する。
(2)図2 ではウイルスPは他のPCへの感染機能を持たないが、他のウイルス感染も想定して先ずはLANケーブルを抜く。

設問2
(1)設問1(1)に同じ
(2)電子メールのreceivedは受信者が一番上、送信者が一番下になる。8行目が最初のReceivedであり、freefree-web-mail.comからhttp経由で送信したというヘッダになっている。
(3)(4)httpで使用するポート番号の知識。webサーバ自体が稼動していない場合はレスポンス無しになる。ア,イ,ウはhttpサーバ自体は稼動しているが、該当するコンテンツが無いといったものなので、稼動自体はしていると判る。

設問3
(1)図10 では14:10に感染、14:11からGETリクエスト送信を開始していると判るので、14:10のタイムスタンプのファイルから確認が必要。
(2)(3)Lさん宛メールはL3 SW経由でメールサーバから送られている。図13 を参照するとL3 SWのMACアドレスとIPアドレスとの対比が書き換えられている。本来、L3 SW MAC & L3 SW IP,のARP組み合わせが正しい。しかし図13ではL3 SW IP & NさんPC MACとなり、L3 SW IPアドレス宛通信がNさんPCのMACアドレスへ解決され、NさんPCへ盗聴されていたと推測できる。本来はL2 SWであればMACアドレス学習により、LさんPC-L3 SWとNさんPC-L3 SW間の通信は隔離される。
(4)上記(2)の攻撃はL3 SWで隔離された他のセグメントには波及しない。192.168.1.0/24のセグメントに対して有効な攻撃となる。

設問4
(1)最新パッチ適用は必要だが業務アプリの検証も忘れない。
(2)表3 項番1を参照。「現状は利用してない」「現状は無効」の記述は設問で「有効にする」の解答をする事が多い。
(3)マルウエアPのみであれば、特定のC&Cサーバをブラックリスト登録で防御できるが、p.13で「マルウエアPを含め、多くのマルウエアとC&Cサーバ」とあるので、プロキシサーバの利用者認証の方が防御範囲が広く出来る。
(4)汚染されているのはNさんPCである。LさんPCでFWにより通信を制御した場合、LさんPCの業務に影響が出る。


問2

設問1
(1)問題文の要件を読み取る。スマートフォンからのアクセスは「社内Webサーバへのアクセス禁止」「Webメールのみ利用可能」とある。これに準じないサービス利用を可能にする通信があるかを確認する。
(2)上記の要件を満たすために、案2ではモバイルPCとスマートフォンの接続先DMZを分けて、各DMZから社内システムへ接続可能なものをそれぞれ異なったものにする。
(3)また案1で、接続IDを1個人がモバイルPC、スマートフォンで共用している。そのため、スマートフォン紛失時に接続IDを無効化すると、モバイルPC接続も不可になってしまう。
(4)表5の対策でC15以外は、D社自身のネットワークや運用対策、製品EのMDMによるスマートフォン管理機能で充足している。

設問2
(1)製品Eは管理用の通信をinternet上のサーバと行う。対して携帯電話事業者のサービスはキャリア通信網を利用している。そのため、WiFi接続時に製品Eは携帯電話の制御が出来るが、携帯電話事業者のサービスでは制御できない。
(2)android,iPhoneではGoogleやiCloudの自動連携機能があり、クラウド上へデータを定期転送、データ保護の仕組みがある。

設問3
BYOD（Bring Your Own Device、個人端末の業務使用）運用では、業務都合でデータ消去されるリスクがある。



H.26春

問2

設問1
(1)(2)ウイルス感染時の証拠保全の基本。
(3)???

設問2
(1)(2)メンテナンス用の接続はインターネット経由なので暗号化を原則、接続元を限定する。

設問3
(1)EV-SSL証明書は発行元組織の厳密な審査が行われ、証明書の発行元だけでなく、Webサイトの運営者情報もブラウザ上で明確に判るようになっている。今回の様にプロキシでSSL復号と再暗号化を行なうとクライアント側から見える証明書はプロキシサーバのものになってしまい、EV-SSL証明書ではなく通常のSSL証明書になる。
(2)表7 「ユーザ定義リスト1」は表6を参照すると項番1の「事務サーバ,設計管理サーバ,CAD/CAMシステム」に対して適用するものである。PCのhttpsアクセスに適用するものではないので、U銀行を含めてはいけない。

設問4
p.22 [ログの取得及び管理方法の見直し」で「攻撃者が用意したサーバへのウイルスからの通信」とあるので、Webサーバが外部へ通信するものを全部拒否する。Webサーバは他の社内システムと連携してデータ授受等はしていないため、一律拒否でよい。

設問5
(1)特定の相手としかデータ交換を許可したくないという要求があれば、クライアント証明書を使用する。
(2)
（正直、当たり前だ！という問題だが...）
(3)禁止できないとあるので、プロキシ経由通信とメール通信とを検討する。D社環境はDMZ上のメールサーバは「内部メールサーバ」であり、「外部メールサーバ」はF社に置かれている。図1には明記していないので解答時には留意すること。
(4)



H.26秋





H.27春

問1

設問1
(1)(2)DNSへのCP攻撃、オープンリゾルバを用いたreflection攻撃の基礎知識。
(3)(4)オープンリレーとその対策。メールの厳密な宛先はメールヘッダではなく、メールエンベロープ（封筒）に記載されたものを基準に判断が必要。

設問2
spam送信はTO:へ相手先を記載して送信する以外に、FROM:へ届けたい宛先を記載しTO:は適当に記載してエラー返信を使って送信する方法がある。

設問3
検疫ネットワークでは必要最小限の通信先を許可して、社内ネットワーク等から隔離する。通信先は最新パッチ、パターンファイル入手先とする。

設問4
(1)設問3に同じ
(2)図5の中継サーバへの最終接続先サーバの指定方法はサブドメイン名を用いている。解答例では部分一致としているが、ドメイン単位（example.net）でのブラックリストでも良い。（ブラックリストの登録書式による）
(3)kouhou@n-sha.co.jp宛に攻撃メールが届いているので、前述のメールを受け取る広報グループへ確認依頼をする。
（一般的には同一ドメイン宛に大量に攻撃メールを送りつけるので、対象は社内全部が良いと思うが）
(4)運用上、黒判定だけでなく、灰色判定も管理者へ通知した方が安全である。

設問5
スキャンやパターンファイルが更新されていない場合、管理者権限で強制適用する。

設問6
(1)(2)問い合わせフォームを用いたスパム、攻撃メールの送信方法。
（そもそもHTMLメール対応やURLをそのまま開くメーラが良くないのだが）


問2

設問1
特に機器制御用PCは互換性等の問題でセキュリティパッチ、アンチウイルスソフトが導入されていない、製造元での動作保証をしない場合が多い。なお、本問では製造用PC、製造統合管理サーバ、製造装置の3種類への感染が考えられるが、本文中に対策済、未対策の記述があるので、留意すること。反射的に製造PCが未対策と考えないこと。

設問2
(1)(2)端末セキュリティの原則。脆弱性対策パッチは遅滞なく適用するが、事前のシステム動作確認が必須である。

設問3
（私見だがg.は愚問）

設問4
(1)インターネット経由での接続元制限の基本知識。グローバルIPアドレスは変化する可能性がある。NAT,Proxy経由で接続しているPC群は個別PCを識別できない。
(2)
(3)
(4)クライアント証明書は端末単位（機器単位）に発行する。当該端末の盗難、廃棄時にはクライアント証明書のシリアル番号をCRLへ登録すれば無効化できる。




H.27秋

問1

設問1
Thin Clientの基本知識。従来クライアントPC上で動作していた全てのアプリケーションはTCサーバ上（例えばXenAPP等）で動作することを意識して通信内容を考えれば良い。

設問2
(1)添付ファイルが暗号化されているとウイルススキャンは効かない。SSL通信も同様。
(2)類似の問題がDHCP + POP before SMTPのメール送信時認証にも存在する。
(3)(4)(5)設問1に同じ

設問3
(1)(2)設問1に同じ

設問4
(1)計算問題
(2)TC系サーバ以外全部が同等のセキュリティ基準を満たすために必要となる。

設問5
監査と被監査部門は分離独立していなければならないという原則。


問2




H.28春

問2

設問1
(1)(2)httpサーバが接続してきたブラウザ種別を認識するためにuser-agentという概念がある。
（最近は少ないですが、IEとNetscapeとで挙動が大きく違うためUA判断でHTMLを変えるという時代もありました...）

設問2
午前2でも出てこない単語なので記憶する

設問3
(1)午前2でも出てこない単語なので記憶する。データ流出は分割して送信するという方法も忘れずに。
(2)簡単

設問4
他には「棚卸し」等も解答例として考えられる。

設問5
(1)ハードディスク暗号化の基礎知識。HDD透過型暗号化は、OSより下の階層でHDDを暗号化している。そのため上位層（この例ではOS）からデータは平文として扱える。
(2)クライアントPCのシステムリカバリに相当する操作となる。
(3)VDI端末へスクリーンキャプチャ、キーロガーによる攻撃があった場合は情報窃取が可能である。
(4)Thin Client,VDIではクライアントPC上で動作していた全てのアプリケーションはVDIサーバ（XenAPP等）で実行する。そのためアプリケーションのアクセス元はVDIサーバになる。