第6部 情報システムの構成要素

6.1 端末

6.1.1 端末

目的・趣旨

端末の利用に当たっては、不正プログラム感染や不正侵入を受けるなどの外的要因により、保存されている情報の漏えい等に注意する必要がある。また、職員等の不適切な利用や過失等の内的要因による不正プログラム感染等の情報セキュリティインシデントが発生するおそれもある。これらのリスクを考慮し職員等が利用する端末については適切なセキュリティ対策を講ずるとともに、利用を認めるソフトウェアや接続を認める機器等を定めておくことが重要である。また、物理的な端末のモバイル利用に当たっては、盗難・紛失等による情報漏えいの可能性も高くなる。これらのことを考慮して、対策を講ずる必要がある。

なお、本款の遵守事項のほか、7.1「情報システムのセキュリティ機能」において定める主体認証・アクセス制御・権限管理・ログ管理等の機能面での対策、7.2.1「ソフトウェアに関する脆弱性対策」、7.2.2「不正プログラム対策」、6.4.4「IPv6通信回線」において定める遵守事項のうち端末に関係するものについても併せて遵守する必要がある。

遵守事項

(1) 端末の導入時の対策

(a) 情報システムセキュリティ責任者は、要保護情報を取り扱う物理的な端末について、端末の盗難、不正な持ち出し、第三者による不正操作、表示用デバイスの盗み見等の物理的な脅威から保護するための対策を講ずること。

(b) 情報システムセキュリティ責任者は、多様なソフトウェアを利用することにより脆弱性が存在する可能性が増大することを防止するため、端末で**利用を認めるソフトウェアを定め、****それ以外のソフトウェアは利用させない**こと。

(c) 情報システムセキュリティ責任者は、端末に**接続を認める機器等を定め、接続を認めた機器等以外は接続させない**こと。

(d) 情報システムセキュリティ責任者は、情報システムのセキュリティ要件として策定した内容に従い、端末に対して**適切なセキュリティ対策を実施する**こと。

(e) 情報システムセキュリティ責任者は、端末において利用する**ソフトウェアに関連する公開された脆弱性について対策を実施する**こと。

【 基本対策事項 】

＜6.1.1(1)(a)関連＞

6.1.1(1)-1 情報システムセキュリティ責任者は、モバイル端末を除く物理的な端末について、**原則としてクラス２以上の要管理対策区域に設置する**こと。

6.1.1(1)-2 情報システムセキュリティ責任者は、**物理的な端末の盗難及び不正な持ち出しを防止**するために、以下を例とする対策を講ずること。

a) モバイル端末を除く端末を、容易に切断できないセキュリティワイヤを用いて固定物又は搬出が困難な物体に固定すること。

b) モバイル端末を保管するための設備（利用者が施錠できる袖机やキャビネット等）を用意すること。

6.1.1(1)-3 情報システムセキュリティ責任者は、**第三者による不正操作及び表示用デバイスの盗み見を防止するために、以下を全て含む対策を講ずる**こと。

a) 一定時間操作が無いと自動的にスクリーンロックするよう設定すること。

b) 不特定多数の人が出入りする場所で使用するモバイル端末に対して、盗み見されるおそれがある場合にのぞき見防止フィルタを取り付けること。

＜6.1.1(1)(b)関連＞

6.1.1(1)-4 情報システムセキュリティ責任者は、以下の全てを考慮した上で、端末で**利用を認めるソフトウェアをバージョンも含め定める**こと。なお、特定の業務や端末のみに利用を認めるなどの条件を付す場合は、その旨を含めること。

a) ソフトウェアベンダ等のサポート状況

b) ソフトウェアと外部との通信の有無及び通信する場合は、プロトコル（バージョンを含む。）、使用するポート、暗号化の有無

c) インストール時に同時にインストールされる他のソフトウェア

d) その他、ソフトウェアの利用に伴う情報セキュリティリスク

6.1.1(1)-5 情報システムセキュリティ責任者は、**端末に対して、利用を認めるソフトウェア以外のソフトウェアを利用者が自由にインストールできない技術的な措置を講ずる**こと。

（解説）

利用を認めるソフトウェアのリストには、市販のアプリケーションに限らず、リモートデスクトップやファイル共有サービス等の特定のポート番号を利用するOSが備えているサービス等も登録する必要がある。また、情報セキュリティリスクを低減する観点から、利用を認めるソフトウェアは極力限定することが重要である。そのため、特定の業務で利用することを条件として利用を認める場合や、特定の端末でのみ利用を認める場合等、利用を認めるソフトウェアを条件を付した状態でリストに登録する場合は、その旨を含めて登録する必要がある。

なお、リストに登録する単位については、ソフトウェアの個別の製品名やバージョン単位で列挙すると分かりやすいが、頻繁にアップデートをする必要がある製品についてはバージョンを最新版とする運用が考えられる。

接続を認める機器等については、例えばUSBポートに接続するキーボードやマウス、ヘッドホンなどが考えられるが、端末を利用して行う業務等を踏まえて定めるとよい。また、外部電磁的記録媒体については、組織で認めたもの以外の接続を制限するなども考えられる。さらに、出所が不明なUSBデバイスについては、不正プログラムが組み込まれたBadUSBと呼ばれる攻撃が存在するため、接続を制限するとよい。

端末を導入する際は、セキュリティ要件に従って適切なセキュリティ対策を実施する必要がある。例えば、端末を利用する際の主体認証方式や情報の暗号化等の情報セキュリティ機能が正しく実装されていることや脆弱性対策、不正プログラム対策等を実施する必要がある。また、端末において不要なポートやプロトコルが有効になっていないことを確認することや一定の無通信時間が経過した場合は当該通信セッションに係る通信を遮断する、不要な機能は無効にするなどの対策も重要である。

職員等が端末を利用する前に端末で利用するソフトウェアに関連する脆弱性情報を確認し、脆弱性が公開されていた場合は、セキュリティパッチを適用するなどの対策を実施する必要がある。

ソフトウェアの脆弱性については、7.2.1「ソフトウェアに関する脆弱性対策」を参照のこと。

クラス２より低位の区域に設置する必要がある場合は、利用者が常時監視できる場所への設置を義務付けるなど、クラス２の区域に設置する場合と同程度の安全性を確保するための代替の対策を講ずる。

モバイル端末を除く物理的な端末については、設置する場所によっては、ハードディスク等の電磁的記録媒体の盗難についても注意が必要である。そのような端末においては筐体を施錠する等の対策も検討するとよい。また、モバイル端末については紛失した際のリスクを軽減するため、ハードディスク等の電磁的記録媒体を暗号化するなどの措置を講ずる等の対策も検討するとよい。

第三者による不正操作等の防止のための対策事項であるが、その他、端末の操作のロックの解除にICカード等の主体認証情報格納装置を使用し、主体認証情報格納装置が無い状態で又は操作の無い状態が一定時間続くことで端末の操作がロックされるようにし、かつ、当該主体認証情報格納装置を執務室からの退出の確認にも利用するという方法が考えられる（これにより、利用者が執務室外にいる際には端末の操作が確実にロックできる）。

また、正規の利用者による不正操作や誤操作の防止策として、端末が備える機能のうち、利用しない機能を停止することが考えられる。停止する機能の例としては、以下が考えられる。

利用を認めるソフトウェアを定める際には、以下を行うことが考えられる。

また、一度利用を認めたソフトウェアであっても、バージョンが上がった際に、旧バージョンと比べ、機能が変わることや、同時にインストールされる他のソフトウェアが追加される場合があるので、利用を認めるソフトウェアを定める際には、バージョンも含めて定めることが重要である。

端末で利用を認めるソフトウェア以外のソフトウェアについて、職員等の認識不足などにより無断で利用されることを防ぐため、本基本対策事項では、利用を認めるソフトウェア以外のソフトウェアを利用者が自由にインストールできない技術的な措置を講ずることを求めている。

技術的な措置としては、以下の例が挙げられる。

遵守事項

(2) 端末の運用時の対策

(a) 情報システムセキュリティ責任者は、利用を認めるソフトウェアについて、定期的な確認による**見直しを行う**こと。

(b) 情報システムセキュリティ責任者は、所管する範囲の端末で利用されている全てのソフトウェアの状態を定期的に調査し、**不適切な状態にある端末を検出等した場合には、改善を図る**こと。

【 基本対策事項 】

＜6.1.1(2)(a)関連＞

6.1.1(2)-1 情報システムセキュリティ責任者は、利用を認めるソフトウェアの定期的な確認においては、引き続き利用を認めるか否かを判断し、利用を認めない場合は利用を認めるソフトウェアから削除すること。

6.1.1(2)-2 情報システムセキュリティ責任者は、利用を認めるソフトウェア以外のソフトウェアについて職員等から利用申請があった場合には、当該ソフトウェアの利用を認めるか否かを判断し、利用を認める場合は利用を認めるソフトウェアに追加すること。

（解説）

ソフトウェアのバージョン更新、サポート期限切れ、新しいソフトウェアの出現等に適切に対応するため、また、利用者の要求に柔軟に対応するため、利用を認めるソフトウェアの確認による見直しを行う必要がある。見直しを行うに当たっては、利用を認めるソフトウェアの必要性や利用を認めることによる脅威へのリスク等を踏まえた上で見直しを行う必要がある。

「定期的」以外の見直しの契機として、職員等から利用を認めるソフトウェア以外のソフトウェアの利用承認の申請（8.1.1「情報システムの利用」を参照のこと。）を受け付けたときが考えられる。申請のあったソフトウェアについて、当該ソフトウェアの必要性や利用目的、取り扱う情報の概要、要機密情報の利用の有無、その他利用することによる脅威へのリスク等を踏まえて、利用を認めるか否かを判断する必要がある。なお、民間事業者等が不特定多数の利用者に対して提供する、定型約款や規約等への同意のみで利用可能となるクラウドサービスでは要機密情報を取り扱う上で必要十分なセキュリティ要件を満たすことが一般的に困難であることから、このようなクラウドサービスの利用に必要なソフトウェア（端末にインストールされるアプリケーションを含む）では、原則として要機密情報を取り扱うことはできない（4.2.3「クラウドサービスの選定・利用（要機密情報を取り扱わない場合）」を参照のこと。）。

特に管理者権限を必要とするソフトウェアや他のソフトウェアを含む機器等の管理や制御を行うソフトウェアの利用を認める場合は、追加のセキュリティ対策を実施させるなど、ソフトウェアを利用することによる脅威へのリスクを低減することが重要である。

「不適切な状態」とは、利用を認めるソフトウェア以外のソフトウェアがインストールされている、ソフトウェアが動作するための適切な設定がなされていない、最新のセキュリティパッチが適用されていないなどの状態のことをいう。その他にも不正プログラム対策ソフトウェアのパターン等が最新でない、要機密情報が暗号化されていない、脆弱又は不要なプロトコルやポート、サービスなどが動作している、脆弱な初期の設定値等が是正されていない状態なども改善を図る必要がある。

なお、利用を認めるソフトウェア以外のソフトウェアが稼働している場合には、当該ソフトウェアを停止する、又は削除する必要がある。セキュリティパッチについては、7.2.1「ソフトウェアに関する脆弱性対策」を参照のこと。

遵守事項

(3) 端末の運用終了時の対策

(a) 情報システムセキュリティ責任者は、**端末の運用を終了する際に、端末の電磁的記録媒体の全ての情報を抹消する**こと。

【 基本対策事項 】規定なし

（解説）

端末を廃棄処分する場合やリース契約が終了し端末を返却する場合が考えられる。

抹消の方法については、「（解説）遵守事項3.1.1(7)(b)「抹消する」について」を参照のこと。

なお、運用を業務委託しているなど、調達元の機関等において抹消できない場合においては、保存されている情報の漏えいが生じないための対策を講じさせるため、情報の抹消方法及び履行状況の確認手段を、契約内容に含むようにするなどの別の手段で対策を講ずる必要がある。

6.1.2 要管理対策区域外での端末利用時の対策

目的・趣旨

テレワークの実施等により、職員等が機関等外で業務を行うことが増え、機関等が支給する物理的な端末を利用して要管理対策区域外で業務を行う場合は、盗み見や盗難・紛失などのリスクが増える。そのようなリスクに対抗するため、要管理対策区域外で機関等が支給する物理的な端末を使用する場合は、利用手順や利用の許可手続等を定め、職員等に守らせる必要がある。また、端末においても盗難、紛失、不正プログラムの感染等による情報窃取を防止するため技術的な措置を講ずる必要がある。

さらに、職員等が機関等外通信回線を用いて情報システムにリモートアクセスをする場合は、リモートアクセス特有の攻撃等に対抗するためのセキュリティ対策を実施する必要がある。リモートアクセスについては、遵守事項8.1.3(2)を参照のこと。

なお、機関等外通信回線を用いて情報システムにリモートアクセス環境を構築する場合は、情報システムへのアクセスについて初回のアクセス要求時のみ制御を行うのではなく、アクセスの都度信用できるアクセスであるかを検証し、信用できない場合には追加の措置を講ずるなど、アクセスの要求ごとに、主体等の状況を継続的に認証し認可する仕組みを実現する機能の一部である動的なアクセス制御を実施することも有効である。動的なアクセス制御については、7.3「ゼロトラストアーキテクチャ」を参照のこと。

遵守事項

(1) 機関等が支給する端末（要管理対策区域外で使用する場合に限る）の導入及び利用に係る運用規程の整備

(a) 統括情報セキュリティ責任者は、職員等が機関等が支給する物理的な端末（要管理対策区域外で使用する場合に限る）を用いて要保護情報を取り扱う場合について、これらの端末や利用した通信回線から情報が漏えいするなどのリスクを踏まえた利用手順及び許可手続を実施手順として定めること。

(b) 統括情報セキュリティ責任者は、**要機密情報を取り扱う機関等が支給する物理的な端末（要管理対策区域外で使用する場合に限る）**について、盗難、紛失、不正プログラムの感染等により情報窃取されることを防止するための技術的な措置に関する運用規程を整備すること。

(c) 統括情報セキュリティ責任者は、要管理対策区域外において機関等外通信回線に接続した機関等が支給する物理的な端末を**機関等内通信回線に接続することについての可否を判断した上で、可と判断する場合は、当該端末から機関等内通信回線を経由して情報システムが不正プログラムに感染するリスクを踏まえた技術的な措置に関する運用規程**を定めること。

【 基本対策事項 】

＜6.1.2(1)(a)関連＞

6.1.2(1)-1 統括情報セキュリティ責任者は、職員等が機関等が支給する物理的な端末（要管理対策区域外で使用する場合に限る。）を用いて要保護情報を取り扱う場合の利用手順を実施手順として、以下を例として定めること。

a) 端末で利用する電磁的記録媒体に保存されている要機密情報の暗号化

b) 盗み見に対する対策（のぞき見防止フィルタの利用等）

c) 盗難・紛失に対する対策（不要な情報を端末に保存しない、端末の放置の禁止、利用時以外のシャットダウン及びネットワークの切断、モバイル端末を常時携帯する、常に身近に置き目を離さないなど）

d) 利用する場所や時間の限定

e) 端末の盗難・紛失が発生した際の緊急対応手順

6.1.2(1)-2 統括情報セキュリティ責任者は、職員等が機関等が支給する物理的な端末（要管理対策区域外で使用する場合に限る。）を用いて要保護情報を取り扱う場合について、以下を全て含む許可手続を実施手順として定めること。

a) 利用時の許可申請手続

b) 手続内容（利用者、利用期間、主たる利用場所、目的、利用する情報、端末、通信回線への接続形態等）

c) 利用期間満了時の手続

d) 許可権限者（課室情報セキュリティ責任者）による手続内容の記録

＜6.1.2(1)(b)関連＞

6.1.2(1)-3 統括情報セキュリティ責任者は、要機密情報を取り扱う機関等が支給する物理的な端末（要管理対策区域外で使用する場合に限る。）について、以下を例に、利用者が端末に情報を保存できないようにするための機能又は端末に保存される情報を**暗号化**するための機能を検討し、要管理対策区域外で使用する物理的な端末に求める技術的な措置に関する運用規程を設けること。

a) **シンクライアント等**の仮想デスクトップ技術を活用した、端末に情報を保存させないリモートアクセス環境を構築し、利用者は専用のシンクライアントアプリケーションを利用端末にインストールし、業務用システムへリモートアクセスすること。

b) **セキュアブラウザ等**を活用した、端末に情報を保存させないリモートアクセス環境を構築し、利用者はセキュアブラウザを利用端末にインストールし、業務用システムへリモートアクセスすること。

c) **ファイル暗号化等のセキュリティ機能を持つアプリケーション**を導入すること。

d) 端末に、**ハードディスク等の電磁的記録媒体全体を自動的に暗号化する機能**を設けること。

e) 上記の各号のいずれの機能も使用できない場合は、端末に**ファイルを暗号化する機能を設ける**こと。

f) ハードディスク等の電磁的記録媒体に保存されている情報を**遠隔からの命令等により暗号化消去する機能**を設けること。

g) **高度なセキュリティ機能を備えたOSを搭載するスマートフォンやタブレット端末等**を使用すること。

＜6.1.2(1)(c)関連＞

6.1.2(1)-4 統括情報セキュリティ責任者は、要管理対策区域外において機関等外通信回線に接続した機関等が支給する物理的な端末について、機関等内通信回線に接続する場合は、当該端末から機関等内通信回線を経由して情報システムが不正プログラムに感染するリスクを踏まえ、以下を例とする技術的な措置について運用規程として定めること。

a) 機関等内通信回線に接続する前に当該端末に対し、不正プログラム対策ソフトウェアを用いて検査を行うこと。

b) 機関等内通信回線に接続した当該端末が、不正な通信を行っていないか、不要なアプリケーション、サービスやポートを使用していないか確認すること。

c) 技術的な措置において不適切な状態を検知した場合は、機関等内通信回線に接続させない措置を講ずることや、機関等内通信回線から直ちに切断するなどの措置を講ずること。

（解説）

要機密情報を取り扱う機関等が支給する端末（要管理対策区域外で使用する場合に限る。）とは、モバイル端末が該当する。

要管理対策区域外においてインターネットに接続した端末（支給外端末を含む。）を要管理対策区域において機関等LANシステムに直接接続する場合、境界監視やファイアウォール等の多重防御を回避して不正プログラムが直接に機関等LANシステム内に持ち込まれることにより、情報窃取、情報の破壊、サービス不能攻撃の踏み台になること等のリスクが高まる。このため、要管理対策区域外において機関等外通信回線に接続した物理的な端末（支給外端末を含む。）の接続の必要性がある場合には、取り得る情報セキュリティ対策、接続先となる情報システムにおいて取り扱う情報、情報セキュリティインシデント発生時の影響等を適切に評価した上で、総合的な見地から可否の判断を行う必要がある。例えば、要管理対策区域外での端末（支給外端末を含む。）の利用時に、機関等外通信回線を通じて機関等の情報システムのみにアクセスできる設定（例えば、機関等の情報システムにアクセスするためのアプリケーション以外を使用させない設定等）とし、シンクライアントやVPNとセキュアブラウザの組み合わせを用いて当該情報システムへリモートアクセスさせるような場合は、機関等外通信回線に接続して業務を行った後、機関等内通信回線へ接続する時のリスクを懸念する必要性は低下する。このように取り得る情報セキュリティ対策等を考慮して上記の判断を行うことが求められる。なお、リモートアクセスに関する対策は、遵守事項8.1.3(2)を参照のこと。

また、テレワークやクラウド利用の拡大により、機関等外から情報システムへのアクセスが増えるにつれ、主体のなりすましによる不正アクセスなどの脅威への対策が重要である。そのような脅威へ対抗するためには、あらゆるアクセスを信用できないものとして扱い、アクセスの都度信用情報を用いた検証によって動的なアクセス制御を行う対策が有効である。動的なアクセス制御の実装については、7.3「ゼロトラストアーキテクチャ」を参照のこと。

インターネット等の機関等外通信回線に直接接続して業務を行った物理的な端末を機関等内通信回線に接続を行う場合には、利用可能な情報セキュリティ対策技術等を総合的に勘案の上、適切に対策を講ずる必要がある。例えば、機関等内通信回線に接続する前に不正プログラム対策ソフトウェアを用いて検査を行うことや当該端末において不正な通信を行っていないか、不要なアプリケーション、サービスやポートを使用していないかなどを確認するなどが考えられる。その際、不適切な状態を検知した場合は、機関等内通信回線に接続させない措置を講ずることや、機関等内通信回線から直ちに切断するなどの措置を講ずることも考えられる。

一般的に、以下に例を挙げる状況では、盗難・紛失が発生しやすいため、要機密情報を含むモバイル端末を携行する場合には十分注意させる必要がある。特に飲酒が想定される場合は、モバイル端末は携行しないことが重要である。

利用期間満了時は、職員等に報告を求めるよう手続に定める必要がある。特に機密性３情報等の取扱いに注意すべき情報を要管理対策区域外に持ち出す場合においては、以下を例とする管理手順を設けるとよい。

機関等が支給する端末（要管理対策区域外で使用する場合に限る。）に要機密情報を保存して業務を行う場合は、端末に保存する情報を暗号化して、盗難・紛失時の情報漏えいのリスクを低減する必要がある。情報へのアクセス権を管理する方法もあるが、モバイル端末が第三者の者の手に渡った場合には、モバイル端末から取り外された内蔵電磁的記録媒体や、モバイル端末で利用していた外部電磁的記録媒体に保存されている情報を他の端末を利用して解読するなどの手段によってアクセス権管理機構を回避され要機密情報が窃取される危険性がある。このような情報の窃取への対策として、端末に暗号化機能を搭載することが有効である。

暗号化する方法としては、ファイル暗号化等のセキュリティ機能を持つアプリケーションを用いる方法、ハードディスク等の電磁的記録媒体又はファイル単体を暗号化するソフトウェアの導入やOSが備えている暗号化機能を使用することが挙げられる。遠隔データ消去機能を補助的な機能として組み合わせると効果的である。ハードディスク等の電磁的記録媒体を暗号化している場合であっても、端末の起動中等の復号可能な状態で盗難等に遭った場合には情報窃取されるおそれがあるため、遠隔データ消去機能と組み合わせて用いると情報窃取される可能性をより低減できる。

また、安全性を確保するためには暗号化に用いる鍵の管理が重要である。端末紛失時に端末内に鍵や、鍵を生成するために必要な全ての情報を保持していると暗号化したデータを復号されるリスクがある。

したがって、業務利用していないときはこれらを保持しないなど、鍵の漏えいリスクが低減されるような管理の仕組みを持つ以下を例とする方式を導入するとよい。

＜例＞

端末に情報を保存させない仕組みとして、シンクライアントやリモートデスクトップと呼ばれる技術の活用が有効である。既に市場において提供されているが、外部の情報処理サービスを組み合わせてシンクライアントやリモートデスクトップ関連の製品やソリューションサービスを利用する場合には、第4部「外部委託」についても参照する必要がある。

＜シンクライアントの主な機能及び特徴＞

図6.1.2-1　シンクライアントのシステム構成例

また、シンクライアントの発展形として、仮想デスクトップ環境の利用機能（ネットワーク接続や画面描画・ディスプレイ出力、キーボード・マウス入力等）のみに機能が絞り込まれたゼロクライアントやシンクライアント専用端末の利用も有効である。特にゼロクライアントは、汎用OSや汎用ブラウザ等を搭載していないことから、不正プログラム対策やソフトウェア更新等のセキュリティ管理の負荷が軽減でき、万一端末が故障しても、端末を交換するだけですぐに利用可能になるなど、セキュリティ管理面の負荷の軽減も期待される。処理能力やコスト負担等の課題も考えられるので、それらも勘案した上で利用を検討するとよい。

セキュアブラウザ製品は、各種サービスと組み合わせたソリューションとして提供される場合があることから、外部の情報処理サービスを組み合わせて利用する場合は、第4部「外部委託」についても参照する必要がある。

＜セキュアブラウザの主な機能及び特徴＞

図6.1.2-2　セキュアブラウザ活用型ソリューションのシステム構成例

通信回線との接続環境が無い場所で業務を行うなど、やむを得ず情報を端末に保存させる必要がある場合は、セキュアブラウザやシンクライアントは利用できないことから、他の方法で安全な利用環境の提供を考える必要がある。この場合は、モバイル端末にファイル暗号化等のセキュリティ機能を持つ業務専用のアプリケーションを搭載し、アプリケーション単位で情報を暗号化するなどの方法が考えられる。当該機能を有するセキュリティソリューションが製品として民間事業者より提供されていることから、それらの活用を検討するとよい。

図6.1.2-3　ファイル暗号化等セキュリティ機能を持つ

アプリケーションを活用したシステム構成例

電磁的記録媒体全体を暗号化する機能については、例えばソフトウェアによる暗号化（WindowsのBitLocker等）やハードウェアによる暗号化（自己暗号化ドライブ（Self-Encrypting Drive）等）などが考えられる。なお、暗号化する機能としてWindowsのBitLockerを利用する場合は、パスワード解析への耐性を高めるため、端末起動時に追加の認証（PIN）を要求することを検討するとよい。

機関等が支給する端末（要管理対策区域外で使用する場合に限る。）のセキュリティ対策については、職員等の人的作業負担とならないようにすべきであり、職員等が講じた安全管理措置が不十分であることも考えられるため、基本対策事項6.1.2(1)-3 a)～d)に示すシステム面で対応が取られることが望ましい。要管理対策区域外で要機密情報を取り扱う際の対策として、個々のファイルを手作業により暗号化する場合は、職員等に確実にこれを実施させることが必要となる。ただし、職員等が個々に暗号化すると、設定ミスや漏れ等が発生する可能性が高くなることから、職員等が暗号化の実施を容易にする仕組みの検討が重要である。

例えば、職員等が確実にファイルの暗号化を実施することを容易にする仕組みとして、仮想化技術を活用した仮想ドライブを用いる方法がある。仮想ドライブの作成時に暗号化の設定を施すことにより、当該仮想ドライブに保存されるファイルの暗号化と復号を自動的に行うことができる。

端末の通信機能を利用して、遠隔から端末内のデータを暗号化消去する機能であるが、通信が確立できないために遠隔からデータ消去できない場合に備え、主体認証の失敗した回数をカウントして一定数を超えた際に消去するなど特定の条件で自律的に消去する機能についても導入するとよい。

一部のスマートフォンやタブレット端末用のOSにおいて、不正プログラム対策ソフトウェアが有効な役割を果たさないと考えられ、提供されていないことがある（「（解説）遵守事項7.2.2(1)(a)「不正プログラム対策ソフトウェア等を導入する」について」を参照のこと。）。そうしたOSは多くの場合、基本対策事項6.1.2(1)-3 d)及びf)のような高度なセキュリティ機能を標準で備えており、追加の対策を講ずることなく容易にそれらの機能を利用することができる。

業務上の要件との兼ね合いもあるが、安全性を優先して、こうしたOSを搭載する端末を積極的に利用することも考えられる。

遵守事項

(2) 機関等が支給する端末（要管理対策区域外で使用する場合に限る）の導入及び利用時の対策

(a) 情報システムセキュリティ責任者は、職員等が機関等が支給する物理的な端末（要管理対策区域外で使用する場合に限る）を用いて要機密情報を取り扱う場合は、当該端末について**前条(b)の技術的な措置を講ずる**こと。

(b) 情報システムセキュリティ責任者は、要管理対策区域外において機関等外通信回線に接続した機関等が支給する物理的な端末を機関等内通信回線に接続させる際、当該端末について**前条(c)の技術的な措置を講ずる**こと。

【 基本対策事項 】

＜6.1.2(2)(a)(b)関連＞

6.1.2(2)-1 情報セキュリティリスクが相対的に高いと考えられる地域においては、**第三者による物理的なアクセスのリスクへの対策**を実施すること。

（解説）

職員等が機関等が支給する物理的な端末（要管理対策区域外で使用する場合に限る。）を用いて要機密情報を取り扱う場合は、遵守事項6.1.2(1)(b)において定めた運用規程に基づき、当該端末に対して技術的な措置を講ずることが求められる。

テレワークなどによって要管理対策区域外の機関等外通信回線に接続した機関等が支給する物理的な端末については、機関等内通信回線に接続させる際に、遵守事項6.1.2(1)(c)において定めた運用規程に基づき技術的な措置を講ずることが求められる。

情報セキュリティリスクが相対的に高いと考えられる地域等においては、第三者による物理的なアクセスのリスクを十分に考慮する必要がある。このような地域等においては、例えば、使用する端末のUSBポート等を物理的にロック（塞ぐ）して封印、システム設定で端末のUSBポート等を無効にするといった対策を施した専用のモバイル端末で業務を行うとともに、端末は常時携行し、このような地域等から戻った際には、端末を工場出荷時の状態に戻すことが望ましい。

