米国 NIST IR 8320E（初期ドラフト）ハードウェア支援型セキュリティ：クラウドワークロードにおけるデータの機密コンピューティング

こんにちは、丸山満彦です。

NISTが、 IR 8320E（初期ドラフト）ハードウェア支援型セキュリティ：クラウドワークロードにおけるデータの機密コンピューティングが公表され、意見募集がされています。

この文書は、クラウド環境においてAIワークロードが処理する機密データやAIモデル自体を、ハードウェアベースの「機密コンピューティング（Confidential Computing）」技術を用いて保護するための実践的な技術ガイドということのようです。。。

従来のクラウドセキュリティでは、ディスクに保存されている時（保存時）やネットワークを流れている時（転送時）のデータは暗号化されているが、AIが計算を行うためにCPUがデータを読み込む「使用中（In Use）」の瞬間、メモリ上では一度復号（平文化）される必要がある。

この状況では、クラウド事業者の特権管理者や、OS・ハイパーバイザーの脆弱性を突いた攻撃者、同じサーバーを使う他のテナントからデータが覗き見られるリスクが残る。

ということで、OSすら入れないハードウェアレベルで物理的な隔離空間」（CPU内部に作られる信頼実行環境（TEE：Trusted Execution Environment） ）をCPUの中に作成するということで解決できる...ただ、TEEが本物か、改ざんされていない安全な状況であるか、などを確認する必要もありますよね...

このシリーズのIR 8320Cは2022年にドラフトだしたまま、IR 8320Dは2023年にドラフトをだしたまま、最終化されていないです。。。

● NIST - ITL

・2026.05.29 NIST IR 8320E (Initial Public Draft) Hardware-Enabled Security: Confidential Computing of Data in Cloud Workloads

NIST IR 8320E (Initial Public Draft) Hardware-Enabled Security: Confidential Computing of Data in Cloud Workloads	NIST IR 8320E（初期ドラフト）ハードウェア支援型セキュリティ：クラウドワークロードにおけるデータの機密コンピューティング
Announcement	通知
The National Cybersecurity Center of Excellence (NCCoE) invites public comments NIST Interagency Report (NIST IR) 8320E ipd (initial public draft), Hardware-Enabled Security: Confidential Computing of Data in Cloud Workloads. This is the latest in a series of reports on hardware-enabled security techniques and technologies.	国立サイバーセキュリティ・センター・オブ・エクセレンス（NCCoE）は、NIST省庁間報告書（NIST IR）8320E ipd（初期ドラフト）『ハードウェア支援型セキュリティ：クラウドワークロードにおけるデータの機密コンピューティング』について、一般からのコメントを募集している。これは、ハードウェア支援型セキュリティの手法および技術に関する一連の報告書の最新版である。
Confidential computing addresses data security and privacy concerns for organizations that move sensitive workloads to the cloud. It is a critical advancement that enables the encryption of data while it is being processed in memory, extending encryption coverage to data in active use. As cloud adoption continues to grow, confidential computing will play a pivotal role in improving security and privacy in cloud environments.	機密コンピューティングは、機密性の高いワークロードをクラウドに移行する組織におけるデータセキュリティおよびプライバシーの懸念に対処するものである。これは、メモリ内で処理中のデータを暗号化し、暗号化の対象をアクティブに使用中のデータにまで拡大することを可能にする重要な進歩である。クラウドの導入が拡大し続ける中、機密コンピューティングはクラウド環境におけるセキュリティとプライバシーの改善において極めて重要な役割を果たすことになる。
IR 8320E describes an example approach to protecting data being acted upon by artificial intelligence workloads on cloud infrastructures so that the datasets are protected from malware, data theft, and other security-related vulnerabilities. This report is intended to be a blueprint that the general security community can use to validate and utilize the described implementation.	IR 8320Eでは、クラウドインフラ上で人工知能（AI）ワークロードによって処理されるデータを防御し、データセットをマルウェア、データ盗難、およびその他のセキュリティ関連の脆弱性から守るためのアプローチ例を記述している。本報告書は、セキュリティコミュニティ全体が、記述された実装の妥当性確認および活用を行うための青写真となることを意図している。
The public comment period for this draft is open through July 13, 2026. See the publication details for a copy of the draft and instructions for submitting comments. You can also contact the authors at hwsec@nist.gov.	本ドラフトに対するパブリックコメントの受付期間は、2026年7月13日までである。ドラフトのコピーおよびコメント提出方法については、出版物の詳細を参照のこと。また、hwsec@nist.gov 宛てに著者に連絡することも可能である。
Abstract	概要
Confidential computing addresses data security and privacy concerns for organizations that move sensitive workloads to the cloud. It is a critical advancement that enables the encryption of data both while it is being processed in memory and in active use. As cloud adoption continues to grow, confidential computing will play a pivotal role in improving security and privacy in cloud environments. This report describes an effective approach to protecting data being acted upon by artificial intelligence workloads on cloud infrastructures so that the datasets are protected from malware, data theft, and other security-related vulnerabilities.	コンフィデンシャル・コンピューティングは、機密性の高いワークロードをクラウドに移行する組織におけるデータセキュリティおよびプライバシーの懸念に対処するものである。これは、メモリ内で処理されている間およびアクティブに使用されている間のデータの両方を暗号化することを可能にする、極めて重要な進歩である。クラウドの導入が進むにつれ、機密コンピューティングはクラウド環境におけるセキュリティとプライバシーの改善において極めて重要な役割を果たすことになる。本レポートでは、クラウドインフラ上で人工知能（AI）ワークロードによって処理されるデータを防御し、データセットをマルウェア、データ盗難、その他のセキュリティ関連の脆弱性から守るための効果的なアプローチについて説明する。

・[PDF]

関係文書

Release Date	Series	Number	Title	タイトル	Status
			Hardware-Enabled Security :	ハードウェアによるセキュリティ：
2026.05.29	IR	8320E	Confidential Computing of Data in Cloud Workloads	クラウドワークロードにおけるデータの機密コンピューティング	Draft
2023.02.23	IR	8320D	Hardware-Based Confidential Computing	ハードウェアベースの機密コンピューティング	Draft
2022.05.04	IR	8320	Enabling a Layered Approach to Platform Security for Cloud and Edge Computing Use Cases	クラウドおよびエッジコンピューティングのユースケースに向けた、プラットフォームセキュリティの多層的アプローチの実現	Final
2022.04.20	IR	8320B	Policy-Based Governance in Trusted Container Platforms	信頼できるコンテナプラットフォームにおけるポリシーベースのガバナンス	Final
2022.04.20	IR	8320C	Machine Identity Management and Protection	マシンIDの管理と保護	Draft
2021.10.27	IR	8320B	Policy Based Governance in Trusted Container Platforms	信頼されたコンテナプラットフォームにおけるポリシーベースのガバナンス	Draft (Obsolete)
2021.10.27	IR	8320	Enabling a Layered Approach to Platform Security for Cloud and Edge Computing Use Cases	クラウドおよびエッジコンピューティングのユースケースに向けたプラットフォームセキュリティの多層的アプローチの実現	Draft (Obsolete)
2021.06.17	IR	8320A	Container Platform Security Prototype	コンテナプラットフォームセキュリティのプロトタイプ	Final
2021.05.27	IR	8320	Enabling a Layered Approach to Platform Security for Cloud and Edge Computing Use Cases	クラウドおよびエッジコンピューティングのユースケースに向けたプラットフォームセキュリティの多層的アプローチの実現	Draft (Obsolete)
2020.12.07	IR	8320A	Container Platform Security Prototype	コンテナプラットフォームセキュリティのプロトタイプ	Draft (Obsolete)

---

● まるちゃんの情報セキュリティ気まぐれ日記

・2023.02.24 NISTIR 8320D（ドラフト）ハードウェア対応セキュリティ：ハードウェアベース・コンフィデンシャル・コンピューティング

・2022.05.07 NISTIR 8320 ハードウェア対応セキュリティ：クラウドおよびエッジ・コンピューティングのユースケースにおけるプラットフォーム・セキュリティへの階層型アプローチの実現

・2022.04.21 NISTIR 8320C (ドラフト) ハードウェア対応セキュリティ：マシン・アイデンティティの管理と保護

・2022.04.21 NISTIR 8320B ハードウェア対応セキュリティ：信頼できるコンテナプラットフォームにおけるポリシーベースのガバナンス

・2021.10.29 NISTIR 8320 (Draft) ハードウェア対応セキュリティ：クラウドおよびエッジ・コンピューティングのユースケースにおけるプラットフォーム・セキュリティへの階層型アプローチの実現（第二次ドラフト）

・2021.10.29 NISTIR 8320B （ドラフト） ハードウェア対応のセキュリティ：信頼できるコンテナプラットフォームにおけるポリシーベースのガバナンス

・2021.06.19 NISTIR 8320A ハードウェア対応セキュリティ：コンテナ・プラットフォーム・セキュリティ・プロトタイプ

・2021.05.28 NISTIR 8320 (Draft) ハードウェア対応セキュリティ：クラウドおよびエッジ・コンピューティングのユースケースにおけるプラットフォーム・セキュリティへの階層型アプローチの実現

・2020.12.13 NISTIR 8320A　マルチテナントクラウド環境におけるコンテナを保護するためのハードウェア対応のセキュリティ技術とその技術に基づくアプローチに関する文書の意見募集

欧州 ENISA NIS360 NIS2 -重要度の高いNISセクターにおけるサイバーセキュリティの成熟度と重大度に関する最新の知見-

こんにちは、丸山満彦です。

ENISAが、NIS360報告書を公表しています。NIS360報告書は、NIS2指令の附属書Iで特定された重要度の高い全セクターについて、サイバーセキュリティの成熟度と重要度を評価した報告書で、今年の報告書で3回目のとなりますね。

ポイント...

• AIの急速な進展：攻撃側・防御側の双方に影響。攻撃側の技術普及が先行し、検知・対応の時間枠短縮が求められる。
  
  
• サプライチェーン・第三者リスク：組織の信頼関係が連鎖し、単一の侵害がセクター全体に波及するシステムリスクが増大。
  
  
• 地政学的変動の激化：制裁、輸出規制、地域不安定化がサイバーセキュリティに直接影響。国家主体の攻撃やデジタル主権への関心が高まっている。

どこも同じような話になりますね...

● ENISA

・2026.05.28 ENISA NIS360

・[PDF] ENISA NIS360 

目次...

Executive Summary	エグゼクティブサマリー
1.  Cybersecurity maturity overview of NIS2 sectors of high criticality	1.  重要度の高いNIS2セクターにおけるサイバーセキュリティ成熟度の概要
1.1  Assessing progress in maturity and criticality of sectors	1.1  セクターの成熟度および重要度に関する進捗状況の評価
1.2  Cross-sector progress overview	1.2  セクター横断的な進捗状況の概要
1.3  Emerging context	1.3  新たな動向
2.  Sector-by-sector cybersecurity maturity overview	2.  セクター別のサイバーセキュリティ成熟度概要
2.1  Energy	2.1  エネルギー
2.2  Digital infrastructure	2.2  デジタルインフラ
2.3  Transport	2.3  運輸
2.4  Finance	2.4  金融
2.5  Health	2.5  医療
2.6 ICT service management	2.6 ICTサービス管理
2.7 Public administrations	2.7 行政
2.8  Space	2.8  宇宙
2.9  Drinking and Waste water	2.9  飲料水・廃水
A  Annex: Overview of maturity dimensions per sector	A  附属書：セクターごとの成熟度次元の概要
A.1  Energy	A.1  エネルギー
A.2  Digital Infrastructure	A.2  デジタルインフラ
A.3  Transport	A.3  運輸
A.4  Finance	A.4  金融
A.5  Health	A.5  医療
A.6  ICT service management	A.6  ICTサービス管理
A.7  Public administrations	A.7  行政
A.8  Space	A.8  宇宙
A.9  Drinking water and Waste water	A.9  飲料水・廃水
B  Annex: NIS360 methodology	B  附属書：NIS360の方法論
C  Annex: Abbreviations and key legislation	C  附属書：略語および主要な法規制

エグゼクティブサマリー...

