ポイント: CI/CDパイプラインにセキュリティアズコードを組み込むことは、開発の初期段階でセキュリティプラクティスを統合し、脆弱性がボトルネックにならないようにします。5つのベストプラクティスは、セキュリティとコンプライアンスチェックが開発ライフサイクル全体に組み込まれることを保証します。
- 最初からセキュリティポリシーを定義してコード化します。
- コードチェックイン時にセキュリティをテストして早期に脆弱性を特定します。
- パイプライン全体で継続的にコンプライアンスチェックを自動化します。
これは、BMCがアジャイル開発、クラウドサービス、インフラストラクチャとしてのコードアプローチ、新しいデプロイメント技術を使用してクラウドネイティブ製品を提供する方法を示すミニシリーズの第4回目のブログです。 ぜひこちらもお読みください： クラウドネイティブアプリケーションの始め方、 継続的デリバリーとデプロイメントのためのパイプライン構築の9ステップ、および インフラストラクチャおよび「すべてをコードとして」がすべてを変える方法 CI/CDパイプラインにセキュリティをコードとして組み込むことは、セキュリティポリシー、テスト、およびコンプライアンスチェックをバージョン管理された自動化されたアーティファクトとして扱うことを意味します。これにより、リリース時ではなく、開発中に脆弱性を捕捉します。以下の5つのベストプラクティスは、エンジニアリングチームがセキュリティアズコードとコンプライアンスアズコードの原則を継続的デリバリーパイプラインに直接組み込む方法を示しています。両方のセキュリティとスピードを維持するために。
CI/CDパイプラインにおけるセキュリティとしてのコードが重要な理由は何ですか？
セキュリティが最初から統合されていない場合、最悪のタイミングでボトルネックになります。リリースがデプロイ準備に近づくと、チームは脆弱性スキャン、侵入テスト、脅威モデリングの遅延ステージの試練に強いられます。これは手動のツール、チェックリスト、およびレビュー文書を通じて実行されます。この段階で重要または高い脆弱性が浮上すると、リリースは数週間または数ヶ月停止します。 セキュリティアズコードの原則は、セキュリティプラクティスをコード化し、セキュリティを実行するための一部として自動化することで、このボトルネックを排除します。DevOps パイプラインにおいて。セキュリティとコンプライアンスは継続的に強制されます。ユースケース、設計、開発、およびアプリケーションデリバリーのテスト段階で、事前リリースレビューに先送りされるのではなく。セキュリティポリシー、テスト、および結果は、第一級のコードアーティファクトとして扱われます：同じリポジトリでバージョン管理され、アプリケーションコードと同じCI/CDパイプラインを通じて進行されます。
セキュリティとコンプライアンスをコードとして適用するための5つのベストプラクティスは何ですか？
以下のプラクティスは、BMCがAmazon Web Services（AWS）上にクラウドネイティブアプリケーションを構築する経験から得られたものです。それぞれがセキュリティアズコードアプローチの異なるレイヤーに対処しており、初期のポリシー定義から本番環境の修正までを含みます。
1. セキュリティポリシーを定義してコード化する
セキュリティポリシーはプロジェクトの非常に初期に定義され、アプリケーションコードと並んでソースコードリポジトリに保存されるべきです。AWS上のクラウドネイティブアプリケーションにおいて、これには以下のような要件が含まれます：
- セキュリティグループとファイアウォールが保護されている
- 仮想プライベートクラウド（VPC）、Elastic Load Balancing、および関連サービスが強制され、保護されている
- すべてのEC2および他のリソースはVPC内に存在し、個別にファイアウォールで保護されなければならない
- すべてのAWSリソースとログはキー管理サービスを使用して暗号化されている
セキュリティポリシーは自動化されなければならず、単一のアクションで任意のアプリケーションの任意のステージまたは環境で評価できる必要があります。セキュリティに関するすべてはコード化され、バージョン管理され、自動化されています。セキュリティアーティファクトは、アプリケーションコードと同様にリポジトリにチェックインされます。 企業は、組織全体やアプリケーション間で再利用できる標準化されたセキュリティパターンを構築するべきです。たとえば、3層アプリケーションと開発/テスト用クラウド環境はそれぞれ、独自の標準セキュリティテンプレートを必要とします。AWSでは、5つのNIST AWS CloudFormationテンプレートがネットワーク、VPC、およびアイデンティティとアクセス管理ロールを強化し、「ハードンされたクラウド」基盤を形成します。プライベートクラウドまたはオンプレミスインフラストラクチャ用には、BMC BladeLogic Server Automationがサーバーのハードニングを処理します。
2. セキュリティユーザーストーリーを定義し、アプリケーションアーキテクチャリスクを評価する
セキュリティ関連のユーザーストーリーは、他の機能ストーリーと同様にアジャイルプロセスで定義されなければなりません。例としては、
- 「クロスサイトスクリプティングおよびSQLインジェクション用の入力検証」
- 「すべての通信にSSL/TLSを有効にする」
- 「自動化されたアプリケーションセキュリティテスト」
このプラクティスは、セキュリティがオプションとして扱われたり、後回しにされたりすることがないことを保証します。セキュリティ制御は、アプリケーションのセキュリティリスクと脅威モデルに基づいて特定され、アプリケーションコードまたはポリシーを通じて実装されます。
3. アプリケーションコードのチェックイン時にセキュリティをテストおよび修正する
セキュリティテストは、アプリケーションおよびインフラストラクチャの変更のためにコードがチェックインされるとすぐに自動的にトリガーされるべきです。多くのセキュリティ脆弱性スキャンツールは、BMC、サードパーティベンダー、およびオープンソースプロジェクトから入手でき、検出と修正を自動化します。重要または高い脆弱性が見つかった場合、自動化ツールはコンポーネントの所有者に解決のために割り当てられる欠陥またはチケットを生成できます。 クラウドネイティブアプリケーションの場合、コードチェックインでのテストには、定義されたセキュリティポリシーに対してAWS CloudFormationテンプレートのようなインフラストラクチャアズコードアーティファクトを評価することが含まれます。
4. セキュリティポリシーをテストして要件を満たさないことを確認する
セキュリティポリシー自体も、既知の悪い構成を許可しないことを確認するためにテストされなければなりません。ポリシー違反チェックの例には、
- 「S3バケットは公開で読み取りまたは書き込み可能であってはならない」
- 「すべてのトラフィックが許可された0.0.0.0を使用しないこと」
このテストは、アプリケーションデリバリーパイプラインの一部として自動化されるべきです。BMCのクラウドネイティブアプリケーション用のパイプラインでは、セキュリティスキャンがSpinnakerからオーケストレーションされ、本番環境へのすべてのプッシュを検証します。規制コンプライアンスチェック、たとえば、 Center for Internet Security (CIS)およびDefense Information Systems Agency (DISA)の要件をサーバー、データベース、およびネットワーク全体で検出し、修正することができます。
5. 本番環境でセキュリティとコンプライアンスをテストおよび修正する
自動化されたセキュリティとコンプライアンスのテストは、アプリケーションが開発、QA、およびテスト環境を通じて移動する際に続きます。この段階で重大な問題を見つけるリスクは低くなります。なぜなら、ほとんどのセキュリティ自動化はパイプラインの早い段階で実行されるからです。本番環境では、BMC BladeLogic Server AutomationとBMC Threat Directorが変更可能なインフラストラクチャの本番サーバーをスキャンした後にセキュリティパッチをサポートします。 このステップは 重要です ：攻撃の80％以上が既知の脆弱性をターゲットにしており、79％の脆弱性は開示当日にパッチが利用可能です。AWSなどの公共クラウドにデプロイされたアプリケーションでは、セキュリティとコンプライアンスの評価をSpinnakerを通じて自動化できます。 現代のクラウドネイティブスタックでは、コンポーネントは決してその場でパッチを適用されません—完全に置き換えられます。それでも、新しいコンテナやサーバーは本番環境に展開される前にセキュリティおよびコンプライアンスのテストを通過する必要があります。
シフト 左にシフトする：セキュリティを最初から始める
この シフトレフト 原則は、リリースプロセスの最後から最初にセキュリティを移動させ、DevOpsパイプライン全体にわたってそれを保持することを意味します。セキュリティを最終ゲートとして扱うのではなく、または本番環境の定期スキャンを実行するのではなく、チームはセキュリティアズコードのプラクティスをデリバリーのすべての段階に組み込みます。プロジェクト開始時のポリシー定義から、本番環境での自動化されたコンプライアンスチェックまで。ポリシーをコード化し、テストを自動化し、CI/CDパイプラインにコンプライアンスを統合することで、製品チームは セキュリティとイノベーションのスピードの両方を維持することができます。
CI/CDにおけるセキュリティとしてのコードに関するよくある質問
セキュリティとしてのコードとDevSecOpsの違いは何ですか？ セキュリティとしてのコードは、セキュリティポリシー、テスト、およびコンプライアンスチェックをバージョン管理された自動化されたコードアーティファクトとして扱うDevSecOpsの特定のプラクティスです。 DevSecOps は、ソフトウェア開発ライフサイクル全体にわたってセキュリティ責任を統合するための幅広い文化的および組織的実践であり、セキュリティとしてのコードはDevSecOpsを実行可能にする技術的実装です。 セキュリティテストの文脈で「シフトレフト」とは何ですか？ シフトレフトとは、開発プロセスの早い段階にセキュリティテストと検証を移動させることを意味します。理想的にはコードチェックインの時点まで待たずに、ステージングやリリースを待たずに。セキュリティアズコードパイプラインでは、自動化されたセキュリティチェックがすべてのコミットで実行され、開発段階での脆弱性を捕捉し、修正が最も安く迅速に行えるようにします。 CI/CDパイプラインで自動化されたセキュリティテストをサポートするツールは何ですか？ 一般的なツールには、脆弱性スキャナー、インフラストラクチャアズコードポリシー検証ツール、およびコンプライアンス自動化プラットフォームが含まれます。BMC BladeLogic Server Automation、BMC Threat Director、およびSpinnakerなどのパイプラインオーケストレーターは、開発、QA、および本番環境における自動化されたセキュリティとコンプライアンスのテストをサポートするツールの例です。 クラウドアプリケーションにおける標準化されたセキュリティパターンが重要な理由は何ですか？ 標準化されたセキュリティパターンは、チームが複数のアプリケーションや環境にわたって再利用可能なセキュリティ構成を使用できるようにします。これにより、各チームがゼロからセキュリティを定義する必要がなくなり、組織全体で一貫した、すぐに使用できるセキュリティカバレッジを確保します。NIST AWS CloudFormationテンプレートは、再利用可能なハードンされたクラウドパターンの一例です。 セキュリティアズコードは、セキュリティレビューによるリリースの遅延をどのように軽減しますか？ コードチェックインおよびCI/CDパイプライン全体で自動化されたセキュリティとコンプライアンスチェックを実行することで、セキュリティアズコードは、リリース時ではなく開発中に脆弱性を捕捉します。これにより、重要な問題が本番環境に近くで見つかった場合に、従来の手動のセキュリティ評価—侵入テスト、脆弱性スキャン、脅威モデリング—によるリリースの数週間または数ヶ月の停止が排除されます。 この投稿における見解や意見は著者のものであり、BMCの公式な立場を必ずしも反映するものではありません。
これらの投稿は私自身のものであり、BMCの立場、戦略、または意見を必ずしも表すものではありません。