DevSecOps の制御

[アーティクル]
07/11/2023

DevSecOps は、セキュリティのプロセスとツールを DevOps 開発プロセスに統合することにより、イノベーションセキュリティを適用します。

DevOps 自体がプロセスのバリエーションが多い新たな分野なので、DevSecOps を成功させるには、セキュリティを理解し、開発プロセスに慎重に統合する必要があります。セキュリティの追加は、コード、開発プロセス、およびワークロードをホストするインフラストラクチャに対する摩擦の少ない変更から始める必要があります。最初に、DevOps プロセスとスキルへの負担を抑えながら、セキュリティに最も良い影響を与える変更に焦点を当てます。

このドキュメントでは、継続的インテグレーションと継続的デリバリー (CI/CD) DevOps プロセスの各ステージと、最初に統合することをお勧めするセキュリティ制御について説明します。

DevSecOps controls

計画と開発

通常、最新の開発はアジャイル開発手法に従います。スクラムはアジャイル手法の実装の 1 つで、すべてのスプリントが計画アクティビティから始まります。開発プロセスのこの部分にセキュリティを導入するには、以下に重点を置く必要があります。

潜在的な攻撃者のレンズを介してアプリケーションを表示する脅威モデリング。
統合開発環境 (IDE) 内で軽量の静的分析チェックを行う IDE セキュリティプラグインと事前コミットフック。
効果的なセキュリティコーディング標準、ピアレビュープロセス、事前コミットフックを識別するためのピアレビューとセキュリティで保護されたコーディング標準。

これらの手順をすべて追加することは必須ではありません。しかし、各手順は、セキュリティの問題を早期に明らかにするのに役立ちます。この段階では、修正ははるかに安価で容易です。

脅威モデリング

脅威モデリングは、おそらく最も重要なセキュリティプラクティスです。結果はすぐに得られ、開発者が将来のすべてのプロジェクトでセキュリティを向上させようとする考え方を培うのに役立ちます。

脅威モデリングは単純な概念ですが、必要に応じてきめの細かい、専門的なものにすることができます。脅威モデリングでは、次のように、アプリケーションについての現実的なセキュリティの観点が明らかになり、文書化されます。

攻撃者がアプリケーションの設計を悪用する方法
脆弱性を修正する方法
問題を修正することの重要性

脅威モデリングでは、事実上、攻撃者の考え方に立ちます。これにより、攻撃者の視点でアプリケーションを見ることができます。攻撃者が行動を起こす前に攻撃をブロックする方法について学びます。チームが設計でユーザーペルソナを使用している場合は、攻撃者を敵対的なユーザーペルソナとして扱うことができます。

脅威モデリングについては、質問と回答によるシンプルな方法からツールベースの詳細な分析に至るまで、公開されているアプローチがあります。 STRIDE モデルまたは OWASP 脅威モデリングのような方法論に基づいてアプローチを構築できます。

脅威モデリング:簡単なことから始める

脅威モデリングに対する一部のアプローチは、時間がかかるスキル集約型のものになる可能性があります。そのため、基本的な質問を使用する、よりシンプルなアプローチから始めることをお勧めします。シンプルな方法は徹底的なものではありませんが、重要な思考プロセスを開始して、セキュリティの主要な問題をすばやく特定するのに役立ちます。

次のような、質問によるシンプルな方法を使用して開始できます。

Microsoft の簡単な質問方法: この方法では、一般的なセキュリティ設計上の誤りを表面化するように設計された特定の技術的な質問を行います。
OWASP 脅威モデリング: この方法では、脅威モデリングプロセスを開始するために、技術的ではないシンプルな質問に焦点を当てます。

チームにとって何が最善かに応じて、これらのアプローチのいずれかまたは両方を使用できます。

チームがプロセスに慣れてくるに従って、Microsoft のセキュリティ開発ライフサイクルに基づく、より高度なテクニックを使用できます。そして、Microsoft Threat Modeling Tool のような脅威モデリングツールを統合することにより、より深い分析情報を得たり、プロセスを自動化したりできます。

