これだけは知っておきたい「DevSecOps」のポイント

2021年08月18日
これだけは知っておきたい「DevSecOps」のポイント

Author

澤田深雪 Miyuki Sawada

澤田深雪</mt:Var>

弊社では、オープンソースの脆弱性管理・コンプライアンス管理ツールであるWhiteSourceを販売しています。

今やOSSライセンスを使ったソフトウェア開発は90%以上とも言われている中で、これらの管理をスプレッドシートを使い手作業で確認をしている方々に是非こちらのブログをお読みいただき、WhiteSourceのツールに興味を持っていただけたらと思っています。

本ブログはWhiteSorce社に了承を得て翻訳をしたものになります。

全6回のうち今回は2回目、「これだけは知っておきたい「DevSecOps」のポイント」というブログをご紹介します。

この数年、DevOpsの周辺では「DevSecOps」という用語が特に注目されています。DevSecOpsが何を意味するのか、なぜ人々の関心を集めるのかは理論的に簡単に理解できます。
DevSecOpsは、DevOpsの効率性をソフトウェアのセキュリティ（Security）にも広げるという戦略です。

しかし、いざ腰を据えてDevSecOpsの導入を始めようとすると、物事はそう単純にはいきません。
DevSecOpsを一瞬でオンにするようなスイッチはありません。
DevSecOpsの実現には、複数のツールと実践的な手法が必要です。

ここサイトでは、DevSecOpsを導入しようとする組織の多くが検討しなければならない主な課題を取り上げ、どのようにDevSecOpsを実現するのかを見ていきます。

DevSecOpsとは、基本的には、DevOpsに最初からセキュリティを組み込んだものです。
セキュリティを要件に組み込み、設計、コーディング、デプロイの各段階にも組み込みます。
つまり、DevOpsパイプラインの全体にセキュリティを組み込むことです。

■DevSecOpsとは何か

これまでのセキュリティ手法は、開発チームの作業スピードを低下させることがよくありました。
しかし、稼働開始までの時間は年々短くなっているため、ソフトウェア開発チームとしては、セキュリティを犠牲にすることなく、ソフトウェア開発プロセスを迅速にする方法を見つける必要がありました。

これが、DevSecOpsの始まりです。

最終的な目標は、セキュリティチームと開発者の橋渡しをして、コードを安全かつ高速にデリバリーすることです。
サイロ的な考えをするのでなく、チーム間でコミュニケーションを図ってアプリケーションセキュリティの責任を共有するという考え方に切り替えます。

■DevSecOpsを成功に導く実践法とツール

こうした目標のためには、どのように実践したらいいでしょうか。

セキュリティプロセスのどの部分を自動化し、CI（継続的インテグレーション）/CD（継続的デリバリー）パイプラインのほかの部分と統合できるでしょうか。
また、それはどのように実現できるでしょうか。

では、このような課題を検討し、最新のDevSecOpsツールと実践法を参考にしながら答えを見つけていきましょう。

【1. 脆弱性のスキャン】

コードをスキャンして脆弱性を検出することは、成果物のセキュリティを確保する基本的な第一歩です。
脆弱性スキャンをCI/CDプロセスに統合することは、DevSecOpsの導入においてまず実施する作業です。

このスキャンの目的は、デリバリーのパイプライン（コードの記述から本番環境へのデプロイまでの全工程）の主要な段階すべてにおいてコードの脆弱性を確実にチェックすることです。
このレベルの統合を実現するには、パイプラインの各種段階の担当者に必要なトレーニングとツールを提供して、各担当者がコード内の脆弱性を検出できるようになる必要があります。

脆弱性スキャンに関する技術としては、自社独自コード内の脆弱性を検出するSAST（静的アプリケーションセキュリティテスト）と、オープンソースコンポーネントに存在する既知の脆弱性を検出するSCA（ソフトウェア構成分析）ツールがあります。
SASTやSCAの多くのベンダーが、CIサーバー、ビルドツール、リポジトリとの統合を提供しています。
また、開発者ができるだけ早期に問題を見つけられるように、IDEとの統合が提供される場合もあります。

【2. ランタイム保護】

ランタイム保護も、DevSecOps戦略の一環としてCI/CDパイプラインに統合されるべき重要なセキュリティプロセスの1つです。

