infra-security

Infrastructure-as-Code セキュリティスキャナー

このスキルを使うと、モデルをクラウドセキュリティ監査担当として活用できます。IaC を読み、危険な設定ミスを見つけ、それぞれの重要度と具体的な修正方法を報告します。分析はすべてディスク上のファイルを対象に実行されます。稼働中のクラウドも、認証情報も、apply も必要ありません。

ルールには、CIS Benchmarks、AWS Well-Architected、Kubernetes Pod Security Standards、および tfsec／trivy、checkov、kube-score、cfn-nag などのツールに含まれるチェックの合意事項が反映されています。別のスキャナーを新たに組み込むのではなく、ソースを読み取って適用します。

仕組み：2 つのステージ

このスキルは、skill-security と同じように、意図的に 2 つのステージに分かれています。

• ステージ 1 — スキャナー（決定論的、機械的）。 scripts/scan.py が、高速で再現率の高い処理を実行します。対象を走査し、各ファイルの形式を判別して、テキストから明確に判断できる設定ミス（ポート 22 の 0.0.0.0/0、Action: "*"、privileged: true、runAsUser: 0、パブリック読み取り可能な S3 ACL）を行単位の検出器で見つけます。オフラインで動作し、依存関係はありません。純粋な Python 標準ライブラリだけを使い、pip install、hcl2、pyyaml は不要です。file:line 形式の検出結果と、CI で使いやすい終了コードを出力します。
• ステージ 2 — あなた（意味的な判断）。 スキャナーは 影響範囲 や 代替のセキュリティ対策 を考慮できません。しかし、あなたにはできます。検出されたリソースを IaC の他の部分と合わせて読み、スキャナーでは判断できない点を見極めます。0.0.0.0/0 は実際に到達可能なのか、それとも WAF の背後にあるのか。そのワイルドカード IAM ポリシーはインターネットに公開されたインスタンスにアタッチされており、P1 を P0 に引き上げるものなのか。「設定漏れ」とされた暗号化は、モジュール内の別の箇所でデフォルト設定されているのか。ステージ 1 で候補を見つけたら、あなたが影響を確認し、誤検出を除外し、正規表現では見つけられない判断が必要な設定ミス（最小権限の不足、リソースの 欠落、リソース間の連鎖）も検出します。

このスキャナーは、意図的に適合率より再現率を重視しています。file:line の位置情報は信頼しつつ、重要度と妥当性は自分で判断してください。

考え方

設定ミスのリスクは、チェックリストの項目ではなく、露出度 × 影響範囲です。

• 露出度 — 攻撃者が到達できるかどうかです。インターネットに公開されている（0.0.0.0/0、パブリック ACL、パブリックサブネット）状態は、最もリスクが高い入口です。内部のみで、プライベートサブネットや認証プロキシの背後にある場合は、リスクがはるかに低くなります。
• 影響範囲 — 到達された場合、何が影響を受けるかです。踏み台サーバーのワイルドカード IAM ポリシーは問題ですが、すべての Lambda が引き受けるロールに同じポリシーが設定されていれば、乗っ取りにつながります。一時利用のバケットで暗号化が無効なら P3 ですが、PII を保管するバケットなら P1 です。

同じ文字列パターンでも、この 2 つの軸によって P0 にも P3 にもなります。だからこそ、スキャナーが候補を提示し、あなたが判断するのです。IaC だけでは影響範囲を本当に判断できない場合は、その旨を伝え、前提を明記したうえで保守的に評価してください。

ワークフロー

次の 3 つのフェーズを順番に実行します。

フェーズ 1 — 検出と取り込み

対象に対してスキャナーを実行し、検出候補とファイルの一覧を取得します。

python3 scripts/scan.py <target-dir> --format markdown

ファイルは拡張子と内容の一部から判別されます。

• Terraform — .tf、.tfvars、.hcl
• CloudFormation／SAM — AWSTemplateFormatVersion または AWS::* 型の Resources: マップを含む .yaml／.yml／.json
• Kubernetes／Helm — apiVersion: と kind: を含む .yaml／.yml（複数ドキュメントのストリームは --- で分割）
• Docker — Dockerfile*、docker-compose*.yml

検出結果を独自の推論処理にプログラムで取り込む場合は --format json を使用します。対象を絞り込むには --severity P0,P1 を指定します。P0／P1 が 1 件でもある場合、スキャナーは 1 で終了するためパイプラインのゲートとして利用でき、それ以外の場合は 0 で終了します。

