APIエコノミーを支えるマイクロサービスのセキュリティ
1 like329 views
APIエコノミーを軸とするFintechやモバイルヘルスでは、アプリケーションコンテナやマイクロサービスを導入する動きが本格化し、「Docker」による開発フローの自動化や、「Kubernetes」による運用管理の標準化が進んでいます。本講演では、海外事例を題材に、マイクロサービスやAPIのセキュリティについて概説します。 1. ユースケース1：Fintechにおけるコンテナ／マイクロサービス／API利用とセキュリティ 2. ユースケース2：Healthtechにおけるコンテナ／マイクロサービス／API利用とセキュリティ 3. マイクロサービス／APIのセキュリティ脅威と対策 4. Q&A https://f2ff.jp/introduction/4002?event_id=secd-2020-02-tokyo
![2
クラウドセキュリティアライアンス
アプリケーションコンテナ／マイクロサービスWGのご紹介
[目的]
セキュアなアプリケーションコンテナおよびマイクロサービス利用の
ためのガイダンスやベストプラクティスを発行する
アプリケーションコンテナおよびマイクロサービスのセキュリティに
関する啓発活動を行う
[WGリーダー]
Anil Karmel（NIST SP 800-180(Draft) 筆頭著者）
Andrew Wild（QTS Data Centers・CISO)](https://image.slidesharecdn.com/csa-sasahara20201007final-200915001827/85/API-2-320.jpg)
APIエコノミーを支えるマイクロサービスのセキュリティ
- 1. @esasahara Cloud Security Alliance Application Containers and Microservices WG APIエコノミーを支える マイクロサービスのセキュリティ
- 2. 2 クラウドセキュリティアライアンス アプリケーションコンテナ／マイクロサービスWGのご紹介 [目的] セキュアなアプリケーションコンテナおよびマイクロサービス利用の ためのガイダンスやベストプラクティスを発行する アプリケーションコンテナおよびマイクロサービスのセキュリティに 関する啓発活動を行う [WGリーダー] Anil Karmel（NIST SP 800-180(Draft) 筆頭著者） Andrew Wild（QTS Data Centers・CISO)
- 3. 3 クラウドセキュリティアライアンス アプリケーションコンテナ／マイクロサービスWGの 作成ドキュメント例 「Challenges in Securing Application Containers and Microservices」(2019年7月） 「Best Practices for Implementing a Secure Application Container Architecture」 (2019年7月） 「Best Practices in Implementing a Secure Microservices Architecture」（2020年2月） 「Microservices Architecture Pattern (MAP)」 （2020年12月予定）
- 4. 4 コンテナ／マイクロサービスの定義に関するガイドライン • 米国立標準技術研究所（NIST） 「SP 800-180(Draft): NIST Definition of Microservices, Application Containers and System Virtual Machines」 （2016年2月） • アプリケーションコンテナ: 共有OS上で稼働するアプリケーションまたはそのコンポーネントとして パッケージ化し、稼働するように設計された構成物 • マイクロサービス： アプリケーション・コンポーネントのアーキテクチャを、疎結合のパターンに 分解した結果生まれる基本的要素であり、標準的な通信プロトコルや 明確に定義された API を利用して相互に通信する自己充足型サービス を構成し、いかなるベンダー、製品、技術からも独立している
- 6. 6 AGENDA • 1. ユースケース1：Fintechにおけるコンテナ／マイクロ サービス／API利用とセキュリティ • 2. ユースケース2：Healthtechにおけるコンテナ／ マイクロサービス／API利用とセキュリティ • 3. マイクロサービス／APIのセキュリティ脅威と対策 • 4. Q&A
- 8. 8 ドイツ銀行「APIプログラム」 （https://developer.db.com/） ・ビジョン：金融データ、商品、サービスを、デジタルな手法により アクセス可能にする • Getting Started Guide • 認証 • OAuth 2.0 • 証明書ベースの認証 • 権限付与（認可） • メッセージ署名 • ワンタイムパスワード利用 • API Explorer 出典：Deutsche Bank「API Program」（https://developer.db.com/）
- 9. 9 ドイツ銀行のクラウドネイティブ技術利用事例(1) ・Deutsche Bank AG「Fabric recognised at Red Hat Innovation Awards 2019 – Deutsche Bank’s Cloud Technology honoured」 （2019年5月7日） • 次世代デジタルトランスフォーメーション戦略プラットフォーム「Fabric」で、 コンテナ、マイクロサービス、DevOpsなどの技術を採用 （https://www.db.com/newsroom_news/2019/deutsche-bank-s-cloud-technology-fabric-recognised- at-red-hat-innovation-awards-2019-en-11483.htm） ・Deutsche Bank AG「Deutsche Bank and Google to form strategic global, multi-year partnership to drive a fundamental transformation of banking」（2020年7月7日） • 最新のクラウド技術を活用して、次世代金融商品を構築するために連携 （https://www.db.com/newsroom_news/2020/deutsche-bank-and-google-to-form-strategic-global- multi-year-partnership-to-drive-a-fundamental-transformation-o-en-11628.htm）
- 10. 10 ドイツ銀行のクラウドネイティブ技術利用事例(2) ・Deutsche Bank AG「Deutsche Bank China’s Blue Water Fintech Space wins Digital Transformation and Innovation Project of the Year 2019」（2019年12月18日） • 2019年9月、ドイツ銀行が中国・上海にBlue Water金融科技空間を開設 • 同年12月、「2019年プロジェクト・オブ・ザ・イヤー」を受賞 （https://www.db.com/newsroom_news/2019/deutsche-bank-china-s-blue-water-fintech-space-wins- digital-transformation-and-innovation-project-of-the-year-20-en-11663.htm） ・Deutsche Bank AG「Deutsche Bank’s Corporate Bank onboards its first digital employee for client-facing role」 （2020年7月20日） • 中国現法の法人金融部門が、Blue Waterで開発されたRPAベースの Blue Bot ‘Yi’を顧客対応デジタル行員として導入 （https://www.db.com/newsroom_news/2020/deutsche-bank-s-corporate-bank-onboards-its-first- digital-employee-for-client-facing-role-en-11639.htm）
- 11. 11 米国連邦金融機関検査協議会（FFIEC） 「クラウドコンピューティング環境におけるセキュリティ」 （2020年4月30日） ・クラウドコンピューティング・サービスのリスク管理 出典：FFIEC 「Security in a Cloud Computing Environment」（2020年4月30日）を基にヘルスケアクラウド研究会作成 項目 管理策 ガバナンス ・金融機関のIT戦略計画やアーキテクチャの一部としてクラウドコンピューティング・サービスを利用するための 戦略 クラウド セキュリティ 管理 ・クラウドサービスプロバイダーのセキュリティに関する適切なデューデリジェンスと継続的な監視・モニタリング ・金融機関およびクラウドサービスプロバイダー向けの契約上の責任、能力、制限 ・クラウドコンピューティング環境に存在するシステムおよび情報資産向け在庫プロセス ・セキュリティの構成、プロビジョニング、ロギング、モニタリング ・アイデンティティ／アクセス管理とネットワーク制御 ・機微データに対するセキュリティ・コントロール ・情報セキュリティ啓発およびトレーニングプログラム
- 12. 12 ・クラウドコンピューティング・サービスのリスク管理（続き） 項目 管理策 変更管理 ・変更管理およびソフトウェア開発ライフサイクルのプロセス ・マイクロサービス・アーキテクチャ レジリエンス と復旧 ・ビジネスレジリエンスと復旧の機能 ・インシデント対応機能 監査および コントロー ルの評価 ・重要システムに対する金融機関のコントロールに関する定期的検証 ・クラウドサービスプロバイダーが管理するコントロールに関する監視およびモニタリング ・クラウドコンピューティングサービス固有のコントロール -仮想インフラストラクチャの管理 -クラウドコンピューティング環境におけるコンテナの利用 -クラウドコンピューティング環境向けのマネージド・セキュリティサービス（例．CASB）の利用 -データおよびサービスの相互運用性とポータビリティの考慮 -データの破壊または無毒化 出典：FFIEC 「Security in a Cloud Computing Environment」（2020年4月30日）を基にヘルスケアクラウド研究会作成
- 14. 14 米国保健福祉省（HHS）「国家医療IT調整室（ONC) 21世紀治療法最終規則」（2020年3月9日） • 電子保健医療情報の相互運用性に関わる標準規格「HL7-FHIR （Fast Healthcare Interoperability Resources）」を採用して、 認証電子健康記録技術プログラムの一部であるAPIの利用を支援 • 患者が、スマートフォンを利用して、医師の電子健康記録（EHR)から、 重要な医療情報にアクセスすることを可能に • 「メディケア・メディケイド・サービス・センター（CMS)相互運用性および 患者アクセス最終規則」と組合せて、APIを介したデータの相互運用性を 推進する医療機関やベンダーに経済インセンティブを付与 • Amazon、Google、IBM、Microsoft、Oracle、Salesforceなどが、 HL7-FHIRの普及・促進を図ることを表明
- 15. 15 FHIRセキュリティ (v4.0.1: R4) (https://www.hl7.org/fhir/security.html) 1. 時刻同期（Time Keeping） 2. 通信セキュリティ（Communications Security） 3. 認証（Authentication） 4. 権限付与／アクセス制御（Authorization/Access Control) 5. 監査(Audit) 6. デジタル署名(Digital Signitures) 7. 添付物(Attachments) 8. ラベル(Labels) 9. データ管理ポリシー(Data Management Policies) 10.記述(Narrative) 11.入力の検証(Input Validation)
- 16. 16 米国保健福祉省（HHS）「ONC FHIR at Scaleタスク フォース (FAST)： データ交換を促進する 拡張性のあるFHIR インフラストラクチャ」 （2020年8月25日） • 保健医療データ交換における APIの役割 出典：HHS 「ONC FHIR at Scale Taskforce (FAST): Scalable FHIR Infrastructure to Facilitate Data Exchange」（2020年8月25日）
- 17. 17 ・統合型アーキテクチャの全体的イメージ 出典：HHS 「ONC FHIR at Scale Taskforce (FAST): Scalable FHIR Infrastructure to Facilitate Data Exchange」 （2020年8月25日）
- 18. 18 FHIRの適用：技術的課題とFASTが提案するソリューション 出典：HHS 「ONC FHIR at Scale Taskforce (FAST): Scalable FHIR Infrastructure to Facilitate Data Exchange」 （2020年8月25日）
- 19. 19 ・信頼されたエコシステムの提案 • ユーザー認証： UDAPの階層化された OAuth • 信頼された動的クライアント レジストリ（DCR)： UDAPの信頼されたDCR • 属性情報伝達： UDAP JWTベースの 属性情報伝達 • クライアント認証： UDAP JWTベースの クライアント認証 出典：HHS 「ONC FHIR at Scale Taskforce (FAST): Scalable FHIR Infrastructure to Facilitate Data Exchange」（2020年8月25日）
- 20. 20 ・信頼された動的クライアント・レジストリとトークン要求の提案 出典：HHS 「ONC FHIR at Scale Taskforce (FAST): Scalable FHIR Infrastructure to Facilitate Data Exchange」 （2020年8月25日）
- 21. 21 ・ONC FAST検証＆認証プログラムの提案 出典：HHS 「ONC FHIR at Scale Taskforce (FAST): Scalable FHIR Infrastructure to Facilitate Data Exchange」 （2020年8月25日）
- 22. 22 米国保健福祉省（HHS）「HIPAAとクラウドコンピューティ ングに関するガイダンス」（2016年10月7日） No. 質問 回答 1 HIPAAの適用対象主体（CE）または事業提携者（BA）は、電子保護対象保健情報（ePHI）を保存または処理するために、クラウ ドサービスを利用可能か？ はい 2 クラウドサービスプロバイダー（CSP)が暗号化されたePHIのみを保存し、復号化鍵を持たない場合、それはHIPAAの事業提携者 か？ はい 3 CSPを、郵便サービスのような「導管」であり、従ってHIPAA規則の遵守義務がある事業提携者でないと考えることはできるか？ いいえ 4 どのCSPが、HIPAA遵守のクラウドサービスを提供しているか？ --- 5 HIPAAの適用対象主体(または事業提携者）が、最初にCSPとの間で事業提携契約書（BAA)を締結することなく、CSPを利用して ePHIを維持した場合、どうなるか？ --- 6 CSPが、HIPAAの適用対象主体または事業提携者のePHIを含むセキュリティインシデントを経験した場合、そのインシデントを 適用対象主体または事業提携者に報告しなければならないか？ はい 7 HIPAA規則は、クラウド上でePHIにアクセスするために、医療提供者がモバイル機器を利用することを認めるか？ はい 8 HIPAA規則は、適用対象主体または事業提携者向けサービスの提供を終了した後の一定期間、CSPに対して、ePHIの維持を要求 するか？ いいえ 9 HIPAA規則は、適用対象主体または事業提携者が、米国外のサーバー上にePHIを保存するCSPを利用することを認めるか？ はい 10 HIPAA規則は、事業提携者であるCSPに対し、適用対象主体または事業提携者である顧客のセキュリティプラクティスについて、 文書化の提供を要求したり、監査を認めたりするか？ いいえ 11 CSPが、HIPAAプライバシー規則に従って非識別化された情報のみを受け入れ維持する場合、それは事業提携者に該当するか？ いいえ 出典：U.S. Department of Health & Human Services「Guidance on HIPAA & Cloud Computing」（2016年10月7日） （https://www.hhs.gov/hipaa/for-professionals/special-topics/cloud-computing/index.html）
- 23. 23 HL7-FHIR向けクラウドサービスのセキュリティ管理策 • Microsoft「FHIR Server for Azure: An open source project for cloud-based health solutions」（2018年11月12日） • Microsoft「Lighting up healthcare data with FHIR®: Announcing the Azure API for FHIR」(2019年2月7日) • Microsoft「Azure API for FHIR® moves to general availability」 (2019年10月21日) • 主要なセキュリティ管理機能 • Azure Active Directoryを利用した アイデンティティ／アクセス管理 （例．OAuth 2.0） • 強制されたロールベースのアクセス制御 • 多層防御によるセキュアなデータ保存 出典：GitHUb 「microsoft/fhir-server」 (https://github.com/microsoft/fhir-server)
- 25. 25 DevOpsとは？ • アプリケーションの開発と配備を自動化することにフォーカスした、アプリケー ション開発の新しい方法論であり考え方である • 開発チームと運用チームの間の協力とコミュニケーションを改善してより深く 結びつけることを意味し、特にアプリケーション配備とインフラストラクチャ運用 の自動化に焦点を当てている • コード堅牢化、変更管理、本番アプリケーションのセキュリティを改善するだけ でなくセキュリティ運用全般をも強化してくれる 出典：日本クラウドセキュリティ アライアンス「クラウドコンピュー ティングのためのセキュリティガイ ダンス v4.0」日本語版1.1 （2017年7月） 継続的インテグレーション／ 継続的デプロイ（CI/CD） パイプライン
- 26. 26 DevOpsのセキュリティへの波及効果 項目 波及効果と長所 標準化 DevOps では、本番に組み込まれるものはすべて、承認済みのコードと設定用テンプレートに基づき、継続的 インテグレーション／継続的デプロイ（CI/CD）パイプラインによって生み出される。開発、テスト、本番（の コード）はすべて完全に 同一のソースファイルから派生しており、周知となっている優れた標準からの逸脱を防 いでいる。 自動化された テスト 広範な種類のセキュリティテストは、必要に応じて補助的に手動 テストを加えることで、CI/CD パイプラインに 組み込むことが可能である。 不可変性(immutable) CI/CD パイプラインは、素早く確実に、仮想マシンやコンテナ、インフラストラクチャスタックのマスターイメージ を生成する。これにより配備の自動化と不可変(immutable)なインフラストラクチャを実現する。 監査と変更管理の改善 CI/CD パイプラインはソースファイルにある 1 文字の変更に至るまでの全て を追跡調査できる。バージョン管 理リポジトリに格納され たアプリケーションスタック（インフラストラクチャを含む）の全履歴と共に、その変更は 変更を行った人物と紐づけられる。 SecDevOps/DevSecO ps と Rugged DevOps SecDevOps/DevSecOps は セキュリティ運用を改善するために DevOps の自動化技術を使う。 Rugged DevOps はアプリケーション開発過程にセキュリティテスティングを組み入れることを意味し、よ り強 固で、よりセキュアで、より障害耐性の高いアプリケーションを生み出す。 出典：日本クラウドセキュリティアライアンス「クラウドコンピューティングのための セキュリティガイダンス v4.0」日本語版1.1（2017年7月）
- 27. 27 マイクロサービス・セキュリティのガイドライン • 米国NIST 「SP 800-204: Security Strategies for Microservices-based Application Systems」 （2019年8月） • マイクロサービスの設計原則 • 個々のマイクロサービスは、他のマイクロサービスから独立して、管理、 複製、スケーリング、アップグレード、展開される • 個々のマイクロサービスは、単独の機能を有し、制限された 環境（例．制限された責任を有し、他のサービスに依存する）で 稼働する • すべてのマイクロサービスは、一定の障害や復旧のために設計されるべき であり、可能な限りステートレスである必要がある • 状況管理のために、既存のトラステッドサービス（例．データベース、 キャッシュ、ディレクトリ）を再利用すべきである
- 28. 28 マイクロサービスのコア機能 • 認証とアクセス制御 • サービス・ディスカバリー • セキュリティ監視・分析 マイクロサービスのAPIゲートウェイ機能 • 最適化されたエンドポイント • リクエストやレスポンスの共有、API変換、プロトコル変換 • サーキットブレーカー • ロードバランサー • レート制限 • ブルー／グリーン・デプロイメント • カナリア・リリース
- 29. 29 • マイクロサービス運用のアーキテクチャ・フレームワーク アーキテクチャ・フレームワーク アーキテクチャ全体における役割 APIゲートウェイ ・南北・東西のトラフィックを制御するのに使用される（後者 はマイクロゲートウェイを使用） ・マイクロサービスがweb／アプリケーションサーバーに展開さ れる時、マイクロゲートウェイが導入される サービス・メッシュ ・コンテナを使用してマイクロサービスが展開される時、純粋に 東西のトラフィックのために導入されるが、マイクロサービスが VMまたはアプリケーションサーバーにハウジングされる状況下 で使用することができる 出典：NIST “SP 800-204: Security Strategies for Microservices-based Application Systems ” （2019年8月）
- 30. 30 ・マイクロサービスの脅威とセキュリティ戦略(1) 脅威 セキュリティ戦略 アイデンティティ／アクセス管理 ・認証（MS-SS-1） ・アクセス管理（MS-SS-2） サービス・ディスカバリーのメカニズム ・サービスレジストリ構成（MS-SS-3） セキュアな通信プロトコル ・セキュアな通信（MS-SS-4） セキュリティモニタリング ・セキュリティモニタリング（MS-SS-5） 遮断機能の展開 ・遮断機能の展開（MS-SS-6） ロードバランシング ・ロードバランシング（MS-SS-7） レート制限 ・レート制限（MS-SS-8） 完全性の保証 ・マイクロサービスの最新版の導入（MS-SS-9） ・セッション維持の取扱（MS-SS-10） ボットネット攻撃への対抗 ・資格情報の悪用やリスト型攻撃の防止（MS-SS-11） マイクロサービスのアーキテクチャ・フレーム ワーク ・APIゲートウェイの展開（MS-SS-12） ・サービス・メッシュの展開（MS-SS-13） 出典：NIST “SP 800-204: Security Strategies for Microservices-based Application Systems ”（2019年8月）
- 31. 31 サービス・メッシュを利用したマイクロサービスのセキュリティ 米国NIST 「SP 800-204A: Building Secure Microservices-based Applications Using Service-Mesh Architecture」（2020年5月） • サービス・プロキシーに基づく手法におけるサービス・メッシュの コンポーネント向け展開ガイドラインを提供する: • サービス・プロキシー向け通信構成 • Ingressプレキシー向け構成 • 外部サービスへのアクセス向け構成 • アイデンティティ／アクセス管理向け構成 • 監視機能向け構成 • ネットワーク・レジリエンス向け構成 • オリジン間リソース共有(CORS)向け構成
- 32. 32 ・なぜサービス・メッシュか？ No. セキュリティ戦略 SM- AR1 サービス・メッシュ・コードをマイクロサービス・アプリケーション・コードに組込んで、 サービス・メッシュが、アプリケーション開発フレームワークで重要な役割を果たすよう にすることができる SM- AR2 サービス・メッシュ・コードがライブラリとして展開されると、アプリケーションは、API コール経由でサービス・メッシュにより提供されるサービスに結合される SM- AR3 サービス・メッシュ機能は、マイクロサービス・インスタンスの前にデプロイされた各プロ キシとともにプロキシに展開され、マイクロサービスベース・アプリケーション向けのイン フラストラクチャサービスを集合的に提供する（サイドカー・プロキシ） SM- AR4 サービス・メッシュ機能は、マイクロサービス・インスタンスごとではなく、ノードごとにデ プロイされたプロキシ（例．物理的ホスト）とともにプロキシに展開される 出典：NIST 「SP 800-204A: Building Secure Microservices-based Applications Using Service-Mesh Architecture」（2020年5月）
- 33. 33 ・マイクロサービス・ベース・アプリケーションのセキュリティ 項目 考慮点 認証と権限付与 ・認証／アクセスポリシーは、マイクロサービスが呼び出すAPIの種類に依存する ・証明に基づく認証は、公開鍵インフラストラクチャ（PKI)と鍵管理を要求する サービス・ディスカバリー （サービスリクエストの間に サービスを発見する機能） ・動的に変わるロケーションを持った各サービスに関連して、相当数のサービスと多くのインスタン スが存在する ・各マイクロサービスには、仮想マシン（VM)またはコンテナとして展開されたものがあり、動的 にIPアドレスが割り当てられた可能性がある ・サービスに関連するインスタンスの数は、負荷変動によって異なる ネットワーク・レジリエンス 技術を介した可用性の向上 ・ロードバランサー（負荷分散） ・サーキットブレーカー（遮断機能） ・レート制限／調整 ・ブルー／グリーン・デプロイメント ・カナリア・リリース アプリケーション監視の要求 事項 ・分散ロギング、メトリクス生成、分析パフォーマンス、追跡を介したマイクロサービスの内外の ネットワークトラフィックのモニタリング 出典：NIST 「SP 800-204A: Building Secure Microservices-based Applications Using Service-Mesh Architecture」（2020年5月）
- 34. 34 ・サービス・メッシュの定義と技術的背景(1) 項目 考慮点 マイクロサービスの機能 ・ビジネスロジック：ビジネス機能、計算処理、サービス構成／統合 ・ネットワーク機能：サービス間の通信メカニズム サービス・メッシュのコン ポーネント データプレーン：アプリケーションからのリクエストをフォワードする機能を提供するデータパス コントロールプレーン：メッシュに渡ってデータプレーン（プロキシ）の行動を制御・構成するために 使用されるAPIツール類 サービス・メッシュの機 能 ・認証と権限付与 ・サービスディスカバリー ・セキュアなコミュニケーション ・コミュニケーション向けのレジリエンス／安定性機能 出典：NIST 「SP 800-204A: Building Secure Microservices-based Applications Using Service-Mesh Architecture」（2020年5月）
- 35. 35 ・サービス・メッシュの定義と技術的背景(2) 項目 考慮点 Ingressコントロー ラー ・サービスメッシュ内部にある実際のAPIを覆っているすべてのクライアント向けの共通API ・HTTP／HTTPSのようなwebに適したプロトコルから、RPC／gRPC／RESTのようなマイクロサー ビスが使用するプロトコルへのプロトコル変換 ・クライアントからのシングルコールに対応して、サービスメッシュ内部の複数サービスへのコールから受け 取った結果の構成 ・負荷分散 ・パブリックTLS終了 Egressコントロー ラー ・メッシュ外にあるマイクロサービス向けのマイクロサービスから発生する内部トラフィックをコントロールす るサービス・プロキシ ・外部ネットワークへの通信をホワイトリスト化する単一セットのワークロード（例．ホスト、IPアドレス） ・資格情報の交換：外部システムの資格情報に直接アクセスするアプリケーションなしに、内部のID資 格情報から外部の資格情報（例．SSOトークン、API鍵）に変換する ・webに適したプロトコル（例．HTTP／HTTPS）から、マイクロサービスに適したプロトコル（例． RPC／gRPC／REST）へのプロトコル変換 出典：NIST 「SP 800-204A: Building Secure Microservices-based Applications Using Service-Mesh Architecture」（2020年5月）
- 36. 36 ・サービス・メッシュの定義と技術的背景(3) 項目 考慮点 通信ミドルウェアとし てのサービス・メッ シュ：相違点 ・伝統的な分散システム向けミドルウェア：アプリケーションデリバリー・コントローラー（ADC)、負荷分 散装置、APIゲートウェイ ・マイクロサービスの通信トラフィックの特徴：「東西」＞「南北」 • 「南北」トラフィック：クライアントとアプリケーション間の通信トラフィック • 「東西」トラフィック：マイクロサービス間の通信トラフィック ・軽量通信ミドルウェアとしてのサービス・メッシュ：プロダクションアプリケーションとして許容できるパ フォーマンス・レベルが要求される ・クラウドネイティブ・アプリケーションの機能として、マイクロサービス・アプリケーションが、コンテナなしで 導入されるケース：サービスベース・アーキテクチャ、APIドリブン通信、コンテナベース・インフラストラク チャ、DevOpsプロセスに関するバイアスなど サービス・メッシュ：最 先端の手法 ・各マイクロサービスをコンテナとして展開する ・アプリケーションは、コンテナ・オーケストレーション・ツールを利用して管理されるコンテナ・クラスター（可 用性とパフォーマンスの向上目的）を活用する ・クラウドプロバイダーが提供し、コンテナ管理／オーケストレーション環境に必要な展開／構成ツールを 有するContainer as a Service (CaaS) 経由で、アプリケーションをホストする 出典：NIST 「SP 800-204A: Building Secure Microservices-based Applications Using Service-Mesh Architecture」（2020年5月）
- 37. 37 サービス・メッシュ展開の推奨事項 • サービス・プロキシー向け通信構成（1） 項目 推奨事項 概要 SM- DR1 サービス・プロキシーに 許容されたトラフィック に関する推奨事項 サービス・プロキシーが関連サービス向けのトラフィックを受容できるプロトコルおよびポートの セットを指定する機能があるべきである。デフォルトで、サービス・プロキシは、この構成により 指定された通り、トラフィックの例外を許容スべきでない。 SM- DR2 サービス・プロキシーの 到達可能性に関する 推奨事項 サービス・プロキシーが到達できるサービス・セットは制限されるべきである。名前空間、すなわ ち所与の名前空間またはサービスのランタイム・アイデンティティ内で特別に命名されたサービ スに基づいてアクセスを制限する機能があるべきである。サービス・メッシュのコントロール・プ レーンへのアクセスは、常に、リレー・ディスカバリー、異なるポリシー、テレメトリーデータに提 供されるべきである。 SM- DR3 プロトコル転送機能に 関する推奨事項 サービス・プロキシーは、ターゲットのマイクロサービスよりも、クライアントの異なるプロトコル との通信を支援する組込み機能を有するべきである（例．REST／HTTPリクエストからｇ RPCリクエストへの変換またはHTTP／1.1からHTTP／2への更新）。これにより、攻撃表 面を増加させる、クライアントごとに分離したサーバー構築へのニーズを回避することが要求 される。 出典：NIST 「SP 800-204A: Building Secure Microservices-based Applications Using Service-Mesh Architecture」（2020年5月）
- 38. 38 • サービス・プロキシー向け通信構成（2） 項目 推奨事項 概要 SM- DR4 ユーザーの拡張可能 性に関する推奨事項 サービス・プロキシは、ネットワーク機能を処理する組込ロジックに加えて、カスタム・ロジックを 定義するための機能を有するべきである。これにより、ユースケース固有のポリシー（例．予 め存在するまたは自家製のポリシー・エンジン）を展開するために、サービス・プロキシを拡張 できることの保証が要求される。この展開では、サンドボックス化、使用する言語のAPI／ラ ンタイム制限、または安全を保証する事前分析の実行（例．WASM、eBPF）など、拡張 性のリスクをコントールする手段を提供すべきである。 SM- DR5 プロキシー向け動的構 成機能に関する推奨 事項 静的構成に加えて、動的にプロキシを構成する（例．イベント・ドリブン構成アップデート） 選択肢があるべきである。言い換えれば、既知の展開時よりも、動的であることが見込まれ る主体向けのディスカバリー・サービスがあるべきである。さらに、従来の構成下で未解決のリ クエストを効率的に処理する（例．完了または終了）一方、プロキシはランタイム時、新た な動的構成へ原子的に交換すべきである。これにより、ユーザートラフィックの劣化やダウンタ イムなく（例．サービス・プロキシを再起動することなく）、ランタイム時、迅速にポリシー変更 を強制することが要求される。 SM- DR6 アプリケーション・サー ビスとプロキシ間の通 信構成に関する推奨 事項 アプリケーション・サービスおよびその関連プロキシは、ループバック・チャンネル（例．ローカ ルホストIPアドレス、UNIXドメイン・ソケットなど）経由のみで通信すべきである。さらに、 サービス・プロキシは、すべての交換データ・パケットが暗号化された相互TLS（mTLS）セッ ションを設定することによってのみ個々の通信を行うべきである。 出典：NIST 「SP 800-204A: Building Secure Microservices-based Applications Using Service-Mesh Architecture」（2020年5月）
- 39. 39 • Ingressプレキシー向け構成 項目 推奨事項 概要 SM- DR7 Ingressプレキシー に関する推奨事項 サービス・プロキシのように、Ingress（スタンドアロン）プロキシ向けにトラフィック・ルーティ ング・ポリシーを構成する機能を有すべきである。アプリケーション・ディプロイメントのエッジま で幅広くルーティング・ポリシーの一貫した強制が要求されるため、これが必要とされる。 出典：NIST 「SP 800-204A: Building Secure Microservices-based Applications Using Service-Mesh Architecture」（2020年5月）
- 40. 40 • 外部サービスへのアクセス向け構成 項目 推奨事項 概要 SM- DR8 外部リソースへのアク セス制限に関する推 奨事項 外部リソースまたはメッシュ外部のサービスへのアクセスは、デフォルトで無効化し、特定の目 的地へのアクセスを制限する明示的ポリシーよってのみ許容されるべきである。加えて、外部 リソースまたはサービスは、サービス・メッシュ自体のサービス（例．サービス・メッシュのサービ ス・ディスカバリー・メカニズムに含まれる）としてモデル化すべきである。 SM- DR9 外部リソースへのセ キュアなアクセスに関 する推奨事項 サービス・メッシュ内部のサービス向けに構成される、同様の可用性向上機能（例．タイムア ウト、サーキットブレーカー）が、外部リソースおよびサービスへのアクセス向けに提供される べきである。 SM- DR10 Egressプロキシーに 関する推奨事項 サービスおよびIngressプロキシのように、Egress（スタンドアロン）プロキシ向けにトラ フィック・ルーティング・ポリシーを構成する機能を有すべきである。ディプロイされた時、外部リ ソースおよびサービスへのアクセスは、これらEgressプロキシにより調整されるべきである。 Egressプロキシは、アクセスおよび可用性のポリシー（SM-DR8）を展開スべきである。こ れは、伝統的なネットワークに基づくセキュリティ・モデルとともに作業するのに役立つ。たとえ ば、インターネットへのアウトバウンド・トラフィックが、ネットワーク内の特定のIPからのみ許 容されると仮定する；Egressプロキシは、メッシュにおける一連のサービス向けのトラフィック を代理する一方、そのアドレスとともに稼働するよう構成することができる。 出典：NIST 「SP 800-204A: Building Secure Microservices-based Applications Using Service-Mesh Architecture」（2020年5月）
- 41. 41 • アイデンティティ／アクセス管理向け構成（1） 項目 推奨事項 概要 SM- DR11 ユニバーサル・アイデ ンティティ・ドメインに 関する推奨事項 マイクロサービスのすべてのインスタンスのアイデンティティは、一貫性があり一意であるべきで ある－稼働場所に関係なく共通の名前を有すべきであるという点で一貫性があり、システム 全体に渡ってという点で一意であり、サービス名がそのサービスに対応してさえすればよい。こ れは、異なるロケーションに異なる論理的サービスがあることを意味しているのではない； 個々のサービスに各自のDNS名が割り当てられた、典型的なドメインネームシステム （DNS)の利用は、この推奨事項を満たしている。サービス向けの一貫した名前（アイデン ティティ）では、システムポリシーが管理可能であることが要求される。 SM- DR12 証明書の展開の署 名に関する推奨事項 サービス・メッシュのコントロールプレーン証明管理システムでは、自己署名により証明を生成 する機能を停止すべきである。この機能は、サービス・メッシュにおいて、他のすべてのアイデン ティティ証明向けにイニシャルサインを自動実行するために、しばしば利用される。その代わり、 メッシュのコントロールプレーンで利用される署名証明が、常に企業の既存のPKIの信頼の 基点（Root of Trust）に根付いたものである必要がある。これは、既存のPKI（例． 失効または監査向け）により、証明の管理を簡素化するものである。さらに、我々は、ロー テーションを簡素化し、きめの細かい失効を可能にするために、別個の中間署名証明が異な るドメイン向けに生成されるべきことを推奨している。 SM- DR13 アイデンティティ証明 書の更新に関する推 奨事項 マイクロサービスのアイデンティティ証明の有効期間は、インフラストラクチャ内部で管理可能 なように、可能な限り短く－できれば時間の順序に従うべきである。攻撃者は、資格情報が 失効するまでの間、資格情報を利用しさえすればサービスになりすますことができるが、資格 情報を成功裏に再び奪うことは、攻撃者にとってますます難しくなっているので、この方法は 攻撃を制限するのに役立つ。
- 42. 42 • アイデンティティ／アクセス管理向け構成（2） 項目 推奨事項 概要 SM- DR14 アイデンティティ変更 におけるサービス・プ ロキシーのサイクル接 続に関する推奨事項 サービス・プロキシのアイデンティティ証明がローテーションしている時、サービス・プロキシは、 既存のコネクションを効率的に終了して、新たな証明とともに、すべての新たなコネクションを 設定すべきである。証明書は、mTLSのハンドシェイクの間のみ有効なので、新たな証明が 発行された時に既存のコネクションを置き換えることは厳格に要求されない；むしろ、遅れず に攻撃を制限するために重要である。 SM- DR15 アイデンティティ証明 書に署名しない場合 の推奨事項 マイクロサービスを識別するために利用される証明書は、署名認証であってはならない。 SM- DR16 証明書発行前の ワークロード認証に 関する推奨事項 サービス・メッシュのコントロールプレーンの証明管理システムは、アイデンティティ証明を発行 する前に、サービス・インスタンスの認証を実行すべきである。多くのシステムでは、システムの オーケストレーション・エンジンに対するインスタンスを証明し、他のローカル証明（例．HSM から収集した鍵）を利用することによって、これが達成可能となる。 SM- DR17 セキュアなネーミング サービスに関する推 奨事項 mTLSに利用される証明が、サーバー・アイデンティティを実行したら、サーバー・メッシュは、 セキュアなディスカバリー・サービスまたはDNSによって提供されるマイクロサービス名に、サー バー・アイデンティティをマッピングするセキュアな命名サービスを提供スべきである。この要求 事項は、サーバーがマイクロサービス向けに認可されたロケーションであることを保証し、ネット ワークハイジャックから保護するために必要である。 出典：NIST 「SP 800-204A: Building Secure Microservices-based Applications Using Service-Mesh Architecture」（2020年5月）
- 43. 43 • アイデンティティ／アクセス管理向け構成（3） 項目 推奨事項 概要 SM- DR18 きめ細かいアイデン ティティに関する推奨 事項 個々のマイクロサービスは、各自のアイデンティティを有すべきであり、このサービスのすべての インスタンスは、ランタイム時に同じアイデンティティを示すべきである。これにより、所与の名 前空間において、マイクロサービスのレベルでアクセスポリシーが適用されることが可能となる。 これが要求されることによって、サービスごとでなく、名前空間ごとにアイデンティティを発行す ることが、共通のマイクロサービスのランタイムにおけるデフォルトとなり、同一の名前空間にあ るすべてのサービスが、特に指定されない限り、共通のランタイムのアイデンティティとなる。加 えて、ラベルは、サービス名（アイデンティティ）を増大させて、きめの細かいロギング構成を 可能にし、きめの細かい認可ポリシーをサポートするために、利用することができる。 SM- DR19 認証ポリシーのス コープに関する推奨 事項 認証のポリシー・スコープを指定する機能は、最低限、以下の選択肢を有すべきである： (a)すべての名前空間におけるすべてのマイクロサービス、(b)特別な名前空間におけるすべ てのマイクロサービス、(c)所与の名前空間における特定のマイクロサービス（SM-DR17で 参照したランタイム・アイデンティティを利用）。 SM- DR20 認証トークンに関す る推奨事項 トークンは、その中に含まれる要求が認証を保証するように、デジタル的に署名・暗号化され るべきであり、アクセスコントロールに関する意思決定を構築するために、認証されたアイデン ティティの増強またはその一部として利用することができる。さらに、これらのトークンは、ルー プバック・デバイス経由（ネットワーク・パスが含まれていないことを保証するため）または暗 号化されたチャンネル経由のみで通過させるべきである。 出典：NIST 「SP 800-204A: Building Secure Microservices-based Applications Using Service-Mesh Architecture」（2020年5月）
- 44. 44 • 監視機能向け構成 項目 推奨事項 概要 SM- DR21 イベントのロギングに 関する推奨事項 プロキシは、入力の妥当性エラーおよび特別な（予期しない）パラメーターのエラー、クラッ シュ、コアダンプをロギングすべきである。共通の攻撃検知機能には、Bearerトークン再利 用攻撃およびインジェクション攻撃が含まれるべきである。 SM- DR22 リクエストのロギング に関する推奨事項 プロキシは、少なくとも、不規則なリクエスト（例．HTTP使用時の200番以外のレスポン ス）向けの共通ログ形式フィールドをロギングすべきである。成功したリクエスト（例．200 番レスポンス）のロギングは、メトリックが利用可能な時、ほとんど意味がない傾向がある。 SM- DR22 ログメッセージのコン テンツに関する推奨 事項 ログメッセージは、最低限、イベントの日時、マイクロサービス名またはアイデンティティ、リクエ ストトレースID、メッセージおよびその他コンテキスト情報（例．ユーザー識別子とURLのリ クエスト時）を含むべきである。しかしながら、たとえばBearerトークンなど、機微な情報を 覆うために注意を払うべきである。 SM- DR23 必須指標に関する推 奨事項 外部クライアントおよびマイクロサービスの呼び出し向けにサービス・メッシュを使用してメト リックを収集するための構成には、最低限、(a)所与の期間におけるクライアント／サービス のリクエスト数、(b)failureコードによる失敗したクライアント／サービスのリクエスト数、 (c)サービス当たりの平均レーテンシーおよび完了リクエストのライフサイクル当たり平均総 レーテンシー（理想的にはヒストグラム；またはfailureコードによる）を含むべきである。 SM- DR24 分散トレーシングの 展開に関する推奨事 項 分散トレーシングの展開向けにサービス・プロキシを構成する時、アプリケーション・サービスが、 受け取った通信パケットのヘッダーを転送するように設定されていることを確認するよう注意を 払うべきである。 出典：NIST 「SP 800-204A: Building Secure Microservices-based Applications Using Service-Mesh Architecture」（2020年5月）
- 45. 45 • ネットワーク・レジリエンス向け構成 項目 推奨事項 概要 SM- DR25 サービス・インスタンス のヘルスチェックの展開 に関する推奨事項 再試行、タイムアウト、サーキットブレーカーまたはカナリア・デプロイメントに関連するデータ （一般的にすべてのコントロールプレーン構成データ）は、キーバリューストアのような、堅 牢なデータストアに保存スべきである。 SM- DR26 サービス・インスタンス のヘルスチェックの展開 に関する推奨事項 再試行、タイムアウト、サーキットブレーカーまたはカナリア・デプロイメントに関連するデータ （一般的にすべてのコントロールプレーン構成データ）は、キーバリューストアのような、堅 牢なデータストアに保存スべきである。 項目 推奨事項 概要 SM- DR27 オリジン間リソース共 有(CORS)に関する 推奨事項 エッジサービス（例．マイクロサービスのエントリーポイント）は、web UIクライアント・サー ビスとしてのように、外部サービスと通信するCORS向けに構成されることがしばしばあり得る。 エッジサービス向けのCORSポリシーは、マイクロサービス・アプリケーション・サービスのコード を経由して処理するよりも、サービス・メッシュ機能（例．」IstioにおけるVirtualService リソースのCorsPolicy構成）を利用して構成されるべきである。 • オリジン間リソース共有(CORS)向け構成 出典：NIST 「SP 800-204A: Building Secure Microservices-based Applications Using Service-Mesh Architecture」（2020年5月）
- 46. 46 • 管理運用向け許可の構成 項目 推奨事項 概要 SM- DR28 管理運用向けアクセ ス・コントロールに関 する推奨事項 名前空間、名前空間内で命名されたサービスなど、すべてのサービスレベルで指定可能な、 サービス・メッシュにおける全管理運用向けの粒度の細かいアクセス・コントロール許可（例． ポリシー指定、サービス・レジリエンシー・パラメーター向けの構成パラメーター、カナリア・デプ ロイメント、再試行など）を有すべきである。一般的に、この機能を実行するインタフェースは、 サービス・メッシュ自体の一部でなく、アプリケーションサービス・クラスターの構成に利用され るインストール用ソフトウェアまたはオーケストレーション・ソフトウェアの一部であることがある。 出典：NIST 「SP 800-204A: Building Secure Microservices-based Applications Using Service-Mesh Architecture」（2020年5月）