「政府機関等のサイバーセキュリティ対策のための統一基準群(案)」 に対する意見募集の結果概要■ 実施期間：2023年４月17日（月）～５月12日（金）■ 実施方法：NISCのウェブページ及びe-Govに掲載して公募。
併せてオンラインでの説明会を実施（4月28日に実施し、参加者約６０名）■ 意見総数：３４者から計８２件 【内訳：１６企業・団体から４４件、１８個人から３８件】（１）修正を求める意見：全７１件
表現の適正化を求めるもの（５件）、有効と考えられる技術や考慮すべき脅威等に係る意見（１２件）⇒ 該当箇所を改定案に反映
原案どおりとする意見（５４件）⇒ 他の箇所で規定しているなどの理由で改定案に反映させないものについては、パブコメ結果の公表時
理由を付して提示（NISCのウェブページ及びe-Govに掲載）
修正意見の主な内容•

情報の抹消方法に関する意見（５件）•

情報のバックアップに関する意見（５件）•

端末やネットワーク通信の挙動を元に攻撃者の横展開を早期検知する分析プラットフォームやASM(アタックサーフェスマネジメント)、コンテナ環境における対策、脆弱性管理ツールの導入等の最新のセキュリティ対策に関する意見（６件）•

機器に組み込まれるソフトウェアにおけるSBOMやコード署名を活用したサプライチェーン管理に関する意見（２件）（２）その他、統一基準の公表方法、サイバーセキュリティ政策に関する意見等（１１件）⇒ パブコメ結果の公表時に対応を提示（NISCのウェブページ及びe-Govに掲載）
Copyright (c) 2021 National center of Incident readiness and Strategy for Cybersecurity (NISC). All Rights Reserved.

「政府機関等のサイバーセキュリティ対策のための統一基準群」の改定（案）に関する意見募集
の結果一覧
通し
No.

提出者 対象文書

概要

ご意見に対する考え方

統一規範について
1 個人

統一規範 統一規範案第２条第１号にデジタル庁を含 デジタル庁は統一規範案第２条第むべきではないか。

１号の「法律の規定に基づき内閣に置かれる機関」に該当します。
（デジタル庁設置法第二条）

2 個人

統一規範 統一規範案第３条第４項「にて規定した」 ご意見のとおり修正いたします。
は同条第５項のように「に定める」とすべきではないか。

3 個人

統一規範 統一規範案第14条第３項中の法令番号は、 ご意見のとおり修正いたします。
他の箇所と合わせて漢数字とするべき。

4 個人

統一規範 統一規範案第19条第４項で「整備しなけれ ご意見を踏まえ修正いたします。
ばならない。」とあるのは、他の箇所と合わせて「定めなければならない。」又は「定め、実施しなければならない。」等と
すべき。

5 個人

統一規範 統一規範案第21条「（以下「情報システム ご意見を踏まえ、「（以下「情報の運用継続計画」という。）」は以下この システムの運用継続計画」とい文言を用いておらず、不要ではないか。ま う。）」は、「（情報システムのた、同条「整備及び運用」は「整備し、及 運用継続計画）」に修正いたしまび運用」とすべきではないか。

1 ページ

す。

通し
No.

提出者 対象文書

6 個人

概要

ご意見に対する考え方

統一規範 独立行政法人によっては所管元の国の行政機 本規定は独法等が自らのポリシー
関が取っているポリシーよりも先進的でデジ を定める際に所管省庁のポリシー
タル技術を的確に利用できる体制を構築しつ を参考とすることを求めており、
つ効果的効率的であったり、不足する内容を 必ずしもその内容を反映させるこ
補完する内容の規範を先んじて取り入れる場 とを求めているものではなく、自合もあるため、国の行政機関に改善提案を行 組織の特性等を踏まえた独法等のうこともできるようにするほか、セキュリ
独自の対策を阻害するものではあティと利便性は相反する部分もありながら、 りません。
技術の研鑽や理解の促進によって、セキュリ
所管省庁から独法等への一方通行
ティ向上をしつつデジタル化を阻害しないよ
ではなく、独法等から所管省庁へうにするための活動も推奨されるべきであるの改善提案や相互の意見交換なため、この点について盛り込む必要がある。
ど、双方が連携して対応してセまた、セキュリティを向上しつつデジタル化
キュリティ向上に向けて対応するを阻害しないための技術研鑽や理解の促進に必要があるとの御意見と認識しま
ついては、所管省庁によらず、意見交換や勉した。御意見を参考にして、引き強会を実施することで相互に向上していくこ
続き検討して参ります。
とがセキュリティの向上に資すると考えるた
め、個別の対策基準についても、国の行政機
関やその独立行政法人等各省庁の壁を越えて研鑽し常に目まぐるしく変化していくセキュ
リティの脅威について適切に対応していくことが必要になってくるため、統一規範への盛り込みについて検討いただきたい。

7 個人

統一規範 管理体制を明記していただいたことは適切 統一基準において、遵守事項な対応で重要な点だと思います。さらに、 2.2.3(2)で情報セキュリティ推進体
CISO及び委員会等の設置を明確にした点も 制やCSIRTに属する職員、CYMAT
非常に賛同いたします。しかし、不足する に属する職員への教育について規点として、CISO、委員会、CISOから職務定しております。また、最高情報を担わせるものの能力、教育にふれる必要 セキュリティアドバーザーについがあるかと思います。まずは、体制を構成 ては、「情報処理安全確保支援
するのが開始点ですが、知識、能力がない 士」を例示して、情報セキュリ
ものだけで構成してもしかたない。あくま ティに関する資格や専門的な知識
で必要な知識、能力があるものを任命して 及び経験を有した者である必要がかつ、不足する知識、能力に対しては教育 あることを規定しております。
を提供すべきことを明記すべき。特に本邦では情報処理安全確保支援士なる資格があるので、この資格者を任命するとか、機関等でそれの資格を目指す等の動機付けを行えるようにすべきではないかと思います。
2 ページ

通し
No.

提出者 対象文書

8 個人

概要

統一規範 第9条に教育を、第10条においてインシデ

ご意見に対する考え方
対処手順の整備や訓練等の情報セントへの対応を定めている。しかし、イン キュリティインシデントに備えた
シデントの対応を発生時に適切に実施する 事前準備については、統一基準のためには、通常時の訓練等が必要になる。 遵守事項2.2.4(1)に規定しておりまこのため、第9条を教育だけでなく、教育、 す。
訓練として、第10条ではインシデント対応のための平常時の準備等の対応も追記しておくべきではないかと思います。
9 個人

統一規範 第14条4項「指定法人を所管する国の行政