6.1.3 機関等支給以外の端末の導入及び利用時の対策

目的・趣旨

機関等の業務の遂行においては、機関等から支給された端末を用いてこれを遂行すべきである。しかしながら、出張や外出等や危機的事象発生時の際に、やむを得ず機関等支給以外の端末を利用して情報処理を行う場合も考えられるが、この際、当該端末の情報セキュリティ水準が対策基準を満たさないおそれがある。このため、機関等支給以外の端末を業務において利用する可能性がある場合は、利用に当たって求められる情報セキュリティの水準が確保されるかどうかを適切に評価し、業務遂行可能なように、利用できる機能の制限や追加のセキュリティ対策を施した上で、職員等に対して機関等における厳格な管理の下で利用させることが必要である。

また、機関等支給以外の端末については、端末の管理を端末の所有者が行うこととなり、機関等において管理ができないことへのリスクを勘案し、その利用の可否を判断する必要がある。利用を認めたとしても、利用の許可手続を定めるとともに、情報の取扱いについての規定や手順を整備し遵守させる必要がある。

遵守事項

(1) 機関等支給以外の端末の利用可否の判断

(a) 最高情報セキュリティ責任者は、機関等支給以外の端末の利用について、取り扱うこととなる情報の格付及び取扱制限、機関等が講じる安全管理措置、当該端末の管理は機関等ではなくその所有者が行うこと等を踏まえ、求められる情報セキュリティの水準の達成の見込みを勘案し、機関等における機関等支給以外の端末の利用の可否を判断すること。

【 基本対策事項 】規定なし

（解説）

機関等支給以外の端末の利用とは、職員等が従事する業務で利用する機関等の情報システムから入手可能な業務に係る情報（業務上知り得る情報）、情報システムの仕様やデータ設定等に係る情報や、情報システムにおいて利用される主体認証情報（パスワード等）を機関等支給以外の端末において利用することである。ただし、機関等支給以外の端末で機関等が公表している情報を入手するなどの利用は、含まない。

機関等支給以外の端末の導入に当たっては、以下のようなリスクが想定される。

個別判断により機関等支給以外の端末の利用を認めてしまうと、「（解説）遵守事項6.1.3(1)(a)「求められる情報セキュリティの水準の達成の見込み」について」に記載したリスクが顕在化する可能性が高いことから、利用に当たっては、最高情報セキュリティ責任者があらかじめ統一的に判断することを求めている。利用を許可するに当たり、機関等としての利用方針を定めて、その利用方針の下、厳格な管理を行うことが求められる。

機関等支給以外の端末の利用方針として、例えば以下の事項を明確にすることが考えられる。

また、機関等支給以外の端末の利用に際して、利用する通信回線やサーバ装置等、情報システム全体として情報セキュリティを確保することが重要であることから、リモートアクセス環境や端末の安全管理措置について、システム機能として提供することも考慮すべきである。

併せて、機関等支給以外の端末の利用可否及びその利用方針について、当該事項を対策基準に記載するとともに、職員等へ周知することで機関等支給以外の端末の適切な利用が行われるようにすることも重要である。

遵守事項

(2) 機関等支給以外の端末の利用に関する運用規程等の整備

(a) 統括情報セキュリティ責任者は、職員等が機関等支給以外の端末を用いて機関等の業務に係る情報処理を行う場合の**許可等の手続**を実施手順として定めること。

(b) 統括情報セキュリティ責任者は、職員等が機関等支給以外の端末を用いて要保護情報を取り扱う場合について、盗難、紛失、不正プログラムの感染等により情報窃取されるなどのリスクを踏まえた利用手順及び許可手続を実施手順として定めること。

(c) 統括情報セキュリティ責任者は、**要機密情報を取り扱う機関等支給以外の端末**について、盗難、紛失、不正プログラムの感染等により情報窃取されることを防止するための技術的な措置を含めた安全管理措置に関する運用規程を整備すること。

(d) 統括情報セキュリティ責任者は、要管理対策区域外において機関等外通信回線に接続した機関等支給以外の端末を**機関等内通信回線に接続することについての可否を判断した上で、可と判断する場合は、当該端末から機関等内通信回線を経由して情報システムが不正プログラムに感染するリスクを踏まえた安全管理措置に関する運用規程**及び許可手続に関する実施手順を定めること。

【 基本対策事項 】

＜6.1.3(2)(a)関連＞

6.1.3(2)-1 統括情報セキュリティ責任者は、機関等支給以外の端末を利用する際に、以下を全て含む許可等の手続を実施手順として整備し、職員等に周知すること。

a) 以下を全て含む機関等支給以外の端末利用時の申請内容

＜6.1.3(2)(b)関連＞

6.1.3(2)-2 統括情報セキュリティ責任者は、職員等が機関等支給以外の端末を用いて要保護情報を取り扱う場合の利用手順を、以下を例とし実施手順として定めること。

a) 端末で利用する電磁的記録媒体に保存されている要機密情報の暗号化

b) 盗み見に対する対策（のぞき見防止フィルタの利用等）

c) 盗難・紛失に対する対策（不要な情報を端末に保存しない、端末の放置の禁止、利用時以外のシャットダウン及びネットワークの切断、モバイル端末を常時携帯する、常に身近に置き目を離さないなど）

d) 利用する場所や時間の限定

e) 端末の盗難・紛失が発生した際の緊急対応手順

6.1.3(2)-3 統括情報セキュリティ責任者は、要機密情報を取り扱う機関等支給以外の端末について、以下を例とする利用時の措置を利用手順に加え、実施手順として定めること。

a) **パスワード等による端末ロック**の常時設定

b) OSやアプリケーションの最新化

c) **不正プログラム対策ソフトウェアの導入**及び定期的な不正プログラム検査の実施（機関等として不正プログラム対策ソフトウェアを指定する場合は当該ソフトウェアの導入も含む。）

d) 機関等提供の業務専用アプリケーションの利用（専用アプリケーションを提供する場合のみ）

6.1.3(2)-4 統括情報セキュリティ責任者は、要機密情報を取り扱う機関等支給以外の端末について、以下を全て含む禁止事項を利用手順に加え、実施手順として定めること。

a) 端末、OS、アプリケーション等の改造行為

b) **安全性が確認できないアプリケーション**のインストール及び利用

c) **利用が禁止されているソフトウェア**のインストール及び利用（利用を禁止するソフトウェアを定める場合）

d) 許可されない通信回線サービスの利用（利用する回線を限定する場合）

e) 第三者への端末の貸与

f) 利用承認を得ていないクラウドサービス等への端末内の要機密情報のバックアップ

g) 機密性３情報の取扱い

6.1.3(2)-5 統括情報セキュリティ責任者は、職員等が機関等支給以外の端末を用いて要保護情報を取り扱う場合について、以下を全て含む許可手続を実施手順として定めること。

a) 利用時の許可申請手続

b) 手続内容（利用者、利用期間、主たる利用場所、目的、利用する情報、端末、通信回線への接続形態等）

c) 利用期間満了時の手続

d) 許可権限者（課室情報セキュリティ責任者）による手続内容の記録

＜6.1.3(2)(c)関連＞

6.1.3(2)-6 統括情報セキュリティ責任者は、要機密情報を取り扱う機関等支給以外の端末について、以下を例に、利用者が端末に情報を保存できないようにするための機能又は端末に保存される情報を**暗号化**するための対策の検討のほか、端末で機密性３情報を取り扱うことができない対策についても検討し、要機密情報を取り扱う機関等支給以外の端末に求める安全管理措置に関する運用規程のうちの技術的な措置として加えること。

なお、可能な限り端末に情報を保存させない機能を設けることも運用規程に含めること。

a) **シンクライアント等**の仮想デスクトップ技術を活用した、端末に情報を保存させないリモートアクセス環境を構築し、利用者は専用のシンクライアントアプリケーションを利用端末にインストールし、業務用システムへリモートアクセスすること。

b) **セキュアブラウザ等**を活用した、端末に情報を保存させないリモートアクセス環境を構築し、利用者はセキュアブラウザを利用端末にインストールし、業務用システムへリモートアクセスすること。

c) **ファイル暗号化等のセキュリティ機能を持つアプリケーション**を導入すること。

d) 端末に、**ハードディスク等の電磁的記録媒体全体を自動的に暗号化する機能**を設けること。

e) 上記の各号のいずれの機能も使用できない場合は、端末に**ファイルを暗号化する機能を設ける**こと。

f) ハードディスク等の電磁的記録媒体に保存されている情報を**遠隔からの命令等により暗号化消去する機能**を設けること。

g) **高度なセキュリティ機能を備えたOSを搭載するスマートフォンやタブレット端末等**を使用すること。

＜6.1.3(2)(d)関連＞

6.1.3(2)-7 統括情報セキュリティ責任者は、要管理対策区域外において機関等外通信回線に接続した機関等支給以外の端末を要管理対策区域で機関等内通信回線に接続することの許可手続として、以下を全て含む手続を実施手順として整備し、職員等に遵守させること。

a) 利用時の許可申請手続

b) 手続内容（利用者、目的、利用する情報、端末等）

c) 利用期間満了時の手続

d) 機関等内通信回線への接続時の手続（端末の事前検疫等）

e) 許可権限者（課室情報セキュリティ責任者）による手続内容の記録

（解説）

許可等の手続を定める際には、機関等支給以外の端末を用いて業務を行うことの脅威を把握し、十分なリスク評価を行った上で許可等の手続を定めるとよい。特に機関等支給以外の端末で要保護情報を取り扱うなど重要な業務に使用する場合は、利用する端末の種類や利用場所、利用する通信回線などを把握し、情報セキュリティインシデントが発生しないような使い方を遵守させることが重要である。また、機関等支給以外の端末を利用する職員等に対しても、どのような脅威が起こり得るかを理解させた上で、十分な管理を行うことを遵守させるとよい。

機関等支給以外の端末としてスマートフォンを利用する場合は、以下を参考にするとよい。

参考：総務省「スマートフォンを安心して利用するために実施されるべき方策」（スマートフォン・クラウドセキュリティ研究会最終報告） （https://www.soumu.go.jp/menu_news/s-news/01ryutsu03_02000020.html）

要機密情報を取り扱う機関等支給以外の端末とは、機関等支給以外のモバイル端末と職員等の自宅で業務を行う際に用いる機関等支給以外の据え置き型端末が該当する。

「（解説）遵守事項6.1.2(1)(c)「機関等内通信回線に接続することについての可否を判断」について」を参照のこと。

機関等支給以外の端末は、日常的に職員等が業務以外の目的で利用していると考えられる。したがって、日常的にインターネット等に直接接続していると考え、機関等内通信回線に接続を行う場合には、利用可能な情報セキュリティ対策等を総合的に勘案の上、職員等に適切に対策を講じさせる必要がある。例えば、機関等内通信回線に接続する前に不正プログラム対策ソフトウェアを用いて検査を行わせることや利用を禁止しているソフトウェアがインストールされていないことを確認させるなどが考えられる。

契約者の名義の提示を求めるのは、業務に使用する端末の名義人と使用人の一致を確認するためである。端末の名義人が端末の利用に係る契約者であり、業務への使用や通信費用に係る訴訟リスクを回避するためには、利用申請時に使用人と名義人が一致していることを確認する必要がある。

なお、名義人と使用人である申請者が同一であることを利用条件とする場合は、名義人の確認を求める必要はない。

職員等が利用する機関等支給以外の端末についても、機関等が支給する端末を調達する際と同等の情報セキュリティ水準でサプライチェーン・リスクに対応することが適当である。

機関等支給以外の端末について、製造企業名、機種名を把握し、「IT調達に係る国等の物品又は役務の調達方針及び調達手続に関する申合せ」（関係省庁申合せ　内閣官房国家サイバー統括室）の趣旨を踏まえた対応として、内閣官房国家サイバー統括室に助言を求める。また、スマートフォンのAndroid OSのように製造企業によってカスタマイズされたOSがある場合や様々なバージョンが利用されている場合、機関等が許可できるOS、バージョンであるか、利用する情報システムの情報セキュリティ対策が対応できる端末であるかを判断する。

機関等支給以外の端末を利用する際に、利用の都度申請手続を行うと事務処理が煩雑化する可能性があるため、例えば１年間の利用期間を定め、包括的な許可を与えるなどして事務処理を効率化する方法も考えられる。この場合は、安全管理措置の実施状況について定期的なチェックを行うなどの対応が求められる。

職員等に機関等支給以外の端末の利用を許可するに当たり、以下の内容を例とした利用許諾条件を示し、許諾書にサインするなどして利用者の同意を証拠として残す必要がある。

機関等支給以外の端末の利用の許可申請においては、許可権限者である端末管理責任者の許可を得ることになるが、必要に応じて取り扱う情報の管理責任を持つ課室情報セキュリティ責任者の許可（遵守事項8.1.1(4)(b)で規定）を同時に得る手続を定めるとよい。

「（解説）基本対策事項6.1.2(1)-1 c)「盗難・紛失に対する対策」について」を参照のこと。

盗難、紛失時の情報窃取を防止するために、適切な方法でパスワード等により端末をロックすることが重要である。適切でない方法による端末ロックの例としては、強固でないパスワードを設定した場合が挙げられる。このような場合、端末を窃取した者により端末ロックを解除される危険性があり、端末ロックが解除されると、基本対策事項6.1.3(2)-6の措置が効力を失う（暗号化している情報が自動的に復号されてしまう、リモートアクセス環境にアクセスされてしまうなど）可能性があるため、情報窃取の被害につながる。

強固なパスワードの設定方法については、「（解説）基本対策事項7.1.1(1)-4「強固なパスワードに必要な十分な桁数を備えた第三者に容易に推測できないパスフレーズ等を使用すること」について」を参照のこと。なお、端末ロックの機能が、主体認証の失敗した回数をカウントして一定数を超えた際に暗号化消去する機能を備えている場合には、数字のみからなるPIN（Personal Identification Number）コードを主体認証情報として用いてもよい。ただし、例えば6桁以上とするなどの一定の長さを要件とする必要がある。

脆弱性対策のため、OSや業務利用するアプリケーションを最新化する必要がある。私的利用するアプリケーションについても最新化することが望ましいが、基本対策事項6.1.3(2)-6で講ずる技術的な措置等を踏まえ、私的利用するアプリケーションが最新化されていないことによるリスクを評価した上で判断するとよい。

携帯電話や一部のスマートフォンなど、不正プログラム対策ソフトウェアが有効な役割を果たさないと考えられている端末やOSにおいて、不正プログラム対策ソフトウェアが提供されていない場合（「（解説）遵守事項7.2.2(1)(a)「不正プログラム対策ソフトウェア等を導入する」について」を参照のこと。）には、事前に安全性が確認されたアプリケーションしかインストールしないようにするなどの別の方法で安全性を確保する必要がある。

iOSにおけるJailbreakやAndroidにおけるroot化のように、ソフトウェア等の改造が行われた端末は外部からの攻撃の的となりやすく、不正パケットの受信によって不正プログラムに感染し、端末が乗っ取られるなどの危険性が高くなる。

このような改造された端末が業務に使用されると、端末に保存された情報が漏えいするなどの情報セキュリティインシデントが発生する可能性があるため、機関等支給以外の端末を利用する際は、事前に端末、OS、アプリケーション等の改造行為を行わないことについて、職員等と事前に同意することが重要である。

モバイル端末を業務利用することを目的とした、MDMツール等を機関等のリモートアクセス環境と組み合わせ、改造された端末を検知するなどして、システム的に改造端末の使用を回避する方法も考えられる。

スマートフォンにおいては、専用のアプリケーション提供サイト等からオンデマンドでアプリケーションをダウンロードする利用形態が一般的であるが、不正プログラム等が混在する提供サイトの存在が懸念されるため、業務に利用する機関等支給以外のスマートフォン等においては安全性が不明なアプリケーションがインストールされた状態で利用されることがないように、例えばOS提供事業者や通信事業者等がアプリケーションの安全性の審査を行っている信頼性の高いアプリケーション提供サイトにて提供されるアプリケーションのみに利用を限定すること等を対策にするとよい。ただし、大手の事業者であっても安全なアプリケーションを提供しているとは限らないので、提供サイトを運営する事業者のセキュリティ対策水準を十分見極めた上で判断することが求められる。

スマートフォンを安全に利用するための留意事項として、OSの最新化及び不正プログラム対策とともに注意喚起されているので、参考にすること。

参考：総務省「スマートフォン情報セキュリティ３カ条」（スマートフォン・クラウドセキュリティ研究会最終報告） （https://www.soumu.go.jp/main_content/000166095.pdf）

遵守事項6.1.1(1)(b)の対策として、機関等支給の端末において規定される利用を認めたソフトウェアを参考に利用を禁止するソフトウェアを検討することが考えられるが、例えば私的な利用の範囲を必要以上に制限しないよう考慮する必要がある。

ホテル等の施設や街中で提供される公衆無線LANサービスでは多数のユーザが容易に接続できることの利便性のため暗号化されていないことや、PSK（Pre-Shared Key/事前共有鍵）による認証方式が使用されていることがあるが、そのような状況では通信内容の盗聴や改ざん、アクセスポイントのなりすましによる情報の窃取等のおそれがあるため、業務に利用すべきではない。また、同様に有線によるインターネット接続が提供されている場合であっても接続経路や管理状況が不明である場合は業務に利用すべきではない。ただし、国外等での利用も含め、情報セキュリティ水準が不明な通信回線サービスを利用せざるを得ない場合が想定されることから、例えば、情報システムへのリモートアクセス経路においてVPN回線を設定しend-endの秘匿性を確保するなどの方法を用いるとよい。

なお、無線LANの利用については、総務省が公表している以下のガイドラインを参考にするとよい。

参考：総務省「公衆Wi-Fi利用者向け 簡易マニュアル」 （https://www.soumu.go.jp/main_sosiki/cybersecurity/wi-fi/）

家族や知人に私物の端末等を貸与することがあるが、その際に意図的に機密性の高い情報を閲覧したり又は誤操作により機密性の高い情報を外部に転送してしまったりすることが懸念される。

私物端末であっても業務に利用するのであれば、第三者への貸与は禁止すべきであり、それに同意できない職員等には私物端末を利用させるべきではない。

本規定はシャドーITの抑止を目的としたものである。

なお、クラウドサービス自体の利用承認を得ている場合であっても、職員等の私的なアカウントを用いて機関等支給以外の端末に格納された要機密情報のバックアップを取得させてはならない。

「（解説）基本対策事項6.1.2(1)-2 c)「利用期間満了時の手続」について」を参照のこと。

「（解説）基本対策事項6.1.2(1)-3「暗号化」について」を参照のこと。

「（解説）基本対策事項6.1.2(1)-3 a)「シンクライアント等」について」を参照のこと。

「（解説）基本対策事項6.1.2(1)-3 b)「セキュアブラウザ等」について」を参照のこと。

「（解説）基本対策事項6.1.2(1)-3 c)「ファイル暗号化等のセキュリティ機能を持つアプリケーション」について」を参照のこと。

「（解説）基本対策事項6.1.2(1)-3 d)「ハードディスク等の電磁的記録媒体全体を自動的に暗号化する機能」について」を参照のこと。

「（解説）基本対策事項6.1.2(1)-3 e)「ファイルを暗号化する機能を設ける」について」を参照のこと。

「（解説）基本対策事項6.1.2(1)-3 f)「遠隔からの命令等により暗号化消去する機能」について」を参照のこと。

「（解説）基本対策事項6.1.2(1)-3 g)「高度なセキュリティ機能を備えたOSを搭載するスマートフォンやタブレット端末等」について」を参照のこと。

遵守事項

(3) 機関等支給以外の端末の利用に関する責任者の策定

(a) 情報セキュリティ責任者は、機関等支給以外の端末を用いた機関等の業務に係る情報処理に関する**安全管理措置の実施状況を管理する責任者**（以下「端末管理責任者」という。）を定めること。

【 基本対策事項 】規定なし

（解説）

機関等支給以外の端末を職員等が利用するに当たって、申請時に安全管理措置の実施状況について端末を目視確認する方法や、定期的な実施状況の確認を管理者にて行うことをあらかじめ定めておく方法等、安全管理措置の確実な実施に資する実効性のある取組を行う必要がある。

機関等支給以外の端末の安全管理措置の実施状況を管理する責任者であり、PCやスマートフォン等に対して一定以上の知見を有している者がその任に当たることが望ましい。例えば、機関等LANシステムの情報セキュリティ責任者等が考えられる。ただし、職員等の安全管理措置の実施状況について適時状況を把握することが求められるため、課室情報セキュリティ責任者が兼ねることも考えられる。

遵守事項

(4) 機関等支給以外の端末の利用時の対策

(a) 職員等は、機関等支給以外の端末を用いて機関等の業務に係る情報処理を行う場合には、端末管理責任者の許可を得ること。

(b) 職員等は、機関等支給以外の端末を用いて要保護情報を取り扱う場合は、(2)(b)で定める**利用手順に従う**こと。

(c) **端末管理責任者等は、要機密情報を取り扱う機関等支給以外の端末について、(2)(c)に定める安全管理措置を講じる又は職員等に講じさせる**こと。

(d) 職員等は、情報処理の目的を完了した場合は、**要保護情報を機関等支給以外の端末から消去する**こと。

【 基本対策事項 】規定なし

（解説）

職員等は、機関等支給以外の端末の利用に係る機関等全体のポリシーをよく理解し、安全管理措置を徹底し、また、利用手順に従い、情報セキュリティインシデントの回避に努めなければならない。特にスマートフォン等の利用については、その特性に応じたリスクを利用者である職員等自身もよく理解した上で利用することが求められる。

遵守事項6.1.3(2)(c)に定める安全管理措置のうち、機関等支給以外の端末から機関等LANシステム等の情報システムにアクセスさせる場合、当該情報システムの情報システムセキュリティ責任者が、機関等支給以外の端末に対する安全管理措置と併せて、当該情報システム側で対応すべき措置を講ずることも考えられる。

例えば、基本対策事項6.1.3(2)-6 a)の規定を参考とし、シンクライアントを用いた機関等LANシステムへのリモートアクセス環境を構築する場合は、端末に専用のシンクライアントアプリケーションをインストールすることに加え、サーバ装置に仮想マシンを構築することが考えられる。この場合は、機関等支給以外の端末から利用される機関等LANシステムに知見を有している、機関等LANシステムを管理する情報システムセキュリティ責任者が機関等支給以外の端末に対して本項を行うことが適切とも考えられる。

基本対策事項6.1.3(2)-6の安全管理措置のうち、職員等が講ずることが適当な項目としては、例えばOSの機能を利用する6.1.3(2)-6 d)の「ハードディスク等の電磁的記録媒体全体を自動的に暗号化する機能」や6.1.3(2)-6 e)の「ファイルを暗号化する機能」が考えられる。

要保護情報を消去することは必須であるが、不必要な情報及び業務用のアプリケーション等についても併せて消去することが望ましい。

6.2 サーバ装置

6.2.1 サーバ装置

目的・趣旨

電子メールサーバやウェブサーバ、ファイルサーバ等の各種サーバ装置には、大量の情報が保存されている場合が多く、当該情報の漏えいや改ざんによる影響も端末と比較して大きなものとなる。また、サーバ装置は、通信回線等を介してその機能が利用される場合が多く、不正プログラム感染や不正侵入を受けるなどの可能性が高い。仮に機関等が利用するサーバ装置が不正アクセスや迷惑メールの送信の中継地点に利用されるようなことになれば、国民からの信頼を大きく損なう。加えて、サーバ装置は、同時に多くの者が利用するため、その機能が停止した場合に与える影響が大きい。これらのことを考慮して、対策を講ずる必要がある。

なお、本款の遵守事項のほか、7.1「情報システムのセキュリティ機能」において定める主体認証・アクセス制御・権限管理・ログ管理・監視機能等の機能面での対策、7.2.1「ソフトウェアに関する脆弱性対策」、7.2.2「不正プログラム対策」、7.2.3「サービス不能攻撃対策」、6.4.4「IPv6通信回線」において定める遵守事項のうちサーバ装置に関係するものについても遵守する必要がある。さらに、機関等外通信回線を経由してサーバ装置の保守作業等を行う場合は、6.4.1「通信回線」のリモートメンテナンスについての対策も遵守する必要がある。また、特に電子メールサーバ、ウェブサーバ、DNSサーバ及びデータベースについては、本款での共通的な対策に加え、それぞれ本節において定める遵守事項についても併せて遵守する必要がある。

遵守事項

(1) サーバ装置の導入時の対策

(a) 情報システムセキュリティ責任者は、要保護情報を取り扱う物理的なサーバ装置について、サーバ装置の盗難、不正な持ち出し、不正な操作、表示用デバイスの盗み見等の物理的な脅威から保護するための対策を講ずること。

(b) 情報システムセキュリティ責任者は、障害や過度のアクセス等によりサービスが提供できない事態となることを防ぐため、要安定情報を取り扱う情報システムについて、サービス提供に必要なサーバ装置を冗長構成にするなどにより可用性を確保すること。

(c) 情報システムセキュリティ責任者は、多様なソフトウェアを利用することにより脆弱性が存在する可能性が増大することを防止するため、サーバ装置で**利用を認めるソフトウェアを定め、それ以外のソフトウェアは利用させない**こと。

(d) 情報システムセキュリティ責任者は、サーバ装置に**接続を認めた機器等を定め、接続を認めた機器等以外は接続させない**こと。

(e) 情報システムセキュリティ責任者は、情報システムのセキュリティ要件として策定した内容に従い、サーバ装置に対して**適切なセキュリティ対策を実施する**こと。

(f) 情報システムセキュリティ責任者は、サーバ装置において利用する**ソフトウェアに関連する公開された脆弱性について対策を実施する**こと。

(g) 情報システムセキュリティ責任者は、要安定情報を取り扱うサーバ装置については、**適切な方法でサーバ装置のバックアップを取得する**こと。

【 基本対策事項 】

＜6.2.1(1)(a)関連＞

6.2.1(1)-1 情報システムセキュリティ責任者は、要保護情報を取り扱う物理的なサーバ装置については、**クラス２以上の要管理対策区域に設置する**こと。

6.2.1(1)-2 情報システムセキュリティ責任者は、物理的なサーバ装置の盗難及び不正な持ち出しを防止するために、以下を例とする対策を講ずること。

a) 施錠可能なサーバラックに設置して施錠すること。

b) 容易に切断できないセキュリティワイヤを用いて、固定物又は搬出が困難な物体に固定すること。

6.2.1(1)-3 情報システムセキュリティ責任者は、第三者による不正操作及び表示用デバイスの盗み見を防止するために、以下を例とする対策を講ずること。

a) 一定時間操作が無いと自動的にスクリーンロックするよう設定すること。

＜6.2.1(1)(b)関連＞

6.2.1(1)-4 情報システムセキュリティ責任者は、障害や過度のアクセス等によりサービスが提供できない事態となることを防ぐため、要安定情報を取り扱う情報システム及び非常時優先業務等を支える情報システムについては、将来の見通しも考慮し、以下を例とする対策を講ずること。

a) 負荷分散装置、DNSラウンドロビン方式等による負荷分散

b) 同一システムを２系統で構成することによる**冗長化**

＜6.2.1(1)(c)関連＞

6.2.1(1)-5 情報システムセキュリティ責任者は、以下を全て考慮した上で、**利用を認めるソフトウェアをバージョンも含め定める**こと。

a) ソフトウェアベンダ等のサポート状況

b) ソフトウェアと外部との通信の有無及び通信する場合は、プロトコル（バージョンを含む。）、使用するポート、暗号化の有無

c) インストール時に同時にインストールされる他のソフトウェア

d) その他、ソフトウェアの利用に伴う情報セキュリティリスク

（解説）

「（解説）遵守事項6.1.1(1)(b)「利用を認めるソフトウェアを定め、それ以外のソフトウェアは利用させない」について」を参照のこと。

「（解説）遵守事項6.1.1(1)(c)「接続を認める機器等を定め、接続を認めた機器等以外は接続させない」について」を参照のこと。

端末を導入する際と同様に、サーバ装置を導入する際も、セキュリティ要件に従って適切なセキュリティ対策を実施する必要がある。例えば、主体認証方式やアクセス制御等の情報セキュリティ機能が正しく実装されていることや脆弱性対策、サーバ装置において要安定情報を取り扱う場合及び非常時優先業務等を支える情報システムを運用する場合はサービス不能攻撃対策等を実施する必要がある。また、不要なポートが開放されていない、不要なサービスが起動していないなどの対策も重要である。

「（解説）遵守事項6.1.1(1)(e)「ソフトウェアに関連する公開された脆弱性について対策を実施する」について」を参照のこと。

