米国 NIST SP 800-63-4（第2次公開草案）デジタル・アイデンティティ・ガイドライン他...

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

NIST SP 800-63-4（第2次公開草案）デジタル・アイデンティティ・ガイドラインが公表され、意見募集されていますね...

4,000通を超えるコメントがあったため、このドラフトの発表が遅れたのでしょうかね...

NIST SP 800-63-4 (2nd Public Draft) Digital Identity Guidelines	NIST SP 800-63-4（第2次公開草案）デジタル・アイデンティティ・ガイドライン
NIST SP 800-63A-4 (2nd Public Draft) Digital Identity Guidelines: Identity Proofing and Enrollment	NIST SP 800-63A-4（第 2 次公開草案）デジタル・アイデンティティ・ガイドライン： アイデンティティ証明および登録
NIST SP 800-63B-4 (2nd Public Draft) Digital Identity Guidelines: Authentication and Authenticator Management	NIST SP 800-63B-4（第 2 次公開草案）デジタル・アイデンティティ・ガイドライン： 認証および認証子管理
NIST SP 800-63C-4 (2nd Public Draft) Digital Identity Guidelines: Federation and Assertions	NIST SP 800-63C-4（第 2 次公開草案）デジタル・アイデンティティ・ガイドライン： フェデレーションおよびアサーション

4つ合わせて467ページです...これは国力だ(^^)

こちらを参考に...

崎村さんのブログ

● @_Nat Zone - Identity, Privacy, and Music

・2024.08.22 NIST SP800-63-4 デジタルアイデンティティガイドライン更新：セキュリティと利便性の両立を目指して

富士榮さんのブログ

● IdM実験室

・2024.08.23 NIST SP800-63-4のSecond Public Draftが出てきました

● NIST - ITL

プレス...

・2024.08.21 NIST Releases Second Public Draft of Digital Identity Guidelines for Final Review

NIST Releases Second Public Draft of Digital Identity Guidelines for Final Review	NIST がデジタル・アイデンティティ・ガイドラインの第 2 次公開草案を発表し、最終レビューを求める
・NIST is offering updated guidance on a wide range of methods people use to prove their identity, from digital wallets and passkeys to physical IDs.	・NIST は、デジタル・ウォレットやパスキーから物理的アイデンティティ に至るまで、人々が自分の アイデンティティを証明するために使用する幅広い方法について、最新のガイダンスを提供している。
・The guidance aims to ensure security, privacy and accessibility during the identity-proofing process for people accessing government services.	・このガイダンスは、政府サービスにアクセスする人の アイデンティティ証明プロセスにおいて、セキュリ ティ、プライバシー、およびアクセシビリティを確保することを目的としている。
・NIST is seeking public comments on the draft guidelines through Oct. 7, 2024.	・NIST は、2024 年 10 月 7 日までガイドライン草案に対するパブリック・コメントを募集している。
GAITHERSBURG, Md. — When we need to show proof of identity, we might reach for our driver’s license — or perhaps, sooner than many of us imagine, we may opt for a digital credential stored on a smartphone. To ensure we can use both novel and time-tested methods to prove our identities securely when accessing essential services, the U.S. Department of Commerce’s National Institute of Standards and Technology (NIST) has updated its draft digital identity guidance.	マサチューセッツ州ゲーサーバーグ - 身分証明を示す必要があるとき、私たちは運転免許証に手を伸 ばすかもしれない。あるいは、私たちの多くが想像しているよりも早く、スマートフォン に保存されたデジタル・クレデンシャルを選ぶかもしれない。米国商務省の国立標準技術研究所（NIST）は、必要不可欠なサービスにアクセスする際に、新規の方法と従来から慣れ親しんだ方法の両方を使用して ID を安全に証明できるようにするため、デジタル・アイデンティティ・ガイドラインの草案を更新した。
The draft Digital Identity Guidelines (NIST Special Publication [SP] 800-63 Revision 4 and its companion publications SPs 800-63A, 800-63B and 800-63C) have been updated to reflect the robust feedback that NIST received in 2023 as part of a four-month-long comment period and yearlong period of external engagement.	デジタル・アイデンティティ・ガイドラインの草案（NIST 特別刊行物 [SP] 800-63 Revision 4 およびその関連出版物 SPs 800-63A、800-63B、800-63C）は、NIST が 2023 年に 4 か月に及ぶコメント期間と 1 年間に及ぶ外部関与の一環として受けた強固なフィードバックを反映して更新された。
“Today’s draft revision from NIST highlights the Biden-Harris administration’s commitment to strengthening anti-fraud controls while ensuring broad and equitable access to digital services,” said Jason Miller, deputy director for management at the Office of Management and Budget. “By incorporating feedback from private industry, federal agencies, privacy and civil rights advocacy groups, and members of the public, NIST has developed strong and fair draft guidelines that, when finalized, will help federal agencies better defend against evolving threats while providing critical benefits and services to the American people, particularly those that need them most.”	行政管理予算局のジェイソン・ミラー次長は次のように述べた。「本日のNISTの改訂草案は、デジタル・サービスへの広範かつ公平なアクセスを確保しつつ、不正防止対策を強化するというバイデン-ハリス政権のコミットメントを浮き彫りにするものである。民間企業、連邦政府機関、プライバシーおよび公民権擁護団体、そして一般市民からのフィードバックを取り入れることで、NISTは強力かつ公正なガイドライン草案を作成した。このガイドライン草案が最終化されれば、連邦政府機関は進化する脅威に対してより良い防御を行うことができるようになり、同時にアメリカ国民、特にそれを最も必要とする人々に重要な利益とサービスを提供することができるようになる。」
“Everyone should be able to lawfully access government services, regardless of their chosen methods of identification,” said Under Secretary of Commerce for Standards and Technology and NIST Director Laurie E. Locascio. “These improved guidelines are intended to help organizations of all kinds manage risk and prevent fraud while ensuring that digital services are lawfully accessible to all.”	標準技術担当商務次官兼NISTディレクターのローリー・E・ロカシオは、は次のように述べた。「誰もが、選択した本人確認方法にかかわらず、合法的に政府サービスにアクセスできるべきである。これらの改善されたガイドラインは、あらゆる種類の組織がリスクを管理し、不正行為を防止するのに役立つと同時に、デジタル・サービスに合法的にアクセスできるようにすることを意図している。」
The suite of documents is the second public draft of the updated guidelines, which NIST first announced in December 2022. NIST is seeking public comment on this new iteration, which is intended to make access to online services both secure and straightforward, regardless of the means by which a person chooses to prove their identity.	この一連の文書は、NISTが2022年12月に初めて発表したガイドライン更新の2回目の公開草案である。NISTは、オンライン・サービスへのアクセスを、人がどのような手段で本人であることを証明するかを問わず、安全かつ容易にすることを意図したこの新しい版について、パブリック・コメントを求めている。
“We are trying to make sure we maintain as many pathways as possible to enable secure online access to services,” said NIST Digital Identity Program Lead Ryan Galluzzo, one of the publication’s authors. “We want to open up the use of modern digital pathways while still allowing for physical and manual methods whenever they may be necessary.”	この出版物の著者の一人である NIST デジタル ID プログラム・リードのライアン・ガ ルッツォ氏は、次のように述べた。「われわれは、サービスへの安全なオンライン・アクセスを可能にするため に、できるだけ多くの経路を確保しようとしている。私たちは、最新のデジタル経路の使用を開放する一方で、物理的および手動的な方法が必要な場合はいつでも利用できるようにしたい。」
Proving one’s identity is often a necessary step in accessing services from federal agencies. Identity management is important to these agencies and other organizations, especially because fraudulent claims can be very costly to both organizations and individuals, but not everyone uses the same methods to demonstrate their identity either in person or online. Defending against fraud while maintaining accessibility for a multitude of potential users are two of the goals NIST is trying to balance with the update, Galluzzo said .	自分のアイデンティティを証明することは、連邦政府機関のサービスを利用する上でしばしば必要なステップである。特に不正請求は、組織と個人の両方にとって甚大な損害となる可能性があるため、アイデンティティ管理はこれらの機関やその他の組織にとって重要である。不正行為から身を守ると同時に、多数の潜在的な利用者のアクセシビリティを維持することは、NISTが更新でバランスを取ろうとしている目標の2つである、とガルッツォ氏は言う。
“We want to open up the use of modern digital pathways while still allowing for physical and manual methods whenever they may be necessary.” —Ryan Galluzzo, NIST Digital Identity Program Lead	「私たちは、最新のデジタル経路の使用を開放する一方で、物理的な方法と手作業による方法が必要な場合はいつでもそれを可能にしたいと考えている」。-ライアン・ガルッツォ、NISTデジタル・アイデンティティ・プログラム・リード
NIST received nearly 4,000 comments from 140 organizations and individuals on the 2022 version of the draft. Many of these comments focused on expanding the guidance on two technologies that are rapidly growing in use: syncable authenticators and digital credentials presented through user-controlled wallets. Syncable authenticators, often called passkeys, offer greater security than passwords while allowing a user to save a single passkey on multiple devices. User-controlled wallets, which several major companies currently offer, can securely store payment information along with other items like plane tickets and digital versions of physical identification documents like driver’s licenses.	NIST は、2022 年版の草案に対して 140 の組織と個人から 4,000 近いコメントを受け取った。これらのコメントの多くは、利用が急速に拡大している 2 つの技術、すなわち同期可能な認証子と、ユーザが管理するウォレットを通じて提示されるデジタル・クレデンシャルに関するガイダンスの拡大に重点を置いていた。同期可能な認証子は、パスキーと呼ばれることが多いが、パスワードよりも高いセキュリ ティを提供する一方で、ユーザは複数のデバイスに 1 つのパスキーを保存することができる。現在、大手企業数社が提供しているユーザー管理ウォレットは、航空券や運転免許証のような物理的な身分証明書のデジタル版といった他のアイテムとともに、支払い情報を安全に保存することができる。
The expanded guidance around passkeys is found in volume SP 800-63B, Galluzzo said, while additions concerning digital wallets are in volume SP 800-63C.	ガルッツォ氏は次のように述べた。パスキーに関する拡張ガイダンスはSP800-63Bにあり、デジタルウォレットに関する追加ガイダンスはSP800-63Cにある。」
“In response to the comments we received on the first draft, we added more detail about wallets,” he said. “We added guidance on how to trust the wallet itself and on how to trust its contents. There is more about how to securely present the information stored on the wallet, as well as how the other party can trust it.”	「最初の草案に寄せられたコメントを受けて、我々はウォレットに関する詳細を追加した。ウォレットそのものを信頼する方法と、その中身を信頼する方法についてのガイダンスを追加した。ウォレットに保存されている情報をどのように安全に提示するか、また、相手がどのようにそれを信頼するかについて、さらに詳しく説明した。」
Not everyone will feel comfortable or be able to use digital passkeys or wallets, however, and not everyone has a smartphone. The updated draft also expands guidance on how agencies can maintain access to services for people using more traditional forms of identification, Galluzzo said. This includes details on in-person identity proofing and mechanisms for handling exceptions. It also includes the concept of the “applicant reference” — meaning a trusted individual who can vouch for a person who doesn’t have access to identification documents, including a person who may not qualify for traditional forms of evidence or one whose evidence may have been lost or destroyed.	ガルッツォ氏はまた、次のように述べた。「しかし、すべての人がデジタルパスキーやウォレットを快適に使えるとは限らないし、すべての人がスマートフォンを持っているわけでもない。更新された草案では、より伝統的な身分証明書を使用している人々のサービスへのアクセスを機関が維持する方法についてのガイダンスも拡大されている、これには、対面での身分証明や例外処理の仕組みについての詳細が含まれる。また、「申請者参照」の概念も含まれている。これは、従来の証明形式を利用する資格がない人、または証明が紛 失または破棄された可能性のある人を含め、アイデンティティ文書を利用できない人を保証できる信頼できる個人を意味する。」
The authors also sought input from NIST’s team of face recognition and analysis experts to refine the guidance on using biometrics to identify a person through a face image. Galluzzo said that biometric-based methods of identity verification have been maintained in the guidance, but that for this path to achieve NIST’s goal of balancing security and access, systems that use these technologies must perform accurately, adhere to the privacy requirements articulated in the guidance, and include manual processes to address errors or challenges that users may encounter.	著者らはまた、NISTの顔認識および分析の専門家チームから意見を求め、顔画像を通じて人物を識別するためにバイオメトリクスを使用する際のガイダンスを改良した。ガルッツォ氏によると、バイオメトリクスに基づく本人確認方法はガイダンスの中で維持 されているが、この方法がセキュリティとアクセスのバランスをとるという NIST の目標を達成するた めには、これらの技術を使用するシステムは正確に動作し、ガイダンスの中で明示されたプライバシ ー要件を遵守し、ユーザが遭遇する可能性のあるエラーや課題に対処するための手動プロセスを 含まなければならない。
“We continue to augment the guidance to emphasize the importance of providing alternatives to face recognition and biometrics, particularly for systems supporting public services,” he said.	「我々は、特に公共サービスをサポートするシステムにおいて、顔認証や生体認証に代わるものを提供することの重要性を強調するため、ガイダンスを引き続き補強していく」と述べた。

・2024.08.21 NIST SP 800-63-4: Digital Identity Guidelines | Second Public Draft

NIST SP 800-63-4: Digital Identity Guidelines | Second Public Draft	NIST SP 800-63-4： デジタル・アイデンティティ・ガイドライン｜第 2 次公開草案
The rapid proliferation of online services over the past few years has heightened the need for reliable, equitable, secure, and privacy-protective digital identity solutions. Revision 4 of NIST’s Special Publication (SP) 800-63, Digital Identity Guidelines, responds to the changing digital landscape that has emerged since the last major revision of this suite was published in 2017—including the real-world implications of online risks. The guidelines present the process and technical requirements for meeting digital identity management assurance levels for identity proofing, authentication, and federation, including requirements for security and privacy as well as considerations for fostering equity and the usability of digital identity solutions and technology.	過去数年間のオンライン・サービスの急速な普及により、信頼性が高く、公平で、安全で、プライ バシを保護するデジタル・アイデンティティ・ソリューションの必要性が高まっている。NIST の特別刊行物（SP）800-63「デジタル・アイデンティティ・ガイドライン」の改訂 4 は、このスイートの最後の主要改訂が 2017 年に発行されて以来、オンライン・リスクの現実世界での影響を含め て、変化するデジタル環境に対応している。このガイドラインは、セキュリティとプライバシーの要件だけでなく、公平性とデジタル・アイデンティティ・ソリューションおよび技術の使いやすさを促進するための考慮事項を含め、アイデンティティ証明、認証、およびフェデレーションに関するデジタル ID 管理の保証レベルを満たすためのプロセスと技術要件を提示している。
Webinar on August 28, 2024 | Digital Identity Guidelines Update	2024年8月28日ウェビナー｜デジタル・アイデンティティ・ガイドラインの更新
Join us on 8/28 from 12:00 pm - 2:00 pm EDT for a webinar where we will cover the major changes to all four volumes. Registration is open until the event begins.	8月28日12:00～14:00（米国東部夏時間）に開催されるウェビナーに参加し、全4巻の主な変更点をカバーする。参加登録はイベント開始まで受け付けている。
In December 2022, NIST released the Initial Public Draft (IPD) of SP 800-63, Revision 4. Over the course of a 119-day public comment period, NIST received close to 4000 comments that improved these Digital Identity Guidelines in a manner that supports NIST's critical goals of providing foundational risk management processes and requirements that enable secure, private, equitable, and accessible identity systems.	2022年12月、NISTはSP 800-63改訂4の初期公開草案（IPD）を発表した。119 日間の意見公募期間中、NIST には 4000 近い意見が寄せられ、安全で、プライベートで、公平で、アクセシブルなアイデンティティ・システムを可能にする基礎的なリスク管理プロセスと要件を提供するという NIST の重要な目標をサポートする形で、このデジタル・アイデンティティ・ガイドラインが改善された。
Based on this initial wave of feedback, several substantive changes have been made across all the volumes. These changes include but are not limited to: updated text and context setting for risk management; added recommended continuous evaluation metrics; expanded fraud requirements and recommendations; restructured identity proofing controls; integrated syncable authenticators; and added user-controlled wallets to the federation model.	この最初のフィードバックの波に基づいて、すべてのボリュームにわたっていくつかの実質的な 変更が加えられた。これらの変更には、リスク管理に関する文言およびコンテキスト設定の更新、推奨される継続 的評価基準の追加、不正要件および推奨事項の拡大、アイデンティティ証明コントロールの再構築、同期可能な認証子の統合、フェデレーション・モデルへのユーザ制御ウォレットの追加などが含まれるが、こ れらに限定されない。
Additionally, this draft seeks to:	さらに、この草案は以下を目指す：
・Address comments received in response to the IPD of Revision 4 of SP 800-63.	・SP 800-63 の改訂 4 の IPD に対して寄せられたコメントに対応する。
・Clarify the text to address the questions and issues raised in the public comments.	・パブリックコメントで提起された質問と問題に対処するため、本文を明確にする。
・Update all four volumes of SP 800-63 based on current technology and market developments, the changing digital identity threat landscape, and organizational needs for digital identity solutions to address online security, privacy, usability, and equity.	・現在の技術および市場の発展、変化するデジタル ID 脅威の状況、およびオンライン・セ キュリティ、プライバシー、ユーザビリティ、および公平性に対処するデジタル ID ソ リューションに対する組織のニーズに基づいて、SP 800-63 の全 4 巻を更新する。
These second public drafts (2PD) include:	これらの第 2 公開草案（2PD）には以下が含まれる：
NIST SP 800-63-4 2pd, Digital Identity Guidelines	NIST SP 800-63-4 2PD、デジタル・アイデンティティ・ガイドライン
NIST SP 800-63A-4 2pd, Digital Identity Guidelines: Identity Proofing and Enrollment	NIST SP 800-63A-4 2pd、デジタル・アイデンティティ・ガイドライン： アイデンティティ証明および登録
NIST SP 800-63B-4 2pd, Digital Identity Guidelines: Authentication and Authenticator Management	NIST SP 800-63B-4 2pd、デジタル・アイデンティティ・ガイドライン： 認証および認証者管理
NIST SP 800-63C-4 2pd, Digital Identity Guidelines: Federation and Assertions	NIST SP 800-63C-4 2pd、デジタル・アイデンティティ・ガイドライン： フェデレーションおよびアサーション

---

・2024.08.21 NIST SP 800-63-4 (2nd Public Draft) Digital Identity Guidelines

NIST SP 800-63-4 (2nd Public Draft) Digital Identity Guidelines	NIST SP 800-63-4（第2次公開草案）デジタル・アイデンティティ・ガイドライン
Announcement	発表
NIST requests comments on the second draft of the fourth revision to the four-volume suite of Special Publication 800-63, Digital Identity Guidelines. This publication presents the process and technical requirements for meeting the digital identity management assurance levels specified in each volume. They also provide considerations for enhancing privacy, equity, and usability of digital identity solutions and technology.	NIST は、Special Publication 800-63 の 4 巻からなる「デジタル・アイデンティティ・ガイドライン」の第 4 版改訂の第 2 草案に対するコメントを求めている。本書は、各巻で指定されたデジタル・アイデンティティ 管理保証レベルを満たすためのプロセスと技術要件を提 示する。また、デジタル・アイデンティティ ソリューションおよび技術のプライバシー、公平性、およびユーザビリティを強化するための考慮事項も示している。
Background	背景
In December 2022, NIST released the Initial Public Draft (IPD) of SP 800-63, Revision 4. Over the course of a 119-day public comment period, the authors received exceptional feedback from a broad community of interested entities and individuals. The input from nearly 4,000 specific comments has helped advance the improvement of these Digital Identity Guidelines in a manner that supports NIST's critical goals of providing foundational risk management processes and requirements that enable the implementation of secure, private, equitable, and accessible identity systems. Based on this initial wave of feedback, several substantive changes have been made across all of the volumes. These changes include but are not limited to the following:	2022年12月、NISTはSP 800-63改訂4の初期公開草案（IPD）を公表 した。119日間のパブリックコメント期間中、著者は幅広い関係団体や個人から非常に多くのフィードバックを得た。約 4,000 件の具体的なコメントからのインプットは、安全で、プライベートで、公平で、アクセ ス可能な アイデンティティ・システムの実装を可能にする基礎的なリスク管理プロセスと要件を提供するという NIST の重要な目標を支援する形で、デジタル・アイデンティティ・ガイドラインの改善を進めるのに役立った。この最初のフィードバックの波に基づいて、すべてのボリュームにわたっていくつかの実質的な 変更が加えられた。これらの変更には以下が含まれるが、これらに限定されない：
1. Updated text and context setting for risk management. Specifically, the authors have modified the process defined in the IPD to include a context-setting step of defining and understanding the online service that the organization is offering and intending to potentially protect with identity systems.	1. リスク管理に関する本文および背景設定を更新した。具体的には、著者は IPD で定義されたプロセスを修正し、組織が提供し、アイデンティティ・システムで保護する可能性があるオンライン・サービスを定義し理解するコンテキスト設定ステップを含めるようにした。
2. Added recommended continuous evaluation metrics. The continuous improvement section introduced by the IPD has been expanded to include a set of recommended metrics for holistically evaluating identity solution performance. These are recommended due to the complexities of data streams and variances in solution deployments.	2. 推奨される継続的評価基準を追加した。IPD によって導入された継続的改善のセクションは拡張され、アイデンティティ・ソリューションのパフォーマンスを全体的に評価するための推奨される測定基準のセットが含まれるようになった。これらは、データ・ストリームの複雑さとソリューションの展開のばらつきのために推奨される。
3. Expanded fraud requirements and recommendations. Programmatic fraud management requirements for credential service providers and relying parties now address issues and challenges that may result from the implementation of fraud checks.	3. 拡張された不正要件および推奨。クレデンシャル・サービス・プロバイダおよび依拠当事者に対するプログラム上の不正 管理要件は、不正チェックの実装から生じる可能性のある問題および課題に対応するようにな った。
4. Restructured the identity proofing controls. There is a new taxonomy and structure for the requirements at each assurance level based on the means of providing the proofing: Remote Unattended, Remote Attended (e.g., video session), Onsite Unattended (e.g., kiosk), and Onsite Attended (e.g., in-person).	4. アイデンティティ証明コントロールを再構築した。証明を提供する手段に基づいて、各保証レベルの要件に新しい分類法と構造が設けられた： 遠隔無人、遠隔出席（ビデオ・セッションなど）、現場無人（キオスクなど）、現場出席 （対面など）である。
5. Integrated syncable authenticators. In April 2024, NIST published interim guidance for syncable authenticators. This guidance has been integrated into SP 800-63B as normative text and is provided for public feedback as part of the Revision 4 volume set.	5. 同期可能な統合器。2024 年 4 月、NIST は、同期可能な認証子に関する暫定ガイダンスを公表 した。このガイダンスは、規範となるテキストとして SP 800-63B に統合され、リビジョン 4 のボリュームセットの一部として、一般からのフィードバックのために提供されている。
6. Added user-controlled wallets to the federation model. Digital wallets and credentials (called "attribute bundles" in SP 800-63C) are seeing increased attention and adoption. At their core, they function like a federated IdP, generating signed assertions about a subject. Specific requirements for this presentation and the emerging context are presented in SP 800-63C-4.	6. フェデレーション・モデルにユーザ管理ウォレットを追加した。デジタル・ウォレットとクレデンシャル（SP 800-63C では「属性バンドル」と呼ばれる）は、注目と採用 が高まっている。その核心は、フェデレーショ ンされた IdP のように機能し、対象者に関する署名されたアサーションを生成することである。このプレゼンテーションの具体的な要件と新たなコンテキストは、SP 800-63C-4 に示されている。
The rapid proliferation of online services over the past few years has heightened the need for reliable, equitable, secure, and privacy-protective digital identity solutions.	過去数年間のオンライン・サービスの急速な普及により、信頼性が高く、公平で、安全で、プライバシを保護するデジタル・アイデンティティ ソリューションの必要性が高まっている。
Revision 4 of NIST Special Publication 800-63, Digital Identity Guidelines, intends to respond to the changing digital landscape that has emerged since the last major revision of this suite was published in 2017 — including the real-world implications of online risks. The guidelines present the process and technical requirements for meeting digital identity management assurance levels for identity proofing, authentication, and federation, including requirements for security and privacy as well as considerations for fostering equity and the usability of digital identity solutions and technology.	NIST 特別刊行物 800-63「デジタル・アイデンティティ・ガイドライン」の改訂 4 は、このスイートの最後の大改訂が 2017 年に発行されて以来、オンライン・リスクの現実世界への影響を含め、変化するデジタ ル環境に対応することを意図 している。このガイドラインは、セキュリティとプライバシに関する要件だけでなく、公平性を育むための 考慮事項や、デジタル・アイデンティティ ソリューションおよび技術のユーザビリティを含め、アイデンティティ証明、 認証、およびフェデレーションに関するデジタル・アイデンティティ管理保証レベルを満たすための プロセスおよび技術要件を示している。
Based on the feedback provided in response to our June 2020 Pre-Draft Call for Comments, research into real-world implementations of the guidelines, market innovation, and the current threat environment, this draft seeks to:	2020 年 6 月のプレ・ドラフト意見募集に対して提供されたフィードバック、ガイドラインの実世界での 実装に関する調査、市場の革新、および現在の脅威環境に基づいて、このドラフトは以下を目指す：
・Address comments received in response to the IPD of Revision 4 of SP 800-63	・SP 800-63 の改訂 4 の IPD に対して寄せられたコメントに対応する。
・Clarify the text to address the questions and issues raised in the public comments	・パブリックコメントで提起された疑問や問題に対処するため、本文を明確にする。
・Update all four volumes of SP 800-63 based on current technology and market developments, the changing digital identity threat landscape, and organizational needs for digital identity solutions to address online security, privacy, usability, and equity	・現在の技術および市場の発展、変化するデジタル・アイデンティティ 脅威の状況、およびオンライン・セ キュリティ、プライバシー、ユーザビリティ、および公平性に対処するデジタル・アイデンティティ ソ リューションに対する組織のニーズに基づいて、SP 800-63 の全 4 巻を更新する。
Note to Reviewers	査読者への注記
NIST is specifically interested in comments and recommendations on the following topics:	NIST は、特に次のトピックに関するコメントおよび提言に関心を持っている：
1. Risk Management and Identity Models	1. リスク管理と アイデンティティ・モデル
Is the "user controlled" wallet model sufficiently described to allow entities to understand its alignment to real-world implementations of wallet-based solutions such as mobile driver's licenses and verifiable credentials?	ユーザが管理する」ウォレット・モデルは、モバイル運転免許証や検証可能なクレデンシャルなど のウォレット・ベースのソリューションの実際の実装との整合性をエンティティが理解できるよう に、十分に説明されているか。
Is the updated risk management process sufficiently well-defined to support an effective, repeatable, real-world process for organizations seeking to implement digital identity system solutions to protect online services and systems?	更新されたリスク管理プロセスは、オンライン・サービスおよびシステムを保護するためにデジタル・アイデンティティ システム・ソリューションの実装を目指す組織にとって、効果的で反復可能な実世界のプロセスを支援するために十分に定義されているか。
2. Identity Proofing and Enrollment	2. アイデンティティ証明および登録
Is the updated structure of the requirements around defined types of proofing sufficiently clear? Are the types sufficiently described?	定義された証明の種類に関する要件の更新された構造は、十分に明確であるか。その種類は十分に説明されているか。
Are there additional fraud program requirements that need to be introduced as a common baseline for CSPs and other organizations?	CSP およびその他の組織の共通基準として導入する必要がある追加の不正プログラム要件はあるか。
Are the fraud requirements sufficiently described to allow for appropriate balancing of fraud, privacy, and usability trade-offs?	不正行為要件は、不正行為、プライバシー、およびユーザビリティのトレードオフの適切なバラン スを可能にするように十分に記述されているか。
Are the added identity evidence validation and authenticity requirements and performance metrics realistic and achievable with existing technology capabilities?	追加されるアイデンティティ証拠の検証および真正性の要件とパフォーマンス測定基準は、既存の技術能力で現実 的かつ達成可能であるか。
3. Authentication and Authenticator Management	3. 認証および認証子管理
Are the syncable authenticator requirements sufficiently defined to allow for reasonable risk-based acceptance of syncable authenticators for public and enterprise-facing uses?	同期可能な認証子の要件は、一般向けおよび企業向けの用途で同期可能な認証子を合理的なリ スクに基づいて受け入れることができるように十分に定義されているか。
Are there additional recommended controls that should be applied? Are there specific implementation recommendations or considerations that should be captured?	適用すべき追加推奨管理はあるか。具体的な実装上の推奨事項や考慮事項があるか。
Are wallet-based authentication mechanisms and "attribute bundles" sufficiently described as authenticators? Are there additional requirements that need to be added or clarified?	ウォレットベースの認証メカニズムおよび「属性バンドル」は、認証子として十分に説明されて いるか。追加または明確化すべき追加要件はあるか。
4. Federation and Assertions	4. フェデレーションとアサーション
Is the concept of user-controlled wallets and attribute bundles sufficiently and clearly described to support real-world implementations? Are there additional requirements or considerations that should be added to improve the security, usability, and privacy of these technologies?	ユーザが管理するウォレットと属性バンドルの概念は、実際の実装をサポートするために十分かつ明 確に記述されているか。これらの技術のセキュリティ、ユーザビリティ、プライバシーを改善するために追加すべき要件や考慮事項はあるか。
5. General	5. 一般
What specific implementation guidance, reference architectures, metrics, or other supporting resources could enable more rapid adoption and implementation of this and future iterations of the Digital Identity Guidelines?	デジタル・アイデンティティ・ガイドラインおよび今後の反復をより迅速に採用し実装するために、具体的な実 装ガイダンス、参照アーキテクチャ、測定基準、またはその他の支援リソースは何か。
What applied research and measurement efforts would provide the greatest impacts on the identity market and advancement of these guidelines?	どのような応用研究と測定の取り組みが、アイデンティティ市場とこれらのガイドラインの進展に最も大きな 影響を与えるか。

Abstract

概要

These guidelines cover identity proofing and authentication of users (such as employees, contractors, or private individuals) interacting with government information systems over networks. They define technical requirements in each of the areas of identity proofing, registration, authenticators, management processes, authentication protocols, federation, and related assertions. They also offer technical recommendations and other informative text intended as helpful suggestions. The guidelines are not intended to constrain the development or use of standards outside of this purpose. This publication supersedes NIST Special Publication (SP) 800-63-3.

このガイドラインは、ネットワークを介して政府情報システムとやり取りするユーザ（職員、請負 業者、または個人など）の アイデンティティ証明および認証を対象としている。ID プルーフィング、登録、認証子、管理プロセス、認証プロトコル、フェデレーション、 および関連アサーションの各分野における技術要件を定義する。また、有用な提案として意図 された技術的推奨およびその他の情報的文章も提供する。このガイドラインは、この目的以外の標準の開発または使用を制約することを意図 するものではない。本書は、NIST 特別刊行物（SP）800-63-3 に取って代わるものである。

・[PDF] NIST.SP.800-63-4.2pd

Table of Contents	目次
1. Introduction	1. はじめに
1.1. Scope and Applicability	1.1. 適用範囲と適用可能性
1.2. How to Use This Suite of SPs	1.2. 本スイートの使用方法
1.3. Enterprise Risk Management Requirements and Considerations	1.3. 企業リスクマネジメントの要求事項及び考慮事項
1.3.1. Security, Fraud, and Threat Prevention	1.3.1. セキュリティ、詐欺、脅威の防止
1.3.2. Privacy	1.3.2. プライバシー
1.3.3. Equity	1.3.3. 公平性
1.3.4. Usability	1.3.4. ユーザビリティ
1.4. Notations	1.4. 表記
1.5. Document Structure	1.5. 文書構造
2. Digital Identity Model	2. デジタル・アイデンティティ モデル
2.1. Overview	2.1. 概要
2.2. Identity Proofing and Enrollment	2.2. アイデンティティ証明と登録
2.2.1. Subscriber Accounts	2.2.1. 加入者アカウント
2.3. Authentication and Authenticator Management	2.3. 認証および認証子管理
2.3.1. Authenticators	2.3.1. オーセンティケータ
2.3.2. Authentication Process	2.3.2. 認証プロセス
2.4. Federation and Assertions	2.4. フェデレーションとアサーション
2.5. Examples of Digital Identity Models	2.5. デジタル・アイデンティティ・モデルの例
3. Digital Identity Risk Management	3. デジタル・アイデンティティ リスク管理
3.1. Define the Online Service	3.1. オンライン・サービスを定義する
3.2. Conduct Initial Impact Assessment	3.2. 初期影響評価の実施
3.2.1. Identify Impact Categories and Potential Harms	3.2.1. 影響カテゴリーと潜在的な損害を特定する
3.2.2. Identify Potential Impact Levels	3.2.2. 潜在的影響レベルを特定する
3.2.3. Impact Analysis	3.2.3. 影響分析
3.2.4. Determine Combined Impact Level for Each User Group	3.2.4. 各ユーザーグループの複合的な影響レベルを決定する
3.3. Select Initial Assurance Levels and Baseline Controls	3.3. 初期保証レベルとベースライン・コントロールの選択
3.3.1. Assurance Levels	3.3.1. 保証レベル
3.3.2. Assurance Level Descriptions	3.3.2. 保証レベルの説明
3.3.3. Initial Assurance Level Selection	3.3.3. 最初の保証レベルの選択
3.3.4. Identify Baseline Controls	3.3.4. ベースライン統制の特定
3.4. Tailor and Document Assurance Levels	3.4. 保証レベルの調整と文書化
3.4.1. Assess Privacy, Equity, Usability and Threat Resistance	3.4.1. プライバシー、公平性、ユーザビリティ、脅威への耐性を評価する
3.4.2. Identify Compensating Controls	3.4.2. 代償となる統制を特定する
3.4.3. Identify Supplemental Controls	3.4.3. 補足的コントロールを特定する
3.4.4. Digital Identity Acceptance Statement (DIAS)	3.4.4. デジタル・アイデンティティ受入ステートメント（DIAS）
3.5. Continuously Evaluate and Improve	3.5. 継続的な評価と改善
3.5.1. Evaluation Inputs	3.5.1. 評価インプット
3.5.2. Performance Metrics	3.5.2. パフォーマンス指標
3.5.3. Measurement in Support of Equity Assessments and Outcomes	3.5.3. 公平性の評価と成果を支援するための測定
3.6. Redress	3.6. 救済
3.7. Cybersecurity, Fraud, and Identity Program Integrity	3.7. サイバーセキュリティ、不正行為、アイデンティティ・プログラムの完全性
3.8. Artificial Intelligence (AI) and Machine Learning (ML) in Identity Systems	3.8. アイデンティティ・システムにおける人工知能（AI）と機械学習（ML）
References	参考文献
Appendix A. List of Symbols, Abbreviations, and Acronyms	附属書 A. 記号、略語、頭字語一覧
Appendix B. Glossary	附属書 B. 用語集
Appendix C. Change Log	附属書 C. 変更履歴
C.1. SP 800-63-1	C.1. SP 800-63-1
C.2. SP 800-63-2	C.2. SP 800-63-2
C.3. SP 800-63-3	C.3. SP 800-63-3
C.4. SP 800-63-4	C.4. SP 800-63-4
List of Tables	表 一覧
Table 1. IAL Summary	表 1. IAL の概要
Table 2. AAL Summary	表 2. AALの概要
Table 3. FAL Summary	表 3. FALの概要
Table 4. Performance Metrics	表 4. パフォーマンス指標
List of Figures	図 一覧
Fig. 1. Sample Identity Proofing and Enrollment Digital Identity Model	図 1. アイデンティティ証明と登録のデジタル・アイデンティティ・モデルの例
Fig. 2. Sample Authentication Process	図 2. 認証プロセスの例
Fig. 3. Non-Federated Digital Identity Model Example	図 3. 非連携デジタル・アイデンティティ モデルの例
Fig. 4. Federated Digital Identity Model Example	図 4. 連携デジタル・アイデンティティ モデルの例
Fig. 5. Federated Digital Identity Model with Subscriber-Controlled Wallet Example	図 5. サブスクライバが管理するウォレットを持つ統合デジタル・アイデンティティ モデルの例
Fig. 6. High-level diagram of the Digital Identity Risk Management Process Flow	図 6. デジタル・アイデンティティ リスク管理プロセスフローのハイレベル図