Executive Summary	エグゼクティブサマリー
This edition of the ENISA NIS360 report is the third to assess the cybersecurity maturity and criticality of all sectors of high criticality as identified under Annex I of the NIS2 directive. The assessment covers the entire ecosystem of a sector, where each sector is understood to comprise relevant actors (i.e., national authorities, entities, EU bodies) and applicable rules (EU legislation). The assessment relies on a structured methodology developed and continuously refined by ENISA. This methodology, takes into account the structural and gradually evolving nature of sectoral cybersecurity maturity and criticality, and builds on evidence gathered over time from: organisations operating in sectors that are within the scope of NIS2 and national authorities supervising those organisations, but also EU-level data, to reflect our latest evidence-informed understanding of where each sector stands.	本版ENISA NIS360報告書は、NIS2指令の附属書Iに基づき特定された、重要度の高い全セクターのサイバーセキュリティ成熟度および重要度を評価する3回目の報告書である。本評価はセクター全体のエコシステムを対象としており、各セクターは関連する主体（すなわち、国家当局、組織、EU機関）および適用される規則（EU法）から構成されると理解される。本評価は、ENISAが開発し継続的に改良を重ねてきた体系的な方法論に基づいている。この方法論は、セクターごとのサイバーセキュリティの成熟度および重要性の構造的かつ漸進的に変化する性質を考慮に入れ、NIS2の適用範囲内にあるセクターで事業を行う組織や、それらを監督する国家当局から長期間にわたり収集された証拠に加え、EUレベルのデータも活用することで、各セクターの現状に関する最新の証拠に基づく理解を反映している。
Since the previous edition of this report, cybersecurity maturity across sectors of high criticality in the EU, has been steadily improving as organisations respond to evolving policy requirements and cyber threats they face. Banking, electricity and telecommunications remain the most mature and critical sectors, while three sectors, trust services, aviation, and financial market infrastructures (FMIs) moved into the high maturity band. Four sectors strengthened their maturity within the moderate band: gas, road, maritime, and health. Several compounding factors contribute to these improvements, including developments in cybersecurity legislation, increased political attention, but also progress across specific maturity dimensions assessed. Overall, maturity is steadily improving across critical sectors, but progress still remains uneven both across and within sectors. A number of factors contribute to these variations including skill shortages, sector-specific characteristics and even organisational size.	本報告書の前回版以降、EU内の重要度の高いセクターにおけるサイバーセキュリティの成熟度は、組織が進化する政策要件や直面するサイバー脅威に対応するにつれ、着実に向上している。銀行、電力、通信は依然として最も成熟度が高く重要なセクターである一方、信頼サービス、航空、金融市場インフラ（FMI）の3つのセクターは、高い成熟度帯へと移行した。ガス、道路、海運、医療の4セクターは、中程度の成熟度帯において成熟度を強化した。こうした改善には、サイバーセキュリティ関連法規の整備や政治的関心の高まりに加え、評価対象となった特定の成熟度指標における進展など、複数の複合的な要因が寄与している。全体として、重要セクター全体で成熟度は着実に向上しているが、セクター間およびセクター内においても進捗には依然としてばらつきが見られる。こうした差異には、スキル不足、セクター固有の特性、さらには組織規模など、多くの要因が影響している。
Sector criticality, under the ENISA NIS360, is assessed based on factors such as its level of digitalisation, the socioeconomic impact of incidents affecting it, and its time-criticality i.e. how quickly the impact of incidents affecting it can be felt on the ground considering interconnections with other sectors. As these factors typically change gradually, criticality scores tend to remain relatively stable from year to year. For instance, sectors such as banking, electricity, aviation, space, and digital infrastructure (including telecommunications, cloud, and data centres) remain the most critical. Nevertheless, in this NIS360 edition, limited adjustments were introduced to the criticality dimension of certain sectors to better reflect the evolving socio-economic conditions and threat landscape. In particular, the criticality score for the space and railway sectors has been revised to reflect changes in how society or other sectors depend on them, and the extent to which they are being targeted.	ENISAのNIS360におけるセクターの重要度は、デジタル化のレベル、当該セクターに影響を及ぼすインシデントの社会経済的影響、および時間的緊急性（すなわち、他セクターとの相互接続性を考慮した際、当該セクターに影響を及ぼすインシデントの影響が現場でどの程度迅速に感じられるか）といった要因に基づいて評価される。これらの要因は通常、徐々に変化するため、重要度スコアは年ごとに比較的安定している傾向にある。例えば、銀行、電力、航空、宇宙、およびデジタルインフラ（通信、クラウド、データセンターを含む）といったセクターは、依然として最も重要度が高い。しかしながら、今回のNIS360版では、変化する社会経済状況や脅威の状況をより適切に反映させるため、特定のセクターの重要度評価に限定的な調整が加えられた。特に、宇宙および鉄道セクターの重要度スコアは、社会や他のセクターがこれらに依存する状況の変化、および標的とされる度合いを反映するよう改訂された。
Combining and jointly interpreting the criticality and maturity dimensions helps identify mismatches between the two and helps define the risk zone. The risk zone includes sectors with lower-thanaverage maturity and criticality that exceeds their maturity. Its composition changes over time as overall maturity improves across sectors. This is one of the reasons why three sectors previously at the risk zone boundary - rail, drinking water, and waste water are now within the risk zone. The positive development is that the gas sector has started moving out of the risk zone. This shift is driven by improved information sharing, stronger collaboration, and better implementation of risk management measures that are to higher maturity.	重大度と成熟度の両次元を組み合わせて解釈することで、両者の不一致を特定し、リスクゾーンを定義するのに役立つ。リスクゾーンには、平均以下の成熟度を持ち、かつその成熟度を上回る重要度を有するセクターが含まれる。その構成は、セクター全体で成熟度が向上するにつれて時間とともに変化する。これが、以前はリスクゾーンの境界線上にあった鉄道、飲料水・廃水の3つのセクターが、現在ではリスクゾーン内に位置している理由の一つである。前向きな進展として、ガスセクターがリスクゾーンから脱却し始めていることが挙げられる。この変化は、情報共有の改善、連携の強化、そしてより高い成熟度に向けたリスク管理措置の適切な実施によって推進されている。
It is expected that, as factors such as cybersecurity legislation, perceived cyber risk and threat exposure, past experience, interdependencies, and ecosystem expectations continue to act as key drivers for both cybersecurity investment and preparedness efforts, more sectors will be moving out of the risk zone.	サイバーセキュリティ関連法規、認識されるサイバーリスクや脅威への曝露、過去の経験、相互依存関係、エコシステムの期待といった要因が、サイバーセキュリティへの投資と準備態勢の両方における主要な推進力として引き続き作用するにつれ、より多くのセクターがリスクゾーンから脱却していくものと予想される。

成熟度と重大度のマトリックス...

矢印で前回からの変化を示しています...

どの分野がやばいという図...

---

● まるちゃんの情報セキュリティ気まぐれ日記

昨年の...

・2025.03.09 欧州 ENISA NIS360 2024 (2025.03.05) 重要インフラのセキュリティの状況...

脅威...

・2025.11.09 欧州 ENISA セクター別脅威状況 - 公共行政 (2025.11.06)

・2025.10.05 ENISA 脅威状況 2025 (2025.10.01)

・2025.08.07 ENISA サイバーセキュリティ脅威状況の評価方法 (2025.08.01)

・2025.03.30 欧州ENISA 宇宙脅威状況 2025 (2025.03.26)

・2025.02.23 欧州 ENISA 脅威状況 (2023.01-2024.06)：金融セクター

・2024.09.26 ENISA 脅威状況2024

・2023.12.09 ENISA 戦争と地政学がDoS攻撃に拍車をかけている - DoS攻撃に関する脅威状況

・2023.10.26 ENISA 脅威状況2023 - AIによる情報操作の台頭でEUの選挙がリスクにさらされる

・2023.09.20 ENISA 2030の脅威の展望 (2023.09.13)

・2023.03.22 ENISA 輸送セクターのサイバー脅威状況

・2022.12.14 ENISA 外国人による情報操作と干渉（FIMI）とサイバーセキュリティ - 脅威状況

・2022.11.08 ENISA 脅威状況 2022：不安定な地政学がサイバーセキュリティ脅威状況の傾向を揺るがす

・2022.08.01 ENISA ランサムウェアについての脅威状況

・2022.07.29 ENISA サイバーセキュリティ脅威ランドスケープの方法論 (2022.07.06) ENISA流サイバーインテリジェンスの方法論?

・2020.12.18 ENISA AI サイバーセキュリティのチャレンジ - AI脅威状況報告を公表していますね。

・2020.12.15 ENISA 5Gネットワークの脅威状況報告書のアップデート

・2020.10.21 ENISA Threat Landscape 2020 : サイバー脅威トップ15 サイバー攻撃はより高度化し、標的化が進み、対象も広範囲になり、検知もされにくくなる。。。

投資...

・2025.12.21 欧州 ENISA NIS投資報告書 2025 (2025.12.08)

・2024.11.25 欧州 ENISA NIS投資報告書 2024

・2023.11.18 ENISA EUにおけるサイバーセキュリティ投資 2023

・2022.11.25 ENISA EUにおけるサイバーセキュリティ投資 2022

・2021.11.26 ENISA NIS投資動向報告書2021 at 2021.11.17

欧州 ETSI TS 119 432 V1.3.1 (2026-03) 技術仕様 電子署名および信頼インフラ（ESI）；リモートデジタル署名作成のためのプロトコル

こんにちは、丸山満彦です。

リモート署名を安全に、相互運用可能に、規制準拠で実装するための技術仕様。署名鍵をリモートサーバで管理しつつ、署名者の単独制御と法的有効性を担保した電子署名を実現するための、実装者・サービス事業者向けプロトコル標準という感じでしょうか？

クラウド環境など分散システムにおいて、eIDAS規則が求める「適格電子署名（QES）」の技術的要件を満たすリモート署名作成プロセスを、標準化されたAPI・認証フロー・セキュリティ要件として規定していますね...

● ETSI

・2026.03 ETSI TS 119 432 V1.3.1 (2026-03) TECHNICAL SPECIFICATION Electronic Signatures and Trust Infrastructures (ESI); Protocols for remote digital signature creation 

目次...