要安定情報を取り扱うサーバ装置については、情報システムにおけるRTO（目標復旧時間）、RLO（目標復旧レベル）等を踏まえて、適切な方法でバックアップを取得する必要がある。そのバックアップの方法については、OSやアプリケーションなどを含むサーバ装置全体をバックアップする方法やサーバ装置の複製をバックアップとして用意する方法などが存在する。

また、バックアップを取得する際は、バックアップの世代管理、保存場所や媒体についても考慮する必要がある。バックアップの取得については、「（解説）基本対策事項5.2.3(1)-7 a)「適切なバックアップの取得及びバックアップ要件の確認による見直し」について」を参照のこと。

サーバ装置に関しては、取り扱う情報の重要性に応じて原則としてクラス３の区域に設置する。また、クラス２の区域（執務室等）に設置する場合においては、原則として常時施錠されたサーバラックに置くことが重要である。

「冗長化」とは、障害や過度のアクセスが発生した場合を想定し、サービスを提供するサーバ装置を代替サーバ装置に切り替えること等により、サービスが中断しないように、情報システムを構成することである。可用性を高めるためには、サーバ装置本体だけでなく、ハードディスク等のコンポーネント単位で冗長化することも考えられる。

なお、災害等を想定して冗長化する場合には、代替のサーバ装置を遠隔地に設置することが望ましい。

「（解説）基本対策事項6.1.1(1)-4「利用を認めるソフトウェアをバージョンも含め定める」について」を参照のこと。

遵守事項

(2) サーバ装置の運用時の対策

(a) 情報システムセキュリティ責任者は、利用を認めるソフトウェアについて、定期的な確認による**見直しを行う**こと。

(b) 情報システムセキュリティ責任者は、所管する範囲のサーバ装置の構成やソフトウェアの状態を定期的に確認し、**不適切な状態にあるサーバ装置を検出等した場合には改善を図る**こと。

(c) 情報システムセキュリティ責任者は、サーバ装置上での情報セキュリティインシデントの発生を監視するため、当該サーバ装置を監視するための措置を講ずること。

(d) 情報システムセキュリティ責任者は、要安定情報を取り扱うサーバ装置について、危機的事象発生時に適切な対処が行えるよう運用をすること。

【 基本対策事項 】

＜6.2.1(2)(b)関連＞

6.2.1(2)-1 情報システムセキュリティ責任者は、所管する範囲のサーバ装置の構成やソフトウェアの状態を定期的に確認し、改善を図る場合は、作業日、作業を行ったサーバ装置名、具体的な作業内容（サーバ装置の構成等の変更、脆弱性管理、ソフトウェアのインストール等）及び作業者、正常動作を確認した者などを含む変更事項等を記録し、管理すること。

＜6.2.1(2)(c)関連＞

6.2.1(2)-2 情報システムセキュリティ責任者は、サーバ装置への不正アクセス等の情報セキュリティインシデントの発生を監視するために、以下を例とする対策を講ずること。

a) **アクセスログ等を定期的に確認する**こと。

b) IDS/IPS、WAF等を設置すること。

c) **不正プログラム対策ソフトウェア**を利用すること。

d) ファイル完全性チェックツールを利用すること。

e) CPU、メモリ、ディスクI/O等のシステム状態を確認すること。

f) **ホスト型のIDS/IPS**を利用すること。

g) ユーザ、グループ、システム管理者の追加、変更の有無を確認すること。

h) 管理者、ユーザのパスワード漏えいの有無、大量のログオン失敗や、通常とは異なる時間帯やアクセス元IPアドレスからのログインがないか確認すること。

＜6.2.1(2)(d)関連＞

6.2.1(2)-3 情報システムセキュリティ責任者は、要安定情報を取り扱うサーバ装置及び非常時優先業務等を支える情報システムを運用するサーバ装置について、以下を全て含む運用をすること。

a) サーバ装置全体の**適切なバックアップの取得及びバックアップ要件の確認による見直し**

b) サーバ装置の構成やソフトウェア等の設定の変更が行われた際及び定期的に、サーバ装置が停止した際の復旧手順の確認による見直し

（解説）

ソフトウェアのバージョン更新、サポート期限切れ、新しいソフトウェアの出現等に適切に対応するため、定期的に利用を認めるソフトウェアの確認による見直しを行う必要がある。見直しを行うに当たっては、利用を認めるソフトウェアの必要性や利用を認めることによる脅威へのリスク等を踏まえた上で見直しを行う必要がある。特に管理者権限を必要とするソフトウェアや他のソフトウェアを含む機器等の管理や制御を行うソフトウェアの利用を認める場合は、追加のセキュリティ対策を実施させるなど、ソフトウェアを利用することによる脅威へのリスクを低減することが重要である。

「不適切な状態」とは、例えば以下の状態のことをいう。

利用を認めるソフトウェア以外のソフトウェアがインストールされているか否かについては、構成管理ツールを使用するほか、プロセスやその他挙動等を監視する方法もある。また、利用を認めるソフトウェアであっても、利用しない機能については無効化するなどの措置が考えられる。セキュリティパッチについては、7.2.1「ソフトウェアに関する脆弱性対策」を参照のこと。

不正アクセスを検知するために、サーバ装置へのアクセスに関するログのほか、サーバ装置が異常等を検出した際に出力するログ（エラーログ）を確認することも有効である。

アクセスログを確認する際は、運用管理作業の記録、管理者権限を持つ識別コードによるアクセスを検知した場合の通知等の確認により、不正なアクセスが行われた可能性を確認することも考えられる。

不正プログラム対策ソフトウェアについては、既知及び未知の不正プログラムの検知及びその実行の防止の機能を有するソフトウェアが考えられるが、具体的にはEPP（Endpoint Protection Platform）と呼ばれる製品のうち「アンチウイルス（AV）」や「次世代アンチウイルス（NGAV）」が挙げられる。そのような製品のうちNGAVについては、不正プログラムの検知方法として、シグネチャにより検出するものに加え、機械学習や振舞い検知といった技術を用いた製品もある。これによって既知の不正プログラムだけではなく、未知の不正プログラムへの対応も可能となる。

さらにEPPと組み合わせて、侵入した不正プログラムを検知する機能を持つEDR製品を用いると、より効果的である。EDRには、リアルタイムでエンドポイントを監視することが可能な製品もあり、EPPで検知できなかった不正プログラム等が被害を拡大させる前に対策をすることが可能となる。

したがって、不正プログラム対策ソフトウェアを利用する場合は、情報システムで取り扱う情報や業務として行う内容等を踏まえて、必要なセキュリティ対策を検討した上で導入する製品等を選定することが望ましい。

ホスト型のIDS/IPSは、ネットワーク型のIDS/IPSとは異なりサーバ装置に直接導入し利用することで、対象のサーバ装置で発生したイベントを監視することが可能となる。また、製品によっては不正アクセスに関する監視のみならず、操作ミスやアプリケーションで発生したエラー、ファイルやレジストリの改ざんを検知する機能を有するものも存在する。

「（解説）基本対策事項5.2.3(1)-7 a)「適切なバックアップの取得及びバックアップ要件の確認による見直し」について」を参照のこと。

「（解説）基本対策事項5.2.3(1)-7 b)「情報システムが停止した際の復旧手順の確認による見直し」について」を参照のこと。

遵守事項

(3) サーバ装置の運用終了時の対策

(a) 情報システムセキュリティ責任者は、**サーバ装置の運用を終了する際に、サーバ装置の電磁的記録媒体の全ての情報を抹消する**こと。

【 基本対策事項 】規定なし

（解説）

サーバ装置を廃棄処分する場合やリース契約が終了し返却する場合のほか、当該サーバ装置のサービス又は機能の提供を終了する場合も考えられる。

サーバ装置の電磁的記録媒体の全ての情報を抹消する場合、サーバ装置で取り扱っていた情報だけでなくOS領域も含めて全て抹消する必要があることに注意が必要である。

抹消の方法については、「（解説）遵守事項3.1.1(7)(b)「抹消する」について」及び「（解説）遵守事項6.1.1(3)(a)「抹消する」について」を参照のこと。

6.2.2 電子メール

目的・趣旨

電子メールの送受信とは情報のやり取りにほかならないため、不適切な利用により情報が漏えいするなどの機密性に対するリスクの他、悪意ある第三者等によるなりすまし等、電子メールが悪用される不正な行為の被害に電子メールを利用する職員等が巻き込まれるリスクもある。これらの問題を回避するためには、適切な電子メールサーバの管理が必要である。

なお、本款の遵守事項のほか、6.2.1「サーバ装置」において定めるサーバ装置に係る遵守事項についても併せて遵守する必要がある。

遵守事項

(1) 電子メールの導入時の対策

(a) 情報システムセキュリティ責任者は、電子メールサーバが電子メールの**不正な中継**を行わないように設定すること。

(b) 情報システムセキュリティ責任者は、電子メールクライアントから電子メールサーバへの電子メールの受信時及び送信時に主体認証を行う機能を備えること。

(c) 情報システムセキュリティ責任者は、電子メールのなりすましの防止策を講ずること。

(d) 情報システムセキュリティ責任者は、インターネットを介して通信する電子メールの盗聴及び改ざんの防止のため、電子メールの**サーバ間通信の暗号化**の対策を講ずること。

【 基本対策事項 】

＜6.2.2(1)(a)関連＞

6.2.2(1)-1 情報システムセキュリティ責任者は、電子メールサーバが電子メールの不正な中継を行わないように以下を例とする設定をすること。

a) 送信元の電子メールサーバのIPアドレスによって中継を制限する設定

b) 送信元のメールアドレスのドメイン名によって中継を制限する設定

c) 宛先のメールアドレスのドメイン名によって中継を制限する設定

＜6.2.2(1)(b)関連＞

6.2.2(1)-2 情報システムセキュリティ責任者は、電子メールクライアントから電子メールサーバへの電子メールの受信時及び送信時に、以下を例とする職員等の主体認証を行う機能を備えること。

a) 電子メールの受信時に限らず、送信時においても不正な利用を排除するためにSMTP認証等の主体認証機能を導入すること。

＜6.2.2(1)(c)関連＞

6.2.2(1)-3 情報システムセキュリティ責任者は、以下を全て含む**送信ドメイン認証技術**による電子メールのなりすましの防止策を講ずること。

a) DMARCによる送信側の対策を行うこと。DMARCによる送信側の対策を行うためには、SPF、**DKIMのいずれか又は両方による対策を行う必要**がある。

b) DMARCによる**受信側の対策を行うこと。DMARCによる受信側の対策を行うためには、SPF、DKIMの両方による対策を行う必要**がある。

c) DMARCポリシーには、“p=quarantine”又は“p=reject”を設定すること。やむをえず、”p=none”を設定する場合も設定期間が可能な限り短くなるようにする必要がある。

6.2.2(1)-4 情報システムセキュリティ責任者は、**必要に応じて、S/MIME等の電子メールにおける電子署名**の技術による電子メールのなりすましの防止策を講ずること。

6.2.2(1)-5 情報システムセキュリティ責任者は、職員等が機関等外の者と電子メールを送受信する場合には、**政府ドメイン名を取得できない場合を除き、政府ドメイン名を使用した電子メールアドレスが利用される機能**を備えること。

＜6.2.2(1)(d)関連＞

6.2.2(1)-6 情報システムセキュリティ責任者は、以下を例とする電子メールの盗聴及び改ざんの防止策を講ずること。

a) **SMTPによるサーバ間通信をTLSにより保護**すること。

b) **S/MIME等の電子メールにおける暗号化及び電子署名**の技術を利用すること。

（解説）

不正な中継が行われると、迷惑メールの送信等に悪用される問題がある。電子メールの不正な中継に起因し生じるおそれのある事象として、以下が考えられる。

悪用を回避するため、電子メールの不正な中継を行わないように、中継を許可する電子メールを必要最小限とする設定を電子メールサーバに行う必要がある。

特に、電子メールサーバ間で送受信する電子メールを中継するメール中継サーバが設置される場合、電子メールの不正な中継を行わない設定をメール中継サーバで必ず実施し、IPアドレスによる制限等の対策をファイアウォールによる通信制限のみに依存しないよう留意が必要である。

なお、当該設定においては、多重防御の考えに基づき、メール中継サーバを含む全ての電子メールサーバにおいて実施するとともに、設定が可能な範囲で複数の設定を行う必要がある。

さらに、送信元のメールがなりすまされていないか検証する必要がある場合には、電子メールの中継を行う電子メールサーバにおいて、電子メールのなりすまし防止対策を講ずることも考えられる。

相手先サーバが暗号化に対応していない状況も考慮しなければならない。自らが送信側となる際には、相手先が暗号化に対応可能であることを確認し、確認が取れた場合には以降の通信を暗号化することが求められる。また、自らが受信側となる際には、相手先からの接続要求時に暗号化の機能に対応していることを示すことが求められる。

暗号化された通信の監視については、「（解説）遵守事項5.2.1(3)(a)(イ)「監視するデータが暗号化されている場合は、必要に応じて復号」について」を参照のこと。

また、電子メールクライアントと電子メールサーバ間の通信の暗号化についても併せて対応することが望ましい。

送信ドメイン認証技術の導入に当たっては、技術的な解説や導入の手順などを詳細に解説した、迷惑メール対策推進協議会による「送信ドメイン認証技術導入マニュアル」を参考にするとよい。

参考：迷惑メール対策推進協議会「送信ドメイン認証技術導入マニュアル　第3.1版」 （https://www.dekyo.or.jp/soudan/aspc/report.html#dam）

総務省による「送信ドメイン認証技術等の導入に関する法的解釈について」において、送信ドメイン認証技術の導入に当たり、電気通信事業法における法的な整理を示しており、この範囲内で実施することが可能となっている。なお、職員等が利用する電子メールシステムに機関等が送信ドメイン認証技術を導入する際には、「送信ドメイン認証技術等の導入に関する法的解釈について」は、必ずしも留意する必要はない。

参考：総務省「送信ドメイン認証技術等の導入に関する法的解釈について」 （https://www.soumu.go.jp/main_sosiki/joho_tsusin/d_syohi/m_mail/legal.html）

DMARCは、認証の基本的な技術はSPFやDKIMを利用しており、SPFやDKIMで認証されたドメイン名と、メールヘッダ上の送信ドメイン名が一致した場合に、なりすまされていないものと判断する。また、電子メールの受信側においてSPF、DKIMの送信ドメイン認証が失敗したときの処理を送信側が指定できる。例えば、受信側で認証が失敗したときは受信を拒否させるといった処理を送信側が指定できる。さらに、認証結果を電子メールの送信側にDMARCレポートとしてフィードバックする機能を備えている。例えば、機関等になりすましたメールが送信されている状況や、受信側におけるSPF、DKIMの認証が成功あるいは失敗している状況をDMARCレポートの内容から分析することができる。

送信側の対策を行うことによって、送信側である機関等が送信した電子メールが詐称されているかどうかを受信側において確認することが可能となる。

送信ドメイン認証技術を使用した送信側の対策として、電子メールで使用するドメインを管理するDNSサーバに、受信者が電子メールの正当性を確認するための情報を登録し公開する必要がある。なお、DNSキャッシュポイズニング攻撃等によりDNSレコードを偽の情報に書き換えられる可能性があるため、DNSサーバに対してDNSSECを導入することが望ましい。

また、電子メールの送信に使用するドメイン名だけではなく、WebサイトのURL等、機関等の使用するあらゆるドメイン名に対しても、受信者が電子メールの正当性を確認するための情報を登録し公開することが重要である。

SPFはネットワーク方式の送信ドメイン認証技術である。

SPFの送信側の対策としては、送信側の電子メールサーバの情報をDNSサーバに登録する必要がある。登録の際は以下の事項に留意が必要である。

DKIMは電子署名方式の送信ドメイン認証技術である。

DKIMの送信側の対策としては、電子メールに付与する電子署名の検証に使用する公開鍵をDNSサーバに登録する必要がある。

SPF、DKIMはどちらも、電子メールが詐称されているかどうかをドメイン名単位で受信側が確認することが可能な技術であるが、DKIMはそれに加えて、電子メールが改ざんされていないことを受信側が検証することが可能となる。

また、電子メールの転送においては、SPFの場合、受信した電子メールのエンベロープFromのドメイン名から取得したSPFレコードに設定されているIPアドレスと、電子メールを転送したサーバのIPアドレスが異なるため、SPFの認証が失敗する。しかし、電子メールの最初の送信者がDKIM署名を付与する場合は、電子メールのヘッダや本文が改変されていなければDKIMの認証が成功する。そのため、電子メールの転送における送信側の対策を講ずる際はDKIMを検討するとよい。

さらに、メーリングリストにおいては、SPFの場合、SPFの認証が成功したとしても、SPFで認証されたドメイン名とDMARCで認証に用いるメールヘッダ上の送信ドメイン名が一致しないため、DMARCの認証は失敗する。しかし、DKIMの場合は、メーリングリスト側でメーリングリストのドメイン名でのDKIM再署名とメールヘッダ上の送信ドメイン名の変更等を行うことで、DMARCの認証が成功する。そのため、メーリングリストの転送における送信側の対策を講ずる際はDKIMを検討するとよい。

電子メールの受信側がSPF、DKIMいずれかのみを導入している可能性があるため、送信側である機関等としてはSPF、DKIMの両方を導入することが望ましい。

SPF、DKIMのいずれかのみを導入する場合は、「（解説）基本対策事項6.2.2(1)-3 a)「DKIM」について」を参考に、SPF、DKIMの機能の違い等を踏まえた上で選択するとよい。

受信側の対策を行うことによって、なりすましと判定した電子メールをいわゆる迷惑メールフォルダへの格納や、電子メールサーバ上での破棄等が可能となり、受信側である機関等がなりすましメールによる被害に遭うリスクを低減させることができる。

送信ドメイン認証技術による受信側の対策としては、受信した電子メールに対し送信ドメイン認証に基づくなりすまし判定を行い、なりすましと判定した場合には、受信した電子メールのDMARCポリシーに従って受信を拒否することや隔離すること等が考えられる。また、受信した電子メールが送信ドメイン認証技術を用いておらず、送信ドメイン認証に基づくなりすまし判定が行えない場合は、受信を拒否することや、隔離し安全性を確認した上で受信すること等の対策を行うことが重要である。

なお、送信ドメイン認証技術を使用し、受信側の電子メールサーバによってなりすましと判定したとしても、送信側の設定等によっては、受信側の電子メールクライアントでは判定結果が分からない場合がある。そのため、なりすましと判定した場合には、以下を例とする電子メールの受信者への注意喚起等を行う機能の導入を検討するとよい。

DMARCポリシーが”p=none”の場合、受信側に特別な処理を要求しないため、機関等になりすましたメールによって受信側が被害に遭うリスクを必ずしも低減させることができない。そのため、以下の対策を実施する必要がある。

・電子メールを利用していないドメインを“p=reject”に設定する。

・電子メールを利用しているドメインを“p= quarantine”に設定する。

・DMARCレポートを取得し、機関等が送信した電子メールが受信側においてSPF、DKIMの認証に失敗するケースを確認して対策する。メーリングリスト、転送を使用している場合は、対策が必要となる場合がある。解説「基本対策事項6.2.2(1)-3 a)「DKIM」について」等を参照し、対策を講ずること。

・認証に失敗するケースが少ないことを確認し、“p=reject”に設定する。

なお、上記の設定は、すべての電子メールについて有効とすること。

電子メールを利用しているドメインについて、DMARC導入当初等でやむをえず、”p=none”に設定する場合も、DMARCレポートを取得、確認のうえ、一年以内に全ての電子メールについて“p= quarantine”又は“p=reject”を設定することが望ましい。

あわせて、DMARCによって認証された電子メールの視認性を向上させるBIMI（Brand Indicators for Message Identification）を導入することが望ましい。送信側がBIMIを設定すると、受信側のBIMIに対応する電子メールクライアントに送信側のロゴの表示ができるため、正規のドメイン名を用いて機関等が送信した電子メールであることが視覚的に分かりやすくなり、類似のドメイン名を用いてなりすまされた電子メールと容易に区別できるようになる。

電子メールの送信側ではSPF、DKIMのいずれかのみを導入している可能性があるため、電子メールの受信側である機関等においてはどちらでも対応できるようにSPF、DKIMの両方を導入する必要がある。

外部に一斉送信する電子メールに、組織の電子証明書で電子署名をすることは、電子メールのなりすまし防止の観点から効果的である。

また、通常のメールについては、職員等に電子証明書を配布し、電子署名を付与することにより、電子メールクライアントによっては、同時に電子メールを自動的に暗号化することが可能となるというメリットもある。

なお、電子メールのなりすまし防止策としては、本基本対策事項の他に、送信ドメイン認証技術を利用する「基本対策事項6.2.2(1)-3」を挙げている。

送信ドメイン認証技術はドメイン名単位で電子メールが詐称されているかどうかを確認できる。一方、S/MIMEは送信者と受信者が一対一で電子メールが詐称されているかどうかを確認できる。送信ドメイン認証技術とS/MIMEでは、認証の対象が異なる等の違いがあり、一対一で電子メールが詐称されているかどうかの確認が必要な場合等は、本基本対策事項を検討するとよい。

本基本対策事項は、職員等が遵守事項8.1.1(5)(b)の遵守を支援する機能を設けることを求めている。

政府ドメイン名を取得できない場合については、「（解説）遵守事項8.1.1(5)(b)「政府ドメイン名を取得できない場合」について」を参照のこと。

メールサーバ間通信であるSMTPによるサーバ間通信には、データを保護する仕掛けがないことから、これをTLSにより保護することが、インターネット上でのデータの盗聴及び改ざんの防止に有効である。

ただし、相手先サーバがTLSに対応していない場合は、通常のSMTPで送受信することになる。相手先がTLSに対応しているかを確認した後にTLS接続を確立するSTARTTLS（RFC3207）を用いたSMTPサーバが普及しているが、STARTTLSは、中間者攻撃によりTLSの使用を妨害されるダウングレード攻撃に弱いことが知られている。これを克服する仕組みとしてMTA-STS（SMTP MTA Strict Transport Security、RFC8461）やTLSRPT（SMTP TLS Reporting、RFC8460）が普及しつつあるので、導入を検討することも考えられる。また、MTA-STSを導入した場合であっても、DNSキャッシュポイズニング攻撃等によりDNSレコードを偽の情報に書き換えられることによって、STARTTLSを無効化される可能性がある。この攻撃への対策としては、DNSSECが必須となるが、DNSキャッシュポイズニング攻撃等によりDNSレコードを偽の情報に書き換えられる可能性を低減できるDANE（DNS-based Authentication of Name Entities）を導入することが考えられる。

なお、SMTPによる電子メール転送は複数のサーバを経由することがあり、最終的な受信先のサーバまでの通信が全て保護されることは必ずしも保証されない点に留意しなければならない。確実に保護するべきデータは、電子メールの送信者があらかじめ暗号化等の対策を行った上で送信する必要がある。

S/MIMEは電子メール自体に暗号化等を行うものであり、電子メールクライアント側で処理されるセキュリティ機能である。このため、送受信する相手側の電子メールクライアント側もS/MIMEに対応している必要がある。

6.2.3 ウェブ

目的・趣旨

インターネット上に公開するウェブサーバは、常に攻撃を受けるリスクを抱えている。様々な攻撃により、ウェブコンテンツ（ウェブページとして公開している情報）の改ざん、ウェブサーバの利用停止、偽サイトへの誘導等の被害が想定されるため、適切な対策を組み合わせて実施することが求められる。

なお、本款の遵守事項のほか、6.2.1「サーバ装置」において定めるサーバ装置に係る遵守事項についても併せて遵守する必要がある。さらに、ウェブサーバにおけるウェブアプリケーションについては、6.6「アプリケーション・コンテンツ」を参照のこと。

遵守事項

(1) ウェブサーバの導入・運用時の対策

(a) 情報システムセキュリティ責任者は、脆弱性が存在する可能性が増大することを防止するため、ウェブサーバが備える機能のうち、必要な機能のみを利用すること。

(b) 情報システムセキュリティ責任者は、ウェブサーバからの不用意な情報漏えいを防止するための措置を講ずること。

(c) 情報システムセキュリティ責任者は、ウェブコンテンツの編集作業を行う主体を限定すること。

(d) 情報システムセキュリティ責任者は、インターネットを介して転送される情報の盗聴及び改ざんの防止のため、全ての情報に対する暗号化及び電子証明書による認証の対策を講じること。

【 基本対策事項 】

＜6.2.3(1)(a)関連＞

6.2.3(1)-1 情報システムセキュリティ責任者は、ウェブサーバが備える機能のうち、必要な機能のみを利用するために、以下を全て含むウェブサーバの管理や設定を行うこと。

a) **CGI機能**を用いるスクリプト等は必要最低限のものに限定し、CGI機能を必要としない場合は設定でCGI機能を使用不可とすること。

b) **ディレクトリインデックスの表示を禁止する**こと。

c) ウェブコンテンツ作成ツールやコンテンツ・マネジメント・システム（CMS）等における**不要な機能を制限する**こと。

d) ウェブサーバ上で動作するソフトウェアは、最新のものを利用するなど、既知の脆弱性が解消された状態を維持すること。

＜6.2.3(1)(b)関連＞

6.2.3(1)-2 情報システムセキュリティ責任者は、ウェブサーバからの不用意な情報漏えいを防止するために、以下を全て含むウェブサーバの管理や設定を行うこと。

a) 公開を想定していないファイルをウェブ公開用ディレクトリに置かないこと。

b) 初期状態で用意されるサンプルのページ、プログラム等、不要なものは削除すること。

c) ウェブサーバに保存する情報を特定し、サービスの提供に必要のない情報がウェブサーバに保存されないことを確認すること。

＜6.2.3(1)(c)関連＞

6.2.3(1)-3 情報システムセキュリティ責任者は、ウェブコンテンツの編集作業を担当するアカウントの限定として、以下を全て含むウェブサーバの管理や設定を行うこと。

a) ウェブサーバ上のウェブコンテンツへのアクセス権限は、ウェブコンテンツの作成や更新に必要な者以外に更新権を与えないこと。

b) OSやアプリケーションのインストール時に標準で作成される識別コードやテスト用に作成した識別コード等、不要なものは削除すること。

6.2.3(1)-4 情報システムセキュリティ責任者は、ウェブコンテンツの編集作業に用いる端末の限定、識別コード及び主体認証情報の適切な管理として、以下を例とするウェブサーバの管理や設定を行うこと。

a) ウェブコンテンツの更新の際は、**専用の端末**を使用して行うこと。

b) ウェブコンテンツの更新の際は、ウェブサーバに接続する接続元のIPアドレスを必要最小限に制限すること。

c) ウェブコンテンツの更新に利用する識別コードや主体認証情報は、**情報セキュリティを確保した管理**を行うこと。

＜6.2.3(1)(d)関連＞

6.2.3(1)-5 情報システムセキュリティ責任者は、通信時の盗聴による第三者への情報の漏えい及び改ざんの防止並びに正当なウェブサーバであることを利用者が確認できるようにするための措置として、以下を全て含むウェブサーバの実装を行うこと。

a) **TLS機能を適切に用いる**こと。

b) TLS機能のために必要となるサーバ証明書には、利用者が事前のルート証明書のインストールを必要とすることなく、その正当性を検証できる認証局（証明書発行機関）により発行された電子証明書を用いること。

c) 暗号技術検討会及び関連委員会（CRYPTREC）により作成された**「TLS暗号設定ガイドライン」に従って、TLSサーバを適切に設定**すること。

（解説）

CGI機能において、外部からの文字列に基づいて実行されるスクリプト等は脆弱性の原因となり易い部分であり、細心の注意を払って脆弱性の無いスクリプト等のみを設置しなければならない。そのため、本基本対策事項は、サーバに設置するスクリプト等は必要最低限のものに限定することを求めている。

ウェブサーバの機能であるディレクトリインデックスの表示機能とは、ウェブサイトの公開対象となるディレクトリが、ファイル名を指定しない形式のURL（すなわち、例えば「https://exmaple.go.jp/directory_name/」の形式）又は「index.html」等の所定のファイル名を指定した形式のURLによってアクセスされたときに、当該ディレクトリに存在するファイル名の一覧を自動的に生成して表示する機能である。万が一、公開するつもりのないファイルがディレクトリに混入していた場合、ディレクトリインデックス機能が有効であると、外部から容易にそのファイル名を見つけられてしまい、アクセスされてしまう。本来、公開対象のディレクトリには、非公開にすべきファイルが混入していてはならないところであるが、念のため、本基本対策事項は、ディレクトリインデックスの表示機能を無効にすることを求めている。