800-63-4 2pdの附属書Cに過去からの変更履歴あります...

Appendix C. Change Log	附属書C. 変更履歴
C.1. SP 800-63-1	C.1. SP 800-63-1
NIST SP 800-63-1 updated NIST SP 800-63 to reflect current authenticator (then referred to as “token”) technologies and restructured it to provide a better understanding of the digital identity architectural model used here. Additional (minimum) technical requirements were specified for the CSP, protocols used to transport authentication information, and assertions if implemented within the digital identity model.	NIST SP 800-63-1 は、現在の認証子（当時は「トークン」と呼ばれた）技術を反映するために NIST SP 800-63 を更新し、ここで使用されるデジタル：アイデンティティ・アーキテクチャ・モデルの理解を深めるために再構築した。デジタル・アイデンティティ・モデルに実装される場合、CSP、認証情報の伝送に使用されるプロトコル、および主張 について、追加の（最低限の）技術要件が規定された。
C.2. SP 800-63-2	C.2. SP 800-63-2
NIST SP 800-63-2 was a limited update of SP 800-63-1 and substantive changes were made only in Sec. 5, Registration and Issuance Processes. The substantive changes in the revised draft were intended to facilitate the use of professional credentials in the identity proofing process, and to reduce the need to send postal mail to an address of record to issue credentials for level 3 remote registration. Other changes to Sec. 5 were minor explanations and clarifications.	NIST SP 800-63-2 は、SP 800-63-1 の限定的な更新であり、実質的な変更は第 5 節「登録および発行プロセ ス」のみに加えられた。改訂ドラフトの実質的な変更は、身元証明プロセスにおける専門家クレデンシャルの使用を容 易にし、レベル 3 遠隔登録のクレデンシャルを発行するために記録された住所に郵便を送る必要 性を減らすことを意図していた。セクション5のその他の変更は、軽微な説明および明確化であった。
C.3. SP 800-63-3	C.3. SP 800-63-3
NIST SP 800-63-3 is a substantial update and restructuring of SP 800-63-2. SP 800-63- 3 introduces individual components of digital authentication assurance — AAL, IAL, and FAL — to support the growing need for independent treatment of authentication strength and confidence in an individual’s claimed identity (e.g., in strong pseudonymous authentication). A risk assessment methodology and its application to IAL, AAL, and FAL has been included in this guideline. It also moves the whole of digital identity guidance covered under SP 800-63 from a single document describing authentication to a suite of four documents (to separately address the individual components mentioned above) of which SP 800-63-3 is the top-level document.	NIST SP 800-63-3 は、SP 800-63-2 の大幅な更新および再構築である。SP 800-63-3 は、デジタル認証保証の個々の構成要素（AAL、IAL、および FAL）を導入し、認証強度の独立した扱いと個人の主張するアイデンティティに対する信頼（強力な仮名認証など）の必要性の高まりをサポートする。リスクアセスメント方法論および IAL、AAL、および FAL へのその適用が、このガイドラ インに含まれている。また、SP 800-63 でカバーされるデジタル・アイデンティティ・ガイダンスの全体が、認証を説明する 1 つの文書から、SP 800-63-3 を最上位文書とする 4 つの文書群（上記の個々の構成要素に個別に対応）に移行している。
Other areas updated in 800-63-3 include:	800-63-3 で更新された他の分野は以下のとおりである：
• Renamed to Digital Identity Guidelines to properly represent the scope includes identity proofing and federation, and to support expanding the scope to include device identity, or machine-to-machine authentication in future revisions.	・身元確認およびフェデレーションを含む範囲を適切に代表し、今後の改訂でデバイス・アイデンティティやマシン間認証を含む範囲への拡張をサポートするため、「デジタル・アイデンティティ・ガイドライン」に改名した。
• Changed terminology, including the use of authenticator in place of token to avoid conflicting use of the word token in assertion technologies.	・アサーション技術におけるトークンという単語の矛盾した使用を避けるため、トークンの代わりに認証子を使用するなど、用語を変更した。
• Updated authentication and assertion requirements to reflect advances in both security technology and threats.	・セキュリティ技術と脅威の両方の進歩を反映するために、認証およびアサーションの要件を更新した。
• Added requirements on the storage of long-term secrets by verifiers.	・検証者による長期秘密の保管に関する要件を追加した。
• Restructured identity proofing model.	・身元証明モデルを再構築した。
• Updated requirements regarding remote identity proofing.	・遠隔身元証明に関する要件を更新した。
• Clarified the use of independent channels and devices as “something you have”.	・独立したチャネルおよびデバイスを「持っているもの」として使用することを明確にした。
• Removed pre-registered knowledge tokens (authenticators), with the recognition that they are special cases of (often very weak) passwords.	・事前登録された知識トークン（認証）は、（多くの場合非常に脆弱な）パスワードの特殊な ケースであるとの認識のもと、削除した。
• Added requirements regarding account recovery in the event of loss or theft of an authenticator.	・認証情報の紛失・盗難時のアカウント復旧に関する要件を追加した。
• Removed email as a valid channel for out-of-band authenticators.	・帯域外認証子の有効なチャネルとして電子メールを削除した。
• Expanded discussion of reauthentication and session management.	・再認証およびセッション管理に関する記述を拡張した。
• Expanded discussion of identity federation; restructuring of assertions in the context of federation.	・アイデンティティ・フェデレーションに関する論点を拡張し、フェデレーションに関連するアサーションを再構築した。
C.4. SP 800-63-4	C.4. SP 800-63-4
NIST SP 800-63-4 has substantial updates and re-organization from SP 800-63-3. Updates to 800-63-4 include:	NIST SP 800-63-4 には、SP 800-63-3 からの大幅な更新と再構成がある。800-63-4 の更新には以下が含まれる：
• Expanded security and privacy considerations and added equity and usability considerations.	・セキュリティおよびプライバシーに関する考慮事項を拡張し、公平性およびユーザビリティ に関する考慮事項を追加した。
• Updated digital identity models and added a user-controlled wallet federation model that addresses the increased attention and adoption of digital wallets and attribute bundles.	・デジタル・アイデンティティ・モデルを更新し、デジタル・ウォレットおよび属性バンドルの注目の高まりと採用に対応 する、ユーザ制御ウォレット・フェデレーション・モデルを追加した。
• Expanded digital identity risk management process to include definition of the protected online services, user groups, and impacted entities.	・デジタル・アイデンティティ・リスクマネジメント・プロセスを拡張し、保護されるオンライン・サービス、ユ ーザ・グループ、および影響を受ける事業体の定義を含める。
• A more descriptive introduction to establish the context of the DIRM process, the two dimensions of risk it addresses, and the intended outcomes. This context setting step includes defining and understanding the online service that the 2organization is offering and intending to protect with identity systems.	・ DIRM プロセスのコンテキスト、DIRM が対処するリスクの 2 つの側面、および意図する結果を 確立するためのより説明的な序文である。このコンテキスト設定のステップには、2 組織が提供し、アイデンティティ・システムで保護することを意図しているオンライン・サービスを定義し、理解することが含まれる。
• Expanded digital identity risk management process to include definition of the protected online services, user groups, and impacted entities.	・デジタル・アイデンティティ・リスクマネジメント・プロセスを拡張し、保護対象のオンライン・サービス、ユー ザ・グループ、および影響を受ける事業体の定義を含めるようにした。
• Updated digital identity risk management process for additional assessments for tailoring initial baseline control selections.	・デジタル・アイデンティティ・リスクマネジメント・プロセスを更新し、初期ベースラインコントロールの選 択を調整するための追加アセスメントを追加した。
• Added performance metrics for the continuous evaluation of digital identity systems.	・デジタル・アイデンティティ・システムの継続的評価のためのパフォーマンス測定基準を追加した。
• Added a new subsection on redress processes and requirements.	・救済プロセスと要件に関する新しいサブセクションを追加した。
• Added a new Artificial Intelligence subsection to address the use of Artificial Intelligence in digital identity services.	・デジタル・アイデンティティ・サービスにおける人工知能の使用に対処するために、新しい人工知能のサブセ クションを追加した。

---

・2024.08.21 NIST SP 800-63A-4 (2nd Public Draft) Digital Identity Guidelines: Identity Proofing and Enrollment

NIST SP 800-63A-4 (2nd Public Draft) Digital Identity Guidelines: Identity Proofing and Enrollment	NIST SP 800-63A-4（第 2 次公開草案）デジタル・アイデンティティ・ガイドライン： アイデンティティ証明および登録
Abstract	概要
This guideline focuses on the enrollment and verification of an identity for use in digital authentication. Central to this is a process known as identity proofing in which an applicant provides evidence to a credential service provider (CSP) reliably identifying themselves, thereby allowing the CSP to assert that identification at a useful identity assurance level. This document defines technical requirements for each of three identity assurance levels. The guidelines are not intended to constrain the development or use of standards outside of this purpose. This publication supersedes NIST Special Publication (SP) 800-63A.	このガイドラインは、デジタル認証で使用するアイデンティティ登録および検証に焦点を当てている。この中心は、申請者が自分自身を確実に識別する証拠をクレデンシャル・サービス・プロバイダ （CSP）に提供することで、CSP が有用な アイデンティティ保証レベルでその識別をアサートできるようにする、 アイデンティティ証明として知られるプロセスである。本文書は、3 つの アイデンティティ保証レベルごとに技術要件を定義する。このガイドラインは、この目的以外の標準の開発または使用を制約することを意図 するものではない。本書は、NIST 特別刊行物（SP）800-63A に取って代わるものである。

・[PDF] NIST.SP.800-63A-4.2pd

Table of Contents	目次
1. Introduction	1. はじめに
1.1. Expected Outcomes of Identity Proofing	1.1. アイデンティティ証明に期待される成果
1.2. Identity Assurance Levels	1.2. 身元保証レベル
1.3. Notations	1.3. 表記
1.4. Document Structure	1.4. 文書構造
2. Identity Proofing Overview	2. 身元証明の概要
2.1. Identity Proofing and Enrollment	2.1. 身元証明と登録
2.1.1. Process Flow	2.1.1. プロセスの流れ
2.1.2. Identity Proofing Roles	2.1.2. アイデンティティ証明の役割
2.1.3. Identity Proofing Types	2.1.3. アイデンティティ証明の種類
2.2. Core Attributes	2.2. コア属性
2.3. Identity Resolution	2.3.アイデンティティ解決
2.4. Identity Validation and Identity Evidence Collection	2.4.アイデンティティ検証およびアイデンティティ証拠収集
2.4.1. Evidence Strength Requirements	2.4.1. 証拠強度の要件
2.4.2. Identity Evidence and Attribute Validation	2.4.2. アイデンティティ証拠と属性の検証
2.5. Identity Verification	2.5.アイデンティティ検証
2.5.1. Identity Verification Methods	2.5.1. 本人確認方法
3. Identity Proofing Requirements	3. 本人確認要件
3.1. General Requirements	3.1. 一般要件
3.1.1. Identity Service Documentation and Records	3.1.1. アイデンティティ・サービスの文書化および記録
3.1.2. Fraud Management	3.1.2. 不正管理
3.1.3. General Privacy Requirements	3.1.3. 一般的プライバシー要件
3.1.4. General Equity Requirements	3.1.4. 一般的な公平性の要件
3.1.5. General Security Requirements	3.1.5. 一般的なセキュリティ要件
3.1.6. Redress Requirements	3.1.6. 救済要件
3.1.7. Additional Requirements for Federal Agencies	3.1.7. 連邦政府機関に対する追加要件
3.1.8. Requirements for Confirmation Codes	3.1.8. 確認コードの要件
3.1.9. Requirements for Continuation Codes	3.1.9. 継続コードに関する要件
3.1.10. Requirements for Notifications of Identity Proofing	3.1.10. 身元証明の通知に関する要件
3.1.11. Requirements for the Use of Biometrics	3.1.11. バイオメトリクスの使用に関する要件
3.1.12. Requirements for Evidence Validation Processes (Authenticity Checks)	3.1.12. 証拠検証プロセス（真正性チェック）に関する要件
3.1.13. Exception and Error Handling	3.1.13. 例外及びエラー処理
3.2. Elevating Subscriber IALs	3.2. 利用者 IAL の昇格
4. Identity Assurance Level Requirements	4. アイデンティティ保証レベル要件
4.1. Identity Assurance Level 1 Requirements	4.1. アイデンティティ保証レベル 1 要件
4.1.1. Proofing Types	4.1.1. 証明タイプ
4.1.2. Evidence Collection	4.1.2. 証拠収集
4.1.3. Attribute Collection	4.1.3. 属性収集
4.1.4. Evidence Validation	4.1.4. 証拠の検証
4.1.5. Attribute Validation	4.1.5. 属性の検証
4.1.6. Verification Requirements	4.1.6. 検証要件
4.1.7. Remote Attended Requirements	4.1.7. 遠隔出席の要件
4.1.8. Onsite Attended Requirements	4.1.8. 現地出席の要件
4.1.9. Onsite Unattended Requirements (Devices & Kiosks)	4.1.9. オンサイト無人要件（デバイスおよびキオスク端末）
4.1.10. Initial Authenticator Binding	4.1.10. 初期認証子バインディング
4.1.11. Notification of Proofing	4.1.11. プルーフィングの通知
4.2. Identity Assurance Level 2 Requirements	4.2. アイデンティティ保証レベル 2 要件
4.2.1. Proofing Types	4.2.1. 証明の種類
4.2.2. Evidence Collection	4.2.2. 証拠収集
4.2.3. Attribute Collection	4.2.3. 属性収集
4.2.4. Evidence Validation	4.2.4. 証拠の検証
4.2.5. Attribute Validation	4.2.5. 属性の検証
4.2.6. Verification Requirements	4.2.6. 検証要件
4.2.7. Remote Attended Requirements	4.2.7. 遠隔出席の要件
4.2.8. Onsite Attended Requirements	4.2.8. 現地出席の要件
4.2.9. Onsite Unattended Requirements (Devices & Kiosks)	4.2.9. オンサイト無人要件（デバイスおよびキオスク端末）
4.2.10. Notification of Proofing	4.2.10. プルーフィングの通知
4.2.11. Initial Authenticator Binding	4.2.11. 初期認証子バインディング
4.3. Identity Assurance Level 3	4.3. アイデンティティ保証レベル 3
4.3.1. Proofing Types	4.3.1. 証明タイプ
4.3.2. Evidence Collection	4.3.2. 証拠収集
4.3.3. Attribute Requirements	4.3.3. 属性要件
4.3.4. Evidence Validation	4.3.4. 証拠の検証
4.3.5. Attribute Validation	4.3.5. 属性の検証
4.3.6. Verification Requirements	4.3.6. 検証要件
4.3.7. Onsite Attended Requirements (Locally Attended)	4.3.7. 現地出席要件（ローカルアテンダント）
4.3.8. Onsite Attended Requirements (Remotely Attended - Formerly Supervised Remote Identity Proofing)	4.3.8. 現地立会要件（遠隔立会-旧監督付き遠隔身元証明）
4.3.9. Notification of Proofing	4.3.9. 証明の通知
4.3.10. Initial Authenticator Binding	4.3.10. 最初の認証子バインディング
4.4. Summary of Requirements	4.4. 要件のまとめ
5. Subscriber Accounts	5. サブスクライバ・アカウント
5.1. Subscriber Accounts	5.1. 加入者アカウント
5.2. Subscriber Account Access	5.2. 加入者アカウントへのアクセス
5.3. Subscriber Account Maintenance and Updates	5.3. 加入者アカウントのメンテナンスおよび更新
5.4. Subscriber Account Suspension or Termination	5.4. 加入者アカウントの一時停止または終了
6. Threats and Security Considerations	6. 脅威およびセキュリティに関する考慮事項
6.1. Threat Mitigation Strategies	6.1. 脅威緩和戦略
6.2. Collaboration with Adjacent Programs	6.2. 隣接プログラムとの協力
7. Privacy Considerations	7. プライバシーへの配慮
7.1. Collection and Data Minimization	7.1. 収集とデータの最小化
7.1.1. Social Security Numbers	7.1.1. 社会保障番号
7.2. Notice and Consent	7.2. 通知と同意
7.3. Use Limitation	7.3. 利用制限
7.4. Redress	7.4. 救済
7.5. Privacy Risk Assessment	7.5. プライバシーリスク評価
7.6. Agency-Specific Privacy Compliance	7.6. 省庁固有のプライバシー・コンプライアンス
8. Usability Considerations	8. ユーザビリティに関する考慮事項
8.1. General User Considerations During Identity Proofing and Enrollment	8.1. アイデンティティ証明および登録時の一般的なユーザへの配慮
8.2. Pre-Enrollment Preparation	8.2. 登録前の準備
8.3. Identity Proofing and Enrollment	8.3. 身元証明および登録
8.4. Post-Enrollment	8.4. 登録後の準備
9. Equity Considerations	9. 公平性への配慮
9.1. Identity Resolution and Equity	9.1. アイデンティティーの解決と公平性
9.2. Identity Validation and Equity	9.2. アイデンティティの検証と公平性
9.3. Identity Verification and Equity	9.3. 本人確認と公平性
9.4. User Experience and Equity	9.4. ユーザー・エクスペリエンスと公平性
References	参考文献
Appendix A. Identity Evidence Examples by Strength	附属書 A. 強度別のアイデンティティ証拠の例
A.1. Fair Evidence Examples	A.1. 公正な証拠例
A.2. Strong Evidence Examples	A.2. 強い証拠の例
A.3. Superior Evidence Examples	A.3. 優れた証拠の例
Appendix B. List of Symbols, Abbreviations, and Acronyms	附属書 B. 記号、略語、頭字語一覧
Appendix C. Glossary	附属書 C．用語集
Appendix D. Change Log	附属書 D. 変更履歴
List of Tables	表 一覧
Table 1. IAL Requirements Summary	表 1. IAL要求事項の概要
Table 2. Identity Proofing and Enrollment Threats	表 2. 身分証明と入会の脅威
Table 3. Identity Proofing and Enrollment Threat Mitigation Strategies	表 3. アイデンティティ証明と登録の脅威軽減戦略
Table 4. Fair Evidence Examples	表 4. 公正な証拠の例
Table 5. Strong Evidence Examples	表 5. 強力な証拠の例
Table 6. Superior Evidence Examples	表 6. 優れた証拠の例
List of Figures	図 一覧
Fig. 1. Identity Proofing Process	図 1. 身元証明のプロセス

---

・2024.08.21 NIST SP 800-63B-4 (2nd Public Draft) Digital Identity Guidelines: Authentication and Authenticator Management

NIST SP 800-63B-4 (2nd Public Draft) Digital Identity Guidelines: Authentication and Authenticator Management	NIST SP 800-63B-4（第 2 次公開草案）デジタル・アイデンティティ・ガイドライン： 認証および認証子管理
Abstract	概要
This guideline focuses on the authentication of subjects who interact with government information systems over networks to establish that a given claimant is a subscriber who has been previously authenticated. The result of the authentication process may be used locally by the system performing the authentication or may be asserted elsewhere in a federated identity system. This document defines technical requirements for each of the three authenticator assurance levels. The guidelines are not intended to constrain the development or use of standards outside of this purpose. This publication supersedes NIST Special Publication (SP) 800-63B.	本ガイドラインは、ネットワークを介して政府の情報システムと相互作用する対象者の認証に焦点を当て、特定の請求者が以前に認証された加入者であることを立証する。認証プロセスの結果は、認証を実行するシステムによってローカルに使用されるか、または連携アイデンティティ・システムの他の場所でアサートされる。本文書は、3 つの認証子保証レベルごとに技術要件を定義する。このガイドラインは、この目的以外の標準の開発または使用を制約することを意図 するものではない。本書は、NIST 特別刊行物（SP）800-63B に取って代わるものである。

・[PDF] NIST.SP.800-63B-4.2pd

Table of Contents	目次
1. Introduction	1. はじめに
1.1. Notations	1.1. 表記
1.2. Document Structure	1.2. 文書の構造
2. Authentication Assurance Levels	2. 認証保証レベル
2.1. Authentication Assurance Level 1	2.1. 認証保証レベル 1
2.1.1. Permitted Authenticator Types	2.1.1. 許可される認証子タイプ
2.1.2. Authenticator and Verifier Requirements	2.1.2. 認証子および検証者の要件
2.1.3. Reauthentication	2.1.3. 再認証
2.2. Authentication Assurance Level 2	2.2. 認証保証レベル 2
2.2.1. Permitted Authenticator Types	2.2.1. 許可される認証子タイプ
2.2.2. Authenticator and Verifier Requirements	2.2.2. 認証子および検証者の要件
2.2.3. Reauthentication	2.2.3. 再認証
2.3. Authentication Assurance Level 3	2.3. 認証保証レベル 3
2.3.1. Permitted Authenticator Types	2.3.1. 許可される認証タイプ
2.3.2. Authenticator and Verifier Requirements	2.3.2. 認証子および検証者の要件
2.3.3. Reauthentication	2.3.3. 再認証
2.4. General Requirements	2.4. 一般要件
2.4.1. Security Controls	2.4.1. セキュリティ制御
2.4.2. Records Retention Policy	2.4.2. 記録保持方針
2.4.3. Privacy Requirements	2.4.3. プライバシー要件
2.4.4. Redress Requirements	2.4.4. 救済要件
2.5. Summary of Requirements	2.5. 要件のまとめ
3. Authenticator and Verifier Requirements	3. 認証子および検証者の要件
3.1. Requirements by Authenticator Type	3.1. 認証子供タイプ別要件
3.1.1. Passwords	3.1.1.パスワード
3.1.2. Look-Up Secrets	3.1.2. ルックアップ・シークレット
3.1.3. Out-of-Band Devices	3.1.3. 帯域外デバイス
3.1.4. Single-Factor OTP	3.1.4. 単一ファクタOTP
3.1.5. Multi-Factor OTPs	3.1.5. 多要素OTP
3.1.6. Single-Factor Cryptographic Authentication	3.1.6. シングルファクター暗号化認証
3.1.7. Multi-Factor Cryptographic Authentication	3.1.7. 多要素暗号化認証
3.2. General Authenticator Requirements	3.2. 一般的な認証機能要件
3.2.1. Physical Authenticators	3.2.1. 物理的認証子
3.2.2. Rate Limiting (Throttling)	3.2.2. レート制限（スロットリング）
3.2.3. Use of Biometrics	3.2.3. バイオメトリクスの使用
3.2.4. Attestation	3.2.4. 認証
3.2.5. Phishing (Verifier Impersonation) Resistance	3.2.5. フィッシング（検証者なりすまし）への耐性
3.2.6. Verifier-CSP Communications	3.2.6. 検証者と CSP の通信
3.2.7. Replay Resistance	3.2.7. リプレイ耐性
3.2.8. Authentication Intent	3.2.8. 認証の意図
3.2.9. Restricted Authenticators	3.2.9. 制限された認証子
3.2.10. Activation Secrets	3.2.10. アクティベーション・シークレット
3.2.11. Connected Authenticators	3.2.11. 接続された認証子
3.2.12. Random Values	3.2.12. ランダム値
3.2.13. Exportability	3.2.13. エクスポート可能性
4. Authenticator Event Management	4. 認証子イベント管理
4.1. Authenticator Binding	4.1. 認証子バインディング
4.1.1. Binding at Enrollment	4.1.1. 登録時のバインディング
4.1.2. Post-Enrollment Binding	4.1.2. 登録後のバインディング
4.1.3. Binding to a Subscriber-Provided Authenticator	4.1.3. サブスクライバが提供する認証機能へのバインディング
4.1.4. Renewal	4.1.4. 更新
4.2. Account Recovery	4.2. アカウント復旧
4.2.1. Account Recovery Methods	4.2.1. アカウント復旧方法
4.2.2. Recovery Requirements by IAL/AAL	4.2.2. IAL/AALによる復旧要件
4.2.3. Account Recovery Notification	4.2.3. アカウント復旧の通知
4.3. Loss, Theft, Damage, and Compromise	4.3. 紛失、盗難、破損、および危殆化
4.4. Expiration	4.4. 有効期限切れ
4.5. Invalidation	4.5. 無効化
4.6. Account Notifications	4.6. アカウント通知
5. Session Management	5. セッション管理
5.1. Session Bindings	5.1. セッション・バインディング
5.1.1. Browser Cookies	5.1.1. ブラウザクッキー
5.1.2. Access Tokens	5.1.2. アクセストークン
5.2. Reauthentication	5.2. 再認証
5.3. Session Monitoring	5.3. セッション・モニタリング
6. Threats and Security Considerations	6. 脅威とセキュリティに関する考慮事項
6.1. Authenticator Threats	6.1. 認証子の脅威
6.2. Threat Mitigation Strategies	6.2. 脅威緩和戦略
6.3. Authenticator Recovery	6.3. 認証子の復旧
6.4. Session Attacks	6.4. セッション攻撃
7. Privacy Considerations	7. プライバシーに関する考察
7.1. Privacy Risk Assessment	7.1. プライバシー・リスクの評価
7.2. Privacy Controls	7.2. プライバシー管理
7.3. Use Limitation	7.3. 利用制限
7.4. Agency-Specific Privacy Compliance	7.4. 省庁固有のプライバシー・コンプライアンス
8. Usability Considerations	8. ユーザビリティに関する考慮事項
8.1. Common Usability Considerations for Authenticators	8.1. 認証子に関する一般的なユーザビリティの考慮事項
8.2. Usability Considerations by Authenticator Type	8.2. 認証子タイプ別のユーザビリティに関する考慮事項
8.2.1. Passwords	8.2.1. パスワード
8.2.2. Look-Up Secrets	8.2.2. ルックアップ・シークレット
8.2.3. Out-of-Band	8.2.3. 帯域外
8.2.4. Single-Factor OTP	8.2.4. 単一ファクタ OTP
8.2.5. Multi-Factor OTP	8.2.5. 多要素OTP
8.2.6. Single-Factor Cryptographic Authenticator	8.2.6. シングルファクタ暗号化認証
8.2.7. Multi-Factor Cryptographic Authenticator	8.2.7. 多要素暗号化認証機能
8.3. Summary of Usability Considerations	8.3. ユーザビリティに関する考慮事項のまとめ
8.4. Usability Considerations for Biometrics	8.4. バイオメトリクスに関するユーザビリティの考慮事項
9. Equity Considerations	9. 公平性に関する考察
References	参考文献
Appendix A. Strength of Passwords	附属書 A. パスワードの強度
A.1. Introduction	A.1. はじめに
A.2. Length	A.2. 長さ
A.3. Complexity	A.3. 複雑さ
A.4. Central vs. Local Verification	A.4. 中央検証とローカル検証
A.5. Summary	A.5. まとめ
Appendix B. Syncable Authenticators	附属書 B. 同期可能な認証子
B.1. Introduction	B.1. はじめに
B.2. Cloning of Authentication Keys	B.2. 認証キーのクローニング
B.3. Implementation Requirements	B.3. 実装要件
B.4. Sharing	B.4. 共有
B.5. Example	B.5. 例
B.6. Security Considerations	B.6. セキュリティに関する考察
Appendix C. List of Symbols, Abbreviations, and Acronyms	附属書 C. 記号、略語、頭字語一覧
Appendix D. Glossary	附属書 D．用語集
Appendix E. Change Log	附属書 E. 変更履歴
List of Tables	表 一覧
Table 1. Summary of Secrets (non-normative)	表 1. 秘密事項の要約（非基準）
Table 2. Authenticator Threats	表 2. 認証子の脅威
Table 3. Mitigating Authenticator Threats	表 3. 認証子の脅威を軽減する
Table 4. Syncable Authenticator Threats, Challenges, and Mitigations	表 4. 同期可能な認証子の脅威、課題、および緩和策
List of Figures	図 一覧
Fig. 1. Summary of requirements by AAL	図 1. AAL による要件の概要
Fig. 2. Transfer of Secret to Primary Device	図 2. プライマリ・デバイスへの秘密の転送
Fig. 3. Transfer of Secret to Out-of-band Device	図 3. 帯域外デバイスへの秘密転送
Fig. 4. Usability considerations by authenticator type	図 4. 認証タイプ別のユーザビリティ

---

・2024.08.21 NIST SP 800-63C-4 (2nd Public Draft) Digital Identity Guidelines: Federation and Assertions

NIST SP 800-63C-4 (2nd Public Draft) Digital Identity Guidelines: Federation and Assertions	NIST SP 800-63C-4（第 2 次公開草案）デジタル・アイデンティティ・ガイドライン： フェデレーションおよびアサーション
Abstract	概要
This guideline focuses on the use of federated identity and the use of assertions to implement identity federations. Federation allows a given credential service provider to provide authentication attributes and (optionally) subscriber attributes to a number of separately-administered relying parties. Similarly, relying parties may use more than one credential service provider. The guidelines are not intended to constrain the development or use of standards outside of this purpose. This publication supersedes NIST Special Publication (SP) 800-63C.	このガイドラインは、フェデレーションされた ID の使用と、ID フェデレーションを実装するための アサーションの使用に焦点を当てている。フェデレーションにより、所定のクレデンシャル・サービス・プロバイダは、認証属性と（オプ ションで）サブスクライバ属性を、個別に管理される多数の依拠当事者に提供できる。同様に、依拠当事者は複数のクレデンシャル・サービス・プロバイダを使用できる。このガイドラインは、この目的以外の標準の開発または使用を制限することを意図 していない。本書は、NIST 特別刊行物（SP）800-63C に取って代わるものである。

・[PDF] NIST.SP.800-63C-4.2pd

Table of Contents	目次
1. Introduction	1. はじめに
1.1. Notations	1.1. 表記
1.2. Document Structure	1.2. 文書の構造
2. Federation Assurance Level (FAL)	2. フェデレーション保証レベル（FAL）
2.1. Common FAL Requirements	2.1. 共通FAL要件
2.2. Federation Assurance Level 1 (FAL1)	2.2. フェデレーション保証レベル 1（FAL1）
2.3. Federation Assurance Level 2 (FAL2)	2.3. フェデレーション保証レベル2（FAL2）
2.4. Federation Assurance Level 3 (FAL3)	2.4. フェデレーション保証レベル 3（FAL3）
2.5. Requesting and Processing xALs	2.5. xALの要求と処理
3. Common Federation Requirements	3. 共通のフェデレーション要件
3.1. Roles	3.1. 役割
3.1.1. Credential Service Provider (CSP)	3.1.1. クレデンシャル・サービス・プロバイダ（CSP）
3.1.2. Identity Provider (IdP)	3.1.2. アイデンティティ・プロバイダ（IdP）
3.1.3. Relying Party (RP)	3.1.3. 依拠当事者（RP）
3.2. Functions	3.2. 機能
3.2.1. Trust Agreement Management	3.2.1. トラスト・エージェント管理
3.2.2. Authorized Party	3.2.2. 認定当事者
3.2.3. Proxied Federation	3.2.3. 代理フェデレーション
3.2.4. Fulfilling Roles and Functions of a Federation Model	3.2.4. フェデレーションモデルの役割と機能
3.3. Federated Identifiers	3.3. フェデレーション識別子
3.3.1. Pairwise Pseudonymous Identifiers (PPI)	3.3.1. ペアワイズ仮名識別子（PPI）
3.4. Trust Agreements	3.4. 信頼協定
3.4.1. Bilateral Trust Agreements	3.4.1. 二者間信頼協定
3.4.2. Multilateral Trust Agreements	3.4.2. 複数者間信頼協定
3.4.3. Redress Requirements	3.4.3. 救済要件
3.5. Identifiers and Cryptographic Key Management for CSPs, IdPs, and RPs	3.5. CSP、IdP、および RP の識別子および暗号鍵管理
3.5.1. Cryptographic Key Rotation	3.5.1. 暗号鍵のローテーション
3.5.2. Cryptographic Key Storage	3.5.2. 暗号鍵の保管
3.5.3. Software Attestations	3.5.3. ソフトウェア認証
3.6. Authentication and Attribute Disclosure	3.6. 認証と属性開示
3.7. RP Subscriber Accounts	3.7. RP加入者アカウント
3.7.1. Account Linking	3.7.1. アカウントのリンク
3.7.2. Account Resolution	3.7.2. アカウントの解決
3.7.3. Alternative Authentication Processes	3.7.3. 代替認証プロセス
3.8. Authenticated Sessions at the RP	3.8. RPでの認証セッション
3.9. Privacy Requirements	3.9. プライバシー要件
3.9.1. Transmitting Subscriber Information	3.9.1. 加入者情報の送信
3.10. Security Controls	3.10. セキュリティ管理
3.10.1. Protection from Injection Attacks	3.10.1. インジェクション攻撃からの保護
3.10.2. Protecting Subscriber Information	3.10.2. 加入者情報の保護
3.10.3. Storing Subscriber Information	3.10.3. 加入者情報の保存
3.11. Identity Attributes	3.11. アイデンティティ属性
3.11.1. Attribute Bundles	3.11.1. 属性バンドル
3.11.2. Derived Attribute Values	3.11.2. 派生属性値
3.11.3. Identity APIs	3.11.3. アイデンティティAPI
3.12. Assertion Protection	3.12. アサーションの保護
3.12.1. Assertion Identifier	3.12.1. アサーション識別子
3.12.2. Signed Assertion	3.12.2. 署名されたアサーション
3.12.3. Encrypted Assertion	3.12.3. 暗号化されたアサーション
3.12.4. Audience Restriction	3.12.4. 視聴者制限
3.13. Bearer Assertions	3.13. ベアラアサーション
3.14. Holder-of-Key Assertions	3.14. HKアサーション
3.15. Bound Authenticators	3.15. バウンド認証子
3.15.1. RP-Provided Bound Authenticator Issuance	3.15.1. RPが提供するバウンド認証子の発行
3.15.2. Subscriber-Provided Bound Authenticator Binding Ceremony	3.15.2. サブスクライバが提供するバウンド認証子のバインディング・セレモニー
3.16. RP Requirements for Processing Holder-of-Key Assertions and Bound Authenticators	3.16. 鍵所有者アサーションおよびバウンド認証子の処理に関する RP 要件
4. General-Purpose IdPs	4. 汎用 IdP
4.1. IdP Account Provisioning	4.1. IdP アカウント・プロビジョニング
4.2. Federation Transaction	4.2. フェデレーション・トランザクション
4.3. Trust Agreements	4.3. 信任契約
4.3.1. Apriori Trust Agreement Establishment	4.3.1. アプリオリ信任契約の成立
4.3.2. Subscriber-driven Trust Agreement Establishment	4.3.2. 加入者主導型信任契約の確立
4.4. Discovery and Registration	4.4. 発見と登録
4.4.1. Manual Registration	4.4.1. 手動登録
4.4.2. Dynamic Registration	4.4.2. 動的登録
4.5. Subscriber Authentication at the IdP	4.5. IdP における加入者認証
4.6. Authentication and Attribute Disclosure	4.6. 認証と属性開示
4.6.1. IdP-Controlled Decisions	4.6.1. IdP が制御する決定
4.6.2. RP-Controlled Decisions	4.6.2. RPが制御する決定
4.6.3. Provisioning Models for RP subscriber accounts	4.6.3. RP 加入者アカウントのプロビジョニングモデル
4.6.4. Attribute Synchronization	4.6.4. 属性の同期
4.6.5. Provisioning APIs	4.6.5. プロビジョニング API
4.6.6. Collection of Additional Attributes by the RP	4.6.6. RPによる追加属性の収集
4.6.7. Time-based Removal of RP Subscriber Accounts	4.6.7. RP 加入者アカウントの時間ベースの削除
4.7. Reauthentication and Session Requirements in Federated Environments	4.7. 連携環境における再認証およびセッション要件
4.8. Shared Signaling	4.8. 共有シグナリング
4.9. Assertion Contents	4.9. アサーション・コンテンツ
4.10. Assertion Requests	4.10. アサーション・リクエスト
4.11. Assertion Presentation	4.11. アサーション・プレゼンテーション
4.11.1. Back-Channel Presentation	4.11.1. バックチャネル・プレゼンテーション
4.11.2. Front-Channel Presentation	4.11.2. フロントチャンネル・プレゼンテーション
5. Subscriber-Controlled Wallets	5. 加入者管理ウォレット
5.1. Wallet Activation	5.1. ウォレットの有効化
5.2. Federation Transaction	5.2. フェデレーション・トランザクション
5.3. Trust Agreements	5.3. トラスト・アグリーメント
5.4. Provisioning the Subscriber-Controlled Wallet	5.4. 加入者管理ウォレットのプロビジョニング
5.4.1. Deprovisioning the Subscriber-Controlled Wallet	5.4.1. サブスクライバが管理するウォレットのデプロビジョニング
5.5. Discovery and Registration	5.5. ディスカバリーと登録
5.6. Authentication and Attribute Disclosure	5.6. 認証と属性開示
5.7. Assertion Requests	5.7. アサーション・リクエスト
5.8. Assertion Contents	5.8. アサーション・コンテンツ
5.9. Assertion Presentation	5.9. アサーション・プレゼンテーション
5.10. Assertion Validation	5.10. アサーションの検証
5.11. RP Subscriber Accounts	5.11. RP 利用者アカウント
6. Security	6. セキュリティ
6.1. Federation Threats	6.1. フェデレーションの脅威
6.2. Federation Threat Mitigation Strategies	6.2. フェデレーションの脅威緩和戦略
7. Privacy Considerations	7. プライバシーに関する考慮事項
7.1. Minimizing Tracking and Profiling	7.1. トラッキングとプロファイリングの最小化
7.2. Notice and Consent	7.2. 通知と同意
7.3. Data Minimization	7.3. データの最小化
7.4. Agency-Specific Privacy Compliance	7.4. 省庁固有のプライバシー・コンプライアンス
7.5. Blinding in Proxied Federation	7.5. プロキシされたフェデレーションにおける盲検化
8. Usability Considerations	8. ユーザビリティに関する考慮事項
8.1. General Usability Considerations	8.1. 一般的なユーザビリティに関する考察
8.2. Specific Usability Considerations	8.2. 特定のユーザビリティに関する考慮事項
8.2.1. User Perspectives on Online Identity	8.2.1. オンライン・アイデンティティに関するユーザーの視点
8.2.2. User Perspectives of Trust and Benefits	8.2.2. 信頼と利点に関するユーザーの視点
8.2.3. User Mental Models and Beliefs	8.2.3. ユーザーのメンタル・モデルと信念
9. Equity Considerations	9. 公平性の考慮
10. Examples	10. 例
10.1. Mapping FALs to Common Federation Protocols	10.1. FALを共通のフェデレーション・プロトコルにマッピングする
10.2. Direct Connection to an Agency’s IdP	10.2. エージェンシの IdP への直接接続
10.3. Multilateral Federation Network	10.3. 多国間フェデレーション・ネットワーク
10.4. Issuance of a Credential to a Digital Wallet	10.4. デジタル・ウォレットへのクレデンシャルの発行
10.5. Enterprise Application Single-Sign-On	10.5. エンタープライズアプリケーションシングルサインオン
10.6. FAL3 With a Smart Card	10.6. スマートカードによる FAL3
10.7. FAL3 With a non-PKI Authenticator	10.7. FAL3 と PKI 以外の認証機能
10.8. FAL3 With Referred Token Binding	10.8. 参照トークン・バインディングを使用する FAL3
10.9. Ephemeral Federated Attribute Exchange	10.9. エフェメラルなフェデレート属性交換
10.10. Multiple Different Authorized Parties and Trust Agreements	10.10. 複数の異なる認可された当事者と信頼契約
10.11. Shared Pairwise Pseudonymous Identifiers for Multiple RPs	10.11. 複数のRPのための共有ペアワイズ仮名識別子
10.12. RP Authentication to an IdP	10.12. IdPに対するRP認証
References	参考文献
Appendix A. List of Symbols, Abbreviations, and Acronyms	附属書 A. 記号、略語、頭字語一覧
Appendix B. Glossary	附属書 B. 用語集
Appendix C. Changelog	附属書 C. 変更履歴
List of Tables	表 一覧
Table 1. Federation Assurance Levels	表 1. フェデレーション保証レベル
Table 2. Federation Threats	表 2. フェデレーションの脅威
Table 3. Mitigating Federation Threats	表 3. フェデレーションの脅威を軽減する
Table 4. Proxy Characteristics	表 4. プロキシの特徴
Table 5. FAL Protocol Examples	表 5. FALプロトコルの例
List of Figures	図 一覧
Fig. 1. Federation Proxy	図 1. フェデレーションプロキシ
Fig. 2. Federation Authority	図 2. フェデレーションオーソリティ
Fig. 3. Holder-of-Key Assertions	図 3. 鍵の所有者のアサーション
Fig. 4. Bound Authenticators	図 4. バウンド認証機能
Fig. 5. Subscriber-Provided Bound Authenticator Binding Ceremony	図 5. サブスクライバが提供するバウンド認証機能バインディング・セレモニー
Fig. 6. Federation Overview	図 6. フェデレーションの概要
Fig. 7. Just-In-Time Provisioning	図 7. ジャストインタイム・プロビジョニング
Fig. 8. Pre-Provisioning	図 8. 事前プロビジョニング
Fig. 9. Ephemeral Provisioning	図 9. エフェメラル・プロビジョニング
Fig. 10. Session Lifetimes	図 10. セッションの有効期間
Fig. 11. Back-channel Presentation	図 11. バックチャネル・プレゼンテーション
Fig. 12. Front-channel Presentation	図 12. フロント・チャンネル・プレゼンテーション
Fig. 13. Subscriber-Controlled Wallet	図 13. 加入者が管理するウォレット