「Guide to Threat Modelling for Developers」(開発者向けの脅威モデリングのガイド) も有用なリソースです。

IDE セキュリティプラグインと事前コミットフック

開発者は配信速度に重点を置きますが、セキュリティ制御によってプロセスが遅くなる可能性があります。通常、低速になるのは、セキュリティチェックがパイプラインで開始された場合です。開発者は、コードをリポジトリにプッシュした後、潜在的な脆弱性を発見します。このプロセスを高速化し、すぐにフィードバックを提供するために、IDE のセキュリティプラグインやコミット前フックなどの手順を追加することには価値があります。

統合開発環境 (IDE) のセキュリティプラグインは、開発者の使い慣れた IDE 環境内で、開発プロセス中にさまざまなセキュリティの問題を特定します。プラグインは、開発者が記述したコードに潜在的なセキュリティリスクがある場合に、すぐにフィードバックを提供します。また、サードパーティのライブラリやパッケージに含まれるリスクを明らかにすることもできます。使用する IDE に応じて、多くのオープンソースまたは商用のプラグインがセキュリティ企業によって提供されており、利用できます。

考慮すべきもう 1 つのステップは、バージョン管理システムで許可されている場合に、pre-commit フレームワークを導入する方法です。 pre-commit フレームワークは、開発者がコードレビューのためにコードを送信する前に問題を識別するのに役立つ、Git フックスクリプトを提供します。 1 つの例として、GitHub で設定できる pre-commit があります。

ピアレビューとセキュリティで保護されたコーディング標準

プル要求は開発プロセスの標準です。 pull request プロセスの一部であるピアレビューでは、欠陥、バグ、人間のミスに関連する問題を検出できることがよくあります。 pull request を作成する前のピアレビューの段階で開発者を指導できる、セキュリティ専門家やセキュリティに関する知識を豊富に持つチームメイトがいることが理想的です。

セキュリティで保護されたコーディングプラクティスのガイドラインは、開発者が重要なセキュリティで保護されたコーディングの原則と、その適用方法を学習するのに役立ちます。 OWASP セキュアコーディングプラクティスなど、セキュリティで保護されたコーディングプラクティスを利用することができ、全般的なコーディングプラクティスに組み込むことができます。

コードをコミットする

通常、開発者は、コードの作成、管理、共有を、GitHub や Azure Repos などのリポジトリで行います。このアプローチでは、バージョン管理されたコードの一元的なライブラリが提供され、開発者はこれを使用して簡単に共同作業を行うことができます。ただし、1 つのコードベースに対して多くのコラボレーターを有効にすると、変更が入り込むリスクが生じる恐れもあります。そのリスクにより、脆弱性が生じたり、資格情報またはトークンが意図せずにコミットに含まれたりする恐れがあります。

このリスクに対処するには、開発チームがリポジトリのスキャン機能を評価して実装する必要があります。リポジトリスキャンツールは、リポジトリ内のソースコードに対して静的なコード分析を行います。ツールは、脆弱性や資格情報の変更を探し、見つかった項目にフラグを設定して修正できるようにします。この機能は人的エラーから保護するために機能し、多くの人が同じリポジトリで共同作業を行っている分散チームにとって便利な保護手段です。

依存関係管理

最近のアプリケーションでは、コードの最大 90 % に外部パッケージまたはライブラリの要素が含まれているか、それに依存しています。ソースコードに依存関係を導入する場合は、潜在的なリスクに対処する必要があります。多くのサードパーティライブラリには、深刻なセキュリティの問題があります。また、開発者が、常に最善のライフサイクルに従って依存関係を最新の状態に保っているわけではありません。

自分の開発チームが、アプリケーションにどのコンポーネントを含めるべきかを理解しておくようにする必要があります。セキュリティで保護された、最新バージョンを既知のソースからダウンロードする必要があります。また、バージョンを最新の状態に保つためのプロセスも必要です。 OWASP Dependency-Check プロジェクトや、WhiteSource などのツールを使用できます。