Executive summary	エグゼクティブサマリー
Introduction	序論
1 Scope	1 適用範囲
2 References	2 参考文献
2.1 Normative references	2.1 規範的参考文献
2.2 Informative references	2.2 参考参考文献
3 Definition of terms, symbols and abbreviations	3 用語、記号および略語の定義
3.1 Terms	3.1 用語
3.2 Symbols	3.2 記号
3.3 Abbreviations	3.3 略語
4 Signature creation process, service decomposition	4 署名作成プロセス、サービスの分解
4.1 Signature creation process steps and data elements	4.1 署名作成プロセスの手順とデータ要素
4.2 Service main components and interfaces	4.2 サービスの主要構成要素とインターフェース
4.3 Signature Creation Application	4.3 署名作成アプリケーション
4.3.1 Signer's document and hashing	4.3.1 署名者の文書とハッシュ化
4.3.2 DTBS composition and formatting	4.3.2 DTBSの構成とフォーマット
4.3.3 DTBS preparation	4.3.3 DTBSの準備
4.3.4 SDO composer	4.3.4 SDOコンポーザー
4.4 Server Signing Application	4.4 サーバー署名アプリケーション
4.4.1 Signature creation	4.4.1 署名の作成
5 Authentication and authorization	5 認証と認可
5.1 Introduction	5.1 序論
5.2 Service authorization	5.2 サービスの認可
5.2.1 Overview	5.2.1 概要
5.2.2 HTTP Basic Authentication and HTTP Digest Authentication	5.2.2 HTTP ベーシック認証および HTTP ダイジェスト認証
5.2.3 OAuth 2.0	5.2.3 OAuth 2.0
5.2.4 Other authentication mechanisms	5.2.4 その他の認証メカニズム
5.3 Signatures creation authorization	5.3 署名作成の認可
5.3.1 Overview	5.3.1 概要
5.3.2 Creating a remote signature with a credential protected by signature creation service-managed authorization	5.3.2 署名作成サービス管理認可によって保護された認証情報を使用したリモート署名の作成
5.3.3 Create a remote signature with a credential protected by OAuth2	5.3.3 OAuth2 によって保護された認証情報を使用したリモート署名の作成
5.4 Credential creation authorization	5.4 資格情報の作成に関する認可
5.5 Credential deletion authorization	5.5 資格情報の削除に関する認可
6 Architectures and use cases for server signing	6 サーバー署名のためのアーキテクチャとユースケース
6.1 Introduction	6.1 序論
6.2 Architectures for creating remote signatures with a credential protected by signature creation service managed authorization	6.2 署名作成サービスによる管理認可で保護された資格情報を使用したリモート署名の作成のためのアーキテクチャ
6.3 Architectures for creating remote signatures with a credential protected by OAuth2	6.3 OAuth2で保護された資格情報を使用したリモート署名の作成のためのアーキテクチャ
6.4 Architectures for creating remote signatures using the European Digital Identity Wallet	6.4 欧州デジタルIDウォレットを使用したリモート署名の作成アーキテクチャ
6.4.1 Overview	6.4.1 概要
6.4.2 EUDIW as authentication and authorization layer for creating remote signatures	6.4.2 リモート署名作成のための認証および認可レイヤーとしてのEUDIW
6.4.3 EUDIW participating in the signature creation process	6.4.3 署名作成プロセスに参加するEUDIW
6.4.4 EUDIW registration and authentication to authorization servers	6.4.4 認可サーバーへのEUDIWの登録および認証
6.4.5 DA / SCA registration and authentication to authorization servers	6.4.5 認可サーバーへのDA / SCAの登録および認証
7 Remote signatures creation service API	7 リモート署名作成サービスAPI
7.1 Introduction	7.1 序論
7.2 Service information API	7.2 サービス情報 API
7.2.1 Description	7.2.1 説明
7.2.2 Request message	7.2.2 リクエストメッセージ
7.2.3 Response message	7.2.3 レスポンスメッセージ
7.3 Credentials list API	7.3 認証情報リスト API
7.3.1 Description	7.3.1 説明
7.3.2 Request message	7.3.2 リクエストメッセージ
7.3.3 Response message	7.3.3 応答メッセージ
7.4 Credentials info API	7.4 認証情報 API
7.4.1 Description	7.4.1 概要
7.4.2 Request message	7.4.2 リクエストメッセージ
7.4.3 Response message	7.4.3 応答メッセージ
7.5 Hash(es) signing API	7.5 ハッシュ署名 API
7.5.1 Description	7.5.1 概要
7.5.2 Request message	7.5.2 リクエストメッセージ
7.5.3 Response message	7.5.3 応答メッセージ
7.6 Document(s) signing API	7.6 文書署名 API
7.6.1 Description	7.6.1 概要
7.6.2 Request message	7.6.2 要求メッセージ
7.6.3 Response message	7.6.3 応答メッセージ
7.7 Signature(s) creation polling API	7.7 署名作成ポーリング API
7.7.1 Description	7.7.1 説明
7.7.2 Request message	7.7.2 要求メッセージ
7.7.3 Response message	7.7.3 応答メッセージ
7.8 Credentials creation API	7.8 認証情報作成 API
7.8.1 Description	7.8.1 説明
7.8.2 Request message	7.8.2 要求メッセージ
7.8.3 Response message	7.8.3 応答メッセージ
7.8.4 Subject distinguished name of the new credential certificate	7.8.4 新しい認証情報証明書のサブジェクト識別名
7.9 Credentials deletion API	7.9 認証情報の削除 API
7.9.1 Description	7.9.1 説明
7.9.2 Request message	7.9.2 リクエストメッセージ
7.9.3 Response message	7.9.3 レスポンスメッセージ
8 Remote signatures creation service API based on OASIS DSS-X	8 OASIS DSS-X に基づくリモート署名作成サービス API
8.1 Introduction and General Provisions	8.1 序論および一般規定
8.2 Service information API	8.2 サービス情報 API
8.3 Credentials list API	8.3 認証情報リスト API
8.4 Credentials info API	8.4 認証情報 API
8.5 Hash(es) signing API	8.5 ハッシュ署名 API
8.6 Document(s) signing API	8.6 文書署名 API
8.7 Signature(s) creation polling API	8.7 署名作成ポーリング API
8.8 Credentials creation API	8.8 認証情報作成 API
Annex A (normative): OpenID4VP EUDIW-centric signing flow profile	附属書 A（規範的）：OpenID4VP EUDIW 中心の署名フロープロファイル
A.1 Overview	A.1 概要
A.2 Roles & Standards	A.2 役割と標準
A.3 Profile scope & transport	A.3 プロファイルの範囲と転送
A.4 Profile identifiers	A.4 プロファイル識別子
A.5 High-level interaction models	A.5 高レベルな相互作用モデル
A.5.1 EUDIW: RP ↔ EUDIW, EUDIW ↔ QTSP	A.5.1 EUDIW: RP ↔ EUDIW、EUDIW ↔ QTSP
A.5.2 QTSP: QTSP ↔ EUDIW	A.5.2 QTSP: QTSP ↔ EUDIW
A.6 Request construction (RP → EUDIW)	A.6 リクエストの構築 (RP → EUDIW)
A.6.1 Introduction	A.6.1 序論
A.6.2 Required parameters (OpenID4VP layer)	A.6.2 必須パラメータ（OpenID4VP レイヤー）
A.6.3 dcql_query (selecting an acceptable signing certificate)	A.6.3 dcql_query（許容可能な署名証明書の選択）
A.6.4 transaction_data (the QES transaction)	A.6.4 transaction_data（QES トランザクション）
A.7 Response handling (EUDIW → RP)	A.7 応答処理（EUDIW → RP）
A.7.1 Inline (VP Token) - x509PresentationResponse	A.7.1 インライン（VP トークン） - x509PresentationResponse
A.7.2 Out of band (HTTP POST to responseURI)	A.7.2 アウトオブバンド（responseURI への HTTP POST）
A.7.3 EUDIW processing	A.7.3 EUDIW 処理
A.8 Transaction data processing & UX rendering (EUDIW)	A.8 トランザクションデータの処理および UX レンダリング（EUDIW）
A.9 Complementary approval flow	A.9 補完的な承認フロー
A.10 Security & privacy requirements	A.10 セキュリティおよびプライバシー要件
A.11 Conformance checklist (RP)	A.11 適合性チェックリスト（RP）
A.12 Examples	A.12 例
A.12.1 Authorization request (core parameters)	A.12.1 認可要求（コアパラメータ）
A.12.2 Example 'qesRequest' (transaction_data before base64url encoding)	A.12.2 「qesRequest」の例（base64url エンコード前の transaction_data）
A.12.3 VP Token (inline) - PAdES result	A.12.3 VP トークン（インライン） - PAdES 結果
A.12.4 Out of band POST to responseURI	A.12.4 responseURI へのアウトオブバンド POST
Annex B (normative): EUDIW QES creation approval profile	附属書 B（規範的）：EUDIW QES 作成認可プロファイル
B.1 Overview	B.1 概要
B.2 Roles and architecture	B.2 役割とアーキテクチャ
B.3 Signature authorization attestation	B.3 署名認可の証明
B.4 Profile scope & transport	B.4 プロファイルの範囲と転送
B.5 Profile identifiers	B.5 プロファイル識別子
B.6 Data model for approval	B.6 承認のためのデータモデル
B.6.1 Introduction	B.6.1 序論
B.6.2 qesApprovalRequest	B.6.2 qesApprovalRequest
B.6.3 Computing qesApproval (EUDIW)	B.6.3 qesApproval の計算 (EUDIW)
B.7 OpenID4VP request (QTSP → Wallet)	B.7 OpenID4VP リクエスト (QTSP → ウォレット)
B.8 EUDIW response (EUDIW → QTSP)	B.8 EUDIW レスポンス (EUDIW → QTSP)
B.8.1 VP Token / DC API response	B.8.1 VP トークン / DC API 応答
B.8.2 Using qesApproval at the AS/SCSP	B.8.2 AS/SCSP における qesApproval の使用
B.9 Processing & rendering requirements (EUDIW)	B.9 処理およびレンダリング要件 (EUDIW)
B.10 Security & privacy	B.10 セキュリティおよびプライバシー
B.11 Conformance checklist (SCSP)	B.11 適合性チェックリスト (SCSP)
B.12 Working sequence	B.12 動作シーケンス
Annex C (normative): Specific recommendations for qualified signatures and/or seals creation	附属書 C (規範的): 適格な署名および/またはシールの作成に関する具体的な推奨事項
C.1 Introduction	C.1 序論
C.2 Separation of Responsibilities	C.2 責任の分離
C.3 Authentication and Authorization Layer	C.3 認証および認可層
C.4 Signature Creation Service	C.4 署名作成サービス
C.5 Strong Binding Between Consent and DTBS	C.5 同意と DTBS 間の強力な結びつき
C.6 Use of FAPI 2.0 for EUDIW-Based Clients	C.6 EUDIW ベースのクライアントにおける FAPI 2.0 の使用
C.7 SCS API Security Recommendations	C.7 SCS API セキュリティに関する推奨事項
Annex D (informative): Change history	附属書 D（参考）：変更履歴
History	履歴

経済産業省 国家サイバー統括室 サイバーインフラ事業者に求められる役割等に関するガイドライン (2026.03.31)

こんにちは、丸山満彦です。

経済産業省、国家サイバー統括室が、サイバーインフラ事業者に求められる役割等に関するガイドラインを公表していますね...

ところで、「サイバーインフラ事業者」とは何か？ということになりますが...

本文の2ページ（5/131）に次のように記載されていますね...直接サービスを提供する事業者と当該情報・通信システム等のソフトウェアのライフサイクルとサプライチェーンに関わる事業者ということになっていますね...

---

...我が国のサイバーセキュリティ基本法第７条においてはサイバー関連事業者・情報システム等供給者3等の責務が規定されており、特に情報システム等供給者は、情報システム等の利用者によるサイバーセキュリティ確保に必要な支援を行う努力義務を負うこととされているところ、これらの事業者のうちソフトウェアの設計を含めた開発、供給、運用において一定の社会インフラの機能を提供している事業者（以下、「サイバーインフラ事業者4」という。）...

<脚注>

3 サイバー関連事業者とは、インターネットその他の高度情報通信ネットワークの整備、情報通信技術の活用又はサイバーセキュリティに関する事業を行う者である。情報システム等供給者とは、情報システム若しくはその一部を構成する電子計算機若しくはプログラム、情報通信ネットワーク又は電磁的記録媒体の供給者である。

4 サイバーインフラ事業者とは、サイバーセキュリティ基本法において、サイバー関連事業者（インターネットその他の高度情報通信ネットワークの整備、情報通信技術の活用又はサイバーセキュリティに関する事業を行う者）等の責務が規定されている事業者のうち、政府機関等及び重要インフラ事業者を始め広く社会で活用される情報・通信システム、ソフトウェア製品及び ICT サービスを開発し提供する事業者並びに当該情報・通信システム等のソフトウェアのライフサイクルとサプライチェーンに関わる事業者をいう。

---

ちなみに、サイバーセキュリティ基本法(e-GOv)の第7条は、次のようになっています...

---

（サイバー関連事業者その他の事業者の責務）

第七条　サイバー関連事業者（インターネットその他の高度情報通信ネットワークの整備、情報通信技術の活用又はサイバーセキュリティに関する事業を行う者をいう。以下同じ。）その他の事業者は、基本理念にのっとり、その事業活動に関し、自主的かつ積極的にサイバーセキュリティの確保に努めるとともに、国又は地方公共団体が実施するサイバーセキュリティに関する施策に協力するよう努めるものとする。

２　情報システム若しくはその一部を構成する電子計算機若しくはプログラム、情報通信ネットワーク又は電磁的記録媒体（以下この項において「情報システム等」という。）の供給者は、サイバーセキュリティに対する脅威により自らが供給した情報システム等に被害が生ずることを防ぐため、情報システム等の利用者がその安全性及び信頼性の確保のために講ずる措置に配慮した設計及び開発、適切な維持管理に必要な情報の継続的な提供その他の情報システム等の利用者がサイバーセキュリティの確保のために講ずる措置を支援する取組を行うよう努めるものとする。

---

で、そのサイバーインフラ事業者に求められる役割等に関するガイドライン 全体概要は次の通りになるという話です...

● 経済産業省

・2026.03.31 「サイバーインフラ事業者に求められる役割等に関するガイドライン」の日本語版・英語版を策定しました

• [PDF] サイバーインフラ事業者に求められる役割等に関するガイドライン【日本語版】

目次...

---

1. 総論
1.1. 背景と目的
1.2. ガイドラインの位置付け
1.3. 適用対象
1.4. 役割分担の考え方
1.5. 代表的なユースケース例

2. サイバーインフラ事業者と顧客の責務と役割分担
2.1. 責務と役割分担の考え方
2.2. 責務

3. 責務を果たすための要求事項
3.1. 要求事項の全体像
3.2. 要求事項
（１）セキュアな設計・開発・供給・運用
（２）ライフサイクル管理、透明性の確保
（３）残続する脆弱性の速やかな対処
（４）人材・プロセス・技術の整備
（５）サイバーインフラ事業者・ステークホルダー間の関係強化
（６）顧客によるリスク管理とセキュアなソフトウェアの調達・運用

4. 要求事項の利活用
4.1. 要求事項の要求パッケージ化
4.2. 役割分担に応じた要求事項の適用に関する注意点

5. 参考情報
5.1. 要求事項チェックリスト
5.2. セキュリティインシデントと要求事項との対応関係例
5.3. システムライフサイクルにおける脅威と要求事項の対応関係
5.4. 要求事項に対する取組例
（１）セキュアな設計・開発・供給・運用
（２）ライフサイクル管理、透明性の確保
（３）残続する脆弱性の速やかな対処
（４）人材・プロセス・技術の整備
（５）サイバーインフラ事業者・ステークホルダー間の関係強化
（６）顧客によるリスク管理とセキュアなソフトウェアの調達・運用
5.5. 統一基準群と本ガイドラインとの関係
5.6. 重要インフラのサイバーセキュリティに係る安全基準等策定指針と本ガイドラインとの関係
5.7. サイバー対処能力強化法と本ガイドラインとの関係
5.8. 参照情報
（１）参照情報のリスト
（２）他の標準・ガイドライン等との関係
（３）NIST SP800-218 との対応関係
（４）NSA Software Supply Chain Guidance の 3 文書との対応関係
（５）CISA Secure-by-Design- Shifting the Balance of Cybersecurity Risk との対応関係
（６）EU Cyber Resilience Act. ANNEX I/II との対応関係
（７）その他の文書との対応関係
5.9. 用語

6. 本ガイドラインの検討体制

---

• [XLSX] サイバーインフラ事業者に求められる役割等に関するガイドライン 評価チェックリスト等【日本語、Excelマクロ機能付き版】
• [XLSX] サイバーインフラ事業者に求められる役割等に関するガイドライン 評価チェックリスト等【日本語、Excelマクロ機能なし版】
• [PDF] サイバーインフラ事業者に求められる役割等に関するガイドライン 概要資料【日本語版】

● 国家サイバー統括室

・2026.03.31 「サイバーインフラ事業者に求められる役割等に関するガイドライン」の日本語版・英語版を策定しました

検討委員のメンバーには、土居先生が座長、稲垣先生、淵上さん、坂東さん、古田さんなどが参画していますね....

総務省 地方公共団体における情報セキュリティポリシーに関するガイドライン（令和8l年3月版）

こんにちは、丸山満彦です。