当該記載は個別の根拠法において機関は、当該指定法人に対して、個別の根 定める「業務の実績等に関する評
拠法に基づき、情報セキュリティ対策の実 価」に基づき、これに情報セキュ
施状況に関して評価を行う。」と記載され リティ対策の実施状況に関して評ている。しかし、個別の根拠法が最新のサ 価を行うことを規定しているもの
イバーセキュリティ、情報セキュリティ等 であり、個別の根拠法自体に最新の動向をキャッチアップされていない可能 のサイバーセキュリティ等の動向性もある。個別の根拠法に従うことは重要 を踏まえた対策等を定めているもではあるが、ここでは「個別の根拠法に基 のではありません。
づき」を削除したほうのがより適切にセキュリティ対策が実施される可能性が高くなるのではないかと思います。
10 個人

統一規範 外部委託において、要機密情報などセキュ 統一規範においては機密性を重視
リティの三要素の機密性のみに注目した記 した規定となっておりますが、統載になっているが、機関等の情報機器、情 一基準及びガイドラインにおいて報システムを使ったサービスは、停止する は、可用性や完全性も考慮した規ことにより国民に多くの影響を与える可能 定を設けているところです。例え性もある。機密性のみを注視するのではな ば、利用するクラウドサービスにく可用性も十分考慮した要件にすべきでおける可用性を考慮した設計を行す。注目すべきものも「情報」だけでなうこと（基本対策事項4.2.2(1)-4）

く、情報システムに関しても見ていくべき や十分な可用性を担保した復旧にかと思います。要機密情報を扱っていない 係る手順の整備（基本対策事項としても、その情報システムが停止するこ 4.2.2(3)-3）、適切なバックアップとにより多くの国民に迷惑をかけるような の取得（基本対策事項5.2.3(1)-7）
ものに関しての考えが不足しているように などを規定しているところです。
思えます。特に「サイバーセキュリティ」との言葉を文書として使っているのでなお
さら、従前の情報セキュリティだけではない考えが必要になると思われます。

3 ページ

通し
No.

提出者 対象文書

11 個人

概要

ご意見に対する考え方

統一規範 クラウドを利用するときの見過ごしされや 御意見のVPN機器については、遵
すいリスクとして、クラウドに接続するた 守事項6.4.2(2)及び基本対策事項
めのVPN機器の脆弱性が放置されやすい。 6.4.2(2)-1において、通信回線装置
クラウド及びクラウドへのネットワークに が動作するために必要なソフト
関してはクラウド事業者等の選定が間違え ウェアの定期的な脆弱性の確認やなければ適切に実施される可能性が高い。 不適切な状態の改善などの対策をしかし、機関等の出口に設定されるであろ 実施することを規定しておりまうVPN機器に関しては、クラウド事業者が す。
面倒を見ないで機関等が直接調達する場合も多いのではないかと思われます。そのときに、運用中に発生する脆弱性のパッチ等が実施されない可能性が非常に高い。そのような事故が多い。この部分を強化した記載を追記すべきではないかと思います。

統一基準・ガイドライン「1.2 情報の格付の区分・取り扱い制限」について
12 個人

統一基準 情報に関して機密性の格付を行うことは適 今般の改定案において、情報シス切と考えるが、特に可用性の格付を行うこ テムの重要度に応じた情報セキュとに違和感がある。

リティ対策が講じられるよう、情報に関しては機密性で格付けをして、情 「情報システムの分類基準」の考報システムに関しては機密性・完全性・可 え方を導入いたしました。この考用性のそれぞれに関して格付けを行うべ

え方には、情報システムの機密き。

性・完全性・可用性の観点も含めております。
いただいたご意見は今後の検討の参考とさせていただきます。

統一基準・ガイドライン「1.3 （統一基準における）用語定義」について
13 個人

統一基準 「業務委託」の定義において「ただし、当 御意見の箇所のただし書きは、守該業務において機関等の情報を取り扱わせ るべき情報がない業務委託（例える場合に限る。」と記載されている。しか ば「庁舎の清掃業務委託」など）
し、本記載によって対象が必要以上に狭く を除外するための記載です。
捉えられる可能性が非常に高い。例えば、クラウド事業者においても、事業者自体が情報にアクセスできない場合は対象外となってしまうおそれがある。同様に情報を扱わない契約の機器の保守も対象外になってしまう。本「ただし」書きは削除すべきではないか。

4 ページ

通し
No.

提出者 対象文書

14 個人

概要

統一基準 「クラウドサービス」の用語定義においご意見に対する考え方
クラウドサービスの用語定義におて、一般の者が一般向けに使うものだけに いては、一般の者が一般向けに範囲を狭めており、誤解やミスリードをし 「使う」ものだけに範囲を狭めててしまう可能性が高い。

いるものではございません。
「機関等外の一般の者が一般向けに情報システムの一部又は全部の機能を『提供する』クラウドサー
ビス」を機関等が利用等することで、「当該サービスにおいて機関等の情報が取り扱われる場合」、
統一基準におけるクラウドサービ
スに該当いたします。

統一基準・ガイドライン「2.1.3 情報セキュリティ関係規程の整備」について
15 個人

統一基準 「統一基準に準拠した対策基準を定めるこ ご意見を踏まえ修正いたします。
と」と記載されているが、統一規範(案)の第6条第3項では、「対策基準は、統一基準と同等以上の情報セキュリティ対策が可能となるように定めなければならない。」となっており、「準拠した」という表現だと、通常、同等レベルと認識される可能性が高いのではないか。

統一基準・ガイドライン「3.1.1 情報の取扱い」について
16 個人

ガイドラ 情報の抹消方法は解説に記載されている
イン

ご意見を踏まえ、機関等においてが、実態として把握されていないことが多 適切な抹消方法が用いられるよ
いと考えるため、遵守事項に記載すべき。 う、機関等への周知に努めて参り
ます。

5 ページ

通し
No.

提出者 対象文書

17 個人

概要

ガイドラ 表 3.1.1-1 情報の抹消方法の例
イン

ご意見に対する考え方
フラッ「（解説）遵守事項3.1.1(7)(b)

シュメモリ媒体の注意点に、「…、データ 「抹消する」について」に記載の抹消ソフトウェアによる上書きを１回実施 とおり、「表3.1.1-1 情報の抹消
した場合は実際にはデータの書き込みが行 方法の例」は、特殊な手段を用いわれず、消去すべき情報がそのまま残って ることによって情報（断片を含しまう現象が発生する可能性があるが、２ む）が読み出されるリスクが存在
回以上の上書きとすることにより、当該情 する抹消方法の例示です。
報は抹消される。」と記載があるが、なお、当該リスクを許容できない「…、完全なる乱数＋２回以上の上書きと ような機密性の高い情報の抹消方することにより、当該情報は抹消され