---

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

・2024.04.25 米国 NIST SP 800-63B [補足 1] NIST SP 800-63B: デジタル・アイデンティティ・ガイドライン - 認証およびライフサイクル管理への同期可能な本人認証の組み込み

・2022.12.19 NIST SP 800-63-4 (ドラフト) デジタル・アイデンティティ・ガイドライン 、63A-4 (ドラフト) 登録と身元確認、63B-4 (ドラフト) 本人認証とライフサイクル管理、63C-4 (ドラフト) 連携とアサーション

・2020.06.11 NIST SP 800-63-4(Draft) PRE-DRAFT Call for Comments: Digital Identity Guidelines

・2020.03.07 NIST SP800-63-3 Digital Identity GuidelinesにEditorialな修正がありました

バーゼル銀行監督委員会 パブコメ 健全なサードパーティリスク管理のための諸原則について協議 (2024.07.09)

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

バーゼル銀行監督委員会が、健全なサードパーティリスク管理のための諸原則についてのパブリックコメントを求めています。これは、2005年に銀行・証券・保険の業態横断的な文書である「金融サービスにおけるアウトソーシング」（原題：Outsourcing in Financial Services）を銀行業態について置き換えるものとして作成されているようです。

具体的には銀行のサードパーティリスク管理について、

・銀行に対する９つの原則（取締役会等の責任、リスク管理枠組みの実施、リスク評価、デュー・デリジェンス、契約締結、オンボーディング、継続的なモニタリング、業務継続管理、契約終了）及び

・監督当局に対する３つの原則（銀行のリスク評価、システム全体の集中リスク、当局間の協調）

からなる計12の原則を示していますね...

サードパーティリスクとして、

・サプライチェーンリスク

・集中リスク

という概念も入っていますね。。。

集中リスクは、いわゆるクラウド事業者に対するリスクで、夏井先生が2010年に提唱した「クラウドは竹」という話に通じます(^^)

●  Basel Committee on Banking Supervision

プレス...

・2024.07.09 Basel Committee consults on principles for the sound management of third-party risk

Basel Committee consults on principles for the sound management of third-party risk	バーゼル委員会、健全なサードパーティリスク管理のための諸原則について協議
・The Basel Committee has published a consultation on Principles for the sound management of third-party risk.	・バーゼル委員会は、「健全なサードパーティリスク管理のための諸原則」についての協議を公表した。
・The proposed principles provide guidance to banks and prudential supervisors on effective third-party risk management, aiming to enhance banks' ability to withstand operational disruptions and mitigate the impact of severe disruptive events.	・提案された原則は、効果的なサードパーティ・リスク管理について銀行および健全性監督当局に指針を提供し、銀行の業務中断への耐性強化と深刻な業務中断事象の影響の低減を目的としている。
・Comments on the proposed principles are requested by 9 October 2024.	・提案された原則に関する意見は、2024年10月9日まで求められている。
The Basel Committee on Banking Supervision today published a consultative document proposing Principles for the sound management of third-party risk in the banking sector.	バーゼル銀行監督委員会は本日、銀行セクターにおける健全なサードパーティリスク管理のための諸原則を提案する協議文書を公表した。
Ongoing digitalisation has led to rapid adoption of innovative approaches in the banking sector. As a result, banks have become increasingly reliant on third parties for services that they had not previously undertaken. This increased reliance on third parties beyond the scope of traditional outsourcing, coupled with the expansion of supply chains and rising concentration risks, has necessitated an update to the 2005 Joint Forum paper Outsourcing in financial services, specifically for the banking sector.	デジタル化の進展により、銀行業界では革新的なアプローチが急速に採用されるようになった。その結果、銀行は従来は自社で対応していなかったサービスについて、サードパーティへの依存度を高めている。従来のアウトソーシングの範囲を超えてサードパーティへの依存度が高まっていること、またサプライチェーンの拡大や集中リスクの増大と相まって、2005年の共同フォーラムの論文「金融サービスにおけるアウトソーシング」の更新が必要となっている。
The consultative document consists of 12 high-level principles offering guidance to banks and supervisors on effectively managing and supervising risks from third-party arrangements. The Principles introduce the concept of a third-party life cycle and emphasise overarching concepts such as criticality and proportionality. Furthermore, they delve into the topics of supply chain risk and concentration risk and highlight the importance of supervisory coordination and dialogue across sectors and borders.	この協議文書は、サードパーティ契約から生じるリスクの効果的な管理と監督について、銀行と監督当局に指針を提供する12のハイレベル原則で構成されている。原則では、サードパーティ・ライフサイクルという概念が導入され、重要度や比例性といった包括的な概念が強調されている。さらに、サプライチェーンリスクと集中リスクについても掘り下げ、セクターや国境を越えた監督上の調整と対話の重要性が強調されている。
The Principles complement and expand on the Financial Stability Board's 2023 report Enhancing third-party risk management and oversight – a toolkit for financial institutions and financial authorities. While primarily directed at large internationally active banks and their prudential supervisors, these Principles also offer benefits to smaller banks and authorities in all jurisdictions. They establish a common baseline for banks and supervisors for the risk management of third parties, while providing the necessary flexibility to accommodate evolving practices and regulatory frameworks across jurisdictions.	本原則は、金融安定理事会(FSB)が2023年に発表した報告書「サードパーティ・リスク管理と監督の強化 – 金融機関および金融当局のためのツールキット」を補完し、さらに発展させたものである。本原則は、主に国際的に活動する大手銀行とその監督当局を対象としているが、あらゆる管轄区域の小規模な銀行や当局にもメリットをもたらす。本原則は、サードパーティのリスク管理に関する銀行と監督当局の共通のベースラインを確立する一方で、管轄区域ごとに進化する慣行や規制枠組みに対応するための必要な柔軟性も提供する。
To remain adaptable and applicable to a wide range of technologies, the Principles maintain a technology-neutral stance. As a result, they can be applied to recent trends like artificial intelligence, machine learning and blockchain technology, even though these trends are not explicitly referenced.	幅広いテクノロジーに適応し適用可能であり続けるため、本原則はテクノロジーに中立な立場を維持している。その結果、本原則は、人工知能、機械学習、ブロックチェーン技術といった最近のトレンドにも適用可能である。これらのトレンドは明示的に言及されていないが、それでも適用可能である。

・[PDF] 

・[DOCX][PDF] 仮訳...

原則...

Principle 1: The board of directors has ultimate responsibility for the oversight of all TPSP arrangements and should approve a clear strategy for TPSP arrangements within the bank’s risk appetite and tolerance for disruption.	原則1：取締役会は、すべてのTPSPとの取決めを監督する最終的な責任を有し、銀行のリスクアペタイトと混乱に対する許容度の範囲内で、TPSPとの取決めに関する明確な戦略を承認すべき。
Principle 2: The board of directors should ensure that senior management implements the policies and processes of the third-party risk management framework (TPRMF) in line with the bank’s third-party strategy, including reporting of TPSP performance and risks related to TPSP arrangements, and mitigating actions.	原則2：取締役会は、上級管理職が、サードパーティの実績並びにTPSPとの取り決めに関するリスクの報告及び低減措置を含む戦略に沿って、サードパーティリスク管理の枠組みの方針及びプロセスを実施することを確実にすべき。
Principle 3: Banks should perform a comprehensive risk assessment under the TPRMF to evaluate and manage identified and potential risks both before entering into and throughout a TPSP arrangement.	原則3：銀行は、TPSPとの取決めを締結する前及び取決めを結んでいる間を通じて、特定されたリスク及び潜在的なリスクを評価し管理するために、サードパーティリスク管理の枠組みの下で包括的なリスク評価を行うべき。
Principle 4: Banks should conduct appropriate due diligence on a prospective TPSP prior to entering into an arrangement.	原則4： 銀行は、TPSPとの取決めを締結する前に適切なデュー・デリジェンスを行うべき。
Principle 5: TPSP arrangements should be governed by legally binding written contracts that clearly describe rights and obligations, responsibilities and expectations of all parties in the arrangement.	原則5：TPSPとの取決めは、すべての当事者の権利、責 任及び期待を明確に記述した法的拘束力のある書面による 契約によって管理されるべき。
Principle 6: Banks should dedicate sufficient resources to support a smooth transition of a new TPSP arrangement in order to prioritise the resolution of any issues identified during due diligence or interpretation of contractual provisions.	原則6：銀行は、デュー・デリジェンスや契約条項の解釈の過程で特定されたあらゆる問題の解決を優先させるために、 新たなサードパーティとの取決めに円滑に移行するための十分な資源を投入すべき。
Principle 7: Banks should, on an ongoing basis, assess and monitor the performance and changes in the risks and criticality of TPSP arrangements and report accordingly to board and senior management. Banks should respond to issues as appropriate.	原則7：銀行は、TPSPとの取決めのパフォーマンス、リスクの変化、及び重要性を継続的に評価・監視し、その結果を取締役会や上級管理職に報告し、必要に応じて 問題に対応すべき。
Principle 8: Banks should maintain robust business continuity management to ensure their ability to operate in case of a TPSP service disruption.	原則8：銀行は、TPSPのサービスが中断した場合に業務を継続する能力を確保するために、堅固な業務継続 管理を維持すべき。
Principle 9: Banks should maintain exit plans for planned termination and exit strategies for unplanned termination of TPSP arrangements.	原則9：銀行は、TPSPとの取決めの計画的な終了のための出口計画及び計画外の終了のための出口戦略を 維持すべき。
Principle 10: Supervisors should consider third-party risk management as an integral part of ongoing assessment of banks.	原則10：監督当局は、サードパーティリスク管理を銀行の継続的な評価の不可欠な部分として考慮すべき。
Principle 11: Supervisors should analyse the available information to identify potential systemic risks posed by the concentration of one or multiple TPSPs in the banking sector.	原則11：監督当局は、銀行セクターにおける1つ又は複数のTPSPの集中がもたらす潜在的なシステミック・リスクを特定するために、利用可能な情報を分析すべき。
Principle 12: Supervisors should promote coordination and dialogue across sectors and borders to monitor systemic risks posed by critical TPSPs that provide services to banks.	原則12：監督当局は、セクターや国境を越えて銀行にサービスを 提供する重要なTPSPがもたらすシステミック・リスクをモニターするために、協調と対話を促進すべき。

---

金融庁からの発表...

● 金融庁

・2024.07.12 バーゼル銀行監督委員会による市中協議文書「健全なサードパーティリスク管理のための諸原則」の公表について

本件に関する金融庁・日本銀行作成説明資料

・2024.08.14 [PDF] バーゼル銀行監督委員会による市中協議文書「健全なサードパーティリスク管理のための諸原則」について

---

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

・2021.02.17 クラウドは竹 クラウド集中リスク

・2010.05.31 パブリッククラウドコンピューティングサービスは竹である　（夏井説）

こういう視点も...

・2021.02.19 除草剤をまけば強い植物だけが生き残る

英国 意見募集：ソフトウェアベンダーのための実践規範 (2024.08.02)

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

英国政府は、ソフトウェアの開発と流通における一般的な誤りを防止し、ソフトウェア・ベンダーとその顧客との情報共有を改善のために、ソフトウェアベンダーのための実践規範のドラフトを公表し、意見募集をしていますね...１週間と短いですね...

同時に発表されている「AIのサイバーセキュリティ」と連動しているようです...

● GOV.UK

・2024.08.02 A Code of Practice for Software Vendors: call for views

意見対象は次...

・2024.08.02 Call for views on the Code of Practice for Software Vendors

目次...

Contents	目次
Executive summary	エグゼクティブサマリー
Chapter 1: Introduction	第1章：序文
Chapter 2: DSIT activity	第2章：DSITの活動
Chapter 3: How organisations procuring software should use this Code of Practice	第3章：ソフトウェアを調達する組織は、この実践規範をどのように利用すべきか
Chapter 4: Voluntary Code of Practice for Software Vendors	第4章：ソフトウェアベンダーのための自主規範
Chapter 5: Supporting materials	第5章：参考資料
Chapter 6: How to respond to the call for views	第6章：意見募集への対応方法
Annex A: Full Code of Practice	附属書A：実施規範全文
Annex B: Implementation guidance example	附属書B：実施ガイダンス例
Annex C: Call for views survey questionnaire	附属書C：意見募集調査アンケート

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

Executive summary	エグゼクティブサマリー
In January 2024, the Department for Science, Innovation and Technology (DSIT) published the government response to the call for views on software resilience and security for businesses and organisations. This response outlined the Government’s proposed policy package that aims to raise the baseline expectations of software security, and to improve software resilience across the UK.	2024年1月、科学技術革新省（DSIT）は、企業・組織のためのソフトウェアのレジリエンスとセキュリティに関する意見募集に対する政府の回答を公表した。この回答では、ソフトウェア・セキュリティに対する基本的な期待を高め、英国全体のソフトウェア・レジリエンスを改善することを目的とした、政府の政策パッケージ案を概説した。
This document provides businesses with the opportunity to provide feedback on the Government’s primary proposed policy intervention that was developed in response to engagement with stakeholders: the Code of Practice for Software Vendors.	本書は、利害関係者とのエンゲージメントに応じて策定された政府の主要な政策介入案である「ソフトウェア・ベンダーのための実施規範」に対するフィードバックを提供する機会を企業に提供するものである。
The Code of Practice for Software Vendors outlines the fundamental security and resilience measures that should reasonably be expected of all organisations that develop and / or sell software to organisational customers. It includes guidance on how software should be developed, built, deployed and maintained, and how vendors can communicate with effectively with customers that procure their software. In engaging with this Code of Practice, software vendors will significantly improve the cyber resilience of their product and services.	ソフトウェア・ベンダーのための実施規範」は、ソフトウェアを開発し、あるいは組織の顧客に販売するすべての組織に合理的に期待されるべき基本的なセキュリティとレジリエンスの対策を概説している。これには、ソフトウ ェアをどのように開発、構築、配備、保守すべきか、また、ベンダーがソフトウ ェアを調達する顧客とどのように効果的なコミュニケーションをとるべきか に関する指針も含まれている。この実践規範に取り組むことで、ソフトウェア・ベンダーは、その製品とサービスのサイバー・レジリエンスを大幅に改善することができる。
The Code of Practice is made up of 21 provisions over 4 principles:	この実施規範は、4つの原則を含む21の条項で構成されている：
・Principle 1: Secure design and development: this principle ensures that the product or service is appropriately secure when provided.	・原則1：安全な設計と開発：この原則は、製品やサービスがプロバイダとして提供される際に、適切に安全であることを保証する。
・Principle 2: Build environment security: this principle ensures that the appropriate steps are taken to minimise the risk of build environments becoming compromised and protect the integrity and quality of the software.	・原則2：ビルド環境のセキュリティ：この原則は、ビルド環境が危険にさらされるリスクを最小化し、ソフトウェアの完全性と品質を保護するための適切な措置が講じられていることを保証する。
・Principle 3: Secure deployment and maintenance: this principle ensures that the product or service remains secure throughout its lifetime, to minimise the likelihood and impact of vulnerabilities.	・原則3：安全な配備と保守：この原則は、製品またはサービスがその耐用年数を通じて安全であり続け、脆弱性の可能性と影響を最小化することを保証する。
・Principle 4: Communication with customers: this principle ensures that vendor organisations provide sufficient information to customers to enable effective risk and incident management.	・原則4：顧客とのコミュニケーション：この原則は、効果的なリスクマネジメントとインシデントマネジメントを可能にするために、ベンダー組織が十分な情報を顧客に提供することを保証する。
The Code of Practice, co-designed with industry leaders, academics, and technical experts from the National Cyber Security Centre, has been developed to support any organisation that develops and/or sells software to be sold to organisational customers (B2B). This includes organisations that sell solely software products or services, or organisations selling digital products or services that contain software. The government and co-creators have been mindful that organisations vary in size, capacity and resources, and organisations will have to engage in risk assessments to determine the most effective way in which they can follow this Code of Practice. Nevertheless, the Code of Practice provides clarity on key, underlying principles that represent best practices to help software vendors develop and distribute software securely.	この実施規範は、業界のリーダー、学者、National Cyber Security Centreの技術専門家と共同で策定したもので、組織の顧客（B2B）に販売するソフトウェアを開発・販売するあらゆる組織を支援するために作成された。これには、ソフトウェア製品やサービスのみを販売する組織や、ソフトウェアを含むデジタル製品やサービスを販売する組織が含まれる。政府と共同作成者は、組織の規模、能力、リソースがさまざまであることを念頭に置いており、組織は、この実施規範に従うための最も効果的な方法を決定するために、リスクアセスメントに取り組まなければならない。とはいえ、この実施規範は、ソフトウェアベンダーがソフトウェアを安全に開発・配布するためのベストプラクティスを代表する重要な基本原則を明確にするものである。
Technical controls and implementation guidance will be published alongside the Code of Practice. This will set out the minimum set of objective controls that a software vendor should demonstrate to provide confidence in the resilience of their software product or service as well as guidance to support organisations in identifying the best implementation options for them.	技術的な管理と実装の手引きは、この「実施規範」とともに公表される予定である。これは、ソフトウェアベンダーが、そのソフトウェア製品やサービスのレジリエンスに対する信頼性を提供するために示すべき客観的な管理の最小限のセットと、組織にとって最適な実装オプションを特定するための支援ガイダンスを規定するものである。
This call for views aims to gather views on the market need for the Code of Practice for Software Vendors, the audience that this policy should be addressing, and the suitability of the Code and proposed supporting materials.	この意見募集は、ソフトウェアベンダーのための実施規範の市場ニーズ、この方針が取り組むべき対象者、実施規範と支援資料案の適合性について意見を集めることを目的としている。

・[PDF]

コードプラクティス...

Annex A: Full Code of Practice	附属書 A：実施規範全文
Principle 1: Secure design and development	原則1：安全な設計と開発
This principle ensures that the software product or service is appropriately secure when provided.	この原則は、ソフトウェア製品またはサービスがプロバイダとして提供される際に、適切にセキュアであることを保証するものである。
The Senior Responsible Officer in vendor organisations shall do the following:	ベンダ組織の上級責任者は、以下を実施しなければならない：
1.1 Ensure the organisation follows an established secure development framework.	1.1 組織が確立されたセキュアな開発フレームワークに従っていることを確認する。
1.2 Ensure the organisation understands the composition of their software products and services and that risks linked to the ingestion and maintenance of third-party components, including open-source components, are assessed throughout the lifecycle.	1.2 組織がソフトウェア製品及びサービスの構成を理解し、オープンソースソフトウェアコンポーネントを含むサードパーティ製コンポーネントの取り込み及び保守に関連するリスクを、ライフサイクル全体を通じてアセスメントする。
1.3 Ensure the organisation has a clear process for testing software before distribution.	1.3 組織は、配布前にソフトウェアをテストするための明確なプロセスを持っていることを確認する。
1.4 Ensure that the organisation follows secure by default principles throughout the development lifecycle of the product.	1.4 組織が、製品の開発ライフサイクルを通じて、セキュアバイデフォルトの原則に従うことを確実にする。
The Senior Responsible Officer in vendor organisations should do the following:	ベンダ組織の上級責任者は、以下のことを行うべきである：
1.5 Ensure secure by design principles are followed throughout the development process.	1.5 開発プロセス全体を通じて、セキュアバイデザインの原則に確実に従う。
1.6 Encourage the use of appropriate security tools and technologies to make sure that the default options throughout development and distribution are secure.	1.6 適切なセキュリティツールや技術の使用を奨励し、開発・配布のデフォルトオプショ ンがセキュアであることを確認する。
Principle 2: Build environment security	原則 2: 構築環境のセキュリティ
This principle ensures that the appropriate steps are taken to minimise the risk of build environments becoming compromised and protect the integrity and quality of the software.	この原則は、ビルド環境が危険にさらされるリスクを最小化し、ソフトウエアの完全性と品 質を保護するために適切な措置が取られることを保証するものである。
The Senior Responsible Officer in vendor organisations shall do the following:	ベンダー組織の上級責任者は、以下を実施するものとする：
2.1 Ensure the build environment is protected against unauthorised access.	2.1 ビルド環境が不正アクセスから確実に保護されるようにする。
The Senior Responsible Officer in vendor organisations should do the following:	ベンダ組織の上級責任者は、以下を実施すること：
2.2 Ensure changes to the environment are controlled and logged.	2.2 環境への変更が確実に管理され、履歴が記録されるようにする。
2.3 Ensure you are using a build pipeline you trust.	2.3 信頼できるビルドパイプラインを使用していることを確認する。
Principle 3: Secure deployment and maintenance	原則3：安全な配備と保守
This principle ensures that the product or service remains secure throughout its lifetime, to minimise the likelihood and impact of vulnerabilities.	この原則は、脆弱性の可能性と影響を最小化するために、製品またはサービスがその存続期間を通じて安全であり続けることを保証するものである。
The Senior Responsible Officer in vendor organisations shall do the following:	ベンダー組織の上級責任者は、以下を実施する：
3.1 Ensure that software is distributed securely to customers.	3.1 ソフトウェアが顧客に安全に配布されるようにする。
3.2 Ensure the organisation implements and publishes an effective vulnerability disclosure process.	3.2 組織が効果的な脆弱性開示プロセスを実施し、公開することを確実にする。
3.3 Ensure the organisation has processes in place for proactively detecting and managing vulnerabilities in software components it uses and software it develops, including a documented process to assess the severity of vulnerabilities and prioritise responses.	3.3 組織が、脆弱性の重大性を評価し、対応の優先順位を決定するための文書化されたプロセスを含め、使用するソフトウェアコンポーネント及び開発するソフトウェアの脆弱性を事前に検知し、管理するためのプロセスを備えていることを確実にする。
3.4 Ensure that vulnerabilities are appropriately reported to the relevant parties.	3.4 脆弱性を関係者に適切に報告する。
3.5 Ensure the organisation provides timely security updates, patches and notifications to its customers.	3.5 セキュリティアップデート、パッチ、通知をタイムリーに提供する。
Senior leaders in vendor organisations should do the following:	ベンダー組織のシニアリーダーは、次のことを行うべきである：
3.6 Make a public affirmation that the organisation would welcome security researchers to test software products and services provided by the organisation as part of its vulnerability disclosure process.	3.6 脆弱性公開プロセスの一環として、組織が提供するソフトウエア製品やサービスをセキュリ ティ研究者がテストすることを歓迎することを公言する。
Principle 4: Communication with customers	原則4：顧客とのコミュニケーション
This principle ensures that vendor organisations provide sufficient information to customers to enable effective risk and incident management.	この原則は、効果的なリスクマネジメントとインシデントマネジメントを可能にするために、ベンダ組織が 顧客に十分な情報を提供することを保証するものである。
Senior Responsible Officers in software vendor organisations shall do the following:	ソフトウェアベンダ組織の上級責任者は、以下を実施する：
4.1 Ensure the organisation provides information to the customer, in an accessible way, specifying the level of support and maintenance provided for the software product/ service being sold.	4.1 組織が、販売するソフトウェア製品／サービスに関して提供されるサポート及び保守のレベルを明記した情報を、利用しやすい方法で顧客に提供することを確実にする。
4.2 Ensure the organisation provides at least 1 year’s notice to customers, in an accessible way, of when the product or service will no longer be supported or maintained by the vendor.	4.2 組織は、製品またはサービスがベンダによってサポートまたは保守されなくなる時期について、少なくとも1年前に、利用しやすい方法で顧客に通知することを確実にする。
4.3 Ensure information is made available to customers in an appropriate and timely manner about notable incidents that may cause significant impact to customer organisations.	4.3 顧客組織に重大な影響を及ぼす可能性のある注目すべきインシデントについて、適切かつタイムリーな方法で顧客に情報が提供されるようにする。
Senior Responsible Officers in vendor organisations should do the following:	ベンダー組織の上級責任者は、以下のことを行うべきである：
4.4 Ensure that high level information about the security and resilience standards, frameworks, organisational commitments and procedures followed by the organisation is made available to customers.	4.4 組織が従うセキュリティ及びレジリエンスの標準、枠組み、組織のコミットメント及び 手続きに関するハイレベルの情報が顧客に提供されるようにする。
4.5 Ensure that the organisation proactively supports affected customers during and following a cyber security incident to contain and mitigate the impacts of an incident. How this would be done should be documented and agreed in contracts with the customer.	4.5 組織が、サイバーセキュリティインシデント発生中及び発生後に、影響を受ける顧 客を積極的に支援し、インシデントの影響を抑制・軽減することを確実にする。その方法は、文書化し、顧客との契約で合意する。
4.6 Provide customer organisations with guidance on how to use, integrate, and configure the software product or service securely.	4.6 ソフトウェア製品またはサービスを安全に使用、統合、設定する方法に関するガイダンスを顧客組織に提供する。

サンプル...

Annex B: Implementation guidance example	附属書 B：実装ガイダンスの例
Below is an example of how the implementation guidance will be designed and structured. Work on the accompanying implementation guidance is ongoing, but the guidance will be published alongside the Code of Practice and technical controls detailed above.	以下は、実施ガイダンスの設計と構成の例である。付随する実施ガイダンスの作成は現在進行中であるが、ガイダンスは、上記で詳述した実施規範および技術的管理とともに公表される予定である。
Principle 1: Secure design & development	原則1：安全な設計と開発
Good security engineering means building technologies that remain usable and resilient throughout their lifetime, even in the face of a cyber attack. Achieving this outcome needs to begin in the design and development phase so that user need and security are baked into the product or service. Ensuring that engineering processes and practices minimise both the likelihood and possible impact of a security compromise plays an essential part in gaining assurance in vendor competence and the products and services producing.	優れたセキュリティ工学とは、サイバー攻撃に直面しても、生涯を通じて使用可能でレジリエンスを維持できる技術を構築することである。この成果を達成するためには、設計・開発の段階から着手し、ユーザのニーズとセキュリティを製品やサービスに組み込む必要がある。セキュリティ侵害の可能性と起こりうる影響の両方を最小化するエンジニアリングプロセスと実践を確保することは、ベンダーの能力と製造される製品・サービスに対する保証を得る上で不可欠な役割を果たす。
Developers are not necessarily security experts and the security toolbox available to them can make it difficult to navigate cyber security technical complexities, leading to implementation mistakes that could have been avoided. The selection of the toolbox available to developers should therefore consider its usability and maintenance, as well as functionality and cost. This support to developers can be through access to experts, training, positive security cultures and processes as well as the availability of up-to-date tools.	開発者は必ずしもセキュリティの専門家ではなく、利用可能なセキュリティツールボックスを利用することで、サイバーセキュリティの技術的な複雑性を理解することが難しくなり、回避できたはずの実装ミスにつながる可能性がある。そのため、開発者が利用できるツールボックスの選択は、機能やコストだけでなく、使いやすさや保守性も考慮する必要がある。開発者に対するこのような支援は、専門家へのアクセス、トレーニング、積極的なセキュリ ティ文化やプロセス、最新のツールの利用可能性などを通じて行うことができる。
By implementing the provisions in the Software Vendor Code of Practice, not only will the software product or service be more cyber resilient by default, but it will also be more stable and easier to maintain.	ソフトウェアベンダー規範」の規定を実施することで、ソフトウ ェア製品またはサービスは、デフォルトでよりサイバーレジリエンスに優れ るだけでなく、より安定し、保守も容易になる。
1.1 Ensure the organisation follows an established secure development framework.	1.1 組織が確立された安全な開発フレームワークに従っていることを確認する。
Technical control: Follow a secure development framework.	技術的な管理を行う： セキュアな開発フレームワークに従う。
Using a secure development framework across your engineering projects will provide a consistent and repeatable way to support developers to ensure security has been considered at the right time. They are proactive approaches to building security into a product or service that incorporate people, processes and technology aspects. By not following a secure development framework, important cyber security decisions may #be missing# and inevitably will need to be bolted on at the end of the development process and/or cause more cost during deployment.	エンジニアリングプロジェクト全体でセキュア開発フレームワークを使用するこ とにより、開発者を支援する一貫した反復可能な方法が提供され、適切な時点でセ キュリティが考慮されていることが確認される。セキュア開発フレームワークは、人、プロセス、技術の各側面から製品またはサービスにセ キュリティを組み込むための事前予防的なアプローチである。セキュアな開発フレームワークに従わない場合、重要なサイバーセキュリティに関する意思決定が欠落し、必然的に開発プロセスの最後に追加する必要が生じたり、導入時にコストが増大したりする可能性がある。
You may wish to publish a description of which framework you are using, and which controls have been implemented. You should be able to demonstrate conformance to a secure development framework across your development and deployment activities.	どのフレームワークを使用し、どのような管理策を導入したかを公表するとよい。開発および配備の活動全体にわたって、セキュアな開発フレームワークへの準拠を実証 できるべきである。
A good secure development framework should include the following topics as a minimum:	優れたセキュア開発フレームワークには、最低限以下の項目を含めるべきである：
Threat modelling – techniques used to understand how the product or service might be attacked or otherwise fail.	脅威モデリング - 製品やサービスがどのように攻撃される可能性があ るか、あるいは他の方法で失敗する可能性があるかを理解するた めに使用される技術
Requirements capture – understanding and recording security and user needs.	要件の収集 - セキュリティ及びユーザのニーズを理解し、記録する。
Governance and roles – how the approach to ensuring secure design & development is controlled and directed.	ガバナンスと役割 - 安全な設計・開発を確保するためのアプローチがどのように管理され、指揮されるか。
Test strategy – consistent approaches to verification that have sufficient rigour and coverage.	テスト戦略 - 十分な厳密性と網羅性を有する検証への一貫したアプロー チを行う。
Data management – understanding what data exists and how it should be appropriately protected throughout its lifecycle.	データ管理 - どのようなデータが存在し、ライフサイクルを通じてどのように 適切に保護されるべきかを理解する。
Configuration management – consistent approaches to tracking changes, implementing version control, and enabling reproducibility.	構成管理 - 変更を追跡し、バージョン管理を実施し、再現性を可能にする一貫したアプローチ。
Which secure development framework you decide to use is a business decision based on what will fit best with the culture and existing processes of your organisation. There are many secure development frameworks available “off-the-shelf”, examples include:	どのセキュア開発フレームワークを使用するかは、組織の文化や既存のプロ セスに最も適合するものに基づいて、ビジネス上の意思決定を行う。多くのセキュア開発フレームワークが「既製品」として入手可能である：

英国 意見募集：AIのサイバーセキュリティ (2024.08.02)

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

AIに対するサイバーセキュリティ対策について、英国政府はガイダンスを設けるということですよね...

同時に発表されている「ソフトウェアベンダーのための実践規範」と連動しているようです...

● GOV.UK

・2024.08.02 Cyber security of AI: a call for views

・2024.08.02 A call for views on the cyber security of AI

目次...

