社内認証システムの統合に関する問題

【H22秋SC午後2問2】

１．A社SSO(シングルサインオン)システムについて

A社はアカウント情報に関して、C-DIR用、LDAP用及びNIS用の3種類のデータ形式を用いている。LDAPのアカウント情報では、inetOrgPersonといったオブジェクトクラスによって組織の利用者の情報を管理する標準的なスキーマを用いている。例えば、製品開発部のスズキタロウ氏が社内で利用するLDAP用のアカウント情報をLDIFによってテキスト形式で示すと、図7となる。

＜図7＞略

SAMLとは、記述言語としてXMLを用いて、認証及び認可に関する情報を交換するための標準規格である。

２．C-DIR※で用いられている認証について

※C社製のディレクトリシステム。利用者、PC端末、プリンタ及びサーバから構成されるドメインという管理単位を定め、ドメインコントローラ（DC）によって管理する。DCでは、C-DIRのディレクトリに保持されるアカウント情報を用いて認証を行う。認証には、C社独自仕様のチャレンジレスポンス認証（C-CR認証）、又はKerberos認証を利用することができる。

C-CR認証では、DCが生成した擬似乱数をチャレンジとし、それを受信したクライアントで、利用者ID、パスワード及びチャレンジの連結をハッシュ化したレスポンスをDCに返信し、アクセス許可を受ける。

• 擬似乱数の生成方法に問題があり、同じ乱数が生成される場合、どのような脅威（攻撃の手順含む）が考えられるか。

⇒　チャレンジとレスポンスのペアを盗聴し、正規のレスポンスを用いてリプレイ攻撃によるなりすましをする。

• Kerberos認証において、有効期限切れのチケットが悪用されないように、DCとサーバをどうしているか

⇒　時刻同期させている

３．シングルサインオンシステムについて

A社の社内向け情報システムは、基幹業務系、Webアプリケーション向けにA社が独自開発したシングルサインオンシステム、部署ごとの部署運用系システム（一部がSSOシステムを採用しているWebアプリ）である。

【A社の認証システムに関して指摘されていた課題】

1. 情報システム全体では3種類の利用者IDが使用されている
2. 情報システムごとにパスワードルールが異なるので、同じレベルのパスワードの強度が確保されていない。
3. 認証システムを管理する部署が複数に分かれている。アカウントの運用及び認証システムの運用管理に関しても、同じレベルのセキュリティが確保されていない。
4. アカウント情報を管理するディレクトリ間の反映が一部手動でおおなわれている。過去に誤って削除したことあり。
5. セキュリティ管理の現状を踏まえると、A社SSOシステムには脆弱性がある。

【A社SSOシステムのプロトコルの動作概要】

(a)～(e)略

(f)A社Webアプリは、クッキーを検証し、有効ならば、サービスを提供する。ここで、A社SSO用のクッキーには、セッションIDやクッキーの発行日時などが設定されており、トリプルDESを用いて暗号化されている。また、すべてのA社Webアプリには、クッキーを復号するために暗号化鍵を配布している。ブラウザは、一度、クッキーの発行を受けると、有効期間内であれば、すべてのA社Webアプリにアクセスできる。

A社SSOシステムの脆弱性とは

⇒　所管部門の異なるWebアプリのすべてに同一の暗号化鍵を配布していること

A社SSOシステムには、クッキーの利用が原因となり、SSOサーバとWebアプリが同じインターネットドメイン上にないとシングルサインオンを実現できないという技術的課題があった。

検討した結果、SAML型SSOシステムを採用することにした。

【SAML型SSOシステムのプロトコル動作概要】

＜図＞略

(a)利用者のブラウザは、Webアプリにサービスを要求する際、SP用のクッキーがあれば、それを提示する。提示したクッキーが有効であることが検証された場合は(f)に進む。

(b)SPは、SAMLRequestメッセージをエンコーディングしたうえでURIに含め、サービス要求をIdPにリダイレクトする。

(c)利用者は、利用者IDとパスワードを入力し、認証を受ける。