法は、NIST SP800-88 Rev.1のる。」または「…、完全なる乱数＋２回以 Purge及びDestroyランクを参考に上の上書き、またはNIST SP800-88 Rev.1

作成した、「表3.1.1-2 機密性ののPurgeレベルの抹消処理を実行すること高い情報の抹消方法の例」に例示

により、当該情報は抹消される。」という しております。
記載に変更すべき。
18 個人

統一基準 「データ抹消処理結果の検証」と「データ 「（解説）遵守事項3.1.1(7)(b)
抹消結果の保存・記録」を遵守事項に加え 「抹消する」について」においるべき。

て、「業務委託を実施する場合
は、情報が適正に抹消されたことの証拠となる記録及び証明書の提出を求める（略）ことが重要である。」と記載しております。また、ご意見頂きました「データ抹消処理結果の検証」は「情報が適正に抹消されたことの証拠となる記録及び証明書」に含まれると考えておりますが、いただいたご意
見は今後の検討の参考とさせていただきます。

6 ページ

通し
No.

提出者 対象文書

概要

ご意見に対する考え方

19 企業・ ガイドラ 「バックアップ取得元の情報システムが接 御意見を踏まえ解説に追記いたし団体

イン

続するネットワークから論理的に隔離 され ます。
た保管場所」と記載があるが、アクセス制
御やネットワークセグメント分離をしても、認証情報を採取されたりセグメント分離しているネットワークスイッチ等にマルウェアが侵入し最終的に攻撃されるリスクが残るので、「物理的な隔離」を基本的な対策とし、これををどうしても満たせない
場合において「論理的な隔離」とするという優先度付けをすべきである。現状、「論理的な隔離」を講じていても被害が出ている事例がある。

20 企業・ ガイドラ 復旧用データの保持期間を具体的に参考値 今後の検討の参考とさせていただ
団体

インとして明確化をすべき。（例.バックアップ きます。
データは最低2週間保持、1ヶ月保持）

21 企業・ ガイドラ バックアップデータを攻撃から守る手段と 今後の検討の参考とさせていただ
団体

イン

して、

きます。

・セキュリティ対策として、バックアップ
データはCIFS／NFSプロトコルで簡易的にアクセスできない仕組みを実装していること。
・セキュリティ対策として、バックアップ
システムはwindowsやLinux等汎用OSではなく、独自OS採用が望ましいを追記すべき。
22 企業・ ガイドラ セキュリティ被害を受けた後の出口対策と 御意見を踏まえ解説に追記いたし団体

イン

して、保管しているバックアップデータに ます。
対する分析検証（検疫）機能を明記すべき。バックアップ時にウイルスチェックを実施することに加え、保管しているバック
アップデータに対してもウイルスに侵されていない復旧に用いるべき正しいデータは何か？のチェック機構は必要と考える。

23 企業・ ガイドラ バックアップ実データに対する整合性を保 今後の検討の参考とさせていただ
団体

イン

持する機能を追加すべき。
7 ページ

きます。

通し
No.

提出者 対象文書

24 個人

概要

ご意見に対する考え方

ガイドラ 廃棄する媒体を外部の民間事業者等へ業務 （解説）「遵守事項3.1.1(7)(b)イン

委託において、廃棄端末を委託先（庁外） 「抹消する」について」においで実施する場合、その移動時や委託先での て、情報の抹消を業務委託する場
情報漏洩のリスクを考慮する必要があるた 合は、職員等による立ち合いを行め、消去場所自組織（庁内）でまず復元で う等、委託先での履行状況を確認
きないかたちでの消去を実施することを前 することを記載しております。ま提とすべき。

た、運搬を第三者へ依頼する場合はセキュアな運送サービスを提供する運送事業者により運搬することを、基本対策事項3.1.1(6)-1において規定しております。

25 個人

ガイドラ 情報が適正に抹消されたことの証拠となる （解説）「遵守事項3.1.1(7)(b)イン

記録及び証明書は、改ざんされないような 「抹消する」について」におい
証跡の管理をすべき。

て、情報の抹消を業務委託する場
合は、職員等による立ち合いを行う等、委託先での履行状況を確認することを記載しております。

26 企業・ ガイドラ 暗号化された圧縮形式のファイルの送受信 ご意見を踏まえ、職員等が不審な団体

インについては、PPAPを利用した場合に、ウィ 電子メールを受信することによる
ルスチェックをされないまま受信される可 被害をシステム的に抑止する機能能性があり受信者側で解凍・復号した際に の導入に係る対策が規定されていウィルス感染するリスクがあることを記載 る、「（解説）「基本対策事項していただきたい。

8.1.1(2)-2 d)「実行プログラム形式のファイルを削除等する」について」に追記いたします。

27 企業・ ガイドラ 運搬する情報を暗号化するにあたり、パス 御意見ありがとうございます。引団体

イン

ワードやパスフレーズでの暗号化について き続き検討して参ります。
記載されていますが、よりセキュリティ強度が高いのはDRM、IRMのようにデータと鍵情報が分離され、サーバ側で主体認証を受ける必要のある暗号化手法です。さらに
パスワードは利用者がファイルの暗号化・復号を意識する必要があり、運用を避けようとする職員もいることから、より利便性の高い暗号化手法を提示することも必要と考えます。

統一基準・ガイドライン「4.1.1 業務委託」について

8 ページ

通し
No.

提出者 対象文書

28 個人

概要

ご意見に対する考え方

統一基準 業務委託の発注機関は、業務委託に伴う入 委託先への要求事項については、
札・公告時において、情報セキュリティの 基本対策事項4.1.1(3)-1に８項目を確保について漠然とした制約を課している 規定し、それらを契約に含めるこことが実情である。各省庁で具体的に定め とを求めております。また、これているであろう情報管理対策基準群は非公 らの８項目について、その具体的開であり、実際の対応状況はブラックボッ な対策をそれぞれの解説に例示す
クス状態である。本統一基準案は、あくま るとともに、NIST SP800-171の管で「政府機関内」向けの内容であり、民間 理策群を参考にすることを示して企業が実質的に参考としなければならない おります。ご意見を踏まえ、本趣内容について、別途整理しなければ外部委 旨が適正に仕様書に反映されるよ
託者のセキュリティを担保できないのでは う、機関等への周知に努めて参り
ないか。

ます。

例えば、防衛装備庁が発表している「装備品等及び役務の調達における情報セキュ
リティ基準」のような具体的内容を、内閣
官房内閣サイバーセキュリティセンターとして各省庁へ同時に発信すべきと考える。
29 企業・ 統一基準 業務委託先の選定には、経済安全保障に基 御意見ありがとうございます。今団体