Executive summary	エグゼクティブサマリー
1: Introduction	1: 序文
2: Our technology security programme	2: 当社のテクノロジー・セキュリティ・プログラム
3: Voluntary Code of Practice and Global Standard	3: 自主行動規範とグローバル標準
AI Cyber Security Code of Practice	AIサイバーセキュリティ実践規範
4: How to respond to the Call for Views and our next steps	4：意見募集への対応方法と次のステップ
Annex A: Research findings	附属書A：調査結果
Annex B: Global approach to AI	附属書B：AIに対するグローバルなアプローチ
Annex C: Glossary of terms	附属書C：用語集
Annex D: Call for views survey questionnaire	附属書D：意見募集アンケート
Annex E: Other interventions considered	附属書E：検討されたその他の介入策
Annex F: Bibliography of relevant publications mapped to principles by Mindgard	附属書F：マインドガードによる原則にマッピングされた関連出版物の書誌

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

Executive summary	エグゼクティブサマリー
AI is transforming our daily lives. As the technology continues to evolve and be embedded, it is crucial that we ensure cyber security is a key underpinning of AI safety. This Call for Views sets out specific interventions to help secure AI, so that the many benefits of AI can be realised.	AIは我々の日常生活を一変させつつある。技術が進化し、組み込まれ続ける中、サイバーセキュリティがAIの安全性を支える重要な基盤であることを確実にすることが極めて重要である。この意見募集では、AIの安全確保を支援するための具体的な介入策を提示し、AIがもたらす多くのメリットを実現できるようにする。
This work has primarily focused specifically on the cyber security risks to AI, rather than wider issues such as safety or the cyber security risks that stem from AI. This work is relevant to all AI technologies, regardless of the sector in which AI is used or the form of AI technology, because security is an essential component and should be considered across the entire AI lifecycle. This work sits alongside wider government activity on AI, much of which is noted in the AI regulation white paper response (see Chapter 2).	この作業は、安全性やAIに起因するサイバーセキュリティ・リスクといったより広範な問題ではなく、主にAIに特有のサイバーセキュリティ・リスクに焦点を当てている。なぜなら、セキュリティは不可欠な要素であり、AIのライフサイクル全体にわたって考慮されるべきものだからである。この作業は、AIに関する政府の広範な活動と並行して進められるものであり、その多くはAI規制白書（セクション2 参照）への回答で述べられている。
The government is proposing to take forward a two-part intervention in the form of a voluntary Code of Practice that will be taken into a global standards development organisation for further development. The proposed voluntary Code sets baseline security requirements for all AI technologies and distinguishes actions that need to be taken by different stakeholders across the AI supply chain.	政府は、自主的な行動規範という形で、2つの部分からなる介入を進めることを提案している。提案されている自主規範は、すべてのAI技術に対する基本的なセキュリティ要件を設定し、AIのサプライチェーン全体にわたって、さまざまな利害関係者が取るべき行動を区別している。
The voluntary Code of Practice was developed by the Department for Science, Innovation & Technology (DSIT) and is based on the National Cyber Security Centre’s (NCSC) Guidelines for secure AI system development which were published in November 2023, alongside the US Cybersecurity and Infrastructure Security Agency and other international cyber partners. The guidelines were co-sealed by agencies from 18 countries. The voluntary Code has also been informed by research we commissioned, including a risk assessment and a mapping of cyber security research in this area. Stakeholder engagement is a key component of our approach and will continue to be embedded throughout this Call for Views process and beyond.	この自主規範は、科学技術革新省（DSIT）によって策定され、国家サイバーセキュリティセンター（NCSC）が2023年11月に米国サイバーセキュリティ・インフラセキュリティ庁やその他の国際的なサイバーパートナーとともに発表した、安全なAIシステム開発のためのガイドラインに基づいている。このガイドラインは、18カ国の機関によって共同承認された。自主行動規範は、リスクアセスメントやこの分野のサイバーセキュリティ研究のマッピングなど、私たちが委託した調査にも基づいている。ステークホルダーの参画は、我々のアプローチの重要な要素であり、今回の「意見募集」のプロセスを通じて、またそれ以降も継続していく予定である。
We want to enable AI developers to be able to distinguish themselves from their competitors by highlighting their commitment to security. We also recognise the importance of developing international alignment and ensuring that stakeholders that make up the AI supply chain have a clear understanding of what they need to implement. To that end, we’ve been engaging closely with international partners and mapped recommendations by industry and other governments to ensure this document sits in support of their efforts. We are also involved in various standards development organisations and multilateral fora to promote the need for security as part of discussions on AI (see Annex B).	我々は、AI開発者がセキュリティへの取り組みを強調することで、競合他社と差別化できるようにしたいと考えている。また、国際的な協調を発展させ、AIのサプライチェーンを構成する関係者が、何を実施する必要があるのかを明確に理解できるようにすることの重要性も認識している。そのため、我々は国際的なパートナーと緊密に連携し、産業界や他の政府による勧告をマッピングし、この文書が彼らの取り組みを支援するものとなるようにしてきた。また、様々な標準開発組織や多国間フォーラムに参加し、AIに関する議論の一環としてセキュリティの必要性を推進している（附属書B参照）。
This publication is intended as the starting point of a much more extensive dialogue with our stakeholders, including industry and international partners. The cyber security of AI requires a global approach, as the risks cross international borders, and so international engagement has been a key element of our approach. We are now holding a Call for Views for 12 weeks until 9 August 2024 to gather feedback on the proposed interventions, including the Code of Practice and the intention to develop a global standard. The feedback will be used to inform UK government policy and our next steps.	本書は、産業界や国際的なパートナーを含むステークホルダーとの、より広範な対話の出発点となることを意図している。AIのサイバーセキュリティは、リスクが国境を越えるため、グローバルなアプローチが必要であり、国際的な関与が我々のアプローチの重要な要素となっている。現在、2024年8月9日までの12週間、意見募集を行い、行動規範や世界標準を策定する意向など、提案されている介入策について意見を集めている。このフィードバックは、英国政府の方針と私たちの次のステップに役立てられる。

実践規範...

