カナダ 機械学習対応医療機器 (MLMD) の市販前ガイダンス（案） (2023.08.30)

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

カナダが、機械学習対応医療機器 (MLMD) の市販前ガイダンス（案）を公表していますね。。。機械学習対応医療機器（MLMD）のMLに関する部分のガイダンスということで、MDのガイダンスに上乗せする感じですかね。。。

機械学習対応医療機器（MLMD）であっても、他と同じ変更管理計画（PCCP）が適用されるようですね。。。

機械学習対応医療機器（MLMD）
を設計、開発、評価、導入、維持する際には、GMLP（Good Machine Learning Practice）が重要であることには変わりはないようですね。。。

MLMDの申請時に提出する証拠には、製造者がどのように組織内でGMLPを採用し、製品ライフサイクル全体を通じてGMLPを実施したかの説明を含めなくてはならず、該当する場合、この記述は、PCCP変更プロトコルに従うことにより、PCCP変更記述が実現されることを保証するために実施された品質実務の概要を示すことになるようですね。。。

● Canada.ca - Health Canada - Medical devices - Guidance documents

・2023.08.30 Draft guidance: Pre-market guidance for machine learning-enabled medical devices

Good machine learning practice	優れた機械学習の実践
Good machine learning practice (GMLP) is important when designing, developing, evaluating, deploying and maintaining an MLMD. This helps to ensure safe, effective and high-quality medical devices.	適切な機械学習の実施（GMLP）は、MLMDを設計、開発、評価、導入、維持する際に重要である。これは、安全で効果的かつ高品質の医療機器を確保するのに役立つ。
The evidence provided with an application for an MLMD should include a description of how the manufacturer has adopted GMLP within the organization and implemented it throughout the product lifecycle. If applicable, this description should outline the quality practices implemented to ensure that the PCCP change description will be realized by following the PCCP change protocol.	MLMDの申請時に提出するエビデンスには、製造業者がどのように組織内でGMLPを採用し、製品ライフサイクル全体を通じてGMLPを実施したかの説明を含めるべきである。該当する場合、この記述は、PCCP 変更プロトコルに従うことにより、PCCP 変更記述が実現されることを保証するために実施された品質慣行の概要を示すべきである。
Pre-determined change control plan: concept	事前決定変更管理計画：概念
A PCCP is the documentation intended to characterize a device and its bounds, the intended changes to the ML system, the protocol for change management and the change impacts. If included, a PCCP is considered part of the device design.	PCCP は、装置及びその境界、ML システムに対する意図された変更、変更管理のためのプロト コル、及び変更の影響を特徴付けることを意図した文書である。PCCP が含まれる場合、PCCP は装置設計の一部とみなされる。
PCCPs should be risk-based and supported by evidence, take a total product lifecycle perspective and provide a high degree of transparency.	PCCP はリスクベースであり、エビデンスに裏付けられ、製品ライフサイクルの総合的な観 点に立ち、高度な透明性を提供するものでなければならない。
All modifications listed in a PCCP must ensure that the device continues to operate within its intended use. Changes listed in a PCCP should not include changes to the medical conditions, purposes or uses of an MLMD. Such changes require a medical device licence amendment application prior to implementation.	PCCPに記載されるすべての変更は、機器がその意図された用途の範囲内で引き続き動作することを保証するものでなければならない。PCCPに記載される変更には、MLMDの医学的条件、目的または用途の変更を含んではならない。このような変更は、実施前に医療機器許可の変更申請が必要である。
Appropriate changes to list in a PCCP include those where pre-authorization is necessary to address a known risk while upholding the benefits to the patient. An example of such a change would be the maintenance or improvement of performance to address the risk of ML performance degradation over time. This performance degradation can be due to changes to the environment, such as to the input data or the relationship between the input variables and the target variable.	PCCPに記載される適切な変更には、患者にとっての利益を維持しつつ、既知のリスクに対処するために事前承認が必要な変更が含まれる。このような変更の例としては、ML の経時的な性能低下リスクに対処するための性能の保守又は 改善が挙げられる。この性能劣化は、入力データや入力変数とターゲット変数の関係などの環境の変化に起因することがある。
The use of a PCCP allows timely and ongoing management of risks while retaining high regulatory standards to ensure device safety and effectiveness.	PCCPの使用により、装置の安全性と有効性を保証する高い標準を維持しながら、タイムリーで継続的なリスクマネジメントが可能となる。
Sex and gender-based analysis plus	性と性別に基づく分析プラス
Sex and gender-based analysis plus (SGBA Plus or GBA Plus) is an analytical process used to assess how a product or initiative may affect diverse groups of people. This process can be incorporated into the risk management approach used across the lifecycle of the device.	性及び性別に基づく分析プラス（SGBAプラス又はGBAプラス）は、製品又は構想が多様な集団にどのような影響を及ぼすかを評価するために用いられる分析プロセスである。このプロセスは、機器のライフサイクル全体で使用されるリスクマネジメント手法に組み込むことができる。
Evidence demonstrates that biological, economic and social differences between diverse groups of people contribute to differences in health risks and outcomes, their use of health services and how they interact with the health system. Integrating SGBA Plus throughout the lifecycle of a medical device will lead to more equitable health outcomes for Canada's diverse population.	多様な集団間の生物学的、経済的及び社会的差異が、健康リスクと転帰、医療サービスの利用及び医療制度との関わり方の差異に寄与していることを示す証拠がある。医療機器のライフサイクルを通じてSGBAプラスを統合することは、カナダの多様な人々にとって、より公平な健康結果をもたらすことにつながる。
Over the lifecycle of the MLMD, manufacturers should apply SGBA Plus and consider the unique anatomical, physiological and identity characteristics of patients. This includes:	MLMDのライフサイクルを通じて、製造業者はSGBAプラスを適用し、患者固有の解剖学的、生理学的、およびアイデンティティの特徴を考慮すべきである。これには以下が含まれる：
・taking into consideration sex and gender, racial and ethnic minorities, elderly and pediatric populations, and pregnant people	・性別、人種、少数民族、高齢者、小児、妊娠者を考慮すること。
・collecting and analyzing disaggregated data on sub-populations in clinical studies, training data and test data, as appropriate	・臨床試験、トレーニングデータ、試験データにおいて、適宜、小集団に関する細分化されたデータを収集し、分析すること。
Design	デザイン
Indications for use, intended use and contraindications	適応症、使用目的、禁忌
For any Class II, III or IV MLMD, the intended use or medical purpose should be made clear in the application. Provide all relevant information, including the following:	クラスⅡ、Ⅲ又はⅣの MLMD については、申請書において、意図される使用又は医療目的を明 確にすること。以下を含むすべての関連情報を提供すること：
・the intended use and/or indications for use of the MLMD	MLMDの使用目的及び／又は適応症
・the medical purpose (for example, diagnosis, treatment, monitoring) and the intended conditions, diseases or disorders	医療目的（例えば、診断、治療、モニタリング）及び対象となる状態、疾患又は障害
・the intended patient population	想定される患者集団
・the intended user	意図する使用者
・the intended use environment	意図する使用環境
・device function information, as applicable, including:	該当する場合、以下を含む装置機能情報：
・・software inputs	ソフトウェア入力
・・software outputs	ソフトウェア出力
・・an explanation of how the software output fits into the healthcare workflow	ソフトウェア出力が医療ワークフローにどのように適合するかの説明
・・the clinical degree of autonomy	自律性の臨床的程度
・・・the capacity to perform a clinical function with no or limited clinical user intervention	臨床的ユーザーの介入なし、または限定的な介入で臨床機能を実行する能力
・contraindications	禁忌事項
・all known limitations	すべての既知の制限事項
Device description	装置の説明
Provide a detailed description of the MLMD, including any ML systems used to achieve an intended medical purpose. Consider including the following information in the description of the device or software:	意図された医療目的を達成するために使用される ML システムを含め、MLMD の詳細な説明 を記載すること。装置又はソフトウェアの説明には、以下の情報を含めることを考慮すること：
・a statement that the device uses ML, which should also be included in the cover letter	カバーレターにも記載すること。
・if applicable, a confirmation that the MLMD includes a PCCP, which should also be included in the cover letter	該当する場合、MLMD が PCCP を含んでいることの確認。
・a detailed description of the ML methods and ML training algorithms	ML手法とML訓練アルゴリズムの詳細な説明
・・ML methods such as supervised learning, unsupervised learning, semi-supervised learning and reinforcement learning	教師あり学習、教師なし学習、半教師あり学習、強化学習などのML手法。
・・ML training algorithm(s) such as convolutional neural network, logistic regression, language models or support vector machines	畳み込みニューラルネットワーク、ロジスティック回帰、言語モデル、サポートベクターマシンなどのML学習アルゴリズム
・a description of the ML system output, intended users, how the output is intended to be used within the healthcare workflow and the clinical degree of autonomy	MLシステムの出力、想定される利用者、出力が医療ワークフローの中でどのように利用されるか、臨床的な自律性の程度についての説明
・・the capacity to perform a clinical function with no or limited clinical user intervention	ユーザーの介入なしに、あるいは限定的な介入で臨床機能を実行する能力
・an explanation of how the ML system works, the known factors influencing the output and the interpretation of the system behaviour, if available	MLシステムがどのように機能するか、出力に影響を与える既知の要因、及びシステム動作 の解釈についての説明（もしあれば）。
・・for example, feature attributions to ML model predictions, how the outputs of the ML model are impacted by changing input properties, saliency maps	例えば、MLモデルの予測に対する特徴属性、MLモデルの出力が入力特性の変化によってどのような影響を受けるか、顕著性マップなど。
・descriptions of the following:	以下の記述：
・・required device input parameters, input specifications and source(s) of device input(s)	必要な機器入力パラメータ、入力仕様及び機器入力のソース
・・all compatible medical devices, including software and hardware versions	ソフトウェアとハードウェアのバージョンを含む、互換性のあるすべての医療機器
・・hardware requirements (for example, CPU requirements, operating system)	ハードウェア要件（例えば、CPU要件、オペレーティングシステム）。
Predetermined change control plan: content	所定の変更管理計画：内容
A PCCP consists of the following 3 components:	PCCPは以下の3つの要素から構成される：
1. Change description	変更の説明
2. Change protocol	変更プロトコル
3. Impact assessment	影響評価
The detailed PCCP, if applicable to the device, should:	詳細な PCCP は、当該機器に適用される場合、以下のようにすべきである：
・be a standalone section in the submission, typically within either the 'device description' or 'software' section	申請書の独立したセクションであり、通常「デバイスの説明」または「ソフトウ ェア」のいずれかのセクションに含まれる。
・include references to any application information related to the PCCP that's outside of the PCCP section, such as in the labelling or evidence used to demonstrate safety and effectiveness	安全性及び有効性を証明するために使用される添付文書やエビデンスなど、PCCP のセ クション以外の PCCP に関連する申請情報への参照を含むこと。
・consider the information outlined in the following 3 sections	以下の 3 つのセクションに記載された情報を考慮すること。
Change description	変更説明
The change description is the documentation that characterizes the device and the proposed changes. It includes:	変更説明書は、当該機器及び提案された変更を特徴付ける文書である。これには以下が含まれる：
・a description of the initial baseline device design and performance as well as the design and performance envelope or limits over time:	最初のベースラインとなる装置の設計及び性能、並びに設計及び性能の経時的な包絡線又は限界の説明：
・・such as performance specifications and associated performance thresholds, inputs, outputs and relevant technical specifications	例えば、性能仕様及び関連する性能閾値、入力、出力及び関連する技術仕様などである。
・a list of specific changes to the MLMD that are proposed for pre-authorization that would otherwise be significant changes in the absence of an authorized PCCP	事前承認のために提案されるMLMDに対する具体的な変更のうち、承認されたPCCPがない 場合には重大な変更となるもののリスト。
・with each change listed, a detailed description of the following:	リストアップされた各変更について、以下の詳細を記述すること：
・・motivation, rationale or trigger for the planned changes	計画されている変更の動機、根拠またはきっかけ
・・・for example, performance thresholds, scheduled time intervals, user feedback	例えば、性能の閾値、予定された時間間隔、ユーザからのフィードバックなど。
・・cause or source of the changes to the device	装置に対する変更の原因又はソース
・・・for example, re-training with new or appended data	例えば、新しいデータまたは追加データによる再トレーニングなど。
・・effect of the changes on the device	装置に対する変更の影響
・・・for example, modified performance, changes in device inputs or outputs	例えば、性能の変更、装置の入力または出力の変更などである。
・・where the changes apply	変更の適用範囲
・・・for example, uniformly across all marketed devices, non-uniformly across marketed devices based on unique characteristics of a clinical site or patient	例えば、市販されているすべての機器に一律に適用される場合、臨床現場又は患者 の固有の特性に基づいて市販されている機器に一律に適用されない場合などである。
・・who will make the changes	誰が変更を行うか
・・・for example, manufacturer, qualified clinical user, non-clinical user, patient, automatically by the software	例えば、製造者、資格を有する臨床ユーザー、非臨床ユーザー、患者、ソフトウ ェアが自動的に行う。
・・planned frequency of changes	予定される変更の頻度
・・any anticipated modifications to the device description, labelling, user interface	機器の説明、ラベル、ユーザーインターフェースに対する予想される変更
Change protocol	変更プロトコル
The change protocol describes the set of policies and procedures that control how changes, as outlined in the change description, will be implemented and managed. The protocol ensures ongoing safety and effectiveness.	変更手順書には、変更説明書に記載された変更がどのように実施され、管理されるかを 管理する一連の方針と手順が記載されている。プロトコールは、継続的な安全性と有効性を保証する。
Aspects of the change protocol that may need to be part of the licence application include plans for ongoing:	ライセンス申請の一部とする必要のある変更プロトコルの側面には、継続的な計画が含まれる：
・Data management	データ管理
・・may include, for example, plans for collecting, annotating, curating, validating, determining reference standard or ground truth, quality assurance	データ管理には、例えば、収集、注釈付け、管理、検証、参照標準またはグラ ンドトゥルースの決定、品質保証に関する計画などが含まれる。
・Risk management	リスクマネジメント
・・may include, for example, plans for ongoing risk identification, monitoring and response	例えば、継続的なリスクの特定、モニタリング及び対応計画などが含まれる。
・Modification procedures	修正手順
・・may include, for example, plans for re-training, learning techniques, update triggers, pre-update verification and validation methods, such as ML system performance validation and its impact on the performance of the MLMD if applicable	例えば、再トレーニング、学習技術、更新トリガー、ML システム性能検証のような更新前検証及び検証方法、及び該当する場合には MLMD の性能への影響に関する計画を含む。
・Update procedures	更新手順
・・may include, for example, version tracking and control such as traceability, ongoing documentation of the PCCP execution history, deployment plan, end-user communication plan, labelling update plan and user acceptance testing	例えば、トレーサビリティ、PCCP 実行履歴の継続的な文書化、展開計画、エンドユーザコミュニケーショ ン計画、ラベリング更新計画、ユーザ受入テストなどのバージョン追跡及び管理などが含まれる。
・Monitoring	モニタリング
・・may include, for example, plans for post-update testing and performance monitoring, frequency of assessments and triggers for evaluation, statistical analysis plan, plans for device surveillance, complaint handling and reporting incidents	例えば、更新後の試験及び性能モニタリングの計画、評価の頻度及びトリガー、統計 分析計画、機器サーベイランスの計画、苦情ハンドリング及びインシデント報告などが含まれる。
・Corrective actions	是正措置
・・may include, for example, roll-back plans, backup and recovery procedures, retraining criteria and objectives, and customer communications	例えば、ロールバック計画、バックアップと復旧手順、再教育の基準と目標、顧客コミュニケーションなどが含まれる。
Each change in the change description should be clearly traceable to the relevant aspects of the change protocol (for example, through a traceability table).	変更説明の各変更は、変更プロトコルの関連する側面と明確に追跡可能でなければならない（例えば、トレーサビリティ表を通して）。
Impact assessment	影響アセスメント
The impact assessment outlines the potential influence and implications of the changes listed in the PCCP. It should consider:	影響アセスメントでは、PCCP に記載された変更の潜在的な影響と影響について概説する。以下の点を考慮する必要がある：
・the benefits and risks of implementing the PCCP and the risk controls in place	PCCPを実施することによる利益とリスク、および実施されているリスク管理
・how the change protocol will continue to ensure the ongoing safety and effectiveness of the device	変更プロトコルが装置の継続的な安全性と有効性をどのように確保し続けるか。
・the collective impact of all proposed changes on the MLMD and the impacts on other elements of the clinical workflow, including on other medical devices	提案されたすべての変更が MLMD に及ぼす総体的な影響、及び他の医療機器を含む臨床ワー クフローの他の要素に及ぼす影響
Risk management	リスクマネジメント
Manufacturers should conduct the necessary risk management and consider providing descriptions of:	製造業者は必要なリスクマネジメントを実施し、以下の説明をプロバイダに提供すること を検討すべきである：
・the risks identified for the MLMD and the associated risk controls in place to eliminate or reduce those risks	MLMD について識別されたリスクと、それらのリスクを排除又は低減するために実施され ている関連するリスク管理。
・the technique used to perform the initial and ongoing risk assessment and the system used for risk level categorization and acceptability	初期及び継続的なリスクアセスメントの実施に使用された手法、並びにリスクレベルの分類 及び許容範囲に使用されたシステム
・the results of the risk assessment	リスクアセスメントの結果
The following items, as applicable, should be considered in the risk analysis:	該当する場合、以下の項目をリスク分析において考慮すべきである：
・erroneous outputs	誤った出力
・・such as false positive or false negative results, or incorrect information for use in diagnosis or treatment	偽陽性又は偽陰性の結果、あるいは診断又は治療に使用するための不正確な情報な どの誤った出力。
・bias	バイアス
・・note that SGBA Plus analysis may address some sources of unwanted bias	SGBAプラス分析は、望ましくないバイアスのいくつかの原因に対処することができる。
・overfitting	オーバーフィッティング
・・an issue that occurs when a model is fit to properties that are specific to the training examples (for example, random noise), resulting in a model that does not apply to the general problem it's meant to address	学習例（例えば、ランダムノイズ）に特有な特性にモデルを適合させた場合に発生する問題で、その結果、そのモデルが対処しようとする一般的な問題には適用されない。
・underfitting	アンダーフィット
・・an issue that occurs when a model is not fit to all relevant properties of the population from the training examples, resulting in a model that does not apply to the general problem it's meant to address	モデルが、訓練例から得られた母集団のすべての関連する性質に適合していない場合に発生する問題で、その結果、そのモデルが対処しようとする一般的な問題に適用されない。
・degradation of ML system performance	MLシステムの性能低下
・・an issue that can occur due to shifts in population demographics or disease incidence, changes in clinical practice, changes in clinical disease presentation, changes in input format or quality	人口統計や疾患インシデントの変化、臨床診療の変化、疾患の臨床像の変化、入力形式や品質の変化により起こりうる問題である。
・automation bias	自動化バイアス
・・an issue that occurs when a user's conclusion is overly reliant on the device output while ignoring contrary data or conflicting human decisions	ユーザーの結論が装置の出力に過度に依存する一方で、反対データや相反する人間の判断を無視する場合に発生する問題
・alarm fatigue	アラーム疲労
・・an issue that occurs when a user is desensitized to alarms due to excessive exposure, which can result in missed alarms	ユーザーが過剰なエクスポージャーによりアラームに鈍感になり、アラームを見逃す場合に発生する問題である。
・risks associated with using a PCCP	PCCPの使用に伴うリスク
・impacts of a PCCP on risk management	PCCPがリスクマネジメントに与える影響
When performing the risk management for an MLMD, consider referring to the current version of the following resource:	MLMDのリスクマネジメントを行う際には、以下の資料の最新版を参照することを考慮すること：
ISO 14971, Medical devices - Application of risk management to medical devices	ISO14971「医療機器-医療機器へのリスクマネジメントの適用」を参照すること。
Data selection and management	データの選択と管理
When describing the selection and management of data for an MLMD, consider providing the following elements:	MLMD のデータの選択及び管理について記述する場合には、以下の要素をプロバイダとして提 供することを考慮すること：
・descriptions of the training, tuning and test datasets used to develop and evaluate the ML system, such as:	ML システムの開発及び評価に使用されるトレーニング、チューニング及びテストデータセットの 記述：
・・sample sizes with and without the condition, clinical characteristics and demographic statistics	症状の有無、臨床的特徴、人口統計学的統計のサンプル数。
・・a comparison between the prevalence within the dataset and the intended population	データセット内の有病率と対象集団の比較
・・methods and environments in which the data were collected	データを収集した方法と環境
・・data collection devices	データ収集装置
・・single versus multi-centre data, personalized data	単一データか多施設データか、個人データか。
・・justifications to support the dataset characteristics, for example, according to:	データセットの特徴を裏付ける正当な理由：
・・・their relation to the intended use	使用目的との関係
・・・statistical considerations	統計的考察
・・・identity factors (such as sex, gender, race or age)	アイデンティティ要因（性別、人種、年齢など）
・・・consideration of subgroups, such as vulnerable or under-represented populations	脆弱性や代表者不足などのサブグループへの配慮
・data inclusion and exclusion criteria and a justification for removing any data	データの包含基準および除外基準、ならびにデータ削除の正当性
・descriptions of techniques used to address data imbalances (for example, specific sampling methods used to address a dataset that has low disease prevalence) and a justification	データの不均衡に対処するために使用した技術（例えば、疾患の有病率が低いデータセットに対処するために使用した特定のサンプリング方法）の説明とその正当性
・a description of how data integrity was maintained during curation and how data quality and accuracy were ensured, including a description of any data augmentation practices	データ管理中にどのようにデータの完全性が維持され、どのようにデータの質と正確性が 確保されたかの説明（データの補強方法の説明を含む）。
・・for example, geometric transformations intended to enhance the size and quality of datasets	例えば、データセットのサイズと質を向上させるための幾何学的変換などである。
・an explanation of how bias in the dataset was controlled during development	開発中にデータセットのバイアスがどのように制御されたかを説明すること。
Development, training and tuning	開発、トレーニング、チューニング
Consider providing descriptions of the ML development, training and tuning approaches, including the following elements:	MLの開発、トレーニング、チューニングのアプローチについて、以下の要素を含む説明をプロバイダとして提供することを検討する：
・a detailed description of the methods used to develop, train and tune the ML system and a justification to support these methods	MLシステムの開発、訓練、チューニングに使用された手法の詳細な説明と、これらの手法を支持する正当な理由。
・a characterization of the reference standard used in training and tuning, including:	トレーニング及びチューニングに使用される参照標準の特徴：
・・the process and methodology used to define the reference standard	標準を定義するために使用されたプロセスと方法論。
・・a justification to support the chosen reference standard	選択された標準を裏付ける正当な理由。
・・a description of the uncertainty and associated limitations	不確実性と関連する限界の説明
・a description of the inputs and parameters used to develop the ML system and any features extracted from the input data	MLシステムの開発に使用された入力とパラメータ、および入力データから抽出された特徴の説明。
Testing and evaluation	試験と評価
Consider including the following information on ML system performance testing as part of the performance/bench testing or software verification and validation:	性能/ベンチテスト又はソフトウェアの検証及び妥当性確認の一部として、ML システムの性能テス トに関する以下の情報を含めることを検討すること：
・a description of the methods used to test or evaluate the ML system performance	ML システムの性能をテストまたは評価するために使用された方法の説明。
・a characterization of the reference standard used in testing, including:	テストに使用された標準の特徴：
・・the process and methodology used to define the reference standard	標準を定義するために使用されたプロセスと方法論。
・・a justification to support the chosen reference standard	選択された標準を裏付ける正当な理由。・・
・a description of the uncertainty and associated limitations	不確かさと関連する限界の説明
・descriptions of the chosen performance metrics, acceptance criteria and operating point/threshold, with clinical and risk-based justifications	選択された性能測定基準、受入基準及び動作点／閾値の説明と、臨床的及びリスクに基づく 正当化。
・evidence to demonstrate that the ML system performs as intended and meets expected performance requirements when integrated as part of the medical device system or software	医療機器システム又はソフトウェアの一部として統合された場合に、ML システム が意図したとおりに機能し、期待される性能要件を満たすことを示す証拠
・evidence to support the performance of the ML system for appropriate subgroups, including at the relevant intersections, for example according to:	関連する交差点を含む適切なサブグループに対する ML システムの性能を裏付ける証拠：
・・identity factors (such as sex, gender, race, age)	アイデンティティ要因（性別、人種、年齢など）
・・vulnerable populations	脆弱性集団
・・under-represented populations	代表者の少ない集団
・・clinical status (such as diagnosis, stage, grade)	臨床状態（診断、病期、悪性度など）
・・clinical features (such as tissue density, lesion type, co-occurrence of conditions)	臨床的特徴（組織密度、病変のタイプ、病態の併発など）
・evidence to support inter-compatibility with all supported input and output devices	対応するすべての入出力装置との相互互換性を裏付ける証拠
・robustness testing	堅牢性試験
・・for example, intentional testing with unexpected inputs	例えば、予期しない入力を用いた意図的なテストなど
・estimate of the uncertainty of the outputs, with supporting evidence and a justification to support the method used to determine the uncertainty	出力の不確かさの推定値。不確かさを決定するために使用された方法を裏付ける根拠と正当な理由。
・the ML software version that was tested, which should represent the appropriate release version	テストされたMLソフトウェアのバージョン（適切なリリースバージョンを代表するものであること。
・an explanation of the software version numbering system and the identification and traceability of the ML system or model version	ソフトウェアのバージョン番号システムの説明、及びMLシステム又はモデルのバージョンの識別とトレーサビリティ。
Clinical validation	臨床的バリデーション
In a medical device licence application for a Class III or IV MLMD, manufacturers should provide the appropriate clinical evidence, including clinical validation studies, to support the safe and effective clinical use of their device. This information should be available upon request for Class II MLMD.	クラスIIIまたはクラスIVのMLMDの医療機器許可申請において、プロバイダは、機器の安全かつ効果的な臨床使用を裏付けるために、臨床検証試験を含む適切な臨床エビデンスを提供すべきである。この情報は、クラスⅡのMLMDについては、要求に応じて入手可能であるべきである。
For more information on clinical evidence requirements, consult:	臨床エビデンス要件の詳細については、以下を参照のこと：
・Guidance on clinical evidence requirements for medical devices	医療機器の臨床エビデンス要件に関するガイダンス
・Companion document: Examples of clinical evidence requirements for medical devices	付属文書 医療機器の臨床エビデンス要件の例
The clinical evidence should support that the trained, tuned and tested ML system, and the MLMD with that ML system, is safe and effective and performs as intended in the intended population.	臨床エビデンスは、訓練され、調整され、試験された ML システム及びその ML システムを備えた MLMD が、安全かつ有効であり、意図された集団において意図されたとおりに機能することを裏付けるものでなければならない。
Examples of clinical evidence that can be used include:	使用できる臨床エビデンスの例としては、以下が挙げられる：
・clinical validation studies, including descriptions of:	臨床的検証試験（以下の説明を含む：
・・the type of study performed	実施された試験の種類
・・the study design and statistical methods	試験デザインと統計的手法
・・the rationale for the study and methods, including the use of retrospective and/or prospective evaluations	レトロスペクティブ及び／又はプロスペクティブ評価の使用を含む、試験及び方法の 根拠。
・・a characterization of study participants and confirmation that the study population is independent of the data used for ML system development, training and tuning	研究参加者の特徴と、研究集団がMLシステムの開発、トレーニング、チューニングに使用されるデータから独立していることの確認。
・・the rationale for the study population, which may include:	研究集団の根拠（以下を含む）：
・・・the relation to the intended use	使用目的との関係
・・・the representation across sex, gender, race, age and/or other identity factors	性、性別、人種、年齢、及び／又はその他のアイデンティティ要因における代表性。
・・statistical considerations	統計的考察
・・study results	研究結果
・relevant clinical data from published sources	公表された情報源からの関連臨床データ
・device-related investigations	機器関連の調査
・・for example, comparator device clinical data	例えば、比較対象機器の臨床データ
・usability/human factors testing	ユーザビリティ／ヒューマンファクター試験
・device-specific evaluations	機器固有の評価
・real-world evidence (RWE) and post-market clinical experience	リアルワールドエビデンス（RWE）及び市販後の臨床経験
The clinical evidence should accompany a justification to support the level of evidence. This justification should establish that the evidence is sufficient to demonstrate:	臨床エビデンスには、エビデンスレベルを裏付ける正当な理由を添付すること。この正当化は、エビデンスが以下を実証するのに十分であることを立証するものでなければならない：
・the device is safe and effective for the intended population when used as described in the 'intended use' or 'indications for use' statement	使用目的」または「適応症」に記載されたとおりに使用された場合、その医療機器は意図され た集団に対して安全かつ有効である。
・as appropriate, the impacts of the device on different sexes, genders and diverse populations, including racial and ethnic groups, and pediatric and older populations	必要に応じて、異なる性別、ジェンダー、人種・民族集団、小児集団、高齢者集団を含む多様な集団に対す る当該医療機器の影響を示すこと。
Transparency	透明性
Transparency requirements should consider the various stakeholders involved in a patient's healthcare across the lifecycle of the device (for example, patients, users, healthcare providers and regulators).	透明性の要件は、機器のライフサイクルを通じて患者のヘルスケアに関わる様々な利害関係者（例えば、患者、ユーザー、医療プロバイダ、規制当局）を考慮すべきである。
Transparency should be considered throughout the device lifecycle, including in the:	透明性は、以下を含む機器のライフサイクル全体を通じて考慮されるべきである：
・design of the device, including:	以下を含む機器の設計
・・the ML system, software user interface, labelling and, if applicable, the PCCP	MLシステム、ソフトウェアのユーザーインターフェイス、ラベリング及び該当する場合はPCCPを含む。
・medical device licence application	医療機器ライセンス申請
・device marketing	機器の販売
・device use	機器の使用
The following subsection outlines transparency considerations for MLMD labelling for the end-user.	次の小項目では、エンドユーザーに対するMLMDのラベリングに関する透明性への配慮を概説する。
Labelling	ラベリング
Manufacturers should provide copies of the directions for use or instructions for use for the device, including those pertaining to the ML system. Health Canada will review the labels against the requirements outlined in sections 21, 22 and 23 of the regulations.	製造業者は、MLシステムに関連するものを含め、機器の使用説明書又は使用指示書の写しを提供す べきである。カナダ保健省は、規則第 21 条、第 22 条及び第 23 条に概説された要件に照らし合わせてラベルを審査する。
The following ML system information should be considered for inclusion in MLMD labelling, as applicable:	以下のMLシステム情報は、該当する場合、MLMDラベルに含めることを検討すべきである：
indications for use, intended use and contraindications (refer to the section under Design)	適応症、使用目的及び禁忌（設計の項を参照のこと。）
instructions for the user, such as:	次のような使用者に対する指示
・how to use the ML system software to generate an output	出力を生成するためのMLシステムソフトウェアの使用方法
・how to interpret the software interface, including:	ソフトウェアインターフェースの解釈方法：
・・the ML system output and any information provided to help users interpret each output (for example, saliency maps and confidence scores)	MLシステムの出力と、ユーザが各出力を解釈するために提供される情報（例えば、顕著性マップや信頼度スコア）。
・・how to perform calibrations, local validation and ongoing performance monitoring	キャリブレーション、ローカルバリデーション、および継続的な性能モニタリングの実行方法。
・device design information, such as:	以下のような装置設計情報：
・・a statement that the device includes ML	デバイスがMLを含むという声明
・・how the ML system works, for example:	MLシステムがどのように機能するか：
・・・ML approaches	MLのアプローチ
・・・feature attributions to ML model predictions, factors influencing the output, if available	MLモデルの予測に対する特徴、出力に影響を与える要因（もしあれば）。
・・required device input parameters, input specifications and source(s) of device input(s)	必要な装置入力パラメータ、入力仕様、及び装置入力の出所。
・・compatible medical devices, including software and hardware versions	ソフトウェアとハードウェアのバージョンを含む互換性のある医療機器
・・hardware and software requirements (for example, CPU requirements, operating system)	ハードウェアとソフトウェアの要件（CPU要件、オペレーティングシステムなど）
・・dataset characterizations of training and test datasets, such as:	トレーニングデータセットとテストデータセットの特徴：
・・・data collection environment/method	データ収集環境／方法
・・determination of reference standard	参照標準の決定
・・・sample sizes with and without the condition, clinical characteristics, demographic statistics	症状の有無、臨床的特徴、人口統計学的統計のサンプルサイズ
・・・inclusion/exclusion criteria	包含/除外基準
・・PCCP information, if applicable, such as:	該当する場合、以下のようなPCCP情報：
・・・a statement that the device includes a PCCP	当該機器に PCCP が含まれている旨の記述
・・・the intended changes and expected update frequency	意図される変更及び予想される更新頻度
・・・any requirements for the user to perform software updates	ユーザーがソフトウェア更新を実施するための要件
・・・when a software update occurs and how it impacts the device performance, inputs, labelling or use (for example, how to obtain updated labelling or how improved performance will be communicated to them)	ソフトウェアの更新がいつ行われ、それが装置の性能、入力、ラベリング又は使用にど のような影響を与えるか（例えば、更新されたラベリングの入手方法又は性能の向上 がどのようにユーザーに通知されるか）。
・device performance information, such as:	以下のような装置性能情報：
・・chosen performance metrics and acceptance criteria as well as the operating point/threshold	選択された性能測定基準および受入基準、ならびに動作点／閾値
・・detailed results of the performance testing, including results for appropriate subgroups and the performance uncertainty (for example, confidence intervals)	適切なサブグループに対する結果及び性能の不確実性（信頼区間など）を含む性能試験の詳細な結果。
・・summaries of clinical studies, if applicable, including detailed characterization of the study participants, methods and results	臨床試験の概要（該当する場合）：試験参加者、方法、結果の詳細な特徴を含む。
・device limitation information, such as:	以下のような装置の制限情報：
・・data characterization limitations	データ特性の限界
・・limitations in the development techniques	開発技術における限界
・・limitations in the performance evaluation	性能評価における限界
・・known failure modes	既知の故障モード
・・・applicable warnings or cautions related to the ML system	MLシステムに関連する該当する警告や注意事項
Product brochures, websites and marketing material with claims related to the ML system should also be provided, as these are also considered labelling.	製品パンフレット、ウェブサイト、MLシステムに関連する主張を含むマーケティング資料も、表示とみなされるため、プロバイダが提供する必要がある。
Post-market performance monitoring	市販後の性能モニタリング
Manufacturers should consider including a description of the processes, surveillance plans and risk mitigations in place to ensure ongoing performance and inter-compatibility of the ML system.	製造業者は、ML システムの継続的な性能及び相互適合性を確保するために実施されているプ ロセス、監視計画及びリスク軽減策についての説明を含めることを検討すべきである。
This should consider the impact on ML system outputs or clinical workflows that could result from potential changes in the inputs to the ML model, changes to how the ML system outputs are handled by compatible products or any other relevant information. This may be addressed as part of the risk analysis and the PCCP, if applicable.	これは、MLモデルへの入力の潜在的な変更、互換製品によるMLシステム出力の処理方法の変 更、又はその他の関連情報によって生じ得るMLシステム出力又は臨床ワークフローへの影 響を考慮すべきである。これは、該当する場合には、リスク分析及び PCCP の一部として扱われる。
Terms and conditions	諸条件
Terms and conditions (T&Cs) may be imposed on some medical device licences. This can help ensure that the device continues to meet the applicable safety and effectiveness requirements of the regulations after it's been approved.	一部の医療機器ライセンスには使用条件（T＆C）が課されることがある。これは、承認後もその医療機器が規制の適用される安全性と有効性の要件を満たしていることを保証するのに役立つ。
As per section 36(2) of the regulations, the Minister may impose T&Cs requiring:	規則第36条(2)に従い、大臣は以下を要求するT&Cを課すことができる：
・tests to be performed on a device to ensure it continues to meet applicable safety and effectiveness requirements	適用される安全性及び有効性要件を引き続き満たしていることを確認するために機器に対して実施される試験
・submission of the results and protocols of any tests performed	実施された試験の結果とプロトコルの提出
As per subsection 36(3) of the regulations, the Minister may amend T&Cs imposed on a medical device licence to take into account any new development with respect to the device.	規則第36条(3)に従い、大臣は、医療機器に関する新たな開発を考慮するため、医療機器ライセンスに課されるT&Cを修正することができる。
The holder of a medical device shall comply with T&Cs of the licence as per subsection 36(4).	医療機器の保有者は、第 36 項(4)に従い、ライセンスの T&C を遵守しなければならない。
The level of risk, uncertainty and/or complexity of a specific situation will be considered when imposing or amending T&Cs, and when determining requirements for individual T&Cs.	特定の状況のリスク、不確実性及び／又は複雑性のレベルは、T&Cの賦課又は修正、並びに個々のT&Cの要件を決定する際に考慮される。