ランタイム保護とは、アプリケーションが実行を開始したときに現れる脅威からソフトウェアを守ることです。
ランタイムセキュリティに関する議論は、これまで、ソフトウェアの本番稼働後だけで安全性どう確保するかという点に集中していましたが、パイプラインの早期段階にランタイム時の脅威が存在する可能性もあります。

また、脅威がないとしても、ランタイムセキュリティをデリバリープロセスの早期に検討しておけば、デプロイの時点ですでにランタイム時の脅威リスクを軽減できています。
こうした理由から、ランタイムセキュリティも、本番環境に限らず、CI/CDパイプラインの全体に統合する必要があります。

ランタイム時の検出に使用するツールや戦略は、それぞれのニーズによって異なります。
しかし、少なくとも、アプリケーションを監視して、侵害の可能性を示す異常な動作を検知することは必要でしょう。

また、監視とともに重要なことは、どの環境変数や構成設定がランタイム時にセキュリティの脆弱性を作り出す可能性があるのかを認識しておくことです。
そうしたリスクを見つけ出すプロセスを導入することも大切です。

【3. クラウドサービスプロバイダー】

セキュリティをアプリケーションのデリバリープロセスに統合するにあたっては、クラウドサービスプロバイダーから提供されるセキュリティ機能をいかに活用するかも重要な戦略になります。

こうしたツールの多くは、デプロイ時とデプロイ後、つまりDevOpsチェーンの後半に位置付けられるため、どちらかといえば、従来の事後対応的なセキュリティサービスに近いものになります。
それでも、アプリケーション外側の防御の1つとして重要な役割を果たします。
また、クラウドインフラストラクチャの一部であることから、一般的に自動化やシステム化を容易行うことができます。

クラウドサービスプロバイダーが提供するセキュリティ機能は、デフォルトでは有効でない場合があり、設定が必要なことがあります。
このため、セキュリティ機能を最大限に活用するには、ユーザー企業の側から積極的に行動する必要もあります。

【4. 基準と方針】

セキュリティに関する基準と方針の設定は、主に人間が手動で行う仕事です。
ソースコードやインフラストラクチャの脆弱性をスキャンした後、セキュリティ対策の優先順位や実装方法を決定するプロセスには人間の熟考が必要になります。
これは、設計やコーディングのレベルでセキュリティ基準を適用するときも同様です。

EU市場の一部には一般データ保護規則（GDPR）が適用されることから、セキュリティ基準を明確に策定し、設計のレベルで適用することが非常に重要になっています。

一方、このような基準の組み込みは、運用レベルでは大部分を自動化できます。
RBAC（ロールベースのアクセス制御）など、オーケストレーションツールやサービスメッシュの機能を使えば非常に細かい粒度でポリシーを適用できます。
ロールベースのアクセスポリシーの設計には、アプリケーションソースコードでのセキュリティ基準の設計と同じように注意を払う必要があります。
どちらも、優先度の高いタスクと考えてください。

【5. コンテナとサービスの管理】

Kubernetesなどのコンテナオーケストレーションツールは、コンテナベースの大規模アプリケーションのデプロイではほぼ必須となっています。
サービスメッシュは、オーケストレーションツールと連携して、サービスの検出やアクセスなどを管理し、ユーザー、コンテナベースのアプリケーション、外部サービスの間の関係も管理しますが、サービスメッシュ自体の重要性も次第に増しています。

このようなツールは、DevSecOpsにとってデプロイのレベルで鍵となる要素であり、コンテナと外部を分離する拡張性の高いレイヤーの役割を果たします（ユーザーや攻撃者は、プロキシーなどで隠ぺいされたサービスにしかアクセスできず、個々のコンテナにはアクセスできません）。
また、こうしたツールは、認証、承認、暗号化などのタスクも実施できます。そしてこれらのツールは、最初の段階から自動化を考慮して設計されています。

しかし、クラウドサービスプロバイダーが提供するセキュリティツール以上に、オーケストレーションツールやサービスメッシュにつしかし、クラウドサービスプロバイダーが提供するセキュリティツール以上に、オーケストレーションツールやサービスメッシュにつ