第7部 情報システムのセキュリティ要件

7.1 情報システムのセキュリティ機能

7.1.1 主体認証機能

目的・趣旨

情報又は情報システムへアクセス可能な主体を制限するためには、主体認証機能の導入が必要である。その際、アクセス権限のある主体へのなりすましや脆弱性を悪用した攻撃による不正アクセス行為を防止するための対策を講ずることが重要となる。

また、機関等の情報システムにおいて、国民向けのサービスを提供する場合は、国民が情報システムへのアクセスの主体となることにも留意して、主体認証情報を適切に保護しなければならない。

遵守事項

(1) 主体認証機能の導入

(a) 情報システムセキュリティ責任者は、情報システムや情報へのアクセス主体を特定し、それが正当な主体であることを検証する必要がある場合、主体の**識別及び主体認証**を行う機能を設けること。

(b) 情報システムセキュリティ責任者は、国民・企業と機関等との間の申請、届出等のオンライン手続を提供する情報システムを構築する場合は、オンライン手続におけるリスクを評価した上で、主体認証に係る要件を策定すること。

(c) 情報システムセキュリティ責任者は、主体認証を行う情報システムにおいて、**主体認証情報の漏えい等による不正行為を防止するための措置及び不正な主体認証の試行に対抗するための措置**を講ずること。

【 基本対策事項 】

＜7.1.1(1)(a)関連＞

7.1.1(1)-1 情報システムセキュリティ責任者は、利用者が正当であることを検証するための主体認証機能を設けるに当たっては、以下を例とする主体認証方式を決定し、導入すること。

a) 知識（パスワード等、利用者本人のみが知り得る情報）による認証

b) 所有（電子証明書を格納するICカード、ワンタイムパスワード生成器、利用者本人のみが所有する機器等）による認証

c) 生体（指紋や静脈等、本人の生体的な特徴）による認証

7.1.1(1)-2 情報システムセキュリティ責任者は、情報システムの主体認証方式として、２つ以上の主体認証方式を組み合わせる**多要素主体認証方式等の導入を検討すること。特に、機関等内通信回線へリモートアクセスを必要とする主体やインターネット回線等の機関等外通信回線から直接アクセスが可能なクラウドサービス等の管理者権限を有する主体、重要な情報システムにおいて情報セキュリティインシデントに繋がる恐れのある強い権限を有する主体など、厳格な主体認証が必要な場合**は、原則として多要素主体認証方式等の強固な認証技術を用いること。。

7.1.1(1)-3 情報システムセキュリティ責任者は、ウェブブラウザを介した主体認証機能を設けるに当たっては、主体認証方式として、**フィッシング耐性を有する方式**の導入を検討すること。

7.1.1(1)-4 情報システムセキュリティ責任者は、主体認証情報としてパスワードを使用し、主体認証情報を付与された主体自らがパスワードを設定することを可能とする場合には、辞書攻撃等によるパスワード解析への耐性を考慮し、**強固なパスワードに必要な十分な桁数を備えた第三者に容易に推測できないパスフレーズ等を使用すること**を利用者に守らせる機能を設けること。

＜7.1.1(1)(c)関連＞

7.1.1(1)-5 情報システムセキュリティ責任者は、主体認証を行う情報システムにおいて、主体認証情報の漏えい等による不正なアクセスを防止するため、以下を全て含む措置を講ずること。

a) 原則として、機器等において**初期値として設定されている識別コードを使用しない**こと。

b) **不要な識別コードを無効にする**こと。

7.1.1(1)-6 情報システムセキュリティ責任者は、主体認証を行う情報システムにおいて、主体認証情報が第三者に対して明らかにならないよう、以下を全て含む方法を用いて適切に管理すること。

a) 主体認証情報を送信又は保存する場合には、その内容を暗号化すること。

b) 主体認証情報に対するアクセス制限を設けること。

c) 主体認証情報に対するアクセスに関するログを保存し、アクセスした主体を確認すること。

7.1.1(1)-7 情報システムセキュリティ責任者は、主体認証を行う情報システムにおいて、主体認証情報を他の主体に不正に利用され、又は利用されるおそれを認識した場合の対策として、以下を例とする機能を設けること。

a) 当該主体認証情報及び対応する識別コードの利用を停止する機能

b) 主体認証情報の再設定を利用者に要求する機能

（解説）

識別のための機能が実装されていない情報システムにおいて主体認証を行う場合（例えば、識別コード自体が存在せず、主体認証情報の検証のみで主体認証を行う場合）は、例外措置として判断し、主体を識別しないことによる影響を勘案の上、必要に応じて代替又は追加の措置を講ずる必要がある。

情報セキュリティ水準と情報システムの利便性等を考慮し、主体認証機能の運用に係る以下の要件の実装要否を情報システムの導入時に考慮するとよい。

なお、生体認証に用いる認証方式によっては、誤認の防止や誤否の防止とならない可能性があるため、そのような認証方式を用いる場合は、複数の認証方式を採用するなどを検討し、情報システムの導入時に考慮することが望ましい。例えば、生体認証として顔認証や指紋認証を用いる場合、認証精度は製品等によって異なる。顔認証の場合、製品によっては、顔の経年の変化や髪型が変わった場合などにより認証できない可能性があるので注意が必要である。また、機関等支給以外の端末をやむを得ず主体認証に利用する場合は、6.1.3「機関等支給以外の端末の導入及び利用時の対策」を参照し、必要な措置を講ずることに留意が必要である。

本項は、国民・企業と機関等との間の申請、届出等のオンライン手続を提供する際に、利用者本人であることを確認するための認証機能を適切に実装することを求めるものである。

オンライン手続におけるリスク評価に当たっては、サイバー攻撃等の脅威から生じ得る不正な認証の成功に加え、事業目的の遂行、公平性、ユーザビリティ／アクセシビリティ、プライバシー保護等の多面的な観点から要件を選定する必要がある。リスク特定の際は、主に以下４つのプロセスに係る代表的なリスクをもとにシステム個別のリスクを抽出すると良い。

①主体認証情報（認証器）の登録

②主体認証（当人認証）の実施

③主体認証情報（認証器）の盗難・紛失時の対応

④停止アカウントの回復

特に「④停止アカウントの回復」に関しては、採用している当人認証手法よりも強い強度を持った方法で実施しない場合、攻撃の起点とされやすいため、注意する必要がある。

次に、抽出されたリスクが顕在化した時の影響を判断する。判断に関しては、以下の観点から実施すると良い。

①申請者が対象手続等によって得られる権利権益等の侵害

②プライバシーの重大な侵害

③犯罪や攻撃への悪用

一方、これらは対象手続において個人等が申請・届出等を行う際の本人確認を対象としているため、リスクの影響範囲は、攻撃や侵害を受けた特定の利用者やアカウント等に限定されることを前提としている。情報システムの特性上、リスクの影響範囲が多数の利用者又は関係者に及ぶ場合には、さらに異なる観点からの影響評価が必要である点に注意が必要である。

なお、認証方式の選択に当たっては、適切なセキュリティ確保と普及を妨げない利便性とを両立させることが重要である。その際は、特定のリスクのみに着目せず、様々な観点でリスクを評価した上で認証方式を決定する必要がある。認証方式の選択においては、以下を参考にするとよい。

参考：デジタル庁「行政手続等での本人確認におけるデジタルアイデンティティの取扱いに関するガイドライン」

（https://www.digital.go.jp/resources/standard_guidelines/）

参考：デジタル庁「行政手続等での本人確認におけるデジタルアイデンティティの取扱いに関するガイドライン 解説書」

（https://www.digital.go.jp/resources/standard_guidelines/）

主体認証情報の漏えい等が発生すると、悪意ある第三者によってなりすましによる不正アクセスをされ、情報の窃取や踏み台にされるなどのリスクが発生する。主体認証情報の漏えいしたアカウントを悪用されると、情報セキュリティ対策を無効にされることや、情報を窃取するために使用する不正プログラム等を導入される可能性がある。したがって、誰もが知っている機器等において初期値として設定されている識別コードは原則として利用しない措置を講ずることが重要である。また、開発時に使用した識別コードや一時的に利用したテスト用の識別コード等を運用時においても有効にしていた場合、そのような識別コードが何らかの手段によって攻撃者に渡り、悪用される可能性も高くなる。したがって、不要となった識別コードは無効にすることが有効である。

主体認証機能に対する不正を防止するための機能として、以下を例とする機能を設けることを検討することが重要である。

端末によっては、例えばパスワード以外にも、自分のみが知る「パターン」を主体認証情報として扱うケースがあるが、これも「知識」に分類される。

「所有」による認証の例を以下に示す。

アプリに保存されている秘密鍵が所有の対象

生体情報による主体認証を用いる場合には、その導入前に、この方式特有の他人受入率（本人を他人と誤って認証してしまう確率）と本人拒否率（本人の認証が受け入れられない確率）の課題があるため、誤認の防止や誤否の防止とならない可能性がある生体による主体認証を用いる場合は、多要素主体認証の一つとして利用することを考慮して情報システムを設計する必要がある。

厳格な主体認証が必要な場合の具体的な例は、以下のとおり。

主体認証を行う情報システムにおいて、厳格な主体認証が必要な場合や1つの主体認証方式のみで行う認証の強度におけるリスクが許容できない場合には、2つ以上の主体認証方式を用いて認証を行う多要素主体認証方式（一部の2段階認証と呼ばれる方式を含む。）を導入する必要がある。

主体認証方式は、一般に、異なる認証方式を組み合わせた方が、強度が高くなる。異なる認証方式を組み合わせた多要素主体認証方式であれば、例えば仮にパスワード（知識）が露呈してしまっても、ICカード（所有）又は指紋（生体）等の残りの主体認証情報が他者の手に渡らない限り、不正なログインを防ぐことができる。

また、通常の運用時は単一の主体認証を実施するケースであっても、認証の要求時に、アクセス元のIPアドレス、アクセスする時間帯、位置情報等が通常のアクセスとは異なる特徴が確認された場合は、不正ログインのリスクが高まったと判断して多要素主体認証を行う方法も考えられる。

2段階認証の例として、利用者の携帯電話の電話番号や利用者の電子メールアドレスに対してワンタイムパスワードを送信して利用者に入力させる方法やスマートフォン等への認証要求を利用した認証方式などがあるが、AiTM（Adversary in The Middle）と呼ばれる高度なフィッシング攻撃（正規の認証画面へのアクセスに対するプロキシサーバとして機能し、正規の認証画面によく似たコンテンツをリアルタイムに表示するフィッシングサイト上で認証を行わせることで、2段階認証済のcookieを窃取する攻撃）により、2段階認証を突破されてしまう可能性がある。また、スマートフォン等への認証要求を利用した認証方式については、不正な認証要求に対して誤って許可をしてしまう多要素認証疲労攻撃等に対しては脆弱であり、スマートフォン等のSMSや音声を使用した認証方式においては、SIMスワップ攻撃等に対して脆弱であるため、2段階認証を突破されてしまう可能性がある。したがって、これらの2段階認証は、上記リスクを評価し、情報システムにおいてリスクを受容できるか判断した上で利用する必要がある。

なお、多要素主体認証方式の代表例としてFIDO認証がある。FIDO認証は、端末等のデバイス側で生体情報等を用いた認証を行った上で、デバイスに保管された秘密鍵を用いた公開鍵暗号方式によりサーバ側で端末認証を行う仕組みである。したがって、FIDO認証は多要素主体認証方式に該当する。デバイスの紛失等のリスクを評価した上で利用する必要があるが、デバイスの紛失等が生じた場合であっても、秘密鍵をOS等のプラットフォームの機能を介して複数のデバイス間で同期することによって認証を可能とする、「マルチデバイス対応FIDO認証資格情報（マルチデバイスFIDOクレデンシャル）」と呼ばれる仕組みも登場している。本方式はフィッシング耐性を有するが、プラットフォーマーのアカウントが侵害された場合、当該サービスのアカウントも侵害されてしまうこと等を考慮する必要がある。

ウェブブラウザを介した主体認証機能が、パスワードを用いた認証方式で実現されている場合、フィッシング攻撃によってパスワードを窃取されてしまう危険性があり、2段階認証を用いたとしても、「（解説）基本対策事項7.1.1(1)-2「多要素主体認証方式」について」で述べたように、AiTM型のフィッシング攻撃によって、2段階認証も突破されてしまう危険性がある。これに対して、フィッシング耐性のある認証方式は、AiTM型のフィッシング攻撃に対しても耐えるものであり、偽サイト上で誤って認証を開始しようとしても、認証が成功しない仕組みを実現するものである。

フィッシング耐性のある認証方式は、ウェブブラウザに組み込まれた仕組みを用いることなしには実現できないものであり、ウェブサーバ側の工夫だけでは実現できないことに留意が必要である。W3C Web Authentication（WebAuthn）は、フィッシング耐性のある認証方式の一つであり、今日の主要ブラウザに標準で組み込まれている。WebAuthnは、「検証者名バインディング」と呼ばれる手法により、あらかじめ登録したウェブサイトにアクセスしたときにしか認証が成功しない仕組みを実現している。

フィッシング耐性のある認証方式には、WebAuthnのほかにも、マイナポータルで用いられているような、独自のウェブブラウザ拡張機能によって検証者名バインディングに相当する仕組みを実現する方法もある。フィッシング耐性のある認証方式としてWebAuthn以外の独自の方法を用いる場合には、検証者名バインディングに相当する仕組みが適切に実装されたブラウザ拡張機能を用いる必要がある。

強固なパスワードの要件を一律に定めることは困難であるが、少なくとも、一般的に知られる単語1つを用いたものや、キーボードの並び順（「qwertyuiop」等）をなぞったものは、たとえそこに数字や記号を付加しようとも、脆弱であり、設定を許すべきではない。他方、ランダムに生成されたパスワードは、適切な長さであれば、強固なものとなる反面、利用者の記憶を要する場合には必ずしも強制できない面がある。利用者が記憶しやすいランダム生成の強固なパスワードの例としては、ランダムに複数の単語（例えば、10万語の辞書から3語、2万語の辞書から4語など）を選んでつなげたものなどが考えられる。そのようなパスフレーズを用いたパスワードを設定する際は、可能な限り桁数を増やして安全性を高める必要がある。

強固なパスワードに必要な十分な桁数を備えた第三者に容易に推測できないパスフレーズ等を利用者に守らせる機能を実現するには、ランダム生成を支援する機能を提供することや、利用者が入力したパスワード候補に対して、適切なパスワードチェッカー（パスワードの強度を評価するソフトウェア）を用いて、脆弱と判断された候補を拒否する機能を設けることなどが考えられる。ただし、既存のパスワードチェッカーの中には、単語1つやキーボードの並び順に数字や記号を付加しただけで合格としてしまう不完全なものも散見されるので、注意が必要である。適切なパスワードチェッカーの例としては、過去に流出が報告されているパスワード文字列と同じものを不合格と判定するものなどが挙げられるが、これに限られない。

また、設定可能なパスワードについては、以下のような第三者に安易に推測可能なパスワードを使用させないための機能を設けることが重要である。

これらのうち、機能として設けることができないものに関しては、注意喚起するなどの対策を講ずることも考えられる。

さらに、端末やサーバ装置においてパスワードに設定できる桁数等を制限する機能を一元的に管理するための仕組みを用いる場合、利用者に守らせる制限の内容を変更した場合は、新規に登録する識別コードに対してのみ制限の内容を適用するのではなく、既存の識別コードに対しても同様の制限を適用するため、パスワードを再設定させるようにするなどの対策を講ずる必要がある。

また、利用者にパスワードの定期的な変更を求めることは、利用者の利便性を低下させ、利用者が強度の低い安易なパスワードを設定しやすくなるなど、結果的に主体認証機能の安全性を低下させる懸念があるため、実施しないことが望ましい。何らかの理由により必要があって実施する場合は、その理由に応じた適切なタイミングと方法で実施する必要がある。

なお、本解説は情報システムや情報へのアクセス主体を特定するための主体認証情報を設ける際の解説となるが、情報自体を暗号化する場合は、「（解説）基本対策事項3.1.1(6)-2 a)「運搬する情報を暗号化する」について」を参照のこと。

端末やサーバ装置、通信回線装置などで使用されている初期値として利用可能な識別コード（Administrator、root、admin等）は、誰もが識別コードを知っているため不正アクセスの標的となる可能性が高い。そのため、そのような識別コードは無効化し、新たに別の識別コードを用意することが望ましい。やむを得ず、そのような識別コードを使用する場合は、強固な認証技術を用いることが重要である。

情報システムを構築した際、情報システムを構築する際に使用する識別コードやテスト用の識別コードなどを登録している可能性がある。そのような識別コードが残っていると不正に利用される可能性もあるため、運用開始前までに削除又は無効化するなど、利用できないようにする必要がある。

