NIST SP 1800-35 (ドラフト) ゼロトラストアーキテクチャの実装（初期ドラフト）(Vol. B)
こんにちは、丸山満彦です。
NISTがSP 1800-35 (ドラフト) ゼロトラストアーキテクチャの実装（初期ドラフト）を公表し、意見募集をしていますね。。。
先月はサマリーにあたる、NIST SP 1800-35A: Executive Summaryを発表していますが、今回は本文にあたる、NIST SP 1800-35B: Approach, Architecture, and Security Characteristics – what we built and whyとなりますね。。。
● NIST - ITL
・2022.07.07 SP 1800-35 (Draft) Implementing a Zero Trust Architecture (Preliminary Draft)
| SP 1800-35 (Draft) Implementing a Zero Trust Architecture (Preliminary Draft) | SP 1800-35 (ドラフト) ゼロトラストアーキテクチャの実装(初期ドラフト) |
| Announcement | 発表 |
| The Zero Trust Architecture (ZTA) team at NIST's National Cybersecurity Center of Excellence (NCCoE) has published volume B of a preliminary draft practice guide titled "Implementing a Zero Trust Architecture" and is seeking the public's comments on its contents. This guide summarizes how the NCCoE and its collaborators are using 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. As the project progresses, the preliminary draft will be updated, and additional volumes will also be released for comment. | NISTのナショナル・サイバーセキュリティ・センター・オブ・エクセレンス（NCCoE）のゼロトラスト・アーキテクチャ（ZTA）チームは、「ゼロトラストアーキテクチャの実装」と題した実践ガイドの初期ドラフトB巻を公開し、その内容に関する一般からのコメントを求めています。このガイドは、NCCoEとその協力者が、NIST Special Publication (SP) 800-207, ゼロトラスト・アーキテクチャの概念と原則に沿った、相互運用可能でオープンスタンダードに基づくZTA実装を、市販の技術を使用して構築する方法を要約したものです。プロジェクトの進捗に伴い、この暫定版は更新され、コメントのために追加版がリリースされる予定です。 |
| 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 the requester’s identity and role, the requesting device’s health and credentials, and the sensitivity of the resource. 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）は、データとリソースの保護に重点を置いています。オンプレミスや複数のクラウド環境に分散している企業リソースへの安全な認証アクセスを可能にし、ハイブリッドワーカーやパートナーが、いつでも、どこからでも、どんなデバイスからでも、組織のミッションをサポートするためにリソースにアクセスできるようにします。各アクセス要求は、アクセス時に利用可能なコンテキスト（要求者のアイデンティティや役割、要求デバイスの状態や認証情報、リソースの機密性など）を検証することで評価されます。企業で定義されたアクセスポリシーに適合する場合、リソースとの間で転送されるすべての情報を保護するために安全なセッションが作成されます。リアルタイムかつ継続的に、ポリシーに基づいたリスクベースの評価が行われ、アクセスの確立と維持が行われます。このプロジェクトでは、NCCoEとその協力者は、市販の技術を使用して、NIST Special Publication (SP) 800-207「Zero Trust Architecture」の概念と原則に沿った、相互運用可能でオープン、標準ベースのZTA実装を構築しています。このNISTサイバーセキュリティ実践ガイドは、市販の技術を統合し、さまざまなZTAを構築するために使用する方法について説明しています。 |
・[PDF] NIST SP 1800-35B iprd
追加情報...
・[PDF] NIST SP 1800-35A iprd
・[web] Project homepage
サマリーに記載されている課題、解決策、利点...
課題
| 1.1 Challenge | 1.1 課題 |
| Protecting enterprise resources, particularly data, has become increasingly challenging as resources have become distributed across both on-premises environments and multiple clouds. Many users need access from anywhere, at any time, from any device to support the organization’s mission. Data is programmatically stored, transmitted, and processed across different boundaries under the control of different organizations to meet ever-evolving business use cases. It is no longer feasible to simply enforce access controls at the perimeter of the enterprise environment and assume that all subjects[1] (i.e., end users, applications, and other non-human entities that request information from resources) within it can be trusted. A zero-trust architecture (ZTA) addresses this challenge by enforcing granular, secure authorized access near the resources, whether located on-premises or in the cloud, for a remote workforce and partners based on an organization’s defined access policy. | 企業のリソース、特にデータの保護は、オンプレミス環境と複数のクラウドの両方にリソースが分散するようになったため、ますます困難になってきています。多くのユーザーは、組織のミッションをサポートするために、いつでも、どこからでも、どんなデバイスからでもアクセスできる必要があります。データは、進化し続けるビジネスユースケースに対応するために、異なる組織の管理下で、異なる境界を越えてプログラム的に保存、送信、処理されます。もはや、企業環境の境界でアクセス制御を実施し、その中にいるすべての主体（エンドユーザー、アプリケーション、リソースに情報を要求するその他の非人間的主体）が信頼できると仮定することは不可能です[1]。ゼロトラストアーキテクチャ（ZTA）は、組織が定義したアクセスポリシーに基づいて、オンプレミスまたはクラウドにあるリモートワーカーとパートナーに対して、リソースの近くできめ細かく安全な認証アクセスを実施することで、この課題に対応します。 |
| Many organizations would like to address these challenges by migrating to a ZTA, but they have been hindered by several factors, such as the following: | 多くの組織は、ZTAへの移行によってこれらの課題に対処したいと考えていますが、以下のようないくつかの要因によって妨げられています。 |
| § No single ZTA solution exists; ZTA deployment requires leveraging integration of many deployed existing technologies that are of varying maturity and may not all have been designed to interoperate with each other. It also requires organizations to identify technology gaps to build a complete ZTA. | § ZTAの導入には、成熟度がまちまちで、相互運用を前提に設計されていない可能性のある、多くの導入済み既存テクノロジーの統合を活用する必要があります。また、完全なZTAを構築するために、組織はテクノロジーギャップを特定する必要があります。 |
| § Organizations may lack the time and resources to sort out what combination of ZTA technologies would work best for them. | § 組織は、どのようなZTAテクノロジーの組み合わせが最適かを整理するための時間やリソースが不足している可能性があります。 |
| § ZTA requires organizations to identify and prioritize their resources and develop explicit policies for determining the conditions that must be met in order for a subject to be granted access to each resource. These conditions can depend on many factors beyond the traditional ones of subject identity and role; they may involve attributes such as subject and resource location, time of day, and the device being used and its health status. Some organizations may find the need to develop and manage such policies daunting. | § ZTAの導入には、組織がリソースを特定し、優先順位を付け、対象者が各リソースへのアクセス を許可されるために満たさなければならない条件を決定するための明確なポリシーを開発することが必要となります。これらの条件は、対象者のアイデンティティと役割という従来のものだけでなく、対象者とリソースの場所、時間帯、使用されているデバイスとその状態などの属性に依存する可能性があります。組織によっては、このようなポリシーを策定し管理する必要性を困難に感じる場合があるでしょう。 |
| § Often organizations do not have a complete inventory of their assets or a clear understanding of the criticality of their data. They also do not fully understand the transactions that occur between subjects, resources, applications, and services. | § 多くの場合、組織は資産の完全な台帳を持っておらず、データの重要性を明確に理解していません。また、サブジェクト、リソース、アプリケーション、およびサービス間で発生するトランザクションを完全に理解しているわけでもありません。 |
| § Many organizations have a heavy investment in legacy enterprise and cloud technologies and don’t have a clear understanding of how they can continue to leverage existing investments and balance priorities while also gradually integrating new technologies to make progress toward ZTA. | § 多くの企業は、レガシーのエンタープライズテクノロジーやクラウドテクノロジーに多大な投資をしており、既存の投資を継続的に活用し、優先順位のバランスを取りながら、新しいテクノロジーを徐々に統合して ZTA に向けて前進する方法について明確には理解していません。 |
| § Organizations may not understand what interoperability issues may be involved or what additional skills and training network administrators may require, and they may lack the resources to develop a pilot or proof-of-concept implementation needed to inform a transition plan. | § 組織は、相互運用性の問題や、ネットワーク管理者が必要とする追加的なスキルやトレーニングを理解していない可能性があります。また、移行計画に必要なパイロット版や概念実証版を開発するためのリソースが不足している可能性もあります。 |
| § Organizations also have concerns that use of ZTA might negatively impact the operation of the environment or the end-user experience. Ideally, ZTA should enhance security in a way that is transparent to the user, but there is some possibility that users could be negatively impacted, for example, by having to repeatedly re-authenticate themselves depending on the resources they are accessing and the strictness of enterprise security policies. | § また、ZTAの利用が環境の運用やエンドユーザー・エクスペリエンスに悪影響を与えるのではないかという懸念もあります。理想的には、ZTAはユーザーに対して透過的にセキュリティを強化すべきですが、例えば、アクセスするリソースや企業のセキュリティポリシーの厳しさに応じて再認証を繰り返さなければならないなど、ユーザーに悪影響を与える可能性もあります。 |
| § There may be a lack of common understanding across the organization regarding what ZTA is and how to gauge the organization’s ZTA maturity, determine which ZTA approach is most suitable for the business, and develop an implementation plan. | § ZTA とは何か、組織の ZTA 成熟度をどのように評価し、どの ZTA アプローチがビジネスに最も適しているかを判断し、導入計画を策定する方法について、組織全体で共通の理解が得られていない可能性があります。 |
ソリューション（解決策）
| 1.2 Solution | 1.2 解決策 |
| This project is designed to help address the challenges discussed above by building, demonstrating, and documenting several example ZTAs using products and technologies from a variety of different vendors. The example solutions are designed to provide secure authorized access to individual resources by enforcing enterprise security policy dynamically and in near-real-time. They restrict access to authenticated, authorized users and devices while flexibly supporting a complex set of diverse business cases. These use cases involve legacy enterprise networks; remote workforces; use of the cloud; use of corporate-provided, bring your own device (BYOD), and guest endpoints; collaboration with partners; guest users; and support for contractors and other authorized third parties. The example solutions are also designed to demonstrate having visibility within the environment and recognizing attacks and malicious insiders. They showcase the ability of ZTA products to interoperate with legacy enterprise and cloud technologies to protect resources with minimal impact on end-user experience. | このプロジェクトは、さまざまなベンダーの製品と技術を使用して、いくつかのZTAの例を構築し、実演し、文書化することで、上記の課題に対処できるように設計されています。これらのソリューションは、企業のセキュリティポリシーをほぼリアルタイムで動的に適用し、個々のリソースへの安全な認証アクセスを提供するよう設計されています。これらのソリューションは、認証された正規のユーザーとデバイスにアクセスを制限すると同時に、複雑で多様なビジネスケースを柔軟にサポートします。これらのユースケースには、レガシーな企業ネットワーク、リモートワーク、クラウドの利用、企業提供のデバイス、BYOD、ゲストエンドポイントの利用、パートナーとのコラボレーション、ゲストユーザー、契約社員やその他のサードパーティへのサポートが含まれます。また、サンプルソリューションは、環境内の可視化、攻撃や悪意のあるインサイダーの認知を実証するよう設計されています。また、ZTA製品が従来の企業やクラウドテクノロジーと相互運用し、エンドユーザーエクスペリエンスへの影響を最小限に抑えながらリソースを保護できることも紹介されています。 |
| The concepts and principles in NIST SP 800-207, Zero Trust Architecture are applied to enterprise networks that are composed of pre-established devices and components and that store critical corporate resources both on-premises and in the cloud. For each access request, ZTA verifies the requester’s identity and role, the requesting device’s health and credentials, and possibly other information. If defined policy is met, ZTA dynamically creates a secure connection to protect all information transferred to and from the accessed resource. ZTA performs real-time, continuous behavioral analysis and risk-based assessment of the access transaction or session. | NIST SP 800-207「Zero Trust Architecture」のコンセプトと原則は、あらかじめ確立されたデバイスとコンポーネントで構成され、オンプレミスおよびクラウドの両方で重要な企業リソースを保管する企業ネットワークに適用されます。各アクセス要求に対して、ZTAは要求者のアイデンティティと役割、要求元のデバイスの健全性と認証情報、場合によってはその他の情報を確認する。定義されたポリシーに合致する場合、ZTAはアクセスされたリソースとの間で転送されるすべての情報を保護するために、安全な接続を動的に作成します。ZTAはリアルタイムで継続的に行動分析を行い、アクセストランザクションまたはセッションのリスクベースの評価を行います。 |
| The example solutions are built starting with a baseline designed to resemble a typical existing enterprise environment that is assumed to have an identity store and other security components in place. This enables the project to represent how we believe most enterprises will evolve toward ZTA, i.e., by starting with their already-existing legacy enterprise environment and gradually adding capabilities. A limited version of the enhanced identity governance (EIG) deployment approach described in NIST SP 800-207 is being implemented first, during what we call the EIG crawl phase of the project. We chose to base our first implementations on the EIG approach because EIG is seen as the foundational component of the other deployment approaches utilized in today’s hybrid environments. The EIG approach uses the identity of subjects and device health as the main determinants of policy decisions. However, instead of using a separate, dedicated component to serve as a policy decision point (PDP), our crawl phase leverages the identity, credential, and access management (ICAM) component to serve as the PDP. | サンプルソリューションは、アイデンティティストアやその他のセキュリティコンポーネントが設置されていると想定される、典型的な既存の企業環境を模して設計されたベースラインから構築されています。つまり、既存のレガシーな企業環境から始めて、徐々に機能を追加していくのです。NIST SP 800-207に記載されている拡張アイデンティティガバナンス（EIG）展開アプローチの限定版が、プロジェクトのEIGクロールフェーズと呼ばれる期間に最初に実装されます。EIG は、今日のハイブリッド環境で利用されている他の展開アプローチの基礎となるコンポーネントと見なされているため、最初の実装は EIG アプローチをベースに行うことを選択しました。EIG アプローチは、ポリシーの決定の主な決定要因として、サブジェクトのアイデンティティとデバイスの健全性を使用します。しかし、ポリシー決定ポイント（PDP）として機能する別の専用コンポーネントを使用する代わりに、私たちのクロール段階では、アイデンティティ、クレデンシャル、およびアクセス管理（ICAM）コンポーネントをPDPとして使用します。 |
| Once the remaining example implementations of the EIG crawl phase of the project are complete, an EIG approach that is not limited to using an ICAM component as the PDP (i.e., an EIG run phase) will be implemented. After that, additional supporting components and features will be deployed to address an increasing number of the ZTA requirements, progressing the project toward eventual demonstration of the micro-segmentation and software-defined perimeter deployment options as well. | 本プロジェクトのEIGクロールフェーズの残りの実装例が完成したら、PDPとしてICAMコンポーネントを使用することに限定されないEIGアプローチ（すなわちEIGランフェーズ）を実装する予定です。その後、より多くのZTA要件に対応するため、サポートするコンポーネントや機能を追加して展開し、最終的にはマイクロセグメンテーションやソフトウェア定義境界の展開オプションも実証する方向でプロジェクトを進めていく予定です。 |
ベネフィット（利点）
| 1.3 Benefits | 1.3 利点 |
| The demonstrated approach documented in this practice guide can provide organizations wanting to migrate to ZTA with information and confidence that will help them develop transition plans for integrating ZTA into their own legacy environments, based on the example solutions and using a riskbased approach. Executive Order 14028, Improving the Nation’s Cybersecurity [2], requires all federal agencies to develop plans to implement ZTA. This practice guide can inform the agencies in developing their ZTA implementation plans. When integrated into their enterprise environments, ZTA will enable organizations to: | この実践ガイドに記載されている実証済みのアプローチは、ZTAへの移行を希望する組織に対して、情報および信頼性を提供するものであり、サンプルソリューションに基づき、リスクに応じたアプローチで、ZTAを自社のレガシー環境に統合する移行計画を策定するのに役立ちます。大統領令14028号「国家のサイバーセキュリティの改善」[2]は、すべての連邦政府機関に対して、ZTAを導入するための計画を策定することを求めています。この実践ガイドは、各機関がZTAの導入計画を策定する際の参考となるものです。ZTAを企業環境に組み込むことで、組織は以下のことが可能になります。 |
| § Support teleworkers by enabling them to access corporate resources regardless of their location—on-premises, at home, or on public Wi-Fi at a neighborhood coffee shop. | § テレワーカーをサポートし、社内、自宅、近所のコーヒーショップの公衆無線LANなど、場所に関係なく企業リソースにアクセスできるようにすること。 |
| § Protect resources regardless of their location—on-premises or in the cloud. | § 場所（オンプレミス、クラウド）に関係なく、リソースを保護すること。 |
| § Limit the insider threat by rejecting the outdated assumption that any user located within the network boundary should be automatically trusted. | § ネットワーク境界内にいるユーザーは自動的に信頼されるという時代遅れの仮定を否定し、インサイダーの脅威を制限すること。 |
| § Limit breaches by reducing an attacker’s ability to move laterally in the network. Access controls can be enforced on an individual resource basis, so an attacker who has access to one resource won’t be able to use it as a springboard for reaching other resources. | § 攻撃者がネットワーク内を横方向に移動する能力を低下させることにより、侵入を制限する。アクセス制御を個々のリソース単位で実施できるため、あるリソースにアクセスした攻撃者が、それを踏み台にして他のリソースにアクセスすることができないようにすること。 |
| § Improve incident detection, response, and recovery to minimize impact when breaches occur. Limiting breaches reduces the footprint of any compromise and the time to recovery. | § インシデントの検出、対応、回復を改善し、侵害が発生した場合の影響を最小化する。侵害を制限することで、侵害の影響を軽減し、回復までの時間を短縮すること。 |
| § Protect sensitive corporate data by using strong encryption both while data is in transit and while it is at rest. Grant subjects access to a resource only after enforcing consistent identification, authentication, and authorization procedures, verifying device health, and performing all other checks specified by enterprise policy. | § データの転送中と保管中の両方で強力な暗号化を使用することにより、機密性の高い企業データを保護する。一貫した識別、認証、承認手順を実施し、デバイスの健全性を確認し、企業ポリシーで指定された他のすべてのチェックを実行した後にのみ、対象者にリソースへのアクセスを許可すること。 |
| § Improve visibility into which users are accessing which resources, when, how, and from where by monitoring and logging every access request within every access session. | § アクセスセッション内のすべてのアクセス要求を監視し、ログに記録することで、どのユーザが、いつ、どのように、どこから、どのリソースにアクセスしているかを可視化すること。 |
| § Perform dynamic, risk-based assessment of resource access through continuous reassessment of all access transactions and sessions, gathering information from periodic reauthentication and reauthorization, ongoing device health verification, behavior analysis, ongoing resource health verification, anomaly detection, and other security analytics. | § 定期的な再認証と再許可、継続的なデバイスの健全性の検証、動作分析、継続的なリソースの健全性の検証、異常検出、その他のセキュリティ分析から情報を収集し、すべてのアクセストランザクションとセッションを継続的に再評価して、リソースアクセスの動的でリスクベースの評価を実行すること。 |
目次...
| 1 Summary | 1 概要 |
| 1.1 Challenge | 1.1 課題 |
| 1.2 Solution | 1.2 解決策 |
| 1.3 Benefits | 1.3 利点 |
| 2 How to Use This Guide | 2 このガイドの使用方法 |
| 2.1 Typographic Conventions | 2.1 文字種の規則 |
| 3 Approach | 3 アプローチ |
| 3.1 Audience | 3.1 想定読者 |
| 3.2 Scope | 3.2 対象範囲 |
| 3.3 Assumptions | 3.3 前提条件 |
| 3.4 Collaborators and Their Contributions | 3.4 協力者とその貢献 |
| 3.4.1 Appgate | 3.4.1 Appgate |
| 3.4.2 AWS | 3.4.2 AWS |
| 3.4.3 Broadcom Software | 3.4.3 Broadcom Software |
| 3.4.4 Cisco | 3.4.4 Cisco |
| 3.4.5 DigiCert | 3.4.5 DigiCert |
| 3.4.6 F5 | 3.4.6 F5 |
| 3.4.7 Forescout | 3.4.7 Forescout |
| 3.4.8 Google Cloud | 3.4.8 Google Cloud |
| 3.4.9 IBM | 3.4.9 IBM |
| 3.4.10 Ivanti | 3.4.10 Ivanti |
| 3.4.11 Lookout | 3.4.11 Lookout |
| 3.4.12 Mandiant | 3.4.12 Mandiant |
| 3.4.13 Microsoft | 3.4.13 Microsoft |
| 3.4.14 Okta | 3.4.14 Okta |
| 3.4.15 Palo Alto Networks | 3.4.15 Palo Alto Networks |
| 3.4.16 PC Matic | 3.4.16 PC Matic |
| 3.4.17 Ping Identity | 3.4.17 Ping Identity |
| 3.4.18 Radiant Logic | 3.4.18 Radiant Logic |
| 3.4.19 SailPoint | 3.4.19 SailPoint |
| 3.4.20 Tenable | 3.4.20 Tenable |
| 3.4.21 Trellix | 3.4.21 Trellix |
| 3.4.22 VMware | 3.4.22 VMware |
| 3.4.23 Zimperium | 3.4.23 Zimperium |
| 3.4.24 Zscaler | 3.4.24 Zscaler |
| 4 Architecture | 4 アーキテクチャ |
| 4.1 General ZTA Reference Architecture | 4.1 一般的なZTAリファレンスアーキテクチャ |
| 4.1.1 ZTA Core Components | 4.1.1 ZTAのコアコンポーネント |
| 4.1.2 ZTA Supporting Components | 4.1.2 ZTAのサポートコンポーネント |
| 4.1.3 ZTA in Operation | 4.1.3 動作中のZTA |
| 4.2 EIG Crawl Phase Reference Architecture | 4.2 EIGクロールフェーズリファレンスアーキテクチャ |
| 4.2.1 EIG Crawl Phase Build-Specific Features | 4.2.1 EIGクロールフェーズのビルド固有の機能 |
| 4.3 ZTA Laboratory Physical Architecture | 4.3 ZTAラボの物理アーキテクチャ |
| 4.3.1 Enterprise 1 | 4.3.1 エンタープライズ1 |
| 4.3.2 Enterprise 1 Branch Office | 4.3.2 エンタープライズ1の支店 |
| 4.3.3 Enterprise 2 | 4.3.3 エンタープライズ2 |
| 4.3.4 Enterprise 3 | 4.3.4 エンタープライズ3 |
| 4.3.5 Enterprise 4 | 4.3.5 エンタープライズ4 |
| 4.3.6 Coffee Shop | 4.3.6 コーヒーショップ |
| 4.3.7 Management and Orchestration Domain | 4.3.7 管理・オーケストレーション領域 |
| 4.3.8 Emulated WAN Service Provider | 4.3.8 エミュレートされたWANサービスプロバイダ |
| 4.3.9 Cloud Services | 4.3.9 クラウドサービス |
| 5 Functional Demonstration | 5 機能デモ |
| 6 General Findings | 6 一般的な知見 |
| 7 Future Build Considerations | 7 今後の構築に関する考察 |
| Appendix A List of Acronyms | 附属書A 頭字語（英語）リスト |
| Appendix B Glossary | 附属書B 用語集 |
| Appendix C References | 附属書C 参考文献 |
| Appendix D EIG Enterprise 1 Build 1 (E1B1) | 附属書D EIGエンタープライズ1ビルド1(E1B1) |
| D.1 Technologies | D.1 テクノロジー |
| D.2 Build Architecture | D.2 ビルドアーキテクチャ |
| D.2.1 Logical Architecture | D.2.1 論理的なアーキテクチャ |
| D.2.2 ICAM Information Architecture | D.2.2 ICAM情報アーキテクチャ |
| D.2.3 Physical Architecture | D.2.3 物理的アーキテクチャ |
| D.2.4 Message Flow for a Successful Resource Access Request | D.2.4 リソースアクセス要求成功時のメッセージフロー |
| Appendix E EIG Enterprise 2 Build 1 (E2B1) | 附属書E EIG Enterprise 2 ビルド1 (E2B1) |
| Appendix F EIG Enterprise 3 Build 1 (E3B1) | 附属書F EIG Enterprise 3 ビルド1 (E3B1) |
| F.1 Technologies | F.1 テクノロジー |
| F.2 Build Architecture | F.2 ビルドアーキテクチャ |
| F.2.1 Logical Architecture | F.2.1 論理的なアーキテクチャ |
| F.2.2 Physical Architecture | F.2.2 物理的アーキテクチャ |
| F.2.3 Message Flows for a Successful Resource Access Request | F.2.3 リソースアクセス要求が成功した場合のメッセージフロー |
| Appendix G EIG Enterprise 4 Build 1 (EB1) | 附属書 G EIG Enterprise 4 ビルド 1 (EB1) |
NCCoEのプレス...
● NCCoE
・2022.07.07 The Zero Trust Architecture (ZTA) Team Releases Preliminary Draft Practice Guide (Vol B)
関連
● まるちゃんの情報セキュリティ気まぐれ日記
・2022.06.07 NIST SP 1800-35 (ドラフト) ゼロトラストアーキテクチャの実装（初期ドラフト）(Vol. A)
« 総務省 プラットフォームサービスに関する研究会 第二次とりまとめ（案）についての意見募集 (2022.07.04) | Main | 米国 GAO 顔認識技術：連邦政府機関の利用と関連するプライバシー保護 (2022.06.29) »
Comments