自治体システム標準化～高コスト化の温床か？「非機能要件の標準」②自治体が決める要件編

キホン編に引き続き、今回は自治体が主体的に決めるべきまとめておくべき要件をピックアップ。ベンダーがほぼ関与しない（できない）ので、各自治体の方々が抑えておく必要がある。要件の数としては多くなく、日頃からキチンと情報システムに関する要件をルール化されている自治体はまとめる程度でよいだろう。

E.1.1.1/セキュリティ/前提条件・制約条件

●メトリクス
順守すべき規程、ルール、法令、ガイドライン等の有無

●メトリクス説明
ユーザが順守すべき情報セキュリティに関する規程やルール、
法令、ガイドライン等が存在するかどうかを確認するための項目。
なお、順守すべき規程等が存在する場合は、
規定されている内容と矛盾が生じないよう対策を検討する。
（例）
・情報セキュリティに関する法令
・地方公共団体における情報セキュリティポリシーに関するガイドライン（総務省）
・その他のガイドライン
・その他のルール

●標準選択レベル 
1（有り）

【解説・何をすべきか】

各自治体のセキュリティポリシーなど明文化されているものを整理しておけばよい。また、明文化されていないければ、今から整備しておく必要がある。

E.2.1.1/セキュリティ/セキュリティリスク分析

●メトリクス
リスク分析範囲

●メトリクス説明
システム開発を実施する中で、どの範囲で対象システムの脅威を洗い出し、
影響の分析を実施するかの方針を確認するための項目。
なお、適切な範囲を設定するためには、
資産の洗い出しやデータのライフサイクルの確認等を行う必要がある。
また、洗い出した脅威に対して、対策する範囲を検討する。

●標準選択レベル
1（重要度が高い資産を扱う範囲）

【解説・何をすべきか】

いわゆる、リスクアセスメントをするのがこの要件。
機器や紙を含む記録媒体などの情報資産をすべて洗い出して、
それぞれの情報資産が紛失や漏洩、破損した場合などの影響度などを加味してランク付けし重要度が高いものを洗い出す。
本来は庁内全体で行う必要があると思うが、今回は自治体基幹システムに関係する情報資産のみでよいと考える。
いずれにせよ、一朝一夕には実施できないため今から準備が必要だろう。

リスクアセスメントとリスク対応｜情報セキュリティ対策の基礎

F.1.1.1(F.1.2.1)/システム環境・エコロジー/システム制約・前提条件

●メトリクス
構築（運用）時の制約条件

●メトリクス説明
構築（運用）時の制約となる庁内基準や法令、各地方自治体の条例などの制約が存在しているかの項目。
例）
・J-SOX法
・ISO/IEC27000系
・政府機関の情報セキュリティ対策のための統一基準
・地方公共団体における情報セキュリティポリシーに関するガイドライン（総務省）
・FISC
・プライバシーマーク
・構築（運用）実装場所の制限
など

●標準選択レベル
1（制約有り/重要な制約のみ適用）

【解説・何をすべきか】

いろいろ書いてはいるが、リフト＆シフト作業および運用時におけるルールを明文化することが軸。
個人情報を含むデータは、庁内にとどめるとか、ベンダー作業員は会議室Aのみで作業をさせるとか。
ベンダー都合で、ベンダー社内で作業をする場合、どのような対策や報告が必要かなどをまとめておく。
こと細かくはいらないので、重要な要件だけまとめておけばよい。