遵守事項

(2) 識別コード及び主体認証情報の管理

(a) 情報システムセキュリティ責任者は、情報システムにアクセスする全ての主体に対して、識別コード及び**主体認証情報を適切に付与**し、管理するための措置を講ずること。

(b) 情報システムセキュリティ責任者は、主体が**情報システムを利用する必要がなくなった場合**は、当該主体の識別コード及び主体認証情報の不正な利用を防止するための措置を速やかに講ずること。

【 基本対策事項 】

＜7.1.1(2)(a)関連＞

7.1.1(2)-1 情報システムセキュリティ責任者は、情報システムを利用する許可を得た主体に対してのみ、識別コード及び主体認証情報を付与（発行、更新及び変更を含む。以下遵守事項7.1.1(2)(a)において同じ。）すること。また、識別コードを情報システムにアクセスする者に交付する際には、身分証明書等による本人確認を行うこと。

7.1.1(2)-2 情報システムセキュリティ責任者は、識別コードの付与に当たっては、以下を例とする措置を講ずること。

a) 単一の情報システムにおいて、ある主体に付与した識別コード（共用識別コードを除く。）を別の主体に対して付与することの禁止

b) 主体への識別コードの付与に関する記録を消去する場合の情報セキュリティ責任者からの事前の許可

7.1.1(2)-3 情報システムセキュリティ責任者は、主体以外の者が識別コード又は主体認証情報を設定する場合、主体以外の者が設定する主体認証情報は**強固なパスワードに必要な十分な桁数を備えた第三者に容易に推測できないパスフレーズ等を設定し、主体へ安全な方法で主体認証情報を配布する**よう、措置を講ずること。

7.1.1(2)-4 情報システムセキュリティ責任者は、識別コード及び知識による主体認証情報を付与された主体に対し、主体以外の者が設定した主体認証情報（必要に応じて、初期設定の識別コードも）を速やかに変更するよう、促すこと。なお、主体認証情報の変更を確認できる機能がある場合は、変更日時を確認し変更がなされない（使用していない）識別コードについては無効にするなどの措置を講ずること。

7.1.1(2)-5 情報システムセキュリティ責任者は、知識による主体認証方式を用いる場合には、**他の情報システムで利用している主体認証情報を設定しない**よう主体に注意を促すこと。

7.1.1(2)-6 情報システムセキュリティ責任者は、情報システムを利用する主体ごとに識別コードを個別に付与すること。ただし、情報システムセキュリティ責任者の判断の下、やむを得ず**共用識別コードを付与する必要がある場合**には、利用者を特定できる仕組みを設けた上で、共用識別コードの取扱いに関する実施手順を整備し、その実施手順に従って利用者に付与すること。

＜7.1.1(2)(b)関連＞

7.1.1(2)-7 情報システムセキュリティ責任者は、主体認証情報の不正な利用を防止するために、主体が情報システムを利用する必要がなくなった場合には、以下を例とする措置を講ずること。

a) 当該主体の**識別コードを無効にする**こと。

b) 当該主体に交付した主体認証情報格納装置を返還させること。

c) 無効化した識別コードを他の主体に新たに発行することを禁止すること。

（解説）

情報システムにおいて認証機能を統合している場合、各機器等の管理者権限を持つローカルアカウントは通常の運用では未使用となるが、その場合においてもデフォルトパスワードのままにせず、設定するパスワードについても同一の値にしないといった措置を講ずる必要がある。

なお、主体認証が必要となる場面が多岐にわたるような情報システムの場合、認証連携を適切に用いることにより、業務の効率化を図ることも考えられる。

情報システムの利用者に対して付与した識別コードの中には、識別コードを付与しても利用しない主体がいる可能性がある。また、人事異動等によって情報システムへアクセスする必要がなくなった識別コードをそのままにしている可能性がある。そのような識別コードを残していると不正に利用される可能性もあるため、不要な識別コードは定期的に確認し、無効にするなどの対処を講ずる必要がある。

強固なパスワードに必要な十分な桁数を備えた第三者に容易に推測できないパスフレーズ等については、「（解説）基本対策事項7.1.1(1)-4「強固なパスワードに必要な十分な桁数を備えた第三者に容易に推測できないパスフレーズ等を使用すること」について」を参照のこと。

利用者以外の者（情報システムの管理者等）が主体認証情報を設定する場合には、以下を例とする方法で、当該主体認証情報を安全な方法で利用者に配布する必要がある。

複数の情報システムにおいて共通の主体認証情報を設定していた場合、ある情報システムから漏えいした主体認証情報が他の情報システムで不正に利用されるというリスクが発生する。機関等の管理下にない情報システムからの漏えいを防止することは不可能であるため、このような情報システムから主体認証情報が漏えいした場合の機関等の情報システムへの影響について考慮する必要がある。対策の例としては、他の情報システムで利用している主体認証情報を機関等の情報システムに設定しないよう注意喚起を表示する、識別コードを情報システム側で割り当てることで識別コードの共通利用を防止する、といった方法が考えられる。

共用識別コードは、その利用履歴だけでは利用者を特定できないため、不正な利用の検知が難しく、また情報セキュリティインシデントが発生した場合の真相究明の支障となる可能性がある。この点を踏まえ、やむを得ず、共用識別コードを利用する場合には、利用者を特定するための以下を例とする仕組みを講ずる必要がある。

また、共用識別コードの主体認証情報は、悪用されないために主体認証情報を知る者を限定するなどの措置を講ずる必要がある。普段は共用識別コードを利用しない職員等が共用識別コードを使用する場合は、一時的に利用する主体認証情報を設定することなどの対策も有効である。

識別コードの付与を最小限に維持するため、退職等により不必要となった識別コードについては、これを無効にする必要がある。また、本人からの届出による場合のほか、登録した識別コードに異常がないことを確認する目的で、定期的に不要な識別コードが存在しないことを確認することが望ましい。

7.1.2 アクセス制御機能

目的・趣旨

アクセス制御とは、情報システム及び情報へのアクセスを許可する主体を制限することである。複数の主体が情報システムを利用する場合、当該情報システムにおいて取り扱う情報へのアクセスを業務上必要な主体のみに限定することによって、情報漏えい等のリスクを軽減することができると考えられる。

遵守事項

(1) アクセス制御機能の導入

(a) 情報システムセキュリティ責任者は、情報システムの特性、情報システムが取り扱う情報の格付及び取扱制限等に従い、権限を有する者のみがアクセス制御の設定等を行うことができる機能を設けること。

(b) 情報システムセキュリティ責任者は、情報システム及び情報へのアクセスを許可する主体が確実に制限されるように、アクセス制御機能を適切に運用すること。

【 基本対策事項 】

＜7.1.2(1)(a)関連＞

7.1.2(1)-1 情報システムセキュリティ責任者は、**主体の属性、アクセス対象の属性に基づくアクセス制御**の要件を定めること。また、情報システムの分類に基づき、以下の対策を実施すること。

**【基本セキュリティ対策】**以下を例とするアクセス制御機能の要件を定めること。

a) 利用時間や利用時間帯によるアクセス制御

b) 同一主体による複数アクセスの制限

c) IPアドレスによる端末の制限

d) ネットワークセグメントの分割によるアクセス制御

e) ファイルに記録された情報へのアクセスを制御するサーバにおいて主体認証を受けたユーザのみが、暗号化されたファイルに記録された情報に対し、与えられた権限の範囲でアクセス可能となる制御

**【追加セキュリティ対策】**基本セキュリティ対策の実施に加えて、以下を例とするアクセス制御機能を用いることを検討すること。

f) **認証・認可の統合管理基盤**を用いたアクセス制御

g) アクセスの要求ごとに、主体等の状況を継続的に認証し認可する仕組みを実現する機能の一部である**動的なアクセス制御**

＜7.1.2(1)(b)関連＞

7.1.2(1)-2 情報システムセキュリティ責任者は、主体の属性、アクセス対象の属性に基づく**アクセス制御の要件の定期的な確認による見直し**をすること。

（解説）

具体的な手法としては、端末や共有フォルダ上のファイルやフォルダ（ディレクトリ）に対する許可属性のリストであるアクセス制御リスト（ACL： Access Control List）が挙げられる。ACLでは例えば、アクセス対象の所有者／所有者の属するグループ／全利用者といったアクセス主体に対して、読み取り／書き込み／実行の権限を設定する。

ただし、一般的な情報システムでは、利用者が適切なアクセス制御の設定を行っても、システムの管理者は全てのファイルやフォルダへアクセス可能である。実際に、運用保守の担当者が、管理者権限相当のアクセス権限を行使して、機密性の高い情報を不正に閲覧するといった事案も確認されている。そのため、アクセス対象が要機密情報等の場合は、アクセス制御機能のみに頼らず、アクセス権限の無い者に閲覧等されないよう、アクセス制限の対象に対して暗号化等の措置を考慮することが求められる。

業務や取り扱う情報の性質・量に応じて、重要な情報に攻撃が到達しないよう、情報システムの重要な情報を取り扱う部分を他の情報システムやインターネットから分離するといった対策をとる必要がある。特に、情報システムの管理を行う部分を独立したネットワークセグメントとし、これをインターネットから切り離すことは、攻撃の拡大阻止の観点から有効である。同時に、ネットワークセグメント分割の意義を損なうことのないよう、各システムで取り扱うことができる情報についてルール化し、職員等に徹底することも重要である。また、他の情報システムやインターネットから論理的に分離をする際は、必要最小限のIPアドレスやプロトコルが通信できるように制御し、許可しない通信に関しては拒否するなどの対策も重要である。

なお、遵守事項5.2.1(3)(a)(オ)において、構築する情報システムのネットワーク構成に関する要件について定めることを求めているが、本基本対策事項は、その際に併せて検討し、情報システムのネットワーク構成の要件を決定するとよい。

ファイル自体にセキュリティ機能を組み込むことで、ファイルに対する閲覧、編集、印刷等の操作を制御する技術（DRM（Digital Rights Management）やIRM（Information Rights Management）として知られるデジタル著作権管理技術）を利用することも考えられる。この技術を利用したファイルは暗号化されるため、ファイルを利用するには、ファイルに記録された情報へのアクセスを制御するサーバで主体認証を受け、正当な主体として認識されること及びファイルへのアクセス権限が付与されていることが必要となる。そのため、第三者がファイルを閲覧しようとしても、主体認証を受け、正当な主体として認識されない限り当該ファイルの内容を参照することはできず、ファイルに記録された情報の漏えいを防止することができる。

また、ファイル利用時には、利用者はファイルの暗号化・復号を意識することなく、付与されたアクセス権限に従った閲覧、編集、印刷等の操作を行えるため、利便性が損なわれることはない。

認証・認可の統合管理基盤とは、それぞれの情報システムにおいて行っている識別コード、主体認証情報、主体の属性等の管理やそれらを使用した主体認証機能及びアクセス制御機能を一元的に実施することを実現するためのものである。そのような基盤を用いてアクセス制御を行うことで、それぞれの情報システム間の整合性を確保しつつ、職員等の異動や機器の交換等による変化に合わせて、常に正しいアクセス制御を実現することができる。

クラウドサービスの利用拡大やテレワークの推進等により、情報システムの利用における業務環境等が変化することで、新たな脅威や攻撃経路などが増大する。このような脅威に対抗するためには、初回のアクセス要求時のみ制御を行うのではなく、情報資産へのアクセスの要求ごとに、アクセスする主体や、アクセス元・アクセス先となる機器、ソフトウェア、サービス、ネットワークなどの状況を継続的に認証し、認可する仕組みを実現する機能の一部と考えられる「動的なアクセス制御」を実装することが有効である。

動的なアクセス制御については、7.3「ゼロトラストアーキテクチャ」を参照のこと。

主体の属性、アクセス対象の属性に基づくアクセス制御の要件については、機関等の業務の変化やクラウドサービス、テレワークといった情報システムの利用環境の変化等により、アクセス制御のセキュリティ要件が変化することを踏まえて、定期的な確認による見直しをする必要がある。

また、アクセス制御の要件の見直しにより、アクセス制御の設定の変更等を実施する場合は、情報システムセキュリティ責任者が指名した監督者の監視の下で設定変更等を実施することや、機械的なチェック機能を設けるなどの設定や修正によるミス等を防止するための対策を行うことが重要である。なお、アクセス制御の見直しを行う場合は、アクセス権限の付与は必要最小限の範囲に限ることを原則とすることが重要である。

7.1.3 権限の管理

目的・趣旨

情報システムのアクセス制御機能を適切に運用するためには、主体から対象に対するアクセスの権限を適切に設定することが必要である。その際、アクセス権限は最小権限の付与とするため、全てにアクセスできないことを前提に、アクセスの必要がある主体に対してのみ権限を付与し、アクセスの必要のない主体に対しては権限を与えないことを原則とすることが重要である。また、情報に対して権限を付与する場合も同様に、知る必要のある主体に対してのみ権限を付与し、知る必要のない主体に対しては権限を与えないことを原則とすることが重要である。なお、権限の管理が不適切になると、情報又は情報システムへ不正アクセスされるおそれが生じる。

また、情報システムの管理機能として、一般的に管理者権限にはあらゆる操作が許可される特権が付与されている。当該特権が悪意ある第三者等に入手された場合、主体認証情報のみならず特権アクセスが可能な情報等の漏えい、改ざん、さらには情報システムや情報を破壊することを目的とした不正プログラムによって業務継続への影響もあり得る。また、これらの不正アクセスや不正プログラム等を検知又は防止するための設定情報等が不正に変更されることによる情報セキュリティ機能の無効化等が懸念されることから、限られた主体のみに管理者権限が付与されることが重要である。

遵守事項

(1) 権限の管理

(a) 情報システムセキュリティ責任者は、主体から対象に対するアクセスの権限を必要最小限の範囲で適切に設定するよう、措置を講ずること。

(b) 情報システムセキュリティ責任者は、管理者権限の特権を持つ主体の識別コード及び主体認証情報が、悪意ある第三者等によって窃取された際の被害を最小化するための措置及び、**内部からの不正操作や誤操作を防止するための措置**を講ずること。

(c) 情報システムセキュリティ責任者は、主体から対象に対する**不要なアクセス権限が付与されていないか定期的に確認する**こと。

【 基本対策事項 】

＜7.1.3(1)(a)関連＞

7.1.3(1)-1 情報システムセキュリティ責任者は、**初期値として利用可能な管理者権限を有する識別コード**には、管理者権限を付与しない又は無効化にすること。

＜7.1.3(1)(b)関連＞

7.1.3(1)-2 情報システムセキュリティ責任者は、主体に対して管理者権限を付与する場合、主体の識別コード及び主体認証情報が、第三者等によって窃取された際の被害を最小化するため、また、管理者による権限の濫用や作業ミスを防ぐため、以下を例とする措置を講ずること。

a) 業務上必要な場合に限定すること。

b) **必要最小限の権限のみ付与**すること。

c) 同一の者が権限の付与と権限の執行を兼ねないようにすること。

d) 管理者権限を行使できる端末をシステム管理者等の専用の端末とすること。

7.1.3(1)-3 情報システムセキュリティ責任者は、管理者権限を有する識別コードの利用は権限を必要とする業務に限定し、一般の業務として使用させないこと。

（解説）

権限管理を行う情報システムのうち、内部からの不正操作や誤操作を防ぐための特に強固な権限管理が必要な情報システムについては、ある処理に対し、複数名による主体認証操作がなければ、その処理自体を完遂できない「デュアルロック機能」や「ワークフロー機能」を導入することが考えられる。

その他の情報システムについては、操作ログを取得することや、確認画面を表示することなどの措置が考えられる。

主体から対象に対するアクセス権限については、人事異動等による主体の業務の変化等に応じて適切に付与する必要がある。特に管理者権限を付与した主体については、情報セキュリティインシデントの発生防止の観点等から管理者権限の付与が不要になった時点で権限を変更するなどの対策を実施する必要がある。また、保守やメンテナンスなどを実施するため、特定の主体に対して一時的に付与した権限については、必要な作業等が終了したら確実に権限の付与を削除する必要がある。したがって、このようなアクセス権限の付与が適切に行われているかを定期的に確認する必要がある。

初期値として利用可能な管理権限を有する識別コードとは、例えば、Administrator、root、adminなどが考えられるが、そのような識別コードは誰もが知っているため不正アクセスの標的となる可能性が高い。そのため初期値として利用可能な管理権限を有する識別コードは無効化することが望ましい。やむを得ず利用する場合においても、管理者権限を付与しない又は権限を最小限にするなどの措置を講ずることを検討することが考えられる。

