DevSecOpsにおける継続的なセキュリティ

継続的なセキュリティモニタリングとは？

継続的なセキュリティモニタリングは、セキュリティの自然な進化形です。現代のソフトウェア開発では、インテグレーションからデリバリー／デプロイまで、あらゆる工程が継続的に行われるモデルへと移行しています。従来のセキュリティアプローチでは、本番リリース後にソフトウェアをテストしますが、この方法は開発のボトルネックとなり、脆弱性が本番環境に持ち込まれる可能性もあります。一方、継続的なセキュリティでは、開発プロセスにセキュリティを組み込むことでリスクを低減し、ボトルネックを解消してリリースを迅速化します。

継続的なセキュリティを導入するメリットは？

現代のソフトウェア開発は、複雑なアーキテクチャとインフラストラクチャ層を特徴としています。クラウドネイティブアプリケーション、マイクロサービス、コンテナ化などのアプローチにより、開発者はより迅速にコードをテストしてデリバリーできます。リリースは通常、小規模かつ迅速に行われます。本番環境へのデプロイが1日に何度も行われることもあります。

DevOpsセキュリティでは、ソフトウェアの変更頻度が急速に高まる状況に対応するため、新たなアプローチが必要です。従来のセキュリティ手法では、開発サイクルの終盤や本番環境へのリリース後にソフトウェアをテストしていました。テストを外部チームが担当することも多く、開発者とセキュリティ担当者の間に摩擦が生じていました。

さらに、従来のセキュリティアプローチは、現代のソフトウェアアーキテクチャやインフラストラクチャに十分対応できません。クラウドインフラストラクチャは数分で構築できますが、アーキテクチャが明確に定義されていないこともあります。これは現代の開発者にとって魅力的である一方、攻撃対象領域が広がり、セキュリティの確保が難しくなります。従来のセキュリティアプローチでは、こうした環境を十分にテストできません。

継続的なセキュリティは、セキュリティをCI/CDパイプラインに組み込む、DevOpsプラクティスの自然な発展形です。DevSecOpsの概念や、セキュリティのシフトレフトのアプローチとも密接に関連しています。開発チームがコードセキュリティのオーナーシップと責任を担うことで、開発プロセスのできるだけ早い段階で問題を検出し、修正できます。結果として、継続的なセキュリティは機能のデリバリーを加速させると同時に、セキュリティ要件を自動化し、ガバナンスとセキュリティの向上につなげます。

継続的なセキュリティはCI/CDパイプラインにどう組み込まれる？

継続的なセキュリティでは、CI/CDパイプラインにポリシーとテストを直接組み込み、ソフトウェア開発ライフサイクルの各段階でインフラストラクチャとアプリケーションを保護します。

脅威モデリング

脅威モデリングは、SDLCの最初期に行うのが理想的です。開発者はコードを実行せずに、その実行によって生じる変更をモデル化します。これにより、ほぼ即座にフィードバックを得られ、コードがセキュリティに及ぼす影響をテストできます。

脅威モデリングは、すぐに複雑化することがあります。STRIDEというアプローチでは、最も一般的な攻撃の種類ごとに個別の分析を行います。

• Sなりすまし

• T改ざん

• R否認

• I情報漏えい

• Dサービス拒否

• E権限昇格

STRIDEなどの手法を使うことで、構築しているもの、起こり得る問題、その緩和策、そして脅威緩和のプロセスを評価する方法を検討できます。

脅威モデリングでは、DevSecOps文化にうまく適合させるための計画も必要です。従来は、開発者とセキュリティ専門家が事前に何度も会議を行っていました。継続的なセキュリティでは、脅威モデリングにシフトレフトのアプローチを適用して開発プロセスの早い段階に移し、さらに「右への拡張」としてサードパーティーのモデリングツールを活用します。これにより、パイプラインの後続段階でも脅威を自動的に検出し、緩和できます。

コードと設計のレビュー

コードを書き終えたら、設計どおりに動作することを確認し、脆弱性やセキュリティ上の問題を見つけるためにレビューを行います。このプロセスでは、信頼できるライブラリを使ってすべての入力をサニタイズおよび検証すること、安全な認証を徹底すること、ソフトウェア依存関係の脆弱性をスキャンすることなど、さまざまなセキュリティチェックを実施します。

その他のベストプラクティスについては、こちらのコードレビューのチートシートをご覧ください。

テスト

コードのセキュリティと設計上の要件を検証したら、次はテストです。この段階では、開発者が本番環境に移行可能なサンドボックスを構築し、その条件下でコードをテストします。ネットワーク呼び出し、入力検証、認可、ログ、アクセス制御の自動テストなどが含まれます。アプリケーションはセキュリティ指標を正しく記録しているでしょうか？アクセスは適切なユーザーのみに制限されていますか？

このような継続的なセキュリティテストにより、迅速なフィードバックが可能になります。インフラストラクチャリソースのプロビジョニングとテストも含められます。たとえば、AWSにデプロイしたテスト環境では、Managed Config Rulesというツールを使い、クラウドリソースがセキュリティ設定のベストプラクティスに従っていることを確認できます。

本番環境

