クラウド

2026.04.11

欧州 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 

20260411-74521

 

目次...

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 履歴

 

 

| | Comments (0)

2026.04.05

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

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

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

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

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


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

<脚注>

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

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


 

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


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

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

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


20260404-153201

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

20260404-153744

 

● 経済産業省

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

目次...


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

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

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

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

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

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


 

国家サイバー統括室

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

 

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

 

| | Comments (0)

2026.03.30

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

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

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

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


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

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

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

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

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

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

4.その他

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

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


20260329-53002

 

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

20260329-62152

 

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

20260329-62241

 

 

 

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

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

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

20260329-61653

 

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

20260329-61736

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

20260329-61916

 

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

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

  • 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 「サイバー攻撃に無防備、193自治体」だそうです。。。

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

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

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

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

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

・2008.08.23 総務省 確定 「地方公共団体におけるICT部門の業務継続計画(BCP)策定に関するガイドライン」

・2008.06.28 総務省 パブコメ 「地方公共団体におけるICT部門の業務継続計画(BCP)策定に関するガイドライン」(案)

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

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

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

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

・2007.04.02 総務省 自治体ISAC(仮称)実証実験の実施結果

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

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

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

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

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

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

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

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

 

 

| | Comments (0)

2026.03.18

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

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

NISTが、SP 800-228 クラウドネイティブシステム向けAPI防御ガイドライン。昨年6月に公開されたバージョンの更新版。附属書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

20260317-90114