NIST IR 8472（初期公開ドラフト） 非代替性トークン (NFT) のセキュリティ (2023.08.31)

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

NISTが、非代替性トークン (NFT) のセキュリティをについてのIRのドラフトを公表していますね。。。

うまく社会的に実装すれば、社会的に役立つような技術であっても、初期ユーザが自分の目先の利益に走りすぎてマーケット自体をつぶしてしまっているようなケースもあるのかもしれません。。。

まぁ、でも、普及しないということは、理屈上はそう考えられ得ても、実際の社会的ニーズが高くないのかもしれません（機能＋安全とかの総合判断で...）

● NIST - ITL

・2023.08.31 NIST IR 8472 (Initial Public Draft) Non-Fungible Token Security

NIST IR 8472 (Initial Public Draft) Non-Fungible Token Security	NIST IR 8472（初期公開ドラフト） 非代替性トークンのセキュリティ
Announcement	発表
Non-fungible token (NFT) technology provides a mechanism to sell and exchange both virtual and physical assets on a blockchain. While NFTs are most often used for autographing digital assets (associating one’s name with a digital object), they utilize a strong cryptographic foundation that may enable them to regularly support ownership-transferring sales of digital and physical objects. For this, NFT implementations need to address potential security concerns to reduce the risk to purchasers.	非代替性トークン（NFT）技術は、ブロックチェーン上で仮想資産と物理資産の両方を販売・交換する仕組みを提供する。NFTはデジタル資産の自署（デジタルオブジェクトに自分の名前を関連付けること）に使用されることが最も多いが、強力な暗号基盤を利用することで、デジタルオブジェクトと物理オブジェクトの所有権移転販売を定期的にサポートできる可能性がある。このため、NFTの実装は潜在的なセキュリティ上の懸念に対処し、購入者のリスクを軽減する必要がある。
This publication:	本書
・Describes NFT technology	・NFT技術について説明する。
・Identifies 11 properties that should be provided by most correctly functioning and secured NFT implementations	・正しく機能し、セキュリティが確保されたNFT実装の多くが備えるべき11の機能を識別する。
・Discusses 27 potential security issues	・潜在的なセキュリティ上の課題27 について説明する。
NIST requests feedback on the technical description, the properties for NFT implementations, the security analysis of those properties, and the enumeration of the potential security issues.	NISTは、技術的説明、NFT実装の特性、これらの特性のセキュリティ分析、および潜在的なセキュリティ問題の列挙に関するフィードバックを求めている。
Abstract	概要
Non-fungible token (NFT) technology provides a mechanism to enable real assets (both virtual and physical) to be sold and exchanged on a blockchain. While NFTs are most often used for autographing digital assets (associating one’s name with a digital object), they utilize a strong cryptographic foundation that may enable them to regularly support ownership-transferring sales of digital and physical objects. For this, NFT implementations need to address potential security concerns to reduce the risk to purchasers. This publication explains NFT technology and then identifies and discusses a list of 27 potential security issues. All of the identified issues can be addressed through use of a systematic security approach that promotes a secure design and implementation.	非代替性トークン（NFT）技術は、ブロックチェーン上で実物資産（仮想資産と実物資産の両方）を売買・交換できる仕組みを提供する。NFTは、デジタル資産へのサイン（デジタルオブジェクトに自分の名前を関連付けること）に使用されることが最も多いが、強力な暗号基盤を利用することで、デジタルオブジェクトや物理オブジェクトの所有権移転販売を定期的にサポートできる可能性がある。このため、NFTの実装では潜在的なセキュリティ上の懸念に対処し、購入者のリスクを軽減する必要がある。本書では、NFT 技術を説明した上で、27 の潜在的なセキュリティ問題を特定し、議論する。識別された問題はすべて、安全な設計と実装を促進する体系的なセキュ リティ・アプローチを用いることで対処できる。

・[PDF] NIST.IR.8472.ipd

目次...

1. Introduction	1. 序文
1.1. Scope	1.1. 範囲
2. Background	2. 背景
2.1. Blockchains	2.1. ブロックチェーン
2.2. Smart Contracts	2.2. スマート・コントラクト
2.3. Tokens	2.3. トークン
3. Definition, Properties, and Security Evaluations	3. 定義、特性、セキュリティ評価
3.1. NFT Definition	3.1. NFTの定義
3.2. NFT Properties	3.2. NFTの特性
3.3. Security Evaluation of NFT Properties	3.3. NFT特性の安全性評価
3.3.1. Contract-Provided Properties	3.3.1. 契約プロバイダのプロパティ
3.3.2. Blockchain-Provided Properties	3.3.2. ブロックチェーンが提供するプロパティ
3.3.3. Human Management-Provided Properties	3.3.3. 人的管理が提供するプロパティ
4. List of Potential Security Concerns	4. 潜在的なセキュリティ懸念のリスト
5. Token Standards	5. トークン標準
5.1. ERC-20: Fungible Token Standard	5.1. ERC-20： 代替性トークン標準
5.2. ERC-721: Non-Fungible Token Standard	5.2. ERC-721：非代替性トークン標準
5.3. Other NFT Standards	5.3. その他のNFT標準
6. Marketplaces and Exchanges	6. マーケットプレイスと取引所
7. Conclusion	7. 結論
References	参考文献
Appendix A. List of Symbols, Abbreviations, and Acronyms	附属書A. 記号、略語、頭字語のリスト
Appendix B. Fractional Token Example	附属書B. 分数トークンの例

NFT実装で備えるべき11の機能...

3.2. NFT Properties	3.2. NFTの特性
The following non-exhaustive set of NFT properties can be derived from this definition. Most correctly functioning and secured NFT implementations will contain these properties (see Section 3.3 for caveats to this).	この定義から、以下の非網羅的なNFT特性のセットを導き出すことができる。正しく機能し、安全が確保されたNFTの実装の大半はこれらの特性を含む（この点に関する注意点については第3.3節を参照）。
1. Owned: NFTs designate ownership by recording a blockchain address.	1. 所有： NFTはブロックチェーンアドレスを記録することで所有権を示す。
2. Transferable: Owners and designated approved entities can transfer the ownership of NFTs to other addresses.	2. 譲渡可能： 所有者および指定承認事業体は、NFTの所有権を他のアドレスに譲渡できる。
3. Indivisible: NFTs cannot be subdivided (although the ownership may be fractionalized).	3. 不可分： 分割不可：NFTを分割することはできない（ただし、所有権の端数処理は可能）。
4. Linked: NFTs have references to the asset that they represent.	4. リンクされている： NFTは、それが代表する資産への参照を有する。
5. Recorded: NFTs are smart contract data records stored on a blockchain.	5. 記録：NFTはブロックチェーン上に保存されたスマートコントラクトのデータ記録である。
6. Provenance: NFTs have their chain of ownership recorded.	6. 証明： NFTには所有権の連鎖が記録されている。
7. Permanence: NFTs are normally indestructible (although some are designed to be burned).	7. 永続性： 通常、NFTは破壊不可能である（ただし、焼却を想定したものもある）。
8. Immutable: The asset that an NFT represents cannot be modified.	8. 不変： NFTが表す資産は変更できない。
9. Unique: Each NFT represents a unique asset.	9. 一意である： 各NFTは固有の資産を表す。
10. Authentic: Each NFT asset is what the NFT claims it to be (e.g., artwork from a particular artist).	10. 本人認証： 各NFTの資産は、NFTが主張するとおりのものである（例えば、特定のアーティストの作品）。
11. Authorized: Each NFT asset has been authorized by an owner to be sold as an NFT.	11. 承認されている： 各NFTアセットが、NFTとして販売されることを所有者から承認されていること。

セキュリティ上の27の課題...

