問1 認証・認可基盤構築の実施計画
認証・認可基盤構築の実施計画に関する次の記述を読んで，設問1〜4に答えよ。
X社は，従業者数10,000名の大手小売業である。X社は，各事業組織の独立性が高く，それぞれが必要な業務システムを開発し，情報システム部は主に基盤の提供，業務システムの開発ガイドラインの提供及び業務システムの運用管理を行っている。CIOは，ITガバナンスが不十分であると認識しており，効率的なIT運用を図ると同時に，セキュリティ管理の強化や技術標準の確立などを急ぐ必要があると考えている。
X社は戦略的に経営統合を行い，成長を図ってきた。現在，Y社と1年後の経営統合を目指して交渉を進めている。
X社の経営トップは，経営統合のためには，統合両社の従業者による情報共有や連携作業を安全にかつ効率よく行う必要があると考えている。そこで，CIOは，情報システム部に対して，IT施策の実施を加速し，Y社との経営統合に間に合わせるよう指示を出した。情報システム部では，プロジェクトチーム（以下，Pチームという）を編成して検討を始め，まず，認証・認可基盤の構築が必要であると判断し，CIOに報告した。CIOの承認を受け，Pチームは認証・認可基盤構築の実施計画を策定する作業に入った。
〔X社情報システム群の概要と認証・認可基盤構築の基本方針〕
X社には，図1に示す大小合わせて100の業務システム（以下，X社情報システム群という）が存在する。多くのシステムは，Web技術に基づいたもの（以下，Web方式という）であるが，基幹業務システムの一部には，Web方式でない独自技術に基づくクライアントサーバ方式（以下，C/S方式という）も存在する。C/S方式の業務システムについては，今年度後半に，Web方式に再構築することを計画している。
現行の業務システムには，購買システムのように，アプリケーションプログラムに認証機能が組み込まれているもの（以下，アプリ認証方式という）と，研究開発システムのように，アプリケーションプログラムが稼働しているWebサーバの前段にリバースプロキシ型の認証サーバを設置しているもの（以下，プロキシ認証方式という）がある。
Pチームでは，これまでのX社情報システム群の問題を洗い出し，認証・認可基盤構築についての基本方針を決定するために集中検討会を行うことにした。
集中検討会では，利用者認証，アクセス権付与管理，利用者認証・認可に用いるディレクトリ（以下，ディレクトリという）の統合，利用者認証・認可に用いる情報（以下，利用者情報という）の維持管理の4点について現状と問題を整理し，改善策の検討を行った後，Y社との経営統合に備え，Y社の従業者によるX社情報システム群の利用について検討を行うことにした。
〔利用者認証に関する現状と問題〕
利用者ID体系については，従業者番号に基づいた利用者IDを使用している業務システムが多いが，従業者の氏名に基づいた利用者IDを使用している業務システムもある。そのため，利用者は，各業務システムに利用者ID，パスワードなどを入力する際に混乱したり，覚えきれなかったりするという問題が起きている。
〔アクセス権付与管理に関する現状と問題〕
X社では，組織変更に伴う役職に対する役割や職掌の変更が頻繁に発生する。例えば，請求書にかかわる業務は，現在は営業部の担当であるが，過去には営業部と独立した，ほかの組織が担当したこともあった。また，組織横断的なプロジェクトチームが組織されて業務を遂行することも多く，従業者が複数の組織に属したり，複数の役割を同時にもったりすることも，しばしば発生している。そのため，1人の従業者による業務システムへのアクセスでも，所属組織や役割によって，使用できる機能を限定することが必要になってきている。
さらに，以前から，業務システムによっては不必要なアクセス権が利用者に与えられていて，セキュリティ上好ましくないという意見があった。
〔ディレクトリの統合に関する現状と問題〕
現在のX社情報システム群の業務システム名，システム方式，認証方式，ディレクトリの実現方法，登録されている利用者ID数及び利用者情報を表に示す。
ディレクトリについては，業務システムごとに構築され維持運用されているので，統合化などによって，運用効率及びコストの改善を図るようCIOから指示されている。そこで，Pチームでは，標準技術であるLDAP規格に準拠しているディレクトリは統合できるのではないかと考え，調査を行った。しかし，①LDAPを使用する業務システムを調査した結果，いずれもLDAP規格に準拠した製品を使用しているにもかかわらず，ディレクトリを容易に統合できないということが分かった。
〔利用者情報の維持管理に関する現状と問題〕
次にPチームは，利用者情報である利用者の認証情報（利用者ID，パスワードなど）と認可情報（アクセス権付与などの設定情報）の維持管理について，現状と問題を調査した。
現状では，利用者認証・認可機能は，業務システムごとに個別に実装されており，利用者情報も，業務システムごとに維持運用されている。
各業務システムの利用者情報の維持管理は，システムごとに決められたシステム管理者によって行われている。業務システムを新たに利用開始する従業者は，その業務システムの管理者に対して，利用者情報の登録申請を行っている。
利用者情報の業務システムへの登録及び削除は，小規模な業務システムでは，システム管理者が管理台帳に基づいて手作業で行っているが，購買システムなどの基幹業務システムでは，個別に開発した利用者管理機能で行っている。利用者IDの新規作成やアクセス権の追加が必要になった場合には速やかに処理が行われるものの，②利用者IDやアクセス権の一部が不要になった場合に，その削除処理が忘れられることがしばしばある。
以上のとおり，検討項目4点について現状と問題を整理した。これらの問題を解決するために，Pチームでは，まず，実際のアクセス権付与の状況を具体的に調査することにした。
〔主要業務システムにおけるアクセス権付与状況の調査〕
調査には，システムモデリングの手法を用いることにし，職務の遂行者を抽象的に類型化したアクタ（例えば，営業部員，営業部長）ごとのアクセス権付与状況を洗い出した。具体的には，システム再構築を予定している購買システム及び顧客管理システム，並びに企業活動の中心となる営業管理システムに絞り，アクタごとのアクセス権付与の状況について調査を行った。購買システムは購買部で，顧客管理システム及び営業管理システムは営業部で使用されている。
Pチームは調査結果を図2のとおり整理した。業務機能は，業務対象と業務操作から成っている。例えば，顧客管理システムでは，顧客情報という業務対象に対して入力更新という業務操作を行う業務機能があり，その業務機能に対するアクセス権が，アクタである営業部員に付与されている。営業管理システムにおいては営業部長に対して，購買システムにおいては購買部長に対して，すべての業務機能に対するアクセス権が付与されている。Pチームでは，営業部長及び購買部長に付与されているアクセス権が本当に必要なのかどうか，確認すべきであると考えた。
そこで，従業者による業務の実態についてヒアリング調査を行い，ユースケース図を使って図3のとおり整理した。
図3のユースケースは，業務システムの業務機能と，その業務機能を使用するアクタを示している。図3を職務規程と照らし合わせたところ，問題になる利用実態はなかった。
次に，この図3を用いて，内部統制上の問題がないか，また，図2に過剰なアクセス権付与がないかを分析した。
購買業務では，営業部が発行した購買依頼書に対し，購買部員が発注基準に従って，購買同意又は購買不同意の決定を行い，これを購買依頼書同意機能を使って処理する（業務量が多い場合には部長も当業務を行う場合がある）。購買同意の場合には，発注起案書の申請を購買部員又は購買事務員（派遣従業者）が発注起案書処理機能を使って行い，同じ発注起案書処理機能を使って購買部長が承認の処理を行う。③この購買業務には，アクセス権付与の問題はなかったが，内部統制上の問題が見つかった。そこで，購買部で職務規程を見直してもらい，その結果に基づいて，情報システム部で，どのように業務システムで対応すべきか検討することになった。
営業部の業務には，顧客管理業務と営業管理業務がある。顧客管理業務は，顧客情報を保守する業務である。X社では，顧客ごとに1人又は複数の担当の営業部員が付いている。顧客情報の入力更新及び削除に関する業務は，営業部長は実施せず，個々の顧客を担当する営業部員だけが実施している。この業務には内部統制上の問題もアクセス権付与の問題もなかった。
営業管理業務については，事前に営業部長の申請によって，部長の代行を務める営業部員にアクセス権が付与され，営業部長が不在の際，業務機能を使用する場合がある。営業部の業務には，内部統制上の重大な問題はなかったが，アクセス権付与に関して問題が見つかった。
〔利用者認証に関する問題の解決〕
Pチームは，今年度後半，すべての業務システムをWeb方式に再構築し，シングルサインオン（以下，SSOという）を導入することで，X社情報システム群の現状の利用者認証に関する問題の解決を図ることにした。
〔アクセス権付与に関する改善策の検討〕
Pチームでは，調査を通して，組織変更や職掌変更などに伴うアクセス権付与管理を効率的に行うための仕組みが必要であるという結論に至り，各種アクセス制御の方式を比較検討した。その結果，業務に必要な最小限のアクセス権だけを付与することが実現しやすくなり，組織変更や職掌変更などに伴うアクセス権付与管理を効率的に行えるという理由で，ロールベースのアクセス制御を選ぶことにした。ロールベースのアクセス制御では，アクタに対するアクセス権をロールという単位で付与する。ここでロールとは，組織内における一定の権限や責任を伴う業務上の役割を意味する。
Pチームでは，一つ以上の業務対象と一つ以上の業務操作との組合せに対するアクセス権をロールとして定義することにした。手始めに，営業管理システムにおける営業部長用のロールについて検討を行った。営業管理システムでは営業部長に一つ以上のロールが定義できると考え，図4に示す定義案を作成し，議論した結果，案4を採用することにした。
ほかの業務システムにおいても，案4と同様の考え方に基づいてロールの定義を行う方針にした。Pチームでは，ロールベースのアクセス制御を実現するために，④人事管理システムへの管理項目の追加と人事管理システムの運用見直しを行うことにした。
〔Y社従業者へのアクセス認可方式の検討〕
次に，Pチームは，Y社の従業者に，X社情報システム群へのアクセスを認可する方式について検討を行った。Y社との経営統合では，顧客情報などを共有することが想定されている。顧客情報などを共有するための要件は二つある。まず第一に，X社情報システム群は，Y社情報システムの利用者認証結果に基づいて，Y社従業者にX社情報システム群へのアクセスを認可する。第二に，同様に，Y社の情報システム群は，X社従業者に，Y社の顧客情報を管理する情報システム群へのアクセスを認可する。このようなことを実現する技術の一つにID連携技術があるという意見が出た。ID連携技術とは，お互いに信頼する組織間で，それぞれが管理する利用者の利用者IDを結び付けることによって，複数の組織間のシステム利用において，利用者認証が一度だけで済むSSOを実現する技術である。
Pチームは，検討した結果，ID連携技術を採用する方針に決めた。
〔ID連携技術の検討〕
Pチームの中でID連携技術検討の担当となったE君は，ID連携技術の選定について，セキュリティコンサルタントのF氏に助言を求めた。次はF氏のE君への説明である。
- F氏：私は，SAML（Security Assertion Markup Language）2.0という標準技術を使ったID連携のシステム構築の経験があります。SAML 2.0では，異なる製品間の相互運用性について，技術標準を策定する団体が主導して試験を行い，検証結果を公表しています。
- E君：相互運用性が高い技術であれば，X社の技術標準として採用しやすいですね。
- F氏：そうですね。仕組みについてご説明します。図5が，SAML 2.0を使ってSSOを実現する場合のメッセージフローです。この図にあるSP（サービスプロバイダ）は，認証された利用者に対して業務アプリケーションなどのサービスを提供する側の機能で，IDP（IDプロバイダ）は，利用者認証の結果をSPに提供する機能です。利用者がSP上のWebアプリケーションを利用する場合に，SPが利用者に対してWebアプリケーションのサービスを提供してよいかを判定する必要がありますが，この判定のためにSPはaをブラウザ経由でIDPから受け取ります。
- E君：なるほど，分かりました。
- F氏：Y社にもSAML 2.0のSPを導入したとします。この場合，X社の利用者が，X社情報システム群の認証サーバ，つまり，IDPで一度認証を受ければ，bするまでは，X社とY社のWebアプリケーションは，利用者が個別にサインオンしなくても利用可能となります。
検証済製品にはY社が導入しているものも含まれており，Y社と協議した結果，2社間でのID連携には問題がないことが判明した。そこで，Pチームは，SAML 2.0を採用することに決めた。
〔X社情報セキュリティポリシの改訂〕
Pチームでは，セキュリティ強化及びITによる内部統制の強化を図り，認証・認可基盤との整合性を確保するために，X社の情報セキュリティポリシを改訂すべきであると考えた。図6に改訂した情報セキュリティポリシ（以下，改訂ポリシという）（案）の改訂部分を示す。改訂ポリシ（案）はPチームでの確認と情報システム部内での審査を経た後，経営会議で正式に承認され，2か月後に発効することになった。Pチームは，各業務システムに対して，発効後1年以内に改訂ポリシに準拠するように求めることとした。
〔認証・認可基盤の全体方式の決定〕
Pチームでは，認証・認可基盤の全体方式を決定するために議論を重ねた。次は，PチームのリーダであるG主任とメンバのHさんの会話である。
- G主任：現行の業務システムの利用者認証方式をSSOに統一し，各業務システムをSPとして構築するためにはどのような変更や作業が必要か説明してくれないか。
- Hさん：アプリ認証方式の場合には，プログラムの構造をかなり変更する必要があるので，移行作業には時間が掛かりそうですが，技術的な問題はなさそうです。プロキシ認証方式の場合には，Webサーバの接続先を，今まで使用していた認証サーバから，SSOサーバに切り替えます。各WebサーバがSSOサーバのインタフェースに対応可能であることは調査済ですので，容易に移行が可能だと思います。いずれの方式でも，SSOを実現するためにはID連携技術に対応したソフトウェアを追加で導入します。
- G主任：Y社との経営統合への対応を含め，利用者認証については，移行についても技術的にめどが立っているようで安心したよ。しかし，利用者情報の維持管理に関しては，どのような方式にするのがよいのかね。
- Hさん：総合的に考えて，図7に示す方式がよいと思います。人事管理システムから提供される利用者に関する情報と図4で検討したロールの定義を認証・認可情報リポジトリで一元管理します。それを利用者管理機能によって，SSOサーバと各業務システムのディレクトリに反映させます。
- G主任：そうすると，各業務システムの対応は，どうなるのかね。
- Hさん：SSO対応以外にも個々の業務システムの⑤システム改修と運用見直しが必要です。
- G主任：分かった。検討作業を続けてくれたまえ。
以上のようにして，Pチームによる集中検討会は終了し，認証・認可基盤構築の実施計画が社内に発表され，認証・認可基盤の構築が開始された。
出題趣旨（IPA）
情報システムの構築において，情報セキュリティ技術者は，企業の経営戦略に適した技術を選択するとともに，内部統制の観点も併せもって情報セキュリティを確保するための検討を行うことが求められている。本問では，経営統合に伴うシステム連携を状況として設定し，認証・認可基盤の構築計画策定を題材に，ロールベースのアクセス制御やID連携技術の基本的な理解を問うとともに，ID管理を検討する際に求められる技術及び運用プロセスの両面から総合的に判断し，適切な構築計画を策定する能力を問う。
採点講評（問全体・IPA）
問1では，ID連携を含む，認証・認可基盤の統合について出題した。全体として，正答率は低かった。
設問と解答例
ID連携技術について，本文中及び図5中のa，bに入れる適切な字句を，それぞれ10字以内で答えよ。また，図5中のcには，ブラウザにおける動作を示す適切な字句を8字以内で答えよ。
〔a〕解答例
- 認証アサーション
- 認証トークン
〔b〕解答例
- サインオフ
〔c〕解答例
- リダイレクト
解説
本文の根拠
〔ID連携技術の検討〕
この判定のためにSPはaをブラウザ経由でIDPから受け取ります。
図5
認証応答メッセージをブラウザ経由でSPに送信
〔ID連携技術の検討〕
X社の利用者が，X社情報システム群の認証サーバ，つまり，IDPで一度認証を受ければ，bするまでは，X社とY社のWebアプリケーションは，利用者が個別にサインオンしなくても利用可能となります。
a は“認証アサーション”（別解は“認証トークン”）である。OASIS の SAML 2.0 の Profiles は，Web ブラウザ SSO で IdP が認証アサーション（authentication assertion）を作り，SP がそのアサーションを受け取って利用者のセキュリティコンテキストを確立すると定めている。本文の“SP が利用者にサービスを提供してよいかを判定するために IdP から受け取るもの”は，これに当たる。
b は“サインオフ”である。IdP で一度認証を受けた利用者は，そのセッションが続く間は，SP を導入した X 社と Y 社の Web アプリケーションを個別にサインオンせずに使える。SAML 2.0 の Profiles も，IdP が利用者とセッションを結び，そのセッションを利用者が終えるまでの流れを Single Logout として扱っている。c は“リダイレクト”である。SP が認証要求メッセージをブラウザに返して IdP へ向け直させ，ブラウザが HTTP GET で IdP にそれを届ける。この伝え方は SAML 2.0 では HTTP Redirect バインディングと呼ばれ，SP から IdP への認証要求（AuthnRequest）は，ブラウザを通して IdP に渡される。
字数は a が 8 字（別解は 6 字），b が 5 字，c が 6 字で，制限は a・b が 10 字，c が 8 字である。a は“認証情報”ではなく，利用者認証の結果を表すメッセージの名前である“アサーション”まで書く。
採点講評（IPA）
設問1は，a及びcの正答率が低かった。SAML及びHTTPの標準仕様の中で定義された用語を理解していないと見受けられる解答が多かった。具体的な製品仕様や技術の表層的な理解だけではなく，その標準仕様の全体的な理解も深めてほしい。
本文中の下線①について，LDAP規格に準拠しているディレクトリを容易に統合できない理由を，40字以内で述べよ。
解答例
- 業務システムごとに拡張属性を定義して使用しており，スキーマが異なるから
解説
本文の根拠
〔ディレクトリの統合に関する現状と問題〕
いずれもLDAP規格に準拠した製品を使用しているにもかかわらず，ディレクトリを容易に統合できない
表 X社情報システム群の業務システム一覧とディレクトリの実現方法など
LDAP標準スキーマに加え，拡張属性として“担当業務”を定義して使用
表 X社情報システム群の業務システム一覧とディレクトリの実現方法など
LDAP標準スキーマに加え，拡張属性として“研究区分”を定義して使用
LDAP を使う業務システムの表を見ると，購買は“担当業務”，研究開発は“研究区分”という拡張属性を，LDAP 標準スキーマに加えて定義している。人事管理は標準スキーマの“inetOrgPerson”，情報共有は標準スキーマだけを使うので，同じ LDAP でも，業務システムごとに持つ属性の種類が違うことになる。
このため，ディレクトリを一つにまとめようとしても，拡張属性の有無や中身がシステムごとに異なり，そのまま統合できない。解答例は“業務システムごとに拡張属性を定義して使用しており，スキーマが異なるから”である。LDAP 規格に準拠していることと，使っているスキーマが同じことは別の話である。
字数は 35 字で，制限の 40 字に収まる。“LDAP 以外の方式のシステムがあるから”のように，表の“独自”の行（顧客管理・営業管理）を理由にしないこと。設問は LDAP を使うシステム同士が統合できない理由を聞いている。
本文中の下線②の現状がもたらすセキュリティ上の問題を，40字以内で述べよ。
解答例（2通り）
- 業務システムへのアクセスが本来許されない利用者が，アクセス可能な状態になる。
- 退職や異動で権限がなくなったはずの者が業務システムにアクセスできてしまう。
解説
本文の根拠
〔利用者情報の維持管理に関する現状と問題〕
利用者IDやアクセス権の一部が不要になった場合に，その削除処理が忘れられることがしばしばある
〔利用者情報の維持管理に関する現状と問題〕
利用者情報の業務システムへの登録及び削除は，小規模な業務システムでは，システム管理者が管理台帳に基づいて手作業で行っている
不要になった利用者 ID やアクセス権の削除が忘れられると，それらが業務システムに残ったままになる。残ったアクセス権は，本来それを持つはずのない利用者に，業務システムを使える状態を与える。解答例は“業務システムへのアクセスが本来許されない利用者が，アクセス可能な状態になる。”，又は“退職や異動で権限がなくなったはずの者が業務システムにアクセスできてしまう。”である。
本文は，登録と削除が業務システムごとにシステム管理者の手で行われること，新規作成や追加は速やかでも削除が漏れることを述べている。そこで，権限がなくなったのは退職や異動で本来の利用者でなくなった者であり，その者がアクセスできてしまう，という流れで書く。
字数は 38 字と 37 字で，制限の 40 字に収まる。“悪用される”“不正アクセスに使われる”だけでは，誰がどのシステムに何をできてしまうのかが伝わらない。“アクセス可能な状態になる”という，削除漏れから生じる具体的な状態まで書く。
採点講評（IPA）
設問2(2)は，正答率が低かった。本文に記述された状況から想定される具体的な問題点を問うたが，削除されずに残った利用者IDやアクセス権が“悪用される”，“不正アクセスに使われる”といった，あいまいな解答が見受けられた。
図3を参照して，顧客管理業務について営業部長に付与されるロールに許可すべき業務対象及び業務操作を答えよ。
〔業務対象〕解答例
- 顧客情報
〔業務操作〕解答例
- 閲覧
解説
本文の根拠
〔主要業務システムにおけるアクセス権付与状況の調査〕
顧客情報の入力更新及び削除に関する業務は，営業部長は実施せず，個々の顧客を担当する営業部員だけが実施している。
図3
顧客情報入力更新と顧客情報削除は営業部員だけとつながり，顧客情報閲覧は営業事務員，営業部員，営業部長の3アクタとつながる。
図3 の顧客管理業務では，営業部長とつながっている業務機能は“顧客情報 閲覧”だけである。入力更新と削除は営業部員だけとつながっている。したがって，営業部長に付与するロールに許可すべきなのは，業務対象が“顧客情報”，業務操作が“閲覧”である。
本文も，顧客情報の入力更新と削除は営業部長が実施せず，担当の営業部員だけが実施していると述べている。図2 の顧客管理システムの表では，営業部長に○が付いているのも“閲覧”だけであり，図3 の実態と合っている。顧客管理業務には，過剰なアクセス権付与は見つかっていない。
ここでは図3 の線をたどって答える設問なので，図2 の営業管理システムのように，営業部長にすべての業務機能が付与されている表と取り違えない。
本文中の下線③の問題を解決するためには，発注起案書処理機能を二つに分離すべきである。その理由を，内部統制上の観点から60字以内で述べよ。
解答例
- 発注起案書申請と発注起案書承認が同一人物によって行われ，架空発注などの不正を発見できないおそれがあるから
解説
本文の根拠
〔主要業務システムにおけるアクセス権付与状況の調査〕
購買同意の場合には，発注起案書の申請を購買部員又は購買事務員（派遣従業者）が発注起案書処理機能を使って行い，同じ発注起案書処理機能を使って購買部長が承認の処理を行う。
図6
情報システムは，権限の分離原則に基づき利用すること。
発注起案書の申請と承認は，同じ“発注起案書処理”機能で行われている。図2 の購買システムの表では，発注起案書の処理が購買事務員，購買部員，購買部長の全員に○であり，申請者と承認者を機能の面で区別していない。そのため，同一人物が申請も承認も行える状態になっており，これが内部統制上の問題である（下線③）。
内部統制では，一つの取引を始める者と承認する者を分ける（権限の分離）。改訂ポリシ（図6）の K-2-2 も，権限の分離原則に基づく利用を求めている。分離しないままだと，申請と承認が同一人物で行われても気付けず，架空発注のような不正を発見できないおそれがある。解答例は“発注起案書申請と発注起案書承認が同一人物によって行われ，架空発注などの不正を発見できないおそれがあるから”である。
字数は 52 字で，制限の 60 字に収まる。“同一人物が申請と承認を行える”という事実と，“不正を発見できない”という内部統制上の問題の二つを入れる。
どのように分離すべきか。分離後の発注起案書処理のユースケースについて，“業務操作”と“アクタとそのアクタが使用する業務機能の対応”を図3に倣って示せ。
解答例（図）
解説
本文の根拠
〔主要業務システムにおけるアクセス権付与状況の調査〕
購買同意の場合には，発注起案書の申請を購買部員又は購買事務員（派遣従業者）が発注起案書処理機能を使って行い，同じ発注起案書処理機能を使って購買部長が承認の処理を行う。
図2
支払請求書の承認：購買事務員－，購買部員－，購買部長○。
発注起案書処理機能を，業務操作ごとに“申請”と“承認”の二つの業務機能に分ける。本文のとおり，申請を行うのは購買部員と購買事務員（派遣従業者），承認を行うのは購買部長なので，“発注起案書 申請”は購買事務員と購買部員の二つのアクタに，“発注起案書 承認”は購買部長に結ぶ。
図2 の支払請求書は，管理と申請は3アクタ，承認は購買部長だけに○が付いており，申請と承認がすでに分かれている。発注起案書も同じ形にそろえる。解答例の図は，“発注起案書”の楕円を“申請”と“承認”の2つに分け，申請の楕円から購買事務員（派遣従業者）と購買部員へ，承認の楕円から購買部長へ線を引いている。
この設問は図に描いて答える形式なので，自己採点では解答例の図と見比べる。楕円には図3 に倣って業務対象（発注起案書）と業務操作（申請，承認）を書き，承認の楕円に購買事務員や購買部員の線を引かないこと。
営業管理システムの営業部長用ロール定義案として案4が選ばれた理由を二つ挙げ，それぞれ45字以内で述べよ。
〔①〕解答例
- 職掌変更などで役職に対する役割に変更が発生した場合に，容易に対応できるから
- 申請と承認のような分離されるべき責務が，同じ権限として定義されていないから
〔②〕解答例
- 職掌変更などで役職に対する役割に変更が発生した場合に，容易に対応できるから
- 申請と承認のような分離されるべき責務が，同じ権限として定義されていないから
〔備考〕このうち異なる二つを答える
解説
本文の根拠
〔アクセス権付与に関する改善策の検討〕
営業管理システムでは営業部長に一つ以上のロールが定義できると考え，図4に示す定義案を作成し，議論した結果，案4を採用することにした。
〔アクセス権付与に関する改善策の検討〕
ここでロールとは，組織内における一定の権限や責任を伴う業務上の役割を意味する。
〔アクセス権付与状況の調査〕
X社では，組織変更に伴う役職に対する役割や職掌の変更が頻繁に発生する。
案4 は，営業部長用のロールを三つに分け（4-1 は見積書と契約書，4-2 は請求書，4-3 は売上報告書と購買依頼書），しかも各ロールに“承認”の操作だけを入れている。この二点が，案1〜3 と比べた理由になる。
一つは，役割の変更に容易に対応できることである。X社では組織変更に伴って役職に対する役割や職掌が頻繁に変わり，請求書にかかわる業務を営業部以外が担当した時期もある。案4 のように業務対象ごとにロールを分けておけば，変わった業務のロールだけを付け替えられる。案1・案3 は一つのロールに全部をまとめており，こうはいかない。もう一つは，申請と承認のような分離すべき責務が，同じ権限にならないことである。案1 と案2 は“作成，承認”“申請，承認”を同じロールに入れており，申請と承認を一人が行える。案4 は承認だけを集めているので，図6 の権限の分離原則に合う。
字数は二つとも 37 字で，制限の 45 字に収まる。解答例は二つの理由を①②に一つずつ答える形で，どちらの理由をどちらの欄に書いてもよい。
本文中の下線④について，追加される管理項目を10字以内で答えよ。また，運用見直しの内容について，50字以内で具体的に述べよ。
〔追加される管理項目〕解答例
- ロールに関する情報
- 職掌に関する情報
〔運用見直しの内容〕解答例
- 人事部あるいは管理者によって，従業者の所属組織や職掌の変更の都度，遅滞なく，情報を更新する。
解説
本文の根拠
〔アクセス権付与に関する改善策の検討〕
④人事管理システムへの管理項目の追加と人事管理システムの運用見直し
図7
人事管理システムから認証・認可情報Repへ“提供”の破線矢印が引かれている。
〔認証・認可基盤の全体方式の決定〕
人事管理システムから提供される利用者に関する情報と図4で検討したロールの定義を認証・認可情報リポジトリで一元管理します。
ロールベースのアクセス制御では，アクセス権を役職や職掌に応じたロールに結び付けて付与する。図7 の方式では，人事管理システムから“提供”される利用者の情報が認証・認可情報リポジトリに集まり，そこにロールの定義と合わせて一元管理され，各業務システムとSSOサーバに反映される。したがって，人事管理システムが持つ利用者情報に，ロールを決めるための項目が要る。追加する管理項目は“ロールに関する情報”又は“職掌に関する情報”である。
運用の見直しは，その情報が古くならないようにすることである。X社では組織変更に伴う役職・職掌の変更が頻繁に起き，利用者が複数の組織に属することもある。そこで，人事部又は管理者が，所属組織や職掌が変わるたびに遅滞なく情報を更新する。解答例は“人事部あるいは管理者によって，従業者の所属組織や職掌の変更の都度，遅滞なく，情報を更新する。”である。
字数は管理項目が 9 字と 8 字（制限 10 字），運用見直しが 46 字（制限 50 字）である。講評は，ID 管理とアクセス管理では異動や退職の変更を情報システムに即座に反映させることが重要だとし，図7 の方式の説明だけの解答や，図7 と矛盾する解答，“適切に管理する”のようなあいまいな解答を挙げている。“誰が”“いつ”“何を”更新するかまで具体的に書く。
採点講評（IPA）
設問3は，全体では想定どおりの正答率だったが，(4)の運用見直しの内容の正答率は低かった。ID管理及びアクセス管理においては，異動・退職といった変更を情報システムに即座に反映させることが重要である。しかし，図7に示された方式を説明しただけの解答，図7と矛盾する内容の解答が見受けられた。また，“適切に管理する”といった，あいまいな解答も見受けられた。
本文中の下線⑤について，営業管理システムを例にとり，システム改修の内容を二つ挙げ，それぞれ40字以内で述べよ。
〔①〕解答例
- 認証方式をアプリ認証方式からプロキシ認証方式に変更する。
〔②〕解答例
- 認可ロジックをロールベースのアクセス制御に対応した実装にする。
解説
本文の根拠
〔認証・認可基盤の全体方式の決定〕
アプリ認証方式の場合には，プログラムの構造をかなり変更する必要があるので，移行作業には時間が掛かりそうですが，技術的な問題はなさそうです。
〔認証・認可基盤の全体方式の決定〕
プロキシ認証方式の場合には，Webサーバの接続先を，今まで使用していた認証サーバから，SSOサーバに切り替えます。
表 X社情報システム群の業務システム一覧とディレクトリの実現方法など
営業管理：Web方式，アプリ認証方式，独自，6,000，RDBの列として，利用者ID，パスワード，権限区分を定義して使用。
営業管理システムは Web 方式で，アプリ認証方式（認証機能をアプリケーションに組み込んでいる），利用者情報は“RDB の列として利用者 ID，パスワード，権限区分を定義”した独自のものである。この業務システムを SSO の SP とし，ロールベースのアクセス制御にするための改修は，認証と認可の二つになる。
認証は，アプリ認証方式からプロキシ認証方式に変更する。H さんが述べるように，プロキシ認証方式なら Web サーバの接続先を認証サーバから SSO サーバに切り替えるだけで済み，プログラムの構造を大きく変えずに済む。認可は，権限区分で付与していた独自のアクセス権を，図4 の案4 のようなロールで付与できる実装にする。解答例は“認証方式をアプリ認証方式からプロキシ認証方式に変更する。”と“認可ロジックをロールベースのアクセス制御に対応した実装にする。”である。
字数は 28 字と 31 字で，制限の 40 字に収まる。講評は，設問が“個々の業務システムのシステム改修”“営業管理システムを例にとり”としているのに，“ID 体系を統一する”“権限情報を一元化する”“ディレクトリを統合する”のような X社情報システム全体の対応を挙げた解答が多く，認証と認可のどちらか一方だけの解答も多かったと述べている。
採点講評（IPA）
設問4は，正答率が低かった。本文及び設問でそれぞれ“個々の業務システムのシステム改修”，“営業管理システムを例にとり”と記載しているにもかかわらず，“ID体系を統一する”，“権限情報を一元化する”，“ディレクトリを統合する”といった，X社情報システム全体に関する解答が多かった。また，営業管理システムの改修として，認証方式の変更と認可方式の変更の両方が必要であるが，どちらか一方だけに関する解答も多かった。
出典：平成21年度 秋期 情報処理安全確保支援士試験 午後Ⅱ 問1（表記を一部改変）
