mcpField
I
iac-security

iac-security

github.com/vinayaklattheセキュリティ17842 回インストール19 週間前に更新
リポジトリ

iac-security について

Bicep、ARM、Terraform を使う Azure の IaC パイプラインを計画・強化するスキルです。デプロイ前のスキャン、ポリシーゲート、パイプラインID、サプライチェーン制御を扱います。

主な機能

  1. 01OIDC によるパイプラインIDの設定
  2. 02IaC とシークレットのスキャン計画
  3. 03Azure Policy のデプロイゲート設定
  4. 04Bicep と Terraform のワークフロー強化
  5. 05インフラのドリフト検出

活用シーン

  1. 01パイプラインのシークレットを OIDC 連携に置き換え
  2. 02プルリクエストで IaC 設定を検査
  3. 03デプロイ前に Azure Policy の拒否ルールを評価
  4. 04Terraform の状態ドリフトを定期検出

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/vinayaklatthe/microsoft-security-skills --skill iac-security

インストール後、Claude Code で/iac-securityを入力して読み込まれたか確認します。

詳細

Azure での Infrastructure-as-Code セキュリティ

現在、クラウド侵害の多くは、コードによってプロビジョニングされた設定ミスのあるインフラストラクチャを経由して発生しています。IaC パイプライン（Bicep、ARM、Terraform、およびそれらを実行する CI/CD）を強化すれば、デプロイ前の段階にセキュリティ対策を移せます。これにより、設定ミスを、3 週間後に Defender for Cloud の検出結果として発覚するのではなく、PR レビュー時に検出できます。

使用する場面

Azure 向けの IaC パイプライン（GitHub Actions / Azure DevOps / GitLab）の設計や強化を行う場合。スキャン、ポリシー・アズ・コード、パイプラインの ID、サプライチェーンの制御が対象です。

このスキルを使用しないでください：K8s のアドミッションコントロールのみを対象とする場合（defender-for-containers）、一般的な CI/CD アーキテクチャ、またはアプリケーション層のセキュリティ。

機能スタック

レイヤー機能
パイプラインの IDOIDC フェデレーション（クライアントシークレットなし）、Workload Identities Premium
コミット前 / PR 時のスキャンMicrosoft Security DevOps（MSDO）Action / Extension、Bicep リンター、tflint、checkov、trivy、シークレットスキャン
ポリシー・アズ・コードのゲートデプロイ時の Audit モードと Deny モードの Azure Policy、az policy what-if による CI 評価、Terraform azapi ポリシープレビュー
セキュリティ態勢への接続GitHub / Azure DevOps 用の Defender for Cloud DevOps Security コネクター
ドリフト検出Defender for Cloud、スケジュールされた CI での Terraform plan、AKS 上の GitOps コントローラー（Flux/ArgoCD）
サプライチェーン署名付きコミット、依存関係レビュー、アーティファクト署名（Notation/cosign）、許可されたモジュールレジストリ

アプローチ

  1. パイプラインのシークレットを OIDC フェデレーションに置き換えます。 最新の Azure CI 統合はすべて、フェデレーションされたワークロード ID に対応しています。

    • GitHub Actions → Azure：ユーザー割り当て MI にフェデレーション資格情報を設定します。AZURE_CREDENTIALS JSON シークレットは不要です。
    • Azure DevOps → Azure：Workload Identity フェデレーションのサービス接続を使用します。 フェデレーション資格情報は特定の環境／ブランチ（repo:org/repo:* ではなく environment:prod）に固定します。entra-workload-identity を参照してください。

  2. パイプライン ID のスコープを最小限にします。 パイプラインごとにサービスプリンシパル／MI を用意し、サブスクリプションの Owner ではなく、RG／リソースのスコープでロールを割り当てます。影響範囲を制限するため、デプロイメントスタック（Bicep）を使用します。

  3. Microsoft Security DevOps（MSDO）Action／Extension を導入します。 オープンソースのスキャナー（template-analyzer、checkov、terrascan、trivy、bandit、ESLint security）と、シークレットスキャン（CredScan）がバンドルされています。統合ポイントを一本化し、重大な検出結果があれば PR を失敗させます。

  4. Bicep 固有の対策。

    • CI で bicep build と bicep lint を実行します。
    • 共有パターンにはテンプレート仕様を使用し、バージョンを管理します。
    • denySettings を設定したデプロイメントスタックを使用し、人間がパイプライン外でスタックのリソースを変更できないようにします。
    • 署名済みモジュールを使用するモジュールレジストリ（プライベート ACR または Bicep レジストリ）を使用します。

  5. Terraform 固有の対策。

    • バックエンドの強化：Azure Storage に状態を保存し、プライベートエンドポイント、Customer Lockbox とスコープを限定した RBAC、論理削除、バージョン管理、ロックを設定します。
    • プロバイダーのバージョン固定（マイナーバージョンには ~>、セキュリティ上重要なものには正確なバージョンを指定します）。
    • CI で tflint と checkov を使用します。tfsec は非推奨となっており、trivy に置き換えられています。
    • レビュー担当者向けに terraform plan の成果物を PR に投稿します。Apply は承認後に実行します。
    • スケジュールされた terraform plan を現在の状態に対して実行し、ドリフトを検出します。

  6. Policy-as-code のゲート。 譲れない制御については、Azure Policy を**拒否（Deny）**モードで設定します。

    • VM にパブリック IP を割り当てない。
    • Storage／SQL／Key Vault にはプライベートエンドポイントを必須とする。
    • 暗号化、診断設定、タグを必須とする。 CI では az deployment what-if（Bicep／ARM）を実行するか、Get-AzPolicyComplianceForResource で Policy に照らして評価し、適用前に拒否モードによる失敗を検出します。

  7. シークレットの衛生管理。

    • プッシュのたびに CredScan／GitHub Advanced Security のシークレットスキャンを実行します。
    • .tfvars や parameters.json にシークレットを含めないでください。Key Vault の参照／GitHub Environments／シークレットとしてマークされたパイプラインの変数グループを使用します。
    • シークレットを含む PR をブロックします（プッシュ保護を有効にします）。
    • 過去に漏えいしたシークレットはローテーションします。git 履歴のクリーンアップは困難なため、シークレットを変更してください。

  8. サプライチェーン。

    • 可能な場合は、ダイジェストを使ってモジュールのバージョンを固定します（Bicep レジストリのダイジェスト、GitHub Action の SHA 固定）。
    • 許可するレジストリ：サブスクリプションに Azure Policy を設定し、コンテナー／Bicep モジュールの使用先をプライベートレジストリに制限します。
    • 署名済み成果物：コンテナーイメージには Notation／cosign を使用し、AKS のアドミッション制御で検証します（defender-for-containers）。

  9. Defender for Cloud DevOps Security。 GitHub／Azure DevOps を Defender for Cloud に接続します。

    • IaC の検出結果、シークレットスキャンの結果、コードスキャン、依存関係の脆弱性を、Defender for Cloud の単一ビューに集約します。
    • クラウドの検出結果と同様に、タグ付け、所有者の設定、優先順位付けを行います。
    • リポジトリ別／パイプライン別に、セキュリティ態勢の傾向を追跡します。

  10. ドリフト検出。 Policy と IaC を導入していても、人間による操作や ClickOps でドリフトが発生します。次の方法で検出します。

    • パイプラインで作成されていないリソースに対する、Defender for Cloud のセキュリティ態勢に関する検出結果。
    • 空でない差分を検出してアラートを出す、スケジュールされた Terraform plan ジョブ。
    • AKS クラスターでの GitOps（Flux／ArgoCD）による調整のアラート。