4. List of Potential Security Concerns	4. 潜在的セキュリティ懸念のリスト
This section lists 27 potential security concerns that can exist with NFT ownership and smart contract management of tokens. The identified security concerns are organized by NFT property.	本セクションでは、トークンのNFT所有権およびスマートコントラクト管理について、潜在的なセキュリティ上の懸念を27項目挙げている。識別されたセキュリティ上の懸念はNFTのプロパティ別に整理されている。
Owned (Section 3.3.1.1)	所有（セクション3.3.1.1）
1. An NFT purchaser may be deceived into thinking that they are purchasing an asset instead of a smart contract data record that contains a reference to the asset (possibly conferring no rights over the asset at all).	1. NFTの購入者は、アセットへの参照を含むスマートコントラクトのデータレコードではなく、アセットを購入しているかのように騙される可能性がある（アセットに対する権利が全く付与されない可能性もある）。
2. A smart contract may create a token linked to an asset without the legal authority to do so for that asset since, technically, anyone can create an NFT linked to anything.	2. スマートコントラクトはアセットにリンクしたトークンを、そのアセットに関する法的権限なしに作成する可能性がある。
3. If a blockchain account is compromised, the malicious actor can transfer all NFTs associated with that address to an address owned by the actor.	3. ブロックチェーンのアカウントが侵害された場合、悪意のある行為者はそのアドレスに関連するすべてのNFTを行為者が所有するアドレスに転送することができる。
4. Stolen tokens will likely be sold immediately by malicious actors for cryptocurrency, preventing easy restoration of the tokens even if a mechanism is available to do so.	4. 盗まれたトークンは悪意のある行為者によって暗号通貨で即座に売却される可能性が高く、トークンを簡単に復元できる仕組みがあったとしても、それを妨げる。
Transferable (Section 3.3.1.2)	譲渡可能（セクション3.3.1.2）
5. There is likely no smart contract mechanism to restore stolen tokens to their rightful owner.	5. 盗まれたトークンを正当な所有者に復元するスマートコントラクトメカニズムがない可能性が高い。
6. If a smart contract enables the contract manager to restore stolen tokens, this feature could be used by the manager to confiscate, freeze, or unilaterally transfer tokens.	6. スマートコントラクトが、コントラクトマネージャーが盗まれたトークンを復元することを可能にする場合、この機能は、トークンを没収、凍結、または一方的に移転するために、マネージャーによって使用される可能性がある。
7. A smart contract may not allow a manager to restore stolen tokens, but the smart contract may have a manager-controlled update mechanism whereby this feature could be added in the future (enabling the previously mentioned security concern).	7. スマートコントラクトは、管理者が盗まれたトークンを復元することを許可しないかもしれないが、スマートコントラクトは、将来この機能を追加することができる管理者制御の更新メカニズムを持つかもしれない（前述のセキュリティ上の懸念が可能になる）。
8. Coding errors in the smart contract could enable attackers to steal tokens and transfer them to their accounts. Indivisible (Section 3.3.1.3)	8. スマートコントラクトのコーディングミスにより、攻撃者がトークンを盗み、自分のアカウントに送金することが可能になる可能性がある。不可分（セクション3.3.1.3）
9. Fractional ownership increases the NFT attack surface by involving an additional thirdparty smart contract that handles the fractional ownership.	9. 分数所有権には、分数所有権を処理するサードパーティのスマートコントラクトが追加されるため、NFTの攻撃対象が増加する。
10. Owners of fractional shares may not be aware that they could lose their shares through a forced buyout.	10. 端数株式の所有者は、強制的な買い取りによって株式を失う可能性があることに気付かない可能性がある。
Linked (Section 3.3.1.4)	リンクされている（セクション3.3.1.4）
11. Inaccurately stored metadata (either done maliciously or accidentally) can delink an NFT from the asset it represents and make it worthless.	11. 不正確に保存されたメタデータ（悪意によるものであれ、偶発的なものであれ）により、NFTとその代表者である資産とがリンクされ、NFTの価値が失われる可能性がある。
12. Server errors that make a digital asset unavailable (e.g., corrupted file, server failure, or storage service discontinuation) could effectively delink an NFT from the asset it represents and make it worthless.	12. デジタルアセットが利用できなくなるようなサーバーエラー（ファイルの破損、サーバーの故障、スト レージサービスの停止等）は、NFTとそのアセットを効果的にリンクさせ、その価値を失わせる可能性がある。
13. If the off-blockchain table linking NFT identifiers to URLs is compromised, an attacker could delink NFTs from their assets and/or change which NFTs represent which assets.	13. NFT識別子をURLとリンクさせるブロックチェーン外のテーブルが侵害された場合、攻撃者はNFTをアセットから切り離したり、どのNFTがどのアセットを表すかを変更したりすることができる。
14. If off-blockchain tables are used to link NFT identifiers to URLs, the owner of the table could use their access to delink NFTs and/or change which NFTs represent which assets.	14. ブロックチェーン外のテーブルがNFT識別子とURLの紐付けに使用されている場合、テーブルの所有者はそのアクセス権を使用してNFTの紐付けを解除し、及び／又はどのNFTがどの資産を表すかを変更することができる。
Recorded (Section 3.3.2.1)	記録（セクション3.3.2.1）
15. An NFT owner may not realize that their account and information on the NFTs that their account owns are public information on the associated blockchain.	15. NFTの所有者は、自己のアカウント及び自己のアカウントが所有するNFTの情報が関連ブロックチェーン上の公開情報であることに気付かない可能性がある。
16. While blockchain accounts are anonymous, they can be de-anonymized through account owner purchases that include personally identifying information (e.g., name and address).	16. ブロックチェーンのアカウントは匿名であるが、個人を特定できる情報（氏名や住所など）を含むアカウント所有者の購入により、匿名性を解除することができる。
Provenance (Section 3.3.2.2)	証明力（セクション3.3.2.2）
17. A blockchain could undergo an attack enabling changes to blockchain history (this is unlikely with established blockchains). Permanence (Section 3.3.2.3)	17. ブロックチェーンが攻撃を受け、ブロックチェーンの履歴が変更される可能性がある（確立されたブロックチェーンではこの可能性は低い）。永続性（セクション3.3.2.3）
18. An NFT may be burned (accidentally or maliciously) by sending it to an address no one has access to.	18. 誰もアクセスできないアドレスにNFTを送信することで、（偶発的または悪意を持って）NFTが焼失する可能性がある。
19. An NFT smart contract could self-destruct, destroying the managed NFTs. Immutable (Section 3.3.2.4)	19. NFTスマートコントラクトが自己破壊し、管理されたNFTが破壊される可能性がある。不変（セクション3.3.2.4）
20. If the smart contract code contains a vulnerability, the data records could be changed by a malicious actor.	20. スマートコントラクトのコードに脆弱性が含まれている場合、悪意のある行為者によってデータレコードが変更される可能性がある。
21. Blockchains are occasionally changed through participant consensus or have their chains split into distinct and different versions when consensus is not reached on resolving a major issue.	21. ブロックチェーンは参加者のコンセンサスによって変更されたり、重大な問題の解決にコンセンサスが得られない場合にチェーンが別個の異なるバージョンに分割されたりすることがある。
22. A blockchain split will result in the duplication of NFT contracts, which in turn results in NFT owners having the same NFTs on two blockchains. They could sell one and keep the other, causing significant issues for NFTs that convey ownership rights over their linked asset.	22. ブロックチェーンの分裂はNFT契約の重複を招き、その結果、NFT所有者は2つのブロックチェーン上に同じNFTを持つことになる。一方を売却し、もう一方を維持する可能性があり、リンクされた資産に対する所有権を伝えるNFTに重大な問題を引き起こす。
Unique (Section 3.3.3.1)	一意である（セクション3.3.3.1）
23. Buyers may not be aware that an exchange is selling the same NFT multiple times (e.g., permitting a limited number of autographs for video clips).	23. 買い手は、取引所が同じNFTを複数回販売していることに気付かない可能性がある（例：ビデオクリップに限定数のサインを許可する）。
24. The same asset (or copies with unperceivable changes to humans) could be sold simultaneously by multiple NFT exchanges or smart contracts. Authentic (Section 3.3.3.2)	24. 複数のNFT取引所やスマートコントラクトにより、同一のアセット（または人間には知覚できない変更を加えたコピー）が同時に販売される可能性がある。本人認証（3.3.3.2項）
25. An asset linked to an NFT may be a forgery or an authentic original artwork whose origin is misrepresented or attributed to a different creator (e.g., to increase its perceived value).	25. NFTにリンクされたアセットが贋作であったり、（価値を高めるために）出所が偽られたり、別のクリエイターに帰属する本物のオリジナル作品であったりする可能性がある。
Authorized (Section 3.3.3.3)	承認されている （セクション3.3.3.3）
26. The seller may not be authorized to sell an NFT linked to a particular asset.	26. 売主は特定の資産に関連するNFT を販売する権限を有していない場合がある。
27. The buyer may be deceived into not receiving the rights over the linked asset that they think they are obtaining by purchasing an NFT.	27. 買主は、NFT を購入することで得られると思っていたリンク先の資産に関す る権利を得られず、騙される可能性がある。

NIST IR 8481（第一公開ドラフト） 研究のためのサイバーセキュリティ： 調査結果と前進の可能性

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

NISTが、研究開発のセキュリティについてのIRのドラフトを公表していますね。。。CHIPS and Science Act [wikipedia] のSection 10229に基づくものですね。。。

● NIST - ITL

・2023.08.31 Comments | NIST IR 8481, Cybersecurity for Research: Findings and Possible Paths Forward

・2023.08.31 NIST IR 8481 (Initial Public Draft) Cybersecurity for Research: Findings and Possible Paths Forward

NIST IR 8481 (Initial Public Draft) Cybersecurity for Research: Findings and Possible Paths Forward	NIST IR 8481（第一公開ドラフト） 研究のためのサイバーセキュリティ： 調査結果と前進の可能性
Announcement	発表
To support implementation of the research cybersecurity effort detailed in Section 10229  of the CHIPS and Science Act, NIST is leading an initiative to disseminate and make publicly available resources to help qualifying institutions of higher education identify, assess, manage, and reduce cybersecurity risks related to conducting research.	CHIPS and Science Act の Section 10229 に詳述されている研究サイバーセキュリティの取り組みの実施を支援するため、NIST は、認定を受けた高等教育機関が研究を実施する際に関連するサイバーセキュリティリスクを特定、アセスメント、マネジメント、削減するのに役立つリソースを普及し、一般に利用可能にするイニシアティブを主導している。
Informed by community dialogue and an April 2023 Request for Comment, today NIST is publishing this Initial Public Draft of NIST Interagency Report (IR) 8481, Research for Cybersecurity: Findings and Possible Paths Forward.	コミュニティとの対話と2023年4月の意見要求を受けて、NISTは本日、NIST Interagency Report (IR) 8481「サイバーセキュリティのための研究」の初公開ドラフトを公表する： 所見と今後の道筋を示すものである。
Abstract	要旨
Unmanaged cybersecurity risks can wreak havoc on a community. This is no less true for the U.S. scientific research ecosystem, particularly members of the higher education research community, which can be characterized by its fundamentally open, collaborative culture and web of highly decentralized administrative and research environments. Securing the digital resources that contribute to a thriving higher education research enterprise requires consideration of the threats and vulnerabilities relevant to the community as well as unique mission contexts, cultures, and motivations. This resource is intended to enable institutions of higher education to identify, assess, manage, and reduce cybersecurity risks related to conducting research, as described in Section 10229 of the CHIPS and Science Act.	管理されていないサイバーセキュリティリスクは、地域社会に大混乱をもたらす可能性がある。このことは、米国の科学研究エコシステム、特に、基本的にオープンで協力的な文化や、高度に分散化された管理・研究環境の網の目によって特徴づけられる高等教育研究コミュニティのメンバーにとっても同様である。高等教育研究エンタープライズの繁栄に貢献するデジタルリソースを保護するためには、そのコミュニティに関連する脅威と脆弱性、また独自のミッションの背景、文化、動機について考慮する必要がある。本リソースは、高等教育機関が CHIPS および科学法第 10229 条に記載されているように、研究の実施に関連するサイバーセキュリティリスクを識別、アセスメント、マネジメント、削減できるようにすることを目的としている。

・[PDF] NIST.IR.8481.ipd

レビューポイント...

Note to Reviewers	査読者への注意事項
NIST is specifically interested in feedback on the following sections:	NIST は、特に以下のセクションに関するフィードバックを求めている：
• Section 3.1: Cybersecurity Challenges and Risks	・セクション 3.1：セクション3.1：サイバーセキュリティの課題とリスク
Through the findings presented in Section 3.1, NIST hopes to document and drive awareness of the cybersecurity challenges and risks that institutions of higher education face when conducting research, as well as the parallel systemic problems and unique considerations associated with this community that increase the complexity of managing cybersecurity risks. Please provide feedback on the challenges, risks, and summary narrative offered in this document, NIST IR 8481, and alert us to any potential gaps or nuance that may have been missed.	セクション 3.1: サイバーセキュリティ上の課題とリスク NIST は、セクション 3.1 に示された知見を通じて、高等教育機関が研究を実施する際に直面するサイバーセキュリティ上の 課題とリスク、またサイバーセキュリティ上のリスクマネジメントの複雑性を増大させるような、このコミュニティ に関連する並行するシステム上の問題や独自の考慮事項について、文書化し、認識を促すことを期待している。本書（NIST IR 8481）に記載されている課題、リスク、および概要説明に対するフィードバックを提供し、見落とされた可能性のあるギャップやニュアンスについてご指摘いただきたい。
• Section 4: Potential Next Steps for NIST	・セクション 4：NISTの次のステップの可能性
A list of potential next steps for NIST was derived from feedback received through engagement with the research community and higher education cybersecurity community about their cybersecurity challenges, existing resources that they have found helpful, and desired new resources. Section 4 proposes three areas in which NIST could play a role:	研究コミュニティや高等教育サイバーセキュリティコミュニティとの関わりを通じて得られた、サイバーセキュリティに関す る課題、有用であると思われる既存のリソース、および希望する新たなリソースに関するフィードバックから、NIST の次 のステップとなり得るリストを作成した。セクション 4 では、NIST が役割を果たすことができる 3 つの分野を提案している：
1. Community-specific cybersecurity resources	1. コミュニティ固有のサイバーセキュリティリソース
2. Coordination	2. 調整
3. Capacity building	3. 能力構築
Please provide feedback on these areas, noting which would be most impactful.	これらの分野について、どれが最もインパクトがあるか、ご意見をお聞かせいただきたい。
• Appendix A: Existing Cybersecurity Resources	・附属書 A:既存のサイバーセキュリティリソース
NIST IR 8481 is a publicly available document that includes a list of existing cybersecurity resources that can be disseminated and used to help institutions of higher education identify, assess, manage, and reduce cybersecurity risks related to conducting research. The list of resources includes items that are currently available for Research Security Officers, Chief Information Security Officers, cybersecurity teams, and others who are responsible for managing risks related to conducting research.	NIST IR 8481 は、高等教育機関が研究実施に関連するサイバーセキュリティリスクを特定、アセスメント、 マネジメント、低減するために普及・利用できる既存のサイバーセキュリティリソースのリストを含む公 開文書である。リソースのリストには、研究セキュリティ責任者、最高情報セキュリティ責任者、サイバーセキュリティチーム、その他研究実施に関連するリスクマネジメントを担当する者が現在利用可能な項目が含まれている。
Beyond this list of existing cybersecurity resources, NIST is seeking input on:	この既存のサイバーセキュリティリソースのリスト以外にも、NIST は以下の点について意見を求めている：
1. NIST resources on this list that could be tailored for an audience of researchers who do not have a background in cybersecurity	1. このリストにある NIST のリソースのうち、サイバーセキュリティの背景を持たない研究者向けに調整可能なもの。
2. NIST resources on this list that could be adapted to align with the research and education environment	2. 本リストに掲載されている NIST のリソースのうち、研究・教育環境に適合させることが可能なもの。

目次...

1. Introduction and Background	1. 序文と背景
1.1. Purpose	1.1. 目的
1.2. Scope and Audience	1.2. 範囲と読者
2. Approach	2. アプローチ
2.1. Initial Discovery	2.1. 初期検出
2.2. Community Engagement	2.2. コミュニティへの関与
2.3. Feedback Analysis	2.3. フィードバック分析
3. Summary of Feedback	3. フィードバックのまとめ
3.1. Cybersecurity Challenges and Risks	3.1. サイバーセキュリティの課題とリスク
3.2. Current Methods and Resources	3.2. 現在の方法とリソース
3.3. Recommendations for Future Work	3.3. 今後の作業に対する提言
4.Potential Next Steps for NIST	4.NISTの潜在的な次のステップ
Appendix A. Existing Cybersecurity Resources	附属書 A. 既存のサイバーセキュリティリソース
A.1. NIST Resources	A.1. NIST のリソース
A.2. Internal Support Provided by Institutions of Higher Education	A.2. 高等教育機関が提供する内部支援
A.3. Research and Education Community Resources	A.3. 研究・教育コミュニティのリソース
Appendix B. Selected Bibliography	附属書 B. 参考文献

NIST SP 800-204D（初期公開ドラフト）DevSecOps CI/CDパイプラインにソフトウェアサプライチェーンセキュリティを統合するための戦略

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

DevSecOpsとCI/CDの統合...

難しいお題ですね。。。これ、、、、

あとで、ちょっと読んどこ...

● NIST - ITL

プレス...

・2023.08.30 Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines: NIST SP 800-204D ipd Available for Comment

発表...

・2023.08.30 NIST SP 800-204D (Initial Public Draft)　Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD pipelines

NIST SP 800-204D (Initial Public Draft) Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD pipelines	NIST SP 800-204D（初期公開ドラフト）DevSecOps CI/CDパイプラインにソフトウェアサプライチェーンセキュリティを統合するための戦略
Announcement	発表
Cloud-native applications are made up of multiple loosely coupled components called microservices. This class of applications is generally developed through an agile software development life cycle (SDLC) paradigm called DevSecOps, which uses flow processes called continuous integration/continuous delivery (CI/CD) pipelines. Analyses of recent software attacks and vulnerabilities have led both government and private-sector organizations to focus on the activities involved in the entire SDLC. The collection of these activities is called the software supply chain (SSC). The integrity of these individual operations contributes to the overall security of an SSC, and threats can arise from attack vectors unleashed by malicious actors as well as defects introduced when due diligence practices are not followed during the SDLC.	クラウドネイティブアプリケーションは、マイクロサービスと呼ばれる複数の疎結合コンポーネントで構成されている。このクラスのアプリケーションは、一般的にDevSecOpsと呼ばれるアジャイルソフトウェア開発ライフサイクル（SDLC）パラダイムを通じて開発され、継続的インテグレーション/継続的デリバリー（CI/CD）パイプラインと呼ばれるフロープロセスを使用する。最近のソフトウェア攻撃と脆弱性の分析によって、政府と民間の両方の組織が SDLC 全体に関わる活動に注目するようになった。これらの活動の集合体は、ソフトウェアサプライチェーン（SSC）と呼ばれる。これらの個々の作業の完全性は、SSC の全体的なセキュリティに寄与し、脅威は、悪意のある行為者によって放たれた攻撃ベクトルや、SDLC の間にデューディリジェンスの実践が守られなかったときに導入された欠陥から生じる可能性があります。
Executive Order (EO) 14028, NIST’s Secure Software Development Framework (SSDF), other government initiatives, and industry forums have addressed security assurance measures for SSCs to enhance the security of all deployed software. This document focuses on actionable measures to integrate the various building blocks of SSC security assurance into CI/CD pipelines to prepare organizations to address SSC security in the development and deployment of their cloud-native applications.	大統領令（EO）14028、NIST のセキュアソフトウェア開発フレームワーク（SSDF）、他の政府のイニシアティブ、および、業界のフォーラムは、すべての配備されたソフトウェアのセキュリティを強化するために、SSC のセキュリティ保証対策に取り組んできました。この文書では、クラウドネイティブなアプリケーションの開発とデプロイメントにおいてSSCセキュリティに対応するための準備として、SSCセキュリティ保証のさまざまなビルディングブロックをCI/CDパイプラインに統合するための実行可能な対策に焦点を当てる。
Abstract	概要
The predominant application architecture for cloud-native applications consists of multiple microservices with a centralized application infrastructure, such as a service mesh, that provides all application services. This class of applications is generally developed using a flexible and agile software development paradigm called DevSecOps. A salient feature of this paradigm is the use of flow processes called CI/CD pipelines, which initially take the software through various stages (e.g., build, test, package, and deploy) in the form of source code through operations that constitute the software supply chain (SSC). This document outlines strategies for integrating SSC security measures into CI/CD pipelines.	クラウドネイティブアプリケーションの主なアプリケーションアーキテクチャは、複数のマイクロサービスから構成され、すべてのアプリケーションサービスを提供するサービスメッシュのような集中型アプリケーションインフラストラクチャを備えている。このクラスのアプリケーションは一般的に、DevSecOpsと呼ばれる柔軟でアジャイルなソフトウェア開発パラダイムを使用して開発される。このパラダイムの顕著な特徴は、CI/CDパイプラインと呼ばれるフロープロセスを使用することである。このパイプラインは、まず、ソフトウェアサプライチェーン（SSC）を構成するオペレーションを通じて、ソースコードの形で、様々な段階（例えば、ビルド、テスト、パッケージ、デプロイ）を経てソフトウェアを完成させる。この文書では、SSC のセキュリティ対策を CI/CD パイプラインに組み込むための戦略を概説する。

・[PDF] NIST.SP.800-204D.ipd

Executive Summary	要旨
1.  Introduction	1.  序文
1.1.  Purpose	1.1.  目的
1.2.  Scope	1.2.  適用範囲
1.3.  Target Audience	1.3.  対象読者
1.4.  Relationship to Other NIST Documents	1.4.  他のNIST文書との関係
1.5.  Document Structure	1.5.  文書の構造
2.  Software Supply Chain (SSC) — Definition and Model	2.  ソフトウェアサプライチェーン（SSC） - 定義とモデル
2.1.  Definition	2.1.  定義
2.2.  Economics of Security	2.2.  セキュリティの経済学
2.3.  Governance Model	2.3.  ガバナンス・モデル
2.4.  SSC Model	2.4.  SSCモデル
2.4.1. Software Supply Chain Defects	2.4.1. ソフトウェア・サプライチェーンの欠陥
2.4.2. Software Supply Chain Attacks	2.4.2. ソフトウェア・サプライチェーン攻撃
3  SSC Security — Risk Factors and Mitigation Measures	3 SSC セキュリティ - リスク要因と低減対策
3.1.  Risk Factors in an SSC	3.1.  SSC におけるリスク要因
3.1.1. Developer Environment	3.1.1. 開発者の環境
3.1.2. Threat Actors	3.1.2. 脅威行為者
3.1.3. Attack Vectors	3.1.3. 攻撃ベクトル
3.1.4. Attack Targets (Assets)	3.1.4. 攻撃ターゲット（資産）
3.1.5. Types of Exploits	3.1.5. エクスプロイトの種類
3.2.  Mitigation Measures	3.2.  低減対策
3.2.1. Baseline Security	3.2.1. ベースライン・セキュリティ
3.2.2. Controls for Interacting With SCMs	3.2.2. SCMと相互作用するためのコントロール
4.  CI/CD Pipelines — Background, Security Goals, and Entities to be Trusted	4.  CI/CDパイプライン - 背景、セキュリティ目標、信頼されるべき事業体
4.1.  Broad Security Goals for CI/CD Pipelines	4.1.  CI/CDパイプラインの広範なセキュリティ目標
4.2.  Entities That Need Trust in CI/CD Pipelines — Artifacts and Repositories	4.2.  CI/CDパイプラインで信頼が必要な事業体 - アーティファクトとリポジトリ
5.  Integrating SSC Security Into CI/CD Pipelines	5.  SSCのセキュリティをCI/CDパイプラインに組み込む
5.1.  Securing Workflows in CI Pipelines	5.1.  CIパイプラインにおけるワークフローのセキュリティ確保
5.1.1. Secure Build	5.1.1. セキュアビルド
5.1.2. Secure Pull-Push Operations on Repositories	5.1.2. リポジトリに対する安全なプル・プッシュ操作
5.1.3. Integrity of Evidence Generation During Software Updates	5.1.3. ソフトウェア更新時の証拠生成の完全性
5.1.4. Secure Code Commits	5.1.4. 安全なコード・コミット
5.2. Securing Workflows in CD Pipelines	5.2. CDパイプラインにおけるワークフローの保護
5.2.1. Secure CD Pipeline — Case Study (GitOps)	5.2.1. セキュアなCDパイプライン - ケーススタディ（GitOps）
5.3.  SSC Security for CI/CD Pipelines — Implementation Strategy	5.3.  CI/CDパイプラインのSSCセキュリティ - 実装戦略
6.  Summary and Conclusions	6.  まとめと結論
References	参考文献
Appendix A. Mapping of Recommended Security Tasks in CI/CD Pipelines to Recommended High-Level Practices in SSDF	附属書A. CI/CD パイプラインで推奨されるセキュリティタスクと SSDF で推奨される高レベルの実施方法のマッピング
Appendix B. Justification for the Omission of Certain Measures Related to SSDF Practices in This Document	附属書B. この文書では、SSDF の実施方法に関連する一部の対策を省略している。

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

Executive Summary	要旨
Cloud-native applications are made up of multiple loosely couple components called microservices. This class of applications is generally developed through an agile software development life cycle (SDLC) paradigm called DevSecOps, which uses flow processes called Continuous Integration/Continuous Delivery (CI/CD) pipelines.	クラウドネイティブアプリケーションは、マイクロサービスと呼ばれる複数の疎結合コンポーネントで構成されている。このクラスのアプリケーションは、一般に、継続的インテグレーション／継続的デリバリー（CI/CD）パイプラインと呼ばれるフロープロセスを使用する、DevSecOps と呼ばれるアジャイルソフトウェア開発ライフサイクル（SDLC）パラダイムを通じて開発される。
Analyses of recent software attacks and vulnerabilities have led both government and privatesector organizations involved in software development, deployment, and integration to focus on the activities involved in the entire SDLC. These collected activities are called the software supply chain (SSC).	最近のソフトウェア攻撃と脆弱性の分析により、ソフトウェア開発、デプロイメント、統合に関与する政府と民間の両方の組織が、SDLC 全体に関与する活動に注目するようになった。これらの収集された活動は、ソフトウェアサプライチェーン（SSC）と呼ばれる。
The integrity of these individual operations contributes to the overall security of an SSC, and threats can arise from attack vectors unleashed by malicious actors as well as defects introduced when due diligence practices are not followed during SDLC.	これらの個々の作業の完全性は、SSC の全体的なセキュリティに寄与し、脅威は、悪意のある行為者が放つ攻撃ベクトルや、SDLC の間にデューディリジェンスの実践が守られていないときに導入される欠陥から生じる可能性がある。
Executive Order (EO) 14028, NIST’s Secure Software Development Framework (SSDF)[2], other government initiatives, and industry forums have discussed the security of SSC to enhance the security of all deployed software. This document focuses on actionable measures to integrate the various building blocks of SSC security assurance into CI/CD pipelines to prepare organizations to address SSC security in the development and deployment of their cloud-native applications.	大統領令（EO）14028、NIST のセキュアソフトウェア開発フレームワーク（SSDF）[2]、他の政府のイニシアティブ、および業界のフォーラムは、すべての配備されたソフトウェアのセキュリティを強化するために、SSC のセキュリティについて議論してきました。この文書では、クラウドネイティブなアプリケーションの開発とデプロイメントにおいて、組織がSSCセキュリティに対応できるように、SSCセキュリティ保証のさまざまなビルディングブロックをCI/CDパイプラインに統合するための実行可能な対策に焦点を当てる。
Building a robust SSC security edifice requires various artifacts, such as a software bill of materials (SBOM) and frameworks for the attestation of software components. Since the specification of these artifacts, their mandatory constituents, and the requirements that processes using them must satisfy are continually evolving through projects in government organizations and various industry forums, they are beyond the scope of this document.	堅牢な SSC セキュリティ基盤を構築するには、ソフトウェア部品表（SBOM）やソフトウ ェアコンポーネントの認証フレームワークなど、さまざまな成果物が必要である。これらの成果物の仕様、必須構成要素、及びそれらを使用するプロセスが満たすべき要件は、政府組織や様々な業界フォーラムにおけるプロジェクトを通じて継続的に進化しているため、本文書の範囲を超えている。