・[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防御ガイドライン

| | Comments (0)

2026.03.10

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

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

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

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

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

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


◼ 影響

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

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

◼ 求められる対応

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

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

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

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

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

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


 

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


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

⚫ 具体的には:

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


 

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

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

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

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

3. 「SolarWinds型」

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

 

● ICT-ISAC

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

20260310-63726

 

| | Comments (0)

2026.02.01

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関連アイデンティティの作成を追跡していないと回答した。これにより、トークンやサービスアカウントの増加するサブセットが正式なインベントリから除外された状態にある。

 

20260130-190901

 

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

| | Comments (0)

2026.01.19

ドイツ 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

20260117-181108

・[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) 諜報機関が商用クラウドサービスを利用するということはどういうことか?

 

| | Comments (0)

2026.01.09

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

・2025.12.23 [PDF]  Ver.4.0

20260107-65211

 

 

 


 

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

発行元 タイトル 発行/更新年 概要
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支援のためのコラボレーション。

 

 

| | Comments (0)

2026.01.08

米国 CSET A米国のAI外交戦略 - 湾岸諸国との取引から国際枠組みへ (2025.10)

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

昨年やり残していたことをしばらく...サイバー空間と新興技術に関する安全保障政策を主導する組織である米国のワシントンDCにあるCenter for Security and Emerging Technology:CSET(安全保障・新興技術センター)[wikipedia]から公表されている報告書をいくつか紹介します... 

 

AI資源を外交に使おうという発想です。AIは広い意味でも生産性向上の不可欠な要素となってきています。現在のところAIサービスを提供する能力という意味では米国が圧倒的に有利な状況にいて、各国がそれを追いかける状況となっています。特に中国は米国の影響をできる限り避けるためにも国をあげて独自のAI開発を進めていますよね...もちろん、欧州も欧州連合がイニシアティブをとって進めていますし、英国もそうです。日本ももちろんそうなのですが、まだピリッとした感じがしないのは気のせいですかね...

さて、米国の立場からするとこの状況をうまく外交のカードとして使うことが重要となってきます。特に中国や欧州が台頭してくる前に有利な状況を作っておく必要があると言えます。そこでAI外交戦略が重要となってきているのかもしれません...

CSETが10月に公表した報告書では湾岸諸国でのAI関連の国家的取り組みについての分析を通じてAI外交戦略の立案の重要性が説明されています。特に米国の立場だと法の支配と民主主義的な価値観(ちょっと揺らぎつつあるのかもしれませんが...)をベースとした価値観とパッケージ化し、AI資源を、ここのケースに応じた1企業対外国政府という形態から、国家戦略に基づくAI外交フレームワークに基づいた戦略的な国際枠組みに変えていくことが重要となっています。要は、米国の利益のためのAI資源をどのように使うのか?ということになります。

で、この報告書での提案...

1. Establish a Structured, Rules-Based Framework for Access to U.S. AI 1. 米国AIへのアクセスに関する構造化されたルールベースの枠組みを確立する
2. Build a Layered Governance Architecture for AI Infrastructure   2. AIインフラのための多層的ガバナンス構造を構築する  
3. Align Institutional Capacity with Strategic Objectives  3. 戦略目標と機構的能力の整合化 
4. Launch an AI Cooperation Forum to Build Strategic Alignment  4. 戦略的連携を構築するための AI 協力フォーラムを立ち上げる 

もっともな話だと思います。おそらく、今後米国はAI資源を外交のカードとして利用してくると思います。そうなったときに日本はどうするのか?ということになります。

日本が取りうるオプションはいくつかあるとは思います。例えば、(1)日米垂直統合(日本が米国のAI資源の不可欠な一部になる)、(2)日本完結(日本が独自のソブリンAIをつくり運用する。ハード、ソフトとも揃える)、(3)多国間協力(多国間での連携体をつくり開発・運用する)

 

(1)はおそらく米国がYesと言わないのでありえないと思います。となると、(2)か(3)。

どちらも難しいですが、早く決めないとオプションがどんどん減っていくかもですね...

 

CSET

・2025.10 U.S. AI Statecraft - From Gulf Deals to an International Framework

U.S. AI Statecraft - From Gulf Deals to an International Framework 米国のAI外交戦略 - 湾岸諸国との取引から国際枠組みへ
Recent U.S.-Gulf AI partnerships represent billions of dollars in strategic technology deals, but they raise critical questions about governance, oversight, and long-term influence. This analysis examines four major AI initiatives with Saudi Arabia and the United Arab Emirates, discussing critical issues including fragmented oversight, technology diversion, and AI sovereignty. It proposes a framework to transform ad hoc dealmaking into principled, transparent, and rule-bound AI statecraft that advances U.S. interests, strengthens technology relationships with allies and partners, and establishes durable governance mechanisms for U.S. AI deployments abroad. 最近の米国と湾岸諸国とのAI提携は、数十億ドル規模の戦略的技術取引を意味するが、ガバナンス、監督体制、長期的な影響力に関する重大な疑問を提起している。本分析はサウジアラビアおよびアラブ首長国連邦との4つの主要AIイニシアチブを検証し、断片化した監督体制、技術の転用、AI主権といった重要課題を論じる。その上で、米国利益の推進、同盟国・パートナーとの技術関係の強化、海外における米国AI展開のための持続可能なガバナンス体制構築を実現するため、場当たり的な取引を原則・透明性・ルールに基づくAI外交へと転換する枠組みを提案する。

・[PDF]

20260105-123547

・[DOCX][PDF] 仮訳

 

目次...

Introduction 序論
Overview of Major U.S.–Gulf AI Initiatives (2024–2025) 主要な米国・湾岸諸国AIイニシアチブ概要(2024-2025年)
Microsoft–G42 Partnership (UAE, 2024) マイクロソフト–G42提携(UAE、2024年)
Stargate UAE AI Campus (UAE, 2025) スターゲートUAE AIキャンパス(UAE、2025年)
AWS–HUMAIN AI Zone Initiative (KSA, 2025) AWS–HUMAIN AIゾーン構想(サウジアラビア、2025年)
NVIDIA–HUMAIN Partnership (KSA, 2025) NVIDIA–HUMAINパートナーシップ(サウジアラビア、2025年)
Structures of U.S.–Gulf AI Partnerships 米国と湾岸諸国間のAIパートナーシップ構造
What Remains Uncertain, and Why It Matters 不透明な点とその重要性
Policy Recommendations: A U.S. Framework for an International AI Infrastructure 政策提言:国際AIインフラのための米国枠組み
Conclusion: From Transactions to Frameworks 結論:取引から枠組みへ
Endnotes 脚注

 

 

 

 

 

| | Comments (0)

2026.01.07

欧州 サイバーセキュリティ法の改正に向けた動き... (2025.12.09)

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

すこし古い話です(^^;;  サイバーセキュリティ法(CSA)改正に関するはなし...

EUのサイバーセキュリティ関係法はデータ関連の法令も併せて混乱気味ですよね...

サイバー領域でも、CSAに続いてNIS2、サイバーレジリエンス法(CRA)、DORAが後から制定されました。規制簡素化はEUの重要なアジェンダですよね...

また、2019年から比較すると、地政学的な状況も変わってきています。2004年に時限的につくられたENISAが2019年のCSAにより恒久組織化されたわけですが、その後新たにいろいろと役割も追加されてきていることもあり、CSAで再定義する必要があるようです。

EUでは安全保障は各国ですることになっていますが、サイバーセキュリティは安全保障とのつながりが強いため、EUで機関をおかない(おいても時限的)と言う流れだったようです...2004年ENISA設置当時の話では...

さらに、欧州サイバーセキュリティ認証枠組み(ECCF)もうまくいっていない面もあり、再度調整が必要そうです。

クラウド認証(EUCS)の導入をめぐっては、主権要件をいれるかどうかで意見が分かれているようです...

この文書は、EUのサイバーセキュリティ法制度の今後の方向性を大まかに理解する上でも読んでおいた方が良いと思いました...

 

European Parliament - Think Tank

・2025.12.09 Cybersecurity Act review: What to expect

Cybersecurity Act review: What to expect サイバーセキュリティ法の見直し:今後の見通し
The Cybersecurity Act (CSA) came into force in 2019 as part of the EU's efforts to build strong cybersecurity. Since its introduction, the EU cybersecurity regulatory framework has become more complex in response to the rise in cyber-attacks. New EU rules, as well as changes in the geopolitical context, have impacted the CSA, and the regulation is currently under review. Although stakeholders are aligned on most issues, significant differences remain, notably in addressing non-technical risks relating to the security of the information and communications technology (ICT) supply chain. サイバーセキュリティ法(CSA)は、EUが強力なサイバーセキュリティを構築する取り組みの一環として2019年に施行された。導入以来、サイバー攻撃の増加に対応し、EUのサイバーセキュリティ規制枠組みはより複雑化している。新たなEU規則や地政学的状況の変化がCSAに影響を与え、現在見直しが進められている。関係者の間では大半の課題で意見が一致しているが、情報通信技術(ICT)サプライチェーンのセキュリティに関連する非技術的リスクへの対応など、重要な相違点は依然として残っている。

 

・[PDF]

20260106-195118

 

Cybersecurity Act review: What to expect サイバーセキュリティ法の見直し:今後の見通し
The Cybersecurity Act (CSA) came into force in 2019 as part of the EU's efforts to build strong cybersecurity. Since its introduction, the EU cybersecurity regulatory framework has become more complex in response to the rise in cyber-attacks. New EU rules, as well as changes in the geopolitical context, have impacted the CSA, and the regulation is currently under review. Although stakeholders are aligned on most issues, significant differences remain, notably in addressing non-technical risks relating to the security of the information and communications technology (ICT) supply chain. サイバーセキュリティ法(CSA)は、EUが強力なサイバーセキュリティを構築する取り組みの一環として2019年に施行された。導入以来、サイバー攻撃の増加に対応し、EUのサイバーセキュリティ規制枠組みはより複雑化している。新たなEU規則や地政学的状況の変化がCSAに影響を与え、現在見直しが進められている。関係者の間では大半の課題で意見が一致しているが、情報通信技術(ICT)サプライチェーンのセキュリティに関連する非技術的リスクへの対応など、重要な相違点は残っている。
The Cybersecurity Act in short サイバーセキュリティ法の概要
Regulation (EU) 2019/881 (the CSA) formalised the role of the European Cybersecurity Agency (ENISA), giving it a permanent mandate, resources and tasks, including operational ones. It also established a voluntary EU cybersecurity certification framework (ECCF) for ICT products, services and processes. The ECCF aims to set up and maintain specific certification schemes, allowing companies operating in the EU to use the certificates recognised across all Member States. In January 2025, a targeted amendment to the CSA was adopted, to enable the future adoption of European certification schemes for 'managed security services' covering areas such as incident response, penetration testing, security audits and consultancy. The CSA requires an evaluation and review every five years. Postponed several times, this is now expected on 14 January 2026. 規則(EU)2019/881(CSA)は欧州サイバーセキュリティ庁(ENISA)の役割を正式に定め、恒久的な権限・資源・任務(運用面を含む)を付与した。またICT製品・サービス・プロセス向けの任意参加型EUサイバーセキュリティ認証枠組み(ECCF)を設立した。ECCFは特定の認証スキームを確立・維持し、EU域内で事業を行う企業が全加盟国で認められる認証を利用できるようにすることを目的としている。2025年1月には、インシデント対応、ペネトレーションテスト、セキュリティ監査、コンサルティングなどの分野をカバーする「マネージドセキュリティサービス」向けの欧州認証スキームを将来的に導入可能とするため、CSAの特定改正が採択された。CSAは5年ごとの評価と見直しを義務付けている。数度延期された後、現在は2026年1月14日に実施が予定されている。
Evolving context 変化する状況
Since the CSA entered into force, cyber-attacks have been on the rise. This has prompted new EU cybersecurity laws to address the growing number and complexity of cyber threats. As a result, ENISA's roles and responsibilities have expanded. For example, ENISA supports implementation of the Directive on measures for a high common level of cybersecurity across the Union (NIS2) by providing technical guidelines, facilitating information sharing, and enhancing coordination between Member States. Similarly, ENISA supports implementation and enforcement of the Cyber Resilience Act (CRA) by providing technical expertise, developing a single reporting platform for vulnerability and incident reporting, and supporting cybersecurity certification schemes. CSA発効以降、サイバー攻撃は増加傾向にある。これにより、増加するサイバー脅威の数と複雑性に対処するため、新たなEUサイバーセキュリティ法が制定された。結果として、ENISAの役割と責任は拡大した。例えば、ENISAは技術ガイドラインの提供、情報共有の促進、加盟国間の連携強化を通じて、EU全域における高度な共通サイバーセキュリティ水準確保のための措置に関する指令(NIS2)実施を支援している。同様に、ENISAは技術的専門知識の提供、脆弱性・インシデント報告のための単一プラットフォームの開発、サイバーセキュリティ認証スキームの支援を通じて、サイバーレジリエンス法(CRA)実施と執行を支援している
As regards certification, implementation of the ECCF has been challenging. So far, only one EU certification scheme has been adopted – the European cybersecurity scheme on common criteria (EUCC), dedicated to certifying ICT products. All other schemes (cloud services – EUCS, 5G, digital identity wallets and managed security services) are still under development. Additionally, there are concerns whether the ECCF effectively addresses non-technical supply-chain cybersecurity risks such as geopolitical dependencies. Questions have also been raised about how voluntary certification frameworks will align with the CRA, which establishes a presumption of conformity (in Article 27) for products certified under a recognised European scheme such as the EUCC. 認証に関しては、ECCFの実施は困難を極めている。現時点で採用されているEU認証スキームは、ICT製品の認証に特化した共通規準に基づく欧州サイバーセキュリティスキーム(EUCC)のみである。その他のスキーム(クラウドサービス向けEUCS、5G、デジタルIDウォレット、およびマネージドセキュリティサービス向け)はいずれも開発段階にある。さらに、ECCFが地政学的依存関係などの非技術的サプライチェーンサイバーセキュリティリスクを効果的に対処できるか懸念されている。また、EUCCのような認定欧州スキームで認証された製品に対して適合性の推定第27条)を定めるCRAと、任意認証枠組みがどのように整合するかも疑問視されている。
The proposal for a revised CSA therefore aims to address both ENISA's growing responsibilities and ECCF implementation. During the consultation, the Commission also gathered views on ICT supply chain security challenges and the simplification of cybersecurity rules, such as how to streamline reporting obligations. したがって、改正CSA提案は、ENISAの拡大する責任とECCF実施の両方に対処することを目的としている。協議期間中、欧州委員会はICTサプライチェーンのセキュリティ課題やサイバーセキュリティ規則の簡素化(報告義務の効率化方法など)に関する意見も収集した。
CSA review: Points of convergence among stakeholders CSA見直し:ステークホルダー間の合意点
The replies to the call for evidence for the CSA review have shown broad agreement that the CSA should be revised on the following issues: (i) streamline cybersecurity measures; (ii) enhance cyber resilience; and (iii) simplify the EU regulatory landscape. The review is seen as an opportunity to reduce administrative burden and compliance costs. A significant convergence point is the need to harmonise definitions and reporting requirements across major EU acts – such as NIS2, CRA and the General Data Protection Regulation (GDPR) – and establish a single EU incident notification platform. Such a platform has now been put forward in the proposal for a 'digital omnibus' regulation. CSA見直しに向けた証拠提出要請への回答からは、以下の点でCSAを改正すべきとの広範な合意が示された:(i) サイバーセキュリティ対策の効率化、(ii) サイバーレジリエンスの強化、(iii) EU規制環境の簡素化。この見直しは行政負担とコンプライアンスコストを削減する機会と見なされている。主要なEU法令(NIS2、CRA、一般データ保護規則(GDPR)など)における定義と報告要件の調和、および単一のEUインシデント通知プラットフォーム確立が必要であるという点で、大きな合意が得られた。このようなプラットフォームは、「デジタルオムニバス」規制の提案において現在提唱されている。
There is consensus that ENISA's mandate should be clarified and strengthened to reflect the agency's growing operational responsibilities under new EU rules such as NIS2 and CRA. Stakeholders note that this expansion should be matched by adequate financial resources and staffing in order to ensure the agency's effectiveness. The view is that ENISA should serve as a central technical coordinator, to promote consistency and harmonise implementation of EU cybersecurity laws across the Member States, thereby reducing regulatory divergence. This echoes the Council conclusions of December 2024 on a stronger EU Agency for Cybersecurity. Poland went as far as calling for a separate law for ENISA, to separate this item from potential controversy around the EUCS discussions. NIS2やCRAといった新たなEU規則下でENISAの業務責任が増大していることを反映し、ENISAの権限を明確化・強化すべきという点で合意が形成されている。関係者らは、この権限拡大には十分な財政資源と人員配置が伴わなければ、機関の有効性が確保できないと指摘する。ENISAは中核的な技術調整機関として機能し、加盟国間でEUサイバーセキュリティ法の一貫性と調和を促進し、規制の乖離を縮小すべきだという見解だ。これは、2024年12月の理事会結論「強化されたEUサイバーセキュリティ機関」の趣旨と一致する。ポーランドはさらに踏み込み、ENISAのための独立した法律を制定し、EUCS議論に伴う潜在的な論争からこの項目を切り離すよう求めた。
Stakeholders widely acknowledge that the process for developing and adopting certification schemes is too slow and opaque. They highlight that a more agile, transparent and inclusive process with clearer timelines is urgently needed. Furthermore, stakeholders underline that certification schemes should be based on and align with international standards in order to ensure global interoperability, maximise acceptance, and reduce compliance costs for companies operating internationally. The prevailing view is that certification schemes should also be leveraged as a recognised means of demonstrating conformity or compliance with security requirements stemming from other major EU legislative acts, including NIS2, CRA and the AI Act. 関係者らは広く、認証スキームの開発・採択プロセスが遅く不透明すぎることを認めている。彼らは強調する、より機敏で透明性が高く包括的なプロセスと明確なタイムラインが緊急に必要だと。さらに、ステークホルダーは、認証スキームが国際標準に基づき整合性を保つべきだと強調する。これにより、国際的な相互運用性を確保し、受容性を最大化し、国際的に事業を展開する企業のコンプライアンスコストを削減できるからだ。認証スキームは、NIS2、CRA、AI法を含む他の主要なEU立法措置から生じるセキュリティ要件への適合性またはコンプライアンスを証明する公認手段としても活用されるべきだという見解が主流だ。
Potential challenges 潜在的な課題
Disagreements revolve around the specific content and scope of certification schemes, particularly regarding sovereignty and the legal limits of ENISA's influence. The most contentious point is the inclusion of sovereignty requirements in certification schemes such as the EUCS. This issue divides stakeholders into those advocating measures to protect European digital autonomy (e.g. both data localisation and corporate headquarters based in the EU) and those prioritising open markets and technical neutrality. Pro-sovereignty advocates, and stakeholders supporting 'cloud by Europe' models (i.e. entirely EU-based cloud service providers, not controlled by non-EU stakeholders), argue that these measures are crucial to protecting sensitive data and reinforcing EU strategic autonomy. By contrast, major tech companies, such as Microsoft, Amazon and Google, argue that non-technical criteria are subjective and do not improve cybersecurity outcomes, potentially restricting market access and innovation. At Member State level, too, positions are divided, with some countries expressing concern over sovereignty requirements, and others advocating in their favour. 意見の相違は、認証スキームの具体的な内容と範囲、特に主権とENISAの影響力の法的限界に関する点に集中している。最も議論の的となる点は、EUCSなどの認証スキームに主権要件を含めることである。この問題は利害関係者を、欧州のデジタル自律性を防御する措置(例:データローカリゼーションとEU域内に本社を置く企業の両方)を主張する側と、開放的な市場と技術的中立性を優先する側に分断している。主権重視派や「欧州発クラウド」モデル(非EU関係者に支配されない完全EU拠点のクラウドプロバイダ)を支持する関係者は、こうした措置が機密データの保護とEUの戦略的自律性強化に不可欠だと主張する。一方、Microsoft、AmazonGoogleなどの大手テック企業は、非技術的基準は主観的でサイバーセキュリティ効果を高めず、市場参入やイノベーションを阻害する可能性があると反論する。加盟国レベルでも立場は分かれており、一部の国々は主権要件に懸念を表明する一方、他の国々はこれを支持している。
On the nature of certification, the majority view is that it should remain mostly voluntary, to maintain flexibility and innovation. However, mandatory certification in critical sectors where high-security assurance is essential was also proposed. In addition, ENISA's regulatory power has sparked debate. Some stakeholders, including Amazon, oppose granting ENISA the authority to issue binding opinions or regulatory guidance, arguing that its role should remain technical and advisory. 認証の性質については、柔軟性と革新性を維持するため、主に任意のままであるべきという見解が大多数を占める。しかし、高いセキュリティ保証が不可欠な重要分野における義務的認証も提案された。加えて、ENISAの規制権限も議論を呼んでいる。Amazonを含む一部の利害関係者は、ENISAに拘束力のある意見や規制ガイダンスを発行する権限を与えることに反対し、その役割は技術的・助言的なものに留まるべきだと主張している。
It remains to be seen to what extent the Commission will consider stakeholders' views. The CSA review will also need to fit into the simplification of cybersecurity-related incident reporting obligations, which are part of the 'digital omnibus' proposal published on 19 November 2025. 欧州委員会が利害関係者の意見をどの程度考慮するかは、まだ見通せない。CSAの見直しは、2025年11月19日に公表された「デジタルオムニバス」提案の一部である、サイバーセキュリティ関連のインシデント報告義務の簡素化にも適合させる必要がある。

 

 

 

参考まで...

分類 法令名 種別 概要 発効日 適用開始日
個人データ保護 GDPR(Regulation (EU) 2016/679) 規則 EU全域の個人データ保護の基盤となる包括規則 2016.05.24 2018.05.25
データ共有・流通 Data Governance Act(Regulation (EU) 2022/868) 規則 データ共有の信頼性確保・データ仲介サービスの規律 2022.06.23 2023.09.24
Data Act(Regulation (EU) 2023/2854) 規則 IoT等のデータアクセス権・データ共有義務を定める横断規則 2024.01.11 2025.09.12 段階的
デジタル市場・プラットフォーム Digital Services Act(Regulation (EU) 2022/2065) 規則 プラットフォームの透明性・違法コンテンツ対策を統一規制 2022.11.16 2024/2/17  VLOPs/VLOSEsは2023.08.25
Digital Markets Act(Regulation (EU) 2022/1925) 規則 GAFA等ゲートキーパー企業の市場支配力を規制 2022.11.01 2023.05.02
AI AI Act(Regulation (EU) 2024/1689) 規則 リスクベースでAIを規制し、高リスクAIに義務を課す 2024.08.01 2025〜2027年に段階的適用
サイバーセキュリティ Cybersecurity Act(Regulation (EU) 2019/881) 規則 ENISA恒久化とEUサイバーセキュリティ認証制度(ECCF)創設 2019.06.27 2019.06.27〜認証は段階的
NIS2 Directive(Directive (EU) 2022/2555) 指令 重要事業体のサイバー義務・インシデント報告を強化 2023.01.16 2024.10.17までに国内法化
製品セキュリティ CRA(Cyber Resilience Act)Regulation (EU) 2024/2847 規則 ソフトウェア・IoT等の製品に「セキュリティ・バイ・デザイン」を義務化し、脆弱性管理・報告を規定
2024.12.10 2027.12.11から適用開始。製造者の脆弱性報告義務は2026.09.11から
金融ICTレジリエンス DORA(Regulation (EU) 2022/2554) 規則 金融セクターのICTリスク管理・インシデント報告を統一 2023.01.16 2025.01.17

 

 


参考...

ENISA

EUサイバーセキュリティ認証の声

・2025.12.15 Voices of EU Cybersecurity Certification

Voices of EU Cybersecurity Certification EUサイバーセキュリティ認証の声
A special publication by ENISA that incorporates feedback from stakeholders involved in building, maintaining, operating, and applying the first EU cybersecurity certification schemes. ENISAによる特別刊行物。EU初のサイバーセキュリティ認証スキームの構築、維持、運用、適用に関わる関係者からのフィードバックをまとめたものである。

 

・[PDF

20260106-212011

 

| | Comments (0)

より以前の記事一覧