Weitere ähnliche Inhalte Ähnlich wie エッジコンピューティング環境におけるアプリケーションコンテナ/マイクロサービスのセキュリティ/リスク管理 (20) Mehr von Eiji Sasahara, Ph.D., MBA 笹原英司 (18) エッジコンピューティング環境におけるアプリケーションコンテナ/マイクロサービスのセキュリティ/リスク管理4. 4
1-1.アプリケーションコンテナ/マイクロサービスとは?(1)
• 米国立標準技術研究所(NIST) 「SP 800-180(Draft):
NIST マイクロサービス、アプリケーションコンテナ、システム仮想
マシンの定義」(2016年2月)
• アプリケーションコンテナ:
共有OS上で稼働するアプリケーションまたはそのコンポーネントとして
パッケージ化し、稼働するように設計された構成物
• マイクロサービス:
アプリケーション・コンポーネントのアーキテクチャを、疎結合のパターンに
分解した結果生まれる基本的要素であり、標準的な通信プロトコルや
明確に定義された API を利用して相互に通信する自己充足型サービス
を構成し、いかなるベンダー、製品、技術からも独立している
8. 8
1-3.ゼロトラストとは?(1)
• 米国立標準技術研究所(NIST)「SP 800-207:
ゼロトラスト・アーキテクチャ」(2020年4月19日)
• ゼロトラスト(ZT)=危険に晒されたと見なされるネットワークに直面した
情報システムおよびサービスにおいて、正確な、特権の少ない、あらかじめ
要求されたアクセスに関する意思決定を強制する際に、不確実性を最小化
するように設計された概念やアイデアの集合
• ゼロトラスト・アーキテクチャ(ZTA)=ゼロトラストの概念を活用して、コン
ポーネントの関係、ワークフロー計画、アクセスポリシーを包含した、エンタープ
ライズのサイバーセキュリティ計画
• ゼロトラストエンタープライズ:ゼロトラストアーキテクチャ計画のプロダクトと
して、エンタープライズに配置されるネットワークインフラストラクチャ(物理的
および仮想的)および業務ポリシー
12. 12
1-4.DevOpsとは?(2)
• 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月)
14. 14
2-1.インダストリー4.0向けフォグ×クラウド(1)
• Tim Bayer et al. 「状態モニタリングおよびインダストリー4.0
配布向けフォグ-クラウドコンピューティング・インフラストラクチャ」
(2019年5月2-4日)
Proceedings of the 9th International Conference on
Cloud Computing and Services Science, CLOSER 2019,
Heraklion, Crete, Greece, May 2-4, 2019
• コンテナ化のアーキテクチャ
• インフラストラクチャサービス
• Kubernetesマスター
• Kubernetesノード
• ネットワーク・通信
出典:Tim Bayer et al. 「A Fog-Cloud Computing
Infrastructure for Condition Monitoring and
Distributing Industry 4.0 Services」(2019年5月2-4日)
17. 17
2-2. コネクテッドカー向けマイクロサービス(1)
• Salman Taherizadeh et al. 「動的Internet of Things向
け毛細管コンピューティングアーキテクチャ:エッジデバイスからフォグ
/クラウドプロバイダーまでのマイクロサービスのオーケストレーション」
(2018年9月4日)
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6164252/
• モノリシック対マイクロサービス
アーキテクチャの
アプリケーション構造
出典:Salman Taherizadeh et al. 「A Capillary
Computing Architecture for Dynamic Internet of
Things: Orchestration of Microservices from
Edge Devices to Fog and Cloud Providers」
(2018年9月4日)
25. 25
3-1. クラウドネイティブのIoTセキュリティ(5)
• IoTセキュリティの推奨事項
出典:Cloud Security Alliance「Recommendations for IoT Firmware Update Processes」(2018年9月)
番号 推奨事項
1 更新適用の前に、現在作動しているIoTデバイスの構成のバックアップをとる
2 ロールアップがサポートされるべきであるが、ベンダーの権限付与なく、古いイメージをリロードすべきでない
3 システム設計は、ネットワークの飽和状態を回避し、意図しないダウンタイムを制限するために、管理者によるデバイス
更新のスケジューリングを許容すべきである
4 ベンダーは、自動更新をサポートするシステム管理者による構成のオプションをサポートすべきである
5 1つのコンポーネントが、IoTデバイスを構成する複数のマイクロコントローラーの更新を管理すべきである
6 更新戦略や差のあるまたは完全なイメージは、帯域幅の制限に適応すべきである
7 更新は、認証を受け、エンドツーエンドで保護された完全性を有すべきである
8 認証署名鍵のストレージはセキュアであるべきである
9 更新の失敗をカバーするために復旧手順を提供する
10 ベンダーによる長期サポート契約を保証する
29. 29
3-2. スマートシティのIoTセキュリティ (4)
項目 概要
ベンダーの
セキュリ
ティ
・ベンダーが、製品のユーザービリティを検証するために、製品テストを実施し、大規模環境をシミュレーションする方法
・ベンダーが、攻撃や知財の漏えいから自分のインフラストラクチャを保護する方法
・ベンダーは、スパイや操作から、開発環境や知財を適正に保護しているか
・ベンダーは、独立した主体に、セキュリティフローやバックドアに関するインフラストラクチャのテストを要求するポリシーや手順を
導入しているか
・ベンダーは、製品、ネットワーク、システム上で、定期的に、独立したコードレビューやペネトレーションテストを実施しているか
・ベンダーは、どのようにして、設計詳細、製品リスト、顧客のコンタクト情報など、顧客に関する詳細を保護するするか
・ベンダーは、セキュア開発ライフサイクル(SDLC)プログラムを有しているか
・ベンダーは、マルウェア、バックドアなどを含む製品の発送を防止するために、サイバーサプライチェーン・サイバーセキュリティを
執行するか
・ベンダーは、公のセキュリティ脆弱性開示・報告ポリシーや、脆弱性報告書を入手する適切なコンタクトチャネルを有しているか
・ベンダーは、コンピューター緊急対応チーム(CERT)、コンピューターセキュリティ・インシデント対応チーム(CSIRT)、オンラ
インサポートなど、セキュリティ問題/インシデントのためのサポートチームを有しているか
製品管理 ・新製品を現行システムに統合する際、セキュリティの影響度を評価しているか
・新製品統合のためのセキュリティ要求事項を保証するために、特別な手段を導入しているか
検証試験 スマート技術を採用する組織は、製品のセキュリティ機能に関するベンダーの要求事項を確認すべきである
・基本的なセキュリティ要求事項の法令遵守
・ペネトレーションテスト
・ハードニング
・認証
・運用セキュリティの検証と妥当性確認
30. 30
3-2. スマートシティのIoTセキュリティ(5)
項目 概要
技術の導入 ・技術が、選定フェーズのセキュリティテストに合格したことを保証する
・技術が、セキュアに配送されたことを保証する
・強力な暗号化が可能なことを保証する
・セキュアなシステム管理を保証する
・強力なパスワード設定を保証する
・不必要なユーザーアカウントが削除されていることを保証する
・利用しない機能やサービスが無効であることを保証する
・セキュリティイベントに対する監査が可能なことを保証する
・改ざん防止、破壊防止メカニズムを追加する
技術の運用と
維持
・モニタリング
・パッチ当て
・定期的な評価と監査
・ロギング環境の保護
・アクセス制御
・サイバー脅威インテリジェンス
・危険な状態への対応と発見
技術の廃棄 ・再利用技術の回避
・セキュアなデータ消去
・ベンダー入れ替えの重要性
34. 34
3-4.マイクロサービスのクラウドセキュリティ(1)
• 米国NIST 「SP 800-204: マイクロサービスベースの
アプリケーションシステム向けセキュリティ戦略」(2019年8月)
• マイクロサービスの設計原則
• 個々のマイクロサービスは、他のマイクロサービスから独立して、管理、
複製、スケーリング、アップグレード、展開される
• 個々のマイクロサービスは、単独の機能を有し、制限された環境(例.
制限された責任を有し、他のサービスに依存する)で稼働する
• すべてのマイクロサービスは、一定の障害や復旧のために設計されるべき
であり、可能な限りステートレスである必要がある
• 状況管理のために、既存のトラステッドサービス(例.データベース、
キャッシュ、ディレクトリ)を再利用すべきである
37. 37
3-4.マイクロサービスのクラウドセキュリティ(4)
• マイクロサービスの脅威とセキュリティ戦略(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月)
39. 39
3-4.マイクロサービスのクラウドセキュリティ(6)
• 米国NIST 「SP 800-204A: サービス・メッシュ・アーキテク
チャを利用したセキュアなマイクロサービスベース・アプリケーション
の構築」(2020年5月)
• なぜサービス・メッシュか?
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月)
41. 41
3-4.マイクロサービスのクラウドセキュリティ(8)
・サービス・メッシュの定義と技術的背景(1)
出典:NIST 「SP 800-204A: Building Secure Microservices-based Applications Using Service-Mesh Architecture」(2020年5月)
項目 考慮点
マイクロサービスの機能 ・ビジネスロジック:ビジネス機能、計算処理、サービス構成/統合
・ネットワーク機能:サービス間の通信メカニズム
サービス・メッシュのコン
ポーネント
データプレーン:アプリケーションからのリクエストをフォワードする機能を提供するデータパス
コントロールプレーン:メッシュに渡ってデータプレーン(プロキシー)の行動を制御・構成するために使用される
APIツール類
サービス・メッシュの機能 ・認証と権限付与
・サービスディスカバリー
・セキュアなコミュニケーション
・コミュニケーション向けのレジリエンス/安定性機能
Ingressコントローラー ・サービスメッシュ内部にある実際のAPIを覆っているすべてのクライアント向けの共通API
・HTTP/HTTPSのようなwebに適したプロトコルから、RPC/gRPC/RESTのようなマイクロ
サービスが使用するプロトコルへのプロトコル変換
・クライアントからのシングルコールに対応して、サービスメッシュ内部の複数サービスへのコールから
受け取った結果の構成
・負荷分散
・パブリックTLS終了
42. 42
3-4.マイクロサービスのクラウドセキュリティ(9)
・サービス・メッシュの定義と技術的背景(2)
出典:NIST 「SP 800-204A: Building Secure Microservices-based Applications Using Service-Mesh Architecture」(2020年5月)
項目 考慮点
Egressコントローラー ・メッシュ外にあるマイクロサービス向けのマイクロサービスから発生する内部トラフィックをコントロールするサービ
ス・プロキシー
・外部ネットワークへの通信をホワイトリスト化する単一セットのワークロード(例.ホスト、IPアドレス)
・資格情報の交換:外部システムの資格情報に直接アクセスするアプリケーションなしに、内部のID
資格情報から外部の資格情報(例.SSOトークン、API鍵)に変換する
・webに適したプロトコル(例.HTTP/HTTPS)から、マイクロサービスに適したプロトコル
(例.RPC/gRPC/REST)へのプロトコル変換
通信ミドルウェアとしての
サービス・メッシュ:相違
点
・伝統的な分散システム向けミドルウェア:アプリケーションデリバリー・コントローラー(ADC)、負荷分散装置、
APIゲートウェイ
・マイクロサービスの通信トラフィックの特徴:「東西」>「南北」
• 「南北」トラフィック:クライアントとアプリケーション間の通信トラフィック
• 「東西」トラフィック:マイクロサービス間の通信トラフィック
・軽量通信ミドルウェアとしてのサービス・メッシュ:プロダクションアプリケーションとして許容できるパフォーマン
ス・レベルが要求される
・クラウドネイティブ・アプリケーションの機能として、マイクロサービス・アプリケーションが、コンテナなしで導入され
るケース:サービスベース・アーキテクチャ、APIドリブン通信、コンテナベース・インフラストラクチャ、DevOpsプ
ロセスに関するバイアスなど
43. 43
3-4.マイクロサービスのクラウドセキュリティ(10)
・サービス・メッシュの定義と技術的背景(3)
出典:NIST 「SP 800-204A: Building Secure Microservices-based Applications Using Service-Mesh Architecture」(2020年5月)
項目 考慮点
サービス・メッシュ:最先
端の手法
・各マイクロサービスをコンテナとして展開する
・アプリケーションは、コンテナ・オーケストレーション・ツールを利用して管理されるコンテナ・クラスター(可用性と
パフォーマンスの向上目的)を活用する
・クラウドプロバイダーが提供し、コンテナ管理/オーケストレーション環境に必要な展開/構成ツールを有する
Container as a Service (CaaS) 経由で、アプリケーションをホストする