関連...

2019.08.07	SP800-204	Security Strategies for Microservices-based Application Systems	マイクロサービスベースのアプリケーションシステムのセキュリティ戦略
2020.05.27	SP800-204A	Building Secure Microservices-based Applications Using Service-Mesh Architecture	サービス・メッシュ・アーキテクチャを用いたセキュアなマイクロサービス・ベースのアプリケーションの構築
2021.08.06	SP800-204B	Attribute-based Access Control for Microservices-based Applications using a Service Mesh	サービスメッシュを用いたマイクロサービスベースのアプリケーションのための属性ベースのアクセス制御
2022.03.08	SP800-204C	Implementation of DevSecOps for a Microservices-based Application with Service Mesh	サービスメッシュを用いたマイクロサービスベースのアプリケーションに対するDevSecOpsの実装
2023.08.30	SP800-204D	Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD pipelines	DevSecOps CI/CDパイプラインにおけるソフトウェアサプライチェーンセキュリティの統合戦略

---

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

・2022.03.12 NIST SP 800-204C サービス・メッシュを用いたマイクロサービス・ベースのアプリケーションに対するDevSecOpsの実施

・2021.10.01 NIST SP 800-204C (ドラフト) サービス・メッシュを用いたマイクロサービス・ベースのアプリケーションに対するDevSecOpsの実施

・2021.08.07 NIST SP 800-204B サービスメッシュを用いたマイクロサービスベースのアプリケーションのための属性ベースアクセス制御

・2021.01.29 NIST SP 800-204B (Draft) サービスメッシュを用いたマイクロサービスベースのアプリケーションのための属性ベースアクセス制御

・2020.03.01 NISTに基づくSupply Chain Risk Managementについてのちょっとしたまとめ

中国 国家標準「情報セキュリティ技術：データセキュリティのリスクアセスメント手法」の公開と意見募集 (2023.08.21)

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

情報セキュリティのリスクマネジメント手法については、かつてはGMITS (ISO/IEC TR 13335) というISOから発行されているTRがあったのですが、廃止されていまはなく、情報セキュリティのリスクマネジメントについてのISOとしてISO/IEC 27005:2022 Information security, cybersecurity and privacy protection — Guidance on managing information security risksがあります。

これに近い中国の標準としては、GB/T 20984-2022：信息安全技术 信息安全风险评估方法 (preview)があります。

今回、中国のいわゆるTC260が提案している「情報セキュリティ技術：データセキュリティのリスクアセスメント手法」は、データセキュリティに集中しているように見えますね。。。という意味では、中国独特のもののようですね。。

● 全国信息安全标准化技术委员会

・2023.08.21 关于国家标准《信息安全技术 数据安全风险评估方法》征求意见稿征求意见的通知

標準案

・[PDF] 信息安全技术数据安全风险评估方法

・[DOCX] 仮訳

説明

・[PDF] 信息安全技术 数据安全风险评估方法-编制说明

国家标准《信息安全技术数据安全风险评估方法》（征求意见稿）编制说明	国家標準「情報セキュリティ技術：データセキュリティリスクアセスメント手法」（公開草案） 説明
一、工作简况	I. 概要
1.1 任务来源	1.1 業務所管
根据国家标准化管理委员会2023年下达的国家标准制修订计划，《信息安全技术 数据安全风险评估方法》由中国电子技术标准化研究院负责承办，并联合国家信息技术安全研究中心、国家计算机网络应急技术处理协调中心等单位编制，计划号：20230257-T-469。本标准由全国信息安全标准化技术委员会归口管理。	国家標準化管理委員会が2023年に発布した国家標準作成・改正計画によると、「情報セキュリティ技術データセキュリティリスクアセスメント方法」は中国国家電子技術標準化研究院（CNISET）が請け負い、国家情報技術セキュリティ研究センター（NITSRC）、国家コンピュータネットワーク緊急対応技術処理調整センター（NCCERTH）及びその他の単位が計画番号第20230257-T-469号に基づいて共同で作成する。 本標準は、国家情報セキュリティ標準化専門委員会によって管理される。
1.2 制定背景	1.2 背景
2022年3月6日，全国信息安全标准化技术委员会发布《关于发布2022年度网络安全国家标准需求的通知》（信安秘字〔2022〕47号)，在附件《2022年网络安全国家标准需求清单》中明确了有关需求“支撑《数据安全法》第十八条、第三十条对数据安全风险评估相关规定的落地实施。 ”	2022年3月6日、国家情報セキュリティ標準化技術委員会は、「2022年サイバーセキュリティ要求事項国家標準の公開に関する通知」（新安密言[2022]第47号）を発表し、附属書「2022年サイバーセキュリティ要求事項国家標準一覧」の中で、関連する要求事項として「データセキュリティ法第18条及び第30条のデータセキュリティリスク評価に関する関連規定の実施支援」を明確に定義した。 データセキュリティリスクアセスメントに関連する規定の実施を支援する。"
我国高度重视数据安全工作，先后出台《中华人民共和国数据安全法》《中华人民共和国个人信息保护法》等法律法规。与此同时，数据安全风险和违法违规问题依然严峻，国家数据安全、企业商业秘密和公民个人信息安全防护需求迫切。为了规范数据处理活动，保障数据安全，《数据安全法》明确提出建立数据安全风险评估机制要求。数据安全风险评估，主要针对数据处理者的数据和数据处理活动进行风险评估，旨在掌握数据安全总体状况，发现存在的数据处理不合理、缺少有效的数据安全措施等风险隐患，为进一步健全数据安全管理制度和技术措施，提高数据安全治理能力奠定基础。	中国はデータセキュリティを非常に重視しており、「中華人民共和国データセキュリティ法」や「中華人民共和国個人情報保護法」などの法規を導入している。 その一方で、データセキュリティのリスクや法律違反は依然として深刻であり、国家データセキュリティ、企業の営業秘密、国民の個人情報のセキュリティ保護が急務となっている。 データ処理活動を規制し、データセキュリティーを保護するため、データセキュリティー法はデータセキュリティーリスクアセスメントメカニズムの確立を明確に打ち出している。 データセキュリティリスクアセスメントは、主にデータ処理者のデータとデータ処理活動を対象にリスクアセスメントを実施し、データセキュリティの全体状況を把握し、不合理なデータ処理の存在、効果的なデータセキュリティ対策の欠如などのリスクや隠れた危険を発見し、データセキュリティ管理体制と技術対策をさらに改善し、データセキュリティガバナンス能力を向上させ、基礎を築くことを目的としている。
本标准给出了数据安全风险评估的基本概念、要素关系、分析原理、实施流程、评估内容、分析与评价方法等，明确了数据安全风险评估各阶段的实施要点和工作方法。适用于指导数据处理者、第三方评估机构开展数据安全风险评估，也可供有关主管监管部门实施数据安全检查评估时参考。	本基準は、データセキュリティリスク評価の基本概念、要素関係、分析原則、実施プロセス、評価内容、分析評価方法などを示し、データセキュリティリスク評価の各段階の実施ポイントと作業方法を規定している。 本書はデータ処理者及び第三者評価機関がデータセキュリティリスク評価を実施する際の指導に適しており、関連主管監督機関がデータセキュリティ検査及びアセスメントを実施する際の参考資料としても利用できる。
1.3 起草过程 2022年3月，成立编制工作组，启动标准编制工作，形成标准草案，同步编制研究报告、实施应用方案。	1.3 起草プロセス 2022年3月、準備作業部会が設立され、規格の準備を開始し、規格草案を作成し、調査報告書と実施・適用プログラムを同時に作成した。
2022年4月，在信安标委标准会议周的WG7工作组内进行立项汇报，通过工作组立项投票。	2022年4月、情報セキュリティ標準化委員会の標準化会議の週のWG7作業部会で、作業部会プロジェクト投票を経て、プロジェクト報告書を提出する。
2022年5-10月。组织多次研讨会，起草组先后完成3次标准草案的修改，形成《数据安全风险评估研究报告》、《<信息安全技术 数据安全风险评估方法> 实施应用方案》。	2022年5月～10月 数回のワークショップを開催し、起草グループは3回の規格案の改訂を完了し、データセキュリティリスクアセスメントに関する研究報告書と<情報セキュリティ技術データセキュリティリスクアセスメント手法>の実施と応用プログラムを形成した。
2022年6月，在信安标委标准会议周的WG7工作组内进行立项汇报，通过立项专家评审。	2022年6月、情報セキュリティ標準化委員会の標準化会議の週のWG7作業部会で報告され、プロジェクトの専門家の評価に合格した。
2022年11月2日，信安标委发布标准立项通知，标准获得信安标委立项。	2022年11月2日、情報セキュリティ標準委員会(ISSC)は標準プロジェクト通知を発行し、標準はISSCからプロジェクトを授与された。
2022年11月16日至11月30日，标准公开征集参编单位。	2022年11月16日から11月30日まで、規格は参加ユニットを公募した。
2022年11月-12月，召开编制组会议，对标准草案进行完善。	2022年11月～12月、準備グループ会議を開催し、規格案を改善した。
2022年11月25日，参与国标委标准项目立项答辩，回应了专家质询。	2022年11月25日、国家標準委員会の標準プロジェクトの弁明に参加し、専門家の質問に答えた。
2022年12月6日，在信安标委会议周的WG7工作组对标准工作进展进行了汇报，通过工作组投票，建议将本标准推进至征求意见稿。	2022年12月6日、SINOSEC会議の週のWG7作業部会は、標準作業の進捗状況を報告し、作業部会の投票を通じて、この標準は、コメントのためのドラフトに進めることが推奨された。
2022年12月至2023年2月，针对会议周专家意见，完善标准内容。	2022年12月から2023年2月にかけて、会議週の専門家の意見を受け、規格の内容を改善した。
2023年3月27日，参加秘书处组织的征求意见稿专家审查会，评审专家对标准提出38条意见。	2023年3月27日、事務局主催の暴露ドラフト専門家レビュー会議に参加し、規格のレビュー専門家が38のコメントを提出した。
2023年4月-5月，处理专家意见，完善标准内容。	2023年4月～5月、専門家の意見に対処し、規格の内容を改善する。
2023年6月1日，在信安标委会议周的WG7工作组对标准工作进展进行了汇报，收集42条意见。	2023年6月1日、SGSEC会議の週のWG7ワーキンググループは、標準作業の進捗状況を報告し、42のコメントを収集した。
2023年6月-8月，处理专家意见，完善标准内容。	2023年6月～8月、専門家の意見に対処し、標準の内容を改善する。
二、标准编制原则、主要内容及其确定依据	II. 標準作成の原則、主な内容とその決定根拠である。
2.1 标准编制原则本标准在编制过程中遵循了问题导向原则、协调性原则。	2.1 標準作成の原則 本標準は、作成過程において、問題志向と協調の原則に従う。
2.2 主要内容及其确定依据	2.2 主な内容とその根拠
本标准为支撑《数据安全法》第十八条、第三十条对数据安全风险评估相关规定落实，贯彻《个人信息保护法》《网络数据安全管理条例（征求意见稿）》有关要求，建设数据安全风险评估的协作和统一管理机制，发现国家、重点行业领域和地方区域的数据安全风险，理清数据安全建设方向，针对性提升我国数据安全能力水平。	本標準は、データセキュリティリスクアセスメントに関する「データセキュリティ法」第18条及び第30条の実施を支持し、「個人情報保護法」及び「ネットワークデータセキュリティ管理条例（意見公募案）」の関連要求を実施し、データセキュリティリスクアセスメントのための協調的かつ統一的な管理メカニズムを構築し、国家、主要産業分野及び地方のデータセキュリティリスクを発見し、データセキュリティ構築の方向性を明らかにする。 中国のデータセキュリティ能力レベルの向上を目標とする。
本文件提出了数据安全风险评估的基本概念、要素关系、分析原理、实施流	本書は、データセキュリティリスク評価の基本概念、要素関係、分析原則、実施フロー及びアセスメント内容を提示する。
程、评估内容，明确了数据安全风险评估各阶段的实施要点和工作方法，包括：	本書は、データセキュリティリスク評価の基本概念、要素間の関係、分析原則、実施フロー、アセスメント内容を提示し、データセキュリティリスク評価の各段階の実施ポイントと作業方法を規定する：
1) 评估要素间关系；	1) アセスメント要素間の関係；
2) 风险分析原理；	2) リスク分析の原則；
3) 评估适用情形；	3) 該当状況のアセスメント；
4) 评估实施流程；	4) アセスメントの実施プロセス
5) 评估内容框架；	5) アセスメント内容の枠組み；
6) 评估方法；	6) アセスメントの方法論
7) 数据安全风险评估准备；	7) データセキュリティリスク評価の準備
8) 数据和数据处理活动识别；	8) データ及びデータ処理活動の特定
9) 数据安全风险识别；	9) データセキュリティリスクの特定
10)数据安全风险分析与评价；	10) データセキュリティリスクの分析と評価
11)评估总结；	11) アセスメントの概要
12)数据安全风险评估报告模板。	12) データセキュリティリスクアセスメント報告書のテンプレート
三、 试验验证的分析、综述报告，技术经济论证，预期的经济效益、社会效益和生态效益	III. 試験検証、技術的・経済的正当性、期待される経済的・社会的・生態学的便益の分析と総合 報告書
3.1 试验验证的分析、综述报告将根据下一步标准试点工作开展情况而定。	3.1 試験検証の分析と統合報告書は、標準パイロット事業の次のステップに基づく。
3.2 技术经济论证将根据下一步标准试点工作开展情况而定。	3.2 技術的・経済的妥当性確認は、標準パイロット試験の次のステップに基づく。
3.3 预期的经济效益、社会效益和生态效益	3.3 期待される経済的、社会的、生態学的利益
通过研究提出统一的数据安全风险评估方法，明确数据安全风险评估的实施流程、内容、风险分析原理，给出数据安全风险评价方法和风险处置方法。支撑国家数据安全相关制度、工作，以及数据安全风险评估要求更好地在各行业领域落地，指导数据处理者开展数据安全风险评估工作，提高我国数据安全保护水平。	研究を通じて、統一的なデータセキュリティリスク評価方法を提案し、データセキュリティリスク評価の実施プロセス、内容、リスク分析原則を明確にし、データセキュリティリスク評価方法とリスク処理方法を与える。 国家データセキュリティ関連制度と作業をサポートし、データセキュリティリスク評価要求が各産業分野でよりよく着地できるようにし、データ処理者がデータセキュリティリスク評価作業を実施するよう指導し、中国のデータセキュリティ保護レベルを向上させる。
四、 与国际、国外同类标准技术内容的对比情况，或者与测试的国外样品、样机的有关数据对比情况	IV. 国際及び外国の同類標準の技術内容との比較、または海外のテスト済みサンプル及びプロトタイプの関連データとの比較
当前，国外数据安全和个人信息保护方面的评估认证，主要有数据保护影响评估（DPIA）、受控非密信息安全评估、ISO/IEC 27000系列管理体系认证、信息技术产品安全评估（CC）等。20世纪80年代，美国、加拿大等发达国家就已经开始建立以信息安全风险评估为基础的信息安全风险管理体系，制定了相关标准、评估方法和相关技术。当前尚缺少数据安全风险评估相关的国际标准。，主要在信息安全、产品安全等标准中引入隐私保护要求。	現在、外国のデータセキュリティと個人情報保護のアセスメントと認証は、主にデータ保護影響評価（DPIA）、管理された未分類の情報セキュリティアセスメント、ISO/IEC 27000シリーズの管理システム認証、情報技術製品のセキュリティアセスメント（CC）などである。 情報セキュリティリスク管理システムを構築し、関連規格、アセスメント方法、関連技術を開発した。 現在、データセキュリティリスク評価に関する国際標準は不足している。 また、プライバシー保護要件は主に情報セキュリティ、製品セキュリティ、その他の規格に導入されている。
ISO/IEC 27000信息安全管理体系认证，扩展到隐私信息管理体系认证。目前，信息安全管理体系认证已形成比较成熟的一套体系认证机制，同时随着 ISO/IEC 27000系列信息安全管理标准不断完善，已经出台针对个人信息保护的管理体系标准，例如提出隐私信息管理体系的ISO/IEC 27701《扩展的ISO/IEC 27001和ISO/IEC 27002 隐私信息管理要求和指南》、提出个人信息保护控制措施集合的ISO/IEC 29151《个人可识别信息保护实践指南》、适用于公有云个人信息保护的ISO/IEC 27018《公有云作为个人信息处理者保护可识别个人信息的实践指南》，这些标准也常被用于进行管理体系认证。	ISO/IEC 27000情報セキュリティマネジメントシステム認証は、プライバシー情報マネジメントシステム認証に拡張された。 現在、情報セキュリティマネジメントシステム認証は、システム認証メカニズムの比較的成熟したセットを形成していると同時に、情報セキュリティマネジメント規格のISO / IEC 27000シリーズの継続的な改善に伴い、個人情報管理システム規格の保護のために導入されている、例えば、提案されたプライバシー情報管理システムISO / IEC 27701は、"拡張ISO / IEC 27001およびISO / IEC 27002の要求事項およびガイドライン。27002 プライバシー情報管理のための要求事項及びガイドライン」、個人情報保護のための管理策集を提案するISO/IEC 29151「個人識別情報保護のための実践的ガイドライン」、パブリッククラウドにおける個人情報保護に適用するISO/IEC 27018「個人情報の処理者としてのパブリッククラウドにおける識別可能な個人情報の保護のための実践的ガイドライン」などがあり、これらの規格はマネジメントシステム認証の実施に利用されることが多い。 認証に用いられることが多い。
此外，信息技术产品安全评估正在增加产品的隐私保护功能评估。信息技术产品安全评估（简称CC）按照ISO/IEC15408《信息技术安全评估通用准则》对信息技术产品，尤其是信息安全产品的安全保障级别进行评估。目前CC作为国际常用的产品安全测评方式，已形成一套完整的测评方法论。同时，ISO/IEC 15408系列标准也正在修订，增加了隐私保护等产品安全功能组件，例如CC中涉及数据安全的安全功能组件，主要包括用户数据保护、隐私两大功能组件，其中用户数据保护涉及访问控制、数据鉴别、数据完整性、数据输入、数据机密性、内部传输、信息流控制、数据输出、残余信息保护等，隐私组件，包括匿名化、假名化、不可链接性、不可观测性等。	また、情報技術製品セキュリティアセスメントは、製品のプライバシー保護機能のアセスメントを追加するものである。 情報技術製品セキュリティアセスメント（略してCC）は、ISO/IEC 15408「情報技術セキュリティアセスメントのための一般ガイドライン」に従って、情報技術製品、特に情報セキュリティ製品のセキュリティレベルを評価するものである。 現在、CCは国際的な共通製品セキュリティ評価手法として、完全な評価方法論を形成している。 同時に、ISO/IEC 15408シリーズもプライバシー保護などの製品セキュリティ機能コンポーネントを追加するために改訂されている。 例えば、CCのデータセキュリティに関わるセキュリティ機能コンポーネントには、主にユーザーデータ保護とプライバシーの2つの主要な機能コンポーネントが含まれ、ユーザーデータ保護には、アクセス制御、データ認証、データ完全性、データ入力、データ機密性、内部送信、情報フロー制御が含まれる、 プライバシーの構成要素には、匿名化、仮名化、リンク不可能性、監視不可能性などが含まれる。
五、 以国际标准为基础的起草情况，以及是否合规引用或者采用国际国外标准，并说明未采用国际标准的原因	V. 国際規格に基づく起草、国際規格や外国規格の引用や準拠の有無、国際規格を採用しない理由。
无。	ない。
六、 与有关法律、行政法规及相关标准的关系	VI.関連法規、行政法規、関連基準との関係
本标准与现行法律、法规以及国家标准不存在冲突与矛盾，与其他标准属于配套衔接关系。	本規格と既存の法律、行政法規、国内規格との間に矛盾や抵触はなく、他の規格も支持関係に属する。
法律方面，《中华人民共和国数据安全法》中提出“国家支持有关部门、行业组织、企业、教育和科研机构、有关专业机构等在数据安全风险评估、防范、处置等方面开展协作。”“国家建立集中统一、高效权威的数据安全风险评估、报告、信息共享、监测预警机制。”“重要数据的处理者应当按照规定对其数据处理活动定期开展风险评估，并向有关主管部门报送风险评估报告。”的要求。	法律面では、「中華人民共和国データセキュリティ法」は、"国家は、データセキュリ ティリスクのアセスメント、予防、廃棄の分野において、関連部門、産業組織、企業、教育・ 科学研究機関、関連専門組織間の協力を支援する。"と提案している。 "国は、データ・セキュリティ・リスクの評価、報告、情報共有、監視、早期警戒のための、集中的、統一的、効率的、権威あるメカニズムを確立する。" "重要データの処理者は、規則に従い、データ処理活動のリスクアセスメントを定期的に実施し、リスクアセスメント報告書を関係主管庁に提出する。" の要求事項がある。
国家标准方面，GB/T 20984-2022《信息安全技术 信息安全风险评估方法》	国家標準としては、GB/T 20984-2022「情報セキュリティ技術情報セキュリティリスク評価方法」がある。
给出了信息安全风险评估的框架、流程和实施方法，本标准充分借鉴信息安全风险评估的评估模型、工作流程、评估模式，结合数据和数据处理活动的特点，从管理、数据处理活动、技术等方面，结合核心数据、重要数据、个人信息、一般数据安全特点及保护要求，从监管要求、安全需求等方面识别数据安全风险。GB/T 37988—2019《信息安全技术 数据安全能力成熟度模型》提供了多维度的数据安全能力评估模型和安全要求，GB/T 35273—2020《信息安全技术 个人信息安全规范》提出了个人信息安全保护要求。行业标准方面，JR/T 0223-2021 《金融数据安全 数据生命周期安全规范》给出了金融行业数据安全保护要求。本标准充分借鉴和参考上述标准，且与相关国家标准协调配套。	GB/T20984-2022「情報セキュリティ技術情報セキュリティリスク評価方法」は、情報セキュリティリスク評価の枠組み、プロセス及び実施方法を示し、情報セキュリティリスク評価のアセスメントモデル、ワークフロー及びアセスメント方式を全面的に採用し、管理、データ処理活動、技術などの側面からデータ及びデータ処理活動の特性、コアデータ、重要データ、個人情報及び一般的なデータセキュリティの特性及び保護要求、規制要求、セキュリティニーズなどの側面を組み合わせている。 GB/T 37988-2019「情報セキュリティ技術データセキュリティ能力成熟度モデル」は多次元データセキュリティ能力アセスメントモデルとセキュリティ要求事項を提供し、GB/T 35273-2020「情報セキュリティ技術個人情報セキュリティ仕様」は個人情報セキュリティ要求事項を提示する。 要求事項を提示している。 業界標準の面では、JR/T 0223-2021「金融データセキュリティデータライフサイクルセキュリティ仕様」が金融業界におけるデータセキュリティ保護の要件を規定している。 この規格は、上記の規格を全面的に活用・参照し、関連する国内規格と連携している。
七、 重大分歧意见的处理经过和依据无。	VII. 主な意見の相違の処理とその根拠は公開されていない。
八、 涉及专利的有关说明	VIII. 特許の関与に関する説明
本文件不涉及专利等知识产权。	本文書は、特許及びその他の知的財産権には関与しない。
九、 实施国家标准的要求，以及组织措施、技术措施、过渡期和实施日期的建议等措施建议	IX.国家規格の実施要件、並びに勧告等の提案措置の組織的措置、技術的措置、移行期間及び実施期日
无。	ない。
十、 其他应当说明的事项无。	X. その他明確にすべき事項 該当事項はない。
《信息安全技术 数据安全风险评估方法》编制工作组	情報セキュリティ技術データセキュリティリスクアセスメント手法作成ワーキンググループ
2023年8月20日	2023年8月20日

