クラウドネイチE��ブアプリケーションにおけめE0の最重要セキュリチE��リスクとそ�E対策方法、E/p>
OWASP Cloud-Native Application Security Top 10は、Kubernetes、Docker、サーバ�EレスアーキチE��チャなどのプラチE��フォーム上で稼働するクラウドネイチE��ブアプリケーションにおける最も顕著なセキュリチE��リスクを特定してぁE��す。誤設定、サプライチェーンリスク、シークレチE��管琁E��ど、クラウドネイチE��ブスタチE��全体にわたる問題を網羁E��てぁE��す、E/p>
誤設定されたクラウドサービス、コンチE��、オーケストレーターは、クラウドネイチE��ブ侵害の主要な原因です。これには、コンチE��をrootとして実行すること、デフォルト設定�E使用、Kubernetes APIサーバ�Eの公開、クラウドリソースの監査ログ有効化失敗などが含まれます、E/p>
攻撁E��E�E誤設定を悪用してクラスタの完�Eな制御を取得し、コンチE��をエスケープし、クラウドメタチE�Eタサービスにアクセスしたり、インフラストラクチャ全体にピ�EチE��することができます。誤設定されたS3バケチE��めE�E開されたKubernetesダチE��ュボ�Eド一つで、大規模なチE�Eタ侵害につながった事例があります、E/p>
# Running container as root with no resource limits FROM ubuntu:latest RUN apt-get update && apt-get install -y curl wget COPY app /app # No USER directive Eruns as root! CMD ["/app/server"]
FROM gcr.io/distroless/static:nonroot COPY --chown=65534:65534 app /app USER 65534:65534 EXPOSE 8080 ENTRYPOINT ["/app/server"]
クラウドネイチE��ブアプリケーションは、従来のHTTPリクエストだけでなく、クラウドイベント！EQS、Pub/Sub、EventBridge�E�、サーバ�Eレストリガー、サービス間通信からも�E力を受け取ります。これらのベクターのぁE��れかでインジェクション欠陥が発生すると、コマンド実行、データ流�E、また�E権限�E格につながる可能性があります、E/p>
クラウドイベントによってトリガーされるサーバ�Eレス関数は、検証なしで信頼できなぁE��ータを�E琁E��る可能性があり、OSコマンドインジェクション、NoSQLインジェクション、また�Eイベント駁E��型SSRFにつながります。攻撁E��E�EメチE��ージキューめE��ベントバスを汚染して、下流�Eサービスを侵害することができます、E/p>
# Lambda function processing S3 event without sanitizing filename import os def handler(event, context): bucket = event['Records'][0]['s3']['bucket']['name'] key = event['Records'][0]['s3']['object']['key'] # Command injection via crafted filename! os.system(f"aws s3 cp s3://{bucket}/{key} /tmp/{key}")
import boto3, re from urllib.parse import unquote_plus def handler(event, context): s3 = boto3.client('s3') bucket = event['Records'][0]['s3']['bucket']['name'] key = unquote_plus(event['Records'][0]['s3']['object']['key']) # Validate key against allowlist pattern if not re.match(r'^[\w\-./]+$', key): raise ValueError(f"Invalid S3 key: {key}") # Use SDK instead of shell commands s3.download_file(bucket, key, f'/tmp/{key.split("/")[-1]}')
クラウドネイチE��ブ環墁E�E、褁E��のアイチE��チE��チE��レイヤーを含みます：クラウドIAM、Kubernetes RBAC、サービスメチE��ュmTLS、アプリケーションレベルの認証。いずれか�Eレイヤーで誤設定されたり過度に許可皁E��ポリシーがあると、横展開、権限�E格、機寁E��ソースへの不正アクセスを許してしまぁE��す、E/p>
ポッドに割り当てられた過度に許可皁E��IAMロールは、ワークロードにクラウドアカウント�E体へのアクセスを許可する可能性があります。サービス間認証の欠如により、侵害された�EチE��が他�Eサービスになりすますことができます、E/p>
# Overly permissive ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: default-admin subjects: - kind: ServiceAccount name: default # Default SA Eshared by all pods! namespace: default roleRef: kind: ClusterRole name: cluster-admin # Full cluster access! apiGroup: rbac.authorization.k8s.io
# Dedicated ServiceAccount with minimal Role apiVersion: v1 kind: ServiceAccount metadata: name: order-service namespace: production annotations: eks.amazonaws.com/role-arn: arn:aws:iam::123456:role/order-svc --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: order-service-role namespace: production rules: - apiGroups: [""] resources: ["configmaps"] verbs: ["get"]
CI/CDパイプラインは、本番環墁E��の書き込みアクセスを持つため、価値の高いターゲチE��です。ビルドパイプラインの侵害により、サプライチェーン攻撁E��悪意�Eあるコード�E注入、バチE��ドア付きイメージのチE�Eロイが可能になります。安�EでなぁE��イプライン設定、汚染された�Eースイメージ、署名されてぁE��ぁE��ーチE��ファクトがこ�Eリスクに貢献します、E/p>
侵害されたCI/CDパイプラインは、すべての環墁E��悪意�EあるコードをチE�Eロイし、パイプライン変数に保存されたシークレチE��を突E��したり、コンチE��イメージを改ざんすることができます。SolarWindsスタイルの攻撁E�E、サプライチェーン侵害の壊滁E��な影響を示してぁE��す、E/p>
# Insecure CI pipeline Eunpinned actions, no image signing name: Deploy on: push jobs: deploy: runs-on: ubuntu-latest steps: - uses: actions/checkout@main # Unpinned Ecould be compromised! - run: | docker build -t myapp:latest . docker push myregistry/myapp:latest # No signing! kubectl apply -f deploy.yaml # No admission control!
name: Secure Deploy on: push permissions: id-token: write jobs: deploy: runs-on: ubuntu-latest steps: - uses: actions/checkout@a5ac7e51b41094c92402da3b24376905380afc29 # Pinned SHA - run: | docker build -t myregistry/myapp:${{ github.sha }} . cosign sign myregistry/myapp:${{ github.sha }} # Sign image - run: trivy image myregistry/myapp:${{ github.sha }} --exit-code 1 - run: kubectl apply -f deploy.yaml # Admission controller verifies signatures
APIキー、データベ�Eス賁E��惁E��、TLS証明書などのシークレチE��は、ソースコードにハ�Eドコードされたり、平斁E�EConfigMapに保存されたり、コンチE��イメージに埋め込まれることが多くあります、Eubernetes SecretsはチE��ォルトでbase64エンコードされてぁE��だけで暗号化されてぁE��ぁE��め、最小限の保護しか提供しません、E/p>
露出したシークレチE��は、攻撁E��E��チE�Eタベ�Eス、クラウドアカウント、サードパーチE��サービスへの直接アクセスを与える可能性があります。git履歴、コンチE��レイヤー、環墁E��数冁E�EシークレチE��は容易に発見され悪用されます、E/p>
# Secrets in plaintext environment variables apiVersion: v1 kind: Pod metadata: name: my-app spec: containers: - name: app env: - name: DB_PASSWORD value: "SuperSecret123!" # Plaintext in manifest! - name: AWS_SECRET_KEY value: "AKIA..." # Cloud credentials in YAML!
# Use External Secrets Operator with a vault backend apiVersion: external-secrets.io/v1beta1 kind: ExternalSecret metadata: name: my-app-secrets spec: refreshInterval: 1h secretStoreRef: name: vault-backend kind: ClusterSecretStore target: name: my-app-secrets data: - secretKey: db-password remoteRef: key: secret/data/myapp property: db-password
チE��ォルトでは、Kubernetesはすべてのポッドが制限なく相互に通信することを許可します。欠落してぁE��か過度に許可皁E��NetworkPolicies、セキュリチE��グループ、ファイアウォールルールは、クラスタ冁E��よ�Eクラウドサービス間�E横展開を可能にします、E/p>
ネットワークセグメンチE�EションがなぁE��、侵害された�EチE��がクラスタ冁E�E他�Eサービスに到達し、データベ�Eスに直接アクセスしたり、外部エンド�EイントにチE�Eタを流�Eさせることができます。フラチE��なネットワークは、あらゆる侵害の影響篁E��を増幁E��せます、E/p>
# No NetworkPolicy Eall pods can talk to everything apiVersion: v1 kind: Namespace metadata: name: production # No NetworkPolicy resources defined # All ingress and egress traffic is allowed by default
# Default-deny all traffic, then allow only what's needed apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-all namespace: production spec: podSelector: {} policyTypes: ["Ingress", "Egress"] --- apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-frontend-to-api namespace: production spec: podSelector: matchLabels: app: api-server ingress: - from: - podSelector: matchLabels: app: frontend ports: - port: 8080
クラウドネイチE��ブアプリケーションは、オープンソースのベ�Eスイメージ、ライブラリ、Kubernetesオペレーターに大きく依存してぁE��す。既知のCVEを持つ古ぁE��た�Eパッチ未適用のコンポ�Eネントを実行すると、文書化されたエクスプロイトにアプリケーションを晒すことになります。コンチE��イメージには数百のパッケージが含まれることが多く、それぞれが潜在皁E��脁E��性となります、E/p>
ベ�Eスイメージの既知の脁E��性�E�例：Log4Shell、OpenSSLのバグ�E��E、�E開されてぁE��チE�Eルを使用して悪用できます。攻撁E��E�E脁E��なバ�Eジョンを実行してぁE��コンチE��を積極皁E��スキャンしてぁE��す。パチE��未適用のライブラリ一つで、ワークロード�E体が侵害される可能性があります、E/p>
# Using outdated base image with known CVEs FROM node:14 # EOL version with known vulns COPY package.json . RUN npm install # No audit, no lockfile verification COPY . . CMD ["node", "server.js"]
# Use current, slim base image with vulnerability scanning FROM node:22-slim AS build WORKDIR /app COPY package.json package-lock.json ./ RUN npm ci --only=production # Reproducible install from lockfile RUN npm audit --audit-level=high # Fail on high+ vulns FROM gcr.io/distroless/nodejs22-debian12 COPY --from=build /app /app CMD ["/app/server.js"]
クラウドネイチE��ブ環墁E��は、リソースのスピンアチE�Eは簡単ですが、追跡は困難です。孤立したコンチE��、忘れられたネームスペ�Eス、古ぁE��ラウドリソース、シャド�EITチE�Eロイメント�E、管琁E��れてぁE��ぁE��撁E��象領域を作り出します。適刁E��賁E��インベントリがなぁE��、セキュリチE��チ�Eムは存在を知らなぁE��のを保護できません、E/p>
忘れられたまた�E管琁E��れてぁE��ぁE��ソースは、古ぁE��フトウェアを実行し、セキュリチE��監視が欠けており、古ぁE��E��惁E��を持ってぁE��ことが多いです。攻撁E��E�E、監視やパッチE��用される可能性が低いため、これらの放置された賁E��をエントリーポイントとして狙います、E/p>
# Resources created without tagging or lifecycle management resource "aws_instance" "test_server" { ami = "ami-0abcdef1234567890" instance_type = "t3.medium" # No tags Ewho owns this? What's it for? # No lifecycle policy Eruns forever } resource "aws_s3_bucket" "temp_data" { bucket = "temp-data-2024" # No expiration, no access logging }
resource "aws_instance" "test_server" { ami = "ami-0abcdef1234567890" instance_type = "t3.medium" tags = { Name = "test-server" Owner = "platform-team" Environment = "staging" ManagedBy = "terraform" ExpiresAt = "2026-04-30" } } resource "aws_s3_bucket" "temp_data" { bucket = "temp-data-2024" tags = { Owner = "data-team" ManagedBy = "terraform" } lifecycle_rule { enabled = true expiration { days = 90 } } }
適刁E��リソースクォータと制限がなぁE��、単一の誤動作また�E侵害されたワークロードが、利用可能なすべてのCPU、メモリ、ストレージを消費し、他�Eアプリケーションにサービス拒否を引き起こす可能性があります。リソース制限�EなぁE��墁E��は、特にクリプトジャチE��ング攻撁E��一般皁E��す、E/p>
攻撁E��E�E、すべてのクラスタリソースを消費する暗号通貨マイニングコンチE��めE��ソース雁E��E��なワークロードをチE�Eロイできます。制限がなぁE��、フォーク爁E��めE��モリリークが一つのポッドでノ�Eド�E体をクラチE��ュさせ、�E存するすべてのワークロードに影響を与える可能性があります、E/p>
# Pod with no resource limits apiVersion: v1 kind: Pod metadata: name: my-app spec: containers: - name: app image: myapp:latest # No resources block Ecan consume unlimited CPU/memory!
apiVersion: v1 kind: Pod metadata: name: my-app spec: containers: - name: app image: myapp:1.2.3 resources: requests: cpu: "100m" memory: "128Mi" limits: cpu: "500m" memory: "512Mi" --- # Namespace-level quota apiVersion: v1 kind: ResourceQuota metadata: name: compute-quota namespace: production spec: hard: requests.cpu: "10" requests.memory: "20Gi" limits.cpu: "20" limits.memory: "40Gi"
クラウドネイチE��ブ環墁E�E、褁E��のレイヤーにわたってログを生成します：アプリケーション、コンチE��ランタイム、オーケストレーター、サービスメチE��ュ、クラウド�EラチE��フォーム。集中ログ記録、これらのレイヤー間�E相関、実行時脁E��検�EがなぁE��、セキュリチE��インシチE��ト�E検�EされなぁE��、発見が遁E��ぎることになります、E/p>
エフェメラルコンチE��は終亁E��にログを失ぁE��フォレンジチE��証拠を破壊します、Eubernetes監査ログと実行時監視がなぁE��、攻撁E��E�Eアラートをトリガーすることなく、バチE��ドアを作�Eし、権限を昁E��させたり、データを流�Eさせることができます、E/p>
# No audit policy, no log forwarding apiVersion: v1 kind: Pod metadata: name: my-app spec: containers: - name: app image: myapp:latest # Logs go to stdout only Elost when pod restarts # No audit logging configured on the cluster # No runtime security monitoring
# Kubernetes audit policy for security events apiVersion: audit.k8s.io/v1 kind: Policy rules: - level: RequestResponse resources: - group: "" resources: ["secrets", "configmaps"] - level: Metadata resources: - group: "rbac.authorization.k8s.io" resources: ["clusterroles", "clusterrolebindings"] - level: Metadata verbs: ["create", "delete", "patch"] # Deploy Falco for runtime threat detection # Forward logs to SIEM via Fluent Bit / Fluentd
| ID | 脁E��性 | 深刻度 | 主要な対筁E/th> |
|---|---|---|---|
| CNAS-1 | 安�EでなぁE��ラウチEコンチE��/オーケストレーション設宁E/td> | Critical | Distrolessイメージ、Pod Security Standards、IaCスキャン |
| CNAS-2 | インジェクションの欠陥�E�クラウドイベント！E/td> | Critical | 入力検証、シェルよりSDK、エグレスフィルタリング |
| CNAS-3 | 不適刁E��認証と認可 | Critical | 最小権限RBAC、IRSA、mTLS |
| CNAS-4 | CI/CDパイプラインとサプライチェーンの欠陥 | High | 固定SHA、イメージ署名、SLSA出自 |
| CNAS-5 | 安�EでなぁE��ークレチE��保管 | Critical | Vault/Secrets Manager、KMS暗号化、シークレチE��スキャン |
| CNAS-6 | 過度に許可皁E��ネットワークポリシー | High | チE��ォルト拒否、エグレス制限、Calico/Cilium |
| CNAS-7 | 既知の脁E��性を持つコンポ�EネンチE/td> | High | イメージスキャン、最小限のベ�Eスイメージ、SBOM |
| CNAS-8 | 不適刁E��賁E��管琁E/td> | Medium | リソースタグ付け、�E動クリーンアチE�E、IaC |
| CNAS-9 | 不十刁E��コンピュートリソースクォータ | Medium | リソース制限、ResourceQuotas、使用状況監要E/td> |
| CNAS-10 | 効果的でなぁE��グ記録と監要E/td> | High | 監査ログ、Falco/Sysdig、E��中型SIEM |