必要最小限の権限のみ付与とは、権限が利用できる時間的な機会を限定すること又はあらかじめ限られた操作が可能な権限を付与することにより、当該権限を使った不正な操作が発生する機会を減らし、結果的に安全性を強化するものである。

本対策の例として、システムを通常操作するユーザにおいては、あらかじめ実行できるプログラムやアクセス可能な領域を限定した権限を付与し、管理作業をするときに限定して管理者権限を利用することを可能とする方式（Unix系システムにおけるsudo等）が考えられる。

特に核心的な強い権限（アカウント管理者、権限管理者等）は常時付与せず、権限の執行が必要となった時に権限有効化申請を都度実施のうえ、承認を受けたうえで執行することが望ましい。

7.1.4 ログの取得・管理

目的・趣旨

情報システムにおけるログとは、システムの動作履歴、利用者のアクセス履歴、通信履歴その他運用管理等に必要な情報が記録されたものであり、悪意ある第三者等による不正侵入や不正操作等の情報セキュリティインシデント及びその予兆を検知するための重要な材料となるものである。また、情報システムに係る情報セキュリティ上の問題が発生した場合には、当該ログは、事後の調査の過程で、問題を解明するための重要な材料となる。したがって、情報システムにおいては、仕様どおりにログが取得され、また、改ざんや消失等が起こらないよう、ログが適切に保全されなければならない。

遵守事項

(1) ログの取得・管理

(a) 情報システムセキュリティ責任者は、情報システムにおいて、情報システムが正しく利用されていることの検証及び不正侵入、不正操作等がなされていないことの検証を行うために必要なログを取得すること。

(b) 情報システムセキュリティ責任者は、情報システムにおいて、その特性に応じて**ログを取得する目的を設定した上で、ログを取得する対象の機器等、ログとして取得する情報項目、ログの保存期間**、要保護情報の観点でのログ情報の取扱方法等について定め、適切にログを管理すること。

(c) 情報システムセキュリティ責任者は、情報システムにおいて、取得したログを定期的に**点検又は分析**する機能を設け、悪意ある第三者等からの不正侵入、不正操作等の有無について点検又は分析を実施すること。

【 基本対策事項 】

＜7.1.4(1)(b)関連＞

7.1.4(1)-1 情報システムセキュリティ責任者は、所管する情報システムの特性に応じて想定される脅威を分析し、分析事象・観点を見極めた上で、ログとして取得する必要のある情報項目を定め、管理すること。

7.1.4(1)-2 情報システムセキュリティ責任者は、情報システムに含まれる構成要素（サーバ装置・端末等）のうち、時刻設定が可能なものについては、情報システムにおいて基準となる時刻に、当該構成要素の**時刻を同期**させ、ログに時刻情報も記録されるよう、設定すること。

7.1.4(1)-3 情報システムセキュリティ責任者は、取得したログに対する、不正な消去、改ざん及びアクセスを防止するため、適切なアクセス制御を含む、**ログ情報の保全方法**を定めること。

＜7.1.4(1)(c)関連＞

7.1.4(1)-4 情報システムセキュリティ責任者は、取得したログを効率的かつ確実に点検及び分析し、その結果を報告するために、情報システムの分類に応じて以下の対策を実施すること。

**【基本セキュリティ対策】**以下を例とする当該作業を支援する機能を導入すること。

a) ログ情報をソフトウェア等により集計し、時系列で表示し、報告書を生成するなどの作業の**自動化機能**

**【追加セキュリティ対策】**基本セキュリティ対策の実施に加えて、以下を例とする当該作業を支援する機能の導入を検討すること。

b) リアルタイムでのログの調査・分析を行うための機能

（解説）

情報システムにおけるログは、情報セキュリティインシデント発生時や情報セキュリティインシデントの予兆となる現象を特定する際に重要な役割を果たすほか、情報セキュリティインシデント対応及びサイバー脅威の分析においても重要な材料となることから、ログを取得する目的を明確にしたうえで、必要なログを取得・保存し適切に保護、管理する必要がある。

ログを取得する目的は、情報システムの特性（取り扱われる情報、接続されるネットワーク、設置環境、利用者等）や想定される脅威に応じ、当該情報システムでどのような事象を検知すべきか、そのためにはどのような情報をどう分析する必要があるかを見極めた上で設定し、目的を実現するために取得すべきログ情報やその保存期間等を検討する必要がある。

また、ログの取得に当たっては、IoCやアノマリ（異常値）の検知に資する情報が含まれるよう留意する必要がある。

不正アクセス、DoS攻撃、内部不正による情報漏洩、マルウェア感染等の脅威に対する分析事象・観点の設定方法、必要な情報・分析などについては、デジタル庁「政府情報システムにおける脅威の検知・対応のためのログ取得・分析導入ガイドブック」に例示があるため、参考にするとよい。

参考：デジタル庁「政府情報システムにおける脅威の検知・対応のためのログ取得・分析導入ガイドブック」（https://www.digital.go.jp/resources/standard_guidelines）

保存期間については、情報システム又は当該システムに保存される情報の特性に基づき、設定される。ただし、情報セキュリティインシデント対応やサイバー脅威の分析の必要性も踏まえ、関連するガイドラインや想定されるリスクに基づき設定することが望ましい。標的型攻撃に関し、攻撃の初期段階から経緯を確認する観点からは、過去の事例を踏まえ、ログは１年間以上保存することが望ましい。

なお、ログの長期保存にはコストがかかるため、費用を抑える観点から、直近のログはすぐに調査可能なハードディスク等のオンラインの電磁的記録媒体に保存し、それ以降はテープや光ディスク等の長期保存に適した外部電磁的記録媒体に保存する方法も考えられる。オンラインの電磁的記録媒体に保存する期間については、過去に遡って調査する期間や頻度、どの程度のコストをログの保存にかけられるかを考慮して決定する。

情報システムの特性等に応じて、点検・分析の頻度や分析の精度を高める必要がある場合には、ログを分析するための製品であるSIEMなどを導入することや監視事業者への委託を検討することが考えられる。

具体的な実装例としては、ログを取得する機器のシステム時刻を、タイムサーバを用いて同期する方法がある。タイムサーバは、NTP（Network Time Protocol）やSNTP（Simple Network Time Protocol）等の方式により、ネットワーク上のクライアント機器に対して、時刻を提供する。例えば、公開NTPサービスを用いる方式や組織内にタイムサーバを設置し、サーバ装置・端末・通信回線装置をタイムサーバに時刻同期するよう設定する方式が挙げられる。後者については、タイムサーバを複数利用することにより、時刻の精度や冗長性を高めることができる。

また、機器によっては明示的に設定を行わないとログに出力する時刻が現地時間とならない場合があるため注意が必要である。

取得したログ情報に対する不正な消去、改ざん及びアクセスを防止するためのログ情報の保全方法として、以下の例が考えられる。

ログとして取得する項目数、利用者数等が多くなるにつれて、ログの量は膨大になり、システム担当者等がログを目視することによって問題（又はその予兆）を検出するのは、困難を極める。システム自体に実装される機能や各種運用管理ツールを組み合わせ、ログの点検・分析・通知が自動的に実行されるなど、ログ管理作業を支援する仕組みを構築することが望ましい。

リアルタイムでのログの調査・分析を行うための機能を具備する製品については、SIEMなどが考えられる。

SIEMを利用することにより、端末、サーバ装置、通信回線装置等の様々なログを組み合わせた相関分析を行うことができ、特定のログ分析だけでは検知できなかった異常が検知できるだけでなく、リアルタイムで自動的に異常を検出できるようになるため、情報セキュリティインシデントへの対処開始に要する時間が短縮できる。

ただし、SIEM等によるリアルタイムでのログの調査・分析を行うための機能を情報システムに実装する場合、導入だけでなく、運用・保守の業務負荷等が増大することから、高度なセキュリティ対策が必要となる情報システム、情報システムを利用して行う業務等を勘案し、導入を判断することが望ましい。

また、収集したログをSIEM 等のシステムで一元的に保存する場合は、許可された管理者のみがアクセスできるようアクセス制御を施すことが望ましい。

また、SIEM等によるリアルタイムでのログの調査・分析を行うための機能を実装しない場合、ファイアウォール、IDS/IPS、EDR、NDR（Network Detection and Response）等のセキュリティ対策機器やソフトウェアに加え、SOC（Security Operation Center）やNOC（Network Operations Center）等での監視を実施するなどの対策を講ずることを検討するとよい。

7.1.5 暗号・電子署名

目的・趣旨

情報システムで取り扱う情報の漏えい、改ざん等を防ぐための手段として、暗号と電子署名は有効であり、情報システムにおける機能として適切に実装することが求められる。

暗号化機能及び電子署名機能を導入する際は、使用する暗号アルゴリズム及び鍵長に加え、それを用いた暗号プロトコルが適切であること、運用時に当該アルゴリズム又は鍵長が危殆化した場合や当該プロトコルに脆弱性が確認された場合等の対処方法及び関連する鍵情報の適切な管理等を併せて考慮することが必要となる。

遵守事項

(1) 暗号化機能・電子署名機能の導入

(a) 情報システムセキュリティ責任者は、情報システムで取り扱う情報の漏えいや改ざん等を防ぐため、以下の全ての措置を講ずること。

(ア) 要機密情報を取り扱う情報システムについては、暗号化を行う機能の必要性の有無を検討し、必要があると認めたときは、当該機能を設けること。

(イ) 要保全情報を取り扱う情報システムについては、電子署名の付与及び検証を行う機能を設ける必要性の有無を検討し、必要があると認めたときは、当該機能を設けること。

(b) 情報システムセキュリティ責任者は、暗号技術検討会及び関連委員会（CRYPTREC）により安全性及び実装性能が確認された**「電子政府推奨暗号リスト」に基づき、情報システムで使用する暗号及び電子署名のアルゴリズム及び鍵長**並びにそれらを利用した安全なプロトコルを定めること。また、その運用方法について実施手順を定めること。

(c) 情報システムセキュリティ責任者は、機関等における暗号化及び電子署名のアルゴリズム、鍵長及び運用方法に、電子署名を行うに当たり、電子署名の目的に合致し、かつ適用可能な**公的な公開鍵基盤が存在する場合はそれを使用する**など、目的に応じた適切な公開鍵基盤を使用するように定めること。

【 基本対策事項 】

＜7.1.5(1)(a)関連＞

7.1.5(1)-1 情報システムセキュリティ責任者は、暗号化又は電子署名を行う情報システムにおいて、以下を例とする措置を講ずること。

a) 情報システムのコンポーネント（部品）として、**暗号モジュールを交換**することが可能な構成とすること。

b) **複数のアルゴリズム、鍵長及びそれらに基づいた安全なプロトコルを選択**することが可能な構成とすること。

c) 選択したアルゴリズム及び鍵長がソフトウェア及びハードウェアへ適切に実装されており、かつ、暗号化された情報の復号又は電子署名の付与に用いる鍵及びそれに対応する主体認証情報等が安全に保護されることを確実にするため、**「暗号モジュール試験及び認証制度」に基づく認証**を取得している製品を選択すること。

d) 暗号化された情報の復号又は電子署名の付与に用いる鍵については、**耐タンパ性**を有する暗号モジュールへ格納すること。

e) 機微な情報のやり取りを行う情報システムを新規に構築する場合は、**安全性に実績のあるプロトコルを選択し、長期的な秘匿性**を保証する観点を考慮すること。

＜7.1.5(1)(b)関連＞

7.1.5(1)-2 情報システムセキュリティ責任者は、職員等が暗号や電子署名を利用する場合、あるいは情報システムの新規構築や更新に伴い、暗号化又は電子署名を導入する場合において、情報システムで使用するアルゴリズム及び鍵長並びにそれらを利用した安全なプロトコルを、「電子政府推奨暗号リスト」に基づき定めること。

7.1.5(1)-3 情報システムセキュリティ責任者は、基本対策事項7.1.5(1)-2で定めた事項の運用方法について、以下を全て含めて実施手順として定めること。

a) 暗号化及び電子署名に使用する**アルゴリズム又は鍵長が危殆化**した場合又はそれらを利用した安全なプロトコルに脆弱性が確認された場合を想定した緊急対応手順を定めること。

b) 暗号化された情報の復号又は電子署名の付与に用いる鍵について、管理手順を定めること。

（解説）

職員等が暗号や電子署名を利用する場合、あるいは情報システムの新規構築や更新に伴い、暗号化又は電子署名を導入する場合においては、「電子政府推奨暗号リスト」に記載されたアルゴリズム及び鍵長を定めることが原則である。

しかし、職員等が利用するソフトウェアや連携する他の情報システム側が「電子政府推奨暗号リスト」に記載されたアルゴリズム又は鍵長に対応していない等の場合は、利用実績が不十分であること、また、今後の普及が見込めない可能性があることによる影響を踏まえた上で、「推奨候補暗号リスト」に記載されたアルゴリズム及び鍵長を利用するとよい。

なお、「運用監視暗号リスト」に記載されたアルゴリズム及び鍵長は互換性維持以外の目的での利用をしてはならない。また、互換性維持の目的であったとしても、暗号が解読される等のリスクが考えられるため、「電子政府推奨暗号リスト」に記載されたアルゴリズム及び鍵長への移行を検討する必要がある。

参考：CRYPTREC「電子政府における調達のために参照すべき暗号のリスト（CRYPTREC暗号リスト）」（CRYPTREC LS-0001-2022R2） （https://www.cryptrec.go.jp/list/cryptrec-ls-0001-2022r2.pdf）

「電子政府における調達のために参照すべき暗号のリスト（CRYPTREC暗号リスト）」に掲載されている暗号技術を利用する際に、利用する鍵長について、「暗号強度要件（アルゴリズム及び鍵長選択）に関する設定基準」の規定に合致しない鍵長を用いた場合には、「電子政府推奨暗号リスト」の暗号技術を利用しているとは見なしていないことに留意が必要である。

参考：CRYPTREC「暗号強度要件（アルゴリズム及び鍵長選択）に関する設定基準」（CRYPTREC LS-0003-2022R1） （https://www.cryptrec.go.jp/list/cryptrec-ls-0003-2022r1.pdf）

保健医療福祉分野の公開鍵基盤（HPKI）のように特定の分野における公的なPKIが存在し、その使用が求められる場合に、当該PKIを使用することが考えられる。

また、政府機関及びその職員が申請・届出等手続において電子署名を行う際には政府認証基盤（GPKI）を使用することが考えられる。

暗号モジュールは、暗号化、電子署名、ハッシュ関数等の暗号に関連した機能を提供するソフトウェアの集合体又はハードウェアとして定義される。選択した暗号化アルゴリズム又は鍵長が将来危殆化することを想定し、暗号モジュールの交換が可能な構成とすることを、情報システムの設計段階から考慮する必要がある。

また、事前に暗号モジュールのアプリケーションインタフェースを統一することなどを考慮する必要がある。

選択したアルゴリズム又は鍵長が将来危殆化することを想定し、危殆化していない他のアルゴリズム及び鍵長へ直ちに変更できる機能と併せて、暗号利用モード等との組合せ等により脆弱性の顕在化が認められない安全なプロトコルを選択できる機能も、あらかじめ情報システムに設けておく必要がある。

アルゴリズム及び鍵長自体が安全であっても、それをソフトウェアやハードウェアへ実装する際、生成する擬似乱数に偏りが生じるなどの理由で擬似乱数が推測可能であったり、鍵によって処理時間に統計的な偏りが生じるなどの理由で鍵情報の一部が露呈したりすると、情報システムの安全性が損なわれるおそれがあることから、これらを確認するには、ISO/IEC 19790に基づく「暗号モジュール試験及び認証制度」が利用可能である。

JIS X 19790（ISO/IEC 19790）の規定によると、耐タンパ性は以下の３つの機能から構成される。

また、暗号モジュールを利用する環境等に応じ、セキュリティレベルが１から４まで設定されている。セキュリティレベル１は、最小限の物理的保護を要求している。セキュリティレベル２では、タンパ証跡メカニズムの追加を要求している。セキュリティレベル３では、除去可能なカバー及びドアに対して、タンパ検出及びタンパ応答メカニズム付きの強固な囲いの利用の要求事項を追加している。セキュリティレベル４では、囲い全体に対して、タンパ検出及びタンパ応答メカニズム付きの強固な囲いの利用の要求事項を追加している。

なお、タンパ検出及びタンパ応答は、タンパ証跡の代わりにはならない。

暗号モジュールの耐タンパ性に関わるセキュリティレベルは、情報システムが取り扱う以下の特性を踏まえて選択することが望ましい。