総務省の地方公共団体における情報セキュリティポリシーに関するガイドラインの改定等に係る検討会が、・「地方公共団体における情報セキュリティポリシーに関するガイドライン」と「地方公共団体における情報セキュリティ監査に関するガイドライン」を改訂していますね...

ガイドライン改定（令和8年3月）のポイントは、

---

1.地方自治法改正に伴う対応

令和６年の地方自治法の改正に伴い、大臣指針案が令和７年４月１日付で発出されており、ガイドライン第1編総則において記載内容が重複する箇所等について削除等を実施。

2. 機器の廃棄・データ消去について

「政府機関等の対策基準策定のためのガイドライン」を参考にマイナンバー利用事務系の領域において住民情報を保存する記録媒体における機器の物理的破壊について、機器のリユース（再利用）が困難になることやコスト等の課題があることから、物理破壊以外の方法を追加。また、データ消去作業の職員の立ち合いを行う範囲を明確化。

3. USBメモリ等の利用におけるリスクへの対処

「政府機関等の対策基準策定のためのガイドライン」と総務省のガイドラインを整合した上で不足している対策について追記。

４.その他

「政府機関等の対策基準策定のためのガイドラインの一部改定（令和７年９月）」を踏まえ、DNS設定情報を悪用する攻撃等について追記。

※ 上記2・3については第3編 対策基準（解説）を改定。
※ 地方公共団体における情報セキュリティ監査に関するガイドラインについては時点更新と形式修正のみ

---

・[PDF] 「地方公共団体における情報セキュリティポリシーに関するガイドライン」（令和8年3月27日改定）

・[PDF] 「地方公共団体における情報セキュリティ監査に関するガイドライン」（令和8年3月27日改定）

暗号消去についても導入されていますよね...第20回の検討会の資料をみると変更点がよりわかりやすいかもしれません。

・2026.01.14 地方公共団体における情報セキュリティポリシーに関するガイドラインの改定等に係る検討会（第20回）

・・[PDF] 資料1　電磁的記録媒体を使用しないデータ連携について

・・[PDF] 資料2　機器の廃棄・データ消去について

・・[PDF] 資料3　今年度のセキュリティポリシーガイドラインの改定内容について

改訂履歴はつぎのような感じですかね...

地方公共団体における情報セキュリティポリシーに関するガイドライン、

• 2001年；平成13年03月；策定
• 2006年；平成18年09月；全部改定；政府の情報セキュリティ政策会議は「第 1 次情報セキュリティ基本計画」を踏まえて改定
  
• 2010年；平成22年11月；一部改定；「第 2 次情報セキュリティ基本計画」等を踏まえて改定
  
• 2015年；平成27年03月；一部改定；マイナンバー法、サイバーセキュリティ基本法を踏まえて改定
• 2018年；平成30年03月；全部改定；平成27年の年金機構情報漏えい事案、三層対策
• 2020年；令和02年12月；一部改定；三層対策のパターンを増やすなど利便性とセキュリティのバランスの調整
• 2022年；令和04年03月；一部改定；政府統一基準の改訂、DX等を踏まえた改定
• 2023年；令和05年03月；一部改定；ガバメントクラウドの導入等を見据えて改定
  
• 2024年；令和06年10月；一部改定；Web会議利用、政府統一基準の改定を踏まえた改定
• 2025年；令和07年03月；一部改定；テレワーク、マイナンバー利用事務系への無線LAN接続等を踏まえた改定
• 2026年：令和08年03月：一部改訂：地方自治法法の改訂により、必要な措置を講じることを義務付け、暗号消去の導入等による改定
  
  

地方公共団体における情報セキュリティ監査に関するガイドライン

• 2003年；平成15年12月；策定
• 2007年；平成19年07月；全部改定；政府の情報セキュリティ政策会議は「第 1 次情報セキュリティ基本計画」を踏まえて改定
• 2010年；平成22年11月；一部改定；「第 2 次情報セキュリティ基本計画」等を踏まえて改定
• 2015年；平成27年03月；一部改定；マイナンバー法、サイバーセキュリティ基本法を踏まえて改定
• 2018年；平成30年09月；一部改定；政府統一基準、自治体情報セキュリティ対策検討チーム報告等を踏まえて改訂
• 2020年；令和02年12月；一部改訂；三層対策のパターンを増やすなどの対策の変化に応じて改訂
• 2022年；令和04年03月；一部改訂；政府統一基準の改訂、DX等を踏まえた改定

 初版からの積み重ねということもあり、どんどんページ数が増えていっている感じですよね...

地方自治体のサプライチェーンセキュリティも重要となってくるので、「サプライチェーン強化に向けたセキュリティ対策評価制度に関する制度（SCS評価制度）の（参考）★3・★4要求事項及び評価基準参照文献の参照文献に総務省の「地方公共団体における情報セキュリティポリシーに関するガイドライン」も加える必要がありそうですね...

幸い、こちらのガイドラインは、JISQ27002（おそらく2024）との参照関係はしめしているので、それを伝えば、つながりそうですね...（包含関係問題はありますが...）

---

● まるちゃんの情報セキュリティ気まぐれ日記

・2025.04.01 総務省 地方公共団体における情報セキュリティポリシーに関するガイドライン（令和7年3月版）

・2021.09.14 地⽅⾃治体によるガバメントクラウドの活⽤について（案）2021.08現在

・2021.05.31 文部科学省 「教育情報セキュリティポリシーに関するガイドライン」公表について

・2021.05.13 参議院　デジタル社会形成基本法案等を議決 デジタル庁設置、個人情報保護法改正、地方自治体システム標準化等。。。

・2020.12.31 自民党デジタル社会推進本部 デジタル庁創設に向けた中間提言 at 2020.12.22 （小林史明議員公式サイト）

・2020.12.29 総務省　「地方公共団体における情報セキュリティポリシーに関するガイドライン」と「地方公共団体における情報セキュリティ監査に関するガイドライン」の公表及び意見募集の結果

・2020.12.25 官邸 「デジタル社会の実現に向けた改革の基本方針」と「デジタル・ガバメント実行計画」が閣議決定

・2020.12.13 総務省 意見募集「地方公共団体における情報セキュリティポリシーに関するガイドライン」（改定案）、「地方公共団体における情報セキュリティ監査に関するガイドライン」（改定案）

・2020.11.19 自民党デジタル社会推進本部がデジタル庁についての第一次提言を平井卓也デジタル改革担当相に手交

・2020.09.05 J-LIS （予告）「自治体テレワーク推進実証実験」の公募について

・2020.05.23 総務省 「自治体情報セキュリティ対策の見直しについて」の公表

ちょっと遡って...

・2012.07.22 総務省 ASP・SaaS・クラウドの普及拡大に向けたガイドの公表

・2010.11.16 総務省 確定 地方公共団体における情報セキュリティポリシーに関するガイドラインと地方公共団体における情報セキュリティ監査に関するガイドライン

・2010.12.12 総務省 自治体クラウド推進本部　有識者懇談会（第3回）

・2010.09.17 総務省 パブコメ　地方公共団体における情報セキュリティポリシーに関するガイドライン（案）と地方公共団体における情報セキュリティ監査に関するガイドライン（案）

・2010.08.06 総務省　電子自治体　情報セキュリティ対策の推進

・2010.08.05 総務省　自治体クラウド推進本部

・2010.05.01 内閣府 地方公共団体の業務継続ガイドライン

・2010.04.02 総務省 確定 地方公共団体におけるASP･SaaS導入活用ガイドライン

・2010.03.12 「サイバー攻撃に無防備、１９３自治体」だそうです。。。

・2010.03.09 総務省 自治体クラウドポータルサイトの開設

・2010.02.20 総務省 パブコメ 「地方公共団体におけるASP・SaaS導入活用ガイドライン（案）」

・2010.01.25 長崎県がクラウド事業者として市町村にサービスを提供するの件

・2010.01.18 日本経団連 「電子行政推進シンポジウム」（2009.12.08）開催の様子

・2009.03.28 総務省　電子自治体の推進に関する懇談会（セキュリティワーキング　グループ）検討結果

・2008.08.23 総務省 確定 「地方公共団体におけるＩＣＴ部門の業務継続計画（ＢＣＰ）策定に関するガイドライン」

・2008.06.28 総務省 パブコメ 「地方公共団体におけるＩＣＴ部門の業務継続計画（ＢＣＰ）策定に関するガイドライン」（案）

・2008.04.26 総務省 地方自治情報管理概要

・2007.07.14 総務省 「地方公共団体におけるITガバナンスの強化ガイド」を公表

・2007.07.09 総務省 確定 「地方公共団体における情報セキュリティ監査に関するガイドライン」

・2007.06.09 総務省 パブコメ 「地方公共団体における情報セキュリティ監査に関するガイドライン」

・2007.04.02 総務省 自治体ＩＳＡＣ（仮称）実証実験の実施結果

・2006.09.30 総務省 地方公共団体における情報セキュリティポリシーに関するガイドラインを公表

・2006.08.21 総務省 パブコメ 「地方公共団体における情報セキュリティポリシーに関するガイドライン」（案）

・2006.06.01 地方公共団体セキュリティ対策支援フォーラム 「情報セキュリティ監査実施状況および推進課題に関する検討」報告書

・2006.04.06 総務省 「地方公共団体の情報セキュリティレベルの評価に係る制度の在り方に関する調査研究報告書」の公表

・2006.01.24 総務省 住民基本台帳ネットワークシステム及びそれに接続している既設ネットワークに関する調査票による点検状況

・2005.07.19 総務省　平成１７年度電子自治体関連施策　セキュリティ認定制度

・2005.07.17 「地方公共団体における情報セキュリティ内部アセスメント（監査）の進め方」

・2005.02.15 住民基本台帳ネットワークシステム　政府と国民の信頼がポイントではないのだろうか？

米国 NIST SP 800-228 更新版 クラウドネイティブシステム向けAPI防御ガイドライン (2026.03.13)

こんにちは、丸山満彦です。

NISTが、SP 800-228 クラウドネイティブシステム向けAPI防御ガイドライン。昨年６月に公開されたバージョンの更新版。附属書D：リスクカテゴリー別APIリスク一覧、附属書E：API ライフサイクル段階別推奨セキュリティ制御リストが追加されています...

API はソフトウェアの一部だけど、外から見える場合も多いし、攻撃面が広いから、DevSecOps を高いレベルで徹底しないと危ないよということですかね...

● NIST - ITL

・2026.03.13 NIST SP 800-228 Guidelines for API Protection for Cloud-Native Systems

NIST SP 800-228 Guidelines for API Protection for Cloud-Native Systems	NIST SP 800-228 クラウドネイティブシステム向けAPI防御ガイドライン
Abstract	要約
Modern enterprise IT systems rely on a family of application programming interfaces (APIs) for integration to support organizational business processes. Hence, a secure deployment of APIs is critical for overall enterprise security. This, in turn, requires the identification of risk factors or vulnerabilities in various phases of the API life cycle and the development of controls or protection measures. This document addresses the following aspects of achieving that goal: (a) the identification and analysis of risk factors or vulnerabilities during various activities of API development and runtime, (b) recommended basic and advanced controls and protection measures during the pre-runtime and runtime stages of APIs, and (c) an analysis of the advantages and disadvantages of various implementation options for those controls to enable security practitioners to adopt an incremental, risk-based approach to securing their APIs.	現代のエンタープライズITシステムは、組織のビジネスプロセスを支えるための統合において、一連のアプリケーション・プログラミング・インターフェース（API）に依存している。したがって、APIの安全な展開は、エンタープライズ全体のセキュリティにとって極めて重要である。これには、APIライフサイクルの各段階におけるリスク要因や脆弱性の特定、および制御策や保護措置の策定が必要となる。本文書は、その目標を達成するための以下の側面について扱う：(a) APIの開発および実行時の様々な活動におけるリスク要因や脆弱性の特定と分析、(b) APIの実行前および実行段階における推奨される基本的および高度な制御および保護措置、ならびに(c) セキュリティ担当者がAPIのセキュリティ確保に向けて段階的かつリスクベースのアプローチを採用できるようにするための、それらの制御に関する様々な実装オプションの長所と短所の分析。

・[PDF] NIST.SP.800-228-upd1

・[DOCX][PDF] 仮訳

エグゼクティブサマリー...

