LabHub

ブログ

クラウドセキュリティ 2026 完全ガイド - Zero Trust・SBOM/SLSA・CSPM/CNAPP・Wiz・Falco・Sigstore・Vault・Tailscale・Cloudflare 徹底解説

2026-05-16 · 26 分で読めます · #cloud-security#zero-trust#sbom#slsa#cspm#cnapp#wiz#falco#sigstore#vault#tailscale#cloudflare-zero-trust#supply-chain#devsecops

한국어English日本語

はじめに — 2026年5月、クラウドセキュリティは「サプライチェーン+ランタイム」が中心になった

2024年3月のXZ Utilsバックドア(CVE-2024-3094)は、クラウドセキュリティの中心テーマを一夜にして変えた。「ファイアウォールを置けば大丈夫」という時代は終わり、これからはビルド時点で入り込む悪性コードと、ランタイムで起こる異常挙動こそが本当の脅威だ。2026年5月時点の市場もこの流れに沿っている。Wizは2025年中盤にGoogle買収交渉から方向転換し、自社で200億ドル超のIPOを目指す方向に切り替えた。TailscaleはアイデンティティベースのメッシュVPNでシリーズCの評価額14億ドルに到達し、SigstoreはCNCFのGraduated段階に達した。

本稿はマーケティングのマトリックスではない。「2026年プロダクションクラウドセキュリティスタックの7レイヤー」を正直に描く。Zero Trustネットワークアクセス(ZTNA)、CSPM/CNAPP、SBOM/SLSAサプライチェーン、ランタイムセキュリティ、シークレット/PAM、IaC/ポリシー・アズ・コード、そしてガバナンス/コンプライアンスまで、実際の設定例とともに比較する。

クラウドセキュリティ2026スタック — 7レイヤーに分解する

まず全体像から。2026年の標準的なクラウドセキュリティスタックは次の7レイヤーに分かれる。

  1. ネットワーク / Zero Trust(ZTNA): VPN代替、アイデンティティベースのマイクロセグメンテーション
  2. クラウド姿勢管理(CSPM/CNAPP): 誤設定されたクラウドリソースの検出、コンテナイメージとランタイムまで一画面で
  3. サプライチェーンセキュリティ(SBOM/SLSA): ビルド成果物の出所、完全性、依存関係の可視化
  4. ランタイムセキュリティ: コンテナ/ノード上の異常syscall検知
  5. シークレット / PAM / IGA: パスワード、APIキー、証明書、権限のライフサイクル
  6. IaC + ポリシー・アズ・コード: Terraform/K8sマニフェストの段階のガードレール
  7. ガバナンス / コンプライアンス: ISMS-P、SOC 2、NIS2、GDPR、韓国個人情報保護法、日本APPI

各レイヤーを1〜2つのツールで担っていた時代は終わった。サプライチェーン事故はZTNAポリシーで止まらず、ランタイム事故はCSPMスコアでは捕まらない。統合プラットフォーム(CNAPP)の流れが加速した理由だ。以下、レイヤーごとに見ていく。

Zero Trustネットワークアクセス(ZTNA) — VPNの緩やかな終焉

Zero Trustの本質は一行に集約できる。「ネットワーク上の位置を信頼しない」だ。すべての要求はユーザーのアイデンティティ、デバイス姿勢、コンテキストに基づいて検証される。2026年5月の市場は次のように分かれている。

選定基準はシンプルだ。グローバルエッジ vs セルフホスト vs メッシュアイデンティティの3軸。Cloudflareがグローバルエッジの標準、Tailscaleがメッシュアイデンティティの標準、OpenZiti/Boundaryがセルフホスト陣営の代表となる。

Tailscale ACL — コード型ネットワークポリシーの標準例

Tailscale ACLはJSONファイル1つでデバイス、ユーザー、タグ、ポート単位のアクセスを制御する。実際のACL例。

{
  "tagOwners": {
    "tag:prod-db":   ["group:sre"],
    "tag:dev-web":   ["group:devs"],
    "tag:bastion":   ["group:sre"]
  },
  "groups": {
    "group:sre":  ["alice@example.com", "bob@example.com"],
    "group:devs": ["carol@example.com", "dave@example.com"]
  },
  "acls": [
    { "action": "accept", "src": ["group:sre"],  "dst": ["tag:prod-db:5432", "tag:bastion:22"] },
    { "action": "accept", "src": ["group:devs"], "dst": ["tag:dev-web:80,443"] }
  ],
  "ssh": [
    { "action": "accept", "src": ["group:sre"], "dst": ["tag:bastion"], "users": ["root", "ubuntu"] }
  ],
  "nodeAttrs": [
    { "target": ["group:sre"], "attr": ["funnel"] }
  ]
}