米国 NIST パブコメ FIPS 203 モジュール・ラティス・ベースの鍵カプセル化メカニズム標準, FIPS 204 モジュール-格子ベース電子署名標準, FIPS 205 ステートレス・ハッシュベース・デジタル署名標準

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

NISTが、次についての初期ドラフトを公表し、意見募集をしていますね。。。

• FIPS 203 モジュール・ラティス・ベースの鍵カプセル化メカニズム標準
• FIPS 204 モジュール-格子ベース電子署名標準
• FIPS 205 ステートレス・ハッシュベース・デジタル署名標準

● NIST - ITL

・2023.08.24 Comments Requested on Three Draft FIPS for Post-Quantum Cryptography

NIST requests comments on the initial public drafts of three Federal Information Processing Standards (FIPS):	NISTは、3つの連邦情報処理標準（FIPS）の初期公開ドラフトに対する意見を要求する：
FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard	FIPS 203、モジュール-格子ベースの鍵カプセル化機構標準
FIPS 204, Module-Lattice-Based Digital Signature Standard	FIPS 204、モジュール-格子ベースの電子署名標準
FIPS 205, Stateless Hash-Based Digital Signature Standard	FIPS 205、ステートレスハッシュベースデジタル署名標準
These proposed standards specify key establishment and digital signature schemes that are designed to resist future attacks by quantum computers, which threaten the security of current standards. The three algorithms specified in these standards are each derived from different submissions to the NIST Post-Quantum Cryptography Standardization Project.	これらの標準規格は、量子コンピュータによる将来的な攻撃に耐えるように設計されており、現在の標準規格の安全性を脅かすものである。これらの標準に規定されている3つのアルゴリズムは、それぞれNISTポスト量子暗号標準化プロジェクトに提出された異なるアルゴリズムから派生したものである。
The public comment period for these three drafts is open through November 22, 2023. See the publication details (linked above) to download the drafts and for information on submitting comments.	これら3つのドラフトに対するパブリックコメント期間は、2023年11月22日までとなっている。 ドラフトをダウンロードし、コメントを提出するための情報については、出版物の詳細（上記リンク）を参照のこと。
***	***
Draft FIPS 203 specifies a cryptographic scheme called the Module-Lattice-Based Key-Encapsulation Mechanism Standard which is derived from the CRYSTALS-KYBER submission. A key encapsulation mechanism (KEM) is a particular type of key establishment scheme that can be used to establish a shared secret key between two parties communicating over a public channel. Current NIST-approved key establishment schemes are specified in NIST Special Publication (SP) 800-56A, Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm-Based Cryptography, and SP 800-56B, Recommendation for Pair-Wise Key Establishment Schemes Using Integer Factorization Cryptography.	ドラフトFIPS 203は、CRYSTALS-KYBERから派生したModule-Lattice-Based Key-Encapsulation Mechanism Standardと呼ばれる暗号方式を規定している。鍵カプセル化機構(KEM)は、特定のタイプの鍵確立スキームであり、公開チャネル上でコミュニ ケーションを行う2つの当事者間で共有秘密鍵を確立するために使用できる。現在NISTが承認している鍵確立方式は、NIST特別刊行物（SP）800-56A「離散対数ベース暗号を使用する ペアワイズ鍵確立方式の推奨」およびSP800-56B「整数化暗号を使用するペアワイズ鍵確立方式の推奨」に規定されている。
The drafts of FIPS 204 and 205 each specify digital signature schemes, which are used to detect unauthorized modifications to data and to authenticate the identity of the signatory. FIPS 204 specifies the Module-Lattice-Based Digital Signature Standard, which is derived from CRYSTALS-Dilithium submission. FIPS 205 specifies the Stateless Hash-Based Digital Signature Standard derived from the SPHINCS+ submission. Current NIST-approved digital signature schemes are specified in FIPS 186-5, Digital Signature Standard, and SP 800-208, Recommendation for Stateful Hash-based Signature Schemes. NIST is also developing a FIPS that specifies a digital signature algorithm derived from FALCON as an additional alternative to these standards.	FIPS 204 および 205 のドラフトは、それぞれデジタル署名方式を規定している。デジタル署名方式は、 データに対する不正な変更を検知し、署名者の本人認証を行うために使用される。FIPS 204 は、CRYSTALS-Dilithium Submission から派生した Module-Lattice-Based Digital Signature Standard を規定している。FIPS 205 は、SPHINCS+ から派生したステートレスハッシュベースデジタル署名標準を規定している。現在NISTが承認しているデジタル署名方式は、FIPS 186-5「デジタル署名標準」とSP 800-208「ステートフルハッシュベース署名方式の推奨」で規定されている。NISTは、これらの標準に代わるものとして、FALCONから派生したデジタル署名アルゴ リズムを規定するFIPSも開発している。

Announcement	発表
NIST requests comments on three draft Federal Information Processing Standards (FIPS):	NIST は、3 つの連邦情報処理標準（FIPS）ドラフトに対する意見を要求する：
・FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard	・FIPS 203 モジュール-格子ベースの鍵カプセル化機構標準
・FIPS 204, Module-Lattice-Based Digital Signature Standard	・FIPS 204 モジュール-格子ベースのデジタル署名標準
・FIPS 205, Stateless Hash-Based Digital Signature Standard	・FIPS 205 ステートレスハッシュベースデジタル署名標準
These proposed standards specify key establishment and digital signature schemes that are designed to resist future attacks by quantum computers, which threaten the security of current standards. The three algorithms specified in these standards are each derived from different submissions to the NIST Post-Quantum Cryptography Standardization Project.	これらの標準規格は、量子コンピュータによる将来的な攻撃に耐えるように設計されており、現在の標準規格の安全性を脅かすものである。これらの標準に規定された3つのアルゴリズムは、それぞれNISTポスト量子暗号標準化プロジェクトに提出された異なるアルゴリズムから派生したものである。

FIPS 203

・2023.08.24 FIPS 203 (Initial Public Draft) Module-Lattice-Based Key-Encapsulation Mechanism Standard

Note to Reviewers	査読者への注記
This draft FIPS specifies a key encapsulation mechanism (KEM) called ML-KEM. A KEM is a particular type of key establishment scheme. While NIST has previously published standards for key establishment schemes (see SP-800-56A and SP-800-56B), this will be the first NIST standard for key establishment using a KEM. As a result, NIST will specify both the particulars of the ML-KEM scheme and the general properties of KEMs in FIPS 203 and SP 800-227, respectively.	このドラフトFIPSは、ML-KEMと呼ばれる鍵カプセル化機構(KEM)を規定する。KEMは、特定のタイプの鍵確立スキームである。NISTはこれまでにも鍵確立方式に関する標準を公表している（SP-800-56AおよびSP-800-56Bを参照）が、 KEMを使用した鍵確立に関するNIST標準はこれが初めてとなる。その結果、NISTは、FIPS 203とSP 800-227において、それぞれML-KEMスキームの特殊性と KEMの一般的な特性の両方を規定することになる。
The scope of FIPS 203 (this document) is limited to specifying only the ML-KEM algorithms (for key generation, encapsulation, and decapsulation) and the associated ML-KEM parameter sets. It aims to provide sufficient information for implementing ML-KEM in a manner that can pass validation through the Cryptographic Module Validation Program (CMVP).	FIPS 203(本文書)の範囲は、ML-KEM アルゴリズム(鍵生成、カプセル化、カプセル化解除)および関連する ML-KEM パラメータセットのみを規定することに限定される。この文書は、暗号モジュール検証プログラム(CMVP)による検証に合格できる方法で ML-KEM を実装するための十分な情報を提供することを目的としている。
SP 800-227 is forthcoming and will discuss the general properties of KEMs in detail. This will include basic definitions, security properties, and requirements for the use of KEMs in secure applications. These topics will not be discussed in detail in the FIPS 203 draft. NIST welcomes comments from reviewers regarding the planned content of SP 800-227.	SP 800-227 は近日中に発表される予定で、KEM の一般的な特性について詳細に論じる予定である。これには、基本的な定義、セキュリティ特性、および安全なアプリケーションにおける KEM の使用に関する要件が含まれる。これらのトピックは、FIPS 203 ドラフトでは詳述されない。NIST は、SP 800-227 の予定内容について、査読者からのコメントを歓迎する。
Abstract	概要
A key-encapsulation mechanism (or KEM) is a set of algorithms that, under certain conditions, can be used by two parties to establish a shared secret key over a public channel. A shared secret key that is securely established using a KEM can then be used with symmetric-key cryptographic algorithms to perform basic tasks in secure communications, such as encryption and authentication.	鍵カプセル化メカニズム（または KEM）は、特定の条件下で、2 つの当事者が公開チャネルを介し て共有秘密鍵を確立するために使用できる一連のアルゴリズムである。KEMを使用して安全に確立された共有秘密鍵は、対称鍵暗号アルゴリズムと併用することで、暗号化や本人認証など、安全なコミュニケーションにおける基本的なタスクを実行することができる。
This standard specifes a key-encapsulation mechanism called ML-KEM. The security of ML-KEM is related to the computational diffculty of the so-called Module Learning with Errors problem. At present, ML-KEM is believed to be secure even against adversaries who possess a quantum computer.	この標準は、ML-KEMと呼ばれる鍵カプセル化メカニズムを規定している。ML-KEMの安全性は、いわゆるエラー付きモジュール学習問題の計算難易度に関係している。現在のところ、ML-KEMは量子コンピュータを持つ敵に対しても安全であると考えられている。
This standard specifes three parameter sets for ML-KEM. In order of increasing security strength (and decreasing performance), these parameter sets are ML-KEM-512, ML-KEM-768, and ML-KEM-1024.	この標準では、ML-KEMのパラメータを3つ規定している。セキュリティ強度が高い（性能が低い）順に、ML-KEM-512、ML-KEM-768、ML-KEM-1024 である。

・[PDF] https://doi.org/10.6028/NIST.FIPS.203.ipd

FIPS 204

・2023.08.24 FIPS 204 (Initial Public Draft) Module-Lattice-Based Digital Signature Standard</>

Abstract<	概要
Digital signatures are used to detect unauthorized modifications to data and to authenticate the identity of the signatory. In addition, the recipient of signed data can use a digital signature as evidence in demonstrating to a third party that the signature was, in fact, generated by the claimed signatory. This is known as non-repudiation since the signatory cannot easily repudiate the signature at a later time.	デジタル署名は、データに対する不正な変更を検知し、署名者の本人認証を行うために使用される。さらに、署名されたデータの取得者は、その署名が実際に署名者によって生成されたものであることをサードパーティに証明するための証拠としてデジタル署名を使用することができる。これは否認防止として知られており、署名者は後で簡単に署名を否認することができないからである。
This standard specifies ML-DSA, a set of algorithms that can be used to generate and verify digital signatures. ML-DSA is believed to be secure even against adversaries in possession of a large-scale quantum computer.	この標準は、デジタル署名の生成と検証に使用できる一連のアルゴリズムであるML-DSAを規定している。ML-DSAは、大規模量子コンピュータを所有する敵対者に対しても安全であると考えられている。

・[PDF] https://doi.org/10.6028/NIST.FIPS.204.ipd

FIPS 205

・2023.08.24 FIPS 205 (Initial Public Draft) Stateless Hash-Based Digital Signature Standard

Abstract

概要

This standard specifies the stateless hash-based digital signature algorithm (SLH-DSA). Digital signatures are used to detect unauthorized modifications to data and to authenticate the identity of the signatory. In addition, the recipient of signed data can use a digital signature as evidence in demonstrating to a third party that the signature was, in fact, generated by the claimed signatory. This is known as non-repudiation since the signatory cannot easily repudiate the signature at a later time. SLH-DSA is based on SPHINCS+, which was selected for standardization as part of the NIST Post-Quantum Cryptography Standardization process.

本標準はステートレスハッシュベースのデジタル署名アルゴリズム（SLH-DSA）を規定する。デジタル署名は、データに対する不正な変更を検知し、署名者の本人認証を行うために使用される。さらに、署名されたデータの取得者は、その署名が実際に署名者によって生成されたものであることをサードパーティに証明するための証拠としてデジタル署名を使用することができる。これは否認防止と呼ばれるもので、署名者が後でその署名を簡単に否認することはできないからである。SLH-DSAはSPHINCS+に基づいており、NISTのポスト量子暗号標準化プロセスの一環として標準化に選ばれた。

・[PDF] https://doi.org/10.6028/NIST.FIPS.205.ipd

NIST SP 1800-35（第3次初期ドラフト） ゼロトラストアーキテクチャの実装 Vol.D 機能デモ

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

実装ガイドライン全5巻（Vol.A 〜 Vol.E）のうちVol.D 機能デモのドラフトとなりますね。。。

SP 1800-35A	Executive Summary	エグゼクティブサマリー	2nd Preliminary Draft
SP 1800-35B	Approach, Architecture, and Security Characteristics	アプローチ、アーキテクチャ、セキュリティ特性	3rd Preliminary Draft
SP 1800-35C	How-To Guides	ハウツーガイド	3rd Preliminary Draft
SP 1800-35D	Functional Demonstrations	機能デモ	3rd Preliminary Draft
SP 1800-35E	Risk and Compliance Management	リスクとコンプライアンスマネジメント	Preliminary Draft

・2023.08.22 NIST SP 1800-35 (3rd Preliminary Draft) Implementing a Zero Trust Architecture

NIST SP 1800-35 (3rd Preliminary Draft) Implementing a Zero Trust Architecture	NIST SP 1800-35（第3次初期ドラフト） ゼロトラストアーキテクチャの実装
Announcement	発表
The Zero Trust Architecture (ZTA) team at NIST's National Cybersecurity Center of Excellence (NCCoE) has published the third version of volume D of a preliminary draft practice guide titled "Implementing a Zero Trust Architecture” and is seeking the public's comments on its contents.	NISTの国立サイバーセキュリティ・センター・オブ・エクセレンス（NCCoE）のゼロトラストアーキテクチャ（ZTA）チームは、「ゼロトラストアーキテクチャの実装」と題する初期ドラフト実践ガイドの第3版D巻を公表し、その内容に関する一般からのコメントを求めている。
This guide summarizes how the NCCoE and its collaborators are using commercially available technology to build interoperable, open standards-based ZTA example implementations that align to the concepts and principles in NIST Special Publication (SP) 800-207, Zero Trust Architecture.	このガイドは、NCCoEとその協力者が、NIST特別刊行物（SP）800-207「ゼロ・トラスト・アーキテクチャ」の概念と原則に沿った、相互運用可能なオープン標準ベースのZTA実装例を構築するために、市販の技術をどのように利用しているかをまとめたものである。
Volume D provides a functional demonstration plan and the updated version includes demonstration results for ten builds. We will continue to update the volumes of NIST SP 1800-35 appropriately as needed as we make significant progress on the project.	D巻は機能実証計画を提供し、更新版には10回の構築の実証結果が含まれる。 NIST SP 1800-35の各巻は、プロジェクトが大きく進展するにつれて、必要に応じて適切に更新していく予定である。
As an enterprise’s data and resources have become distributed across the on-premises environment and multiple clouds, protecting them has become increasingly challenging. Many users need access from anywhere, at any time, from any device. The NCCoE is addressing these challenges by collaborating with industry participants to demonstrate several approaches to a zero trust architecture applied to a conventional, general-purpose enterprise IT infrastructure on-premises and in the cloud.	エンタープライズのデータやリソースがオンプレミス環境や複数のクラウドに分散するようになり、それらを防御することはますます困難になっている。多くのユーザーは、いつでも、どこからでも、どのデバイスからでもアクセスする必要がある。NCCoEは、業界参加者と協力し、オンプレミスおよびクラウド上の従来の汎用エンタープライズITインフラに適用されるゼロトラスト・アーキテクチャへのいくつかのアプローチを実証することで、これらの課題に取り組んでいる。
Abstract	概要
A zero trust architecture (ZTA) focuses on protecting data and resources. It enables secure authorized access to enterprise resources that are distributed across on-premises and multiple cloud environments, while enabling a hybrid workforce and partners to access resources from anywhere, at any time, from any device in support of the organization’s mission. Each access request is evaluated by verifying the context available at access time, including criteria such as the requester’s identity and role, the requesting device’s health and credentials, the sensitivity of the resource, user location, and user behavior consistency. If the enterprise’s defined access policy is met, a secure session is created to protect all information transferred to and from the resource. A real-time and continuous policy-driven, risk-based assessment is performed to establish and maintain the access. In this project, the NCCoE and its collaborators use commercially available technology to build interoperable, open, standards-based ZTA implementations that align to the concepts and principles in NIST Special Publication (SP) 800-207, Zero Trust Architecture. This NIST Cybersecurity Practice Guide explains how commercially available technology can be integrated and used to build various ZTAs.	ゼロ・トラスト・アーキテクチャー（ZTA）は、データとリソースの保護に重点を置く。ZTAは、オンプレミスや複数のクラウド環境に分散しているエンタープライズ・リソースへのセキュアな認証アクセスを可能にする一方で、ハイブリッドな従業員やパートナーが、組織のミッションをサポートするために、いつでも、どこからでも、どのデバイスからでもリソースにアクセスできるようにする。各アクセス・リクエストは、アクセス時に利用可能なコンテキストを検証することで評価される。これには、リクエスト元のアイデンティティや役割、リクエスト元のデバイスの状態や認証情報、リソースの機密性、ユーザーの場所、ユーザーの行動の一貫性などの基準が含まれる。エンタープライズで定義されたアクセス・ポリシーに合致する場合、リソースとの間で転送されるすべての情報を保護するためのセキュアなセッションが作成される。リアルタイムかつ継続的なポリシー駆動型のリスクベースのアセスメントが実行され、アクセスが確立・維持される。このプロジェクトでは、NCCoE とその協力者は、市販の技術を使用して、NIST 特別刊行物（SP）800-207「Zero Trust Architecture」の概念と原則に沿った、相互運用可能でオープンな標準ベースの ZTA 実装を構築する。この NIST サイバーセキュリティ実践ガイドでは、さまざまな ZTA を構築するために、市販の技術をどのように統合し、使用できるかを説明する。

・[PDF]

● NIST - NCCoE

アナウンス

・2022.08.22 The Zero Trust Architecture (ZTA) Team Releases Preliminary Draft Practice Guide (Vol D)

The Zero Trust Architecture (ZTA) Team Releases Preliminary Draft Practice Guide (Vol D)	ゼロ・トラスト・アーキテクチャー（ZTA）チーム、実践ガイド初期ドラフト（Vol.D）を発表
The Zero Trust Architecture (ZTA) team at NIST’s National Cybersecurity Center of Excellence (NCCoE) has published the third version of volume D of a preliminary draft practice guide titled “Implementing a Zero Trust Architecture” and is seeking the public’s comments on its contents.	NISTの国立サイバーセキュリティ・センター・オブ・エクセレンス（NCCoE）のZero Trust Architecture（ZTA）チームは、「Implementing a Zero Trust Architecture」と題する初期ドラフト実践ガイドの第3版（Volume D）を公開し、その内容に対する一般からのコメントを求めている。
This guide summarizes how the NCCoE and its collaborators are using commercially available technology to build interoperable, open standards-based ZTA example implementations that align to the concepts and principles in NIST Special Publication (SP) 800-207, Zero Trust Architecture. Volume D provides a functional demonstration plan, and the updated version includes demonstration results for ten builds.	このガイドは、NCCoEとその協力者が、NIST特別刊行物（SP）800-207「Zero Trust Architecture」の概念と原則に沿った、相互運用可能なオープン標準ベースのZTA実装例を構築するために、市販の技術をどのように利用しているかをまとめたものである。D巻は機能実証計画を提供し、更新版には10回の構築の実証結果が含まれている。
As an enterprise’s data and resources have become distributed across the on-premises environment and multiple clouds, protecting them has become increasingly challenging. Many users need access from anywhere, at any time, from any device. The NCCoE is addressing these challenges by collaborating with industry participants to demonstrate several approaches to a zero trust architecture applied to a conventional, general-purpose enterprise IT infrastructure on-premises and in the cloud.	エンタープライズのデータやリソースがオンプレミス環境や複数のクラウドに分散されるようになり、それらの防御はますます困難になっている。多くのユーザーは、いつでも、どこからでも、どのデバイスからでもアクセスする必要がある。NCCoEは、業界参加者と協力し、オンプレミスおよびクラウド上の従来の汎用エンタープライズITインフラに適用されるゼロトラスト・アーキテクチャへのいくつかのアプローチを実証することで、こうした課題に取り組んでいる。
The NCCoE is making volume D available as a preliminary draft for public comment while work continues on the project. Review the preliminary draft and submit comments online on or before October 9th, 2023. Visit the ZTA page to download the volume and feedback form.	NCCoEは、このプロジェクトの作業を継続する間、パブリックコメント用の初期ドラフトとしてボリュームDを公開している。初期ドラフトを確認し、2023年10月9日までにオンラインでコメントを提出できる。また、ZTAのページで、それぞれの巻とフィードバックフォームをダウンロードできる。

・Implementing a Zero Trust Architecture

Implementing a Zero Trust Architecture	ゼロ・トラスト・アーキテクチャの実装
Conventional network security has focused on perimeter defenses, but many organizations no longer have a clearly-defined perimeter. To protect a modern digital enterprise, organizations need a comprehensive strategy for secure “anytime, anywhere” access to their corporate resources (e.g., applications, legacy systems, data, and devices) regardless of where they are located.	従来のネットワーク・セキュリティは境界防御に重点を置いてきたが、多くの組織ではもはや境界が明確に定義されていない。 現代のデジタル・エンタープライズを防御するためには、企業リソース（アプリケーション、レガシー・システム、データ、デバイスなど）への「いつでも、どこからでも」安全にアクセスできる包括的な戦略が必要である。
End-to-end zero trust architecture implementations to help industry and government reduce the risk of cyber attack	エンド・ツー・エンドのゼロ・トラスト・アーキテクチャの実装により、産業界と政府はサイバー攻撃のリスクを軽減できる。
The National Cybersecurity Center of Excellence (NCCoE) aims to remove the shroud of complexity around designing for zero trust with “how to” guides and example approaches to implementing a zero trust architecture for several common business cases.	国立サイバーセキュリティ・センター・オブ・エクセレンス（NCCoE）は、いくつかの一般的なビジネスケースに対応したゼロトラスト・アーキテクチャを実装するための「ハウツー」ガイドとアプローチ例により、ゼロトラスト設計にまつわる複雑な覆いを取り除くことを目指す。

・[PDF] Fact Sheet: IMPLEMENTING A ZERO TRUST ARCHITECTURE

