![5
1-1. 米国FedRAMP 「2024-2025年FedRAMPロードマップ」
(2024年3月28日)
(https://www.fedramp.gov/2024-03-28-a-new-roadmap-for-fedramp/)
[目標]
1. 顧客体験の向上:
クラウドサービスプロバイダーがFedRAMP認証を取得しやすくするためのプロセス改善を目指す
2. サイバーセキュリティとリスク管理のリーダーシップ:
FedRAMPをサイバーセキュリティとリスク管理の分野でのリーダーとして位置づける
3. 信頼できるFedRAMPマーケットプレイスの拡大:
連邦機関が利用できるクラウドサービスの市場を拡大する
4. 自動化と技術先進の運営によるプログラムの効果向上:
自動化と最新技術を活用して、プログラムの効率と効果を高める](https://image.slidesharecdn.com/csakansaicloudworkload20240924v1-251004104632-f0b526b0/85/FedRAMP-September-24-2024-5-320.jpg)
![82
4-1. OWASP DevSecOps ガイドライン v-0.2(1)
[構成]
0 – イントロダクション
0-a – 概要
0-b – 脅威モデリング
1 – コミット前
1-a – 秘密管理
1-b – コードの検査(Linting)
2 – 脆弱性スキャン
2-a – 静的(Static)アプリケーションテスト
2-b – 動的(Dynamic)アプリケーションテスト
2-c – インタラクティブな(Interactive)アプリケーションテスト
2-d – ソフトウェア構成分析
2-e – インフラストラクチャ脆弱性スキャン
2-f – コンテナ脆弱性スキャン
2-g – プライバシー
3 – コンプライアンス監査](https://image.slidesharecdn.com/csakansaicloudworkload20240924v1-251004104632-f0b526b0/85/FedRAMP-September-24-2024-82-320.jpg)
Uploaded byEiji Sasahara, Ph.D., MBA 笹原英司
クラウドワークロードセキュリティと 新FedRAMPガイダンス September 24, 2024
1. 新FedRAMPガイダンス 2. CSAクラウドセキュリティガイダンスV5とクラウドワークロードセキュリティ 3. CSAクラウドセキュリティガイダンスV5とアプリケーションセキュリティ 4. OWASP DevSecOps／API関連ガイドライン 5. まとめ／Q&A
クラウドワークロードセキュリティと 新FedRAMPガイダンス September 24, 2024
- 1. @esasahara Cloud Security Alliance DevSecOps/ServerlessWG クラウドワークロードセキュリティと 新FedRAMPガイダンス September 24, 2024
- 2.
- 3. 3 AGENDA • 1. 新FedRAMPガイダンス •2. CSAクラウドセキュリティガイダンスV5と クラウドワークロードセキュリティ • 3. CSAクラウドセキュリティガイダンスV5と アプリケーションセキュリティ • 4. OWASP DevSecOps／API関連ガイドライン • 5. まとめ／Q&A
- 4. 4 AGENDA • 1. 新FedRAMPガイダンス 1-1.米国FedRAMP 「2024-2025年FedRAMPロードマップ」 1-2. 米国FedRAMP 「新興技術優先順位付けフレームワーク」 1-3. 米国大統領府行政管理予算局（OMB）「クラウドサービスの セキュアな採用を加速するためのFedRAMPガイダンス」
- 5. 5 1-1. 米国FedRAMP 「2024-2025年FedRAMPロードマップ」 (2024年3月28日) (https://www.fedramp.gov/2024-03-28-a-new-roadmap-for-fedramp/) [目標] 1.顧客体験の向上: クラウドサービスプロバイダーがFedRAMP認証を取得しやすくするためのプロセス改善を目指す 2. サイバーセキュリティとリスク管理のリーダーシップ: FedRAMPをサイバーセキュリティとリスク管理の分野でのリーダーとして位置づける 3. 信頼できるFedRAMPマーケットプレイスの拡大: 連邦機関が利用できるクラウドサービスの市場を拡大する 4. 自動化と技術先進の運営によるプログラムの効果向上: 自動化と最新技術を活用して、プログラムの効率と効果を高める
- 6. 6 ロードマップの設定施策 施策 目標 ・事前承認を必要としない新しい “重要変更リクエスト” プロセスを試行することにより、アジャイルなソフトウェアの デリバリーを可能にする ・認証プロセスにおいて、より大きなセキュリティ目標を妨げる既知の主要政策の障壁に取り組む ・ガイダンス、トレーニング、リアルワールド事例の生きた知識ベースを作成することにより、FedRAMPを成功裏に 導く方法の明確さを極める ・CSPに対して、CISAと協力して、サービスの安全な構成プロファイルと使用に関するガイダンスを提供するよう 奨励する 1.顧客体験の向上 ・GSAのFedRAMPプログラムおよびエコシステムに、より多くの技術的能力と専門知識を導入する ・政府全体の適正性の想定を支えるすべてのFedRAMP認証に対する基本的なセキュリティ期待事項を定義する ・FedRAMPと外部フレームワーク間の相互承認の初期アプローチを定義して、低インパクトのSaaSから始める 2. サイバーセキュリティ とリスク管理のリーダー シップ ・信頼できる認証パートナーと共に低レビューのプロセスを実施し、国防総省とのパイロットプロジェクトを追求する ・初期の合同認証グループを形成し、FedRAMP認証における追加のレビューや遅延を減らす ・CSPのサイバーセキュリティ体制の可視性を向上させ、負担を軽減するために、継続的な監視を集中化し、自動 化する 3. 信頼できる FedRAMP マーケットプレイスの 拡大 ・顧客の実際の体験に基づいた新しい主要業績評価指標を発表し、時間と費用の結果を含める ・FedRAMPの新しい技術プラットフォームを確立し、データファースト、APIファーストの基盤を提供することにより、 各機関やクラウドプロバイダーがFedRAMPからセキュリティ情報を送受信できるようにする ・自動化をサポートするために、機械判読可能な“デジタル認証パッケージ”をサポートして、商用クラウドプロバイ ダーや機関パートナーとともに試験運用する 4. 自動化と技術先進 の運営によるプログラム の効果向上
- 7. 7 1-2. 米国FedRAMP 「新興技術優先順位付けフレームワーク」 (2024年6月27日) (https://www.fedramp.gov/2024-06-27-release-of-et-framework/) ・大統領令第14110号(人工知能の安心、安全で信頼できる開発と利用)に 呼応して、FedRAMPが、人工知能(AI)に係る重要なクラウド関連新興技術 (ET)に優先順位付けを行い、それに基づいて、FedRAMPの内部業務やレビュー のプロセスを行う ・優先順位付けの対象となるAI関連新興技術基準: 1.チャットインタフェース 2. コード生成デバッグツール 3. プロンプトベースの画像生成
- 8. 8 1-3. 米国大統領府行政管理予算局（OMB）「クラウドサービスの セキュアな採用を加速するためのFedRAMPガイダンス」 (2024年7月27日) (https://www.whitehouse.gov/omb/briefing-room/2024/07/26/fact-sheet-omb-releases-fedramp-guidance- to-accelerate-the-secure-adoption-of-cloud-services/) ・目的:FedRAMPのモダナイゼーション <注力テーマ> ・不可欠で効率的なセキュリティにフォーカスする • クラウド業界が製品のセキュリティを意味のある形で効率的に向上させ、 連邦政府のサイバーセキュリティ基準を満たすことを可能にする •安全なツールの利用により、連邦政府をサイバー脅威から保護する ・政府機関にとってクラウド利用をより簡単で安全なものにする ・FedRAMPガバナンスを強化する
- 9.
- 10. 10 AGENDA • 2. CSAクラウドセキュリティガイダンスV5と クラウドワークロードセキュリティ 2-1.CSAクラウドセキュリティガイダンスV5:クラウドワークロードセキュリティ 2-2. クラウドワークロードセキュリティとは? 2-3. 仮想マシン(VM) 2-4. コンテナのセキュア化 2-5. PaaSセキュリティ 2-6. サーバーレス／FaaSのセキュア化 2-7. AIワークロード 2-8. クラウドワークロードセキュリティの推奨事項
- 11. 11 2-1. CSAクラウドセキュリティガイダンスV5:クラウドワークロード セキュリティ 1. クラウドコンピューティングの概念と アーキテクチャ 2.クラウドガバナンスと戦略 3. リスク、監査とコンプライアンス 4. 組織管理 5. アイデンティティ／アクセス管理 6. セキュリティモニタリング 7. インフラストラクチャとネットワーク 8. クラウドワークロードセキュリティ 9. データセキュリティ 10.アプリケーションセキュリティ 11.インシデント対応とレジリエンス 12.関連技術・戦略 8. クラウドワークロードセキュリティ 8.1 クラウドワークロードセキュリティへの導入 8.1.1 クラウドワークロードのタイプ 8.1.2 クラウドワークロード:短期と⾧期 8.1.3 伝統的なワークロードセキュリティ制御への影響 8.1.4 ソフトウェア構成分析 8.1.5 ソフトウェア部品表(SBOM) 8.2 仮想マシン 8.2.1 仮想マシンの課題と低減策 8.2.2 ファクトリーによるセキュアな仮想マシンイメージの生成 8.2.2.1 VM向けに推奨されるツールとベストプラクティス 8.2.3 デプロイメントパイプラインによるセキュアなイメージの生成 8.2.4 スナップショットと公的暴露／抽出 8.3 コンテナのセキュア化 8.3.1 コンテナイメージの生成 8.3.2 コンテナネットワーキング 8.3.3 コンテナオーケストレーション＆管理システム 8.3.4 コンテナオーケストレーションのセキュリティ 8.3.4.1 アーティファクトリポジトリのセキュア化 8.3.4.2 セキュアなリポジトリ利用に関するベストプラクティス 8.3.5 コンテナ脆弱性の管理 8.3.6 コンテナ向けのランタイム保護 8.4 PaaSセキュリティ 8.4.1 一般的なPaaS向けのセキュリティプラクティス 8.4.2 暗号化とアクセス制御 8.4.3 特定のPaaSのセキュア化 8.5 サーバーレス／FaaS(Function as a Service)のセキュア化 8.5.1 FaaSセキュリティの課題 8.5.2 サーバーレス向けIAM 8.5.3 ネットワーク接続とアクセスパターン 8.5.4 環境変数と秘密 8.6 AIワークロード 8.6.1 AIシステムの脅威 8.6.2 AI低減戦略
- 12. 12 2-2. クラウドワークロードセキュリティとは?(1) ・クラウドワークロードの定義 クラウドコンピューティング環境で稼働する様々なタスク、アプリケーション、サービス、 プロセスであり、仮想マシン(VMs)、コンテナ、サーバーレス／FaaS (Function asa Service)、AI、PaaS(Platform as a Service) など、幅広いリソースをカバーするものである。 内容 特徴 ・データやワークロードが静的な従来型環境と異なり、クラウドは、継続的に進化する、動的で拡張的な 背景を有している。このような環境の流動的な特性は、アジャイルで順応性があるセキュリティアプローチ を必要とする。クラウドに挑むセキュリティ専門家にとって、これは、標準的なセキュリティ対策を再考して、 関与のルールが継続的に書き換えられるような背景に適応することを意味する。 動的で拡張的 ・固有の要求事項を有する様々な種類のワークロードが存在するため、セキュリティに対する汎用的な アプローチは機能しない。 複雑性と多様性 ・クラウドワークロードセキュリティの中核は、データの完全性、機密性、可用性というサイバーセキュリティ の基盤となる原則の維持にある。クラウドでは、データが変更できないこと(完全性)、認可されたユーザー だけがアクセスできること(機密性)、必要な時に利用可能なこと(可用性)の保証が重要である。 完全性、機密性、 可用性
- 13.
- 14. 14 2-2. クラウドワークロードセキュリティとは?(3) ・クラウドワークロードのタイプ(2) 内容 タイプ ・PaaSは、より効率的でオーバーヘッドの少ないアプリケーションの開発、実装、管理を促進するような、 一連のツールおよびサービスを提供することによって、クラウドプラットフォームの機能を拡張する。 ・データベースやメッセージングシステムから、コンテンツデリバリーネットワーク(CDN)に至るまで、様々な サービスに基づいたセキュリティ考慮事項を示す。 PaaS(Platform as aService) ・FaaSは、開発者が、基盤となるインフラストラクチャの管理なしに、イベントやリクエストに対応して実行さ れるような個々の機能を書いてデプロイするクラウドコンピューティングモデルである。 ・サーバーレスモデルは、セキュリティ責任のより多くの部分をCSPに委ねる。この信頼性の再割り当てにより、 CSPの特別なセキュリティ専門知識と先進的な保護対策を活かして、攻撃対象領域を最小化する。 ・CSPによる強制された分離とともに、実行環境の短期間な性質が、固有のセキュリティの利点を提供する。 ・サービス拒否(DoS)攻撃や自動スケーリングによる経済的疲弊など、不正アクセスや潜在的攻撃に対す るサーバーレスアプリケーションの保護のために、最小特権による秘密の管理と機能の構成が最も重要で ある。 サーバーレス／ FaaS(Function as a Service) ・AIワークロードは、膨大な量の学習用データを処理して、意思決定を行い、予測を提供する。敵対的攻 撃に対する保護、モデルの盗難の防止、プロンプトインジェクションに対する保護を特に強調しながら、デー タの完全性とプライバシーを保証することが最も重要である。 ・このような脆弱性にも関わらず、AIワークロードは、先進的な計算処理リソースとクラウド環境の拡張性 を活用する。 AIワークロード
- 15. 15 2-2. クラウドワークロードセキュリティとは?(4) ・クラウドワークロードのモデル: 短期間Vs. ⾧期間 セキュリティ面では、短期間モデル＞⾧期間モデル 内容 モデル ・短期間アプローチは、ワークロードを交換可能で使い捨てのリソースとして扱う。これらは一時的なサービ スであり、必要に応じて出現し、特定のタスクやワークロードを処理するために短期間だけ存在する。 ・短期間のワークロードにおけるセキュリティはプロアクティブであり、VMやコンテナイメージの作成プロセス の一部として組み込まれており、手動での設定やデプロイ後の構成は不要となる。 ・不可変インフラストラクチャの使用により、パッチ適用や再構成の代わりに、新しいワークロードがスピン アップされ、危険なものや侵害されたものを置き換える。 ・このモデルは自動スケーリングと自己修復機能をサポートし、その効率性と強化されたセキュリティ姿勢に より、現代のクラウドネイティブアプリケーションアーキテクチャにおいて支配的なパターンとなりつつある。 短期間モデル ・⾧期間アプローチは、ワークロードを不可欠なものとして扱い、手動での維持管理が必要となる。 ・このようなアプローチは時間がかかり、人為的なミスが発生しやすいため、一貫性のないセキュリティ対策 につながる可能性がある。 ・⾧時間実行されるワークロードは、従来のオンプレミスのワークロードが管理哲学を変更せずにクラウドに 移行されるシナリオ(「リフトアンドシフト」)で一般的に見られる。 ・⾧時間実行されるワークロードは、特別なケアが必要なデータベースなどの特定のアプリケーションにとっ て重要な場合があるが、問題が発生した場合には回復力が低く、維持するのにコストを要することがある。 ⾧期間モデル
- 16.
- 17.
- 18.
- 19. 19 2-3. 仮想マシン(VM)(1) ・仮想マシンの課題 ・ 内容 課題 ・特にユーザーが独自のイメージを提供できる場合には、VMイメージを安全にデプロイし、最新の状態 に保つことが課題となる。 イメージ制御 ・ベースイメージを定期的に最新のセキュリティパッチで更新することは重要だが、リソース集約的になる。 パッチ管理 ・クラウドサービスカスタマー(CSCs) が稼働中のVM を変更できるようにすると、意図せずに脆弱性 を導入したり、構成の逸脱を引き起こしたりする可能性がある。 変更管理 ・VM内のOSやアプリケーションは、コンテナのようなより効率的なワークロードタイプに比べて、攻撃 対象領域が大きくなる。 攻撃対象領域管理 ・⾧期間稼働し、手動で構成された仮想マシン(VM)は、頻繁に交換されないので、強固なセキュリ ティ体制を維持するのが難しい。 ライフサイクル管理 ・VMへのネットワークアクセスを保護するために必要な、詳細な制御メカニズムには、Secure Shell(SSH)が含まれ、VMインスタンスへのアクセスに使用されるSSH秘密鍵の不注意な漏えいの 課題に対処することが含まれる。 ネットワークセキュリティ ・カーネルレベルの権限を持つルートキットやブートキットを使用して、ファームウェアやオペレーティングシ ステムに感染させる。 ルートキットと ブートキット
- 20.
- 21.
- 22. 22 2-3. 仮想マシン(VM)(4) ・ファクトリーによるセキュアな仮想マシンイメージの生成(1) 出典:Cloud SecurityAlliance 「Security Guidance For Critical Areas of Focus in Cloud Computing v5」(2024年7月15日)(https://cloudsecurityalliance.org/artifacts/security-guidance-v5)
- 23.
- 24. 24 2-3. 仮想マシン(VM)(6) ・VM向けに推奨されるツールとベストプラクティス(1) 脆弱性管理ライフサイクル 出典:Cloud SecurityAlliance 「Security Guidance For Critical Areas of Focus in Cloud Computing v5」(2024年7月15日)(https://cloudsecurityalliance.org/artifacts/security-guidance-v5) 内容 サイクル ・自動化ツールを使用して、VMの既知の脆弱 性をスキャンする 特定 ・識別された脆弱性に関連するリスクを、VMの 役割および処理／保存されるデータの分類 (データの機密性など)を考慮して分析・評価 する 評価 ・パッチを適用し、セキュリティ設定を構成し、脆 弱性に対処するための回避策を講じる 低減＆ 報告 ・報告、コンプライアンス、および監査のために、 脆弱性、評価、修正措置の詳細な記録を 保持する 文書化
- 25.
- 26. 26 2-3. 仮想マシン(VM)(8) ・デプロイメントパイプラインによるセキュアなイメージの生成(1) デプロイメントパイプラインのプロセス 出典:Cloud SecurityAlliance 「Security Guidance For Critical Areas of Focus in Cloud Computing v5」(2024年7月15日)(https://cloudsecurityalliance.org/artifacts/security-guidance-v5)
- 27. 27 2-3. 仮想マシン(VM)(9) ・デプロイメントパイプラインによるセキュアなイメージの生成(2) デプロイメントパイプラインの各ステップ 内容 パイプラインのステップ ・イメージにコンパイルしてインストールする可能性のあるソースコード。 1.ソースコード ・安全なイメージの基盤は、明確に定義されたサーバー構成から始まる。IaC(Infrastructure asCode)の利 用により、このステップではOS、ネットワーク設定、セキュリティポリシーを指定し、サーバー環境の基盤を形成する。 2.サーバー構成 ・イメージやコンテナに焦点が移る。この段階では、アプリケーションとその依存関係を、事前に定義されたサーバー 設定に基づいて、スリムで安全な構成でパッケージ化する。 3.イメージ構成 ・イメージ構成ファイルの流れは、バージョン管理システムにチェックインされることで続く。Gitリポジトリやコンテナレジ ストリなどのツールを使用することによって、この手法は変更の追跡、コラボレーション、およびビルドプロセスにおける 責任を促進する。 4.バージョン制御 リポジトリ ・ここでは自動化が中心となる。継続的インテグレーションサービス／サーバーが、構成ファイルからイメージをビルド し、変更がコミットされるたびにセキュリティチェックを実行する。 5.継続的インテグレー ションサーバー ・セキュリティテストがパイプラインの統合コンポーネントとなる。ソフトウェア構成解析(SCA)や脆弱性スキャンの ツールを使用して、パイプラインはセキュリティ問題を特定し、修正し、進行する前にイメージを強化する。 6.セキュリティテストと 強制 ・安全なマスターイメージが生成される。このプロセスの最終結果として、強化され検証されたマスターイメージが安 全に保存され、展開の準備が整う。 7.マスターイメージ ・この時点で、イメージは厳密な検査を受ける。そのリスクと重要度に応じて、手動レビューまたは自動受け入れテス トを通過する場合がある。 8.手動または自動化 された受け入れ ・マスターイメージは本番環境にある。このイメージの本番環境への移行は一貫性があり、安全で、IaCと自動化 ツールを使用して正確にデプロイされる。 9.本番
- 28.
- 29.
- 30.
- 31. 31 2-4. コンテナのセキュア化(3) ・コンテナオーケストレーション＆管理システム(1) ・コンテナオーケストレーションシステム: コンテナ化されたアプリケーションの複雑な ライフサイクルを管理するための重要なツール ・Kubernetes(K8s):代表的なオープンソースのコンテナオーケストレーション システムで、マシンクラスター全体にわたるアプリケーションのデプロイ、スケーリング、 管理をオーケストレーションし、シームレスな自動化と一貫した運用を可能にする。 ・コンテナはマイクロサービス(アプリケーションコンポーネント)をホストし、コンポーネ ントが一貫した環境で実行されることを保証する。 ・Kubernetesのデフォルト設定の留意点: ・オープンダッシュボードが、適切に保護されていない場合、貴重な情報を意図 せずに露出させる可能性がある ・デフォルトのサービスアカウントは、広範な権限を持ち、必要以上のアクセスを 許可する可能性がある ・ネットワーク構成が、特定のデプロイの厳格なセキュリティ要件を満たさない
- 32. 32 2-4. コンテナのセキュア化(4) ・コンテナオーケストレーション＆管理システム(2) ロードバランサーやポッドによるKubernetesの基本設定 出典:Cloud SecurityAlliance 「Security Guidance For Critical Areas of Focus in Cloud Computing v5」(2024年7月15日)(https://cloudsecurityalliance.org/artifacts/security-guidance-v5)
- 33.
- 34. 34 2-4. コンテナのセキュア化(6) ・コンテナオーケストレーションのセキュリティ(2) 考慮事項 ベストプラクティス ・Kubernetes SecurityPolicies、Network Policiesなどのツールを使用して、ポッド間の ネットワークアクセスを制限・監視するためのセキュリティポリシーを定義および実施する。 コンテナセキュリティ ポリシー ・Kubernetes向けCISベンチマークなどの標準規格および標準化ツールは、不適切なデフォルト 設定を検出・修正するための体系的なアプローチを提供する。 セキュリティベンチマー クとツールの有効活用 ・セキュアなイメージリポジトリはコンテナセキュリティの中核である。プライベートリポジトリを使用し、 ロールベースのアクセス制御(RBAC)を実装して、誰がイメージをプッシュ／プルできるかを管理 する。 ・コンテナイメージのスキャンと脆弱性検出を、デプロイ前および本番環境で定期的に実施する。 イメージ署名を利用して信頼の連鎖を確立し、イメージが作成されてからデプロイされるまでの間に 改ざんされていないことを確認する。 セキュアなイメージ リポジトリ コンテナ化された環境の整合性とセキュリティを確保するためには、堅牢で安全な設定から始める ことが重要である。これらの基本設定はコンテナ環境のあらゆる側面をカバーしており、安全な環境 を提供するために不可欠である。 セキュアな構成
- 35.
- 36.
- 37.
- 38.
- 39.
- 40.
- 41. 41 2-5. PaaSセキュリティ(3) ・特定のPaaSのセキュア化 考慮事項 ベストプラクティス ・CDNを通じて移動するデータのためのSSL(Secure SocketsLayer)または TLS(Transport Layer Security)による暗号化は、情報が機密で改ざんされない ことを保証する。強力なアクセス制御と認証メカニズムにより、保存されたコンテンツへの アクセスが制限される。 コンテンツデリバリー ネットワーク(CDN) ・通知を暗号化し、安全な配信チャネルを使用することによって、情報を保護する。これは、 信頼できる宅配便を通じて機密文書を送るのと似ている。強力な認証方法は、通知を送 信するサービスやユーザーの正当性を確認する。 通知サービス ・メッセージの保存時および転送時の暗号化、そしてセキュアなアクセスポリシーとRBAC は、メッセージキュー内の機密データを保護する。これにより、認可されたエンティティのみ がキューに公開または購読できるようになり、通信の完全性が維持される。 メッセージクエリ
- 42. 42 出典:Cloud Security Alliance「Security Guidance For Critical Areas of Focus in Cloud Computing v5」(2024年7月15日)(https://cloudsecurityalliance.org/artifacts/security-guidance-v5) 2-6. サーバーレス／FaaSのセキュア化(1) ・FaaS(Function as a Service): ・開発者が基盤となるインフラを扱うこと なくコードを書いてデプロイする方法 ・クラウドプロバイダーがサーバーを管理 し、サーバーのプロビジョニング、異なる 負荷に対応するためのスケーリング、 メンテナンスを行う ・開発者はサーバー管理業務を心配 することなく、純粋にコーディングに集中 できる
- 43.
- 44.
- 45.
- 46. 46 2-6. サーバーレス／FaaSのセキュア化(5) ・ネットワーク接続とアクセスパターン ・ネットワーク設計: サーバーレス機能を仮想ネットワーク内に隔離して、不正アクセスのリスク を減らし、セキュリティを強化できる。 ACL(アクセス制御リスト)などの細かいアクセス制御を設定して、誰または 何がこれらの機能にアクセスできるか、どのような条件でアクセスできるかを 定義することができる。 ・サーバーレス機能と他のサービス間の相互作用: APIゲートウェイは、しばしば受信リクエストのエントリーポイントとなり、 厳重に保護する必要がある。 加えて、データの転送中の暗号化も重要である。 ネットワークセキュリティは主にCSPの管理下にあるが、CSCはアプリケー ション層のデータ移動を保護するためのセキュリティ設定を構成する必要が ある。
- 47. 47 2-6. サーバーレス／FaaSのセキュア化(6) ・環境変数と秘密 ・サーバーレスアプリケーション内での機密情報の取り扱い: パスワードやAPIキーなどの秘密情報をコードにハードコーディングするので はなく、環境変数を利用すべきである。これらの変数は動的に管理され、 実行時に注入されるため、機密情報の露出を最小限に抑えることができる。 ・秘密管理: クラウドサービス(AWS Secrets Manager、Azure Key Vaultなど) は、秘密管理向けに信頼性の高いメカニズムを提供し、資格情報の安全な 保存、取得、ローテーションを可能にする。秘密を定期的にローテーション することにより、古くなったり、侵害された可能性のある資格情報が悪用 されるリスクを減らす。 IAMロールを通じて秘密へのアクセスを制御することで、認可されたエンティ ティのみがそれらを取得または変更できるように保証する。
- 48. 48 2-7. AIワークロード(1) ・AIシステムの脅威 脅威 カテゴリー ・データポイズニング:悪意を持って誤った情報を導入し、不正確なモデル出力を引き起こす。 ・プライバシー侵害: 機微データへの不正アクセスは、プライバシー違反および関連する法的問題の結果を招く。 ・データ漏えい:偶発的な教育データの露出は、モデルのアウトプットを通して起きる場合があり、機密情報の公開のリスク がある。 データセキュリティ ・モデルの窃盗: 機械学習モデルの不正コピーは、攻撃者が知的財産法を回避することを可能にし、モデルを騙す方法を 明らかにする可能性もあり、リスクが増大する。 ・敵対的攻撃:入力は、設計上の弱点を悪用し、誤った予測を引き起こすように操作することが可能である。 ・モデル反転攻撃:この攻撃はモデルの出力から入力データを再構築でき、トレーニングデータの機密性を脅かす。 ・プロンプトインジェクション:悪意のある入力は、AIモデルの脆弱性を悪用して意図しない行動を引き起こしたり、 機密情報を漏洩させたりする可能性がある。これは、ソーシャルエンジニアリングが個人をだましてセキュリティを侵害 させる方法に似ている。 モデルセキュリティ ・不正アクセス: AIインフラストラクチャへの侵入は、データ窃盗、悪意ある変更、有害なソフトウェアのデプロイにつながる 可能性がある。 ・DDoS攻撃:過剰なトラフィックはサービスを妨害するために利用される可能性がある。 ・ハードウェアの脆弱性: GPUやTPUを標的とする悪用には、サイドチャネル攻撃が含まれ、機密情報の漏洩のリスクがある。 インフラストラクチャ セキュリティ ・ソフトウェアの依存関係: サードパーティライブラリが、脆弱性や悪意あるコードを導入する可能性がある。 ・サードパーティサービス: 外部のデータ処理やストレージサービスへの依存が、脆弱性を導入する可能性がある。 サプライチェーン
- 49. 49 2-7. AIワークロード(2) ・AI低減戦略 低減策 カテゴリー ・暗号化: 転送時および保存時の間、データの機密性を保護する。 ・差分プライバシー:個々の記録が個人に遡れないように、データやクエリに、ランダム性を導入する。 ・セキュアマルチーパーティ計算: 機微情報をフローの一部として、匿名化やトークン化を行うことによって、機微情報を露出 することなしに、複数ソースからデータを処理する。 ・秘密計算: 処理中のデータを保護し、AIモデルの展開を守るために、高信頼実行環境(TEE)を利用する。 データセキュリティ ・モデルのハードニング: モデルのレジリエンスを強化するために、敵対的攻撃に対して防御する。 ・堅牢なトレーニング:一般化能力を向上させ、過学習を減らすための手法を採用する。 ・敵対的トレーニング:攻撃に対抗するために、操作された例をトレーニングデータに組み込むことによってAIモデルを強化し、 さまざまな動きに対抗する方法を学ぶ格闘家のように、そのレジリエンスを高める。 ・モデルの透かし:所有権を主張し、盗難を防止するためにユニークな識別子を埋め込む。 ・出力操作: AIの応答を変更してその意思決定プロセスを隠すことによって、ポーカープレイヤーのブラフのように、潜在的な 盗難者を阻止することができる。 モデルセキュリティ ・GPUとTPU: システムの完全性を維持するために、ハードウェアベースのセキュリティ機能や、定期的なファームウェアの アップデート、ネットワーク・セキュリティ対策を有効活用する。 ・AIサービス:クラウドサービスのベストプラクティスに従い、アクセス制御とリアルタイムモニタリングを含める。 ・割り当てとレート制限: DoSおよびDDoS攻撃を識別し防止するために、割り当てとレート制限を適用する。 インフラストラクチャ セキュリティ ・ポリシー: サプライチェーン向けのサイバーセキュリティポリシーを定義し、承認する。 ・ソフトウェアサプライチェーンリスク管理: サードパーティに対して、定期的に監査し、更新する。 ・サードーパーティサービスの調達: 統合前にセキュリティ評価を実施する。 ・信頼されたソース:ソフトウェアの依存関係について、信頼できるソースに依存し、承認されたリストを維持する。 サプライチェーン
- 50. 50 2-8. クラウドワークロードセキュリティの推奨事項(1) 推奨事項 項目 ・集中型クラウドデプロイメントレジストリの生成:効率的なトラッキングと管理のために、すべてのクラウドワークロード およびデプロイメントの包括的なインベントリを維持する ・複数のデプロイメントを利用した組織階層の定義:セキュリティおよび管理の制御の向上のために組織ユニットを反映 するクラウド環境を構築する ・新たなデプロイメント生成のための低摩擦プロセスのサポート:運用効率性を妨げることなくセキュリティポリシーの遵守 を保証するためにプロセスを簡素化する クラウドワーク ロード管理 ・安全なベースVMイメージの強制:すべてのデプロイメント向けに、集中管理でバージョン化された、不可変なベース イメージを利用する ・イメージファクトリーの実装:一貫性とセキュリティを保証するために、VMイメージの生成、テスト、デプロイメントを自動 化する ・VMイメージの脆弱性スキャン:セキュリティリスクを低減するために、定期的にスキャンし、VMイメージをアップデートする ・短期間稼働のVMの採用:⾧期間稼働のインスタンスに関連するリスクを低減するために、不可変的なインフラストラク チャと一時的なVMを利用する ・構成管理とIaC(Infrastructure asCode)の利用:望ましい状態を維持し、構成逸脱を防止する ・ホストベースのファイアウォールとSSHハードニングの実装:ネットワークアクセスを制御し、VMインスタンス上のSSH (Secure Shell)構成をセキュアにする 仮想マシン セキュリティ
- 51. 51 2-8. クラウドワークロードセキュリティの推奨事項(2) 推奨事項 項目 ・オーケストレーション向けのCSPサービス利用:セキュリティ強化のためにKubernetes-as-a-Serviceのような マネージドサービスを有効活用する ・オーケストレーションサービスのハードニング:不必要な機能を無効化し、最小特権アクセスを保証して、ネットワーク ポリシーおよびファイアウォールを実装する ・定期的なパッチ当てとアップデート:コンテナ、ホスト、オーケストレーションプラットフォーム向けパッチ管理の自動化 ・セキュリティポリシーの定義と強制:Kubernetes SecurityPolicy、NetworkPolicyのようなツールを利用する ・セキュリティベンチマークとツールの有効活用:Kubernetesの安全な構成を保証するために、CISベンチマークを フォローする ・クラスターのホストとストレージの保護:ホストOSをハードニングし、保存時および転送時のデータの暗号化を適用して、 アクセス制御リスト(ACL)を利用する コンテナオーケスト レーションセキュリティ ・CSPMツールの有効活用:クラウドセキュリティポスチャー管理(CSPM)ツールを利用して、クラウドセキュリティポス チャーを継続的にモニタリングする ・継続的モニタリングの実装:ワークロードの活動を追跡し、潜在的なセキュリティインシデントを迅速に検知するために、 リアルタイムモニタリングツールを利用する ・SCAツールの利用:依存関係を管理し、脆弱性を早期に特定するために、ソフトウェア構成分析(SCA)ツールを CI/CDパイプラインに統合する ・SBOMの生成と維持:透明性、セキュリティ対応、規制遵守を強化するために、すべてのワークロード向けにソフトウェア 部品表(SBOM)を生成する ・エンドポイント検知・対応(EDR)エージェント:ランタイムモニタリングを実行し、脆弱性評価をサポートする ・セキュリティ情報・イベント管理(SIEM):リアルタイムのモニタリングとレポーティングを提供する モニタリングと評価
- 52.
- 53. 53 AGENDA • 3. CSAクラウドセキュリティガイダンスV5と アプリケーションセキュリティ 3-1.CSAクラウドセキュリティガイダンスV5:アプリケーションセキュリティ 3-2. セキュアソフトウェア開発ライフサイクル(SSDLC) 3-3. 脅威モデリング 3-4. セキュアな設計と開発 3-5. テスト 3-6. セキュアなクラウドアプリケーションアーキテクチャ 3-7. アイデンティティ／アクセス管理のアプリケーションセキュリティ 3-8. DevSecOps:CI／CDとアプリケーションテスト 3-9. サーバーレスの考慮事項 3-10. コンテナの考慮事項 3-11. アプリケーションセキュリティの推奨事項
- 54. 54 3-1. CSAクラウドセキュリティガイダンスV5:アプリケーションセキュリティ 1. クラウドコンピューティングの概念と アーキテクチャ 2.クラウドガバナンスと戦略 3. リスク、監査とコンプライアンス 4. 組織管理 5. アイデンティティ／アクセス管理 6. セキュリティモニタリング 7. インフラストラクチャとネットワーク 8. クラウドワークロードセキュリティ 9. データセキュリティ 10.アプリケーションセキュリティ 11.インシデント対応とレジリエンス 12.関連技術・戦略 10. アプリケーションセキュリティ 10.1 セキュアな開発ライフサイクル 10.1.1 CSAセキュア開発ライフサイクル 10.1.2 脅威モデリング 10.1.3 セキュアな設計と開発 10.1.4 テスト:デプロイ前 10.1.5 テスト:デプロイ後 10.2 セキュアなクラウドアプリケーションアーキテクチャ 10.2.1 クラウドのアーキテクチャレベルのセキュリティへの影響度 10.2.2 クラウドのアプリケーション設計とアーキテクチャへの影響度 10.2.3 Infrastructure as Codeとアプリケーションセキュリティ 10.2.4 APIセキュリティのベストプラクティス 10.3 アイデンティティ／アクセス管理のアプリケーションセキュリティ 10.3.1 アプリケーションコンポーネント上での許可の設定 10.3.2 秘密管理 10.4 DevSecOps:CI／CDとアプリケーションテスト 10.4.1 DevSecOps 10.4.2 DevSecOpsの6つの柱 10.4.3 実用的なDevSecOps 10.4.3.1 シフトレフトとセキュリティの組込 10.4.3.2 SecOps:WebアプリケーションファイアウォールとDDoS 10.5 サーバーレスとコンテナ化されたアプリケーションの考慮事項 10.5.1 サーバーレスとコンテナのアプリケーションセキュリティへの影響度 10.5.1.1 サーバーレスの考慮事項 10.5.1.2 コンテナの考慮事項
- 55. 55 3-2. セキュアソフトウェア開発ライフサイクル(SSDLC) • セキュアなデザインとアーキテクチャ •セキュアコーディング(Developer IDEとCode Repository) • 継続的なビルド、統合、およびテスト • 継続的なデリバリーとデプロイ • 継続的なモニタリングとランタイムディフェンス 内容 フェーズ デザインは、製品の設計時に適用できる技術やツールを参照している。設計は継続的なものであるため、新しい製品 機能や変更は設計活動を通じて進行する。設計段階でセキュリティを含めないと、セキュリティ対策は展開・実行時に より高い運用への影響と費用を伴って導入されることになる。また、対策のスケーリングが難しくなり、セキュリティのボト ルネックが開発速度を遅らせ、リリースのタイムラインに影響を与える。 1. セキュアなデザインと アーキテクチャ 開発段階でこの機能を適用することで、アプリケーションの構築中にセキュリティが統合されるようにする。自動化ツー ルに依存したコーディングセキュリティコントロールは、手動の人間によるレビューと比較して、コードの弱点や脆弱性を よりよく、一貫して特定できる。開発段階でセキュリティ分析と設計を含めないと、ソースコードの脆弱性が特定されず、 運用環境にデプロイされるリスクがあり、SSDLの後段階で修正するとより高価になる。 2. セキュアコーディング (Developer IDEと Code Repository) 統合とテストには、アプリケーションや製品のセキュリティ脆弱性をデプロイ前にテストするためのツールとプロセスが含ま れる。これらがないと、セキュリティ脆弱性が悪用され、データ漏えい、不正アクセス、アプリケーション、サービスの可用 性に対するさまざまな影響などの悪用が発生する可能性がある。 3. 継続的なビルド、 統合、およびテスト デプロイ前の安全チェックは、アプリケーションや製品が安全なインフラストラクチャにデプロイされることを保証する。 デプロイフェーズでセキュリティ分析を含めないと、脆弱性や不適切なセキュリティプラクティスにより、アプリケーション、 製品、サービスが本番環境での悪用や攻撃にさらされるリスクがある。 4. 継続的なデリバリー とデプロイ これらの機能とプラクティスは、アプリケーションや製品が本番環境にリリースされた後に適用される。ランタイムセキュリ ティは、非効率性、脆弱性、弱点を特定し、インシデント対応を可能にすることで、継続的な改善を促進する。 5.継続的なモニタリング とランタイム防御
- 56. 56 3-3. 脅威モデリング ・STRIDEフレームワーク:セキュリティリスクを特定・分類する 内容 フェーズ 不正アクセスを行うために、ユーザーやシステムのように誰か他人のふりをする攻撃者が含まれる(例. ログイン資格情報を盗み出すために、攻撃者が合法サイトを真似たところでのフィッシング攻撃)。 1. 偽造(Spoofing) データやメッセージの不正な変更のこと。これが、転送時やストレージシステム内部で起きて、データの 完全性が損なわれる可能性がある。 2.なりすまし (Tampering) これは、そうしたにも関わらずエンティティが行為を否定した時に起きる。これにより、行為を正しいソース に帰するシステムの能力が弱体化して、責任が複雑化する。 3. 否認 (Repudiation:) これには、機密情報への不正アクセスが含まれる。手法には、セキュアでない通信上での盗み聞き、 機微データにアクセスする脆弱性の悪用が含まれる。 4. 情報開示 (Information Disclosure) これは、システムの可用性欠如につながるようなシステムリソースの消耗である。これにより、オペレーショ ンが破壊され、重大なダウンタイムを招く可能性がある。 5. サービス拒否 (Denial of Service) 攻撃者が、許可されたレベル以上の高度なアクセスを取得した場合、より特権の高いアカウント用に 指定した行動を実行するために、アクセス制御をバイパスする。 6. 特権昇格 (Elevation of Privilege)
- 57.
- 58.
- 59. 59 3-5. テスト(2) ・デプロイ後テスト:継続的デプロイ(CD) ・ソフトウェアがデプロイされた後にそのセキュリティと機能を検証し、特にクラウド アプリケーションにおいて設計および統合時に行われた仮定を検証する ・このフェーズでは、ソフトウェアが実際の環境で効果的に動作することを確認し、 従来のデータセンターでのテストプロセスを反映する デプロイ後テスト 1. 動的脆弱性スキャニング 2.動的アプリケーションセキュリティテスト(DAST) ・動的分析(ファジング) ・インタラクティブアプリケーションセキュリティテスト(IAST) 3. ペネトレーションテスト 4. バグバウンティプログラム
- 60. 60 3-6. セキュアなクラウドアプリケーションアーキテクチャ(1) ・クラウドのアーキテクチャレベルのセキュリティへの影響度 影響 アプローチ ・クラウドはインフラストラクチャとアプリケーションを統合し、サーバーやデータベースなどの要素をアプリケー ションの機能に不可欠なものにする ・この統合により、シームレスな運用を通じてセキュリティが強化される可能性がある ・誤った権限設定が侵害につながる可能性があるアイデンティティ／アクセス管理(IAM)のリスクも生じる ・潜在的な脆弱性を軽減するために、アイデンティティとアクセスの管理を慎重に行うことが重要である 1.インフラストラク チャとアプリケーショ ンの統合 ・クラウド環境では、マイクロサービスなどのコンポーネントが特定の権限や資格情報を使用して通信する ・資格情報が漏えいしたり、管理が不適切であったりすると、重大なセキュリティインシデントにつながる 可能性がある ・資格情報を安全に取り扱い、アクセスを厳密に制御することが、侵害を防ぐために重要である 2.アプリケーション コンポーネントの 資格情報 ・インフラストラクチャをコードで定義することにより、デプロイメントの一貫性と効率性を提供する ・これらのデプロイメントパイプラインは攻撃者を引き付ける可能性がある ・パイプラインの侵害は、ソフトウェアサプライチェーン全体を危険にさらす可能性がある ・パイプラインを保護することは、開発およびデプロイメントプロセスを守ることにつながる 3.Infrastructur e asCodeと パイプライン ・仮想化技術とIaaS技術の成熟に伴い、マシン構成の管理と展開を維持または改変しないというパラダイ ムに移行した。アプリケーション、サーバー、システム構成のインスタンスが作成されると、変更されることは ない。変更が必要な場合は、共通のテンプレートから新しいインスタンスを作成し、完全に置き換える。 4.不可変インフラス トラクチャ
- 61.
- 62. 62 3-6. セキュアなクラウドアプリケーションアーキテクチャ(3) ・Infrastructure asCode(IaC)とアプリケーションセキュリティ 内容 アプローチ ・IaCは、インフラがプロビジョニングまたは変更されるたびに、セキュリティ基準や規制に対する自動検証を促 進し、コンプライアンスを確保する。この自動化は、セキュリティポリシーの遵守を常に確保するため、絶え間 ない監察官のように機能する。 1.コンプライアンス チェックの自動化 ・インフラのセットアップをコード化することで、IaCは、サーバーからデータベースに至るまで、すべての要素が セキュリティのベストプラクティスに従って一貫して構成されることを保証する。これにより、手動設定に伴う人 的エラーが排除され、設定のドリフトが検出・排除され、すべてのリソースにわたって均一なセキュリティレベル が維持される。 ・IaCは、これらのセキュリティポリシーに対する例外の管理もサポートする。たとえば、特定のリソースが有効 なビジネスニーズにより標準設定からの逸脱を必要とする場合、これらの例外をIaCフレームワーク内で文書 化し管理することで、組織は、そのような逸脱が認識され、承認され、追跡されることを保証し、必要な運用 の柔軟性をサポートしながらセキュリティの監視を維持できる。 2.一貫したセキュリ ティポスチャ ・IaCは、特定された脆弱性に対応してインフラコードを迅速に修正し、インフラ全体にわたるパッチやホット フィックスの展開を可能にする。 3.迅速な脅威への 対応 ・IaCは迅速なCI／CDロールバック機能をサポートし、運用の回復力を強化する。コンテナや仮想化環境の 更新が行われると、パフォーマンスはベンチマークと統計的に比較される。 ・カナリアリリースなどの新しい自動展開がこれらのベンチマークを満たさない場合、IaCは以前の安定した 構成に自動的にロールバックすることができる。これにより、ダウンタイムを最小限に抑え、新しい変更によって セキュリティや運用の安定性が損なわれることを防ぐ。 4.迅速なCI／CD ロールバック
- 63. 63 3-6. セキュアなクラウドアプリケーションアーキテクチャ(4) ・Infrastructure asCode(IaC): 自動化によるセキュリティ強化 出典:Cloud Security Alliance 「Security Guidance For Critical Areas of Focus in Cloud Computing v5」(2024年7月15日)(https://cloudsecurityalliance.org/artifacts/security-guidance-v5)
- 64.
- 65.
- 66. 66 3-7. アイデンティティ／アクセス管理のアプリケーションセキュリティ(2) ・アプリケーションセキュリティのためのIAMと秘密管理 出典:Cloud SecurityAlliance 「Security Guidance For Critical Areas of Focus in Cloud Computing v5」(2024年7月15日)(https://cloudsecurityalliance.org/artifacts/security-guidance-v5)
- 67.
- 68. 68 3-7. アイデンティティ／アクセス管理のアプリケーションセキュリティ(4) ・IAMと秘密管理のプロセス 鍵ペアの生成証明書署名要求(CSR)の提出認証局(CA)による発行 出典:Cloud SecurityAlliance 「Security Guidance For Critical Areas of Focus in Cloud Computing v5」(2024年7月15日)(https://cloudsecurityalliance.org/artifacts/security-guidance-v5)
- 69. 69 3-8. DevSecOps:CI／CDとアプリケーションテスト(1) ・DevSecOps: SSDLCを通してセキュリティの統合を自動化するような 開発、セキュリティ、運用を短縮したもの ・継続的インテグレーション(CI):開発者はしばしば、コード変更を共有リポジトリに 統合する ・継続的デプロイ(CD): CIを経て、コード変更は自動的・継続的にデプロイされる 出典:Cloud Security Alliance 「Security Guidance For Critical Areas of Focus in Cloud Computing v5」(2024年7月15日)(https://cloudsecurityalliance.org/artifacts/security-guidance-v5)
- 70.
- 71.
- 72. 72 3-8. DevSecOps:CI／CDとアプリケーションテスト(4) ・シフトレフトとセキュリティの組込 ～開発フェーズ全体に渡るセキュリティの統合 出典:Cloud SecurityAlliance 「Security Guidance For Critical Areas of Focus in Cloud Computing v5」(2024年7月15日)(https://cloudsecurityalliance.org/artifacts/security-guidance-v5)
- 73. 73 3-8. DevSecOps:CI／CDとアプリケーションテスト(5) ・SSDLC全体を通じたプロアクティブなセキュリティ対策 出典:Cloud SecurityAlliance 「Security Guidance For Critical Areas of Focus in Cloud Computing v5」(2024年7月15日)(https://cloudsecurityalliance.org/artifacts/security-guidance-v5)
- 74. 74 3-8. DevSecOps:CI／CDとアプリケーションテスト(6) ・IaaS／PaaSサービスにおけるWAF／DDoS保護の共通シナリオ 出典:Cloud SecurityAlliance 「Security Guidance For Critical Areas of Focus in Cloud Computing v5」(2024年7月15日)(https://cloudsecurityalliance.org/artifacts/security-guidance-v5) 内容 シナリオ IaaSの仮想マシンをWebサーバーとして利用する時、WAFエージェントを、 OSの上位にインストールすることができる。通常、このオプションには、DDoS 低減機能はない。 1. エージェント のデプロイ IaaS／PaaSプロバイダーは、通常ロードバランサーサービス上にデプロイ される、WAFとDDoS保護の統合型サービスを提供する。 2. クラウドプロ バイダーサービス IaaS／PaaSマーケットプレイスは、専用VMにデプロイされた、様々なサード パーティ製商用WAFソフトウェアを提供する。WAFをデプロイし、ルーティング やリダンダンシー、ロードバランシングを保証するのは、顧客の責任である。 3. サードパー ティマーケットプ レイスサービス DNSリダイレクトを利用して、消費者のトラフィックは、サードパーティWAFに ルーティングされ、検証・フィルタリングした上で、クラウドプロバイダー環境に ルーティングされる。 4. WAF／ DDoS as a Service
- 75. 75 3-8. DevSecOps:CI／CDとアプリケーションテスト(7) ・SecOps:WebアプリケーションファイアウォールとDDoS 出典:Cloud SecurityAlliance 「Security Guidance For Critical Areas of Focus in Cloud Computing v5」(2024年7月15日)(https://cloudsecurityalliance.org/artifacts/security-guidance-v5)
- 76. 76 3-9. サーバーレスの考慮事項 (参考文献) CSAServerless WG ・「サーバレスアプリケーションの12の最も重大なリスク2019」(2019年2月11日) (https://cloudsecurityalliance.org/artifacts/the-12-most-critical-risks-for-serverless-applications) (日本語訳版:https://cloudsecurityalliance.org/artifacts/the-12-most-critical-risks-for-serverless-applications-japanese-translation) ・「安全なサーバーレスアーキテクチャを設計するには 2021年版」(2021年9月14日) (https://cloudsecurityalliance.org/artifacts/serverless-computing-security-in-2021) (日本語訳版:https://www.cloudsecurityalliance.jp/site/wp-content/uploads/2022/01/How-to-Design-a-Secure-Serverless-Architecture-091321-J.pdf) 「サーバーレスアーキテクチャのセキュリティを確保するためのCレベルへのガイダンス」(2022年4月19日) (https://cloudsecurityalliance.org/artifacts/c-level-guidance-to-securing-serverless-architectures) (日本語訳版:https://cloudsecurityalliance.org/artifacts/c-level-guidance-to-securing-serverless-architectures-japanese-translation) ・「NIST 800-53 R5のコントロールに基づくFaaSサーバーレスコントロールフレームワーク」(2023年8月30日) (https://cloudsecurityalliance.org/artifacts/faas-serverless-control-framework-set-based-on-nist-800-53-r5-controls) ・「安全なサーバーレスアーキテクチャを設計するには 2023年版」(2023年10月23日) (https://cloudsecurityalliance.org/artifacts/how-to-design-a-secure-serverless-architecture) (日本語訳版:https://cloudsecurityalliance.org/artifacts/how-to-design-a-secure-serverless-architecture-japanese-translation) 内容 考慮事項 ・サーバーレス機能の一時的な性質は、単独で、持続的なストレージのない短期運用を行い、 本質的に攻撃に対する露出を抑制する。 攻撃対象領域の 削減 ・製品製造時の既知の安全性記録を有するサードパーティコンポーネント利用に似たような、 外部のコードまたはサービスへの依存。 依存関係のリスク ・サーバーレス機能の一時的で分散化した性質は、多数の継続的に変化するアクセスポイント 全体のセキュリティ維持に匹敵する、複雑なアクセス管理を必要とする。 IAMの複雑性
- 77. 77 3-10. コンテナの考慮事項 内容 考慮事項 ・侵入者が簡単に入れる通路を可能にするコネクテッドルームの不適正な分離と同様に、コンテ ナ化環境における不十分な分離は、セキュリティ侵害をもたらし得る。 分離のリスク ・コンテナは、デプロイ後不可変的になるように設計されており、一貫性を促進し、証拠改ざん 防止パッケージのようにリスクを低減する。 不可変インフラス トラクチャ ・スケールが拡大するにつれて、コンテナの複雑なセキュリティ構成が課題となっており、複数施 設に渡る先進的なセキュリティシステムの複雑なネットワークを監視するのに似ている。 複雑な構成管理 出典:Cloud SecurityAlliance 「Security Guidance For Critical Areas of Focus in Cloud Computing v5」(2024年7月15 日)(https://cloudsecurityalliance.org/arti facts/security-guidance-v5)
- 78. 78 3-11. アプリケーションセキュリティの推奨事項(1) 推奨事項 項目 ・セキュアな設計とアーキテクチャ: 早期段階でセキュリティを統合する設計フェーズの間、技術やツールを適応して、費用の高 騰や後工程でのボトルネックを回避する ・継続的ビルド、統合、テスト:セキュリティ侵害を防止するために、デプロイ前に脆弱性をテストするためのツールとプロセスを 導入する ・継続的デリバリーとデプロイ: アプリケーションがセキュアなインフラストラクチャ上にデプロイされていることを保証するために、 デプロイ前の安全性チェックを実施する ・ランタイム防御とモニタリング: デプロイ後の脆弱性や非効率性を継続的に特定・低減するためのプラクティスを実装する CSAセキュア 開発 ライフサイクル (SSDLC) ・脅威を分類するためにSTRIDEフレームワークを適用する:偽造、なりすまし、否認、情報開示、サービス拒否、特権昇格 構造化脅威モデリ ングの採用 ・セキュリティの責任をプロバイダーに引き渡すために、PaaS(Platform as a Service)およびその他のCSPサービスを 利用する。 ・すべてのコンポーネントについて、最小特権およびアイデンティティ／アクセス管理(IAM)を実装する。 ・インターネットへの露出を最小化するために、ロードバランサーやセキュリティグループのようなCSPサービスを利用する セキュアなクラウド 設計へのフォーカ ス ・静的アプリケーションセキュリティテスト(SAST):デプロイ前に脆弱性や論理的エラーを特定するために、コードレビューを 自動化する ・ソフトウェア構成分析(SCA):脆弱性やライセンシングのリスクに関して、外部コンポーネントを監査し、透明性のために、 ソフトウェア部品表(SBOM)を生成する。 セキュリティテスト 手法の統合
- 79.
- 80.
- 81. 81 AGENDA • 4. OWASPDevSecOps／API関連ガイドライン 4-1.OWASP DevSecOpsガイドライン v-0.2 4-2.OWASP APIセキュリティ トップ10 2023
- 82. 82 4-1. OWASP DevSecOpsガイドライン v-0.2(1) [構成] 0 – イントロダクション 0-a – 概要 0-b – 脅威モデリング 1 – コミット前 1-a – 秘密管理 1-b – コードの検査(Linting) 2 – 脆弱性スキャン 2-a – 静的(Static)アプリケーションテスト 2-b – 動的(Dynamic)アプリケーションテスト 2-c – インタラクティブな(Interactive)アプリケーションテスト 2-d – ソフトウェア構成分析 2-e – インフラストラクチャ脆弱性スキャン 2-f – コンテナ脆弱性スキャン 2-g – プライバシー 3 – コンプライアンス監査
- 83. 83 4-1. OWASP DevSecOpsガイドライン v-0.2(2) ・目標:できるだけ早く、セキュリティ課題(Security by Design、 アプリケーション脆弱性)を検知する ・基礎的パイプラインにおける実装のステップ: ・潜在的な資格情報の漏えいを見つけるためのgitスキャン ・SAST(静的アプリケーションセキュリティテスト) ・SCA(ソフトウェア構成分析) ・IAST(インタラクティブなアプリケーションセキュリティテスト) ・DAST(動的アプリケーションセキュリティテスト) ・IaCスキャンニング(構成ミスを見つけるためのTerraform、HelmChartコードのスキャン) ・インフラストラクチャスキャンニング ・コンプライアンスチェック
- 84. 84 4-1. OWASP DevSecOpsガイドライン v-0.2(3) ・集中型脆弱性管理ソリューション 出典:OWASP Foundation, Inc.「OWASP DevSecOps Guideline - v-0.2」(2024年8月時 点)(https://github.com/OWASP/DevSecOpsGuideline)
- 85. 85 4-2. OWASP APIセキュリティトップ10 2023(1) 説明 項目 番号 APIはオブジェクト識別子を扱うエンドポイントを公開する傾向があり、これによりオブジェクトレベ ルのアクセス制御問題の広範な攻撃対象領域が生じる。ユーザーからのIDを使用してデータ ソースにアクセスするすべての機能で、オブジェクトレベルの認可チェックを考慮する必要がある。 壊れたオブジェクトレベル 認可 API1:2023 認証メカニズムはしばしば誤って実装され、攻撃者が認証トークンを侵害したり、実装の欠陥を 悪用して他のユーザーの身元を一時的または永久に乗っ取ることができる。システムのクライアン ト/ユーザーを識別する能力が損なわれると、APIセキュリティ全体が危険にさらされる。 壊れた認証 API2:2023 このカテゴリは、API3:2019 過剰なデータ露出と API6:2019 大量割り当てを組み合わせた もので、根本的な原因に焦点を当てている。それは、オブジェクトのプロパティレベルでの認可検 証の欠如または不適切な認可検証である。これにより、認可されていない第三者による情報の露 出や操作が引き起こされる。 壊れたオブジェクトプロパ ティレベル認可 API3:2023 APIリクエストを満たすには、ネットワーク帯域幅、CPU、メモリ、ストレージなどのリソースが必要 である。メール、SMS、電話、生体認証の検証など、他のリソースは、サービスプロバイダーによっ てAPI統合を通じて提供され、リクエストごとに料金が発生する。攻撃が成功すると、サービス拒 否(DoS)や運用コストの増加につながる可能性がある。 制限のないリソース消費 API4:2023 複雑なアクセス制御ポリシーは、異なる階層、グループ、役割を持ち、管理機能と通常の機能の 区別が不明確な場合、認可の欠陥を引き起こす傾向がある。これらの問題を悪用することで、攻 撃者は他のユーザーのリソースや管理機能にアクセスすることができる。 壊れた機能レベル認可 API5:2023 出典:OWASP Foundation, Inc.「API Security Top 10 2023」(2023年)(https://owasp.org/API- Security/editions/2023/en/0x00-header/)を基にヘルスケア研究会作成
- 86. 86 4-2. OWASP APIセキュリティトップ10 2023(2) 説明 項目 番号 このリスクに対して脆弱なAPIは、チケットの購入やコメントの投稿などのビジネスフローを公開す るが、その機能が自動化された形で過度に使用された場合、ビジネスにどのような害を及ぼすかに ついては補償しない。これは必ずしも実装上のバグに起因するものではない。 機微なビジネスフローへの 制限のないアクセス API6:2023 Server-Side Request Forgery (SSRF)の脆弱性は、APIが、ユーザーに指定された URIを検証せずにリモートリソースを取得する際に発生する可能性がある。これにより、攻撃者は アプリケーションに細工されたリクエストを送信させ、ファイアウォールやVPNで保護されている場 合でも予期しない宛先にリクエストを送信させることができる。 Server-Side Request Forgery (SSRF) API7:2023 APIとそれをサポートするシステムは、通常、APIをよりカスタマイズ可能にするために複雑な設定 を含む。ソフトウェアエンジニアやDevOpsエンジニアは、これらの設定を見逃したり、設定に関す るセキュリティのベストプラクティスに従わなかったりすることがあり、さまざまな種類の攻撃のリスク を高める。 セキュリティの設定ミス API8:2023 APIは従来のWebアプリケーションよりも多くのエンドポイントを公開する傾向があるため、適切 で最新のドキュメントがとても重要である。また、ホストとデプロイされたAPIバージョンの適切な インベントリを持つことも、廃止されたAPIバージョンや公開されたデバッグエンドポイントなどの問 題を軽減するために重要である。 不適切なインベントリ管理 API9:2023 開発者はユーザー入力よりもサードパーティAPIから受け取るデータを信頼する傾向があり、その ためセキュリティ基準が弱くなることがある。攻撃者はターゲットAPIを直接攻撃するのではなく、 統合されたサードパーティサービスを狙ってAPIを侵害しようとする。 APIの安全でない消費 API10:2023 出典:OWASP Foundation, Inc.「API Security Top 10 2023」(2023年)(https://owasp.org/API- Security/editions/2023/en/0x00-header/)を基にヘルスケア研究会作成
- 87.