依存関係の脆弱性やそのライフサイクルに注意するだけでは十分ではありません。また、パッケージフィードのセキュリティに対処することも重要です。パッケージ管理システムを攻撃する、タイポスクワッティング、既存のパッケージの侵害、置き換え攻撃などの既知の攻撃ベクトルがあります。それで、パッケージ管理の責任者は、これらのリスクに対処する必要があります。詳細については、「Three ways to mitigate risk when using private package feeds」(プライベートパッケージフィードを使用する際にリスクを軽減する 3 つの方法) を参照してください。

静的アプリケーションセキュリティテスト

サードパーティのライブラリとパッケージ管理に取り組んだ後は、焦点を移し、コードのセキュリティを改善することが不可欠です。コードのセキュリティを改善するためのさまざまな方法があります。 IDE のセキュリティプラグインを使用できます。また、既に論じたように、増分スタティック分析であるコミット前およびコミット時のチェックを活用することもできます。また、ソースコード全体のスキャンを実行して、これまでの手順で見落としたミスを見つけることもできます。これは必要なことですが、大量のコードのスキャンを行うには、数時間、場合によっては数日かかることもあります。そのために、このアプローチによって開発が遅れ、負担となってしまう恐れがあります。

とはいえ、静的コードスキャンのプラクティスの導入は、どこかで始めなければなりません。 1 つの方法は、継続的インテグレーションに静的コード分析を導入することです。この方法では、コードが変更されたらすぐにセキュリティが検証されます。 1 つの例として、SonarCloud があります。これは、さまざまな言語を対象とする、複数の静的アプリケーションセキュリティテスト (SAST) ツールをまとめたものです。 SonarCloud は、保守容易性に重点を置きつつ、技術的負債を評価して追跡します。セキュリティに特化したチェッカーを備えており、コードの品質やスタイルを確認します。市場には、他にも多くの商用およびオープンソースのツールがあります。

フィードバックループを効果的なものにするためには、ツールのチューニングが欠かせません。誤検知を最小限に抑えて、問題を修正するために、明確で実行可能なフィードバックを提供する必要があります。さらに、何かが検出された場合に既定のブランチへのコードのコミットを防ぐためのワークフローを実装することも役立ちます。品質とセキュリティに関する検出結果の両方に対応する必要があります。そのため、セキュリティは単体テストエクスペリエンスの一部と言えます。

パイプラインのセキュリティ保護

DevOps では開発ライフサイクルのすべてのものがパイプラインを経由するため、自動化のレベルを引き上げることができます。継続的インテグレーションと継続的デリバリー (CI/CD) は、最新の開発サイクルにおいて重要な部分を占めています。 CI/CD では、開発者のコードが中央のコードベースと定期的にマージされ、通常のビルドとテストのプロセスが自動的に実行されます。

インフラストラクチャパイプラインは、開発における中核です。しかし、パイプラインを使用してスクリプトを実行したり、コードを運用環境にデプロイしたりすることによって、独特なセキュリティの課題が生じる恐れがあります。 CI/CD パイプラインが、悪意のあるコードの実行や資格情報の盗難のための手段になったり、攻撃者がアクセスするための入口になったりしないように気を付ける必要があります。また、意図したコードだけがリリースされ、デプロイされるように気を配る必要もあります。

DevOps チームは、パイプラインのための適切なセキュリティコントロールを確実に実装する必要があります。選択したプラットフォームに応じて、リスクに対処するための様々なガイドラインがあります。詳細については、「Azure Pipelines のセキュリティ保護」を参照してください。

ビルドおよびテスト

多くの組織では、ビルドパイプラインとリリースパイプラインを使用して、コードをビルドおよびデプロイするためのプロセスの自動化と標準化を行っています。リリースパイプラインにより、開発チームは、コードの一部に対する反復的な変更を、迅速かつ大規模に行うことができます。チームは、既存の環境の再デプロイやアップグレードのために大量の時間を費やす必要がなくなります。

また、リリースパイプラインを活用することで、開発環境からテスト環境を経て、最終的に運用環境までコードを進めることができます。自動化の一部として、開発チームは、コードをテスト環境にデプロイする際にスクリプト化された自動テストを実行するセキュリティツールを含める必要があります。このテストには、脆弱性やパブリックエンドポイントを確認する、アプリケーションの機能に対する単体テストを含める必要があります。テストによって、意図したアクセスだけを許可することができます。

