claude-skills/

Anthropic公式スキル・プラグインの日本語ディレクトリ

last sync 22h ago
スキルOfficialdevelopment

🔐setup-security-agent

説明

現在のワークスペース向けにAWS Security Agentを設定します。 エージェントスペース、IAMサービスロール、およびS3バケットのプロビジョニングまたは再利用を行います。 次のような場合に使用: ユーザーが「security agentをセットアップしたい」「security scannerを設定したい」「security agentは設定済みか」と尋ねた場合、 またはスキャンやペネトレーションテストを初めて実行する前の初回セットアップ時。

原文を表示

Configure AWS Security Agent for the current workspace — provision or reuse an agent space, IAM service role, and S3 bucket. Use when the user asks to "set up security agent", "configure security scanner", "is security agent configured", or on first-time use before any scan or pentest.

ユースケース

  • Security Agentをセットアップしたいとき
  • Security Scannerを設定したいとき
  • スキャンやペネトレーションテストを初めて実行するとき
  • Security Agentの設定状況を確認するとき

本文(日本語訳)

AWS Security Agent — セットアップ

このスキルが担うのは1つのことだけです: ワークスペースに、動作するagent space・IAMサービスロール・S3バケットが連携した状態で存在することを確認します。 スキャンおよびペネトレーションテストは別スキルで処理され、このセットアップが完了していることを前提としています。


ローカル状態の規約

すべてのSecurity AgentスキルはワークスペースローカルのステートをKEY .security-agent/ 配下で共有します:

  • config.json{ "agent_space_id": "as-...", "region": "us-east-1", "code_reviews": { "<abs_path>": "cr-..." } } アカウントID・ロールARN・バケット名は命名規約から導出します。 code_reviews マップにより、スキャン時に同じCodeReviewをワークスペース内で再利用できます。
  • scans.json{ scan_id, code_review_id, job_id, agent_space_id, scan_type, title, started_at, status, path } の配列(最新50件を保持)
  • pentests.json — 同じ構造、ペネトレーションテストジョブ用
  • .gitignore — 内容は *(このディレクトリをGit管理外にする)
  • findings-{scan_id}.md — 各スキャン完了後にスキャンスキルが書き出す

このスキルの役割は config.json を生成し、.gitignore を作成することです。

導出値(設定より規約)

他のスキルは config.json から読み込む代わりに、呼び出しのたびに以下の値を算出します:

