DevOps とセキュリティの統合を実現するための4つのヒント

多くの企業においてアプリケーション開発のデリバリーサイクルが高速化するなか、まだ DevOps の導入を検討していない企業は、市場の動きに遅れを取らないためにも DevOps へ移行せざるを得なくなるでしょう。DevOps は、設計・開発から本番環境のサポートに至るまで、ソフトウェアのデリバリーライフサイクル全体を通して、開発チームと運用チームのコラボレーションを可能にする文化、取り組み、プラクティスです。

しかし、継続的なデリバリーモデルの普及に伴い、DevOps とセキュリティの統合に関して運用面や文化面にて新たな課題が生じています。

この統合は、さまざまな困難を伴うプロセスです。しかし、セキュリティをパイプラインに組み込むことで、被害を受ける前にリスクを軽減できるため、これらの困難を乗り越えてでも導入するメリットがあります。そのためには、DevOps チームがセキュリティをプロセスの一環として受け入れ、セキュリティを DevOps の組織文化に融合する必要があります。

すでに多くの企業が、ビジネスの成果を考慮してセキュリティを統合することに取り組んでいるか、統合を計画しています。Enterprise Strategy Group (ESG) と提携して実施した調査レポート「転換期を迎えた Web アプリと API のセキュリティ」では、55%の企業が現在は複数のチームが Web アプリケーションのセキュリティを担当しているが、将来的にはチームを統合する予定であると回答しています。

この統合はセキュア DevOps (または DevSecOps) と呼ばれ、サービスのライフサイクル全体でセキュリティと DevOps を連携させる取り組みです。DevOps とセキュリティの統合を検討する際には、以下の点に注意してください。

1. ゲート型の対策にとらわれないセキュリティ

組織文化はあらゆるビジネス機能の基盤です。それは特に DevOps によく言えることです。セキュリティが DevOps への文化的な移行を進めるうえで、セキュリティ担当者は、セキュリティチームが進行とイノベーションを妨げると、無視され疎んじられることを認識しなければなりません。

ゲート型のセキュリティ文化を構築・育成することは、持続可能なモデルでもなければ、先進的なモデルでもありません。セキュリティチームは開発チームと連携し、優れた相互関係を築く方法を見つけることが重要です。

両チームが組織文化の壁を超え、互いに歩み寄ることができなければ、セキュアな DevOps への移行が妨げられてしまいます。セキュリティチームと開発チームには、部門の垣根を超えた、ツール、ポリシー、プロセス全体の高度なコラボレーションと一体化が必要になります。

2. 組織のセキュリティの主導者の任命

DevSecOps を推進する取り組みは、セキュリティチームだけの仕事ではありません。組織内で、セキュリティを考慮した意思決定を促進することができるセキュリティ擁護者を任命することが重要です。

セキュリティ専門の人材不足により、将来的な需要の拡大はおろか現在のニーズを満たすことも困難な状況であるため、単に追加のリソースを雇うだけでは企業のセキュリティの問題は解決できません。その代わり、最も効率的なセキュリティチームは、部署をまたいでセキュリティの主導者を代わりに任命する方法を模索しています。

3. フィードバックループの改善

セキュリティにとって最悪のフィードバックループは、セキュリティ侵害を受けたことで企業名が見出しに掲載されてしまうようなフィードバックループです。あらゆるプロセスの基盤となるものですが、ソフトウェア開発の分野ではこのフィードバックループの定義に苦労しています。よりペースの早い新しい DevOps サイクルでセキュリティを成功させるには、フィードバックループを改善しなければなりません。高速なデリバリーサイクルを目指す場合、セキュリティチームは速やかなフィードバックループを確立する必要があります。

急速に変化する実稼働環境のインサイトを得ることで、イベントがインシデントに発展する前に、セキュリティチームは開発および運用チームと連携してイベントに対応することができます。プロアクティブな Web 保護対策を導入することで、セキュリティチームと DevOps チームに対するフィードバックループが形成され、以下のような質問に答えられるようになります。

• ログイン数が増加していないか

• パスワード変更の数が増加していないか

• 過去1時間に通常よりも多くのアカウントが作成されていないか

これらはすべて、現在のビジネスの状況に関連した主観的な質問です。多くの組織によってすでにこれらのメトリクスのいくつかが追跡されていると思われますが、全体を見通せるように可視化されていません。次世代 WAF (Web アプリケーションファイアウォール) を利用することで、セキュリティチームは、現在進行中または成功した攻撃シグナルの指標となる異常な動作をチェックするフィードバックループを構築することができます。

4. 「すべてをコードとして扱う」ことのセキュリティへの影響

「Infrastructure as code」または「Everything as Code (すべてをコードとして扱う)」とは、インフラやシステム全体の作成、実行、テスト、変更、監視、セキュリティ、破棄などに必要なすべてをコードで定義することです。これにより DevOps チームは、従来は手作業で行っていたタスクに対して反復可能でスケーラビリティのあるアプローチを導入し、人的ミスを減らすことができます。

以下に挙げる Infrastructure as Code の広義の目標はセキュリティと密接な関係があります。

成果物のバージョン管理

バージョン管理された成果物は、システムとそのすべてのコンポーネントを記述する必要があります。これにより、Wiki やドキュメントから構成が分離され、バージョン管理可能で参照可能な状態を維持できます。さらに、システムの構成管理が稼働中であることが必要です。

テスト駆動開発と結合テスト

テスト駆動開発と結合テストを習慣化することが重要です。テストは、開発中のアプリケーションコードだけでなく、インフラストラクチャコードに対して記述するようにしましょう。インフラストラクチャを作成しながらテストを記述することで、要件を満たしているか確認できるだけでなく、CI/CD のためのテストスイートも同時に得られます。

分散コンピューティングとスケーラビリティ

インフラストラクチャをコードとして扱わない場合、スケールアップが困難になり、分散コンピューティング (クラウド) がほぼ不可能になります。分散コンピューティングとスケーリングが望ましい結果であるとする考え方が開発プラクティスの指針となります。

ソフトウェアサプライチェーン

ソフトウェアを構成するのは、開発者によって書かれた何百、何千行ものコードだけではありません。さまざまな依存関係から OS、仮想化フレームワークに至るまで、多くのコンポーネントで構成されています。Infrastructure as Code は、特定性とシステム稼働時の監査可能なログを提供することで、ソフトウェアのサプライチェーン管理を促進します。

次のステップ

まだ移行の初期段階にある場合は、セキュリティフィードバックループを作成することから始めるのがベストです。これにより、本番環境のアプリケーションにセキュリティの測定機能が組み込まれ、開発、運用、セキュリティの各チームへのフィードバックが作成されます。このような測定機能を追加することで、開発サイクルの短縮を促し、組織のセキュリティに対する認識を「イノベーションの阻害要因」から「イノベーションの促進要因」に変えることができます。

DevSecOps への移行において組織が直面している課題や、成功するために必要なツールの種類の詳細については、「転換期を迎えた Web アプリと API のセキュリティ」のレポートをダウンロードしてください。