不要な機能の典型的な例としては、管理者画面の機能が挙げられる。ウェブコンテンツ作成ツールやCMS（Content Management System）には、コンテンツを編集する管理者向けのログイン画面を有するものがある。このログイン画面がインターネットから閲覧可能であると、管理者のパスワードを破って不正にログインされ、ウェブサイトのコンテンツを改ざんされるリスクを生じさせる。管理者画面は、機関等内からのアクセスのみを許可し、インターネットからの利用を制限することを求めている。その他の不要な機能として制限すべき例として、アクセス解析の機能がインターネットから閲覧できるようになっている場合等が挙げられる。

ウェブコンテンツを管理する端末では、ウェブコンテンツの管理に関係する作業のみを行い、その作業に関係の無いウェブサイトを閲覧しない、セキュリティ対策が不十分なUSBメモリを利用しないなど、情報セキュリティを確保した運用をする必要がある。また、ウェブサーバのみでなく、ウェブコンテンツを管理する専用の端末においても、不正プログラム対策やソフトウェアに関する脆弱性対策を行うことが重要である。

ウェブコンテンツを更新する際の主体認証情報について、パスワードを設定する場合は「（解説）基本対策事項7.1.1(1)-4「強固なパスワードに必要な十分な桁数を備えた第三者に容易に推測できないパスフレーズ等を使用すること」について」を参照し強固なパスワードを設定する、多要素主体認証方式で主体認証を行う機能を設けるなどにより、情報セキュリティを確保することが求められる。また、ウェブコンテンツの更新に利用する識別コードや主体認証情報は、他の情報システムの認証で使用しているものを使い回さない、ウェブコンテンツを更新する者以外に知らせない、複数の更新を実施する者で共有しないなどの情報セキュリティを確保した管理が求められる。

ウェブサーバにTLS機能を搭載することにより、利用者が当該ウェブサーバのサイトを「https://」で始まるURLでアクセスできるようになる。「https://」で始まるURLのページ（以下「セキュアページ」という。）へのアクセスは、ブラウザからウェブサーバへの入力及びウェブサーバからブラウザへの出力が自動的に暗号化されて送受信される。

盗聴による情報の漏えいを防止するには、盗聴を防ぐべき情報を出力するウェブページがセキュアページとなっている必要がある。また、盗聴を防ぐべき情報を利用者に入力させるウェブページを設ける場合には、入力された情報の送信先となるURLがセキュアページとなっていることが必要であり、かつ、利用者に情報を入力させるウェブページ（入力欄が設置されている画面）自体もセキュアページとなっている必要がある。

ウェブサーバにTLS機能を搭載することは、当該ウェブサーバが正当なサーバである（偽のサーバでない。）ことを確認できる手段を利用者に提供することにもなる。利用者は、当該サイトを「https://」で始まるURLでアクセスし、エラーなく正常に表示されたことで、当該サーバが当該ドメイン名の正当なサイトのものであると確認することができる。

なお、TLSで配信されるページにおいて、TLSを使わないコンテンツが含まれていると、利用者がフィッシング等の被害に合うリスクがあるため、TLSで配信されるページにおいて、TLSを使わないコンテンツを含めてはならない。また、TLS機能を用いるに当たっては、使用するバージョンの脆弱性に関する最新の情報も踏まえ、適切に使用する必要がある。

従来、サービス利用者の個人に関する情報を保護することが特に求められていたが、さらに今日では、全ての情報について、インターネット上の通信経路において第三者による盗聴や改ざんから守り、国民や外部組織が不利益を被らず安心して利用できるようにすることが求められている。このための対策として、ウェブサイト全体に対するTLS適用が有効であり、本対策は、外国の政府機関や民間企業のウェブサイトにおいても取組が進められている。

利用者が「http://」から始まるURLを入力した場合であっても常にTLSでアクセスさせるためには、以下の全ての対策を実施するとよい。

TLS機能を用いるには、ウェブサーバ側に「サーバ証明書」と呼ばれる電子証明書の設置が必要であり、サーバ証明書はそれを発行する「認証局」から取得する必要がある。

本基本対策事項は、サーバ証明書をどの認証局から取得するかの選択において、「利用者が事前のルート証明書のインストールを必要とすることなくその正当性を検証できる認証局」を選択することを求めている。それ以外の認証局を選択した場合、利用者のウェブブラウザには、サーバ証明書の正当性検証ができないことを示す警告やエラー画面が表示されることになる。この警告やエラー画面は、事前に当該認証局の自己署名証明書をブラウザにルート証明書としてインストールすることによって解消することができる。しかし、一般に、利用者によるルート証明書のインストールは安全に行うことが容易でないものであり、利用者に危険を伴うルート証明書のインストールを強いるのはそもそも避けるべきことである。そのため、本基本対策事項は、利用者にルート証明書のインストールを求めなくても、警告やエラー画面が現れることなく、正常にTLS通信ができるよう、適切に認証局を選択してサーバ証明書を取得することを求めている。

なお、ウェブサーバの利用が機関等内の管理された端末からのアクセスに限定されている場合には、対象となる全ての端末に対して事前に安全な方法でルート証明書をインストールすることも可能であるから、そのような管理がなされている場合には、当該ウェブサーバで使用するサーバ証明書として、機関等で独自に用意した認証局から発行されたものを用いることができる。

CRYPTRECが発行している「TLS暗号設定ガイドライン」は、TLS通信での安全性と相互接続性のバランスを踏まえたTLSサーバの設定方法を示すものである。

このガイドラインでは、「高セキュリティ型」、「推奨セキュリティ型」、「セキュリティ例外型」の3段階の設定基準に分けて、各々の要求設定が示されており、どの設定基準を採用するかは、安全性の確保と相互接続の必要性の両面を鑑みてサーバ管理者が選択するものとされている。

「推奨セキュリティ型」は、利用例に「電子申請等、企業・国民と役所等との電子行政サービスを提供する場合」とあるように、一般的な利用形態で使うことを想定した設定基準であり、安全性又は相互接続性についての特段の要求がなければ選択することが強く勧められている。

他方、「高セキュリティ型」は、情報が漏えいした際、組織の運営や資産、個人の資産やプライバシー等に悪影響を及ぼすと予想される情報を、安全性を優先してTLS通信を行うような場合に選択すべき設定基準である。また、「セキュリティ例外型」は、システム等の制約上、安全性が低いプロトコルの利用を全面禁止することが現実的ではなく、安全性上のリスクを受容してでも当該プロトコルを継続利用せざるを得ないと判断される場合にのみ採用すべき設定基準である。

ガイドラインは、巻末に付録として「チェックリスト」を提供しており、ここに、設定基準ごとに満たすべき要求設定として「プロトコルバージョン設定」、「サーバ証明書設定」、「暗号スイート設定」の具体的な基準が示されているので、これに従うことで、容易に適切なTLS設定を行うことができる。

情報システムセキュリティ責任者は、TLSを導入するシステムの特性に応じて、どの設定基準が相応しいかを決定し、その設定基準に対応する要求設定に従ったサーバ設定を、「チェックリスト」を活用して確認するなどして、適切に行うことが求められる。

また、ガイドラインは、サーバ証明書の作成・管理について注意すべきことや、委託先のサーバ（PaaS/SaaS）を利用する場合の注意点を示し、また、「さらに安全性を高めるために」として、HTTP Strict Transport Security（HSTS）の設定有効化その他を推奨している。これらについても併せて検討することが望ましい。

参考：CRYPTREC「TLS暗号設定ガイドライン」（CRYPTREC GL-3001-3.1.1） （https://www.cryptrec.go.jp/report/cryptrec-gl-3001-3.1.1.pdf）

6.2.4 ドメインネームシステム（DNS）

目的・趣旨

ドメインネームシステム（DNS：Domain Name System）は、インターネットを使った階層的な分散型システムで、主としてインターネット上のホスト名や電子メールで使われるドメイン名と、IPアドレスとの対応づけ（正引き、逆引き）を管理するために使用されている。DNSでは、端末等のクライアント（DNSクライアント）からの問合せを受けて、ドメイン名やホスト名とIPアドレスとの対応関係等について回答を行う。DNSには、機関等が管理するドメインに関する問合せについて回答を行うコンテンツサーバと、DNSクライアントからの要求に応じてコンテンツサーバに対して問合せを行うキャッシュサーバが存在する。キャッシュサーバの可用性が損なわれた場合は、ホスト名やドメイン名を使ったウェブや電子メール等の利用が不可能となる。また、コンテンツサーバが提供する情報の完全性が損なわれ、誤った情報を提供した場合は、端末等のDNSクライアントが悪意あるサーバに接続させられるなどの被害に遭う可能性がある。さらに、電子メールのなりすまし対策の一部はDNSで行うため、これに不備があった場合には、なりすまされた電子メールの検知が不可能となる。これらの問題を回避するためには、DNSサーバの適切な管理が必要である。

なお、本款の遵守事項のほか、6.2.1「サーバ装置」において定めるサーバ装置に係る遵守事項についても併せて遵守する必要がある（SaaS系のクラウドサービスを利用する場合を除く）。

遵守事項

(1) DNSの導入時の対策

(a) 情報システムセキュリティ責任者は、要安定情報を取り扱う情報システムの名前解決を提供するコンテンツサーバにおいて、名前解決を停止させないための措置を講ずること。

(b) 情報システムセキュリティ責任者は、キャッシュサーバにおいて、名前解決の要求への適切な応答をするための措置を講ずること。

(c) 情報システムセキュリティ責任者は、コンテンツサーバにおいて、機関等のみで使用する名前の解決を提供する場合、当該コンテンツサーバで管理する情報が外部に漏えいしないための措置を講ずること。

【 基本対策事項 】

＜6.2.4(1)(a)関連＞

6.2.4(1)-1 情報システムセキュリティ責任者は、要安定情報を取り扱う情報システム及び非常時優先業務等を支える情報システムの名前解決を提供するコンテンツサーバにおいて、以下を例とする名前解決を停止させないための措置を講ずること。

a) コンテンツサーバを**冗長構成**にすること。

b) 通信回線装置等で、コンテンツサーバへのサービス不能攻撃に備えたアクセス制御を行うこと。

c) ISP等が提供するマネージドDNSサービスやDDoS対策サービスを利用すること。

d) UDP及びTCPの両方でサービスを提供すること。

＜6.2.4(1)(b)関連＞

6.2.4(1)-2 情報システムセキュリティ責任者は、**機関等外からの名前解決の要求に応じる必要性**があるかについて検討し、必要性がないと判断される場合は必要であれば機関等内からの名前解決の要求のみに応答をするよう、以下を例とする措置を講ずること。

a) キャッシュサーバの設定でアクセス制御を行うこと。

b) ファイアウォール等でアクセス制御を行うこと。

6.2.4(1)-3 情報システムセキュリティ責任者は、**DNSキャッシュポイズニング攻撃**から保護するため、以下を例とする措置を講ずること。

a) **ソースポートランダマイゼーション**機能を導入すること。

b) **DNSSEC検証**を有効にすること。

＜6.2.4(1)(c)関連＞

6.2.4(1)-4 情報システムセキュリティ責任者は、機関等内のみで使用する名前の解決を提供するコンテンツサーバにおいて、以下を例とする**当該コンテンツサーバで管理する情報の漏えいを防止するための措置**を講ずること。

a) 外部向けのコンテンツサーバと別々に設置すること。

b) ファイアウォール等でアクセス制御を行うこと。

（解説）

コンテンツサーバは、冗長構成にすることが一般的である。その際には、ネットワーク障害等を考慮して各々のコンテンツサーバをそれぞれ異なるネットワークに配置する、災害等を考慮して物理的に離れた建物や遠隔地に設置するなど、情報と情報システムに要求される可用性の確保に応じて、最適な構成を検討する必要がある。ISP等が提供するセカンダリDNSの利用等も、遠隔地への設置による冗長化の措置の例である。

また、要求される可用性の度合いに応じて、保守作業による復旧等、冗長化以外の措置を探ることも考えられる。

不特定のDNSクライアントからの名前解決の要求に応じるキャッシュサーバはオープンリゾルバと呼ばれる。オープンリゾルバは、存在しないホスト名の名前解決の問合せを大量に送信することで当該ホスト名の名前解決に関係するDNSサーバの過負荷を狙うランダムサブドメイン攻撃（DNS水責め攻撃）や、送信元IPアドレスを偽った問合せを大量に送信することで応答を攻撃対象に送り付け、サービス不能の状態にすることを狙うDNSリフレクター攻撃といったサービス不能攻撃等の踏み台として悪用される危険性がある。そのため機関等で利用するキャッシュサーバが機関等外からの名前解決の要求に応じる必要性があるか検討する必要がある。

DNSキャッシュポイズニング攻撃とは、DNSのキャッシュサーバに偽の応答をキャッシュさせることで、利用者のアクセスを攻撃者が用意したサイト等に誘導する攻撃である。この攻撃により、例えば、利用者は正しいURLのウェブサイトに接続しているつもりでも、偽の情報により不正なウェブサイトに誘導されるといった被害を受ける可能性がある。

なお、DNSキャッシュポイズニング攻撃対策として、名前解決におけるIPフラグメンテーションの発生を回避するため、コンテンツサーバ及びキャッシュサーバのUDPメッセージサイズの上限を1,232バイトに設定することが望ましい。

参考：DNS flag day 2020 （https://www.dnsflagday.net/2020/index-ja.html）

ソースポートランダマイゼーションとは、キャッシュサーバからコンテンツサーバへの問合せに使用されるUDPポート番号をランダム化する技術である。UDPポート番号をランダム化することにより、攻撃者がキャッシュポイズニング攻撃を行う際にUDPポート番号の推測を困難にすることができ、攻撃の成功確率を低下させることが可能となる。

なお、キャッシュサーバからコンテンツサーバへの問合せにおいて、通信経路上のファイアウォールにてネットワークアドレス変換（NAT）処理が行われる場合、UDPポート番号が推測可能な形に変換されてしまうことのないように留意が必要である。

DNSSECでは、コンテンツサーバによって応答に電子署名が追加され、キャッシュサーバがその署名を検証することで、応答が改ざん等されているか確認することができる。DNSSECは、公開鍵暗号技術を用いるため、その導入には情報の提供側であるコンテンツサーバと情報の問合せ側であるキャッシュサーバの双方に対応が必要となる。国民等への信頼できるサービスの提供と、機関等の情報セキュリティ向上の観点から、政府ドメイン名を管理するコンテンツサーバにおけるDNSSEC署名、及び機関等のキャッシュサーバに対する円滑なDNSSEC検証の導入が望ましい。

コンテンツサーバにおいて、機関等内のみで使用する名前の解決を提供する場合、内部のみで使用している名前情報を機関等外の者が取得できないようにすることを求めている。

遵守事項

(2) DNSの運用時の対策

(a) 情報システムセキュリティ責任者は、コンテンツサーバを複数台設置する場合は、管理するドメインに関する情報について**サーバ間で整合性を維持**すること。

(b) 情報システムセキュリティ責任者は、コンテンツサーバにおいて管理する**ドメインに関する情報が正確であることを定期的に確認**すること。

(c) 情報システムセキュリティ責任者は、キャッシュサーバにおいて、名前解決の要求への適切な応答を維持するための措置を講ずること。

【 基本対策事項 】

＜6.2.4(2)(b)関連＞

6.2.4(2)-1 情報システムセキュリティ責任者は、コンテンツサーバにおいて管理するドメインに関する情報が正確であることを定期的に確認すること。

a) コンテンツサーバとDNSルートサーバのそれぞれの当該ドメインに関する情報が正しく同一であること。

b) コンテンツサーバとホスト（ホスティングサービス等のホストを含む。）のそれぞれの当該ドメイン（サブドメインを含む。）に関する情報が正しく同一であること。

＜6.2.4(2)(c)関連＞

6.2.4(2)-2 情報システムセキュリティ責任者は、キャッシュサーバにおいて、ルートヒント（DNSルートサーバの情報が登録されたファイル等）の更新の有無を定期的（３か月に一度程度）に確認し、最新のDNSルートサーバの情報を維持すること。

6.2.4(2)-3 情報システムセキュリティ責任者は、キャッシュサーバにおいてDNSSECを利用する場合、電子署名を検証する起点となるDNSSECトラストアンカーを最新の状態に保つため、自動更新機能を有効にする又は更新の有無を定期的（３か月に一度程度）に確認すること。

（解説）

複数台のコンテンツサーバでドメインに関する情報を保有し管理する場合に、各コンテンツサーバ間でドメインに関する情報の整合性を維持することを求める事項である。例えば、主系統のコンテンツサーバで管理するドメインに関する情報が変更された場合に、ゾーン転送等によって、情報システムの可用性に影響を及ぼさない適切なタイミングで副系統のコンテンツサーバが管理するドメインに関する情報も更新するといった方法が考えられる。

なお、主系統のコンテンツサーバから副系統のコンテンツサーバへ安全にゾーン転送を行う対策として、例えば、TSIG（Transaction Signature）の利用等が考えられる。

ドメイン名に関する情報には、機関等が当該ドメイン名の委任元（親ゾーン）の登録機関（レジストリ・レジストラ）に登録する情報（以下本解説において「登録情報」という。）と機関等のコンテンツサーバに設定・管理する情報（以下本解説において「設定情報」という。）の２種類が存在する。いずれの情報も利用者のウェブサイトのアクセスや電子メールの送受信において参照されるため、正確性を保つことが重要である。

① 登録情報に関する対策

ドメイン名の登録情報が不正に書き換えられ、攻撃者が用意したネームサーバの情報が追加されることで、利用者のアクセスが不適切なウェブサイト等に誘導されるドメイン名ハイジャックと呼ばれる攻撃が知られている。このような攻撃への対策として、登録機関に情報を登録する際のなりすましの防止、登録機関が提供する各種ロックサービスの利用等が挙げられる。

なりすましの防止としては、第三者に容易に推測できるパスワードを利用しない、パスワードの使い回しをしないなどの対策に加え、二段階認証やクライアント証明書等、登録機関が提供する追加の認証手段の利用等が挙げられる。

登録機関が提供する各種ロックサービスとしては、JPドメイン名（政府ドメイン名を含む。）については、意図しない登録情報の変更を制限するためのレジストリロックサービスや意図しないドメイン名の移転を防ぐための指定事業者変更ロックサービスが利用可能な場合があるため、当該サービスの利用を検討してもよい。

ドメイン名を廃止する場合には、登録機関にドメイン名の廃止申請を行い、当該ドメイン名が確実に廃止されていることを確認するとともに、当該ドメイン名に関する機関等のコンテンツサーバの設定情報を確認し、削除することが重要である。これに加えて、ドロップキャッチ（ドメイン名の登録期限が切れたタイミングで、第三者がそのドメイン名を新たに取得してしまうこと。）対策の観点から、当該ドメイン名を利用しなくなった後でも一定期間（少なくとも１年以上）ドメイン名登録を継続することや、可能な限りウェブサイトからのリンクを解除することなどが求められる。

② 設定情報に関する対策

設定情報については、コンテンツサーバの設定誤りや削除漏れ、不正な改ざん等が発生していないかを定期的に確認することにより、正確性を保つことが重要である。具体的には、以下を例とする情報の記述内容等を確認することが求められる。

なお、電子メールにおけるなりすまし防止の観点からも、管理するドメイン名のSPFレコード等を記述するTXTレコードの内容が正確であるか否かを確認する必要がある。また、ホスティングサービス等の利用終了後に残ったままになっている設定情報を利用して意図しないウェブサイト等を公開されてしまうサブドメインテイクオーバー・NSテイクオーバーと呼ばれる攻撃を避けるため、当該ウェブサイト等の利用を終了する場合には、当該ホスティングサービス等の利用開始時に設定したCNAMEやNSレコードを全て削除・修正することが重要である。

加えて、クラウドサービスによっては、使用中のサービスにテイクオーバー可能なDNS設定がないかを利用者において確認できるツールを公開している場合もあるので、そのようなツールを活用することも有用である。

6.2.5 データベース

目的・趣旨

本款における「データベース」とは、データベース管理システムとそれによりアクセスされるデータファイルから構成され、体系的に構成されたデータを管理し、容易に検索・抽出等が可能な機能を持つものであって、要保護情報を保管するサーバ装置とする。

要保護情報を保管するデータベースでは、不正プログラム感染や不正アクセス等の外的要因によるリスク及び職員等の不適切な利用や過失等の内的要因によるリスクに対して、管理者権限の悪用を防止するための技術的対策等を講ずる必要がある。

特に大量のデータを保管するデータベースの場合、そのデータが漏えい等した際の影響が大きく、また、そのようなデータは攻撃者の標的となりやすい。

なお、本款の遵守事項のほか、7.1「情報システムのセキュリティ機能」において定める主体認証・アクセス制御・権限管理・ログ管理・暗号・電子署名等の機能面での対策、6.4.4「IPv6通信回線」、7.2.1「ソフトウェアに関する脆弱性対策」、7.2.2「不正プログラム対策」において定める遵守事項のうち、データベースに関係するものについても併せて遵守する必要がある。

遵守事項

(1) データベースの導入・運用時の対策

(a) 情報システムセキュリティ責任者は、データベースに対する内部不正を防止するため、管理者アカウントの適正な権限管理を行うこと。

(b) 情報システムセキュリティ責任者は、**データベースに格納されているデータにアクセスした利用者を特定**できるよう、措置を講ずること。

(c) 情報システムセキュリティ責任者は、データベースに格納されているデータに対するアクセス権を有する利用者による**データの不正な操作を検知**できるよう、対策を講ずること。

(d) 情報システムセキュリティ責任者は、データベース及びデータベースへアクセスする機器等の脆弱性を悪用した、データの不正な操作を防止するための対策を講ずること。

(e) 情報システムセキュリティ責任者は、データの窃取、電磁的記録媒体の盗難等による情報の漏えいを防止する必要がある場合は、**適切に暗号化**をすること。

【 基本対策事項 】

＜6.2.5(1)(a)関連＞

6.2.5(1)-1 情報システムセキュリティ責任者は、必要に応じて**情報システムの管理者とデータベースの管理者を別に**すること。

6.2.5(1)-2 情報システムセキュリティ責任者は、データベースに格納されているデータにアクセスする必要のない管理者に対して、データへのアクセス権を付与しないこと。

6.2.5(1)-3 情報システムセキュリティ責任者は、データベースの管理に関する**権限の不適切な付与**を検知できるよう、措置を講ずること。

＜6.2.5(1)(c)関連＞

6.2.5(1)-4 情報システムセキュリティ責任者は、業務を遂行するに当たって不必要なデータの操作を検知できるよう、以下を例とする措置を講ずること。

a) 一定数以上のデータの取得に関するログを記録し、警告を発すること。

b) データを取得した時刻が不自然であるなど、通常の業務によるデータベースの操作から逸脱した操作に関するログを記録し、警告を発すること。

＜6.2.5(1)(d)関連＞

6.2.5(1)-5 情報システムセキュリティ責任者は、データベースにアクセスする機器上で動作するプログラムに対して、SQLインジェクションの脆弱性を排除すること。

6.2.5(1)-6 情報システムセキュリティ責任者は、データベースにアクセスする機器上で動作するプログラムに対してSQLインジェクションの脆弱性の排除が不十分であると判断した場合、以下を例とする対策の実施を検討すること。

a) ウェブアプリケーションファイアウォールの導入

b) データベースファイアウォールの導入

＜6.2.5(1)(e)関連＞

6.2.5(1)-7 情報システムセキュリティ責任者は、データベースに格納されているデータに対して暗号化を実施する場合には、バックアップデータやトランザクションデータ等についても暗号化を実施すること。

（解説）

一般的に、データベースの使用形態は図6.2.5(1)-1のように、データベースから見たアクセス主体が「人間の利用者」となる場合と、「中間アプリケーションサーバ」となる場合の２つのモデルに分けられる。中間アプリケーションサーバを利用するモデルでは、中間アプリケーションサーバ用にデータベースアクセス用のアカウントを作成して運用する構成となるのが通常である。この構成では、データベースのログにはアクセス主体が中間アプリケーションサーバとして記録されることになるため、不正な操作が行われた場合に実際には誰が操作をしたものかをデータベースのログのみからでは特定できない可能性がある。そのため中間アプリケーションサーバにおいて、データベースの利用者とデータベースへの操作要求とを紐づけてログを取得し、利用者を特定できるようにする必要がある。

図6.2.5(1)-1　データベース利用形態モデル

通常業務では取り扱わないような大量のデータを取得することや業務時間外にデータの操作を行う等の不正な操作を、SIEMやUEBA（User and Entity Behavior Analytics）等を導入することによってシステム的に検知する方法を用いるとよい。なお、データベースのログを目視によって確認する方法も考えられるが、人手に依存する方法は確認漏れ等が発生する可能性があり望ましくない。

データの不正な操作が発生したときの影響や操作ログの量等を踏まえて、システム的に検知する方法か人手に依存する方法かを選択するとよい。

データベースに格納されるデータを暗号化する方法には、電磁的記録媒体の暗号化、データベースのテーブルの暗号化、カラムの暗号化等がある。想定される脅威や利用環境等によってメリット・デメリットがあるため、適切な方式を選択することが望ましい。

データベースの管理者は、データベースに格納されるデータの管理、アカウント・権限の管理、ネットワーク環境の構成等の管理を行う。多数の管理者権限を保持するアカウントを奪取された場合、甚大な被害を受けるおそれがあるため、重要な情報を管理するデータベースの管理者の特権を他の管理者と分掌することが望ましい。

業務の遂行、データベースの運用・管理等をするに当たって不必要なデータに対するアクセス権の付与のほか、他のアカウントに対して権限を付与する権限の付与等がある。

6.3 複合機・特定用途機器

6.3.1 複合機・特定用途機器

目的・趣旨

機関等においては、プリンタ、ファクシミリ、イメージスキャナ、コピー機等の機能が一つにまとめられている複合機が利用されている。複合機は、機関等内通信回線や公衆電話網等の通信回線に接続して利用されることが多く、その場合には、ウェブによる管理画面を始め、ファイル転送、ファイル共有、リモートメンテナンス等多くのサービスが動作するため、様々な脅威が想定される。

また、機関等においては、テレビ会議システム、IP電話システム、ネットワークカメラシステム、入退管理システム、施設管理システム、環境モニタリングシステム等の特定の用途に使用される情報システムが利用されている。これらの特定用途機器がインターネットに接続する機能を備える、いわゆるIoT機器となっている場合が多くある。例えばネットワークカメラシステムの構成要素である機器のうちインターネットに接続する機能を備えるカメラや、環境モニタリングシステムの構成要素である機器のうちインターネットに接続する機能を備えるセンサーが挙げられる。近年、IoT機器の脆弱性をついた攻撃が数多く発生しており、IoT機器が踏み台となって他の情報システムへの攻撃に利用されるなど、社会的問題となってきている。このため、これらの機器に対する情報セキュリティ対策が必要となる。

したがって、複合機やIoT機器を含む特定用途機器に関しても情報システムの構成要素と捉え、責任者を明確にして適切に対策を講ずることが重要である。

遵守事項

(1) 複合機

(a) 情報システムセキュリティ責任者は、複合機を調達する際には、当該複合機が備える機能、設置環境並びに取り扱う情報の格付及び取扱制限に応じ、適切なセキュリティ要件を策定すること。

(b) 情報システムセキュリティ責任者は、複合機が備える機能について適切な設定等を行うことにより運用中の複合機に対する情報セキュリティインシデントへの対策を講ずること。

(c) 情報システムセキュリティ責任者は、複合機の運用を終了する際に、複合機の電磁的記録媒体の全ての情報を抹消すること。

【 基本対策事項 】

＜6.3.1(1)(a)関連＞

6.3.1(1)-1 情報システムセキュリティ責任者は、**「IT製品の調達におけるセキュリティ要件リスト」を参照**するなどし、複合機が備える機能、設置環境並びに取り扱う情報の格付及び取扱制限に応じ、当該複合機に対して想定される脅威を分析した上で、脅威へ対抗するためのセキュリティ要件を調達仕様書に明記すること。

＜6.3.1(1)(b)関連＞

6.3.1(1)-2 情報システムセキュリティ責任者は、以下を例とする運用中の複合機に対する、情報セキュリティインシデントへの対策を講ずること。

a) 複合機について、利用環境に応じた**適切なセキュリティ設定**を実施すること。

b) 複合機が備える機能のうち**利用しない機能を停止**すること。

c) 印刷された書面からの情報の漏えいが想定される場合には、複合機が備える**操作パネルで利用者認証が成功した者のみ印刷が許可される機能**等を活用すること。

d) 複合機をインターネットに直接接続しないこと。

e) リモートメンテナンス等の目的で複合機がインターネットを介して外部と通信する場合は、**ファイアウォール等の利用により適切に通信制御を行う**こと。

f) **利用者ごとに許可される操作を適切に設定する**こと。

＜6.3.1(1)(c)関連＞