Executive Summary	エグゼクティブサマリー
Application programming interfaces (APIs) provide the means to integrate and communicate with the modern enterprise IT application systems that support business processes. However, a lack of due diligence can introduce vulnerabilities and risk factors that exploit the connectivity and accessibility features of APIs. If these vulnerabilities are not identified, analyzed, and addressed through control measures, attack vectors could threaten the security posture of the application systems spanned by these APIs. A systematic and effective means of identifying and addressing these vulnerabilities is only possible by treating the development and deployment of APIs as an iterative life cycle using paradigms like development, security, and operations (DevSecOps).	アプリケーション・プログラミング・インターフェース（API）は、ビジネスプロセスを支える現代のエンタープライズITアプリケーションシステムとの統合およびコミュニケーション手段を提供する。しかし、十分な注意を払わないと、APIの接続性やアクセシビリティの機能を悪用する脆弱性やリスク要因が生じる可能性がある。これらの脆弱性が特定・分析されず、制御措置によって対処されない場合、攻撃ベクトルが、これらのAPIによって接続されたアプリケーションシステムのセキュリティ態勢を脅かす恐れがある。 これらの脆弱性を識別し対処するための体系的かつ効果的な手段は、APIの開発と展開を、開発、セキュリティ、運用（DevSecOps）といったパラダイムを用いた反復的なライフサイクルとして扱うことによってのみ可能となる。
This document provides guidelines and recommendations on controls and protection measures for secure API deployments in the enterprise. In addition, an analysis of the advantages and disadvantages of various implementation options (called patterns) for those controls enable security practitioners to choose the most effective option for their IT ecosystem.	本書は、エンタープライズにおける安全なAPI展開のための制御および防御措置に関するガイドラインと推奨事項を提供する。さらに、それらの制御に対する様々な実装オプション（パターンと呼ばれる）の長所と短所を分析することで、セキュリティ担当者は自社のITエコシステムに最も効果的なオプションを選択できるようになる。
Developing these controls and analyzing their implementation options should be guided by several overarching principles:	これらの制御策の策定および実装オプションの分析にあたっては、以下の包括的な原則に従うべきである：
• The guidance for controls should cover all APIs, regardless of whether they are exposed to customers/partners or used internally within the enterprise.	• 制御に関するガイダンスは、顧客やパートナーに公開されているか、あるいはエンタープライズ内で内部的に使用されているかを問わず、すべてのAPIを対象とするべきである。
• With the vanishing of perimeters in modern enterprise IT applications, all controls should incorporate the concept of zero trust.	• 現代のエンタープライズITアプリケーションにおいて境界が消失しつつあるため、すべての制御にはゼロトラストの概念を組み込むべきである。
• The controls should span the entire API life cycle and be classified into (a) pre-runtime protections and (b) runtime protections that are then subdivided into basic and advanced protections to enable incremental risk-based adoption.	• コントロールはAPIのライフサイクル全体にわたり、(a) 実行前防御と (b) 実行時防御に分類されるべきであり、実行時防御はさらに基本防御と高度な防御に細分化され、リスクベースの段階的な導入を可能にする必要がある。

目次...

Executive Summary	エグゼクティブサマリー
1. Introduction	1. 序論
1.1. Zero Trust and APIs: The Vanishing Perimeter	1.1. ゼロトラストとAPI：消えゆく境界線
1.2. API Life Cycle	1.2. APIライフサイクル
1.3. Document Goals	1.3. 文書の目的
1.4. Relationship to Other NIST Documents	1.4. 他の NIST 文書との関係
1.5. Document Structure	1.5. 文書の構成
2. API Risks: Vulnerabilities and Exploits	2. APIのリスク：脆弱性と悪用
2.1. Lack of Visibility of APIs in the Enterprise Inventory	2.1. エンタープライズ・インベントリにおけるAPIの可視性の欠如
2.2. Missing, Incorrect, or Insufficient Authorization	2.2. 欠落、不正確、または不十分な認可
2.3. Broken Authentication	2.3. 認証の欠陥
2.4. Unrestricted Resource Consumption	2.4. 制限のないリソース消費
2.4.1. Unrestricted Compute Resource Consumption	2.4.1. 制限のないコンピューティングリソースの消費
2.4.2. Unrestricted Physical Resource Consumption	2.4.2. 物理リソースの無制限な消費
2.5. Leaking Sensitive Information to Unauthorized Callers	2.5. 権限のない呼び出し元への機密情報の漏洩
2.6. Insufficient Verification of Input Data	2.6. 入力データの不十分な検証
2.6.1. Input Validation	2.6.1. 入力の妥当性確認
2.6.2. Malicious Input Protection	2.6.2. 悪意のある入力に対する防御
2.7. Credential Canonicalization: Preparatory Step for Controls	2.7. 認証情報の正規化：制御のための準備段階
2.7.1. Gateways Straddle Boundaries	2.7.1. 境界にまたがるゲートウェイ
2.7.2. Requests With a Service Identity But No User Identity	2.7.2. サービスIDはあるがユーザーIDがないリクエスト
2.7.3. Requests With a User Identity But No Service Identity	2.7.3. ユーザーIDはあるがサービスIDがないリクエスト
2.7.4. Requests With Both User and Service Identities	2.7.4. ユーザーとサービスの両方のIDを含むリクエスト
2.7.5. Reaching Out to Other Systems	2.7.5. 他のシステムへの接続
2.7.6. Mitigating the Confused Deputy	2.7.6. 「Confused Deputy」の緩和
2.7.7. Identity Canonicalization	2.7.7. アイデンティティの正規化
3. Recommended Controls for APIs	3. API に対する推奨対策
3.1. Pre-Runtime Protections All API controls must be well-defined and inventoried.	3.1. 実行前防御すべてのAPI制御は明確に定義され、一覧化されなければならない。
3.1.1. Basic Pre-Runtime Protections	3.1.1. 基本的な実行前防御
3.1.2. Advanced Pre-Runtime Protections	3.1.2. 実行前の高度な防御措置
3.2. Runtime Protections For runtime protections for APIs, apply zero trust principles as a baseline, and augment them with additional policy on requests and their payloads.	3.2. 実行時防御APIの実行時防御については、ゼロトラストの原則を基本とし、リクエストとそのペイロードに対する追加のポリシーでこれを補強する。
3.2.1. Basic Runtime Protections	3.2.1. 基本的な実行時防御
3.2.2. Advanced Runtime Protections	3.2.2. 高度な実行時防御
4. Implementation Patterns and Trade-Offs for API Protections	4. API防御のための実装パターンとトレードオフ
4.1. Centralized API Gateway	4.1. 集中型APIゲートウェイ
4.2. Hybrid Deployments	4.2. ハイブリッド展開
4.3. Distributed Gateway Pattern	4.3. 分散ゲートウェイパターン
4.4. Related Technologies	4.4. 関連技術
4.4.1. Web Application Firewalls	4.4.1. Webアプリケーションファイアウォール
4.4.2. Bot Detection	4.4.2. ボット検知
4.4.3. Distributed Denial of Service (DDoS) Mitigation	4.4.3. 分散型サービス拒否（DDoS）攻撃の緩和
4.4.4. API Endpoint Protection	4.4.4. APIエンドポイント防御
4.4.5. Web Application and API Protection (WAAP)	4.4.5. WebアプリケーションおよびAPI防御（WAAP）
4.5. Summary of Implementation Patterns	4.5. 実装パターンの概要
5. Conclusions and Summary	5. 結論と要約
References	参考文献
Appendix A. API Classification Taxonomy	附属書A. API分類の分類体系
A.1. API Classification Based on Degree of Exposure	A.1. エクスポージャーに基づくAPI分類
A.2. API Classification Based on Communication Patterns	A.2. コミュニケーションパターンに基づくAPIの分類
A.3. API Classification Based on Architectural Style or Pattern (API Types)	A.3. アーキテクチャスタイルまたはパターンに基づくAPIの分類（APIの種類）
A.4 API Classification Based on Data Sensitivity	A.4 データの機密性に基づく API の分類
Appendix B. DevSecOps Phases and Associated Classes of API Controls	附属書 B. DevSecOps のフェーズと関連する API 制御のクラス
Appendix C. Limit Types Configured During Runtime	附属書 C. 実行時に設定される制限タイプ
Appendix D. List of API Risks by Risk Categories	附属書D. リスクカテゴリー別APIリスク一覧
Appendix E. List of Recommended Security Controls by API Lifecycle Stage	附属書 E. API ライフサイクル段階別推奨セキュリティ制御リスト
Appendix F. Change Log	附属書F. 変更履歴

---

● まるちゃんの情報セキュリティ気まぐれ日記

・2025.07.04 米国 NIST SP 800-228 クラウドネイティブシステムのための API 保護に関するガイドライン (2025.06.27)

・2025.03.26 米国 NIST SP 800-228（初期公開ドラフト）クラウドネイティブシステムのAPI防御ガイドライン

ICT-ISAC ICT分野事業者に向けたセキュリティ・クリアランス法制に関するレポート (2026.03.03)

こんにちは、丸山満彦です。

ICT-ISACがICT分野事業者に向けたセキュリティ・クリアランス法制に関するレポート、「我が国におけるセキュリティ・クリアランス法制の動向
「重要経済安保情報保護活用法」」という報告書を公表していますね...KDDI総合研究所が作成したものです...

「電気通信事業者に求められる実務的な対応と、企業活動への影響を明確化することを目的とする。特に、通信業界が今後直面し得る制度対応を、条文および運用基準に基づき整理する。」としていますね...

電気通信事業者への影響と求められる対応のイメージとして次のように考えているようですね...

組織に求められる対応もその通りだと思います。。。（私は次の5つで考えていましたが（①組織体制、②設備、③システム、④人事対応、⑤調達・委託管理（日本人らしい...(^^)）。KDDIの報告書は、わたしの①から③をまとめて「適合事業者認定への備え」としているイメージですね...）

---

◼ 影響

⚫ 電気通信は「重要インフラ15分野」として明確に位置づけられており、本法の運用において対象となりやすい業
態となる可能性がある。留意点として以下が考えられる：

• 「特定秘密」とは異なる制度であるため、事業で生ずる情報が指定対象になり得る可能性。
• 適合事業者認定や適性評価は任意制度だが、事実上の政府調達参加条件となる可能性が高い。
• 下請・委託先（ベンダー・工事会社等）との関係性。

◼ 求められる対応

⚫ 組織対応・社内体制構築：適合事業者認定への備え

• 保護責任者（役員）／業務管理者（CSIRT等）指名
• 重要情報取扱区画（専用室）設置計画 等

⚫ 労務・人事対応：適性評価への備え

• 従業者選定
• 退職者の情報管理強化 等

⚫ 調達・委託管理対応：サプライチェーン対策

• NDA の強化（退職後規定含む）
• 再委託禁止（または報告義務）
• 委託先監査の実施

---

また、サイバーセキュリティに関するサプライチェーンリスクを3つの類型にわけていますが、私もその通りと思います。ときどき、どのリスクの話をしているのかわかりにくくなるので、この３類型に名前をつけたらよいのではないかと思います。（渉外 -> 障害）

---

◼ サプライチェーン・リスクの種類（サイバーセキュリティに関し）

⚫ 具体的には：

• 委託先（委託先のシステムを経由したサイバー攻撃）
• クラウドサービス（クラウドサービスの渉外によるサービス停止）
• ソフトウェア（バックドア型マルウェアが仕込まれる）

---

1. 委託先（委託先のシステムを経由したサイバー攻撃）
2. クラウドサービス（クラウドサービスの渉外によるサービス停止）
3. ソフトウェア（バックドア型マルウェアが仕込まれる）

とすると、、、たとえば...

1. 「大阪急性期総合医療センター型」

2. 「小島プレスのクラウド版型」

3. 「SolarWinds型」

みたいな...社名出すとあかんか...

● ICT-ISAC

・2026.03.03 国内初、ICT分野事業者に向けたセキュリティ・クリアランス法制に関するレポートを公表

CSA 非人間アイデンティティとAIセキュリティの現状 (2026.01.26)

こんにちは、丸山満彦です。

ID管理をしている人と話をしていると、AI等のNHIの効率的な管理をしなければ、爆発的に増大するIDの管理が追いつかず、システムが暴走し、止めることもできなくなるかも...と言う話をしていたところなので、なるほどです。。。

IDに限らず、生成をAIがするときに同時に独立した別のAIによりその情報の適切性を検証し、修復またはプロセスを中止し、人間の判断を入れるようにする必要があるかもしれませんね...

この報告書で指摘されているように、AI時代のID管理は「新しい問題」ではなく「既存の脆弱性の増幅」ですよね。。。特に、ガバナンスとオーナーシップの欠如が、AIによるIDの高速生成と相まって、セキュリティリスクを指数関数的に高めているのは課題でしょう。

AIエージェントを人間と同様に扱い、ライフサイクル全体で自動化されたガバナンスを組み込むことが重要でしょうね。。。そうなるとNHI管理の自動化に取り組むことが必要となりますね...

● Cloud Security Alliance: CSA

・2026.01.26 The State of Non-Human Identity and AI Security