コードにとって本番環境はゴールですが、セキュリティにとってはそうではありません。リソースは変更、追加、削除されるため、本番環境のアプリケーションは、組織、業界、政府の基準への準拠を継続的にテストする必要があります。本番環境のセキュリティには、自動パッチ適用、構成管理、依存関係の自動更新などが含まれます。

効果的な継続的セキュリティプログラムを構築するためのベストプラクティスを見ていきましょう。

継続的なセキュリティプロセスのベストプラクティスは？

継続的なセキュリティには計画が必要

セキュリティ目標をDevOpsチームに渡し、手順を適用して徹底してもらうだけでは不十分です。インテグレーションの負担を開発チームだけに負わせるべきではありません。セキュリティチームは、計画段階から、業務への影響を最小限に抑えながら継続的なセキュリティを適用することに注力すべきです。セキュリティチームとDevOpsチームが協力して、初期段階から機能や監査を組み込み、プロセス全体を通じて連携する必要があります。

計画は、システム、アプリケーション、ユーザーストーリーの初期構想段階での脅威モデリングから始まります。アプリケーションセキュリティテストは、コード変更時とインテグレーション後に自動的に実行する必要があります。懸念事項があればレビュー対象として提示し、開発者が普段使っている開発ツールに結果を届けます。

プロセスは可能な限り自動化する必要があります。たとえば、デプロイの実行条件にセキュリティ指標とランタイムセキュリティを含めます。

インフラストラクチャには特別な注意が必要

クラウドインフラストラクチャの柔軟性を踏まえ、ポリシーを定めて徹底する必要があります。不要なサービスの無効化、不要なポートの閉鎖、権限の適用、本番環境に開発ツールがインストールされていないことの確認などが含まれます。

コードは、セキュリティが確保され、アプリケーションが最新バージョンで動作するオペレーティングシステム上でビルドする必要があります。クラスターのサイズ、共有インフラストラクチャの権限、インフラストラクチャやプラットフォームのパートナーに関するセキュリティ管理策も徹底する必要があります。

定期的にテストを実施する（ペネトレーションテスト、バグバウンティ）

テストは不可欠です。リリース前にコードの機能性と安全性を確認できます。また、手動検証に伴う遅延を避けるため、自動化することも可能です。テストにより攻撃経路を見つけ、潜在的な脆弱性を特定し、想定される影響範囲に応じて分類できます。

このレベルのテストは、インフラストラクチャ、ネットワーク、その他コードとして表現されるすべてのものにも適用する必要があります。アプリケーションのすべてのコンポーネントを分析し、テクノロジースタック全体に十分なセキュリティが実装されていることを確認するのが目的です。

開発者の妨げにならず、セキュリティを強化できるツールを使う

最新のツールを使えば、CI/CDパイプライン内で開発者が直接セキュリティを強化しやすくなります。静的アプリケーションセキュリティテスト（SAST）ツールをソフトウェアのビルド時に使うと、更新されたコードの問題や脆弱性を見つけられます。たとえば、ユーザー入力によってデータベース関連の関数が呼び出され、SQLインジェクションというセキュリティ脆弱性が発生する可能性をSASTツールで検出できます。

従来、SASTツールは独立したCIプロセスで使われていましたが、最新のSASTツールはソースコードのビルド時に使え、開発者に迅速で実用的なフィードバックを提供します。誤検知率が低く、修正方法に関する情報も得られます。開発者を第一に考えて設計されており、IDE、CLI、その他開発者がすでに使用しているツールと連携します。

ソフトウェア構成分析（SCA）ツールも、継続的なセキュリティに役立つテクノロジーです。開発者はマージ前に、ソースコードの変更に依存関係の脆弱性が含まれていないか確認できます。

ポリシーエンジンやリンターのようなツールも、開発者がコードを提出するたびに実行できます。Vaultなどのシークレット管理ツールも、クラウドインフラストラクチャやアプリケーション全体のコード保護に役立ちます。

継続的なセキュリティを実現するSnykのツール

開発ライフサイクル全体を通じて脆弱性を見つけ、修正するツールは数多くあります。Snykは開発者を第一に考えた姿勢と、業界をリードするセキュリティプラットフォームが特長です。

たとえば、依存関係を最新の状態に保つことは、開発者にとって障壁になります。必要な更新をどうすれば把握できるでしょうか？変更は役に立つのでしょうか？バグを引き起こしたり、コンパイルを壊したりしないでしょうか？変更を小さくして頻度を高める依存関係の継続的な更新により、問題を管理しやすくなります。開発者は、テストに合格した更新を自動的に承認してマージするツールを活用できます。これにより、デプロイを迅速化し、プルリクエストから本番環境までを完全に自動化できます。

オープンソースの依存関係は、特に注意が必要な領域です。Snyk Open SourceはCI/CDパイプライン全体でコードを自動的にテストし、本番環境に移行する前に脆弱性を検出して修正します。本番環境への移行後も、独自の脆弱性データベースを使って新たに判明した脆弱性を継続的に監視します。

つまり、コードスキャンは継続的なセキュリティに不可欠です。スキャンを導入していない場合、どのような脆弱性やバグが見逃されてしまうでしょうか？