Code of Practice Principles	実践規範の原則
Secure Design	安全な設計
Principle 1: Raise staff awareness of threats and risks	原則1：脅威とリスクに対する職員の意識を高める
Principle 2: Design your system for security as well as functionality and performance	原則2：機能や性能だけでなく、セキュリティも考慮してシステムを設計する
Principle 3: Model the threats to your system	原則3：システムに対する脅威をモデル化する。
Principle 4: Ensure decisions on user interactions are informed by AI-specific risks	原則4：AI特有のリスクに基づいて、ユーザとのインタラクションに関する意思決定が行われるようにする。
Principle 5: Identify, track and protect your assets	原則5：資産を識別、追跡、保護する。
Principle 6: Secure your infrastructure	原則6：インフラストラクチャーの安全性を確保する。
Principle 7: Secure your supply chain	原則7：サプライチェーンの安全性を確保する。
Principle 8: Document your data, models and prompts[	原則8：データ、モデル、プロンプトを文書化する。
Principle 9: Conduct appropriate testing and evaluation	原則9：適切なテストと評価を実施する。
Secure Deployment	安全な配備
Principle 10: Communication and processes associated with end-users	原則10：エンドユーザ[脚注 37]とのコミュニケーションとプロセス
Secure Maintenance	安全な保守
Principle 11: Maintain regular security updates for AI model and systems	原則11：AIモデルとシステムのセキュリティ更新を定期的に行う。
Principle 12: Monitor your system’s behaviour	原則12：システムの挙動を監視する

・2024.05.15 Cyber security of AI: call for views

・2024.08.02 Call for views on the Cyber Security of AI

---

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

・2024.06.27 英国 国家サイバーセキュリティセンター 人工知能 (AI) のサイバーセキュリティに関する研究 (2024.05.15)

Continue reading "英国 意見募集：AIのサイバーセキュリティ (2024.08.02)"

中国 公安部 国家サイバースペース管理局「国家ネットワーク ID 認証公共サービス管理弁法（意見募集案）」意見募集 (2024.07.26)

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

中国の公安部、国家サイバースペース管理局が「国家ネットワーク ID 認証公共サービス管理弁法（意見募集案）」を公表し、意見募集をしていますね...

中国はインターネット実名制ですが、国家ネットワークID認証公共サービス基盤を利用することで、最小限の個人情報の提供ですむのでいいでしょうという話？

日本でも参考になる部分があるように思います...

● 中央网络安全和信息化委员会办公室 (Cyberspace Administration of China: CAC)

・2024.07.26 公安部 国家互联网信息办公室关于《国家网络身份认证公共服务管理办法（征求意见稿）》公开征求意见的公告

公安部 国家互联网信息办公室关于《国家网络身份认证公共服务管理办法（征求意见稿）》公开征求意见的公告	公安部 国家サイバースペース管理局による「国家ネットワーク ID 認証公共サービ ス管理弁法（意見募集案）」公開諮問に関する発表
为强化公民个人信息保护，推进并规范国家网络身份认证公共服务建设应用，加快实施网络可信身份战略，根据《中华人民共和国网络安全法》《中华人民共和国数据安全法》《中华人民共和国个人信息保护法》《中华人民共和国反电信网络诈骗法》等法律法规，公安部、国家互联网信息办公室等研究起草了《国家网络身份认证公共服务管理办法（征求意见稿）》，现向社会公开征求意见。公众可以通过以下途径和方式提出意见建议：	国民の個人情報保護を強化し、国家ネットワーク身元認証公共サービスの構築と応用を促進・標準化し、ネットワーク信頼されるアイデンティティ戦略の実施を加速するため、中華人民共和国ネットワークセキュリティ法、中華人民共和国データセキュリティ法、中華人民共和国個人情報保護法、中華人民共和国通信ネットワーク詐欺防止法などの法規に従って、公安部、国家サイバースペース管理局などは、「国家ネットワーク身元認証公共サービス管理弁法（案）」を研究・起草した。 公安部、国家インターネット情報弁公室などは、「国家ネットワーク身元認証公共サービス管理弁法（案）」を研究・起草し、現在一般に公開し、意見を募集している。 国民は以下の方法・手段で意見・提案を行うことができる：
附件：1.《国家网络身份认证公共服务管理办法（征求意见稿）》	添付資料： 1.国家ネットワークID認証公共サービス管理弁法（意見募集案）
2.关于起草《国家网络身份认证公共服务管理办法（征求意见稿）》的说明	2.国家ネットワーク識別情報認証公共サービス管理弁法（意見募集案）の作成に関する説明書

・全奥ネットワークID認証公共サービス管理弁法（意見募集案）

国家网络身份认证公共服务管理办法	国家ネットワーク識別情報認証公共サービス管理弁法（案
（征求意见稿）	(意見募集案）
第一条 为实施网络可信身份战略，推进国家网络身份认证公共服务建设，保护公民身份信息安全，促进数字经济发展，根据《中华人民共和国网络安全法》《中华人民共和国数据安全法》《中华人民共和国个人信息保护法》《中华人民共和国反电信网络诈骗法》等法律法规，制定本办法。	第1条 本弁法は、中華人民共和国サイバーセキュリティ法、中華人民共和国データセキュリティ法、中華人民共和国個人情報保護法、中華人民共和国電気通信網詐欺対策法およびその他の法令に基づき、ネットワーク信頼されるアイデンティティ戦略を実施し、国家ネットワーク身元認証公共サービスの建設を推進し、国民の身元情報の安全を保護し、デジタル経済の発展を促進することを目的として制定される。
第二条 本办法所称国家网络身份认证公共服务（以下称“公共服务”），是指国家根据法定身份证件信息，依托国家统一建设的网络身份认证公共服务平台（以下称“公共服务平台”），为自然人提供申领网号、网证以及进行身份核验等服务。	第2条 この弁法にいう国家ネットワーク ID 認証公共サービス（以下「公共サービス」という。）とは、 法定 ID 文書の情報に基づき、国家統一構築ネットワーク ID 認証公共サービスプラットフォーム（以下「公共サービスプラットフォーム」という。 (以下、「公共サービス・プラットフォーム」という。）において、ネットワーク番号、ネットワーク証明書の申請、本人確認の実施などのサービスを自然人に提供する。
本办法所称网号，是指与自然人身份信息一一对应，由字母和数字组成、不含明文身份信息的网络身份符号；网证，是指承载网号及自然人非明文身份信息的网络身份认证凭证。网号、网证可用于在互联网服务及有关部门、行业管理、服务中非明文登记、核验自然人真实身份信息。	本方針でいうネットワーク番号とは、自然人の身元情報に対応し、身元情報を明示しない文字と数字で構成されるネットワーク身元記号を指し、ネットワーク証明書とは、自然人のネットワーク番号および身元情報を明示しないネットワーク身元認証クレデンシャルを指す。 ネットワーク番号、ネットワーク証明書は、インターネットサービスおよび関連部門、業界管理、サービスおよび非明示的な登録、自然人の真の身元情報の検証で使用できる。
第三条 国务院公安部门、国家网信部门依照各自法定职责，负责国家网络身份认证公共服务的监督管理，监督、指导公共服务平台依法落实数据安全和个人信息保护义务。	第3条 国務院公安部門、国家インターネット情報部門は、それぞれの法定任務に従い、データセキュリティおよび個人情報保護義務の実施に従い、国家ネットワークID認証公共サービス、公共サービスプラットフォームの監督および指導の監督および管理を担当する。
国务院民政、文化和旅游、广播电视、卫生健康、铁路、邮政等部门依照本办法和有关法律、行政法规的规定，在各自职责范围内负责国家网络身份认证公共服务的推广应用和监督管理工作。	国務院の民政、文化観光、ラジオ・テレビ、衛生、鉄道、郵政などの部門は、本弁法および関連法律・行政法規の規定に従って、それぞれの職務範囲内で国家ネットワーク ID 認証公共サービスの推進および適用、監督および管理に責任を負う。
第四条 持有有效法定身份证件的自然人，可自愿向公共服务平台申领网号、网证。	第4条 有効な法的身元証明書を有する自然人は、ネットワーク番号およびネットワーク証明書を公共サービスプラットフォームに自主的に申請することができる。
不满十四周岁的自然人需要申领网号、网证的，应当征得其父母或者其他监护人同意，并由其父母或者其他监护人代为申领。	14歳未満の自然人がネットワーク番号、ネットワーク証明書を申請する場合、両親またはその他の保護者の同意を得る必要があり、両親またはその他の保護者が申請を代行する。
已满十四周岁未满十八周岁的自然人需要申领网号、网证的，应当在其父母或者其他监护人的监护下申领。	14歳に達したが18歳に達していない自然人がネットワーク番号またはネットワーク免許を申請する必要がある場合は、両親またはその他の保護者の監督の下で申請しなければならない。
第五条 根据法律、行政法规规定，在互联网服务中需要登记、核验用户真实身份信息的，可以使用网号、网证依法进行登记、核验。	第5条 法律および行政法規の規定に従い、インターネットサービスにおいて、利用者の身元情報を登録・確認する必要がある場合、登録・確認のために、法律に従ってネットワーク番号、ネットワークカードを使用することができる。
不满十四周岁的自然人使用网号、网证登记、核验真实身份信息的，应当征得其父母或者其他监护人同意。	ネットワーク番号、ネットワークカードの登録、本当の身元情報の検証を使用する14歳未満の自然人は、両親または他の保護者の同意を得なければならない。
第六条 鼓励有关主管部门、重点行业按照自愿原则推广应用网号、网证，为用户提供安全、便捷的身份登记和核验服务，通过公共服务培育网络身份认证应用生态。	第6条は、関係主務官庁および主要産業に対して、自主性の原則に従ってネットワーク番号およびネットワーク証明書の適用を促進し、利用者に安全で便利な ID 登録および検証サービスを提供し、公共サービスを通じてネットワーク ID 認証適用の生態を育成することを奨励する。
第七条 鼓励互联网平台按照自愿原则接入公共服务，用以支持用户使用网号、网证登记、核验用户真实身份信息，依法履行个人信息保护和核验用户真实身份信息的义务。	第7条は、インターネットプラットフォームが自主性の原則に従って公共サービスにアクセスし、利用者がネットワーク番号、ネットワーク証明書の登録、利用者の本当の身元情報の検証を利用することを支援し、法律に従って個人情報保護と利用者の本当の身元情報の検証の義務を果たすことを奨励する。
互联网平台接入公共服务后，用户选择使用网号、网证登记、核验真实身份信息并通过验证的，互联网平台不得要求用户另行提供明文身份信息，法律、行政法规另有规定或者用户同意提供的除外。	インターネットプラットフォームが公共サービスにアクセスする場合、利用者はネットワーク番号、ネットワーク証明書登録、本人確認情報の検証を利用することを選択し、検証を通じて、インターネットプラットフォームは、法律および行政法規に別段の定めがある場合、または利用者が同意した場合を除き、利用者に別途明示的な本人確認情報の提供を求めないものとする。
互联网平台应当保障使用网号、网证的用户与其他用户享有相同服务。	インターネットプラットフォームは、ネットワーク番号、ネットワーク証明書の利用者およびその他の利用者が同じサービスを享受することを保証しなければならない。
第八条 互联网平台需要依法核验用户真实身份信息但无需留存用户法定身份证件信息的，公共服务平台应当仅提供用户身份核验结果。	第8条 インターネットプラットフォームは、法律に基づき利用者の真正な身元情報を確認する必要があるが、利用者の法的身元証明書類情報を保持する必要はなく、公共サービスプラットフォームは利用者の身元確認結果のみを提供するものとする。
根据法律、行政法规规定，互联网平台确需获取、留存用户法定身份证件信息的，经用户授权或者单独同意，公共服务平台应当按照最小化原则提供。	法律および行政法規の規定に基づき、インターネットプラットフォームが本当に利用者の合法的身分証明書情報を取得、保持する必要がある場合、利用者が許可した場合、または利用者が個別に同意した場合、公共サービスプラットフォームは最小化の原則に従って提供しなければならない。
未经自然人单独同意，互联网平台不得擅自处理或者对外提供相关数据信息，法律、行政法规另有规定的除外。	自然人の個別同意がない場合、インターネットプラットフォームは、法律および行政法規に別段の定めがある場合を除き、関連データおよび情報を処理し、または外部に提供してはならない。
第九条 公共服务平台处理个人信息不得超出为自然人提供申领网号、网证以及进行身份核验等服务所必需的范围和限度，在向自然人提供公共服务时应当依法履行告知义务并取得其同意。处理敏感个人信息的，应当取得个人的单独同意，法律、行政法规规定应当取得书面同意的，从其规定。	第9条 公共サービスプラットフォームは、自然人に対してネットワーク番号、ネットワーク証明書の申請、本人確認などのサービスを提供するために必要な範囲および限度を超えて個人情報を取り扱ってはならず、法律に基づき公共サービスを提供する場合は、自然人に通知し同意を得る義務を履行しなければならない。機微（センシティブ）個人情報を取り扱う場合には、別途本人の同意を得るものとし、法令および行政規則において書面による同意を得ることが定められている場合には、当該規定を適用する。
未经自然人单独同意，公共服务平台不得擅自处理或者对外提供相关数据信息，法律、行政法规另有规定的除外。	公共サービスプラットフォームは、本人の同意がない場合、法令及び行政法規に別段の定めがある場合を除き、関連データ及び情報を処理し、または外部に提供してはならない。
公共服务平台应当依照法律、行政法规规定或者用户要求，及时删除用户个人信息。	公共サービスプラットフォームは、法律および行政法規の規定または利用者の要請により、適時に利用者の個人情報を削除しなければならない。
第十条 公共服务平台在处理用户个人信息前，应当通过用户协议等书面形式，以显著方式、清晰易懂的语言真实、准确、完整地向用户告知下列事项：	第10条 公共サービスプラットフォームは、利用者の個人情報を取り扱う前に、利用契約書及びその他の書面により、利用者に次の事項を分かりやすい言葉で、真実、正確かつ完全に通知しなければならない：
（一）公共服务平台的名称和联系方式；	(一) 公共サービスプラットフォームの名称及び連絡先
（二）用户个人信息的处理目的、处理方式，处理的个人信息种类、保存期限；	(二) 利用者の個人情報の利用目的及び取扱方法、取り扱う個人情報の種類及び保存期間
（三）用户依法行使其个人信息相关权利的方式和程序；	(三) 利用者が法令に基づき個人情報に関する権利を行使するための方法及び手続
（四）法律、行政法规规定应当告知的其他事项。	(四) その他法令及び行政規則で定めるところにより、通知しなければならない事項
处理敏感个人信息的，还应当向个人告知处理的必要性以及对个人权益的影响，法律、行政法规另有规定的除外。	機微（センシティブ）個人情報を取り扱う場合には、法令に別段の定めがある場合を除き、その必要性及び本人の権利利益に与える影響についても本人に通知するものとする。
第十一条 公共服务平台处理个人信息，有法律、行政法规规定应当保密或者不需要告知的情形的，可以不向个人告知前条第一款规定的事项。	第11条 公共サービスプラットフォームは、個人情報を取り扱う場合であって、法令及び行政規則で定める秘密を保持すべき事情又は通知することを要しない事情があるときは、前条第1項に規定する事項を本人に通知しないことができる。
紧急情况下为保护自然人的生命健康和财产安全无法及时向个人告知的，公共服务平台应当在紧急情况消除后及时告知。	緊急事態において、自然人の生命、健康及び財産の安全を保護するため、適時に本人に通知することができない場合、公益事業プラットフォームは、緊急事態が解消した後、適時に本人に通知しなければならない。
第十二条 公共服务平台应当加强数据安全和个人信息保护，依法建立并落实安全管理制度与技术防护措施。	第12条 公共サービスプラットフォームは、データセキュリティと個人情報保護を強化し、法律に基づいてセキュリティ管理システムと技術保護措置を構築し、実施しなければならない。
第十三条 公共服务平台的建设和服务涉及密码的，应当符合国家密码管理有关要求。	第13条 公共サービスプラットフォームの建設およびパスワードが関係するサービスは、国家パスワード管理の関連要求を遵守しなければならない。
第十四条 违反本办法第七条第二款、第八条、第九条、第十条、第十二条规定，依照《中华人民共和国网络安全法》《中华人民共和国数据安全法》《中华人民共和国个人信息保护法》应当追究法律责任的，由国务院公安部门、国家网信部门在各自职责范围内依法予以处罚；构成犯罪的，依法追究刑事责任。	第14条 「中華人民共和国ネットワーク安全法」、「中華人民共和国データ安全法」、「中華人民共和国個人情報保護法」に基づき、本弁法第7条第2項、第8条、第9条、第10条、第12条の規定に違反した場合、国務院公安部門、国家インターネット情報化部門は、それぞれの責任範囲において、法律に従って処罰され、犯罪を構成する。刑事責任は、法律に従って調査されなければならない。
第十五条 本办法所称法定身份证件，包括居民身份证、定居国外的中国公民的护照、前往港澳通行证、港澳居民来往内地通行证、台湾居民来往大陆通行证、港澳居民居住证、台湾居民居住证、外国人永久居留身份证等身份证件。	第15条 本弁法にいう法定身分証明書には、在留身分証明書、海外に定住する中国公民のパスポート、香港・マカオへの渡航許可証、香港・マカオ居住者の本土との往復渡航許可証、台湾居住者の本土との往復渡航許可証、香港・マカオ居住者の本土との往復渡航居住許可証、台湾居住者の本土との往復渡航居住許可証、永住外国人身分証明書などの身分証明書が含まれる。
第十六条 本办法自 年 月 日起施行。	第16条 本弁法は、年　月　日から施行する。

解説...

关于起草《国家网络身份认证公共服务管理办法（征求意见稿）》的说明	国家ネットワーク・アイデンティティ認証公共サービス管理弁法（案）」（意見募集案） についての説明
一、起草必要性	一、草案の必要性
为全面贯彻落实《中华人民共和国网络安全法》《中华人民共和国数据安全法》《中华人民共和国个人信息保护法》《中华人民共和国反电信网络诈骗法》中关于国家实施网络可信身份战略、推进网络身份认证公共服务建设等有关规定，国家组织建设网络身份认证公共服务基础设施，旨在建成国家网络身份认证公共服务平台，形成国家网络身份认证公共服务能力，为社会公众统一签发“网号”“网证”，提供以法定身份证件信息为基础的真实身份登记、核验服务，达到方便人民群众使用、保护个人信息安全、推进网络可信身份战略的目标。基于国家网络身份认证公共服务（以下简称公共服务），自然人在互联网服务中依法需要登记、核验真实身份信息时，可通过国家网络身份认证APP自愿申领并使用“网号”“网证”进行非明文登记、核验，无需向互联网平台等提供明文个人身份信息。由此，可以最大限度减少互联网平台以落实“实名制”为由超范围采集、留存公民个人信息。为进一步强化个人信息保护、规范公共服务的运行管理，公安部、国家互联网信息办公室等有关部门经充分调研论证，起草了《国家网络身份认证公共服务管理办法（征求意见稿）》（以下简称《管理办法》）。	中華人民共和国ネットワーク安全法、中華人民共和国データ安全法、中華人民共和国個人情報保護法、および中華人民共和国電気通信ネットワーク詐欺防止法の関連規定 を全面的に実施し、国家ネットワーク信頼できる ID 戦略を実施し、ネットワーク ID 認証公共サービスの建設を推進するため、国家はネットワーク ID 認証公共サービス・インフラを構築する。 国家ネットワーク ID 認証公共サービス・プラットフォーム、国家ネットワーク ID 認証公共サービ ス能力の形成、国民のための「ネットワーク番号」と「ネットワーク証明書」の統一的な発行、法定 ID 文書の情報に基づく本当の ID 登録および検証サービスを提供し、 国民の利用の利便性を実現し、個人情報の安全を保護する。国民の利用を容易にし、個人情報のセキュリティを保護し、ネットワーク信頼される ID 戦略を推進するという目標を達成するために、法的な ID 文書情報に基づいて実際の ID 登録および検証サービスを提供する。国家ネットワーク ID 認証公共サービス（以下、公共サービスという）に基づき、自然人が法律 に従ってインターネット・サービスに自分の本当の ID 情報を登録および検証する必要が ある場合、国家ネットワーク ID 認証 APP を通して「ネットワーク番号」および「ネットワーク証明書」を自主的に申請し、使用することができる。 インターネット・サービスにおいて実 ID 情報の登録および検証が法律で義務付けられている場合、申請者は、インターネット・プラットフォームに明示的な個人 ID 情報を提供する必要なく、非明示的な登録および検証を実施するように、国家ネットワーク ID 認証 APP を通じて「ネットワーク番号」および「ネット証明書」を自主的に申請および使用することができる。これにより、インターネット・プラットフォームが「実名制」の範囲を超えて市民の個人情報を収集・保持する必要性を最小限に抑えることができる。個人情報の保護をさらに強化し、公共サービスの運営管理を規制するため、公安部、国家サイバースペース管理局およびその他の関連部門は、綿密な調査と実証を経て、「国家ネットワーク身元認証公共サービス管理弁法（案）」（以下、「管理弁法」という）を起草した。
二、主要内容	二、主な内容
《管理办法》共16条，主要包括四个方面的内容：一是明确了公共服务和“网号”“网证”等概念；二是明确了公共服务的使用方式和场景；三是强调了公共服务平台和互联网平台的数据和个人信息保护义务；四是明确了公共服务平台和互联网平台违反数据和个人信息保护义务的法律责任。	第一に、公共サービスと「ネットワーク番号」、「ネットワーク証明書」の概念を明確にしている。第二に、公共サービスの利用方法とシナリオを明確にしている。第三に、公共サービスプラットフォームとインターネットプラットフォームのデータと個人情報保護義務を強調している。第三に、公共サービスプラットフォーム及びインターネットプラットフォームのデータ及び個人情報保護義務を強調し、第四に、公共サービスプラットフォーム及びインターネットプラットフォームのデータ及び個人情報保護義務違反に対する法的責任を明らかにした。
三、主要考虑	三、主な検討事項
《管理办法》根据《中华人民共和国网络安全法》《中华人民共和国数据安全法》《中华人民共和国个人信息保护法》《中华人民共和国反电信网络诈骗法》的规定，明确了使用“网号”“网证”进行网络身份认证的方式，并对“网号”“网证”的申领条件、公共服务的使用场景、法定身份证件范围、数据和个人信息安全保护义务等基础性事项作出规定。此外，依照《中华人民共和国个人信息保护法》《未成年人网络保护条例》等对未成年人的特殊保护要求，对未成年人申领、使用公共服务作出了特别规定。	中華人民共和国ネットワーク安全法』、『中華人民共和国データ安全法』、『中華人民共和国個人情報保護法』、『中華人民共和国電気通信ネットワーク詐欺対策法』の規定に基づき、本行政弁法はネットワーク身元認証に「ネットワーク番号」と「ネットワーク証明書」を使用することを規定している。また、「ネットワーク番号」および「ネットワーク証明書」を使用するネットワーク ID 認証の方法を規定し、「ネットワーク番号」および「ネットワーク証明書」の適用条件、公共サービスの使用シナリオ、合法的な ID 文書の範囲、 データおよび個人情報のセキュリティ保護の義務、およびその他の基本的な事項について規定している。規定する。また、「中華人民共和国個人情報保護法」および「インターネットにおける未成年者の保護に関する規定」に基づく未成年者の特別な保護要件に従い、未成年者が公共サービスを申請および利用するための特別な規定が設けられている。
《管理办法》鼓励互联网平台接入公共服务，支持用户使用“网号”“网证”登记、核验真实身份，并作为其履行用户真实身份核验和个人信息保护等法定义务的一种方式。对自愿选择使用“网号”“网证”的用户，除法律法规有特殊规定或者用户同意外，互联网平台不得要求用户另行提供明文身份信息，最大限度减少互联网平台以落实“实名制”为由超范围采集、留存公民个人信息。	行政弁法」は、インターネットプラットフォームが公共サービスにアクセスすることを奨励し、「ネットワーク番号」と「ネットワーク証明書」の利用を支持して、利用者の本当の身元を登録・確認し、利用者の本当の身元を確認し、個人情報を保護する法的義務を果たす方法としている。自発的に「ネットワーク番号」および「ネットワーク証明書」の使用を選択するユーザーについては、法令に特別な規定がある場合またはユーザーが同意する場合を除き、インターネットプラットフォームはユーザーに別途明示的な身元情報の提供を求めないものとし、インターネットプラットフォームが「実名制」を実施する必要性を最小限に抑える。本行政措置は、「中華人民共和国実名制」および「中華人民共和国行政弁法」に厳格に従う。
《管理办法》严格依照《中华人民共和国个人信息保护法》等上位法的规定，充分保障了用户个人信息相关权利。明确了公共服务平台采集个人信息的“最小化和必要性原则”，即公共服务平台处理个人信息不得超出为自然人提供“网号”“网证”相关服务所必需的范围和限度。明确了公共服务平台处理用户个人信息时的解释告知、数据保护等义务，充分保障用户的知情权、选择权、删除权等个人信息相关权利。	本行政措置は、「中華人民共和国個人情報保護法」及びその他の優越的な法律の規定を厳格に遵守し、ユーザーの個人情報に関する権利を全面的に保護する。公共サービスプラットフォームが個人情報を収集する際の「必要最小化の原則」が明確に規定されている。すなわち、公共サービスプラットフォームが個人情報を取り扱うのは、自然人の「ネットワーク番号」および「ネットワーク証明書」に関連するサービスを提供するために必要な範囲を超えないものとする。公共サービスプラットフォームは、自然人に対する「ネット番号」及び「ネット証明書」関連サービスの提供に必要な範囲及び限度を超えて、個人情報を取り扱ってはならない。公共サービスプラットフォームが利用者の個人情報を取り扱う際の説明・通知、データ保護などの義務を明確にし、利用者の個人情報に関する知る権利、選択する権利、削除する権利などの権利を全面的に保護する。
《管理办法》明确了身份核验结果信息的“最小化提供原则”和依法处理要求。对依法需要核验用户真实身份但无需留存用户法定身份证件信息的，公共服务平台应当仅向互联网平台提供核验结果；对于依法确需获取、留存用户法定身份证件信息的，经用户单独同意，公共服务平台应按照“最小化原则”向互联网平台提供必要、相关的明文信息。	行政措置では、「本人確認の結果に関する情報の提供を最小限に抑える原則」と、法律に従った処理の要件が規定されている。法律で要求される利用者の身元確認については、利用者の法的身元証明書情報を保持する必要なく、公共サービス・プラットフォームはインターネット・プラットフォームに確認結果のみを提供するものとし、利用者の法的身元証明書情報を取得および保持する法的必要性については、利用者の個別の同意を得て、公共サービス・プラットフォームは「最小化」の原則に従い、必要かつ関連性のある明示的な情報をインターネット・プラットフォームに提供するものとする。公共サービスプラットフォームは、利用者個人の同意を得て、「最小化原則」に従い、必要かつ関連性のある明示的な情報をインターネットプラットフォームに提供するものとする。

米国 NIST SP 800-73-5 個人アイデンティティ検証用インタフェース Part1-3

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

NISTが、SP 800-73-5 個人アイデンティティ検証用インタフェース Part1-3と、NIST SP 800-78-5 個人アイデンティティ検証のための暗号アルゴリズムおよび鍵サイズを公表ていますね...

● NIST- ITL 

プレス...

・2024.07.15 Personal Identity Verification (PIV) Interfaces, Cryptographic Algorithms, and Key Sizes: NIST Revises SP 800-73 and SP 800-78

Personal Identity Verification (PIV) Interfaces, Cryptographic Algorithms, and Key Sizes: NIST Revises SP 800-73 and SP 800-78	個人アイデンティティ検証（PIV）インタフェース、暗号アルゴリズム、および鍵サイズ： NIST は SP 800-73 および SP 800-78 を改訂する。
In January 2022, NIST revised Federal Information Processing Standard (FIPS) 201, which establishes standards for the use of Personal Identity Verification (PIV) credentials, including those on PIV Cards. NIST Special Publication (SP) 800-73-5: Parts 1–3 and SP 800-78-5 have subsequently been revised to align with FIPS 201.	2022 年 1 月、NIST は、PIV カード上のものを含む個人アイデンティティ検証（PIV）クレデンシャルの使 用標準を確立する連邦情報処理標準（FIPS）201 を改訂した。NIST 特別刊行物（SP）800-73-5： パート 1-3 および SP 800-78-5 は、その後 FIPS 201 と整合するように改訂された。
SP 800-73-5: Parts 1–3	SP 800-73-5： パート 1-3
SP 800-73-5: Parts 1–3, Interfaces for Personal Identity Verification, describe the technical specifications for using PIV Cards. The three parts cover the PIV data model (Part 1), the card edge interface (Part 2), and the application programming interface (Part 3). Major changes to the documents include:	SP 800-73-5： パート１～パート3、個人アイデンティティ検証用インタフェースは、PIV カードを使用するための技術仕様 を記述している。この 3 部は、PIV データ・モデル（パート1）、カード・エッジ・インタフェース （パート2）、およびアプリケーション・プログラミング・インタフェース（パート3） を対象としている。文書の主な変更点は以下のとおりである：
・Removal of the previously deprecated CHUID authentication mechanism	・以前は非推奨であった CHUID 認証メカニズムの削除。
・Deprecation of the SYM-CAK and VIS authentication mechanisms	・SYM-CAK および VIS 認証メカニズムの廃止。
・Addition of an optional 1-factor secure messaging authentication mechanism (SM-Auth) for facility access applications	・施設アクセス・アプリケーション用のオプションの 1 要素セキュア・メッセージング認証 （SM-Auth）の追加
・Additional use of the facial image biometric for general authentication via BIO and BIO-A authentication mechanisms	・BIOおよびBIO-A認証メカニズムによる一般認証への顔画像バイオメトリックの追加使用
・Addition of an optional Cardholder identifier in the PIV Authentication Certificate to identify a PIV credential holder to their PIV credential set issued during PIV eligibility	・PIV 認証証明書にオプションのカード保持者識別子を追加して、PIV クレデンシャル保持 者を PIV 資格認定中に発行された PIV クレデンシャル・セットに識別する。
・Restriction on the number of consecutive activation retries for each of the activation methods (i.e., PIN and OCC attempts) to be 10 or less	・各アクティベーション方法（すなわち、PIN および OCC 試行）の連続アクティベーショ ン再試行回数を 10 回以下に制限する。
・SP 800-73-5: Part 3 on PIV Middleware specification marked as optional to implement	・SP 800-73-5： PIV ミドルウェア仕様の第 3 部は、実装のオプションとされた。
SP 800-78-5	SP 800-78-5
SP 800-78-5, Cryptographic Algorithms and Key Sizes for Personal Identity Verification, defines the requirements for the cryptographic capability of the PIV Card and supporting systems in coordination with FIPS 201-3. It has been modified to add additional algorithm and key size requirements and to update the requirements for Cryptographic Algorithm Validation Program (CAVP) validation testing, including:	SP 800-78-5「個人アイデンティティ検証のための暗号アルゴリズムおよび鍵サイズ」は、FIPS 201-3 と連携して、PIV カードおよび支援システムの暗号機能の要件を定義している。追加アルゴリズムおよび鍵サイズ要件を追加し、暗号化アルゴリズム検証プログラム（CAVP） 検証テストの要件を更新するために、以下のように修正されている：
Deprecation of 3TDEA algorithms with identifier ‘00’ and ‘03’	識別子が'00'および'03'の3TDEAアルゴリズムの廃止。
Removal of the retired RNG from CAVP PIV component testing where applicable	該当する場合、CAVP PIV コンポーネント・テストから引退した RNG を削除する。
Removal of retired FIPS 186-2 key generation from CAVP PIV component testing where applicable	該当する場合、CAVP PIV コンポーネント・テストからの引退した FIPS 186-2 鍵生成の削除。
Accommodation of the Secure Messaging Authentication key	Secure Messaging 認証鍵の収容
Update to Section 3.1 and Table 1 to reflect additional higher strength keys with at least 128-bit security for use in authentication beginning in 2031	セクション 3.1 および表 1 を更新し、2031 年から認証に使用される、少なくとも 128 ビットのセ キュリティを持つ、より強度の高い鍵を追加する。

こちらは、SP800-73-5...

・2024.07.15 NIST SP 800-73-5 Interfaces for Personal Identity Verification:

Part 1 – PIV Card Application Namespace, Data Model and Representation	パート 1 - PIV カードアプリケーション名前空間、データモデルおよび表現
Part 2 – PIV Card Application Card Command Interface	パート 2 - PIV カードアプリケーション・カード・コマンド・インタフェース
Part 3 – PIV Client Application Programming Interface	パート 3 - PIV クライアント・アプリケーション・プログラミング・インターフェイス

Abstract

概要

FIPS 201 defines the requirements and characteristics of government-wide interoperable identity credentials. It specifies that these identity credentials must be stored on a smart card and that additional common identity credentials, known as derived PIV credentials, may be issued by a federal department or agency and used when a PIV Card is not practical. This document contains the technical specifications to interface with the smart card to retrieve and use the PIV identity credentials. The specifications reflect the design goals of interoperability and PIV Card functions. The goals are addressed by specifying a PIV data model, card edge interface, and application programming interface. Moreover, this document enumerates requirements for the options and branches in international integrated circuit card standards [ISO7816]. The specifications go further by constraining interpretations of the normative standards to ease implementation, facilitate interoperability, and ensure performance in a manner tailored for PIV applications.

FIPS 201 は、政府全体で相互運用可能な ID クレデンシャルの要件および特性を定義して いる。FIPS 201 は、政府全体で相互運用可能な ID クレデンシャルの要件および特性を定義する。 FIPS 201 は、これらの ID クレデンシャルがスマート・カードに格納されなければならず、派生 PIV クレデンシャルと呼ばれる追加の共通 ID クレデンシャルが連邦省庁によって発行され、PIV カードが実用的でない場合に使用される可能性があることを規定する。本文書には、PIV ID クレデンシャルを取得して使用するためにスマート・カードとインタ ーフェースする技術仕様が含まれている。この仕様は、相互運用性および PIV カード機能の設計目標を反映している。目標は、PIV データ・モデル、カード・エッジ・インタフェース、およびアプリケーショ ン・プログラミング・インタフェースを規定することで対処される。さらに、本文書は、国際集積回路カード標準［ISO7816］のオプションおよび分岐に対する要 件を列挙している。この仕様は、実装を容易にし、相互運用性を促進し、PIV アプリケーションに合わせた方法でパ フォーマンスを確保するために、標準の解釈を制約することによって、さらに進む。

・[PDF] NIST.SP.800-73pt1-5

目次...

1. Introduction	1. 序文
1.1. Purpose	1.1. 目的
1.2. Scope	1.2. 適用範囲
1.3. Effective Date	1.3. 発効日
1.4. Audience and Assumptions	1.4. 想定読者および前提条件
1.5. Document Overview and Structure	1.5. 文書の概要と構成
2. PIV Card Application Namespaces	2. PIV カード・アプリケーション名前空間
2.1. Namespaces of the PIV Card Application	2.1. PIV カード・アプリケーションの名前空間
2.2. PIV Card Application AID	2.2. PIV カード・アプリケーション AID
3. PIV Data Model Elements	3. PIV データ・モデル要素
3.1. Mandatory Data Elements	3.1. 必須データ要素
3.2. Conditional Data Elements	3.2. 条件付きデータ要素
3.3. Optional Data Elements	3.3. オプションのデータ要素
3.4. Inclusion of Universally Unique Identifiers (UUIDs)	3.4. 汎用一意識別子（UUID）のインクルード
3.5. Data Object Containers and Associated Access Rules and Interface Modes	3.5. データ・オブジェクト・コンテナおよび関連するアクセス・ルールとインターフェイス・モード
4. PIV Data Objects Representation	4. PIV データ・オブジェクトの表現
4.1. Data Objects Definition	4.1. データ・オブジェクト定義
4.2. OlDs and Tags of PIV Card Application Data Objects	4.2. PIV カード・アプリケーション・データ・オブジェクトの OlDs とタグ
4.3. Object Identifiers	4.3. オブジェクト識別子
5. Data Types and Their Representation	5. データ型とその表現
5.1. Key References	5.1. キー参照
5.2. PIV Algorithm Identifier	5.2. PIV アルゴリズム識別子
5.3. Cryptographic Mechanism Identifiers	5.3. 暗号メカニズム識別子
5.4. Secure Messaging and Authentication Using a Secure Messaging Key (SM-AUTH)	5.4. セキュア・メッセージング鍵（SM-AUTH）を使用するセキュア・メッセージングおよび認証
5.5. Virtual Contact Interface	5.5. バーチャル・コンタクト・インターフェース
5.6. Status Words	5.6. ステータスワード
References	参考文献
Appendix A. PIV Data Model	附属書A. PIV データモデル
Appendix B. PIV Authentication Mechanisms	附属書B. PIV 認証メカニズム
Appendix C. PIV Algorithm Identifier Discovery	附属書C. PIV アルゴリズム識別子の発見
Appendix D. List of Symbols, Abbreviations, and Acronyms	附属書D. 記号、略語、および頭字語のリスト
Appendix E. Glossary	附属書E. 用語集
Appendix F. Notation	附属書F. 表記法
Appendix G. Revision History	附属書G. 改訂履歴

・[PDF] NIST.SP.800-73pt2-5

目次...

1. Introduction	1. 序文
1.1. Purpose	1.1. 目的
1.2. Scope	1.2. 適用範囲
1.3. Audience and Assumptions	1.3. 想定読者および前提
1.4. Content and Organization	1.4. 内容と構成
2. Overview: Concepts and Constructs	2. 概要 概念と構成要素
2.1. Platform Requirements	2.1. プラットフォーム要件
2.2. Namespaces of the PIV Card Application	2.2. PIV カード・アプリケーションの名前空間
2.3. Card Applications	2.3. カード・アプリケーション
2.3.1. Default Selected Card Application	2.3.1. デフォルト選択カード・アプリケーション
2.4. Security Architecture	2.4. セキュリティ・アーキテクチャ
2.4.1. Access control kule	2.4.1. アクセス管理クレ
2.4.2. Security Status	2.4.2. セキュリティ・ステータス
2.4.3. Authentication of an Individual	2.4.3. 個人の認証
2.5. Current State of the PIV Card Application	2.5. PIV カード・アプリケーションの現状
3. PIV Card Application Card Command Interface	3. PIV カード・アプリケーション・カード・コマンド・インタフェース
3.1. PIV Card Application Card Commands for Data Access	3.1. データ・アクセスのための PIV カード・アプリケーション・カード・コマンド
3.1.1. SELECT Card Command	3.1.1. SELECT カード・コマンド
3.4.2. Oll DalA Laro Command	3.4.2. Oll DalA Laro コマンド
3.2. PIV Card Application Card Commands for Authentication	3.2. 認証のための PIV カード・アプリケーション・カード・コマンド
3.2.1. VERIFY Card Command	3.2.1. VERIFY カード・コマンド
3.2.2. CHANGE REFERENCE DATA Card Command	3.2.2. CHANGE REFERENCE DATA カード・コマンド
3.2.3. REStT RETRY COUNTER Card command	3.2.3. REStT RETRY COUNTER カード・コマンド
3.2.4. GENERAL AUTHENTICATE Card Command	3.2.4. GENERAL AUTHENTICATE カード・コマンド
3.3. PIV Card Application Card Commands for Credential Initialization and Administration	3.3. クレデンシャル初期化および管理のための PIV カードアプリケーションカードコマンド
3.3.1. PUT DATA Card Command	3.3.1. PUT DATA カード・コマンド
3.3.2. GENERATE ASYMMETRIC KEY PAIR Card Command	3.3.2. GENERATE ASYMETRIC KEY PAIR カード・コマンド
4. Secure Messaging	4. セキュア・メッセージング
4.1. Key Establishment Protocol,	4.1. 鍵確立プロトコル
4.1.1. Client Application Steps	4.1.1. クライアント・アプリケーションの手順
4.1.2. PIV Card Application Protocol Steps	4.1.2. PIV カード・アプリケーション・プロトコル・ステップ
4.1.3. Notations	4.1.3. 表記
4.1.4. Cipher Suite	4.1.4. 暗号スイート
4.1.5. Card Verifiable Certificate	4.1.5. カード検証可能証明書
4.1.6. Key Derivation	4.1.6. 鍵の導出
4.1.7. Key Confirmation	4.1.7. 鍵の確認
4.1.8. Command Interface	4.1.8. コマンド・インターフェース
4.2. Secure Messaging	4.2. セキュア・メッセージング
4.2.1. Secure Messaging Data Objects	4.2.1. セキュア・メッセージング・データ・オブジェクト
4.2.2. Command and Response Data Confidentiality	4.2.2. コマンドとレスポンス・データの機密性
4.2.3. Command Integrity	4.2.3. コマンドの完全性
4.2.4. Command With PIV Secure Messaging	4.2.4. PIV セキュア・メッセージングを使用したコマンド
4.2.5. Response Integrity	4.2.5. 応答の完全性
4.2.6. Response With PIV Secure Messaging	4.2.6. PIV セキュア・メッセージングを使用した応答
4.2.7. Error Handling	4.2.7. エラー処理
4.3. Session Key Destruction	4.3. セッション鍵の破棄
References	参考文献
Appendix A. Examples of the Use of the GENERAL AUTHENTICATE Command	附属書A. GENERAL AUTHENTICATEコマンドの使用例
Appendix B. List of Symbols, Abbreviations, and Acronyms	附属書B. 記号、略語、頭字語のリスト
Appendix C. Glossary	附属書C．用語集
Appendix D. Notation	附属書D．表記

・[PDF] NIST.SP.800-73pt3-5

目次...

1. Introduction	1. 序文
1.1. Purpose	1.1. 目的
1.2. Scope	1.2. 適用範囲
1.3. Audience and Assumptions	1.3. 想定読者および前提
1.4. Content and Organization	1.4. 内容と構成
2. Overview: Concepts and Constructs	2. 概要 概念と構成要素
3. Client Application Programming Interface	3. クライアント・アプリケーション・プログラミング・インターフェイス
3.1. Entry Points for Communication	3.1. コミュニケーションのエントリーポイント
3.2. Entry Points for Data Access	3.2. データアクセスのエントリーポイント
3.3. Entry Points for Cryptographic Operations	3.3. 暗号操作のエントリーポイント
3.4. Entry Points for Credential Initialization and Administration	3.4. クレデンシャルの初期化および管理のエントリポイント
References	参考文献
Appendix A. List of Symbols, Abbreviations, and Acronyms	附属書A. 記号、略語、および頭字語のリスト
Appendix B. Glossary	附属書B. 用語集
Appendix C. Notation	附属書C. 表記法

---

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

・2024.07.17 米国 NIST SP 800-78-5 個人アイデンティティ検証のための暗号アルゴリズムおよび鍵サイズ

・2024.07.17 米国 NIST SP 800-73-5 個人アイデンティティ検証用インタフェース Part1-3

・2023.12.16 NIST SP 800-79 Rev.3（初期公開ドラフト）PIV カードおよび派生 PIV クレデンシャル発行者の認可に関するガイドライン

・2023.09.30 NIST SP 800-73-5（初期公開ドラフト） 個人 ID 検証のためのインタフェース：パート 1 - PIV データ・モデル、パート 2 - カード・エッジ・インタフェース、パート 3 - アプリケーション・プログラミング・ インタフェース

・2023.09.30 NIST SP 800-78-5（初期公開ドラフト） 個人識別検証の暗号アルゴリズムおよび鍵サイズ

・2022.01.25 NIST FIPS 201-3 連邦職員および委託業者のアイデンティティの検証（PIV）

個人情報保護委員会 意見募集 いわゆる3年ごと見直しに係る検討の中間整理

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

個人情報保護委員会（第292回）でいわゆる3年ごと見直しに係る検討の中間整理（案）が議論され、意見募集がされていますね...（ただし、意見をだしても回答はないようです...）

● 個人情報保護委員会

・2024.06.26 「個人情報保護法　いわゆる３年ごと見直しに係る検討の中間整理」の公表及び同整理に対する意見募集

・・報道発表資料  [PDF] プレスリリース

・・別添１[PDF] 中間整理

目次...

第１ はじめに（中間整理の位置づけ等）

第２ 個別検討事項

１ 個人の権利利益のより実質的な保護の在り方
(1)個人情報等の適正な取扱いに関する規律の在り方
(2)第三者提供規制の在り方（オプトアウト等）
(3)こどもの個人情報等に関する規律の在り方
(4)個人の権利救済手段の在り方

２ 実効性のある監視・監督の在り方
(1)課徴金、勧告・命令等の行政上の監視・監督手段の在り方
(2)刑事罰の在り方
(3)漏えい等報告・本人通知の在り方

３ データ利活用に向けた取組に対する支援等の在り方
(1)本人同意を要しないデータ利活用等の在り方
(2)民間における自主的な取組の促進

４ その他
参考

・・別添２[PDF] 意見募集要領 

このページのライバルページ(^^)

・個人情報保護法　いわゆる３年ごと見直しについてのページ...

・・2024.06.27 [PDF] 個人情報保護法　いわゆる３年ごと見直しに係る検討の中間整理 

あと、今回のヒアリングには呼ばれていませんが、かつて米国企業のアジアCPOをしていて、2004年10月に経済産業省がだした、[PDF] 個人情報の保護に関する法律についての経済産業分野を対象とするガイドラインを作成する委員会（ちなみに委員長は現在の個人情報保護委員長の藤原静雄先生）で私と一緒に委員だった佐藤慶浩さんのご意見も是非参考に...

米国の感覚が少しはわかるかもです...

当時から佐藤さんは、利用目的管理の重要性を言っていましたね...

● 砂糖の甘い付箋

・2024.06.27 日本の個人情報保護と米国のプライバシー尊重の違い

---

内容...

個別の検討事項は、

１ 個人の権利利益のより実質的な保護の在り方
(1)個人情報等の適正な取扱いに関する規律の在り方
(2)第三者提供規制の在り方（オプトアウト等）
(3)こどもの個人情報等に関する規律の在り方
(4)個人の権利救済手段の在り方

２ 実効性のある監視・監督の在り方
(1)課徴金、勧告・命令等の行政上の監視・監督手段の在り方
(2)刑事罰の在り方
(3)漏えい等報告・本人通知の在り方

３ データ利活用に向けた取組に対する支援等の在り方
(1)本人同意を要しないデータ利活用等の在り方
(2)民間における自主的な取組の促進

なのですが、

それ以外も...ということで、

• プロファイリング（本人に関する行動・関心等の情報を分析する処理）
• 個人情報等に関する概念の整理
• プライバシー強化技術（「PETs」：Privacy Enhancing Technologies）の位置づけの整理
• 金融機関の海外送金時における送金者への情報提供義務の在り方
• ゲノムデータに関する規律の在り方
• 委員会から行政機関等への各種事例等の情報提供の充実
• 委員会が関係の深いステークホルダーと透明性のある形で継続的に議論する場を設け、以下の項目等を検討していく
  
  • 個人情報保護政策の方向性や、
  • 本人同意を要しない公益に資するデータ利活用に関係するガイドライン等の見直しの在り方

---

【考え方】の部分だけ抜粋...

１ 個人の権利利益のより実質的な保護の在り方

(1)個人情報等の適正な取扱いに関する規律の在り方

ア 要保護性の高い個人情報の取扱いについて（生体データ）

生体データは、長期にわたり特定の個人を追跡することに利用できる等の特徴を持ち得るものであり、特に、特定の個人を識別することができる水準が確保されている場合において、通常の個人情報と比較して個人の権利利益に与える影響が大きく、保護の必要性が高いと考えられる。他方、生体データは本人認証に広く利用されているほか、犯罪予防や安全確保等のために利用することも想定されるものである。これを踏まえ、生体データの取扱いについて、諸外国における法制度なども参考にしつつ、特に要保護性が高いと考えられる生体データについて、実効性ある規律を設けることを検討する必要がある。この点について、関係団体からは、事業者の自主的な取組を促進すべきとの声もあるが、本人関与や安全管理措置等を通じた個人の権利利益の保護とのバランスを踏まえ検討を進める必要がある。

まず、現行法上、個人情報の利用目的については、「できる限り特定」しなければならないとされているが（法第 17 条第１項）、生体データの要保護性を踏まえると、生体データを取り扱う場合においては、例えば、どのようなサービスやプロジェクトに利用するかを含めた形で利用目的を特定することを求めることが考えられる。

また、個人の権利利益の保護という観点からは、生体データの利用について、本人がより直接的に関与できる必要がある。そのため、生体データの取扱いに関する一定の事項を本人に対し通知又は十分に周知することを前提に、本人による事後的な利用停止を他の保有個人データ以上に柔軟に可能とすることが考えられる。

このほか、必要となる規律の在り方について、事業者における利活用の実態やニーズ、運用の負担、利用目的の違いによる影響なども考慮して検討する必要がある。

イ 「不適正な利用の禁止」「適正な取得」の規律の明確化

不適正な利用の禁止、適正な取得の規定については、個人の権利利益の保護により資するものとするとともに、事業者による予測可能性を高める観点から、適用される範囲等の具体化・類型化を図る必要がある。具体化・類型化に際しては、これまでに問題とされた事例等を踏まえて検討することが必要である。

また、現行法の個人情報の取扱いに係る規律は、本人が、自らの個人情報の提供等について、自らの自律的な意思により選択をすることが可能である状況にあることを前提としていると考えられる。他方、個人情報取扱事業者と本人との関係によっては、本人にそのような選択を行うことが期待できない場合があり得る。そのため、こうした場合において、本人との関係に照らして当然認められるべき利用目的以外の利用目的で個人情報を取得・利用することや、当然認められるべき利用目的の達成に真に必要な範囲を越えて個人情報を取得・利用すること等について、不正取得や不適正利用等の規律をどのように適用すべきか、継続的に検討する必要がある。

個人関連情報については、事業者が、電話番号、メールアドレス、Cookie ID など、個人に対する連絡が可能な情報を有している場合 ^[1]には、個人関連情報の取扱いによりプライバシーなどの個人の権利利益が侵害される蓋然性が認められ、その侵害の程度・蓋然性は、事業者による利用の方法によっては、個人情報と同様に深刻なものになり得ると考えられる。そのため、このような場合につい

て、不正取得や不適正利用等への対応の在り方を検討する必要がある。

(2)第三者提供規制の在り方（オプトアウト等）

オプトアウト届出事業者は、提供先の利用目的や身元等について、その内容や真偽を積極的に確認する義務まではないことから、明確に認識しないまま意図せず犯罪グループに名簿を提供してしまうことが生じ得る。そこで、一定の場合には提供先の利用目的や身元等を特に確認する義務を課すことについて検討する必要がある。その際、確認義務の要件についての検討や、住宅地図等を広く市販する場合など規律の在り方についても検討が必要である。

また、不正に名簿等を持ち出した者が、当該名簿等により利益を得る有力な方法として、オプトアウト届出事業者への販売が想定される。そのため、オプトアウト届出事業者には、取得元における取得の経緯や取得元の身元等の確認について、より高度の注意義務を課すことが考えられる。具体的には、一定の場合には取得元の身元や取得の適法性を示す資料等を特に確認する義務を課すことについて検討する必要がある。その際、確認義務の要件や対象の類型化についての検討が必要である。

さらに、本人が、オプトアウト届出事業者によって個人情報が提供されており、かつ、当該提供の停止を求めることができることを確実に認識できるようにするための措置など、本人のオプトアウト権行使の実効性を高めるための措置について、継続して検討する必要がある。

(3)こどもの個人情報等に関する規律の在り方

こどもの個人情報の取扱いに係る規律については、こどもの脆弱性・敏感性及びこれらに基づく要保護性を考慮するとともに、学校等における生徒の教育・学習に関するデータの有用性も考慮する必要がある。これを踏まえ、主要各国においてこどもの個人情報等に係る規律が設けられており、執行事例も多数見られることも踏まえ、こどもの権利利益の保護という観点から、規律の在り方の検討を深める必要がある。

他方で、第三者が公開したこどもの個人情報を取得する場合などにおいては、取得した情報にこどもの個人情報とこども以外の者の個人情報が含まれている場合や、こどもの個人情報が含まれているかが明らかでない場合があり得ることから、こうした場合における事業者の負担を考慮する必要がある。

ア 法定代理人の関与

現行法上、原則として本人同意の取得が必要とされている場面（目的外利用（法第18条第２項）、要配慮個人情報の取得（法第20条第２項）、個人データの第三者提供（法第27条第１項、第28条１項）、個人関連情報の第三者提供（法第31条第１項）など）において、こどもを本人とする個人情報について、法定代理人の同意を取得すべきことを法令の規定上明確化することを検討する必要がある。

また、本人に対する通知等が必要となる場面（利用目的の通知（法第21条第１項）、本人から直接書面に記載された個人情報を取得する場合における利用目的の明示（同条第２項）、漏えい等に関する本人への通知（法第26条第２項）など）においても、こどもを本人とする個人情報について、法定代理人に対して情報提供すべきことを法令の規定上明文化することを検討する必要がある。

イ 利用停止等請求権の拡張

現行法上、利用停止等請求権を行使できる場面は、保有個人データについて違法行為があった場合等限定的であるが、こどもの要保護性を踏まえると、こどもを本人とする保有個人データについては、他の保有個人データ以上に柔軟に事後的な利用停止を認めることについて検討する必要がある。ただし、取得について法定代理人の同意を得ている場合等、一定の場合においてはその例外とすることも考えられる。

ウ 安全管理措置義務の強化

重大なこどもの個人情報の漏えい事件が国内で発生しており、委員会においても前述の大手学習塾に対する指導に際して「こどもの個人データについては、こどもの「安全」を守る等の観点から、特に取扱いに注意が必要であり、組織的、人的、物理的及び技術的という多角的な観点からリスクを検討し、必要かつ適切な安全管理措置を講ずる必要がある」旨述べているところである。そこで、こどもの個人データについて安全管理措置義務を強化することがあり得る。

 エ 責務規定

上記アからウにかかわらず、各事業者の自主的な取組の促進という観点からは、こどもの個人情報等の取扱いについては、こどもの善の利益を優先し特別な配慮を行うべき等、事業者等が留意すべき責務を定める規定を設けることも検討する必要がある。

オ 年齢基準

こどもの個人情報等の取扱いに係る年齢基準の考え方については、国内外の法制度において様々な年齢基準が設けられていることや、対象年齢によっては事業者等の負担が大きくなることも考慮する必要があるが、対象とするこどもの年齢については、Q&Aの記載やGDPRの規定の例などを踏まえ、16歳未満とすることについて検討を行う。

(4)個人の権利救済手段の在り方

法の規定に違反する個人情報の取扱いに対する抑止力を強化し、本人に生じた被害の回復の実効性を高めるという観点からは、適格消費者団体を念頭に置いた、団体による差止請求制度や被害回復制度 ^[2]の枠組みは有効な選択肢となり得る。

このうち、差止請求制度については、法に違反する不当な行為を対象行為とすることを検討すべきである。差止請求の実効的な運用のためには、次の課題が指摘されている一方で、差止請求は個人の権利利益保護の手段を多様化する、委員会の監視・監督機能を補完し得るとの指摘もあることから、継続して検討する必要がある。

・ 専門性の確保（法に精通した人材を各適格消費者団体が確保しているとは限らないため、研修等の実施や、制度導入初期段階での専門家確保のための施策が必要と考えられる。）

・ 端緒情報等の共有・立証等における考慮（委員会が取得している情報のうち重大案件と考えられるものについて、事業者名を特定して適格消費者団体に提供できると、制度が効果的に機能すると考えられる。また、事業者の応答を促す仕組み等についても検討すべき。）

・ 報告、監督窓口の一本化（年次の報告先等が２箇所となれば適格消費者団体の負担となる。）

・ 資金を含む団体への援助（適格消費者団体は限られた資金の下ボランティアベースで運営されている団体が大多数。）

もう一方の被害回復制度については、差止請求制度の課題に加え、個人情報の漏えいに伴う損害賠償請求は極端な少額大量被害事案となる（過去の裁判例等を踏まえると、認容被害額は数千円から数万円程度と考えられる。）こと、立証上の問題があることが課題と考えられることから、更に慎重な検討が必要である。

他方で、団体による差止請求や被害回復の枠組みについては、関係団体からのヒアリングにおいて、その導入について強く反対との意見があったところであり、法に違反する行為や不法行為を対象とする場合であっても、萎縮効果の懸念が示されていることから、事業者の負担と個人の権利利益の保護とのバランスを踏まえつつ、その導入の必要性を含めて多角的な検討を行っていく必要がある。

２ 実効性のある監視・監督の在り方

(1)課徴金、勧告・命令等の行政上の監視・監督手段の在り方

ア 課徴金制度

課徴金制度については、関係団体からのヒアリングで強い反対意見が示されていることに加え、我が国の他法令における導入事例や国際的動向、個人の権利利益保護と事業者負担とのバランスを踏まえ、その導入の必要性を含めて検討する必要がある。

課徴金制度を導入する必要があると考えられる場合には、次のような論点を整理する必要がある。

・ 課徴金賦課の対象となる違法行為類型（現行法の指導・勧告・命令のみでは違反行為により得た利得が事業者の元に残ることとなり、事業者による個人の権利利益の侵害を効果的に抑止できないことを前提に、個人データの違法な第三者提供等の違反行為によって不当な利得を得ている場合や、個人データの漏えい等が発生している可能性を認識したにもかかわらず、適切な措置を講じることを怠る等の悪質な違反行為により、本来なすべき支払を免れた場合等について検討することが必要である。）

・ 課徴金の算定方法（例えば、個人データを販売することを通じて違法に第三者に提供した場合については、販売による売上という不当な利益が生じている点に着目することが考えられる。他方、悪質な安全管理措置義務違反の場合には、本来なすべき支払を免れた結果として、事業活動から得られる利益が増加している点に着目することが考えられる。）

・ 課徴金の 低額の設定、一定の要件を満たした場合の課徴金の加減算等

イ 勧告・命令の在り方

勧告・命令に関しては、個人情報取扱事業者等による法に違反する個人情報等の取扱いにより個人の権利利益の侵害が差し迫っている場合に直ちに中止命令を出すことの必要性や、法に違反する個人情報等の取扱いを行う個人情報取扱事業者等のみならず、これに関与する第三者に対しても行政上の措置をとることの必要性、法に違反する個人情報等の取扱いの中止のほかに個人の権利利益の保護に向けた措置を求めることの必要性の有無や手続保障など、その法制上の課題等について検討すべきである。

(2)刑事罰の在り方

個人情報が不正に取り扱われた悪質事案の類型が様々であることを踏まえ、法の直罰規定がこれらの事案を過不足なく対象としているかを検証し、その処罰範囲について検討するとともに、法定刑の適切性についても検討する必要がある。

さらに、個人情報の詐取等の不正取得が多数発生している状況を踏まえ、こうした行為を直罰規定の対象に含めるべきかについても検討する必要がある。

（3)漏えい等報告・本人通知の在り方

ア 漏えい等報告

漏えい等報告及び本人通知に関し、漏えい等報告の件数は、令和４年度（2022 年度）から漏えい等報告が義務化されたこと等により、令和元年度（2019年度）以降全体として増加傾向にある一方で、関係団体等からはこれらの義務が事業者の過度な負担になっているという意見が示されている。

そこで、こうした意見も踏まえつつ、委員会がこれまでに受けた漏えい等報告の内容を検証した上で、上記制度の趣旨を損なわないようにしつつ、個人の権利利益侵害が発生するリスク等に応じて、漏えい等報告や本人通知の範囲・内容の合理化を検討すべきである。

この点、①上記のように、委員会がこれまでに受けた漏えい等報告を件数ベースでみると、漏えいした個人データに係る本人の数が１名である誤交付・誤送付案件が大半を占めているが、このようなケースは、当該本人にとっては深刻な事態になり得るものであり、本人通知の重要性は変わらないものの、本人通知が的確になされている限りにおいては、委員会に速報を提出する必要性が比較的小さい。また、②漏えい等又はそのおそれを認識した場合における適切な対処（漏えい等が生じたか否かの確認、本人通知、原因究明など）を行うための体制・手順が整備されていると考えられる事業者については、一定程度自主的な取組に委ねることも考えられる。そこで、例えば、体制・手順について認定個人情報保護団体などの第三者の確認を受けることを前提として、速報については、一定の範囲でこれを免除し、さらに①のようなケースについては確報について一定期間ごとの取りまとめ報告を許容することも考えられる。

また、関係団体からは、いわゆる「おそれ」要件についての要望も示されている。「おそれ」については、個人の権利利益を害する可能性等を勘案してより合理的と考えられる場合に報告や本人通知を求めることが適当であるとも考えられるが、その具体的な当てはめについては、現実の事例に応じて精査する必要がある。事業者の協力も得ながら、実態を明らかにした上で検討を行い、必要となる要件の明確化を行うことが必要である。

イ 違法な第三者提供

現行法においては、事業者が個人データを違法に第三者に提供した場合について、報告義務及び本人通知義務は存在しないが、個人データが漏えい等した場合については事業者にこれらの義務が課されることとの均衡から、漏えい等との違いの有無も踏まえ、その必要性や報告等の対象となる範囲を検討する必要がある。

 

３ データ利活用に向けた取組に対する支援等の在り方

(1)本人同意を要しないデータ利活用等の在り方

昨今のデジタル化の急速な進展・高度化に伴い、生成AI等の新たな技術の普及等により、大量の個人情報を取り扱うビジネス・サービス等が生まれている。また、健康・医療等の公益性の高い分野を中心に、機微性の高い情報を含む個人情報等の利活用に係るニーズが高まっている。このほか、契約の履行に伴う個人情報等の提供や、不正防止目的などでの利活用についてもニーズが寄せられている。

こうした状況を踏まえ、法で本人同意が求められる規定の在り方について、個人の権利利益の保護とデータ利活用とのバランスを考慮し、その整備を検討する必要がある。この場合においては、単に利活用の促進の観点から例外事由を認めるのは適当ではなく、本人の権利利益が適切に保護されることを担保することが必要である。

まず、生成AIなどの、社会の基盤となり得る技術やサービスのように、社会にとって有益であり、公益性が高いと考えられる技術やサービスについて、既存の例外規定では対応が困難と考えられるものがある。これらの技術やサービスについては、社会的なニーズの高まりや、公益性の程度を踏まえて、例外規定を設けるための検討が必要である。この際、「いかなる技術・サービスに高い公益性が認められるか」について、極めて多様な価値判断を踏まえた上で高度な意思決定が必要になる。個人の権利利益の保護とデータ利活用の双方の観点から多様な価値判断が想定されるものであり、関係府省庁も含めた検討や意思決定が必要と考えられる。

また、医療機関等における研究活動等に係る利活用のニーズについても、公益性の程度や本人の権利利益保護とのバランスを踏まえて、例外規定に係る規律の在り方について検討する必要がある。例えば、医療や研究開発の現場における公衆衛生例外規定の適用のように、例外規定はあるものの、適用の有無に関する判断にちゅうちょする例があるとの指摘がある。こうした点等については、事業者の実情等も踏まえつつ、関係府省庁の関与を得ながら、ガイドラインの記載等についてステークホルダーと透明性のある形で議論する場の設定に向けて検討する必要がある。

(2)民間における自主的な取組の促進

PIA・個人データの取扱いに関する責任者は、データガバナンス体制の構築において主要な要素となるものであり、その取組が促進されることが望ましい。他方、これらの義務化については、各主体における対応可能性や負担面などを踏まえ、慎重に検討を進める必要がある。

PIAについては、民間における自主的な取組という現状の枠組みを維持しつつ、その取組を一層促進させるための方策について、PIAの出発点となり得るデータマッピングを活用していくことを含め、検討を進める必要がある。

個人データの取扱いに関する責任者に関しては、現行の通則ガイドライン等で定める「組織体制の整備」を超えた措置の必要性について検討を進めるべきである。資格要件の要否、設置を求める対象事業者の範囲等によりその効果が変わってくると考えられるところ、各企業の現状も踏まえ、現実的な方向性を検討する必要がある。

[1] 個人関連情報とは、「Cookie 等の端末識別子を通じて収集された、ある個人のウェブサイトの閲覧履 歴」や「メールアドレスに結び付いた、ある個人の年齢・性別・家族構成」等がこれに該当する。ただ し、これらの情報が個人情報に該当する場合には、個人関連情報には該当しない。

[2] なお、仮名加工情報を取り扱う場合には、電話をかけ、郵便若しくは信書便により送付し、電報を送達 し、ファクシミリ装置若しくは電磁的方法を用いて送信し、又は住居を訪問するために、当該仮名加工情報に含まれる連絡先その他の情報の利用を行ってはならないこととされている（法第 41 条第８項）。

---

適時の紹介はしていなかった、289回と290回...

• 289回（技術的専門性のある方）
  
  • 佐藤一郎さん
  • 高木浩光さん
• 290回（法的専門性のある方）
  
  • 板倉陽一郎さん
  • 鈴木正朝さん

です。みなさんのことは昔から存じていますが、その主張やその表現に人柄が現れているように感じます。

板倉先生のコメントはわかりやすく参考になると思います...

● 個人情報保護委員会

・[PDF] 第二次いわゆる３年ごと見直しへのコメント（ひかり総合法律事務所　板倉弁護士）

・[PDF] デジタル社会の個人情報保護法（新潟大学　鈴木教授）

・[PDF] 個人情報保護委員会「いわゆる３年ごと見直し」ヒアリング（国立情報学研究所　佐藤教授） 

・[PDF] 個人情報保護法３年ごと見直し令和６年に対する意見（産業技術総合研究所　高木主任研究員）

3年ごとの見直し...

2024.06.26	第292回個人情報保護委員会
資料１	個人情報保護法 いわゆる３年ごと見直しに係る検討の中間整理（案）
【委員長預かりで会議後に修正した資料】 資料１	個人情報保護法　いわゆる３年ごと見直しに係る検討の中間整理
資料２−１	日EU相互認証の枠組みの拡大に向けた対応について
資料２−２	個人情報保護委員会藤原靜雄委員長と欧州委員会ベラ・ヨウロバー副委員長（価値・透明性担当）の会談に関する共同プレス・ステートメント（英語）
資料２−３	個人情報保護委員会藤原靜雄委員長と欧州委員会ベラ・ヨウロバー副委員長（価値・透明性担当）の会談に関する共同プレス・ステートメント（日本語仮訳）
資料３	一般送配電事業者及び関係小売電気事業者等における顧客情報の不適切な取扱事案に対する個人情報の保護に関する法律に基づく行政上の対応について
議事概要
議事録
2024.06.13	第290回個人情報保護委員会
資料１－１	第二次いわゆる３年ごと見直しへのコメント（ひかり総合法律事務所　板倉弁護士）
資料１－２	デジタル社会の個人情報保護法（新潟大学　鈴木教授）
議事概要
議事録
2024.06.12	第289回個人情報保護委員会
資料１－１	個人情報保護委員会「いわゆる３年ごと見直し」ヒアリング（国立情報学研究所　佐藤教授）
資料１－２	個人情報保護法３年ごと見直し令和６年に対する意見（産業技術総合研究所　高木主任研究員）
議事概要
議事録
2024.06.03	第287回個人情報保護委員会
資料１－１	個人情報保護法見直しに関するコメント（京都大学　曽我部教授）
資料１－２	いわゆる3年ごと見直しに関する意見（慶應義塾大学　山本教授）
資料１－３	３年ごと見直しヒアリング２０２４（英知法律事務所　森弁護士）
資料１－４－1	個人情報保護法のいわゆる３年ごと見直しに関する意見（東京大学　宍戸教授）
資料１－４－2	宍戸常寿氏御提出資料（令和元年５月21日提出）
議事概要
議事録
2024.05.29	第286回個人情報保護委員会
資料１	個人情報保護法 いわゆる３年ごと見直し規定に基づく検討（実効性のある監視・監督の在り方③）
議事概要
議事録
2024.05.15	第284回個人情報保護委員会
資料２	個人情報保護法 いわゆる３年ごと見直し規定に基づく検討（データ利活用に向けた取組に対する支援等の在り方）
資料３	個人情報保護法 いわゆる３年ごと見直し規定に基づく検討（実効性のある監視・監督の在り方②）
議事概要
議事録
2024.05.10	第283回個人情報保護委員会
資料１－１	個人情報保護法における課徴金制度導入にかかる諸論点（名古屋大学 林教授）
資料１－２	個人情報保護法における法執行の強化について（神戸大学 中川教授）
議事概要
議事録
2024.04.24	第281回個人情報保護委員会
資料１	個人情報保護法の３年ごと見直しに対する意見
資料２	個人情報保護法　いわゆる３年ごと見直し規定に基づく検討（個人の権利利益のより実質的な保護の在り方③）
議事概要
議事録
2024.04.10	第280回個人情報保護委員会
資料１	個人情報保護法　いわゆる３年ごと見直し規定に基づく検討（個人の権利利益のより実質的な保護の在り方② ）
議事概要
議事録
2024.04.03	第279回個人情報保護委員会
資料１―１	AIと個人情報保護：欧州の状況を中心に（一橋大学 生貝教授）
資料１―２	AI利用と個人情報の関係の考察（NTT社会情報研究所 高橋チーフセキュリティサイエンティスト）
資料１−３	医療情報の利活用の促進と個人情報保護（東京大学 森田名誉教授）
資料１―４	医療・医学系研究における個人情報の保護と利活用（早稲田大学　横野准教授）
議事概要
議事録
2024.03.22	第277回個人情報保護委員会
資料１	個人情報保護法　いわゆる３年ごと見直し規定に基づく検討（実効性のある監視・監督の在り方①）
議事概要
議事録
2024.03.06	第275回個人情報保護委員会
資料１	個人情報保護法　いわゆる３年ごと見直し規定に基づく検討（個人の権利利益のより実質的な保護の在り方①）
議事概要
議事録
2024.02.21	第273回個人情報保護委員会
資料４	個人情報保護法　いわゆる３年ごと見直し規定に基づく検討項目
【委員長預かりで会議後に修正した資料】資料４	個人情報保護法　いわゆる３年ごと見直し規定に基づく検討項目
議事概要
議事録
2024.02.14	第272回個人情報保護委員会
資料２－１	地方公共団体における個人情報保護法運用状況のヒアリング（京都府総務部政策法務課）
資料２－２	岡山市における個人情報保護法の運用状況（岡山市総務局行政事務管理課）
資料２－３	個人情報保護法運用状況について（都城市総務部総務課）
資料２－４	個人情報保護法運用状況について（上里町総務課）
議事概要
議事録
2024.02.07	第271回個人情報保護委員会
資料１	インターネット広告における個人に関する情報の取扱いについての取組状況（日本インタラクティブ広告協会）
議事概要
議事録
2024.01.31	第270回個人情報保護委員会
資料２	個人情報保護法の3 年ごと見直しに対する意見（日本経済団体連合会）
議事概要
議事録
2024.01.23	第268回個人情報保護委員会
資料１―１	(特定)適格消費者団体の活動について（消費者支援機構関西）
資料１―２	個人情報保護委員会ヒアリング資料（日本商工会議所）
議事概要
議事録
2023.12.21	第266回個人情報保護委員会
資料１―１	個人情報保護法の３年ごと見直しに関する意見（電子情報技術産業協会）
資料１―２	ヒアリング資料（全国商工会連合会）
議事概要
議事録
2023.12.20	第265回個人情報保護委員会
資料１―１	ACCJ Comments for the Personal Information Protection Commission Public Hearing（在米国商工会議所）
資料１―２	公開ヒアリングに向けたACCJ意見（在米国商工会議所）
議事概要
議事録
2023.12.15	第264回個人情報保護委員会
資料１―１	個人情報保護法の見直しについて（新経済連盟）
資料１―２	個人情報保護法見直しに関する意見（日本IT団体連盟）
議事概要
議事録
2023.12.06	第263回個人情報保護委員会
資料２	個人情報保護法に関する欧州企業の代表的な課題（欧州ビジネス協会）
議事概要
議事録
2023.11.29	第262回個人情報保護委員会
資料１	ヒアリング資料（一般社団法人日本情報経済社会推進協会）
議事概要
議事録
2023.11.15	第261回個人情報保護委員会
資料２－１	個人情報保護法　いわゆる３年ごと見直し規定に基づく検討
資料２－２	個人情報保護に係る主要課題に関する海外・国内動向調査　概要資料
議事概要
議事録

以前、このブログにも書いた私の考えですが...

個人情報保護委員会の事務局長とお話をした時に、私も結果的にグローバルスタンダードになっているGDPRとの整合（ブラッセル効果をなんでうけなあかんねん！なんですけどね...）と、もう一方の米国の規制については考慮すべきという話をしました。具体的には、以前にも書いていますが、、、

法令の見直しという点では、

• 悪徳事業者への罰金等の増額
• 拡大した個人情報の定義についてのGDPR等との整合性の確保のための整理
• 子供の個人情報保護のための規定の追加
• 各個別分野（医療、金融、通信、その他重要インフラ分野）等における課題の調整

というのが必要かと思っていて、

さらにガイドライン及びFAQにおいて

• 改訂部分の説明と事例の提示
• AIの利活用における考え方の整理と具体例の提示
• 公益性とプライバシー保護のグラデーションの整理と事例の提示
• 漏えい等の報告におけるルールのさらなる明確化と事例の追加（例えば、報告が不要な軽微な例）

そして、政策的には

• G7、G20各国等の主要国とのプライバシー保護に関する規制の調整に関するリーダーシップをとるための体制の整備
• 国内省庁との連携体制の強化（例：子ども家庭庁、国家安全保障委員会）のための体制の強化
• 国民への周知等（例：より幅広い層へのアクセス手段の拡大、教育現場への教育ツールの提供）の強化

というのが必要と思っています...

あと、加えて安全保障との関係の整理も別途必要となりそうですね...

医療情報、災害時と同様に一般的な利活用と保護のバランスではないので、別途検討が必要となるかもですね...

欧州委員会 金融セクターにおける人工知能に関する意見募集 (2024.06.18)

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

欧州委員会が、金融セクターにおける人工知能に関する質問書について意見募集が出ていますね。。。

3部構成になっていて、

1. 第1部：AIの発展に関する一般的な質問
2. 第2部：金融における具体的なユースケースに関する質問
3. 第3部：金融セクターに関連するAI法に関する質問

で、

第一部については、

• AIの利用
• 金融サービスにおけるAIアプリケーション活用のメリット
• 金融サービスでAIアプリケーションを使用する際の課題とリスク
• AIとコンプライアンスの負担
• データアクセス
• ビジネスモデル 
• 汎用AI
• ハイリスクでないユースケースに関連し、AI法に基づく特定の要件の対象とならないAIガバナンス 
• 予測

第2部については、

• 銀行業務
• 証券業務
• 市場業務
• 保険業務
• 資産管理業務
• その他業務

となっていますね...

● European Commission

・2024.06.18 Targeted consultation on artificial intelligence in the financial sector

Target audience	対象者
The targeted consultation will gather input from all financial services stakeholders including companies and consumer associations. Views are particularly welcome from financial firms that provide or deploy/use AI systems. This consultation is designed for respondents developing or planning to develop or use AI applications in financial services.	対象となるコンサルテーションは、企業や消費者団体を含むすべての金融サービス関係者から意見を集める。特に、AIシステムのプロバイダや導入・利用を行う金融機関からの意見を歓迎する。このコンサルテーションは、金融サービスにおいてAIアプリケーションを開発中、または開発・利用を計画している回答者を対象としている。
Why we are consulting	コンサルティングを行う理由
The present targeted consultation will inform the Commission services on the concrete application and impact of AI in financial services, considering the developments in the different financial services use cases.	本協議は、金融サービスにおけるAIの具体的な応用と影響について、さまざまな金融サービスのユースケースの進展を考慮しながら、欧州委員会の業務に情報を提供するものである。
The views from stakeholders will support the Commission services in their assessment of market developments and risks related to AI and in the implementation of the AI Act in the financial sector. The consultation is focused on the objectives of the financial sector acquis and the AI Act and is not intended to focus on other policy objectives such as competition policy. It is intended to improve the effective implementation of these legal frameworks.	利害関係者からの意見は、AIに関連する市場の発展やリスクのアセスメントにおいて、また、金融分野におけるAI法の実施において、欧州委員会の業務を支援するものとなる。この協議は、金融セクター規制とAI法の目的に焦点を当てたものであり、競争政策など他の政策目的に焦点を当てることを意図したものではない。これらの法的枠組みの効果的な実施を改善することを目的としている。
This targeted consultation will include questions with multiple choice and open answers. The questionnaire contains three parts:	この的を絞ったコンサルテーションには、多肢選択式および自由回答式の質問が含まれる。アンケートには3つのパートがある：
1. a first part with general questions on the development of AI	1. 第1部：AIの発展に関する一般的な質問
2. a second part with questions related to specific use cases in finance	2. 第2部：金融における具体的なユースケースに関する質問
3. and a third part on the AI Act related to the financial sector	3. 第3部：金融セクターに関連するAI法に関する質問
For the purpose of this targeted consultation, the concept of AI corresponds to the definition of an AI system established in the AI Act, which covers “any machine-based system designed to operate with varying levels of autonomy and that may exhibit adaptiveness after deployment and that, for explicit or implicit objectives, infers, from the input it receives, how to generate outputs such as predictions, content, recommendations, or decisions that can influence physical or virtual environments”.	本コンサルテーションでは、AIの概念は、AI法に定められたAIシステムの定義に対応するものであり、「様々なレベルの自律性を持って動作するように設計され、導入後に適応性を示す可能性があり、明示的または暗黙的な目的のために、物理的または仮想的環境に影響を与えることができる予測、コンテンツ、推奨、または決定などの出力を生成する方法を、受け取った入力から推測するもの」を対象とする。
Respond to the consultation	コンサルテーションへの対応
Please note that in order to ensure a fair and transparent consultation process responses should be submitted through the online questionnaire.	公平で透明性の高いコンサルテーションプロセスを確保するため、回答はオンラインアンケートを通じて提出されることに留意されたい。
Respond to the consultation	コンサルテーションに対応する
Reference documents	参考資料
・Consultation document: Artificial intelligence in the financial sector	・コンサルテーション文書 金融分野における人工知能
・Specific privacy statement: Artificial intelligence in the financial sector	・特定のプライバシーに関する声明 金融分野における人工知能

・TARGETED CONSULTATION ON ARTIFICIAL INTELLIGENCE IN THE FINANCIAL SECTOR

本文部分...

・[PDF] Consultation document: Artificial intelligence in the financial sector

INTRODUCTION	序文
In financial services and beyond, there is a broad technology-driven trend towards greater use of AI. The Commission highlighted the need for a targeted consultation on the use of AI in financial services. The goal is to identify the main use cases and the benefits, barriers and risks related to the development of AI applications in the financial sector.	金融サービスをはじめ、幅広い分野でAIを活用する動きが広がっている。欧州委員会は、金融サービスにおけるAIの活用に関する的を絞ったコンサルテーションの必要性を強調した。その目的は、金融分野におけるAIアプリケーションの開発に関する主なユースケース、メリット、障壁、リスクを特定することである。
In general, the development and use of AI in the EU will be regulated by the AI Act, the world’s first comprehensive AI law. The AI Act which was voted by the European Parliament on 13 March and expected to enter into force in July, aims to guarantee the safety and fundamental rights of people and businesses, while strengthening AI uptake, investment and innovation across the EU. To support further these objectives, an AI innovation package has been adopted by the Commission on 24 January 2024. It contains a series of measures to support European startups and SMEs in the development of trustworthy AI that respects EU values and rules. This follows the political agreement reached in December 2023 on the AI Act.	一般的に、EUにおけるAIの開発と利用は、世界初の包括的なAI法であるAI法によって規制される。3月13日に欧州議会で採決され、7月に施行される見込みのAI法は、EU全域でのAIの導入、投資、イノベーションを強化する一方で、人々と企業の安全と基本的権利を保証することを目的としている。こうした目標をさらに支援するため、欧州委員会は2024年1月24日、AIイノベーションパッケージを採択した。このパッケージには、EUの価値観と規則を尊重した信頼できるAIの開発において、欧州の新興企業や中小企業を支援するための一連の措置が盛り込まれている。これは、2023年12月に成立したAI法に関する政治的合意に続くものである。
The AI Act is designed to complement the already existing financial services acquis, that, while not explicitly targeted at regulating AI, is an important framework to manage the related risks in specific applications and includes several relevant requirements for financial entities when providing financial services. It does so by pursuing objectives to ensure healthy financial markets, such as transparency, market integrity, investor protection and financial stability. For example, when providing investment services, including through reliance on AI such as trading algorithms, investment firms must comply with the MIFID/R framework and the market abuse rulebook.	AI法は、すでに存在する金融サービス法を補完するように設計されている。同法は、AIの規制を明確には対象としていないものの、特定のアプリケーションにおける関連リスクを管理するための重要な枠組みであり、金融サービスを提供する際の金融事業体に対するいくつかの関連要件を含んでいる。これは、透明性、市場の健全性、投資家保護、金融の安定など、健全な金融市場を確保するための防御を追求するものである。例えば、取引アルゴリズムのようなAIへの依存を含め、投資サービスを提供する場合、投資会社はMIFID/Rのフレームワークと市場濫用ルールブックを遵守しなければならない。
The aim of this consultation is not to lead to policy work that would generate new duplicative requirements in relation to the use of AI by the financial sector, or to new requirements that have the potential to stifle AI innovation.	このコンサルテーションの目的は、金融セクターによるAIの利用に関して、新たな生成的要件を生み出すような政策作業や、AIのイノベーションを阻害する可能性のある新たな要件につながらないようにすることである。
Objective of the consultation	コンサルテーションの目的
The present targeted consultation will inform the Commission services on the concrete application and impact of AI in financial services, considering the developments in the different financial services use cases.	本コンサルテーションは、金融サービスにおけるAIの具体的な応用と影響について、さまざまな金融サービスのユースケースの進展を考慮しながら、欧州委員会の業務に情報を提供することを目的としている。
The views from stakeholders will support the Commission services in their assessment of market developments and risks related to AI and in the implementation of the AI Act and existing financial services legislation in the financial sector. The consultation is focused on the objectives of the financial sector acquis and the AI Act and is not intended to focus on other policy objectives such as competition policy. It is intended to improve the effective implementation of these legal frameworks.	利害関係者からの意見は、AIに関連する市場の発展やリスクのアセスメント、金融分野におけるAI法や既存の金融サービス法の施行において、欧州委員会の業務を支援するものとなる。このコンサルテーションは、金融セクター規制およびAI法の目的に焦点を当てたものであり、競争政策など他の政策目的に焦点を当てることを意図したものではない。これらの法的枠組みの効果的な実施を改善することを目的としている。
This targeted consultation will include questions with multiple choice and open answers. The questionnaire contains three parts:	この的を絞ったコンサルテーションには、多肢選択式および自由回答式の質問が含まれる。アンケートには3つのパートがある：
1.     a first part with general questions on the development of AI	1. 第1部：AI開発に関する一般的な質問
2.     a second part with questions related to specific use cases in finance	2. 第2部：金融における具体的なユースケースに関する質問
3.     and a third part on the AI Act related to the financial sector	3. 第3部：金融セクターに関連するAI法に関する質問
For the purpose of this targeted consultation, the concept of AI corresponds to the definition of an AI system established in the AI Act, which covers “any machine-based system designed to operate with varying levels of autonomy and that may exhibit adaptiveness after deployment and that, for explicit or implicit objectives, infers, from the input it receives, how to generate outputs such as predictions, content, recommendations, or decisions that can influence physical or virtual environments”.	このコンサルテーションでは、AIの概念はAI法に定められたAIシステムの定義に対応するものであり、「様々なレベルの自律性で動作するように設計され、導入後に適応性を示す可能性があり、明示的または暗黙的な目的のために、物理的または仮想的な環境に影響を与えることができる予測、コンテンツ、推奨、決定などの出力を生成する方法を、受け取った入力から推論するもの」を対象とする。
Target group	対象グループ
The targeted consultation will gather input from all financial services stakeholders including companies and consumer associations. Views are particularly welcome from financial firms that provide or deploy/use AI systems. This consultation is designed for respondents developing or planning to develop or use AI applications in financial services.	対象となるコンサルテーションは、企業や消費者団体を含む全ての金融サービス関係者から意見を集める。特に、AIシステムのプロバイダや導入・利用を行う金融企業からの意見を歓迎する。本コンサルテーションは、金融サービスにおいてAIアプリケーションを開発または使用する予定の回答者を対象としている。
Responding to the consultation	コンサルテーションへの対応
Respondents are invited to complete the questionnaire by 13 September 2024. They are invited to elaborate by providing input and additional insights to their answers.	対応者は2024年9月13日までにアンケートに回答するよう求められる。回答者は、回答に対するインプットや追加的な洞察を提供することで、より詳細な情報を得ることができる。
Outcome	成果
Depending on the progress made, the Commission will publish a report on the findings and an analysis of the main trends and issues arising with the use of AI applications in financial services.	進捗状況に応じて、欧州委員会は、調査結果および金融サービスにおけるAIアプリケーションの利用によって生じる主な傾向と問題点の分析に関する報告書を公表する。
Please note that the information collected will not be shared with third parties and if used, it will be anonymised, in such a manner that it does not relate to any identified or identifiable financial institution.	なお、収集された情報はサードパーティと共有されることはなく、使用される場合は、特定または識別可能な金融機関に関連しないように匿名化される。
CONSULTATION QUESTIONS	コンサルテーションに関する質問
Part 1: GENERAL QUESTIONS ON AI APPLICATIONS IN FINANCIAL SERVICES	第1部：金融サービスにおけるAiアプリケーションに関する一般的な質問
1.1. Use of AI	1.1. AIの利用
Question 1. Are you using or planning to use AI systems?	質問1. AIシステムを使用しているか、または使用する予定があるか？
•     Yes, we are already using AI systems.	・はい、すでにAIシステムを利用している。
•     Not yet, but we plan to use AI systems within the next 2 years.	・まだ使用していないが、今後2年以内に使用する予定である。
•     No, we are not using AI systems and we don’t plan to use it within the next 2 years.	・いいえ、AIシステムを利用していないし、今後2年以内に利用する予定もない。
Question 2. What are the positive things you encounter when using AI?	質問2. AIを使用する際に遭遇するポジティブなことは何か？
Open answer/Please explain and give examples when possible.	自由回答／可能であれば例を挙げて説明してほしい。
Question 3. What are the negative things you encounter when using AI?	質問3. AIを利用する際に、マイナスになることは何か？
Open answer/Please explain and give examples when possible.	自由回答／可能であれば例を挙げて説明してほしい。
Question 4. Will you be deploying AI for new or additional processes within your organisation?	質問4. 組織内の新規または追加のプロセスにAIを導入するか？
•     Yes, which ones?	・はい。
•     No	・いいえ
Question 5. Are you developing or planning to develop in-house AI applications?	質問5. 社内でAIアプリケーションを開発しているか、または開発する予定があるか？
•     Yes, please explain.	・はい、説明してほしい。
•     No, please explain broadly whom you plan to collaborate with for the development of your AI applications (fintech, bigtech, etc.). or whether you plan to buy off the shelf fully developed solutions.	・いいえ、AIアプリケーション（フィンテック、ビッグテックなど）の開発のために誰と協業する予定か、または完全に開発された既製のソリューションを購入する予定かどうか、大まかに説明してください。
Question 6. Which tools are you using to develop your AI applications? Examples: machine learning, neural networks, natural language processing, large language models, etc.	質問6. AIアプリケーションの開発にはどのツールを使っているか？例：機械学習、ニューラルネットワーク、自然言語処理、大規模言語モデルなど。
Open answer/Please explain and give examples when possible.	自由回答／可能であれば例を挙げて説明してほしい。
1.2. Benefits of using AI applications in financial services	1.2. 金融サービスにおけるAIアプリケーション活用のメリット
Question 7. Please score the following benefits from most significant (10) to least significant (1):	質問7. 以下の利点について、最も重要なもの（10）から最も重要でないもの（1）までの点数をつけてください：
•     Fraud detection: AI algorithms can analyse large amounts of data to detect patterns and anomalies that may indicate fraudulent activity, helping to reduce financial losses for businesses and customers.	・不正検知：AIアルゴリズムは大量のデータを分析し、不正行為を示すパターンや異常を検知することができる。
•     Risk management: AI can analyse and predict market trends, assess credit risks, and identify potential investment opportunities, helping financial institutions make more informed decisions and manage risks more effectively.	・リスクマネジメント：AIは、市場動向の分析と予測、信用リスクのアセスメント、潜在的な投資機会の特定を行うことができ、金融機関がより多くの情報に基づいた意思決定を行い、より効果的にリスクを管理するのに役立つ。
•     Automation of routine tasks: AI can automate repetitive tasks such as data entry, transaction processing, and document verification, freeing up time for employees to focus on more complex and strategic activities.	・定型業務の自動化：AIは、データ入力、取引処理、文書検証などの反復作業を自動化し、従業員がより複雑で戦略的な業務に集中できる時間を確保することができる。
•     Cost savings: by automating processes and improving efficiency, AI can help financial institutions reduce operational costs.	・コスト削減:プロセスを自動化し、効率を向上させることで、AIは金融機関の運用コスト削減に貢献する。
•     Personalized financial advice: AI can analyse customer data to provide personalized financial advice and recommendations, helping customers make better financial decisions and improve their financial well-being.	・パーソナライズされた金融アドバイス：AIは顧客データを分析し、個人に合った金融アドバイスや提案を提供することで、顧客がより適切な金融上の意思決定を行い、経済的な幸福を向上させることを支援する。
•     Compliance and regulatory support: AI can help financial institutions stay compliant with regulations by analysing and interpreting complex regulatory requirements and monitoring transactions for suspicious activities.	・コンプライアンスと規制のサポート：AIは、複雑な規制要件を分析・解釈し、疑わしい取引がないかを監視することで、金融機関が規制を遵守し続けることを支援できる。
•     Enhanced decision-making: AI can analyse large amounts of data and provide insights that can help financial institutions make better investment decisions, assess credit risks, and optimize their operations.	・意思決定の強化：AIは大量のデータを分析し、金融機関がより適切な投資判断を下し、信用リスクを評価し、業務を最適化するのに役立つ洞察を提供することができる。
•     Improved security: AI can enhance security measures by identifying potential security threats, detecting unusual patterns of behaviour, and providing real-time alerts to prevent security breaches.	・セキュリティの改善：AIは、潜在的なセキュリティ脅威を特定し、異常な行動パターンを検知し、セキュリティ侵害を防止するためのリアルタイム・アラートを提供することで、セキュリティ対策を強化することができる。
•     Streamlined processes: AI can streamline various financial processes, such as loan underwriting, account opening, and claims processing, leading to faster and more efficient services for customers.	・プロセスの合理化：AIは、ローンの引き受け、口座開設、クレーム処理など、さまざまな金融プロセスを合理化し、顧客により迅速で効率的なサービスを提供することができる。
•     Improved customer service: AI can be used to provide personalized and efficient customer service, such as chatbots that can answer customer queries and provide assistance 24/7.	・顧客サービスの改善：AIは、顧客からの問い合わせに回答し、24時間365日サポートを提供できるチャットボットなど、パーソナライズされた効率的な顧客サービスを提供するために利用できる。
Question 8. What are the main benefits/advantages you see in the development of your AI applications?	質問8. AIアプリケーションの開発における主なメリット／利点は何か？
Open answer/Please explain and give examples when possible.	自由回答／可能であれば例を挙げて説明してほしい。
1.3. Challenges and risks when using AI applications in financial services	1.3. 金融サービスでAIアプリケーションを使用する際の課題とリスク
Question 9. Please score the following challenges and risks from most significant	質問9. 以下の課題とリスクについて、最も重要なもの（10点）から最も重要でないもの（1点）まで、点数をつけていただきたい。
(10) to least significant (1):	（10）から最も重要でないもの（1）まで採点していただきたい：
•     Lack of access to the required data, in general.	・一般的に、必要なデータにアクセスできない。
•     Lack of access to the data in an appropriate digital format.	・適切なデジタル形式のデータにアクセスできない。
•     Lack of access to appropriate data processing technology, e.g. cloud computing.	・適切なデータ処理技術（例：クラウド・コンピューティング）へのアクセスが欠如している。
•     Data privacy: it is crucial to ensure that sensitive financial information remains confidential.	・データ・プライバシー:機密性の高い財務情報の機密性を確保することは極めて重要である。
•     Lack of trust in relation to performance levels/ security aspects/ certified solutions/ reliability of the technology.	・パフォーマンス・レベル/セキュリティ面/認定されたソリューション/テクノロジーの信頼性に関する信頼の欠如。
•     Regulatory compliance with financial regulation: financial services are heavily regulated and not all types of AI applications are in line with requirements under these regulations.	・金融規制へのコンプライアンス:金融サービスは規制が厳しく、すべての種類のAIアプリケーションがこれらの規制下の要件に合致しているわけではない。
•     Innovation: the ability to leverage on combining AI with other technologies to enhance its potential and generate new services?	・イノベーション:AIを他のテクノロジーと組み合わせて活用し、その可能性を高め、新たなサービスを生み出す能力か。
•     Transparency and explainability: AI algorithms can be complex and opaque. It can be difficult for humans to understand how AI arrives at certain conclusions, which can create issues of trust and accountability.	・透明性と説明可能性：AIのアルゴリズムは複雑で不透明な場合がある。AIがどのようにして特定の結論に至るのかを人間が理解することは困難であり、信頼と説明責任の問題が生じる可能性がある。
•     Bias and discrimination: AI models are trained using data, and if the data is biased, the AI model can also be biased, leading to unfair outcomes.	・バイアスと識別的：AIモデルはデータを使って訓練されるため、データにバイアスがかかっていると、AIモデルにもバイアスがかかり、不公平な結果につながる可能性がある。
•     Reputational risk from undesirable AI behavior or output.	・望ましくないAIの行動や出力による風評リスク。
•     Liability risks: legal uncertainty on who bears the liability in case of damages generated by the malfunctioning of the AI applications.	・責任リスク:AIアプリケーションの誤動作によって損害が発生した場合、誰が責任を負うかに関する法的不確実性。
•     Skills gap: the development of AI requires specific tech skills, and there is a shortage of such skills.	・スキル・ギャップ:AIの開発には特定の技術スキルが必要であり、そのようなスキルは不足している。
•     Dependability: as financial institutions rely more and more on AI; the dependability of these systems becomes paramount. Any malfunction or error (e.g. in risk management) can lead to significant financial losses.	・信頼性：金融機関のAIへの依存度が高まるにつれ、これらのシステムの信頼性が最も重要になる。誤作動やエラー（リスクマネジメントなど）があれば、大きな財務的損失につながりかねない。
•     Job displacement: the use of AI can potentially automate certain roles in the financial sector leading to job displacement.	・雇用の置き換え:AIの利用は、金融セクターにおける特定の役割を自動化する可能性があり、雇用の置き換えにつながる。
•     Cybersecurity: AI systems could be targeted by cybercriminals, leading to potential data breaches or manipulation of AI systems.	・サイバーセキュリティ：AIシステムはサイバー犯罪者に狙われる可能性があり、データ侵害やAIシステムの操作につながる可能性がある。
•     Integration challenges: integrating AI technologies with existing systems and processes can be complex and expensive.	・統合の課題:AI技術を既存のシステムやプロセスに統合することは複雑でコストがかかる可能性がある。
•     Additional cost: the deployment and use of AI requires up-front investment and ongoing resources (acquiring or developing applications, keeping them up to date, training/skills).	・追加コスト：AIの導入と利用には、先行投資と継続的なリソース（アプリケーションの取得や開発、最新状態の維持、トレーニング／スキル）が必要となる。
Question 10. What are the main difficulties/obstacles you are facing in the development of your AI applications?	質問10. AIアプリケーションの開発で直面している主な困難／障害は何か？
Open answer/Please explain and give examples when possible.	自由回答／可能であれば例を挙げて説明してほしい。
Question 11. Please rank the potential negative impact that widespread use of AI can have on the following risks. 8 being the highest risk.	質問11. AIの普及が以下のリスクに与える潜在的な悪影響をランク付けしてほしい。8が最も高いリスクである。
•     Operational risks	・オペレーションリスク
•     Market risks	・市場リスク
•     Liquidity risks	・流動性リスク
•     Financial stability risks	・金融安定性リスク
•     Market integrity risks	・市場整合性リスク
•     Investor protection risk	・投資家保護リスク
•     Consumer protection risk	・消費者保護リスク
•     Reputational risk	・風評リスク
Please explain your answer to the previous question and give examples when possible.	前問に対する回答について説明し、可能であれば例を挙げて説明してほしい。
Question 12. AI may affect the type and degree of dependencies in financial markets in certain circumstances, especially where a high number of financial entities rely on a relatively small number of third-party providers of AI systems. Do you see a risk of market concentration and/or herding behavior in AI used for financial services?	質問12. 特に、多数の金融事業体が比較的少数のAIシステムのサードパーティ・プロバイダに依存している場合、AIは特定の状況において、金融市場における依存関係の種類や程度に影響を与える可能性がある。金融サービスに使用される AI において、市場集中及び／又は群れ行動 のリスクがあると考えるか？
•     Yes, in which areas of AI?	・はい、AIのどの分野で？
•     No, please explain.	・いいえ、説明してほしい。
1.4. AI and compliance burden	1.4. AIとコンプライアンスの負担
Question 13. Can AI help to reduce the reporting burden?	質問13. AIは報告負担の軽減に役立つか。
•     Yes, in which areas do you see AI reducing reporting burden?	・はい、どの分野でAIが報告負担を軽減すると思うか？
•     No, why?	・いいえ、その理由は？
Question 14. Do you think AI can facilitate compliance with multiple regulatory standards across the EU and thus facilitate market integration or regulatory compliance? For example, would you consider it feasible to use AI for converting accounting and financial statements developed under one standard (e.g. local GAAP) to another standard (e.g. IFRS)? Please elaborate.	質問14. AIはEU全域で複数の規制標準への準拠を促進し、市場統合や規制遵守を促進できると考えるか。例えば、ある標準（例えばローカルGAAP）の下で作成された会計・財務諸表を別の標準（例えばIFRS）に変換するためにAIを利用することは実現可能だと考えるか。詳しく説明してほしい。
Open answer/Please explain and give examples when possible.	自由回答／可能であれば例を挙げて説明してほしい。
1.5. Data access	1.5. データアクセス
Question 15. In order to develop AI applications, do you need access to external datasets that you currently don’t have access to?	質問15. AIアプリケーションを開発するために、現在アクセスできない外部データセットにアクセスする必要があるか？
•     Yes	・はい
•     No	・必要ない
Question 16. Which datasets would you need to develop meaningful AI applications and for which purpose / use case?	質問16. 有意義なAIアプリケーションを開発するために、どのようなデータセットが必要か。
Open answer/Please explain and give examples when possible.	自由回答／可能であれば例を挙げて説明してほしい。
Question 17. Do you face hurdles in getting access to the data you need to develop AI applications in financial services?	質問17. 金融サービスでAIアプリケーションを開発するために必要なデータにアクセスする際にハードルに直面するか？
•     Yes, please explain which type of data you would need to have access to.	・はい、どのようなデータにアクセスする必要があるか説明してほしい。
•     No	・いいえ
Question 18. Are you familiar with the EU Data Hub, a data sharing tool for supervisors and financial companies?	質問18. 監督当局と金融会社のためのデータ共有ツールであるEUデータハブをご存知か？
•     Yes, do you think it can improve access to data?	・はい、データへのアクセスを改善できると思うか。
•     No, are you aware of other data sharing initiatives that you find useful?	・いいえ、有用と思われる他のデータ共有イニシアチブを知っているか。
Question 19. Should public policy measures (e.g. legislative or non-legislative) encourage the exchange of data between market participants, which can be used to train AI systems for use cases in finance?	質問19. 金融のユースケースのためのAIシステムの訓練に使用できる市場参加者間のデータ交換を、公共政策措置（立法的または非立法的など）で奨励すべきか？
•     Yes. Which type of measures do you propose?	・はい。どのような対策を提案するか？
•     No	・提案しない
1.6. Business model	1.6. ビジネスモデル
Question 20. Has AI changed your business model?	質問20. AIは貴社のビジネスモデルを変えたか？
•     Yes, how?	・はい、どのように？
•     No	・いいえ
Question 21. Which parts of the value chain are being improved with AI?	質問21. バリューチェーンのどの部分がAIによって改善されているか？
Open answer/Please explain and give examples when possible.	自由回答／可能であれば例を挙げて説明してほしい。
Question 22. Are there functions that cannot/would not be improved by AI?	質問22. AIで改善できない／改善しない機能はあるか？
Open answer/Please explain and give examples when possible.	自由回答／可能であれば例を挙げて説明してほしい。
1.7. General purpose AI	1.7. 汎用AI
For the purpose of this targeted consultation, respondents should consider general purpose AI as defined in the AI Act (Article 3(63)), i.e. meaning any “AI model, including where such an AI model is trained with a large amount of data using selfsupervision at scale, that displays significant generality and is capable of competently performing a wide range of distinct tasks regardless of the way the model is placed on the market and that can be integrated into a variety of downstream systems or applications, except AI models that are used for research, development or prototyping activities before they placed on the market”.	本対象コンサルテーションでは、回答者は、AI法（第3条63項）に定義される汎用AI、すなわち、「AIモデル（そのようなAIモデルが大規模な自己監視を使用して大量のデータを用いて訓練される場合を含む）であって、そのモデルが上市される方法にかかわらず、有意な汎用性を示し、広範囲の明確なタスクを適切に実行することができ、様々な下流のシステム又はアプリケーションに統合することができるもの（上市前に研究、開発又はプロトタイピング活動に使用されるAIモデルを除く）」を意味する汎用AIを検討すべきである。
Question 23. Do you use general purpose AI models, including generative AI, and their respective reference architectures?	質問23. 生成的AIを含む汎用AIモデルと、それぞれの参照アーキテクチャを使用しているか？
•     Yes, please explain why you want to opt for these AI models in your organisation.	・はい、あなたの組織でこれらのAIモデルを選択したい理由を説明してほしい。
•     Not yet, but we plan to use general purpose AI models within the next 2 years.	・まだ使用していないが、今後2年以内に汎用AIモデルを使用する予定である。
•     No, please explain which other AI reference architectures (e.g. more traditional ones) you plan to use to develop your AI applications and why.	・いいえ、AIアプリケーションの開発に他のどのAI参照アーキテクチャ（より伝統的なものなど）を使用する予定か、その理由を説明してほしい。
Question 24. How do you plan to operationalise and adopt general purpose AI at scale?	質問24. 汎用AIをどのように運用し、大規模に採用する予定か。
Open answer/Please explain and give examples when possible.	自由回答／可能であれば例を挙げて説明してほしい。
Question 25. How does the increasing availability of general purpose AI models, including generative AI applications, impact the need to access new datasets?	質問25. 生成的AIアプリケーションを含む汎用AIモデルの利用可能性の増加は、新しいデータセットにアクセスする必要性にどのように影響するか？
Open answer/Please explain and give examples when possible.	自由回答／可能であれば例を挙げて説明してほしい。。
Question 26. Compared to traditional AI systems such as supervised machine learning systems, what additional opportunities and risks are brought by general purpose AI models?	質問26. 教師あり機械学習システムなどの従来のAIシステムと比較して、汎用AIモデルはどのような新たな機会とリスクをもたらすか？
Open answer/Please explain and give examples when possible.	自由回答／可能であれば例を挙げて説明してほしい。
Question 27. In which areas of the financial services value chain do you think general purpose AI could have a greater potential in the short, medium and long term?	質問27. 金融サービスのバリューチェーンのどの分野で、汎用AIが短期・中期・長期的に大きな可能性を持つと思うか？
Open answer/Please explain and give examples when possible.	自由回答／可能であれば例を挙げて説明してほしい。
1.8. AI Governance in relation to non-high risk use cases, and which are not subject to specific requirements under the AI Act	1.8. ハイリスクでないユースケースに関連し、AI法に基づく特定の要件の対象とならないAIガバナンス
Question 28. Have you developed, or are you planning to develop an AI strategy or other relevant guidelines within your organisation for the use of AI systems?	質問28. AIシステムの利用に関して、組織内でAI戦略やその他の関連ガイドラインを策定したか、または策定する予定があるか。
•     Yes, which ones?	・はい。
•     No	・いいえ
Question 29. Have you put in place or are you planning to put in place governance and risk management measures to ensure a responsible and trustworthy use of AI within your organisation?	質問29. 組織内で責任ある信頼できるAIの利用を確保するために、ガバナンスやリスクマネジメントを導入しているか、または導入する計画があるか。
•     Yes, which ones?	・はい、どのようなものか？
•     No	・いいえ
1.9. Forecasts	1.9. 予測
Question 30. What are the main evolutions to be expected in AI in finance?	質問30. 金融分野におけるAIに期待される主な進化は何か？
Open answer/Please explain and give examples when possible.	自由回答／可能であれば例を挙げて説明してほしい。
Question 31. Which financial services do you expect to be the most impacted by AI?	質問31. AIによって最も影響を受けると予想される金融サービスは？
Open answer/Please explain and give examples when possible.	自由回答／可能であれば例を挙げて説明してほしい。
Question 32. Do you have any additional information to share?	質問32. その他、共有すべき情報はあるか。
Part 2: QUESTIONS RELATED TO SPECIFIC USE CASES IN FINANCIAL SERVICES	第2部：金融サービスにおける具体的なユースケースに関する質問
Question 33. In which sector are you using AI?	質問33. どの分野でAIを活用しているか？
You may select more than one answer.	複数回答可
•     Banking and payments	・銀行業務と決済
•     Market infrastructure	・市場インフラ
•     Securities markets	・証券市場
•     Insurance and pensions	・保険・年金
•     Asset management	・資産管理
•     Other	・その他
2.1. Questions per sector	2.1. セクターごとの質問
Banking and payments (if selected)	銀行業務と決済（選択した場合）
In banking, possible AI use cases range from credit risk assessment and credit scoring to advice, compliance, early warning (for example of unusual social media activity / massive withdrawal of deposits), fraud/AML and customer service.	銀行業務では、AIのユースケースとして、信用リスクアセスメントやクレジットスコアリングから、アドバイス、コンプライアンス、早期警告（ソーシャルメディアの異常な活動や預金の大量引き出しなど）、詐欺／AML、顧客サービスまでが考えられる。
Depending on the specific use cases, relevant legislation would include:	具体的なユースケースに応じて、関連する法律には以下が含まれる：
•       the AI Act (for the identified high-risk use cases such as creditworthiness and credit-scoring of natural persons)	・AI法（自然人の信用度や信用スコアリングなど、特定された高リスクのユースケース用）
•       the Consumer Credit Directive  and the Mortgage Credit Directive	・消費者信用指令および住宅ローン信用指令
(creditworthiness of natural persons and robo-advice)	（消費者信用指令および住宅ローン信用指令（自然人の信用度およびロボアドバイス）
•       the Capital Requirements Regulation (CRR) (for example provisions on risk management in relation to credit risk assessment)	・資本規制（CRR）（信用リスク評価に関するリスクマネジメント規定など）
•       the Payment Services Directives (PSD) (for example for fraud detection)	・決済サービス指令（PSD）（不正行為の検知など）
•       and the Anti-Money Laundering Directive (AMLD) (for example for AML risk use cases)	・マネーロンダリング防止指令（AMLD）（AML リスクのユースケースなど）
Question BANKING 1. For which use case(s) are you using/considering using AI?	質問 銀行業務 1. どのようなユースケースで AI を利用／検討しているか。
Open answer. Examples: risk assessment, credit scoring, robo-advice, sustainable finance, personal finance management, regulatory compliance, fraud detection, AML, customer service, etc.	自由回答 検知例：リスクアセスメント、クレジットスコアリング、ロボアドバイス、サステナブルファイナンス、パーソナルファイナンスマネジメント、規制遵守、不正検知、AML、顧客サービスなど。
Question BANKING 2. What are the opportunities that AI brings to your use case?	質問 銀行業務 2.AIがあなたのユースケースにもたらす機会は何か？
Open answer/Please explain and give examples when possible.	自由回答／可能であれば例を挙げて説明してほしい。
Question BANKING 3. What are the main challenges and risks that AI brings to your use case (e.g. discrimination, opacity of the AI application developed, difficult to control/supervise it, etc.)?	質問 銀行業務 3. AIが貴社のユースケースにもたらす主な課題とリスクは何か（識別的、開発されたAIアプリケーションの不透明性、制御／監督が困難など）。
Open answer/Please explain and give examples when possible.	自由回答／可能であれば例を挙げて説明してほしい。
Question BANKING 4. What is the main barrier to developing AI in your use case (e.g. lack of skills and resources, readiness of the technology, high regulatory costs for compliance with the relevant frameworks, etc.)?	質問 銀行業務 4. ユースケースにおけるAI開発の主な障壁は何か（スキルやリソースの不足、技術の準備、関連フレームワークへの準拠のための高い規制コストなど）？
Open answer/Please explain and give examples when possible.	自由回答／可能であれば例を挙げて説明してほしい。
Question BANKING 5. Does AI reduce or rather increase bias and discrimination in your use case?	質問 銀行業務 5. あなたのユースケースにおいて、AIはバイアスや識別を減らすか、むしろ増やすか？
Please explain and give examples when possible.	可能であれば例を挙げて説明してほしい。
Question BANKING 6. Has general purpose AI opened new possibilities or risks in your use case?	質問 銀行業務 6. あなたのユースケースにおいて、汎用AIは新たな可能性やリスクをもたらしたか。
•     Yes	・はい
•     No	・いいえ
Please explain and give examples when possible.	可能であれば例を挙げて説明してほしい。
Question BANKING 7. On whom do you rely for the development of your AI solutions?	質問 銀行業務 7. AIソリューションの開発を誰に依存しているか。
•     External providers	・外部プロバイダ
•     In-house applications	・社内アプリケーション
•     Partial collaboration with external providers	・外部プロバイダとの一部協業
Please explain and give examples when possible.	可能であれば例を挙げて説明してほしい。
Market infrastructure (if selected)	市場インフラ（選択した場合）
According to the European securities and markets authority (ESMA)[1], AI is currently not widely used by financial market infrastructures in their operations. However, use of AI systems in post-trading is emerging and will likely become more relevant in the future, such as for predicting settlement fails, anomaly detection, data verification and data quality checks.	欧州証券市場認可局（ESMA）[1]によると、現在、金融市場インフラにおいてAIはあまり活用されていない。しかし、ポストトレーディングにおけるAIシステムの利用は台頭しつつあり、決済失敗の予測、異常検知、データ検証、データ品質チェックなど、今後関連性が高まる可能性が高い。
Question MARKET 1. For which use case(s) are you using/considering using AI?	質問 市場業務1. どのようなユースケースでAIの活用を考えているか？
Open answer. Examples: risk management, sustainable finance, regulatory compliance, etc.	自由回答 例：リスクマネジメント、サステイナブル・ファイナンス、規制遵守など。
Question MARKET 2. What are the opportunities that AI brings to your use case?	質問 市場業務2. AIがあなたのユースケースにもたらす機会は何か？
Open answer/Please explain and give examples when possible.	自由回答／可能であれば例を挙げて説明してほしい。
Question MARKET 3. What are the main challenges and risks that AI brings to your use case (e.g. discrimination, opacity of the AI application developed, difficult to control/supervise it, etc.)?	質問 市場業務3. AIがあなたのユースケースにもたらす主な課題とリスクは何か（識別的、開発されたAIアプリケーションの不透明性、制御／監督の困難性など）？
Open answer/Please explain and give examples when possible.	自由回答／可能であれば例を挙げて説明してほしい。
Question MARKET 4. What is the main barrier to developing AI in your use case (e.g. lack of skills and resources, readiness of the technology, high regulatory costs for compliance with the relevant frameworks, etc.)?	質問 市場業務 4.あなたのユースケースにおけるAI開発の主な障壁は何か（例：スキルやリソースの不足、技術の準備、関連フレームワークへの準拠のための高い規制コストなど）？
Open answer/Please explain and give examples when possible.	自由回答／可能であれば例を挙げて説明してほしい。
Question MARKET 5. Does AI reduce or rather increase bias and discrimination in your use case?	質問 市場業務 5. あなたのユースケースにおいて、AIはバイアスや識別を減らすか、むしろ増やすか？
Please explain and give examples when possible.	可能であれば例を挙げて説明してほしい。
Question MARKET 6. Has general purpose AI opened new possibilities or risks in your use case?	質問 市場業務6. あなたのユースケースにおいて、汎用AIは新たな可能性やリスクをもたらしたか。
•     Yes	・はい
•     No	・いいえ
Please explain and give examples when possible.	可能であれば例を挙げて説明してほしい。
Question MARKET 7. On whom do you rely for the development of your AI solutions?	質問 市場業務 7. AIソリューションの開発を誰に依存しているか？
•     External providers	・外部プロバイダ
•     In-house applications	・社内アプリケーション
•     Partial collaboration with external providers	・外部プロバイダと一部協業している
Please explain and give examples when possible.	可能であれば例を挙げて説明してほしい。
Securities markets (if selected)	証券市場（選択した場合）
In securities markets, possible AI use cases range from risk assessment to trade execution (e.g. algorithmic trading), robo-advice, regulatory compliance and market abuse to customer service. Depending on the specific use cases, relevant legislation would include, for example:	証券市場では、リスクアセスメントから取引執行（アルゴリズム取引など）、ロボアドバイス、規制遵守、市場濫用、顧客サービスまで、さまざまなAIユースケースが考えられる。具体的なユースケースに応じて、関連する法律には例えば以下のようなものがある：
•       Markets in Financial Instruments Directive (MiFID) (for example on trading and robo-advice)	・金融商品市場指令（MiFID）（取引やロボ・アドバイスなど）
•       and Market Abuse Regulation (MAR) (for example for market abuse detection use cases).	・および市場濫用規制（MAR）（市場濫用検知のユースケースなど）が含まれる。
Robo advice: According to the upcoming AI Act, there are specific transparency requirements for AI systems which are not high-risk. The requirements imply that these	ロボアドバイス：来るべきAI法によれば、ハイリスクではないAIシステムには特定の透明性要件がある。この要件は、以下のことを意味する。
AI systems are developed and used in a way that allows making humans aware that they communicate or interact with an AI system. This would for example apply to use cases such as robo-advice or other customer personalised AI applications.	AIシステムは、AIシステムとのコミュニケーションやインタラクションを人間に認識させるような方法で開発・使用される。これは例えば、ロボアドバイスやその他の顧客向けにパーソナライズされたAIアプリケーションのようなユースケースに適用される。
Question SECURITIES 1. For which use case(s) are you using/considering using AI?	質問 証券業務 1. どのようなユースケースでAIを使用／検討しているか？
Open answer. Examples: risk assessment, individual or collective portfolio management, algorithmic trading, robo-advice, sustainable finance, personal finance management, regulatory compliance, customer service, market abuse detection, etc.	自由回答 例：リスクアセスメント、個人または集団のポートフォリオマネジメント、アルゴリズム取引、ロボアドバイス、持続可能な金融、個人金融マネジメント、規制遵守、顧客サービス、市場濫用検知など。
Question SECURITIES 2. What are the opportunities that AI brings to your use case?	質問 証券業務 2. AIがあなたのユースケースにもたらす機会は何か？
Open answer/Please explain and give examples when possible.	自由回答／可能であれば例を挙げて説明してほしい。
Question SECURITIES 3. What are the main challenges and risks that AI brings to your use case (e.g. discrimination, opacity of the AI application developed, difficult to control/supervise it, etc.)?	質問 証券業務 3. あなたのユースケースにおいて、AIがもたらす主な課題やリスクは何か（識別的、開発したAIアプリ ケーションの不透明性、制御・監督の困難性など）？
Open answer/Please explain and give examples when possible.	自由回答／可能であれば例を挙げて説明してほしい。
Question SECURITIES 4. What is the main barrier to developing AI in your use case (e.g. lack of skills and resources, readiness of the technology, high regulatory costs for compliance with the relevant frameworks, etc.)?	質問 証券業務 4. ユースケースにおけるAI開発の主な障壁は何か（スキルやリソースの不足、技術の準備、関連フレームワークへの準拠のための高い規制コストなど）？
Open answer/Please explain and give examples when possible.	自由回答／可能であれば例を挙げて説明してほしい。
Question SECURITIES 5. Can AI reduce bias and discrimination or increase them in your use case?	質問 証券業務 5.あなたのユースケースにおいて、AIはバイアスや識別的差別を減らすことができるか、あるいは増やすことができるか。
•     Yes	・はい
•     No	・いいえ
Please explain and give examples when possible.	可能であれば例を挙げて説明してほしい。
Question SECURITIES 6. Has general purpose AI opened new possibilities or risks in your use case?	質問 証券業務 6. あなたのユースケースにおいて、汎用AIは新たな可能性やリスクをもたらしたか？
•     Yes	・はい
•     No	・いいえ
Please explain and give examples when possible.	可能であれば例を挙げて説明してほしい。
Question SECURITIES 7. On whom do you rely for the development of your AI solutions?	質問 証券業務 7. AIソリューションの開発を誰に依存しているか？
•     External providers	・外部プロバイダ
•     In-house applications	・社内アプリケーション
•     Partial collaboration with external providers	・外部プロバイダとの一部協業
Please explain and give examples when possible.	可能であれば例を挙げて説明してほしい。
Question SECURITIES 8. ‘Herding effects’, where trading is dominated by trading algorithms that make decisions based on similar model calibrations, are often considered as a risk for financial markets. Do you believe that the use of AI has increased this risk?	質問 証券業務 8. 類似のモデル・キャリブレーションに基づいて意思決定を行う取引アルゴリズ ムによって取引が支配される「ハーディング効果」は、しばしば金融市場のリスクと見なされている。AIの利用がこのリスクを高めていると考えるか？
•     Yes	・はい
•     No	・いいえ
Please explain and give examples when possible.	可能であれば例を挙げて説明してほしい。
Question SECURITIES 9. Machine learning trading algorithms can interact with each other in unpredictable ways on the market. Do you see any risks to market integrity and efficiency stemming from these interactions, such as collusion that can amount to market manipulation or sudden bouts of illiquidity where trading algorithms stop trading in response to unusual patterns of market behaviour?	質問 証券業務 9. 機械学習による取引アルゴリズムは、市場において予測不可能な方法で相互作用する可能性がある。このような相互作用から、市場操作に相当するような談合や、市場行動の異常なパターンに反応して取引アルゴリズムが取引を停止するような突然の非流動性の発生など、市場の整合性や効率性に起因するリスクがあると考えるか。
•     Yes	・はい
•     No	・いいえ
Please explain and give examples when possible.	可能であれば例を挙げて説明してほしい。
Question SECURITIES 10. Can robo-advice based on general purpose AI, which can sometimes produce ‘hallucinations’, i.e. nonsensical or inaccurate replies, be made compatible with regulatory requirements applicable to investment advice?	質問 証券業務 10. 時として「幻覚」、すなわち無意味または不正確な回答を生み出す可能性のある汎用 AI に基づくロボアドバイスは、投資助言に適用される規制要件に適合させることができるか。
•     Yes	・はい
•     No	・いいえ
Please explain and give examples when possible.	可能であれば例を挙げて説明してほしい。
Question SECURITIES 11. What precautions will you put in place to ensure robo-advice is developed in compliance with the requirements for investment advice?	質問 証券業務 11. ロボアドバイスが投資助言の要件に準拠して開発されることを保証するために、どのような予防措置を講じるか。
Insurance and pensions (if selected)	保険・年金（選択した場合）
In insurance, possible AI use cases range from insurance pricing and underwriting to advice, compliance, fraud detection/AML and customer service. Depending on the specific use cases, relevant legislation would include	保険では、AIのユースケースとして、保険料設定や保険引受から、アドバイス、コンプライアンス、不正検知／AML、顧客サービスまでが考えられる。具体的なユースケースに応じて、関連する法律には以下が含まれる。
•       the AI Act (for the identified high risk use-cases such as life and health insurance risk assessment and pricing in relation to natural persons)	・AI法（自然人に関する生命保険や医療保険のリスクアセスメントやプライシングなど、識別された高リスクのユースケースの場合）
•       the Insurance Intermediation Directive (IDD) (for example robo-advice),	・保険仲介指令（IDD）（ロボアドバイスなど）、
•       Solvency II and institutions for occupational retirement provisions (IORPs) (for example provisions on risk management in relation to insurance risk assessment),	・ソルベンシーⅡおよび退職給付機構（IORPs）（保険リスクアセスメントに関するリスクマネジメント規定など）、
•       and the Anti-Money Laundering Directive (AMLD) (for example AML use cases).	・およびマネーロンダリング防止指令（AMLD）（AML のユースケースなど）。
Question INSURANCE 1. For which use case(s) are you using/considering using AI?	質問 保険業務 1. どのようなユースケースで AI を使用しているか／使用を検討しているか？
Open answer. Examples: risk management, insurance pricing and underwriting, setting capital requirements/technical provisions, robo-advice, regulatory compliance, sustainable finance, fraud detection, AML, customer service, sales and distribution, claims management, etc.	自由回答 検知例：リスクマネジメント、保険のプライシングとアンダーライティング、資本要件／技術的規定の設定、ロボアドバイス、規制コンプライアンス、持続可能な金融、不正検知、AML、顧客サービス、販売・流通、クレームマネジメントなど。
Question INSURANCE 2. What are the opportunities that AI brings to your use case?	質問 保険業務 2.AIが貴社のユースケースにもたらす機会は何か？
Open answer/Please explain and give examples when possible.	自由回答／可能であれば例を挙げて説明してほしい。
Question INSURANCE 3. What are the main challenges and risks that AI brings to your use case (e.g. discrimination, opacity of the AI application developed, difficult to control/supervise it, etc.)?	質問 保険業務 3. AIがあなたのユースケースにもたらす主な課題とリスクは何か（識別的、開発されたAIアプリケーションの不透明性、制御／監督の困難性など）？
Open answer/Please explain and give examples when possible.	自由回答／可能であれば例を挙げて説明してほしい。
Question INSURANCE 4. What is the main barrier to developing AI in your use case (e.g. lack of skills and resources, readiness of the technology, high regulatory costs for compliance with the relevant frameworks, etc.)?	質問 保険業務 4.あなたのユースケースでAIを開発する際の主な障壁は何か（例：スキルやリソースの不足、技術の準備、関連する枠組みを遵守するための高い規制コストなど）？
Open answer/Please explain and give examples when possible.	自由回答／可能であれば例を挙げて説明してほしい。
Question INSURANCE 5. Does AI reduce or rather increase bias and discrimination in your use case?	質問 保険業務 5.あなたのユースケースにおいて、AIはバイアスや識別を減少させるか、あるいはむしろ増加させるか。
Please explain and give examples when possible.	可能であれば例を挙げて説明してほしい。
Question INSURANCE 6. How can insurers ensure that the outcomes of AI systems are not biased?	質問 保険業務 6. 保険会社は、AI システムの結果がバイアスにならないことをどのように保証できるか。
Open answer/Please explain and give examples when possible.	自由回答／可能であれば例を挙げて説明してほしい。
Question INSURANCE 7. Has general purpose AI opened new possibilities or risks in your use case?	質問 保険業務 7. 貴社のユースケースにおいて、汎用AIは新たな可能性やリスクをもたらしたか？
•     Yes	・はい
•     No	・いいえ
Please explain and give examples when possible.	可能であれば例を挙げて説明してほしい。
Question INSURANCE 8. On whom do you rely for the development of your AI solutions?	質問 保険業務 8. AIソリューションの開発を誰に依存しているか？
•     External providers	・外部プロバイダ
•     In-house applications	・自社アプリケーション
•     Partial collaboration with external providers	・外部プロバイダと一部協業している。
Please explain and give examples when possible.	可能であれば例を挙げて説明してほしい。
Asset management (if selected)	資産管理（選択した場合）
In asset management, possible AI use cases range from risk and portfolio management, robo-advice, regulatory compliance and market abuse to customer service. Depending on the specific use cases, relevant legislation would include, for example:	資産管理では、リスクマネジメント、ポートフォリオマネジメント、ロボアドバイス、規制遵守、市場濫用から顧客サービスまで、さまざまなAIの活用事例が考えられる。具体的なユースケースに応じて、関連する法律には例えば以下のようなものがある：
•       Undertakings for the Collective Investment in Transferable Securities (UCITS)	・譲渡性証券集団投資事業（UCITS：Undertakings for the Collective Investment in Transferable Securities）
•       Alternative Investment Fund Managers Directive (AIFMD)	・オルタナティブ投資ファンド・マネージャー指令（AIFMD）
•       or Markets in Financial Instruments Directive (MiFID)	・または金融商品市場指令（MiFID）
Question ASSET MANAGEMENT 1. For which use case(s) are you using/considering using AI?	質問 資産管理 1. どのようなユースケースでAIを使用／検討しているか？
Open answer. Examples: risk management, individual and collective portfolio management, regulatory compliance, trades monitoring, robo-advice, customer service, sustainable finance, etc.	自由回答 例：リスクマネジメント、個人や集団のポートフォリオ管理、規制遵守、取引モニタリング、ロボアドバイス、顧客サービス、持続可能な金融など。
Question ASSET MANAGEMENT 2. What are the opportunities that AI brings to your use case?	質問 資産管理 2. AIが貴社のユースケースにもたらす機会は何か？
Open answer/Please explain and give examples when possible.	自由回答／可能であれば例を挙げて説明してほしい。
Question ASSET MANAGEMENT 3. What are the main challenges and risks that AI brings to your use case (e.g. discrimination, opacity of the AI application developed, difficult to control/supervise it, etc.)?	質問 資産管理 3. AIがあなたのユースケースにもたらす主な課題とリスクは何か（識別的、開発されたAIアプリケーションの不透明性、制御／監督の困難性など）？
Open answer/Please explain and give examples when possible.	自由回答／可能であれば例を挙げて説明してほしい。
Question ASSET MANAGEMENT 4. What is the main barrier to developing AI in your use case (e.g. lack of skills and resources, readiness of the technology, high regulatory costs for compliance with the relevant frameworks, etc.)?	質問 資産管理 4.あなたのユースケースにおけるAI開発の主な障壁は何か（例：スキルやリソースの不足、技術の準備、関連する枠組みを遵守するための高い規制コストなど）？
Open answer/Please explain and give examples when possible.	自由回答／可能であれば例を挙げて説明してほしい。
Question ASSET MANAGEMENT 5. Does AI reduce or rather increase bias and discrimination in your use case?	質問 資産管理 5.あなたのユースケースにおいて、AIはバイアスや識別を減少させるか、あるいはむしろ増加させるか。
Please explain and give examples when possible.	可能であれば例を挙げて説明してほしい。
Question ASSET MANAGEMENT 6. Has general purpose AI opened new possibilities or risks in your use case?	質問 資産管理 6. あなたのユースケースにおいて、汎用AIは新たな可能性やリスクをもたらしましたか。
•     Yes	・はい
•     No	・いいえ
Please explain and give examples when possible.	可能であれば例を挙げて説明してほしい。
Question ASSET MANAGEMENT 7. On whom do you rely for the development of your AI solutions?	資産管理 7. AIソリューションの開発を誰に依存しているか？
•     External providers	・外部プロバイダ
•     In-house applications	・社内アプリケーション
•     Partial collaboration with external providers	・外部プロバイダとの一部協業
Please explain and give examples when possible.	可能であれば例を挙げて説明してほしい。
Question ASSET MANAGEMENT 8. When delegating functions to third parties, do you check the extent to which the provisions of services will entail the use of AI?	質問 資産管理 8. サードパーティに機能を委託する際、サービスの提供がAIの利用を伴う範囲をチェックしているか。
•     Yes	・はい
•     No	・いいえ
Please explain and give examples when possible.	可能であれば例を挙げて説明してほしい。
Other (if selected)	その他（選択した場合）
Question OTHER 1. For which use case(s) are you using/considering using AI?	質問 その他業務 1.どのようなユースケースでAIの利用を考えているか。
Open answer. Examples: accounting, financial planning, credit rating, etc.	自由回答 例：会計、財務計画、信用格付けなど。
Question OTHER 2. What are the opportunities that AI brings to your use case?	質問 その他業務 2. AIがあなたのユースケースにもたらす機会は何か？
Open answer/Please explain and give examples when possible.	自由回答／可能であれば例を挙げて説明してほしい。
Question OTHER 3. What are the main challenges and risks that AI brings to your use case (e.g. discrimination, opacity of the AI application developed, difficult to control/supervise it, etc.)?	質問 その他業務 3. AIがあなたのユースケースにもたらす主な課題とリスクは何か（識別的、開発されたAIアプリケーションの不透明性、制御／監督が困難など）？
Open answer/Please explain and give examples when possible.	自由回答／可能であれば例を挙げて説明してほしい。
Question OTHER 4. What is the main barrier to developing AI in your use case (e.g. lack of skills and resources, readiness of the technology, high regulatory costs for compliance with the relevant frameworks, etc.)?	質問 その他業務 4.あなたのユースケースにおいて、AIを開発する上での主な障壁は何か（例：スキルやリソースの不足、技術の準備、関連する枠組みを遵守するための高い規制コストなど）？
Open answer/Please explain and give examples when possible.	自由回答／可能であれば例を挙げて説明してほしい。
Question OTHER 5. Does AI reduce or rather increase bias and discrimination in your use case?	質問 その他業務 5. あなたのユースケースにおいて、AIはバイアスや差別を減らすか、むしろ増やすか？
Please explain and give examples when possible.	可能であれば例を挙げて説明してほしい。
Question OTHER 6. Has general purpose AI opened new possibilities or risks in your use case?	質問 その他業務 6. あなたのユースケースにおいて、汎用AIは新たな可能性やリスクをもたらしたか。
•     Yes	・はい
•     No	・いいえ
Please explain and give examples when possible.	可能であれば例を挙げて説明してほしい。
Question OTHER 7. On whom do you rely for the development of your AI solutions?	質問 その他業務 7. AIソリューションの開発を誰に依存しているか？
•     External providers	・外部プロバイダ
•     In-house applications	・社内アプリケーション
•     Partial collaboration with external providers	・外部プロバイダと部分的に協力している
Please explain and give examples when possible.	可能であれば例を挙げて説明してほしい。
Part 3: AI ACT	第3部：AI法
In December 2023 the European Parliament and the Council reached a provisional political agreement on the first comprehensive AI framework, put forward by the Commission on 21 April 2021. The regulation was adopted by the European Parliament on 13 March 2024 and will enter into force later this spring once it has been published in the Official Journal of the EU. This horizontal acquis is applicable across all economic sectors.	2023年12月、欧州議会と欧州理事会は、欧州委員会が2021年4月21日に提案した初の包括的AI枠組みについて暫定的な政治合意に達した。同規則は2024年3月13日に欧州議会で採択され、EU官報に掲載された後、今春以降に発効する。この水平的協定は、すべての経済分野に適用される。
The AI Act defines an AI system as “a machine-based system designed to operate with varying levels of autonomy, that may exhibit adaptiveness after deployment and that, for explicit or implicit objectives, infers, from the input it receives, how to generate outputs such as predictions, content, recommendations, or decisions that can influence physical or virtual environments”. Recital 11 further sets out the reasons for this definition, notably setting out that it is based on key characteristics that distinguish it from simpler traditional software systems of programming approaches.	AI法は、AIシステムを「さまざまなレベルの自律性で動作するように設計された機械ベースのシステムであって、導入後に適応性を示す可能性があり、明示的または暗黙的な目的のために、物理的または仮想的環境に影響を与えることができる予測、コンテンツ、推奨、決定などの出力を生成する方法を、受け取った入力から推測するもの」と定義している。説明11にはさらに、この定義の理由が示されており、特に、より単純な従来のソフトウェア・システムのプログラミング・アプローチとは異なる主要な特徴に基づいていることが明記されている。
The AI Act will establish two high risk use cases for the financial sector:	AI法では、金融セクター向けに2つのリスクの高いユースケースを設定する：
1.     AI systems intended to be used to evaluate the creditworthiness of natural persons or establish their credit score, with the exception of those AI systems used for the purpose of detecting financial fraud	1.     金融詐欺を検知する目的で使用されるAIシステムを除き、自然人の信用度を評価するため、または信用スコアを設定するために使用されることを意図したAIシステム。
2.     AI systems intended to be used for risk assessment and pricing in relation to natural persons in the case of life and health insurance	2.     生命保険および医療保険の場合、自然人に関するリスクアセスメントおよびプライシングに使用されることを意図したAIシステム。
The aim of this section is to identify which are your specific needs in order for the Commission to be able to adequately assist you with appropriate guidance for the implementation of the upcoming AI framework in your specific market areas, especially in particular to the high-risk use cases identified.	このセクションの目的は、欧州委員会が、特に特定されたリスクの高いユースケースについて、今後予定されているAIの枠組みを特定の市場分野で実施するための適切なガイダンスを提供し、適切な支援を行えるようにするために、具体的にどのようなニーズがあるかを特定することである。
3.1. Scope and AI definition	3.1. 範囲とAIの定義
Question 34. Which of the following use cases that could fall into the categorisation of high-risk are potentially relevant to your activity?	質問34. 高リスクに分類される可能性のある以下のユースケースのうち、貴社の活動に関連する可能性のあるものはどれか。
•     AI systems intended to be used to evaluate the creditworthiness of natural persons or establish their credit score.	・自然人の信用度を評価したり、信用スコアを設定したりするために使用することを意図したAIシステム。
•     AI systems intended to be used for risk assessment and pricing in relation to natural persons in the case of life and health insurance.	・生命保険や医療保険の場合、自然人に関するリスクアセスメントやプライシングに使用されることを意図したAIシステム。
•     Both.	・両方
•     None.	・なし。
Question 35. Please explain the overall business and/or risk management process in which the high-risk use case would be integrated and what function exactly the AI would carry out.	質問35. 高リスクのユースケースが統合される全体的なビジネス及び／又はリスクマネジメントプロセスと、AIが具体的にどのような機能を果たすのかについて説明してほしい。
Question 36. Are there any related functions AI would carry out which you would suggest distinguishing from the intended purpose of the high-risk AI systems in particular to the use cases identified in question 34?	質問36．質問34で識別されたユースケースについて、特に高リスクAIシステムの意図された目的から区別することを提案する、AIが実行する関連機能があるか。
Question 37. Please explain why these functions would/should in your view not be covered by the high-risk use cases set out in the AI act either because they would not be covered by the definition of the use case or by relying on one of the conditions under article 6(3) of the AI Act and explaining your assessment accordingly that the AI system would not pose a significant risk of harm if:	質問37. これらの機能が、ユースケースの定義に含まれないため、又はAI法6条3項に基づく条件のいずれかに依拠することにより、AI法に定める高リスクのユースケースに含まれない／含まれるべきであると考える理由を説明し、以下の場合、AIシステムが重大な危害のリスクをもたらさないというあなたのアセスメントを適宜説明してください：
a)     the AI system is intended to perform a narrow procedural task	a） AIシステムが、狭い手続き上のタスクを実行することを意図している。
b)    the AI system is intended to improve the result of a previously completed human activity	b） AIシステムが、以前に完了した人間の活動の結果を改善することを意図している。
c)     the AI system is intended to detect decision-making patterns or deviations from prior decision-making patterns and is not meant to replace or influence the previously completed human assessment, without proper human review	c） AIシステムは、意思決定のパターンや以前の意思決定のパターンからの逸脱を検知することを意図したものであり、人間による適切なレビューなしに、以前に完了した人間のアセスメントに取って代わったり、影響を与えたりすることを意図したものではない。
d)    or the AI system is intended to perform a preparatory task to an assessment relevant for the purpose of the use cases listed in Annex III of the AI Act	d） または、AIシステムが、AI法の附属書IIIに記載されているユースケースの目的に関連するアセスメントの準備作業を行うことを意図している。
Question 38. At this stage, do you have examples of specific AI applications/use cases you believe may fall under any of the conditions from article 6(3) listed above?	質問38. 現段階で、上記の第6条3項の条件のいずれかに該当すると思われる具体的なAIアプリケーション／ユースケースの例をお持ちか。
Please describe the use case(s) in cause and the conditions you believe they may fall under.	具体的なユースケースと、それが該当すると思われる条件を記述してくださ い。
Question 39. Based on the definition of the AI system, as explained above (and in article 3(1) and accompanying recitals), do you find it clear if your system would fall within the scope of the AI Act?	質問39. 上記（及び第3条第1項と付随するリサイタル）で説明したAIシステムの定義に基づき、貴社のシステムがAI法の適用範囲に入るかどうか明らかであると思われるか。
•     Yes	・はい
•     No, it is not clear/ easy to understand if it falls within the scope of the AI Act. If “No”, please specify in relation to what aspects and/or which algorithmic/mathematical models?	・いいえ、AI法の適用範囲に入るかどうか明確でない/理解しにくい。いいえ」の場合、どのような側面および/またはどのアルゴリズム/数学モデルに関してか、具体的に教えてほしい。
3.2. AI Act requirements	3.2. AI法の要件
Question 40. Bearing in mind there will be harmonised standards for the requirements for high-risk AI (Mandates sent to CEN-CENELEC can be monitored here), would you consider helpful further guidance tailored to the financial services sector on specific AI Act requirements, in particular regarding the two high-risk AI use cases?	質問40 高リスクAIの要件については標準化が予定されているが（CEN-CENELECに送られた指令はこちらで確認できる）、特に2つの高リスクAIのユースケースについて、AI法の具体的な要件について、金融サービス部門に合わせたさらなるガイダンスが有用であると考えるか。
•     Yes. If yes, on which specific provisions or requirements and on what aspects concretely?	・はい。「はい」の場合、具体的にどの条項または要件について、またどのような側面についてか。
•     No	・いいえ。
3.3. Financial legislation requirements	3.3. 金融法上の要件
Question 41. Future AI high-risk use cases would also need to comply with existing requirements from the financial legislation. Would you consider helpful further guidance meant to clarify the supervisory expectations for these use cases?	質問41. 今後の AI の高リスクのユースケースは、金融法制の既存の要件にも準拠する必要があ る。このようなユースケースに対する監督当局の期待事項を明確にするために、さらなるガイダンスが有用であると考えるか。
•     If yes, please explain your choice and indicate if the guidance should be highlevel and principles based or tailored to specific use cases.	・「はい」の場合、その選択肢を説明し、ガイダンスがハイレベルで原則に基づくものであるべきか、特定のユースケースに合わせたものであるべきかを示していただきたい。
•     No, the supervisory expectations are clear.	・監督当局の期待は明確である。
Question 42. There are other use cases in relation to the use of AI by the financial services sector which are not considered of high-risk by the AI Act, but which need to comply with the existing requirements from the financial legislation. Would you consider helpful further guidance meant to clarify the supervisory expectations for these use cases?	質問42. 金融サービス部門によるAIの利用に関して、AI法ではハイリスクとはみなされないが、金融法制の既存の要件に準拠する必要がある他のユースケースがある。このようなユースケースに対する監督当局の期待を明確にするための更なるガイダンスが有用であると考えるか。
•     If yes, please explain your response, and indicate if the guidance should be highlevel and principles based or tailored to specific use cases.	・また、そのガイダンスがハイレベルで原則に基づくものであるべきか、特定のユースケースに合わせたものであるべきかを示されたい。
•     No, the supervisory expectations are clear.	・監督当局の期待は明確である。
Question 43. Are you aware of any provisions from the financial acquis that could impede the development of AI applications (e.g. provisions that prohibit the use of risk management models which are not fully explainable or the use of fully automated services for the interaction with consumers)?	質問43. AI アプリケーションの開発を阻害する可能性のある金融規制の規定を知っているか （完全には説明できないリスクマネジメントモデルの使用や、消費者との対話に完全自動化されたサー ビスを使用することを禁止する規定など）。
•     If yes, please indicate the acquis/ provision in cause.	・「はい」の場合、その根拠となる法令・規定を示すこと。
•     No, I am not aware of any provision(s) of this kind	・いいえ、この種の規定を知らない。