情報システムで暗号を用いるとき、暗号アルゴリズム及び鍵長の適切な選択に加え、暗号プロトコル（暗号アルゴリズム及び鍵長をどのように用いるかの手順）が適切なものとなっている必要がある。一般に、情報システムを新規に構築するときに、独自の暗号プロトコルを設計することは、その安全性について十分に検証されないときは、期待される安全性が確保されていない可能性がある。安全な暗号プロトコルの設計は高度な専門性を有する者以外には容易なことではないため、可能な限り、独自の設計を避け、既に広く利用実績のある著名な暗号プロトコルを用いることが求められる。

なお、必要とする機能を実現する暗号プロトコルとして既存のものが存在しない場合はこの限りでないが、独自に暗号プロトコルを設計するときは、その安全性に関して十分に検証する必要がある。

情報システム上で機微な情報のやり取りを行う場合、情報を暗号化して通信しても、その暗号文が悪意ある第三者等に傍受され、将来の解読に備えて長期間にわたり保管されるという脅威が想定される。この場合に、前方秘匿性を有しない暗号プロトコルを用いた結果、公開鍵暗号の鍵交換で使用した秘密鍵（以下本解説において「秘密鍵」という。）が将来破られることになれば、過去に遡って全ての暗号文が解読されてしまうことになる。「前方秘匿性」とは、秘密鍵に対して乱数を付加することで、毎回異なる秘密鍵を使ったセッション鍵の共用により、秘密鍵が破られた場合でも乱数が破られなければ、過去に遡った暗号文が解読される可能性を低減することができる性質のことをいう。なお、TLSで使う暗号スイートの中では、DHE（Ephemeral DH）及びECDH（Ephemeral ECDH）方式が前方秘匿性を有している。

そのため、長期の機密性を確保する必要のある機微な情報のやりとりを行う情報システムを構築するときは、前方秘匿性を実現する暗号プロトコルの採用を検討し、必要かつ可能であれば、採用することが求められる。

暗号化や電子署名に用いられる暗号アルゴリズム及び鍵長は、年月が経つにつれ、情報システムの処理能力の向上や新たな暗号解読技法の考案等によって、アルゴリズム及び鍵長の設計当初の強度を失い、結果として、安全性を保てなくなる。

暗号アルゴリズム及び鍵長の強度には理論上の強度及び実装上の強度が存在する。理論上の強度の低下は情報システムの処理能力の向上や暗号解読法の考案によるところが大きく、実装上の強度の低下はサイドチャネル攻撃等の攻撃技術によるところが大きい。サイドチャネル攻撃の例として、実装時に暗号アルゴリズム及び鍵長の動作に伴う消費電力や暗号モジュールから漏えいする電磁波等の付加的な情報を悪意ある第三者等が知り得る場合には、実装上の強度は極端に低下する可能性がある。

暗号化された情報の復号又は電子署名の付与に用いる鍵（以下本解説において「鍵」という。）の管理手順として、CRYPTRECが発行している「暗号鍵管理システム設計指針（基本編）」や「暗号鍵設定ガイダンス」を参照しつつ、以下の視点を含む鍵のライフサイクルを考慮した管理手順を策定するとよい。また、暗号化された情報の復号や電子署名の付与の際には、本人及び管理上必要のある者のみが知り得る秘密の情報を用いる必要があることから、適切に管理する必要がある。

参考：CRYPTREC「暗号鍵管理システム設計指針（基本編）」（CRYPTREC GL-3002-1.1） （https://www.cryptrec.go.jp/report/cryptrec-gl-3002-1.1.pdf）

参考：CRYPTREC「暗号鍵設定ガイダンス」（CRYPTREC GL-3003-1.0.1） （https://www.cryptrec.go.jp/report/cryptrec-gl-3003-1.0.1.pdf）

遵守事項

(2) 暗号化・電子署名に係る管理

(a) 情報システムセキュリティ責任者は、暗号及び電子署名を適切な状況で利用するため、以下の全ての措置を講ずること。

(ア) 電子署名の付与を行う情報システムにおいて、電子署名の正当性を検証するための情報又は手段を、署名検証者へ安全な方法で提供すること。

(イ) 暗号化を行う情報システム又は電子署名の付与若しくは検証を行う情報システムにおいて、暗号化又は電子署名のために選択されたアルゴリズム又は鍵長の危殆化及びプロトコルの脆弱性に関する情報を定期的に入手し、必要に応じて、職員等と共有を図ること。

【 基本対策事項 】

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

7.1.5(2)-1 情報システムセキュリティ責任者は、署名検証者が、電子署名の正当性を容易に検証するための情報を入手できるよう、以下を例とする方法により、当該情報の提供を可能とすること。

a) 信頼できる機関による電子証明書の提供

b) 機関等の窓口での電子証明書の提供

（解説）

例えば、信頼できる機関のサイトから、利用者が電子署名を検証するための電子証明書をダウンロードできるように環境を整備する方法である。利用者はダウンロードした電子証明書を端末に取り込み、それを基に署名検証を行う。

機関等において、利用者に電子署名を検証するための電子証明書を電磁的記録媒体で配布する方法である。利用者は電磁的記録媒体経由で電子証明書を端末に取り込み、それを基に署名検証を行う。

7.1.6 監視機能

目的・趣旨

情報システムにおける情報セキュリティインシデントや不正利用等の速やかな認知や、情報セキュリティ対策の実効性を確認するためには、適切に監視機能を実装し、運用することが重要である。また、監視機能の実装に当たっては、情報システムの特性や当該情報システムで取り扱う情報の格付等を踏まえて、監視対象や監視内容を定める必要がある。

遵守事項

(1) 監視機能の導入・運用

(a) 情報システムセキュリティ責任者は、情報システム運用時の監視に係る運用管理機能要件を策定し、**監視機能を実装**すること。

(b) 情報システムセキュリティ責任者は、情報システムの運用において、情報システムに実装された監視機能を適切に運用すること。

(c) 情報システムセキュリティ責任者は、新たな脅威の出現、運用の状況等を踏まえ、情報システムにおける監視の対象や手法を定期的に見直すこと。

【 基本対策事項 】

＜7.1.6(1)(a)(c)関連＞

7.1.6(1)-1 情報システムセキュリティ責任者は、監視のために必要な機能について、**以下を例とする機能**を調達仕様書等に明記すること。

a) 機関等外と通信回線で接続している箇所における外部からの不正アクセスやサービス不能攻撃を監視する機能

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

c) 端末等の組織内ネットワークの末端に位置する機器及びサーバ装置において不正プログラムの挙動を監視する機能

d) 機関等内通信回線への端末の接続を監視する機能

e) 端末への外部電磁的記録媒体の挿入を監視する機能

f) サーバ装置等の機器の動作を監視する機能

g) **ネットワークセグメント間の通信を監視**する機能

7.1.6(1)-2 情報システムセキュリティ責任者は、暗号化された通信データを**監視のために復号することの要否**を判断し、要すると判断した場合は、当該通信データを復号する機能及び必要な場合はこれを再暗号化する機能を調達仕様書等に明記すること。

＜7.1.6(1)(b)関連＞

7.1.6(1)-3 情報システムセキュリティ責任者は、情報システムのセキュリティ監視について、以下の内容を全て含む**監視手順**を定め、適切に監視運用すること。

a) 監視するイベントの種類や重要度

b) 監視体制

c) 監視状況の報告手順や重要度に応じた報告手段

d) 情報セキュリティインシデントの可能性を認知した場合の報告手順

e) 監視運用における情報の取扱い（機密性の確保）

7.1.6(1)-4 **【追加セキュリティ対策】情報システムセキュリティ責任者は、情報システム運用時の監視において、SOCやNOC等のセキュリティ監視を専門の外部事業者に業務委託**することを検討すること。

（解説）

監視機能により監視を求められる対象やイベントは、情報システム及び取り扱う情報の格付や取扱制限等を考慮して必要性を見極める必要がある。職員等による情報窃取等の不正な動作を監視し、これらの不正な動作を検知・防止する内部脅威対策機能を備えたDLPの仕組みの導入を検討してもよい。

監視の対象やイベントとしては、以下が考えられる。また、監視の対象やイベントについては、新たな脅威の出現、運用の状況等により、定期的に見直す必要がある。

なお、監視に係る運用管理機能要件の策定の際には、イベント情報を効率的に活用できるようにするため、当該情報を収集する際のデータ形式については、その標準化の動向を踏まえ、一般的に用いられる見込みのある形式をとることが望ましい。

ここに例示した監視機能について、情報システムの構成を踏まえ、それぞれに監視対象となる脅威が存在するかどうかを検討し、脅威が存在すると判断した場合には、その全てを監視対象とすることが望ましい。

異なるネットワークセグメントを接続する通信回線装置において、異なるネットワークセグメント間の通信を監視することにより、攻撃者による侵入範囲の拡大（ラテラルムーブメント：横方向の侵害）の試み等検知することを想定している。

監視のために復号することの要否については、個人情報等の取り扱う情報の特性によって判断するとよい。

情報システムのセキュリティ監視を行う体制を特別に設けずに、情報システムの運用を行う体制にてセキュリティ監視を行うことも考えられる。

監視によりプライバシーを侵害する可能性がある場合は、対象となる関係者への説明等の手順についても機関等として定めておく必要がある。

24時間365日のセキュリティ監視の必要がある場合、セキュリティ監視を専門の外部事業者に業務委託することが考えられる。当該業務を外部事業者に請け負わせることは、「業務委託」に該当することから、4.1「業務委託」の規定を遵守する必要がある。さらに、機関等内通信回線に接続した機器等に対してインターネット等の外部ネットワークから直接接続してリモート監視を行わせる場合は、遵守事項6.4.1(2)(c)も遵守する必要がある。また、外部事業者の選定に際しては、事業者における一定の技術要件及び品質管理要件を確保する観点から、経済産業省が定める「情報セキュリティサービス基準」及び当該基準を満たすと認められた企業を掲載した「情報セキュリティサービス基準適合サービスリスト」（うちセキュリティ監視・運用サービスに係る部分）を活用することが考えられる。

7.2 情報セキュリティの脅威への対策

7.2.1 ソフトウェアに関する脆弱性対策

目的・趣旨

機関等の情報システムに対する脅威としては、第三者が情報システムに侵入し機関等の重要な情報を窃取・破壊する、第三者が過剰な負荷をかけ情報システムを停止させるなどの攻撃を受けることが想定される。特に、個人情報等の重要な情報の漏えい等が発生した場合、国民生活に多大な影響を及ぼすとともに機関等に対する社会的な信用が失われる。

このような攻撃では、情報システムを構成するサーバ装置、端末及び通信回線装置のソフトウェアの脆弱性を悪用されることが多く見受けられる。したがって、機関等の情報システムにおいては、ソフトウェアに関する脆弱性について、迅速かつ適切に対処することが求められる。

なお、情報システムを構成するハードウェアに関しても、同様に脆弱性が存在する場合があるので、5.2.2「情報システムの調達・構築」の規定も参照し、必要な対策を講ずる必要がある。

遵守事項

(1) ソフトウェアに関する脆弱性対策の実施

(a) 情報システムセキュリティ責任者は、サーバ装置、端末及び通信回線装置の設置又は運用開始時に、当該機器上で利用するソフトウェアに関連する公開された脆弱性についての対策を実施すること。

(b) 情報システムセキュリティ責任者は、**公開された脆弱性の情報がない段階において、サーバ装置、端末及び通信回線装置上でとり得る対策**がある場合は、当該対策を実施すること。

(c) 情報システムセキュリティ責任者は、**サーバ装置、端末及び通信回線装置上で利用するソフトウェアにおける脆弱性対策の状況を定期的及び適時に確認**すること。

(d) 情報システムセキュリティ責任者は、脆弱性対策の状況の定期的な確認により、脆弱性対策が講じられていない状態が確認された場合並びにサーバ装置、端末及び通信回線装置上で利用するソフトウェアに関連する脆弱性情報を入手した場合には、セキュリティパッチの適用又はソフトウェアのバージョンアップ等による情報システムへの影響を考慮した上で、ソフトウェアに関する脆弱性対策計画を策定し、措置を講ずること。

【 基本対策事項 】

＜7.2.1(1)(a)関連＞

7.2.1(1)-1 情報システムセキュリティ責任者は、サーバ装置、端末及び通信回線装置の設置又は運用開始時に以下の対策を実施すること。

**【基本セキュリティ対策】インターネット向けにサービスを公開しているサーバ装置や直接インターネットから到達可能なサーバ装置、端末及び通信回線装置に対し脆弱性診断を実施**すること。また、その他のサーバ装置、端末及び通信回線装置については、情報システムの分類や保有する情報、システム特性等を踏まえ、脆弱性診断の実施を検討すること。

**【追加セキュリティ対策】サーバ装置、端末及び通信回線装置に対し脆弱性診断を実施すること。また、脆弱性診断の実施に当たっては、ペネトレーションテスト、TLPT（脅威ベースのペネトレーションテスト）等の高度な脆弱性診断**の実施を検討すること。

＜7.2.1(1)(a)(c)関連＞

7.2.1(1)-2 情報システムセキュリティ責任者は、対象となるソフトウェアの脆弱性に関して、以下を全て含む**情報を適宜入手**すること。

a) 脆弱性の原因

b) 影響範囲

c) 対策方法

d) 脆弱性を悪用する不正プログラムの流通状況

7.2.1(1)-3 情報システムセキュリティ責任者は、利用するソフトウェアは**サポート期間を考慮して選定し、サポートが受けられないソフトウェア**は利用しないこと。

7.2.1(1)-4 情報システムセキュリティ責任者は、構成要素ごとに**ソフトウェアのバージョン等を把握**し、当該ソフトウェアの脆弱性の有無を確認すること。

7.2.1(1)-5 情報システムセキュリティ責任者は、**情報システムを構成する機器へのセキュリティパッチの適時の適用を前提とした運用設計**を行い、実行可能な運用体制を構築・維持すること。

＜7.2.1(1)(c)関連＞

7.2.1(1)-6 **【追加セキュリティ対策】情報システムセキュリティ責任者は、サーバ装置、端末及び通信回線装置の運用時に、定期的な**脆弱性診断（ペネトレーションテスト、TLPT等の高度な脆弱性診断を含む。）の実施を検討すること。

7.2.1(1)-7 情報システムセキュリティ責任者は、脆弱性対策の状況を確認する間隔を、可能な範囲で短くすること。

＜7.2.1(1)(d)関連＞

7.2.1(1)-8 情報システムセキュリティ責任者は、ネットワーク境界にある通信回線装置や認証サーバ、要機密情報を保有するサーバ等の**サイバーセキュリティリスクが高い機器等**に対しては、原則、セキュリティパッチの適用又はソフトウェアのバージョンアップ等の措置を講ずること。リスク評価結果を踏まえ措置を講じないと判断した場合には、リスク評価結果の記録を残すこと。

7.2.1(1)-9 情報システムセキュリティ責任者は、ソフトウェアに関する脆弱性対策計画を策定する場合には、サイバー攻撃の高度化・自動化等の技術や脅威の動向を踏まえ、迅速な対策が必要であるかどうかを見極めた上で、以下の全ての事項について判断すること。

a) 対策の必要性

b) 対策方法。この際、**自動でソフトウェアを更新する機能を有するIT資産管理ソフトウェア**を導入するなどにより、効率的に脆弱性対策を実施する手法をあらかじめ決定すること。

c) 対策方法が存在しないゼロデイと呼ばれる状態の場合又は対策が完了するまでの期間に対する**一時的な回避方法**

d) 対策方法又は回避方法が情報システムに与える影響。迅速な対策が必要である場合は情報システムの運用を一時停止することも検討すること。

e) 対策の実施予定時期

f) **対策試験**の必要性

g) 対策試験の方法

h) 対策試験の実施予定時期

7.2.1(1)-10 情報システムセキュリティ責任者は、脆弱性対策が計画どおり実施されていることについて、実施予定時期の経過後、遅滞なく確認すること。

7.2.1(1)-11 情報システムセキュリティ責任者は、脆弱性対策を実施する場合には、少なくとも以下の全ての事項を記録し、これらの事項のほかに必要事項があれば適宜記録すること。

a) 実施日

b) 実施内容

c) 実施者

7.2.1(1)-12 情報システムセキュリティ責任者は、セキュリティパッチ、バージョンアップソフトウェア等の脆弱性を解決するために利用されるファイル（以下「対策用ファイル」という。）は、信頼できる方法で入手し、完全性を検証すること。

（解説）

対策としては、データ実行防止機能（DEP、Exec-Shield）の有効化、特定のメモリ上の実行権限の削除等の対策を実施すること等が挙げられる。

