パイプラインと CI/CD ワークフローの保護

  • [アーティクル]

この記事では、CI/CD パイプラインとワークフローをセキュリティで保護する方法について説明します。

自動化とアジャイル手法を使用すると、チームはより早く提供できるようになりますが、ワークフローが開発者チーム自体にまで及ぶため、セキュリティの複雑さが増します。

次の図は、ベースライン CI/CD ワークフローを示しています。 赤い構成アイコン は、顧客が構成しなければならないセキュリティのアクセス許可を示します。 これは、Azure や他のベンダーがアクセス許可を提供し、顧客がガバナンス モデルやビジネス要件に応じて構成しなければならないという、共同責任モデルに従ったものです。

Git リポジトリのコード変更がクラウド リソースに与える影響を示す典型的な CI/CD ワークフロー

この典型的なワークフローの各ステージを詳しく見て、構成が多くの場合、相互に依存していることを理解していきましょう。 実際のワークフローでは、ステージの数がより多い場合があります。 次の概念は、CI/CD を理解し、セキュリティのためにワークフローを設計するのに役立ちます。

ステージ 1: Git ワークフロー

ソフトウェアだけでなく、Pipeline as Code や Infrastructure as Code など、コードの変更は Git に保存され、管理されます。 Git は、分散型のソース コード管理ソフトウェアです。 コードがローカル コンピューターから集中管理された Git サーバーにプッシュされると、受け入れられる前にビジネス ルールを適用できます。

pull request とコラボレーション

ソフトウェア構成管理 (SCM) サービスとしてのソフトウェア (SaaS) ベンダーに関係なく、業界標準のワークフローでは、pull requests が使用されています。これは、自動化された品質ゲート キーパーとして、またソース コードが受け入れられる前の手動承認ステップとして機能します。