(d)IdPは、利用者IDとパスワードを入力し、認証を受ける。

(e)SPは、SAMLResponseメッセージのディジタル署名などを検証し、有効であればSPようのクッキーを発行する。

(f)SPが稼動するWebアプリは、該当するサービスを提供する。

技術的課題に、SAML型SSOシステムではどのように対処しているか。

⇒　暗号化及びディジタル署名したSAMLResponseメッセージを用いて、IdPからSPへ認証情報を転送している。

４．統合認証システムについて

統合認証システムではアカウント情報を一元的に管理することとした。

アカウント情報のシステム間の反映に関しては、人事マスタからID管理サーバ（IDM）にアカウント情報を日次で反映し、IDMのディレクトリ（IDMマスタ）で保持し、変換後、IDMからC-DIRのディレクトリ及びLDAPにアカウント情報を即時反映する方式を採用した。

統合認証システムにおいて、【A社の認証システムに関して指摘されていた課題】の2.の私的にどのように対処しているか。

⇒　管理フォーマットを一つにし、IDMでパスワードを一元的に管理し、それを各情報システムが参照する仕組みを導入した。

【SaaS型サービス事業への展開】

A社のソフトウェアパッケージをSPと連携するように改修。WebアプリとしてA社データセンタに配備しサービスを提供する予定。

このサービスを導入する企業は、自社のイントラネットにIdPを用意すれば、導入する企業のイントラネットにあるPC端末からインターネット経由で、A社のデータセンタに配備されたSaaS型サービス事業のWebアプリを利用することが可能。運用はA社に委託できるため自社内での運用よりコストの削減が期待できる一方で、A社にとっても、IdPを顧客のイントラネットに構築することは運用管理上のメリットがある。

そのメリットとは何か。

⇒　SaaS型サービスのアカウント管理と運用を、必要に応じて、A社から切り分けることが可能となる。

転職サイトにおける個人情報保護に関する問題

【H22春SC午後1問3】

• P社（人材紹介会社）の転職サイト
• 応募入力画面（求職者が利用）
• 応募時の個人プロフィールをWebサーバから求人企業にメールで自動送信（暗号化されていない）
• 暗号化されていないメールでの求職者の個人情報を送信することは、漏えいの危険性がある　⇒　改善することとした

１．求職者の個人情報保護

【案１：メールの暗号化】

個人プロフィールを送信するメールを以下の方法で暗号化する。

S/MIME

⇒　各求人企業が「S/MIME証明書」を用意しなければならない。時間とコストがかかる（実現は難しい）。

PGP

⇒　自社で鍵の生成システムを用意できるが、クライアントPCのメールソフトが対応していないことが多い（実現は難しい）

※通常、証明書のフィンガプリントを確認する（紙媒体で入手する）

【案２：パスワード付きファイルの添付】

個人プロフィールを含む文書ファイルなどをパスワードで保護した状態でメールに添付して送信する。

オンラインでパスワードを入力させる場合は、施行回数を多くできないように制限できる（パスワードエラーが一定回数連続して発生したら、ログインを一定時間拒絶するという対策）が、添付ファイルを攻撃者に入手されたら、ファイルに対してオフラインで直接的に攻撃（施行回数制限なし、解析ツール等使用）される危険性があるため運用は難しい。

【案３：求人企業向けWebページの追加】

応募があったら、個人プロフィールを含めず、応募があったことだけを通知するメールを送信する。

求人企業は、パスワード認証とTLS(SSL)で保護されている求人企業向けWebページから個人プロフィールをダウンロードする。

⇒　採用

２．求人企業向けWebページのパスワード

利用者IDは求人企業の各利用者にメールで送信するが、初期パスワードの通知書の郵送先は求人企業の登記事項証明書に記載された所在地とする

⇒　あて先に実在する求人企業の従業員からの申し込みであることを確認するため

【パスワード再設定手順（案）】