フェーズ 2 — カテゴリ別の評価

スキャナーの候補を確認し、周辺の IaC を読みます。references/controls.md のカテゴリを順に確認し、影響を確かめながら、スキャナーでは検出できない判断が必要な見落としを探します。

• ID とアクセス管理（IAM） — Action／Resource のワイルドカード、リソースポリシー内の * プリンシパル、コンピューティングリソースにアタッチされた過剰な権限を持つロール、最小権限の欠如、ハードコードされた認証情報。
• ネットワークとファイアウォール — 機密性の高いポート（22、3389、3306、5432、6379、27017、9200）への 0.0.0.0/0 からのアクセス、パブリックサブネット内のデータベース、不要なアウトバウンド通信の開放、インターネットに公開されたエンドポイントでの WAF の欠如。
• ストレージとデータ — パブリックな S3 ACL／ポリシー、保存時の暗号化の無効化（S3／EBS／RDS／DynamoDB）、機密バケットでのバージョニング／ログ記録の無効化、パブリックなスナップショット。
• コンピューティングとコンテナ — 特権コンテナ、root としての実行、readOnlyRootFilesystem の欠如、hostNetwork／hostPID／hostIPC の使用、Docker ソケットのマウント、リソース制限の欠如。
• シークレットと暗号化 — 変数／環境変数／ConfigMap 内の平文のシークレット、TLS の欠如、ワイルドカードを含む KMS キーポリシー。
• ログ記録とモニタリング — CloudTrail／Config／VPC Flow Logs の無効化、ログの保持期間または暗号化の欠如。
• サプライチェーン — :latest タグのイメージ、または信頼できないレジストリのイメージ、ピン留めされていない git／HTTP ソースを参照する Terraform モジュール。

各候補で判断の決め手となるのは、次の考え方です。どのような露出があり、その影響範囲はどれほどか。 これによって、単なるパターン一致が深刻度を評価した検出事項になります。

フェーズ 3 — 報告と修正

確認された検出事項ごとに、次の情報を提示します。

• 深刻度（P0～P3。references/severity-rubric.md を参照）
• リソースおよび file:line
• 現在のコード — 問題のあるコードをそのまま記載
• 修正後のコード — 修正したコード（パターンは references/remediation-playbook.md を参照）
• 根拠 — 露出と影響範囲を 1～2 文で説明
• コンプライアンス対応付け — 該当する場合、SOC-2／PCI-DSS／ISO-27001 の管理策 ID
• 工数 — Quick Fix／Moderate／Complex

references/report-template.md のレポートにこれらをまとめます。既定の保存先：./infra-audit-report-<timestamp>.md。

検出事項の形式

インラインで報告する場合（ドキュメント全体ではない場合）は、次の形式を使用します。深刻度ごとにまとめ、P0 を先頭にします。

[P0] network-ssh-world-open in infra/sg.tf:24
  aws_security_group.web allows 0.0.0.0/0 to port 22. Any host on the
  internet can reach SSH; combined with the public subnet on this SG,
  the blast radius is full shell access to the instance.

  Current:
    ingress {
      from_port   = 22
      to_port     = 22
      cidr_blocks = ["0.0.0.0/0"]
    }

  Fix (scope to the bastion / VPN CIDR, or use SSM Session Manager):
    ingress {
      from_port   = 22
      to_port     = 22
      cidr_blocks = [var.admin_cidr]   # e.g. ["10.0.0.0/16"]
    }

ユーザーがパスを指定せずにコードスニペットを貼り付けた場合は、「このリソース」と記載し、スニペット内の行番号を使用します。深刻度の根拠として、露出と影響範囲の両方を必ず明記してください。

深刻度の尺度

概要のみです。完全な基準、デプロイリスクの評価、工数の尺度については references/severity-rubric.md を参照してください。

• P0 Critical — インターネットから直ちに悪用可能で、影響範囲が大きいもの：認証されていないデータの露出、またはインフラの乗っ取り。デプロイをブロックします。
• P1 High — 権限昇格、ラテラルムーブメント、または重大なデータ露出（P0 に至るまでの前提条件があと 1 つの場合が多い）。マージ前にオーナーのレビューが必要です。
• P2 Medium — 多層防御の不足で、特定の条件下で悪用可能なもの。技術的負債として追跡します。
• P3 Low — 直接悪用される可能性はないものの、ベストプラクティスからの逸脱、またはコンプライアンス上の不備があるもの。
• Informational — アーキテクチャ上の推奨事項またはドキュメントに関する注記。単独ではセキュリティ上の影響はありません。