情報システムの構築時に、ソフトウェアを効率的に開発するために使用するソフトウェアフレームワークやソフトウェア部品が情報システムに組み込まれて納入される場合があることについても考慮する必要がある。当該フレームワークや部品についても脆弱性対策の状況を定期的に確認することが求められる。これを確実に実施するためには、対象とするソフトウェアの管理簿を作成することが望ましい。また、これらのソフトウェアには外部から入手するもののみでなく、機関等が自ら開発するもの及び委託により開発するものについても含まれる。

定期的に加え、脆弱性を悪用する不正プログラムの流通が確認されたり、当該脆弱性を悪用した被害が多く発生している等の重大な脆弱性が公開された場合には、適時、当該脆弱性の対策状況を確認する必要がある。

インターネットから攻撃を受ける可能性のあるサーバ装置、端末及び通信回線装置を想定している。グローバルIPアドレスが付与されているサーバ装置等は直接インターネットから到達可能なため、対象とする必要がある。また、グローバルIPアドレスを直接付与されていない場合であっても、静的NAT（Network Address Translation）により実質的にグローバルIPアドレスを付与されているものと同じと考えられる場合は、これも対象とする必要がある。

OSや各種サーバ、ファイアウォール等の通信回線装置等における脆弱性対策の状況を効率的に確認する方法として、専用ツールを用いて機関等自らが脆弱性診断を行ったり、事業者が提供するサービス等を利用して脆弱性診断を行うことが挙げられる。脆弱性診断には、ソースコード診断、プラットフォーム診断、ウェブアプリケーション診断等の種類があり、ソフトウェアの種類によって利用する脆弱性診断を使い分ける必要がある。

ソースコード診断では、独自に開発したソフトウェアのソースコードを対象に、静的解析ツール等を用いて脆弱性の有無を検証する。したがって、運用開始までにソースコード診断を実施し、運用開始後にソースコードへ修正を加えた場合は、再度診断を実施することが望ましい。

プラットフォーム診断では、OSや各種サーバ、ファイアウォール等を対象に、テスト用の通信パケットを送信するなどの方法によって、最新のセキュリティパッチが適用されているか、設定が適切に行われているか、不要な通信ポートが開いていないかなどを検証する。したがって、運用開始までにプラットフォーム診断を実施し、その後も例えば年に１回診断を実施するなど、定期的に実施することが望ましい。

ウェブアプリケーション診断では、独自に開発したウェブアプリケーションを対象に、実際に不正なデータをウェブアプリケーションに送信するなどの方法によって、SQLインジェクションやクロスサイトスクリプティング等の脆弱性が存在しないかを検証する。したがって、運用開始までにウェブアプリケーション診断を実施し、運用開始後においても、ウェブアプリケーションへ修正を加えた場合や新たな脅威が確認された場合は、再度診断を実施することが望ましい。診断の項目等については、OWASPのASVSを参考にするとよい。

なお、事業者が提供するサービス等を利用して脆弱性診断を行う場合には、事業者における一定の技術要件及び品質管理要件を確保する観点から、経済産業省が定める「情報セキュリティサービス基準」及び当該基準を満たすと認められた企業を掲載した「情報セキュリティサービス基準適合サービスリスト」（うち脆弱性診断サービスに係る部分）を活用することが考えられる。また、脆弱性診断の種別や対象範囲、事業者が提供するサービス等の検討に当たっては「政府情報システムにおける脆弱性診断導入ガイドライン」を参考にするとよい。

開発を伴わない情報システムの導入を行う場合（パッケージ製品をプログラム開発なしのパラメータ変更のみで利用する場合やSaaSサービスを利用する場合）やクラウドサービス等で利用者側の脆弱性診断が禁止されている場合については、ベンダから当該製品やサービスに関する脆弱性診断の実施結果等の証跡を徴求し、脆弱性対策が行われていることを確認する必要がある。また、証跡の徴求も困難な場合については、自組織の対策基準に基づきリスク評価を行った上で利用する必要がある。

参考：デジタル庁「政府情報システムにおける脆弱性診断導入ガイドライン」 （https://www.digital.go.jp/resources/standard_guidelines/）

事業者が提供するサービス等を利用してペネトレーションテストを行う場合には、事業者における一定の技術要件及び品質管理要件を確保する観点から、経済産業省が定める「情報セキュリティサービス基準」及び当該基準を満たすと認められた企業を掲載した「情報セキュリティサービス基準適合サービスリスト」（うちペネトレーションテスト（侵入試験）サービスに係る部分）を活用することが考えられる。

情報システムを構成するサーバ装置、端末及び通信回線装置上で利用するソフトウェアの脆弱性に関する情報は、製品ベンダや脆弱性情報提供サイト等を通じて適時調査を行う必要がある。自動アップデート機能を持つソフトウェアの場合には、当該機能を利用して、定期的に脆弱性に関連する情報が報告されているかを確認する方法で差し支えないが、自動アップデート機能の対象範囲を把握し、対象範囲外のソフトウェアについては適時調査を行う必要がある。例えば、ウェブアプリケーションの開発にソフトウェアフレームワークを利用する場合があるが、そのようなソフトウェアフレームワークは自動アップデートが行えないのが通常であるため、脆弱性の有無について適宜調査を行う必要がある。

入手した脆弱性に関連する情報及び対策方法に関しては、脆弱性対策を効果的に実施するために、他の情報システムセキュリティ責任者と共有することが望ましい。

脆弱性が既知になると、インターネット上の情報交換コミュニティ等を通じて、その脆弱性を悪用する方法が考案され、その悪用方法を機械的に実行するための不正プログラム（exploitコードとも呼ばれる。）が作られ、次第に広まっていく。この「脆弱性を悪用する不正プログラム」が流通している段階に入ると、脆弱性が攻撃されるリスクが格段に高まると考えられる。脆弱性を悪用する不正プログラムが世の中に流通していることが確認された場合には、速やかに当該の脆弱性について対処することを検討する必要がある。

利用するソフトウェアのサポート期間が過ぎた場合、それ以降はセキュリティ関連の脆弱性を修正するためのセキュリティパッチは、原則としてソフトウェアベンダから提供されなくなる。したがって、情報システムのライフサイクルを考慮し、少なくとも情報システムの次期改修までは対策用ファイルの提供が継続されるソフトウェアを選定する必要がある。

また、情報システムは特定のソフトウェアバージョンに依存しないよう設計することが望ましいが、情報システムの中には、特定のソフトウェアバージョンに強く依存する場合がある。この場合には、ソフトウェアをバージョンアップすることが困難となるが、新しいバージョンのソフトウェアでしか対処できない脆弱性が発生したときに、情報システムの停止という最悪の事態も想定される。したがって、情報システムが特定のソフトウェアバージョンに依存せざるを得ない場合には、当該ソフトウェアのサポート期間を考慮して情報システムの更改について検討する必要がある。

ソフトウェアベンダによるサポートや他の事業者によるサポートサービスが一切受けられないものを対象としている。ソフトウェアベンダの製品ロードマップの見直し等により、サポートの打ち切りが突然予告されることもあり得るため、利用するソフトウェアのサポート期間に関する情報を適時入手し、ソフトウェア更改やサポート事業者の切替え等の対策が適切に講じられるよう考慮することが望ましい。

ソフトウェアのバージョン等の把握については、「（解説）基本対策事項5.2.2(1)-3 b)・基本対策事項5.2.2(1)-5 b)「機種並びに利用しているソフトウェアの種類、名称及びバージョン、サポート体制等」について」及び「（解説）基本対策事項5.2.2(1)-3 c)「ソフトウェアを動作させるために用いられる他のソフトウェア」について」を参照のこと。

例えば、外部から入手した脆弱性情報が世の中で大きな被害をもたらしているような緊急性の高い場合には、情報システムにおける該当する脆弱性の有無の確認を運用保守業者に作業を委託するのみでなく、情報システムセキュリティ責任者自らも情報セキュリティ関連文書を参照し確認することが望まれる。

ソフトウェアに関する脆弱性対策では、セキュリティパッチ、バージョンアップソフトウェア等の脆弱性を解決するために利用される対策用ファイルが提供され次第、情報システムを構成する機器等に速やかに対策用ファイルを適用することが重要である。

一方で、情報システムの運用という観点では、情報システムの安定稼働を重視する場合、対策用ファイルを適用した場合の影響有無の調査・検証が必要であり、対策用ファイルの適用までの期間が長期化するだけでなく、対策用ファイルがほとんど適用されないといった状況が発生してしまうことは珍しくない。

しかしながら、不正アクセス、ランサムウェア等のサイバー攻撃において、ソフトウェアに関する脆弱性を悪用する手法は一般的であり、対策用ファイルの未適用は重大な情報セキュリティインシデントを引き起こす要因となっている。高性能AIの悪用などのサイバー攻撃の高度化、自動化等を踏まえると、セキュリティパッチの速やかな適用は非常に重要である。

そのため、情報システムの新規構築、更改時において、サーバ装置、端末、通信回線装置等の情報システムを構成する機器等へのセキュリティパッチ等の対策用ファイルの適時の適用を前提とした運用設計（パッチマネジメント（管理））を行う必要がある。また、サイバー攻撃の高度化、自動化等の状況を踏まえ、必要に応じて運用設計を見直し、脆弱性対策の強化を図る必要がある。

セキュリティパッチ等の対策用ファイルの適用を前提とした運用設計を行うためには、設計段階において以下を例とする内容を検討し、定めることが重要である。

特に「セキュリティパッチ等の対策用ファイルの適用基準」は、製品、セグメント、脆弱性の深刻度等のセキュリティリスクを踏まえた判断基準を事前に定めておくことで、セキュリティリスクが高い場合にセキュリティパッチ等の対策用ファイルの適用を速やかに実施できる運用を構築し、即時適用してセキュリティ対策を優先する場合と影響調査・検証を必要とする安定稼働を優先する場合を明確にすることができる。

また、脆弱性の深刻度については、共通脆弱性評価システム「CVSS」やMicrosoft社の「深刻度評価システム（Security Update Severity Rating System）」などを活用することが考えられる。

定期的な脆弱性診断を実施する頻度については、少なくとも１年に１回程度以上とし、さらに機能追加などの変更が行われた時に実施することが望ましい。

例えば、NAS（Network Attached Storage）において、認証情報を不正に入手される可能性がある脆弱性が公表された際には情報漏えい等のリスクが高まることが考えられる。

IT資産管理ソフトウェアにはOSやその他アプリケーションのセキュリティパッチを管理する機能を持つものがあり、サーバ装置及び端末に導入されたソフトウェアの種類やバージョンの管理と併せて統合的に管理を行うことができる。

ソフトウェアにおいて脆弱性が顕在化した際に、ソフトウェアベンダが対応するまでの間は、当該ソフトウェアの利用を禁止する、当該ソフトウェアベンダが公開した緩和策を実施する、脆弱性が関係する機能を無効化する、ファイアウォール、WAF等により当該ソフトウェアへの通信を制限するなどの対応が必要となる。

しかし、これらの対応によって業務に著しく悪影響を与えることが想定される場合は、事前に必要な措置を講じておくことが求められる。例えば、ブラウザは業務上利用せざるを得ないケースが多いが、異なるソフトウェアベンダが提供する複数のブラウザを、端末に事前に導入することで、業務継続性を維持しつつ、脆弱性を悪用した攻撃を受けるリスクを低減することができる。複数のブラウザを導入することは、情報システムのコスト増加を招く可能性があるが、一方のブラウザを常時利用するとともに、他方を緊急時のインターネットへのアクセス手段として利用するなど、用途を分ける方法も考えられる。また、ログ出力の設定を確認し、対応が完了するまでの期間、出力されたログの監視を強化するなどの対応も考えられる。

「対策試験」とは、脆弱性対策の実施による情報システムへの影響の有無を確認するために、事前に試験用の情報システムを用いて試験することが想定される。

入手した対策用ファイルに悪意のあるコードが含まれている可能性を考慮し、対策用ファイルは信頼できる方法で入手する必要がある。

信頼できる方法としては、OSやソフトウェアの開発元が提供するパッケージ管理システムや自動アップデート機能のほか、ソフトウェアの開発元等が公開するウェブサイトからダウンロードする方法が挙げられる。また、入手した対策用ファイルが改ざんされていないこと等の完全性の検証を開発元等が公開したハッシュ値と入手した対策ファイルのハッシュ値を比較する等により行う必要がある（検証が自動的に行われるものを含む。）。

7.2.2 不正プログラム対策

目的・趣旨

情報システムが不正プログラムに感染した場合、情報システムが破壊される脅威や、当該情報システムに保存される重要な情報が外部に漏えいする脅威が想定される。さらには、不正プログラムに感染した情報システムは、他の情報システムに感染を拡大させる、迷惑メールの送信やサービス不能攻撃等の踏み台として利用される、標的型攻撃における拠点として利用されるなどが考えられ、当該情報システム以外にも被害を及ぼすおそれがある。このような事態を未然に防止するため、不正プログラムへの対策を適切に実施することが必要である。

遵守事項

(1) 不正プログラム対策の実施

(a) 情報システムセキュリティ責任者は、サーバ装置及び端末に**不正プログラム対策ソフトウェア等を導入する**こと。

(b) 情報システムセキュリティ責任者は、想定される不正プログラムの感染経路の全てにおいて、不正プログラム対策ソフトウェア等により対策を講ずること。

(c) 情報システムセキュリティ責任者は、不正プログラム対策の状況を適宜把握し、必要な対処を行うこと。

【 基本対策事項 】

＜7.2.2(1)(a)関連＞

7.2.2(1)-1 情報システムセキュリティ責任者は、不正プログラム対策ソフトウェア等の導入に当たり、**既知及び未知の不正プログラムの検知及びその実行の防止の機能を有する**ソフトウェアを導入すること。

7.2.2(1)-2 情報システムセキュリティ責任者は、不正プログラム対策ソフトウェア等が常に最新の状態となるように構成すること。

7.2.2(1)-3 情報システムセキュリティ責任者は、不正プログラム対策ソフトウェア等に定義ファイルを用いる場合、その**定義ファイルが常に最新の状態となるように構成する**こと。

7.2.2(1)-4 情報システムセキュリティ責任者は、不正プログラム対策ソフトウェア等の設定変更権限については、システム管理者が一括管理し、システム利用者に当該権限を付与しないこと。

7.2.2(1)-5 情報システムセキュリティ責任者は、不正プログラム対策ソフトウェア等を定期的に全てのファイルを対象とした検査を実施するように構成すること。

＜7.2.2(1)(b)関連＞

7.2.2(1)-6 情報システムセキュリティ責任者は、想定される全ての**感染経路を特定し、不正プログラム対策ソフトウェア等の導入による感染の防止、端末の接続制限及び機能の無効化等による感染拡大の防止**等の必要な対策を行うこと。

7.2.2(1)-7 **【追加セキュリティ対策】情報システムセキュリティ責任者は、EDRソフトウェア**等を利用し、端末やサーバ装置（エンドポイント）の活動を監視し、感染したおそれのある装置を早期にネットワークから切り離す機能の導入を検討すること。

＜7.2.2(1)(c)関連＞

7.2.2(1)-8 情報システムセキュリティ責任者は、不正プログラム対策の実施を徹底するため、以下を例とする不正プログラム対策に関する状況を把握し、必要な対処を行うこと。

a) 不正プログラム対策ソフトウェア等の導入状況

b) 不正プログラム対策ソフトウェア等の定義ファイルの更新状況

（解説）

メインフレームシステムや一部のスマートフォンなど、不正プログラム対策ソフトウェアが有効な役割を果たさないと考えられているOSにおいて、不正プログラム対策ソフトウェアが提供されていないことがあるが、そのような場合は、取り扱う情報の格付や情報システムの特性に応じ、不正プログラム対策ソフトウェアをインストールせずに利用できる不正プログラム対策の技術や運用を検討するとよい。

既知の不正プログラムについては、不正プログラム対策ソフトウェアベンダにより、その不正プログラムに関するシグネチャが対策ソフトの定義ファイルに反映されることにより感染を防止することができる。一方で、標的型攻撃等の攻撃手法においては、不正プログラムのソースコードを部分的に改変する亜種や、ソフトウェアの新たな脆弱性を突く不正プログラムなど、不正プログラム対策ソフトウェア等の検知を回避しようとする攻撃が多く見られる。

このような未知の不正プログラムの検知及び感染防止への対応として、ソフトウェアの脆弱性への適切な対策に加えて、シグネチャにより検知する方式以外の手法を用いる製品やサービスを導入することの重要性も高まっている。例えば、必要に応じ以下の検知方式を複数組み合わせて多重防御を行うことにより、攻撃にスクリプト等を使用するファイルレスマルウェア対策としても効果が期待できるなど、不正プログラムの検知精度を向上させることで、端末及びサーバ装置に対する不正プログラム感染リスクの低減を図ることも可能となる。