The State of Non-Human Identity and AI Security	非人間アイデンティティとAIセキュリティの現状
Based on a comprehensive survey of IT and security professionals, this report explores how rapid AI adoption amplifies long-standing Identity and Access Management (IAM) challenges. It reveals that AI does not introduce an entirely new identity paradigm. Instead, AI magnifies existing non-human identity (NHI) risks related to governance, visibility, ownership, and credential lifecycle management.	ITおよびセキュリティ専門家を対象とした包括的な調査に基づき、本レポートはAIの急速な導入が既存のアイデンティティおよびアクセス管理（IAM）課題をいかに増幅させるかを検証する。AIが全く新しいアイデンティティの枠組みをもたらすわけではないことが明らかになった。むしろAIは、ガバナンス、可視性、オーナーシップ、認証情報のライフサイクル管理に関連する既存の非人間アイデンティティ（NHI）リスクを増幅させるのである。
Most organizations still manage AI identities using legacy IAM tools and manual processes. But these resources were never designed for autonomous, high-velocity systems. As AI-driven workloads accelerate identity creation, organizations struggle with credential sprawl, unclear ownership, inconsistent automation, and slow remediation timelines.	多くの組織は依然として、レガシーなIAMツールと手動プロセスでAIアイデンティティを管理している。しかしこれらのリソースは自律的で高速なシステム向けに設計されたものではない。AI駆動のワークロードがアイデンティティ生成を加速させる中、組織は認証情報の拡散、不明確なオーナーシップ、一貫性のない自動化、遅延した修復プロセスに苦慮している。
The findings uncover four critical areas of concern:	調査結果から明らかになった4つの重大な懸念領域は以下の通りである：
・AI identities compounding traditional non-human identity security risks	・AIアイデンティティが従来の非人間アイデンティティセキュリティリスクを増幅させる
・Persistent governance and ownership gaps	・持続的なガバナンスとオーナーシップのギャップ
・The friction between AI speed and legacy IAM infrastructure	・AIの速度とレガシーIAMインフラの摩擦
・Token sprawl caused by inadequate rotation and revocation practices	・不十分なローテーションと失効処理によるトークンの拡散
Together, these issues expand the operational attack surface and increase the blast radius of identity-related incidents.	これらの問題は相まって、運用上の攻撃対象領域を拡大し、アイデンティティ関連インシデントの被害範囲を拡大させる。
This research provides a data-driven view into how organizations are currently managing AI-era identities. It shows why visibility, automation, and accountability are essential to securing AI at scale. Finally, it serves as a benchmark for identity maturity and a call to modernize IAM.	本調査は、組織がAI時代のアイデンティティを現在どのように管理しているかをデータに基づいて明らかにする。可視性、自動化、説明責任が大規模なAIセキュリティに不可欠な理由を示し、アイデンティティ成熟度のベンチマークとして機能するとともに、IAMの近代化を促すものである。
Key Findings:	主な調査結果：
・Organizations largely view AI identities through the same lens as traditional NHIs. When asked what constitutes an AI identity, most respondents selected service accounts, API keys or tokens, and chatbots.	・組織はAIアイデンティティを従来のNHIと同様の視点で捉えている。AIアイデンティティの構成要素を問う質問に対し、回答者の大半がサービスアカウント、APIキー／トークン、チャットボットを選択した。
・Governance remains one of the weakest links in organizations’ AI identity programs. Less than ¼ of organizations reported having documented and formally adopted policies for creating or removing AI identities.	・ガバナンスは組織のAIアイデンティティプログラムにおいて依然として最も脆弱な部分である。AIアイデンティティの作成・削除に関する文書化済みかつ正式に採用されたポリシーを有すると回答した組織は4分の1未満だった。
・The limitations of legacy IAM systems often constrain AI opportunities. Only 12% of organizations reported being highly confident in their ability to prevent attacks via NHIs. Even fewer expressed high confidence that their legacy IAM solutions can effectively manage AI and NHI security risks.	・レガシーIAMシステムの限界がAI活用の機会を制約している。NHI経由の攻撃を防止できると高い自信を持っている組織はわずか12%だった。さらに少ない組織しか、レガシーIAMソリューションがAIおよびNHIのリスクを効果的に管理できると高い自信を示していない。
・More than 16% of organizations said they do not track the creation of new AI-related identities. This leaves a growing subset of tokens and service accounts outside formal inventory.	・16%以上の組織が、新たなAI関連アイデンティティの作成を追跡していないと回答した。これにより、トークンやサービスアカウントの増加するサブセットが正式なインベントリから除外された状態にある。

Continue reading "CSA 非人間アイデンティティとAIセキュリティの現状 (2026.01.26)"

ドイツ BSIがセキュリティや主権機能の設計を支援したAWS 欧州ソブリンクラウドが開始した (2026.01.15)

こんにちは、丸山満彦です。

日本ではソブリンクラウドについてなんとなく話されている程度ですが、欧州では戦略的に体系立てて整理され、実装にむけて進んでいますね...で、AWSを利用した欧州ソブリンクラウドが開始されたという話です...

● BSI

・2025.01.15 AWS European Sovereign Cloud startet: BSI unterstützt bei Ausgestaltung von Sicherheits- und Souveränitätsmerkmalen

AWS European Sovereign Cloud startet: BSI unterstützt bei Ausgestaltung von Sicherheits- und Souveränitätsmerkmalen	AWS European Sovereign Cloud が開始：BSI がセキュリティおよび主権機能の設計を支援
Das Bundesamt für Sicherheit in der Informationstechnik (BSI) unterstützt den US-Cloud-Anbieter Amazon Web Services (AWS) bei der Ausgestaltung von Sicherheits- und Souveränitätsmerkmalen seiner heute gestarteten European Sovereign Cloud (ESC): einer eigenständigen Cloud-Infrastruktur, die sich vollständig innerhalb der EU befindet und deren Betrieb physisch wie auch logisch von der globalen AWS-Instanz unabhängig sein wird.	ドイツ連邦情報セキュリティ局（BSI）は、米国のクラウドプロバイダーである Amazon Web Services（AWS）が本日開始した European Sovereign Cloud（ESC）のセキュリティおよび主権機能の設計を支援している。ESC は、EU 域内に完全に設置され、物理的および論理的にグローバルな AWS インスタンスから独立して運用される、独立したクラウドインフラストラクチャである。
BSI-Präsidentin Claudia Plattner: „Um mit digitalen Innovationen Schritt zu halten und gleichzeitig digitale Souveränität zu ermöglichen, verfolgt das BSI eine Doppelstrategie. Erstens: Der europäische Markt und die hiesige Digitalindustrie müssen gestärkt werden. Zweitens: Außereuropäische globale Produkte müssen so angepasst und eingebettet werden, dass eine sichere und selbstbestimmte Nutzung möglich wird. Voraussetzung dafür sind im Bereich Cloud-Computing innovative Angebote, die als europäische Instanzen sowohl technisch als auch organisatorisch unabhängig betrieben werden. Die Zukunft der Hyperscaler in Europa sind daher Angebote wie die AWS European Sovereign Cloud. Als Cybersicherheitsbehörde Deutschlands freuen wir uns, dass wir zu deren Konzeption beitragen können. Wir werden die Umsetzung der Sicherheits- und Souveränitätsmerkmale eng begleiten.“	BSI のクラウディア・プラットナー会長は、「デジタルイノベーションに遅れを取らないよう、同時にデジタル主権を実現するため、BSI は 2 つの戦略を追求している。まず、欧州市場と欧州のデジタル産業を強化すること。次に、欧州以外のグローバル製品を、安全かつ自主的な利用が可能になるよう調整し、組み込むことだ。その前提条件としては、クラウドコンピューティングの分野において、技術的にも組織的にも独立して運営される、革新的なサービスが必要だ。したがって、ヨーロッパにおけるハイパースケーラーの未来は、AWS European Sovereign Cloud のようなサービスにある。ドイツのサイバーセキュリティ機関として、その構想に貢献できることを嬉しく思う。我々は、セキュリティと主権の特徴の実装を密接に支援していくつもりだ。」
Stéphane Israël, Managing Director AWS European Sovereign Cloud and Digital Sovereignty: „Europa braucht Zugang zu führender Cloud- und KI-Technologie. Die Erweiterung der AWS Innovationen in Europa wird dabei helfen, das Wachstum unserer Kunden und ihre KI-Ambitionen voranzutreiben. Kunden wollen das Beste aus beiden Welten – sie möchten die komplette Palette der fortschrittlichen Cloud- und KI-Services von AWS nutzen können und gleichzeitig sicherstellen, dass sie strengste Souveränitätsanforderungen erfüllen können. Indem wir eine Cloud aufbauen, die in ihrer Technologie, ihrem Betrieb und ihrer Kontrolle vollständig europäisch ist, ermöglichen wir Organisationen, mit Zuversicht zu innovieren und dabei die vollständige Kontrolle über ihre digitalen Ressourcen zu behalten.“	ステファン・イスラエル、AWS European Sovereign Cloud and Digital Sovereignty マネージングディレクター：「ヨーロッパは、最先端のクラウドおよび AI テクノロジーへのアクセスを必要としている。ヨーロッパにおける AWS のイノベーションの拡大は、お客様の成長と AI に関する野心の推進に貢献するだろう。顧客は、両方の長所を最大限に活用したいと考えている。つまり、AWS の先進的なクラウドおよび AI サービスをすべて利用しながら、最も厳しい主権要件も満たすことを望んでいる。技術、運用、管理のすべてにおいて完全にヨーロッパのクラウドを構築することで、組織は自信を持ってイノベーションを推進しながら、デジタルリソースを完全に管理し続けることができるようになる。」
Um Souveränität faktisch zu gewährleisten, sollte die AWS European Sovereign Cloud aus Sicht des BSI technische und strukturelle Souveränitätsmerkmale kombinieren: Zu den wichtigsten Aspekten gehört dabei neben der technischen Unabhängigkeit von der globalen Partition ein technisch und organisatorisch eigenständiges Personal der europäischen Cloud-Infrastruktur, das den Regelbetrieb (einschließlich der kontinuierlichen Schließung von Sicherheitslücken) sicherstellt und ausschließlich aus EU-Bürgern zusammengesetzt ist. Darüber hinaus ist es aus Sicht des BSI unabdingbar, durch technische Kontrollschichten zum einen zu verhindern, dass Nutzerdaten aus dem EU-Raum abfließen können, und zum anderen auszuschließen, dass eine externe Steuerung oder auch Abschaltung (sog. Kill-Switch) der Instanz vorgenommen werden kann. Dies betrifft auch Updates, welche in die ESC eingespielt werden.	主権を事実上確保するためには、BSI の見解では、AWS European Sovereign Cloud は技術的および構造的な主権の特徴を組み合わせていなければならない。その最も重要な側面としては、グローバルパーティションからの技術的独立性に加え、欧州のクラウドインフラストラクチャの技術的および組織的に独立したスタッフがいることが挙げられる。このスタッフは、通常の運用（セキュリティギャップの継続的な解消を含む）を確保し、EU 市民のみで構成される。さらに、BSI の見解では、技術的な制御層によって、EU 域外へのユーザーデータの流出を防止するとともに、外部からの制御やインスタンスの停止（いわゆるキルスイッチ）を不可能にすることが不可欠だ。これは、ESC に導入されるアップデートにも当てはまる。
Im nächsten Schritt wird das BSI den Status der Entkopplungsfähigkeit und die Umsetzung u.a. der genannten Souveränitätsmaßnahmen prüfen und bewerten sowie zur weiteren Optimierung der Souveränitätsmerkmale der AWS ESC beitragen.	次のステップとして、BSI は、分離可能性のステータス、および上記の主権対策などの実施状況を検証・評価し、AWS ESC の主権特性のさらなる最適化に貢献する予定だ。
Im Laufe des Jahres wird das BSI auf Basis des EU Cloud Sovereignty Framework allgemeine Souveränitätskriterien für Cloud-Computing-Lösungen veröffentlichen. Diese Kriterien sollen als Grundlage für die Bewertung des Autonomiegrades von Cloud-Lösungen dienen und u.a. auch in Beschaffungsprozessen eingesetzt werden können.	今年中に、BSI は EU クラウド主権フレームワークに基づいて、クラウドコンピューティングソリューションの一般的な主権基準を発表する予定だ。これらの基準は、クラウドソリューションの自律性の程度を評価するための基礎として、また調達プロセスなどで活用することができる。

---

・2025.10 [PDF] Cloud Sovereignty Framework Version 1.2.1 – Oct. 2025

・[DOCX][PDF] 仮訳

参考

主権目標

#	Sovereignty Objectives	主権目標	Sovereignty Objectives Descriptions	主権目標の説明
SOV-1	Strategic  Sovereignty	戦略的主権	Strategic sovereignty captures the degree to which the services of a cloud provider (or technology actor) are anchored within the European Union legal, financial, and industrial ecosystem. It assesses ownership stability, governance influence, and alignment with EU strategic priorities.	戦略的主権とは、クラウドプロバイダ（または技術アクター）のサービスが、欧州連合の法的・金融・産業エコシステムにどの程度定着しているかを示すものである。所有権の安定性、ガバナンスへの影響力、EUの戦略的優先事項との整合性を評価する。
SOV-2	Legal & Jurisdictional Sovereignty	法的・管轄主権	Legal & Jurisdictional sovereignty evaluates the legal environment, exposure to foreign authority, and enforceability of rights that govern the services of a technology provider. It determines the extent to which the services are anchored in European jurisdiction and insulated from external legal claims.	法的・管轄主権は、技術プロバイダのサービスを統治する法的環境、外国当局への曝露、権利の執行可能性を評価する。サービスが欧州の管轄権にどの程度定着し、外部からの法的請求から隔離されているかを決定する。
SOV-3	Data & AI  Sovereignty	データ・AI主権	Data & AI sovereignty focuses on the protection, control, and independence of data assets and AI services within the EU. It addresses how data is secured, where it is processed, and the degree of autonomy customers retain over AI capabilities.	データ・AI主権は、EU域内におけるデータ資産とAIサービスの防御、管理、独立性に焦点を当てる。データの防御方法、処理場所、顧客がAI機能に対して保持する自律性の程度を扱う。
SOV-4	Operational  Sovereignty	運用主権	Operational sovereignty measures the practical ability of EU actors to run, support, and evolve a technology independently of foreign control. It focuses on continuity of operations, skill availability, and resilience against external dependencies.	運用主権とは、EU関係者が外国の支配を受けずに技術を運用・支援・進化させる実践的能力を測るものである。運用継続性、技能の可用性、外部依存に対するレジリエンスに焦点を当てる。
SOV-5	Supply Chain  Sovereignty	サプライチェーン主権	Supply chain sovereignty evaluates the geographic origin, transparency, and resilience of the technology supply chain, focusing on the extent to which critical components and processes remain under EU control or exposed to non-EU dependencies.	サプライチェーン主権は、技術サプライチェーンの地理的起源、透明性、レジリエンスを評価する。重要部品やプロセスがEUの管理下に留まるか、非EU依存に晒されるかの程度に焦点を当てる。
SOV-6	Technology  Sovereignty	技術主権	Technology sovereignty evaluates the degree of openness, transparency, and independence in the underlying technological stack, ensuring EU actors can interoperate, audit, and evolve solutions without lock-in to foreign proprietary systems.	技術主権は、基盤となる技術スタックの開放性、透明性、独立性の程度を評価する。これにより、EU関係者が外国の独自システムに縛られることなく、相互運用、監査、ソリューションの進化を実現できることを保証する。
SOV-7	Security & Compliance Sovereignty	セキュリティ・コンプライアンス主権	Security & Compliance sovereignty measures the extent to which security operations, compliance obligations, and resilience measures are controlled within the EU, ensuring independence from foreign jurisdictions and long-term operational assurance.	セキュリティ・コンプライアンス主権は、セキュリティ運用、コンプライアンス義務、レジリエンス対策がEU域内で管理されている程度を測定し、外国の管轄権からの独立性と長期的な運用保証を確保する。
SOV-8	Environmental Sustainability	環境持続可能性	Environmental sustainability assesses autonomy and resilience of cloud services over the long term in relation to energy usage, dependency and raw material scarcity.	環境持続可能性は、エネルギー使用量、依存度、原材料の不足に関して、クラウドサービスの長期的な自律性とレジリエンスを評価する。