動的アプリケーションセキュリティテスト

従来のウォーターフォール型開発モデルでは、セキュリティは運用環境に移行する直前の最後の段階で導入されるのが一般的でした。最も一般的なセキュリティアプローチの 1 つは、侵入テスト (ペンテスト) です。侵入テストでは、チームは攻撃者の視点に最も近い、ブラックボックスの視点でアプリケーションを見ることになります。

侵入テストにはいくつかのアクションポイントが含まれますが、そのうちの 1 つが動的アプリケーションセキュリティテスト (DAST) です。 DAST は、アプリケーションが特別に作成された要求に応答する方法を確認することで、実行中のアプリケーションでセキュリティの問題を見つける Web アプリケーションセキュリティテストです。 DAST ツールは、Web アプリケーション脆弱性スキャナーとも呼ばれます。 1 つの例は、オープンソースツールの OWASP Zed Attack Proxy (ZAP) です。これは、実行中の Web アプリケーション内の脆弱性を見つけます。 OWASP ZAP スキャンには、構成に応じてパッシブベースラインスキャンまたはフルスキャンなどのいくつかの方法があります。

侵入テストのデメリットは、時間がかかることです。徹底的な侵入テストには数週間かかることもあり、DevOps 開発のスピードを考えると、それほどの時間を確保するのは現実的ではありません。とはいえ、開発プロセスにより簡易的な侵入テストを追加して、SAST やその他の手順で見落とした問題を見つけることには価値があります。 OWASP ZAP のような DAST ツールが役立ちます。

開発者は、OWASP ZAP をタスクとしてパイプラインに統合します。実行中に、OWASP ZAP スキャナーがコンテナー内で起動してスキャンを行い、結果を発行します。このアプローチは徹底的な侵入テストではないため完ぺきではないかもしれませんが、それでも価値はあります。セキュリティ態勢を改善するための、開発サイクルにおいて品質を確保するもう 1 つの手段となります。

クラウド構成の検証とインフラストラクチャのスキャン

アプリケーションのコードのスキャンとセキュリティ保護を行うのと同時に、アプリケーションをデプロイする環境がセキュリティで保護されていることを確認する必要があります。セキュリティで保護された環境は、迅速に行動し、イノベーションを起こし、新しい技術を使いたい組織にとって重要です。セキュリティで保護された環境は、チームが実験のための新しい環境を迅速に作成するのにも役立ちます。

Azure の機能を活用すると、組織は Azure Policy など、環境のセキュリティに関する標準を作成することができます。チームは、Azure Policy を使用してポリシーセットを作成できます。ポリシーセットは、特定の種類のワークロードや、パブリック IP アドレスなどの構成アイテムを作成できないようにします。これらの "ガードレール" を使用すると、チームは安全で制御された環境内で実験を行い、イノベーションとガバナンスのバランスを取ることができます。

DevOps が開発者と運用の足並みを揃える方法の 1 つは、既存のインフラストラクチャを、コードとしてのインフラストラクチャアプローチに変換することをサポートすることです。

コードとしてのインフラストラクチャ (IaC) は、記述型モデルでのインフラストラクチャ (ネットワーク、仮想マシン、ロードバランサー、接続トポロジ) の管理です。 IaC では、DevOps がソースコードに対して使用するのと同じバージョン管理モデルを使用します。同じソースコードからは同じバイナリが生成されるという原則と同様に、IaC モデルが適用されるたびに同じ環境が生成されます。 IaC は継続的デリバリーで使用される主要な DevOps 手法です。

DevSecOps ではセキュリティをシフトレフトしており、セキュリティがアプリケーションだけを対象としたものではなく、インフラストラクチャのセキュリティでもあることを示しています。 DevSecOps がインフラストラクチャのセキュリティをサポートする方法の 1 つは、インフラストラクチャをクラウドにデプロイする前のセキュリティスキャンを含めることです。インフラストラクチャがコードになるため、アプリケーションセキュリティと同じセキュリティアクションを、インフラストラクチャにも適用します。選択する IaC 戦略に応じて、インフラストラクチャのセキュリティスキャンを実行するために使用できるセキュリティツールがあります。