なお、不正プログラム対策ソフトウェア等の選定に当たっては、ソフトウェアの稼働によって端末及びサーバ装置への負荷が増加し、業務に影響を与えるおそれがあること等も勘案した上で判断する必要がある。

インターネットに接続されていないサーバ装置や端末の定義ファイルを最新の状態にするため、一時的にインターネット接続が必要となる場合は、当該サーバ装置及び端末を定義ファイルの更新時にインターネットに接続することのリスクや取り扱う情報の格付等を勘案して、定義ファイルの更新の頻度や方法を検討する必要がある。

不正プログラムの感染経路には、電子メール、ウェブ等のネットワーク経由のほか、不正プログラムに感染したモバイル端末の機関等支給回線への直接接続や外部電磁的記録媒体の経由及びソフトウェアサプライチェーン攻撃も考えられる。

不正プログラム対策ソフトウェア等は、製品ごとに検知方式や不正プログラム定義ファイルの提供時期及び種類が異なる。また、不正プログラム対策ソフトウェア等は現存する全ての不正プログラムを検知及び除去できるとは限らないほか、不具合により不正プログラムの検知又は除去に失敗する危険性もある。このことから、不正プログラムによる被害を低減させるため、感染経路において、異なる定義ファイルを用いる不正プログラム対策製品を組み合わせる、又は定義ファイルパターンマッチングやふるまい検知等の異なる技術を用いる製品を組み合わせることにより、どれか一つの不具合で、その環境の全てが不正プログラムの被害を受けることのないようにすることが望ましい。例えば、電子メールサーバに導入する不正プログラム対策と端末に導入する不正プログラム対策について、それぞれ異なる検知技術を用いる製品を導入すること等が考えられる。

ネットワークを経由した感染拡大の防止策としては、以下の例が挙げられる。

不正プログラム対策ソフトウェア等のEPPのような不正プログラムへの感染防止に特化した製品とは異なり、端末やサーバ装置（エンドポイント）の活動を監視し、不正プログラム等の検知や対処を行うなど、不正プログラム等に感染した後の対処に有効であるEDRソフトウェア等を利用し、複数台にわたって統合的に監視を行うことで、感染した装置を早期にネットワークから切り離す仕組みを導入することができる。ただし、一般的にEDRソフトウェアは導入後の運用・保守段階において、専門的な知識を持った人材による膨大なログの分析が必要になることから、マネージドセキュリティサービス（Managed Security Service：MSS）と呼ばれる、ログ分析等を行うSOC業務を委託できるサービスの利用なども検討するとよい。

7.2.3 サービス不能攻撃対策

目的・趣旨

インターネットからアクセスを受ける情報システムに対する脅威としては、第三者からサービス不能攻撃を受け、利用者がサービスを利用できなくなることが想定される。このため、機関等の情報システムのうち、インターネットからアクセスを受けるものについては、サービス不能攻撃を想定し、システムの可用性を維持するための対策を実施する必要がある。近年ではインターネットに接続されたいわゆるIoT機器で構成されたボットネットによる大規模な攻撃や、専門的な技術や設備がなくても攻撃を行うことのできるDDoS代行サービスの存在も知られており、より一層の警戒が必要となっている。

遵守事項

(1) サービス不能攻撃対策の実施

(a) 情報システムセキュリティ責任者は、要安定情報を取り扱う情報システム（インターネットからアクセスを受ける情報システムに限る。以下本条において同じ。）については、サービス提供に必要なサーバ装置、端末及び通信回線装置が装備している機能又は民間事業者等が提供する手段を用いてサービス不能攻撃への対策を行うこと。

(b) 情報システムセキュリティ責任者は、**要安定情報を取り扱う情報システム**については、サービス不能攻撃を受けた場合の影響を最小とする手段を備えた情報システムを構築すること。

(c) 情報システムセキュリティ責任者は、**要安定情報を取り扱う情報システム**については、サービス不能攻撃を受けるサーバ装置、端末、通信回線装置又は通信回線から監視対象を特定し、監視すること。

【 基本対策事項 】

＜7.2.3(1)(a)関連＞

7.2.3(1)-1 情報システムセキュリティ責任者は、サーバ装置、端末及び通信回線装置について、**サービス不能攻撃に対抗するための以下の機能**を設けている場合は、これらを有効にしてサービス不能攻撃に対処すること。

a) パケットフィルタリング機能

b) 3-way handshake時のタイムアウトの短縮

c) 各種Flood攻撃への防御

d) アプリケーションゲートウェイ機能

7.2.3(1)-2 情報システムセキュリティ責任者は、以下を例とするサービス不能攻撃への対策を実施すること。

**【基本セキュリティ対策】**以下を例とする対策を実施すること。

a) サービス不能攻撃の影響を排除又は低減するための専用の**対策装置**やサービスの導入

b) サーバ装置、端末及び通信回線装置及び通信回線の**冗長化**

**【追加セキュリティ対策】**基本セキュリティ対策に加え、以下を例とする対策を検討すること。

c) **インターネットに接続している通信回線の提供元となる事業者やクラウドサービス提供者が別途提供する、サービス不能攻撃に係る通信の遮断等**の対策

d) **コンテンツデリバリーネットワーク（CDN）サービス**の利用

＜7.2.3(1)(b)関連＞

7.2.3(1)-3 情報システムセキュリティ責任者は、サービス不能攻撃を受けた場合を想定し、直ちに情報システムを外部ネットワークから遮断する、又は通信回線の通信量を制限するなどの手段を有する情報システムを構築すること。

7.2.3(1)-4 情報システムセキュリティ責任者は、サービス不能攻撃を受け、サーバ装置、通信回線装置又は通信回線が過負荷状態に陥り利用できない場合を想定し、**攻撃への対処を効率的に実施できる手段**の確保について検討すること。

＜7.2.3(1)(c)関連＞

7.2.3(1)-5 情報システムセキュリティ責任者は、特定した監視対象について、**監視方針及び監視方法**を定めること。

7.2.3(1)-6 情報システムセキュリティ責任者は、**監視対象の監視記録の保存期間を定め、監視記録を保存**すること。

7.2.3(1)-7 情報システムセキュリティ責任者は、監視対象の平常時の負荷の状況を把握し、監視においてこれを著しく逸脱したと判断する目安を定めること。

7.2.3(1)-8 情報システムセキュリティ責任者は、監視において、前項で定めた目安を超える負荷の状況が確認された場合は、サービス不能攻撃の可能性が排除される場合を除き、速やかに遵守事項2.2.4(1)(a)で定める報告手順に基づきCSIRTに報告すること。

7.2.3(1)-9 **【追加セキュリティ対策】情報システムセキュリティ責任者は、脅威動向等の脅威情報を収集**し、サービス不能攻撃を受ける可能性が予見される場合は、必要に応じて、CSIRT等の関係者に通知すること。

（解説）

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

パケットフィルタリング機能は、通信パケットのヘッダ部に含まれる情報（送信元及び送信先のIPアドレス、ポート番号、通信プロトコル等）を条件として、パケットの許可/遮断を行う機能である。これにより、攻撃に利用されているIPアドレスが明らかになっている場合、攻撃を遮断することが可能である。

3-way handshake時のタイムアウトの短縮は、TCP通信時に用いられる3-way handshakeの一連の通信（通信の可否確認、通信の可否応答、通信セッションの確立）の上限時間を短縮することにより、DDoS攻撃によって大量の通信セッションが同時に確立されサーバ等のCPUやメモリ等のリソースがひっ迫することを防止する方法である。

各種Flood攻撃への防御は、3-way handshakeの仕組みを悪用したSYN FloodやACK Flood、DNS通信において問い合わせパケットに比べて応答パケットのサイズが大きくなることを悪用したDNS Flood等に対する防御である。具体的な方法として、帯域制限機能により特定のIPアドレスからの一定時間内の通信数の上限を設定する、アラート機能によりサーバ等のCPUやメモリ等のリソースひっ迫を検知し攻撃を遮断する・一時的にリソースを増強する等があげられる。

アプリケーションゲートウェイ機能は、パケットフィルタリング機能で用いるヘッダ部の情報のみならず、通信の本体部（ペイロード部）を条件として、パケットの許可/遮断を行う機能である。

WAF、IDS/IPS、UTM（Unified Threat Management）、DDoS攻撃対策専用アプライアンス製品等が考えられる。

冗長化の例としては、サービス不能攻撃が発生した場合に備え、サービスを提供するサーバ装置、端末、通信回線装置又は通信回線について、負荷を分散させる、又はそれぞれ代替のものに切り替えるなどにより、サービスを継続することができるように情報システムを構成することが考えられる。

なお、代替のものへの切替えについては、サービス不能攻撃の検知及び代替サーバ装置等への切替えが許容される時間内に行えるようにする必要がある。

情報システムに対してサーバ装置、端末及び通信回線装置に係るサービス不能攻撃の対策を実施しても、機関等外へ接続する通信回線及び通信回線装置への過負荷の影響を完全に排除することは不可能である。このため、インターネットに接続している通信回線の提供元となる事業者やクラウドサービス提供者に確認した上で、サービス不能攻撃発生時の対処手順や連絡体制を整備する必要がある。

DDoS攻撃はボットからの攻撃によって実施されることが多いため、ボットに感染している端末等が多い国やドメインからの通信を拒否することによってもDDoS攻撃の影響を緩和することが可能であり、特に国内のみからアクセスを受ける情報システムであれば有効であるため、正規の通信への影響も考慮しつつ実施を検討してもよい。また、同一のIPアドレスからのしきい値を超えた大量のリクエストを遮断する機能がオプションとして提供されている場合は、その利用について検討するとよい。

DDoS攻撃によるパケットが大量に送り込まれインターネット接続回線の帯域が消費されると、正当なユーザもWebサイトにアクセスできなくなる状況が発生する。コンテンツデリバリーネットワーク（Contents Delivery Network）は、世界中に配置されたキャッシュサーバを利用してWebサイトのコンテンツを配信するというサービスであり、元来はWebサイトのレスポンス向上を目的としたサービスであるが、DDoS攻撃で大量にアクセスがあった場合も、接続先がキャッシュサーバに分散されるため、攻撃の影響を軽減する効果が期待できる。また、CDN機能がオプションとして提供されているクラウドサービスやクラウド型WAFサービスに本機能が含まれている場合もあることから、それらの利用についても検討するとよい。なお、コンテンツデリバリーネットワーク（CDN）サービスを利用する場合は、元の配信コンテンツを格納しているオリジンサーバへ直接アクセスされることを防ぐため、オリジンサーバのIPアドレスを隠蔽する必要がある。

対処例としては、サービス提供に利用している通信回線がサービス不能攻撃により過負荷状態に陥った場合においても、サービス不能攻撃を受けているサーバ装置、通信回線装置及びそれらを保護するための装置を操作できる手段を確保することが挙げられる。具体的には、管理者が当該装置を操作するためのサーバ装置、端末及び通信回線を、サービス提供に利用しているものとは別に用意することが挙げられる。

また、サービス不能攻撃に伴い、機関等の自己管理ウェブサイトの閲覧障害が発生した場合においても、緊急性・重要度が高い情報が長時間閲覧できなくなることは極力回避すべきである。これに鑑み、災害情報等の緊急性が高く、国民の生命や財産に著しく影響を及ぼし得るような重要情報については、広報担当とも協力するなどして、サービス不能攻撃を受けた際にも発信を可能とするよう、閲覧障害時の告知ページに最低限のテキストデータを掲載するなどの必要な措置を考慮するとよい。

インターネットからアクセスされるサーバ装置や、そのアクセスに利用される通信回線装置及び通信回線の中から、特に高い可用性が求められるものを優先的に監視する必要がある。

「監視方針」については、監視対象の特性を踏まえて、監視する時間を定め、監視により認知した異常の程度の段階に応じた対応の優先度や情報共有範囲、対応時間帯（24時間365日対応、平日の日中のみ対応等） 等を定めることが考えられる。

「監視方法」については、サービス不能攻撃を受けることに関する監視には、稼動中か否かの状態把握や、システムの構成要素に対する負荷の定量的な把握（CPU使用率、プロセス数、ディスクI/O量、ネットワークトラフィック量等）がある。監視方法は多種多様であるため、当該情報システムの構成等の特性に応じて適切な方法を選択する必要がある。

サーバ装置、端末、通信回線装置及び通信回線を監視している場合、監視対象の状態は一定ではなく変動することが一般的である。そのため、時間変動、曜日変動、週変動、月変動、季節変動等を監視対象の変動を把握するという目的に照らした上で記録の保存期間を定め、一定期間保存する。

サービス不能攻撃の可能性が排除される場合として、情報システムのメンテナンスのために一時的に一部機能等を制限した場合や、一時的にアクセスが集中することが考えられるコンテンツをウェブサイトに掲載した場合などが考えられる。

脅威動向等の脅威情報の収集については、内閣官房国家サイバー統括室等からの注意喚起等のほか、セキュリティベンダが提供している脅威情報の提供サービスを活用することも考えられる。

7.2.4 標的型攻撃対策

目的・趣旨

標的型攻撃とは、特定の組織に狙いを絞り、その組織の業務習慣等内部情報について事前に入念な調査を行った上で、様々な攻撃手法を組み合わせ、その組織に最適化した方法を用いて、執拗に行われる攻撃である。典型的なものとしては、組織の情報システム内に何らかの手法で不正侵入・潜入し、権限の奪取等を通じて侵入範囲を拡大、重要な情報を窃取又は破壊する攻撃活動が考えられる。これら一連の攻撃活動は、未知の手段も用いて実行されることもあり、完全に検知及び防御することは困難との前提に立った対策が必要である。

標的型攻撃への対策としては、情報システム内部への侵入を低減する対策（入口対策）に加え、内部に侵入した攻撃を早期検知して対処する、侵入範囲の拡大の困難度を上げる（内部対策）、及び外部との不正通信を検知して対処する対策（出口対策）からなる、多重防御の情報セキュリティ対策体系によって、標的型攻撃に備える必要がある。

なお、近年は、組織に対する直接的な攻撃だけでなく、委託先等の関連組織への間接的な攻撃も確認されており、より幅広い対策の検討が求められる。

遵守事項

(1) 標的型攻撃対策の実施

(a) 情報システムセキュリティ責任者は、情報システムにおいて、標的型攻撃による組織内部への侵入を低減する対策（入口対策）を講ずること。

(b) 情報システムセキュリティ責任者は、情報システムにおいて、内部に侵入した攻撃を早期検知して対処する、侵入範囲の拡大の困難度を上げる、及び外部との不正通信を検知して対処する対策（内部対策及び出口対策）を講ずること。

【 基本対策事項 】

＜7.2.4(1)(a)関連＞

7.2.4(1)-1 情報システムセキュリティ責任者は、サーバ装置及び端末について、組織内部への侵入を低減するため、以下を例とする対策を行うこと。

a) 不要なサービス機能やアプリケーションを削除又は停止すること。

b) **不審なプログラムが実行されないよう設定する**こと。

c) パーソナルファイアウォール等を用いて、サーバ装置及び端末に入力される通信及び出力される通信を必要最小限に制限すること。

d) サービスは原則「標準ユーザ」の権限で実行すること。

7.2.4(1)-2 情報システムセキュリティ責任者は、USBメモリ等の外部電磁的記録媒体を利用した、組織内部への侵入を低減するため、以下を例とする対策を行う。

a) 出所不明の外部電磁的記録媒体を組織内ネットワーク上の端末に接続させないこと。また、接続する外部電磁的記録媒体を事前に特定すること。

b) 外部電磁的記録媒体をサーバ装置及び端末に接続する際、不正プログラム対策ソフトウェアを用いて検査すること。

c) サーバ装置及び端末について、**自動再生（オートラン）機能や自動実行機能を無効化**すること。

d) サーバ装置及び端末について、使用を想定しない**USBポートを無効化**すること。

e) **組織内ネットワーク上の端末に対する外部電磁的記録媒体の接続を制御及び管理するための製品やサービス**を導入すること。

＜7.2.4(1)(b)関連＞

7.2.4(1)-3 情報システムセキュリティ責任者は、**情報窃取や破壊等の攻撃対象となる蓋然性が高いと想定される、認証サーバやファイルサーバ等の重要なサーバ**について、以下を全て含む対策を行うこと。

a) 重要サーバについては、組織内ネットワークを複数セグメントに区切った上で、重要サーバ類専用のセグメントに設置し、他のセグメントからのアクセスを必要最小限に限定すること。また、インターネットに接続する必要がある場合は、必要最小限のプロトコルやポートのみに限定し、インターネットに接続する必要がない場合はインターネット分離を行うこと。

b) 認証サーバについては、利用者端末から**管理者権限を狙う攻撃（辞書攻撃、ブルートフォース攻撃等）を受けることを想定した対策**を講ずること。