づくセキュリティクリアランスの観点も考 後の検討の参考とさせていただき慮すべきだと考えます。

ます。

30 企業・ ガイドラ 委託先に対して技術的な措置の実施と、そ 情報を委託先に提供する場合に必団体

イン

れを実施させるための方法（NDA等）が記 要な対策については、遵守事項
載されていますが、情報漏洩対策として委 3.1.1(5)及び(6)に定めているとこ
託元が実施可能な技術的措置についての記 ろです。
載がないように見える。
目的外利用を禁止するために、委託元機関が提供するデータに対して事前に暗号化、アクセス制御等の技術的措置を施してから提供することで漏洩を防ぐことも考えられるなど、委託元機関による提供データへの技術的な措置についての記載の追加を希望する。

31 企業・ ガイドラ 委託業務に伴う情報を取り扱う従業員等の 御意見ありがとうございます。今団体

イン

資格条件の明確化について、資格条件の具 後の検討の参考とさせていただき
体例を例示していただくことは可能でしょ ます。
うか。

統一基準・ガイドライン「4.1.2 情報システムに関する業務委託」について
9 ページ

通し
No.

提出者 対象文書

概要

ご意見に対する考え方

32 企業・ ガイドラ 「業務委託サービス」に該当する例につい 「クラウドサービス」の定義の中に団体

インては理解できたが、「クラウドサービス」 「利用者によって自由にリソースのと「業務委託サービス」の線引きについて 設定・管理が可能なサービスであっ判断に迷う局面があることが考えられるた て、情報セキュリティに関する十分
め、より具体的な定義について記載願いた な条件設定の余地があるもの」という記載がありますが、「業務委託
い。
サービス」との線引きのポイントの一つとして、「情報セキュリティに関する十分な条件設定の余地がある」が考えられます。「クラウドサービス」は、情報セキュリティに関する十分な条件設定の余地がある
ため、当該サービス利用者が情報セ
キュリティ設定を実施することによって情報セキュリティを確保することを求めております。一方、「業務委託サービス」は、当該サービス
利用者が情報セキュリティ対策を実施することに加え、主に、業務委託
契約により、委託先がセキュリティ対策を講じることによって、情報セ
キュリティを確保することを求めています。

33 企業・ ガイドラ 業務委託サービスは、クラウドサービス以 御意見で示されている団体

イン外であることからISO27017ではなく、「ISO27001」も考えられますが、

ISO27001を取得していることを要件とすれ 取り扱う情報の格付や取扱制限等ば、問題ないでしょうかに応じてセキュリティ要件を策定することを求めているため、これに限定するものではありません。

統一基準・ガイドライン「4.2.1 クラウドサービスの選定（要機密情報を取り扱う場合）」について
34 企業・ 統一基準 データが海外のクラウドサービスに格納さ ご意見を踏まえ、解説に追記いた団体れる場合も、国内の準拠法を適用するため します。にも、日本国内で運用される認証局による鍵管理が必要だと考える。

10 ページ

通しNo.

提出者 対象文書

概要

ご意見に対する考え方

35 企業・ ガイドラ 機関等の調達を伴わない場合であっても、 機関等の調達を伴わない場合でも団体

イン

クラウドサービスを選定する際は、4.2.1(2) 遵守事項4.2.1(2)の「原則としての条項に従う必要があるという記載がある ISMAP等クラウドサービスリスト
ことから、「原則としてISMAP等クラウド からクラウドサービスを選定す
サービスリストからクラウドサービスを選 る」等が求められますが、これは定する」必要があるという認識で合ってい 機関等がクラウドサービスを利用るか。例えば、委託先がすでに契約してい する場合に情報システムセキュリ
るクラウドサービスを利用する場合、その ティ責任者又は課室情報セキュリ
クラウドサービスISMAP等クラウドサービ ティ責任者に求めているものであ
スリストに掲載されているサービスである り、委託先が利用するクラウド必要があるという理解で間違いないか。

サービスについて必ずしも求めて

委託事業者においても、ISMAP等クラウ いるものではありません。しかし
ドサービスリスト掲載サービスの利用を求 ながら、4.1.1「業務委託」の目
めるのは、難しいと考えております。本項 的・趣旨において、業務委託で取の記載の見直しについて、ご検討をお願い り扱う情報の格付、委託する業務致します。

や利用するクラウドサービスの特性等に応じて、委託先への要求事
項に含める必要があるとしている
ところです。

統一基準・ガイドライン「4.2.2 クラウドサービスの利用（要機密情報を取り扱う場合）」について

11 ページ

通しNo.

提出者 対象文書

36 個人

概要

ご意見に対する考え方

ガイドラ 「政府情報システムにおけるクラウドサービス

御意見ありがとうございます。今の適切な利用に係る基本方針」では、政府情報後の検討の参考とさせていただきシステムについて、単にクラウドを利用するの

ます。

イン

ではなく、クラウドを適切（スマート）に利用するための考え方等が示されています。セキュ
リティについては、オンプレミスとクラウドで考え方や方 針レベルで大きく異なる点として、「サーバを構築しないアーキテクチャの採用」
が挙げられていま す。
コンテナは、サーバを構築しないアーキテク
チャにおける主要な技術の一つであり、クラウ
ドをスマートに利用するための、重要な選択肢の一つでもあると認識しています。ただし、やはりコンテナ環境におけるリスクや対策は従来とは大きく異なり、「NIST SP 800-190 ア 18
プリケーションコンテナセキュリティガイド」
や 「OWASP Docker Top 10」 等でその詳細が示されています。
上述の理由より、仮想マシンに加えて、コンテ
ナ環境に対しても、適切なセキュリティ対策が必要で あることを示しておくことが望ましいと考えるため、コンテナ環境に対する適切なセ
キュリティ対策についても、追加で示してはいかがでしょうか。

統一基準・ガイドライン「4.3.1 機器等の調達」について
37 企業・ 統一基準 調達には、情報システムの構成部品の安全 機器等の調達に当たっては、基本
団体

性確認や真正性担保のために、IEC62443や 対策事項4.3.1(1)-1において、「ITSP800シリーズなどの国際安全基準の機器調達に係る国等の物品等又は役務レベルに求められるサイバーセキュリティ の調達方針及び調達手続きに関す対策に加えて、機器に組み込まれるソフト る申合せ」に基づき、サプライ
ウェアについてもSBOMやコード署名を活チェーン・リスクの観点から必要用した継続的なサプライチェーン管理が求 な場合にデジタル庁及びNISCに対められると考えます。

