システム調達におけるセキュリティ要件研究会

調達におけるセキュリティ要求仕様

作成マニュアル

Ver. 0.92 2006/11/13

1

目次 1. 本マニュアルの位置づけ....................................................................................................................... 3

1.1 目的 .............................................................................................................................................. 3 1.2 対象読者....................................................................................................................................... 3 1.3 諸活動等との関係 ......................................................................................................................... 3 1.4 セキュリティ対策の検討と ST 確認制度の利用 ............................................................................... 4

2. 情報システムセキュリティとは ................................................................................................................. 5 2.1 自治体情報システムの種類と特徴.................................................................................................. 5

(1) 情報システムの種類................................................................................................................... 5 (2) 情報システムの特徴................................................................................................................... 6

2.2 保護すべき情報資産 ..................................................................................................................... 7 (1) 用途や重要性の観点での整理................................................................................................... 7 (2) 情報資産の分類と管理 .............................................................................................................. 8

2.3 セキュリティ確保のための対策...................................................................................................... 10 2.4 情報資産に対する脅威.................................................................................................................11 2.5 情報システムの技術的セキュリティ対策 ........................................................................................ 12 2.6 情報システムの運用面のセキュリティ対策..................................................................................... 13 2.7 情報セキュリティポリシーの遵守 ................................................................................................... 15

(1) 職員等の遵守義務................................................................................................................... 15 (2) 実施手順の策定 ...................................................................................................................... 15 (3) 遵守状況のチェック.................................................................................................................. 15

2.8 情報システムのライフサイクルとセキュリティ................................................................................... 16 (1) 情報システムのライフサイクル................................................................................................... 16 (2) 情報セキュリティマネジメントにおける PDCA サイクル............................................................... 16

3. 調達時のセキュリティ要求仕様の作成方法 .......................................................................................... 18 3.1 情報システムの調達プロセス........................................................................................................ 18 3.2 セキュリティ要求仕様の果たすべき役割 ....................................................................................... 19 3.3 セキュリティ要求仕様の構成......................................................................................................... 19 3.4 セキュリティ要求仕様の検討における手順とポイント...................................................................... 21

(1) セキュリティ要求仕様の検討手順.............................................................................................. 21 (2) 検討のポイント ......................................................................................................................... 21

3.5 セキュリティ要求仕様の作成における手順とポイント...................................................................... 22 (1) セキュリティ要求仕様の作成手順.............................................................................................. 22 (2) 調達時に提案を求めるべき項目について ................................................................................. 22

3.6 調達シーンごとのセキュリティ要件抽出シートの活用方法.............................................................. 22 (1) 新規に情報システム構築を行う際のセキュリティ要件の検討 ...................................................... 23 (2) 現状の情報システムのセキュリティ問題の分析と見直し ............................................................. 25 (3) 情報システムを考慮したセキュリティポリシーの分析と見直し...................................................... 26

2

(4) 情報システムを調達する段階のセキュリティ要求仕様の作成 ..................................................... 28 3.7 調達に応じたセキュリティ要求仕様のまとめ方............................................................................... 28

4. 提案書のセキュリティに関する評価方法 .............................................................................................. 30 4.1 提案の評価に関する手順 ............................................................................................................ 30

(1) セキュリティ要求仕様に基づく評価表の作成............................................................................. 30 (2) 提案方法の指示 ...................................................................................................................... 32 (3) セキュリティ要求仕様に対する充足度評価................................................................................ 33 (4) セキュリティ要求仕様に対する実効性評価................................................................................ 33

4.2 評価のとりまとめ........................................................................................................................... 34

3

1. 本マニュアルの位置づけ

1.1 目的

本マニュアルは、調達者が作成する調達仕様書のなかに、調達する情報システムまたは製品が具備す

べきセキュリティ要件を明確に記載するための手法を示すことを目的としています。 特に、本マニュアルは、以下のことを念頭に、調達者がセキュリティ要件を検討する際に活用できるよう

にまとめています。

① 調達者が、システム構築や機器の購入の調達に際して満足すべきセキュリティ機能の要求仕様（セキュリティ要求仕様）を作成する際の基本的な考え方と手順の手引きとなること。

② 調達者が、提案者からのセキュリティ機能の提案（セキュリティ提案仕様）を審査する際の基本的な

考え方と手順の手引きとなること。 ③ 調達者が、付録のアプリケーション例を参照して、セキュリティ要求仕様を具体的に検討する際の参

考となること。また、同様にして、提案者から提出されたセキュリティ提案仕様を具体的に審査する

際の参考となること。 ④ 調達者が、添付の「セキュリティ要件検討支援ツール」を利用してセキュリティ要件を簡易に抽出す

る際の手引きとなること。

1.2 対象読者

本マニュアルは、地方自治体において情報システムや情報機器の調達仕様作成に関わる方を対象と

しています。

1.3 諸活動等との関係

本マニュアルは、主に以下の文書を参考にしています。 ・ 政 府 機 関 の 情 報 セ キ ュ リ テ ィ 対 策 の た め の 統 一 基 準 （ 2005 年 12 月 版 （ 全 体 版 初 版 ） ）

