Cloud Security Alliance がマイクロサービス・アーキテクチャー・パターンに関する報告書を公表していますね...

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

Cloud Security Alliance がマイクロサービス・アーキテクチャー・パターンに関する報告書を公表していますね...

● Cloud Security Alliance

・2021.08.31 Microservices Architecture Pattern

Microservices Architecture Pattern	マイクロサービス・アーキテクチャ・パターン
This document serves to propose a repeatable approach to architecting, developing and deploying Microservices as a “MAP” (Microservices Architecture Pattern). The proposed MAP contains all the information necessary for a microservice to operate independently and communicate with other microservices which, in aggregate, become capabilities which, in turn, become the components of an application. This paper describes the key elements of the MAP, how they should be designed and deployed, shifting security & compliance left via a continuous compliance-as-code approach.	本文書は、Microservicesを「MAP」（Microservices Architecture Pattern）として構築、開発、デプロイするための反復可能なアプローチを提案するものである。提案されたMAPには、マイクロサービスが独立して動作し、他のマイクロサービスと通信するために必要なすべての情報が含まれています。これらのマイクロサービスは、集合的にはアプリケーションのコンポーネントとなる機能となります。本文書では、MAPの主要な要素、MAPの設計と導入方法、継続的なコンプライアンス・アズ・コード・アプローチによるセキュリティとコンプライアンスの移行について説明します。
The primary goal of this work effort is to develop a vendor neutral reference architecture foundation that decomposes into software architecture patterns represented in Software and Platform (Enterprise) Planes, and then can be built back up with the addition of security control overlays. This can be demonstrated by the successful decomposition and recomposition of microservice architecture patterns where the integral action is the overlay of security controls.	この作業の主な目標は、ベンダーニュートラルなリファレンスアーキテクチャの基盤を開発することです。この基盤は、ソフトウェアおよびプラットフォーム（エンタープライズ）プレーンで表現されるソフトウェアアーキテクチャパターンに分解され、その後、セキュリティ制御オーバーレイを追加することで、再び構築することができます。このことは、マイクロサービスアーキテクチャパターンの分解と再構成に成功し、その際、セキュリティ制御のオーバーレイが不可欠であることで実証されています。

・[PDF] は簡単な質問に答えることで入手できます。

Acknowledgments	謝辞
1. Introduction	1. はじめに
2. Goal	2. 目標
3. Audience	3. 想定読者
4. Architecture vs Solutions	4. アーキテクチャとソリューション
4.1 Patterns and Control Overlays	4.1 パターンとコントロールオーバーレイ
4.2 Introduction to the Microservices Architecture Pattern (MAP)	4.2 マイクロサービス・アーキテクチャ・パターン(MAP)の紹介
5. Microservices Architecture Patterns	5. マイクロサービス・アーキテクチャ・パターン
5.1 Introduction to Patterns	5.1 パターンの紹介
5.1.1 Offload Pattern	5.1.1 オフロードパターン
5.1.2 Route (Routing) Pattern	5.1.2 ルート（ルーティング）パターン
5.1.3 Aggregation Pattern	5.1.3 アグリゲーションパターン
5.1.4 Cache Pattern	5.1.4 キャッシュパターン
5.1.5 Proxy	5.1.5 プロキシ
5.1.6 AuthN (Authentication) Pattern	5.1.6 AuthN（認証）パターン
5.1.7 AuthZ (Authorization) Pattern	5.1.7 AuthZ（認可）パターン
5.1.8 Facade Pattern	5.1.8 ファサード（外見）パターン
5.1.9 Strangler Fig Pattern	5.1.9 締め殺し無花果パターン
5.1.10 Circuit Breaker Pattern	5.1.10 サーキット・ブレーカー・パターン
5.1.11 Adapter (wrapper/ translate/ transform) Pattern	5.1.11 アダプター（ラッパー／翻訳／変換）パターン
6. Security Control Overlays	6. セキュリティ・コントロール・オーバーレイ
6.1 Introduction to Overlays	6.1 オーバーレイの紹介
6.1.1 Service Overlays	6.1.1 サービスオーバーレイ
6.1.2 IAM Overlays	6.1.2 IAMオーバーレイ
6.1.3 Network Overlays	6.1.3 ネットワークオーバーレイ
6.1.4 Monitoring Overlays	6.1.4 モニタリングオーバーレイ
6.1.5 Cryptologic Overlays	6.1.5 暗号化オーバーレイ
6.1.6 Microservice Resiliency and Availability Overlay	6.1.6 マイクロサービスの回復力と可用性のオーバーレイ
Summary/ Conclusion	まとめ・結論
Appendix A: Acronyms	附属書A：頭字語
Appendix B: Glossary	附属書B：用語集
Appendix C: References	附属書C：参考文献
Appendix D: Work Instruction	附属書D: 作業手順
1.0 Microservice Architecture Pattern Template	1.0 マイクロサービス・アーキテクチャ・パターン・テンプレート
1.1 Pattern Work Instruction	1.1 パターンの作業手順
1.2 Pattern Template	1.2 パターンテンプレート
2.0 Security Overlay Template	2.0 セキュリティ・オーバーレイ・テンプレート
2.1 Security Overlay Work Instruction	2.1 セキュリティオーバレイ作業指示書
2.1.1 Introduction	2.1.1 はじめに
2.1.2 Preliminaries	2.1.2 前提知識
2.1.3 Steps	2.1.3 手順