して、講ずべき必要な措置について助言を求めることを規定しています。また、解説においてSBOMを参考にすることを例示として示しています。コード署名については、今後の検討の参考とさせていただきます。

12 ページ

通しNo.

提出者 対象文書

概要

ご意見に対する考え方

38 企業・ 統一基準 スパイチップや不正プログラムなどの混入 機器等の調達に当たっては、基本団体を防ぐためにも、製造メーカーや製造国、 対策事項4.3.1(1)-1において、「IT製造ロットなど出自がはっきりした機器を 調達に係る国等の物品等又は役務導入することを考慮すべきだと思われまの調達方針及び調達手続きに関すす。また多くのIoT機器でオープンソースが る申合せ」に基づき、サプライ利用されていることを考慮すると、組み込 チェーン・リスクの観点から必要
まれるソフトウェアに関しても、サプライ な場合にデジタル庁及びNISCに対チェーン管理が重要であり、コード署名や して、講ずべき必要な措置につい
SBOMの活用が必要になってくると考えまて助言を求めることを規定していす。

ます。また、解説においてSBOMを参考にすることを例示として示しています。コード署名については、今後の検討の参考とさせていただきます。

39 個人

ガイドラ サイバー空間における安全保障の観点から 機器等の調達に当たっては、基本
イン

必要な対策と考えています。また、我が国 対策事項4.3.1(1)-1において、「ITの同盟国である米国では同様の調達法令が 調達に係る国等の物品等又は役務
定められており、国家レベルの脅威が発現 の調達方針及び調達手続きに関すした際、原案では、当該調達ポリシーレベ る申合せ」に基づき、サプライ
ルの違いを理由に同盟国からの支援が限定 チェーン・リスクの観点から必要されるのではないかと懸念しております。 な場合にデジタル庁及びNISCに対
そのため、防衛省が防衛白書などで言及し して、講ずべき必要な措置についている脅威国製の製品を調達しない基準を て助言を求めることを規定してい採用していただきたい。

ます。

もしくは、脅威国製の製品の場合、防衛省など国家安全保障を担う機関による検査で安全とされたもののみを調達するような基準としていただきたい。ここでの「脅威国製」の定義は、当該脅威国で製造もしくは保守を行っているものとします。
統一基準・ガイドライン「5.1.1 情報システムの分類基準等の整備」について

13 ページ

通しNo.

提出者 対象文書

概要

40 企業・ ガイドラ 今回の「情報システムの分類基準」と、団体

インご意見に対する考え方
統一基準における「情報システム「情報システムに係る政府調達におけるセ の分類基準」と、「情報システム
キュリティ要件策定マニュアル」（SBDマ に係る政府調達におけるセキュリニュアル）は、どのように平仄を取って運 ティ要件策定マニュアル」（以下用していくべきか。

「SBDマニュアル」という。）における「実施レベル」の関連性について、統一基準において特段の定めはございません。「SBDマニュアル」の1.5「活用範囲」の「本マニュアルの活用範囲（対象として想定している情報システムの範囲）は、基幹LANシステムや共通基盤システムなど総合的かつ緻密なリスク分析を要する情報シ
ステムを除く、（略）中小規模の情報システムの調達に対して特に有効」の記載を踏まえ、情報シス
テムのセキュリティ要件を策定する必要があります。「情報システ
ムの分類基準」と「SBDマニュアル」の関係性については今後検討
して参ります。

41 企業・ ガイドラ 表 5.1.1-1 情報システムの分類基準（例）団体

イン「運用経費が極めて大きい場合」

において、重要度「高」の判断基準として が、必ずしも「重要度「高」とし「運用経費が極めて大きい場合」があるて判断される情報システムに該当が、「情報セキュリティインシデント等が するとは限らないところですが、発生した際に業務遂行に影響を及ぼすな指標の一つとしては考えられるとど、社会的・経済的な混乱を招くおそれが 判断しております。
ある高度な情報セキュリティ対策が要求される情報システムを判別するための基準」の例示として必ずしも適切ではない。
統一基準・ガイドライン「5.2.3 情報システムの運用・保守」について

14 ページ

通しNo.

提出者 対象文書

概要

ご意見に対する考え方

42 企業・ 統一基準 既知の脆弱性の対策と未知の脆弱性の早期 脆弱性のスキャン・可視化に有効団体

発見の為の定期的かつ継続的な運用サイク と考えられる自動でソフトウェア
ルとするため、情報システムのスキャン、 の種類やバージョン等を管理する
脆弱性の可視化、対応を自動化するための 機能や、自動でソフトウェアを更脆弱性管理ツールの導入が望ましい。

新する機能を有する、「IT資産管理ソフトウェア」の導入を例示した規定がございます。

統一基準・ガイドライン「5.2.4 情報システムの更改・廃棄」について
43 個人

ガイドラ 情報の抹消方法は解説に記載されている
イン

ご意見を踏まえ、機関等においてが、実態として把握されていないことが多 適切な抹消方法が用いられるよ
い。そのため、情報の抹消方法は解説では う、機関等への周知に努めて参りなく遵守事項に記載すべき。

ます。

44 企業・ 統一基準 廃棄の際には、復元できない形での確実な 情報の抹消方法や抹消に係る留意団体

情報の抹消に加えて、データ消去証明の取 点は、「（解説）遵守事項
得が望ましいと考えます。

3.1.1(7)(b)「抹消する」について」に記載しており、当該解説において、「業務委託を実施する場
合は、情報が適正に抹消されたことの証拠となる記録及び証明書の提出を求める（略）ことが重要である。」と記載しております。

統一基準・ガイドライン「5.3.1 情報システムの運用継続計画の整備・整合的運用の確保」について
45 個人

ガイドラ 危機的事象発生に備え訓練を実施するのイン

遵守事項5.3.1(1)(b)に記載のとおは、運用継続計画の範疇であり、サイバー り、「情報セキュリティに係る」
セキュリティの範囲を逸脱していると考え 対策事項、運用規程、実施手順がます。

運用可能であるかを確認するため

令和3年度版の解説に記載の通り「情報シス の訓練となります。
テムの運用継続計画の教育訓練を行う際
は、対策事項の有効性の確認も目的とすることが望ましい。」にとどめてはいかがでしょうか。
統一基準・ガイドライン「6.2.1 サーバ装置」について

15 ページ

通しNo.

提出者 対象文書

概要

ご意見に対する考え方

46 企業・ ガイドラ サーバ装置の「適切なセキュリティ対策を ご意見を踏まえ、修正いたしま
団体