（NISD-K303-052）(2005 年、情報セキュリティ政策会議決定）（以下、「統一基準」とします。） ・ 調達ガイドライン（改訂版）（平成 18 年 3 月、財団法人ニューメディア開発協会） ・ FISMA：Federal Information Security Management Act 特に「NIST Special Publication

800-53:連邦政府情報システムにおける推奨セキュリティ管理策」 ・ 情報システムの構築等におけるセキュリティ要件及びセキュリティ機能の検討に関する解説書

（DM6-07-061）（2006 年 6 月、内閣官房セキュリティセンター） ・ 情報システムの構築等における ST 評価・ST 確認の実施に関する解説書（DM6-08-061）（2006 年 6 月、

4

内閣官房セキュリティセンター） ・ 地方公共団体における情報セキュリティポリシーに関するガイドライン（平成 18 年 9 月版）（2006 年 9 月、

総務省）

1.4 セキュリティ対策の検討と ST 確認制度の利用 本マニュアルで示すセキュリティ対策の検討方法は、ISO/IEC TR 13335 で紹介される「ベースラインアプローチを考慮したセキュリティ対策の検討」を適用するものですが、高いリスクにさらされる情報システムである場合

は「詳細リスク分析に基づくセキュリティ対策の検討」を適用することで、そのリスクを許容範囲以下にするための

対策を実施する必要があります。 本マニュアルでは、セキュリティの専門家でなくても、セキュリティ要件検討支援ツールを利用することで情報シ

ステムに対する適切なセキュリティ対策を検討できるような方法を示しました。本マニュアルの付録には、ツール

を利用して適切なセキュリティ要件を検討するケースと、重要なセキュリティ要件がある場合に詳細リスク分析を

行うケースを例示しています。 また、政府機関に適用される統一基準では、重要なセキュリティ要件があると認められた情報システムに対し

ては、セキュリティ機能の設計について第三者機関によるセキュリティ設計仕様書（ST：セキュリティターゲット）の ST 評価・ST 確認を受けることが基本遵守事項に含まれています。本マニュアルで示すリスクに応じたセキュリティ要件の検討方法と、政府機関に適用される統一基準との対応を以下の図に示します。

付録の詳細リスク分析を行うケースは、この ST を作成することを念頭に置いた構成となっています。

ISO/IEC TR 13335で示されたリスクマネジメントには、高いリスクにさらされている特定の対象には、詳細リスク分析に基づくセーフガード（セキュリティ対策）を実施して、残りの組織全体には、ベースラインアプローチに基づくセーフガードを実施することが示されている。　

対象のリスク分析 ベースラインアプローチに基づくセーフガードの選択

詳細リスク分析に基づくセーフガードの選択

高度なリスクにさらされているITシステムを対象、確実性は高いがコスト、時間等負荷が高い

適切なセーフガードを選択することにより、組織全体のITシステムに一貫性のある適切なベースライン保護を実施できる。

【ISO/IEC TR 13335】

【統一基準】

情報資産の評価 統一基準の要件の選択

ST評価・確認

保護すべき情報資産、およびこれを扱う情報システム

各省庁にて必要と認められるもの

【基本遵守事項】

【強化遵守事項】

重要なセキュリティ要件と認められるもの

図 1.1-1 リスクマネジメントと ST 確認の役割

5

2. 情報システムセキュリティとは

2.1 自治体情報システムの種類と特徴

(1) 情報システムの種類 自治体の情報システムは、以下のように分類されます。なお、情報システムの分類は自治体ごとに情報

化計画等で定義されていますが、下記に示した定義及び呼称は、各団体の定義及び呼称と必ずしも一

致するものではありません。

ア 住民情報システム 住民の情報を保持・管理するとともに、戸籍、税務、福祉、保健、教育等の各種サービスを提供する業

務に導入されているシステムです。情報システムの操作は窓口等の職員によって行なわれ、住民が直接

操作することはありません。 具体的には、住民基本台帳、戸籍、税務、福祉といった業務に扱われる情報システムが該当します。

イ 地域情報システム 近年、住民サービスの利便性を高める一環として、証明書の自動交付機やスポーツ施設の予約端末な

ど、窓口での対応時間帯よりも幅広い日時や場所で、サービスを提供できる仕組みを取り入れる自治体が

増えています。また、国の e-Japan 戦略や IT 新改革戦略の推進に合わせて、自治体の施策やサービスに関する情報の提供や、各種申請の受付を、インターネットを通じて実施するサービスの導入も進んでい

ます。 具体的には、自動交付機や図書館の検索システムといった、自治体の施設で住民が直接端末を操作

するものや、自治体の施策やサービスについてインターネットを通じて広く住民に通知するウェブサイト、

さらには、電子申請や電子入札といった、インターネットを通じて住民サービスを実施する情報システムが

あります。

ウ 内部事務システム 自治体の役所・役場の内部事務には各種の情報システムが取り入れられ、事務の効率的な推進に役立

っています。 具体的には、人事管理、給与計算、文書管理、財務会計、グループウェアなど、行政事務全般を推進

するために活用される情報システムです。

エ インフラシステム 上記の各種システムを庁内の必要な場所から利用できるようにする、あるいは、インターネット等の他の

システムとの接続を行うためのシステムです。ネットワークを構成する機器等や、端末や利用者のネットワ

ークへの接続を管理するシステム等が該当します。 また、職員の各種システムへのアクセスを共通で管理するための認証システムや、住民の基本情報、職

員の所属及び職責といった、情報システム間で共通に整備され、同一の情報で管理されることが求められ

る情報の同期を図るためのシステム間連携システムを導入する自治体も増えてきています。

6

(2) 情報システムの例 平成 17 年度、18 年度に地方自治情報センターによって実施されている「市町村の業務システムの導入及び運用に要する経費等の調査」において調査対象となっている、合わせて 30 の情報システムを、上記に従って分類したものを下表に示します。

表 2.1-1 情報システムの例 分類 ①住民情報システム ②地域情報システム ③内部事務システム ④インフラシステム

住民情報関連 自動交付機 財務会計 システム間連携

税業務 電子申請 庶務事務

国保・年金 電子申告 人事給与

戸籍 施設予約 文書管理

選挙投票 図書館 統計

福祉業務 電子調達 土木積算

介護保険 情報提供 公有財産管理

医療費助成 電子相談 グループウェア

学齢簿 情報公開 統合型 GIS

情報システムの例

上下水道料金 公営住宅管理

(3) 情報システムの特徴 前項で示した情報システムの分類ごとに、セキュリティの観点からの特徴以下に示します。

ア 住民情報システム 住民サービスを行うに当たって、自治体では、家族構成や収入、要介護や障害といった、機密性の高い

個人情報を取り扱います。各種のサービスは法律、条令、規則等によってルールが定められ、個人情報

の内容によって利用できるサービスが定められるケースも少なくありません。こういった、機密性の高い、プ

ライバシーに属するような個人情報は、自治体職員といえども担当者以外には知られないよう、厳重に管

理される必要があります。庁外の住民等の目に触れることのないようにしなければならないことは言うまで

もありません。また、ここまで繊細な情報ではない場合でも、庁内外を問わず、必要のない者が必要な範

囲以外の用途、目的で閲覧したり扱ったりすることのないように管理されなければなりません。 これらの情報システムは、通常、インターネットを始めとした庁外のネットワークからはアクセスされないよ

うに管理されており、また、住民向けのサービスに利用される際にも、担当の職員だけが情報を扱うことが

できるように管理されます。

イ 地域情報システム 地域情報システムでは、誰もが端末の操作、あるいはインターネットを通じた情報の送付ができるように

なっている必要がありますが、同時に、間違いあるいは故意によって、情報システムや記録されている情

報に対して、セキュリティ上のリスクが発生することに留意する必要があります。 これらの情報システムは、端末の利用者やインターネットを通じて接続する利用者によって、サービス停

7

止を引き起こされる、あるいは、不正な情報の入出力がなされることのないように管理され、また、万が一な

された場合でも、影響を最小限にとどめ、また速やかに復旧できるよう、導入される必要があります。

ウ 内部事務システム 内部事務システムは、庁内の職員が広く利用できるように整備されていますが、一部には職員の個人情

報や人事情報、公開前の施策にかかわる情報など、取扱いに注意を要する、一部の職員を除いては利

用できないようにする必要が生じる情報も扱われています。 これらの情報システムは、庁内の幅広い職員に配付されている事務用パソコンからアクセスできるものが

多く、それぞれの機能、情報を利用できる職員を限定するアクセス権限管理が重要になります。

エ インフラシステム 上記の情報システムを稼動させるネットワークは、行政事務を実施する部署や窓口を網羅して整備され

る必要がある上、セキュリティの観点からは、不正アクセスや情報漏洩、コンピュータウィルス等の侵入を防

止し、また万が一被害に遭った場合にも、その被害を最小限にするよう、計画されています。 具体的には、自治体ごとの管理方針に基づき、以下に示すように整備がなされています。

全システムを物理的に接続されたネットワークとして整備し、ファイアウォール、ルータ等の設備

を用いてセキュリティ設定の異なる区画を設定 住民情報システム、内部事務システム、地域情報システムといった情報システムの分類ごとに、

物理的に隔離されたネットワークを個別に整備 インフラの整備方法によって、セキュリティ管理の方法は異なります。情報システムがネットワークで接続

されている場合には、ネットワークを通じた不正侵入や情報漏洩、ウィルス等への対策が重要になりますし、

物理的に断絶している場合には、フロントオフィス系との間での情報連携に利用される電子媒体等を通じ

た事故や不正を防止する必要が生じます。 また、認証システムやシステム間連携システムは、各種システムの間での情報のやり取りを行いますが、

個人情報を取り扱うシステムの間での情報の連携が、業務に係わる重要情報の漏洩等をもたらす危険が

生じないよう、セキュリティ面で十分な配慮が必要です。

2.2 保護すべき情報資産 自治体の情報システムで扱われている、保護すべき情報資産について、用途や重要性の観点での整理を

行ったうえで、情報資産の管理の観点での整理を行います。

(1) 用途や重要性の観点での整理

ア 扱われている情報の種類 情報システムで扱われている情報をその用途に沿って分類すれば、以下に示すようになります。

① 業務情報 当該業務で直接扱う情報です。住民の個人情報、とりわけ、税額、各種手当ての給付、福祉サー

ビスの給付資格、職員についても個人情報や評価等の個人情報といった、特に機密性の高い情報

が含まれる場合が高いと考えられます。 ② 職員情報

8

当該システムに係わる業務を提供する職員に関する情報です。部署名や氏名、職員番号といっ

た情報が記録されることが多いと考えられますが、業務上の必要がない限り取扱いに特段の留意を

要する情報が扱われることは少ないと考えられます。 ③ システム管理情報

当該システムの管理に係わる情報です。システムを操作する職員等の ID やパスワード、アクセス権限の設定、操作ログ、外字等の情報が含まれます。外部への漏洩によるシステム外での利用より

も、むしろ改ざんや不正アクセスといった、システム自体やシステムで管理されている他の情報への

攻撃を防止する観点から、セキュリティを確保する必要が生じます。 ④ サービス情報

当該システムで扱う業務のサービス内容に関する情報です。サービス情報は基本的には公開情報

と考えられますが、改ざん防止、可用性確保などは一般的に必要となります。

イ 重要性から見た情報の種類 ① センシティブ情報

外部に漏洩した場合に、情報の主体（住民等）の身体や財産等に重大な不利益をもたらすことが

想定される非公開情報。基幹業務系システムの業務情報に含まれる場合が高いと考えられます。 ② 重要非公開情報

非公開としている情報のうち、外部に漏洩した場合に、自治体の行政運営に重大な影響を及ぼす

ことが想定される情報。内部事務系システムの業務情報に含まれる場合が多いと考えられます。 ③ 通常の非公開情報

非公開としている情報です。 ④ 重要公開情報

他の媒体で公開されていないなど、一時的にも利用できなくなることが行政事務の進行に大きな

影響を及ぼすような情報です。 ⑤ 通常の公開情報

他の媒体でも公開されているなど、一時的に利用できなくなった場合でも代替策による行政事務

が実施できる情報です。広報情報などがこれに当たります。

(2) 情報資産の分類と管理 情報資産の管理のためには、セキュリティの観点から機密性、完全性及び可用性の尺度を用います。

各々のシステムで利用する情報資産は、それぞれの尺度において以下のように分類されます。 下記の分類には、「地方公共団体における情報セキュリティポリシーに関するガイドライン」（総務省）に

示されている分類を用いています。 情報資産の分類基準は、それぞれの自治体においてセキュリティポリシーに基づいて定めるものですが、

ここでは、それぞれの分類について、前項であげた重要度から見た情報の種類との関連についての考え

方の例を、参考情報として示します。

ア 機密性 表 2.1-1 機密性に関する分類基準

分類 分類基準

9

機密性 3 行政事務で取り扱う情報資産のうち、秘密文書に相当する機密性を要する情報資産 機密性 2 行政事務で取り扱う情報資産のうち、秘密文書に相当する機密性は要しないが、直ち

に一般に公表することを前提としていない情報資産 機密性 1 機密性２又は機密性３の情報資産以外の情報資産

「地方公共団体における情報セキュリティポリシーに関するガイドライン」（総務省）より 前節の重要度による種類では、センシティブ情報は機密性 3、重要非公開情報及び通常の非公開情報は機密性 2、重要公開情報及び通常の公開情報は機密性 1 と区分することが考えられます。

イ 完全性 表 2.1-2 完全性に関する分類基準

分類 分類基準 完全性 2 行政事務で取り扱う情報資産のうち、改ざん、誤びゅう又は破損により、住民の権利が

侵害される、又は行政事務の適確な遂行に支障（軽微なものを除く。）を及ぼすおそれ

がある情報資産 完全性 1 完全性２の情報資産以外の情報資産

「地方公共団体における情報セキュリティポリシーに関するガイドライン」（総務省）より

前節の重要度による種類では、センシティブ情報、重要非公開情報及び重要公開情報は完全性 2、通常の非公開情報及び通常の公開情報は完全性 1 と区分することが考えられます。

ウ 可用性 表 2.1-3 可用性に関する分類基準

分類 分類基準 可用性 2 行政事務で取り扱う情報資産のうち、滅失、紛失又は当該情報資産が利用不可能であ

ることにより、住民の権利が侵害される、又は行政事務の安定的な遂行に支障（軽微な

ものを除く。）を及ぼすおそれがある情報資産 可用性 1 完全性２の情報資産以外の情報資産

「地方公共団体における情報セキュリティポリシーに関するガイドライン」（総務省）より

前節の重要度による種類では、センシティブ情報、重要非公開情報及び重要公開情報は可用性 2、通常の非公開情報及び通常の公開情報は可用性 1 と区分することが考えられます。

10

2.3 セキュリティ確保のための対策

情報システムにセキュリティが必要かどうかを検討する場合、対象となる情報システムが取り扱う情報やデ

ータに対してどのような「脅威」が存在するかを想定します。脅威が存在するからこそ、何らかの「対策」が必

要となります。 例えば、相手に手紙を送る場合、他人に中身を読まれるという脅威が存在するのであれば、封緘をし、価

値が高いものを送るのであればさらに書留を利用するといった付加的な対策を行うことが考えられます。これ

を電子メールに置き換えれば、メッセージを暗号化し、さらにセキュリティを高めるために電子署名を付与す

るといった対策を行うことに相当するといえます。 情報システムが具備すべきセキュリティ要件は、「何を（情報資産）」「何から（脅威）」「どのように守る（対

策）」必要があり、したがって「この機能」が必要である、という考え方で決定することが重要です。この流れで

検討することにより、過剰なセキュリティ機能を要求したり、逆に不足したりすることを防ぎ、バランスの取れた

セキュリティ機能を要求することができます。

表 2-1 脅威と対策の基本的な考え方

情報システムのセキュリティを確保するためには、想定される脅威に対して必要となる対策が漏れること無

く組み込まれたシステム設計が必要となります。このようなシステム設計では、まず、情報システム全体を俯

瞰し、情報資産に対する脅威の洗い出しを行い、それぞれの脅威について、機器等（IT）で対策すべき脅威か、運用（IT 以外）で対策または回避すべき脅威かについて体系立った分類を行います。

機器等（IT）で対策すべき脅威に対しては、情報システムに必要なセキュリティの仕様を決定するためにセキュリティ要件（セキュリティ要求仕様）をとりまとめます。このような検討の手順は、セキュアな情報システム

を設計するためには有効なものとなります。

脅威

対策

情報資産

● 有効な対策の検討 IT 機器(単一の機器または複数の機器の組合せ等で実現) IT 機器以外（運用、規則など）

● 想定される脅威の抽出

11

表 2-2 基本的なセキュリティ機能（対策）の概観

2.4 情報資産に対する脅威

情報セキュリティの確保とは、すなわち「情報資産を守る」ということです。 「守る」対象とは、具体的には情報資産の「機密性」、「完全性」及び「可用性」であり、それらを阻害する原

因となるものを「脅威」と言います。 「地方公共団体における情報セキュリティポリシーに関するガイドライン」では、「機密性」、「完全性」及び

「可用性」を以下のように定義しています。

機密性： 情報にアクセスすることを認められた者だけが、情報にアクセスできる状態を確保することをいう。 完全性：情報が破壊、改ざんまたは消去されていない状態を確保することをいう。 可用性：情報にアクセスすることを認められた者が、必要なときに中断されることなく、情報にアクセス

できる状態を確保することをいう。

脅威には様々なものがありますが、大きく分けて次の 3つに分類できます。

① 物理的脅威 地震、火災、台風等の自然災害、機器故障やテロ等により、物理的な施設、機器等が被害を受ける

ような脅威を指します。 一般にその発生は予測しづらく、発生を防ぐことは困難です。

脅威１ 機密情報

業務システム 対策５(IT 以外)

脅威２

対策１ 対策２

個人情報

ｾｷｭﾘﾃｨﾃﾞｰﾀ etc

情報資産

・主体認証 ・主体認証情報の管理 ・通信路の暗号化 ・主体認証の証跡と管理 etc

脅

威 ４

脅威３

証跡情報

・アクセス制御 ・アクセスの証跡と管理 ・権限の管理 etc

・アカウントの 無い利用者 etc

・権限外のｱｸｾｽ etc

対策３

・ｺﾏﾝﾄﾞを使用した改ざん ・情報資産の持ち出し etc

・データ暗号化

脅威５

・通信路の盗聴 etc

・データ暗号化 ・データの署名 ・コマンドﾞの権限管理 etc

対策４

・運用、組織管理 ・要員、物理的対策 ・取り扱い規則 etc

12

② 技術的脅威

システムに不正に侵入し、情報を窃取したり破壊するような、IT 技術を利用した脅威を指します。 ウィルスやスパイウェア、フィッシング等もこの技術的脅威に含みます。

③ 人的脅威

「人」が原因となる脅威で、IT 技術を意図的に利用しない脅威を指します。 重要情報が記載されたファイルの置き忘れ、データの誤入力、メールの送付先を間違う等の偶発的

なミス、機密情報の不正な持ち出し、なりすましによる不正入室、事実の否認等の意図的な攻撃があり

ます。

2.5 情報システムの技術的セキュリティ対策

「技術的セキュリティ対策」とは、IT 技術を利用して脅威から情報資産を守る方法です。「技術的セキュリティ対策」として、統一基準に示されている機能を以下に例示します。

技術的セキュリティ対策は以下が全てではありません。実際は情報資産の形態やシステムの実装状況に

よって個別に検討することになります。

（１）主体認証機能

システムの利用者が、本当にその権限を持った本人（主体）であるかを確認（認証）する機能です。

もっとも一般的なのがパスワードによる認証です。その他 IC カードや USB メモリを利用した認証、生体の特徴（指紋、指の静脈、掌の静脈、虹彩等）を利用した生体認証等があります。

それぞれの認証方式には特徴があり、利便性や導入コスト、運用コスト等を総合的に判断して方式を選択

することになります。

主体認証機能には、登録された主体認証情報と入力された情報をマッチングする機能以外にも、付随す

る機能が求められます。統一基準で示されている機能を以下に例示します。

① 主体認証情報を暗号化して保存する機能。

② 主体認証情報を通信する場合には暗号化する機能。

③ 主体認証情報を他者が容易に知ることが出来ないようにする機能。

④ 利用者が主体認証情報を定期的に変更していることをチェックする機能。

⑤ 利用者が主体認証情報を定期的に変更しなかった場合、システムを利用させなくする機

能。

⑥ 利用者が主体認証情報を変更できる機能。

⑦ 複数の要素で主体認証を行う機能。（パスワード＋指紋など）

⑧ 不正ログオンを検知し、防止する機能。（3 回パスワードを間違うと、ID をロックする等）これらをどこまで実装するかは、保護する情報資産の重要性やリスクの度合いによって個別に判断する必

要があります。例えば、上記の②の場合は、インターネットを介して利用する場合は必須と思われますが、ネ

13

ットワークセキュリティが確保されている庁内 LAN のみで使用するシステムの場合は不要になるかもしれません。

(2)アクセス制御機能

利用者の権限によって保護すべき情報に対するアクセスを制限する機能です。 権限を利用者個人単位に制御する方法や、グループの属性単位に制御する方法があります。

(3)権限管理機能

上記アクセス制御機能で使用される「権限」を設定管理する機能です。 本機能の実装にあたっては、権限設定する人が確かに本人であるか「(1)主体認証機能」で確認するとと

もに、「権限設定の権限」を持たない人が勝手に権限を変更しないように「(2)アクセス制御機能」でアクセス制御する機能があわせて実装されている必要があります。

(4)証跡管理機能

「証跡」とは、情報システムの利用記録であり、システムの稼動ログ、利用者のログインログアウトやファイ

ル操作の記録等を指します。証跡管理機能は、この証跡を取得、保存、分析、報告する機能を含みます。 取得した証跡に対しては、不正な改ざんや削除が行われないように適切にアクセス制御を行う必要があり

ます。

(5)保証のための機能 セキュリティ機能を具備したとしても、それが適切に機能しなければ意味がありません。「保証のための機

能」とは、セキュリティ機能が適切に機能することを保証するために、各機能の稼動状況を監視し、必要に応

じて警告等を発する機能です。

(6)暗号と電子署名（鍵管理を含む） 機密情報のディスク内あるいはネットワーク上での盗聴等による暴露を防ぐための暗号化機能、及び発信

人の正当性を保証するための電子署名を行う機能です。暗号化や電子署名を行うためには、鍵を厳重に管

理する必要があります。そのためには、上記の主体認証機能やアクセス制御機能等を利用する必要がありま

す。

2.6 情報システムの運用面のセキュリティ対策 情報セキュリティを確保するためには、運用に関わる様々な事項を検討して運用ルールを策定し、そのルール

に沿って適切に運用することが必要となります。 統一基準には、この運用面でのセキュリティ対策についても個々に規定されています。 例えば以下のようなものです。

① 情報の機密性、完全性、可用性に応じた格付けを行う。（3.2.1(2)(a)）

14

② 主体認証情報格納装置を他者に付与及び貸与しないこと。（4.1.1(3)(d)） ③ 権限管理を行う必要があると認めた情報システムにおいて、識別コードの不正使用の報告を受けた場

合には、直ちに当該識別コードによる使用を停止させること。（4.1.3(3)(b)） また、これらの規定（ルール）を実施するためには、運用する職員に対する教育研修が必要になります。本マ

ニュアルでは教育の実施については触れていませんが、統一基準では「2.2.1 情報セキュリティ対策の教育」で教育について言及されています。

15

2.7 情報セキュリティポリシーの遵守

策定した情報セキュリティポリシーは、情報システムに関わるすべての関係者のもとで遵守されなければ、

その効力を発揮できません。情報セキュリティポリシーの遵守に際して、留意すべき事項を示します。

(1) 職員等の遵守義務 情報セキュリティポリシーで規定された事項については、業務を通じてその対象となる情報システムを扱

う職員には遵守義務があります。職員以外の外部委託事業者や臨時職員等が情報システムを扱う場合は、

そうした作業にあらかじめ契約書や誓約書の作成を通じて、情報セキュリティポリシーを遵守することを約

束してもらうことが一般的です。 なお、自治体の情報システムの中には、利用者として市民や不特定多数のインターネット利用者等が含

まれるものもあります。しかしながら統一基準では行政事務従事者以外は適用範囲の対象外であるため、

こうした利用者を対象とした事項はありません（主体認証に関しては国民向けのサービスの場合に「注意

喚起することが望ましい」とされています（4.1.1））。したがって、必要であれば行政事務従事者以外の利用者にも注意喚起するよう注意してください。

(2) 実施手順の策定 総務省の情報セキュリティポリシーに関するガイドラインによれば、情報セキュリティポリシーには「基本

方針」と「対策基準」の２つの規程が含まれます。これらは情報セキュリティに関する基本的な方向性や基

準を定めることを目的とした文書であるため、要求事項は必ずしも具体的に記述されているわけではあり

ません。これをそのまま遵守しようとしても、どうすれば遵守したことになるのか判断が困難です。そこで、

「対策基準」を、具体的なシステムや手順、手続に展開して個別の実施事項を定めるものが「実施手順」で

す。「実施手順」は情報セキュリティポリシーには含まれないため、情報セキュリティポリシーの適用対象と

なる情報システムの種類に応じて別途策定する必要があります。 統一基準では、実施手順に相当するものとして情報システムに関する「情報セキュリティ関係規程」を定

め、これを遵守することを求めています。

(3) 遵守状況のチェック 情報セキュリティポリシーが遵守されているかどうかを検証する手段として、統一基準では以下の２つの

方法を定めています。 ① 自己点検（2.3.1）

情報システムの運用者、利用者が所属する部署内において、予め定められた点検項目をもとに、

情報セキュリティポリシーの遵守状況を確認するものです。 ② 情報セキュリティ監査（2.3.2）

対象組織と情報システムに対する独立性を有する者が、対策の妥当性や運用の適切性などの観

点から情報セキュリティポリシーの遵守状況を確認するものです。一般に監査業務は組織の内部の

監査担当者ないし部署によって行う内部監査と、組織外部の者を含めた形で行う外部監査の 2 種類がありますが、自治体を対象とした情報セキュリティ監査の場合、情報セキュリティに関する十分

な専門知識をもつ職員が限られていることと、外部の視点を交えることで客観性を確保する意味か

ら、外部監査の形式で行われるのが一般的です。

16

情報セキュリティ監査に関しては、経済産業省の Web サイト（http://www.meti.go.jp）において「情報セキュリティ監査基準」とその実施基準ガイドラインが公開されており、その中で詳細な説明が

行われていますので参照してください。

2.8 情報システムのライフサイクルとセキュリティ

情報セキュリティの確保に際しては、情報システムのライフサイクルに応じた対応が求められます。さらに、

ライフサイクルのほか、情報システムのマネジメントサイクルを含めてセキュリティ対策を考えていく必要があり

ます。

(1) 情報システムのライフサイクル 情報システムのライフサイクルは、その計画、設計、構築、運用、監視、移行、廃棄及び見直しといった

各段階に分類することができます。このとき、情報システムを用いた業務でセキュリティを確保するために

求められる要件は、各段階に応じて異なってくるため、統一基準では情報システムのライフサイクルの視

点から、各段階毎の対策を定めています。その主なものを示すと次のようになります。

表 2-3 情報システムのライフサイクルと主なセキュリティ要求事項 ライフサイクルの段階 主な要求事項 全般 セキュリティ維持が可能な体制の確保

計画・設計

機器等の購入・リース及びソフトウェア開発において必要な対策の策定 情報セキュリティについての機能の設定 情報セキュリティについての脅威への対策の策定 情報システムの構成要素についての対策の策定 第三者機関によるセキュリティ設計仕様書（Security Target）の ST 評価・ST 確認 運用段階への導入のための手順及び環境の策定 IT セキュリティ評価及び認証制度に基づく認証を取得している製品の選択

構築・運用・監視 セキュリティ要件に基づき定めた情報セキュリティ対策の実施

移行・廃棄 情報の消去及び保存、並びに情報システムの廃棄及び再利用についての

必要性の検討、適切な措置の採用 見直し 情報セキュリティ対策について見直しを行う必要性の有無を適時検討

(2) 情報セキュリティマネジメントにおける PDCA サイクル 情報セキュリティマネジメントシステム（ISMS）は、品質管理（ISO9000 シリーズ）や環境管理（ISO14000 シリーズ）と同様、「マネジメントシステム」という考え方を情報セキュリティに適用したものです。情報セキュリティに関する国際標準規格である ISO/IEC27001（2005 年発行、JIS Q 27001 と同じ）では、組織における情報セキュリティ要求事項を満足させるための活動及びプロセスのモデルとして、「PDCAモデル」が採用されています。これは、計画（Plan）、実行（Do）、点検（Check）、処置（Act）の４つの要素

17

をサイクルとして展開していくことで、情報セキュリティの継続的な向上を実現していくものです。 具体的な作業としては以下が相当します。なお、これらには職員が行う作業だけでなく、外部業者等が

行う作業も含まれます。 ① 計画（Plan）

基本方針や目的、プロセス及び手順の確立に関する事項です。 ・ 企画

情報システムの導入や更改に関する企画の立案や構想の検討などです。 ・ 関連規程、手続の策定

新たな情報システムの調達や運用に際して必要となる、規定や手続きの策定など。既存の規定

や手続きを修正することも含みます。 ・ 調達

調達仕様の作成とこれに基づく調達のプロセスに相当します。 ・ 設計・開発・テスト

情報システムの機能設計から詳細設計までのあらゆる設計とこれに基づく開発やテストを含みま

す。 ② 実行（Do）

基本方針や目的、プロセス及び手順の導入及び運用に関する事項です。 ・ 運用

ユーザ管理、リソース管理、異常の検知など、運用に関する作業全般を含みます。 ・ 証跡の保存

事故や不正アクセスに備えて、情報システムにおけるログファイルを保存する作業に相当しま

す。 ・ 緊急時対応

情報システムの故障、不正アクセスを含む事故や自然災害の発生時の、通常の運用体制とは

異なる対応に関する作業を指します。 ③ 点検（Check）

基本方針、目的及び実際の経験に照らした、プロセスのパフォーマンス評価及びそのレビューに関

する事項です。 ・ 自己点検（2.3.1）

予め定められた点検項目をもとに、運用者・利用者が自ら情報セキュリティポリシーの遵守状況

を確認するものです。 ・ 情報セキュリティ監査（2.3.2）

運用者・利用者と独立性を有する者が、情報セキュリティポリシーの遵守状況を確認します。 ④ 処置（Act）

継続的な改善を達成するための是正措置及び予防措置の実施に関する事項です。 ・ 運用体制、手続きの見直し（2.4 項）

③の結果をもとに、情報セキュリティ対策をより有効なものとすべく、情報セキュリティポリシー自

体を含め、規程や手続とそれを実施する体制の見直しを行います。

18

3. 調達時のセキュリティ要求仕様の作成方法

3.1 情報システムの調達プロセス 一般に情報システムの調達は次のようなプロセス（ライフサイクル）で実施されます。（出典：ニューメディア開

発協会「調達ガイドライン」（平成 18 年 3 月））

図 3.1-1 情報システムの調達プロセス

① 企画・立案 調達対象の情報システムの背景・目的、対象業務・システム概要、調達範囲と内容、セキュリティの

考え方、他の情報システムとの関連を検討し、費用対効果分析を実施して調達内容を情報システム

調達構想として取りまとめます。

② 予算手続き 予算年度による制約が調達の合理性・一貫性を損なうことのないように、複数年度予算の確保を考

慮します。

③ 調達基本計画策定 ライフサイクル全体を見通した事業（予算）の執行計画として調達の計画を策定します。 このプロセスで、上記で作成した情報システム調達構想を踏まえたシステム要件定義書、提案依頼

書等が策定されます。

④ 調達(契約） 調達者は、調達仕様書にセキュリティ要件をセキュリティ要求仕様として記載して公示します。 提案者は、提案する提案仕様書にセキュリティ要求仕様に対する回答をセキュリティ提案仕様とし

て記載して提出します。 調達者は、提案仕様書に記載されたセキュリティ提案仕様の内容を審査し、発注先を選定、契約（調

印）します。

⑤ 実施（設計・開発・導入） 調達対象の情報システムの設計・開発・導入を行います。

①企画･立

案

② 予 算 手

続き

③ 調 達 基

本 計 画 策

定

⑤実施（設

計 ・ 開 発 ・

導入）

④調達（契

約）

⑥運用・保

守

19

⑥ 運用・保守 構築された情報システムの稼動後、情報システムによるサービスを提供するための運用・保守を実

施すると共に、情報システムのユーザに対して主にシステム的なサポートを行います。

「③調達基本計画策定」のプロセスで作成されるシステム要件定義書には、セキュリティについての要求仕様

も含まれます。従来、セキュリティについての要求仕様は、システムの要件定義に含まれるか、簡単に触れられ

る程度でした。しかし、それではセキュリティ要求仕様が適切なものであるのか、過不足がないのか判断しづらい

という問題があります。本マニュアルでは、セキュリティ要求仕様を独立した文書として作成することで、適切なセ

キュリティ要求を正確に開発者（受託者）に伝達し、提案を検証する方法を示しています。

3.2 セキュリティ要求仕様の果たすべき役割 セキュアなソフトウェアや情報システムを構築するためには、調達者と開発者（受託者）がセキュリティ要件の仕

様について正確に情報交換する必要があります。 具体的には、「情報資産」（守るべき対象）、「前提条件」（システムの利用・設置環境、利用形態、利用組織の

対応内容等）を明確にする必要があります。 「情報資産」を明らかにすることで、セキュリティ機能で守るべき対象に漏れが出ることを防ぐと同時に対象を限

定することで無駄な投資を防ぐことが可能となります。 「前提条件」を明確にすることで、「情報資産」に対する脅威は何かを推測することができるようになります。例え

ば、情報を保持するサーバを通常の執務室に設置せざるを得ないという前提があった場合、「権限のない者が

サーバに物理的にアクセスする」という脅威が想定できます。その脅威の想定のもとに、例えば「ディスク内を暗

号化し、不正な持ち出しに対抗する」というセキュリティ機能を持つシステム提案が可能となります。あるいは、

「鍵付きの堅牢なラックにサーバを格納する」という提案があるかもしれません。 前提条件からはたくさんの脅威が導かれることがあります。しかし、あらゆる脅威に対抗することは膨大なコスト

が必要になります。そこで、内容によっては、「対処すべき明示的な脅威」も調達者が明確化する必要がありま

す。 情報資産を守る「セキュリティ機能」の実現方法には様々な方法が考えられます。その実現方法について依頼

者側に要求があればそれも正確に開発者に伝達する必要があります。例えば、利用者個人を認証する方法に

は、パスワード、IC カード、生体認証等様々な方法があります。実際の仕様の選択においては、他の業務との整合やコスト、拡張性等を考慮して調達者側が具体的に指示する必要がある場合もあります。 セキュリティ要求仕様はこれらの「情報資産」「前提条件」を明確にし、必要に応じて「対処すべき明示的な脅

威」、「具体的なセキュリティ機能の要求」を明確に開発者に伝達する役割を担うものです。

3.3 セキュリティ要求仕様の構成 セキュリティ要求仕様では、「3.2 セキュリティ要求仕様の果たすべき役割」で示した各項目を含める必要があり

20

ます。セキュリティ要求仕様で記載すべき項目は以下の通りです。 ① システム概要 要求するシステムの概要を示すことで、セキュリティ要求仕様の理解を助けるものです。システムの詳細は、

「システム要件定義書」に示されます。 開発者は、システム要件を考慮することで、当該システムの機能や利便性を損なわないようにセキュリティ機能

を設計・提案することが可能となります。 システム概要には、システム全体概要、ハードウェア構成、ソフトウェア構成、ネットワーク構成、外部システムと

の連携、機能概要、想定ユーザ等が記載されます。 ② 保護すべき情報資産 保護すべき情報資産を明記します。情報資産は、その重要度のレベル（機密性、完全性、可用性ごとに表す）

で表すことが一般的です。 ③ 前提条件 物理的環境、ネットワーク環境、組織的対応状況、システムの前提（情報交換の内容、利用者等）を明記しま

す。 ④ 脅威（必要に応じて）

システムの運用環境において想定される、調達者が特に対策を要求したい脅威を示します。

21

3.4 セキュリティ要求仕様の検討における手順とポイント

前項の構成をもとに、セキュリティ要求仕様を検討する際の手順とポイントについて整理します。

(1) セキュリティ要求仕様の検討手順 セキュリティ要求仕様の検討手順は、おおよそ以下のようになります。

① 要求仕様にすべき項目の候補の列挙 候補の列挙に際しては、必要な項目が抜け落ちるのを避けるため、標準的な規格や基準を検討材

料として用いるのが一般的です。このマニュアルでは、この材料として統一基準を利用します。3.6で示すセキュリティ要件検討支援ツールを用いることで、簡単に候補を得ることができます。

② 現行のセキュリティ要件との比較 これまで用いてきたセキュリティ要件がある場合は、①で得た候補と比較してみます。この比較結果

を、以下の③、④の作業を行う際の参考にします。 ③ 不要な項目の除外

①で得た候補の中から、自組織にはない設備やサービスについて扱っている項目など、必要のな

い項目を除外します。 ④ 特殊な項目の追加

②とは逆に、①に含まれていないが、要求仕様に含める必要があると考える項目を追加します。具

体的には、特殊な設備や環境への対策項目などが想定されます。 ⑤ 必須とするかどうかの判断

①～③の手順で列挙した項目を、以下のいずれかに分類します。分類するための判断基準につい

ては、後述の(2)で示します。 ・ 項目に記載された要求事項を満たすことを必須とする項目 ・ 要求事項を満たすことが望ましいが、実現されていなくても差し支えない項目

(2) 検討のポイント 要求仕様に含めるべきかどうか、あるいは必須項目とすべきかどうかの判断基準を以下に示します。 ア 要求仕様において必須とすべき項目

必須とすべき項目は、以下の条件のいずれかに当てはまるものになります。 ・ 自治体のセキュリティポリシーにおいて要求事項としているもの ・ 情報システムのセキュリティ確保に関する重要な要件・指示を含むもの ・ 曖昧にすることが情報セキュリティの低下を招く恐れのあるもの

イ 要求仕様において必須とする必要がない項目 反対に、必須としない項目は以下のような条件に当てはまるものです。 ・ 準拠すべきポリシーや基準のいずれにおいても必須要件とされていないもの ・ 項目を除いてもセキュリティ低下の懸念がないもの ・ 現在の製品や技術動向では実現の見通しが低いか、実現可能であっても費用対効果が著しく

悪くなることが懸念されるもの

22

3.5 セキュリティ要求仕様の作成における手順とポイント

前項の検討をもとに、具体的なセキュリティ要求仕様を作成する手順を示します。なお、ここに示す内容は、

いずれも 3.4 における検討が済んでいることを前提とするものです。

(1) セキュリティ要求仕様の作成手順 セキュリティ要求仕様の作成手順は、以下のようになります。

① 要求仕様の列挙 3.4 での検討をもとに抽出された項目を列挙します。

② 項目の順序調整、分類 利用者認証、回線、証跡管理等、情報セキュリティの分野別に要求仕様を整理してまとめます。

③ 調達時に提案を求める項目の選択 要求仕様を詳細にわたって指示するのではなく、要求仕様では概要のみを提示し、具体的な内容

については調達参加者からの提案を求めることもできます。詳細については(2)で説明します。 ④ 要求仕様のとりまとめ

以上の結果を整形し、文書化します。

(2) 調達時に提案を求めるべき項目について 要求仕様を詳細まで定めるか、提案を求めるかのいずれが適切かの判断は、項目に求められる要件の

性質によって異なります。 ア 要求仕様において詳細まで指示すべき項目

要求仕様において発注側が詳細まで仕様を定めるべき項目は、以下のような条件のものです。 ・ 上位規程等で仕様が明確に規定されているもの ・ 実装方式等を厳密に定めておかないと、情報システムの円滑な稼動やセキュリティの確保に支

障をきたすもの ・ 実装方法に選択の余地が無く、提案に委ねても差異がないと思われるもの

イ 要求仕様において提案を求めるべき項目 調達参加者からの提案を求める項目は、以下に示す条件を全て満たす必要があります。 ・ 提案内容の妥当性について、発注側での評価が可能なもの ・ 参加者における提案の工夫によってコスト削減や性能向上が期待できるもの ・ 概括的な要件の指示のみでも、セキュリティの確保に関する影響の生じないもの

3.6 調達シーンごとのセキュリティ要件検討支援ツールの活用方法

セキュリティ要件検討支援ツールは、情報システムのセキュリティ要求仕様を作成するにあたり、以下の４

つの機能のステップを提供します。これらの機能を必要に応じて利用することにより、情報システムのセキュリ

ティ要件の検討・見直しや、情報システムのセキュリティポリシーの見直しに活用することができます。

23

① 対応すべきセキュリティ要件候補（推奨項目）の抽出 対象とする情報システムに対して推奨されるセキュリティ要件を自動的に抽出し、以下の２つの観点か

ら対応すべきセキュリティ要件候補（推奨項目）として参照することができます。 対象とする情報システムの稼動環境や運用に関する前提条件から想定される脅威に対抗するため

のセキュリティ要件 目標とするセキュリティのベースラインとなる基準もしくは自治体のセキュリティポリシーとして求める

セキュリティ要件 ② 対応すべきセキュリティ要件候補（テンプレート）の選択と集約

自治体向けの代表的な情報システムが具備すべきセキュリティ要件のテンプレートが用意されており、

これらのうちの１つもしくは複数を選択し、対応すべきセキュリティ要件候補（テンプレート）として集約する

ことができます。 ③ 対応すべきセキュリティ要件候補と現状のセキュリティ要件との差分抽出 ①と②のセキュリティ要件候補のそれぞれと、対象とする情報システムの現状のセキュリティ要件との差

分を自動抽出し、以下のような分類で確認することができます。（以下の記号で表記されます）

△：現状のセキュリティ要件にはないが、セキュリティ要件候補（推奨項目）として抽出されたもの ▲：現状のセキュリティ要件にはないが、セキュリティ要件候補（テンプレート）として集約されたもの ＋：セキュリティ要件候補にはないが、現状のセキュリティ要件となっているもの

④ 採択したセキュリティ要件に基づきセキュリティ要求仕様を作成

①、②、③等の結果を踏まえ、今回の調達においてセキュリティ要求仕様とする項目の採否を検討・指

定します。この指定に基づき、セキュリティ要求仕様書シート（別紙３～別紙６の目的に応じた４種類の要

求仕様書シート）を自動で作成します。 上記の４つのセキュリティ要求仕様の確認は、情報システムのセキュリティを検討する際のいくつかの異な

るシーンで活用することができます。ここでは、自治体において情報システムのセキュリティを検討する際に

セキュリティ要件検討支援ツールをどのように活用すればよいのか、利用シーンごとに示します。

(1) 新規に情報システム構築を行う際のセキュリティ要件の検討 新しい情報システムを構築する際には、その情報システムでカバーする業務領域に関する分析を行い、

システム化すべき業務システム要件を整理したうえで調達仕様書をとりまとめます。その際、情報システム

で考慮すべきセキュリティ要件について、想定する情報システムの稼動環境や運用方法で起こり得る脅威

への対策や、その情報システムへの適用が望まれる基準（統一基準や自治体セキュリティポリシーガイド

など）に基づき、セキュリティ要件の候補を導き出す際に、セキュリティ要件検討支援ツールを活用します。 ※ 導き出されたセキュリティ要件候補を確認のうえ指定することで、セキュリティ要求仕様の雛

形を作成することもできます。

24

運用面のセキュリティ要件を変化させることで、最適な技術的セキュリティ仕様を導く

検討システム

設計上のセキュリティ環境 技術的セキュリティ要件（調達仕様）

運用面でのセキュリティ要件

セキュリティ要件

検討支援ツール

セキュリティポリシー

図 3.6-1 ツール活用方法（情報システム新規調達時） セキュリティ要件検討支援ツールの活用の流れは以下の通りです。

（必須）セキュリティ環境の設定前提条件の記入

（任意）情報資産評価を行い、セキュリティカテゴリを確認

（任意）基準とするセキュリティポリシーを選択

（必須）抽出ロジックの選択

（任意）自治体情報システム・サブシステムのテンプレートの選択

（前提条件入力シート）　新規導入を検討する情報システムについて、構想段階で検討された稼動環境や運用方法に関する質問に対して、選択肢から番号を選ぶ。これにより想定される脅威に対抗するためのセキュリティ要件候補を導くための準備ができる。

（情報資産評価シート）　新規導入する情報システムで扱うことを想定する情報のうち、セキュリティ面で考慮すべきカテゴリに含まれる情報の有無を検討し、一般的に求められるセキュリティカテゴリ（SC)を確認する

（全体フロー）　新規導入する情報システムで対応が望まれるセキュリティポリシー（ベースラインとする基準）を選択する

（全体フロー ）　対応すべきセキュリティ要件候補を抽出するためのロジッ

クを選択する。前提条件で想定される脅威への対策項目か、ベースラインか、またはこれらを踏まえたANDまたはOR条件とするか、などが選択できる

（全体フロー ）　情報システムのテンプレートから１つもしくは複数選択し、標準的なシステムの場合に対応を検討することになるセキュリティ要件候補を選択することもできる

（必須）セキュリティ要件の候補の抽出

（全体フロー ）　候補の抽出の実行を行うと、セキュリティ要件候補（推奨項

目）及び、選択した場合はテンプレートのセキュリティ要件の集約が自動で行われ、（要求検討シート）のセキュリティ要件候補の欄にそれぞれ抽出結果が表示される

図 3.6-2 ツール活用の流れ（情報システム新規調達時） 活用のポイントを以下に示します。

前提条件入力シートにて、想定されるさまざまな条件に対する項目の選択番号を変更し、候補の

抽出の実行を行うことで、選択した前提条件に基づいて抽出されたセキュリティ要件候補を確認

25

していくことができます。 選択番号が記入されない場合（空白もしくは選択範囲外の番号の場合）、そのようなケースの前

提条件は該当しないものとして、この条件に関連する脅威も候補とするセキュリティ要件も抽出さ

れません。 基準とするベースラインと、前提条件から導かれた対処すべき脅威への対抗を考慮したセキュリ

ティ要件候補（推奨項目）を抽出する場合、AND 条件で候補を抽出すると重要度の高い要件候補に絞り込まれ、OR 条件で抽出すると要件候補のもれを減らすためにより広範に要件を抽出します。

対象システムに類似した構成を持つシステムテンプレート（１つもしくは複数）を選択し候補の抽

出を実行すると、上記のセキュリティ要件候補（推奨項目）とは別に、選択したテンプレート（群）

のセキュリティ要件候補を抽出します。これらを要件検討シートでならべて表示することで、それ

ぞれの方法により抽出したセキュリティ要件候補を比較検討することができます。

(2) 現状の情報システムのセキュリティ問題の分析と見直し 稼動中の情報システムは、その運用を行う過程でさまざまな要因により新たなセキュリティ上の脅威が

認識されたり脆弱な面が発見されたりします。このようなセキュリティ上の問題の有無を検討し、情報システ

ムに求められるセキュリティ対策を見直す際に、セキュリティ要件検討支援ツールを活用します。

検討システム

システムのセキュリティ環境

技術的セキュリティ要件

（調達仕様）

運用面での

セキュリティ要件

セキュリティ要件

検討支援ツール

セキュリティポリシー 現状のシステムの技術的セキュリティ要件

現状のセキュリティ運用環境

見直し

（技術的・管理）

図 3.6-3 ツール活用方法（現状の情報システム見直し時） セキュリティ要件検討支援ツールの活用の流れは以下の通りです。

26

（必須）セキュリティ環境の設定前提条件の記入

（任意）基準とするセキュリティポリシーを選択

（必須）抽出ロジックの選択

（任意）自治体情報システム・サブシステムのテンプレートの選択

（前提条件入力シート）　現状の情報システムの稼動環境や運用方法に関する質問に対して、選択肢から番号を選ぶ。これにより想定される脅威に対抗するためのセキュリティ要件候補を導くための準備ができる。

（全体フロー ）　現状の情報システムで対応すべきセキュリティポリシー（ベー

スラインとする基準）を選択する

（全体フロー ）　対応すべきセキュリティ要件候補を抽出するためのロジックを選択する。前提条件で想定される脅威への対策項目か、ベースラインか、またはこれらを踏まえた論理和・積とするか、などが選択できる

（全体フロー ）　現状の情報システムと類似する業務特性やシステム構成を持つシステムのテンプレートを１つもしくは複数選択し、標準的なシステムの場合に対応を検討することになるセキュリティ要件候補を選択することもできる

（必須）セキュリティ要件の候補の抽出

（全体フロー ）　候補の抽出の実行を行うと、セキュリティ要件候補（推奨項

目）及び、選択した場合はテンプレートのセキュリティ要件の集約が自動で行われ、（要求検討シート）の「セキュリティ要件候補」の欄にそれぞれ抽出結果が表示される

（必須）現行のセキュリティ要件の設定

（要件検討シート）　現行の情報システムにて考慮しているセキュリティ要件について、シートで示されるセキュリティ要件項目ごとに現状適用の採否を選択していく

（必須）差分の抽出の実行

（全体フロー ）　差分の抽出の実行を行うと、２つのセキュリティ要件候補

（推奨項目とテンプレート）それぞれと、設定した現行のセキュリティ要件との差分を抽出し、（要求検討）シートの「候補と現行の差分」の欄にそれぞれ抽出した差分結果を示す記号（△、▲、＋）が表示される

図 3.6-4 ツール活用の流れ（現状の情報システム見直し時） 活用のポイントを以下に示します。

現行のセキュリティ要件の設定を行う際、適用している（○）、適用していない（×）と明示的に設

定することで差分抽出の計算が行われます。○や×でなくブランクとすると、差分抽出の計算は

行なわず、「候補と現行との差分」欄には何も表示しませんので注意してください。 差分情報の記号から、以下のケースが想定されます。

△：脅威が残留している可能性がある → 候補のセキュリティ要件の追加を検討する ▲：搭載すべき標準機能の漏れの可能性がある → 候補のセキュリティ要件の追加を検討する ＋：現行システムのセキュリティ要件が過剰かもしれない → 効率化について検討する

(3) 情報システムを考慮したセキュリティポリシーの分析と見直し 自治体の情報システムに関するセキュリティポリシーについて、対象とする情報システムのセキュリティ

問題に関する検討状況と、既存のセキュリティポリシーとの対応を検討する際に、セキュリティ要件検討支

援ツールを活用します。

27

検討システム

システムのセキュリティ環境

技術的セキュリティ要件

（調達仕様）

運用面での

セキュリティ要件

セキュリティ要件

検討支援ツール

セキュリティポリシー 現状のシステムの技術的セキュリティ要件

現状のセキュリティ運用環境

見直し

（セキュリティポリシー）

図 3.6-5 ツール活用方法（現状のセキュリティポリシー見直し時） セキュリティ要件検討支援ツールの活用の流れは以下の通りです。

（必須）基準とするセキュリティポリシーを選択

（必須）抽出ロジックの選択

（全体フロー ） 自治体自ら総務省セキュリティポリシーガイドに基づいて策

定したセキュリティポリシーを選択することができる

（全体フロー ） 対応すべきセキュリティ要件候補を抽出するためのロジックを選択する。ここでは、（２）ベースライン対応項目のみを抽出 を選択する

（必須）現行のセキュリティ要件の設定 （要件検討シート） 現行の情報システムにて考慮しているセキュリティ要件を、このシート上の「現行のセキュリティ要件」欄に各セキュリティ要件項目を適用しているかどうかの値（○、×またはブランク）を選択していく

（必須）差分の抽出の実行（全体フロー ） 差分の抽出の実行を行うと、セキュリティ要件候補（推奨項

目）と、設定した現行のセキュリティ要件との差分を抽出し、（要求検討）シートの「候補と現行の差分」の欄にそれぞれ抽出した差分結果を示す記号（△、＋）が表示される

（必須）セキュリティポリシーの入力・確認

（管理策入力シート ） 自治体のセキュリティポリシーで適用すべきISMS管理基準（ISO/IEC27001:2005）の管理策を選択する。入力完了ボタンを押し、確認メニューで「はい」を選択すると、選択した管理策を統一基準のセキュリティ要件に変換し、自治体ポリシーシートに反映する。

（必須）セキュリティポリシーの入力・確認

（自治体ポリシーシート ） 上記操作の結果が反映された自治体のセキュリティポリシーで適用すべき統一基準のセキュリティ要件を確認し、必要に応じてする。総務省セキュリティポリシーガイドラインで示される内容と統一基準との対応例を参考にすることができる。

図 3.6-6 ツール活用の流れ（現状のセキュリティポリシー見直し時） 活用のポイントを以下に示します。

（管理策入力シート）にて、自治体のセキュリティポリシーを ISMS 管理基準（ISO/IEC27001）の

28

管理策に沿って選択してください。入力後、「入力完了（入力内容をセット）」ボタンを押すと、ツ

ールが自動的に選択した管理策に相当する統一基準のセキュリティ要件を選択し、（自治体ポリ

シーシート）の「自治体セキュリティポリシー（変換後）」欄に反映します。 自治体のセキュリティポリシーに沿って統一基準のセキュリティ要件を確認・修正する際、（自治

体ポリシーシート）では、総務省の公開する地方公共団体における情報セキュリティポリシーに関

するガイドラインで示す項目と統一基準のセキュリティ要件との関係の例を示しているため、これ

を参考としてセキュリティ要件を選択してください。 自治体情報システムのテンプレートは何も選択しない状態で、候補の抽出の実行を行ってくださ

い。 現行のセキュリティ要件の設定を行う際、適用している（○）、適用していない（×）と明示的に設

定することで差分抽出の計算が行われます。○や×でなくブランクとすると、差分抽出の計算は

行なわず、「候補と現行との差分」欄には何も表示しませんので注意してください。 差分情報の記号から、以下のケースが想定されます。

△：脅威が残留している可能性がある → 候補のセキュリティ要件を適用する方向でセキュリテ

ィポリシーの見直しを図る ×：現行ポリシーに関連するセキュリティ要件が過剰かもしれない → 候補のセキュリティ要件を

適用しなくても問題ないかどうかの検討を行ないセキュリティポリシーの見直しを図る

(4) 情報システムを調達する段階のセキュリティ要求仕様の作成 新規の情報システムを構築する場合、もしくは現在運用中の情報システムに対して機能改善等の改修

を行う場合、現状の業務及び情報システムに関する業務ニーズや業務効率化に向けた要件を洗い出し、

あるべき姿との比較および最適化検討を経て、情報システムの機能改修項目を決定していきます。その

際、情報システムの現状のセキュリティ問題を踏まえた分析をあわせて実施し、見直すべきセキュリティ対

策を調達する際に、セキュリティ要件検討支援ツールを活用します。この場合、セキュリティ要件等の分析

は(1)～（3）の分析･見直し時のシート利用方法に準じますが、（総括シート）の「要求仕様の選定」を選択しジャンプした（要件検討シート）にて、候補情報、差分情報などの値を参考として各セキュリティ要件の採

否を決定し「項目採否（必要性）」の欄に○もしくは△を設定します。その後、「セキュリティ要求仕様案（４

シート）の生成」を選択すると、別紙３～６の４つのシートに、「項目採否（必要性）」の欄に○もしくは△を設

定したセキュリティ要件項目のみで構成したセキュリティ要求仕様書案が作成されます。

3.7 調達に応じたセキュリティ要求仕様のまとめ方 セキュリティ要件検討支援ツールで作成した（セキュリティ要求仕様シート：別紙３～６）を利用し、調達に応じた

以下の情報記入を行い、セキュリティ要求仕様項目をより明確化していきます。このシートをセキュリティ要求仕

様書から参照することで、情報システムの調達に利用することができます。「必須」欄には、（要件検討シート）の

「項目採否（必要性）」の欄に○を設定した場合は○が表示され、△を設定した場合は空白となります。「必須」

欄の○の有無を参考として、「提案」欄に○を付けるか否か（提案欄に○を付けた場合、応札するベンダーに、

29

そのセキュリティ要件の採用有無について理由とともに妥当な対応方法の提案を求めることを意図します。 ① 別紙３ 情報システムに実装すべき技術的セキュリティ要求仕様を簡潔にまとめたものです。調達に利用するほか、自

治体自ら情報システムのセキュリティ要件の過不足をさらに検討する際にもこのシートを利用することができま

す。 ② 別紙４ 情報システムに実装すべき技術的セキュリティ要求仕様について応札者から提案をうけ、セキュリティ要件の

充足度等、自治体側で提案書を精査する際に有効な提案情報を求めるための書式の例です。 ③ 別紙５ 情報システムの運用やシステム稼動環境において実現すべき運用面のセキュリティ要求仕様を簡潔にまとめ

たものです。 ④ 別紙６ 情報システムの運用やシステム稼動環境において実現すべき運用面のセキュリティ要求仕様について、応札

者から提案をうけ、セキュリティ要件の充足度等、自治体側で提案書を精査する際に有効な提案情報を求める

ための書式の例です。

30

4. 提案書のセキュリティに関する評価方法

セキュリティ要件を充足する情報システムを調達するためには、提案者の提案内容がセキュリティ要件を充足

することを検証・評価する必要があります。 以下の記述は、企画コンペによる随意契約先選定を前提として、セキュリティ要求仕様に基づく評価表の作成、

及び提案内容の評価の方法を解説するものです。 他の方法で調達を行う場合には、本章で記述する評価方法は、以下のように活用することができます。

表 4-1 本章で示す評価方法の利用場面 本章の記述

調達方法 活用場面 活用目的 評価の範囲 その他

企画コンペによる随

意契約先選定 提案の評価 委託先の選定 必須への対応適否

加点 －

既存システム等によ

る随意契約 委託先との仕

様検討 仕様検討 必須への対応適否

－

総合評価による競

争入札 提案の評価 委託先の選定 必須への対応適否

加点 総合評価競争入

札の手順に準拠 一般的な競争入札

入札意思確認 入札者を仕様を満たす事業者に限定

必須への対応適否 －

4.1 提案の評価に関する手順

(1) セキュリティ要求仕様に基づく評価表の作成 前節までで整理したセキュリティ要求仕様より、評価ポイントを策定して評価表を策定します。 要求仕様の各項目について、以下の 2 つの評価のいずれ（あるいは双方）の対象とするかを整理します。

ア セキュリティ要求仕様に対する充足度評価 提案者の提案は、この評価の対象とする項目全てを満たさなければなりません。評価の結果全ての項目

を満たしている提案だけが、次の段階で行う実効性評価の対象となります。 なお、充足度評価においては、要求仕様に方法まで示して規定する場合と、同様のセキュリティレベル

を確保する代替案による提案を許可する場合とが考