cloud-security について
cloud-security は、クラウド構成や IaC を評価するセキュリティ担当者向けのスキルです。IAM の権限昇格、ストレージの公開、ネットワークのリスクを検査し、重大度と修正案を示します。
主な機能
- 01IAM 権限昇格パスの検出
- 02S3 の公開設定と暗号化の評価
- 03セキュリティグループのリスク検出
- 04IaC 設定のレビュー
- 05重大度と修正案の提示
活用シーン
- 01デプロイ前のクラウド構成確認
- 02過剰な IAM ポリシーの調査
- 03公開状態の S3 バケットの発見
- 04CI/CD で危険な設定をブロック
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ alirezarezvani/ claude-skills --skill cloud-securityインストール後、Claude Code で/cloud-securityを入力して読み込まれたか確認します。
同梱ファイルreferences/cspm-checks.mdscripts/cloud_posture_check.py
詳細
クラウドセキュリティ
IAM 権限昇格、ストレージの公開、ネットワーク設定のリスク、Infrastructure as Code の設定ミスを検出するための、クラウドセキュリティ態勢評価スキルです。これは、進行中のクラウド侵害へのインシデント対応(incident-response を参照)や、アプリケーションの脆弱性スキャン(security-pen-testing を参照)を目的とするものではありません。悪用を防ぐため、クラウド設定を体系的に分析します。
目次
- 概要
- クラウド態勢チェックツール
- IAM ポリシー分析
- S3 の公開状態評価
- セキュリティグループ分析
- IaC セキュリティレビュー
- クラウドプロバイダー対応状況一覧
- ワークフロー
- アンチパターン
- 相互参照
概要
このスキルの機能
このスキルでは、**クラウドセキュリティ態勢管理(CSPM)**の方法論とツールを提供します。悪用可能な攻撃対象領域を生み出す設定ミスがないか、クラウド設定を体系的に確認します。IAM の権限昇格経路、ストレージの公開状態、ネットワーク権限の過剰設定、インフラストラクチャコードのセキュリティを対象とします。
他のセキュリティスキルとの違い
| スキル | 対象 | アプローチ |
|---|---|---|
| cloud-security(このスキル) | クラウド設定のリスク | 予防的 — 悪用される前に評価 |
| incident-response | 進行中のクラウドインシデント | 事後対応 — 確認済みのクラウド侵害をトリアージ |
| threat-detection | 振る舞いの異常 | 先制的 — クラウドログから攻撃者の活動を探索 |
| security-pen-testing | アプリケーションの脆弱性 | 攻撃的 — 発見した弱点を積極的に悪用 |
前提条件
JSON 形式の IAM ポリシードキュメント、S3 バケット設定、セキュリティグループルールへの読み取りアクセスが必要です。継続的な監視には、クラウドプロバイダーの API(AWS Config、Azure Policy、GCP Security Command Center)と連携してください。
クラウド態勢チェックツール
cloud_posture_check.py ツールは、iam(権限昇格)、s3(公開アクセス)、sg(ネットワークへの露出)の 3 種類のチェックを実行します。設定ファイルの構造からチェックの種類を自動検出するほか、明示的な --check フラグも指定できます。
# Analyze an IAM policy for privilege escalation paths
python3 scripts/cloud_posture_check.py policy.json --check iam --json
# Assess S3 bucket configuration for public access
python3 scripts/cloud_posture_check.py bucket_config.json --check s3 --json
# Check security group rules for open admin ports
python3 scripts/cloud_posture_check.py sg.json --check sg --json
# Run all checks with internet-facing severity bump
python3 scripts/cloud_posture_check.py config.json --check all \
--provider aws --severity-modifier internet-facing --json
# Regulated data context (bumps severity by one level for all findings)
python3 scripts/cloud_posture_check.py config.json --check all \
--severity-modifier regulated-data --json
# Pipe IAM policy from AWS CLI
aws iam get-policy-version --policy-arn arn:aws:iam::123456789012:policy/MyPolicy \
--version-id v1 | jq '.PolicyVersion.Document' | \
python3 scripts/cloud_posture_check.py - --check iam --json
終了コード
| コード | 意味 | 必要な対応 |
|---|---|---|
| 0 | 高または重大な検出事項なし | 対応不要 |
| 1 | 高重大度の検出事項あり | 24 時間以内に修正 |
| 2 | 重大な検出事項あり | 直ちに修正 — 進行中の場合は incident-response にエスカレーション |
IAM ポリシー分析
IAM 分析では、権限昇格経路、過剰な権限付与、公開プリンシパルへの露出、データ窃取のリスクを検出します。
権限昇格のパターン
| パターン | 重大度 | 主なアクションの組み合わせ | MITRE |
|---|---|---|---|
| Lambda PassRole による昇格 | 重大 | iam:PassRole + lambda:CreateFunction | T1078.004 |
| EC2 インスタンスプロファイルの悪用 | 重大 | iam:PassRole + ec2:RunInstances | T1078.004 |
| CloudFormation PassRole | 重大 | iam:PassRole + cloudformation:CreateStack | T1078.004 |
| ポリシーを自身にアタッチすることによる昇格 | 重大 | iam:AttachUserPolicy + sts:GetCallerIdentity | T1484.001 |
| インラインポリシーによる自己昇格 | 重大 | iam:PutUserPolicy + sts:GetCallerIdentity | T1484.001 |
| ポリシーバージョンを利用したバックドア | 重大 | iam:CreatePolicyVersion + iam:ListPolicies | T1484.001 |
| 認証情報の収集 | 高 | iam:CreateAccessKey + iam:ListUsers | T1098.001 |
| グループメンバーシップによる昇格 | 高 | iam:AddUserToGroup + iam:ListGroups | T1098 |
| パスワードリセット攻撃 | 高 | iam:UpdateLoginProfile + iam:ListUsers | T1098 |
| サービスレベルのワイルドカード | 高 | iam:* または s3:* または ec2:* | T1078.004 |
IAM 検出事項の重大度ガイド
| 検出事項の種類 | 条件 | 重大度 |
|---|---|---|
| 完全な管理者ワイルドカード | Action=* Resource=* | 重大 |
| パブリックプリンシパル | Principal: '*' | 重大 |
| 危険なアクションの組み合わせ | 2 つのアクションによる権限昇格経路 | 重大 |
| 個別の権限昇格アクション | ワイルドカードリソース上 | 高 |
| データ持ち出しアクション | * に対する s3:GetObject、secretsmanager:GetSecretValue | 高 |
| サービスのワイルドカード | service:* アクション | 高 |
| 名前付きリソースに対するデータアクション | 適切な範囲 | 低/問題なし |
最小権限に関する推奨事項
重大または高の検出事項ごとに、ツールは具体的な修正ガイダンスを示す least_privilege_suggestion フィールドを出力します。
Action: *を、必要なアクションの名前付きリストに置き換えるResource: *を、具体的な ARN パターンに置き換える- AWS Access Analyzer を使用して、実際に使用されている権限を特定する
- 危険なアクションの組み合わせを、異なる信頼ポリシーを持つ別々のロールに分ける
S3 の公開状態の評価
S3 の評価では、パブリックアクセスブロックの設定、バケット ACL、バケットポリシーのプリンシパルの公開範囲、デフォルトの暗号化という 4 つの観点を確認します。
S3 設定の確認マトリックス
| 確認項目 | 検出条件 | 重大度 |
|---|---|---|
| パブリックアクセスブロック | 4 つのフラグのいずれかが未設定または false | 高 |
| バケット ACL | public-read-write | 重大 |
| バケット ACL | public-read または authenticated-read | 高 |
| バケットポリシーの Principal | Allow で "Principal": "*" | 重大 |
| デフォルトの暗号化 | ServerSideEncryptionConfiguration がない | 高 |
| デフォルトの暗号化 | 標準外の SSEAlgorithm | 中 |
| PublicAccessBlockConfiguration なし | 状態不明 | 中 |
推奨される S3 ベースライン設定
{
"PublicAccessBlockConfiguration": {
"BlockPublicAcls": true,
"BlockPublicPolicy": true,
"IgnorePublicAcls": true,
"RestrictPublicBuckets": true
},
"ServerSideEncryptionConfiguration": {
"Rules": [{
"ApplyServerSideEncryptionByDefault": {
"SSEAlgorithm": "aws:kms",
"KMSMasterKeyID": "arn:aws:kms:region:account:key/key-id"
},
"BucketKeyEnabled": true
}]
},
"ACL": "private"
}
4 つすべてのパブリックアクセスブロック設定を、バケットレベルと AWS アカウントレベルの両方で有効にする必要があります。両方で強制されていない場合、アカウントレベルの設定はバケットレベルの設定で上書きされることがあります。
セキュリティグループの分析
セキュリティグループの分析では、管理ポート、データベースポート、またはインターネット CIDR(0.0.0.0/0、::/0)に対してすべてのトラフィックを公開するインバウンドルールを検出します。
重大なポート公開ルール
| ポート | サービス | 検出事項の重大度 | 修正方法 |
|---|---|---|---|
| 22 | SSH | 重大 | VPN CIDR に制限するか、AWS Systems Manager Session Manager を使用する |
| 3389 | RDP | 重大 | VPN CIDR に制限するか、AWS Fleet Manager を使用する |
| 0–65535(すべて) | すべてのトラフィック | 重大 | ルールを削除し、必要なポートのみを個別に追加する |
高リスクのデータベースポートルール
| ポート | サービス | 検出事項の重大度 | 修正方法 |
|---|---|---|---|
| 1433 | MSSQL | 高 | アプリケーション層の SG からのみ許可し、プライベートサブネットに移動する |
| 3306 | MySQL | 高 | アプリケーション層の SG からのみ許可し、プライベートサブネットに移動する |
| 5432 | PostgreSQL | 高 | アプリケーション層の SG からのみ許可し、プライベートサブネットに移動する |
| 27017 | MongoDB | 高 | アプリケーション層の SG からのみ許可し、プライベートサブネットに移動する |
| 6379 | Redis | 高 | アプリケーション層の SG からのみ許可し、プライベートサブネットに移動する |
| 9200 | Elasticsearch | 高 | アプリケーション層の SG からのみ許可し、プライベートサブネットに移動する |
重大度の修飾子
評価対象のリソースがインターネットから直接アクセス可能な場合(ロードバランサー、API ゲートウェイ、パブリック EC2)は、--severity-modifier internet-facing を使用します。リソースが PCI、HIPAA、または GDPR の規制対象データを扱う場合は、--severity-modifier regulated-data を使用します。どちらの修飾子も、各検出事項の重大度を 1 段階引き上げます。
IaC セキュリティレビュー
Infrastructure as Code のレビューでは、デプロイ前に定義時点で設定上の問題を検出します。
IaC チェックマトリクス
| ツール | チェックの種類 | 実行タイミング |
|---|---|---|
| Terraform | リソースレベルのチェック(aws_s3_bucket_acl、aws_security_group、aws_iam_policy_document) | plan 前、apply 前、PR ゲート |
| CloudFormation | テンプレートプロパティの検証(PublicAccessBlockConfiguration、SecurityGroupIngress) | テンプレートの lint、デプロイゲート |
| Kubernetes マニフェスト | コンテナの権限、ネットワークポリシー、シークレットの露出 | PR ゲート、アドミッションコントローラー |
| Helm チャート | Kubernetes と同じ | PR ゲート |
Terraform IAM ポリシーの例 — 問題ありと問題なし
# BAD: Will generate critical findings
resource "aws_iam_policy" "bad_policy" {
policy = jsonencode({
Version = "2012-10-17"
Statement = [{
Effect = "Allow"
Action = "*"
Resource = "*"
}]
})
}
# GOOD: Least privilege
resource "aws_iam_policy" "good_policy" {
policy = jsonencode({
Version = "2012-10-17"
Statement = [{
Effect = "Allow"
Action = ["s3:GetObject", "s3:PutObject"]
Resource = "arn:aws:s3:::my-specific-bucket/*"
}]
})
}
CSPM チェックの完全なリファレンス:references/cspm-checks.md
クラウドプロバイダー対応マトリクス
| チェックの種類 | AWS | Azure | GCP |
|---|---|---|---|
| IAM 権限昇格 | 完全対応(IAM ポリシー、信頼ポリシー、ESCALATION_COMBOS) | 部分対応(RBAC 割り当て、サービスプリンシパルのリスク) | 部分対応(IAM バインディング、ワークロード ID) |
| ストレージのパブリックアクセス | 完全対応(S3 バケットポリシー、ACL、パブリックアクセスブロック) | 部分対応(Blob SAS トークン、コンテナーのアクセスレベル) | 部分対応(GCS バケット IAM、均一なバケットレベルのアクセス) |
| ネットワークの公開 | 完全対応(Security Group、NACL、ポートレベルの分析) | 部分対応(NSG ルール、インバウンドポートの分析) | 部分対応(ファイアウォールルール、VPC ファイアウォール) |
| IaC スキャン | 完全対応(Terraform、CloudFormation) | 部分対応(ARM テンプレート、Bicep) | 部分対応(Deployment Manager) |
ワークフロー
ワークフロー 1:迅速なセキュリティ態勢チェック(20 分)
新たにプロビジョニングされたリソース、またはデプロイ前のレビューの場合:
# 1. Export IAM policy document
aws iam get-policy-version --policy-arn ARN --version-id v1 | \
jq '.PolicyVersion.Document' > policy.json
python3 scripts/cloud_posture_check.py policy.json --check iam --json
# 2. Check S3 bucket configuration
aws s3api get-bucket-acl --bucket my-bucket > acl.json
aws s3api get-public-access-block --bucket my-bucket >> bucket.json
python3 scripts/cloud_posture_check.py bucket.json --check s3 --json
# 3. Review security groups for open admin ports
aws ec2 describe-security-groups --group-ids sg-123456 | \
jq '.SecurityGroups[0]' > sg.json
python3 scripts/cloud_posture_check.py sg.json --check sg --json
判断:終了コード 2 の場合、デプロイをブロックして修正します。終了コード 1 の場合、24 時間以内に修正を予定します。
ワークフロー 2:クラウドセキュリティの完全評価(複数日)
1 日目 — IAM とアイデンティティ:
- 本番環境のロールにアタッチされたすべての IAM ポリシーをエクスポートします
- 各ポリシーに対して cloud_posture_check.py --check iam を実行します
- 見つかったすべての権限昇格経路をマッピングします
- 過剰な権限を持つサービスアカウントとロールを特定します
- アカウント間の信頼ポリシーをレビューします
2 日目 — ストレージとネットワーク:
- すべての S3 バケットを列挙し、設定をエクスポートします
- データバケットに対して cloud_posture_check.py --check s3 --severity-modifier regulated-data を実行します
- すべての VPC のセキュリティグループ設定をエクスポートします
- インターネットに公開されているリソースに対して cloud_posture_check.py --check sg を実行します
- ネットワーク分割の不備がないか、NACL ルールをレビューします
3 日目 — IaC と継続的インテグレーション:
- バージョン管理下の Terraform/CloudFormation テンプレートをレビューします
- CI/CD パイプラインに IaC セキュリティゲートがあることを確認します
references/cspm-checks.mdに照らして検出結果を検証します- 優先度順(Critical → High → Medium)に並べた修正計画を作成します
ワークフロー 3:CI/CD セキュリティゲート
設定ミスのあるリソースが本番環境に到達しないよう、セキュリティ態勢チェックをデプロイパイプラインに統合します:
# Validate IaC before terraform apply
terraform show -json plan.json | \
jq '[.resource_changes[].change.after | select(. != null)]' > resources.json
python3 scripts/cloud_posture_check.py resources.json --check all --json
if [ $? -eq 2 ]; then
echo "Critical cloud security findings — blocking deployment"
exit 1
fi
# Validate existing S3 bucket before modifying
aws s3api get-bucket-policy --bucket "${BUCKET}" | jq '.Policy | fromjson' | \
python3 scripts/cloud_posture_check.py - --check s3 \
--severity-modifier regulated-data --json
アンチパターン
- 権限昇格の組み合わせを確認せずに IAM 分析を実行する — 個別の高リスクアクションは、単独では低リスクに見えることがあります。危険なのは組み合わせです。
iam:PassRole単独では重大ではありませんが、iam:PassRole + lambda:CreateFunctionは確認済みの権限昇格経路です。個々のアクションではなく、必ずステートメント全体を分析してください。 - バケットレベルのパブリックアクセスブロックだけを有効にする — AWS S3 には、アカウントレベルとバケットレベルの両方にパブリックアクセスブロック設定があります。バケットレベルの設定はアカウントレベルの設定を上書きできます。両方を設定する必要があります。バケットに明示的な上書きがある場合、アカウントレベルのブロックだけでは不十分です。
- パブリックリソースに対する
--severity-modifier internet-facingを任意扱いする — インターネットに公開されているリソースは、内部リソースよりも大幅に高いリスクにさらされています。インターネットに公開されたインフラストラクチャでの高リスクの検出結果は、重大として扱う必要があります。DMZ、ロードバランサー、API ゲートウェイの設定には、必ず--severity-modifier internet-facingを適用してください。 - 管理者ポリシーだけを確認する — 権限昇格経路は、一見無害な権限を組み合わせた非管理者ポリシーから発生することがよくあります。明らかに高いアクセス権限を持つポリシーだけでなく、本番環境のアイデンティティにアタッチされているすべてのポリシーを確認してください。
- 根本原因を分析せずに検出結果を修正する — 危険な権限が付与された理由を理解せずに削除すると、再び追加されることになります。意図せず再導入されるのを防ぐため、高リスクの権限を削除する前に、その業務上の正当性をすべて記録してください。
- サービスアカウントに過剰な権限が付与されている状態を放置する — サービスアカウントには、開発時に過剰な権限が付与され、本番環境への移行時に見直されないことがよくあります。本番環境のすべてのサービスアカウントについて、AWS Access Analyzer または同等のツールで監査し、未使用の権限を特定して削除する必要があります。
- 規制対象データのワークロードに重大度修飾子を適用しない — 汎用の S3 バケットでの高リスクの検出結果と、PHI またはカード会員データを含むバケットでの同じ検出結果は異なります。規制対象データ環境のリソースを評価する際は、必ず
--severity-modifier regulated-dataを使用してください。
関連項目
| スキル | 関連性 |
|---|---|
| incident-response | 重大な検出結果(パブリックな S3、権限昇格が有効であることを確認)により、インシデントの分類が必要になる場合があります |
| threat-detection | クラウドのセキュリティ態勢に関する検出結果は、脅威ハンティングの対象になります。過剰な権限を持つロールは、ラテラルムーブメントの移動先となる可能性があります |
| red-team | レッドチーム演習では、セキュリティ態勢の評価で見つかったクラウドの設定ミスの悪用可能性を特にテストします |
| security-pen-testing | クラウドのセキュリティ態勢に関する検出結果は、ペネトレーションテスト評価のインフラストラクチャセキュリティの項目に反映されます |