DevSecOpsの概要
著者
0 分で読めます
DevSecOpsとは？
DevSecOpsとは、DevOpsのソフトウェアデリバリーモデルにセキュリティプラクティスを統合することです。その基盤となるのは、プロセスとツールによって開発チームと運用チームが連携し、安全なソフトウェアを提供する責任を共有する文化です。
DevSecOpsモデルを高い成熟度で実現するには、ソフトウェア開発ライフサイクルの可能な限り早い段階から、セキュリティ目標を統合する必要があります。セキュリティは「全員の責任」ですが、開発と運用の接点に位置するDevOpsチームは、幅広く、かつ深くセキュリティを適用できる独自の立場にあります。
DevOpsとDevSecOpsの違いとは？
DevOpsとDevSecOpsの違いを簡単に言えば、責任を共有する文化があるかどうかです。DevOpsは10年以上にわたって語られ、書かれてきた概念であり、さまざまな定義が生まれています。その本質は、開発と運用のプラクティスを共通の責任として連携させる組織のあり方です。
DevOpsとDevSecOpsの比較
当初は、成果を上げているソフトウェアエンジニアリングチームに共通するプラクティスの緩やかな集合体だったものが、現代のエンジニアリング文化とプロセスを表す概念へと発展しました。それがDevOpsです。開発と運用の責任を共有する組織は、より迅速に改善を重ねられるため、より大きな成果を上げられます。DevSecOpsはこの考え方をさらに発展させ、全体目標の中にセキュリティ目標を組み込みます。DevSecOpsは、別個の考え方ではなく、DevOpsの自然な発展形と捉えるべきです。DevOpsのプラクティスをうまく実践できているチームは、DevSecOpsを革命的な変化ではなく、進化のステップとして考えるとよいでしょう。
多くの人が目指していたのは、コードから本番環境への移行をシームレスかつ持続的に進め、ビジネス価値を生み出す環境だったと考えるでしょう。この新しいモデルに伴って導入されたツールや手法は開発のペースを速めましたが、ボトルネックも生み出しました。従来のセキュリティプラクティスはフィードバックサイクルが遅く、スピードを重視するDevOpsの妨げとなったのです。その結果、セキュリティ対策は本番リリース後に実施されたり、プロセスに外部チームが加わったりすることが多く、開発を遅らせていました。
DevOpsとDevSecOpsの違いをより明確にすると、DevSecOpsはDevOpsの責任共有の文化にセキュリティプラクティスを加えたものです。セキュリティ上の問題を特定し、可能であれば解決するための活動を、製品リリース後ではなく、アプリケーション開発ライフサイクルの早い段階から組み込みます。そのために、ソフトウェア開発ライフサイクル（SDLC）の中で、多くのセキュリティタスクを開発チームが自律的に実行できるようにします。
このアプローチにより、本番環境に到達する脆弱性を最小限に抑え、セキュリティ上の欠陥修正にかかるコストを削減できます。拡張性を高めるとともに、セキュリティをDevOpsの目標に近づける協力的な文化を築きます。DevSecOpsは、要件定義の段階からデリバリープロセスのすべてのステージにセキュリティを組み込み、セキュリティ自動化の計画を確立することを目指します。
DevSecOpsが重要な理由
DevSecOpsのプラクティスが重要なのはなぜでしょうか？
デジタルトランスフォーメーションは、ほぼすべての企業にとって不可欠なものになっています。この変革には、ソフトウェアの増加、クラウドテクノロジー、DevOps手法という3つの大きな動きが含まれます。
ソフトウェアが増えるほど、組織のリスクはデジタル化し、技術的負債も増大します。その結果、アプリケーションセキュリティの重要性が高まり、デジタル資産の保護はますます難しくなります。
クラウドの利用は、新しいテクノロジーの導入を意味します。これらのテクノロジーは異なるリスクをもたらし、変化の速度も速く、より広く公開されるため、安全な境界という概念がなくなるか、再定義されます。また、多くのITリスクやインフラリスクがクラウドへ移行し、ソフトウェアによって定義されるものも増えています。これにより多くのリスクが軽減される一方、権限やアクセス管理の重要性が高まります。
最後に、DevOpsはソフトウェアの開発とデリバリーの方法を変えます。コードの作成から顧客への価値提供、市場からの学び、そして適応までのサイクルを加速させます。権限を与えられた開発チームは、テクノロジーや実装に関する判断を自律的に行い、仲介者を介さず、これまで以上の速さで継続的にソフトウェアをリリースします。開発の足かせとなる従来の遅いフィードバックサイクルは受け入れられなくなり、チームは自立性をますます重視します。つまり、「自分で書いたコードは自分で運用する」という考え方です。
組織の他の部門が進化する一方で、セキュリティチームへの要求は高まり、ボトルネックになりやすくなっています。クラウド以前の低速な時代に設計された従来型のアプリケーションセキュリティツールやプラクティスは、高品質なアプリケーションの提供において、セキュリティチームをクリティカルパスにしてしまいます。深刻なセキュリティ人材不足で人員が足りないチームはボトルネックとなり、要求に追いつけません。その結果、開発チームは安全でないアプリケーションをリリースし、セキュリティチームは疲弊し、セキュリティは反対ばかりする存在となり、ビジネスが求めるスピードを損ないます。
こうした課題に対応するため、人々がプラクティスを変え始め、DevSecOpsが生まれました。DevSecOps文化は、セキュリティをDevOpsに組み込み、開発チームが自らのペースで構築したものを保護できるようにすると同時に、開発担当者とセキュリティ担当者の連携を強化します。セキュリティチームは、開発者の自律性を高める専門知識やツールを提供する支援組織となり、ビジネスが求めるレベルの監督も維持できます。
DevSecOpsモデルの6つのメリット
デリバリーの迅速化：パイプラインにセキュリティを統合することで、ソフトウェアのデリバリーを速められます。デプロイ前にバグを特定して修正できるため、開発者は機能のリリースに集中できます。
セキュリティ態勢の向上：設計段階からセキュリティを機能の一部として組み込みます。責任共有モデルにより、構築からデプロイ、本番ワークロードの保護まで、あらゆる段階にセキュリティを緊密に統合できます。
コストの削減：デプロイ前に脆弱性やバグを特定することで、リスクと運用コストを大幅に削減できます。
DevOpsの価値向上：セキュリティプラクティスをDevOpsに統合することで、責任共有の文化が生まれ、全体的なセキュリティ態勢が向上します。成熟したDevSecOpsを実践する組織でこの効果が見られることは、Snyk/Puppet 2020 DevSecOps Insights Reportでも明らかになっています。
セキュリティ統合と開発速度の向上：開発後にセキュリティ制御を後付けする必要がなくなり、安全なソフトウェアの提供にかかるコストと時間を削減できます。
ビジネス全体の成功を後押し：開発したソフトウェアのセキュリティに対する信頼が高まり、新しいテクノロジーを活用することで、収益の成長や事業の拡大につながります。
DevSecOpsの導入：CI/CDパイプラインへのセキュリティ統合
現在のDevOps組織の多くは、CI/CDパイプラインという形で、継続的インテグレーションと継続的デプロイメント／デリバリーのシステムを組み合わせて利用しています。このパイプラインは、人手による作業を必要とせずに、さまざまなセキュリティテストや検証を自動化するための優れた基盤です。
DevSecOpsの導入：CI/CDパイプラインへのセキュリティの統合
アプリケーション開発の早い段階からセキュリティ目標を統合するには、最初のコードを書く前から始めましょう。システムやアプリケーション、個々のユーザーストーリーの初期構想段階から、セキュリティを組み込み、効果的な脅威モデリングを開始できます。開発者がコードをチェックインするたびに静的解析、リンター、ポリシーエンジンを実行すれば、変更が次の工程に進む前に、容易に対処できる問題を解決できます。
ソフトウェア構成分析を包括的に適用することで、オープンソースの依存関係に互換性のあるライセンスが適用され、脆弱性がないことを確認できます。その結果、開発者はアプリケーションのセキュリティに対する当事者意識を持ち、自分が書いたコードの安全性について、すぐにフィードバックを得られるようになります。
コードをチェックインしてビルドしたら、セキュリティ統合テストを開始できます。コードを隔離されたコンテナサンドボックスで実行すると、ネットワーク呼び出し、入力検証、認可などを自動テストできます。テストからすぐにフィードバックが得られるため、問題を迅速に解決し、全体の開発フローへの影響を最小限に抑えながら、すばやく反復できます。説明のつかないネットワーク呼び出しや、サニタイズされていない入力などが見つかった場合はテストが失敗し、パイプラインから関係チームにレポートや通知が送られ、対応につながります。
デプロイ用アーティファクトが最初の統合テストを通過すると、次のテスト段階に進みます。ここでは、本番環境を限定的に再現した、より広範なサンドボックスにデプロイします。この段階でも、目的を変えてさらにセキュリティ統合テストを実施できます。
この段階では、適切なログ記録やアクセス制御などをテストできます。アプリケーションは、関連するセキュリティ指標やパフォーマンス指標を正しく記録しているでしょうか？適切な対象者だけにアクセスを許可し、それ以外のアクセスを完全に防いでいるでしょうか？テストに失敗した場合は、関係チームに対応事項が通知されます。
最後に、アプリケーションを本番環境に移行します。しかし、DevSecOpsの取り組みはそこで終わりません。パッチ適用と構成管理を自動化することで、本番環境では常に依存関係の最新かつ最も安全なバージョンが稼働します。理想的には、イミュータブルインフラストラクチャによって環境全体を頻繁に破棄して再構築し、パイプラインの各段階で一連のテストを継続的に実施します。
DevSecOpsのCI/CDパイプラインを活用すれば、煩雑な官僚的手続きや門番役を増やすことなく、各段階でセキュリティ目標を統合し、ビジネス価値を迅速に提供し続けられます。
DevSecOps文化を推進する
では、組織が「DevOps」から「DevSecOps」へ進化するには、どうすればよいでしょうか？多忙なDevOpsチームにセキュリティのKPIを渡して終わり、というほど簡単ではありません。迅速な反復を支える、協力的で責任を共有する文化が必要です。
開発の早い段階でセキュリティ目標を統合することが目的なら、できるだけ負担のない方法にする必要があります。セキュリティチームや目標をバリューストリームに統合する負担を、開発者に押し付けてはいけません。手順を追加するだけでは、顧客に機能を届けるまでの時間が長くなるだけです。セキュリティ組織は機動的であり、影響を最小限に抑えながらセキュリティを適用する現実的なアプローチを取るべきです。
計画段階、とりわけインフラに関する議論には、セキュリティエンジニアも参加すべきです。適切でない、または安全でない選択には異議を唱えられる一方で、代替案を提示できるだけの知識も必要です。過重な負担を抱えるセキュリティチームは、ただ「ノー」と言い、代替案の検討をDevOpsチームに任せてしまうことがあります。これも、セキュリティ組織に適切なリソースを与えることの重要性につながります。
セキュリティチームとDevOpsチームが早い段階から頻繁に連携することで、セキュリティ目標をインフラの基盤にしっかりと組み込めます。本番環境にデプロイされる機能やアプリケーションは、セキュリティ、開発、運用の各チームによる包括的かつ効果的な協力の成果となります。セキュリティチームが後から開発チームに機能追加や監査を依頼する必要はありません。最初から組み込まれていることを把握できるからです。
組織でDevSecOpsを実践するようになったなら、迅速な反復開発によって新機能や機能改善を提供し、お客様に喜ばれているだけでなく、それに見合うレベルのセキュリティも備えた体験を提供していることでしょう。
DevSecOpsを4つのステップで導入する方法をご覧ください。