６ セキュリティ・バイ・デザイン実施における留意事項
本ガイドラインの最後に、前章までの内容もふまえて、セキュリティ・バイ・デザイン実施にあたっての留意事項について示す。
-
セキュリティ・バイ・デザインにおいては、工程間で不整合なセキュリティ対策が実施されることにより、システムのセキュリティ品質を確保することが困難になるため、工程間で一貫した整合性を確保することを念頭にセキュリティ対策を実施する。
-
本紙記載のセキュリティ・バイ・デザインの実施内容の全てを同時に実現することは困難であることが想定される。自組織の開発プロセスやルール等を考慮し、組織として考慮すべきリスクや実現可能性を踏まえて実施可能なところから運用を開始し、課題改善と内容拡充をはかりながら、成熟度を向上していくことが現実的である。
-
セキュリティ・バイ・デザインは一度実施して終了でなく、新たなセキュリティ脅威の出現やシステム更改等の場合において、セキュリティ・バイ・デザインの再実施要否、（要の場合）再実施方法を検討し、継続的にセキュリティリスクの対応をはかることが肝要である。
別紙1 各工程で参照可能なセキュリティ標準
| # | 提供元 | セキュリティ標準名 | 対象工程 | URL |
|---|---|---|---|---|
| 1 | NISC(内閣サイバーセキュリティセンター) | 政府機関等のサイバーセキュリティ対策のための統一基準群（以下、「統一基準群」という。） | 工程全般 | https://www.nisc.go.jp/policy/group/general/kijun.html |
| 2 | NISC(内閣サイバーセキュリティセンター) | 情報システムに係る政府調達におけるセキュリティ要件策定マニュアル(SBDマニュアル) |
|
|
| 3 | NISC(内閣サイバーセキュリティセンター) | インターネットの安心・安全ハンドブック |
|
|
| 4 | デジタル庁 | 政府情報システムにおける脆弱性診断ガイドライン |
|
https://www.digital.go.jp/resources/standard_guidelines/#ds221 |
| 5 | デジタル庁 | ゼロトラストアーキテクチャ適用方針ガイドライン |
|
|
| 6 | デジタル庁 | CRSAアーキテクチャ技術レポート |
|
https://www.digital.go.jp/resources/standard_guidelines/#ds211 |
| 7 | IPA（情報処理推進機構） | 安全なウェブサイトの作り方 |
|
|
| 8 | IPA（情報処理推進機構） | TLS暗号設定ガイドライン |
|
|
| 9 | IPA（情報処理推進機構） | 組織における内部不正防止ガイドライン |
|
|
| 10 | ISMAP運営委員会 | ISMAPクラウドサービスリスト ISMAP-LIUクラウドサービスリスト ISMAP管理基準 |
セキュリティ要件定義、 セキュア調達 |
|
| 11 | METI（経済産業省） | クラウドサービス利用のための情報セキュリティマネジメントガイドライン |
|
|
| 12 | 各府省情報化統括責任者連絡会 | 行政手続におけるオンラインによる本人確認の手法に関するガイドライン |
|
|
| 13 | CRYPTREC | 電子政府推奨暗号リスト |
|
|
| 14 | IPA（情報処理推進機構） | 『高度標的型攻撃』対策に向けたシステム設計ガイド |
|
|
| 15 | 総務省 | サイバー攻撃（標的型攻撃）対策防御モデルの解説 |
|
|
| 16 | 総務省 | テレワークセキュリティガイドライン |
|
|
| 17 | NIST（National Institute of Standards and Technology） | Cybersecurity Framework |
|
https://www.ipa.go.jp/files/000071204.pdf |
| 18 | NIST（National Institute of Standards and Technology） | SP 800-53（組織と情報システムのためのセキュリティおよびプライバシー管理策） |
|
|
| 19 | FedRAMP | FedRAMP(米国政府機関におけるクラウドセキュリティ認証制度) |
|
|
| 20 | NIST（National Institute of Standards and Technology） | SP 800-190（アプリケーションコンテナセキュリティガイド） |
|
|
| 21 | NIST（National Institute of Standards and Technology） | SP-800-207（ゼロトラストアーキテクチャ） |
|
|
| 22 | ANSSI（フランス国家情報システムセキュリティ機関） | EBIOS RISK MANAGER |
|
|
| 23 | NCSC（National Cyber Security Centre） | Secure design principle |
|
|
| 24 | CIS（Center for Internet Security） | CIS controls Version 8 |
|
|
| 25 | CIS（Center for Internet Security） | CIS Benchmarks |
|
|
| 26 | JPCERT/CC | セキュアコーディング（関連資料） |
|
|
| 27 | OWASP | OWASP 10 |
|
|
| 28 | ISO | ISO27017, ISO27018 |
|
|
| 29 | MVSP （Minimum Viable Secure Product） |
Minimum Viable Secure Product Controls |
|
|
| 30 | CSA（Cloud Security Alliance） | クラウドコンピューティングのためのセキュリティガイダンス |
|
|
| 31 | CSA（Cloud Security Alliance） |
|
|
|
| 32 | JSSEC |
|
|
|
| 33 | JSSEC |
|
|
|
| 34 | JPCERT/CC |
|
|
|
| 35 | JPCERT/CC |
|
|
|
| 36 | IPA（情報処理推進機構） |
|
|
|
| 37 | 各府省情報化統括責任者連絡会 |
|
|
|
| 38 | IPA（情報処理推進機構） |
|
|
|
| 39 | IPA（情報処理推進機構） |
|
|
|
| 40 | METI（経済産業省） |
|
|
|
| 41 | 総務省 |
|
|
|
| 42 | ENISA |
|
|
別紙2 各工程のセキュリティ関連の実施項目
別紙2では、4章に記載したセキュリティ・バイ・デザインの実施内容に基づいた、各工程で実施すべき項目をチェックリストとして示す。
セキュリティ・バイ・デザインの関係者は、本チェックリストを用いて各工程でのセキュリティ・バイ・デザインの実施状況を把握し、本来実施すべき内容の抜け漏れを防止することが求められる（原則全ての項目を実施することが望ましいが、システム特性等に応じて該当しない項目が生じる場合もあることに留意する）。
本チェックリストを用いてセキュリティ・バイ・デザインの実施状況を可視化することで、リスクアセッサー等による検証やセキュリティ監査の効率化や継続的なセキュリティリスク対応の見直しの一助にできるため、積極的に活用すること。
①セキュリティリスク分析/セキュリティ要件定義のチェックリスト
| # | 確認項目 | チェック |
|---|---|---|
| 1 | 【システムプロファイルの作成】 システムで取扱う重要情報の種類、重要情報の処理フローやライフサイクルが分かる内容、ステークホルダー、実施業務、他システムとの連携方法等を記載したシステムプロファイルを作成している |
□ |
| 2 | 【セキュリティ脅威の特定】 脅威分析モデル（Microsoft STRIDEモデル、MITRE ATT＆CK等）を用いて、対象システムにて発生が想定されるセキュリティ脅威を特定している（システム面でのセキュリティ脅威だけでなく、サービス仕様上の脅威や人的ミスによるセキュリティ脅威も含めて検討している） |
□ |
| 3 | 【セキュリティリスク分析の実施】 セキュリティ脅威に対するリスク分析を実施し、対象システムにおけるセキュリティ対応方針として リスク対応優先度、遵守すべきセキュリティ標準、 検証方法、対応リソース等を決定している |
□ |
| 4 | 【セキュリティ要件定義】 セキュリティ対応方針（リスク対応優先度、遵守すべきセキュリティ標準等）に従って、システムで満たすべきセキュリティの状態を機能面、非機能面ともに要件として定義している |
□ |
| 5 | 【多層防御の導入】 サイバー攻撃やセキュリティ事故は発生する前提で、多層的なセキュリティ対策を実施して被害を極小化する考え方に基づいてセキュリティ要件を定義している |
□ |
②セキュア調達のチェックリスト
| # | 確認項目 | チェック |
|---|---|---|
| 1 | 【セキュリティ仕様の策定】 調達仕様書やそれに付随する文書の中に、システムに求めるセキュリティ要件に加えて、委託先に求めるセキュリティ（委託先での情報管理等）や機器/ソフトウェア調達時、サービス選定時のセキュリティ要件に関する記載を含めている |
□ |
| 2 | 【責任範囲の明確化】 システムのセキュリティ対策、セキュリティ運用に抜け漏れが発生しないよう、自組織と委託先のセキュリティ対策に関する責任範囲を明確化した上で調達仕様等におけるセキュリティ関連事項を記載している（クラウドサービスにおいては、クラウドサービスの特性（SaaS,IaaS,PaaS）等を踏まえて、責任範囲を明確化している） |
□ |
| 3 | 【安全な委託先の選定】 セキュリティ仕様を実装できる能力を十分に有し、セキュリティ管理基準（委託元で提示したもの）を満たすことができる安全な委託先を選定している |
□ |
| 4 | 【安全なプロダクトの選定】 システムで利用する機器、ミドルウェア、ライブラリについて、不正侵入の経路となるバックドア等が含まれておらず、サービスの提供期間中にサポートを受けられる安全なプロダクトを選定している |
□ |
③セキュリティ設計のチェックリスト
| # | 確認項目 | チェック |
|---|---|---|
| 1 | 【セキュリティベースライン、フレームワークの導入】 セキュリティ設計の取りこぼしや属人化を避けるため、セキュリティベースラインやフレームワークを参照して、網羅的なセキュリティ設計を実施している 例：CIS control（ver8）をセキュリティベースラインとして用い、具体的な設計（設定）はCISベンチマークを用いてシステムにおけるセキュリティ設計を実施している 等 |
□ |
| 2 | 【アタックサーフェスの最小化】 システムに対するアタックサーフェス（攻撃対象領域）を必要最小限に抑えるため、システムの操作/処理に必要な外部インターフェースや機器のみを公開する仕様としている |
□ |
| 3 | 【不要な機能、サービス、データの削除】 攻撃への悪用や、被害の拡大を防止するため、システムに不要な機能やサービス、データはシステムから取り除いている |
□ |
| 4 | 【外部入力値の検証】 システムに対する外部からの全ての入力は信頼せず、検証した上で、システムに被害が発生しないよう、安全に変換処理等をしている |
□ |
| 5 | 【全層におけるセキュリティ対策】 システムの全構成要素（アプリケーション、ネットワーク、プラットフォーム（OS 、ミドルウェア等））においてセキュリティ対策を実施している |
□ |
| 6 | 【インシデント被害拡大防止対策】 システム分離（ネットワーク分離）、管理者アカウントの保護、アカウントへの必要最低限のアクセス権付与等、インシデント発生時の被害拡大を防止するための対策を実施している |
□ |
| 7 | 【セキュリティ監視の準備】 セキュリティ運用設計として、システムで発生が想定される脅威を検知するために必要なログやセキュリティアラートを定義し、収集し、一元的に管理する設計を実施している |
□ |
| 8 | 【セキュリティ監視設計】 セキュリティ運用設計として、収集したログやセキュリティアラートを定期的に分析し、システムの異常やその兆候を速やかに検知し、必要な関係者に報告するための仕組み（分析方法、エスカレーションフロー等）を検討している |
□ |
| 9 | 【インシデント対応プロセス整備】 セキュリティ運用設計として、インシデント発生時に速やかにインシデント対応およびシステム復旧を可能とするための体制や対応手順を策定している |
□ |
| 10 | 【脆弱性対応方針策定】 システムの運用フェーズで発生するプラットフォームやアプリケーションの脆弱性に対する対応基準、対応方法（セキュリティパッチの適用方法、セキュリティパッチを適用できない場合の代替策等）を策定している |
□ |
| 11 | 【人的ミスへの対応策の検討（仕様やサービスデザインでの対応）】 サービス利用者やシステム管理者等の人的ミスの発生可能性のある仕様については、サービスデザイン等を工夫して防止につとめている |
□ |
| 12 | 【人的ミスへの対応策の検討（その他）】 過去のインシデント事例等も参考に技術的対策、運用的対策、人的対策等を組み合わせて、多角的な視点をもってリスク低減策を実施している |
□ |
④セキュリティ実装のチェックリスト
| # | 確認項目 | チェック |
|---|---|---|
| 1 | 【セキュアコーディング】 アプリケーションセキュリティに関して、セキュアコーディングを実施するためのコーディング規約を策定している |
□ |
| 2 | 【開発用フレームワークやツールの利用】 セキュアコーディングをサポートする機能を有した開発用フレームワークやツール等を活用することで、 脆弱性を作りこまないようにセキュアコーディングを実施している（Webアプリケーションであれば、IPA「安全なウェブサイトの作り方（https://www.ipa.go.jp/security/vuln/websecurity.html）」に記載されているような脆弱性への対処が完了している） |
□ |
| 3 | 【安全なライブラリ、ミドルウェアの利用】 アプリケーションのセキュリティを確保するため、信頼できる安全なライブラリやミドルウェアを利用している |
□ |
| 4 | 【プラットフォームの堅牢化、要塞化】 プラットフォームのセキュリティに関して、セキュリティ設計に基づき、もれなくセキュリティ設定（堅牢化、要塞化）を実施している（クラウドサービス、OS、ミドルウェア、ネットワーク等） |
□ |
| 5 | 【セキュリティテンプレートの利用】 プラットフォームセキュリティに関して、セキュリティテンプレートやセキュリティ設定が組み込まれたシステムイメージ、IaCテンプレート等を利用し、セキュリティ設定（堅牢化、要塞化）の属人性を排除している |
□ |
⑤セキュリティテストのチェックリスト
| # | 確認項目 | チェック |
|---|---|---|
| 1 | 【セキュリティ関連機能のテスト】 システムで実装しているセキュリティ関連機能（利用者認証機能等）において、十分なテストを実施し、（バグ対応等を実施して）機能の品質を確保している |
□ |
| 2 | 【必要な脆弱性診断の実施（アタックサーフェスをカバー）】 システムの特性を考慮して、アタックサーフェス（攻撃対象領域）をもれなくカバーするように脆弱性診断を実施している（Webシステムでアプリケーション診断とプラットフォーム診断、スマホアプリを使用する場合はスマホアプリ診断等が対象） ※脆弱性診断にあたっては、「DS-221 政府情報システムにおける脆弱性診断導入ガイドライン」に従った実施を原則とする |
□ |
| 3 | 【必要な脆弱性診断の実施（システム重要度に応じた診断品質の確保）】 システムの重要度等踏まえて、必要な品質レベルの脆弱性診断を実施している（重要度が高いシステムにおいては、脆弱性診断ツールを実行するだけでなく、専門家による高度な診断を実施する、等） ※脆弱性診断にあたっては、「DS-221 政府情報システムにおける脆弱性診断導入ガイドライン」に従った実施を原則とする |
□ |
| 4 | 【一般的なセキュリティ上の問題点への対応】 リリースにあたり、政府情報システムにおいて作りこまれやすい傾向にあるセキュリティ上の問題点（別紙3システムにおける一般的なセキュリティ上の問題点を参照）について、対応が完了している |
□ |
| 5 | 【脆弱性対応】 脆弱性診断結果に従って、当該脆弱性によって引き起こされるリスクやシステムへの影響を考慮し、優先度に応じて必要な修正を実施している |
□ |
⑥セキュリティ運用準備のチェックリスト
| # | 確認項目 | チェック |
|---|---|---|
| 1 | 【セキュリティ運用体制の確立】 セキュリティ運用として平時（通常時のセキュリティ運用）、有事（インシデント発生時の対応）を実施するのに十分な運用体制を確立している |
□ |
| 2 | 【セキュリティ運用手順の整備】 セキュリティ運用として平時（通常時のセキュリティ運用）、有事（インシデント発生時の対応）を実施するための、具体的な運用手順を整備している （平時（通常時のセキュリティ運用）として求められる実施内容は下記の⑦-1～⑦-6に該当する項目） |
□ |
| 3 | 【インシデント対応訓練の実施】 有事（インシデント発生時の対応）を想定してセキュリティ訓練を実施し、インシデント対応手順の実行性を担保している |
□ |
⑦セキュリティ運用のチェックリスト
| # | 確認項目 | チェック |
|---|---|---|
| 1 | 【システム構成管理】 通常時のセキュリティ運用として、システム構成を管理し、構成情報を最新化している |
□ |
| 2 | 【ソフトウェア構成管理】 通常時のセキュリティ運用として、システムで使用するソフトウェアの開発元、バージョン、ライセンス、依存関係などを容易に参照できるような構成管理している |
□ |
| 3 | 【アカウント管理】 通常時のセキュリティ運用として、システム管理者アカウントの適正管理を行っている（古いアカウントが残らないよう、最新化している） |
□ |
| 4 | 【変更管理】 通常時のセキュリティ運用として、システムの設定変更に合わせて、セキュリティリスクが増大しないよう、セキュリティ対策を見直している（変更管理を行っている） |
□ |
| 5 | 【脆弱性管理】 通常時のセキュリティ運用として、システムに影響する脅威情報や脆弱性情報を定常的に収集し、脅威や脆弱性による影響に関するリスク分析等を実施し、自システムへの対応方針を決定している |
□ |
| 6 | 【ログ、アラート監視】 通常時のセキュリティ運用として、ログやセキュリティアラートを用いた異常な状態の監視等を行い、インシデントやその兆候を早期検知するための仕組みを導入している |
□ |
| 7 | 【インシデント対応手順の整備】 インシデント発生時に速やかに対応するためのインシデント対応体制、インシデント対応手順を整備している |
□ |
| 8 | 【復旧手順の準備】 インシデント発生後、速やかなシステム復旧を実現するため、重要データのバックアップ、システム復旧のリストア手順を整備している |
□ |
| 9 | 【インシデント対応手順等の見直し】 インシデント対応プロセスやシステム復旧プロセスは、有効性確保のための定期的に見直し、更新している |
□ |
別紙3 システムにおける一般的なセキュリティ上の問題点
一般的な政府情報システムにおけるセキュリティ上の問題点は下記表の通りである。これらのセキュリティ上の問題点を作りこまないよう、留意してシステム開発を進めることが求められる。
| 要因 | セキュリティ上の問題点 | |
|---|---|---|
| 1 | 認証管理不備 |
|
| 2 | アクセス制御不備 |
|
| 3 | 暗号化不備 |
|
| 4 | 資産管理、脆弱性管理不備 |
|
| 5 | Webアプリケーションの脆弱性 |
|
| 6 | ログ管理不備 |
|
| 7 | 外部委託の 管理不備 |
|
| 8 | 人的ミス発生の考慮漏れ |
|
別紙4 リスクランクに応じたセキュリティリスクアセッサーによる評価例
別紙5 政府情報システムにおけるクラウドセキュリティ要件策定、審査手順
1． 本手順の概要
本手順は、クラウドサービス選定にあたり調達仕様書に記載すべきセキュリティ要件の策定および当該要件に基づく事業者からのクラウドサービス提案内容を審査するための手順である。
2． 実施ステップ
本手順における実施ステップは下記の通りである。
ステップ①：クラウドサービスが満たすべき要件を策定
ステップ②：①の要件に基づく事業者からのクラウドサービス提案内容の審査
以降、ステップごとに具体的な実施手順を記載する。
ステップ①：クラウドサービスが満たすべき要件を策定
クラウドサービス選定にあたり調達仕様書に記載すべき要件は、以下の通りに分類される。調達仕様書には下記a～cの要件を記載すること。
a. 統一基準群等に基づく委託先に求める要件
b. ISMAP等クラウドサービスリスト登録済みのクラウドサービスに求める要件
c. 個別のセキュリティ要件
以降で各要件の策定方法を記載する。
a. 統一基準群等に基づく委託先に求める要件
「政府機関等のサイバーセキュリティ対策のための統一基準群（令和5年度版）(https://www.nisc.go.jp/policy/group/general/kijun.html)」「4.1.1業務委託(1) (a)(イ)」に規定されている委託先選定基準の内容を踏まえて、調達仕様書に要件を記載すること。（具体的な委託先選定基準は参考資料「統一基準群に規定されている委託先選定基準」を参考にすること）
なお各府省の個別の委託先に求める要件も考慮すること。
b. ISMAP等クラウドサービスリスト登録済みのクラウドサービスに求める要件
ISMAP等クラウドサービスリストに登録済みのクラウドサービスの管理策の適用状況については、登録サービスごとに異なっている。このため、適用必須と考える管理策については、参考資料「クラウドサービスが遵守すべきISMAP管理策基準」及び、ISMAP管理基準（https://www.ismap.go.jp/csm?id=kb_article_view&sysparm_article=KB0010028）第５章管理策基準の内容を踏まえて調達仕様書に要件として記載すること。
なお、登録サービスごとの管理策の適用状況については、ISMAPクラウドサービスリスト「基本言明要件のうち実施している統制目標の管理策」から確認可能。（具体的な確認手順は参考資料「ISMAPポータルサイト内のサービスリストについて」を参考にすること）
c. 個別のセキュリティ要件
上記a,bの要件に加えて、クラウドサービスを使用する業務の特性や取扱う情報の機微性等を考慮し、リスクに見合ったセキュリティ要件を追加検討すること。
なお、機密性3情報をクラウドサービスで取り扱う場合には、ISMAPが前提とする情報の格付（機密性2情報）を踏まえて、必要なセキュリティ要件を追記すること。
表．個別のセキュリティ要件
| 項番 | 要件分類 | セキュリティ要件 | 補足 |
|---|---|---|---|
| 例 | 保存データの暗号アルゴリズム | クラウドサービスで保存するデータの暗号アルゴリズムは、電子政府推奨暗号アルゴリズム（CRYPTREC）を使用可能であること | 統一基準群を考慮した個別のセキュリティ要件 |
| 1 | |||
| 2 |
ステップ②：①の要件に基づく事業者からのクラウドサービス提案内容の審査**
①の要件に基づく事業者からのクラウドサービス提案内容の審査において、下記図の示す通り、ISMAP等クラウドサービスリストに登録されているサービスもしくは登録されていないサービスかで審査方法が異なる。
図．クラウドサービス提案内容の審査の全体概要
事業者からのクラウドサービス提案内容の具体的な審査方法については、下記表に従って実施すること。
表．クラウドサービスの審査方法
| 項番 | クラウドサービスカテゴリ | クラウドサービス審査方法 |
|---|---|---|
| 1 | ISMAP等クラウドサービスリストに登録されているクラウドサービスを審査する | ISMAP等クラウドサービスリストを活用し(参考資料「ISMAPポータルサイト内のサービスリストについて」参照)、ステップ①で策定した要件に対する事業者からのクラウドサービス提案内容の妥当性を確認し、審査する。要件の妥当性の確認観点は下記の通りとする。 [確認観点①]
[確認観点②]
|
| 2 | ISMAP等クラウドサービスリストに登録されていないクラウドサービスを審査する場合 | ステップ①で策定した「a. 統一基準群等に基づく委託先に求める要件」、「b. ISMAP等クラウドサービスリスト登録済みのクラウドサービスに求める要件」、「c. 個別のセキュリティ要件」に対する事業者からのクラウドサービス提案内容の充足性を確認し、審査する。 |
参考資料 ISMAPポータルサイト内のサービスリストについて
【参考資料のURL】
ISMAP等クラウドサービスリストの利用について
https://www.ismap.go.jp/csm?id=kb_article_view&sysparm_article=KB0010265
ISMAPポータルサイト
ISMAPクラウドサービスリスト
https://www.ismap.go.jp/csm?id=cloud_service_list
ISMAP-LIUクラウドサービスリスト
https://www.ismap.go.jp/csm?id=cloud_service_list_liu
参考資料 統一基準群に規定されている委託先選定基準
① 以下の内容を含む情報セキュリティ対策を実施することを委託先の選定基準とし、仕様内容にも含めること。
第4部 外部委託
4.1 業務委託
4.1.1 業務委託
遵守事項
(1) 業務委託に係る運用規程の整備
(a) 統括情報セキュリティ責任者は、業務委託に係る以下の内容を全て含む運用規程を整備すること。
(イ) 委託先の選定基準
【 基本対策事項 】
＜4.1.1(2)(a)(イ)関連＞
4.1.1(2)-1 情報システムセキュリティ責任者又は課室情報セキュリティ責任者は、以下の内容を全て含む情報セキュリティ対策を実施することを委託先の選定条件とし、仕様にも含めること。
a) 委託先に提供する情報の委託先における目的外利用の禁止
b）委託先における情報の適正な取扱いのための情報セキュリティ対策の実施内容及び管理体制
c) 情報セキュリティインシデントへの対処方法
d) 情報セキュリティ対策その他の契約の履行状況の確認方法
e) 情報セキュリティ対策の履行が不十分な場合の対処方法
4.1.1(2)-2 情報システムセキュリティ責任者又は課室情報セキュリティ責任者は、委託する業務において取り扱う情報の格付等を勘案し、以下の内容の全てを必要に応じて仕様に含めること。
a) 監査の受入れ
b) サービス品質の保証
＜4.1.1(2)(a)(ウ)関連＞
4.1.1(2)-4 情報システムセキュリティ責任者又は課室情報セキュリティ責任者は、委託先がその役務内容を一部再委託する場合は、再委託されることにより生ずる脅威に対して情報セキュリティが十分に確保されるよう、基本対策事項4.1.1(2)-1及び2の措置の実施を委託先に担保させるとともに、再委託先の情報セキュリティ対策の実施状況を確認するために必要な情報を機関等に提供し、機関等の承認を受けるよう、仕様に含めること。また、委託判断基準及び委託先の選定基準に従って再委託の承認の可否を判断すること。
4.1.2 情報システムに関する業務委託
遵守事項
(1) 情報システムに関する業務委託における共通的対策
(a) 情報システムセキュリティ責任者は、情報システムに関する業務委託の実施までに、委託先の選定条件に情報システムに機関等の意図せざる変更が加えられないための対策に係る選定条件を加え、仕様を策定すること。
【 基本対策事項 】
＜4.1.2(1)(a)関連＞
4.1.2(1)-1 情報システムセキュリティ責任者は、以下の内容を全て含む情報セキュリティ対策を実施することを情報システムに関する業務委託の委託先の選定条件に加え、仕様にも含めること。
a) 委託先企業若しくはその従業員、再委託先又はその他の者によって、情報システムに機関等の意図せざる変更が加えられないための管理体制
b) 委託先の資本関係・役員等の情報、委託事業の実施場所、委託事業従事者の所属・専門性（情報セキュリティに係る資格（情報処理安全確保支援士等）・研修実績等）・実績及び国籍に関する情報提供