このACLの価値はPRレビュー可能なネットワークポリシーである点だ。Gitにプッシュし、Slack上でレビューし、マージで反映。従来のファイアウォールルールにおける「Excelシートベースの変更管理」はもう答えにならない。

CSPMからCNAPPへ — Wiz、Orca、Prisma Cloudの統合戦争

CSPM(Cloud Security Posture Management)は元々「誤設定されたS3バケットを見つける」が主だった。2026年にはその役割がCNAPP(Cloud-Native Application Protection Platform)に移った。一つのプラットフォームでIaCスキャン→ビルド→レジストリ→ランタイム→データまでを一気通貫で見るという流れだ。

選定基準はエージェントレス vs エージェントベース、マルチクラウドの深さ、IaC統合。Wizがエージェントレスの標準、Sysdig/Aquaがエージェントベースのランタイム陣営の強者、Snykが開発者フレンドリーの代表だ。

SBOMの時代 — CycloneDXとSPDX、そして米国大統領令14028

SBOM(Software Bill of Materials)は2021年の米国大統領令14028以後、すべての連邦調達ソフトウェアの必須成果物となった。2024年にNIST SP 800-218(SSDF)が2.0に改訂されSBOM要件がより具体化され、2025年にはEU NIS2と韓国のISMS-P認証の付属ガイドもSBOM義務化の流れに合流した。日本のMETIも2024年8月に「OSS活用時のSBOM作成ガイド」v2.0を公開した。

事実上の標準は2つ。

生成ツールも事実上4つに収束する。

CycloneDX JSON SBOMの最小形は次のとおり。

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "version": 1,
  "metadata": {
    "timestamp": "2026-05-16T09:00:00Z",
    "tools": [{ "vendor": "Anchore", "name": "syft", "version": "1.20.0" }],
    "component": {
      "type": "application",
      "name": "checkout-api",
      "version": "1.42.0"
    }
  },
  "components": [
    {
      "type": "library",
      "name": "express",
      "version": "4.21.2",
      "purl": "pkg:npm/express@4.21.2"
    },
    {
      "type": "library",
      "name": "left-pad",
      "version": "1.3.0",
      "purl": "pkg:npm/left-pad@1.3.0"
    }
  ]
}

SBOMの価値は単純だ。新しいCVEが出たとき、影響範囲を5分以内に答えられるか。Log4Shell、XZ Utils、そして2025年のnpmタイポスクワッティング騒動で、SBOMを持つ組織と持たない組織の差は時間単位ではなく日単位で表れた。

SLSAフレームワークとin-toto — ビルド由来証明の標準

SLSA(Supply-chain Levels for Software Artifacts)はOpenSSFが主導するビルド完全性フレームワークだ。2026年現在、v1.0が安定段階、v1.1がRC。中核は4段階のレベル。

最も一般的なprovenanceフォーマットはin-toto attestationだ。predicate typeごとにSLSA provenance、SBOM、Vuln、SCAIなどを標準化する。2025年にIETF SCITT(Supply Chain Integrity, Transparency, and Trust)WGがSBOM/attestation透明性サービスのRFC草案を公開し、2026年第1四半期にWG Last Callに入った。

標準的なin-toto provenanceの例。

{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [{
    "name": "ghcr.io/acme/checkout-api",
    "digest": { "sha256": "abc123def456..." }
  }],
  "predicateType": "https://slsa.dev/provenance/v1",
  "predicate": {
    "buildDefinition": {
      "buildType": "https://slsa-framework.github.io/github-actions-buildtypes/workflow/v1",
      "externalParameters": {
        "workflow": {
          "ref": "refs/tags/v1.42.0",
          "repository": "https://github.com/acme/checkout-api",
          "path": ".github/workflows/release.yml"
        }
      }
    },
    "runDetails": {
      "builder": { "id": "https://github.com/actions/runner/v2" },
      "metadata": { "invocationId": "https://github.com/acme/checkout-api/actions/runs/12345" }
    }
  }
}

Sigstore — 署名、透明性ログ、キーレスの標準

Sigstoreは2021年にLinux Foundation傘下でスタートし、2024年にCNCFのGraduated段階に達したサプライチェーン署名プロジェクトだ。3つのコンポーネントから構成される。

中核はキーレス署名だ。開発者は秘密鍵を保存する必要がなく、OIDC IDトークン(GitHub Actions、Google、Microsoft)でFulcioに署名要求を送り、Fulcioが短期X.509証明書を発行する。署名はRekorに記録され、Rekorはマークルツリーで改竄を防ぐ。