6.3.1(1)-3 情報システムセキュリティ責任者は、内蔵電磁的記録媒体の全領域完全消去機能（上書き消去機能）を備える複合機については、当該機能を活用することにより複合機内部の情報を抹消すること。当該機能を備えていない複合機については、委託先との契約時に委託先に複合機内部に保存されている情報の漏えいが生じないための対策を講じさせることを、契約内容に含むようにするなどの**別の手段で対策を講ずる**こと。

（解説）

遵守事項5.2.1(3)(c)及び基本対策事項5.2.1(3)-9に規定されている「IT製品の調達におけるセキュリティ要件リスト」には、複合機について一般的に想定される「セキュリティ上の脅威」が記載されているため、それらが自身の運用環境において該当する場合には対抗する必要がある。当該リストには、「国際標準に基づくセキュリティ要件」が記載されており、それを調達時に活用することで脅威に対抗するための機能を有した製品を調達することが可能となる。

なお、「IT製品の調達におけるセキュリティ要件リスト」に記載されている「セキュリティ上の脅威」のうち、利用環境や複合機に実装されている機能によっては、一部の脅威だけに対抗すればよい場合もあり得る。そのような場合には、「国際標準に基づくセキュリティ要件」では過剰な要件（要求仕様）となる可能性もあるので、個別にセキュリティ要件を策定して脅威に対抗してもよい。

自身の利用環境における脅威に対抗するために、運用前に複合機のセキュリティ機能の設定値が適切な値となっていることを確認する必要がある。例えば、管理者パスワードが初期設定のままでないか、イメージスキャナで複合機内部に保存したデータへのアクセス制御設定が適切であるかなどを確認する必要がある。

運用において必要としていない機能が利用者の意図に反して動作していた場合、セキュリティ対策が不十分になっていることが考えられる。対策が不十分である場合は、情報セキュリティインシデントが発生するおそれがあるため、複合機が備える機能を把握し、運用上不必要な機能については、運用前に停止した状態にする必要がある。また、脆弱性が指摘されている通信プロトコルについても停止すべきである。

複合機の設置環境によっては、印刷された文書が第三者に閲覧される可能性がある。そのような場合には、印刷の際に複合機内部に一旦データを保存し、複合機本体の操作パネルで主体認証に成功した者だけが印刷できるように設定するなどの対策を講ずる必要がある。

トナー残量の通知や遠隔地からの状態監視等の遠隔保守サービス等を利用する場合には、インターネットを介して外部と通信する必要が生じる。その際には必要最小限の通信のみを許可するようにする必要がある。また、ファイアウォール等の通信制御を行うための機器に例外的な設定を行う場合には、その設定によって脆弱性が生じないようにする必要がある。

様々な機能を備えている複合機では、利用者ごとに許可される操作権限の管理が重要である。例えば、ファクシミリで受信したデータを複合機内部に保存する場合のデータの読み出し権限等を適切に設定していない場合には、情報の漏えいにつながる可能性がある。

内蔵電磁的記録媒体の全領域完全消去機能を備えていない複合機については、調達元の機関等において内蔵電磁的記録媒体の全ての情報を抹消することが困難であるため、委託先と情報の抹消サービスを契約するなどの情報の漏えいへの対策を講ずることが必要となる。

遵守事項

(2) IoT機器を含む特定用途機器

(a) 情報システムセキュリティ責任者は、特定用途機器について、取り扱う情報、利用方法、通信回線への接続形態等により脅威が存在する場合には、**当該機器の特性に応じた対策を講ずる**こと。

【 基本対策事項 】

＜6.3.1(2)(a)関連＞

6.3.1(2)-1 情報システムセキュリティ責任者は、特定用途機器の特性に応じて、以下を全て含む対策を講ずること。ただし、使用している特定用途機器の機能上の制約により講ずることができない対策を除く。

a) 特定用途機器について、**主体認証情報を初期設定から変更**した上で、適切に管理すること。

b) 特定用途機器にアクセスする**主体に応じて必要な権限を割り当て、管理**すること。

c) 特定用途機器が備える機能のうち**利用しない機能を停止**すること。

d) インターネットと通信を行う必要のない特定用途機器については、当該特定用途機器をインターネットに接続させず、インターネットに接点を有する情報システムに接続する場合は、当該特定用途機器がインターネットに接続されないように適切に通信制御を行うこと。

e) 特定用途機器がインターネットを介して外部と通信する場合は、ファイアウォール等の利用により**適切に通信制御を行う**こと。

f) 特定用途機器のソフトウェアに関する脆弱性の有無を確認し、脆弱性が存在する場合は、バージョンアップやセキュリティパッチの適用、アクセス制御等の対策を講ずること。

g) 特定用途機器に対する不正な行為、無許可のアクセス等の意図しない事象の発生を監視すること。

h) 特定用途機器を使用しない場合は、**特定用途機器の電源をオフ**にすること。

i) 特定用途機器を廃棄する場合は、特定用途機器の内蔵電磁的記録媒体に保存されている全ての情報を抹消すること。

（解説）

例えば、テレビ会議システム、IP電話システム等は機関等LANシステムを経由してインターネットに接続されて利用されることが想定され、その場合外部からの攻撃対象となり得る。また、これら情報システムを構成する機器が内蔵電磁的記録媒体を備える場合は、運用終了時に内蔵電磁的記録媒体に残された情報が漏えいするおそれがある。このような脅威に対抗するために、情報システムや端末、サーバ装置に対して定められた遵守事項や基本対策事項を参考にして、IoT機器を含む特定用途機器の対策を講ずる必要がある。

特定用途機器の導入時に注意すべき点として、特定用途機器の導入後にサポートが適切に行われるかどうかという点や、特定用途機器の設定を適切に変更できるかどうかという点が挙げられる。

サポートが適切に行われなかったり、設定を適切に変更できなかったりする等の場合、必要なセキュリティ対策を講ずることが困難になる可能性がある。そのため、導入時にサポートの提供や設定変更が可能な範囲やIoT機器の使用期間全般に渡ってファームウェアやドライバーの更新が保証されることについて仕様に盛り込むなどして、必要なセキュリティ対策を講ずることができる特定用途機器を調達する必要がある。

IoT機器等については、2025年３月に、セキュリティ要件適合評価及びラベリング制度（JC-STAR）の運用が開始されている。詳細については、「（解説）基本対策事項4.3.1(1)-2「セキュリティ要件適合評価及びラベリング制度（JC-STAR）」について」を参照のこと。また、セキュリティ対策に係るガイドラインや手引書が公表されていることから、必要に応じて参考にするとよい。

参考：IoT推進コンソーシアム、総務省、経済産業省「IoTセキュリティガイドライン」 （http://www.iotac.jp/wg/security）

（https://www.soumu.go.jp/main_content/000428393.pdf）

参考：情報処理推進機構（IPA）「IoT開発におけるセキュリティ設計の手引き」 （https://www.ipa.go.jp/security/iot/iotguide.html）

参考：情報処理推進機構（IPA）「ネットワークカメラシステムにおける情報セキュリティ対策要件に関するチェックリスト　第２版」 （https://www.ipa.go.jp/security/jisec/about/knowledge/nw-camera.html）

特定用途機器の一部の機種は、遠隔保守や外部ネットワークからの機能利用を目的として、インターネット回線等の通信回線を経由して、特定用途機器へログインする機能を有しているものがあるが、この機能を悪用したサイバー攻撃の手法が存在する。具体的には、工場出荷時に設定される初期のパスワードを変更せずに運用している特定用途機器を標的とし、一般によく使われる初期の識別コードとパスワードの組合せを用いて辞書攻撃を行い、不正なログインを試行するものである。特定用途機器の運用保守等のために、インターネット回線等の通信回線を介してログインを行う必要がある場合は、このような攻撃を受けることを想定して、特定用途機器の運用開始前に初期設定されているパスワード等の主体認証情報を「（解説）基本対策事項7.1.1(1)-4「強固なパスワードに必要な十分な桁数を備えた第三者に容易に推測できないパスフレーズ等を使用すること」について」を参照し強固なパスワード等に変更することが重要である。また、管理者アカウントに対して不正なログインが行われた場合の影響は一般アカウントと比較して大きくなることが考えられるため、管理者アカウントの主体認証は多要素主体認証方式等の強固な認証技術を用いることが望ましい。

特定用途機器の導入及び運用においては、設定変更などを行う管理者権限と、状態の確認や閲覧等を行うだけの一般権限のアカウントを別にして使い分けることで、内部不正や誤操作の防止につながる。さらに管理者権限の利用を許可するアクセス元を制限するといった他の対策と複合的に組み合わせることによって、悪意のある第三者によって設定変更されたり攻撃に利用されたりする可能性を低減することが可能である。

「（解説）基本対策事項6.3.1(2)-1 a)「主体認証情報を初期設定から変更」について」にも示すとおり、インターネット回線等の通信回線を経由して特定用途機器へ不正なログインを試行する攻撃手法においては、Telnetのような汎用のプロトコルを利用したサービスが標的とされることがある。インターネット上には、グローバルアドレスに対してポートスキャンを行いレスポンスを返すサービスや、特定用途機器の情報を公表しているサイトが存在しており、そのようなサイトにセキュリティの弱いサービスや特定用途機器が登録されてしまうと、サイバー攻撃を企図する者の標的となるおそれがある。

このような攻撃手法への対抗策として、特定用途機器が備える機能を把握し、TelnetサービスやFTPサービス等のうち利用していないものは全て停止し、不正なログイン試行を無効化することが重要である。また、必要のある場合を除き、遠隔から起動する機能についても停止することが重要である。

なお、特定用途機器の中にはサービスや遠隔から起動する機能の停止などの設定を変更することができないものも存在するため、導入に当たっては、係る設定を変更できることを仕様に盛り込むといったことを検討するとよい。一方で、代替の特定用途機器がなかったり、既に導入済みで更改まで使用を継続しなければならない場合も考えられる。そういった場合には適切に通信制御を行う等の対策を講ずることが重要である。

特定用途機器への不正アクセスが生じると、不正プログラムへの感染、不正操作、情報窃取等の不正行為が行われるおそれがある。そのため、特定用途機器への通信制御を適切に実施し、不正アクセスを防止するとともに、不正行為が行われた場合の被害範囲を限定するなどの対策を行うことが重要である。

特定用途機器への通信制御は、例えば以下の方法により実施することが考えられる。

特定用途機器のソフトウェアの脆弱性を放置すると、脆弱性を悪用されるおそれがあることから、脆弱性が公表された場合は、ソフトウェアのバージョンアップやセキュリティパッチの適用により脆弱性対策を速やかに講ずることが重要である。特定用途機器の機種によっては、脆弱性対策が困難なものがあることに留意が必要である。そのような特定用途機器がサイバー攻撃の踏み台にされるなどし、意図せず攻撃に加担してしまう可能性も考えられる。このような問題を回避するためには、特定用途機器の導入に当たって、ベンダがセキュリティパッチを提供していること、ベンダが外部から報告を受けた脆弱性に対応するだけでなく開発時に利用したライブラリ等の脆弱性についても対応可能な体制となっていること等を仕様に盛り込むことを検討するとよい。

また、運用保守の委託先に対して、運用している特定用途機器の脆弱性に対応する必要があることを認識させること、さらに、特定用途機器のバージョンアップやセキュリティパッチの適用手順、実施に当たってのサービスへの影響を把握させることも重要である。

調達元の機関等で対処できないような機器の場合には、特定用途機器の調達に当たって保守契約締結の必要性等について検討することも重要である。

使用していない特定用途機器をインターネットに接続した状態で放置した場合、気が付かない間に特定用途機器が乗っ取られてしまい、不正利用される可能性がある。特に長期休暇中等の長期間に渡って放置した場合は、特定用途機器のソフトウェアに関する新たな脆弱性が発見された場合にセキュリティパッチ等による対策が遅れることや、不正な主体認証の試行が多く繰り返されること等によって、不正利用される可能性が高まることが考えられる。

そのため、特定用途機器を使用しない場合は特定用途機器の電源をオフにすることによって、不正アクセス等のサイバー攻撃を受ける機会を減らすことや、既に受けていたとしても悪用される時間を少なくすることが重要である。

6.4 通信回線

6.4.1 通信回線

目的・趣旨

サーバ装置や端末への不正アクセスやサービス不能攻撃等は、当該サーバ装置や端末に接続された通信回線及び通信回線装置を介して行われる場合がほとんどであることから、通信回線及び通信回線装置に対する情報セキュリティ対策については、情報システムの構築時からリスクを十分検討し、必要な対策を実施しておく必要がある。通信回線の運用主体又は物理的な回線の種類によって情報セキュリティリスクが異なることを十分考慮し、対策を講ずる必要がある。

また、情報システムの運用開始時と一定期間運用された後とでは、通信回線の構成や接続される情報システムの条件等が異なる場合があり、攻撃手法の変化も想定されることから、情報システムの構築時に想定した対策では十分でなくなる可能性がある。そのため、通信回線の運用時においても、継続的な対策を実施することが重要である。

遵守事項

(1) 通信回線の導入時の対策

(a) 情報システムセキュリティ責任者は、通信回線構築時に、当該通信回線に接続する情報システムにて取り扱う情報の格付及び取扱制限に応じた**適切な回線種別を選択**し、情報セキュリティインシデントによる影響を回避するために、通信回線に対して必要な対策を講ずること。

(b) 情報システムセキュリティ責任者は、通信回線において、サーバ装置及び端末のアクセス制御及び経路制御を行う機能を設けること。

(c) 情報システムセキュリティ責任者は、要機密情報を取り扱う情報システムを通信回線に接続する際に、通信内容の秘匿性の確保が必要と考える場合は、通信内容の秘匿性を確保するための措置を講ずること。

(d) 情報システムセキュリティ責任者は、職員等が**通信回線へ情報システムを接続する際に、当該情報システムが接続を許可されたものであることを確認するための措置を講ずること。機関等内通信回線へ機関等支給以外の端末を接続する際**も同様とする。

(e) 情報システムセキュリティ責任者は、**要安定情報を取り扱う情報システム**が接続される通信回線について、当該通信回線の継続的な運用を可能とするための措置を講ずること。

【 基本対策事項 】

＜6.4.1(1)(a)(b)関連＞

6.4.1(1)-1 情報システムセキュリティ責任者は、**通信回線を経由した情報セキュリティインシデントの影響範囲を限定的にするため、通信回線の構成、当該通信回線に接続する情報システムにて取り扱う情報の格付及び取扱制限、拠点等の地理的事情**に応じて、以下を例とする通信経路の分離を行うこと。

a) **外部等との通信を行うサーバ装置及び通信回線装置のセグメントをDMZとして構築**し、内部のセグメントと通信経路を分離すること。

b) 通信が必要な単位でセグメントを分割し、**セグメント間の通信を必要最小限とするアクセス制御を行う**こと。

c) 他の情報システムから独立した**専用の通信回線を構築**すること。

＜6.4.1(1)(c)関連＞

6.4.1(1)-2 情報システムセキュリティ責任者は、通信経路における盗聴及び情報の改ざん等の脅威への対策として、通信内容の秘匿性を確保するための機能を設けること。通信回線の秘匿性確保の方法として、TLS、IPsec等による暗号化を行うこと。また、その際に使用する暗号アルゴリズム及び鍵長については、「電子政府推奨暗号リスト」を参照し決定すること。

＜6.4.1(1)(d)関連＞

6.4.1(1)-3 情報システムセキュリティ責任者は、機関等内通信回線への接続を許可された情報システムであることを確認し、無許可の情報システムの接続を拒否するための機能として、以下を例とする対策を講ずること。

a) 情報システムのMACアドレス等の端末を一意に識別できる情報により接続機器を識別すること。

b) クライアント証明書により接続機器の認証を行うこと。

＜6.4.1(1)(e)関連＞

6.4.1(1)-4 情報システムセキュリティ責任者は、要安定情報を取り扱う情報システム及び非常時優先業務等を支える情報システムが接続される通信回線を構築する場合は、以下を例とする対策を講ずること。

a) 通信回線の性能低下や異常の有無を確認するため、通信回線の利用率、接続率等の運用状態を定常的に確認、分析する機能を設けること。

b) **通信回線及び通信回線装置を冗長構成にする**こと。

c) 端末等が情報システムと通信可能な代替手段を整備すること。

（解説）

通信回線に利用する物理的な回線（通信事業者の回線・公衆無線LAN回線 等）の種別によって、盗聴、改ざん等の脅威及びそれらに対する有効なセキュリティ対策が異なることから、適切な回線を選択することが求められる。

例えば、通信経路の破壊等による可用性への影響を回避することを目的として仮想的な通信回線を複数の通信経路により構築する場合、物理的にも分離された通信経路上にそれぞれ仮想的な通信回線を構築しなければ、本来求められる可用性の維持に関する要件を満たすことにはならない。

要管理対策区域外において機関等外通信回線に接続した端末（支給外端末を含む。）を要管理対策区域で機関等内通信回線に接続することについては、本項に加えて、遵守事項6.1.2(1)(c)及び遵守事項6.1.3(2)(d)にて、接続することの可否の判断、可と判断する場合における安全管理措置に関する規定及び許可手続を求めている。

要安定情報を取り扱う情報システムについては、「（解説）基本対策事項5.2.1(3)-7「要安定情報を取り扱う情報システム及び非常時優先業務等を支える情報システムについて」を参照のこと。

情報セキュリティ対策が十分でない端末等から侵入すると、悪意ある攻撃者は、機関等内通信回線に接続している端末やサーバ装置、通信回線装置などの機器等の脆弱性を含めた情報を収集し、侵入可能な端末等からアクセスが可能な通信経路を用いて侵入範囲の拡大（ラテラルムーブメント：横方向の侵害）を行う。

通信回線を経由した情報セキュリティインシデントの影響範囲を限定的にするためには、通信回線の構成や特性、当該通信回線に接続する情報システムにて取り扱う情報の格付及び取扱制限、拠点等の地理的事情に応じて、例えば拠点などのセグメントごとに通信回線を分離することや、拠点などのセグメント間における通信を必要最小限にするためのアクセス制御をする、いわゆるマイクロセグメンテーションの観点を踏まえた対策が重要である。

地方の拠点や海外の拠点などは、情報セキュリティ責任者による管理が行き届きにくく、情報セキュリティ対策が十分でない場合がある。このため例えば、国外の拠点等から当該情報システムに対して直接通信する必要性がない場合は、相互に直接通信ができないよう通信経路を分離し情報セキュリティインシデントが発生した際に、他の拠点等へ影響を及ぼさない構成にするなどを検討するとよい。

セグメント間のラテラルムーブメントを困難にする観点から、内部ネットワークと他のセグメントとの間にDMZを構築することで、仮に外部から侵入されても、アクセスが可能な範囲を限定的にすることも考えられる。

通信が必要な単位でセグメントを分割し、他のセグメントとの間に次世代ファイアウォール等を設置することや仮想ネットワーク技術を活用する等により、セグメント間の通信を必要最小限とするアクセス制御を行うことが考えられる。

リスクを検討した結果、他の情報システムと共通的な通信回線を利用すると情報システムのセキュリティが確保できないと判断した場合には、他の通信回線から独立させて閉鎖的な通信回線とするなどの構成を採用することが考えられるが、過剰なセキュリティ要件とならないように、閉鎖的な通信回線とする必要性を見極めることが重要である。例えば、通信回線をVLAN等で論理的に分割し、分割された論理的な通信回線ごとに情報セキュリティを確保することで十分要件を満たすのであれば、費用や維持管理の面でメリットがある。このように情報セキュリティ以外の観点とのバランスをとって要件を定めることが重要である。

高い可用性が求められる情報システムを構築する場合は、大規模災害の発生を想定し、通信回線を冗長構成にすることが望ましい。また、機関等の施設から外部に敷設する通信回線の管路についても、例えば、異なる通信事業者が敷設した通信回線による複数の経路で構築することで、災害を受けた際に復旧にかかる時間が短縮されるなどの効果が期待される。

遵守事項

(2) 機関等外通信回線の接続時の対策

(a) 情報システムセキュリティ責任者は、機関等内通信回線にインターネット回線、公衆通信回線等の機関等外通信回線を接続する場合には、機関等内通信回線及び当該機関等内通信回線に接続されている情報システムの情報セキュリティを確保するための措置を講ずること。

(b) 情報システムセキュリティ責任者は、機関等内通信回線と機関等外通信回線との間及び機関等内通信回線内の不正な通信の有無を監視するための措置を講ずること。

(c) 情報システムセキュリティ責任者は、保守又は診断のために、機関等外通信回線から機関等内通信回線に接続された機器等に対して行われる**リモートメンテナンス**に係る情報セキュリティを確保すること。

(d) 情報システムセキュリティ責任者は、電気通信事業者の通信回線サービスを利用する場合には、当該通信回線サービスの情報セキュリティ水準及びサービスレベルを確保するための措置について、情報システムの構築を委託する事業者と**契約時に取り決めておく**こと。

【 基本対策事項 】

＜6.4.1(2)(a)関連＞

6.4.1(2)-1 情報システムセキュリティ責任者は、機関等内通信回線に、インターネット回線や公衆通信回線等の機関等外通信回線を接続する場合には、**外部からの不正アクセスによる被害を防止する**ため、以下を例とする対策を講ずること。

a) ファイアウォール、WAF、プロキシやリバースプロキシ、**次世代ファイアウォール**等により通信制御を行うこと。

b) 通信回線装置による特定の通信プロトコルの利用を制限すること。

c) IDS/IPSにより不正アクセスを検知及び遮断すること。

d) **不審なメールの受信や不審なウェブサイトへのアクセスを遮断する**こと。

e) **サンドボックス型の標的型攻撃対策**をすること。

6.4.1(2)-2 インターネット回線等の機関等外通信回線を用いたクラウドサービスへのアクセスがある場合、**クラウドサービスへのアクセスを可視化し、適切な利用を把握するための対策**を検討すること。

＜6.4.1(2)(b)関連＞

6.4.1(2)-3 情報システムセキュリティ責任者は、機関等内通信回線と機関等外通信回線との間及び機関等内通信回線内の不正な通信の有無を監視するため、以下を例とする監視を行うこと。

a) 機関等外と通信回線で接続している箇所における**外部からの不正アクセスの監視**

b) 不正プログラム感染や踏み台に利用されること等による**機関等外への不正な通信の監視**

c) 不正プログラム等の感染による拡大防止のため、機関等内通信回線の**機器等における不審な通信の監視**

6.4.1(2)-4 情報システムセキュリティ責任者は、特定した監視対象について、監視方法及び監視記録の保存期間を定め、監視記録を保存し、適切に保護、管理すること。

＜6.4.1(2)(c)関連＞

6.4.1(2)-5 情報システムセキュリティ責任者は、機関等外通信回線からの保守又は診断のための機関等内通信回線に接続された機器等に対して行われるリモートメンテナンスのセキュリティ確保のために、以下を全て含む対策を講ずること。

a) リモートメンテナンスを行う主体の認証において**多要素主体認証を用いる**こと。

b) リモートメンテナンスを行う**端末等を制限するアクセス制御**

c) 主体認証によるアクセス制御

d) 通信内容の暗号化による秘匿性の確保

e) ファイアウォール等の通信制御のための機器に例外的な設定を行う場合は、その設定により脆弱性が生じないようにすること。

（解説）

インターネット等の外部ネットワークである機関等外通信回線から機関等内通信回線に接続された機器等に対して行われるリモートメンテナンスについては、職員等が業務アプリケーション等のみへアクセスできるリモートアクセスとは違い、インターネット等の外部ネットワークから機関等内通信回線へのアクセスが前提となることを想定している。インターネット等の外部ネットワークから機関等内通信回線に接続された機器等に対して直接アクセスが可能な場合、インターネット等の外部ネットワークから攻撃を受ける可能性が高くなり、悪意ある攻撃者からのなりすまし等による不正アクセスを受けると、当該機器を踏み台に利用するなどして、他の機器等への被害が拡大するおそれがある。

したがって、インターネット等の外部ネットワークから機関等内通信回線へ接続した機器に対してリモートメンテナンスをする場合は、主体に対して強固な認証技術を用いることやアクセスする端末を限定するなど十分な情報セキュリティを確保する必要がある。

なお、機関等内通信回線に接続した機器等に対して行われるリモートメンテナンスについては、職員等が直接行うリモートメンテナンスのみならず、業務委託として行うリモート運用やリモート保守も含まれることに注意が必要である。また、機関等内通信回線に接続した機器等に対してインターネット等の外部ネットワークから直接接続して行うリモート監視についても同様の情報セキュリティを確保するための措置を講ずることが重要である。

業務委託として行うリモート運用やリモート保守に関しては、4.1「業務委託」の遵守事項も併せて遵守する必要があるため、参照すること。

公衆通信回線サービスを使用する場合においては、回線の利用規約等に記載されているセキュリティレベルやサービスレベルを合意した上で当該回線を選択する必要がある。役務提供契約で通信回線を利用するなど、機関等において直接回線を調達しない場合については、通信回線に求めるセキュリティレベル及びサービスレベルについて、役務提供事業者と合意形成する必要がある。

機関等内通信回線に、インターネット等の外部ネットワークを接続する場合は、外部からの攻撃による脅威から情報システムや情報を守るため、通信回線に対して必要な対策を講ずる必要がある。必要な対策としては、外部からの不正なアクセス等による侵入を防ぐための対策（入口対策）のみならず、侵入されてしまったとしても情報を外部へ漏えいさせないための対策（出口対策）が重要である。入口対策としては、外部からの攻撃や侵入に対する通信を制御及び遮断するため、ファイアウォール、WAF、リバースプロキシ、IDS/IPSなどを利用することが有効である。出口対策としては、外部から侵入させてしまったとしても情報を外部へ漏えいさせないために、ファイアウォールやプロキシ、IPS、次世代ファイアウォールなどを用いて外部への通信を制限及び遮断することが有効である。さらに、入口対策と出口対策の両方で有効なサンドボックス型の標的型攻撃対策を利用することも考えられる。情報システムセキュリティ責任者は、インターネット等の外部ネットワークと接続する場合は、外部からの不正アクセスによる被害を防止するため入口対策と出口対策の両方の対策が含まれるよう必要な対策を組み合わせて講ずる必要がある。

なお、外部からの不正アクセスによる被害を防止するため対策については、通信回線で行う入口対策や出口対策のほか、端末やサーバ装置等に対して行う内部対策も重要であるため、7.2.4「標的型攻撃対策」を参考に必要な対策を実施することが重要である。

次世代ファイアウォールは、機関等内通信回線に接続した端末やサーバ装置等が、インターネット等の外部ネットワークと通信する際に、出口対策として外部ネットワークと通信できるアプリケーションを制限するために有効である。例えば、機関等において許可していないファイル共有サービスにファイルをアップロードしようとする通信を遮断することなどが可能となる。

不審なメールの受信を遮断する手段としては、電子メールフィルタリングのスパムフィルタ機能などが考えられる。また、不審なウェブサイトへのアクセスを遮断する手段としては、ウェブサイトフィルタリングやURLフィルタリングなどの機能が考えられる。これらのような手段を組み合わせて、外部からの不正アクセスによる侵入を防止するとよい。

サンドボックスとは、攻撃されても影響を与えない仮想環境を用意し、不審なファイル等を仮想環境にて動作させ異常がないかを分析するものである。サンドボックス型ではない標的型攻撃対策では、不正プログラムの検出方法として主にシグネチャを用いて検出するが、シグネチャに登録されていない不正プログラムや未知の不正プログラムに関しては、検出できない問題があった。そこで、サンドボックス型の標的型攻撃対策として、不審なファイル等の動作等を隔離された仮想環境において確認し、ファイルの動作等に異常がないかの確認を行うことで、未知の不正プログラムに対してもその挙動において判断することが可能となる。したがって、外部からの不正アクセスによる被害を防止するための対策として、サンドボックス型の対策を検討するとよい。

インターネット回線等の機関等外通信回線を用いてクラウドサービスへアクセスを許可している場合、どの主体がどのような端末を用いてどのようなクラウドサービスへアクセスし、取り扱う情報に対してどのような操作を行ったか等のクラウドサービスを利用する状況を把握することが重要である。クラウドサービスの利用状況を把握することで、情報セキュリティインシデントの可能性を把握することや、未然に防止することが可能となるため、適切な利用を把握するための対策を検討する必要がある。

適切な利用を把握するための対策としては、CASB等の“クラウドサービスの利用度の可視化”や“アクセス制御”などの機能を持つ製品やSASEなどの利用を検討することが考えられる。

外部からの不正アクセスを監視する場合、ファイアウォールのログを監視するだけでは外部からの正常な通信と異常な通信を全て区別することはできない。そこで、IDS/IPSやWAFによって監視することが重要である。

また、外部へ公開しているウェブサーバ等に関しては、外部から短い間隔での大量の認証要求が発生するなどの通常とは異なる現象を監視することも重要である。