^[1] https://www.esma.europa.eu/sites/default/files/library/ESMA50-164-6247-AI_in_securities_markets.pdf  

米国 NIST IR 8505（初期公開ドラフト） クラウドネイティブ・アプリケーションのためのデータ保護アプローチ (2024.06.14)

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

NISTが、IR 8505（初期公開ドラフト） クラウドネイティブ・アプリケーションのためのデータ保護アプローチを公表し、意見募集をしていますね。。。

静止状態でのデータ防御技術（正規表現など）に加えて、サービスやネットワーク・プロトコルを横断して移動するデータを能動的に監視して保護するために、リアルタイムでデータ分析を実行する移動中のデータ分類を開発することが不可欠になっていることから、WebAssembly（WASM）の機能を利用した効果的なデータ保護のための実用的なフレームワークについて　概説しているのが、この文書ということのようです...

● NIST - ITL

・2024.06.14 NIST IR 8505 (Initial Public Draft) A Data Protection Approach for Cloud-Native Applications

NIST IR 8505 (Initial Public Draft) A Data Protection Approach for Cloud-Native Applications	NIST IR 8505（初期公開ドラフト） クラウドネイティブ・アプリケーションのためのデータ保護アプローチ
Announcement	発表
Cloud-native applications, which are generally based on microservices-based application architecture, involve the governance of thousands of services with as many inter-service calls. In this environment, ensuring data security involves more than simply specifying and granting authorization during service requests. It also requires a comprehensive strategy to categorize and analyze data access and leakage as data travels across various protocols (e.g., gRPC, REST-based), especially within ephemeral and scalable microservices implemented as containers.	クラウドネイティブ・アプリケーションは、一般的にマイクロサービス・ベースのアプリケーション・アーキテクチャをベースにしており、何千ものサービスのガバナンスが必要であり、サービス間の呼び出しも多い。このような環境では、データ・セキュリティの確保は、単にサービス・リクエスト時に認可を指定・付与するだけではない。また、特にコンテナとして実装されたエフェメラルでスケーラブルなマイクロサービス内で、データが様々なプロトコル（gRPC、RESTベースなど）を横断する際に、データアクセスと漏えいを分類・分析する包括的な戦略も必要となる。
Hence, in addition to techniques for protecting data at rest (e.g., regular expressions), it has become essential to develop in-transit data categorization that performs real-time data analysis to actively monitor and secure data as it moves across services and network protocols. This IR outlines a practical framework for effective data protection using the capabilities of WebAssembly (WASM) — a platform-agnostic, in-proxy approach with compute and traffic processing capabilities (in-line, network traffic analysis at layers 4–7) that can be built and deployed to execute at native speed in a sandboxed and fault-tolerant manner.	したがって、静止状態でのデータ防御技術（正規表現など）に加えて、サービスやネットワーク・プロトコルを横断して移動するデータを能動的に監視して保護するために、リアルタイムでデータ分析を実行する移動中のデータ分類を開発することが不可欠になっている。このIRでは、WebAssembly（WASM）の機能を利用した効果的なデータ保護のための実用的なフレームワークについて概説する。このフレームワークは、プラットフォームにとらわれないインプロキシアプローチであり、計算機能とトラフィック処理機能（インライン、レイヤー4～7でのネットワークトラフィック分析）を備えている。
Abstract	概要
This document addresses the need for effective data protection strategies in the evolving realm of cloud-native network architectures, including multi-cloud environments, service mesh networks, and hybrid infrastructures. By extending foundational data categorization concepts, it provides a framework for aligning data protection approaches with the unknowns of data in transit. Specifically, it explores service mesh architecture, leveraging and emphasizing the capabilities of WebAssembly (WASM) in ensuring robust data protection as sensitive data is transmitted through east-west and north-south communication paths.	本書は、マルチクラウド環境、サービスメッシュ・ネットワーク、ハイブリッド・インフラなど、進化するクラウドネイティブ・ネットワークアーキテクチャの領域における効果的なデータ保護戦略の必要性に取り組むものである。基本的なデータ分類の概念を拡張することで、転送中のデータの未知数にデータ保護アプローチを整合させるためのフレームワークを提供する。具体的には、WebAssembly（WASM）の機能を活用し、機密データが東西および南北の通信経路を経由して伝送される際に、堅牢なデータ保護を確保するためのサービスメッシュアーキテクチャを探求している。