IMPLEMENTING A ZERO TRUST ARCHITECTURE	ゼロトラストアーキテクチャの実装
The National Cybersecurity Center of Excellence (NCCoE) is addressing the challenge of implementing a zero trust architecture (ZTA) through collaborative efforts with industry and the information technology (IT) community, including cybersecurity solutions providers. This fact sheet provides an overview of the Implementing a Zero Trust Architecture project, including background, goal, potential benefits, and project collaborators.	国立サイバーセキュリティ・センター・オブ・エクセレンス（NCCoE）は、サイバーセキュリティ・ソリューション・プロバイダを含む産業界や情報技術（IT）コミュニティとの協力を通じて、ゼロ・トラスト・アーキテクチャ（ZTA）の実装という課題に取り組んでいる。このファクト・シートでは、背景、目標、潜在的なメリット、プロジェクトの協力者など、「ゼロ・トラスト・アーキテクチャの実装」プロジェクトの概要を説明する。
BACKGROUND	背景
The conventional security approach has focused on perimeter defenses. Once inside the network perimeter, users are “trusted” and often given broad access to many corporate resources. But malicious actors can come from inside or outside the perimeter, and several high-profile cyberattacks in recent years have undermined the case for the perimeter- based model. Moreover, the perimeter is becoming less relevant due to several factors, including the growth of cloud computing and mobility, and changes in the modern workforce.	従来のセキュリティ・アプローチは、境界防御に焦点を当ててきた。ネットワーク境界の内側に入ると、ユーザーは「信頼」され、多くの企業リソースへの広範なアクセスが与えられることが多い。しかし、悪意のある行為者は、境界の内外から侵入する可能性があり、近年、いくつかの有名なサイバー攻撃によって、境界をベースとしたモデルの根拠が崩れつつある。さらに、クラウド・コンピューティングやモビリティの拡大、現代の労働力の変化など、いくつかの要因により、境界はあまり意味を持たなくなってきている。
Zero trust is a cybersecurity strategy that focuses on moving perimeter-based defenses from wide, static perimeters to narrow dynamic and risk-based access control for enterprise resources regardless of where they are located. Zero trust access control is based on a number of attributes such as identity and endpoint health.	ゼロ・トラストとは、サイバーセキュリティ戦略であり、境界ベースの防御を広く静的な境界から、エンタープライズ・リソースの所在に関係なく、狭く動的でリスクに基づくアクセス制御へと移行することに重点を置いている。ゼロトラスト・アクセス制御は、IDやエンドポイントの健全性など、多くの属性に基づいている。
CHALLENGE	課題
The challenges to implementing a ZTA include:	ZTAの導入には、以下のような課題がある：
Leveraging existing investments and balancing priorities while making progress toward a ZTA via modernization initiatives	既存の投資を活用し、優先順位のバランスを取りながら、近代化イニシアチブを介してZTAに向けて前進する。
Integrating various types of commercially available technologies of varying maturities, assessing capabilities, and identifying technology gaps to build a complete ZTA	完全なZTAを構築するために、成熟度の異なるさまざまなタイプの市販技術を統合し、能力を評価し、技術ギャップを特定すること。
Concern that ZTA might negatively impact the operation of the environment or end-user experience	ZTAが環境の運用やエンドユーザー・エクスペリエンスに悪影響を及ぼすのではないかという懸念
Lack of common understanding of ZTA across the organization, gauging the organization’s ZTA maturity, determining which ZTA approach is most suitable for the business, and developing an implementation plan	組織全体のZTAに対する共通理解が不足しており、組織のZTA成熟度を測定し、どのZTAアプローチがビジネスに最も適しているかを判断し、実施計画を策定する。
GOALS	目標
The goal of this NCCoE project is to demonstrate several example ZTA solutions—applied to a conventional, general- purpose enterprise IT infrastructure—that are designed and deployed according to the concepts and tenets documented in NIST Special Publication (SP) 800207, Zero Trust Architecture.	このNCCoEプロジェクトの目標は、NIST特別刊行物（SP）800207「Zero Trust Architecture」に記載されているコンセプトと原則に従って設計・導入された、従来の汎用エンタープライズITインフラに適用されるZTAソリューションの例をいくつか実証することである。
BENEFITS	利点
The potential business benefits of the example solutions include:	例示したソリューションの潜在的なビジネス上のメリットは以下のとおりである：
Support user access to resources regardless of user location or user device (managed or unmanaged)	ユーザーの場所やデバイス（管理型、非管理型）に関係なく、ユーザーのリソースへのアクセスをサポートする。
Protect business assets and processes regardless of their location (on-premises or cloud-based)	場所（オンプレミスまたはクラウドベース）に関係なく、ビジネス資産とプロセスを防御する。
Limit the insider threat (insiders—both users and nonperson entities—are not automatically trusted)	インサイダーの脅威を制限する（インサイダー（ユーザーと非事業体の両方）は自動的に信頼されるわけではない
Limit breaches (reduce attackers’ ability to move laterally and escalate privilege within the environment)	侵害を制限する（攻撃者が環境内で横方向に移動し、権限をエスカレートする能力を低下させる）
Protect sensitive corporate information with data security solutions	データセキュリティ・ソリューションで企業の機密情報を防御する。
Improve visibility into the inventory of resources, what configurations and controls are implemented, all communications and their specific flows, and how resources are accessed and protected, and then use this understanding to formulate and enforce a useful and complete security policy	リソースのインベントリ、どのような構成と制御が実装されているか、すべてのコミュニケーションとその具体的なフロー、リソースがどのようにアクセスされ、保護されているかについての可視性を改善し、この理解を利用して有用かつ完全なセキュリティポリシーを策定し、実施する
Perform real-time and continuous monitoring and logging, and policy-driven, risk-based assessment and enforcement of resource access policy	リアルタイムかつ継続的なモニタリングとロギングを行い、ポリシー駆動型のリスクベースの評価とリソース・アクセス・ポリシーの実施を行う。
HIGH-LEVEL ARCHITECTURE	ハイレベルアーキテクチャ
A ZTA is designed for secure access to enterprise resources. Shown here is a high-level, notional architecture of the core components of a ZTA build for a typical IT enterprise and the functional components to support it. A detailed explanation of each component can be found within the practice guide and project description at [web] .	ZTAはエンタープライズリソースへの安全なアクセスのために設計されている。ここに示すのは、典型的なITエンタープライズ向けに構築されたZTAのコアコンポーネントと、それをサポートする機能コンポーネントのハイレベルな想定アーキテクチャである。各コンポーネントの詳細な説明は、[web] の実践ガイドとプロジェクトの説明の中にある。
TECHNOLOGY COLLABORATORS	技術協力者
The technology vendors participating in this project submitted their capabilities in response to an open call in the Federal	このプロジェクトに参加する技術ベンダーは、連邦官報に掲載された公募に応じ て、その能力を提出した。
Register. Companies with relevant security capabilities were invited to sign a Cooperative Research and Development Agreement with the National Institute of Standards and Technology (NIST), allowing them to participate in a consortium to build this example solution.	登録された。関連するセキュ リティ機構を持つ企業は、国立標準技術研究所（NIST）と協力研究開発契約を締結するよう招 待され、このソリューション例を構築するコンソーシアムへの参加が認められた。
Appgate	Appgate
AWS	AWS
Broadcom Software	Broadcom Software
Cisco	Cisco
DigiCert	DigiCert
F5	F5
Forescout	Forescout
Google Cloud	Google Cloud
IBM	IBM
Ivanti	Ivanti
Lookout	Lookout
Mandiant	Mandiant
Microsoft	Microsoft
Okta	Okta
Palo Alto Networks	Palo Alto Networks
PC Matic	PC Matic
Ping Identity	Ping Identity
Radiant Logic	Radiant Logic
SailPoint	SailPoint
Tenable	Tenable
Trellix	Trellix
VMware	VMware
Zimperium	Zimperium
Zscaler	Zscaler
Certain commercial entities, equipment, products, or materials may be identified by name or company logo or other insignia to acknowledge their participation in this collaboration or to describe an experimental procedure or concept adequately. Such identification is not intended to imply special status or relationship with NIST or recommendation or endorsement by NIST or the NCCoE; neither is it intended to imply that the entities, equipment, products, or materials are necessarily the best available.	特定の営利事業体、機器、製品、または材料は、本協業への参加を認めるため、または実験手順やコンセプトを適切に説明するために、名称や企業ロゴ、その他の記章によって識別される場合がある。このような識別は、NIST との特別な地位や関係、あるいは NIST や NCCoE による推奨や支持を意味するものではなく、事業体、機器、製品、または材料が必ずしも入手可能な最良のものであることを意味するものでもない。
The National Cybersecurity Center of Excellence (NCCoE), a part of the National Institute of Standards and Technology (NIST), is a collaborative hub where industry organizations, government agencies, and academic institutions work together to address businesses’ most pressing cybersecurity challenges. Through this collaboration, the NCCoE develops modular, easily adaptable example cybersecurity solutions demonstrating how to apply standards and best practices using commercially available technology.	国立標準技術研究所（NIST）の一部門である国立サイバーセキュリティ・センター・オブ・エクセレンス（NCCoE）は、産業組織、政府機関、学術機関が協力して、企業の最も差し迫ったサイバーセキュリティの課題に取り組む共同拠点である。このコラボレーションを通じて、NCCoEは、市販の技術を使用して標準とベスト・プラクティスを適用する方法を実証する、モジュール式で容易に適応可能なサイバーセキュリティ・ソリューションの例を開発している。
LEARN MORE	詳細はこちら
For more information about this project, visit:  [web]	このプロジェクトの詳細については、以下を参照のこと：  [web]

---

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

1800-35...

・2023.07.23 NIST SP 1800-35（第2次初期ドラフト） ゼロトラストアーキテクチャの実装 (Vol. B, C)

・2022.08.10 NIST SP 1800-35 (ドラフト) ゼロトラストアーキテクチャの実装（初期ドラフト）(Vol. C, D)

・2022.07.09 NIST SP 1800-35 (ドラフト) ゼロトラストアーキテクチャの実装（初期ドラフト）(Vol. B)

・2022.06.07 NIST SP 1800-35 (ドラフト) ゼロトラストアーキテクチャの実装（初期ドラフト）(Vol. A)

800-207他

・2023.04.23 NIST SP 800-207A（ドラフト）マルチクラウド環境におけるクラウドネイティブ・アプリケーションにおけるアクセス制御のためのゼロトラストアーキテクチャモデル

・2022.12.12 カナダ サイバーセキュリティセンター 「ゼロトラスト・セキュリティモデル - ITSAP.10.008」

・2022.05.08 NIST ホワイトペーパー CSWP 20 ゼロトラストアーキテクチャのための計画：連邦政府管理者向け計画策定ガイド

・2022.03.15 米国 CISA 意見募集 ゼロトラスト原則のエンタープライズ・モビリティへの適用 (2022.03.07)

・2021.09.09 米国 CISA 意見募集 ゼロトラスト成熟度モデル

・2021.06.30 金融庁 「ゼロトラストの現状調査と事例分析に関する調査報告書」の公表

・2021.03.01 米国国家安全保障局 (NSA) ゼロトラストセキュリティモデルに関するガイダンス

・2020.12.14 PwC Japanが「NIST SP800-207 「ゼロトラスト・アーキテクチャ」の解説と日本語訳」を公表していますね。。。

・2020.08.14 NIST SP 800-207 Zero Trust Architecture

・2020.02.14 NIST SP 800-207(Draft) Zero Trust Architecture (2nd Draft)

中国 TC260 国家標準「機微な個人情報の処理に関するセキュリティ要件」公開草案 (2023.08.09)

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

中国の国家情報セキュリティ標準化技術委員会（全国信息安全标准化技术委员会, National Information Security Standardization Technical Committee, いわゆるTC260）が、「機微な個人情報の処理に関するセキュリティ要件」についての国家標準案を公表し、意見募集をしていました...

機微な個人情報をさらに次のように分類していますね。。。

类别	種別	典型例
生物识别信息	生体情報	個人の遺伝子、指紋、声紋、掌紋、眼紋、耳紋、虹彩、顔認識機能、歩行など。
宗教信仰信息	宗教に関する情報	信仰宗教、宗教団体の会員、宗教団体での地位、宗教活動への参加、特別な宗教的慣習など。
特定身份信息	特定身元個人情報	犯罪者識別情報、障害者識別情報、職務固有情報（軍隊、警察など）、識別番号など。
医疗健康信息	医療・健康情報	病気、病院の記録、医療指示、検査報告書、検査報告書、手術・麻酔記録、看護記録、投薬記録、出生情報、家族病歴、感染症歴など。
金融账户信息	金融口座情報	銀行、証券、ファンド、保険、プロビデントファンドの口座番号およびパスワード、プロビデントファンドの共同口座番号、支払口座番号、銀行カードの磁気チャネルデータ（またはチップに相当する情報）、口座情報に基づいて生成された支払マーキング情報など。
行踪轨迹信息	居場所経路情報	リアルタイムの正確な位置情報、GPS車両追跡情報、航空券情報、特定宿泊施設情報など。
不满十四周岁未成年人个人信息	14歳未満の未成年者の個人情報	14歳未満の未成年者の個人情報
身份鉴别信息	識別情報	ログインパスワード、支払いパスワード、口座照会パスワード、取引パスワード、動的パスワード、パスワード保護回答など。
其他敏感个人信息	その他の機微な個人情報	ウェブ閲覧情報、婚姻歴、性的指向、通信内容、信用情報、未公表の犯罪歴など。

実務において、参考になる点も多くありそうですね。。。

● 全国信息安全标准化技术委员会

・2023.08.09 关于国家标准《信息安全技术 敏感个人信息处理安全要求》征求意见稿征求意见的通知

標準案　[PDF] 信息安全技术 敏感个人信息处理安全要求-标准文本.pdf

・[DOCX] 仮訳

编制说明：信息安全技术 敏感个人信息处理安全要求-编制说明.docx

米国 NIST IR 8477（初公開ドラフト）：文書標準、規制、フレームワーク、ガイドライン間の関係をマッピングする： サイバーセキュリティとプライバシーの概念マッピングの開発

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

・2023.08.17 Cybersecurity and Privacy Mapping Guide: Draft NIST IR 8477 Available for Comment

Cybersecurity and Privacy Mapping Guide: Draft NIST IR 8477 Available for Comment	サイバーセキュリティとプライバシーのマッピングガイド： NIST IR 8477ドラフト、コメント募集中
NIST has released the initial public draft (ipd) of a new report for public comment: NIST Internal Report (IR) 8477 ipd, Mapping Relationships Between Documentary Standards, Regulations, Frameworks, and Guidelines: Developing Cybersecurity and Privacy Concept Mappings.	NISTは、新しい報告書の初公開ドラフト（ipd）を公開し、パブリックコメントを求めている： NIST内部報告 (IR) 8477 ipd： サイバーセキュリティとプライバシーの概念マッピングを開発する。
Understanding how the elements of diverse sources of cybersecurity and privacy content are related to each other is an ongoing challenge for people in nearly every organization. This document explains NIST’s proposed approach for identifying and documenting relationships between concepts such as controls, requirements, recommendations, outcomes, technologies, functions, processes, techniques, roles, and skills.	サイバーセキュリティとプライバシーの内容の多様な情報源の要素が互いにどのように関連しているかを理解することは、ほとんどすべての組織の人々にとって継続的な課題である。この文書では、コントロール、要求事項、勧告、成果、技術、機能、プロセス、技術、役割、スキルなどの概念間の関係を特定し、文書化するための NIST の提案するアプローチを説明する。
NIST intends for the approach to be used for mapping relationships involving NIST cybersecurity and privacy publications that will be submitted to NIST’s National Online Informative References (OLIR) Program for hosting in NIST’s online Cybersecurity and Privacy Reference Tool (CPRT). This will include mapping the equivalent of the NIST Cybersecurity Framework’s (CSF) 1.1 Informative References in support of CSF 2.0.	NIST は、NIST のオンラインサイバーセキュリティ・プライバシー参照ツール（CPRT）に掲載するために、NIST の全国オンライン情報参考文献（OLIR）プログラムに提出される NIST のサイバーセキュリティおよびプライバシーに関する出版物に関係する関係をマッピングするために、このアプローチを使用することを意図している。これには、NIST のサイバーセキュリティフレームワーク（CSF）1.1 に相当する参考文献を CSF2.0 に対応させることも含まれる。
By following this approach, NIST and others in the cybersecurity and privacy standards community can jointly establish a single concept system over time that links cybersecurity and privacy concepts from many sources into a cohesive, consistent set of relationship mappings. The mappings can then be used by different audiences to better describe the interrelated aspects of the global cybersecurity and privacy corpus.	このアプローチに従うことで、NIST とサイバーセキュリティとプライバシーの標準コミュニティの他の人々は、多くのソースからのサイバーセキュリティとプライバシーの概念を、まとまりのある一貫した一連の関係マッピングに結びつける単一の概念体系を、時間をかけて共同で確立することができる。このマッピングは、グローバルなサイバーセキュリティとプライバシーのコーパスの相互に関連する側面をよりよく記述するために、さまざまな想定読者が使用することができる。

 ・2023.08.17 NIST IR 8477 (Initial Public Draft) Mapping Relationships Between Documentary Standards, Regulations, Frameworks, and Guidelines: Developing Cybersecurity and Privacy Concept Mappings

NIST IR 8477 (Initial Public Draft) : Mapping Relationships Between Documentary Standards, Regulations, Frameworks, and Guidelines: Developing Cybersecurity and Privacy Concept Mappings	NIST IR 8477（初公開ドラフト）：文書標準、規制、フレームワーク、ガイドライン間の関係をマッピングする： サイバーセキュリティとプライバシーの概念マッピングの開発
Announcement	発表
Understanding how the elements of diverse sources of cybersecurity and privacy content are related to each other is an ongoing challenge for people in nearly every organization. This document explains NIST’s proposed approach for identifying and documenting relationships between concepts such as controls, requirements, recommendations, outcomes, technologies, functions, processes, techniques, roles, and skills.	サイバーセキュリティとプライバシーに関する多様な情報源の要素が互いにどのように関連しているかを理解することは、ほとんどすべての組織の人々にとって継続的な課題である。この文書では、コントロール、要求事項、勧告、成果、技術、機能、プロセス、技術、役割、スキルなどの概念間の関係を特定し、文書化するための NIST の提案するアプローチを説明する。
NIST intends for the approach to be used for mapping relationships involving NIST cybersecurity and privacy publications that will be submitted to NIST’s National Online Informative References (OLIR) Program for hosting in NIST’s online Cybersecurity and Privacy Reference Tool (CPRT). This will include mapping the equivalent of the NIST Cybersecurity Framework’s (CSF) 1.1 Informative References in support of CSF 2.0.	NIST は、NIST のオンラインサイバーセキュリティ・プライバシー参照ツール（CPRT）に掲載するために、NIST の オンライン情報参考文献（OLIR）プログラムに提出される NIST のサイバーセキュリティおよびプライバシーに関する出版物に関係する関係をマッピングするために、このアプローチを使用することを意図している。これには、NIST のサイバーセキュリティフレームワーク（CSF）1.1 に相当する参考文献を CSF2.0 に対応させることも含まれる。
By following this approach, NIST and others in the cybersecurity and privacy standards community can jointly establish a single concept system over time that links cybersecurity and privacy concepts from many sources into a cohesive, consistent set of relationship mappings. The mappings can then be used by different audiences to better describe the interrelated aspects of the global cybersecurity and privacy corpus.	このアプローチに従うことで、NIST とサイバーセキュリティとプライバシーの標準コミュニティの他の人々は、多くのソースからのサイバーセキュリティとプライバシーの概念を、まとまりのある一貫した一連の関係マッピングに結びつける単一の概念体系を、時間をかけて共同で確立することができる。このマッピングは、グローバルなサイバーセキュリティとプライバシーのコーパスの相互に関連する側面をよりよく記述するために、さまざまな想定読者が使用することができる。
Abstract	概要
This document describes an approach that NIST would use and other parties could use for mapping the elements of documentary standards, regulations, frameworks, and guidelines to NIST publications, such as CSF Subcategories or SP 800-53r5 controls. NIST intends for this approach to be used for future mappings involving NIST cybersecurity and privacy publications that will be submitted via the NIST National Online Informative References (OLIR) process for hosting on NIST’s online Cybersecurity and Privacy Reference Tool (CPRT). By following this approach, NIST and others in the cybersecurity and privacy standards community can jointly establish a single concept system over time that links cybersecurity and privacy concepts from many sources into a cohesive, consistent set of relationship mappings within the NIST CPRT. The approach is informed by concept system and terminology standards, as well as experience with what information the cybersecurity and privacy community would find most valuable.	本文書は、文書化された標準、規制、フレームワーク、およびガイドラインの要素を、CSF サブカテゴリーや SP 800-53r5 コントロールのような NIST の出版物にマッピングするために、NIST が使用し、他の関係者が使用できるアプローチについて記述している。NIST は、NIST 全国オンライン情報参考文献（OLIR）プロセスを通じて提出され、NIST のオンライン・サイバーセキュリティ・プライバシー・リファレンス・ツール（CPRT）でホストされる NIST のサイバーセキュリティとプライバシーの出版物を含む将来のマッピングに、このアプローチが使用されることを意図している。このアプローチに従うことで、NIST とサイバーセキュリティとプライバシーの標準化コミュニティの他の関係者は、多くの情報源からのサイバーセキュリティとプライバシーの概念を NIST CPRT 内のまとまりのある一貫した一連の関係マッピングにリンクさせる単一の概念体系を、時間をかけて共同で確立することができる。このアプローチは、概念体系と用語の標準に加え、サイバーセキュリティとプライバシーのコミュニティがどのような情報に最も価値を見出すかについての経験に基づいている。

・[PDF] NIST.IR.8477.ipd

目次と表...

Executive Summary	エグゼクティブサマリー
1. Introduction	1. 序文
1.1. Purpose and Scope	1.1. 目的と範囲
1.2. Related Work	1.2. 関連作業
1.3. Publication Structure	1.3. 出版構成
2. Concept Mapping Approach Overview	2. 概念マッピング・アプローチの概要
3. Identify and Document Use Cases for the Mapping	3. マッピングのユースケースの識別と文書化
4. Choose a Concept Relationship Style	4. 概念関係のスタイルを選択する
4.1. Concept Crosswalk	4.1. 概念クロスウォーク
4.2. Supportive Relationship Mapping	4.2. サポート関係マッピング
4.3. Set Theory Relationship Mapping	4.3. セットセオリー関係マッピング
4.4. Structural Relationship Mapping	4.4. 構造的関係マッピング
4.5. Custom	4.5. カスタム
4.6. Using Mappings With Different Relationship Styles	4.6. 異なるリレーションシップスタイルでマッピングを使用する
5. Evaluate Concept Pairs and Document Their Relationships	5. 概念ペアを評価し、その関係を文書化する
6. Next Steps	6. 次のステップ
References	参考文献
Appendix A. Glossary	附属書A. 用語集
List of Tables	表
Table 1. Notional documentation of assumptions	表1. 前提条件の想定文書
Table 2. Concept relationship styles	表2. 概念関係のスタイル
Table 3. Supportive relationship mapping examples from SP 1800-36 Vol. E	表3. SP 1800-36 Vol.Eからの支援関係マッピングの例
Table 4. Supportive relationship mapping examples from SP 1800-35 Vol. E	表4. SP 1800-35 Vol.Eからの支援関係マッピング例
Table 5. Set theory relationship mapping example from OLIR repository	表5. OLIRリポジトリからの集合論的関係マッピング例
Table 6. Notional example of parent-child relationships	表6. 親子関係の想定例
Table 7. Converting set theory relationships to supportive relationships	表7. 集合論の関係を支持関係に変換する

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