イン実施する」の解説において、本質的なこと す。
が記載されておらず、例としてあげられているものも端末への対策例となっている。
サーバ側での対策と端末側での対策がそのまま一致しているとは限らないため、情報システムという枠組みで第7部を参照させる
か、本項目内に主体認証、アクセス制御な
どの主要な対策だけでも記載する方がよいと考える。

統一基準・ガイドライン「6.2.2 電子メール」について
47 企業・ ガイドラ DMARCに関する具体的な設定やスケ団体

イン

ご意見を踏まえ、修正いたしま

ジュール感を明示されたことで、実効的な す。
対策が速やかに進むのではないかと期待する。さらにBIMIについても一言追加して記載することを検討いただきたい。

48 企業・ ガイドラ 基本対策事項6.2.2(1)-2を以下のように修正す 基本対策事項6.2.2(1)-2では、機関
団体

イン

べき。

等が受信した電子メールに送信ド「DMARCによる受信側の対策を行う。

メイン認証技術が用いられていな

DMARCによる受信側の対策を行うためにい場合、機関等に当該電子メール

は、SPF、DKIMの両方による対策を行う必の受信を拒否することを必ずしも要がある。なお、送信ドメイン認証技術によ 求めてはおりません。
る電子メールのなりすましの防止策が適用で また、送信ドメイン技術に頼らなきない場合、送信ドメイン認証技術に頼らな いなりすまし（Impersonation）対
いなりすまし防止策を行う必要がある。」
策については検討して参ります。
当該意見による修正に合わせ（解説）として以下を追加することを提案する。
「公平性が高い事業を営む上で普く電子メー
ルを受信する目的で送信ドメイン認証技術を利用できない場合やビジネス電子メール詐欺の脅威がある場合、送信ドメイン技術に頼らないなりすまし対策を代替もしくは併用として検討するべきである。」
補足: 原案のなりすまし対策はなりすまし（Spooﬁng）攻撃に対抗するものだが、なりすまし（Impersonation）攻撃の対抗を代替・併用対策として意見する。

16 ページ

通しNo.

提出者 対象文書

概要

ご意見に対する考え方

統一基準・ガイドライン「6.2.3 ウェブ」について
49 個人

ガイドラ sslサーバ証明書の有効期限についての記載 サーバ証明書の有効期限について
インが必要である。

は、「TLS暗号設定ガイドライン」に記載があり、当該ガイドラインに従うことが基本対策事項
6.2.3(1)-5に規定されております。

50 個人

ガイドラ ウェブサーバの導入・運用時の対策の項目 ご意見を踏まえ、追記いたしまインに、アクセス集中対策ならびにDDoS対す。

策、オリジンサーバの隠匿をすることでサーバに直接不正ログインをされてサイト改ざんをされてしまうリスクを低減させる
ためや、クラウドサービスによるWAFによる攻撃への対策といった用途に、コンテン
ツデリバリーネットワーク（CDN）を用いた負荷分散並びにセキュリティ対策を図る
ことについて追加記載したほうが良い。
統一基準・ガイドライン「6.2.4 ドメインネームシステム（DNS）」について
51 個人

ガイドラ DNSSECにも踏み込むべきである。

今回の改定案では、現行の統一基

イン

準群の基本対策事項において、
DNSキャッシュポイズニング対策の例示としてDNSSECの利用を規定しておりましたが、本改定案ではこれに加え、DNSSECを利用する場合のDNSSECトラストアン
カーを最新の状態に保つための対策を規定しようとしているところです。DNSSECに係る対策については引き続き検討して参ります。

統一基準・ガイドライン「6.4.1 通信回線」について

17 ページ

通しNo.

提出者 対象文書

概要

ご意見に対する考え方

52 企業・ ガイドラ 未知の不正プログラムに対する判断や外部 御意見ありがとうございます。御団体

インからの不正アクセスによる被害への対策と 指摘の内容については今後の普及
して、サンドボックス型の対策を検討する 状況等を踏まえて検討してまいりとよい、との記載について、現在では不正 ます。
プログラムの検知回避や、処理遅延の大きさが問題になっている側面もある。そのため、サンドボックス型の対策の他、シグニチャ方式によらず、未知の不正プログラムを即時検出が可能なファイルセキュリティ
技術もあります為、検知、処理速度、コストの観点から、今回の改訂に際し併せて検討項目として記載されると良いと考えます。

統一基準・ガイドライン「6.4.3 無線LAN」について
53 個人

統一基準 単に秘匿性を確保だけではWEPなどを使う 無線LANの暗号化方式につきまし可能性があるため、方式を限定すべきであ ては、解説において、WPA3る。また、必要以上の電波伝搬を阻止する EnterpriseやWPA2 Enterpriseが考観点から出力の強さを制限しても良い。

えられること、また、WEPやTKIP
は利用してはならないことを記載しているところでございます。
無線LANの出力強度につきましては、3.2.1「情報を取り扱う区域」に関連する記載をしているところ
でございます。いただいたご意見は今後の検討の参考とさせていただきます。

統一基準・ガイドライン「6.4.4 IPv6通信回線」について
54 企業・ 統一基準 対象に、IPv6 Ready Logo Program
団体

御意見ありがとうございます。御(Phase-2) 準拠製品だけでなく、USGv6 準 指摘については今後の検討の参考
拠製品を含めて頂きたい。USGv6 は米国国 とさせていただきます。
立標準技術研究所 (NIST) が米政府機関向けに提供している IPv6 機能や相互運用性に関する認証となり、テスト仕様は IPv6
Ready Log Program と同様のものが広範に渡り使用されています。認証の実効性はIPv6 Ready Log Program 相当のものと考えられ、また類似の複数の認証を取得することは製品ベンダにとっては大きな負担となる。
18 ページ

通しNo.

提出者 対象文書

概要

ご意見に対する考え方

統一基準・ガイドライン「7.1.1 主体認証機能」について
55 企業・ 統一基準 厳格な機器特定による認証の為には、安全 御意見ありがとうございます。御団体

な鍵管理による真正性の担保と識別の仕組 指摘については今後の検討の参考みが必要だと考えます。

とさせていただきます。

また第三者認証機関による本人認証の仕組みも必要となると思われます。
56 企業・ ガイドラ 「（パスワードの）定期的な変更が真に必 基本対策事項7.1.1(1)-5において、団体

イン

要である場合に限り適用すべき」という内 利用者に主体認証情報の定期的な容を遵守事項に追加してはいかがでしょう 変更を求める「場合」と記載してか。定期的に変更を促すことが必須要件と おり、利用者に主体認証情報の定とらえられていることが多く、上記の記載 期的な変更を求めることが必須要が必要と考えます。

