Successfully reported this slideshow.
Your SlideShare is downloading. ×

なぜあなたのプロジェクトのDevSecOpsは形骸化するのか(CloudNative Security Conference 2022)

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad

Check these out next

1 of 45 Ad

More Related Content

Similar to なぜあなたのプロジェクトのDevSecOpsは形骸化するのか(CloudNative Security Conference 2022) (20)

Recently uploaded (20)

Advertisement

なぜあなたのプロジェクトのDevSecOpsは形骸化するのか(CloudNative Security Conference 2022)

  1. 1. なぜあなたのプロジェクトの DevSecOpsは形骸化するのか CloudNative Security Conference 2022 田原聖也 (Tahara, Masaya) August 5, 2022
  2. 2. Agenda 本発表の目的 DevSecOpsのおさらい 形骸化するDevSecOps 導入を目的としないDevSecOpsのあり方 発表内容のまとめ 1 2 3 4 5 6 自己紹介 2
  3. 3. 1. 自己紹介 田原 聖也 Tahara, Masaya • アクセンチュア株式会社 テクノロジーコンサルティング本部所属 • クラウドとセキュリティの2軸でお客様の支援をしております • アプリケーション・・・業務でもプライベートでも幅広く Rust, Go, Ruby, Python, C#, Java, C++, etc • インフラ・・・ほぼAWS、Azureを少し • セキュリティ・・・ 2022 APN AWS Top Engineer (Security) 情報処理安全確保支援士 3 This presentation makes reference to marks owned by third parties. Unless otherwise noted, all such third-party marks are the property of their respective owners. No sponsorship, endorsement or approval of this content by the owners of such marks is intended, expressed or implied.
  4. 4. 2. 本発表の目的 複数のプロジェクトへのDevSecOpsの導入経験をもとに、DevSecOpsを形骸化 させないポイントをお伝えできれば幸いです。 4 みなさんのプロジェクトでは、こんなことが起きていませんか? ✓ 誰かがいつの間にかテストをして、言われた通りにセキュリティ対応をしている ✓ セキュリティは、リリース前にペネトレーションテストをしてれば十分だと思っている ✓ DevSecOpsを謳っている製品を導入したが、結局誰も使っていない
  5. 5. 3. DevSecOpsのおさらい DevSecOpsでは、ただセキュリティチェックを行うのではなく、できるだけそれが開発 の邪魔にならないことが求められます。 5 (Gartner[1] より引用。日本語部分は発表者が抄訳。) ✓ DevSecOpsとは、新興のアジャイルITやDevOpsの開発に、セキュリティをできる だけシームレスかつ透過的に統合すること ✓ 理想的には、開発者のアジリティやスピードを低下させたり、開発ツール環境を変 更することなく、これを実現する [1] https://www.gartner.com/en/information-technology/glossary/devsecops
  6. 6. 3. DevSecOpsのおさらい DevSecOpsを実現するための手段として、各種セキュリティテストがCI/CDパイプ ラインやIDE等に統合された形で実装されることが一般的です。 6 要件定義・ 設計 コーディング ビルド テスト デプロイ 保守・運用 ✓ 脅威分析 ✓ セキュアコーディング ✓ 機密情報の漏洩対策 ✓ 静的コード解析 ✓ ソフトウェア構成解析 ✓ コンテナ解析 ✓ IaC解析 ✓ 動的アプリ解析 ✓ ペネトレーションテスト ✓ コンプライアンスチェック ✓ ガードレール ✓ 異常検知 ✓ 脆弱性自動修復 図:DevSecOps施策の代表例
  7. 7. 4. 形骸化するDevSecOps 発表者の経験を基にしたフィクションとして、コンシューマ向けWebサイト構築プロジ ェクトにおいてDevSecOpsを導入した事例を紹介します。 7 要件定義・ 設計 コーディング ビルド テスト デプロイ 保守・運用 ✓ 脅威分析 ✓ セキュアコーディング ✓ 機密情報の漏洩対策 ✓ 静的コード解析 ✓ ソフトウェア構成解析 ✓ コンテナ解析 ✓ IaC解析 ✓ 動的アプリ解析 ✓ ペネトレーションテスト ✓ コンプライアンスチェック ✓ ガードレール ✓ 異常検知 ✓ 脆弱性自動修復 図:本事例で実施・実装されたセキュリティ施策
  8. 8. 4. 形骸化するDevSecOps 本事例では、技術の導入にばかり気を取られ、人やプロセスの整備が不十分になり その結果DevSecOpsの取り組みが形骸化してしまいました。 8 技術 プロセス 人 ✓ 商用セキュリティ製品をCI/CD パイプラインに組み込んだ ✓ セキュリティテストは自動化したが、 他の工程で属人化が多かった ✓ セキュリティチームへの依存度が高い ✓ 各開発者のセキュリティへの意識が低い 図:基盤となる人・プロセスが脆弱であり不安定
  9. 9. 5. 導入を目的としないDevSecOpsのあり方 基盤となる人・プロセスを整備し、その上で技術面を強化していくことで、継続的に DevSecOpsを運用することができます。 9 ✓ 現在の採用技術に固執しない ✓ 自動化、ゲート化、文書化が徹底 されている 図:人・プロセスが安定したDevSecOpsのあるべき姿 技術 プロセス 人 ✓ セキュリティチームへの依存度が低い ✓ 各開発者のセキュリティへの意識が高い (プラス・セキュリティ) → 「人」「プロセス」「技術」に関して、あるべき姿をご紹介していきます。
  10. 10. 5-1. 導入を目的としないDevSecOpsのあり方 「人」 枯渇が著しいセキュリティ人材を定常的な運用に組み込んでしまうと、その部分がボ トルネックとなり、DevSecOpsの形骸化につながることがあります。 10 図:日本におけるセキュリティ人材の充足状況 NRIセキュアテクノロジーズ株式会社「企業における情報セキュリティ実態調査2021」[1]より引用 [1] https://www.nri.com/jp/news/newsrelease/lst/2022/cc/0208_1 n=1,616 ①人材が過剰な状態 ②充足している(最適な状態) ③どちらかといえば充足している ④どちらかといえば不足している ⑤不足している ⑥わからない ⑤61.5% ⑥2.9% ④29.0% ③4.9% ②1.6% ①0.3% 日本の90.4%の企業がセキュリティ 人材の不足を感じている ※小数点以下の切り上げ・切り捨てにより 合計値が異なる
  11. 11. 5-1. 導入を目的としないDevSecOpsのあり方 「人」 「プラス・セキュリティ」の考え方を取り入れることで、プロジェクトに関わる全員でセキ ュリティ運用を回すことを目指しましょう。 11 ✓ プラス・セキュリティ ・・・事業部門、管理部門等においてそれぞれの業務に従事する人材が、DX等 のデジタル活用を進めるなかでセキュリティを意識し、業務遂行に伴う適切なセ キュリティ対策の実施やセキュリティ人材との円滑なコミュニケーションに必要な能 力を育成する (経済産業省「サイバーセキュリティ体制構築・人材確保の手引き(第2.0版)」[1] より引用) [1] https://www.meti.go.jp/policy/netsecurity/tebiki_taisei_jinzai.html
  12. 12. 5-1. 導入を目的としないDevSecOpsのあり方 「人」 DevSecOps関連タスクでは、頻度が高いものはできるだけセキュリティチームが受 け持たないことで、継続的にDevSecOpsを運用しやすくなります。 12 表:DevSecOps関連タスクと担当チームの例 設計 実装 運用・保守 ✓ 脅威分析 ✓ 施策立案 ✓ 技術選定 ✓ 技術検証 ✓ 技術導入 ✓ 各種テスト ✓ 検出される脆弱性への対応策定 ✓ システムの改修 開発フェーズ DevSecOps関連タスクの例 各チームの分担イメージ アプリ・イン フラチーム セキュリティチーム アプリ・インフラチー ム セキュリティチーム アプリ・インフラチーム セキュリテ ィチーム 実施頻度が高いタスク セキュリティチームの負担を下げるべき
  13. 13. 5-2. 導入を目的としないDevSecOpsのあり方 「プロセス」 「自動化」だけでなく、「ゲート化」と「文書化」も徹底することが、DevSecOpsのプ ロセスを成熟させるために重要となります。 13 成熟したDevSecOpsプロセス 自動化 ゲート化 文書化 ✓ 可能な限りプロセスを自動化し、作業の抜け漏れを防ぐ ✓ プロセスの移行時にはテスト実施し、チェックポイントを設ける ✓ 関連するあらゆる経緯や作業内容に関し文書を残す → 「自動化」「ゲート化」「文書化」に関して、実践例を紹介していきます。
  14. 14. 5-2. DevSecOpsプロセスにおける自動化 既存のセキュリティ施策であっても、まず自動化できないか、DevSecOpsに取り込 めないか、を検討することを推奨します。 14 要件定義・ 設計 コーディング ビルド テスト デプロイ 保守・運用 ✓ 脅威分析 ✓ セキュアコーディング ✓ 機密情報の漏洩対策 ✓ 静的コード解析 ✓ ソフトウェア構成解析 ✓ コンテナ解析 ✓ IaC解析 ✓ 動的アプリ解析 ✓ ペネトレーションテスト ✓ コンプライアンスチェック ✓ ガードレール ✓ 異常検知 ✓ 脆弱性自動修復 図:自動化できるDevSecOps施策例
  15. 15. 5-2. DevSecOpsプロセスにおける自動化 「シフトレフト」の考え方によれば、セキュリティ施策を実装するフェーズは、できるだけ 開発初期段階に寄せることで、影響範囲が小さくなり、手戻りも削減できます。 15 ・・・設計 コーディング ビルド テスト デプロイ 保守・運用 ・・・ 図:開発フェーズと作業実施場所の例 IDE CI/CDパイプライン コードレポジトリ クラウド基盤 運用基盤 セキュリティ施策をできるだけ早期に実装・・・シフトレフト
  16. 16. 5-2. DevSecOpsプロセスにおけるゲート化 セキュリティ観点でのチェックポイントとなる「ゲート」を実装する部分についても、「シフ トレフト」に則りできるだけ開発初期段階に設けることを検討してみましょう。 16 ・・・設計 コーディング ビルド テスト デプロイ 保守・運用 ・・・ 図:開発フェーズとセキュリティゲートの例 pre-commit hook CI中の解析結果による クライテリア 各種テスト結果による クライテリア IDE CI/CDパイプライン コードレポジトリ クラウド基盤 運用基盤
  17. 17. 5-2. DevSecOpsプロセスにおける文書化 Googleの調査によれば、文書品質が高いチームは多くのセキュリティ対策を実施で きていることが分かります。 17 (Google Accelerate State of DevOps Reports[1] より引用。日本語部分は発表者が抄訳。) 文書品質が高いチームには、次のような特徴があります。 ✓ セキュリティ対策が実装される可能性が3.8倍高い ✓ 信頼性目標を達成・超過する可能性が2.4倍高い ✓ SREを導入する可能性が3.5倍高い ✓ クラウドをフルに活用する可能性が2.5倍高い [1] https://cloud.google.com/blog/products/devops-sre/announcing-dora-2021- accelerate-state-of-devops-report
  18. 18. 5-2. DevSecOpsプロセスにおける文書化 文書化する内容は、ツールの使い方や手順だけでなく、あらゆる作業の背景、経緯 、参考文献、判断根拠等も対象とすることを推奨します。 18 表:ソースコードの静的解析結果に対するアクション例と文書化の対応関係 アクション① アクション② アクション③ 静的解析の結果を確認する 「誤検知ではないのか」「コードの修正が 必要か」といった判断をする コードの修正 「どう結果を見ればよいか」が文書化されて いるか? 参考にした脆弱性情報の記事、情報の 整理、判断根拠が文書化されているか? 何を参考にしてなぜ修正したか、コード中 のコメントとしても文書化されているか? ※文書を残すツールの選定条件として、検索性についても考慮することを推奨します。
  19. 19. 5-3. 導入を目的としないDevSecOpsのあり方 「技術」 DevSecOpsに限らず、プロジェクトで採用する技術に対しては、現状維持バイアス を鑑みて何が最適なのかを見直し続ける必要があります。 19 図:採用する技術に対する見直しトリガの例 ✓ スケジュールされた見直し ・・・毎月や、四半期に1回程度、採用する技術を見直す ✓ イベントドリブンな見直し ・・・システムの大規模改修や脆弱性の発見といったタイミングで、 採用する技術を見直す
  20. 20. 5-3. 導入を目的としないDevSecOpsのあり方 「技術」 皆様のプロジェクトにおけるDevSecOpsを見直す上で、参考となる技術を幅広く 紹介していきます。 20 要件定義・ 設計 コーディング ビルド テスト デプロイ 保守・運用 ✓ 脅威分析 ✓ セキュアコーディング ✓ 機密情報の漏洩対策 ✓ 静的コード解析 ✓ ソフトウェア構成解析 ✓ コンテナ解析 ✓ IaC解析 ✓ 動的アプリ解析 ✓ ペネトレーションテスト ✓ コンプライアンスチェック ✓ ガードレール ✓ 異常検知 ✓ 脆弱性自動修復 図:自動化できるDevSecOps施策例(再掲)
  21. 21. 5-3. 導入を目的としないDevSecOpsのあり方 「技術」 21 コーディングからテストは、ソフトウェア開発プロセスの中でもDevSecOpsのシフトレ フトの中心であり、かつOSSの活用が盛んなフェーズです。 ・・・設計 コーディング ビルド テスト デプロイ・・・ ✓ セキュアコーディング ✓ 機密情報の漏洩対策 ✓ 静的コード解析(SAST) ✓ ソフトウェア構成解析 (SCA) ✓ コンテナ解析 ✓ IaC解析 ✓ 動的アプリ解析(DAST)
  22. 22. 5-3. コーディングフェーズのDevSecOps施策 22 コーディングフェーズにおいて、開発者のIDE上で脆弱性を発見することが、理想的 なシフトレフトの実装となります。 ・・・設計 コーディング ビルド テスト デプロイ・・・ ✓ セキュアコーディング ✓ 機密情報の漏洩対策 ✓ 静的コード解析(SAST) ✓ ソフトウェア構成解析 (SCA) ✓ コンテナ解析 ✓ IaC解析 ✓ 動的アプリ解析(DAST)
  23. 23. 5-3. コーディングフェーズのDevSecOps施策 アプリケーションコードのセキュアコーディングを支援するツールでは、Snykは適用でき る範囲が非常に幅広く、推奨できるツールです。 23 ➢ Snyk Vulnerability Scanner (Snyk Code IDEプラグイン) • IDEプラグインとして無償利用可能なセキュアコーディング支援 ツールである • 対応言語はPython、JavaScript/TypeScript、Java等、 対応IDEもVS Code、JetBrains系、Eclipse等と幅広く、 基本的にはいつでもどこでも使うことができる ・・・設計 コーディング ビルド テスト デプロイ・・・ ✓ セキュアコーディング ✓ 機密情報の漏洩対策
  24. 24. 5-3. コーディングフェーズのDevSecOps施策 アプリケーションコードだけでなく、Dockerfile等のマニフェスト系ファイルを対象とした セキュアコーディング支援ツールも存在します。 24 ➢ hadolint • Dockerfileに対するlinterである • CLIとしても実行可能だが、VS Code等のIDEとの統合によ りよりシフトレフトを実現しやすくなる • Dockerfile以外にもKubernetesマニフェスト等使っている 場合には、別途対応するツールの利用を推奨する ・・・設計 コーディング ビルド テスト デプロイ・・・ ✓ セキュアコーディング ✓ 機密情報の漏洩対策
  25. 25. 5-3. コーディングフェーズのDevSecOps施策 機密情報の漏洩対策には、commit/push前後等のソースコードの状態に応じた 適切なツールが利用可能です。 25 ➢ awslabs/git-secrets(複数形、sあり) • AWSのアクセスキー等、Gitレポジトリで共有したくない機密情 報のcommitを防ぐ • 検査対象は正規表現で定義するため、用意されているプロバ イダ毎のテンプレートに加えて、自前でも定義できる ・・・設計 コーディング ビルド テスト デプロイ・・・ ✓ セキュアコーディング ✓ 機密情報の漏洩対策
  26. 26. 5-3. コーディングフェーズのDevSecOps施策 既に機密情報が漏洩してしまっていないかを調査するOSSツールも存在します。 26 ➢ trufflesecurity/truffleHog • 特定のGitレポジトリにcommit、pushされてしまっている機 密情報を探す • 商用版では、Gitレポジトリだけでなくコンテナレポジトリや Slack等にアップロードされてしまった機密情報も探すことがで きる ➢ tillson/git-hound • アクセス可能な複数のGitHubレポジトリ(Publicレポジトリだ けでなく参照権限のあるPrivateレポジトリも)をスキャンし、 特定の機密情報が漏洩していないかチェックする ・・・設計 コーディング ビルド テスト デプロイ・・・ ✓ セキュアコーディング ✓ 機密情報の漏洩対策
  27. 27. 5-3. ビルドフェーズのDevSecOps施策 27 ビルドフェーズでは、利用しているCI/CDパイプラインやコードレポジトリ、クラウドプラ ットフォームとの相性も加味した上でツールの選定をしていく必要があります。 ・・・設計 コーディング ビルド テスト デプロイ・・・ ✓ セキュアコーディング ✓ 機密情報の漏洩対策 ✓ 静的コード解析(SAST) ✓ ソフトウェア構成解析 (SCA) ✓ コンテナ解析 ✓ IaC解析 ✓ 動的アプリ解析(DAST)
  28. 28. 5-3. ビルドフェーズのDevSecOps施策 Amazon CodeGuruは機能追加により、SASTとしても、JavaとPythonの ソースコードを解析可能となりました。 28 ・・・設計 コーディング ビルド テスト デプロイ・・・ ✓ 静的コード解析(SAST) ✓ ソフトウェア構成解析 (SCA) ✓ コンテナ解析 ✓ IaC解析 ➢ Amazon CodeGuru • リリース当時はなかったが、(田原がリクエストし続けた結果)セキュリティ 観点での解析機能が追加された • AWS CodeCommitとの相性の良さは言わずもがな • 現在の対応言語はJavaとPythonのみと少ない • 「Boto3(AWS SDK for Python)を使う運用スクリプト」 のようなユースケースには非常に適している ※SAST・・・Static Application Security Testing
  29. 29. 5-3. ビルドフェーズのDevSecOps施策 SASTの中ではOSSの定番としてSonarQubeが存在しますが、比較的新しいツ ールとしてSnyk Codeが台頭しています。 29 ・・・設計 コーディング ビルド テスト デプロイ・・・ ✓ 静的コード解析(SAST) ✓ ソフトウェア構成解析 (SCA) ✓ コンテナ解析 ✓ IaC解析 ➢ Snyk Code • 前述のIDEプラグインのコアロジックとなっている • 対応言語はPython、JavaScript/TypeScript、Java等、 かなり幅広い • GitHub等と統合するSaaS版(Web UI)だけでなく、CLI ツールとしても利用できる ➢ SonarQube • OSSのコード解析ツールとして永らく定番とされているが、セ キュリティ観点の解析機能は正直物足りない部分がある
  30. 30. 5-3. ビルドフェーズのDevSecOps施策 ソフトウェアの大部分をOSSが占めていると言われる昨今ですが、さらに2021年末 にLog4Shell脆弱性が大きく話題になり、SCAが注目されています。 30 ・・・設計 コーディング ビルド テスト デプロイ・・・ ✓ 静的コード解析(SAST) ✓ ソフトウェア構成解析 (SCA) ✓ コンテナ解析 ✓ IaC解析 ➢ OWASP Dependency Check • OWASP Foundation直属のOSSプロジェクトである • Java、.NETが正式サポート、PythonやNode.jsは Experimental supportとされている • 公式にも書かれている通り、実は検知精度には自信がない ➢ Snyk Open Source • Snyk Code同様、対応言語がかなり幅広い • SCA自体が解析結果・対応工数が莫大になりやすい分野だ が、自動Fix(アップデートしたPR作成等)機能を具備する ※SCA・・・Software Composition Analytics
  31. 31. 5-3. ビルドフェーズのDevSecOps施策 Amazon ECRを利用しているのにコンテナ解析をしていない場合、まずは Amazon ECRが持つイメージスキャン機能の利用を強く推奨します。 31 ・・・設計 コーディング ビルド テスト デプロイ・・・ ✓ 静的コード解析(SAST) ✓ ソフトウェア構成解析 (SCA) ✓ コンテナ解析 ✓ IaC解析 ➢ Amazon ECRイメージスキャン • Amazon ECRさえ使っていれば、設定がとにかく簡単、ベー シックスキャンは無料で利用できる![1] • Amazon ECRへpushしたイメージのみが対象である • Inspectorと統合された拡張スキャン機能により、解析カバ レッジが増加、AWS Security Hub等との他サービス連携、 などなど様々な機能が利用可能になった(ただしInspector の利用料金がかかる)[2] [1] https://docs.aws.amazon.com/ja_jp/inspector/latest/user/enable-disable-scanning-ecr.html [2] https://aws.amazon.com/jp/inspector/faqs/
  32. 32. 5-3. ビルドフェーズのDevSecOps施策 コンテナ解析ツールは開発が盛んな分野ですが、OSSと商用製品(無償利用 可能)から1つずつ紹介します。 32 ・・・設計 コーディング ビルド テスト デプロイ・・・ ✓ 静的コード解析(SAST) ✓ ソフトウェア構成解析 (SCA) ✓ コンテナ解析 ✓ IaC解析 ➢ aquasecurity/trivy • 伝説の日本人のセキュリティエンジニアが立ち上げた (早く映画化してほしい) • ビルドしたイメージのスキャンだけでなく、ビルド前のDockerfile 等のマニフェストファイルもスキャンできる ➢ Snyk Container • Trivy同様、ビルドしたイメージのスキャン、マニフェストファイル のスキャンもできる • docker scanコマンドの裏側には、実はこれも使われている • ECR、TrivyよりもGUIが充実している
  33. 33. 5-3. ビルドフェーズのDevSecOps施策 インフラの構成管理にIaCが浸透するにつれ、IaCのセキュリティ解析ツールの開発 も盛んになっています。まずはセキュリティ企業が管理する2つのOSSを紹介します。 33 ・・・設計 コーディング ビルド テスト デプロイ・・・ ➢ aquasecurity/trivy • Terraform、Kubernetesマニフェストファイルを解析できる • 対応IaCツールは今後拡大である ➢ bridgecrewio/checkov • Terraform、Kubernetesマニフェストファイルに加え、 CloudFormationやDockerfile等も解析できる • Bridgecrewとの連携によりWeb UI利用やCI/CDパイプラ イン連携できる ※IaC・・・Infrastructure as Code ✓ 静的コード解析(SAST) ✓ ソフトウェア構成解析 (SCA) ✓ コンテナ解析 ✓ IaC解析
  34. 34. 5-3. ビルドフェーズのDevSecOps施策 CloudFormationやTerraform等、特定のIaCツール専用のIaC解析ツールも 存在します。 34 ・・・設計 コーディング ビルド テスト デプロイ・・・ ➢ stelligent/cfn_nag • CloudFormation専用である • CodePipelineとの連携や、GitHub Actionsとしても利用で きたり、統合機能に力を入れている印象がある ➢ aquasecurity/tfsec • Terraform専用である • VS Codeプラグインとしても利用できるため、Terraformユー ザはとりあえず導入してほしい・・・ ✓ 静的コード解析(SAST) ✓ ソフトウェア構成解析 (SCA) ✓ コンテナ解析 ✓ IaC解析
  35. 35. 5-3. ビルドフェーズのDevSecOps施策 SnykはSASTやSCA、コンテナ解析に加え、IaC解析の機能も提供しています。 35 ・・・設計 コーディング ビルド テスト デプロイ・・・ ➢ Snyk IaC • Terraform, CloudFormation, Kubernetes等、幅広い IaCツールに対応する • 月間300スキャンまで無料で利用できる ✓ 静的コード解析(SAST) ✓ ソフトウェア構成解析 (SCA) ✓ コンテナ解析 ✓ IaC解析
  36. 36. 5-3. テストフェーズのDevSecOps施策 36 ビルドフェーズとテストフェーズの境界は曖昧ですが、明確にビルド後に実施するテス トとして動的アプリ解析を挙げています。 ・・・設計 コーディング ビルド テスト デプロイ・・・ ✓ セキュアコーディング ✓ 機密情報の漏洩対策 ✓ 静的コード解析(SAST) ✓ ソフトウェア構成解析 (SCA) ✓ コンテナ解析 ✓ IaC解析 ✓ 動的アプリ解析(DAST)
  37. 37. 5-3. テストフェーズのDevSecOps施策 SASTと並んで、DASTはアプリケーションセキュリティの代表分野です。しかし、 誤検知の多さにより、実運用では結果の精査や改修対応に苦戦しがちです。 37 ・・・設計 コーディング ビルド テスト デプロイ・・・ ✓ 動的アプリ解析(DAST) ➢ OWASP ZAP • OWASP Foundation直属のOSSプロジェクトである • SASTのSonarQubeとセットで永らく愛されている • OWASP ZAPに限らないが、DASTの特性上、誤検知(特 にFalse Positive)が大量に発生する場合が多い。そのため、 導入しても解析結果の精査・改修対応をしきれず、形骸化し てしまうプロジェクトもある。商用製品の前にOWASP ZAPの ようなOSSを導入してみて、本当に使いこなせるのかを吟味す ることを推奨。 ※DAST・・・Dynamic Application Security Testing
  38. 38. 5-3. 導入を目的としないDevSecOpsのあり方 「技術」 38 デプロイから保守・運用では、セキュリティベンダの製品を採用することも多いですが、 ここではクラウドベンダ(AWS)のサービスとして提供される機能を紹介します。 ・・・テスト デプロイ 保守・運用 ・・・ ✓ コンプライアンスチェック ✓ ガードレール ✓ 異常検知 ✓ 脆弱性自動修復
  39. 39. 5-3. デプロイフェーズのDevSecOps施策 コンプライアンスチェックではデータの収集が問題となりやすいですが、クラウドベンダが 提供するサービスを活用することでハードルがぐっと下がります。 39 ・・・テスト デプロイ 保守・運用 ・・・ ✓ コンプライアンスチェック ✓ ガードレール ➢ AWS Config • AWSリソースの設定を記録する • 記録したデータに対して、事前定義したルールに基づきコンプラ イアンスチェックを実行する ➢ Amazon Inspector • 仮想サーバ(Amazon EC2)とコンテナレジストリ (Amazon ECR)を対象に脆弱性を検査・管理する • re:Invent 2021においてv2が登場したため、v1しか知らな い方は再チェックしてみてください
  40. 40. 5-3. デプロイフェーズのDevSecOps施策 コンプライアンスチェックのサービスを複数利用すると、結果の集約・管理が煩雑にな りがちですが、この課題に対してもクラウドベンダが提供するサービスが増えています。 40 ・・・テスト デプロイ 保守・運用 ・・・ ✓ コンプライアンスチェック ✓ ガードレール ➢ AWS Security Hub • 検出された脆弱性情報を集約し、自動修復までを一元管理 する • 脆弱性の評価自体は、Amazon InspectorやAmazon GuardDuty等の別サービスが実行する ➢ AWS Audit Manager • AWS ConfigやAWS Security Hubでのコンプライアンス チェック結果を集約し、CIS AWS Foundations benchmarkやPCI DSS、GDPR等の監査標準とのマッピン グを行う
  41. 41. 5-3. デプロイフェーズのDevSecOps施策 組織内でのパブリッククラウドの広い活用促進の中で、ガバナンスも適切に効かせる 必要がありますが、それを支援するサービスも提供されています。 41 ・・・テスト デプロイ 保守・運用 ・・・ ✓ コンプライアンスチェック ✓ ガードレール ➢ AWS Control Tower • AWSアカウントをテンプレートとして事前定義し、諸設定が施 された環境をすぐに使える状態にする(Landing Zone) • 管理対象のAWSアカウント内に「予防ガードレール」と「検出 ガードレール」を定義し、ガバナンスを効かせる
  42. 42. 5-3. 保守・運用フェーズのDevSecOps施策 インシデントを迅速に検知するためには、監視体制の強化も重要ですが、クラウドベ ンダが提供するサービスも活用することが増えています。 42 ・・・テスト デプロイ 保守・運用 ・・・ ✓ 異常検知 ✓ 脆弱性自動修復 ➢ Amazon GuardDuty • AWSアカウント内の監査ログ(AWS CoudTrail等)やネッ トワークログ(VPCフローログ、DNSログ等)をデータソースと する • 脅威データベースや機械学習の活用により、AWSリソースの 侵害や、悪意のあるアクティビティを検知する
  43. 43. 5-3. 保守・運用フェーズのDevSecOps施策 パブリッククラウドではイベントドリブンな処理の実行が得意ですが、その仕組をセキュ リティにも活かすことができます。 43 ・・・テスト デプロイ 保守・運用 ・・・ ✓ 異常検知 ✓ 脆弱性自動修復 ➢ コンプライアンスチェック、異常検知サービス×FaaS(Function as a Service)の組み合わせが主流 • 例:仮想サーバ(Amazon EC2)のファイヤーウォール (Security Group)がインターネットに対して22ポートを開 放したら、そのルールを削除する • →AWS Configによりファイヤーウォールの設定を検知し、 AWS Lambdaによりルールの削除処理を実行
  44. 44. 6. 発表内容のまとめ DevSecOpsを形骸化させないためには、基盤となる人・プロセスを整備し、その上 で技術面を強化していくことを心がけてみてはいかがでしょうか。 44 ✓ 現在の採用技術に固執しない ✓ 自動化、ゲート化、文書化が徹底 されている ✓ セキュリティチームへの依存度が低い ✓ 各開発者のセキュリティへの意識が高い (プラス・セキュリティ) 図:人・プロセスが安定したDevSecOpsのあるべき姿(再掲) 技術 プロセス 人
  45. 45. Thank You! ご意見、ご質問ありましたらお気軽にご連絡下さい masaya.tahara@accenture.com 田原 聖也 (Tahara, Masaya)

×