- 1.ガバメントクラウド
- 2.ISMAP
- 3.GSS
- 4.NCO（旧NISC）
- 5.デジタル庁
- 6.サイバーセキュリティに関する法律
- 7.個人情報保護委員会への報告
- 8.自治体のセキュリティ
- 9.IPA
- 10.NICT
- 11 セキュリティの規格
- 12.経済産業省
1.ガバメントクラウド
1.1 ガバメントクラウドについて
(1)概要
・政府共通のパブリッククラウドサービスの利用環境。
・デジタル庁の以下の資料に概要の記載があります。
| 政府共通のクラウドサービスの利用環境です。クラウドサービスの利点を最大限に活用することで、迅速、柔軟、かつセキュアでコスト効率の高いシステムを構築可能とし、利用者にとって利便性の高いサービスをいち早く提供し改善していくことを目指します。 （出典：https://www.digital.go.jp/policies/gov_cloud） |
・デジタル庁の「ガバメントクラウド概要解説（全編）」には、以下の記載がある。
| ガバメントクラウドは単なるインフラ環境やクラウド環境ではない。システムのモダン化（高コストの要因となる旧来技術からの脱却）を目的とする利用システムに、最適なクラウド環境を手段として提供するのがガバメントクラウドである。 （出典：https://guide.gcas.cloud.go.jp/general/overview-explanation 「1 はじめに」） |
・ガバメントクラウドを構成するクラウドサービスは、ISMAPに登録されている必要があります。
・調達は各省庁ではなくデジタル庁が一括して実施
・各府省庁がクラウドサービスの利用する場合、原則としてガバメントクラウドを検討する義務がある（ガバクラ法案）
(2)関連する用語
| 用語 | 説明 |
|---|---|
| GCAS（Government Cloud Assistant Service） | ・ガバメントクラウド活用支援サービス ・「ジーキャス」と読む。 ガバメントクラウドの利用申請のWebサービス |
| モダン化 | 「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」の 3.5 5)では、モダン化の説明として「自らはサーバーを構築せずマネージドサービスの組合せだけでシステムを構成する、IaCを使う、インターネット接続（閉域網依存からの脱却）、フロントエンド・バックエンド分離型のWebシステム（クライアントサーバー方式やWeb3層モデルからの脱却）、APIで連携する、自動化の徹底（テスト、変更、デプロイ、運用管理）、動的なリソース管理（その時点で必要な分のみ）など、クラウドならではの考え方とする。」としている。 |
| CoE（Center of Excellence） | 知見・技術を集約し、全体をリード支援する専門チームのこと |
(3)クラウドファーストとクラウドスマート
| 方針 | 時期 | 内容 | 補足 |
|---|---|---|---|
| クラウドファースト （クラウド・バイ・デフォルト原則） |
2018年 | クラウドサービスの利用を第一として検討 | 2018年6月「政府情報システムにおけるクラウドサービスの利用に係る基本方針」を公表 |
| クラウドスマート | 2022年 | クラウドサービスを賢く適切に利用 | 2022年秋に上の基本方針を改定。単にオンプレをクラウドにするだけではなく、業務の見直し（BPR）を行う |
クラウドファーストに従ってクラウド移行していくには、IaCの活用も重要であろう。
(3)実際のサービス事業者
・採択されているのは、以下の5つ
| サービス名 | 事業者 | 備考 |
|---|---|---|
| さくらのクラウド | さくらインターネット | 国産事業者として初認定 |
| Amazon Web Services (AWS) | Amazon | 世界・国内クラウドシェアNo.1。圧倒的なサービス数と、行政・民間での豊富な導入実績 |
| Microsoft Azure | Microsoft | WindowsやMicrosoft 365など、既存のマイクロソフト製品群やシステムとの親和性が極めて高い |
| Google Cloud Platform (GCP) | ||
| Oracle Cloud Infrastructure (OCI) | Oracle | 他社に比べてコストが安価 |
・データは日本国内のデータセンターに置くことが求められている
・ガバメントクラウド本番環境を利用している1497システムのうちAWSが1452システムを占める。→97.0%
出典：https://xtech.nikkei.com/atcl/nxt/column/18/00001/10042/
(※NotebookLMを使って作成）
(4)ガバクラを使うメリット
通常のクラウドではなくガバクラを使うといいことあるのでしょうか？
現場のシステム主管（PJMO）は、通常のクラウドサービスを利用することも、ガバメントクラウドを利用することもできます。
では、ガバメントクラウドを使うと良いことある？
❶セキュリティの担保
・政府標準のセキュリティ要件を満たしている（ISMAP認証など）。
・自治体や省庁ごとにセキュリティ基準を検討および実装する手間が減る。
❷共通基盤としての信頼性
・サポート体制が政府横断で整えられている。
・GSSや他省庁システムもガバクラ上にあり、 同じ基盤に載せた方が相互接続が容易
❸調達・運用の効率化
・ガバクラを使うことで、調達プロセスや契約が統一化されている。
・PJMOが個別にクラウド事業者と契約・交渉するのではなく、契約はデジタル庁がやってくれる。そして、デジタル庁が各省庁に請求することになるだろう。
※ただ、これが利点かどうかは考え方によると思う。予算請求などのプロセスであったり、誰の予算で行うかなど、詳細は不明。
❹コスト優位性
・規模の経済（政府一括調達）によって、単独でクラウド契約するより安価になる可能性がある。
・運用監査やセキュリティチェックのコストを省ける。
・AWSの場合、デジタル庁はエンタープライズの契約を結んでいるので、そのサポートが利用できます。
個別にエンタープライズ契約をすると数百万〜数千万円単位の費用（※要確認）になります。
※問合せやサポート
残念ながら、デジタル庁はそこはやってくれません。クラウド事業者への問合せ窓口は各システム主管が直接持つことになるでしょう。
1.2 ガバクラのセキュリティ対策
(1)セキュリティ対策の全体像
（出典：https://guide.gcas.cloud.go.jp/general/security-tech)
※IaC（Infrastructure as Code）
インフラ構成をコードで管理し、再現性・自動化・バージョン管理を可能にする技術的手法。
AWSでいうと、AWSが提供する純正のIaCツールであるAWS CloudFormationやTypeScript, Python, Java, C# などのプログラミング言語でAWSインフラをコード化するAWS CDK（Cloud Development Kit）がある。
※予防的、発見的統制は、こちらに記載
(2)ガバメントクラウドでの責任共有モデル
・ガバメントクラウドにおける責任範囲は、以下の三つの範囲に分割される。
| 組織 | 役割 | 備考 |
|---|---|---|
| 利用組織 | クラウドサービスを含めたインフラ構成、クラウドサービスの設定、OS、ミドルウェア、アプリケーション、データの管理など | 実際にシステムを構築し、運用する組織。政府機関に加え、地方自治体もある |
| ガバメントクラウド | ガードレール設定、テンプレート/IaCファイル、環境払い出しなど | 実際にはデジタル庁が担当することになると思う |
| CSP | クラウド基盤（ハードウェア、ソフトウェア、ネットワーク）、マネージドサービスなど | AWSなどのCSP |
・各組織の役割
（出典：https://guide.gcas.cloud.go.jp/general/security-tech)
これを見ると、ガバクラが何を提供するのかが見えてくると思う。具体的には、ガードレールとなるポリシーを作成し、それを適用した上で、利用者に提供する。
また、構築がスムーズに行くようなテンプレートやIaCファイルを提供する。そして、マニュアルやらトレーニング、問い合わせ窓口を提供する。
1.3 ガバクラの詳細
(1)アカウントの管理
・デジタル庁からアカウントが発行される。
・また、「管理者権限ユーザーが侵害される可能性を減らすため、本番環境の管理者権限ユーザーの人数は3名までを推奨する。通常の運用時は、必要最小限の権限を付与したユーザーで実施する（出典：https://guide.gcas.cloud.go.jp/general/overview-explanation-chapter-03）」と記載されているので、利用部門（PJMO）としても、管理者権限の乱発はできないようなブレーキが効くであろう。
(2)ネットワーク
基本的に、ガバクラを使おうが、通常のクラウドサービスを使おうが、ネットワーク構成は同じ。しかし、「ただし、各府省拠点からの接続について、インターネット経由での接続を許容できない場合は、デジタル庁ガバメントソリューションサービス（以下GSSネットワークとする）経由での接続や専用線を用いた閉域網での接続を検討すること（出典：https://guide.gcas.cloud.go.jp/general/overview-explanation-chapter-03）」とある。これができるのは、ガバクラに配置しているからだと思う。
(3)デジ庁の役割
・ガバメントクラウドに係る体制
（出典：https://guide.gcas.cloud.go.jp/general/overview-explanation-chapter-03）
・また、上記のところに「デジ庁の役割」に該当するであろう記載がある。
| デジタル庁では以下を行う。 ・デジタル庁(デジタル庁)から利用システムに対してクラウド利用料を調査した上で、クラウドサービスに係る予算要求及び調達を一括して行う。 ・全体管理アカウントを管理し、利用システムに対し、環境利用のためのアカウントや管理者用のアカウントを払い出すとともに、各利用システムのクラウド利用料を一括して支払う。 ・利用システムからのガバメントクラウド自体やそのテンプレート/IaCファイルに関する問合せ対応、FAQの整備、ガバメントクラウド利用に関するドキュメント、利用システムの円滑な運用のサポートを提供する。 ・クラウドCoE体制を通して、利用システムが行うクラウド環境移行作業（環境構築、ネットワーク接続、データ移行等）に関して支援を行う。 ・ガバメントクラウドが推進するモダンアプリケーション化に向けて、企画段階を含む各工程における助言等支援を行う。 |
1.4 ガバクラ法案
(1)概要
・「情報通信技術を活用した行政の推進等に関する法律」（デジタル行政推進法）の改正案
・ガバメントクラウドを利用することを検討する「義務」がある。※個人的には、「検討する義務」というのがあいまいな気がする。
(2)目的
・国と地方公共団体が共通のクラウド基盤を共同利用することで「コストを削減」し、「効率的かつセキュア」な行政システムを実現するための法整備を図る
・自治体とCSP（AWSやAzureなど）で直接契約をせず、CSPとデジタル庁、デジタル庁と自治体のそれぞれで契約を結ぶ。このようなことを可能にするために、この「ガバメントクラウド法案」での法整備が必要。
(3)法案の骨子
❶国と地方の共同クラウド利用環境の整備
国または地方公共団体の事務に関わる情報システムについて、国と地方など複数の主体が共同でクラウドサービスを利用できるようにする
❷ガバメントクラウド利用の検討義務
ガバメントクラウドを利用することを検討することを義務化。また、地方自治体など国以外の機関についても同様の内容を「努力義務」として規定
❸費用負担と一括契約の仕組み
デジタル庁がクラウドサービス提供事業者（CSP）との契約主体となり、国および地方公共団体等の利用料を一括で支払う仕組みを整える。これによりボリュームディスカウントを最大限引き出す。
1.5 Q＆A
Q1.ガバクラってSaaS、PaaS、IaaSの全てが対象？
A1.はい、すべてが対象です。（たぶん）
1.6 MAFFクラウド
(1)概要
このサイトより抜粋
・ガバメントクラウドの先行事例として、令和２年から稼働
・マルチクラウド・マルチアカウントのデザイン
→マルチクラウドなので、AWS＋Azure（Microsoft）＋GCP（Google Cloud Platform）など、複数のクラウドを利用する。マルチアカウントなので、一つのCSP内で、複数のアカウントを運用し、責任の分離やセキュリティ向上に寄与する。
・共通機能をMAFFクラウド管理者アカウントに集約
→管理者アカウントから全体のポリシーを一元的にコントロール
(2)MAFFクラウドの共通機能
上記に記載がありますが、MAFFクラウドの場合、以下の4つをセキュリティ面の共通機能として利用しているとあります。
| 機能 | 概要 | |
|---|---|---|
| 1 | AWS Direct Connect | 専用線接続 |
| 2 | Amazon GuardDuty | 不正アクセスや悪意のある挙動を検出 |
| 3 | AWS Config | ルートユーザのMFAが無効になっている。ポートが全て空いているなどチェック、変更のログの取得 |
| 4 | AWS Security HUB | Configによる各リソースの診断結果をまとめ、全体として準拠性を満たしているかのチェック |
(3)MAFFクラウドCoE
・MAFFクラウドCoEは、「クラウド移行を検討する各部署のPJMO（プロジェクト・マネジメント・オフィス、プロジェクト推進組織を指す）担当者に対し、検討から企画、予算要求、設計・構築、保守運用までのそれぞれの段階で技術支援している。」（出典：日経クロステック https://xtech.nikkei.com/atcl/nxt/column/18/02121/070700002/）とあります。
(4)MAFFクラウドの運用面の大きな利点
・CoEを使ったこのMAFFクラウドの仕組みだと、たとえば脆弱性管理において大きな利点があります。詳しくはこちら
(5)クラウド移行の課題
(1)移行費用が膨らむこと
「クラウド利用で課題になるのは移行費用が膨らむこと」（出典：日経クロステック https://xtech.nikkei.com/atcl/nxt/column/18/02121/070700002/）
2.ISMAP
2.1 概要
・正式名称は、「政府情報システムのためのセキュリティ評価制度」で、Information system Security Management and Assessment Programの頭文字を取ってISMAPです。
・政府の資料によると、「政府が求めるセキュリティ要求を満たしているクラウドサービスを予め評価・登録することにより、政府のクラウドサービス調達におけるセキュリティ水準の確保を図り、政府機関等（各府省庁等及び独立行政法人等）におけるクラウドサービスの円滑な導入に資することを目的とする制度で、令和２年６月に運用を開始」
・政府の資料によると、「各政府機関は、クラウドサービスを調達する際は本制度において登録されたサービスから調達することを原則」とする。
・ISMAP運営委員会の所管はNISC。
2.2 なぜISMAPが必要なのか
・通常のシステム調達ではこのような仕組みがないのに、なぜISMAPが必要なのか。まず、ISMAPは、「クラウドサービス」の調達に関しての制度であることをがポイントです。
・クラウドサービスは、仕様が公開されておらず、セキュリティ対策や運用がどのようになっているか、サービスを利用する側が判断することは困難です。
・政府がクラウドサービスを検討する都度、クラウドサービス側のセキュリティ対策状況を問合せたり確認するのは大変です。そこで、このISMAPによる評価制度を用いるのです。ISMAPに登録されていれば、一定の情報セキュリティ対策の実施が確認されています。よって、ISMAPのサービスに登録されたクラウドサービスを選定すればいいのです。
2.3 ISMAPクラウドサービスリスト
登録されている実際のサービスリストは、以下で検索できます。
https://www.ismap.go.jp/csm?id=cloud_service_list
たとえば、AWSは、「クラウドサービスの名称」が「Amazon Web Services」、登録番号がC21-0008-2となっている。Amazon Web Servicesの言明対象範囲として、ISMAPのサイトには資料があり、たとえば、以下がある。AWSのほぼ全て？のサービスが登録されているように感じる。
・Amazon Elastic Compute Cloud (EC2)
・Amazon Elastic Block Store (EBS)
・route53
・Amazon Simple Storage Service (S3)
Q.リージョンは海外でもいいの？
A.はい、日本限定ということはありません。
AWSの場合も、「Amazon Web Services_言明対象範囲.pdf」によると、アメリカだけでなく、ヨーロッパ、オーストラリアなど、多くのリージョンが対象です。なので、海外リージョンを選べば、海外にデータセンターがあることになります。とはいえ、「契約に定める準拠法・裁判管轄に関する情報」の資料を見ると、準拠法は「日本国法」になっています。つまり、リージョンは海外であっても、日本の法律が適用されるということです。
実際の構築時には、海外のリージョンが選べるということであって、機密性が高い情報に関しては、国内のリージョンを選ぶことになると思います。
2.4 ISMAPの利用状況
・「ISMAP等クラウドサービスリスト」への登録サービス数は、令和６年10月末時点で76サービスまで増加している。
・ 国の行政機関におけるISMAPの利用率は、令和５年10月末時点で、IaaSは89％、PaaSは90％、SaaSは69％となっている。
（出典：https://www8.cao.go.jp/kisei-kaikaku/kisei/meeting/wg/2409_01common/241209/common04_04.pdf）
2.5 ISMAPに関するQ＆A
Q1.ISMAPに登録されるには何をすればよいですか？
A.提供するクラウドサービスに対して、登録セキュリティ評価機関による評価を受け、その結果をISMAP運営委員会に提出し、登録審査を通過する必要があります。
Q2.ISMAPとISMS認証は何が違いますか？
A.ISMS（ISO/IEC 27001）は組織全体の情報セキュリティマネジメントの仕組みで、ISMAPはクラウドサービス単位のより詳細な技術・運用面の適合性を求める制度です。
Q3.更新は必要ですか？
A.はい。監査対象期間が終わって、1年4ヶ月以内に更新申請が必要。イメージとしては、1年間が監査期間で、3か月間で監査結果を提出し、その後1か月で更新の申請をする。
Q4.ガバメントクラウドとISMAPは同じものですか？
A.いいえ、ガバメントクラウドは「政府共通のクラウド利用基盤」を指し、ISMAPは「その基盤に使えるクラウドサービスを事前に評価・登録する制度」です。ガバメントクラウドの構成サービスは、ISMAPに登録されているクラウドであることが前提です。ですが、ISMAPの登録されたサービスは、ガバメントクラウド以外の政府のサービスでも利用されます。
Q5.セキュリティ面で外部からの攻撃を受けにくいプライベートクラウドでもISMAPは必要？
以下の資料において、政府が定義するクラウドサービスには、パブリッククラウドとプライベートクラウドの両方が含まれています。この事実から考えると、ISMAPが必要というのは、プライベートクラウドでも同様であろうと判断されます。https://cio.go.jp/sites/default/files/uploads/documents/cloud_policy_20210330.pdf
実際、IDCFプライベートクラウドはISMAPを取得している。https://www.idcf.jp/cloud/private/
2.6 ISMAP取得期間、費用
(1)登録までの期間
通常、準備・評価・申請・審査を含めて6か月〜1年程度かかります。評価項目のボリュームが多く、事前準備が重要です。
(2)費用
・以下のサイトによると、「ISMAPの登録にかかる費用は概ね数千万円〜1億円ほどが相場」とあります。
https://secure-navi.jp/blog/000129
・グラファ―社の資料によると、年間の維持コストは3000万～4000万円程度とある。
https://www8.cao.go.jp/kisei-kaikaku/kisei/meeting/wg/2409_01common/241209/common04_02.pdf
2.7 ISMAP管理基準
(1)概要
・ISMAPの評価基準は専用のISMAP管理基準があります。
・その内容ですが、ISMAPだからといって特別な基準というわけではありません。ISO27001や政府の統一基準、NIST SP800-53などがベースにあり、よくあるセキュリティ対策の基準といえるでしょう。
※出典は、政府の資料
・管理基準は、以下の3つで構成される。
| 基準 | 内容（ISMAPの管理策の資料より引用） |
|---|---|
| ガバナンス基準 | 経営陣が実施すべき事項として、JIS Q 27014(ISO/IEC 27014) の内容を精査し、監査の実施可能性の観点から「プロセス」の4 桁部分(X.X.X. を再構成し、ガバナンス基準とした。 |
| マネジメント基準 | 管理者が実施すべき事項として、情報セキュリティマネジメントの計画、実行、点検、処置、及び、リスクコミュニケーションに必要な実施事項を定めている |
| 管理策基準 | 組織における情報セキュリティマネジメントの確立段階において、リスク対応方針に従って管理策を選択する際の選択肢を与えるものである。「管理策基準」のそれぞれの事項は、管理目的と詳細管理策で構成される。 |
(2)具体的な基準
・ISMAPの管理基準（ただし、一部しか掲載されていない）
https://www.ismap.go.jp/csm?id=kb_article_view&sysparm_article=KB0010028&sys_kb_id=757ef62ac3755250076ededb05013195&spa=1
・ISMAPの管理基準の詳細な基準は500とか700とかの数らしく、かなり多いです。NISCの資料では、「リスクベースアプローチを活用することにより、管理策数を数百まで削減」したい方針が出されている。
・デジ庁が公開しているISMAPの管理策基準
参考資料 クラウドサービスが遵守すべき ISMAP 管理策基準 （統制目標、末尾にＢが付された詳細管理策）
https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/669b13b5/20220630_resources_standard_guidelines_outline_03.pdf
・以下は上記からの抜粋ですが、管理策という位置づけ上、やや抽象的な表現になっている。
| 通番 | ISMAP管理策番号 | クラウドサービスが遵守すべきISMAP管理策 |
|---|---|---|
| 35 | 9.1.1 | アクセス制御方針は、業務及び情報セキュリティの要求事項に基づいて確立し、文書化し、レビューする。 |
| 36 | 9.1.2 | 利用することを特別に認可したネットワーク及びネットワークサービスへのアクセスだけを、利用者に提供する。 |
| 37 | 9.2.1 | アクセス権の割当てを可能にするために、利用者の登録及び登録削除についての正式なプロセスを実施する。 |
| 38 | 9.2.1.6.PB | クラウドサービスのユーザによるクラウドサービスへのアクセスをクラウドサービス利用者が管理するため、クラウドサービス事業者は、クラウドサービス利用者に、ユーザの登録及び登録削除の機能及び仕様を提供する。 |
| 39 | 9.2.2 | 全ての種類の利用者について、全てのシステム及びサービスへのアクセス権を割り当てる又は無効化するために、利用者アクセスの提供についての正式なプロセスを実施する。 |
| 40 | 9.2.2.8.PB | クラウドサービス事業者は、クラウドサービスのユーザのアクセス権を管理する機能及び仕様を提供する。 |
| 41 | 9.2.3 | 特権的アクセス権の割当て及び利用は、制限し、管理する。 |
| 42 | 9.2.3.11.PB | クラウドサービス事業者は、特定したリスクに応じて、クラウドサービスの管理能力にあわせたクラウドサービス利用者の管理者認証に、十分に強固な認証技術を提供する。 |
| 43 | 9.2.4 | 秘密認証情報の割当ては、正式な管理プロセスによって管理する。 |
2.8 ISMAPとISO27017との比較
(1)共通点
・どちらも、クラウドサービスに特化したセキュリティの評価
・第三者による審査が必要
(2)相違点
| 比較項目 | ISMAP （政府情報システムのためのセキュリティ評価制度） |
ISO/IEC27017 （クラウドセキュリティ管理の国際規格） |
|---|---|---|
| 目的 | 日本政府が調達に使うクラウドサービスのセキュリティ基準を評価・登録する | クラウドサービスに特化した情報セキュリティ管理の国際的なベストプラクティスを提供 |
| 策定主体 | 日本政府（内閣官房、デジタル庁など） | ISO（国際標準化機構） |
| 対象 | 政府に納入されるクラウドサービス | 政府・民間問わず |
| 審査 | ISMAP運営委員会（NISC、デジタル庁、総務省、経済産業省、有識者） | 第三者認証機関 |
| 更新間隔 | 1年4か月 | 3年 |
| 取得費用 | 高 | 安 |
| 取得難易度 | 難 | 適切に管理されていれば難しくはない |
2.9 ISMAP-LIU
(1)概要
ISMAP-LIU（ISMAP for Low-Impact Use）は、ISMAPが対象とするクラウドサービスのうち、セキュリティ上のリスクの小さな業務、情報に用いられるSaaSを対象とする制度
(2)ISMAP-LIU策定の背景
「機密性２情報の中でも比較的重要度が低い情報のみを取り扱うサービス等リスクが低いサービスもあり、それらのサービスについて現行のISMAPと一律の取扱いとした場合、過剰なセキュリティ要求となり、それにより当該サービスの活用が進まない場合も考えられる。」
出典：https://www.ismap.go.jp/sys_attachment.do?sys_id=17a1ddcd8324a610aa68c6a8beaad363
(3)ISMAP-LIU に認定されたサービス
2022年11月にサービス申請受付を開始した。2025年3月現在、認定されたサービスは「営業DXサービス Sansan」1件だけのようです。
2.10 ISMAPの課題
課題が認識され、改善に向かっている。
（出典：https://www8.cao.go.jp/kisei-kaikaku/kisei/meeting/wg/2409_01common/241209/common04_04.pdf）
3.GSS
3.1 GSSの基本
(1)GSSとは
・GSS（Government Solution Service）に関するデジタル庁の資料は以下です。
https://www.digital.go.jp/policies/gov_solution_service
ここに「職員が利用する業務用PC、オフィスソフトウェア、コミュニケーションツール、各種セキュリティ対策等の業務環境の整備」とありますように、政府の職員が利用するPCやメール、ソフトウェアを利用する政府専用ネットワーク環境です。
・これまで利用していた「政府共通ネットワーク」の後継
・2023年度（令和5年）に移行完了を目指して進められた。
・NECさんのまとめ
https://jpn.nec.com/government/solution04/col_g.4/index.html
| 【参考】どこの話をしているのか 文字だけだとわかりづらいので、R7年のネットワークスペシャリスト試験の構成図を紹介します。この図は、一般企業の話なので、GSSの話ではありません。ただ、このあたりの話をしているというイメージを掴んでもらえると思います。 ■1.従来のネットワーク構成  ■2.ゼロトラ移行後のネットワーク構成  |
(2)GSSの目的
・府省間ネットワークを構築する
・広帯域、高品質、低コストかつ高いセキュリティを保つ。※それまでの政府共通ネットワークは、ビデオ会議などができないほど低速であった。
(3)歴史
※以下の記事を参照
https://xtech.nikkei.com/atcl/nxt/column/18/00001/06774/
・霞が関WAN（1997年運用開始）
・政府共通ネットワーク（2013年に上記を刷新）
・2021年、ダークファイバーを使って省庁間でビデオ会議を利用する高速ネットワークを構築。このネットワークを各種業務システムが利用できる統合WANに作り替え。
・ガバメントソリューションサービス（GSS）
3.3 GSSとガバメントクラウド
(1)違いは？
・国民の皆様向けに利用する公開サーバはガバメントクラウドで提供され、職員はGSSを利用します。
・GSSが利用する各種アプリケーションの中で、クラウドサービスで提供されるものは、すべてガバメントクラウド上に構築されます。
3.5 GSSと他のネットワーク
(1)他のネットワーク概要
| 名称 | 正式名称 | 主な用途 | 接続対象 | 管理主体 | 特徴・備考 |
|---|---|---|---|---|---|
| GSS | Government Solution Service | 行政機関の業務用PCやネットワーク環境 | 中央省庁 | デジタル庁 | 政府共通プラットフォーム |
| LGWAN | Local Government Wide Area Network（総合行政ネットワーク） | 地方自治体間の行政専用ネットワーク | 自治体、都道府県、総務省など | J-LIS（地方公共団体情報システム機構） | インターネットから分離された閉域網。電子申請・帳票交換などで利用。セキュリティが高い。 |
| 情報ハイウェイ | 地域情報通信基盤整備推進事業などに基づくネットワーク（各自治体ごと） | 都道府県内の官公庁・教育機関などの通信基盤 | 自治体内の各種公共施設 | 各都道府県など | 主に地域内の通信網。LGWANやインターネットと連携することもある。 |
(2)LGWAN
ネットワーク接続はどうなっている？
デジタル庁の資料に、以下の図があります。
（出典：https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/b5181b0c-6424-4977-b415-b1cbb3301bc8/6fad53cc/20240618_policies_assessment_outline_05.pdf）
3.7 GSSで提供される具体的なサービス
・LAN
・PC端末
・ID管理
・省庁横断的なクラウドサービス
・テレワーク環境（ゼロトラストの考え方による設計）
出典は以下
https://xtech.nikkei.com/atcl/nxt/column/18/00001/06774/
4.NCO（旧NISC）
4.1 NISCとは
・内閣サイバーセキュリティセンター（National center of Incident readiness and Strategy for Cybersecurity：NISC）
・Cybersecurityとありますが、サイバーだけをやっているわけではない。メールの誤送信も含めたサイバー以外の情報セキュリティも含んでいる
4.2 NISCの活動
・NISCの活動は、大きく2つに分けられる
❶政府機関等の防護
❷重要インフラの防護 ※つまり、政府機関だけではなく民間企業のセキュリティ対策にも重要な役割を担う
https://www.nisc.go.jp/pdf/about/nisc_gaiyou.pdf
(1)政府機関等の防護
以下の資料によると、主な活動は3つ
| 項番 | 内容 | 具体的な内容 |
|---|---|---|
| 1 | 共通ルールの設定 | ・統一基準群 ・ISMAP（ｾｷｭﾘﾃｨ評価制度） ・調達申し合わせ |
| 2 | 横断監視・即応調整（GSOC） | ・ﾘｱﾙﾀｲﾑ横断的監視 ・警告・助言による情報共有 ・不正ﾌﾟﾛｸﾞﾗﾑの分析・脅威情報の収集 |
| 3 | インシデント対処支援 | ・発生事象の把握 ・被害拡大防止、復旧、再発防止のための支援 ・研修・訓練等の実施 ・CYMAT支援（技術的支援等） |
(2)重要インフラの防護
4.3 NISCからNCOに
・2025（令和７）年７月、内閣サイバーセキュリティセンターを改組し、内閣サイバー官を長とする「国家サイバー統括室（NCO：National Cybersecurity Office）」を設置しました。
（出典：https://www.nisc.go.jp/about/overview/index.html）
・内閣サイバー官という事務次官級のポストを新設
・以下の資料にて、NISCとNCOの役割を比較しても、大きな差は感じない。というか、注釈以外は同じ気がする。
資料1：NISC https://www.nisc.go.jp/pdf/about/NCO_gaiyou.pdf
資料2：NCO https://www.nisc.go.jp/pdf/about/nisc_gaiyou.pdf
4.4 GSOC
(1)GSOCとは
GSOC : Government Security Operation Coordination team
・2008年４月から政府機関に対する情報セキュリティ横断監視・即応調整チーム（第一GSOC）を設置
・2017年４月から独立行政法人等に対する情報セキュリティ横断監視・即応調整チーム（第二GSOC）を設置
（出典：https://www.nisc.go.jp/pdf/policy/kihon-s/shiryou04-3.pdf ）
・各省庁にセンサーを置いている。
(2)GSOCで検知していること
・政府機関に対する不審な通信の検知
※「不審な通信」とは、外部から政府機関等に対する不正アクセス、サイバー攻撃やその準備動作に係るもの、標的型攻撃によりもたらされた不正プログラムが行うもの、これらに該当するとの疑いがあるもの等
・政府機関等のWebサイトに対する稼働状況の監視活動
・セキュリティ対策に必要となる情報収集や情報
（出典：https://www.nisc.go.jp/pdf/council/cs/dai19/19shiryou02.pdf ）
4.5 政府の統一基準
(1)統一基準
発出元はNISCである。
・「政府機関等のサイバーセキュリティ対策のための統一基準群」
https://www.cyber.go.jp/policy/group/general/kijun.html
・政府機関等のサイバーセキュリティ対策のための統一基準（令和7年度版）
https://www.cyber.go.jp/pdf/policy/general/kijyunr7.pdf
・政府機関等の対策基準策定のためのガイドライン（令和７年度版）
https://www.cyber.go.jp/pdf/policy/general/guider7.pdf
・統一基準なので、詳細な内容までは踏み込んでいない。以下、情報セキュリティポリシーが3階層あるように、こちらも階層で分かれている。
（出典：https://www.nisc.go.jp/pdf/policy/general/rev_pointr5.pdf )
ちなみに、セキュリティポリシーの3階層とうまくリンクしているかというと、そうでもないみたい。上記の出典には以下も記載されている。
(3)機密性についての格付の定義
上記の資料に記載があるが、なかなかわかりづらい。ポイントになるであろうところを抜粋すると以下です。
| 格付の区分 | 分類の基準 |
|---|---|
| 機密性3情報 | 秘密文書としての取扱いを要する情報 |
| 機密性2情報 | 不開示情報に該当すると判断される蓋然性の高い情報を含む情報であって、「機密性３情報」以外の情報 |
| 機密性１情報 | 不開示情報に該当すると判断される蓋然性の高い情報を含まない情報 |
ちなみに、「蓋然性（がいぜんせい）」とは、起こる見込みのこと。
(4)最高情報セキュリティアドバイザー
・各省庁では最高情報セキュリティアドバイザーを設置し、セキュリティ対策に関する助言を求める。
・「政府機関等のサイバーセキュリティ対策のための統一基準（令和５年度版）（ https://www.nisc.go.jp/pdf/policy/general/kijyunr5.pdf ）に記載されているのは2か所。
| 2.1.1 組織・体制の整備 遵守事項 (5) 最高情報セキュリティアドバイザーの設置 (a) 最高情報セキュリティ責任者は、情報セキュリティについて専門的な知識及び経験を有する者を最高情報セキュリティアドバイザーとして置き、自らへの助言を含む最高情報セキュリティアドバイザーの業務内容を定めること。 |
| 5.2.1 情報システムの企画・要件定義 遵守事項 (3) 情報システムのセキュリティ要件の策定 (d) 情報システムセキュリティ責任者は、構築する情報システムが取り扱う情報や情報システムを利用して行う業務の内容等を踏まえ高度な情報セキュリティ対策を要求する情報システムについては、情報システムの分類に応じて策定したセキュリティ要件について、最高情報セキュリティアドバイザー等へ助言を求め、業務の特性や情報システムの特性を踏まえて、上位の情報セキュリティ対策をセキュリティ要件として盛り込む必要が無いかを確認すること。 |
・「政府機関等の対策基準策定のためのガイドライン（令和５年度版）」（https://www.nisc.go.jp/pdf/policy/general/guider6.pdf ）には、具体的な業務内容の例が記載されている。
| 【 基本対策事項 】 ＜2.1.1(5)(a)関連＞ 2.1.1(5)-1 最高情報セキュリティ責任者は、以下を例とする最高情報セキュリティアドバイザーの業務内容を定めること。 a)機関等全体の情報セキュリティ対策の推進に係る最高情報セキュリティ責任者及び最高情報セキュリティ副責任者への助言 b)情報セキュリティ関係規程の整備に係る助言 c)対策推進計画の策定に係る助言 d)教育実施計画の立案に係る助言並びに教材開発及び教育実施の支援 e)情報システムに係る技術的事項に係る助言 f)情報システムの設計・開発を外部委託により行う場合に調達仕様に含めて提示する情報セキュリティに係る要求仕様の策定に係る助言 g)職員等に対する日常的な相談対応 h)情報セキュリティインシデントへの対処の支援 i)情報システムの分類に応じた情報セキュリティ対策に係る助言 j)前各号に掲げるもののほか、情報セキュリティ対策への助言又は支援 |
(5)具体的な内容
以下の資料より、いくつか抜粋する
https://www.nisc.go.jp/pdf/policy/general/guider6.pdf
❶政府ドメイン名の使用
| 遵守事項 (1) 政府ドメイン名の使用 (a) 情報システムセキュリティ責任者は、機関等外向けに提供するウェブサイト等が実際の機関等提供のものであることを利用者が確認できるように、政府ドメイン名を取得できない場合を除き政府ドメイン名を情報システムにおいて使用すること。 (b) 職員等は、機関等外向けに提供するウェブサイト等の作成を業務委託する場合においては、機関等に適するドメイン名を使用するよう調達仕様に含めること。 |
❷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 情報システムセキュリティ責任者は、主体の属性、アクセス対象の属性に基づくアクセス制御の要件の定期的な確認による見直しをすること。 |
❸7.1.4 ログの取得・管理
| 遵守事項 (1) ログの取得・管理 (a) 情報システムセキュリティ責任者は、情報システムにおいて、情報システムが正しく利用されていることの検証及び不正侵入、不正操作等がなされていないことの検証を行うために必要なログを取得すること。 (b) 情報システムセキュリティ責任者は、情報システムにおいて、その特性に応じてログを取得する目的を設定した上で、ログを取得する対象の機器等、ログとして取得する情報項目、ログの保存期間、要保護情報の観点でのログ情報の取扱方法等について定め、適切にログを管理すること。 (c) 情報システムセキュリティ責任者は、情報システムにおいて、取得したログを定期的に点検又は分析する機能を設け、悪意ある第三者等からの不正侵入、不正操作等の有無について点検又は分析を実施すること。 【 基本対策事項 】 ＜7.1.4(1)(a)関連＞ 7.1.4(1)-1 情報システムセキュリティ責任者は、情報システムに含まれる構成要素（サーバ装置・端末等）のうち、時刻設定が可能なものについては、情報システムにおいて基準となる時刻に、当該構成要素の時刻を同期させ、ログに時刻情報も記録されるよう、設定すること。 ＜7.1.4(1)(b)関連＞ 7.1.4(1)-2 情報システムセキュリティ責任者は、所管する情報システムの特性に応じてログを取得する目的を設定し、以下を例とする、ログとして取得する情報項目を定め、管理すること。 a)事象の主体（人物又は機器等）を示す識別コード b)識別コードの発行等の管理記録 c)情報システムの操作記録 d)事象の種類 e)事象の対象 f)正確な日付及び時刻 g)試みられたアクセスに関わる情報 h)電子メールのヘッダ情報及び送信内容 i)通信パケットの内容 j)操作する者、監視する者、保守する者等への通知の内容 7.1.4(1)-3 情報システムセキュリティ責任者は、取得したログに対する、不正な消去、改ざん及びアクセスを防止するため、適切なアクセス制御を含む、ログ情報の保全方法を定めること。 ＜7.1.4(1)(c)関連＞ 7.1.4(1)-4 情報システムセキュリティ責任者は、取得したログを効率的かつ確実に点検及び分析し、その結果を報告するために、情報システムの分類に応じて以下の対策を実施すること。 【基本セキュリティ対策】以下を例とする当該作業を支援する機能を導入すること。 a)ログ情報をソフトウェア等により集計し、時系列で表示し、報告書を生成するなどの作業の自動化機能 【追加セキュリティ対策】基本セキュリティ対策の実施に加えて、以下を例とする当該作業を支援する機能の導入を検討すること。 b)リアルタイムでのログの調査・分析を行うための機能 |
さらに、（解説）にて、より詳細な説明がある。
たとえば、ログの保存期間について
| 遵守事項 7.1.4(1)(b)「保存期間」について 保存期間については、情報システム又は当該システムに保存される情報の特性に基づき、設定される。ただし、標的型攻撃に関し、攻撃の初期段階から経緯を確認する観点からは、過去の事例を踏まえ、ログは１年間以上保存することが望ましい。 なお、ログの長期保存にはコストがかかるため、費用を抑える観点から、直近のログはすぐに調査可能なハードディスク等のオンラインの電磁的記録媒体に保存し、それ以降はテープや光ディスク等の長期保存に適した外部電磁的記録媒体に保存する方法も考えられる。オンラインの電磁的記録媒体に保存する期間については、過去に遡って調査する期間や頻度、どの程度のコストをログの保存にかけられるかを考慮して決定する。 |
また、d)やe)の内容についても詳細な記載があります。
| 基本対策事項 7.1.4(1)-2 d)「事象の種類」について 事象の種類の例を以下に示す。 • ウェブサイトへのアクセス • ログイン及びログアウト • サーバ、ファイルへのアクセス • 要保護情報の書き出し、変更、削除 • アプリケーションの起動及び終了 • ユーザ、グループの作成、変更、削除 • ユーザ、グループへのアクセス権限の設定、変更、削除 • 通信経路及びアクセス制御の設定、変更、削除 • 不正プログラム対策ソフトウェア等の更新、不正プログラムの検出 • 特定の操作指令 基本対策事項 7.1.4(1)-2 e)「事象の対象」について 事象の対象の例を以下に示す。 • アクセスした URL、IP アドレス • ログインしたアプリケーション名 • アクセスしたファイル名及びファイル操作内容 • 異常検出された URL、IP アドレス、アプリケーション名、ファイル名 • 起動及び終了したアプリケーション名及びパス • 特定の操作指令の対象 |
❹PPAP関連
基本対策事項 8.1.1(2)-2 d)「実行プログラム形式のファイルを削除等する」について
官公庁で多用されてきたパスワード付きZIPファイル添付（いわゆる“PPAP”）は、受信側でのウイルス検査ができずかえってリスクを高めることが指摘されています。
| なお、パスワードを用いて暗号化された圧縮形式のファイルについては、当該ファイル中に不正プログラムが含まれるか否かの検疫を行えないことが考えられるため、不正プログラムに感染するリスクがより高まることが想定される。そのため、パスワードを用いて暗号化された圧縮形式のファイル中に実行プログラム形式のファイルが含まれるか否かを技術的に検査できない場合には、暗号化された圧縮形式のファイル自体を添付ファイルから削除等する機能の導入を考慮する必要がある。圧縮形式のファイル中のファイルの検査をする機能を導入する代わりに、暗号化の有無にかかわらず圧縮形式のファイルのすべてを削除等する措置を用いてもよい。 （出典：https://www.nisc.go.jp/pdf/policy/general/guider6.pdf ） |
(6)具体的な内容：対策基準策定のためのガイドライン
以下の資料より、いくつか抜粋する
政府機関等の対策基準策定のためのガイドライン（令和７年度版）
https://www.cyber.go.jp/pdf/policy/general/guider7.pdf
❶情報システム台帳の整備
「(a) 統括情報セキュリティ責任者は、全ての情報システムに対して、当該情報システムのセキュリティ要件に係る事項について、情報システム台帳に整備すること。」という記載があり、詳細は以下である。
【 基本対策事項 】 ＜2.1.2(1)(a)関連＞ 2.1.2(1)-1 統括情報セキュリティ責任者は、以下の内容を全て含む台帳を整備すること。 a)情報システム名 b)管理課室 c)当該情報システムセキュリティ責任者の氏名及び連絡先 d)システム構成 e)接続する機関等外通信回線の種別 f)取り扱う情報の格付及び取扱制限に関する事項 g)当該情報システムの設計・開発、運用・保守に関する事項 h)情報システムの利用目的 i)情報システムの分類基準に基づいて実施した情報システムの分類結果 j)連携する情報システム及び連携内容 また、民間事業者等が提供するクラウドサービス等を利用して情報システムを構築する場合は、前述の a)～j)に加え、以下を全て含む内容についても台帳として整備すること。 k)クラウドサービス等の名称（クラウドサービスの場合、必要に応じて機能名までを含む） l)クラウドサービス等の提供者の名称 m)利用期間 n)クラウドサービス等の概要 o)ドメイン名 p)クラウドサービス等で取り扱う情報の格付及び取扱制限に関する事項 q)情報の暗号化に用いる鍵の管理主体（機関等管理かクラウドサービス等の提供者管理か） r)クラウドサービス等で取り扱う情報が保存される国・地域 s)サービスレベル
→個人的な感想で、システムで利用しているソフトウェアや外部に公開しているポートは、セキュリティ的には欲しい。ポートに関しては、サーバのポートとFWを含めて開けているポートは違いますが・・・。
4.6 政府デジタル人材のスキル認定
(1)資料の出典
政府デジタル人材のスキル認定の基準
https://www.nisc.go.jp/pdf/council/cs/taisaku/shingikan/dai26/26skill_nintei.pdf
(2)スキル認定区分
政府デジタル人材のスキル認定は、「政府デジタル人材として職務を遂行する」人に対する認定であり、全員が該当するわけではありません。ごく一部と言えるでしょう。
ちなみに、以下の5つの区分があります。
| 項番 | スキル認定区分 |
|---|---|
| 1 | 係員スキル認定 |
| 2 | 係長スキル認定 |
| 3 | 課長補佐（プロジェクト担当）スキル認定 |
| 4 | 課長補佐（サイバーセキュリティ担当）スキル認定 |
| 5 | 課室長スキル認定 |
(3)スキル認定の基準
以下のすべての要件を満たす必要がある
（１）業務経験
（２）公的資格試験等の合格又は修了
（３）研修の修了
(4)公的資格試験等の合格又は修了
スキル認定区分に応じて、求められる資格が異なる。
たとえば、係長であれば、応用情報技術者試験の合格が求められる。※代替えのベンダ資格もあり。
5.デジタル庁
5.1 デジタル庁について
(1)デジタル庁とは
デジタル社会の形成に向けた司令塔として、デジタル改革を推進する。
（出典：https://www.nisc.go.jp/pdf/council/cs/dai31/31shiryou01.pdf ）
(2)NISC（NCO）との違い
・まず、デジタル庁は、セキュリティだけではなく、デジタル社会形成に向けた改革を推進することがミッション。
・それに対して、（NCO）は、セキュリティがミッション
・両者は密接に連携しており、デジタル庁が推進するシステムにも、NISCのセキュリティ基準が適用されるケースが多いです。
5.2 各種のガイドライン
(1)生成AIの調達・利活用に係るガイドライン
・正式名称は「行政の進化と革新のための生成AIの調達・利活用に係るガイドライン」で、以下のリンクに記載があります。
https://www.digital.go.jp/news/3579c42d-b11c-4756-b66e-3d3e35175623
| Q.政府は生成AIの利用を禁止する立場なの？それとも使った方がいいという立場？ |
→ガイドラインには「政府の様々な業務への生成AIの利活用促進とリスク管理を表裏一体で進める」とあり、リスク管理をしながらも、基本的にはAIの利活用を促進しています。
・この中で、「5.2生成AIによるリスク」が整理されている。以下はリスクを引用。
| カテゴリ | 内容 | 詳細 |
|---|---|---|
| 技術的リスク | データ汚染攻撃等のAIシステムへの攻撃 | 学習データへの不正データ混入、アプリケーション⾃体を狙ったサイバー攻撃、プロンプトを通した攻撃等のリスクにより、AIの出力が意図的に操作され、悪影響が生じる。 |
| バイアスのある出力、差別的出力、一貫性のない出力等 | 学習データの偏り等によりAIが差別を助長する。 | |
| ハルシネーション等による誤った出力 | 生成AIが事実と異なることをもっともらしく回答する。 | |
| ブラックボックス化、判断に関する説明の不足 | AIの判断のブラックボックス化により、有事の説明責任を果たせなくなる。また、複雑な機構を持つAIシステムの場合、メンテナンスやトラブルシューティングの難易度が上がる場合がある。 | |
| 社会的リスク | 個人情報の不適切な取扱い | 適切な同意取得がなく、透明性を欠く個人情報の利用が行われる。 |
| 生命等に関わる事故の発生 | 自動運転等において、AIの誤動作による⼤規模な事故リスクが発生する懸念がある。生成AIで機械等のプログラムコードを生成するケースでは、誤った/非効率なコードによって、パフォーマンスの低下や事故等につながる懸念がある。 | |
| トリアージにおける差別 | AIが優先順位を決定する際にバイアスを持つことで、公平性の喪失等が生じる可能性がある。医療場面においては、生命に対する脅威が発生する可能性がある。 | |
| 過度な依存 | 人材採用活動等、重要な意思決定におけるAIへの過度な依存により、企業が説明責任を問われたり批判を受けたりする懸念がある。また、生成AIを用いたチャットボットとの会話により、利用者が精神的依存状態になる事例も報告されている。 | |
| 悪用 | 詐欺目的でAIが利用される懸念がある。 | |
| 知的財産権等の侵害 | 生成物による他者の知的財産権等の侵害の可能性がある。複数のアーティストからの集団訴訟事例もある。 | |
| 金銭的損失 | 企業が自社の扱うAIの出力により他者の権利を著しく侵害した場合等において、損害賠償請求など金銭的な責任を問われる懸念がある。 | |
| 機密情報の流出 | 個人情報及び機密情報がプロンプトとして入力され、そのAIからの出力等を通じて流出してしまう懸念がある。特に、外部サービスと内部データを連携する場合は、意図しない重要情報の漏えいや情報の改ざん等に注意が必要となる。 | |
| 労働者の失業 | AI等の導入により、失業リスクや格差の拡大なども懸念されている。 | |
| データや利益の集中 | 一部のAI開発者のみにデータや利益が集中する懸念がある。また、少数言語国では自国言語による高性能なAIが存在しないといった懸念がある。 | |
| 資格等の侵害 | 法律又は医療等業法免許及び資格が求められる領域に生成AIを利活用する場合、業法免許及び独占資格等の侵害リスクが存在する。 |
(2)セキュリティ・バイ・デザインガイドライン
・DS-200 政府情報システムにおけるセキュリティ・バイ・デザインガイドライン
https://www.digital.go.jp/resources/standard_guidelines
・言葉定義として、上記のリンク内にある資料には、以下の記載がある。
| 本書では政府情報システムの企画工程から設計工程、開発工程、運用工程まで含めた全てのシステム開発ライフサイクルにおいて、一貫したセキュリティを確保する方策のことを「セキュリティ・バイ・デザイン」と定義する。 |
・また、「セキュリティ・バイ・デザインの基本方針」として、以下の記載がある。
| 1. 事後的ではなく、予防的にセキュリティ対策を組み込むこと 2. 全てのシステム開発ライフサイクルを保護すること 3. 初期設定値においてセキュリティが担保された状態を実現すること 4. システム特性に応じて過不足ないセキュリティ対策を実施すること 5. セキュリティリスクの評価、管理を実施すること 6. 利便性を損なわないように、セキュリティを確保すること |
5.3 各種資料
(1)政府情報システムにおける セキュリティリスク分析ガイドライン
デジタル庁の資料です。
https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/1b65a1dc/20230411_resources_standard_guidelines_guideline_01.pdf
・上記から何点か抜粋します。
| 2.4. リスク分析のプロセス リスク分析のプロセスは、「ISO31000:2018, Risk management－Guidelines」のプロセスを参考に、本ガイドラインで採用する組み合わせアプローチのプロセスを以下のように定義する。   |
| 3.2. 事業への影響度（インパクト）の定義 政府情報システムが提供する国民や事業者向けの行政サービスや、行政機関の業務において生じる負の影響を、事業リスクとして以下のように定義する。  |
5.4 GPKI
・政府認証基盤（GPKI：Government Public Key Infrastructure）
・デジタル庁が所掌
・GPKIのページから
| 政府認証基盤は行政機関側の認証局であるブリッジ認証局及び府省認証局等から構成され、平成13年4月から運用を開始しました。また、平成20年1月から、府省認証局等が順次廃止され、現在、１つの政府共用認証局に集約されております。（出典：https://www.gpki.go.jp/） |
・以降は要調査
・ルートCAの役割とブリッジ認証局の役割を持つ。
・個別のサーバ証明書などは発行しない。
・ルート証明書は、Windowsにデフォルトで入っているのではなく、個別にダウンロードする必要がある。
5.5 CRSA
・常時リスク診断・対処（CRSA: Continuous Risk Scoring and Action）
https://www.digital.go.jp/policies/security/crsa
・言葉の通り、年１回などのスポット的なリスク診断ではなく、常時診断するという考え方です。
6.サイバーセキュリティに関する法律
6.1 サイバーセキュリティ基本法
(1)サイバーセキュリティ基本法
以下の4つの章で構成されている。
第一章 総則（第一条―第十一条）
第二章 サイバーセキュリティ戦略（第十二条）
第三章 基本的施策（第十三条―第二十三条）
第四章 サイバーセキュリティ戦略本部（第二十四条―第三十五条）
(2)サイバーセキュリティ戦略本部
以下にあるように、官房長官（2025年は林 芳正さん）を筆頭に、デジタル大臣や総務大臣および外部の有識者による18名のメンバーで構成されている。
https://www.nisc.go.jp/pdf/council/cs/meibo20250401.pdf
日本全体のサイバーセキュリティ戦略の決定する会議のことだと考えればいいだろう。
| Q.NISCとはどういう関係？ |
A.戦略本部が決めた方針を具体的に実行・調整・監督する事務機関がNISC
6.2 能動的サイバー防御法
・『「国民生活や経済活動の基盤」と「国家及び国民の安全」をサイバー攻撃から守るため、能動的なサイバー防御を実施する体制を整備する。』
（出典：https://www.nisc.go.jp/pdf/council/cs/ciip/dai39/39shiryou_09.pdf ）
能動的サイバー防御を導入する関連法（総称・パッケージ）
├── 能動的サイバー防御法（通称）
│ └── 中核法：
│ 重要電子計算機に対する不正な行為による被害の防止に関する法律
│ （令和7年法律第42号・通称「サイバー対処能力強化法」）
└── 関係法律の整備法：
重要電子計算機に対する不正な行為による被害の防止に関する法律の施行に伴う
関係法律の整備等に関する法律
（令和7年法律第43号・俗称「同整備法」）
| 区分 | 名称（通称） | 正式名称 | 説明 |
|---|---|---|---|
| A | 能動的サイバー防御法（通称） | 重要電子計算機に対する不正な行為による被害の防止に関する法律（令和7年法律第42号） | 中核となる法律を指す呼び名。サイバー対処能力強化法とも呼ばれる。 |
| B | 能動的サイバー防御を導入する関連法（総称） | 中核法（42号）＋ 整備法（43号） | 能動的サイバー防御の導入に必要な2本セット全体のパッケージ名。 |
| A-1 | サイバー対処能力強化法（通称） | 重要電子計算機に対する不正な行為による被害の防止に関する法律（令和7年法律第42号） | 能動的サイバー防御の制度を創設した本体の法律。政府が攻撃の把握・無害化を行う根拠法。 |
| A-2 | 同整備法（通称） | 重要電子計算機に対する不正な行為による被害の防止に伴う関係法律の整備等に関する法律（令和7年法律第43号） | 中核法を運用するために、警察法・通信法などを一括改正する調整法。 |
・NSCが発足したタイミング（2025.7.1）から施行された
・「能動的」サイバー防御と言われたりもするが、決してサイバー攻撃へ反撃をするわけではありません。「通信情報の利用」ということで、「（同意によらない）通信情報の取得」し、「重大な危害を防止するための警察による無害化措置」ができたりします。具体的には、政府の判断でその情報を通信キャリアなどから入手し、通信の中身（内容）ではなく、主にメタデータ（宛先IP、宛先ポート、通信先ドメインなど）に基づき、攻撃者らしきらしき通信を、IPアドレス制限などによって通信を止めることができます。ちなみに、これまでは、憲法や電気通信事業法に基づく「通信の秘密」の保護により、政府が通信の内容に事前にアクセスすることは原則としてできませんでした。
7.個人情報保護委員会への報告
7.1 個人情報保護委員会への報告
以下に記載あり。
https://www.ppc.go.jp/personalinfo/legal/leakAction/
■ポイント ・「漏えい」ではなく「おそれ」であっても報告が必要 ・民間企業の場合は1000人を超える場合だが、行政機関の場合は100人が基準 ・民間企業の場合、「個人データ」であるが、行政機関の場合は「保有個人情報」が対象
(1)個人データと保有個人情報の違い
| 用語 | 対象主体 | 適用法令 | 特徴 | *補足 |
|---|---|---|---|---|
| 個人データ | 民間事業者等 | 個人情報保護法（一般法） | 検索可能な形で管理される個人情報 | 個人情報保護法に従いうので、コンピュータ処理されるか、検索可能な形で整理された個人情報。バラバラに保管した紙の名刺の情報は対象外 |
| 保有個人情報 | 行政機関・独法等 | 行政機関個人情報保護法 など | 組織的に保有し、一定期間使用が予定される個人情報 | 個人データと違い、書類などの紙で保存した情報も含まれる |
(2)報告の期限
・速報は、発覚日から、3-5日以内
・確報は、発覚日から30日以内
(3)漏えい等報告が必要な場合
・要配慮個人情報が含まれる
・不正に利用されることにより財産的被害が生じるおそれがある（たとえば、クレジットカードの番号など）
・不正の目的をもって行われたおそれがある
・一定件数以上（民間企業の場合は1000人を超える場合だが、行政機関の場合は100人）
・条例要配慮個人情報が含まれる保有個人情報の漏えい等（又はそのおそれ）※地方公共団体の機関、地方独立行政法人
8.自治体のセキュリティ
8.1 ネットワーク分離
通信経路 (7) LGWAN接続系端末に１台化 オンプレミス セキュアブラウザの対策イメージ
（出典：https://www.soumu.go.jp/main_content/001001339.pdf ）
9.IPA
9.1 JC-STAR
(1)概要
・セキュリティ要件適合評価及びラベリング制度（JC-STAR）
https://www.ipa.go.jp/security/jc-star/index.html
・「IoT製品を対象として、共通的な物差しで製品に具備されているセキュリティ機能を評価・可視化することを目的」としています。
(2)適合ラベル
| レベル | 想定利用者・用途 | 要件の内容 | 評価主体 |
|---|---|---|---|
| ★4（レベル4） | 政府機関・重要インフラ・大企業・自治体などの最重要システム向け | ★1・★2に加えて高度で汎用的な追加セキュリティ要件 | 第三者評価（独立組織） |
| ★3（レベル3） | 上記と同様に高リスク用途を想定 | ★1・★2に加えた強化された追加要件 | 第三者評価（独立組織） |
| ★2（レベル2） | 一般企業や業務システム向け | 製品カテゴリ特性を考慮した、★1に追加される基本的セキュリティ要件 | ベンダー自己宣言 |
| ★1（レベル1） | 一般家庭含む幅広いIoT向け | 製品として共通して求められる最低限のセキュリティ要件 | ベンダー自己宣言 |
10.NICT
(1)NICTとは
(2)CYXROSS
・CYXROSSは「純国産」のセキュリティ技術であり、機能としてはEDR（Endpoint Detection and Responseの役割を果たすセンサー（エージェント）です。
・エンドポイントのEDRとは共存する形になる。
・ただ、EDRのように止める機能はなく、監視するだけ。（止める機能を持つとなると、プロセスを奪いあうので、他のEDRとの共存ができなくなる）
・開発元はNICTで、監視はNICTのNICT CYNEX。
| ・NICT開発のセンサー「CYXROSS Agent」を政府端末に導入し情報収集 ・ NICT CYNEXで組織横断的情報分析を行い、デジタル庁やNISC等に情報共有、今後GSOCとも連携予定 ・CYXROSS Agentは各省庁の既存のエンドポイント対策製品と共存（セカンドオピニオン）  （出典：https://www.soumu.go.jp/main_content/000952545.pdf） |
11 セキュリティの規格
11.1 全体像
| 規格 | 意味 | 説明 | 主な対象者 |
|---|---|---|---|
| ISO/IEC27001 | 情報セキュリティマネジメントシステム（ISMS）要求事項 | 情報セキュリティの基本ルール（認証対象） | 全組織・情報システム部門 |
| ISO/IEC27002 | 情報セキュリティ管理策の実践のための規範 | 27001の実施手順集（詳細な管理策） | 実務担当者 |
| ISO/IEC27014 | 情報セキュリティガバナンス | 経営層向けのセキュリティ統治ガイド | 経営層・CISO・ガバナンス責任者 |
| ISO/IEC27017 | クラウドサービスにおける情報セキュリティ管理策の実践のための規範 | ISO27001のクラウドに特化したものと考えればいいでしょう。 | クラウド提供者・利用者 |
| ISO/IEC27018 | 個人識別情報（PII）の保護に関する実践規範（パブリッククラウド） | パブリッククラウドでの個人情報保護ガイド | クラウド提供者（PIIを取り扱う） |
| ISO/IEC27701 | プライバシー情報マネジメントシステム（PIMS）－要求事項および指針 | 27001をベースに、プライバシー保護に関するもの。GDPRとの対応表も付則にあり、GDPRに適合する際にも参考になる。 | プライバシー担当者・法務部門・情報管理責任者 |
11.2 ISO/IEC27017
(1)概要
・ISO/IEC 27017を取得するには、ISMS（ISO/IEC 27001）認証を取得する必要がある。
・ISO/IEC 27017 は、クラウドサービスに特化したセキュリティ認証
・ISO/IEC 27017の対象となるのは、クラウドサービスを提供する組織（CSP）と
・クラウドサービスを利用する組織（CSC）の2つです。
・ISO27017は、クラウドサービス単位の認証ではなく、組織に対する認証です。CSマーク（クラウドセキュリティ・マーク）は、クラウドサービス単位だったはず。
・以下にあるように、「ISO/IEC 27001の適用範囲内またはISO/IEC 27001と同一とする」
https://www.jqa.jp/service_list/management/service/iso27017/
・審査は通常、文書審査と、現地またはリモートでの運用状況確認審査が行われる。
・認証の取得までには、既にISMS認証を取得済みの企業の場合、半年くらいで取得できると思われる。
・毎年、維持審査が必要で、数十万程度の費用は発生する。また、３年ごとに再認証の審査が必要
(2)クラウドならではの規定とは？
内容に関しては、クラウドサービス事業者のホワイトペーパー（https://www.iij.ad.jp/svcsol/certificate/CPX006.pdf）でも確認できるが、クラウドサービスならではとして、たとえば、以下のような要件が求められる。
| 項番 | 内容 |
|---|---|
| CLD.6.3.1 | クラウドコンピューティング環境における役割及び責任の共有及び分担 |
| CLD.8.1.5 | クラウドサービスカスタマの資産の除去 →解約の翌日を起算日（1 日目）として、起算日から 90 日間以内に、すべての情報が削除されます。 |
| CLD.9.5.1 | 仮想コンピューティング環境における分離 →お客様がアクセスするネットワークと弊社運用担当者が利用する管理ネットワークは分離しています。 |
| CLD.12.4.5 | お客様専用のコントロールパネルにおいて、アクセスログを提供しております。 →自分でログが確認できる |
(3)原本
❶ISO公式サイト
https://www.iso.org/standard/43757.html
155ドル
❷JSA（日本規格協会）
https://webdesk.jsa.or.jp/books/W11M0090/index/?bunsyo_id=JIS+Q+27017%3A2016
4620円
12.経済産業省
12.1 サプライチェーン強化に向けたセキュリティ対策評価制度（通称：SCS評価制度）
(1)制度の概要と背景
近年、セキュリティが比較的脆弱な取引先（中小企業など）を踏み台にして侵入する「サプライチェーン攻撃」が増えています。
これまでは、発注元企業が独自の「セキュリティチェックシート」を受注企業に送付して対策状況を確認していましたが、受注企業側は取引先ごとに異なるフォーマットへの回答を迫られ、大きな負担でした。この制度は、こうした非効率なチェックシートのやり取りを削減し、日本全体のセキュリティ水準を底上げすることを目的としています。・・・が、本当に意味あるかは不明
(2)5段階の評価システム（★1〜★5）
・企業の対策成熟度に応じて5つの段階（星の数）で評価
・★1と★2は既存のIPA（情報処理推進機構）の制度を活用し、今回の新制度で新たに★3〜★5が創設される。
| 評価段階 | 対策の目安と対象企業 | 評価スキーム | 有効期限（予定） |
| --- | --- | --- | --- |
| ★5 | サプライチェーン企業が到達点として目指すべき高度な対策（国際規格等のリスクベース） | 第三者評価 | 今後検討 |
| ★4 | サプライチェーンに大きな影響をもたらす企業が標準的に目指すべき対策（多層防御など） | 第三者評価 | 3年 |
| ★3 | すべてのサプライチェーン企業が最低限実装すべき基礎的な防御策と体制整備 | 自己評価 ＋ 専門家等の確認 | 1年 |
| ★2 | 自社診断の実施と「情報セキュリティ基本方針」の策定・公開 | IPA「SECURITY ACTION」自己宣言 | - |
| ★1 | IPA「情報セキュリティ5か条」への取り組み | IPA「SECURITY ACTION」自己宣言 | - |
(3)★3の取得方法
取得プロセスは以下のようになります。
❶対策の実行（約25項目の必須要件）
自社のIT環境を見直し、制度が求めるセキュリティ要件をクリアします。
| 主な要件の例: OSやソフトウェアの常に最新化（脆弱性対応） 多要素認証（MFA）の導入 ウイルス対策ソフト（EDRなど）の導入とログ監視 データのバックアップ体制 インシデント発生時の連絡体制・初動対応ルールの整備など |
❷自己評価の実施
自社でチェックシートを用い、要件を満たしているか年に1回自己評価を行います。
❸専門家による確認・助言
★1や★2と異なり、★3では「自己評価の結果を、外部の専門家やITベンダー等に確認してもらい、助言を受けるプロセス」が含まれます。
❹登録・公開
所定のプラットフォーム等に結果を登録し、★3企業としての認定を受けます（有効期限は1年更新が想定されています）。
(4)★3の取得費用
費用は大きく「①審査・評価にかかる費用」と「②対策の導入・運用にかかる費用」に分かれます。
| 費用の種類 | 金額の目安 | 備考 |
|---|---|---|
| ① 審査・評価の費用 | 無料 ～ 数万円程度 | 制度自体への申請は基本的に無料（または少額）の予定。ただし、「専門家による確認」を外部のコンサルタントやベンダーに単発で依頼する場合、数万円程度の費用が発生する可能性があります。 |
| ② 対策の導入・運用費 | 月額 数千円 ～ 数万円（※企業規模による） | まだ対策が不十分な場合、ツールやサービスの導入費がかかります。 |
(5)JC-STARとの違い
どちらも★で評価するが、違いは、「何を評価するのか（対象）」。
| SCS評価制度 | 「企業（組織）」全体のセキュリティ対策体制を評価する制度 |
|---|---|
| JC-STAR | ルーターやWebカメラなどの「IoT製品（モノ）」のセキュリティ性能を評価する制度 |