1. Introduction	1. はじめに
The impact of weakly constructed microservices exists , realized as under-secured and over-exposed application programming interfaces (API’s) which form the core tranche of microservice application risk. Some business and technology owners skip the architecture methods  and search for a software solution primarily based upon a set of coarse-grained requirements. Those that research solutions in the open market end up applying architecture methods to fit the purchased solution into the existing control landscape. Even newly constructed greenfield microservice applications integrate with the rest of the legacy enterprise - companies do not throw out the existing architecture each year. Inevitably, product purchases without architecture methods lead to trade-offs capable of introducing constraints and add-ons at a later date when the monetary cost to modify increases over time.	脆弱な構造のマイクロサービスの影響は、マイクロサービスアプリケーションのリスクの中核を成す、安全性の低い、過剰に露出したAPIとして実現されています。ビジネスオーナーや技術者の中には、アーキテクチャーの手法を使わず、主に粗い要件に基づいてソフトウェアソリューションを探す人がいます。オープン・マーケットでソリューションを調査する人は、購入したソリューションを既存のコントロール・ランドスケープに適合させるためにアーキテクチャ・メソッドを適用することになります。新たに構築された全く新しいマイクロサービスアプリケーションであっても、レガシーシステムの残りの部分と統合されます。システムは毎年、既存のアーキテクチャを捨ててしまうわけではありません。必然的に、アーキテクチャー手法を用いずに製品を購入すると、時間の経過とともに修正にかかる金銭的コストが増加したときに、後から制約やアドオンを導入できるようなトレードオフが発生します。
Whether a business leader has a bias to purchasing solutions or supports a “build in-house” mindset, API consumption and microservice integration is a common systems integration expectation. It is best to have a means to guide integration with the use of architecture, architecture patterns, and security control overlays to ensure that information security is an upfront requirement set. Microservice architectural patterns and corresponding security control overlays set the foundation for microservices development as a complete thought. Patterns plus overlays ensure baked-in information security. Done correctly, security control overlays become indistinguishable from the architecture and design methods used to create microservice applications. Some would call this phenomena DevSecOps . The security control overlay concept originated in the Federal Information Systems Management Act (FISMA) Project . As per the FISMA project, “An overlay is a fully-specified set of controls, control enhancements, and supplemental guidance derived from the application of tailoring guidance to control baselines.”  Security controls overlays are further elaborated in detail in National Institutes of Standards Special Publication Security and Privacy Controls for Federal Information Systems and Organizations SP800-53 version 4 Section 3.35.  Although overlay is a NIST-introduced concept, other control frameworks, like ISACA COBIT 5, PCI-DSS 3.2.1, or CSA CCM v3.0.1, can be used.	ビジネスリーダーがソリューションの購入に偏っていようと、「社内で構築する」という考え方を支持していようと、APIの消費とマイクロサービスの統合は、一般的なシステムインテグレーションに期待されるものです。そのためには、アーキテクチャ、アーキテクチャ・パターン、およびセキュリティ・コントロール・オーバーレイを使用して、情報セキュリティを事前の要件セットとして確保し、統合を導く手段を持つことが最善です。マイクロサービス・アーキテクチャ・パターンとそれに対応するセキュリティ・コントロール・オーバーレイは、完全な思考としてのマイクロサービス開発の基盤を設定します。パターンとオーバーレイがあれば、情報セキュリティを確実に組み込むことができます。セキュリティ・コントロール・オーバーレイは、マイクロサービス・アプリケーションを作成するためのアーキテクチャや設計手法と見分けがつかなくなります。この現象をDevSecOpsと呼ぶ人もいます。セキュリティ・コントロール・オーバーレイのコンセプトは、連邦情報システム管理法（FISMA）プロジェクトで生まれました。FISMA プロジェクトによると、「オーバーレイとは、コントロールベースラインにテーラーリングガイダンスを適用することで得られる、完全に仕様化されたコントロール、コントロールの強化、および補足ガイダンスのセットである」とされています。 セキュリティ管理のオーバーレイについては、米国国立標準研究所（NIST）の特別刊行物「Security and Privacy Controls for Federal Information Systems and Organizations SP800-53 version 4 Section 3.35」でさらに詳しく説明されています。 オーバーレイはNISTが提唱した概念ですが、ISACA COBIT 5、PCI-DSS 3.2.1、CSA CCM v3.0.1など、他のコントロールフレームワークを使用することもできます。
Software design patterns guide software development . Security control overlays, a discrete collection that represents a fully-specified set of controls, control enhancements, and supplemental guidance, integrates into the architectural design process as embedded and upfront administrative, technical or physical requirements. Together, software design patterns and security control overlays inform software development to “build in” security as a design element, and not as an application of facade applied at the end where changes to software are most expensive to make. The following pages establish the foundation for software architecture as a complete thought. A complete thought in an architectural sense is an architectural expression that behaves like a good math equation; it can be run forward to its expected product and backward to its non-functional and functional requirements.	ソフトウェアのデザインパターンは、ソフトウェア開発の指針となるものです。セキュリティコントロールオーバーレイは、完全に仕様化されたコントロール、コントロール強化、および補足ガイダンスのセットを表す個別の集合体であり、管理、技術、または物理的な要件として組み込まれ、アーキテクチャ設計プロセスに統合されます。ソフトウェアデザインパターンとセキュリティ管理オーバーレイを併用することで、ソフトウェアへの変更が最もコストのかかる最後の段階で適用されるファサードのアプリケーションとしてではなく、設計要素としてセキュリティを「組み込む」よう、ソフトウェア開発に情報を提供する。以下のページでは、完全な思考としてのソフトウェアアーキテクチャの基礎を確立します。建築的な意味での完全な思考とは、優れた数学の方程式のように振る舞う建築的な表現であり、期待される製品に向かって前進し、非機能的要件と機能的要件に向かって後退することができます。
Once practitioners master software design patterns and security control overlays, use unlocks additional levels of architectural maturity where specific microservice viewpoints reveal needed control state in specific aspects of the underlying service delivery framework such as the data, integration, and deployment architectures.  Although not “microservice architectures,” they are supporting architectures and designs requiring assurance that system behavior remains repeatable, reliable, accurate, and complete according to an understood control state.	実務者がソフトウェアのデザインパターンとセキュリティ制御のオーバーレイを習得すると、アーキテクチャの成熟度がさらに高まり、特定のマイクロサービスの視点から、データ、統合、デプロイメントアーキテクチャなど、基盤となるサービス提供フレームワークの特定の側面に必要な制御状態が明らかになります。 これらは「マイクロサービスアーキテクチャ」ではありませんが、理解された制御状態に従って、システムの動作が反復可能で、信頼性が高く、正確で、完全であることを保証する必要があるアーキテクチャや設計をサポートします。
Microservice architecture style represents a distributed application processing footprint where the combined capability derived from static configuration, dynamic adaptation, and abstraction yield what people would term “application functionality.” Prior to the microservices and containerization transformation, many configurations and abstractions existed within a singular monolithic application boundary. As monolithic code bases became larger, internal application states and co-dependencies became increasingly difficult to discern leading to a number of architecture, development, and operations challenges. However, it remained common to have one business representative  accountable for business process functionality, one product owner fulfilling application custodial obligations, and managing allied developers housed under a singular organization structure. Microservices architecture style changes organization structure just as much as it changes software construction and assembly. Each part of the architecture, whether at the platform, software-defined, application programming interface (API), or software development level, performs a specific and particular function with respect to the entire functionality delivered by a microservice application. Organizations responded to virtualization of compute, memory, storage, and network into a single capability, by combining teams to match the technological change. Hybrids of storage, network, and server computer teams materialized from the combination of discrete teams.	マイクロサービスアーキテクチャのスタイルは、静的な構成、動的な適応、および抽象化から得られる能力を組み合わせることで、人々が「アプリケーション機能」と呼ぶものを生み出す、分散アプリケーション処理フットプリントを表しています。マイクロサービスとコンテナ化の変革以前は、多くの構成と抽象化が、単一のモノリシックなアプリケーション境界内に存在していました。一枚岩のコードベースが大きくなるにつれ、アプリケーション内部の状態や共依存性を見極めることが難しくなり、アーキテクチャ、開発、運用の面で多くの課題が発生しました。しかし、ビジネスプロセスの機能に責任を持つビジネス担当者、アプリケーションの管理義務を果たすプロダクトオーナー、そして単一の組織構造の下で収容された提携開発者を管理することは、依然として一般的でした。マイクロサービスアーキテクチャのスタイルは、ソフトウェアの構築や組み立てを変えるのと同様に、組織構造も変えます。アーキテクチャの各部分は、プラットフォーム、ソフトウェア定義、アプリケーション・プログラミング・インターフェース（API）、ソフトウェア開発のいずれのレベルであっても、マイクロサービス・アプリケーションが提供する機能全体に対して、特定の特殊な機能を果たします。組織は、計算機、メモリ、ストレージ、ネットワークを単一の機能に統合する仮想化に対応するため、技術的な変化に合わせてチームを統合しました。ストレージ、ネットワーク、サーバーコンピュータの各チームは、個別のチームを組み合わせてハイブリッド化しました。
As microservice software development takes root, the industry is placing an increasing emphasis on DevSecOps , and federation of software assembly as well as application security. For example, a business owner may own the entirety of a workflow application, but only deal with the forwardfacing requests for improvements to existing capability or new capability. A business owner concerns themselves with maximizing the value of delivered or deliverable results; this role exists outside the teams building the software. In the microservice architectural style, it is possible that multiple product owners align with a singular business owner. A product owner and associated software development team (or “crew” in Agile parlance) may have ownership of specific functionality, such as search functionality (API usage, sort, algorithms, metadata cataloging), while a second product owner focuses on the front-end customer facing user experience (Style, presentation, flow and overall experience). Data integration may be left to an allied crew that serves multiple product owner needs for data. Monolithic applications bound all of these roles and actions into a vertical of support, which is a key microservice architectural style distinction - the microservice software development and production deployment behavior flattens an organization’s traditional verticals. Not only is the application functionality distributed, so is its support structure forcing a greater reliance on automation to deliver a wide variety of infrastructure, policy, security, identity, and network capability previously isolated into verticals. Operations typically own the set of processes to deploy and manage IT services, however the deployment and testing responsibility at times shifts-left toward the developer who builds the software. Out of necessity, architects commonly take on new skill sets in software engineering, to better translate customary and traditional architectural worksets into the microservice architectural style.	マイクロサービスソフトウェアの開発が定着するにつれ、業界ではDevSecOpsやソフトウェアアセンブリのフェデレーション、アプリケーションセキュリティなどが重視されるようになってきました。例えば、ビジネスオーナーは、ワークフローアプリケーションの全体を所有していても、既存の機能を改善したり、新しい機能を追加したりといった前向きな要求にのみ対応することができます。ビジネスオーナーは、納品された結果の価値を最大化することに関心があり、この役割はソフトウェアを構築するチームの外に存在する。マイクロサービスアーキテクチャのスタイルでは、複数のプロダクトオーナーが1人のビジネスオーナーと連携することが可能である。プロダクトオーナーと関連するソフトウェア開発チーム（アジャイル用語で「クルー」）は、検索機能（APIの使用、ソート、アルゴリズム、メタデータのカタログ化）などの特定の機能のオーナーシップを持ち、もう一人のプロダクトオーナーは、顧客が直面するフロントエンドのユーザーエクスペリエンス（スタイル、プレゼンテーション、フロー、全体的なエクスペリエンス）に焦点を当てることができます。データ統合は、複数のプロダクトオーナーのデータニーズに対応する提携クルーに任せることもできます。モノリシックなアプリケーションは、これらの役割と行動をすべてサポートの垂直方向に束ねていますが、これはマイクロサービスアーキテクチャスタイルの重要な違いであり、マイクロサービスソフトウェアの開発と本番デプロイメントの動作は、組織の伝統的な垂直方向を平らにします。アプリケーションの機能が分散しているだけでなく、そのサポート構造も分散しているため、これまで縦割りであったインフラ、ポリシー、セキュリティ、アイデンティティ、ネットワークなどの幅広い機能を提供するために、自動化への依存度が高まっています。オペレーション部門は通常、ITサービスを展開・管理するための一連のプロセスを所有していますが、展開とテストの責任は、ソフトウェアを構築する開発者に委ねられることがあります。アーキテクトは、必要に迫られてソフトウェアエンジニアリングの新しいスキルセットを身につけ、従来の伝統的なアーキテクチャーのワークセットをマイクロサービスアーキテクチャーのスタイルにうまく変換しています。
Appendix B further defines the roles of business owner, product owner, developer, operator and architect. For further detail and specific definition of these five roles, please refer to the glossary.	附属書Bでは、ビジネスオーナー、プロダクトオーナー、開発者、オペレーター、アーキテクトの役割をさらに定義しています。これら5つの役割の詳細および具体的な定義については、用語集を参照してください。