・[PDF] NIST.IR.8505.ipd

目次...

1. Introduction	1. 序文
1.1. Existing Approaches to Data Protection and Their Limitations	1.1. データ保護に対する既存のアプローチとその限界
1.2. In-Proxy Application for Data Protection	1.2. データ防御のためのインプロキシ・アプリケーション
1.3. Objective and Scope of This Document	1.3. この文書の目的と範囲
1.4. Organization of This Document	1.4. 本文書の構成
2. Web Assembly Background	2. ウェブアセンブリの背景
2.1. Origin	2.1. 起源
2.2. Progression Into Server-Side Environments	2.2. サーバーサイド環境への移行
2.2.1. Development and Deployment Process	2.2.1. 開発と展開のプロセス
2.3. Proxies as WASM Platforms	2.3. WASMプラットフォームとしてのプロキシ
2.4. Proxy-WASM	2.4. Proxy-WASM
2.4.1. Role of WASM in Different Service Mesh Architectures	2.4.1. 異なるサービスメッシュ・アーキテクチャにおけるWASMの役割
2.5. WASI-HTTP	2.5. WASI-HTTP
2.6. eBPF	2.6. eBPF
3. Data Protection in Transit	3. トランジットにおけるデータ防御
3.1. Data Categorization Techniques	3.1. データ分類技術
3.2. Techniques for Data Protection	3.2. データ防御のテクニック
3.2.1. Web Traffic Data Protection	3.2.1. ウェブ・トラフィック・データの防御
3.2.2. API Security	3.2.2. APIセキュリティ
3.2.3. Microsegmentation	3.2.3. マイクロセグメンテーション
3.2.4. Log Traffic Data Protection	3.2.4. ログ・トラフィック・データの防御
3.2.5. LLM Traffic Data Protection	3.2.5. LLMトラフィックデータ防御
3.2.6. Credit Card-Related Data Protection	3.2.6. クレジットカード関連データの防御
3.2.7. Monitoring Tools to Visualize Sensitive Data Flows	3.2.7. 機密データの流れを可視化する監視ツール
4. Security Analysis of WASM Modules	4. WASMモジュールのセキュリティ分析
4.1. WASM Security Goals and Security Feature Sets	4.1. WASMのセキュリティ目標とセキュリティ機能セット
4.1.1. User-Level Security Features	4.1.1. ユーザーレベルのセキュリティ機能
4.1.2. Security Primitives for Developers	4.1.2. 開発者のためのセキュリティ・プリミティブ
4.2. Memory Model and Memory Safety	4.2. メモリ・モデルとメモリ安全性
4.3. Execution Model and Control Flow Integrity	4.3. 実行モデルと制御フローの完全性
4.4. Security of API Access to OS and Host Resources	4.4. OSとホスト・リソースへのAPIアクセスの安全性
4.5. Protection From Side-Channel Attacks	4.5. サイドチャンネル攻撃からの防御
4.6. Protection Against Code Injection and Other Attacks	4.6. コード・インジェクションやその他の攻撃に対する防御
4.7. Deployment and Operating Security	4.7. 配備と運用のセキュリティ
5. Summary and Conclusions	5. まとめと結論
References	参考文献
Appendix A. Execution Model for Web Assembly in Browsers	附属書A. ブラウザにおけるウェブアセンブリの実行モデル
Appendix B. Comparison of Execution Models for Containers and WASM Modules	附属書B. コンテナとWASMモジュールの実行モデルの比較