機関等内通信回線から機関等外への不審な通信を監視する場合は、ファイアウォールやプロキシ、次世代ファイアウォールなどを監視することが有効である。ただし、ファイアウォールについては、機関等内から機関等外へ特定のポート等を用いた通信は監視することができるものの、多く使われるHTTPS等の通信について監視することは困難である。そのため次世代ファイアウォール等を用いてアプリケーションごとの不正な通信の有無を監視することが有効である。また、プロキシ等による外部への通信の成功の可否を監視することも考えられる。監視する例としては、不正なウェブサイトへのアクセスや通常通信しないアドレスとの通信、通常よりも多い頻度での通信の観測などが考えられる。

悪意ある攻撃者により機関等内通信回線へ侵入された場合、攻撃者は機関等内通信回線に接続されている端末やサーバ装置、通信回線装置などの機器等の脆弱性を含めた情報を収集する。そのため、機関等内通信回線の中で普段は起こり得ない機器同士の通信が発生してないかなど監視をすることが有効である。

多要素主体認証については、基本対策事項7.1.1(1)-2及び「（解説）遵守事項8.1.3(2)(b)「リモートアクセスに対し多要素主体認証を行うこと」について」を参照のこと。

機関等外通信回線からのリモートメンテナンスを行う場合、主体のなりすましなどによる不正アクセス等のリスクが高まる。そのため、強固な主体認証による対策のみならず、リモートメンテナンスを行う端末等を制限し、不正アクセス等の脅威に対抗するための措置を講ずる必要がある。リモートメンテナンスを行う端末等を制限する方法としては、証明書を用いた端末等の認証のほか、事前に端末等を一意に識別できる情報を登録し認証する方法などが考えられる。なお、端末等を一意に識別できる情報を用いる場合、MACアドレスなどの偽装や情報窃取が容易な情報だけを用いてはならない。

遵守事項

(3) 通信回線の運用時の対策

(a) 情報システムセキュリティ責任者は、経路制御及びアクセス制御を適切に運用し、通信回線や通信要件の変更の際及び定期的に、経路制御及び**アクセス制御の設定の確認及び見直しを行う**こと。

(b) 情報システムセキュリティ責任者は、機関等内通信回線と機関等外通信回線との間及び機関等内通信回線内の**不正な通信の有無を監視するための監視対象や監視方法等について、定期的な確認による見直しをする**こと。

(c) 情報システムセキュリティ責任者は、保守又は診断のために、機関等外通信回線から機関等内通信回線に接続された機器等に対して行われるリモートメンテナンスに係る情報セキュリティ対策について、定期的な確認による見直しをすること。

(d) 情報システムセキュリティ責任者は、情報システムの情報セキュリティの確保が困難な事由が発生した場合には、当該情報システムが他の情報システムと共有している通信回線について、共有先の他の情報システムを保護するため、当該通信回線とは別に独立した閉鎖的な通信回線に構成を変更すること。

【 基本対策事項 】

＜6.4.1(3)(c)関連＞

6.4.1(3)-1 情報システムセキュリティ責任者は、機関等外通信回線から保守又は診断のためのリモートメンテナンスに関する以下を全て含む事項について、定期的な確認による見直しを行うこと。

a) リモートからのアクセスが必要な主体

b) リモートメンテナンスを行う端末

c) ファイアウォール等の通信制御のための機器に例外的な設定を行った場合の設定

（解説）

機関等内通信回線にインターネット等の外部ネットワークを接続する場合は、経路制御及びアクセス制御の設定を定期的な確認により見直すことが重要である。特にファイアウォールやWAF、次世代ファイアウォールなどの通信を制御する機器等の設定に関しては、機関等の業務の変化やクラウドサービス、テレワークといった情報システムの利用環境の変化等により、通信の内容が変化することを踏まえて、適切に設定を見直す必要がある。

また、アクセス制御の設定の見直しにより、設定条件を変更又は設定の不備を修正する場合は、情報システムセキュリティ責任者が指名した監督者の監視の下で設定変更等を実施することや、機械的なチェック機能を設けるなど設定や修正によるミス等を防止するための対策を行うことが重要である。なお、設定変更を行う場合は、当該通信回線に接続されている情報システムの情報システムセキュリティ責任者にも事前の連絡及び結果を通知する必要がある。

通信内容については、機関等の業務の変化やクラウドサービス、テレワークといった情報システムの利用環境の変化等により変化することが考えられる。そのような変化に応じて、監視対象や監視方法などが適切であるか定期的な確認により見直しを行う必要がある。見直しの結果、監視対象や監視のための設定、監視方法などに不備があった場合は、修正することが求められる。

6.4.2 通信回線装置

目的・趣旨

インターネット等の外部ネットワークからアクセス可能な通信回線装置においては、ソフトウェアの脆弱性を悪用された不正アクセスの被害を受ける可能性がある。そのため、通信回線装置におけるソフトウェアの脆弱性対策は、迅速かつ適切に対処することが求められる。また、通信回線装置は端末やサーバ装置などの経路制御やアクセス制御に用いるため、情報システムの構築時からリスクを十分検討し、必要なセキュリティ対策を実施しておく必要がある。さらに運用時においても、脅威動向の変化等に応じた継続的な対策を実施することが重要である。

遵守事項

(1) 通信回線装置の導入時の対策

(a) 情報システムセキュリティ責任者は、物理的な通信回線装置を設置する場合、第三者による破壊や不正な操作等が行われないようにすること。

(b) 情報システムセキュリティ責任者は、通信回線装置が動作するために必要な**ソフトウェアに関する事項**を含む実施手順を定めること。

(c) 情報システムセキュリティ責任者は、情報システムのセキュリティ要件として策定した情報システムのネットワーク構成に関する要件内容に従い、通信回線装置に対して**適切なセキュリティ対策を実施する**こと。

(d) 情報システムセキュリティ責任者は、通信回線装置において利用する**ソフトウェアに関連する公開された脆弱性について対策を実施する**こと。

【 基本対策事項 】

＜6.4.2(1)(a)関連＞

6.4.2(1)-1 情報システムセキュリティ責任者は、第三者による通信回線及び物理的な通信回線装置の破壊、不正操作等への対策として、以下を例とする措置を講ずること。

a) 要管理対策区域に設置すること。

b) 物理的な通信回線装置を施錠可能なラック等に設置すること。

c) 機関等の施設内に敷設した通信ケーブルを物理的に保護すること。

d) 物理的な通信回線装置の操作ログを取得すること。

＜6.4.2(1)(b)関連＞

6.4.2(1)-2 情報システムセキュリティ責任者は、通信回線装置が動作するために必要なソフトウェアを定め、ソフトウェアを変更する際の許可申請手順を整備すること。ただし、ソフトウェアを変更することが困難な通信回線装置の場合は、この限りでない。

（解説）

通信回線装置としての機能や動作を明確にするとともに、ソフトウェアの脆弱性に関する対策を確実なものとするために、通信回線装置で使用するソフトウェアについて、バージョンを含めて定めておくことが望ましい。通信回線装置の更新ソフトウェアの提供を受けた際は、更新ソフトウェアに脆弱性を解決するための修正が含まれている可能性があるため、更新内容を確認し修正された脆弱性についての影響度と緊急度を判断し、影響度や緊急度に応じて更新ソフトウェアを適用するまでの時間をできるだけ短くするなどの対策を検討する必要がある。ただし、更新ソフトウェアに新たに機能が追加されるなど通信に影響を与えるような更新がなされる場合は、適用することへの影響を十分に考慮し、切り戻しに備えてバックアップを用意するなどの対策を講じた上で適用する必要がある。

機関等内通信回線にインターネット等の外部ネットワークを接続する場合は、不正アクセス等のリスクを低減するためのネットワーク構成等を構築する必要がある。また、通信回線装置を設定する際は、当該通信回線装置を提供している提供者が提示している推奨設定や業界標準、ベストプラクティス等を参照し、通信回線装置の各種設定を行い、設定の不備等がないようにする必要がある。

通信回線装置の利用を開始する前に通信回線装置で利用するソフトウェアに関連する脆弱性情報を確認し、脆弱性が公開されていた場合は、セキュリティパッチを適用するなどの対策を実施する必要がある。

ソフトウェアの脆弱性については、7.2.1「ソフトウェアに関する脆弱性対策」を参照のこと。

遵守事項

(2) 通信回線装置の運用時の対策

(a) 情報システムセキュリティ責任者は、通信回線装置の運用・保守に関わる作業等により**通信回線装置の設定変更等を実施する場合**は、情報セキュリティインシデント発生時の調査対応のための作業記録を取得し保管すること。

(b) 情報システムセキュリティ責任者は、**要安定情報を取り扱う情報システム**を構成する通信回線装置については、運用状態を復元するために必要な設定情報等のバックアップを取得し保管すること。

(c) 情報システムセキュリティ責任者は、通信回線装置が動作するために必要なソフトウェアの状態等を調査し、認識した脆弱性等について対策を講ずること。

【 基本対策事項 】

＜6.4.2(2)(c)関連＞

6.4.2(2)-1 情報システムセキュリティ責任者は、通信回線装置が動作するために必要な**ソフトウェアの状態を定期的に調査（脆弱性の確認を含む。）し、許可されていないソフトウェアがインストールされているなど、不適切な状態**にある通信回線装置を認識した場合には、改善を図ること。

（解説）

通信回線装置の運用・保守に関わる作業等により通信回線装置の設定変更等を実施する場合は、情報システムセキュリティ責任者が指名した監督者の監視の下で設定変更等を実施することや、機械的なチェック機能を設けるなど設定変更等によるミス等を防止するための対策を行うことが重要である。なお、設定変更を行う場合は、当該通信回線に接続されている情報システムの情報システムセキュリティ責任者にも事前の連絡及び結果の通知を行う必要がある。

要安定情報を取り扱う情報システムについては、「（解説）基本対策事項5.2.1(3)-7「要安定情報を取り扱う情報システム及び非常時優先業務等を支える情報システム」について」を参照のこと。

通信回線の重要性、想定される脅威及び機器の特性等から調査の必要性及び調査の間隔を検討する必要がある。例えば、基幹回線等の重要な通信回線を構成する機器、ファイアウォールのようにインターネット等と直接接続されている機器、頻繁にソフトウェアがアップデートされるような機器等は、ソフトウェアの脆弱性等の調査の必要性が高く、より短期間に繰り返し調査を実施することが考えられる。また、そのような重要な通信回線を構成する機器に関しては、脆弱性に関する情報を製品ベンダや脆弱性情報提供サイト等から通知を受け取るようにするとともに、内閣官房国家サイバー統括室やJPCERT/CC、情報処理推進機構（IPA）等からの注意喚起も参照し、常に確認できるようにする必要がある。必要性が低いと判断された機器についても、利用するソフトウェア等の脆弱性が報告された場合や、通信回線の構成変更が発生した場合に随時調査することが望ましい。

不適切な状態とは、許可されていないソフトウェアがインストールされている、ソフトウェアの脆弱性が公開されているが適切な対策が取られていない、定められたソフトウェアが動作するための設定が適切でないなどの状態のことを指す。

遵守事項

(3) 通信回線装置の運用終了時の対策

(a) 情報システムセキュリティ責任者は、通信回線装置の運用を終了する場合には、当該通信回線を構成する通信回線装置が運用終了後に再利用された時又は廃棄された後に、運用中に保存していた情報が漏えいすることを防止するため、当該通信回線装置の電磁的記録媒体に記録されている全ての**情報を抹消するなど適切な措置**を講ずること。

【 基本対策事項 】規定なし

（解説）

抹消の方法としては、通信回線装置の初期化、内蔵電磁的記録媒体の物理的な破壊等の方法がある。通信回線装置内にも、設定情報や通信ログ等の情報が保存されていることから、サーバ装置及び端末と同様に運用終了時に留意が必要である。

通信回線装置は通信事業者からリース提供されることがあり、その場合は通信回線の運用終了に伴い通信事業者に装置を返却することになるため、通信回線装置の初期化の手順等本項を遵守するための方法について、通信事業者に確認する必要がある。

6.4.3 無線LAN

目的・趣旨

無線LANは、有線の通信回線及び通信回線装置において想定される脅威に加え、電波を利用するために有線と比較して通信の傍受等が容易であることに起因する脅威への対策が必要である。

なお、本款の遵守事項の他、6.4.1「通信回線」及び6.4.2「通信回線装置」において定める導入時の対策に係る遵守事項についても併せて遵守する必要がある。

遵守事項

(1) 無線LAN環境導入時の対策

(a) 情報システムセキュリティ責任者は、無線LAN技術を利用して機関等内通信回線を構築する場合は、通信回線の構築時共通の対策に加えて、通信内容の秘匿性を確保するために通信路の暗号化を行った上で、その他の情報セキュリティ確保のために必要な措置を講ずること。

【 基本対策事項 】

＜6.4.3(1)(a)関連＞

6.4.3(1)-1 情報システムセキュリティ責任者は、無線LAN技術を利用して機関等内通信回線を構築する場合は、通信回線の構築時共通の対策に加えて、情報システムの分類に基づき、以下の対策を講ずること。

**【基本セキュリティ対策】**以下を全て含む対策を講ずること。

a) 無線LAN通信の暗号化

b) 無線LAN回線利用申請手続の整備

c) **無線LAN機器の管理**手順の整備

d) **来訪者等に提供する無線LANによるインターネット接続回線**と業務で使用する機関等LANシステムの分離

**【追加セキュリティ対策】**基本セキュリティ対策の実施に加えて、以下を例とする対策を講ずること。

e) IEEE 802.1Xによる無線LANへのアクセス主体の認証

（解説）

暗号化方式として、例えばWPA3 Enterprise（Wi-Fi Protected Access 3 Enterprise）やWPA2 Enterprise（Wi-Fi Protected Access 2 Enterprise）方式を選択することが考えられる。WEP（Wired Equivalent Privacy）、TKIP（Temporal Key Integrity Protocol）等は、比較的容易に解読できたり、通信を妨害できたりするという脆弱性が報告されており、利用してはならない。他の暗号化方式においても同様の問題が起こる可能性があるため、最新の情報に従い適切な方式や設定値を選択することが求められる。

無線LAN機器の管理については、以下の例が考えられる。

なお、無線LAN回線を構築する場合は、以下を参考にするとよい。

参考：総務省「国民のためのサイバーセキュリティサイト」の「職場での対策」、「システムを“利用”する人向けの対策」にある「安全な無線LANの利用」のページの解説 （https://www.soumu.go.jp/main_sosiki/cybersecurity/kokumin/security/business/staff/03/）

機関等の無線LAN環境を来訪者等に提供する場合、来訪者等が機関等LANシステムに侵入することによって、情報の漏えいや改ざんなどが行われる可能性がある。そのため、来訪者等に提供する無線LANと機関等LANシステムをルータ等の通信回線装置によって論理的に分離する対策等が考えられる。

なお、来訪者等に向けた無線LANによるインターネット接続回線を提供する際には以下を参考にするとよい。

参考：総務省「無線LANビジネスガイドライン」 （https://www.soumu.go.jp/main_content/000620877.pdf）

参考：総務省「公衆Wi-Fi提供者向け セキュリティ対策の手引き」（https://www.soumu.go.jp/main_sosiki/cybersecurity/wi-fi/）

IEEE 802.1X認証については、機関等LANシステム等の無線LANにおいて要機密情報を扱う場合は、高度な情報セキュリティ対策を要求する情報システムに該当する場合に限定せず、導入することが望ましい。

IEEE 802.1X認証で用いられるEAPの規格について、脆弱性が指摘されているEPA-MD5やLEAP等の認証方式もあるため、利用する規格についてセキュリティ上問題が無いか確認する。

また、偽のアクセスポイントを利用した攻撃等へ対抗するためにも相互認証に対応した規格を利用すること。また、認証に用いる識別符号（識別コード及びパスワード、電子証明書等）の安全な配布方法と運用手順についても整備する。

6.4.4 IPv6通信回線

目的・趣旨

近年では、サーバ装置、端末及び通信回線装置等にIPv6技術を利用する通信（以下「IPv6通信」という。）を行う機能が標準で備わっているものが多く出荷されている。IPv6通信プロトコルでは、グローバルIPアドレスによるパケットの直接到達性などを考慮する必要があり、設定不備によっては運用者が意図しないIPv6通信が通信ネットワーク上で動作し、結果として、不正アクセスの手口として悪用されるおそれもある。このため、必要な対策を講じていく必要がある。

遵守事項

(1) IPv6通信を行う情報システムに係る対策

(a) 情報システムセキュリティ責任者は、IPv6技術を利用する通信を行う情報システムを構築する場合は、製品として調達する機器等について、IPv6 Ready Logo Programに基づくPhase-2準拠製品を、可能な場合には選択すること。

(b) 情報システムセキュリティ責任者は、IPv6通信の特性等を踏まえ、IPv6通信を想定して構築する情報システムにおいて、IPv6通信による情報セキュリティ上の脅威又は脆弱性に対する検討を行い、必要な措置を講ずること。

【 基本対策事項 】

＜6.4.4(1)(b)関連＞

6.4.4(1)-1 情報システムセキュリティ責任者は、以下を全て含むIPv6通信による情報セキュリティ上の脅威又は脆弱性に対する検討を行い、必要な措置を講ずること。

a) グローバルIPアドレスによる直接の到達性における脅威

b) IPv6通信環境の設定不備等に起因する**不正アクセスの脅威**

c) IPv4通信とIPv6通信を情報システムにおいて**共存させる際の処理考慮漏れに起因する脆弱性**の発生

d) アプリケーションにおける**IPv6アドレスの取扱い考慮漏れに起因する脆弱性**の発生

（解説）

IPv6通信を想定して構築する情報システムにおいて、グローバルIPアドレスによる通信パケットの直接到達性における脅威に対抗するために、以下を例に対策を講ずることが考えられる。

IPv6の特徴として、アドレスが長いこと、アドレスの省略形が複数パターン存在して一意に定まらない可能性があること、端末が複数のIPアドレスを持つこと等が挙げられる。このため、複雑なアクセス制御の設定が必要になり、設定不備等による不正アクセスにつながるリスクが想定される。

対策としては、外部ネットワークとの通信において、OSI基本参照モデルのネットワーク層（第３層）及びトランスポート層（第４層）を中心にフィルタリングを行う機能及び断片化された通信の再構築を行う機能を適切に設定すること等、通信機器を流れる通信そのものを制御することが挙げられる。

なお、IPv6通信を想定して構築する情報システムにおいて、IPv6のログを取得し、分析する場合は、IPv6アドレスでは桁数が大幅に増えること等から、IPv6対応のログの解析ツールを利用することで、IPv6アドレスの読み間違い等の運用上の作業ミスを軽減するための対策を検討することが望ましい。

IPv6通信プロトコルに対応している端末やサーバ装置には、多様なIPv6移行機構（デュアルスタック機構、IPv6-IPv4トンネル機構等）が実装されている。それらのIPv6移行機構は、それぞれが想定する使用方法と要件に基づき設計されていることから、その選定と利用に当たっては、セキュリティホールの原因をつくらないよう十分な検討と措置を講ずる必要がある。

例えば、デュアルスタック機構を運用する場合には、IPv4のプライベートアドレスを利用したイントラネットの情報システムであっても外部ネットワークとのIPv6通信が可能となるため、デュアルスタック機構を導入したサーバ装置及び端末を経由した当該外部ネットワークからの攻撃について対策を講ずる必要がある。また、IPv6-IPv4トンネル機構を運用する場合、トンネルの終端が適切に管理されないと本来通信を想定しないネットワーク間のIPv6通信が既設のIPv4ネットワークを使って可能となるため、機関等のネットワークが外部から攻撃される危険性がある。管理されたサーバ装置及び端末以外のトンネル通信を当該IPv4ネットワークに設置されたファイアウォールにて遮断するなど、不適切なIPv6通信を制御する対策を行う必要がある。

IPv4のみに対応する機器及びソフトウェアがIPv6ネットワーク上で動作する際、システム内部でのIPアドレスの取扱いがIPv4に依存している場合、IPv6アドレスが取り扱えない、又はバッファオーバーラン等を引き起こす可能性があるというリスクを認識し、これが無いことを確認するなどが挙げられる。統合認証システムや、システム間連動を行うようなアプリケーションでは、IPv4/IPv6が混在した状況でも適切なシステム連携を行う必要がある。

また、IPv4対応システムがIPv6アドレスに対応するため、IPv6／IPv4コンバータ等が使用される場合がある。このような場合、内部からは個別のIPv6アドレスを特定できないため、通信ログの取得やパケットフィルタリング等の機能を実装し運用する際等において留意が必要である。

遵守事項

(2) 意図しないIPv6通信の抑止・監視

(a) 情報システムセキュリティ責任者は、サーバ装置、端末及び通信回線装置を、IPv6通信を想定していない通信回線に接続する場合には、自動トンネリング機能で想定外のIPv6通信パケットが到達する脅威等、当該通信回線から受ける不正なIPv6通信による情報セキュリティ上の脅威を防止するため、**IPv6通信を抑止するなどの措置**を講ずること。

【 基本対策事項 】規定なし

（解説）

複数の機関等の間及び機関等内のみで利用する情報システムについて、通信回線がIPv6通信を想定していない場合には、当該通信回線に接続される端末等のIPv6通信の機能を停止する必要がある。ただし、当該端末等のOSやOSのバージョン等によってIPv6通信の機能を停止することが推奨されていない場合は、当該端末等のIPv6通信の優先度をIPv4より低くする等、当該端末等のOSやOSのバージョン等において推奨される設定を行う必要がある。

IPv6通信を想定していない通信回線においては、ファイアウォールやIDS/IPS等のセキュリティ機能に不正なIPv6通信を制御する措置が講じられず、悪意ある者によるIPv6通信を使った攻撃に対して無防備となるおそれがある。さらに、IPv6通信が可能なサーバ装置及び端末においては、IPv4ネットワークに接続している時でもIPv6通信による当該サーバ装置及び端末への接続を可能とする自動トンネリング機能を提供するものがある。この機能を利用すると、サーバ装置及び端末と外部のネットワークとの間に情報システムの利用者や情報システムの運用管理者が気付かないうちに意図しない経路が自動生成され、これがセキュリティを損なうバックドアとなりかねないことから、自動トンネリング機能を動作させないようサーバ装置及び端末を設定する必要がある。また、ルータ等の通信回線装置についてもIPv6通信をしないよう設定し、意図しないIPv6通信を制限することが求められる。

なお、「政府情報システムに係るIPv6対応の取組について」（2011年11月２日各府省情報化統括責任者（CIO）連絡会議決定）においてIPv6対応の取組を進めることが確認されているが、外部と直接通信を行う情報システム等についても、現時点においてIPv6対応がされていない場合には、意図しないIPv6通信を抑止又は遮断するための措置を講ずる必要がある。

6.5 ソフトウェア

6.5.1 情報システムの基盤を管理又は制御するソフトウェア

目的・趣旨

情報システムの基盤を管理又は制御するソフトウェアは、情報システムを制御する上でセキュリティ上の重要な機能を有している。そのようなソフトウェアは悪用や不正アクセスされた場合、被害が広範囲に及ぶ可能性がある。したがって、情報システムの基盤を管理又は制御するソフトウェアを利用する端末やサーバ装置、通信回線装置等及びソフトウェア自体において、必要なセキュリティ対策を実施する必要がある。

本款では、情報システムの基盤を管理又は制御するソフトウェアを利用する場合に求めるセキュリティ対策として、7.1「情報システムのセキュリティ機能」で求めている対策から特に必要と考えられるものを示しており、本款以外に7.1.1「主体認証機能」で定める主体認証機能の導入、7.1.2「アクセス制御機能」で定めるアクセス制御機能の導入、7.1.3「権限の管理」で定める権限の管理、7.1.4「ログの取得・管理」で定めるログの取得に係る遵守事項についても併せて遵守する必要があるが、情報システムの基盤を管理又は制御するソフトウェアの機能や仕様等を踏まえて、適切な対策を講ずることが重要となる。

また、当該ソフトウェアを利用する際の操作ミスや設定不備などを防ぐためには、当該ソフトウェアの利用者や管理者が利用するソフトウェアを利用するための手順を整備することも重要である。さらに、情報システムの基盤を管理又は制御するソフトウェアを悪用した攻撃を防ぐにはソフトウェアの脆弱性対策が特に重要となる。当該ソフトウェアに関係する脆弱性に関する情報を製品ベンダや脆弱性情報提供サイト等からの通知を受け取るようにするとともに、公開された脆弱性についての影響度と緊急度に応じてセキュリティパッチ等を適用するまでの時間をできるだけ短くするなどの対策を検討する必要がある。脆弱性対策については、7.2.1「ソフトウェアに関する脆弱性対策」を参照し確実な対策を実施することが重要である。

遵守事項

(1) 情報システムの基盤を管理又は制御するソフトウェア導入時の対策

(a) 情報システムセキュリティ責任者は、情報セキュリティの観点から**情報システムの基盤を管理又は制御するソフトウェアを導入する端末、サーバ装置、通信回線装置等及びソフトウェア自体を保護するための措置**を講ずること。

(b) 情報システムセキュリティ責任者は、利用するソフトウェアの特性を踏まえ、以下の全ての実施手順を整備すること。

(ア) 情報システムの基盤を管理又は制御するソフトウェアの**情報セキュリティ水準の維持に関する手順**

(イ) 情報システムの基盤を管理又は制御するソフトウェアで発生した**情報セキュリティインシデントを認知した際の対処手順**

【 基本対策事項 】規定なし

（解説）

情報システムの基盤を管理又は制御するソフトウェアは、端末やサーバ装置、ネットワークなどを管理又は制御するための権限を用いてアクセスが可能な機能を有しているソフトウェアを想定しており、当該ソフトウェアが悪用された場合、被害が広範囲に及ぶリスクが高くなる。また、当該ソフトウェアにおいて要機密情報が取り扱われる場合は、当該ソフトウェアを保護することで情報を守る必要がある。したがって、情報システムの基盤を管理又は制御するソフトウェアを導入する端末、サーバ装置、通信回線装置等及び当該ソフトウェア自体については、必要な措置を講ずる必要がある。なお、情報システムの基盤を管理又は制御するソフトウェアについては、以下のソフトウェアが考えられる。

情報システムの基盤を管理又は制御するソフトウェアを導入する場合、当該ソフトウェア自体を保護するのみならず、当該ソフトウェアを動作させる端末、サーバ装置、通信回線装置等も保護する必要がある。当該ソフトウェアを保護するための対策としては、以下の各款における規定内容が有効であるため、それぞれに示される対策を行う必要がある。

特に情報システムの基盤を管理又は制御するソフトウェアを導入する端末やサーバ装置、通信回線装置等及び当該ソフトウェア自体の管理者権限を有する識別コードについては、なりすましによって不正アクセスによる被害を受けた場合、被害が広範囲に及ぶ可能性があることから、原則として多要素主体認証を用いることを検討するとよい。さらに、当該ソフトウェアへのアクセスは必要最小限となるよう、ネットワークセグメントを分離したアクセス制御や当該ソフトウェアのアクセスは認めた主体のみがアクセス可能となるよう制限する他、他のソフトウェアやサービスと連携する機能を有している場合の適切な認証をするなど、アクセス権限を最小限にし、不正なアクセスがないことを監視するなどの措置も有効である。

情報システムの基盤を管理又は制御するソフトウェアは、端末やサーバ装置、通信回線装置などを管理又は制御するための権限を用いてアクセスが可能な機能を有しているものを想定しており、そのようなソフトウェアを悪用された場合、被害が広範囲に及ぶリスクが高くなる。

情報システムの基盤を管理又は制御するソフトウェアは、情報システムの構成要素を管理又は制御する上で重要な機能を有しているため、セキュリティに関する設定などに関しては不備がないように管理することが重要である。そのため、当該ソフトウェアが管理又は制御する情報システム全体のセキュリティ水準を保つための設定や構成に関しては、文書にすることが重要である。さらに、ソフトウェアを安全に使用及び管理するため、情報システム全体に影響を及ぼすような重要な操作や情報セキュリティに関する設定や構成を変更する際の手順も整備することが重要である。なお、情報システム全体に影響を及ぼす操作や設定変更等を実施する際は、監督者の指揮の下で実施するなどの対策も含めるとよい。

情報セキュリティインシデントを認知した際の対処手順に関しては、ソフトウェアの個別の事情に合わせて検討する必要がある。情報システムセキュリティ責任者は、情報システムの基盤を管理又は制御するソフトウェアにおいて情報セキュリティインシデントを認知した際は、機関等で定められた対処手順又はCSIRTの指示若しくは勧告に従って、適切に対処する必要がある。また、情報セキュリティインシデントが発生すると、当該ソフトウェアが管理又は制御する権限を用いて他の機器等に対して不正なアクセスがなされる等が発生し、被害が広範囲に及ぶ可能性がある。したがって、利用するソフトウェアの仕様や機能等を踏まえて情報セキュリティインシデントを認知した際の対処手順を整備する必要がある。