この pull request のワークフローは、健全な摩擦が生じるように設計されているため、セキュリティが確保されている特定の Git ブランチのにのみ適用する必要があります。 特に、デプロイ、構成、または他の方法でクラウド リソースに影響を与える自動化されたワークフローをトリガーするブランチが該当します。 これらのブランチは保護されたブランチと呼ばれ、一般的には production や releases/* のような名前付け規則に従います。

pull request では、以下のことが要求されるのが一般的です。

  • ピア レビュー
  • 継続的インテグレーション (CI) ビルドの通過
  • 手動承認

要件が満たされていれば、コードの変更が承認され、統合することができます。

保護されたブランチへのアクセスを制限する

pull request のワークフローは、制限付きのアクセス制御と共に使用されます。 しかし、保護されたブランチを直接変更することを拒否するようサーバーが設定されている場合を除き、pull request のワークフローを実行することはできません。

開発者は直接 production ブランチにプッシュすることはできず、代わりに、保護されたブランチを対象とする pull request を作成する必要があります。 保護されたブランチへのアクセスを制限する方法は、SCM ベンダーごとに異なります。 例えば、GitHub の場合、この機能は GitHub Team または GitHub Enterprise クラウドを利用している組織でのみ利用できます。

Git アクセス モデルを文書化する

コラボレーション モデルは複雑で、多くの可動部分があるため、コード変更によってデプロイをトリガーできる可能性があるすべての方法を文書化した表を作成すると便利です。以下に例を示します。

ブランチ名 PR の必要有無 デプロイ 開発者のアクセス 管理者アクセス
feat/* いいえ いいえ 読み取り/書き込み 読み取り/書き込み
main はい ステージング Read 読み取り/書き込み
production はい。main からのみ Production Read 読み取り/書き込み

この Git アクセスの表の例は、用途の説明用なため非常に単純化されています。 実際には、より多くのアクター、より多くのデプロイメント ターゲット、そして異なるユース ケースで実行される複数のパイプラインが存在することがよくあります。 表の構造は、組織の要件やワークロードに応じて異なる場合があります。

この表は、次のような質問に答えるのに役立ちます。

  • 開発者がコードの変更をブランチ X にプッシュした場合、デプロイされるかどうか。 その場合、どの環境に対してなのか。
  • アプリケーション コード ライフサイクルのどの時点で、脆弱性スキャンを行うのか。
  • セキュリティの脆弱性が見つかった場合、運用環境に導入するまでに何回コード プッシュを行い、認証を得る必要があるのか。

この表は、デバッグや静的な文書化だけでなく、チームのコラボレーションにも役立ちます。 コードの品質とセキュリティを優先するために、ワークフローに健全な摩擦が導入されていることが開発者には明らかになります。 さらに重要なことは、コードの変更が運用環境に到達するまでの予想される経路が、開発者に示されることです。

DevOps はプロセスであるため、Git のアクセス モデルは固定的なものではありません。 チームがそれぞれのリズムを見つけ、成熟していくにつれて、Git のアクセス モデルは変化し、進化していきます。 だからこそ、このドキュメントをできるだけコードの近く、たとえば Git リポジトリに保管することが重要になります。

pull request と保護されたブランチの詳細については、以下を参照してください。

ステージ 2: Pipeline as Code

pipeline-as-code のムーブメントは、パイプラインの定義と構成を CI ベンダーから開発者に移し、ビルドとデプロイのロジックを対応するアプリケーション ロジックに近づけることで、自動化の導入とデプロイを加速させました。 しかしこの大きな柔軟性にも、大きな責任が伴います。

UI 駆動型のパイプラインでは、RBAC コントロールにより、個々のユーザーが破壊的な変更を行うことを防ぐことができます。 しかし、Pipeline as Code は、しばしば特権 ID で実行されるため、指示があればワークロードを破壊することも可能になっています。

ステージ 3: デプロイ資格情報をセキュリティで保護する

パイプラインやとコード リポジトリには、ハードコードされた資格情報やシークレットを含めるべきではありません。 資格情報とシークレットは他の場所に格納し、セキュリティのために CI ベンダーの機能を使用する必要があります。 パイプラインはヘッドレス エージェントとして実行されるため、個人のパスワードを使用してはいけません。 パイプラインは、サービス プリンシパルやマネージド ID など、ヘッドレスのセキュリティ プリンシパルを使用して実行する必要があります。 このセキュリティ プリンシパルの資格情報、データベース接続文字列、およびサードパーティの API キーへのアクセスも、CI プラットフォームで安全に管理する必要があります。

資格情報のセキュリティ保護、ゲート、および承認の方法は、ベンダー固有の機能です。 CI プラットフォームを選択する際には、必要な機能がすべてサポートされていることを確認してください。

Azure Pipelines は、エンタープライズ規模の継続的インテグレーション ソリューションであり、資格情報はサービス接続として保存され、それに基づいて承認やチェックを構成することができます。 この構成には、手動承認や特定のブランチまたはパイプラインの承認が含まれます。

Azure Key Vault

使用する CI プラットフォームでサポートされている場合は、Azure Key Vault などの専用シークレット ストアに資格情報を格納することを検討してください。 資格情報はビルド エージェントによって実行時にフェッチされるため、攻撃面が減少します。

ステージ 4: Azure リソースのセキュリティ保護

Azure リソースは、アクセス許可とスコープの両方に適用される最小特権の原則に従ってセキュリティで保護する必要があります。

詳細については、次を参照してください。

ビルド エージェントのカスタム ロールを作成する

CI/CD 自動化は、アプリケーションだけでなくインフラストラクチャにも適用されます。 Infrastructure as Code (IaC) テンプレートは、一貫性のあるデプロイを実現し、集中管理されたクラウド プラットフォーム チームを拡張する際に役立ちます。

IaC の自動化がうまくいかない可能性があることを理解しておくことは重要です。 構成を間違えたり、最悪の場合はインフラストラクチャが完全に削除される場合もあります。 クラウドの導入を計画する際には、どの操作がビジネス クリティカルで人の介入を必要とするかを事前に特定します。

例えば、データのようなビジネス クリティカルなリソースには、削除不可の管理ロックをかけるなどです。 このような事態を防ぐために、CI オートメーションで使用するサービス プリンシパルから Microsoft.Authorization/*/Delete の権限を "削除" することができます。 この例およびユースケースでは、サービス プリンシパルで管理ロックを "作成" することはできますが、削除することはできません。

そのため、CI エージェント用のカスタム ロールを作成することをお勧めします。 ビルド エージェントはヘッドレスで動作し、ヘッドレスのエージェントには頭脳がないことを忘れないでください。 お客様に付与するアクセス許可は、慎重に選択してください。

詳細については、以下をご覧ください。

リソース

次のステップ

DevOps をセキュリティで保護する方法を理解したところで、DevOps から Azure へのエンドツーエンドのガバナンスについて詳しく説明します。

DevOps から Azure までのエンドツーエンドのガバナンス