NIST SP 800-204C (ドラフト) サービス・メッシュを用いたマイクロサービス・ベースのアプリケーションに対するDevSecOpsの実施
こんにちは、丸山満彦です。
NISTがSP 800-204C (ドラフト) サービス・メッシュを用いたマイクロサービス・ベースのアプリケーションに対するDevSecOpsの実施を公開し、意見募集をしていますね。。。
● NIST - ITL
・2021.09.29 SP 800-204C (Draft) Implementation of DevSecOps for a Microservices-based Application with Service Mesh
SP 800-204C (Draft) Implementation of DevSecOps for a Microservices-based Application with Service Mesh | SP 800-204C (ドラフト) サービス・メッシュを用いたマイクロサービス・ベースのアプリケーションに対するDevSecOpsの実施 |
Announcement | 発表内容 |
The newest generation of software applications—"cloud-native applications"—is a class with various functional layers, such as transaction logic, application services, infrastructure resources, policy enforcement, and monitoring of states. The unique architecture of this application class requires a more agile software life cycle paradigm, and DevSecOps (development, security, and operations) offers faster deployment and updates, while integrating security throughout the life cycle. | 最新世代のソフトウェア・アプリケーションである「クラウド・ネイティブ・アプリケーション」は、トランザクション・ロジック、アプリケーション・サービス、インフラストラクチャ・リソース、ポリシーの施行、状態の監視など、さまざまな機能層を持つクラスです。このアプリケーションクラスのユニークなアーキテクチャは、よりアジャイルなソフトウェアライフサイクルのパラダイムを必要とし、DevSecOps(開発、セキュリティ、運用)は、ライフサイクル全体でセキュリティを統合しながら、より迅速な展開と更新を実現します。 |
Draft NIST SP 800-204C provides guidance for the implementation of DevSecOps primitives for a reference platform hosting a cloud-native application with the functional layers described above. The guidance also discusses the benefits of this approach for high security assurance and enabling continuous authority to operate (C-ATO). | ドラフトNIST SP 800-204Cでは、上記のような機能レイヤーを持つクラウドネイティブ・アプリケーションをホストするリファレンス・プラットフォームに対する、DevSecOpsプリミティブの実装に関するガイダンスを提供しています。また、このガイダンスでは、高いセキュリティ保証と継続的な運用権限(C-ATO)の実現に向けたこのアプローチの利点についても説明しています。 |
Abstract | 概要 |
Cloud-native applications have evolved into a standardized architecture consisting of multiple loosely coupled components called microservices (implemented as containers), supported by code for providing application services called service mesh. Both of these components are hosted on a container orchestration and resource management platform, which is called a reference platform in this document. Due to security, business competitiveness, and its inherent structure (loosely coupled application components), this class of applications needs a different application development, deployment, and runtime paradigm. DevSecOps (consisting of three acronyms for Development, Security, and Operations, respectively) has been found to be a facilitating paradigm for these applications with primitives such as Continuous Integration, Continuous Delivery, and Continuous Deployment (CI/CD) pipelines. These pipelines are workflows for taking the developer’s source code through various stages, such as building, testing, packaging, deployment, and operations supported by automated tools with feedback mechanisms. In addition to the application code, and the code for application services (service mesh), the architecture has functional elements for infrastructure (computing, networking, and storage resources), runtime policies (authentication, authorization etc.) and continuous monitoring of the health of the application (Observability), which can be deployed through declarative codes. Thus, separate CI/CD pipelines can be created for all of the five code types. | クラウドネイティブアプリケーションは、マイクロサービスと呼ばれる複数の疎結合コンポーネント(コンテナとして実装)と、サービスメッシュと呼ばれるアプリケーションサービスを提供するためのコードでサポートされた標準的なアーキテクチャに進化しています。これらのコンポーネントはいずれも、コンテナのオーケストレーションとリソース管理を行うプラットフォーム上でホストされています。このプラットフォームを本書ではリファレンスプラットフォームと呼びます。このクラスのアプリケーションは、セキュリティ、ビジネス上の競争力、およびその固有の構造(アプリケーション・コンポーネントの疎結合)のために、異なるアプリケーション開発、デプロイメント、およびランタイム・パラダイムが必要です。DevSecOps(Development(開発)、Security(セキュリティ)、Operation(運用)の3つの頭文字をとったもの)は、継続的インテグレーション、継続的デリバリ、継続的デプロイメント(CI/CD)パイプラインなどのプリミティブにより、これらのアプリケーションを促進するパラダイムであることがわかっています。これらのパイプラインは、開発者のソースコードを、構築、テスト、パッケージ化、デプロイメント、運用などのさまざまな段階を経て、フィードバックメカニズムを備えた自動化ツールでサポートするワークフローです。アーキテクチャには、アプリケーションコード、アプリケーションサービスのコード(サービスメッシュ)に加えて、インフラ(コンピューティング、ネットワーキング、ストレージリソース)、ランタイムポリシー(認証、認可など)、アプリケーションの健全性の継続的な監視(Observability)などの機能要素があり、これらは宣言型コードによって展開することができます。したがって、5つのコードタイプのすべてに対して、個別のCI/CDパイプラインを作成することができます。 |
The objective of this document is to provide guidance for the implementation of DevSecOps primitives for a reference platform hosting a cloud-native application with the functional elements described above. The benefits of this approach for high security assurance and for enabling continuous authority to operate (C-ATO) are also discussed. | このドキュメントの目的は、上述の機能要素を持つクラウドネイティブアプリケーションをホストするリファレンスプラットフォームに、DevSecOpsプリミティブを実装するためのガイダンスを提供することです。また、高いセキュリティ保証と継続的な運用権限(C-ATO)を実現するためのこのアプローチの利点についても説明します。 |
・[PDF] SP 800-204C (Draft)
Executive Summary | エグゼクティブサマリー |
1 Introduction | 1 はじめに |
1.1 Scope | 1.1 範囲 |
1.2 Related DevSecOps Initiatives | 1.2 関連するDevSecOpsの取り組み |
1.3 Target Audience | 1.3 対象となる読者 |
1.4 Relationship to Other NIST Guidance Documents | 1.4 他のNISTガイダンス文書との関係 |
1.5 Organization of this document | 1.5 本文書の構成 |
2 Reference Platform for the Implementation of DevSecOps Primitives | 2 DevSecOpsのプリミティブを実装するためのリファレンス・プラットフォーム |
2.1 Container Orchestration and Resource Management Platform | 2.1 コンテナオーケストレーションおよびリソース管理プラットフォーム |
2.1.1 Security Limitations of Orchestration Platform | 2.1.1 オーケストレーション・プラットフォームのセキュリティ上の制限事項 |
2.2 Service Mesh Software Architecture | 2.2 サービスメッシュソフトウェアアーキテクチャ |
2.2.1 Data Plane | 2.2.1 データプレーン |
2.2.2 Control Plane | 2.2.2 コントロール・プレーン |
3 DevSecOps – Organizational Preparedness, Key Primitives, and Implementation | 3 DevSecOps - 組織的準備、主要なプリミティブ、および実装 |
3.1 Organizational Preparedness for DevSecOps | 3.1 DevSecOpsを実現するための組織的準備 |
3.2 Seamless Evolution from DevOps to DevSecOps | 3.2 「DevOps」から「DevSecOps」へのシームレスな進化 |
3.3 DevSecOps – Key Primitives and Implementation Tasks | 3.3 DevSecOps - キー・プリミティブと実装タスク |
3.3.1 Concept of Pipelines and the CI/CD pipeline | 3.3.1 パイプラインの概念とCI/CDパイプライン |
3.3.2 Building Blocks for CI/CD pipelines | 3.3.2 CI/CDパイプラインのビルディングブロック |
3.3.3 Designing and Executing the CI/CD pipeline | 3.3.3 CI/CDパイプラインの設計と実行 |
3.3.4 Strategies for Automation . | 3.3.4 自動化のための戦略 . |
3.3.5 Requirements for Automation Tools in CI/CD Pipelines | 3.3.5 CI/CDパイプラインにおける自動化ツールの要件 |
4 Implementing DevSecOps Primitives for the Reference Platform | 4 リファレンス・プラットフォームへのDevSecOpsプリミティブの実装 |
4.1 Code Types in Reference Platform and Associated CI/CD Pipelines | 4.1 リファレンス・プラットフォームのコード・タイプと関連するCI/CDパイプラ イン |
4.2 CI/CD Pipeline for Application Code and Application Services Code | 4.2 アプリケーション・コードとアプリケーション・サービス・コードのCI/CDパイプライン |
4.3 CI/CD Pipeline for Infrastructure as Code | 4.3 Infrastructure as CodeのCI/CDパイプライン |
4.3.1 Comparison of Configuration and Infrastructure | 4.3.1 構成とインフラの比較 |
4.4 CI/CD Pipeline for Policy as Code | 4.4 Policy as CodeのためのCI/CDパイプライン |
4.5 CI/CD Pipeline for Observability as Code | 4.5 コードとしての観測性のためのCI/CDパイプライン |
4.6 Securing the CI/CD Pipeline | 4.6 CI/CDパイプラインの安全性確保 |
4.7 Workflow Models in CI/CD Pipelines | 4.7 CI/CDパイプラインにおけるワークフローモデル |
4.7.1 GitsOps Workflow Model for CI/CD – A Pull-based Model | 4.7.1 CI/CDのためのGitsOpsワークフローモデル - プルベースのモデル |
4.8 Security Testing – Common Requirement for CI/CD Pipelines for All Code Types | 4.8 セキュリティテスト - 全てのコードタイプのCI/CDパイプラインの共通要件 |
4.8.1 Functional and Coverage Requirements for AST tools | 4.8.1 ASTツールの機能要件とカバレッジ要件 |
4.9 Benefits of DevSecOps Primitives to Application Security in the Service Mesh | 4.9 サービス・メッシュにおけるアプリケーション・セキュリティに対するDevSecOpsプリミティブの利点 |
4.10 Leveraging DevSecOps for Continuous Authorization to Operate (c-ATO) | 4.10 DevSecOpsを活用したc-ATO(Continuous Authorization to Operate)の実現 |
5 Summary and Conclusion | 5 まとめと結論 |
References | 参考文献 |
Executive Summary | エグゼクティブサマリー |
Cloud-native applications have evolved into a standardized architecture consisting of the following components: | クラウドネイティブなアプリケーションは、以下のコンポーネントで構成される標準的なアーキテクチャに進化しています。 |
• Multiple loosely coupled components called microservices (implemented as containers) | ・マイクロサービスと呼ばれる疎結合の複数のコンポーネント(コンテナとして実装される ) |
• An application services infrastructure called Service Mesh (providing services such as secure communication, authentication, and authorization for users, services, and devices) | ・サービスメッシュと呼ばれるアプリケーションサービス基盤(ユーザー、サービス、デバイスのセキュアな通信、認証、承認などのサービスを提供する)。 |
Due to security, business competitiveness, and its inherent structure (loosely coupled application components), this class of applications needs a different application, deployment, and runtime monitoring paradigm – collectively called the software life cycle paradigm. DevSecOps (consisting of three acronyms for Development, Security, and Operations, respectively) is one of the facilitating paradigms for the development, deployment, and operation of these applications with primitives such as Continuous Integration, Continuous Delivery, and Continuous Deployment (CI/CD) pipelines. | このクラスのアプリケーションは、セキュリティやビジネス上の競争力、そしてアプリケーションコンポーネントの疎結合という固有の構造により、アプリケーション、デプロイメント、ランタイムモニタリングのパラダイムが異なります。DevSecOps(Development(開発)、Security(セキュリティ)、Operation(運用)の3つの頭文字)は、継続的インテグレーション、継続的デリバリ、継続的デプロイメント(CI/CD)パイプラインなどのプリミティブを用いて、これらのアプリケーションの開発、デプロイ、運用を促進するパラダイムの1つです。 |
CI/CD pipelines are workflows for taking the developer’s source code through various stages, such as building, functional testing, security scanning for vulnerabilities, packaging, and deployment supported by automated tools with feedback mechanisms. In addition to the application code and the code for providing application services, this architecture may be made up of functional elements for infrastructure, runtime policies (such as zero trust policy), and continuous monitoring of the health of the application, the last three of which can be deployed through declarative codes. Thus, separate CI/CD pipelines can be created for all five code types. The runtime behavior of each of these code types is also described to highlight the roles that they play in the overall execution of the application. | CI/CDパイプラインとは、開発者が作成したソースコードを、ビルド、機能テスト、脆弱性のセキュリティスキャン、パッケージング、デプロイなどの様々な段階を経て、フィードバックメカニズムを備えた自動ツールでサポートするワークフローのことです。このアーキテクチャは、アプリケーションコードとアプリケーションサービスを提供するコードに加えて、インフラ、ランタイムポリシー(ゼロトラストポリシーなど)、アプリケーションの健全性の継続的な監視などの機能要素で構成されている場合があり、最後の3つは宣言型コードでデプロイすることができます。したがって、5つのコードタイプすべてに対して、個別のCI/CDパイプラインを作成することができます。また、これらのコードタイプの実行時の動作についても説明し、アプリケーションの全体的な実行においてコードタイプが果たす役割を明らかにします。 |
Though cloud-native applications have a common architectural stack, the platform on which the components of the stack run may vary. The platform is an abstraction layer over a physical (bare metal) or virtualized (e.g., virtual machines, containers) infrastructure. In this document, the chosen platform is a container orchestration and resource management platform (e.g., Kubernetes). To unambiguously refer to this platform or application environment throughout this document, it is called the Reference Platform for DevSecOps Primitives, or simply the reference platform. |
クラウドネイティブアプリケーションには共通のアーキテクチャスタックがありますが、スタックのコンポーネントが実行されるプラットフォームはさまざまです。プラットフォームとは、物理的(ベアメタル)または仮想化(仮想マシン、コンテナなど)されたインフラストラクチャ上の抽象化レイヤーのことです。本書では、コンテナのオーケストレーションとリソース管理のためのプラットフォーム(Kubernetesなど)を選択しています。本書では、このプラットフォームやアプリケーション環境を明確に示すために、DevSecOps Primitivesのリファレンス・プラットフォーム、または単にリファレンス・プラットフォームと呼びます。 |
The objective of this document is to provide guidance for the implementation of DevSecOps primitives for the reference platform. The benefits of this implementation for high security assurance and the use of the artifacts within the pipelines for providing continuous authority to operate (C-ATO) using risk management tools and dashboard metrics are also described. | この報告書の目的は、リファレンス・プラットフォームに対するDevSecOpsプリミティブの実装に関するガイダンスを提供することです。また、高いセキュリティ保証を実現するためのこの実装の利点と、リスク管理ツールとダッシュボード・メトリクスを使用して継続的な運営権限(C-ATO)を提供するためのパイプライン内の成果物の使用についても説明しています。 |
« NIST SP 800-214 2020年度サイバーセキュリティ・プライバシー年次報告書 | Main | NIST 白書 NISTサイバーセキュリティフレームワークと北米電力信頼度協議会 (NERC) 重要インフラ保護基準の最新マッピングの利点 »
Comments