Executive Summary	エグゼクティブサマリー
Understanding how the elements of diverse cybersecurity and privacy standards, regulations, frameworks, guidelines, and other content are related to each other is an ongoing challenge for people at nearly every organization. It can be time-consuming and difficult to answer questions like:	多様なサイバーセキュリティとプライバシーの標準、規制、フレームワーク、ガイドライン、その他のコンテンツの要素が互いにどのように関連しているかを理解することは、ほとんどすべての組織の人々にとって継続的な課題である。次のような質問に答えるには、時間がかかり、困難な場合がある：
•       How does conforming to one standard help the organization conform to another standard? What parts of the second standard does the first standard fail to address?	・ある標準に適合することは、その組織が別の標準に適合することにどのように役立つのか？ある標準に適合することは、その組織が別の標準に適合することにどのように役立つのか？
•       Where can we find more information on how to satisfy a particular requirement in a guideline? What types of technologies can we use, and what types of skills do the implementers need to have?	・あるガイドラインの特定の要求事項を満たす方法について,詳しい情報はどこにあるのか？どのような種類の技術を使うことができ,実装者にはどのような種類のスキルが必要なのか？
•       If we want to conform to a particular standard, what types of cybersecurity capabilities do our technology product and service providers need to support?	・特定の標準に適合させたいのであれば、どのような種類のサイバーセキュリティ機能 を,当社の技術製品及びサービスプロバイダがサポートする必要があるのか。
•       If we perform a particular security assessment methodology, what requirements will be sufficiently validated across our compliance portfolio?	・特定のセキュリティ評価手法を実施する場合、どのような要件が当社のコンプライ アンス・ポートフォリオ全体で十分に検証されることになるのか。
•       What recommendations substantially changed from a guideline’s previous version to its current version?	・ガイドラインの旧版と現行版とで、どのような推奨事項が大幅に変更されたのか。
•       What security and privacy controls must be in place before we adopt a new technology?	・新しい技術を採用する前に、どのようなセキュリティ管理及びプライバシー管理を実施しなければならないか。
This document explains NIST’s proposed approach for identifying and documenting the relationships between concepts in cybersecurity and privacy, such as how the concepts of a NIST or third-party standard or guideline relate to the concepts of a foundational NIST publication like the Cybersecurity Framework (CSF) or NIST Special Publication (SP) 800-53. There are many possible concept types, including controls, requirements, recommendations, outcomes, technologies, functions, processes, techniques, roles, and skills. NIST intends to use this approach for mapping relationships involving NIST cybersecurity and privacy publications that will be submitted via NIST’s National Online Informative References (OLIR) Program for hosting in NIST’s online Cybersecurity and Privacy Reference Tool (CPRT). This will include mapping the equivalent of CSF 1.1’s Informative References in support of CSF 2.0. Third parties choosing to contribute mappings to OLIR for CPRT hosting would also need to use the approach in the future.	この文書では、サイバーセキュリティとプライバシーの概念間の関係を特定し、文書化するための NIST の提案アプローチを説明する。例えば、NIST やサードパーティの標準やガイドラインの概念が、サイバーセキュリティフレームワーク（CSF）や NIST 特別刊行物（SP）800-53 のような NIST の基本的な刊行物の概念とどのように関連しているかなどである。概念には、管理、要件、推奨、成果、技術、機能、プロセス、技術、役割、スキルなど、多くの種類が考えられる。NIST は、NIST のオンライン・サイバーセキュリティ・プライバシー・リファレンス・ツール（CPRT）に掲載するために、NIST の全国オンライン情報参照（OLIR）プログラムを通じて提出される NIST のサイバーセキュリティとプライバシーの出版物に関係する関係をマッピングするために、このアプローチを使用する予定である。これには、CSF 2.0 をサポートするために、CSF 1.1 の参考情報に相当するマッピングが含まれる。CPRT ホスティングのために OLIR にマッピングを提供することを選択したサードパーティも、将来はこのアプローチを使用する必要がある。
By following this approach, NIST and others in the cybersecurity and privacy standards community can jointly establish a single concept system over time that links cybersecurity and privacy concepts from many sources into a cohesive, consistent set of relationship mappings within the NIST CPRT. The mappings can then be used by different audiences to better describe the interrelated aspects of the global cybersecurity and privacy corpus.	このアプローチに従うことにより、NIST 及びサイバーセキュリティとプライバシーの標準コミュニティの他の関係者は、NIST CPRT 内で、多くの情報源からのサイバーセキュリティとプライバ シーの概念を首尾一貫した一連の関係マッピングにリンクする単一の概念体系を、長期にわたっ て共同で確立することができる。このマッピングは、グローバルなサイバーセキュリティとプライバシーのコーパスの相互に関連する側面をよりよく記述するために、さまざまな想定読者が使用することができる。

---

参考

● NIST

全国オンライン情報参考文献 （OLIR）プログラム

・National Online Informative References Program OLIR

PDFからの解放...

サイバーセキュリティとプライバシーリファレンスツール CPRT

・Cybersecurity and Privacy Reference Tool CPRT

中国 「未成年者向けモバイルインターネットモデル構築ガイドライン（意見募集案）」 (2023.08.02)

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