主権効果保証レベル（SEAL）

主権効果保証レベル	Sovereignty Effectiveness Assurance Levels Descriptions	主権有効性保証レベルの説明
SEAL-0	No Sovereignty:	主権なし：
	Service, technology or operations under exclusive control of non-EU third parties, governed entirely in non-EU jurisdictions.	サービス、技術、または運用が非EUサードパーティの独占的支配下にあり、完全に非EU管轄区域で管理されている状態。
SEAL-1	Jurisdictional Sovereignty:	管轄権主権：
	EU law formally applies with limited practical enforceability; service, technology or operations under exclusive control of non-EU third parties.	EU法が形式的に適用されるが、実際の執行力は限定的である。サービス、技術、または運営は非EUサードパーティの独占的支配下にある。
SEAL-2	Data Sovereignty:	データ主権：
	EU law applicable and enforceable, with material non-EU dependencies remaining; service, technology or operations under indirect control of non-EU third parties.	EU法が適用され執行可能だが、EU域外への重要な依存関係が残存する。サービス、技術、または業務がEU域外のサードパーティの間接的な管理下にある。
SEAL-3	Digital Resilience:	デジタルレジリエンス：
	EU law applicable and enforceable, EU actors exercising meaningful but not full influence; service, technology or operations under marginal control of non-EU third parties.	EU法が適用可能かつ執行可能だが、EU関係者は実質的影響力を行使するものの完全な支配権は有さない。サービス、技術、または運用が非EUサードパーティの軽微な支配下にある。
SEAL-4	Full Digital Sovereignty:	完全なデジタル主権：
	Technology and operations under complete EU control, subject only to EU law, with no critical non-EU dependencies.	技術と運用は完全にEUの管理下にあり、EU法のみに従う。重要な非EU依存関係は存在しない。

主権目標の評価要素

#	主権目標	Contributing factors	評価要素
SOV-1	戦略的主権	- Ensuring that bodies having decisive authority over your services are located within EU jurisdiction,	- サービスに対する決定権限を持つ団体がEUの管轄区域内に所在することを保証する。
		- Evaluating the assurances against change of control.	- 支配権の変更に対する保証を評価する。
		- Degree to which the provider relies on financing coming from EU sources.	- プロバイダがEU域内からの資金調達に依存する度合い。
		- Extent of investment, jobs, and value creation within EU.	- EU域内における投資、雇用創出、価値創造の規模。
		- Involvement in EU initiatives, Consistency with digital, green, and industrial sovereignty objectives defined at EU level.	- EUイニシアチブへの関与。EUレベルで定義されたデジタル主権、グリーン主権、産業主権の目標との整合性。
		- Ability to sustain secure operations against requests to cease or suspend the service, or if vendor support is withdrawn or disrupted.	- サービスの停止・中断要求、あるいはベンダーサポートの撤回・中断が発生した場合でも、安全な運用を維持する能力。
SOV-2	法的・管轄権主権	- The national legal system governing the provider’s operations and contracts.	- プロバイダの運営と契約を規定する国内法体系。
		- Degree of exposure to non-EU laws with cross-border reach (e.g., US CLOUD Act, Chinese Cybersecurity Law).	- 域外適用のある非EU法（例：米国クラウド法、中国サイバーセキュリティ法）へのエクスポージャー度合い。
		- Existence of legal, contractual, or technical channels through which non-EU authorities could compel access to data or systems.	- EU域外の当局がデータやシステムへのアクセスを強制できる法的、契約上、技術的な経路の存在。
		- Applicability of international regimes, which may restrict usage or transfer.	- 使用や移転を制限する可能性のある国際的な規制の適用性。
		- Location of intellectual property creation, registration, and development (EU vs. third countries), legal jurisdiction where IP is created and developed.	- 知的財産の創出、登録、開発の場所（EU対第三国）、知的財産が創出・開発される法的管轄区域。
SOV-3	データとAIの主権	- Ensuring that only the customer, not the provider, has effective control over cryptographic access to their data.	- 顧客のみが、プロバイダではなく、自らのデータへの暗号アクセスを効果的に制御できることを保証する。
		- Visibility into when, where, and by whom data is accessed, including auditability of AI model usage, mechanisms guaranteeing irreversible removal of data, with verifiable evidence.	- データがいつ、どこで、誰によってアクセスされたかの可視性。これにはAIモデル使用の監査可能性、データの不可逆的削除を保証するメカニズム、検証可能な証拠が含まれる。
		- Strict confinement of storage and processing to European jurisdictions, with no fallback to third countries.	- 保存と処理を欧州の管轄区域に厳格に限定し、第三国へのフォールバックを一切認めないこと。
		- Extent to which AI models and data pipelines are developed, trained, hosted, and governed under EU control, minimizing dependency on non-EU technology stacks.	- AIモデルとデータパイプラインがEUの管理下で開発、トレーニング、ホスティング、ガバナンスされる範囲を拡大し、EU外の技術スタックへの依存を最小限に抑えること。
SOV-4	運用主権	- Ease of migrating workloads or integrating with alternative EUcontrolled solutions without vendor lock-in.	- ベンダーロックインなしに、ワークロードの移行や代替となるEU管理ソリューションとの統合が容易であること。
		- Capacity for EU operators to manage, maintain, and support the technology without requiring non-EU vendor involvement	- EU 事業者が、EU 域外のベンダーの関与を必要とせずに、技術を管理、保守、サポートする能力。
		- Existence of an EU-based talent pool with the expertise to operate and sustain the service.	- サービスを運用・維持する専門知識を持つEU拠点の人材プールが存在すること。
		- Assurance that operational support is delivered from within the EU and subject exclusively to EU legal frameworks	- 運用サポートがEU域内から提供され、EUの法的枠組みのみに従うことが保証されていること。
		- Availability of full technical documentation, source code, and operational know-how enabling long-term autonomy.	- 長期的な自律性を可能にする完全な技術文書、ソースコード、運用ノウハウが利用可能であること。
		- Location and legal control of critical suppliers or subcontractors involved in service delivery.	- サービス提供に関わる重要なサプライヤーや下請け業者の所在地と法的管理。
SOV-5	サプライチェーン主権	- Geographic source of key physical parts, manufacturing location - countries where hardware is manufactured or assembled	- 主要な物理部品の地理的調達源、製造場所 - ハードウェアが製造または組み立てられる国々
		- Jurisdiction and provenance of embedded code controlling hardware, firmware	- ハードウェアを制御する組み込みコードの管轄権と来歴証明、ファームウェア
		- Origin of Software: where and by whom software is architected and programmed, location and jurisdiction governing software packaging, distribution, and updates.	- ソフトウェアの起源：ソフトウェアが設計・プログラミングされた場所と担当者、ソフトウェアのパッケージング、配布、更新を管轄する場所と管轄区域。
		- Degree of reliance on non-EU vendors, facilities, or proprietary technologies	- 非EUベンダー、施設、または独自技術への依存度
		- Visibility into the entire supplier and sub-supplier chain, including audit rights.	- サプライヤー及び下請けサプライヤーの全チェーンに対する可視性、監査権を含む。
SOV-6	技術主権	- Ability to integrate with other technologies through well-documented and non-proprietary APIs or protocols, extent to which the solution adheres to publicly governed and widely adopted standards, reducing dependency on single vendors	- 文書化され非専有のAPIやプロトコルを介した他技術との統合能力、公開ガバナンスされ広く採用された標準への準拠度合い、単一ベンダーへの依存低減
		- Whether software is accessible under open licenses, with rights to audit, modify, and redistribute, ensuring transparency and adaptability	- ソフトウェアがオープンライセンスで利用可能か、監査・修正・再配布の権利が付与されているか。透明性と適応性を確保する
		- Visibility into the design and functioning of the service, including architectural documentation, data flows, and dependencies	- サービスの設計と機能に関する可視性。これにはアーキテクチャ文書、データフロー、依存関係が含まれる。
		- Degree of EU independence in high-performance computing capabilities, including processors, accelerators, and software ecosystems.	- プロセッサ、アクセラレータ、ソフトウェアエコシステムを含む、高性能コンピューティング能力におけるEUの自立性の度合い。
SOV-7	セキュリティとコンプライアンスの主権	- Attainment of EU and internationally recognized certifications (e.g., ISO, ENISA schemes)	- EUおよび国際的に認められた認証（例：ISO、ENISAスキーム）の取得
		- Adherence to GDPR, NIS2, DORA, and other EU frameworks	- GDPR、NIS2、DORA、その他のEU枠組みへの準拠
		- Security Operations Centres and response teams operating exclusively under EU jurisdiction, control over security monitoring/logging - customer or EU authority ability to oversee logs, alerts, and monitoring functions directly.	- EUの管轄下で専ら運営されるセキュリティオペレーションセンター（SOC）および対応チーム。セキュリティ監視・ロギングの管理権限 - 顧客またはEU当局がログ、アラート、監視機能を直接監督する能力。
		- Transparent, timely, and EU-compliant reporting of breaches or vulnerabilities, maintenance Autonomy - ability to develop, test, and apply security patches independently of non-EU vendors	- 侵害や脆弱性に関する透明性のある、タイムリーでEU準拠の報告、保守自律性 - 非EUベンダーから独立してセキュリティパッチを開発、テスト、適用する能力
		- Capacity for EU entities to perform independent security and compliance audits with full access.	- EU 事業体が完全なアクセス権を持って独立したセキュリティおよびコンプライアンス監査を実施する能力。
SOV-8	環境持続可能性	- Adoption of energy-efficient infrastructure (e.g., low PUE) and measurable improvement targets.	- エネルギー効率の高いインフラ（例：低PUE）の採用と測定可能な改善目標。
		- Circular economy practices ensuring reuse, refurbishment, and responsible end-of-life treatment of hardware.	- ハードウェアの再利用、改修、責任ある廃棄処理を保証する循環経済の実践。
		- Transparent measurement and disclosure of carbon emissions, water usage, and other sustainability indicators.	- 炭素排出量、水使用量、その他の持続可能性指標の透明性のある測定と開示。
		- Sourcing of renewable or low-carbon energy to power infrastructure and operations	- インフラと運営に電力を供給するための再生可能エネルギーまたは低炭素エネルギーの調達。

---

参考...

● EUR-Lex

EUのデジタル主権を支える包括的サイバー安全保障戦略...

・2020.12.16 JOINT COMMUNICATION TO THE EUROPEAN PARLIAMENT AND THE COUNCIL The EU's Cybersecurity Strategy for the Digital Decade JOIN/2020/18 final

データ法

・2023.12.22 Regulation (EU) 2023/2854 of the European Parliament and of the Council of 13 December 2023 on harmonised rules on fair access to and use of data and amending Regulation (EU) 2017/2394 and Directive (EU) 2020/1828 (Data Act) (Text with EEA relevance) 

NIS2指令

・2022.12.27 Directive (EU) 2022/2555 of the European Parliament and of the Council of 14 December 2022 on measures for a high common level of cybersecurity across the Union, amending Regulation (EU) No 910/2014 and Directive (EU) 2018/1972, and repealing Directive (EU) 2016/1148 (NIS 2 Directive) (Text with EEA relevance)

データガバナンス法

・2022.06.03 Regulation (EU) 2022/868 of the European Parliament and of the Council of 30 May 2022 on European data governance and amending Regulation (EU) 2018/1724 (Data Governance Act) (Text with EEA relevance)

---

● まるちゃんの情報セキュリティ気まぐれ日記

