NIST SP 800-240A サービス・メッシュ・アーキテクチャを利用したセキュアなマイクロサービス・ベース・アプリケーション構築の概説
•
0 likes•601 views
サービス・メッシュを利用したマイクロサービスのセキュリティ 米国NIST 「SP 800-204A: Building Secure Microservices-based Applications Using Service-Mesh Architecture」 （2020年5月）
![2
クラウドセキュリティアライアンス
アプリケーションコンテナ／マイクロサービスWGのご紹介
[目的]
セキュアなアプリケーションコンテナおよびマイクロサービス利用の
ためのガイダンスやベストプラクティスを発行する
アプリケーションコンテナおよびマイクロサービスのセキュリティに
関する啓発活動を行う
[WGリーダー]
Anil Karmel（NIST SP 800-180(Draft) 筆頭著者）
Andrew Wild（QTS Data Centers・CISO)](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to NIST SP 800-240A サービス・メッシュ・アーキテクチャを利用したセキュアなマイクロサービス・ベース・アプリケーション構築の概説
Similar to NIST SP 800-240A サービス・メッシュ・アーキテクチャを利用したセキュアなマイクロサービス・ベース・アプリケーション構築の概説 (20)
More from Eiji Sasahara, Ph.D., MBA 笹原英司
More from Eiji Sasahara, Ph.D., MBA 笹原英司 (16)
Recently uploaded
Recently uploaded (8)
NIST SP 800-240A サービス・メッシュ・アーキテクチャを利用したセキュアなマイクロサービス・ベース・アプリケーション構築の概説
- 1. 2020年6月 Cloud Security Alliance Application Containers and Microservices WG NIST SP 800-240A サービス・メッシュ・アーキテクチャを利用した セキュアなマイクロサービス・ベース・ アプリケーション構築の概説
- 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月発行）
- 4. 4 サービス・メッシュを利用したマイクロサービスのセキュリティ 米国NIST 「SP 800-204A: Building Secure Microservices-based Applications Using Service-Mesh Architecture」（2020年5月） • サービス・プロキシーに基づく手法におけるサービス・メッシュの コンポーネント向け展開ガイドラインを提供する: • サービス・プロキシー向け通信構成 • Ingressプレキシー向け構成 • 外部サービスへのアクセス向け構成 • アイデンティティ／アクセス管理向け構成 • 監視機能向け構成 • ネットワーク・レジリエンス向け構成 • オリジン間リソース共有(CORS)向け構成
- 5. 5 [構成](1) • 1. 序論 • 2. マイクロサービス・ベースのアプリケーション – 背景とセキュリティ要求事項: • 認証と権限付与の要求事項 • サービス・ディスカバリー • ネットワーク・レジリエンス技術を介した可用性の向上 • アプリケーション監視の要求事項 • 3. サービス・メッシュ – 定義と技術的背景 • サービス・メッシュのコンポーネントと機能 • Ingressコントローラー • Egressコントローラー • 通信ミドルウェアとしてのサービス・メッシュ：相違点 • サービス・メッシュ：最先端
- 6. 6 [構成](2) • 4. サービス・メッシュ展開の推奨事項 • サービス・プロキシー向け通信構成 • Ingressプレキシー向け構成 • 外部サービスへのアクセス向け構成 • アイデンティティ／アクセス管理向け構成 • 監視機能向け構成 • ネットワーク・レジリエンス向け構成 • オリジン間リソース共有(CORS)向け構成 • 管理運用向け許可の構成
- 7. 7 1. 序論 なぜサービス・メッシュか？ • SM-AR1：サービス・メッシュ・コードをマイクロサービス・アプリケーション・ コードに組込んで、サービス・メッシュが、アプリケーション開発フレームワーク で重要な役割を果たすようにすることができる • SM-AR2：サービス・メッシュ・コードがライブラリとして展開されると、アプリ ケーションは、APIコール経由でサービス・メッシュにより提供されるサービスに 結合される • SM-AR3：サービス・メッシュ機能は、マイクロサービス・インスタンスの前に デプロイされた各プロキシとともにプロキシに展開され、マイクロサービスベー ス・アプリケーション向けのインフラストラクチャサービスを集合的に提供する （サイドカー・プロキシ） • SM-AR4：サービス・メッシュ機能は、マイクロサービス・インスタンスごとでは なく、ノードごとにデプロイされたプロキシ（例．物理的ホスト）とともにプロ キシに展開される
- 8. 8 2. マイクロサービス・ベースのアプリケーション – 背景とセキュリティ要求事項 • 認証と権限付与の要求事項 • 認証／アクセスポリシーは、マイクロサービスが呼び出すAPIの種類に依 存する • 証明に基づく認証は、公開鍵インフラストラクチャ（PKI)と鍵管理を要 求する • サービス・ディスカバリー • 動的に変わるロケーションを持った各サービスに関連して、相当数の サービスと多くのインスタンスが存在する • 各マイクロサービスには、仮想マシン（VM)またはコンテナとして展開 されたものがあり、動的にIPアドレスが割り当てられた可能性がある • サービスに関連するインスタンスの数は、負荷変動によって異なる *サービス・レジストリ＝サービスリクエストの間にサービスを発見する機能
- 9. 9 2. 続き • ネットワーク・レジリエンス技術を介した可用性の向上 • ロードバランサー（負荷分散） • サーキットブレーカー（遮断機能） • レート制限／調整 • ブルー／グリーン・デプロイメント • カナリア・リリース • アプリケーション監視の要求事項 • 分散ロギング、メトリクス生成、分析パフォーマンス、追跡を介した マイクロサービスの内外のネットワークトラフィックのモニタリング
- 10. 10 3. サービス・メッシュ – 定義と技術的背景 • マイクロサービスの機能 • ビジネスロジック：ビジネス機能、計算処理、サービス構成／統合 • ネットワーク機能：サービス間の通信メカニズム(→サービスメッシュ) • サービス・メッシュのコンポーネント • データプレーン：アプリケーションからのリクエストをフォワードする機能 を提供するデータパス • コントロールプレーン：メッシュに渡ってデータプレーン（プロキシ）の 行動を制御・構成するために使用されるAPIツール類 • サービス・メッシュの機能 • 認証と権限付与 • サービスディスカバリー • セキュアなコミュニケーション • コミュニケーション向けのレジリエンス／安定性機能
- 11. 11 3. 続き（1） • Ingressコントローラー • サービスメッシュ内部にある実際のAPIを覆っているすべての クライアント向けの共通API • HTTP／HTTPSのようなwebに適したプロトコルから、RPC／ gRPC／RESTのようなマイクロサービスが使用するプロトコルへの プロトコル変換 • クライアントからのシングルコールに対応して、サービスメッシュ内部の 複数サービスへのコールから受け取った結果の構成 • 負荷分散 • パブリックTLS終了
- 12. 12 3. 続き（2） • Egressコントローラー • メッシュ外にあるマイクロサービス向けのマイクロサービスから発生する 内部トラフィックをコントロールするサービス・プロキシ • 外部ネットワークへの通信をホワイトリスト化する単一セットのワーク ロード（例．ホスト、IPアドレス） • 資格情報の交換：外部システムの資格情報に直接アクセスするアプ リケーションなしに、内部のID資格情報から外部の資格情報（例． SSOトークン、API鍵）に変換する • webに適したプロトコル（例．HTTP／HTTPS）から、マイクロ サービスに適したプロトコル（例．RPC／gRPC／REST）への プロトコル変換
- 13. 13 3. 続き（3） • 通信ミドルウェアとしてのサービス・メッシュ：相違点 • 伝統的な分散システム向けミドルウェア：アプリケーションデリバリー・ コントローラー（ADC)、負荷分散装置、APIゲートウェイ • マイクロサービスの通信トラフィックの特徴：「東西」＞「南北」 • 「南北」トラフィック：クライアントとアプリケーション間の通信 トラフィック • 「東西」トラフィック：マイクロサービス間の通信トラフィック • 軽量通信ミドルウェアとしてのサービス・メッシュ：プロダクションアプリ ケーションとして許容できるパフォーマンス・レベルが要求される • クラウドネイティブ・アプリケーションの機能として、マイクロサービス・ アプリケーションが、コンテナなしで導入されるケース： サービスベース・アーキテクチャ、APIドリブン通信、コンテナベース・イン フラストラクチャ、DevOpsプロセスに関するバイアスなど
- 14. 14 3. 続き（4） • サービス・メッシュ：最先端の手法 • 各マイクロサービスをコンテナとして展開する • アプリケーションは、コンテナ・オーケストレーション・ツールを利用して管 理されるコンテナ・クラスター（可用性とパフォーマンスの向上目的） を活用する • クラウドプロバイダーが提供し、コンテナ管理／オーケストレーション環 境に必要な展開／構成ツールを有するContainer as a Service (CaaS) 経由で、アプリケーションをホストする
- 15. 15 4. サービス・メッシュ展開の推奨事項 • サービス・プロキシー向け通信構成（1） 項目 推奨事項 概要 SM- DR1 サービス・プロキシーに 許容されたトラフィック に関する推奨事項 サービス・プロキシーが関連サービス向けのトラフィックを受容できるプロトコルおよびポートの セットを指定する機能があるべきである。デフォルトで、サービス・プロキシは、この構成により 指定された通り、トラフィックの例外を許容スべきでない。 SM- DR2 サービス・プロキシーの 到達可能性に関する 推奨事項 サービス・プロキシーが到達できるサービス・セットは制限されるべきである。名前空間、すなわ ち所与の名前空間またはサービスのランタイム・アイデンティティ内で特別に命名されたサービ スに基づいてアクセスを制限する機能があるべきである。サービス・メッシュのコントロール・プ レーンへのアクセスは、常に、リレー・ディスカバリー、異なるポリシー、テレメトリーデータに提 供されるべきである。 SM- DR3 プロトコル転送機能に 関する推奨事項 サービス・プロキシーは、ターゲットのマイクロサービスよりも、クライアントの異なるプロトコル との通信を支援する組込み機能を有するべきである（例．REST／HTTPリクエストからｇ RPCリクエストへの変換またはHTTP／1.1からHTTP／2への更新）。これにより、攻撃表 面を増加させる、クライアントごとに分離したサーバー構築へのニーズを回避することが要求 される。
- 16. 16 • サービス・プロキシー向け通信構成（2） 項目 推奨事項 概要 SM- DR4 ユーザーの拡張可能 性に関する推奨事項 サービス・プロキシは、ネットワーク機能を処理する組込ロジックに加えて、カスタム・ロジックを 定義するための機能を有するべきである。これにより、ユースケース固有のポリシー（例．予 め存在するまたは自家製のポリシー・エンジン）を展開するために、サービス・プロキシを拡張 できることの保証が要求される。この展開では、サンドボックス化、使用する言語のAPI／ラ ンタイム制限、または安全を保証する事前分析の実行（例．WASM、eBPF）など、拡張 性のリスクをコントールする手段を提供すべきである。 SM- DR5 プロキシー向け動的構 成機能に関する推奨 事項 静的構成に加えて、動的にプロキシを構成する（例．イベント・ドリブン構成アップデート） 選択肢があるべきである。言い換えれば、既知の展開時よりも、動的であることが見込まれ る主体向けのディスカバリー・サービスがあるべきである。さらに、従来の構成下で未解決のリ クエストを効率的に処理する（例．完了または終了）一方、プロキシはランタイム時、新た な動的構成へ原子的に交換すべきである。これにより、ユーザートラフィックの劣化やダウンタ イムなく（例．サービス・プロキシを再起動することなく）、ランタイム時、迅速にポリシー変更 を強制することが要求される。 SM- DR6 アプリケーション・サー ビスとプロキシ間の通 信構成に関する推奨 事項 アプリケーション・サービスおよびその関連プロキシは、ループバック・チャンネル（例．ローカ ルホストIPアドレス、UNIXドメイン・ソケットなど）経由のみで通信すべきである。さらに、 サービス・プロキシは、すべての交換データ・パケットが暗号化された相互TLS（mTLS）セッ ションを設定することによってのみ個々の通信を行うべきである。
- 17. 17 • Ingressプレキシー向け構成 項目 推奨事項 概要 SM- DR7 Ingressプレキシー に関する推奨事項 サービス・プロキシのように、Ingress（スタンドアロン）プロキシ向けにトラフィック・ルーティ ング・ポリシーを構成する機能を有すべきである。アプリケーション・ディプロイメントのエッジま で幅広くルーティング・ポリシーの一貫した強制が要求されるため、これが必要とされる。
- 18. 18 • 外部サービスへのアクセス向け構成 項目 推奨事項 概要 SM- DR8 外部リソースへのアク セス制限に関する推 奨事項 外部リソースまたはメッシュ外部のサービスへのアクセスは、デフォルトで無効化し、特定の目 的地へのアクセスを制限する明示的ポリシーよってのみ許容されるべきである。加えて、外部 リソースまたはサービスは、サービス・メッシュ自体のサービス（例．サービス・メッシュのサービ ス・ディスカバリー・メカニズムに含まれる）としてモデル化すべきである。 SM- DR9 外部リソースへのセ キュアなアクセスに関 する推奨事項 サービス・メッシュ内部のサービス向けに構成される、同様の可用性向上機能（例．タイムア ウト、サーキットブレーカー）が、外部リソースおよびサービスへのアクセス向けに提供される べきである。 SM- DR10 Egressプロキシーに 関する推奨事項 サービスおよびIngressプロキシのように、Egress（スタンドアロン）プロキシ向けにトラ フィック・ルーティング・ポリシーを構成する機能を有すべきである。ディプロイされた時、外部リ ソースおよびサービスへのアクセスは、これらEgressプロキシにより調整されるべきである。 Egressプロキシは、アクセスおよび可用性のポリシー（SM-DR8）を展開スべきである。こ れは、伝統的なネットワークに基づくセキュリティ・モデルとともに作業するのに役立つ。たとえ ば、インターネットへのアウトバウンド・トラフィックが、ネットワーク内の特定のIPからのみ許 容されると仮定する；Egressプロキシは、メッシュにおける一連のサービス向けのトラフィック を代理する一方、そのアドレスとともに稼働するよう構成することができる。
- 19. 19 • アイデンティティ／アクセス管理向け構成（1） 項目 推奨事項 概要 SM- DR11 ユニバーサル・アイデ ンティティ・ドメインに 関する推奨事項 マイクロサービスのすべてのインスタンスのアイデンティティは、一貫性があり一意であるべきで ある－稼働場所に関係なく共通の名前を有すべきであるという点で一貫性があり、システム 全体に渡ってという点で一意であり、サービス名がそのサービスに対応してさえすればよい。こ れは、異なるロケーションに異なる論理的サービスがあることを意味しているのではない； 個々のサービスに各自のDNS名が割り当てられた、典型的なドメインネームシステム （DNS)の利用は、この推奨事項を満たしている。サービス向けの一貫した名前（アイデン ティティ）では、システムポリシーが管理可能であることが要求される。 SM- DR12 証明書の展開の署 名に関する推奨事項 サービス・メッシュのコントロールプレーン証明管理システムでは、自己署名により証明を生成 する機能を停止すべきである。この機能は、サービス・メッシュにおいて、他のすべてのアイデン ティティ証明向けにイニシャルサインを自動実行するために、しばしば利用される。その代わり、 メッシュのコントロールプレーンで利用される署名証明が、常に企業の既存のPKIの信頼の 基点（Root of Trust）に根付いたものである必要がある。これは、既存のPKI（例． 失効または監査向け）により、証明の管理を簡素化するものである。さらに、我々は、ロー テーションを簡素化し、きめの細かい失効を可能にするために、別個の中間署名証明が異な るドメイン向けに生成されるべきことを推奨している。 SM- DR13 アイデンティティ証明 書の更新に関する推 奨事項 マイクロサービスのアイデンティティ証明の有効期間は、インフラストラクチャ内部で管理可能 なように、可能な限り短く－できれば時間の順序に従うべきである。攻撃者は、資格情報が 失効するまでの間、資格情報を利用しさえすればサービスになりすますことができるが、資格 情報を成功裏に再び奪うことは、攻撃者にとってますます難しくなっているので、この方法は 攻撃を制限するのに役立つ。
- 20. 20 • アイデンティティ／アクセス管理向け構成（2） 項目 推奨事項 概要 SM- DR14 アイデンティティ変更 におけるサービス・プ ロキシーのサイクル接 続に関する推奨事項 サービス・プロキシのアイデンティティ証明がローテーションしている時、サービス・プロキシは、 既存のコネクションを効率的に終了して、新たな証明とともに、すべての新たなコネクションを 設定すべきである。証明書は、mTLSのハンドシェイクの間のみ有効なので、新たな証明が 発行された時に既存のコネクションを置き換えることは厳格に要求されない；むしろ、遅れず に攻撃を制限するために重要である。 SM- DR15 アイデンティティ証明 書に署名しない場合 の推奨事項 マイクロサービスを識別するために利用される証明書は、署名認証であってはならない。 SM- DR16 証明書発行前の ワークロード認証に 関する推奨事項 サービス・メッシュのコントロールプレーンの証明管理システムは、アイデンティティ証明を発行 する前に、サービス・インスタンスの認証を実行すべきである。多くのシステムでは、システムの オーケストレーション・エンジンに対するインスタンスを証明し、他のローカル証明（例．HSM から収集した鍵）を利用することによって、これが達成可能となる。 SM- DR17 セキュアなネーミング サービスに関する推 奨事項 mTLSに利用される証明が、サーバー・アイデンティティを実行したら、サーバー・メッシュは、 セキュアなディスカバリー・サービスまたはDNSによって提供されるマイクロサービス名に、サー バー・アイデンティティをマッピングするセキュアな命名サービスを提供スべきである。この要求 事項は、サーバーがマイクロサービス向けに認可されたロケーションであることを保証し、ネット ワークハイジャックから保護するために必要である。
- 21. 21 • アイデンティティ／アクセス管理向け構成（3） 項目 推奨事項 概要 SM- DR18 きめ細かいアイデン ティティに関する推奨 事項 個々のマイクロサービスは、各自のアイデンティティを有すべきであり、このサービスのすべての インスタンスは、ランタイム時に同じアイデンティティを示すべきである。これにより、所与の名 前空間において、マイクロサービスのレベルでアクセスポリシーが適用されることが可能となる。 これが要求されることによって、サービスごとでなく、名前空間ごとにアイデンティティを発行す ることが、共通のマイクロサービスのランタイムにおけるデフォルトとなり、同一の名前空間にあ るすべてのサービスが、特に指定されない限り、共通のランタイムのアイデンティティとなる。加 えて、ラベルは、サービス名（アイデンティティ）を増大させて、きめの細かいロギング構成を 可能にし、きめの細かい認可ポリシーをサポートするために、利用することができる。 SM- DR19 認証ポリシーのス コープに関する推奨 事項 認証のポリシー・スコープを指定する機能は、最低限、以下の選択肢を有すべきである： (a)すべての名前空間におけるすべてのマイクロサービス、(b)特別な名前空間におけるすべ てのマイクロサービス、(c)所与の名前空間における特定のマイクロサービス（SM-DR17で 参照したランタイム・アイデンティティを利用）。 SM- DR20 認証トークンに関す る推奨事項 トークンは、その中に含まれる要求が認証を保証するように、デジタル的に署名・暗号化され るべきであり、アクセスコントロールに関する意思決定を構築するために、認証されたアイデン ティティの増強またはその一部として利用することができる。さらに、これらのトークンは、ルー プバック・デバイス経由（ネットワーク・パスが含まれていないことを保証するため）または暗 号化されたチャンネル経由のみで通過させるべきである。
- 22. 22 • 監視機能向け構成 項目 推奨事項 概要 SM- DR21 イベントのロギングに 関する推奨事項 プロキシは、入力の妥当性エラーおよび特別な（予期しない）パラメーターのエラー、クラッ シュ、コアダンプをロギングすべきである。共通の攻撃検知機能には、Bearerトークン再利 用攻撃およびインジェクション攻撃が含まれるべきである。 SM- DR22 リクエストのロギング に関する推奨事項 プロキシは、少なくとも、不規則なリクエスト（例．HTTP使用時の200番以外のレスポン ス）向けの共通ログ形式フィールドをロギングすべきである。成功したリクエスト（例．200 番レスポンス）のロギングは、メトリックが利用可能な時、ほとんど意味がない傾向がある。 SM- DR22 ログメッセージのコン テンツに関する推奨 事項 ログメッセージは、最低限、イベントの日時、マイクロサービス名またはアイデンティティ、リクエ ストトレースID、メッセージおよびその他コンテキスト情報（例．ユーザー識別子とURLのリ クエスト時）を含むべきである。しかしながら、たとえばBearerトークンなど、機微な情報を 覆うために注意を払うべきである。 SM- DR23 必須指標に関する推 奨事項 外部クライアントおよびマイクロサービスの呼び出し向けにサービス・メッシュを使用してメト リックを収集するための構成には、最低限、(a)所与の期間におけるクライアント／サービス のリクエスト数、(b)failureコードによる失敗したクライアント／サービスのリクエスト数、 (c)サービス当たりの平均レーテンシーおよび完了リクエストのライフサイクル当たり平均総 レーテンシー（理想的にはヒストグラム；またはfailureコードによる）を含むべきである。 SM- DR24 分散トレーシングの 展開に関する推奨事 項 分散トレーシングの展開向けにサービス・プロキシを構成する時、アプリケーション・サービスが、 受け取った通信パケットのヘッダーを転送するように設定されていることを確認するよう注意を 払うべきである。
- 23. 23 • ネットワーク・レジリエンス向け構成 項目 推奨事項 概要 SM- DR25 サービス・インスタンス のヘルスチェックの展開 に関する推奨事項 再試行、タイムアウト、サーキットブレーカーまたはカナリア・デプロイメントに関連するデータ （一般的にすべてのコントロールプレーン構成データ）は、キーバリューストアのような、堅 牢なデータストアに保存スべきである。 SM- DR26 サービス・インスタンス のヘルスチェックの展開 に関する推奨事項 再試行、タイムアウト、サーキットブレーカーまたはカナリア・デプロイメントに関連するデータ （一般的にすべてのコントロールプレーン構成データ）は、キーバリューストアのような、堅 牢なデータストアに保存スべきである。 項目 推奨事項 概要 SM- DR27 オリジン間リソース共 有(CORS)に関する 推奨事項 エッジサービス（例．マイクロサービスのエントリーポイント）は、web UIクライアント・サー ビスとしてのように、外部サービスと通信するCORS向けに構成されることがしばしばあり得る。 エッジサービス向けのCORSポリシーは、マイクロサービス・アプリケーション・サービスのコード を経由して処理するよりも、サービス・メッシュ機能（例．」IstioにおけるVirtualService リソースのCorsPolicy構成）を利用して構成されるべきである。 • オリジン間リソース共有(CORS)向け構成
- 24. 24 • 管理運用向け許可の構成 項目 推奨事項 概要 SM- DR28 管理運用向けアクセ ス・コントロールに関 する推奨事項 名前空間、名前空間内で命名されたサービスなど、すべてのサービスレベルで指定可能な、 サービス・メッシュにおける全管理運用向けの粒度の細かいアクセス・コントロール許可（例． ポリシー指定、サービス・レジリエンシー・パラメーター向けの構成パラメーター、カナリア・デプ ロイメント、再試行など）を有すべきである。一般的に、この機能を実行するインタフェースは、 サービス・メッシュ自体の一部でなく、アプリケーションサービス・クラスターの構成に利用され るインストール用ソフトウェアまたはオーケストレーション・ソフトウェアの一部であることがある。