1. 求人企業の利用者が、パスワード再設定の申請ページに利用者IDを入力する。
2. Webアプリケーションが自動的に、パスワード再設定の申請があった旨と、パスワード再設定の実行ページのURLを、利用者のメールアドレスあてにメールで通知する。URLには十分長いランダムな文字列を含める。
3. 求人企業の利用者が、URLの示すパスワード再設定の実行ページにアクセスし、新パスワードを入力すると新パスワードが設定される。
4. パスワード再設定の実行ページのURLを通知後、20分以内にアクセスがない場合は、実行ページのURLを自動的に無効にする。

上記手順では第三者にパスワードを再設定されてしまう危険性がある。

⇒　メールを盗聴し、利用者よりも先に再設定実行ページにアクセスする手口

パスワード再設定手順の見直し案

⇒　パスワード再設定実行ページに、初期パスワードの入力を追加する。

情報システムの特権管理に関する問題

【H21春SC午後1問4】

• 上場企業情報システム部のサーバ（80台）
• 複数のOS、DBMS、APが稼動
• それぞれのOS、DBMS、APにシステム管理特権が付与された特権IDが一つずつ登録されている
• システム管理者10名ですべての特権IDとパスワードを共用している
• セキュリティ診断の結果、情報システムの特権ID管理が十分でない（内部者の不正使用を防止及び発見する仕組みが構築されていない）との指摘をうけたため、改善することとした。

１．特権ID管理の要件

上場企業を対象に、内部統制の評価及び報告を求める法律

⇒　金融商品取引法

特権IDの共用

⇒　改善が必要。ログからはだれが不正使用を行ったのか特定できない。

内部不正を発見する仕組み

• 特権IDの使用目的、使用者、使用する特権IDを記入した特権ID利用申請書を使用日ごとに課長に提出し、事前に申請してもらう運用にする。
• ログのレビューを月に１回実施し、不正な使用がなかったことを確認する。

２．特権ID管理の運用

UNIXでログを収集、転送する方式

⇒　syslog

あるサーバのOSで特権IDの利用申請があったのに、ログが残っていないものがあった。確認したところ、ある従業員が誤ってシステムのリストアの際にログファイルを上書きしてしまったとのこと。

ログを保護するための対策

⇒　ログサーバの特権ID使用者とほかのサーバの特権ID使用者を分離（ログサーバを購入）

不正の可能性が考えられる特権IDの使用が発見されたときだけアラートを発生させ、電子メールで通知する仕組みをログサーバに導入

【アラートの発生条件】

1. ひとつのサーバで１ヶ月ログインしていない特権IDでログインされたとき（普段使わないIDの使用）
2. 全サーバ累計で一人が１日で10回ログインを行ったとき（頻繁な使用）
3. ログアウト時にログインからの時間が2時間を超えているとき（長時間の使用）
4. 特権IDの追加が行われたとき
5. システム設定が変更されたとき
6. DBMSに対してSQLが実行されたとき

特権IDをもっていない人が特権IDを使用しようとする行為があったときのアラート

⇒　特権IDの認証が失敗したとき

アラートを設定していることはシステム管理者に周知するが、具体的なアラートの発生条件は伝えない

• システム管理者による不正行為の実行を抑止するために周知する。
• アラートの発生条件を回避しようとする行為を防止するため、アラートが発生しないような不正使用方法を発見されないようにするために、具体的なアラートの発生条件は伝えない。

DBには財務に関わる重要なデータが管理されている。財務報告の信頼性を確保するために、

特権IDに関するDBのログの個々の記録について確認する内容

• 特権IDでDBのデータを変更した処理のログに対応する特権ID利用申請書が提出されていること
• DBのデータを変更した処理が、すべて業務目的に基づいていること

立証しようとしていること

• DBMS内の財務データが特権によって改ざんされていないこと
• DBMS内の財務データの完全性

SNSのセキュリティに関する問題

【H27秋AP午後問1】

１．SNSサイトへの不正ログイン

ログインを試みるアクセスあり。パスワードは氏名と生年月日を組み合わせたものだった

⇒　『類推攻撃』