cosignの典型的なフロー。

# 1) キーレス署名 (GitHub Actions OIDC)
cosign sign \
  --identity-token "$ACTIONS_ID_TOKEN" \
  ghcr.io/acme/checkout-api@sha256:abc123def456

# 2) SBOMをattestationとして添付
cosign attest \
  --predicate sbom.cdx.json \
  --type cyclonedx \
  ghcr.io/acme/checkout-api@sha256:abc123def456

# 3) 検証 (デプロイ時)
cosign verify \
  --certificate-identity "https://github.com/acme/checkout-api/.github/workflows/release.yml@refs/tags/v1.42.0" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
  ghcr.io/acme/checkout-api@sha256:abc123def456

2024年のXZ Utilsバックドア以後、GitHub Actions、GitLab CI、npm、PyPIが急速にSigstore統合を進めている。npmは2023年からnpm publish --provenanceでSigstore provenanceを発行しており、2026年第1四半期時点でトップ1000パッケージのうち60%以上がprovenanceを持つ。

GUAC — SBOMのグラフデータベース

SBOMとattestationを集めたら、次の問いは「どう検索するか」だ。1万のマイクロサービスに散らばるSBOMをgrepするのは答えにならない。GUAC(Graph for Understanding Artifact Composition)が2023年に登場した理由だ。

典型的な質問例。

GUACは2026年5月にv1.0 GAを控えており、Kusariが商用マネージドサービスを提供している。Dependency-Track(OWASP)がSBOMインデックス陣営のもう一つの主要選択肢だ。

Trivyイメージスキャン — 最も使われるOSSスキャナ

TrivyはAqua Securityが作ったOSSスキャナで、コンテナイメージ、ファイルシステム、Gitリポジトリ、K8sマニフェスト、Terraformなどを1ツールで見る。2026年5月時点でGitHubスター23k、Kubernetes陣営の事実上の標準だ。

# イメージスキャン (CVE + ライセンス + シークレット + 誤設定)
trivy image \
  --severity HIGH,CRITICAL \
  --ignore-unfixed \
  --format sarif \
  --output trivy.sarif \
  ghcr.io/acme/checkout-api:v1.42.0

# SBOM生成 (CycloneDX)
trivy image \
  --format cyclonedx \
  --output sbom.cdx.json \
  ghcr.io/acme/checkout-api:v1.42.0

# Terraformポリシー検査
trivy config ./infra/terraform

# Kubernetesクラスタ姿勢
trivy k8s --report summary cluster

代替陣営も堅実だ。Grype(Anchore)はSyftと組み合わせてSBOMファーストワークフローの標準、Snyk Containerは開発者UX優先、Anchore Enterpriseはポリシーエンジンの強者。OSV-Scanner(Google)はOSV.devデータセットベースで正確なマッチングが強み。

ランタイムセキュリティ — Falco vs Tetragon、eBPFの時代

ランタイムセキュリティは「すでにデプロイされたコンテナ内で起こる異常挙動」を見る。2026年5月時点で2つの陣営に分かれる。

FalcoルールはYAMLで書く。「コンテナ内でシェルが起動した」を捉えるルール例。

- rule: Terminal Shell In Container
  desc: A shell was spawned by a container with an attached terminal.
  condition: >
    spawned_process and container
    and shell_procs and proc.tty != 0
    and container_entrypoint and not user_expected_terminal_shell_in_container_conditions
  output: >
    A shell was spawned in a container with an attached terminal
    (user=%user.name container_id=%container.id container_name=%container.name
     shell=%proc.name parent=%proc.pname cmdline=%proc.cmdline)
  priority: NOTICE
  tags: [container, shell, mitre_execution]

Tetragonは類似のポリシーをポリシー・アズ・コード(K8s CRD)で書き、さらにLSMフックで遮断まで行う。Falcoが検知陣営の標準、Tetragonが検知+遮断陣営の新星だ。

シークレット管理 — Vault、Doppler、Infisical

シークレットはセキュリティで最もよくある事故ポイントだ。2024年のGitGuardian "State of Secrets Sprawl"レポートによれば、GitHub公開リポジトリで露出したシークレットは1290万件、2025年には1740万件に増加した。ツールの選択肢は次のとおり。

PAM(Privileged Access Management) / IGA(Identity Governance & Administration)は別市場だ。

Vault動的シークレット — 静的シークレットの終わり