なお、統括情報セキュリティ責任者が整備する対処手順（「（解説）遵守事項2.2.4(1)(b)「対処手順」について」を参照のこと。）が、当該ソフトウェアの事情に応じた内容で整備されているならば、個別に整備しなくても構わない。

遵守事項

(2) 情報システムの基盤を管理又は制御するソフトウェア運用時の対策

(a) 情報システムセキュリティ責任者は、情報システムの基盤を管理又は制御するソフトウェアを運用・保守する場合は、以下の全てのセキュリティ対策を実施すること。

(ア) 情報システムの基盤を管理又は制御するソフトウェアのセキュリティを維持するための対策

(イ) 脅威や情報セキュリティインシデントを迅速に検知し、対応するための対策

【 基本対策事項 】

＜6.5.1(2)(a)(ア)関連＞

6.5.1(2)-1 情報システムセキュリティ責任者は、情報システムの基盤を管理又は制御するソフトウェアのセキュリティを維持するため、権限設定やアクセス制御、セキュリティ設定が適切であるか**定期的な確認をする**こと。

＜6.5.1(2)(a)(イ)関連＞

6.5.1(2)-2 情報システムセキュリティ責任者は、情報システムの基盤を管理又は制御するソフトウェアにおいて、脅威や情報セキュリティインシデントを迅速に検知し、対応するため、以下の全ての対策を実施すること。

a) 情報システムの基盤を管理又は制御するソフトウェアの**情報セキュリティ水準の維持に関する手順に基づく教育の実施**

b) 情報セキュリティインシデントを認知した際の対処手順に基づく訓練

（解説）

情報システムの基盤を管理又は制御するソフトウェアを管理するための権限や当該ソフトウェアを利用できる識別コードなどについては、適切な付与であることを継続的に確認する必要がある。特に、アクセスが不要となった識別コードは、すみやかに削除又は無効化するなどの対策をする必要がある。また、当該ソフトウェアのセキュリティ設定についても正しく設定されているか定期的に確認する必要がある。例えば、当該ソフトウェアのバージョンアップ等を行った際は、新たな機能が追加されるなどのセキュリティに関する設定が変更になっていないかなどを確認するとよい。

情報システムの基盤を管理又は制御するソフトウェアは、情報システムの構成要素を管理又は制御する上で重要な機能を有しているため、ソフトウェアを安全に使用及び管理する必要がある。当該ソフトウェアを初めて運用管理する職員等や重要な操作を行う職員等に対しては、ソフトウェアの情報セキュリティ水準の維持に関する手順に基づき教育を実施することが重要である。

情報システムの基盤を管理又は制御するソフトウェアにて制御又は管理している機器等において、情報セキュリティインシデントが発生した場合に備えて、当該ソフトウェアを利用した対処手順等を定期的に確認する必要がある。対処手順の訓練の方法としては、机上における訓練の他、実機を用いた訓練などの方法があり、どのような手段を用いて確認するかは、対処手順を整備してからの経過時間、対処に係る訓練の度合い等を踏まえて決めるとよい。なお、対処手順に基づく訓練について、2.2.4「情報セキュリティインシデントへの対処」又は5.3「情報システムの運用継続計画」において他の訓練と一緒に実施している場合は、個別に実施する必要はない。

6.6 アプリケーション・コンテンツ

6.6.1 アプリケーション・コンテンツの作成・運用時の対策

目的・趣旨

機関等では、情報の提供、行政手続、意見募集等の行政サービスのためにアプリケーション・コンテンツを用意し、広く利用に供している。利用者がこれらのアプリケーション・コンテンツを利用する際に、利用者端末の情報セキュリティ水準の低下を招いてしまうことは避けなければならない。機関等は、アプリケーション・コンテンツの提供に際しても、情報セキュリティ対策を講じておく必要がある。

また、アプリケーション・コンテンツの開発・提供を業務委託する場合については、4.1「業務委託」についても併せて遵守する必要がある。

遵守事項

(1) アプリケーション・コンテンツの作成に係る運用規程の整備

(a) 統括情報セキュリティ責任者は、**アプリケーション・コンテンツの提供時に機関等外の情報セキュリティ水準の低下を招く行為を防止するための運用規程を整備**すること。

【 基本対策事項 】規定なし

（解説）

行政サービスは、アプリケーションプログラムやウェブコンテンツ等を用いて国民等に提供されている。特にウェブコンテンツでは、機関等以外が提供するコンテンツ（以下「外部コンテンツ」という。）を組み込むことによって、容易に様々な機能を提供することが可能となるが、機関等において外部コンテンツの信頼性を担保することは不可能であることから、このような利用方法には注意が必要である。例えば、外部コンテンツが事前に通知されることなく変更されてしまい、行政サービスの利用者の意図に反して利用者の個人に関する情報が取得される可能性がある。また、外部コンテンツに不正プログラムが組み込まれ、行政サービスの利用者がそれに感染する被害が生じることも考えられる。そのため、ウェブコンテンツでは外部コンテンツを利用しないことが望ましいが、必要があって利用する場合には、これらの脅威に対して適切なセキュリティ対策を実施することが求められる。

国民等が機関等によって提供される行政サービスを利用する場合、行政サービスの利用によって、利用者の端末が不正プログラムに感染しやすい状況を強制することや、利用者個人の情報が利用者の意図に反して第三者に提供させられるといった状況を作り出すことは避けなければならない。機関等は、機関等外の情報システム利用者の情報セキュリティ水準を低下させないように留意して、行政サービスのためのアプリケーション・コンテンツを提供する必要がある。

統括情報セキュリティ責任者は、アプリケーション・コンテンツの提供に関する運用規程の整備に当たり、遵守事項6.6.1(2)以降において規定した事項を含める必要がある。

遵守事項

(2) アプリケーション・コンテンツのセキュリティ要件の策定

(a) 情報システムセキュリティ責任者は、機関等外の情報システム利用者の情報セキュリティ水準の低下を招かぬよう、アプリケーション・コンテンツについてのセキュリティ要件を定め、仕様に含めること。

(b) 職員等は、アプリケーション・コンテンツの開発・作成を業務委託する場合において、前項に掲げる内容を**調達仕様に含める**こと。

【 基本対策事項 】

＜6.6.1(2)(a)関連＞

6.6.1(2)-1 情報システムセキュリティ責任者は、提供するアプリケーション・コンテンツが**不正プログラムを含まない**ことを確認するために、以下を全て含む対策をセキュリティ要件として仕様に含めること。

a) アプリケーション・コンテンツを提供する前に、不正プログラム対策ソフトウェアを用いて検査を行い、不正プログラムが含まれていないことを確認すること。

b) 業務委託により作成したアプリケーションプログラムを提供する場合には、委託先事業者に、当該アプリケーションの仕様に反するプログラムコードが含まれていないことを確認させること。

6.6.1(2)-2 情報システムセキュリティ責任者は、提供するアプリケーション・コンテンツが**脆弱性を含まない**ように開発することをセキュリティ要件として仕様に含めること。

6.6.1(2)-3 情報システムセキュリティ責任者は、実行プログラムの形式以外にコンテンツを提供する手段がない場合を除き、**実行プログラムの形式でコンテンツを提供しない**ことをセキュリティ要件として仕様に含めること。

6.6.1(2)-4 情報システムセキュリティ責任者は、電子証明書を用いた署名等、提供するアプリケーション・コンテンツの**改ざん等がなく真正なものであることを確認できる手段をアプリケーション・コンテンツの提供先に与える**ことをセキュリティ要件として仕様に含めること。

6.6.1(2)-5 情報システムセキュリティ責任者は、提供するアプリケーション・コンテンツの利用時に、**脆弱性が存在するバージョンのOSやソフトウェア等の利用を強制するなどの情報セキュリティ水準を低下させる設定変更を、OSやソフトウェア等の利用者に要求する**ことがないよう、アプリケーション・コンテンツの提供方式を定めて開発することをセキュリティ要件として仕様に含めること。

6.6.1(2)-6 情報システムセキュリティ責任者は、**サービス利用者その他の者に関する情報が本人の意思に反して第三者に提供されるなど、サービス利用に当たって必須ではない機能**がアプリケーション・コンテンツに組み込まれることがないよう、以下を全て含む開発をすることをセキュリティ要件として仕様に含めること。

a) 機関等外のウェブサイト等のサーバへ自動的にアクセスが発生する機能が仕様に反して組み込まれていないことを、HTMLソースを表示させるなどして確認すること。**必要があって当該機能を含める場合**は、当該機関等外へのアクセスが情報セキュリティ上安全なものであることを確認すること。

b) 本来のサービス提供に必要のない**機関等外へのアクセスを自動的に発生させる機能**を含めないこと。

（解説）

例えば、機関等が何らかのキャンペーンとして啓発コンテンツを提供する際に、その作成を広告会社等に業務委託する場合は、情報システム部門以外の職員等がその業務委託の調達仕様を定めることになると考えられる。このような場合でも、機関等外の情報セキュリティ水準を低下させないよう、前項に掲げるセキュリティ要件を調達仕様に含めることが求められる。

不正プログラムを含まないようにすべきものは、機関等外の利用者の端末にインストールさせるプログラムの他、利用者に閲覧させるウェブサイトのウェブページも含む。

脆弱性は、アプリケーションプログラムが動作するOSや利用する開発言語によって様々な種類のものが存在する。例えば、C言語によって開発されたアプリケーションプログラムにバッファオーバーフローの脆弱性を意図せず埋め込む可能性があり、脆弱性が原因で利用者の端末上で任意のプログラムを実行される可能性がある。したがって、脆弱性を埋め込ませない、セキュアコーディングとコードの正常性を担保するテストを実施する必要がある。脆弱性が含まれないことを確認するための手段として、ソースコード診断等があり、開発するアプリケーション・コンテンツに応じて脆弱性診断を行うことを検討するとよい。なお、脆弱性診断については、「（解説）基本対策事項7.2.1(1)-1「脆弱性診断を実施」について」を参照のこと。

実行プログラムの形式とは、利用者がダブルクリックするなどしてファイルを開いたときに自動的にプログラムコード（当該ファイルの作成者が意図した任意のコード）が実行される形式のファイルのことであり、拡張子が「.exe」の形式のものがこれに該当するほか、「.pif」、「.scr」、「.bat」等のものも該当する。本基本対策事項に違反する例としては、会議資料等のプログラムではない文書を提供する際に、自己展開式圧縮ファイル作成ソフトウェアを用いて拡張子が「.exe」の圧縮ファイルを作成してこれを配布する行為が典型例として挙げられる。多数に及ぶ会議資料等のファイルを１個のファイルとして提供する必要がある場合には、拡張子「.zip」等の形式の圧縮ファイルを作成して配布すればよい。

なお、電子メールの添付により文書等を配布する場合については、「（解説）基本対策事項8.1.1(2)-2 d)「実行プログラム形式のファイルを削除等する」について」を参照のこと。

実行プログラムの形式は、不正プログラムがその感染手段として悪用することが多いため、基本的に開かないようにしなければならない。それにもかかわらず、機関等が日頃から実行プログラムの形式でのコンテンツ提供を行う場合、機関等の職員等だけでなく、一般の行政サービスの利用者に対しても、実行プログラムの形式のファイルを開くことに慣れさせてしまうことになり、利用者の情報セキュリティ水準を低下させてしまうことになる。そのため、本基本対策事項は、実行プログラムの形式でのコンテンツ提供をしないよう求めている。

なお、機関等が行政サービスのためにアプリケーションプログラムを提供する必要がある場合等、「実行プログラムの形式以外にコンテンツを提供する手段がない」場合は、実行プログラムの形式で提供してもよいが、基本対策事項6.6.1(2)-4に従った措置を講ずる必要がある。

改ざん等がなく真正なものであることを確認できる手段としては、電子証明書を用いた電子署名が有効である。

利用者に提供するものがアプリケーションプログラムである場合は、「コードサイニング証明書」と呼ばれる電子証明書を用いてアプリケーションプログラムに署名を施すことがこれに該当する。利用者はアプリケーションプログラムに施された署名を確認することで、改ざんがないことを確認でき、さらに、そのアプリケーションプログラムの提供者が機関等であることを確認できる。なお、電子署名が使用できない場合は、プログラムのハッシュ値を取得し、そのハッシュ値をウェブサイト等において提供する手法も考えられる。なお、ハッシュ値を取得する際に使用するハッシュ関数については、SHA-256などいくつか種類があるため、利用者が確認する際に判断できるように使用したハッシュ関数についても提供する必要がある。

利用者に提供するものが文書ファイルである場合は、文書ファイルに対応するアプリケーションが備える電子署名機能を利用することができる。文書ファイルは、原則として電子署名を施すことが望ましいが、文書ファイルの形式によっては、電子署名を施すアプリケーションが提供されていない場合があるが、こうした場合はTLSにより通信路を保護したウェブページから当該電子ファイルをダウンロードするとともに、アプリケーションプログラムと同様にハッシュ値を用いて改ざんされていないことを確認することができるようにする等の対応が求められる。

提供するコンテンツがウェブサイト上にある場合には、TLSを用いた「」で始まるURLのウェブページとすることができる。これにより、利用者は現在閲覧しているウェブページが「https://」で始まるURLのウェブページであることを目視確認の上で、そこからリンクをクリックするなどしてファイルをダウンロードする手順を踏むことにより、当該ファイルは、暗号化された通信によって改ざんなくダウンロードされることになる。TLSを用いる際に、機関等のサーバ証明書を用いれば、当該サイトが機関等のものであることを確認できる。

コンテンツを電子メールで提供する場合には、S/MIME等の電子署名の技術を用いることで、電子メールが配送途中で改ざんされていないこと及び発信者が機関等であることを確認できる。

行政サービスを提供する情報システムの提供において、当該情報システムを利用するために、機関等外の事業者等が作成した汎用のソフトウェアやミドルウェアのインストールが利用者の端末で必要となる場合がある。この場合、利用者は機関等から指示されたソフトウェアを自身の端末にインストールせざるを得ないが、指定されるソフトウェア（又はソフトウェアバージョン）のサポート期間が過ぎているなどの理由により脆弱性が存在するものであると、利用者の情報セキュリティ水準を機関等が低下させることになる。したがって、脆弱性が存在するバージョンのOSの利用やソフトウェアのインストールを機関等が暗黙又は明示的に要求することにならないよう、利用者に使用を求めるソフトウェアのサポート状況を考慮した上で、アプリケーション・コンテンツの提供方式を定めて開発しなければならない。

具体的には、当該行政サービスを提供するシステムが準備された時点では脆弱性が発見されていなくても、運用開始後に発見されることがある。そのとき、利用者が迅速に当該脆弱性を回避できるようになっている必要がある。例えば、当該行政サービスを利用するために、第三者が提供している汎用のソフトウェアのインストールを必要としていたとする。このとき、当該ソフトウェアに脆弱性が発見され、それを修正した新バージョンのソフトウェアが公開された場合に、当該新バージョンのソフトウェアをインストールすることで当該行政サービスに不具合等が生じて利用が不可能になるような事態が発生すると、利用者は、当該ソフトウェアを新バージョンに更新することができなくなる。結果として、機関等の行政サービスが利用者の脆弱性回避を妨げることになってしまう。こうしたことが起きないよう、行政サービスを提供するシステムは、第三者の汎用ソフトウェアの併用を前提とする場合は、当該汎用ソフトウェアが新バージョンに置き換わっても、正常に動作するように設計する必要がある。予期せず不具合が発生する事態が発生した場合にも、行政サービスを提供するシステムを修正することができるよう、迅速に新バージョンのソフトウェアに対応することを保守契約に盛り込んでおくことが望ましい。

また、特定の種類のウェブブラウザに脆弱性が発見され、利用する危険性が高くなった場合においても、他の種類のウェブブラウザも利用可能とすることで、提供するサービスを継続可能にする必要がある。そのためには、例えば、２種類以上のウェブブラウザ又は同一製品の異なるバージョンが動作するように、情報システムの構築時に配慮し、その動作確認を行うことが考えられる。

なお、開発時に公開されているバージョンだけでなく、例えば、利用を想定しているブラウザの次期バージョンについて、ソフトウェアの配布前に情報が公開された状態又は試用版ソフトウェアが配布され動作検証可能な状態にあれば、前もって利用可能か否かを検証するなど、その後に公開が想定されるバージョンにも対応できるよう、構築時に配慮することが望ましい。

行政サービスを提供する情報システムを利用するために、利用者の端末にインストールされているソフトウェア（機関等が直接提供していないソフトウェア（例えば、端末のOSやウェブブラウザ等））の設定変更を必要とするとき、その設定変更が情報セキュリティ水準の低下を招くものである場合、そのような設定変更を要求してはならない。必要があって利用者に設定変更を求めるときは、そのOSやブラウザの標準設定（初期設定）に変更することのみを求めることとし、当該設定によって情報セキュリティ水準を低下させないことが前提である。

これに該当する典型的な例は、機関等のウェブサイトを構成する各HTMLファイルの中に、機関等外のサイト（例として広告事業者の広告提供サーバ）のコンテンツを見えない形又は見える形で組み込むことで、機関等のウェブサイトの閲覧者のアクセス履歴を当該広告サーバへ自動的に送信する、いわゆる「トラッキング処理」を行う機能である。このとき、当該広告提供サーバがHTTPのcookie機能を用いて閲覧する利用者に識別番号を付番している場合は、アクセス履歴等の、サービス利用に当たって必須ではない、サービス利用者その他の者に関する情報が、本人の意思に反して当該広告提供サーバを運営する第三者に提供されることになるので、本基本対策事項はこのような機能がアプリケーション・コンテンツに組み込まれることがないようにすることを求めている。

また、トラッキング処理ではなくとも、例えば、利用者のキー入力の全てを当該利用者が意図しない形で送信するなどの機能も、「サービス利用に当たって必須ではない、サービス利用者その他の者に関する情報が本人の意思に反して第三者に提供されるなどの機能」に該当し得る。

なお、対象はウェブサイトのHTMLファイルに限られず、アプリケーションプログラムを提供する場合に、そのプログラムに含まれ得る機能についても同様である。

機関等外へのアクセスを自動的に発生させる機能を含める必要がある場合の例としては、ソーシャルメディアとの連携機能を提供するためのボタン（ボタン画像の他、ボタン押下の機能等を提供するプログラムを含む。）等を機関等のウェブページ上に設置する場合が挙げられる。万が一、機関等外のウェブサイトが提供するプログラムに不正なコードが含まれていると、当該プログラムを使用した機関等のウェブサイトが利用者に危険をもたらすことになるため、その安全性が確認できているボタン等のみを使用することが求められる。これはウェブページ等のコンテンツに限らず、機関等が提供するアプリケーションプログラムにおいても同様である。

機関等外へのアクセスを自動的に発生させる機能とは、例えば、機関等が提供するウェブページのHTMLファイルに、<script src=”https://機関等外のサイト/foo.js”\>等の記述があり、機関等外のウェブサイトからプログラムを読み込んで実行する機能が該当する。もし、機関等外のウェブサイトが提供するプログラムに不正なコードが含まれる場合、当該プログラムを使用した機関等のウェブサイトが利用者に危険をもたらすことになるため、そのような機能をウェブページに含めることは可能な限り避けるべきである。具体的には、当該ファイルを当該機関等ウェブサイトのサーバ上に置いて提供することで解決できる。これはウェブページ等のコンテンツに限らず、機関等が提供するアプリケーションプログラムにおいても同様である。

遵守事項

(3) アプリケーション・コンテンツの開発時の対策

(a) 情報システムセキュリティ責任者は、ウェブアプリケーションの開発において、セキュリティ要件として定めた仕様に加えて、既知の種類の**ウェブアプリケーションの脆弱性を排除するための対策**を講ずること。

【 基本対策事項 】

＜6.6.1(3)(a)関連＞

6.6.1(3)-1 情報システムセキュリティ責任者は、以下を全て含むウェブアプリケーションの脆弱性を排除すること。

a) SQLインジェクション脆弱性

b) OSコマンドインジェクション脆弱性

c) ディレクトリトラバーサル脆弱性

d) セッション管理の脆弱性

e) アクセス制御欠如と認可処理欠如の脆弱性

f) クロスサイトスクリプティング脆弱性

g) クロスサイトリクエストフォージェリ脆弱性

h) クリックジャッキング脆弱性

i) メールヘッダインジェクション脆弱性

j) HTTPヘッダインジェクション脆弱性

k) evalインジェクション脆弱性

l) レースコンディション脆弱性

m) バッファオーバーフロー及び整数オーバーフロー脆弱性

n) サーバサイドリクエストフォージェリ（SSRF）脆弱性

6.6.1(3)-2 情報システムセキュリティ責任者は、**ウェブアプリケーションを運用段階へ移行する前**に情報システムの分類に基づき、以下の対策を実施すること。

【基本セキュリティ対策】開発したウェブアプリケーションに対して脆弱性診断の実施を検討すること。

**【追加セキュリティ対策】**高度な情報セキュリティ対策が要求される情報システムで実行するウェブアプリケーションに対して、脆弱性診断を実施すること。

（解説）

ウェブアプリケーションの開発時には、既知の種類のウェブアプリケーションの脆弱性を排除するための対策が求められる。脆弱性を排除したウェブアプリケーションを実装する方法の詳細については、情報処理推進機構（IPA）による「安全なウェブサイトの作り方」やOWASPのASVS（Application Security Verification Standard：アプリケーションセキュリティ検証標準）を参照することも考えられる。

参考：情報処理推進機構（IPA）「安全なウェブサイトの作り方 改訂第７版」 （https://www.ipa.go.jp/security/vuln/websecurity/about.html）

参考：OWASP「Application Security Verification Standard」 （https://owasp.org/www-project-application-security-verification-standard/）

OWASP「Application Security Verification Standard」については、以下の邦訳も参考にするとよい。

参考：情報処理推進機構（IPA）「情報システム開発契約のセキュリティ仕様作成のためのガイドライン～Windows Active Directory編～」

（https://www.ipa.go.jp/digital/model/ug65p90000001ljh-att/000087453.docx）にある、「参考例　OWASP アプリケーションセキュリティ検証標準 4.0」

また、ウェブアプリケーションを開発する際に脆弱性を含まないように開発したとしても、開発者の気付かない脆弱性が存在してしまう可能性がある。そのようなリスクが考えられるため開発したウェブアプリケーションについては、脆弱性対策の状況を確認するために脆弱性診断を行うことが考えられる。脆弱性診断には、ソースコード診断、ウェブアプリケーション診断等の種類があり、必要に応じて脆弱性診断を使い分けて実施する必要がある。

さらに、高度な情報セキュリティ対策が要求される情報システムにおいてウェブアプリケーションを構築する場合は、脆弱性診断を実施することが求められる。なお、脆弱性診断については、「（解説）基本対策事項7.2.1(1)-1「脆弱性診断を実施」について」を参照のこと。

ウェブアプリケーションのプログラムがデータベースを操作する手段としてSQL言語を用いている場合に、プログラムがSQL文を文字列の連結によって動的に生成する構造になっていると、外部から悪意ある者によって与えられた攻撃用の文字列がSQL文に不正に混入し得る欠陥となることがある。この欠陥を攻撃されると、データベースを破壊されることや、データベース内の情報を盗まれるなどの被害が生じ得る。このような欠陥は一般に「SQLインジェクション脆弱性」と呼ばれている。SQLインジェクション脆弱性を排除するには、SQL文の組立てにプレースホルダを用いる実装方法を採用することを徹底するなどの対策が考えられる。

ウェブアプリケーションのプログラムがOSのコマンドを操作する必要がある場合に、プログラムがOSのコマンドを呼出しできる構造になっていると、外部から悪意ある者によって与えられた攻撃用の文字列がコマンドラインに不正に混入し得る欠陥となることがある。この欠陥を攻撃されると、サーバに侵入される被害が生じ得る。このような欠陥は一般に「OSコマンドインジェクション脆弱性」と呼ばれている。OSコマンドインジェクション脆弱性を排除するには、ウェブアプリケーションプログラムの処理において、OSコマンドを使用しないようにし、OSコマンドの実行が可能な関数等の使用を避けることが考えられる。また、OSコマンドを使用する必要がある場合は、実行するコマンド文字列の検証処理を追加し、想定するコマンド文字列以外は実行できない仕組みとするなどの対策が考えられる。

ウェブアプリケーションが使用するファイルのパス名を外部のパラメータから指定する仕様になっている場合に、指定されたパス名をプログラムがそのまま使用する構造になっていると、公開を想定しないファイルが参照されて、その内容が外部から閲覧され得る欠陥となる場合がある。このような欠陥は一般に「ディレクトリトラバーサル脆弱性」と呼ばれている。ディレクトリトラバーサル脆弱性を排除するには、外部のパラメータからパス名を指定する仕様を排除する対策、それができない場合には、ファイルにアクセスする直前に、使用するパス名の妥当性検査を行う方法、又は、ファイルのディレクトリと識別子を固定にしてアクセスするなどの対策が考えられる。

ウェブアプリケーションのプログラムがログイン機能を有するなど、セッション管理の仕組みを持つ場合に、そのセッション管理の実装方法に欠陥がある場合がある。例えば、セッション管理に用いられるセッションIDが推測可能な値となっている場合、セッションIDをURLパラメータに格納している場合、TLSを使用しているセッションの管理に用いるcookieにsecure属性がセットされていない場合等が、この脆弱性に該当する。この欠陥を攻撃されると、正規の利用者がログイン中に、その利用者になりすまして不正にアクセスする「セッションハイジャック」の被害が生じ得る。この脆弱性を排除するには、暗号論的擬似乱数生成器（CSPRNG）で生成する十分な長さの文字列をセッションIDとして推測困難なものとし、secure属性のセットされたcookieにこれを格納することでセッションIDの漏えいを防ぐ対策方法が考えられる。

ウェブアプリケーションがログイン機能を有し、ログイン中の利用者にのみ利用を許可すべき機能がある場合に、ログインしていない利用者にもその機能が利用できてしまう欠陥がある場合がある。このような欠陥は一般に「アクセス制御欠如の脆弱性」と呼ばれる。また、ログイン中の利用者のうち、一部の利用者にのみ利用を許可すべき機能がある場合に、それ以外の利用者にもその機能が利用できてしまう欠陥がある場合がある。このような欠陥は一般に「認可処理欠如の脆弱性」と呼ばれる。これらの欠陥を攻撃されると、秘密情報の漏えい、なりすまし操作等の被害が生じ得る。これらの脆弱性を排除するには、アクセス制御と認可処理が必要な画面の仕様を明確にし、仕様に沿った実装を徹底するなどの対策が考えられる。

ウェブアプリケーションのプログラムがHTMLページを出力する場合に、プログラムがHTMLを文字列の連結によって動的に生成する構造になっていると、外部から悪意ある者によって与えられた攻撃用の文字列がHTMLに不正に混入し得る欠陥となることがある。この欠陥を攻撃されると、cookieの値を盗まれてセッションハイジャックされるほか、画面の内容を改ざんされるなどの被害が生じ得る。このような欠陥は一般に「クロスサイトスクリプティング脆弱性」と呼ばれている。クロスサイトスクリプティング脆弱性を排除するには、以下を全て含む対策が考えられる

ただし、当該ウェブアプリケーションの仕様の都合で、これらだけでは解決できない場合もあり、その場合には追加的な対策が必要となる。

ウェブアプリケーションが、ログイン中の利用者にのみ利用を許可する機能を有している場合に、その機能のウェブページに前記e)の対策が施されている場合であっても、外部のサイトから当該ウェブページにリンクを張る方法により、利用者本人にそのリンクをたどらせることで、当該利用者の意図に反して当該機能が利用されてしまうという構造になっている場合がある。このような欠陥は一般に「クロスサイトリクエストフォージェリ脆弱性」と呼ばれている。この欠陥を攻撃されると、悪意ある者が仕掛けたリンクによって、不正に当該機能を操作される被害（具体的には、ウェブアプリケーションに設定された個人設定の内容を変更されるなどの被害）が生じ得る。この脆弱性を排除するには、外部からのリンクによって機能が作動してはならないウェブページは、処理を実行するページをPOSTメソッドでアクセスするようにし、その「hiddenパラメータ」に秘密情報が挿入されるよう、前のページを自動生成して、実行ページではその値が正しい場合のみ処理を実行するように実装するなどの対策方法が考えられる。