7.2.4(1)-4 情報システムセキュリティ責任者は、端末の管理者権限アカウントについて、以下を全て含む対策を行うこと。

a) 不要な管理者権限アカウントを削除すること。

b) 管理者権限アカウントのパスワードは、**容易に推測できないもの**に設定すること。

7.2.4(1)-5 **【追加セキュリティ対策】情報システムセキュリティ責任者は、以下を例とする内部対策及び出口対策**を行うこと。

a) プロキシサーバ等により、C&Cサーバ等への**不正な通信を監視し、遮断**すること。

b) 情報システムの管理者が利用する情報システム管理用の専用端末を用意し、他のセグメントと分離した運用管理セグメントを構築し、当該セグメントにシステム管理用の専用端末を接続すること。

c) 認証サーバに管理者権限でログインできる端末をシステム管理用の専用端末に制限すること。

d) 一般利用者が利用する**端末間でのファイル共有機能を停止**する又は一般利用者が利用する端末間の直接通信を遮断すること。

（解説）

第６部から第８部の各款における規定内容は、標的型攻撃への対策としても有効であるため、各款にそれぞれに示される対策を標的型攻撃への対策の観点からも行う必要がある。

標的型攻撃の手法として代表的なものは「標的型メール」であり、攻撃者は攻撃対象の組織や個人の情報を入念に調査し情報を収集した上で、攻撃対象が疑念を抱かないよう巧妙に偽装したメールにより攻撃を仕掛けてくる。情報システムセキュリティ責任者には、不審な電子メールへの対策として基本対策事項8.1.1(2)-2に例示された対策の導入が求められるが、これら攻撃メールを完全に検知及び防御することは困難であることから、システム的な抑止機能の導入だけでなく、不審な電子メールの添付ファイルを実行しない、記載されたURLリンクをクリックしないといった基本的な情報セキュリティ対策を職員等に意識づけるための教育や定期的な注意喚起を組織全体として実施することが重要である。

ただし、上記のような入口対策を講じても組織内部への侵入の可能性はなお残ることから、内部対策の実施及び職員等が被害を受けた可能性を認知した際の機関等内での連絡体制を日頃から周知することも重要である。

具体的な設定手段としては、あらかじめ利用するアプリケーションを登録してそれ以外のアプリケーションの実行を拒否するよう設定する、通常のアプリケーションでは利用しないメモリ空間を利用しようとしたアプリケーションを不審と判定して実行を拒否するソフトウェアを利用する、情報システムにおいて不正プログラムの起動又は動作を拒否する手法を導入するなどが挙げられる。

なお、これらを導入する場合には、業務で利用するアプリケーションに影響が及ぶ可能性があるため、事前に検証する必要がある。

標的型攻撃に用いられる手段として、自動再生（オートラン）機能を悪用するものがあり、例えば、不正プログラムを格納したUSBメモリを端末に接続させることにより、不正プログラムを実行させるという手法が想定される。

自動再生（オートラン）機能を無効にすることで、この機能を悪用する手段による被害に遭うリスクを低減することができる。

物理的に又はシステム的にUSBポートを利用できない状態にすることで、USBメモリ等の外部電磁的記録媒体を接続することによって生じる情報セキュリティインシデントの発生を抑止できる。

外部電磁的記録媒体のポートへの接続や利用を制御及び管理するため、以下のような機能を持つ製品やサービスが市場に提供されている。

悪意ある第三者等は、入口対策を突破して内部への侵入に成功すると、外部から遠隔指令を出して内部侵入の範囲を拡大しつつ、目的の達成を目指すと想定される。その目的としては、重要情報の窃取や破壊が想定され、したがって、識別コード及びアクセス権限を集中管理する認証サーバ、又は、情報が集中的に保存されるファイルサーバは、攻撃対象となる蓋然性が高いと考えられる。これら重要サーバには、特に注意して情報セキュリティ対策を講ずる必要がある。

管理者権限を狙う攻撃としては、機械的にパスワードを変えながら連続してログイン試行する攻撃が考えられる。このような攻撃を受けることを想定した対策としては、以下に挙げるものが考えられる。

「（解説）基本対策事項7.1.1(1)-4「強固なパスワードに必要な十分な桁数を備えた第三者に容易に推測できないパスフレーズ等を使用すること」について」を参照のこと。

内部対策は、内部に侵入してしまった攻撃を想定し、これを早期検知して対処するための対策や侵入範囲の拡大（ラテラルムーブメント：横方向の侵害）の困難度を上げるための対策などが考えられる。具体的には、基本対策事項7.2.4(1)-3及び4並びに7.2.4(1)-5 b)からd)の対策のほか、多要素主体認証方式の導入や基本対策事項7.1.3(1)-1の管理者権限に係る対策、基本対策事項7.2.2(1)-7のEDRソフトウェア等を利用した端末やサーバ装置（エンドポイント）の監視、基本対策事項6.4.1(2) -3の機関等内通信回線の機器等における不審な通信の監視などが考えられる。また、高い管理者権限アカウントに似せたトラップアカウントを端末等に設定しておき、当該トラップアカウントを用いた攻撃者のログイン行為等を検知する対策も有効であるが、認証失敗のログを収集し、これを監視できる体制とする必要がある。さらに、侵入範囲の拡大の手法の一つとして、ActiveDirectoryのようなディレクトリサービスが攻撃対象とされる事例も多く、当該サービスを提供するサーバ装置に対する脆弱性対策や上記の対策が特に重要であるほか、当該サービスの管理専用端末を用意するといった対策も検討するとよい。

出口対策として、基本対策事項7.2.4(1)-5 a)の対策のほか、基本対策事項6.4.1(2)-3の機関等外への不正な通信の監視などが考えられる。

本対策を有効とするため、プロキシサーバの導入に当たっては、ウェブブラウザのプロキシ設定を有効にし、ファイアウォールにおいて、内部（ユーザセグメント）から外部（インターネット）への通信の遮断ルール（ファイアウォールポリシー）を適切に設計・設定することにより、端末から直接インターネットへの通信（プロキシサーバを経由しない通信）ができないようにする必要がある。また、プロキシサーバにおけるアクセス制御リストを適切に設計・設定する必要がある。

プロキシサーバの認証機能を有効にした場合は、当該認証失敗ログ等を分析することにより、不正な通信を調査・発見できることがある。

なお、不正な通信の監視、遮断について、NDR製品を活用することも考えられる。

OSがWindowsである端末間でファイルやフォルダを共有するための機能である「ファイル共有機能」について、内部に侵入した悪意ある第三者等によって侵入範囲を拡大するために悪用されることを防ぐため、本機能を停止することが望ましい。なお、「管理共有機能」（C$、D$、ADMIN$等）も停止することが望ましい。

7.3 ゼロトラストアーキテクチャ

7.3.1 動的なアクセス制御の実装時の対策

目的・趣旨

従来、組織内ネットワーク上の情報資産の保護においては、インターネット等の機関等外通信回線と組織内ネットワークである機関等内通信回線との境界にファイアウォール等を設置し防御を行い、組織内のネットワークに一定の信頼を置く「境界モデル」の対策が一般的であった。クラウドサービスの普及や、テレワークによる業務システム環境の変化等により、組織内の情報資産を取り巻く脅威は変化しており、このような新たな環境における脅威に対して境界モデルによる防御だけでは十分なセキュリティ対策の実施は困難になりつつある。特に、境界内部に設置されたサーバ装置等の情報資産について、境界での対策を過信しており、内部に侵入された際の横断的侵害（横方向の侵害やラテラルムーブメントとも呼称される）への情報セキュリティ対策が不足している可能性がある。

ゼロトラストアーキテクチャは、組織内外を問わずネットワークは常に侵害されているものであるとの前提のもと、情報資産を保護し、情報セキュリティリスクの最小化を図るための情報セキュリティ対策における論理的・構造的な考え方である。また、ゼロトラストアーキテクチャは中長期的な政府情報システムに係るライフサイクル全体にわたって適用されるものであり、特定の実装やソリューションを指すものではない。

ゼロトラストアーキテクチャに基づく情報資産の保護策の１つとして、情報資産へのアクセスの要求ごとに、アクセスする主体や、アクセス元・アクセス先となる機器、ソフトウェア、サービス、ネットワークなどの状況を継続的に認証し、認可する仕組みが考えられる。本款では、このような仕組みを実現する機能の一部と考えられる「動的なアクセス制御」を実装する場合に特に必要な対策について記載する。

動的なアクセス制御の機能を実装する場合は、本款以外に7.1.1「主体認証機能」で定める主体認証機能の導入、7.1.2「アクセス制御機能」で定めるアクセス制御機能の導入、7.1.3「権限の管理」で定める権限の管理に係る遵守事項についても併せて遵守する必要があるが、既存の情報システムの構成に動的なアクセス制御を実装する場合は、既存の情報システムの構成やアクセス制御に用いるソフトウェアなどを見直していくことが重要となる。

遵守事項

(1) 動的なアクセス制御における責任者の設置

(a) 統括情報セキュリティ責任者は、複数の情報システム間で**動的なアクセス制御を実装する場合は、複数の情報システム間で横断的な対策の企画・推進・運用に関する事務の責任者**として、情報システムセキュリティ責任者を選任すること。

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

（解説）

本節における動的なアクセス制御とは、特定のアクセスに対して、セッションが確立していない操作ごとに、都度、アクセス元の信用情報を動的に評価し、アクセス先が信用できる状態であるかを検証したうえで、特定のリスクが検出された場合には追加の認証を求めることや、アクセスを拒否する等のアクセス制御を行うことを想定している。

機関等において動的なアクセス制御を実装する場合は、複数の情報システム間で動的なアクセス制御を実装する場合がある。その場合、複数の情報システムに対して横断的な対策を実施しなければならず、複数の情報システムセキュリティ責任者が連携して対応する必要がある。したがって、複数の情報システムセキュリティ責任者の中から複数の情報システム間の横断的な対策の企画・推進・運用に関する事務を統括する責任者として、情報システムセキュリティ責任者を選任することが有効である。

遵守事項

(2) 動的なアクセス制御の導入方針の検討

(a) 情報システムセキュリティ責任者は、動的なアクセス制御を導入する場合、動的アクセス制御の対象とする情報システムのリソースを識別し、動的なアクセス制御の導入方針を定めること。

【 基本対策事項 】

＜7.3.1(2)(a)関連＞

7.3.1(2)-1 情報システムセキュリティ責任者は、**動的なアクセス制御の対象とする情報システムの範囲や優先度を検討**し、動的なアクセス制御の対象とする情報システムを特定すること。

7.3.1(2)-2 情報システムセキュリティ責任者は、特定した情報システムの利用形態等を基に以下を例とする区分で**情報システムのリソースを識別する**こと。

a) ユーザアカウント

b) 機器

c) アプリケーション

d) データ

7.3.1(2)-3 情報システムセキュリティ責任者は、**識別したリソースを基にアクセスパターンを整理**すること。

7.3.1(2)-4 情報システムセキュリティ責任者は、整理した**アクセスパターンに対するリスク評価**を実施し、動的なアクセス制御を実装するアクセスパターンを特定すること。

（解説）

動的なアクセス制御の実装においては、組織内ネットワーク上に存在する全ての情報システムを対象とすることが望ましいが、全ての情報システムを対象とする場合、リソースの識別やアクセスパターンの特定、リスク評価の実施など多くの時間を要することが想定される。このため、動的なアクセス制御の対象とする情報システムの範囲や優先度を検討し、動的なアクセス制御の対象とする情報システムを特定することが重要である。

なお、動的なアクセス制御の対象とする情報システムについては、5.1節で定める高度な情報セキュリティ対策が求められる情報システムを判別するための分類に基づき検討することも考えられる。また、機関等LANシステムのような機関等内で共通的に利用される情報システムを優先的な動的なアクセス制御の対象とすることで、機関等全体の情報セキュリティ水準の向上を図ることが可能となる。

情報システムのリソースとは、情報システムを構成（当該情報システムを利用する機器等を含む。）する機器、アプリケーション、利用アカウント、データ等の情報資産を指す。情報システムにおけるリソースの識別については、情報システムの調達仕様書や設計書等における情報システムの構成図や利用形態等を参照しつつ、情報システムへアクセスする際に利用するリソースについて整理する必要がある。

また、情報システムの利用形態によっては、複数の情報システム間で連携するアプリケーションなどが存在する場合もある。そのような形態が存在する場合、それぞれの情報システムで連携するアプリケーションや、アプリケーションが利用する認証用アカウント、アクセストークン、証明書、証明書発行に用いる認証情報、アクセス対象のデータ等のリソースを識別する必要がある場合があることに留意が必要である。

表7.3.1-1は、リソースを識別するに当たり、ユーザアカウント、機器、アプリケーション、データを区分した例示である。このような区分を参考に、情報システムに対してどのようなものが存在するか整理する必要がある。

表7.3.1-1　リソースを識別する区分例
リソース 属性 リソース例
属性例 属性値の例
ユーザアカウント 所属 部局名、課室名、委託先名 機関等LANシステム内ディレクトリサービスのユーザアカウント、クラウド型メールサービスのログインアカウント、（特定の）システムユーザアカウント
役職 部局長、課室長、係長、主査、係員
権限種別 利用者、管理者、運用者
機器 機関等支給の有無 機関等支給、機関等支給以外 PC、タブレット端末、スマートフォン、サーバ装置、複合機、特定用途機器、通信回線装置
用途 事務用、運用・保守用、開発用
場所の使用制限等 要管理対策区域（庁舎や契約するデータセンター等）、要管理対策区域外（持ち出し先、自宅等）
ネットワーク所属情報 機関等LANシステム内端末、インターネット接続端末

リソース

属性

リソース例

属性例

属性値の例

クライアントアプリケーション

Webブラウザ、アプリケーション名

アプリケーション

種別

機関等LANシステム内情報システム上のアプリケーション、クラウドサービス

機関等LANシステム内ディレクトリサービス、クラウド型メールサービス

実行基盤

サーバ名、クラウドサービス（PaaS、IaaS）名

実行環境

本番環境、開発環境

データ

格付

機密性〇、完全性〇、可用性〇

特定プロジェクトの要機密情報、機関等WEBページ公開用コンテンツ

取扱制限

〇〇限り、〇〇禁止、〇〇要許可

操作の制限

管理者：フルコントロール可能

一般職員：参照のみ

動的なアクセス制御の実装に向けて、対象とする情報システムにおいて考えられるリソース及び当該リソースへのアクセスパターンを漏れなくリスト化する必要がある。ここで整理したアクセスパターンのリストは、動的なアクセス制御の制御対象の単位となり、組織内ネットワーク上の情報システムのリソースを保護するための基礎情報となるものである。なお、リソースやアクセスパターンは運用していく中で当初に想定していたものから変化していくため、変化に応じて見直しをする必要があることに注意が必要である。

アクセスパターンの整理に当たっては、情報システムの利用形態に基づき識別される各リソースに対して、どのようなアクセスが考えられるかといった点を考慮し検討する必要がある。その際、ある文脈でアクセス先であったリソースが、別の文脈ではアクセス元として、さらに別のリソースへアクセスを行う場合もあることに留意が必要である。例えば、あるユーザが、ある機器にログインし、当該機器を用いてアプリケーションAにアクセスを行い、アプリケーションAは、さらに別のアプリケーションBにアクセスを行う、という点を考慮する必要がある。

検討の中で、識別したリソースに不足があった場合は、新たなリソースとして識別する必要もある。識別した全てのリソースについて、このようなアクセスパターンを列挙することで、対象となる情報システム全体のアクセスパターンを整理することができる。

アクセスパターンを整理する具体例として、例えば機関等LANシステムのような機関等内で共通的に利用される情報システムにおいて、当該情報システムへアクセスする方法として、職員等が自組織のドメインユーザアカウントで端末にログインし、当該端末を用いて庁舎内の要管理対策区域内から機関等内通信回線を用いてファイルストレージシステムに保存された要機密情報にアクセスする場合や、職員等が端末を用いて、公衆回線経由で、クラウド型メールサービスに、クラウド用認証アカウントを用いてログインしアクセスする場合、等が想定される。このように、情報システムの利用形態からリソースに着目し、アクセスパターンを整理する。

アクセスパターンの整理についての例示として、表7.3.1-2に「職員が端末を用いてインターネット経由でクラウド型電子メールサービスへのアクセスする」パターンと「職員がVPN経由で機関等LANシステム上のファイルストレージシステム上のデータにアクセスする」パターンを示す。アクセスパターンを整理する場合は、それ以外にも考えられる各リソースの組み合わせを用いて整理することが求められる。