見逃していたみたいです...(^^;;

未成年がスマフォ等を通じてインターネットに接続し、アプリを使う時間を制限するということで、端末、アプリ、配信プラットフォームの３つを連携させて制限をしようとするようですね。。。

で、未成年の区分は５段階です。。。

1. 3歳未満
2. 3歳以上8歳未満
3. 8歳以上12歳未満
4. 12歳以上16歳未満
5. 16歳以上18歳未満

年齢	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	...
区分	1			2					3				4				5
利用時間	40分以内								１時間								２時間
連続利用	未成年者が30分以上連続して携帯情報端末を使用する場合、携帯情報端末は休息通知を発すること
時間帯	22:00から翌日6:00までの間、携帯情報端末は未成年者に対してサービスを提供することができない
推奨コンテンツ	童謡、啓蒙教育などの親子連れの番組を推奨コンテンツとし、音声を重視することを推奨する			啓蒙教育、興味と識字、一般教育などの番組を推奨する					一般教育、科学の知識と普及、ライフスキル、積極的な指導を伴う娯楽コンテンツ、この年齢層の認知能力に適したニュースや情報など				一般教育、教科教育、科学の知識と普及、ライフスキル、積極的な指導による娯楽コンテンツ、この年齢層の認知能力に適したニュースや情報				この年齢層の認知能力に適した、健康で上向きの情報コンテンツを推奨する
アプリダウンロード	未成年者向けゾーンでアプリケーションをダウンロードおよびインストールするには保護者の同意が必要であり、保護者は未成年者が未成年者向けゾーン外でアプリケーションをダウンロードすることを許可する一定の免除権限を有する												未成年者向けゾーンでアプリケーションをダウンロードおよびインストールするには保護者の同意が必要であり、保護者は未成年者が未成年者向けゾーン外でアプリケーションをダウンロードすることを許可する一定の免除権限を有する

これ以外には、未成年モードではゲーム、ソーシャルネットワーク、コンテンツ、広告等についての規制がありますね。。。

こういうことを国が決めようとするのが、中国っぽい感じなんですかね。。。昭和なおじさん、おばさんの中にもこういうアプローチが好きな人が多いのかもしれません...知らんけど...

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

・2023.08.02 国家互联网信息办公室关于《移动互联网未成年人模式建设指南（征求意见稿）》公开征求意见的通知

国家互联网信息办公室关于《移动互联网未成年人模式建设指南（征求意见稿）》公开征求意见的通知	国家サイバースペース管理局が「未成年者向けモバイルインターネットモデル構築ガイドライン（意見募集案）」の公開協議に関する通知
为切实强化未成年人网络保护，近年来，国家网信办指导网站平台持续推进青少年模式建设，扩大覆盖范围，优化功能设置，丰富适龄内容。模式自上线以来，普及率稳步提升，在帮助未成年人减少网络沉迷和不良信息影响方面发挥了积极作用。	インターネットにおける未成年者の保護を効果的に強化するため、近年、国家サイバースペース管理局は、ウェブサイトプラットフォームに対し、青少年モードの構築を継続的に推進し、カバー範囲を拡大し、機能設定を最適化し、年齢相応のコンテンツを充実させるよう指導してきた。 開始以来、このモデルの人気は着実に高まり、未成年者がインターネット中毒や好ましくない情報の影響を軽減する上で積極的な役割を果たしている。
为进一步提升模式效能，立足未成年人网络保护新形势新要求，国家网信办研究起草了《移动互联网未成年人模式建设指南（征求意见稿）》，将全面升级“青少年模式”为“未成年人模式”，推动模式覆盖范围由APP扩大到移动智能终端、应用商店，实现软硬件三方联动，方便用户一键进入模式，为未成年人营造安全健康的网络环境。现面向社会公开征求意见建议，欢迎社会各界积极参与。公众可通过以下途径和方式提出反馈意见：	同モードの有効性をさらに高めるため、国家サイバースペース管理局は、未成年者のネットワーク保護に関する新たな情勢と要求に基づき、「青少年モード」を「未成年者モード」に全面的にアップグレードし、同モードのカバー範囲を促進する「未成年者向けモバイルインターネットモデル構築ガイドライン（意見募集案）」を起草した。 「青少年モード」を「未成年者モード」に全面的にアップグレードし、APPからモバイルスマート端末、アプリケーションショップまで、モードのカバー範囲を拡大し、ソフトウェアとハードウェアの三位一体の連携を実現することで、ユーザーがワンクリックでモードに入ることができ、未成年者にとって安全で健全なネットワーク環境を構築する。 我々は現在、一般からの意見や提案を公募しており、コミュニティーの各界からの積極的な参加を歓迎している。 一般の方は、以下の方法・手段で意見を提出することができる：
...	...
国家互联网信息办公室	国家サイバースペース管理局
2023年8月2日	2023年8月2日
移动互联网未成年人模式建设指南	モバイルインターネット未成年者モード構築ガイドライン
（征求意见稿）	(意見募集案）
一、目的依据	I. 目的及び根拠
为了更好发挥互联网积极作用，营造良好网络环境，预防和干预未成年人网络沉迷问题，引导未成年人形成良好的网络使用习惯，按照《中华人民共和国网络安全法》《中华人民共和国个人信息保护法》《中华人民共和国未成年人保护法》等法律、行政法规，以及未成年人网络保护有关规定，制定本指南。	中華人民共和国ネットワーク安全法」、「中華人民共和国個人情報保護法」、「中華人民共和国未成年者保護法」及びその他の法律、行政法規、並びに未成年者のインターネット保護に関する関連規定に基づき、インターネットの積極的な役割をよりよく発揮させ、良好なネットワーク環境を構築し、未成年者のインターネット中毒の問題を予防・介入し、未成年者がインターネットを利用する良い習慣を形成するよう指導するために、本ガイドラインを策定する。 本ガイドラインを策定する。
二、适用范围	II. 適用範囲
本指南规定了各类移动智能终端、移动互联网应用程序（以下简称“应用程序”）、移动互联网应用程序分发服务平台（以下简称“应用程序分发平台”）的未成年人模式应满足的基本要求、功能要求和管理要求，适用于移动智能终端提供者、应用程序提供者以及应用程序分发平台提供者等相关主体开展未成年人模式的研发和应用。	本ガイドラインは、各種モバイルインテリジェント端末、モバイルインターネットアプリケーション（以下「アプリケーション」という）及びモバイルインターネットアプリケーション配信サービスプラットフォーム（以下「アプリケーション配信プラットフォーム」という）が未成年者モードに関して満たすべき基本要件、機能要件及び管理要件を規定する。 各種モバイルインテリジェント端末、モバイルインターネットアプリケーション（以下「アプリケーショ ン」という）及びモバイルインターネットアプリケーション配信サービスプラットフォーム（以下「アプリケーショ ン配信プラットフォーム」という）の未成年者モードについて、基本要求、機能要求及び管理要求を満たすこと。
三、通用规范	III. 一般仕様
（一）三方联动	（１）三者連携
移动智能终端、应用程序和应用程序分发平台之间应实现联动：	モバイルインテリジェント端末、アプリケーション及びアプリケーション配信プラットフォームは連携するものとする：
1.未成年人模式应具备自动切换功能。在移动智能终端一键启动未成年人模式后，应用程序、应用程序分发平台应自动切换到未成年人模式界面；在移动智能终端退出未成年人模式后，应用程序、应用程序分发平台应自动切换到普通模式界面。	1. 未成年モードは自動切替機能を有すること。 モバイルインテリジェント端末が1つのキーで未成年モードを起動した後、アプリケーションとアプリケーション配信プラットフォームは自動的に未成年モードインターフェースに切り替わり、モバイルインテリジェント端末が未成年モードを終了した後、アプリケーションとアプリケーション配信プラットフォームは自動的に通常モードインターフェースに切り替わる。
2.未成年人模式应支持家长或未成年人用户通过账号在多移动智能终端（包括同一厂家的相同类型或不同类型的多个移动智能终端）进行统一设置。用户通过登录统一账号，自动将该账号下其他移动智能终端的已有配置复制到本地并开启。	2. 未成年モードは、親または未成年ユーザーがアカウントを通じて複数のモバイルインテリジェント端末（同一メーカーの同一タイプまたは異なるタイプの複数のモバイルインテリジェント端末を含む）の統一設定を行うことをサポートする。 統一アカウントにログインすることで、ユーザーは自動的にアカウント下の他のモバイルインテリジェント端末の既存の設定をローカルにコピーし、それらを開く。
3.移动智能终端、应用程序、应用程序分发平台之间应提供必要接口和数据共享，满足未成年人防沉迷提醒、家长监督管理等功能。	3. 未成年者の反盗撮リマインダー機能及び保護者の監督管理機能を満たすため、モバイルスマート端末、アプリケーション及びアプリケーション配信プラットフォーム間で必要なインターフェース及びデータ共有が提供されなければならない。
（二）便捷使用	（２）利便性
1.为保护未成年人个人信息权益，鼓励家长为未成年人启动未成年人模式，移动智能终端、应用程序、应用程序分发平台应为家长管理提供便捷功能和服务，便于家长履行监护职责，引导未成年人形成良好上网习惯。	1. 未成年者の個人情報の権益を保護し、保護者に未成年者モードを起動させるよう促すため、モバイルスマート端末、アプリケーション及びアプリケーション配信プラットフォームは、保護者管理のための便利な機能及びサービスを提供し、保護者の保護責任の履行を促進し、未成年者が良好なオンライン習慣を形成するよう導かなければならない。
2.移动智能终端、应用程序、应用程序分发平台应当坚持最有利于未成年人的原则，提供有效识别违法信息和可能影响未成年人身心健康的信息、预防未成年人沉迷网络等功能，加强对未成年人的网络保护。	2. モバイルインテリジェント端末、アプリケーションおよびアプリケーション配信プラットフォームは、未成年者にとって最も好ましいという原則を堅持し、違法情報や未成年者の心身の健康に影響を与える可能性のある情報を効果的に識別し、未成年者のインターネット中毒を防止するなどの機能を提供し、インターネットにおける未成年者の保護を強化しなければならない。
3.移动智能终端、应用程序、应用程序分发平台应在未成年人模式下建立便捷、合理、有效的投诉、举报渠道，及时受理处置涉未成年人投诉举报。	3. モバイルインテリジェント端末、アプリケーションおよびアプリケーション配信プラットフォームは、未成年者モードの下で、便利で合理的かつ効果的な苦情・通報ルートを確立し、未成年者が関わる苦情・通報を速やかに受理・処理しなければならない。
（三）分龄原则	（３）年齢別原則
移动智能终端、应用程序以及应用程序分发平台应根据不同年龄阶段的未成年人身心发展特点，通过评估产品的类型、内容与功能等要素，为不同年龄阶段用户提供适合其身心发展的信息和服务。分龄化设计根据以下5个年龄区间划分：	モバイルインテリジェント端末、アプリケーションおよびアプリケーション配信プラットフォームは、年齢の異なる未成年者の身体的・精神的発達の特性に合わせて製品等の種類、内容、機能を評価し、年齢の異なる利用者の身体的・精神的発達に適した情報およびサービスを提供しなければならない。 年齢別デザインは、以下の5つの年齢ゾーンに基づいている：
1.不满3周岁；	1. 3歳未満
2.3周岁以上不满8周岁；	2. 3歳以上8歳未満；
3.8周岁以上不满12周岁；	3. 8歳以上12歳未満；
4.12周岁以上不满16周岁；	4. 12歳以上16歳未満；
5.16周岁以上不满18周岁。	5. 16歳以上18歳未満。
四、移动智能终端未成年人模式要求	IV. モバイルインテリジェント端末未成年モードの要件
（一）基本要求	（１）基本条件
1.未成年人模式入口	1. 未成年モードの入口
未成年人模式的入口设置应确保最简化原则。用户可通过开机提醒、桌面图标、系统设置等至少3种方式进入未成年人模式。模式入口应在固定位置、便捷易寻，满足家长和未成年人用户一键进入或切换。	未成年モードの入口設定は、最も簡単な原則を確保すること。 ユーザーは、ブートリマインダー、デスクトップアイコン、システム設定など、少なくとも3つの方法で未成年モードに入ることができる。 未成年者モードの入口は、親や未成年者がワンクリックで未成年者モードに入ったり切り替えたりできるように、便利で見つけやすい、固定された場所にあるべきである。
用户在首次登录未成年人模式时，移动智能终端应在入口提供设置生日、选择年龄或年龄区间等多种方式供用户自行选择，并允许设置多个未成年人信息。	利用者が初めて未成年者モードにログインする場合、モバイルインテリジェント端末は、誕生日の設定、年齢または年齢範囲の選択など、利用者が選択できる複数の方法を提供し、複数の未成年者情報を設定できるようにする。
用户可在首次开机或系统设置选择不需要未成年人模式，系统将不再出现相关提醒。	ユーザーは、初回起動時またはシステム設定時に、未成年モードを必要としないことを選択でき、システムは関連するリマインダーを表示しなくなる。
2.未成年人模式退出	2. 未成年モードからの退出
从未成年人模式退出时，需要家长进行验证同意，家长可基于现有移动智能终端认证机制，自行选择密码、指纹、人脸等识别方式进行单一或复合验证。	未成年モードから退出する際、保護者の同意確認が必要であり、保護者はモバイルインテリジェント端末の既存の認証メカニズムに基づき、パスワード、指紋、顔などの認証方式を選択し、単一認証または複合認証を行うことができる。
（二）使用时长管理	（２）利用時間管理
1.移动智能终端应为不同年龄段的未成年人用户提供差异化使用时长管理服务。当超过每日使用时限，移动智能终端应自动关闭除特定必要应用程序和家长自定义豁免的应用程序之外的其他应用程序：	1. モバイルインテリジェント端末は、年齢層の異なる未成年者の利用者に対して、差別化された利用時間管理サービスを提供しなければならない。 モバイルインテリジェント端末は、1日の利用制限時間を超過した場合、特定必要アプリケーション及び保護者カスタマイズ対象外アプリケーション以外のアプリケーションを自動的に終了する：
（1）在面向不满8周岁用户的未成年人模式中，移动智能终端应支持默认使用总时长不超过40分钟，同时提供家长豁免操作；	(1) 8歳未満の未成年者向けのモードでは、モバイルインテリジェント端末は、デフォルトの合計利用時間が40分を超えないようにサポートし、同時に保護者免除操作を提供すること；
（2）在面向8周岁以上不满16周岁用户的未成年人模式中，移动智能终端应支持默认使用总时长不超过1小时，同时提供家长豁免操作；	(2) 8歳以上16歳未満の未成年者向けモードでは、モバイルインテリジェント端末は、デフォルトの総使用時間が1時間を超えないようにサポートし、同時に保護者免除操作を提供すること；
（3）在面向16周岁以上不满18周岁用户的未成年人模式中，移动智能终端应支持默认使用总时长不超过2小时，同时提供家长豁免操作；	(3) 16歳以上18歳未満の未成年者モードでは、携帯情報端末はデフォルトの総使用時間を2時間以内とし、同時に保護者免除操作を提供すること；
（4）在未成年人模式下，当未成年人用户连续使用移动智能终端时长超过30分钟，移动智能终端应发出休息提醒；	(4) 未成年者モードでは、未成年者が30分以上連続して携帯情報端末を使用する場合、携帯情報端末は休息通知を発すること；
（5）在未成年人模式下，移动智能终端每日22时至次日6时期间禁止向未成年人提供服务；	(5) 未成年者モードでは、毎日22:00から翌日6:00までの間、携帯情報端末は未成年者に対してサービスを提供することができない；
（6）以下应用程序和业务不受上述使用时长和时间段限制：	(6) 以下のアプリケーションおよびサービスは、上記の利用時間および期間の制限を受けない：
①应急类：用于保障未成年人人身安全的产品和服务，包括紧急呼叫业务及移动智能终端自定义的用于保障未成年人的人身安全的应用程序；	① 緊急カテゴリ：未成年者の身の安全を守るために使用される製品およびサービス。緊急通報サービス、未成年者の身の安全を守るためにモバイルインテリジェント端末によってカスタマイズされたアプリケーションを含む；
②教育类：在有关主管部门备案的，为未成年人提供网课等教育服务的产品和服务；	② 教育カテゴリ：関係当局に申請し、未成年者にオンライン授業やその他の教育サービス製品およびサービスを提供する；
③适合未成年人使用的工具类：经应用程序分发平台认证的，适合未成年人身心发展的产品和服务，如部分图像处理、计算测量应用程序等；	③ 未成年者に適したツール：一部の画像処理、計算・計測アプリケーションなど、未成年者の心身の発達に適したアプリケーション配信プラットフォームが認定した製品・サービス；
④家长自定义设置可被豁免的应用程序。	④ 保護者のカスタマイズ設定により免除可能なアプリ。
2.在移动智能终端的未成年人模式中，家长使用时间管控功能应至少满足如下功能：	2. モバイルインテリジェント端末の未成年モードにおいて、保護者による利用時間制御機能は、少なくとも以下の機能を満たさなければならない：
（1）设置移动智能终端整机使用时长；	(1) モバイルインテリジェント端末の全使用時間を設定する；
（2）设置移动智能终端整机使用时间段，可根据具体需要，设置某个或者多个使用时间段；	(2) モバイルインテリジェント端末の全使用時間帯を設定し、特定のニーズに応じて1つ以上の使用時間帯を設定できる；
（3）设置指定应用程序使用时间；	(3) 指定アプリケーションの使用時間を設定する；
（4）禁止未成年人修改移动智能终端的系统日期和时间。	(4) 未成年者がモバイルインテリジェント端末のシステム日時を変更することを禁止する。
（三）防绕过要求	（３）バイパス防止要件
1.移动智能终端应具备防绕过功能。在进入未成年人模式后，移动智能终端应在家长验证并确认后才能执行退出未成年人模式或恢复出厂设置等操作。	1. モバイルインテリジェント端末は、バイパス防止機能を有すること。 モバイルインテリジェント端末は、未成年者モードに移行した後、保護者が確認した後、未成年者モードを終了したり、工場出荷時の設定に戻したりする操作を行うこと。
2.开启未成年人模式的移动智能终端应确保提供未成年人模式服务功能的图标始终保持在桌面一级页面，不被卸载、冻结和隐藏，进程不被强制结束。	2. 未成年モードを有効にしたモバイルインテリジェント端末は、未成年モードのサービス機能を提供するアイコンが常にデスクトップレベルのページに留まり、アンインストール、フリーズ、非表示にならず、プロセスが強制終了されないようにしなければならない。
3.在未成年人模式下，如需启动开发者模式，应经家长验证并确认。	3 .未成年モードで開発者モードを有効にする必要がある場合は、保護者による確認・検証を行うこと。
（四）补充要求	（４）追加要件
1.由于未成年人的视觉、听觉等生理和心理尚未发育成熟，鼓励移动智能终端利用技术手段降低或消除未成年人在使用移动智能终端过程中可能出现的危害。	1. 未成年者は視覚、聴覚などの生理的、心理的発達が未熟であるため、未成年者がモバイルインテリジェント端末を使用する際に発生する可能性のある危険を低減または除去するための技術的手段を利用することが奨励される。
2.移动智能终端应提供未成年人用户紧急向关联的家长用户终端发送位置和进行呼叫的服务。	2. モバイルインテリジェント端末は、未成年者が緊急時に、関連する親ユーザー端末に位置情報を送信したり、電話をかけたりするサービスを提供しなければならない。
3.儿童智能手表、早教机、智能音箱等儿童智能设备，及虚拟现实/增强现实（VR/AR）可穿戴设备在为未成年人提供服务时，应遵守本规定中的相关条款，确保信息内容安全可控，防范未成年人产生网络沉迷或接触可能影响身心健康的信息。	3. 児童用スマートウォッチ、早期学習機、スマートスピーカー、VR/ARウェアラブルデバイスなどの児童用知能端末は、未成年者にサービスを提供する場合、本規定の関連規定を遵守し、情報内容の安全性と制御性を確保し、未成年者がインターネット中毒になったり、心身の健康に影響を及ぼす可能性のある情報に接触したりすることを防止しなければならない。
4.现有应用程序中的青少年模式，应在移动智能终端普通模式下予以保留，并按照本指南的有关要求进行升级改造，为未成年人在普通模式下使用现有应用程序提供安全防护。	4 .既存アプリケーションの青少年モードは、モバイルインテリジェント端末の通常モードで維持し、本ガイドラインの関連要件に従ってアップグレードし、通常モードで既存アプリケーションを使用する未成年者のセキュリティ保護を提供する。
五、移动互联网应用程序未成年人模式要求	V. モバイルインターネットアプリケーションの未成年者モードに関する要求事項
（一）基本要求	（１）基本要件
在未成年人模式下移动互联网信息服务提供者应为未成年人提供分龄内容服务，并打造专属内容池。适龄推荐内容如下：	モバイルインターネット情報サービス提供者は、未成年者モードにおいて、未成年に適したコンテンツサービスを提供し、専用のコンテンツプールを作成しなければならない。 年齢相応の推奨コンテンツは以下の通りである：
1.不满3周岁：推荐儿歌、启蒙教育等亲子陪伴类节目内容，建议以音频为主；	1. 3歳未満：童謡、啓蒙教育などの親子連れの番組を推奨コンテンツとし、音声を重視することを推奨する；
2.3周岁以上不满8周岁：推荐启蒙教育、兴趣素养、通识教育等节目内容；	2. 3歳以上8歳未満：啓蒙教育、興味と識字、一般教育などの番組を推奨する；
3.8周岁以上不满12周岁：推荐通识教育、知识科普、生活技能、具有正向引导意义的娱乐性内容和适合本年龄段认知能力的新闻资讯等；	3. 8歳以上12歳未満：一般教育、科学の知識と普及、ライフスキル、積極的な指導を伴う娯楽コンテンツ、この年齢層の認知能力に適したニュースや情報など；
4.12周岁以上不满16周岁：推荐通识教育、学科教育、知识科普、生活技能、具有正向引导意义的娱乐性内容和适合本年龄段认知能力的新闻资讯等。	4. 12歳以上16歳未満：一般教育、教科教育、科学の知識と普及、ライフスキル、積極的な指導による娯楽コンテンツ、この年齢層の認知能力に適したニュースや情報。
5.16周岁以上不满18周岁：推荐适合本年龄段认知能力、健康向上的信息内容。	5. 16歳以上18歳未満：この年齢層の認知能力に適した、健康で上向きの情報コンテンツを推奨する。
鼓励移动互联网信息服务提供者根据分龄要求对未成年人专属内容池中的内容进行适龄推荐标注。	モバイルインターネット情報サービス提供者は、年齢別要件に従い、未成年者専用コンテンツプールのコンテンツについて、年齢に適した推奨ラベルを作成することが奨励される。
（二）内容安全要求	（２）コンテンツの安全性要件
在未成年人模式下移动互联网信息服务提供者应履行主体责任，保障未成年人接触的信息内容安全：	未成年者モードにおいて、モバイルインターネット情報サービス提供者は、未成年者がアクセスできる情報コンテンツの安全性を確保する主な責任を果たさなければならない：
1.在未成年人模式下移动互联网信息服务提供者应积极开展未成年人内容池建设。制作、复制、发布、传播弘扬社会主义核心价值观和社会主义先进文化、革命文化、中华优秀传统文化，铸牢中华民族共同体意识，培养未成年人家国情怀和良好品德，引导未成年人养成良好生活习惯和行为习惯等的网络信息，营造有利于未成年人健康成长的清朗网络空间和良好网络生态。	1. 未成年者モードのモバイルインターネット情報サービス提供者は、未成年者向けコンテンツプールの構築を積極的に実施しなければならない。 社会主義の核心的価値観と先進的な社会主義文化、革命文化、優れた中国伝統文化を促進し、中華民族の共同体意識を鍛え、未成年者の家族意識と国家意識、善良な風紀を養い、未成年者が良い生活習慣と行動習慣を身につけるよう導くネットワーク情報などを制作、コピー、出版、普及し、未成年者の健全な成長に資する明確なサイバースペースと良好なネットワーク生態を創造する。
2.移动互联网信息服务提供者应履行主体责任，在未成年人模式下不应出现任何形式向未成年人用户提供诱导其沉迷或不利于其身心健康的相关产品和服务：	2. モバイルインターネット情報サービス提供者は、その主な責任を果たすものとし、未成年者モードの下で、いかなる形であれ、未成年者の中毒を誘発したり、心身の健康を害したりするような関連商品やサービスを未成年者の利用者に提供してはならない：
（1）禁止利用网络制作、复制、发布、传播含有危害未成年人身心健康内容的信息，禁止向未成年人发送含有危害或者可能影响未成年人身心健康内容的信息；	(1)未成年者の心身の健康に有害な内容を含む情報を作成、複製、出版、流布するためにネットワークを使用することを禁止し、未成年者の心身の健康に有害な、または影響を与える可能性のある内容を含む情報を未成年者に送信することを禁止する；
（2）禁止制作、复制、发布、传播或者持有有关未成年人的淫秽色情网络信息，禁止诱骗、强迫未成年人制作、复制、发布、传播可能暴露其个人隐私的文字、图片、音视频；	(2) 未成年者に関するわいせつ・ポルノ的なインターネット情報を作成、コピー、出版、流布、所持することを禁止し、未成年者が個人のプライバシーを暴露する可能性のある文章、写真、音声、映像を作成、コピー、出版、流布するよう誘引または強制することを禁止する；
（3）禁止制作、复制、发布、传播可能引发或者诱导未成年人模仿不安全行为、实施违反社会公德行为、产生不良情绪、养成不良嗜好等可能影响未成年人身心健康的信息。	(3) 未成年者が危険な行為を模倣したり、社会道徳に反する行為をしたり、悪い感情を抱いたり、悪い趣味を持つなど、未成年者の心身の健康に影響を与える可能性のある情報を作成、複製、公表、流布することを禁止する。
（三）功能限制要求	（３）機能制限要件
在未成年人模式下移动互联网信息服务提供者应限制未成年人用户使用可能危害其身心健康的产品和服务：	未成年者向け携帯インターネット情報サービス事業者は、未成年者の心身の健康を損なうおそれのある商品・サービスの利用を制限しなければならない：
1.网络直播、网络音视频、网络社交等网络服务提供者应针对未成年人使用其服务设置相应的时间管理、权限管理、消费管理等功能。	1. ウェブキャスティング、ネットワークオーディオ・ビデオ、ネットワークソーシャルネットワーキングサービス提供者は、未成年者がサービスを利用する際に、時間管理、権限管理、消費管理などの機能を設けなければならない。
2.网络直播、网络音视频、网络社交等网络服务提供者应采取措施，合理限制未成年人在使用网络产品和服务中的单次消费数额和单日累计消费数额，不得向未成年人提供与其民事行为能力不符的付费服务。	2. ウェブキャスティング、ネットワークオーディオ・ビデオ、ネットワークソーシャルネットワーキングおよびその他のネットワークサービスの提供者は、未成年者によるネットワーク製品およびサービスの利用において、1回の消費量および1日の累積消費量を合理的に制限する措置を講じなければならず、未成年者の市民的行動能力にそぐわない有料サービスを提供してはならない。
3.未成年人模式下不得设置以应援集资、投票打榜、刷量控评等为主题的网络社区、群组、话题，不得利用泛娱乐化功能和内容诱导未成年人沉迷网络。	3. 未成年者モードで、支援・募金、投票・ランキング、ブラッシュボリューム、コメント制御などをテーマとするオンラインコミュニティ、グループ、トピックを設置してはならず、汎用の娯楽機能やコンテンツを利用して未成年者のインターネット中毒を誘発してはならない。
4.网络游戏的防沉迷要求应遵守相关管理规定。	4. オンラインゲームの中毒防止要求は、関連管理規定に従う。
5.在线教育网络产品和服务不得插入网络游戏链接，不得推送广告等与教学无关的信息。	5. オンライン教育ネットワーク製品およびサービスは、オンラインゲームへのリンクを挿入してはならず、教育と無関係な広告およびその他の情報をプッシュしてはならない。
6.算法推荐服务提供者不得向未成年人推送可能引发未成年人模仿不安全行为和违反社会公德行为、诱导未成年人不良嗜好等可能影响未成年人身心健康的信息，不得利用算法推荐服务诱导未成年人沉迷网络。	6. アルゴリズム推薦サービス提供者は、未成年者に安全でない行動を模倣させ、社会道徳に違反する可能性のある情報、未成年者に悪い習慣を誘発させる可能性のある情報、その他未成年者の心身の健康に影響を与える可能性のある情報を未成年者にプッシュしてはならず、アルゴリズム推薦サービスを利用して未成年者のインターネット中毒を誘発してはならない。
7.鼓励应用程序开发者遵照相关法律法规，开发适应未成年人身心健康发展规律和特点的应用程序，帮助未成年人培养良好网络素养。	7. アプリケーション開発者は、関連法令を遵守し、未成年者の心身の健康発達の法令や特性に適応したアプリケーションを開発し、未成年者が良好なネットワークリテラシーを培うことを支援することが奨励される。
（四）社交管理要求	（４）ソーシャル管理要件
1.应用程序应为未成年人及家长提供社交管理权限，允许关注或屏蔽特定用户，限定特定信息的公开范围。	1. アプリは、未成年者とその保護者にソーシャル管理権を提供し、特定のユーザーに注目したり、ブロックしたり、特定の情報の公開範囲を制限したりできるようにしなければならない。
2.社交类应用程序不应在未成年人模式中为容易产生网络沉迷或使未成年人接触不利于其身心健康的互联网信息提供外链。	2. ソーシャルアプリケーションは、未成年者モードにおいて、インターネット中毒を生じさせたり、未成年者の心身の健康を害するような情報に触れさせる可能性のあるインターネット情報への外部リンクを提供してはならない。
3.除即时通讯工具以外的应用程序，在未成年人模式下应关闭陌生人私信功能。	3. インスタントメッセンジャー以外のアプリケーションは、未成年者向けモードにおいて、見知らぬ人からのプライベートメッセージの機能を閉じるべきである。
六、移动互联网应用程序分发服务平台未成年人模式要求	VI. モバイルインターネットアプリケーション配信サービスプラットフォームの未成年モードに関する要件
（一）基本要求	（１）基本要件
1.应用程序分发平台应提供未成年人应用专区，便利未成年人获取有益身心健康的平台内产品或者服务；	1. アプリケーション配信プラットフォームは、未成年者がプラットフォーム内の心身の健康に有益な製品またはサービスにアクセスすることを容易にするために、未成年者向けの特別ゾーンを提供しなければならない；
2.应用程序分发平台应根据不同年龄段未成年人的身心特点和认知水平，标注应用程序的推荐年龄，提供适宜不同年龄段未成年人的应用程序。	2. アプリケーション配信プラットフォームは、異なる年齢層の未成年者の心身の特性及び認知レベルに応じて、アプリケーションの推奨年齢を表示し、異なる年齢層の未成年者に適したアプリケーションを提供すること。
（二）未成年人专区建设要求	（２）未成年者専用エリアの構築要件
应用程序分发平台应根据相关管理要求，加强未成年人专区建设：	アプリケーション配信プラットフォームは、関連する管理要件に従い、未成年者専用エリアの構築を強化しなければならない：
1.应用程序提供者应当坚持最有利于未成年人的原则，关注未成年人健康成长，履行未成年人网络保护各项义务，严格落实未成年人用户账号实名注册和登录要求，不得以任何形式向未成年人用户提供诱导其沉迷的相关产品和服务。	1. アプリケーション提供者は、未成年者にとって最も好ましいという原則を堅持し、未成年者の健全な成長に配慮し、インターネット上の未成年者保護に関するすべての義務を履行し、未成年者のユーザーアカウントに対する実名登録およびログインの要件を厳格に履行し、未成年者が当該製品およびサービスに依存するよう誘導するいかなる形態でも、未成年者に関連製品およびサービスを提供してはならない。
2.鼓励教育、益智、科普、读书、音乐、体育等有利于未成年人身心健康的应用程序在未成年人专区中上架。	2. 教育、教養、大衆科学、読書、音楽、スポーツアプリケーションなど、未成年者の心身の健康に資するアプリケーションは、未成年者向けの特別エリアにアップロードするよう奨励すること。
3.有关部门针对各年龄段特点明确禁用的应用程序，不得在未成年人模式下的应用程序分发平台上架。	3. 各年齢層の特性上、関連部門が明確に禁止しているアプリは、未成年者モードのアプリ配信プラットフォームに棚上げしてはならない。
（三）下载安全	（３）ダウンロードの安全性
应用程序分发平台应根据有关法律法规对各类网络应用程序和服务准入未成年人模式进行审核和处置：	アプリ配信プラットフォームは、関連法規に従い、未成年者モードにアクセスする各種ネットワークアプリとサービスを審査・処分しなければならない：
1.明确产品所适合的未成年人用户年龄阶段，并在用户下载、注册、登录界面等位置显著提示。	1. 未成年者の年齢段階を定義し、製品のダウンロード、登録、ログインのインターフェースおよびその他の場所に明示する。
2.应用程序分发平台应根据未成年人的年龄特点，为未成年人用户提供差异化下载服务，并确保家长可以对未成年人模式下的应用程序下载和安装进行审核或豁免：	2. アプリケーション配信プラットフォームは、未成年者の年齢特性に応じて、未成年者向けの差別化されたダウンロードサービスを提供し、保護者が未成年者モードでのアプリケーションのダウンロードおよびインストールを審査または免除できるようにすること：
（1）不满12周岁的未成年人用户下载、安装未成年人专区中的应用程序时，需经家长同意；家长具备一定的豁免权力，允许未成年人下载未成年人专区以外的应用程序；	(1)12歳未満の未成年者が未成年者向けゾーンでアプリケーションをダウンロードおよびインストールするには保護者の同意が必要であり、保護者は未成年者が未成年者向けゾーン外でアプリケーションをダウンロードすることを許可する一定の免除権限を有する；
（2）12周岁以上不满16周岁的未成年人用户可自行下载、安装未成年人专区中的应用程序，家长具备一定的豁免权力，允许未成年人下载未成年人专区以外的应用程序。	(2)12歳以上16歳未満の未成年者は、未成年者向けゾーンのアプリケーションを自らダウンロード・インストールすることができ、保護者は一定の免責権限を有し、未成年者向けゾーンの外で未成年者にアプリケーションをダウンロードさせることができる。
3.禁止通过外链下载应用程序，家长审核并豁免的除外。	3. 保護者が審査し、免除したものを除き、外部リンクを通じたアプリケーションのダウンロードは禁止する。
4.应用程序分发平台应建立相关举报机制，加强用户对未成年人模式中的信息内容与服务进行监督，必要时根据相关管理要求对有关应用程序予以下架处理。	4. アプリケーション配信プラットフォームは、未成年者モードにおける情報コンテンツおよびサービスに対するユーザーの監督を強化するため、関連する報告メカニズムを構築し、必要に応じて、関連する管理要件に従い、関連するアプリケーションを削除しなければならない。
七、家长管理	VII. 保護者管理
（一）基本要求	（１）基本要件
未成年人模式下，移动智能终端、应用程序、应用程序分发平台应为家长提供管理权限，保障家长能够对指定的未成年人用户进行日常和应急状态管理，更好监督引导未成年人用户上网行为：	未成年者モードにおいて、モバイルスマート端末、アプリケーションおよびアプリケーション配信プラットフォームは、保護者に管理権限を提供し、保護者が指定された未成年者の利用者の日常管理および緊急管理を実施できるようにし、未成年者の利用者のオンライン行動をよりよく監督・指導しなければならない：
1.移动智能终端、应用程序、应用程序分发平台应为家长提供对未成年人使用时长、信息服务接收、应用程序下载安装等方面的管理权限，满足家长对未成年人用户的监督、豁免和审核需求。	1. モバイルスマート端末、アプリケーション及びアプリケーション配信プラットフォームは、未成年者の利用期間、情報サービスの受信及びアプリケーションのダウンロードとインストールに関して、保護者に管理権限を提供し、未成年者の利用者に対する監督、免除及び監査に関する保護者のニーズを満足させなければならない。
2.移动智能终端应为未成年人账号提供至少1个亲情号绑定作为家长账号，该账号可满足家长与未成年人同终端和异终端使用，并可同时关联应用程序和应用程序分发平台。	2. モバイルスマート端末は、未成年者のアカウントを保護者のアカウントとしてバインドするために、少なくとも1つの親和番号を提供しなければならず、これは、保護者と未成年者が同じ端末および異なる端末を使用するニーズを満たすことができ、同時にアプリケーションおよびアプリケーション配信プラットフォームと関連付けることができる。
（二）家长对未成年人移动智能终端使用时间的管理	（２）未成年者のモバイルインテリジェント端末利用時間の保護者管理
移动智能终端和应用程序应为未成年人及其家长提供防沉迷提醒，允许家长对未成年人移动智能终端的使用时间进行监督指导：	モバイルインテリジェント端末及びアプリケーションは、未成年者及びその保護者に対し、不注意防止のリマインダーを提供し、保護者が未成年者のモバイルインテリジェント端末の利用時間を監督・指導できるようにしなければならない：
1.移动智能终端应定期向家长提供未成年人用户在未成年人模式下的使用时长、各应用程序使用时长、上网时长等概览报告，协助家长对未成年人网络行为进行监督。	1. モバイルインテリジェント端末は、未成年者の未成年者モードでの利用時間、各アプリケーションの利用時間、インターネット利用時間の概要報告を定期的に保護者に提供し、保護者が未成年者のオンライン行動を監督できるように支援する。
2.当未成年人用户的使用时长超过本规定所建议的时间限制时，可由未成年人用户向关联的家长用户发出豁免申请。	2. 未成年ユーザーの利用時間が本規定で提示された制限時間を超える場合、未成年ユーザーから関連する親ユーザーに免除申請を送ることができる。
（三）家长对未成年人信息服务内容的管理	（３）未成年者向け情報サービスのコンテンツの保護者による管理
家长可以使用关联账号对未成年人模式下的信息内容提供审核和豁免功能：	保護者は、関連アカウントを使用して、未成年者モード下の情報コンテンツの監査および免除機能を提供することができる：
1.家长可对非专属内容池的信息进行豁免，加入到指定未成年人用户的内容池中。	1. 保護者は、非排他的コンテンツプールから情報を除外し、指定された未成年ユーザーのコンテンツプールに追加することができる。
2.鼓励家长对非专属内容池的内容进行标注和建议，为平台丰富专属内容池建设提供依据。	2. 保護者は、非排他的コンテンツプールのコンテンツをマークし、提案することができ、プラットフォームが排他的コンテンツプールの構築を充実させる基礎となる。
（四）家长对未成年人应用程序使用的管理	（４）未成年者によるアプリ使用の保護者管理
家长可以使用关联账号对未成年人模式下的应用程序下载进行审核，豁免或禁止用户下载及安装特定应用程序。包括：	保護者は関連アカウントを使用して、未成年者モードでのアプリケーションのダウンロードを確認し、特定のアプリケーションのダウンロードとインストールを免除または禁止することができる。 以下を含む：
1.为特定应用程序开放始终豁免的权限，如对辅助教育类应用程序开放未成年人长期使用权限。	1. 補助教育アプリの未成年者向け長期使用許可など、特定のアプリの常時免除権限を開放する。
2.为特定应用程序开放限时使用权限，如根据需要，对适合未成年人身心发展的工具类应用程序开放特定时间段内使用的权限。	2. 未成年者の心身の発達に適したツールについて、特定の期間内の利用を許可するなど、特定のアプリについて、必要に応じて期間限定の利用許可を開放する。
3.将特定应用程序和功能设置为始终禁止使用，期间相关应用程序不得弹出通知，不得被调取使用。	3. 特定のアプリや機能を常時利用禁止に設定し、その間は当該アプリの通知ポップアップを禁止し、アクセスしても利用できないようにすること。
4.相关法规明令禁止未成年人使用的应用程序和服务，不得被豁免。	4. 関連法規で未成年者の利用が明示的に禁止されているアプリやサービスは適用除外としない。
八、管理要求	VIII. 管理要件
（一）移动智能终端、应用程序、应用程序分发平台应积极配合有关管理部门开展的监督检查，提供必要的技术、数据等支持和协助。	（１）モバイルインテリジェント端末、アプリケーションおよびアプリケーション配信プラットフォームは、関連管理部門が実施する監督検査に積極的に協力し、必要な技術、データおよびその他のサポートと支援を提供しなければならない。
（二）向未成年人用户提供服务的移动智能终端、应用程序、应用程序分发平台，应定期开展未成年人网络保护影响评估。	（２）未成年の利用者にサービスを提供するモバイルインテリジェント端末、アプリケーションおよびアプリケーション配信プラットフォームは、未成年のネットワーク保護に関する影響評価を定期的に実施しなければならない。
（三）向未成年人用户提供服务的移动智能终端、应用程序、应用程序分发平台，应建立必要应急响应机制，确保保护未成年人用户人身安全的应急类业务不被屏蔽。	（３）未成年者にサービスを提供するモバイルインテリジェント端末、アプリケーション及びアプリケーション配信プラットフォームは、未成年者の身の安全を守るための緊急型サービスが遮断されないよう、必要な緊急対応メカニズムを構築しなければならない。
（四）在未成年人模式下移动互联网信息服务提供者应依照相关法律法规提供服务，不应超范围收集用户数据。	（４）未成年者モードのモバイルインターネット情報サービス提供者は、関連法規に従っ てサービスを提供し、その範囲を超えて利用者データを収集してはならない。
附录 术语和定义	付録 用語と定義
（1）未成年人模式	（１）未成年者モード
本《指南》所称未成年人模式，是指适应未成年人身心健康发展规律和特点，专门面向未成年人使用，覆盖移动智能终端、移动互联网应用程序和移动互联网应用程序分发平台的网络保护模式。	本ガイドでいう未成年者モードとは、未成年者の心身の健康発達に関する法律及び特性に適応し、特に未成年者の利用を指向するネットワーク保護モードを指し、モバイルインテリジェント端末、モバイルインターネットアプリケーション及びモバイルインターネットアプリケーション配信プラットフォームを対象とする。
（2）移动智能终端	（２）モバイルインテリジェント端末
移动智能终端是指接入公众移动通信网络、具有操作系统、可由用户自行安装运行和卸载应用程序的移动终端产品，包括智能手机、平板电脑、儿童智能手表、早教机等智能终端和智能可穿戴设备。	モバイルインテリジェント端末とは、公衆移動通信網に接続され、オペレーティングシステムを持ち、ユーザーがインストール、実行、アンインストールできるモバイル端末製品を指し、スマートフォン、タブレットPC、子供用スマートウォッチ、幼児教育機、その他のインテリジェント端末、インテリジェントウェアラブルデバイスを含む。
（3）移动互联网应用程序	（３）モバイルインターネットアプリケーション
移动互联网应用程序指通过应用程序向用户提供文字、图片、音频、视频等信息制作、复制、发布、传播等服务的软件。	モバイルインターネットアプリケーションとは、アプリケーションを通じて、テキスト、画像、音声、映像、その他の情報の制作、複製、配信、普及などのサービスをユーザーに提供するソフトウェアを指す。
（4）移动互联网应用程序分发服务平台	（４）モバイルインターネットアプリケーション配信サービスプラットフォーム
移动互联网应用程序分发服务平台指通过互联网提供应用程序发布、下载、动态加载等服务的平台，包括应用商店、应用中心、互联网小程序平台等。	モバイルインターネットアプリケーション配信サービスプラットフォームとは、アプリケーションショップ、アプリケーションセンター、インターネットアプレットプラットフォームなど、インターネットを通じてアプリケーションのリリース、ダウンロード、ダイナミックローディングなどのサービスを提供するプラットフォームを指す。

---

JETROの説明がわかりやすいかもです。。。

● JETRO

・2023.08.15 スマートフォン経由での未成年者のインターネット利用時間を制限へ