ウェブアプリケーションが、サイト内のボタンやリンクをクリックするだけで作動する機能を有している場合に、悪意ある者が、当該サイトを透明化した（透明色で表示して利用者の目に見えないように設定された）フレームとして外部のサイト上に表示するようにし、利用者を当該外部サイトへ誘導して、当該ボタンやリンクの表示された画面上の位置をクリックさせるよう誘導することで、利用者の意図に反して当該機能を作動させることができてしまう場合がある。このような欠陥は一般に「クリックジャッキング脆弱性」と呼ばれている。この欠陥を攻撃されると、ウェブアプリケーションに設定された個人設定の内容を変更されるなどの被害が生じ得る。この脆弱性を排除するには、ウェブサーバの設定で、HTTPレスポンスに「X-Frame-Options」ヘッダを出力するようにし、そのフィールド値に「deny」又は「sameorigin」の値をセットすることで、当該ウェブページが外部のサイトにフレームとして表示されることを拒否するよう利用者のブラウザに指示する機能を用いるといった対策方法が考えられる。

ウェブアプリケーションが電子メールを送信する機能を有し、その宛先となる電子メールアドレスをウェブアプリケーションのパラメータから指定する構造になっている場合に、悪意ある者により任意の電子メールアドレスが当該パラメータに与えられ、迷惑メールの送信のために当該ウェブアプリケーションが悪用されてしまうという被害が生じ得る。この欠陥を排除するには、電子メールの送信先電子メールアドレスはプログラム中に固定的に記述する実装方法（又は設定ファイルから読み込む実装方法）を採用して、ウェブアプリケーションのパラメータを用いるのを避けるなどの対策方法が考えられる。

ウェブアプリケーションがHTTPレスポンスヘッダの「Location」や「Set-Cookie」のフィールド値を動的に出力する構造になっている場合、外部から悪意ある者によって与えられた改行文字を含む攻撃用の文字列がHTTPレスポンスヘッダに不正に混入し得る欠陥となることがある。この欠陥を攻撃されると、クロスサイトスクリプティング脆弱性の場合と同じ被害が生じ得る。このような欠陥は一般に「HTTPヘッダインジェクション脆弱性」と呼ばれている。HTTPヘッダインジェクション脆弱性を排除するには、HTTPレスポンスヘッダを出力する際に、直接にヘッダ文字列を出力するのではなく、ウェブアプリケーションの実行環境や言語に用意されているヘッダ出力用APIを使用する実装方法を採用するなどの対策が考えられる。

ウェブアプリケーションのプログラムを作成する言語が、「eval」、「JavaScript」等、文字列をプログラムとして実行する機能を持つ言語である場合に、プログラムがこの機能を使用していると、外部から悪意ある者によって与えられた攻撃用の文字列が、そのevalに与える文字列に混入し得る欠陥となることがある。この欠陥を攻撃されると、任意のプログラムがサーバで実行されることとなり、様々な被害が生じ得る。このような欠陥は一般に「evalインジェクション脆弱性」と呼ばれる。この脆弱性を排除するには、eval機能を一切使用しない実装方法を採用するなどの対策が考えられる。

ウェブアプリケーションの機能を複数の利用者が全く同時に利用したときに、一方の利用者向けの処理ともう一方の利用者向けの処理を途中で取り違えてしまう事態が一定の確率で発生する場合がある。このような欠陥は一般に「レースコンディション脆弱性」と呼ばれる。この欠陥により、利用者の秘密にすべき情報が第三者に閲覧される被害が生じる。この被害は、攻撃者がいなくても偶然に発生する場合もあれば、攻撃者が大量のアクセスをすることで意図的に引き起こされる場合もある。この脆弱性を排除するには、ソースコードレビューによってレースコンディションが起きえない構造にプログラムが記述されていることを確認する方法や、大量のアクセスを同時に発生させて異常が発生しないことを十分に確認するテストを行うなどの対策方法が考えられる。

ウェブアプリケーションのプログラムを作成する言語として、バッファオーバーフロー脆弱性等が生じない言語を採用することが望ましいが、バッファオーバーフロー脆弱性等が生じない言語を採用した場合であっても、ウェブアプリケーションが、内部でC言語等を用いて独自に作成されたプログラムを呼び出す構造になっている場合がある。その呼び出されるプログラムにバッファオーバーフロー脆弱性や整数オーバーフロー脆弱性が存在し、ウェブアプリケーションに外部から与えた文字列が当該プログラムに引き渡される構造になっていると、それらの欠陥を攻撃されて、サーバに侵入される被害が生じ得る。このような脆弱性を排除するためには、C言語等のバッファオーバーフロー脆弱性等が生じ得る言語により作成されたプログラムが内部で呼び出されることを避けるなどの対策が考えられる。

インターネット等の外部に公開したウェブアプリケーションから、本来は外部から到達できない領域にある任意の送信先に対して、リクエストを送ることが可能な仕様になっている場合がある。このような欠陥のことを一般的に「サーバサイドリクエストフォージェリ脆弱性」と呼ぶ。この脆弱性を悪用されると、インターネット等の外部に公開されているウェブアプリケーションをとおして、任意の送信先に対して不正なコマンド等を実行することができ、不正に操作される被害等が生じる可能性がある。

この脆弱性を排除するには、インターネット等の外部に公開したウェブアプリケーションにおいて外部からのリクエストの送信先を限定するため、ドメインなどの許可リストを利用してホワイトリスト化するなどの対策が考えられる。送信先を限定することが困難な場合は、リクエストの入力規則を慎重に設計する等の対策が考えられる。

また、外部に公開したウェブアプリケーションとの通信が必要なセグメントと通信の必要のないセグメントを分離する等の対策も有効である。

ウェブアプリケーションの脆弱性を悪用されると、ウェブアプリケーションで取り扱う情報の漏えいやウェブアプリケーションに入力する情報の窃取などが発生する可能性がある。そのため、脆弱性を排除するようにウェブアプリケーションの開発をする必要があるが、開発時には想定できなかった脆弱性が存在する可能性もある。そのため、ウェブアプリケーションで行われる業務や取り扱う情報等を踏まえて、ウェブアプリケーションの脆弱性診断を実施する必要がある。

基本セキュリティ対策として、開発した全てのウェブアプリケーションについては、運用段階へ移行する前に当該ウェブアプリケーションを用いて行われる業務や取り扱う情報等を踏まえて脆弱性診断の実施の必要性を検討し、実施する必要がある場合はウェブアプリケーション診断等を行うこと。なお、インターネットからアクセス可能なウェブアプリケーションについては、脆弱性診断を実施することが望ましい。

追加セキュリティ対策として、高度な情報セキュリティ対策が要求される情報システムにおいて実行するウェブアプリケーションについては、運用段階へ移行する前に脆弱性診断を行う必要がある。実施すべき脆弱性診断については、ソースコード診断、プラットフォーム診断、ウェブアプリケーション診断等の種類があり、構築する情報システムの構成等によって利用する脆弱性診断を使い分ける必要があるが、最低限ウェブアプリケーション診断は実施することが求められる。

なお、脆弱性診断については、デジタル庁が公表している以下のガイドラインを参考にするとよい。

参考：デジタル庁「政府情報システムにおける脆弱性診断導入ガイドライン」 （https://www.digital.go.jp/resources/standard_guidelines/）

遵守事項

(4) アプリケーション・コンテンツの運用時の対策

(a) 情報システムセキュリティ責任者は、利用者の情報セキュリティ水準の低下を招かぬよう、アプリケーション及びウェブコンテンツの提供方式等を見直すこと。

(b) 情報システムセキュリティ責任者は、運用中のアプリケーション・コンテンツにおいて、**定期的に脆弱性対策の状況を確認し、脆弱性が発覚した際は必要な措置を講ずる**こと。

(c) 情報システムセキュリティ責任者は、ウェブアプリケーションやウェブコンテンツにおいて、アプリケーションやコンテンツの**改ざんを検知するための措置を講ずる**こと。

【 基本対策事項 】

＜6.6.1(4)(a)関連＞

6.6.1(4)-1 情報システムセキュリティ責任者は、利用者に強制するOSやソフトウェア等のサポート状況や脆弱性情報等を確認し、**サポートが終了する又は脆弱性が存在するバージョンのOSやソフトウェア等の利用を強制する**など情報セキュリティ水準を低下させる設定変更等を、OSやソフトウェア等の利用者に要求することがないよう、アプリケーション及びウェブコンテンツの提供方式等を見直すこと。

（解説）

情報システムセキュリティ責任者は、運用中のアプリケーション・コンテンツにおいて脆弱性対策の状況を確認する手段として、アプリケーション・コンテンツで使用しているソフトウェア等における脆弱性に関する情報が公開されていないかを確認する方法の他、ウェブアプリケーションを標的とした攻撃手法の確認や専用ツールを用いて脆弱性診断を行うことや、事業者が提供するサービス等を利用して脆弱性診断を行うなどの方法も考えられる。脆弱性診断には、ソースコード診断、プラットフォーム診断、ウェブアプリケーション診断等の種類があり、運用中の変化等に応じて脆弱性診断を使い分ける必要がある。

なお、脆弱性診断については、「（解説）基本対策事項7.2.1(1)-1「脆弱性診断を実施」について」を参照のこと。

アプリケーション・コンテンツの脆弱性が発覚した場合は、適切な対応を速やかに進めることが求められる。脆弱性は、脆弱性診断等により発覚する以外に、「ソフトウエア製品等の脆弱性関連情報に関する取扱規程（平成29年経済産業省告示第19号）」を踏まえた「情報セキュリティ早期警戒パートナーシップ」の活動により、調整機関から通知されることもある。「情報セキュリティ早期警戒パートナーシップ」の活動から通知された場合を含め、アプリケーション・コンテンツの脆弱性が発覚した場合は、「情報セキュリティ早期警戒パートナーシップガイドライン」に説明されている脆弱性関連情報への対処に沿った対応を行うこと。「情報セキュリティ早期警戒パートナーシップ」については、以下の告示及びガイドラインを参照するとよい。

参考：経済産業省「ソフトウエア製品等の脆弱性関連情報に関する取扱規程（平成29年経済産業省告示第19号）」

（https://www.meti.go.jp/policy/netsecurity/vul_notification.pdf）

参考：経済産業省「受付機関及び調整機関を定める告示（平成31年経済産業省告示第19号）」

（https://www.meti.go.jp/policy/netsecurity/vul_institutions.pdf）

参考：情報処理推進機構（IPA）「情報セキュリティ早期警戒パートナーシップガイドライン」

（https://www.ipa.go.jp/security/guide/vuln/partnership_guide.html）

情報システムセキュリティ責任者は、ウェブアプリケーションやウェブコンテンツの改ざんを検知するため、ウェブアプリケーションやウェブコンテンツを更新するたびにハッシュ値等を保存し、定期的に比較するなどの措置を講ずることが考えられる。

情報システムセキュリティ責任者は、提供するアプリケーション・コンテンツを運用する際は、当該アプリケーション・コンテンツの利用者に対して強制するOSやブラウザ等のソフトウェア等のサポート状況や脆弱性情報を確認し、利用を強制するソフトウェア等のサポートが終了する又は脆弱性が存在することが発覚した場合、利用者の情報セキュリティ水準の低下を招かぬように対策を講じなければならない。

6.6.2 アプリケーション・コンテンツ提供時の対策

目的・趣旨

機関等では、情報の提供、行政手続及び意見募集等の行政サービスのためにウェブサイト等を用意し、国民等の利用に供している。これらの国民等に提供するサービス（クラウドサービスを含む）は通常インターネットを介して利用するものであるため、国民等にとっては、そのサービスが実際の機関等のものであると確認できることが重要である。また、機関等になりすましたウェブサイトを放置しておくと、機関等の信用を損なうだけでなく、国民等が不正サイトに誘導され、不正プログラムに感染するおそれがあるため、このような事態への対策を講ずる必要がある。

遵守事項

(1) 政府ドメイン名の使用

(a) 情報システムセキュリティ責任者は、機関等外向けに提供するウェブサイト等が**実際の機関等提供のものであることを利用者が確認できるように、政府ドメイン名を取得できない場合**を除き政府ドメイン名を情報システムにおいて使用すること。

(b) 職員等は、機関等外向けに提供するウェブサイト等の作成を業務委託する場合においては、**機関等に適するドメイン名を使用するよう調達仕様に含める**こと。

【 基本対策事項 】規定なし

（解説）

政府ドメイン名は、株式会社日本レジストリサービスが定める「属性型（組織種別型）・地域型JPドメイン名登録等に関する規則」に基づき、その登録資格は日本国の政府機関、各省庁所轄研究所、独立行政法人、特殊法人（特殊会社を除く。）に限られるとされていることから、日頃から機関等が政府ドメイン名を用いることを徹底することにより、なりすましが発生しても、機関等外の者がウェブサイト等の真偽を見分けることが容易なものとすることができる。

仮に政府ドメイン名以外を使用した場合には、そのサイトの使用を終了した後も、当該ドメイン名を不正に利用されないように登録管理を一定期間（少なくとも１年以上）維持しなければならないが、そのような管理の必要がないことも、政府ドメイン名を用いることの利点の一つである。ただし、ホスティングサービス等を用いてそのサイトを公開した場合、公開時に設定した当該政府ドメイン名に関するDNS設定を、終了時に削除する必要があることに注意が必要である。DNS設定が残ったままになっている場合、その設定を第三者に利用され、使用を終了した政府ドメイン名を使って意図しないウェブサイト等を公開されてしまうサブドメインテイクオーバー・NSテイクオーバーと呼ばれる攻撃を受ける可能性がある。

政府ドメイン名を用いるべき場合の例を以下に示す。

政府ドメイン名を使用しない場合は、機関等を装ったなりすましの脅威があることを十分に理解し、国民に対して当該ドメイン名が機関等のものであることの真偽を見分けられるようにすることが重要である。また、政府ドメイン名以外のドメイン名は、ドメインの廃止後に第三者に取得され、悪用されるリスクがあることから、当該ドメインを利用しなくなった後でも当面の間、登録を継続することや再利用することができないURL等を用いるなどの対策が必要となり、利用を終了した後もリスクが存在することを十分に理解した上で、使用することを検討すること。

本対策における政府ドメイン名を取得できない場合とは、特段の理由により政府ドメイン名が使えない場合も含めたものである。

政府ドメイン名を取得できない場合の例を以下に示す。

なお、高等教育機関向けのドメイン名を使用する場合は、あらかじめ、情報セキュリティの確保の観点から、政府ドメイン名と高等教育機関向けのドメイン名のどちらを使用するべきかを比較考慮の上、判断すること。

国の行政機関に属する教育機関については、従前より統一基準において政府ドメイン名の使用を求めてきているが、その性格が「職員の養成や研修」という点において国の行政機関の行政事務の一環としてとらえることができ、政府ドメイン名を用いることが適当である。

一方、独立行政法人や指定法人である教育機関については、これら教育機関で勉学を行う国民の目から見れば、国の行政関係機関というよりも教育の場としての性格が強いと考えられ、使用するドメイン名については、情報セキュリティ確保の観点と、ウェブサイトの利用者側の視点の両面から考慮する必要がある。また、例えば、教育機関に所属する学生が政府ドメイン名のメールアドレスを使用するとした場合、メールを受信した者にとっては、メールの送信者が機関等の職員であると誤解する可能性もあり、このような点も考慮する必要がある。

そのため、独立行政法人や指定法人である教育機関においては、これら自組織の特性及び情報セキュリティ確保の観点を踏まえた上で、どちらのドメイン名を使用するべきか比較考慮し、判断する必要がある。

政府ドメイン名の取得は可能であるが、例外として政府ドメイン名以外を使用する場合の例と留意事項を以下に示す。

機関等外向けのウェブサイトを構築する場合に、情報システム部門以外の職員等がウェブサイトの構築業務を業務委託することが考えられる。このような場合でも、情報セキュリティ水準の低下を招かないよう、例えば、国の行政機関であれば政府ドメイン名の使用を調達仕様に含めることが求められる。

遵守事項

(2) 不正なウェブサイトへの誘導防止

(a) 情報システムセキュリティ責任者は、利用者が検索サイト等を経由して**機関等のウェブサイトになりすました不正なウェブサイト**へ誘導されないよう対策を講ずること。

【 基本対策事項 】

＜6.6.2(2)(a)関連＞

6.6.2(2)-1 情報システムセキュリティ責任者は、機関等外向けに提供するウェブサイトに対して、以下を例とする**検索エンジン最適化措置（SEO対策）**を講ずること。

a) **クローラからのアクセスを排除しない**こと。

b) **cookie機能を無効に設定したブラウザでも正常に閲覧可能とする**こと。

c) **適切なタイトルを設定する**こと。

d) **不適切な誘導を行わない**こと。

6.6.2(2)-2 情報システムセキュリティ責任者は、機関等外向けに提供するウェブサイトに関連するキーワードで定期的にウェブサイトを検索し、検索結果に不審なサイトが存在した場合は、速やかにその検索サイト業者へ報告するとともに、**不審なサイトへのアクセスを防止するための対策**を講ずること。

6.6.2(2)-3 情報システムセキュリティ責任者は、機関等のウェブサイトなどになりすました**不審なウェブサイト等が存在していることの連絡を受け付ける体制を整備するとともに、不審なウェブサイトに対し必要な措置を講ずる**こと。

（解説）

機関等外の者が、機関等の名前をタイトルに掲げるなどして、機関等のウェブサイトと誤認されかねないウェブサイトを作成することがあり、これを完全に防ぐことはできない。本来ならば、利用者は当該サイトのURL中のドメイン名が政府ドメイン名であるかを確認することで、機関等のウェブサイトかを確認できるところであるが、検索サイト等を利用して機関等名で検索して訪れる利用者も多いことから、検索サイトで検索したときに、正規の機関等サイトが検索結果の上位に現れるようになっていることが望ましい。通常は、特別な対策をすることなく、そのような結果になることがほとんどであるが、正規の機関等サイトの側で、不適切な設定になっている場合や、コンテンツが適切に構成されていない場合に、検索サイトで、正規の機関等サイトが最上位に現れないことや、適切な表示がなされないことがある。本条はそのような事態を防止するための措置を講ずることを求めている。

正規のウェブサイトが検索サイトで上位に現れるように正規のウェブサイト側で工夫を施すことを、一般に「検索エンジン最適化」又は「SEO対策」と呼ぶ。本基本対策事項は、機関等サイトにおいても一般的な検索エンジン最適化の措置を講ずることを求めている。

一般に、検索サイトは、ウェブクローラと呼ばれる自動的にウェブサイトのリンクをたどって全てのページを巡回するプログラムを、自ら稼働させることによって収集したHTMLデータを用いて検索機能を実現している。そのため、検索サイトのクローラからのアクセスを拒否する設定をしている場合、当該サイトは検索サイトの検索結果に現れなくなることがある。そのような設定は、ウェブサイトの「/robots.txt」のファイルの記述で簡単にできるものであるため、誤ってクローラからのアクセスを拒否する設定にしてしまう状況が想定される。通常、このファイルを設定する必要はないため、何ら記述しないでおくことが望ましい。

一般に、検索サイトが自ら稼働させるウェブクローラは、HTTPのcookie機能に対応していない。そのため、cookie機能を無効に設定したブラウザで閲覧したときに、正常に表示されないウェブページは、検索サイトの検索結果に正常に表示されない事態が起きる。通常のウェブサイトの構成では、cookie機能を無効にしても正常に表示されるものであるが、一部のCMSには、cookieを無効にして閲覧すると「cookieを有効にしてください」とだけ記述したエラー画面を表示するものがあり、そのようなCMSを用いてウェブサイトを構成すると、前述の事態が生じる。実際に、過去に一部の機関等サイトでそのような事態が発生したことがあるため、ウェブサイトの構築を業務委託する場合を含め、注意が必要である。

一般に、検索サイトの検索結果には、当該ページのタイトル（HTML中のTITLE要素で設定される文字列）が見出しとして表示され、利用者はこれを頼りにサイトを訪れることから、機関等サイトにおいても、ページのタイトルに機関等の名称を含めるなど、適切なタイトルを設定することが重要である。

その他の対策として、HTML中のH1要素やH2要素を適切に記述することで、そこに含まれる単語や文で検索したときに、検索サイトの上位に当該ページが現れやすくなる。機関等サイトにおいても、H1要素やH2要素を適切に記述することで、検索結果の上位に現れやすくすることができる。また、HTML中のメタタグ（「description」や「keywords」等）に概要やキーワード等を記述することで、そこに含まれる単語や文で検索したときに、検索サイトの上位に当該ページが現れやすくなる。機関等サイトにおいても、メタタグを適切に記述することで、検索結果の上位に現れやすくすることができる。

一般に、HTML中に見えない文字等でページ内容に関係のないキーワードを過剰に記述するなどして、当該ページへのアクセスを無用に誘う行為（「SEOスパム」等と呼ばれる。）は、不適切な行為として検索サイトからペナルティを科され、検索結果の上位に表示されなくなることがある。機関等のウェブサイトにおいて、故意にそのような行為が行われることは考えにくいが、コンテンツの作成を業務委託した場合に、委託先が独自判断で行うことも想定されるため、そのようなコンテンツを作成しないよう注意が必要である。

不審なサイトを確認した場合は、機関等のウェブサイト等において注意喚起を行うなどの対応を図るとともに、必要に応じて自組織や内閣官房国家サイバー統括室等の関係部門に状況を報告する。特に悪質な場合は、誤って当該サイトにアクセスすることを防止するため、検索サイト業者に対して検索結果に表示されないよう依頼する、機関等LANシステムからアクセスできないよう当該サイトに対してフィルタを設定する、といった対策が考えられる。

機関等のウェブサイトなどになりすました不審なサイトは、主に外部からの通報によって把握する場合が多い。そのため、ウェブサイト等のアプリケーション・コンテンツを提供する場合は、不審なウェブサイト等を発見した場合の外部からの通報窓口などを用意することが望ましい。また、警察や内閣官房国家サイバー統括室、JPCERT/CCなどの公的機関や専門機関、職員等からの通報についても定められた連絡先を用意するとよい。定められた連絡先としては、情報セキュリティインシデントの可能性を認知した際の報告窓口やCSIRTなどが考えられる。また、公的機関等からの通報があることを踏まえて、公的機関等との関係を整理するとよい。

不審なウェブサイトについて通報を受けた場合は、そのサイトが正規のサイトではない場合、警察への通報・連絡をするとともに、JPCERT/CCやフィッシング対策協議会などに正規でないサイトを閉鎖するための支援を要請するなどの措置を講ずることが考えられる。また、そのような正規でないサイトを把握した場合、当該ウェブサイトの利用者が正規でないサイトへ誘導されないよう、機関等のウェブサイトやSNS等を使用し通知するなどの措置を講ずることも考えられる。

なお、フィッシング対策については、フィシング対策協議会が公開している「フィッシング対策ガイドライン」を参考にするとよい。

参考：フィッシング対策協議会「フィッシング対策ガイドライン」 （https://www.antiphishing.jp/report/guideline/）

遵守事項

(3) アプリケーション・コンテンツの告知

(a) 職員等は、アプリケーション・コンテンツを告知する場合は、告知する対象となるアプリケーション・コンテンツに利用者が確実に誘導されるよう、必要な措置を講ずること。

(b) 職員等は、**機関等外の者が提供するアプリケーション・コンテンツを告知する**場合は、告知するURL等の有効性を保つこと。

【 基本対策事項 】

＜6.6.2(3)(a)関連＞

6.6.2(3)-1 職員等は、アプリケーション・コンテンツを告知するに当たって、誘導を確実なものとするため、**URL等を用いて直接誘導することを原則とし、検索サイトで指定の検索語を用いて検索することを促す方法その他の間接的な誘導方法を用いる場合であっても、URL等と一体的に表示すること。また、短縮URLを用いない**こと。

6.6.2(3)-2 職員等は、アプリケーション・コンテンツを告知するに当たって、URLを二次元コード等に変換して印刷物等に表示して誘導する場合には、当該コードによる誘導先を明らかにするため、**アプリケーション・コンテンツの内容に係る記述を当該コードと一体的に表示**すること。

＜6.6.2(3)(b)関連＞

6.6.2(3)-3 職員等は、機関等外の者が提供するアプリケーション・コンテンツを告知する場合は、**告知するURL等の有効性を保つために以下の全ての措置を講ずる**こと。

a) 告知するアプリケーション・コンテンツを管理する組織名を明記すること。

b) 告知するアプリケーション・コンテンツの所在場所の有効性（リンク先のURLのドメイン名の有効期限等）を確認した時期又は有効性を保証する期間について明記すること。

（解説）

機関等外の者が提供するアプリケーション・コンテンツを告知する場合、告知を開始した時点では、当該アプリケーション・コンテンツが、告知したURL等の誘導先に確かに存在していても、将来にわたりその誘導先に意図したアプリケーション・コンテンツが存在し続けるとは限らない。誘導先のドメイン名等が放棄された場合には、悪意ある者に当該ドメイン名が取得され、偽のアプリケーション・コンテンツに差し替えられる攻撃が想定される。したがって、機関等外の者が提供するアプリケーション・コンテンツを機関等が告知する場合には、誘導先の有効性を保つことが求められる。

URLを用いた直接誘導に該当する例としては、ウェブサイトにハイパーリンクを設ける場合のほか、電子メールにURLを記載して告知する場合、印刷物にURLを表示して誘導する場合等が挙げられる。URL「等」としているのは、例えば、ホスト名（FQDN形式での表記）もこれに該当するものとする趣旨である。

印刷物やテレビCMにより告知する際に、URL等の文字列が長すぎると、利用者にその全部を入力させることが困難であることから、検索サイトで検索するよう検索語を指定して促す方法が広く普及している。

しかし、この誘導方法では、偽サイトや別のサイトに誘導されてしまうリスクを否定できない。検索結果の上位に目的の誘導先が現れない可能性があるだけでなく、検索サイトの広告部分に悪意あるサイトを出現させる攻撃手法も想定され、利用者が検索サイトの広告部分を誘導先として解釈してしまうおそれがある。

また、アプリケーション・コンテンツの告知を広告代理店に委託している場合、広告代理店が検索連動型広告と呼ばれる検索サイトの広告枠を購入し、検索結果の画面に表示される広告部分を直接クリックすることなどを用いて目的の誘導先に誘導する方法が用いられることがある。この広告部分を利用して誘導する方法が広告代理店によって頻繁に用いられると、検索結果の画面に表示される広告部分を正規の誘導先として利用者が解釈するようになると考えられ、広告部分に攻撃者による偽サイトが現れることのリスクを無視することはできなくなる。したがって、機関等がアプリケーション・コンテンツを告知する場合には、検索サイトの検索画面に表示される広告枠を購入して誘導する方法を用いないようにすることが望ましい。なお、検索サイトに限らず、名称や存在等を広く周知することを目的とし、利用者の主体的な検索等による誘導を前提としないディスプレイ広告等については、この限りでない。

間接的な誘導方法を用いて機関等の提供するアプリケーション・コンテンツを告知する場合は、当該誘導方法による誘導の状況を適時確認するなどして、不正な又は不適切なウェブサイトへ誘導されてしまう可能性が高い状況になっているか否かを確かめることが望ましい。

アプリケーション・コンテンツの告知はURL等を用いて直接誘導することを原則とするが、間接的な誘導方法を用いたい場合があることも想定されることから、その場合に実施すべき措置として、間接的な誘導方法と一体的にURL等を表示することを求めている。

短縮URLを提供する民間事業者のサービスは、将来にわたり永続的に運営が保証されるものではなく、いずれサービスが消滅し、ドメイン名が放棄されれば、悪意ある者に当該ドメイン名が取得され、偽のアプリケーション・コンテンツに差し替えられる攻撃が想定される。したがって、やむを得ない場合を除き、短縮URLを用いるべきでない。やむを得ない場合の例としては、ソーシャルメディアにおいてURLを告知する場合に、当該ソーシャルメディアが強制的に所定の短縮URLを用いてしまう場合が挙げられる。

印刷物等でアプリケーション・コンテンツを告知する際に、URL等の表示に代わるもの又はURL等と一体的に表示するものとして、二次元コード等を用いて誘導する方法がある。この方法は、特にスマートフォンや携帯電話の利用者にとって利便性が高く、機関等においても用いられるようになってきている。

しかしながら、二次元コード等のみを単体で表示した場合、それがどこへ誘導するものであるかが、利用者にとって必ずしも明確でない場合がある。そこで、本基本対策事項では、当該二次元コード等がどこへ誘導するものであるかを、当該二次元コード等と一体的に表示することにより利用者に明示することを求めている。

「アプリケーション・コンテンツの内容に係る記述」の例としては、誘導先のURL等や、誘導先のアプリケーション・コンテンツの内容を示す記述が考えられる。

この措置を講ずるための対策事項a)及びb)について、具体的な記載例を以下に示す。