Vaultの核となる価値は「シークレットを事前に作っておかず、必要時に発行する」だ。PostgreSQLのユーザー/パスワードを要求ごとに新規発行し、TTL終了時に自動失効させる。

# vaultサーバ設定 (HCL)
storage "raft" {
  path    = "/vault/data"
  node_id = "vault-1"
}

listener "tcp" {
  address       = "0.0.0.0:8200"
  tls_cert_file = "/etc/vault/tls/cert.pem"
  tls_key_file  = "/etc/vault/tls/key.pem"
}

seal "awskms" {
  region     = "ap-northeast-2"
  kms_key_id = "alias/vault-unseal"
}

api_addr     = "https://vault.internal:8200"
cluster_addr = "https://vault.internal:8201"
ui           = true

# 1) DBシークレットエンジン有効化
vault secrets enable database

# 2) PostgreSQL接続登録
vault write database/config/checkout-db \
  plugin_name=postgresql-database-plugin \
  allowed_roles="readonly,readwrite" \
  connection_url="postgresql://{{username}}:{{password}}@db.internal:5432/checkout" \
  username="vault-admin" \
  password="$ADMIN_PW"

# 3) ロール定義 (TTL 1時間)
vault write database/roles/readonly \
  db_name=checkout-db \
  creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \
  default_ttl="1h" \
  max_ttl="24h"

# 4) ユーザー発行
vault read database/creds/readonly

発行されたユーザーはTTL終了とともに自動で失効する。シークレットがGit、wiki、Slackに漏れても1時間後には無効になる。これがZero Trustシークレットモデルの本質だ。

IaCスキャン — Checkov、tfsec、KICS、Terrascan

Terraform/CloudFormation/K8sマニフェストはビルド成果物だが、同時に「コード」でもある。コードはスキャンできる。

Checkovの実行は一行で済む。

checkov -d ./infra/terraform \
  --framework terraform \
  --output sarif \
  --output-file-path checkov.sarif \
  --skip-check CKV_AWS_79

代表的な誤設定パターン3つ。

この3つは、ほぼすべての事故報告書の1、2、3番目だ。

ポリシー・アズ・コード — OPA Gatekeeper、Kyverno、Conftest、Cedar

K8sクラスタに入るすべてのリソースをadmission webhookの段階で検証するのがポリシー・アズ・コードの流れだ。

OPA Regoで「すべてのデプロイはリソースlimitsを持つこと」を強制するポリシー。

apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8srequiredresources
spec:
  crd:
    spec:
      names:
        kind: K8sRequiredResources
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8srequiredresources
        violation[{"msg": msg}] {
          container := input.review.object.spec.template.spec.containers[_]
          not container.resources.limits.cpu
          msg := sprintf("container %v missing cpu limits", [container.name])
        }
        violation[{"msg": msg}] {
          container := input.review.object.spec.template.spec.containers[_]
          not container.resources.limits.memory
          msg := sprintf("container %v missing memory limits", [container.name])
        }

Kyvernoの同じポリシーは短い。YAML 1ファイルで済む。「OPAは表現力、Kyvernoは可読性」という定説は2026年も有効だ。

シークレットスキャニング — gitleaks、truffleHog、GitGuardian

コード/コミット/イメージに露出したシークレットを見つけるレイヤー。

運用フローはpre-commit+CI+定期スキャン(週次full-history)の三重だ。

SAST/DASTとSCA — GitHub Advanced Security、Snyk、FOSSA、Mend

コード自体を見るSAST(Static)、実行中のアプリを見るDAST(Dynamic)、オープンソース依存を見るSCA(Software Composition Analysis)は別市場だ。

2026年の流れは単純だ。GitHubに自然に統合されるツールを使うか、Snykのようなマルチ-VCSツールを使うか、どちらかだ。

CSPM/CNAPPツールマトリックス — 2026年5月時点

選定の実用基準を表で整理する。

ツールエージェントマルチクラウドIaC統合ランタイムCIEM価格(SMB→Ent)
WizエージェントレスAWS/Azure/GCP/OCI強Wiz Defend強中上
Orca SecurityエージェントレスAWS/Azure/GCP中中強中上
Prisma Cloud両方AWS/Azure/GCP/OCI/Alibaba強強強上
Sysdig SecureエージェントAWS/Azure/GCP中非常に強い(Falco)中中
Aqua SecurityエージェントAWS/Azure/GCP強強中中上
Snyk CloudエージェントAWS/Azure/GCP強弱中中
Defender for CloudエージェントAzure優先中中中値打ち
AWS Security Hubn/aAWSのみ弱n/an/a無料+従量
GCP SCCn/aGCPのみ弱n/an/a無料+Premium
Lacework FortiCNAPPエージェントAWS/Azure/GCP中中中中
Tenable Cloud SecurityエージェントレスAWS/Azure/GCP中弱非常に強い中