表7.3.1-2　アクセスパターンの特定例
アクセスパターン リソースアクセス アクセス元 アクセス先
項番 項目
A 職員が端末を用いてインターネット経由でクラウド型電子メールサービスへのアクセスする。 1 OSログインアカウントの認証 職員 クラウドディレクトリサービス上のユーザオブジェクト
2 クラウド型メールサービスの認証 職員 クラウド型メールサービスのIDプロバイダ
3 端末からクラウド型メールサービスへのアクセス 端末 クラウド型メールサービス
B 職員がVPN経由で機関等LANシステム上のファイルストレージシステム上のデータにアクセスする。 1 OSログインアカウントの認証 職員 ディレクトリサービス上のユーザオブジェクト（キャッシュされたログオン情報）
2 端末からVPN装置へのアクセス 端末 VPN装置
アクセスパターン リソースアクセス アクセス元 アクセス先
項番 項目
3 端末からファイルストレージシステムへのアクセス 端末 ファイルストレージシステム

アクセスパターンに対するリスク評価については、整理した全てのアクセスパターンに対して想定される脅威に基づき、脅威事象が発生する可能性及び脅威事象が負の影響をもたらす可能性を推定することによって行う。想定される脅威は、係わるリソースの持つ属性や状態に依存して発生するものもあることに留意が必要である。

例えば、職員等が端末のWEBブラウザを用いてインターネット経由で機関等が契約するクラウドサービス上の要機密情報を参照するようなアクセスパターンを想定した場合、攻撃者が当該職員の認証情報を不正利用し当該サービスにアクセスするリスクが高いと評価することが考えられる。この場合、インターネット経由でのアクセスか、機関等LANシステム経由でのアクセスか、といった情報は、職員が使用する機器をリソースとして捉えた場合に、当該機器リソースの「所属ネットワーク情報」という属性の値の違いから判別される。

動的なアクセス制御を実装するアクセスパターンの優先度や範囲については、リスク評価の結果を踏まえ、当該リスクを低減するための費用対効果の観点などから決定することが考えられる。

なお、具体的なリスク評価の手法や考え方については「（解説）遵守事項2.1.3(1)(a)「リスクを評価する」について」を参照のこと。

遵守事項

(3) 動的なアクセス制御の実装時の対策

(a) 情報システムセキュリティ責任者は、動的なアクセス制御の実装に当たり、**リソースの信用情報**の変化に応じて動的にアクセス制御を行うためのアクセス制御ポリシー（以下「アクセス制御ポリシー」という。）を作成すること。

(b) 情報システムセキュリティ責任者は、アクセス制御ポリシーに基づき、動的なアクセス制御を行うこと。

【 基本対策事項 】

＜7.3.1(3)(a)関連＞

7.3.1(3)-1 情報システムセキュリティ責任者は、**動的なアクセス制御を実現するための構成**について検討すること。

7.3.1(3)-2 情報システムセキュリティ責任者は、動的なアクセス制御の実装に当たり、動的なアクセス制御に活用する以下を例とする**リソースの信用情報を整理**すること。

a) ユーザアカウント

b) 機器

c) アプリケーション

d) データ

7.3.1(3)-3 情報システムセキュリティ責任者は、**リソースの信用情報の変化に応じてアクセス制御ポリシーを作成する**こと。

＜7.3.1(3)(b)関連＞

7.3.1(3)-4 情報システムセキュリティ責任者は、リソースの信用情報の変化を踏まえて、リソースの**信用情報を収集する頻度・機会**について定めること。

7.3.1(3)-5 情報システムセキュリティ責任者は、リソースの認証・認可において、アクセス制御ポリシーに基づき、セッションが確立してない操作ごとにアクセス制御を行うこと。

（解説）

リソースの信用情報とは、リソースから収集する情報のことで、リソースの性質や特性に係わる属性情報（例：ユーザアカウントの権限種別、機器の所属ネットワーク情報）や状態情報（例：ユーザアカウントの識別コードや主体認証情報の漏えい状況、機器のセキュリティパッチ適用状況等）のことを指し、当該リソースをアクセス元、アクセス先とするアクセス制御において、アクセス可否の判断等に使用するものである。

動的なアクセス制御を実現するためには、新しい情報システムの導入や既存の情報システムの改修も踏まえ、対象とする情報システム上のリソースの信用情報を収集可能とし、当該信用情報を活用することでリソースへのアクセス制御を行うことを可能とするようなシステム構成を検討する必要がある。具体的な構成を検討するに当たっては、リソースから情報を収集するための製品やソリューション、それらを用いてアクセス制御を行うための製品やソリューションを検討し、それぞれの製品やソリューションが連携可能であるか確認することが重要である。

表7.3.1-3は、リソースへの情報セキュリティ対策機能や当該対策が有効に機能し、リソースが信頼できるものであるかを検討する機能を有するソリューションの一部を示すが、他の製品やソリューション等も有効であるため検討するとよい。また、これらの製品やソリューションの活用については、想定されるリスクや費用対効果等を踏まえ検討することが望ましい。

表7.3.1-3　有効な機能や当該機能を有するソリューションの例

リソース

有効な機能の例

ソリューションの例

ユーザアカウント

識別コード・主体認証
情報の保護機能

IDaaS （Identity as a Service）、

IGA （Identity Governance & Administration）

機器

機器（エンドポイント）の脅威からの保護機能

EPP 、EDR、MDM、MAM（Mobile Application Management）

ZTNA（Zero Trust Network Access）、SWG（Secure Web Gateway）、CASB

ユーザアカウント、機器、アプリケーション、データに係るリソースの信用情報としては、表7.3.1-4に掲げるようなものが挙げられる。動的なアクセス制御に活用する信用情報については、リスク評価の結果、リスクが高いと評価したアクセスパターンにおいて、そのリスクを低減させるためにどのリソースのどのような信用情報を活用すればアクセスの安全性が高められるかを整理することで求められる。

例えば、リスク評価の結果、不正な主体認証のリスクが高いと考えられるアクセスパターンにおいて、アクセス元の機器がリスクの懸念されるリソースとなる場合、当該機器が信用できるものであるかを判断するためには、表7.3.1-4で掲げるような端末における標準設定がなされていることや、不正プログラムの検知状況等の情報が必要であるとし、これらを動的なアクセス制御に活用する信用情報として整理することが考えられる。

表7.3.1-4　リソースの信用情報の例

リソース

信用情報の例

ユーザ

アカウント

属性（所属する部局や役職等）

主体認証情報の漏えい有無（脅威インテリジェンスとの突合結果）

多要素主体認証の実施有無

アクセスの時間帯

リソース

信用情報の例

主体認証の失敗回数

機器

利用しているアプリケーションやOSの種類及びバージョン

セキュリティパッチの適用状況

端末における標準設定がされているか（クライアント証明書導入有無、ディレクトリ管理機能で管理される機関等ドメインへの参加有無、不正プログラム対策ソフトウェアの導入有無等）

不正プログラムの検知状況

機器が接続しているネットワーク種別（機関等LANシステム、インターネット等）

IPアドレス

地理情報

アプリケーション

アプリケーションのセキュリティ状態

アプリケーション実行環境（サーバ基盤等）のセキュリティ状態

アプリケーションの第三者機関による安全性評価（CASBにおける安全性評価等）

機関等におけるアプリケーションの利用許可状況

データ

情報の格付及び取扱制限

情報の形式（実行プログラム形式、文書形式、圧縮形式等）

情報の量

また、このようなリソースの信用情報を蓄積する情報基盤として、IDとアクセスの管理（Identity and Access Management：IAM）と呼ばれる仕組みや、資産管理を行う仕組みを導入することについて検討するとよい。

動的なアクセス制御の実装に当たっては、リソースの信用情報は時間の経過に伴い刻々と変化する。そのため、リソースの信用情報を用いたアクセスの検証は、初回のアクセス要求時だけでなく、セッションが確立してない操作ごとに都度検証することが必要となる。

このようなリソースの信用情報の変化については、例えば、端末で利用しているOSやアプリケーションの脆弱性が見つかった場合や機関等内通信回線からのアクセスではなく機関等外通信回線を利用してアクセスするなど、時間の経過に伴いリソースの属性や状態が変化し、リスクが発生する可能性が変化した状態のことをいう。

なお、このようなリソースの信用情報の変化に伴うリスクを相関的に検出する機能を有するソリューションとして、SIEMやUEBA等があり、これらのソリューションに連携可能な情報を組み合わせることで、リソースの信用状況の変化を動的なアクセス制御に活用する可能性についても必要に応じて検討するとよい。

表7.3.1-5　リソースの信用情報の変化例

リソース区分変化前変化後
ユーザアカウント主体認証情報の漏えいや、管理されていない識別コードなし主体認証情報が漏えい、異動に伴う不要な識別コードあり
機器最新バージョンのOSやアプリケーション利用脆弱なバージョンのOSやアプリケーション利用
アプリケーション安全性が確認されたアプリケーション問題点が発見されたアプリケーション

アクセス制御ポリシーとは、動的なアクセス制御を行うに当たり、アクセス先のリソースに対してアクセス元のリソースに許容されるアクセスや処理を、アクセス元の権限等の情報に基づいて規定するルールである。アクセス制御ポリシーの作成に当たっては、リソースの信用情報や、基本対策事項7.3.1(2)-3、基本対策事項7.3.1(2)-4で検討したアクセスパターンとそのリスク評価結果、機関等が定めた情報セキュリティ関係規程、アクセス制御ポリシーに基づき連携する製品やサービス等を踏まえて作成することが望ましい。

アクセス制御ポリシーに基づくアクセス制御のイメージとしては、アクセス元、アクセス先のリソースの信用情報がベースラインとして定義した表7.3.1-6が考えられる。この表に掲げるような要件に全て準拠していれば、他の認証要素による確認を追加で要求せずリソースへのアクセスを許可するようなことが考えられる。さらに、アクセスする際の検証の結果が表7.3.1-7のようにベースラインに一部準拠していないものの、非準拠部分がアクセスとして認めている内容であれば他の認証要素による確認を追加で要求することや、表7.3.1-8のように非準拠部分がアクセスとして認めていない内容であればアクセスを拒否することが考えられる。また、アクセス制御ポリシーが流出した場合、悪意のある第三者等によって重要な情報へのアクセス権を持つアカウントを推測される可能性がある。そのため、第三者等への流出を防止する等、適切に管理する必要がある。

表7.3.1-6　ベースラインに全て準拠し多要素主体認証を不要とする例

リソース リソースの信用情報
アクセス元 ユーザアカウント 主体認証情報が漏えいしていない
主体認証の失敗回数が既定回数以内
機器 既知の脆弱性のないOSバージョン
端末の標準設定がされている
機関等LANシステムからのアクセス
アクセス先 アプリケーション 機関等において利用を許可したアプリケーション
データ 格付や取扱制限に準拠したアクセス

表7.3.1-7　インターネット経由のアクセスは認めているがベースラインを満たさないため多要素主体認証を追加で要求する例

リソース リソースの信用情報
アクセス元 ユーザアカウント 主体認証情報が漏えいしていない
主体認証の失敗回数が既定回数以内
機器 既知の脆弱性のないOSバージョン
端末の標準設定がされている
インターネットからのアクセス
アクセス先 アプリケーション 機関等において利用を許可したアプリケーション
データ 格付や取扱制限に準拠したアクセス

表7.3.1-8　インターネット経由かつ端末の標準設定がされていない端末からのアクセスは認めておらずアクセスを拒否する例

リソース ベースラインとする診断内容
アクセス元 ユーザアカウント 主体認証情報が漏えいしていない
主体認証の失敗回数が既定回数以内
機器 既知の脆弱性のないOSバージョン
端末の標準設定がされていない
インターネットからのアクセス
アクセス先 アプリケーション 機関等において利用を許可したアプリケーション
データ 格付や取扱制限に準拠したアクセス

動的なアクセス制御において活用するリソースの信用情報については、セッションが確立してない操作ごとに都度検証する際に利用される。したがって、リソースの信用情報を収集する頻度や機会を適切に定めることで、情報セキュリティ対策が有効に機能し、リソースが保護され信用できるものであるかを確認できるようにする必要がある。

リソースの信用情報を収集する頻度・機会については、可能な限りセッションが確立してない操作ごとに都度検証することが望ましいが、システムの負荷や、想定されるリスクの受容可能期間、是正措置実施後の最新の信用情報を収集する待ち時間等に鑑みて、業務効率に影響を与えないようにすることも検討する必要がある。

ただし、リソースの信用情報の収集頻度が著しく低い場合は、適切なリスクの判断ができなくなる可能性がある。例えば、機器に対する脆弱性対策として、セキュリティパッチが未適用と判明した機器からのアクセスを遮断するような動的なアクセス制御を行う場合、セキュリティパッチ適用状況を収集する頻度が低いと、セキュリティパッチが未適用と判明した機器からのアクセスを遮断するまでの間に、振る舞い検知やUEBAやSIEMなどによるリソースへのアクセス状況の特異性の評価など、他の施策による対応依存度が高まることについて、留意が必要である。

7.3.2 動的なアクセス制御の運用時の対策

目的・趣旨

テレワークの拡大やクラウド・バイ・デフォルト原則によって、リソースの利用形態は日々変化していることを踏まえ、動的なアクセス制御の運用時には、実装時に検討した対策内容が正しく機能しているかどうか確認し、必要に応じてアクセス制御ポリシーを見直すことが重要である。また、動的なアクセス制御の前提となるリソースの信用情報を収集する中でリスクが検出された場合は、当該リスクを低減するための措置が必要となる。

本款では、機関等が動的なアクセス制御を運用する場合に特に必要な対策についてのみ規定するため、本款以外に7.1.1「主体認証機能」で定める識別コード・主体認証情報の管理、7.1.2「アクセス制御機能」で定めるアクセス制御の適切な運用、7.1.3「権限の管理」で定める権限の管理に係る遵守事項についても併せて遵守する必要がある。

遵守事項

(1) 動的なアクセス制御の実装方針の見直し

(a) 情報システムセキュリティ責任者は、動的なアクセス制御の運用に際し、情報セキュリティに係る重大な変化等を踏まえ、アクセス制御ポリシーの見直しをすること。

【 基本対策事項 】

＜7.3.2(1)(a)関連＞

7.3.2(1)-1 情報システムセキュリティ責任者は、動的なアクセス制御の運用に際し、アクセスパターンやアクセス先のリソースの変化があった場合は、**変化が影響する箇所に対し再度リスク評価を行い、アクセス制御ポリシーの見直しをする**こと。

7.3.2(1)-2 情報システムセキュリティ責任者は、基本対策事項7.3.2(1)-1による見直しによりアクセス制御ポリシーを変更した場合、変更の履歴を記録し、点検を実施すること。

（解説）

アクセスパターンの変化として、例えばテレワークの拡大等を背景として、これまで機関等LANシステムからアクセスしていたオンプレミスの情報システムを、クラウドサービス上へ移行する等の変化が想定される。

アクセスパターンの変化の他にリソースの重要度及びリソースの追加、廃止、取り扱いレベル等の変化によって、これまで想定されなかった新たなリスクが想定される場合は、リスク評価の結果やアクセス制御ポリシーについて見直しが必要となる。

遵守事項

(2) リソースの信用情報に基づく動的なアクセス制御の運用時の対策

(a) 情報システムセキュリティ責任者は、動的なアクセス制御の運用に際し、**リソースの信用情報の収集により検出されたリスクへ対処**を行うこと。

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

（解説）

動的なアクセス制御の運用においては、リソースの信用情報の収集により、新たなリスクを検出する機会が増加することが想定される。これら検出したリスクに対し、動的なアクセス制御で許容する範囲に是正する目的で、日常的な対処を行うことが必要となる。

このような収集によって検出したリスクに対する対処は、管理者・利用者それぞれにおいて行われる必要がある。管理者として行う対処の具体例は、ユーザアカウントの主体認証情報の利用状況の特異点を確認する中で検出された、主体認証情報の漏えいが疑わしいユーザアカウントについて、セキュリティ担当者にエスカレーションし、追加の調査の実施を依頼するような対処が挙げられる。利用者として行う対処の具体例は、動的なアクセス制御によって抵触したセキュリティパッチ未適用や不適切なネットワークへの接続などの事柄に対する是正措置として、セキュリティパッチの適用作業や適切なネットワークへの再接続を実施するような対処が挙げられる。

また、こうしたリスクへの対処に際して、一時的に当該リソースを利用する職員等による情報システムへのアクセスが不可となる影響が想定されるため、事前に職員等への連絡手段や、職員等からの問い合わせ窓口を用意するとともに、利用者に対して動的なアクセス制御で抵触した事柄の是正措置を動的なアクセス制御を提供するシステムによって明示できるようにすることが望ましい。