ガードレール

  • クラウドの認証情報を長期間有効なパイプラインシークレットとして保存しないでください。 常に OIDC フェデレーションを使用します。
  • パイプラインを Subscription Owner として実行しないでください。 スコープを厳密に制限し、封じ込めにはデプロイメントスタックを使用します。
  • 成熟段階で PR を critical のみで失敗させるのは寛容すぎます。 ベースラインのノイズを調整して除去したら、medium 以上に引き上げます。
  • Bicep の what-if はセキュリティレビューではありません。 変更を表示するものであり、セキュリティレビューではその内容を確認します。
  • Terraform の state ファイルにはシークレットが平文で含まれています。 バックエンドストレージの強化は必須です。
  • パイプライン間で provider "azurerm" { ... features {} } のバージョン指定が固定されずに変動するのを許容しないでください。 再現性はセキュリティです。
  • Azure Policy の Audit のみの運用は必要ですが、それだけでは不十分です。 重要な制御には Deny が必要です。
  • 必須レビュー担当者のいないブランチ保護では、IaC のマージを制御できません。 人によるレビューを必須にします。
  • MSDO は言語ごとのリンターに取って代わるものではありません。 併用します。
  • Defender DevOps Security にはコネクターと、各リポジトリの担当者が必要です。 そうしなければ、検出結果は放置されます。

よくあるアンチパターン

  • 「GitHub Actions でサービスプリンシパルのクライアントシークレットを使用する」 — 大半のパイプライン侵害を招く漏えいの原因です。
  • 「パイプラインの SP にサブスクリプションスコープの Contributor を付与する」 — たった一度のミスでサブスクリプション全体が停止します。
  • 「what-if を省略し、問題が起きるか確認するために Bicep を先にデプロイする」 — プレビューなしで本番環境を変更することになります。
  • 「Terraform の state をデフォルトのストレージアカウントのパブリックエンドポイントに保存する」 — シークレットが露出します。
  • 「CI スキャンがあるから」とプッシュ保護を無効にする — CI が検出する前に、シークレットが履歴に漏えいします。
  • 「アクションを @ main に固定する」 — サプライチェーンの侵害がそのまま入り込みます。検証済みの SHA またはタグに固定します。
  • 「プロバイダーバージョンをランダムにした Terraform」 — 同じコードでも結果が異なります。
  • 「誰も担当しない Defender DevOps Security の検出結果」 — 誰も担当しない Defender for Cloud の検出結果と同じです。
  • 「安定性のために本番環境で GitOps の調整を無効にする」 — ドリフトが見えなくなります。

プロンプトの例

  • GitHub Actions での Azure デプロイをすべて、クライアントシークレットを使うサービスプリンシパルから、環境に固定されたサブジェクトを使う OIDC フェデレーションに移行してください。
  • 80 個のリポジトリに Microsoft Security DevOps を導入し、medium 以上の深刻度の検出結果がある場合は PR をブロックしてください。
  • Azure DevOps と GitHub の組織を Defender for Cloud DevOps Security に接続し、リポジトリごとの担当者モデルを構築してください。
  • Terraform のバックエンドストレージを強化してください：プライベートエンドポイント、Customer Lockbox、RBAC、ソフト削除。
  • ランディングゾーンで必須となる要件に対して Azure Policy の deny モードポリシーを作成し、デプロイ前に PR 時点で評価してください。
  • 本番環境の影響範囲を分離するため、denySettings を指定した Bicep デプロイメントスタックを実装してください。
  • ドリフト検出パイプライン：Terraform plan の定期実行、Defender for Cloud の差分、アラートの振り分け。
  • サプライチェーンの強化：GitHub Actions を SHA に固定し、プライベートレジストリ内の Bicep モジュールに署名し、cosign でコンテナーイメージに署名してください。

Microsoft Learn

コメント

Markdown 対応