政府におけるDevSecOpsの運用
政府の製品開発は、多様なユーザーベースの幅広さから、テクノロジー製品の必要なスケーリングと信頼性まで、困難です。 ユーザーには、製品が堅牢で回復力があり、回復可能であることを期待するあらゆるタイプの人々、世代、民族、言語が含まれます。 どの製品にとっても最も困難な側面の1つは、情報の保護です。 特に政府製品に関する違反は、長年の努力を通じて築き上げられた可能性のある信頼を即座に損なう可能性があります。 開発、セキュリティ、運用を統合するアジャイルアプローチ(DevSecOps)を採用することで、パイプライン全体にセキュリティが組み込まれます。
この記事では、DevSecOps を定義し、製品開発で使用する方法について説明します。
DevSecOpsとは何ですか?
まず、DevOpsとは何ですか? DevOpsは、ソフトウェア開発と一般的なITインフラストラクチャ間のプロセスを自動化および統合するために機能する一連のアジャイルプラクティスであるため、クロスファンクショナルチームとしてソフトウェア製品をより迅速かつ確実にシームレスに構築、テスト、リリースできます。 DevOpsという用語は、「開発」と「運用」という言葉を組み合わせて形成され、歴史的にサイロで機能していたソフトウェア開発とIT運用の間のギャップを埋める文化的変化を意味します。
DevSecOpsは、最初からDevOps内にセキュリティプラクティスを統合するという哲学です。 これには、ソフトウェア開発、IT運用、セキュリティの専門知識間の継続的で柔軟なコラボレーションにより、アジャイルな「コードとしてのセキュリティ」文化を構築することが含まれます。 セキュリティの問題を別のチームとして扱うのではなく、すべての開発やその他のテストが完了したら、すべてのスプリント で完了の定義 にセキュリティを組み込みます。 DevSecOpsの目標は、ITとセキュリティの間の従来のギャップを埋めながら、ソフトウェアの高速で安全な配信を保証することです。
DevSecOps は、古いセキュリティ モデルのボトルネック効果への対応です。 従来のセキュリティゲートは、多くの場合、ソフトウェア開発プロセスの最後のステップで、通常は別のセキュリティ部門によるセキュリティ要件とテストに合格しない限り、製品がリリースされないようにするために設置されました。 継続的インテグレーションと継続的デプロイ (CI/CD) を組み合わせた DevSecOps アプローチにより、セキュリティ テストは、完了のスプリント レベル定義の一部として毎日の自動化によって実装され、リリース レベルの定義の一部として “レッド チーム” テストを通じてリリース サイクル中に対処されます。
アジャイルチームが 新しい設計に積極的に関与し、ソフトウェアの価値と品質を提供し、規制要件を遵守することで、セキュリティはもはやセキュリティチームだけの関心事ではなくなりました。それは全員の責任です。
また、DevSecOpsワークフローの速度が低下しないように、いくつかのセキュリティゲートを自動化することも意味します。 セキュリティを継続的に統合するための適切なツールを選択することで、これらの目標を達成することができます。 ただし、効果的な DevSecOps には、新しいツール以上のものが必要であり、DevOps の文化的な変化に基づいて構築され、セキュリティの作業を遅かれ早かれ統合できます。 DevSecOps は組み込みのセキュリティに関するものであり、アプリやデータの境界として機能するセキュリティではありません。
アジャイル組織は DevSecOps をどのように使用しますか?
セキュリティは、ソフトウェアに後付けで追加できるものではなく、リスクを軽減するセキュリティ対策を、開始から配信、そしてそれ以降のプロセスに組み込む必要があります。 各要件はアイデアとして始まり、コード化、テスト、統合、文書化、承認、展開され、市場からのフィードバックが得られます。
アジャイル製品開発チームがリスクを軽減するセキュリティ対策を製品開発に組み込む方法の例を次に示します。
- アイデアとして、ユーザーストーリーを使用して、望ましい安全な機能と結果を説明できます。
- コーディング時に、チームはテスト駆動開発またはペアリングを使用して、開発時に高品質で安全な製品を確保できます。
- 継続的なテストと統合を通じて、スキャンまたは静的コード分析、侵入テスト、コンプライアンス テスト、負荷テスト、オリジン分析テスト、およびその他のアプローチを使用して、製品のセキュリティの堅牢性に対する信頼性を高めることができます。
- デプロイ時に、チームはコーディング中にビルドされた同じイメージが、ユーザーにデプロイされた同じイメージであることを確認します。 DevSecOps パイプラインは、デプロイを自動化し、単体テストと回帰テストの多くを自動化します。
- 製品を保守する場合、ユーザーにリリースされた後、定期的な脆弱性スキャンによって突然変異や脆弱性が公開される可能性があります。
これらのリスク軽減策は、チームの完了の定義に含まれます。 製品所有者は、「完了」していない、または安全でない製品の増分をすぐに拒否します。
欠陥が特定されると、アジャイルチームは 予期しないセキュリティ問題に対処するために簡単に適応できます。 アジャイルアプローチは、長期的な視点で作業を整理し、変更が発生したときに対応するチームに非常に適しています。 安全で安定した製品の作成に関心を持つのはすべての人の仕事ですが、 開発者がセキュリティ専門家を100対1で上回っているため、各チームに深いセキュリティの専門知識を持つことは不可能です。 標準と自動化を通じて、DevSecOpsはDevOpsを拡張し、強固なセキュリティプラクティスとツールをデリバリー運用プロセスに統合し、チームが適切なレベルのセキュリティ保証と信頼性を実現できるようにします。
セキュリティトレーニングは、DevSecOpsを使用している組織が推進する別の側面です。 多くの場合、組織は、セキュリティの専門家を活用して、健全なセキュリティプラクティスがすべての部門横断的な製品開発チームのメンバーによって学習、理解、採用されるようにできる実践コミュニティまたはギルドをサポートしています。 セキュリティ、運用の利害関係者、対象分野の専門家も、フィードバックとガイダンスを提供できるスプリント レビューに参加する機会があります。 懸念事項や調査結果が議論されます。 製品所有者は、他のすべてのフィードバックと共に、製品バックログでの追加と優先順位付けのためのセキュリティ フィードバックを検討します。
どこから始めますか?
あなたがいるところから始めましょう。 まず、製品のセキュリティの強み、弱み、機会、脅威を分析します。 製品のセキュリティを向上させるために、完了の定義に加えることができる変更はありますか? おそらく、すべての人のセキュリティ慣行を改善できる標準または自動化があります。 CI/CD パイプラインの一部として、または潜在的な脅威を強調するために独立して実行できるセキュリティ テストはありますか? その場合は、この情報を使用して開発アプローチを適応させます。 検査して適応します。
結論
DevSecOpsは、セキュリティがプロセスと製品に内在するように製品開発を可能にすることを目指しています。 このアプローチは、最新のシステム、特に政府が使用する製品など、より規制の厳しい環境では不可欠です。 DevSecOpsは、組織がソフトウェア開発プロセス全体にエンドツーエンドでセキュリティを織り込むことに取り組んでいると同時に、配信を遅らせる可能性のある不必要な負担を回避しているときに登場しました。 DevSecOps を成功させるための鍵は次のとおりです。
- セキュリティは最初から考慮され、製品開発プロセス全体を通じて完了するというチームの定義を使用して組み込まれ、「コードとしてのセキュリティ」文化が生まれます
- ソフトウェア開発、運用、セキュリティの熟練した人材間の日常的な部門横断的なコラボレーション
- 自動化とアジャイルなアプローチにより、DevSecOps が可能になります
- セキュリティは、認識、トレーニング、所有権を通じてすべての人の責任になります。
お 問い合わせ。 DevSecOpsのベストプラクティスを取り入れ、持続可能な「コードとしてのセキュリティ」文化を構築するお手伝いをします。