件と捉えられることはないものと認識しておりますが、ご意見を踏
まえ、本趣旨が機関等に伝わるよう、機関等への周知に努めて参ります。

統一基準・ガイドライン「7.1.2 アクセス制御機能」について
57 企業・ ガイドラ ゼロトラストの観点から侵害された場合等 御意見ありがとうございます。御団体

インを考慮し、情報の漏洩を防止するための施 指摘については今後の検討の参考策が必要であるため、追加セキュリティ対 とさせていただきます。
策として以下を追加すべきと考える。
・情報に対して行える操作（閲覧、複製、印刷、メール送信等）を限定するアクセス制御

統一基準・ガイドライン「7.1.4 ログの取得・管理」について
58 企業・ 統一基準 不正侵入、不正操作等の有無について定期 御意見を踏まえ、解説において団体的にログを点検又は分析とありますが、こ NDRの導入を例示として追加いたれに認証サーバやネットワーク機器のログ します。
からネットワークへの侵入をいち早く検知し、対処を行うための仕組みの利用を追記頂きたい。

統一基準・ガイドライン「7.2.1 ソフトウェアに関する脆弱性対策」について

19 ページ

通しNo.

提出者 対象文書

概要

ご意見に対する考え方

59 企業・ ガイドラ 追加セキュリティ対策について「また、脆 オフラインのサーバに対してもペ団体

イン

弱性診断の実施に当たっては、インター

ネトレーションテスト等の高度なネットから攻撃を受ける可能性のあるサー 脆弱性診断を実施することを想定
バ装置、（略）に対してはペネトレーショ しております。これはインターンテスト、TLPT（脅威ベースのペネトレー ネット接続系と物理分離された基
ションテスト）等の高度な脆弱性診断の実 幹ネットワークへの保守用端末や施を検討すること。」に修正してはいかが リモートアクセス端末を起点としでしょうか。現状の記載はオフラインのた内部不正を想定したペネトレー

サーバに対してもペネトレーションテスト ションテスト等を想定しておりま等の実施が必要とも読み取れます。

す。

60 企業・ ガイドラ ソフトウェアに関する脆弱性対策について 「改善を行うまでの間は監視を強団体

イン

は、脆弱性情報の公開から対応までに時間 化すること」については、基本対を要した場合や、不適切な状態が長く続い 策事項7.2.1(1)-9 c)の解説においてた場合には、改善の措置を講じる前に侵害 記載しております。「改善を行うを受ける可能性についても考慮する必要が と同時に遡って調査（アクセスロあると思われます。

グ等）を行うことが望ましい」旨改善を行うまでの間は監視を強化すること については、「脆弱性が公開されや、改善を行うと同時に遡って調査（アク た際にリスク評価を行い、遡ってセスログ等）を行うことが望ましい旨を追 調査（アクセスログ等）した結
記してはいかがでしょうか。

果、必要と判断した場合に実施が必要になる」が正しい対応であると考えていますが、同趣旨は「5.2.3(1)情報システムの運用・保守」や「7.1.4(1)ログの取得・管理」の遵守事項、基本対策事項又は解説において記載されております。

20 ページ

通しNo.

提出者 対象文書

概要

ご意見に対する考え方

61 企業・ 統一基準 システム停止が必要となる脆弱性対策対策 セキュリティパッチ等の適用が難団体において、脆弱性対策計画を策定したもの しい場合の暫定措置（WAFによるの再起動が実施できる日が決まっており、 仮想パッチ等）については、基本
緊急度の高い脆弱性であってもシステム再 対策事項7.2.1(1)-9 c)の解説に記載
起動・停止ができないためにそれら脆弱性 されています。また、「攻撃パ対策の実行が先延ばしになるケースがあケットを検知しブロックする暫定る。そのため、このような背景を踏まえた 的なセキュリティ対策」について確実に実行できる対策として、確実に脆弱 は、IPSによる攻撃元IPアドレスの性の定期確認を行う脆弱性スキャンの自動 遮断を意識したものと考えます
化、システムに影響を与えずに脆弱性対策 が、本件については基本対策事項を実行する技術（例えば仮想パッチ）を明 6.4.1(2)-1に記載されています。
記し、被害を最小限にとどめることが必要があると考える。「ソフトウェアに関する脆弱性対策計画を策定し、措置を講ずること。さらに、システム再起動の計画等の影響により再起動を必要とするセキュリティ
パッチ等のすみやかな適用が難しい環境においては、仮想パッチ等、脆弱性を突く攻撃パケットを検知しブロックする暫定的なセキュリティ対策や定期的に脆弱性を自動検知できる対策を講ずること。」との変更を提案します。
統一基準・ガイドライン「7.2.2 不正プログラム対策」について
62 企業・ ガイドラ メインフレームシステムなど、不正プログ ご意見を踏まえ、修正いたしま
団体

イン

ラム対策ソフトウェアが有効な役割を果た す。
さないと考えられているOS において、不正プログラム対策ソフトウェアが提供されていない場合は本項の対象外であるとの記載があるが、現在はスマートフォンなどを含めて新しいOSにも対応したソフトウェア
やOSにインストールせずに利用できる不正プログラム対策の技術があるため、 特にそのメインフレームシステムが本改定案の重要度分類により高重要度に分類されるシス
テムについては、同様に対策を検討することを推奨するべきと考える。

統一基準・ガイドライン「7.2.4 標的型攻撃対策」について

21 ページ

通しNo.

提出者 対象文書

概要

ご意見に対する考え方

63 企業・ ガイドラ 内部対策の追加セキュリティ対策として、 ご意見を踏まえ、不正な通信を監団体

イン

端末やネットワーク通信の挙動を元に攻撃 視する方法としてNDRの仕組みを者の横展開を早期検知する分析プラット

例示として解説に記載いたしま

フォームの利用を追記頂きたい。

す。

統一基準・ガイドライン「7.3.1 動的なアクセス制御の実装時の対策」について
64 企業・ ガイドラ 表7.3.1-3「有効な機能や当該機能を有する 「（解説）基本対策事項7.3.1(3)-1
団体

イン

ソリューションの例」の「リソース」は、 「動的なアクセス制御を実現する「ユーザアカウント」・「機器」のみだ

ための構成」について」に記載のが、「アプリケーション」・「データ」も とおり、表7.3.1-3は、リソースへ記載すべき。

の情報セキュリティ対策機能や当該対策が有効に機能し、リソースが信頼できるものであるかを検討する機能を有するソリューション
の一部を示しております。「ユーザアカウント」・「機器」以外のリソースに対する有効な機能やソリューションは、表7.3.1-3等を参考にして下さい。