規約
ACCOUNT aws sts get-caller-identity --query Account --output text
REGION config.region(デフォルト: us-east-1
service_role_arn arn:aws:iam::${ACCOUNT}:role/SecurityAgentScanRole
s3_bucket security-agent-scans-${ACCOUNT}-${REGION}

config を最小限にする理由: ロール名とバケット名は決定的に導出できるため、それらを保存すると設定ドリフトのリスクが生じます(ユーザーが手動でロールを再作成した場合、古いパスがサイレントに使われ続けます)。 agent_space_id のみを保存する理由は、ユーザーが複数のagent spaceを持つ可能性があり、セッションごとにどれを使うか確認する手間を避けるためです。


ワークフロー

  1. 既存の状態を確認: .security-agent/config.json が存在すれば読み込む。

  2. 呼び出し元のIDとリージョンを取得:

    export ACCOUNT=$(aws sts get-caller-identity --query Account --output text)
    export REGION="${AWS_REGION:-us-east-1}"
    
  3. Agent space の処理:

    • config.agent_space_id が設定済みの場合、以下で存在を確認する:

      aws securityagent batch-get-agent-spaces --agent-space-ids <id>
      

      レスポンスが存在しないことを示す場合は、未設定として扱う。

    • 未設定の場合、既存のagent spaceを一覧表示する:

      aws securityagent list-agent-spaces
      
      • 既存のものがある場合 → 名前とIDを添えてユーザーに表示し、「いずれかを再利用しますか?それとも新しく作成しますか?」と尋ねる。回答を待つこと。自動選択は絶対にしない。

      • ユーザーが既存のものを選んだ場合、その agentSpaceId を使用する。

      • ユーザーが新規作成を希望する場合、または既存のものがない場合:

        aws securityagent create-agent-space --name security-scans
        

        返された agentSpaceId を取得する。

  4. サービスロールの処理 (SecurityAgentScanRole、ARN: arn:aws:iam::$ACCOUNT:role/SecurityAgentScanRole):

    • 存在確認:

      aws iam get-role --role-name SecurityAgentScanRole
      
    • NoSuchEntity が返された場合はロールを作成する。 冪等性に関する注意: ロールが既に存在する場合、create-roleEntityAlreadyExists で失敗します。その場合は update-assume-role-policy にフォールスルーして、信頼ポリシーが正しいことを確認してください。

      # 信頼ポリシー — aws:SourceAccount による confused-deputy ガードを含む
      cat > /tmp/sa-trust.json <<EOF
      {"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"securityagent.amazonaws.com"},"Action":"sts:AssumeRole","Condition":{"StringEquals":{"aws:SourceAccount":"${ACCOUNT}"}}}]}
      EOF
      # 権限ポリシー(S3 + CloudWatch Logs)
      cat > /tmp/sa-perms.json <<EOF
      {"Version":"2012-10-17","Statement":[
        {"Effect":"Allow","Action":["s3:GetObject","s3:GetObjectVersion","s3:ListBucket"],"Resource":["arn:aws:s3:::security-agent-scans-${ACCOUNT}-${REGION}","arn:aws:s3:::security-agent-scans-${ACCOUNT}-${REGION}/*"]},
        {"Effect":"Allow","Action":["logs:CreateLogGroup","logs:CreateLogStream","logs:PutLogEvents"],"Resource":"arn:aws:logs:*:${ACCOUNT}:log-group:/aws/securityagent/*"}
      ]}
      EOF
      
      aws iam create-role --role-name SecurityAgentScanRole --assume-role-policy-document file:///tmp/sa-trust.json
      # EntityAlreadyExists の場合:
      aws iam update-assume-role-policy --role-name SecurityAgentScanRole --policy-document file:///tmp/sa-trust.json
      # 常に権限ポリシーを(再)適用する:
      aws iam put-role-policy --role-name SecurityAgentScanRole --policy-name SecurityAgentCodeReviewAccess --policy-document file:///tmp/sa-perms.json
      
  5. S3バケットの処理 (security-agent-scans-$ACCOUNT-$REGION):

    • 存在確認:

      BUCKET="security-agent-scans-${ACCOUNT}-${REGION}"
      aws s3api head-bucket --bucket "$BUCKET"
      
    • 404 の場合、作成する:

      # us-east-1: LocationConstraint は不要
      aws s3api create-bucket --bucket "$BUCKET"
      # 他のリージョンの場合:
      aws s3api create-bucket --bucket "$BUCKET" --create-bucket-configuration LocationConstraint="$REGION"
      
    • 常にパブリックアクセスブロックと30日ライフサイクルを(再)適用する:

      aws s3api put-public-access-block --bucket "$BUCKET" \
        --public-access-block-configuration BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true
      
      cat > /tmp/sa-lifecycle.json <<'EOF'
      {"Rules":[{"ID":"AutoDeleteUploads","Status":"Enabled","Filter":{"Prefix":""},"Expiration":{"Days":30}}]}
      EOF
      aws s3api put-bucket-lifecycle-configuration --bucket "$BUCKET" --lifecycle-configuration file:///tmp/sa-lifecycle.json
      
  6. ロールとバケットをagent spaceに登録する(冪等):

    • 既存のリソースを読み込む:

      aws securityagent batch-get-agent-spaces --agent-space-ids <id>
      

      agentSpaces[0].awsResources.iamRolesawsResources.s3Buckets を確認する。

    • ロールARNまたはバケット名がリストに存在しない場合、マージして更新する:

      aws securityagent update-agent-space --agent-space-id <id> --name <existing-name> \
        --aws-resources iamRoles=[<arn1>,<arn2>...],s3Buckets=[<bucket1>,<bucket2>...]
      
  7. .security-agent/config.json に保存する(最小構成 — アカウント/ロール/バケットは導出するため不要):

    {
      "agent_space_id": "as-xxxxx",
      "region": "us-east-1"
    }
    
  8. .gitignore を作成する(未存在の場合):

    mkdir -p .security-agent
    echo '*' > .security-agent/.gitignore
    
  9. ユーザーに確認メッセージを表示する: 「セットアップが完了しました。セキュリティスキャンまたはペネトレーションテストを実行できます。」


ルール

  • 複数のagent spaceが存在する場合は自動選択せず、必ずユーザーに確認すること
  • 安全保護機能を無効にしないこと(パブリックアクセスブロックは常に有効にする)
  • 信頼ポリシーは securityagent.amazonaws.com(本番サービスプリンシパル)を許可し、aws:SourceAccount による confused-deputy ガードを含めること
  • ユーザーが規約のデフォルトと異なる独自のロール名やバケット名を指定した場合、次のように伝えること: 「このpluginは規約ベースのデフォルト(SecurityAgentScanRole / security-agent-scans-${ACCOUNT}-${REGION})を使用します。デフォルトを受け入れるか、スキルを拡張してください。他のスキルはこれらの名前をconfigから読み込むのではなく導出しています。」
  • config.json が存在しない場合、スキャンおよびペネトレーションテストスキルからこのスキルをインライン呼び出しできます。初回ユーザーはセットアップを別途実行する必要はありません。

トラブルシューティング

  • iam:CreateRoleAccessDenied → ユーザーにIAM権限がありません。独自のロールARNを使用してセットアップを実行するか、iam:CreateRole + iam:PutRolePolicy 権限の付与を依頼してください。
  • s3api create-bucketAccessDenied → バケット名がグローバルで既に使用されているか、ユーザーに s3:CreateBucket 権限がありません。ユーザーが所有する既存のバケットを使用して明示的に指定するよう提案してください。
  • ロールは存在するが信頼ポリシーが誤っているupdate-assume-role-policy(ステップ4のフォールバック)を実行します。ユーザーがそのロールの更新を望まない場合は、別のロールARNを確認してください。
  • Agent spaceは存在するが別のリージョンにある → ユーザーに通知し、正しいリージョンを使用するか、現在のリージョンに新しいspaceを作成するよう提案してください。
原文(English)を表示

AWS Security Agent — Setup

This skill handles ONE thing: making sure the workspace has a working agent space, IAM service role, and S3 bucket linked together. Scans and pentests live in separate skills and assume this is done.


Local state convention

All Security Agent skills share workspace-local state at .security-agent/:

  • config.json{ "agent_space_id": "as-...", "region": "us-east-1", "code_reviews": { "<abs_path>": "cr-..." } }. Account ID, role ARN, and bucket name are derived by convention. The code_reviews map lets scans reuse the same CodeReview for a workspace.
  • scans.json — array of { scan_id, code_review_id, job_id, agent_space_id, scan_type, title, started_at, status, path } (keep last 50)
  • pentests.json — same shape, for pentest jobs
  • .gitignore — contents * so this directory stays untracked
  • findings-{scan_id}.md — written by the scan skill after each scan completes

This skill's job is to populate config.json and create .gitignore.

Derived values (convention over config)

Other skills compute these on each invocation rather than reading them from config.json:

Value Convention
ACCOUNT aws sts get-caller-identity --query Account --output text
REGION config.region (default us-east-1)
service_role_arn arn:aws:iam::${ACCOUNT}:role/SecurityAgentScanRole
s3_bucket security-agent-scans-${ACCOUNT}-${REGION}

Why minimal config: the role name and bucket name are deterministic, so storing them adds drift risk (a user re-creating a role manually would silently use a stale path). Only agent_space_id is stored because users may have multiple agent spaces and we don't want to ask which one every session.


Workflow

  1. Check existing state: read .security-agent/config.json if it exists.

  2. Caller identity + region:

    export ACCOUNT=$(aws sts get-caller-identity --query Account --output text)
    export REGION="${AWS_REGION:-us-east-1}"
    
  3. Agent space:

    • If config.agent_space_id is set, verify with:

      aws securityagent batch-get-agent-spaces --agent-space-ids <id>
      

      If the response shows it doesn't exist, treat as missing.

    • If missing, list existing:

      aws securityagent list-agent-spaces
      
      • If any exist → show them to the user with name + id and ask: "Would you like to reuse one of these, or should I create a new one?" Wait for the answer. Do not auto-select.

      • If user picks one, use that agentSpaceId.

      • If user wants new, or none exist:

        aws securityagent create-agent-space --name security-scans
        

        Capture returned agentSpaceId.

  4. Service role (SecurityAgentScanRole, ARN arn:aws:iam::$ACCOUNT:role/SecurityAgentScanRole):

    • Probe:

      aws iam get-role --role-name SecurityAgentScanRole
      
    • If NoSuchEntity is returned, create the role. Idempotency note: create-role will fail with EntityAlreadyExists if the role already exists. If that happens, fall through to update-assume-role-policy to ensure the trust policy is correct.

      # Trust policy — includes aws:SourceAccount confused-deputy guard
      cat > /tmp/sa-trust.json <<EOF
      {"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"securityagent.amazonaws.com"},"Action":"sts:AssumeRole","Condition":{"StringEquals":{"aws:SourceAccount":"${ACCOUNT}"}}}]}
      EOF
      # Permissions policy (S3 + CloudWatch Logs)
      cat > /tmp/sa-perms.json <<EOF
      {"Version":"2012-10-17","Statement":[
        {"Effect":"Allow","Action":["s3:GetObject","s3:GetObjectVersion","s3:ListBucket"],"Resource":["arn:aws:s3:::security-agent-scans-${ACCOUNT}-${REGION}","arn:aws:s3:::security-agent-scans-${ACCOUNT}-${REGION}/*"]},
        {"Effect":"Allow","Action":["logs:CreateLogGroup","logs:CreateLogStream","logs:PutLogEvents"],"Resource":"arn:aws:logs:*:${ACCOUNT}:log-group:/aws/securityagent/*"}
      ]}
      EOF
      
      aws iam create-role --role-name SecurityAgentScanRole --assume-role-policy-document file:///tmp/sa-trust.json
      # if EntityAlreadyExists:
      aws iam update-assume-role-policy --role-name SecurityAgentScanRole --policy-document file:///tmp/sa-trust.json
      # always (re)apply permissions:
      aws iam put-role-policy --role-name SecurityAgentScanRole --policy-name SecurityAgentCodeReviewAccess --policy-document file:///tmp/sa-perms.json
      
  5. S3 bucket (security-agent-scans-$ACCOUNT-$REGION):

    • Probe:

      BUCKET="security-agent-scans-${ACCOUNT}-${REGION}"
      aws s3api head-bucket --bucket "$BUCKET"
      
    • If 404, create:

      # us-east-1: no LocationConstraint
      aws s3api create-bucket --bucket "$BUCKET"
      # other regions:
      aws s3api create-bucket --bucket "$BUCKET" --create-bucket-configuration LocationConstraint="$REGION"
      
    • Always (re)apply public access block + 30-day lifecycle:

      aws s3api put-public-access-block --bucket "$BUCKET" \
        --public-access-block-configuration BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true
      
      cat > /tmp/sa-lifecycle.json <<'EOF'
      {"Rules":[{"ID":"AutoDeleteUploads","Status":"Enabled","Filter":{"Prefix":""},"Expiration":{"Days":30}}]}
      EOF
      aws s3api put-bucket-lifecycle-configuration --bucket "$BUCKET" --lifecycle-configuration file:///tmp/sa-lifecycle.json
      
  6. Register role + bucket on the agent space (idempotent):

    • Read existing resources:

      aws securityagent batch-get-agent-spaces --agent-space-ids <id>
      

      Look at agentSpaces[0].awsResources.iamRoles and awsResources.s3Buckets.

    • If the role ARN or the bucket name is missing from those lists, merge and update:

      aws securityagent update-agent-space --agent-space-id <id> --name <existing-name> \
        --aws-resources iamRoles=[<arn1>,<arn2>...],s3Buckets=[<bucket1>,<bucket2>...]
      
  7. Persist to .security-agent/config.json (minimal — account/role/bucket are derived):

    {
      "agent_space_id": "as-xxxxx",
      "region": "us-east-1"
    }
    
  8. Create gitignore if missing:

    mkdir -p .security-agent
    echo '*' > .security-agent/.gitignore
    
  9. Confirm to user: "Setup complete. You can run security scans or pentests now."


Rules

  • Never auto-select an agent space when multiple exist — always ask the user
  • Never disable safety protections (the public-access-block stays on)
  • Trust policy must allow securityagent.amazonaws.com (production service principal) and include the aws:SourceAccount confused-deputy guard
  • If the user provides their own role name or bucket name (different from the conventional defaults), tell them: this plugin uses convention-based defaults (SecurityAgentScanRole / security-agent-scans-${ACCOUNT}-${REGION}). Either accept those defaults or extend the skill — the other skills derive these names rather than reading them from config.
  • The scan and pentest skills can call this skill inline if config.json is missing — first-time users don't need to run setup separately.

Troubleshooting

  • AccessDenied calling iam:CreateRole → user lacks IAM permissions. Ask them to run setup with their own role ARN, or to grant iam:CreateRole + iam:PutRolePolicy.
  • AccessDenied on s3api create-bucket → either the bucket name is taken globally, or the user lacks s3:CreateBucket. Suggest using an existing bucket they own and pass it explicitly.
  • Role exists but trust policy is wrongupdate-assume-role-policy (step 4 fallback). If they don't want that role updated, ask them for a different role ARN.
  • Agent space exists but in a different region → tell the user; suggest using the right region or creating a new space in the current region.

原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。