選定は既存のEDR/SIEMとの統合、マルチクラウドの深さ、価格、エージェントレスへの選好で絞り込む。

ZTNAツール比較 — グローバルエッジ vs メッシュ vs セルフホスト

ZTNAも同じ要領で整理する。

ツールモデル無料ティアアイデンティティ統合セルフホスト強み
Cloudflare Zero Trustグローバルエッジ50席Okta/Google/Azure/GitHub一部(Tunnel)グローバルPOP、エッジキャッシュ
TailscaleメッシュP2P100デバイスOkta/Google/Azure/GitHubHeadscaleアイデンティティ、UX、ACL
Twingateゲートウェイ2名/5リソースOkta/Google/Azure/GitHub一部エージェントレス、価格
Zscaler ZPASASEなしSAML/OIDCなしエンタープライズPoC
NetskopeSASEなしSAML/OIDCなしDLP/CASB統合
Palo Alto Prisma AccessSASEなしSAML/OIDCなしNGFW統合
OpenZitiメッシュ100% OSSSAML/OIDCフルセルフホスト
HashiCorp BoundaryブローカーOSS + EntOIDC/LDAPフルVault直結

Cloudflare Zero Trust + Tailscaleの組み合わせは2026年のSMBの標準解だ。Cloudflareが外部→内部のSaaS/アプリアクセス、Tailscaleが内部→内部のデバイス/サービスメッシュ。

韓国 / 日本 / EUコンプライアンス — 2026年の変化

法規制側も急速に動いている。

耐量子暗号(PQC) — 2026年のスタートライン

2024年8月にNISTがML-KEM(鍵交換)、ML-DSA(署名)、SLH-DSA(ハッシュベース署名)の3アルゴリズムを標準として確定した。2026年5月時点の状況。

CRAのSBOM義務化とPQC移行は2026〜2028年の間に並行して進む。SBOMに「このライブラリがどの暗号プリミティブを使うか」を記録するCBOM(Cryptographic Bill of Materials)がCycloneDX 1.6に追加された理由だ。

2025年npmタイポスクワッティング騒動とサプライチェーン脅威マップ

2025年の1年間にnpm陣営で発生した主要サプライチェーン事故。

対応の標準は単純だ。lockfile + 完全性ハッシュ + Sigstore検証 + 変更隔離ビルド。加えてnpmは2026年1月から--require-provenanceフラグをデフォルト有効化する方向を発表した。

標準ビルドパイプライン — 2026年の「安全なビルド」の絵

最後にすべてをまとめた標準パイプラインを整理する。

  1. PR段階: gitleaks、Snyk Code/CodeQL、Checkov、dependency review action
  2. ビルド段階: hermeticコンテナビルド、SLSA L3ビルダー(GitHub-hosted runner + reusable workflow)
  3. 成果物段階: cosignキーレス署名、SBOM添付(CycloneDX)、SLSA provenance attestation
  4. レジストリ: GHCR/ECRのimmutable tag、Sigstore署名ポリシー
  5. デプロイ段階: K8s admission webhook(OPA/Kyverno)が署名+provenanceなしで拒否
  6. ランタイム段階: Falco/Tetragonルール、CSPM(Wiz/Sysdig)が姿勢+driftを監視
  7. 事故対応: SBOMインデックス(GUAC/Dependency-Track)で影響範囲を5分以内に回答

この7段階をすべて備える組織は2026年5月時点でグローバルトップ1%程度だ。ただし1〜3段階はOSSだけで可能で、4〜6段階はクラウドネイティブ+CNAPP1つでまかなえる。

おわりに — 2026年クラウドセキュリティの一行まとめ

2026年のクラウドセキュリティのエッセンスは一行に凝縮される。「ファイアウォールの内側で起こることのほうが怖い」。XZ Utilsバックドアはビルド時点で入り込み、2025年のnpmタイポスクワッティングは依存ツリーの奥深くで起きた。そしてSBOMを持たない組織は誰一人として影響範囲を即答できなかった。

答えはシンプルだ。

ツールは揃い、標準も整い、残るは実行だけだ。

References

原文を読む: https://www.youngju.dev/blog/culture/2026-05-16-cloud-security-zero-trust-sbom-slsa-cspm-wiz-falco-sigstore-vault-2026-deep-dive.ja

コメント

まだコメントはありません。

ログインするとコメントできます