クラウドを採用する際には、アプリケーションアーキテクチャの決定においてコンテナ化のアプローチを選択することが一般的です。一部のコンテナーリポジトリでは、イメージをスキャンして既知の脆弱性を持つパッケージを見つけます。それでも、コンテナーに最新ではないソフトウェアが含まれているというリスクがまだ残されています。このリスクのため、コンテナーをスキャンしてセキュリティリスクを確認する必要があります。この領域をターゲットにした、CD プロセスでの緊密な統合をサポートするオープンソースおよび商用のセキュリティツールが豊富にあります。このようなセキュリティツールを活用することで、チームはコードとしてのインフラストラクチャのための DevSecOps を採用でき、より具体的にはコンテナーの使用方法を学ぶことができます。

実稼働環境に移動して運用する

ソリューションを運用環境に移動した後も、セキュリティ状態の監視と管理を行うことは重要です。プロセスのこの段階では、クラウドインフラストラクチャとアプリケーション全体に焦点を当てる必要があります。

構成とインフラストラクチャのスキャン

クラウドサブスクリプションと、複数のサブスクリプションをまたぐリソース構成を把握するには、AzSK チームが提供する Azure テナントセキュリティソリューションをご利用ください。

Azure には、監視とセキュリティの機能が含まれています。これらの機能は、調査や場合によっては修復を必要とする、異常なイベントや構成を検出してアラートを出します。 Microsoft Defender for Cloud と Microsoft Sentinel は、Azure 環境にネイティブに統合されたファーストパーティツールです。これらの技術は、環境およびコードのセキュリティツールを補完します。また、徹底的なセキュリティ監視を提供して、組織が迅速かつ安全な方法で実験やイノベーションを行えるようにします。

侵入テスト

侵入テストは、攻撃者が悪用できる弱点が含まれる可能性があるインフラストラクチャやアプリケーション構成の脆弱性を確認する、推奨されるプラクティスです。

多くの製品やパートナーが、侵入テストサービスを提供しています。 Microsoft では、Azure での侵入テストに関するガイダンスを提供しています。

一般的なテストには、次の種類のテストが含まれます。

脆弱性を検出するためのエンドポイントのテスト
エンドポイントのファジーテスト (不正な形式の入力データを指定してプログラムエラーを検出する)
エンドポイントのポートスキャン

アクション可能なインテリジェンス

このガイダンスで説明されているツールとテクニックは、成長を続けてイノベーションを促進するために新しい技術を試したいと望む組織に対して、包括的なセキュリティモデルを提供します。 DevSecOps の重要な要素は、データドリブン、イベントドリブンなプロセスです。このようなプロセスは、潜在的なリスクを特定、評価し、それに対応するのに役立ちます。多くの組織は、アラートや使用に関するデータを IT サービスマネジメント (ITSM) プラットフォームに統合することを選択します。チームは、その同じ構造化されたワークフローをセキュリティイベントに適用して、他のインシデントやリクエストのために使用しています。

フィードバックループ

これらのすべての手法とツールを使用すると、チームは調査と場合によっては解決を必要とするリスクと脆弱性を見つけてフラグを設定できます。アラートを受け取る運用チーム、またはサポートチケットを調査するときに問題を発見する可能性のある運用チームには、項目にフラグを設定してレビューを行うために開発チームに戻すルートが必要です。問題に迅速に対処し、脆弱性のリスクを可能な限り最小限に抑えるためには、スムーズで協調的なフィードバックループが不可欠です。

フィードバックのための一般的なパターンは、それを Azure DevOps や GitHub などの開発者の作業を管理するシステムに統合することです。組織は、開発者が計画を立ててアクションを起こせるように、アラートやインシデントを作業項目にリンクできます。このプロセスは、開発、テスト、リリースなど、標準ワークフロー内の問題を開発者が解決するための効果的な方法を提供します。