・2021.11.08 英国 王立防衛安全保障研究所 (RUSI) 諜報機関が商用クラウドサービスを利用するということはどういうことか？

東京都産業労働局 中小企業向けサイバーセキュリティ対策の極意 Ver.4.0 (2025.12.23)

こんにちは、丸山満彦です。

東京都産業労働局の中小企業向けサイバーセキュリティ対策のガイドが更新されていました...

サプライチェーン上重要な中小企業が存在し、その中小企業がランサムウェアにより業務が停止したり、その中小企業を足場によりよりTierの高い企業への侵入につながったり、その中小企業から重要な情報が窃盗されたりすると、国の経済活動に多大な影響がでることがあり得る。

そのため、中小企業全部とは言わないが、企業の規模に関わらず経済活動にとって重要な企業はすべてサイバーセキュリティ対策を実施しておくことが必要となる。

ところが大企業に比較すると中小企業はリソースが限られている。サイバーセキュリティ対策は規模の経済が働く面が大きく、大企業と同じレベルのセキュリティ対策を中小企業が実施しようとすると、経済的になりたたなくなる。

と言う背景もあり、日本のみならず、世界各国で中小企業のサイバーセキュリティ対策というのは重要な政策課題となっています。（少なくとも2003年に経産省でサイバーセキュリティ戦略の議論をしている時からそうでした）。また、個人情報保護法のガイドラインを策定する際にも安全管理措置の面でもその議論はでました。

サイバー以外も含めてですが、J-SOXの議論の時も中小企業（ベンチャー）のIT内部統制の評価についても議論がありました。

規模の経済という構造的な問題なので、対策としては、

・「中小企業がまとまって」対策をする

・「コストを変動費にできる」対策をする

ということしかないと考えています。

お助け隊サービスはどちかというと前者の対策。クラウドサービスの利用は前者かつ後者ともいえると思います。と考えていくと、中小企業はセキュリティ対策を起点としても、クラウドシフトを加速することになります。

結果的に国の産業のクラウド依存が高まっていくことを意味します。欧州、英国、オーストラリア、（最近ではカナダ）ではソブリンクラウドのための制度づくりをしていますよね。。。（米国クラウドベンダーを締め出すのではなく、ソブリンクラウドの要件を決め、それに従っているサービスであれば採用をする一方で、欧州のクラウドベンダーの育成もしていく）

政府、重要インフラ以外にも多くの事業者がクラウドベンダーに依存していくと、集中リスクというのはあり得ますね...

この辺りは少し先の課題かもしれません...

ということで、話を元に戻して、東京都産業労働局の中小企業向けサイバーセキュリティ対策の極意 Ver.4.0 の紹介です。劇場風漫画形式となっています(^^)

●東京都 - 産業労働局 - 中小企業向けサイバーセキュリティ対策の極意ポータルサイト

・2025.12.23 [PDF]  Ver.4.0

---

日本の中小企業セキュリティガイドのようなもの...

発行元	タイトル	発行/更新年	概要
NISC（内閣サイバーセキュリティセンター、政府機関）	小さな中小企業とNPO向け 情報セキュリティハンドブック（インターネットの安全・安心ハンドブックに統合）	2023年 （Ver.5.00）	小規模事業者向けに基本的なセキュリティ対策をハンドブック形式でまとめたもの。パスワード管理や脅威対策を中心に。
総務省（政府機関）	中小企業等担当者向けテレワークセキュリティの手引き（チェックリスト）（第3版）	2022年 （第3版）	セキュリティ専任担当がいない中小企業等を対象に、テレワーク時の最低限のセキュリティ対策をチェックリスト形式で提供。テレワーク方式確認、脅威カテゴリ別の対策、緊急対応を含む。
IPA（独立行政法人情報処理推進機構）	中小企業の情報セキュリティ対策ガイドライン	2023年 （第3.1版）	経営者向け指針と実践的な対策手法をステップバイステップで説明。付録にチェックリストを含む。
東京都産業労働局	中小企業向けサイバーセキュリティ対策の極意	2025年 （Ver.3.0a）	漫画形式でわかりやすく、サイバー攻撃の現状と必須対策、事故対応を解説。Web版とPDF版あり。
愛知県	経済安全保障 中小企業向け 入門ガイド	2023年	経済安全保障の観点からサイバーセキュリティ対策を含む。従業員意識向上と体制整備を重点。
ITコンソーシアム京都（京都府関連、地方自治体支援）	セキュリティマニュアル	不明 （最新版参照）	京都府内中小企業向けにサイバー相談件数推移と対策をまとめたマニュアル。相談窓口情報あり。

---

米国、欧州、英国、オーストラリア、カナダ等の主に中小企業向けのセキュリティガイドのようなもの...

国・地域	組織	発行元	タイトル	発行/ 更新年	概要
米国	連邦政府機関	CISA	Cyber Guidance for Small Businesses	2024年	小規模事業者向けの行動計画。CEO、セキュリティマネージャー、ITリーダーの役割ごとに分かれ、MFA導入やバックアップなどの対策を説明。実際の攻撃に基づく。
米国	連邦政府機関	CISA	Cyber Essentials	2023年	小規模事業者や地方自治体リーダー向けのガイド。アクショナブルな理解を促進し、サイバーハイジーンを強調。
米国	連邦政府機関	FTC	Cybersecurity for Small Business	継続（最新2025年）	サイバー攻撃から事業を守るツール。NIST CSF 2.0 Quick Start Guideを基に、ガバナンスとリスク管理を解説。
米国	連邦政府外郭	NIST	Small Business Cybersecurity Corner	継続（最新2025年）	寄稿者からのドキュメントとリソース集。小規模事業者のサイバーセキュリティニーズに対応。
米国	連邦政府機関	SBA	Strengthen your Cybersecurity	2024年	脅威の概要と保護方法。CISAのスキャニングサービスなどを紹介。
米国	連邦政府機関	FCC	Cybersecurity for Small Businesses	継続（最新2025年）	Small Biz Cyber Planner 2.0を提供。カスタマイズされたサイバーセキュリティ計画作成ツール。
米国	連邦政府機関	DoD Office of Small Business Programs	Cybersecurity Resources	継続（最新2025年）	意識向上とコンプライアンスのためのツールとトレーニングプラットフォーム。
米国	州政府機関	California Attorney General	Guide for Small Businesses to Protect Against Cyber Attacks	2014年	従業員と顧客のリスク低減のための具体的な推奨事項。
米国	州政府機関	New York Attorney General	Small Business Guide to Cybersecurity in New York State	不明（最新2023年）	NY州中小企業向けのデータセキュリティガイド。
米国	州政府機関	New York Attorney General	Data Security Guide	2023年	効果的なデータセキュリティ対策の採用を支援。
米国	州政府機関	Texas State Securities Board	Are You Secure?	継続（最新2025年）	サイバーリスクの特定と手順の確立のための計画ガイド。
欧州	連合機関	ENISA	Cybersecurity Guide for SMEs - 12 Steps to Securing Your Business	2021年	COVID-19後のデジタル移行を考慮した12のハイレベルステップ。システムと事業のセキュリティ向上。
欧州	連合機関	ENISA	Cybersecurity for SMEs - Challenges and Recommendations	2021年	SMEの課題と推奨事項。加盟国がSMEを支援するための提案を含む。
欧州	連合外郭	European DIGITAL SME Alliance	Guide to ISO/IEC 27001 for SMEs	継続（最新2025年）	ISO 27001の実装のためのハンディガイド。
ドイツ	連邦政府機関	BSI	Small and Medium-Sized Enterprises Guidance	継続（最新2025年）	サイバーセキュリティの基本要素と短い動画。情報セキュリティのキーアスペクトをカバー。
フランス	政府機関	ANSSI	Digital Security Best Practices for Business Travellers	2019年	出張中のデジタルセキュリティベストプラクティス。
フランス	政府機関	ANSSI	Controlling the Digital Risk	不明（最新2025年）	組織のデジタルリスク管理ガイド。
イタリア	政府機関	ACN	Practical Guides for SMEs on Cyber Risks	2025年	SME向けの実用的ガイド。サイバーリスクの特定と管理。
イタリア	政府機関	Cyber 4.0	Vademecum on Cybersecurity for SMEs	継続（最新2025年）	ENISAの12ステップを基にしたSME向けガイド。
スペイン	政府機関	INCIBE	Spanish National Guidelines for Reporting and Managing Cyber Incidents	2020年	サイバーインシデントの報告と管理のためのガイドライン。
スペイン	政府機関	INCIBE	Cybersecurity for SMEs and Freelancers	2023年	デジタル世界での事業保護。セクター別のアドバイスを含む。
英国	政府機関	NCSC	Small Business Guide: Cyber Security	継続（最新2025年）	5つの簡単ステップ（バックアップ、マルウェア対策、モバイルセキュリティ、パスワード、フィッシング）。時間とお金を節約。
英国	政府機関	NCSC	Cyber Security: Small Business Guide (PDF Version)	継続（最新2025年）	一般的な攻撃からの保護のための低コストでシンプルなテクニックのまとめ。
英国	政府機関	GOV.UK	Cyber Security Guidance for Business	継続（最新2025年）	オンラインセキュリティ向上のためのガイダンス。無料の30分セッションを含む。
英国	地方	NI Cybersecurity Centre	Basic Steps to Cyber Security – Small Organisation Guide	継続（最新2025年）	5つの簡単ステップでセキュリティ向上。評判保護に焦点。
英国	市政府	Bury Council	Cyber Security Guide For Small Businesses	継続（最新2025年）	攻撃の兆候、保護方法、無料リソースのリンク。
英国	市政府	Wandsworth Council	Cyber Security: Small Business Guide	継続（最新2025年）	バックアップ、パスワードポリシー、アクセス制御の決定。
英国	地方関係	Northwest Cyber Resilience Centre	Cyber Security Guide for Small Businesses	継続（最新2025年）	北西地域の小規模事業者向け。基本、ランサムウェアなどカバー。
豪州	政府機関	ACSC	Small Business Cyber Security Guide	2023年（最新2025年）	基本的なセキュリティ対策を説明。サイバー脅威からの保護に焦点を当て、チェックリストを含む。
豪州	政府機関	ACSC	Small Business Cloud Security Guides	2022年（最新2025年）	Essential Eightをクラウド環境に適用したガイド。Microsoft 365、Google Workspaceなどの具体例。
豪州	政府機関	Business.gov.au	Cyber Security and Your Business	継続（最新2025年）	サイバー脅威の種類と被害対応。ACSCのリソースを統合した一般ガイド。
豪州	州自治体	NSW Government	7 Steps to Cybersecurity for Small Businesses	継続（最新2025年）	小規模事業者向けの7ステップガイド。脅威認識から回復計画まで。
豪州	州自治体	NSW Small Business Commissioner	Cyber Security Awareness	継続（最新2025年）	マルウェア対策とバックアップの基本。ACSCガイドを補完。
豪州	州自治体	Business Victoria	Manage Cybersecurity in Your Business	2025年	サイバー犯罪の理解と保護方法。報告手順を含む。
豪州	州自治体	Business Victoria	The Essential Small Business Guide to Cybersecurity	2021年	一般的な脅威と安全策。ACSCに基づく。
豪州	州自治体	Business Queensland	Keeping Your Business Cyber Secure	2025年	Cyber Wardensプログラムを含む対策。脅威防止の短いコース。
豪州	州自治体	Business Queensland	Cyber Security Self-Help Toolkit for Mentors	2021年	メンター向けツールキット。事業者のリスク管理支援。
豪州	州自治体	Small Business Development Corporation	Cyber Security	継続（最新2025年）	情報保護の簡単で効果的な方法。サイバー犯罪者からの防御。
豪州	州自治体	Small Business Development Corporation	Six Cyber Security Habits to Protect Your Business	継続（最新2025年）	悪い習慣の修正と6つの積極的ステップ。
カナダ	政府機関	CCCS	Baseline Cyber Security Controls for Small and Medium Organizations	2020年	低コストの13セキュリティコントロール。リスク低減と対応力向上。
カナダ	政府機関	CCCS	Cyber Security for Small Business	2020年	基本コントロールの実装支援。サイバー敵対者からの保護。
カナダ	政府機関	Get Cyber Safe	Get Cyber Safe Guide for Small and Medium Businesses	2022年	リスク理解と対策ステップ。中小企業オーナー向け。
カナダ	政府機関	Get Cyber Safe	Get Cyber Safe Guide for Small Businesses	2024年	脅威軽減のためのステップ。デバイス、ネットワーク、データ保護。
カナダ	政府機関	Get Cyber Safe	Quick Guide to Cyber Security for Small Business	2024年	6つの簡単ステップ：在庫管理から従業員トレーニングまで。
カナダ	政府機関	CyberSecure Canada	CyberSecure Canada	継続（最新2025年）	ベストプラクティスを使用したプログラム。SMEのセキュリティ強化。
カナダ	省自治体	Ontario Government	Cyber Security	2021年	サイバーセキュリティの基本と役割。
カナダ	省自治体	Alberta Government	Government of Alberta Cybersecurity Strategy 2024	2024年	脅威情報とリソース提供。SMEを含むデジタル資産保護。
カナダ	省自治体	British Columbia Government	CyberBC	2025年	公共セクターのセキュリティ向上。SME支援のためのコラボレーション。