⇒　『パスワードリスト攻撃』に備え、他のサービスについても同一のパスワードを使用している場合は変更してもらう

２．不正ログインの足がかりとなった情報

会員登録（アカウント名、パスワード、電子メールアドレス、ニックネーム、プロフィール情報を登録）のうち、

⇒　プロフィール情報、ニックネーム、アカウント名

３．Cookieによる認証は何を認証するものか

⇒　Webブラウザ

４．不正ログイン対策

悪意を持った第三者がSNSサイトにログインできないように、アカウント名とパスワードによる認証に加え、Cookieによる認証を追加する。

1. ユーザ（Webブラウザ）にて会員登録（アカウント名、パスワード、電子メールアドレス、ニックネーム、プロフィール情報を登録）する。
2. Cookie発行機能のURLが記載された電子メールがユーザに送信される（1時間のみ有効）。
3. ユーザはメールソフトでメールを受信、メール内のURLからCookie発行機能にWebブラウザを用いてアクセスする（会員情報として入力された電子メールアドレスの有効性を確認できる）。
4. ユーザがアカウント名とパスワードを入力して認証を完了すると、ログイン用Cookieが発行される（半年間有効。ログインするたびに有効期間が半年更新される）。
5. ログインする時はアカウント名、パスワード、ログイン用Cookieがログイン機能に送信される。
6. ログイン機能では送信されたログイン用Cookieがその会員に発行されたログイン用Cookieか確認し、異なる場合はログインを拒否する。
7. 通信は暗号化し、悪意を持った第三者が盗聴できないようにする。

ポケットスタディ 情報セキュリティスペシャリスト

お手頃サイズで持ち歩きに便利な書籍です。

午前II、午後I,IIに対応しています。

直前になりましたが、こちらはいつも持ち歩いたり、子どもが部屋で遊んでいるときに読んでいます。

ポケットスタディ 情報セキュリティスペシャリスト 第2版 (情報処理技術者試験)

検疫ネットワークに関する問題

【H22秋AP午後問9】

検疫システム：セキュリティ対策の検査を行い、セキュリティ対策が不十分な端末を社内ネットワークに接続させず、隔離したり、必要なセキュリティ対策を施したりする機能をもつ。

１．認証と検疫の処理の流れ

1. 所属VLANが設定されていないエリアのPCは、それぞれのエリア内のL2SWの空きポートに接続されると、L2SWやL3SWを介して、a「RADIUS」サーバと限定的に通信し、端末認証を受ける。PCから送られたユーザの認証情報をaサーバが受信すると、aサーバは、ユーザ情報をb「ディレクトリ」サーバに問い合わせ、ユーザ認証を行う。ユーザ認証がc「失敗」したPCは、引き続き、VLANが設定されないままとなる。
2. ユーザ認証がd「成功」したPCの所属VLANを、検疫エリアに配置されたサーバと同じくe「検疫用VLAN」に設定して、そのPCを隔離する。
3. 検疫サーバによる検査行われ、不合格となったPCは、検査が合格となるまでeに隔離され、検疫サーバによってセキュリティパッチや設定変更が行われる。さらにウィルス対策サーバによってウィルスチェックが行われる。
4. 検査が合格となったPCは、bサーバに登録された所属VLANIDに従い、検疫システムによって、所属するVLANが割り当てられる。
5. 所属するVLANを割り当てられたPCが、h「DHCP」サーバにIPアドレスを要求すると、hサーバは、VLANIDに応じたIPアドレスを動的に割り当てる。IPアドレスが割り当てられたPCは、社内ネットワークを利用することができる。

3の検査を隔離して行う理由

⇒　ウィルスなどの二次感染の範囲を限定できるから

勉強方法

こちらの試験対策書に沿って勉強しています。

2016 情報セキュリティスペシャリスト 「専門知識+午後問題」の重点対策 (午後対策シリーズ)

ピックアップされた過去問に取り組み、間違ってしまった問題や重要用語について残しておこうと思います。

※試験まで残り少ないので、メモ程度になってしまうかもしれません。