問題が見つからない場合

すべてのカテゴリを確認し、該当するものがなければ、次のようにします。

1. その旨を明確に伝えます。「標準の管理策セットに対する検出事項はありません。」
2. 確認していない項目を記載します：実際のクラウドの状態とドリフト（デプロイ済みリソースがこの IaC と異なる可能性があります）、評価済み IAM 権限（スキャナーが読み取るのはポリシーの ドキュメント であり、実効アクセスグラフではありません）、実行時のコンテナの動作、IaC の外部から注入されるシークレット、スキャン対象のツリーに含まれていないモジュール／チャート内のすべての内容。
3. デプロイ済みの環境との照合をユーザーに推奨します。IaC を確認して問題が見つからなくても、稼働中のインフラが安全であるとは証明できません。

安全性とガードレール

1. ファイルに対しては読み取り専用です。 問題を「検証」するために、terraform apply／plan -out、kubectl apply、helm install、aws cloudformation deploy、docker build/run を実行してはいけません。このスキルが分析するのは IaC テキストのみです。
2. 認証情報を使ったアクセスは禁止です。 問題の確認のために、~/.aws/credentials、~/.kube/config、環境変数内のシークレットを読んだり、クラウド API を呼び出したりしてはいけません。
3. まず決定論的なルールを適用します。 重大度の判断は references/controls.md に基づきます。モデルの判断を用いるのは、影響範囲、誤検知の抑制、根拠の説明であり、ルールを独自に作るためではありません。
4. 誤検知を減らします。 問題のあるパターンが存在し、かつ同じスコープ内で補完的な制御が確認できない場合に限り、問題を報告します（例：明示的な aws_s3_bucket_public_access_block、暗号化を設定するデフォルト値、開放ポートの前段にある WAF）。スキャン対象のツリー外に補完的な制御が存在する可能性がある場合は、その前提を記載します。
5. シークレットを伏せます。 IaC に有効なシークレットが含まれている場合、レポートにそのまま記載せず、伏せ字にしてください。

トリガーフレーズ

Audit this Terraform for security issues: <dir>
Review these Kubernetes manifests before deploy: <dir>
Check this CloudFormation for public S3 buckets: <file>
Is this security group open to the internet?
Is this container running as root / privileged?
Pre-deployment security review of this IaC: <dir>
What's the blast radius if this Terraform is wrong?

参照ファイル

• references/controls.md — 制御カタログです。各ルールの固定 ID、カテゴリ、重大度、問題のあるパターンと望ましいパターン、および SOC-2／PCI-DSS／ISO-27001 との対応を記載しています。確認対象と評価方法を把握するため、フェーズ 2 で参照してください。
• references/severity-rubric.md — P0～P3 と情報提供の定義、隣接するレベル間の選び方、デプロイリスクの評価、および作業量の尺度を記載しています。スコアリングの際に参照してください。
• references/remediation-playbook.md — よくある設定ミスについて、修正前から修正後への変更例、根拠、および正しく見えるが実際には問題があるケースを記載しています。問題点を挙げるだけでなく、修正方法を作成する際に参照してください。
• references/report-template.md — 監査レポートの出力構成を記載しています。最終文書を作成する際に参照してください。

このスキルが行わないこと

• terraform apply、kubectl apply を実行したり、何かをデプロイしたり、クラウド認証情報を読み取ったりしません。監査では、モデルが IaC と標準ライブラリのスキャナーを読み取ります。
• pip install、Docker、ネットワークアクセスを必要としません。スキャナーは標準ライブラリのみで動作します。形式を判別するのに実際のパーサーが必要な場合は、モデルがファイルを直接読み取ります。
• リテラルパターンだけをもとに問題の重大度を評価することはありません。重大度は露出度と影響範囲によって決まるため、同じパターンでも P0 から P3 まで異なる評価になります。
• ランタイムのセキュリティ態勢を評価するツール（CSPM）や、実環境の IAM アクセス分析ツールの代わりにはなりません。IaC がデプロイされる前に確認するものであり、設定のドリフトや、デプロイ済みアカウントの実効的な権限グラフは確認できません。
• 「安全」とは断言しません。「この制御セットに対する問題は見つかりませんでした」と、ファイルの読み取りでは確認できない内容を示すにとどまります。