統一基準・ガイドライン「8.1.1 情報システムの利用」について
65 企業・ ガイドラ 実行プログラム形式の添付ファイルのシス ご意見を踏まえ、実行プログラム
団体

イン

テム側での削除や圧縮形式のファイル全て 形式以外の形式に関して、追記いの削除については業務影響が出る部分であ たします。
り、負担から利用者からの問合せや依頼等が増えている。実行プラグラム形式以外のファイルタイプの脅威も同等に多いことから、実行プログラム形式ファイルのみを対象にして、添付ファイルを削除の運用では、効果の割に運用が難しいと捉える組織が多い。現在はファイルタイプを問わず、一律削除せずとも、悪性なプログラムを即座に隔離する技術があるため、案に記載の運用等と併せ、システム的に抑止する機能の選択肢の1つとして推奨することを提案します。

22 ページ

通しNo.

提出者 対象文書

概要

ご意見に対する考え方

66 企業・ ガイドラ 暗号化された圧縮形式のファイルの送受信 ご意見を踏まえ、職員等が不審な団体

インについては、PPAPを利用した場合に、ウィ 電子メールを受信することによる
ルスチェックをされないまま受信される可 被害をシステム的に抑止する機能能性があり受信者側で解凍・復号した際に の導入に係る対策が規定されていウィルス感染するリスクがあることを記載 る、「（解説）「基本対策事項していただきたい。

8.1.1(2)-2 d)「実行プログラム形式のファイルを削除等する」について」に追記いたします。

統一基準・ガイドライン「8.1.3 テレワーク」について
67 企業・ 統一基準 利用者側での対策に加えて、管理体制、団体

全体の体制は「2.1.1組織・体制のネットワーク環境、物理的な施設・作業環 整備」において規定がございま
境などテレワーク施設側に求められる対策 す。テレワーク施設につきましてについても言及した方がよい。

は、当該施設が機関等の管理下にない場合は統一基準群の適用範囲外となりますので、当該施設側の対策ではなく、利用者側の対策として、例えば、画面ののぞき見や盗聴から発生する情報漏えい対策（基本対策事項8.1.3(3)-1）や、報セキュリティ対策の状況が不明又は不十分な回線を利用しないための対策（基本対策事項8.1.3(3)-2）
を規定しております。

統一基準・ガイドライン全般について
68 企業・ ガイドラ 多くの企業が、「PPAPの利用禁止の方向」 ご賛同頂きありがとうございま団体

インを公表し、産業界としてもPPAP撲滅に向け す。
て推進していると認識しており、政府機関
等においてもPPAPの利用禁止をお願いした
いと考えており、今回、PPAPの利用禁止を促す記載が追加されていることに賛同する。

23 ページ

通しNo.

提出者 対象文書

概要

ご意見に対する考え方

69 企業・ ガイドラ 昨今運用体制としてSOCやMSS、ツールと 御意見ありがとうございます。御団体

イン

してSIEMやSOAR、EDRやNDR(Network

指摘の内容については今後の動向

Detection & Response)などの技術・サー等を踏まえて検討してまいりま

ビスの出現により検知領域の進歩および運 す。
用体制の充実が図られてきたが、実際に検知後に求められるインシデントレスポンスを中心とした適切な調査・解析・対処の部
分で新たな課題が発生している。そのため、政府統一基準群の考え方全体にXDR(eXtended Detection & Response)を含めることを要望する。
70 企業・ ガイドラ 政府統一基準群の考え方にアタックサー
団体

イン

ご意見頂いた内容については今後

フェスのリスクを管理することでシステム の検討の参考とさせていただきま
運用やSOCのリソースを最大限活用するた す。
めのよりプロアクティブな防御力向上策を含めるため、ASM(アタックサーフェスマネ
ジメント)の活用を要望する。

その他ご意見について
71 個人

その他

全体として違反時の罰則に触れられていな 統一基準ではセキュリティポリ
い。一般企業では違反したら懲戒の文言が シーに違反した場合の罰則についあるのだが、官公庁では違反したらどうな て規定する想定はありません。職るのか。

員等は各機関等において定められたセキュリティポリシーに従う必要がありますが、これに違反した
場合の処分については、各機関等において定められた基準において判断されます。

72 個人

その他

サイバーセキュリティ戦略本部が指定する 指定法人の指定については、統一法人（指定法人）は現在9法人が指定されて 基準において定めているものではいるものと認識している。
しかしながら、サイバー攻撃の手口がありませんが、いただいたご意見は今後の検討の参考とさせていた

日々巧妙化している状況下、「保有情報の だきます。
機微性、業務の国民生活・経済活動へ与える影響」等の基準と併せて、予期せぬインシデントが発生した際の将来的なリスクも勘案して対象を継続的に点検し、必要に応じて追加を行っていくべきではないか。

24 ページ

通しNo.

提出者 対象文書

73 個人

その他

概要

ご意見に対する考え方

IT分野の進展は早く、次から次へと新サーご意見頂いた内容については今後

ビス、新形態のサービスが登場しており、 の検討の参考とさせていただきま
行政分野で取り入れる際に、本基準が適用 す。
されるのか曖昧なものが多々あると思われる。基準の網から抜け落ちると、そこをキッカケにセキュリティリスクが広がることも考えられる。クラウド、SAAS、ウェブ
アプリ、スマホアプリ等等行政サービスとして国民向けに提供されるITシステムやソフトも増えている。これらを包含するような再定義があると良いのでは。
74 個人

その他

しおり付きPDFで提供されたことは最低限 現在、統一基準群のWord版と、の電子的可読性が保てて非常によい。政府 「政府機関等の対策基準策定のた
全体での取り組みに発展させて欲しい。し めのガイドライン」のExcel版の公かし、改訂なので新旧対象表と、Wordの変 開を検討しております。
更履歴付きの版も提供してあるといいのではないかと思います。特にWordで提供することにより、レビュー時の検索だけでなく、その書類の利活用にも有効である。本来、利活用するために提供するものである
ので、如何に利活用しやすくできるかも考
慮して欲しい。例えば、統一基準は最低限の基準であり、機関等はこれ以上のことを要求している。これを確認するためには、
統一基準の各要件と自機関の要件とをExcelのようなもので並べて比較、確認したくなる。そのためには統一基準の各要件がExcel
等で提供されるとより利活用しやすくなる
等が考えられる。

75 企業・ その他
団体「政府機関等の対策基準策定のためのガイ 現在、「政府機関等の対策基準策ドライン」を、エクセル形式でも公開すべ 定のためのガイドライン」のExcel
き

版を公開することを検討しております。

上記以外にも、本改定案に直接関係ありませんが、ご意見をいただきました。

25 ページ