序文...

1. Introduction	1. 序文
In the constantly evolving landscape of cloud-native application architectures, where data resides in multiple locations (i.e., on-premises and on the cloud), ensuring data security involves more than simply specifying and granting authorization during service requests. It also involves a comprehensive strategy to categorize and analyze data access and leakage as data travels across various protocols (e.g., gRPC, REST-based), especially within ephemeral and scalable microservices applications. As organizations find themselves governing hundreds to tens of thousands of services and the inter-service calls between them, a security void has been identified in observing and protecting sensitive data in transit.	データが複数の場所（すなわち、オンプレミスとクラウド上）に存在するクラウドネイティブ・アプリケーション・アーキテクチャの状況は常に進化しており、データセキュリティの確保には、サービス要求時に単に認可を指定・付与するだけでは不十分である。また、特にエフェメラルでスケーラブルなマイクロサービス・アプリケーション内で、データが様々なプロトコル（gRPC、RESTベースなど）を横断する際に、データ・アクセスと漏えいを分類・分析する包括的な戦略も必要となる。政府は、数百から数万のサービスと、それらの間のサービス間コールをガバナンスしていることに気付くと、転送中の機密データを観察し、保護するセキュリティ上の空白が特定された。
1.1. Existing Approaches to Data Protection and Their Limitations	1.1. データ保護に対する既存のアプローチとその限界
Traditionally, regular expressions (regex) have been widely used for data categorization to identify patterns that match predefined categories or data classes with the aid of keywords and validators for enhanced precision. Despite its wide adoption and usage, the approach has notable limitations. The processing time scales linearly with data volume, making it impractical for very large datasets. Regex also lacks the capability for logical computations, which are necessary for complex validations like checksums in credit card numbers. Its effectiveness heavily relies on the correct proximity to specific keywords, leading to potential false positives and considerable noise if not managed correctly.	従来、正規表現（regex）は、精度を高めるためのキーワードやバリデータの助けを借りて、事前に定義されたカテゴリーやデータクラスに一致するパターンを識別するために、データの分類に広く使用されてきた。広く採用され使用されているにもかかわらず、このアプローチには顕著な限界がある。処理時間はデータ量に比例するため、非常に大きなデータセットでは実用的でない。また正規表現には、クレジットカード番号のチェックサムのような複雑なバリデーションに必要な論理計算の機能がない。その有効性は、特定のキーワードに正しく近接しているかどうかに大きく依存しており、正しく管理されなければ誤検出の可能性やかなりのノイズにつながる。
Machine learning (ML) offers a promising enhancement to data categorization by learning from data patterns and improving over time, thus providing a scalable and adaptable solution. ML algorithms can handle both structured and unstructured data, predict data categories based on historical data, and adjust to new patterns without explicit reprogramming. This adaptability significantly reduces the time and computational resources required to manage complex datasets and is effective for both data at rest and in motion.	機械学習(ML)は、データパターンから学習し、時間の経過とともに改善することで、データ分類に有望な強化を提供する。MLアルゴリズムは、構造化データと非構造化データの両方を扱い、過去のデータに基づいてデータカテゴリーを予測し、明示的な再プログラミングなしに新しいパターンに適応することができる。この適応性は、複雑なデータセットを管理するのに必要な時間と計算資源を大幅に削減し、静止しているデータと動いているデータの両方に有効である。
To address and complement the limitations of traditional data-at-rest inventory, in-transit data categorization has recently come to light as the next logical step in data protection. Unlike the former, which only secures stored information, in-transit categorization actively monitors and secures data as it moves across services and network protocols. This shift to real-time data analysis within the network brings new observability capabilities, eliminating the need for traffic mirroring and data duplication.	従来のデータアットレストのインベントリの限界に対処し、補完するために、データ保護の次の論理的ステップとして、移動中のデータ分類が最近注目されるようになった。保存された情報のみを保護する従来の方法とは異なり、移動中のデータ分類は、サービスやネットワーク・プロトコルを移動するデータを積極的に監視し、保護する。ネットワーク内でのリアルタイム・データ分析への移行は、新たな観測可能性をもたらし、トラフィックのミラーリングやデータの複製を不要にする。
1.2. In-Proxy Application for Data Protection	1.2. データ防御のためのインプロキシ・アプリケーション
To address the need for data categorization during travel across services, a relatively new class of in-proxy application called the WebAssembly program (also called a WASM module) has been increasingly deployed. A WASM module is a lightweight executable compiled to low-level bytecode. This bytecode can be:	サービス間の移動中にデータを分類する必要性に対処するため、WebAssemblyプログラム（WASMモジュールとも呼ばれる）と呼ばれる比較的新しいクラスのインプロキシ・アプリケーションの導入が進んでいる。WASMモジュールは、低レベルのバイトコードにコンパイルされた軽量の実行ファイルである。このバイトコードには次のようなものがある：
(a)   Generated from code written in any language using their associated WebAssembly compilers, including C, C++, and Rust	(a) C、C++、Rustなど、関連するWebAssemblyコンパイラを使って任意の言語で書かれたコードから生成する。
(b)  Run using a WASM runtime in an isolated virtual machine (VM) within the proxy, which allows developers to enhance applications with necessary functionality and run them as efficiently as native code in the proxies.	(b) プロキシ内の分離された仮想マシン（VM）内でWASMランタイムを使用して実行する。これにより、開発者は必要な機能を持つアプリケーションを拡張し、プロキシ内でネイティブコードと同様に効率的に実行することができる。
Over the last few years, the Envoy WASM VM has enabled new types of compute and traffic processing capabilities and allowed for custom WASM modules to be built and deployed in a sandboxed and fault-tolerant manner.	ここ数年で、Envoy WASM VMは新しいタイプのコンピュートとトラフィック処理機能を可能にし、サンドボックス化されたフォールトトレラントな方法でカスタムWASMモジュールを構築してデプロイできるようになった。
Additionally, the following features of WebAssembly modules make them particularly effective for data protection:	さらに、WebAssemblyモジュールの次のような特徴は、データ保護に特に効果的である：
• Data Discovery and Categorization: WASM modules can dynamically identify and categorize data as it traverses the network, ensuring that sensitive information is recognized and handled appropriately.	・データの発見と分類: WASMモジュールは、ネットワーク上を通過するデータを動的に識別・分類し、機密情報が認識され。適切に処理されるようにすることができる。
• Dynamic Data Masking (DDM): WASM modules can apply DDM techniques to redact or mask sensitive information in transit, enhancing privacy and security.	・動的データマスキング(DDM): WASMモジュールはDDM技術を適用して、転送中の機密情報を再編集またはマスクし、プライバシーとセキュリティを強化することができる。
• User and Entity Behavior Analytics (UEBA): WASM modules can analyze user and entity behaviors in real time, detecting anomalies and potential security threats.	・ユーザーと事業体の行動分析(UEBA): WASMモジュールはユーザーや事業体の行動をリアルタイムで分析し、異常や潜在的なセキュリティ脅威を検知することができる。
• Data Loss Prevention (DLP): WASM modules can enforce DLP policies by monitoring and controlling data transfers to prevent unauthorized data exfiltration.	・データ損失防止(DLP): WASMモジュールは、不正なデータ流出を防ぐためにデータ転送を監視・管理することで、DLPポリシーを実施することができる。
1.3. Objective and Scope of This Document	1.3. この文書の目的と範囲
All services (e.g., networking, security, monitoring, etc.) for microservices-based applications are provided by a centralized infrastructure called the service mesh, and the data plane for this service mesh — which performs all runtime tasks — consists of proxies. This document outlines a practical framework for effective data protection and highlights the versatile capabilities of WebAssembly (WASM) within service mesh architectures, multi-cloud environments, and hybrid (i.e., a combination of on-premises and cloud-based) infrastructures. By focusing on inline, network traffic analysis at layers 4–7, organizations can enhance security, streamline operations, and utilize adaptive data protection measures.	マイクロサービスベースのアプリケーションのすべてのサービス（ネットワーキング、セキュリティ、モニタリングなど）は、サービスメッシュと呼ばれる集中型インフラストラクチャによって提供され、このサービスメッシュのデータプレーン（すべてのランタイムタスクを実行する）は、プロキシで構成される。このドキュメントでは、効果的なデータ保護のための実用的なフレームワークの概要を示し、サービスメッシュアーキテクチャ、マルチクラウド環境、ハイブリッド（オンプレミスとクラウドベースの組み合わせ）インフラにおけるWebAssembly（WASM）の多用途な機能を強調する。レイヤー4～7におけるインラインのネットワークトラフィック分析に重点を置くことで、企業はセキュリティを強化し、運用を合理化し、適応的なデータ保護対策を利用することができる。
1.4. Organization of This Document	1.4. 本文書の構成
This document is organized as follows:	本文書の構成は以下の通りである：
• Section 2 describes the execution environment for WASM modules in detail, including the application infrastructure (i.e., service mesh) under which it runs, the specific host environment (i.e., proxies), the process for generating bytecodes and executables, the processes for executing the modules using a WASM runtime, and an API (i.e., WASI) for accessing OS resources of the underlying platform.	・セクション2では、WASMモジュールが実行されるアプリケーション基盤（すなわちサービスメッシュ）、特定のホスト環境（すなわちプロキシ）、バイトコードと実行可能ファイルを生成するプロセス、WASMランタイムを使用してモジュールを実行するプロセス、基盤となるプラットフォームのOSリソースにアクセスするためのAPI（すなわちWASI）など、WASMモジュールの実行環境について詳しく説明する。
• Section 3 introduces the concept of data categorization and the use of various data protection techniques (e.g., data masking, redaction, etc.) to ensure the security of data in different domains or application scenarios using WASM modules, such as web traffic data protection, API Security, microsegmentation, log traffic data protection, LLM traffic data protection, and integration with monitoring tools for the visualization of sensitive data flows.	・セクション3では、データの分類の概念と、ウェブトラフィックデータ保護、APIセキュリティ、マイクロセグメンテーション、ログトラフィックデータ保護、LLMトラフィックデータ保護、機密データフローの可視化のための監視ツールとの統合など、WASMモジュールを使用したさまざまなドメインやアプリケーションシナリオにおけるデータのセキュリティを確保するための、さまざまなデータ保護技術（データマスキング、再編集など）の使用について紹介する。
• Section 4 presents a detailed security analysis of a WASM module by examining its development, deployment, and execution environment to ensure that the module satisfies the properties of a security kernel and can provide the necessary security assurance.	・セクション4では,WASMモジュールがセキュリティカーネルの特性を満たし、必要なセキュリティ保証を提供できることを保証するために、その開発、実装、実行環境を調査することによって、WASMモジュールの詳細なセキュリティ分析を行う。
• Section 5 provides a summary of the topics covered in this document and discusses how WASM module functionality must continuously evolve to provide the security assurance needed to protect against data breaches and exfiltration in the context of increasingly sophisticated attacks on data.	・セクション5では,本文書で取り上げたトピックの概要を示し,データに対する攻撃がますます巧妙化する中で、データ侵害や流出から保護するために必要なセキュリティ保証を提供するために、WASMモジュールの機能がどのように継続的に進化していかなければならないかについて議論する。

図1. WASMモジュールの生成とその実行

図2. WASMモジュールの開発とブラウザでの実行

図3. コンテナとWASMモジュールの実行スタックの比較

米国 NIST TN 2283（初期公開ドラフト）上下水道部門のサイバーセキュリティ： アーキテクチャを構築する 運用技術 リモートアクセス (2024.06.12)

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

NISTが、NIST TN 2283（初期公開ドラフト）上下水道部門のサイバーセキュリティ： アーキテクチャを構築する 運用技術 リモートアクセスを公表し、意見募集をていますね.

上下水道システム（WWS）セクターの事業者に共通するサイバーセキュリティ上の課題を特定し、参照サイバーセキュリティ・アーキテクチャを開発し、リスクを軽減・マネジメントするための既存の市販製品の活用を提案するプロジェクトの一環として、上下水道事業者が自主的に活用できるようなサイバーセキュリティリスクに対処するために市販の技術や既存の標準、ベストプラクティスを作成したものということのようです...

超小規模から小規模（25～3,300 の顧客）、中規模から大規模（3,301～100,000 の顧客）に分類して、それぞれのシステムの複雑さ、予算上の制約、運用上の要件などを想定した上で、適切な技術を使用することができようにしているようです...

● NIST - ITL

・2024.06.12 NIST TN 2283 (Initial Public Draft) Cybersecurity for the Water and Wastewater Sector: Build Architecture. Operational Technology Remote Access

NIST TN 2283 (Initial Public Draft) Cybersecurity for the Water and Wastewater Sector: Build Architecture. Operational Technology Remote Access	NIST TN 2283（初期公開ドラフト）上下水道部門のサイバーセキュリティ： アーキテクチャを構築する 運用技術 リモートアクセス
Announcement	発表
The National Cybersecurity Center of Excellence (NCCoE) has undertaken a project to identify common cybersecurity challenges among Water and Wastewater Systems (WWS) sector participants, develop reference cybersecurity architectures, and propose the utilization of existing commercially available products to mitigate and manage risks. The reference cybersecurity architectures outlined in this report can be voluntarily leveraged by water and wastewater utilities to use commercially available technologies and existing standards and best practices to address their cybersecurity risks.	国立サイバーセキュリティ・センター・オブ・エクセレンス（NCCoE）は、上下水道システム（WWS）セクターの事業者に共通するサイバーセキュリティ上の課題を特定し、参照サイバーセキュリティ・アーキテクチャを開発し、リスクを軽減・マネジメントするための既存の市販製品の活用を提案するプロジェクトを実施した。本報告書に概説されている参照用サイバーセキュリティアーキテクチャは、上下水道事業者が自主的に活用することで、サイバーセキュリティリスクに対処するために市販の技術や既存の標準、ベストプラクティスを利用することができる。
The publication is designed for use by those in the water and wastewater systems sector. The architectures presented in this report for water and wastewater utilities are categorized by system size; specifically, from very small to small (25-3,300 customers) and the medium to large (3,301 – 100,000 customer) size ranges. This categorization allows the use of appropriate technologies based on assumptions of system complexity, budgetary constraint, and operational requirements. This proposed guidance does not offer prescriptive solutions but rather showcases example approaches appropriate within each range of system sizes.	本書は、上下水道システムセクターの事業者が使用することを想定して作成されている。具体的には、超小規模から小規模（25～3,300 の顧客）、中規模から大規模（3,301～100,000 の顧客）に分類されている。この分類により、システムの複雑さ、予算上の制約、運用上の要件などを想定した上で、適切な技術を使用することができる。本ガイダンス案は、規定的な解決策を提供するものではなく、むしろ、各システム規模の範囲内で適切なアプローチ例を紹介するものである。
Abstract	概要
This Technical Note describes the product-agnostic remote access security architectures and the example solutions the NIST National Cybersecurity Center of Excellence (NCCoE) plans to demonstrate as part of the Cybersecurity for the Water and Wastewater Sector: A Practical Reference Design for Mitigating Cyber Risk in Water and Wastewater Systems project. These security architectures were developed in collaboration with technology vendors, water utilities, and other experts. The NCCoE continues to work with these collaborators to develop example solutions that demonstrate how these security architectures can be leveraged to address cybersecurity risks associated with remote access to water and wastewater operational technology systems.	本テクニカルノートでは、NIST国立サイバーセキュリティ・センター・オブ・エクセレンス（NCCoE）が上下水道分野のサイバーセキュリティの一環として実証する予定の、製品にとらわれないリモートアクセスセキュリティアーキテクチャとソリューション例について説明する： A Practical Reference Design for Mitigating Cyber Risk in Water and Wastewater Systems）プロジェクトの一環として実証する予定である。これらのセキュリティ・アーキテクチャは、技術ベンダー、水道事業者、その他の専門家と協力して開発された。NCCoE は、上下水道業務技術システムへのリモート・アクセスに関連するサイバーセキュリティ・リスクに対処するために、これらのセキュリティ・アーキテクチャをどのように活用できるかを示すソリューション例を開発するために、これらの協力者と引き続き協力している。
This Technical Note presents a traditional on-premises remote access architecture and two example solutions, one for medium to large water and wastewater systems (WWS) and one for very small to small water and wastewater systems. A cloud-based remote access architecture and example solution are also described.	本テクニカルノートでは、従来のオンプレミス型リモートアクセスアーキテクチャと、中規模から大規模の上下水道システム（WWS）向けと、ごく小規模から小規模の上下水道システム向けの 2 つのソリューション例を示す。また、クラウドベースのリモートアクセスアーキテクチャとソリューション例についても説明する。

・[PDF] NIST.TN.2283.ipd

目次...

1. Introduction	1. 序文
1.1. Audience	1.1. 想定読者
1.2. Collaborators	1.2. 協力者
1.2.1. Report Organization	1.2.1. 報告組織
2. Remote Access Background	2. リモートアクセスの背景
2.1. Remote Access Technologies in the WWS Sector	2.1. WWS分野におけるリモートアクセス技術
2.2. Medium to Large WW	2.2. 中規模から大規模WW
2.3. Very Small to Small WWs	2.3. 超小型から小型WW
2.4. WWS Characteristics Comparison	2.4. WWSの特徴の比較
2.5. WWS Remote Access Cybersecurity Considerations	2.5. WWS リモートアクセスのサイバーセキュリティに関する考察
3. Traditional Remote Access Architecture	3. 従来のリモートアクセス・アーキテクチャ
3.1. Product-Agnostic Remote Access Architecture	3.1. 製品にとらわれないリモートアクセスのアーキテクチャ
3.2. Medium to Large WWS Remote Access Example Solution	3.2. 中規模から大規模WWSリモートアクセスのソリューション例
3.3. Very Small to Small Remote Access Example Solution	3.3. 超小型～小型リモートアクセス ソリューション例
4. Cloud-Based Remote Access	4. クラウドベースのリモートアクセス
4.1. Product-Agnostic Architecture for Cloud-Based Remote Access	4.1. クラウドベースのリモートアクセスのための製品に依存しないアーキテクチャ
4.1.1. Ed	4.1.1. Ed
4.1.2. Network	4.1.2. ネットワーク
4.1.3. Application	4.1.3. アプリケーション
4.1.4. Security Considerations	4.1.4. セキュリティ
4.2. Cloud-Based Remote Access Example Solution	4.2. クラウドベースのリモートアクセス ソリューション例
5. Summary and Next Steps	5. まとめと次のステップ
References	参考文献
Appendix A. Glossary	附属書 A. 用語集
List of Tables	表一覧
Table 1. Project Collaborators	表1. プロジェクト協力者
Table 2. Size Categories of US Community Water System	表2. 米国の簡易水道の規模カテゴリー
Table 3. WWS Characteristics	表3. WWSの特徴
List of Figures	図一覧
Figure 1. Remote Access Concept	図1. リモートアクセスの概念
Figure 2. Components of a medium to large water system	図2. 中規模から大規模の水道システムの構成要素
Figure 3. Components of a very small to small water system	図3. 超小型から小型の水道システムの構成要素
Figure 4. Traditional Remote Access Architecture	図4. 従来のリモート・アクセス・アーキテクチャ
Figure 5. Remote Access for Medium to Large WWS example solution	図5. 中規模から大規模WWSのためのリモートアクセス ソリューション例
Figure 6. Remote Access for Very Small to Small WWS example solution	図6. 超小型～小型WWS向けリモートアクセス ソリューション例
Figure 7. Cloud-based remote access	図7. クラウドベースのリモートアクセス クラウドベースのリモートアクセス
Figure 8 Cloud-based remote access example solution	図8. クラウドベースのリモートアクセス ソリューション例

序文...

Introduction	序文
As described in the preceding NIST NCCoE publication “Cybersecurity for the Water and Wastewater Sector: A Practical Reference Design for Mitigating Cyber Risk in Water and Wastewater Systems” [1], the NCCoE has undertaken a project to identify common cybersecurity challenges among Water and Wastewater Systems (WWS) sector participants, develop reference cybersecurity architectures, and propose the utilization of existing commercially available products to mitigate and manage risks. The reference cybersecurity architectures outlined in this report can be voluntarily leveraged by water and wastewater utilities to use commercially available technologies and existing standards and best practices to address their cybersecurity risks. Specifically, our work focuses on four areas identified by the United States Cybersecurity and Infrastructure Security Agency (CISA) [2][3] as priority:	先行するNIST NCCoE発行の「上下水道セクターのサイバーセキュリティ」[1]に記載されているように、NCCoEは上下水道システムにおけるサイバーリスク軽減のための実践的なリファレンスデザインを策定するプロジェクトを実施した： A Practical Reference Design for Mitigating Cyber Risk in Water and Wastewater Systems」[1]に記載されているように、NCCoE は上下水道システム（WWS）セクターの参加者に共通するサイバーセキュリティの課題を特定し、参照用サイバーセキュリティアーキテクチャを開発し、リスクを低減・管理するための既存の市販製品の活用を提案するプロジェクトを実施した。本報告書で概説する参照用サイバーセキュリティアーキテクチャは、上下水道事業者が自主的に活用できるものであり、サイバーセキュリティリスクに対処するために市販の技術や既存の標準、ベストプラクティスを利用することができる。具体的には、米国サイバーセキュリティ・インフラセキュリティ庁（CISA）[2][3]が優先事項として特定した 4 つの分野に焦点を当てている：
1. Remote Access – ensure security safeguards are configured to control access based on roles or responsibilities; collect, aggregate, and analyze log information.	1. リモート・アクセス：役割や責任に基づいてアクセスを管理するようにセキュリティ保護措置が設定されていることを確認し、ログ情報を収集、集計、分析する。
2. Network Segmentation – demonstrate open-source products for logical partitions of the operational network, such as firewalls, data diodes, or SDN (software defined networks)	2. ネットワーク・セグメンテーション：ファイアウォール、データ・ダイオード、SDN（ソフトウ ェア定義ネットワーク）など、運用ネットワークの論理パーティション用のオープンソース 製品を実証する。
3. Asset management - discover, identify, categorize, and manage all network-enabled devices: detect potential risks and validate patches and upgrades.	3. 資産マネジメント：すべてのネットワーク対応デバイスを検知、識別、分類、管理する。
4. Data Integrity – protect the integrity of data by detecting lack of protections, provide secure communications, sandboxing techniques, and methods to prevent software modifications.	4. データ・セキュリティ：保護の欠如を検知し、セキュアなコミュニケーション、サンドボックス技術、ソフトウェアの改変を防止する方法を提供することで、データの完全性を保護する。
This first guide addresses the remote access scenario and describes architectures and example solutions allowing authorized access to a water or wastewater utility’s Operational Technology (OT) assets. Subsequent publications will address the other identified risk scenarios and solutions.	この最初のガイドでは、リモートアクセスのシナリオを取り上げ、上下水道事業者の運用技術（OT）資産への認可されたアクセスを可能にするアーキテクチャとソリューション例を説明する。後続の出版物では、その他の識別されたリスクシナリオと解決策を取り上げる予定である。
1.1.  Audience	1.1.  想定読者
The publication is designed for use by those in the water and wastewater systems sector. The architectures presented in this report for water and wastewater utilities are categorized by system size; specifically, from very small to small (25-3,300 customers) and the medium to large (3,301 – 100,000 customer) size ranges. This categorization allows the use of appropriate technologies based on assumptions of system complexity, budgetary constraint, and operational requirements. This proposed guidance does not offer prescriptive solutions but rather showcases example approaches appropriate within each range of system sizes.	本書は、上下水道システム部門関係者の使用を目的としている。具体的には、超小規模から小規模（25～3,300の顧客）、中規模から大規模（3,301～100,000の顧 客）に分類している。この分類により、システムの複雑さ、予算の制約、運営上の必要条件などを前提に、適切な技術を使用することができる。本ガイダンス案は、規定的な解決策を提供するものではなく、各システム規模の範囲内で適切なアプローチ例を紹介するものである。
1.2. Collaborators	1.2. 協力者
The NCCoE has assembled a team of collaborators who provide products and expertise in formulating remote access architectures and building example solutions. Table 1 lists the cybersecurity product vendors, water and wastewater utilities, professional associations, and industry consultants who have volunteered to collaborate on this project.	NCCoE は、リモートアクセスアーキテクチャの策定とソリューション例の構築において、製品 と専門知識を提供する協力者のチームを編成した。表 1 に、このプロジェクトにボランティアで協力してくれたサイバーセキュリティ製品ベンダー、上下水道事業者、専門家団体、業界コンサルタントを示す。
Table 1. Project Collaborators	表 1. プロジェクトの協力者
The NCCoE is using commercial products provided by our collaborators to build secure remote access example solutions. NIST, the NCCoE, and this guide do not endorse these specific products. Your organization should identify and select products that will best integrate with your existing infrastructure. We hope that you will seek products that are congruent with applicable standards and best practices.	NCCoEは、協力者が提供する商用製品を使用して、安全なリモートアクセスのサンプルソリューションを構築している。NIST、NCCoE、および本ガイドは、これらの特定の製品を推奨するものではない。各組織は、既存のインフラストラクチャに最適な製品を特定し、選択する必要がある。適用される標準およびベストプラクティスに合致する製品を求めることを望む。
1.2.1. Report Organization	1.2.1. 報告書の構成
This report contains six sections and two appendices. A brief description of each follows:	本報告書は、6つのセクションと2つの附属書から構成されている。それぞれの簡単な説明は以下の通りである：
• Section 1, this section, provides context for the project scenarios, identifies the report’s intended audience, and lists the project’s collaborator.	・セクション1では,プロジェクトシナリオの背景を説明し,報告書の対象読者を特定し, プロジェクトの協力者を列挙する。
• Section 2 introduces the concept of remote access and provides background on water and wastewater systems for a range of utility sizes.	・セクション2では,リモートアクセスの概念を紹介し,様々な規模の上下水道システムの背景を説明する。
• Section 3 presents a traditional product-agnostic remote access architecture and describes two proposed example solution implementations of this architecture, one for medium to large WWS and one for very small to small WWS.	・第3節では、従来の製品にとらわれないリモートアクセスアーキテクチャを示し、このアーキテクチャの2つのソリューション実装例（1つは中規模から大規模のWWS向け、もう1つは超小規模から小規模のWWS向け）を提案する。
• Section 4 presents a product-agnostic cloud-based Software as a Service (SaaS) architecture for remote access and describes an example solution that is scalable from very small to large WWS.	・セクション4は、リモートアクセスのための製品にとらわれないクラウドベースのSaaS（Software as a Service）アーキテクチャを提示し、非常に小規模なWWSから大規模なWWSまでスケーラブルなソリューション例を説明する。
• Section 5 summarizes this technical note.	・セクション5はこのテクニカルノートの要約である。
• Appendix A is a selected bibliography.	・附属書A：参考文献の一部
• Appendix B provides a glossary of terms.	・附属書B：用語集
Your organization can adopt the remote access solutions presented in this technical note or ones that adhere to the guidelines presented here. Your organization may use this guide as a starting point for tailoring and implementing parts of the reference architecture to provide a remote access solution that best meets your needs.	あなたの組織は、このテクニカルノートで紹介されているリモートアクセス・ソリューションを採用することもできるし、 ここで紹介されているガイドラインに従ったものを採用することもできる。このガイドを出発点として、リファレンスアーキテ クチャの一部をカスタマイズして実装し、ニーズに最適なリモートアクセスソリューションを提供することもできる。

リモートアクセス概念

中規模から大規模の水道システムの構成要素

超小型から小型の水道システムの構成要素

従来のリモート・アクセス・アーキテクチャ

中規模から大規模WWSのためのリモートアクセス ソリューション例

超小型～小型WWS向けリモートアクセス ソリューション例

クラウドベースのリモートアクセス

クラウドベースのリモートアクセス ソリューション例