AWS Certified Security - Specialty (SCS-C02)

書籍レベル完全学習ガイド

試験概要

ドメイン別出題割合

┌──────────────────────────────────────────────────────────────────┐
│  ドメイン1: 脅威検出・インシデント対応         14%  ██████          │
│  ドメイン2: セキュリティログ・監視             18%  ████████        │
│  ドメイン3: インフラストラクチャセキュリティ    20%  █████████       │
│  ドメイン4: IAM                               16%  ███████         │
│  ドメイン5: データ保護                         18%  ████████        │
│  ドメイン6: セキュリティガバナンス              14%  ██████          │
└──────────────────────────────────────────────────────────────────┘

ドメイン1: 脅威検出・インシデント対応（14%）

1.1 Amazon GuardDuty 完全ガイド

GuardDutyの脅威タイプ

GuardDuty データソース

┌─────────────────────────────────────────────────────────────────┐
│                        GuardDuty                                 │
│                                                                  │
│  VPC Flow Logs ──────→ ネットワーク異常検出                       │
│  CloudTrail Events ──→ APIコール異常検出                          │
│  DNS Logs ───────────→ DNSクエリ分析                             │
│  S3 Access Logs ─────→ S3異常アクセス検出                        │
│  EKS Audit Logs ─────→ Kubernetes脅威検出                       │
│  RDS Login Events ───→ RDS異常ログイン検出                       │
│  Lambda Network ─────→ Lambda悪意ある通信検出                    │
│  EBS/EC2 Malware ────→ マルウェアスキャン                        │
└─────────────────────────────────────────────────────────────────┘

GuardDuty自動対応（EventBridge + Lambda）

# EventBridgeルール: GuardDuty高重大度FindingでLambda起動
# パターン: { "source": ["aws.guardduty"], "detail-type": ["GuardDuty Finding"] }

import boto3
import json

def lambda_handler(event, context):
    detail = event['detail']
    severity = detail['severity']
    finding_type = detail['type']
    account_id = detail['accountId']
    region = detail['region']
    
    # 重大度7以上（HIGH/CRITICAL）は自動対応
    if severity >= 7.0:
        handle_high_severity(detail)
    
    return {'statusCode': 200}

def handle_high_severity(finding):
    ec2 = boto3.client('ec2')
    iam = boto3.client('iam')
    
    finding_type = finding['type']
    
    # EC2インスタンス侵害の場合: セキュリティグループで隔離
    if 'EC2' in finding_type:
        instance_id = finding['resource']['instanceDetails']['instanceId']
        
        # 隔離用セキュリティグループに変更（全アウトバウンドブロック）
        ec2.modify_instance_attribute(
            InstanceId=instance_id,
            Groups=['sg-quarantine-0123456789']
        )
        
        # スナップショット取得（フォレンジック用）
        volumes = ec2.describe_instance_attribute(
            InstanceId=instance_id,
            Attribute='blockDeviceMapping'
        )
        for volume in volumes['BlockDeviceMappings']:
            ec2.create_snapshot(
                VolumeId=volume['Ebs']['VolumeId'],
                Description=f'Forensic snapshot - GuardDuty finding {finding["id"]}'
            )
    
    # IAMユーザー侵害の場合: アクセスキー無効化
    elif 'IAMUser' in finding_type:
        user_name = finding['resource']['accessKeyDetails']['userName']
        access_key_id = finding['resource']['accessKeyDetails']['accessKeyId']
        
        iam.update_access_key(
            UserName=user_name,
            AccessKeyId=access_key_id,
            Status='Inactive'
        )
        
        # すべてのセッションを無効化
        iam.put_user_policy(
            UserName=user_name,
            PolicyName='DenyAll',
            PolicyDocument=json.dumps({
                "Version": "2012-10-17",
                "Statement": [{"Effect": "Deny", "Action": "*", "Resource": "*"}]
            })
        )

1.2 AWS Security Hub

Security Hub: セキュリティアラートの集約・正規化・優先順位付け

                GuardDuty Finding
                Inspector Finding    →  Security Hub  →  EventBridge
                Macie Finding                            →  Lambda
                Firewall Manager                         →  SIEM
                Config Rules
                3rd Party (CrowdStrike等)

Security Hub 標準

# Security Hub Findingの取得と処理
import boto3

securityhub = boto3.client('securityhub')

# Findingフィルタリング
response = securityhub.get_findings(
    Filters={
        'SeverityLabel': [{'Value': 'CRITICAL', 'Comparison': 'EQUALS'}],
        'RecordState': [{'Value': 'ACTIVE', 'Comparison': 'EQUALS'}],
        'WorkflowStatus': [{'Value': 'NEW', 'Comparison': 'EQUALS'}]
    },
    MaxResults=100
)

for finding in response['Findings']:
    print(f"Title: {finding['Title']}")
    print(f"Severity: {finding['Severity']['Label']}")
    print(f"Resource: {finding['Resources'][0]['Id']}")
    
    # Finding状態を更新（対応中）
    securityhub.batch_update_findings(
        FindingIdentifiers=[{
            'Id': finding['Id'],
            'ProductArn': finding['ProductArn']
        }],
        Workflow={'Status': 'IN_PROGRESS'},
        Note={'Text': '自動対応開始', 'UpdatedBy': 'auto-remediation-lambda'}
    )

1.3 Amazon Detective

Detective: GuardDuty/Security Hub Findingの根本原因調査

GuardDuty Finding → Detective で
  - どのIPから
  - どのユーザーが
  - いつ
  - 何のAPIを
  - どのリソースに対して呼んだか
を視覚的に調査

VPC Flow Logs + CloudTrail + GuardDuty を統合グラフDB化

1.4 AWS Config によるインシデント検出

# Config Rule: セキュリティグループでSSH公開許可を検出
import boto3
import json

def lambda_handler(event, context):
    invoking_event = json.loads(event['invokingEvent'])
    configuration_item = invoking_event['configurationItem']
    
    if configuration_item['resourceType'] != 'AWS::EC2::SecurityGroup':
        return build_evaluation('NOT_APPLICABLE', configuration_item)
    
    config = configuration_item['configuration']
    
    for permission in config.get('ipPermissions', []):
        if permission.get('fromPort') == 22 and permission.get('toPort') == 22:
            for ip_range in permission.get('ipv4Ranges', []):
                if ip_range.get('cidrIp') == '0.0.0.0/0':
                    return build_evaluation('NON_COMPLIANT', configuration_item,
                                          'SSH open to 0.0.0.0/0')
    
    return build_evaluation('COMPLIANT', configuration_item)

def build_evaluation(compliance_type, ci, annotation=None):
    evaluation = {
        'ComplianceResourceType': ci['resourceType'],
        'ComplianceResourceId': ci['resourceId'],
        'ComplianceType': compliance_type,
        'OrderingTimestamp': ci['configurationItemCaptureTime']
    }
    if annotation:
        evaluation['Annotation'] = annotation
    return evaluation

ドメイン2: セキュリティログ・監視（18%）

2.1 CloudTrail 完全ガイド

CloudTrail イベント種類

// CloudTrail ログ例（不正アクセス試行）
{
  "eventVersion": "1.08",
  "userIdentity": {
    "type": "IAMUser",
    "principalId": "AIDAXXXXXXXXXX",
    "arn": "arn:aws:iam::123456789012:user/attacker",
    "accountId": "123456789012",
    "accessKeyId": "AKIAIOSFODNN7EXAMPLE",
    "userName": "attacker"
  },
  "eventTime": "2026-01-15T10:30:00Z",
  "eventSource": "s3.amazonaws.com",
  "eventName": "GetObject",
  "awsRegion": "us-east-1",
  "sourceIPAddress": "203.0.113.1",  // 外部IP
  "requestParameters": {
    "bucketName": "sensitive-data-bucket",
    "key": "confidential/customer-data.csv"
  },
  "responseElements": null,
  "errorCode": "AccessDenied",
  "errorMessage": "Access Denied"
}

CloudTrail の証跡保護

import boto3

cloudtrail = boto3.client('cloudtrail')

# 証跡の設定（S3 + CloudWatch Logs + SNS）
cloudtrail.create_trail(
    Name='org-security-trail',
    S3BucketName='security-trail-bucket',
    IncludeGlobalServiceEvents=True,
    IsMultiRegionTrail=True,
    EnableLogFileValidation=True,   # 改ざん検知ハッシュ
    CloudWatchLogsLogGroupArn='arn:aws:logs:us-east-1:123456789012:log-group:CloudTrail/DefaultLogGroup',
    CloudWatchLogsRoleArn='arn:aws:iam::123456789012:role/CloudTrail_CloudWatchLogs_Role',
    IsOrganizationTrail=True        # Organizations全アカウント
)

# ログファイル検証
cloudtrail.validate_log_file(
    TrailArn='arn:aws:cloudtrail:us-east-1:123456789012:trail/org-security-trail',
    LogFilePath='AWSLogs/123456789012/CloudTrail/us-east-1/2026/01/15/xxx.json.gz'
)

S3バケットへのCloudTrail証跡保護

// S3バケットポリシー: CloudTrail専用・削除禁止
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AWSCloudTrailAclCheck",
      "Effect": "Allow",
      "Principal": {"Service": "cloudtrail.amazonaws.com"},
      "Action": "s3:GetBucketAcl",
      "Resource": "arn:aws:s3:::security-trail-bucket"
    },
    {
      "Sid": "AWSCloudTrailWrite",
      "Effect": "Allow",
      "Principal": {"Service": "cloudtrail.amazonaws.com"},
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::security-trail-bucket/AWSLogs/*",
      "Condition": {
        "StringEquals": {"s3:x-amz-acl": "bucket-owner-full-control"}
      }
    },
    {
      "Sid": "DenyDelete",
      "Effect": "Deny",
      "Principal": "*",
      "Action": ["s3:DeleteObject", "s3:DeleteBucket"],
      "Resource": [
        "arn:aws:s3:::security-trail-bucket",
        "arn:aws:s3:::security-trail-bucket/*"
      ]
    }
  ]
}

2.2 VPC Flow Logs 分析

-- Athena でVPC Flow Logs を分析
-- テーブル作成
CREATE EXTERNAL TABLE vpc_flow_logs (
  version int,
  account_id string,
  interface_id string,
  srcaddr string,
  dstaddr string,
  srcport int,
  dstport int,
  protocol bigint,
  packets bigint,
  bytes bigint,
  starttime int,
  endtime int,
  action string,
  log_status string
)
PARTITIONED BY (date string)
ROW FORMAT DELIMITED FIELDS TERMINATED BY ' '
LOCATION 's3://my-flow-logs/AWSLogs/123456789012/vpcflowlogs/us-east-1/';

-- ポートスキャン検出
SELECT srcaddr, COUNT(DISTINCT dstport) as port_count
FROM vpc_flow_logs
WHERE action = 'REJECT'
  AND date = '2026/01/15'
GROUP BY srcaddr
HAVING COUNT(DISTINCT dstport) > 100
ORDER BY port_count DESC;

-- データ漏洩の可能性がある大量アウトバウンドを検出
SELECT srcaddr, dstaddr, SUM(bytes) as total_bytes
FROM vpc_flow_logs
WHERE action = 'ACCEPT'
  AND srcaddr LIKE '10.%'  -- 内部IP
  AND date >= '2026/01/15'
GROUP BY srcaddr, dstaddr
HAVING SUM(bytes) > 1073741824  -- 1GB超
ORDER BY total_bytes DESC;

2.3 Amazon Macie（機密データ検出）

import boto3

macie = boto3.client('macie2')

# Macie有効化
macie.enable_macie()

# 機密データ検出ジョブ作成
response = macie.create_classification_job(
    name='pii-detection-job',
    jobType='SCHEDULED',
    scheduleFrequency={'dailySchedule': {}},
    s3JobDefinition={
        'bucketDefinitions': [
            {
                'accountId': '123456789012',
                'buckets': ['sensitive-data-bucket', 'customer-uploads']
            }
        ]
    },
    managedDataIdentifierSelector='ALL',  # PII検出全ルール
    customDataIdentifierIds=['custom-id-credit-card']
)

# Macie Findingの処理
findings = macie.get_findings(
    findingIds=['finding-id-1', 'finding-id-2']
)

for finding in findings['findings']:
    print(f"Type: {finding['type']}")
    print(f"Severity: {finding['severity']['description']}")
    print(f"Bucket: {finding['resourcesAffected']['s3Bucket']['name']}")
    # 機密データ種類（SSN、クレカ番号、etc.）
    if 'sensitiveData' in finding:
        for category in finding['sensitiveData']:
            print(f"PII Category: {category['category']}")

ドメイン3: インフラストラクチャセキュリティ（20%）

3.1 AWS WAF 完全ガイド

WAFルール種類

import boto3

wafv2 = boto3.client('wafv2', region_name='us-east-1')

# WebACL作成
response = wafv2.create_web_acl(
    Name='production-waf',
    Scope='REGIONAL',  # ALB向け。CloudFrontはCLOUDFRONT
    DefaultAction={'Allow': {}},
    Rules=[
        # マネージドルール: AWS一般的な脅威
        {
            'Name': 'AWSManagedRulesCommonRuleSet',
            'Priority': 1,
            'Statement': {
                'ManagedRuleGroupStatement': {
                    'VendorName': 'AWS',
                    'Name': 'AWSManagedRulesCommonRuleSet',
                    'ExcludedRules': [
                        {'Name': 'SizeRestrictions_BODY'}  # 特定ルール除外
                    ]
                }
            },
            'OverrideAction': {'None': {}},  # マネージドルールのアクションをそのまま使用
            'VisibilityConfig': {
                'SampledRequestsEnabled': True,
                'CloudWatchMetricsEnabled': True,
                'MetricName': 'AWSManagedRulesCommonRuleSet'
            }
        },
        # SQLインジェクション防御
        {
            'Name': 'AWSManagedRulesSQLiRuleSet',
            'Priority': 2,
            'Statement': {
                'ManagedRuleGroupStatement': {
                    'VendorName': 'AWS',
                    'Name': 'AWSManagedRulesSQLiRuleSet'
                }
            },
            'OverrideAction': {'None': {}},
            'VisibilityConfig': {
                'SampledRequestsEnabled': True,
                'CloudWatchMetricsEnabled': True,
                'MetricName': 'SQLiRuleSet'
            }
        },
        # レートリミット（DDoS防御）
        {
            'Name': 'RateLimit',
            'Priority': 3,
            'Statement': {
                'RateBasedStatement': {
                    'Limit': 2000,           # 5分間に2000リクエスト
                    'AggregateKeyType': 'IP'
                }
            },
            'Action': {'Block': {}},
            'VisibilityConfig': {
                'SampledRequestsEnabled': True,
                'CloudWatchMetricsEnabled': True,
                'MetricName': 'RateLimit'
            }
        },
        # 地理的制限
        {
            'Name': 'GeoBlock',
            'Priority': 4,
            'Statement': {
                'GeoMatchStatement': {
                    'CountryCodes': ['KP', 'IR', 'CU']  # ブロック対象国
                }
            },
            'Action': {'Block': {}},
            'VisibilityConfig': {
                'SampledRequestsEnabled': True,
                'CloudWatchMetricsEnabled': True,
                'MetricName': 'GeoBlock'
            }
        }
    ],
    VisibilityConfig={
        'SampledRequestsEnabled': True,
        'CloudWatchMetricsEnabled': True,
        'MetricName': 'production-waf'
    }
)

マネージドルールグループ一覧

3.2 AWS Shield

# Shield Advanced 保護リソース登録
import boto3

shield = boto3.client('shield', region_name='us-east-1')

# 保護対象リソース追加
shield.create_protection(
    Name='production-alb-protection',
    ResourceArn='arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/app/prod-alb/xxx'
)

# DRT（DDoS Response Team）への連絡設定
shield.associate_drt_log_bucket(
    LogBucket='shield-drt-logs'
)

3.3 VPC セキュリティ設計

多層防御アーキテクチャ

Internet
    ↓
CloudFront + WAF          ← レイヤー7 DDoS/SQLi/XSS防御
    ↓
Internet Gateway
    ↓
Network ACL (ステートレス)  ← サブネットレベルでIP/ポートフィルタ
    ↓
Public Subnet
  [ALB]
    ↓
Security Group (ステートフル) ← インスタンスレベルでアプリポートのみ許可
    ↓
Private Subnet
  [EC2/ECS]
    ↓
Network ACL
    ↓
Data Subnet
  [RDS/ElastiCache]        ← EC2からのみアクセス許可

セキュリティグループ vs Network ACL

# セキュリティグループ設定例
import boto3

ec2 = boto3.client('ec2')

# Webサーバー用SG
web_sg = ec2.create_security_group(
    GroupName='web-server-sg',
    Description='Web server security group',
    VpcId='vpc-xxxxxxxx'
)

# ALBからのHTTP/HTTPS のみ許可
ec2.authorize_security_group_ingress(
    GroupId=web_sg['GroupId'],
    IpPermissions=[
        {
            'IpProtocol': 'tcp',
            'FromPort': 80,
            'ToPort': 80,
            'UserIdGroupPairs': [{'GroupId': alb_sg_id}]  # ALB SGのみ
        },
        {
            'IpProtocol': 'tcp',
            'FromPort': 443,
            'ToPort': 443,
            'UserIdGroupPairs': [{'GroupId': alb_sg_id}]
        }
    ]
)

3.4 AWS Network Firewall

# ステートフル・ステートレスルールエンジン
# VPC間・VPC-Internet間のLayer4/7フィルタリング

import boto3

network_firewall = boto3.client('network-firewall')

# ルールグループ作成（ステートフル・Suricataベース）
rg = network_firewall.create_rule_group(
    RuleGroupName='block-malicious-domains',
    Type='STATEFUL',
    Capacity=100,
    RuleGroup={
        'RulesSource': {
            'RulesString': '''
# Suricataルール形式
alert dns any any -> any any (msg:"Malicious Domain"; dns.query; content:"malware-site.com"; nocase; sid:1000001; rev:1;)
drop http any any -> any any (msg:"Block Ransomware C2"; http.host; content:"c2-server.net"; sid:1000002; rev:1;)
'''
        }
    }
)

# ファイアウォールポリシー
policy = network_firewall.create_firewall_policy(
    FirewallPolicyName='production-firewall-policy',
    FirewallPolicy={
        'StatelessDefaultActions': ['aws:forward_to_sfe'],
        'StatelessFragmentDefaultActions': ['aws:drop'],
        'StatefulRuleGroupReferences': [
            {'ResourceArn': rg['RuleGroupResponse']['RuleGroupArn']}
        ],
        'StatefulDefaultActions': ['aws:drop_strict']
    }
)

Network Firewall Inspection VPC パターン

                    ┌──────────────────────────────────────┐
  Internet ─────→  │         Inspection VPC               │
                   │  IGW → Network Firewall → TGW attach  │
                   └──────────────────────────────────────┘
                                    ↓
                        Transit Gateway (TGW)
                          ↙            ↘
               Production VPC      Dev VPC
               (内部トラフィック)    (内部トラフィック)

ドメイン4: IAM（16%）

4.1 IAMポリシー評価ロジック

ポリシー評価順序（優先度高い順）:

1. Explicit DENY (明示的拒否)     ← 最優先。全ての Allow より強い
   ↓ DenyなければAllow確認
2. SCPs (Service Control Policies) ← Organizations全体の上限
   ↓ SCPでAllowされていれば
3. Resource-based Policy
   ↓ 
4. Permission Boundary             ← IAMエンティティの上限
   ↓
5. Identity-based Policy (IAM Policy)
   ↓
6. Session Policy (AssumeRoleの際)
   ↓
最終的にどのDenyにもマッチせず、AllowにマッチすればOK
いずれかのDenyまたはAllowなしの場合はDENY

# IAMポリシーシミュレーターでの確認
import boto3

iam = boto3.client('iam')

response = iam.simulate_principal_policy(
    PolicySourceArn='arn:aws:iam::123456789012:user/developer',
    ActionNames=['s3:GetObject', 's3:DeleteObject', 'ec2:TerminateInstances'],
    ResourceArns=['arn:aws:s3:::production-bucket/*', 'arn:aws:ec2:us-east-1:123456789012:instance/i-xxxxxxxxxx'],
    ContextEntries=[
        {
            'ContextKeyName': 'aws:MultiFactorAuthPresent',
            'ContextKeyValues': ['true'],
            'ContextKeyType': 'boolean'
        }
    ]
)

for result in response['EvaluationResults']:
    print(f"Action: {result['EvalActionName']}")
    print(f"Decision: {result['EvalDecision']}")
    if result['EvalDecision'] == 'implicitDeny':
        print(f"  → 許可ポリシーなし")
    elif result['EvalDecision'] == 'explicitDeny':
        print(f"  → Denyポリシー: {result['MatchedStatements']}")

4.2 クロスアカウントアクセス設計

// アカウントB（リソース側）のIAMロールの信頼ポリシー
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::AccountA-ID:role/app-role"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "unique-external-id-12345"  // 混乱した代理問題防止
        },
        "Bool": {
          "aws:MultiFactorAuthPresent": "true"  // MFA必須
        }
      }
    }
  ]
}

# アカウントAのアプリケーションがアカウントBのリソースにアクセス
import boto3

sts = boto3.client('sts')

# アカウントBのロールをAssumeRole
response = sts.assume_role(
    RoleArn='arn:aws:iam::AccountB-ID:role/cross-account-role',
    RoleSessionName='MyAppSession',
    ExternalId='unique-external-id-12345',
    DurationSeconds=3600
)

credentials = response['Credentials']

# 一時認証情報でS3アクセス
s3 = boto3.client(
    's3',
    aws_access_key_id=credentials['AccessKeyId'],
    aws_secret_access_key=credentials['SecretAccessKey'],
    aws_session_token=credentials['SessionToken']
)

s3.get_object(Bucket='accountb-bucket', Key='data.csv')

4.3 Permission Boundary

// Permission Boundary: 開発者が作れるポリシーの上限を定義
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:*",
        "cloudwatch:*",
        "logs:*"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Deny",
      "Action": [
        "iam:*",
        "organizations:*",
        "account:*"
      ],
      "Resource": "*"
    }
  ]
}

# Permission Boundaryを設定してIAMロールを作成
iam.create_role(
    RoleName='developer-role',
    AssumeRolePolicyDocument=trust_policy_json,
    PermissionsBoundary='arn:aws:iam::123456789012:policy/DeveloperBoundary'
)

# 実効権限 = Identity Policy ∩ Permission Boundary
# Permission Boundaryがない場合は Identity Policy のみ有効

4.4 Service Control Policy（SCP）設計

// SCP: 特定リージョン以外のリソース作成禁止
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyNonApprovedRegions",
      "Effect": "Deny",
      "NotAction": [
        "iam:*",
        "organizations:*",
        "support:*",
        "sts:*",
        "route53:*",
        "cloudfront:*",
        "waf::*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotIn": {
          "aws:RequestedRegion": [
            "ap-northeast-1",
            "us-east-1"
          ]
        }
      }
    }
  ]
}

// SCP: GuardDutyの無効化禁止
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ProtectGuardDuty",
      "Effect": "Deny",
      "Action": [
        "guardduty:DeleteDetector",
        "guardduty:DisassociateFromMasterAccount",
        "guardduty:DisassociateMembers",
        "guardduty:StopMonitoringMembers",
        "guardduty:UpdateDetector"
      ],
      "Resource": "*",
      "Condition": {
        "ArnNotLike": {
          "aws:PrincipalARN": "arn:aws:iam::*:role/security-admin"
        }
      }
    }
  ]
}

4.5 AWS IAM Identity Center（旧 SSO）

                        IdP (Okta/Azure AD)
                              ↓ SAML 2.0
                    IAM Identity Center
                              ↓
             ┌────────────────┼────────────────┐
         開発アカウント    本番アカウント    セキュリティアカウント
             ↓                  ↓                    ↓
        Developer Role    ReadOnly Role         SecurityAdmin Role

# Permission Set作成
sso_admin = boto3.client('sso-admin')

# Permission Set = 権限のテンプレート
response = sso_admin.create_permission_set(
    InstanceArn='arn:aws:sso:::instance/ssoins-xxxxxxxxxx',
    Name='DeveloperAccess',
    SessionDuration='PT8H',    # 8時間セッション
    Description='Developer access for application teams'
)

permission_set_arn = response['PermissionSet']['PermissionSetArn']

# AWSマネージドポリシーをアタッチ
sso_admin.attach_managed_policy_to_permission_set(
    InstanceArn='arn:aws:sso:::instance/ssoins-xxxxxxxxxx',
    PermissionSetArn=permission_set_arn,
    ManagedPolicyArn='arn:aws:iam::aws:policy/PowerUserAccess'
)

# アカウントへのアクセス割り当て
sso_admin.create_account_assignment(
    InstanceArn='arn:aws:sso:::instance/ssoins-xxxxxxxxxx',
    TargetId='123456789012',    # AWSアカウントID
    TargetType='AWS_ACCOUNT',
    PermissionSetArn=permission_set_arn,
    PrincipalType='GROUP',
    PrincipalId='group-id-for-developers'
)

ドメイン5: データ保護（18%）

5.1 AWS KMS 完全ガイド

キー種類

import boto3

kms = boto3.client('kms')

# CMK作成
key = kms.create_key(
    Description='Production data encryption key',
    KeyUsage='ENCRYPT_DECRYPT',
    KeySpec='SYMMETRIC_DEFAULT',
    Origin='AWS_KMS',
    EnableKeyRotation=True,
    Policy=json.dumps({
        "Version": "2012-10-17",
        "Statement": [
            {
                "Sid": "Enable IAM User Permissions",
                "Effect": "Allow",
                "Principal": {"AWS": "arn:aws:iam::123456789012:root"},
                "Action": "kms:*",
                "Resource": "*"
            },
            {
                "Sid": "Allow use of key for app",
                "Effect": "Allow",
                "Principal": {"AWS": "arn:aws:iam::123456789012:role/app-role"},
                "Action": [
                    "kms:Encrypt",
                    "kms:Decrypt",
                    "kms:ReEncrypt*",
                    "kms:GenerateDataKey",
                    "kms:DescribeKey"
                ],
                "Resource": "*"
            },
            {
                "Sid": "Allow key administration",
                "Effect": "Allow",
                "Principal": {"AWS": "arn:aws:iam::123456789012:role/key-admin"},
                "Action": [
                    "kms:Create*",
                    "kms:Describe*",
                    "kms:Enable*",
                    "kms:List*",
                    "kms:Put*",
                    "kms:Update*",
                    "kms:Revoke*",
                    "kms:Disable*",
                    "kms:Get*",
                    "kms:Delete*",
                    "kms:ScheduleKeyDeletion",
                    "kms:CancelKeyDeletion"
                ],
                "Resource": "*"
            }
        ]
    })
)

key_id = key['KeyMetadata']['KeyId']
key_arn = key['KeyMetadata']['Arn']

# エイリアス作成
kms.create_alias(
    AliasName='alias/production-data-key',
    TargetKeyId=key_id
)

# データ暗号化（エンベロープ暗号化）
# 1. データキー生成
data_key = kms.generate_data_key(
    KeyId=key_arn,
    KeySpec='AES_256'
)
plaintext_data_key = data_key['Plaintext']
encrypted_data_key = data_key['CiphertextBlob']

# 2. データキーでデータ暗号化（アプリケーション側）
from cryptography.fernet import Fernet
import base64

fernet = Fernet(base64.b64encode(plaintext_data_key[:32]))
encrypted_data = fernet.encrypt(b"sensitive data here")

# 3. データキーをメモリから削除（平文保持しない）
del plaintext_data_key

# 4. 暗号化データキーとともに保存
storage = {
    'encrypted_data': encrypted_data,
    'encrypted_data_key': encrypted_data_key  # CMKで暗号化済み
}

エンベロープ暗号化の仕組み

┌─────────────────────────────────────────────────────────┐
│  エンベロープ暗号化                                        │
│                                                          │
│  KMS CMK ──→ データキー(DEK)生成                         │
│              ├── 平文DEK ──→ アプリでデータ暗号化         │
│              │              → 平文DEK削除                 │
│              └── 暗号化DEK ──→ 暗号化データと一緒に保存   │
│                                                          │
│  復号時:                                                  │
│  暗号化DEK → KMS Decrypt → 平文DEK → データ復号          │
│                                                          │
│  利点: 大量データをKMS APIを使わずに暗号化可能            │
│       （KMS APIはDEKの暗号化/復号のみ）                   │
└─────────────────────────────────────────────────────────┘

5.2 S3暗号化オプション

# S3オブジェクトをSSE-KMSで暗号化してアップロード
s3 = boto3.client('s3')

s3.put_object(
    Bucket='my-secure-bucket',
    Key='sensitive/data.csv',
    Body=csv_data,
    ServerSideEncryption='aws:kms',
    SSEKMSKeyId='arn:aws:kms:us-east-1:123456789012:key/xxxxxxxx',
    BucketKeyEnabled=True  # S3バケットキーでKMS API呼び出しを削減（コスト最適化）
)

# バケットデフォルト暗号化設定
s3.put_bucket_encryption(
    Bucket='my-secure-bucket',
    ServerSideEncryptionConfiguration={
        'Rules': [{
            'ApplyServerSideEncryptionByDefault': {
                'SSEAlgorithm': 'aws:kms',
                'KMSMasterKeyID': 'alias/production-data-key'
            },
            'BucketKeyEnabled': True
        }]
    }
)

5.3 転送中の暗号化

# S3: HTTPS強制（HTTP拒否）バケットポリシー
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyHTTP",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::my-bucket",
        "arn:aws:s3:::my-bucket/*"
      ],
      "Condition": {
        "Bool": {"aws:SecureTransport": "false"}
      }
    }
  ]
}

# ALB: HTTPをHTTPSにリダイレクト
{
  "Type": "redirect",
  "RedirectConfig": {
    "Protocol": "HTTPS",
    "Port": "443",
    "StatusCode": "HTTP_301"
  }
}

# RDS: SSL/TLS接続強制
# PostgreSQLの場合:
# rds.force_ssl = 1 (パラメータグループ設定)

5.4 AWS Secrets Manager

# シークレット作成・自動ローテーション
secretsmanager = boto3.client('secretsmanager')

# シークレット作成
secretsmanager.create_secret(
    Name='prod/myapp/database',
    SecretString=json.dumps({
        'engine': 'mysql',
        'host': 'prod-db.cluster-xxxx.us-east-1.rds.amazonaws.com',
        'username': 'admin',
        'password': 'MySecretPassword123!',
        'dbname': 'production'
    }),
    KmsKeyId='alias/production-secrets-key'
)

# 自動ローテーション設定（RDS連携Lambda）
secretsmanager.rotate_secret(
    SecretId='prod/myapp/database',
    RotationLambdaARN='arn:aws:lambda:us-east-1:123456789012:function:SecretsManagerRDSMySQLRotation',
    RotationRules={
        'AutomaticallyAfterDays': 30,
        'Duration': '2h'
    },
    RotateImmediately=True
)

# アプリケーションからのシークレット取得
def get_db_credentials():
    client = boto3.client('secretsmanager')
    response = client.get_secret_value(SecretId='prod/myapp/database')
    return json.loads(response['SecretString'])

ドメイン6: セキュリティガバナンス（14%）

6.1 AWS Organizations + セキュリティ

セキュリティOU設計

Root
├── Security OU (セキュリティチームのみ)
│   ├── Security-Tooling Account (GuardDuty管理, Security Hub集約)
│   └── Log-Archive Account (全CloudTrailログ集約)
├── Infrastructure OU
│   └── Shared-Services Account (DNS, AD, Patch管理)
├── Workloads OU
│   ├── Production OU
│   │   ├── Prod-Account-A
│   │   └── Prod-Account-B
│   └── Development OU
│       └── Dev-Account-A
└── Sandbox OU (実験用・制限なし)

6.2 AWS Firewall Manager

# Firewall Manager: Organizations全体にWAF・Shield・SGポリシーを適用

fms = boto3.client('fms', region_name='us-east-1')

# WAFポリシーをOrganizations全体に適用
fms.put_policy(
    Policy={
        'PolicyName': 'org-waf-policy',
        'SecurityServicePolicyData': {
            'Type': 'WAFV2',
            'ManagedServiceData': json.dumps({
                'type': 'WAFV2',
                'defaultAction': {'type': 'ALLOW'},
                'overrideCustomerWebACLAssociation': True,
                'preProcessRuleGroups': [
                    {
                        'ruleGroupArn': None,
                        'managedRuleGroupIdentifier': {
                            'vendorName': 'AWS',
                            'managedRuleGroupName': 'AWSManagedRulesCommonRuleSet'
                        },
                        'overrideAction': {'type': 'NONE'},
                        'priority': 1,
                        'id': 'common-rule-set'
                    }
                ],
                'postProcessRuleGroups': [],
                'loggingConfiguration': {
                    'logDestinationConfigs': ['arn:aws:firehose:...']
                }
            })
        },
        'ResourceType': 'AWS::ElasticLoadBalancingV2::LoadBalancer',
        'ResourceTags': [],
        'ExcludeResourceTags': False,
        'RemediationEnabled': True,    # 自動修復
        'IncludeMap': {
            'ORG_UNIT': ['ou-xxxx-production']  # 本番OUのみ
        }
    }
)

6.3 AWS Audit Manager

# Audit Manager: コンプライアンス証拠の自動収集

auditmanager = boto3.client('auditmanager')

# フレームワーク（CIS AWS / PCI DSS / HIPAA等）でアセスメント作成
assessment = auditmanager.create_assessment(
    name='PCI-DSS-Q1-2026',
    assessmentReportsDestination={
        'destinationType': 'S3',
        'destination': 's3://audit-reports-bucket'
    },
    scope={
        'awsAccounts': [
            {'id': '123456789012', 'name': 'Production Account'}
        ],
        'awsServices': [
            {'serviceName': 'S3'},
            {'serviceName': 'RDS'},
            {'serviceName': 'IAM'}
        ]
    },
    roles=[
        {'roleArn': 'arn:aws:iam::123456789012:role/AuditManagerRole',
         'roleType': 'PROCESS_OWNER'}
    ],
    frameworkId='PCI-DSS-framework-id'
)

6.4 SOARアーキテクチャ（自動インシデント対応）

┌─────────────────────────────────────────────────────────────────┐
│                     SOAR Architecture                           │
│                                                                  │
│  GuardDuty Finding                                               │
│  Security Hub Finding  →  EventBridge  →  Step Functions        │
│  Config Non-Compliant                                            │
│                                                                  │
│  Step Functions ワークフロー:                                     │
│  1. Finding重大度確認                                            │
│  2. 対象リソース特定                                              │
│  3. 自動修復実行 (Lambda)                                        │
│  4. SNS通知 (PagerDuty/Slack)                                   │
│  5. Jira/ServiceNow チケット作成                                  │
│  6. Security Hub Findingステータス更新                            │
│  7. 証跡記録 (S3/CloudTrail)                                     │
└─────────────────────────────────────────────────────────────────┘

// Step Functions: インシデント対応ワークフロー
{
  "Comment": "Security Incident Response",
  "StartAt": "CheckSeverity",
  "States": {
    "CheckSeverity": {
      "Type": "Choice",
      "Choices": [
        {
          "Variable": "$.detail.severity",
          "NumericGreaterThanEquals": 7.0,
          "Next": "ImmediateResponse"
        },
        {
          "Variable": "$.detail.severity",
          "NumericGreaterThanEquals": 4.0,
          "Next": "StandardResponse"
        }
      ],
      "Default": "LowSeverityLog"
    },
    "ImmediateResponse": {
      "Type": "Parallel",
      "Branches": [
        {
          "StartAt": "IsolateResource",
          "States": {
            "IsolateResource": {
              "Type": "Task",
              "Resource": "arn:aws:lambda:us-east-1:123456789012:function:IsolateCompromisedResource",
              "End": true
            }
          }
        },
        {
          "StartAt": "NotifyOnCall",
          "States": {
            "NotifyOnCall": {
              "Type": "Task",
              "Resource": "arn:aws:states:::sns:publish",
              "Parameters": {
                "TopicArn": "arn:aws:sns:us-east-1:123456789012:security-oncall",
                "Message.{{CONTENT}}quot;: "States.Format('CRITICAL: {} in account {}', $.detail.type, $.detail.accountId)"
              },
              "End": true
            }
          }
        }
      ],
      "Next": "CreateTicket"
    },
    "CreateTicket": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:us-east-1:123456789012:function:CreateJiraTicket",
      "End": true
    }
  }
}

試験重要数値チートシート

10週間学習プラン

Week 1-2: IAMとアクセス制御

• [ ] IAMポリシー評価ロジック（全パス）
• [ ] SCP設計（Organizations構造）
• [ ] Permission Boundary ハンズオン
• [ ] IAM Identity Center + SAML フェデレーション
• [ ] AWS IAMシミュレーターで権限テスト

Week 3-4: ネットワークセキュリティ

• [ ] VPC多層防御設計
• [ ] AWS WAF ルール作成ハンズオン
• [ ] Network Firewall Inspection VPCパターン
• [ ] Shield Advanced設定
• [ ] PrivateLink/VPC Endpoint設計

Week 5-6: 検出・監視

• [ ] GuardDuty全脅威タイプ暗記
• [ ] Security Hub集約アーキテクチャ
• [ ] CloudTrail高度設定（組織証跡）
• [ ] VPC Flow Logs + Athena分析
• [ ] Amazon Macie PII検出

Week 7-8: データ保護・暗号化

• [ ] KMS CMK設計（キーポリシー詳細）
• [ ] エンベロープ暗号化の仕組み
• [ ] S3暗号化全オプション
• [ ] Secrets Manager自動ローテーション
• [ ] Certificate Manager + ACM Private CA

Week 9: インシデント対応・ガバナンス

• [ ] SOAR自動化（EventBridge + Step Functions）
• [ ] Audit Manager + Inspector
• [ ] Firewall Manager
• [ ] Config Rules自動修復

Week 10: 試験対策

• [ ] AWS公式模擬試験（全問解説）
• [ ] Tutorialsdojo模擬試験 × 3回
• [ ] 苦手分野の集中復習
• [ ] AWSセキュリティブログ・ホワイトペーパー精読

頻出問題パターンと解法

Q1: ルートアカウントの保護

問題: AWS Organizations の管理アカウント（旧マスターアカウント）のセキュリティ強化策？

解答:

1. ルートアカウントのMFA必須化（仮想/ハードウェアMFA）
2. ルートアクセスキーを削除（または作成しない）
3. CloudTrailでルートAPIコールを監視
4. SCPでメンバーアカウントのルート使用を検知（完全ブロックは不可）
5. アラーム: { $.userIdentity.type = "Root" } のCloudWatch Metric Filter

Q2: 最小権限のロール設計

問題: Lambda関数にS3バケットへの書き込み権限のみ付与する最適な方法？

解答: Lambda実行ロールにインラインポリシーで特定バケット・特定Prefix・s3:PutObjectのみ許可。Resourceをarn:aws:s3:::bucket-name/prefix/*と絞ること。

Q3: データ漏洩の検出と対応

問題: S3から大量データが外部へ転送されていることを検出・対応するサービスは？

解答:

• 検出: GuardDuty Exfiltration:S3/ObjectRead.Unusual、Macie
• 確認: CloudTrail Data Events、S3 Access Logs
• 対応: S3バケットポリシーで一時遮断、SCPでアカウント隔離
• 調査: Amazon Detective でアクセスパターン調査

Q4: 規制対応の証跡保管

問題: PCI DSS準拠のためCloudTrailログを7年間改ざん不可で保管する方法？

解答:

1. CloudTrail EnableLogFileValidation=True（ハッシュ検証）
2. S3 Object Lock（Compliance Mode、保持期間7年）
3. S3バケットにDeleteObject拒否ポリシー
4. S3 Glacier Deep Archiveに自動ライフサイクル移行

Q5: マルチアカウント GuardDuty集約

問題: 50アカウントの GuardDuty Findingを1箇所で管理する方法？

解答: セキュリティアカウントをGuardDuty管理者アカウントに設定。Organizations連携で全メンバーアカウントを自動登録。Security Hubでクロスアカウント集約。EventBridgeでクロスアカウントルール作成。

アーキテクチャ図

AWS セキュリティ多層防御アーキテクチャ

flowchart TB
    Internet["🌐 Internet"]

    subgraph Edge["エッジセキュリティ層"]
        Shield["Shield Advanced\n(DDoS防御 Layer3/4)"]
        CF["CloudFront\n(CDN + エッジ配信)"]
        WAF["WAF\n(SQLi/XSS/Bot防御)"]
    end

    subgraph Network["ネットワーク層"]
        NF["Network Firewall\n(IPS/IDS・ステートフル検査)"]
        NACL["Network ACL\n(サブネット境界)"]
        SG["Security Group\n(インスタンス境界)"]
    end

    subgraph App["アプリケーション層"]
        ALB["ALB"]
        EC2["EC2/ECS"]
    end

    subgraph Data["データ層"]
        RDS["RDS\n(暗号化: KMS)"]
        S3["S3\n(SSE-KMS+Object Lock)"]
    end

    subgraph Detect["検出・対応層"]
        GD["GuardDuty\n(脅威検出)"]
        Macie["Macie\n(PII検出)"]
        SecHub["Security Hub\n(集約・優先順位)"]
        CloudTrail["CloudTrail\n(全API監査)"]
    end

    Internet --> Shield --> CF --> WAF --> NF
    NF --> NACL --> SG --> ALB --> EC2
    EC2 --> RDS & S3
    GD & Macie & CloudTrail --> SecHub

    style Edge fill:#fee2e2,stroke:#dc2626
    style Network fill:#fef3c7,stroke:#d97706
    style App fill:#dbeafe,stroke:#3b82f6
    style Data fill:#dcfce7,stroke:#16a34a
    style Detect fill:#f3e8ff,stroke:#9333ea

インシデント対応自動化フロー

sequenceDiagram
    participant GD as GuardDuty
    participant EB as EventBridge
    participant SF as Step Functions
    participant Lambda as Lambda
    participant EC2 as EC2 (侵害疑い)
    participant SNS as SNS/PagerDuty
    participant Jira as Jira

    GD->>EB: Finding: HIGH severity\nUnauthorizedAccess:EC2/SSHBruteForce
    EB->>SF: インシデント対応ワークフロー起動
    SF->>Lambda: 重大度判定
    Lambda-->>SF: severity=8.0 (HIGH)
    SF->>Lambda: EC2隔離実行
    Lambda->>EC2: セキュリティグループ変更\n(全インバウンド遮断)
    Lambda->>EC2: EBSスナップショット取得\n(フォレンジック用)
    SF->>SNS: オンコール通知 (PagerDuty)
    SF->>Jira: インシデントチケット作成
    SF->>Lambda: Security Hub Finding更新\n(IN_PROGRESS)

本試験形式 模擬問題（詳細解説付き）

問題 1

企業のセキュリティチームがOrganizations内の全50アカウントでGuardDutyのFindingを一元管理したいと考えています。最も適切なアーキテクチャはどれですか？

• A. 各アカウントのGuardDuty Findingを個別に確認する
• B. 全アカウントのGuardDuty FindingをSNSトピックに集約する
• C. セキュリティアカウントをGuardDuty Organizations委任管理者に設定し、全メンバーアカウントを自動登録する
• D. 全アカウントのCloudTrailログをセキュリティアカウントのS3に集約してGuardDutyで分析する

問題 2

AWS KMSのカスタマーマネージドキー（CMK）を使ってS3のデータを暗号化しています。特定のIAMユーザーがS3オブジェクトを取得しようとしても KMS.KMSInvalidKeyUsageException エラーが発生します。原因として最も可能性が高いのはどれですか？

• A. S3バケットポリシーでそのユーザーのアクセスが拒否されている
• B. KMSキーポリシーにそのユーザーへの kms:Decrypt 権限がない
• C. CMKが無効化（Disabled）されている
• D. CMKのキーポリシーが空である

問題 3

企業の S3 バケットに機密データが保存されており、バケットへのパブリックアクセスが意図せず許可された場合に即座に検出・修復したい場合の最適な構成はどれですか？

• A. 定期的に AWS Trusted Advisor のレポートを確認する
• B. AWS Config ルール s3-bucket-public-access-prohibited + Remediation Action（SSM Automation）で自動修復する
• C. AWS Security Hub の CIS ベンチマーク標準を有効化する
• D. GuardDuty でS3パブリックアクセスの検出を有効化する

S3バケット設定変更（パブリックアクセス許可）
↓（数秒以内）
Config ルール評価: NON_COMPLIANT
↓
Remediation Action 実行
↓
SSM Automation: AWS-DisableS3BucketPublicReadWrite
↓
自動修復: パブリックアクセスブロック有効化
↓
CloudTrail + SNS 通知

問題 4

AWS CloudTrailのログが改ざんされていないことを定期的に検証したい場合、最も適切な方法はどれですか？

• A. S3バケットにバージョニングを有効化する
• B. CloudTrailの ValidateLogFile APIを使ってデジタル署名を検証する
• C. S3のアクセスログを別のバケットに保存する
• D. CloudTrailログをCloudWatchにリアルタイムで転送する

# CloudTrail ログ検証コマンド
aws cloudtrail validate-logs \
  --trail-arn arn:aws:cloudtrail:us-east-1:123456789012:trail/my-trail \
  --start-time 2026-01-01T00:00:00Z \
  --end-time 2026-01-15T23:59:59Z \
  --verbose
# 出力: ファイル毎に VALID または INVALID が表示される

問題 5

EC2 インスタンスが侵害されたという GuardDuty の HIGH Finding が発生しました。フォレンジック調査のためにインスタンスを保全しながら、本番トラフィックへの影響を最小化する手順として最も適切なものはどれですか？

• A. インスタンスを即座に終了（terminate）する
• B. インスタンスを停止（stop）してスナップショットを取得する
• C. インスタンスを隔離用セキュリティグループに移動し、EBSスナップショットを取得後に本番から切り離す
• D. AMIを作成して新しいインスタンスを起動する

問題 6

AWS WAF で特定のIPアドレス範囲（社内ネットワーク 203.0.113.0/24）からのアクセスのみを許可し、それ以外を全て拒否したい場合の設定として最も適切なものはどれですか？

• A. WAF ルールで 203.0.113.0/24 を Block に設定し、デフォルトアクションを Allow にする
• B. WAF IP セットに 203.0.113.0/24 を追加し、そのIPセットを Allow するルールを作成。デフォルトアクションを Block にする
• C. セキュリティグループで 203.0.113.0/24 からの HTTP/HTTPS のみ許可する
• D. Network ACL で 203.0.113.0/24 以外の全トラフィックを拒否する

問題 7

企業が PCI DSS 準拠のために、AWS 環境での「特権アクセス管理（PAM）」を実装したいと考えています。AWS において最もセキュアな管理者アクセス方法はどれですか？

• A. 管理者ユーザーに強力なパスワードと長期アクセスキーを付与する
• B. AWS IAM Identity Center で時間制限付きロールを割り当て、MFA必須で管理コンソールにアクセスする
• C. ルートアカウントに MFA を設定して管理者作業を行う
• D. 共有管理者アカウントを作成して管理チーム全員で使用する

IAM 上級：Permission Boundaries と ABAC

Permission Boundaries（許可境界）

Permission Boundary は IAM エンティティ（ユーザー/ロール）に設定できる 最大許可ポリシーです。

┌─────────────────────────────────────────────┐
│         有効な権限の決定ロジック              │
│                                             │
│  Identity-based Policy: S3:* + EC2:*        │
│  Permission Boundary:   S3:* のみ           │
│                                             │
│  有効な権限 = 両者の交差集合 = S3:*          │
│  (EC2 は Boundary にないので拒否)            │
└─────────────────────────────────────────────┘

主なユースケース:

• 開発者に IAM ユーザー作成権限を委任するが、作成されたユーザーの権限を自分以下に制限する
• AWS Organizations の委任管理シナリオ

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["iam:CreateUser", "iam:AttachUserPolicy"],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "iam:PermissionsBoundary": "arn:aws:iam::123456789012:policy/DeveloperBoundary"
        }
      }
    }
  ]
}

試験での問い方:

• 「開発者が過剰な権限を持つ IAM ユーザーを作成できないようにする方法」→ Permission Boundary
• 「SCP と Permission Boundary の違い」→ SCP は Organizations レベル（アカウント全体）、Permission Boundary は個別 IAM エンティティ

ABAC（Attribute-Based Access Control）

タグを使った動的なアクセス制御。リソースとプリンシパル両方のタグを照合します。

ユーザータグ: Department=Finance
リソースタグ: Department=Finance

→ アクセス許可（タグ一致）

ユーザータグ: Department=Engineering
リソースタグ: Department=Finance

→ アクセス拒否（タグ不一致）

ABAC ポリシー例:

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "s3:ExistingObjectTag/Department": "${aws:PrincipalTag/Department}"
    }
  }
}

ABAC vs RBAC 比較:

KMS 上級：キーポリシー・Grants・クロスアカウント

KMS キーポリシー詳細

KMS の キーポリシー はリソースベースポリシーの一種で、KMS キーへのアクセスを制御します。

重要な原則:

• KMS キーはキーポリシーを 必ず 持つ（空にできない）
• デフォルトキーポリシーは アカウントの root が全権限を持つ
• IAM ポリシーだけではキーにアクセスできない（キーポリシーでの明示的許可が必要）

{
  "Sid": "Enable IAM User Permissions",
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::123456789012:root"
  },
  "Action": "kms:*",
  "Resource": "*"
}

このステートメントがあると → IAM ポリシーで KMS 権限を付与可能 このステートメントが ない と → IAM ポリシーで権限を与えても KMS 操作不可

KMS Grants

Grants は一時的・プログラム的なキーアクセス委任の仕組みです。

CreateGrant → GrantToken 発行
    ↓
Grantee プリンシパルが GrantToken を使用
    ↓
指定されたオペレーション（Decrypt等）のみ実行可能
    ↓
RetireGrant / RevokeGrant で失効

Grants vs キーポリシーの違い:

クロスアカウント KMS

Account A (キー所有)          Account B (使用者)
┌─────────────────────┐      ┌─────────────────────┐
│ KMS Key             │      │                     │
│ キーポリシー:        │      │ IAM Policy:         │
│ "Allow Account B    │  →   │ "Allow kms:Decrypt  │
│  root"             │      │  on Account A key"  │
└─────────────────────┘      └─────────────────────┘

両方が必要！ どちらか一方では不十分

試験での問い方:

• 「KMS キーを別アカウントで使いたい」→ キーポリシーで相手アカウントを許可 + 相手側 IAM ポリシー
• 「キーポリシーを変更せずにキーアクセスを付与したい」→ Grants

セキュリティサービス詳細比較

GuardDuty 脅威インテリジェンス

GuardDuty が分析するデータソース:

┌──────────────────────────────────────────────────────┐
│                   GuardDuty                          │
│                                                      │
│  VPC Flow Logs → 異常なネットワーク通信               │
│  CloudTrail →   API コールの異常パターン              │
│  DNS Logs →     C2 (Command & Control) 通信           │
│  S3 Logs →      S3 への不審なアクセス                 │
│  EKS Audit →    Kubernetes API 異常                  │
│  RDS Logs →     DB への不審なログイン                 │
│  Lambda Logs → 異常なファンクション実行               │
└──────────────────────────────────────────────────────┘

GuardDuty 検出カテゴリ:

• Backdoor: マルウェア C2 通信
• Behavior: 異常なリソース使用
• CryptoCurrency: 暗号通貨マイニング
• Pentest: ペネトレーションテストツール検出
• Recon: 偵察活動（ポートスキャン等）
• Trojan: トロイの木馬的な動作
• UnauthorizedAccess: 不正アクセス試行

GuardDuty 自動応答:

GuardDuty 検出
    ↓
EventBridge ルール
    ↓
Lambda 関数 → IAM ユーザー無効化 / セキュリティグループ変更

Security Hub 統合管理

Security Hub は複数セキュリティサービスの 統合ダッシュボード です。

GuardDuty ─┐
Inspector  ─┤
Macie      ─┼─→ Security Hub → 統合ビュー + 自動化
IAM AA     ─┤
Firewall Mgr┘

セキュリティ標準サポート:

• AWS Foundational Security Best Practices (FSBP)
• CIS AWS Foundations Benchmark v1.2/v1.4
• PCI DSS v3.2.1
• NIST SP 800-53

Findings の重大度:

• CRITICAL (90-100): 即座の対応が必要
• HIGH (70-89): 速やかな対応
• MEDIUM (40-69): 計画的な対応
• LOW (1-39): 監視
• INFORMATIONAL (0): 情報提供

Macie 機密データ検出

Amazon Macie は S3 の 機密データ自動検出 サービスです。

S3 バケット スキャン
    ↓
機械学習 + パターンマッチング
    ↓
検出カテゴリ:
  - PII（個人識別情報）: 氏名/メアド/電話番号
  - 財務情報: クレジットカード番号/銀行口座
  - 医療情報: PHI（Protected Health Information）
  - 認証情報: APIキー/パスワード
  - 日本固有: マイナンバー/日本語住所

Macie 調査結果タイプ:

• Policy 調査結果: バケット設定の問題（パブリックアクセス等）
• Sensitive Data 調査結果: 機密データの検出

Amazon Inspector 脆弱性評価

Inspector はインフラの 脆弱性スキャン サービスです（v2 は自動化）。

• Inspector v2 スキャン対象:
• EC2 インスタンス → OS パッケージの CVE
• ECR コンテナイメージ → 既知の脆弱性
• Lambda 関数 → コードの依存ライブラリ脆弱性

Inspector vs GuardDuty vs Security Hub:

Amazon Detective 調査分析

Detective は セキュリティインシデントの根本原因調査 ツールです。

GuardDuty アラート
    ↓
Detective で深堀り
    ↓
グラフ分析（行動グラフ）:
  - どの IP から？
  - どの IAM ロールが使われた？
  - どのリソースにアクセスした？
  - タイムライン上でのパターン

GuardDuty → Detective ワークフロー: GuardDuty が「不審な API コール」を検出 → Detective でその API コールの前後の行動を分析 → 攻撃の全体像を把握

インシデントレスポンス手順

AWS セキュリティインシデント対応フレームワーク

検出 (Detect)
    ↓
分析 (Analyze)  ← Detective / CloudTrail / VPC Flow Logs
    ↓
封じ込め (Contain)
  - IAM ユーザー/ロール無効化
  - セキュリティグループ隔離
  - EC2 インスタンス停止/スナップショット
    ↓
根絶 (Eradicate)
  - 侵害リソースの削除
  - マルウェア除去
    ↓
復旧 (Recover)
  - クリーンなスナップショットから復元
  - 強化した設定で再デプロイ
    ↓
事後分析 (Post-Incident)
  - タイムライン作成
  - 再発防止策

EC2 インスタンス侵害対応

疑わしい EC2 インスタンス検出
    ↓
1. スナップショット取得（フォレンジック用）
2. 隔離セキュリティグループ適用（全インバウンド/アウトバウンドを拒否）
3. インスタンスからの IAM ロール削除
4. TerminationProtection を有効化
5. フォレンジック EC2 で EBS ボリュームをマウント分析
6. 元インスタンスは停止（削除はフォレンジック完了後）

試験での問い方:

• 「侵害された EC2 を削除せずに調査したい」→ スナップショット取得 + 隔離 SG 適用
• 「マルウェアが検出された後の最初の対応」→ 封じ込め（ネットワーク隔離）が最初

IAM 認証情報侵害対応

CloudTrail で不審な IAM API コール検出
    ↓
1. アクセスキーを即座に無効化（削除ではなく無効化）
2. 侵害されたキーで実行されたすべての API を CloudTrail で確認
3. 作成されたリソース（EC2/ユーザー/ロール）を特定
4. 不審なリソースを削除
5. パスワードリセット（該当ユーザー）
6. MFA を再設定
7. CloudTrail / Config で変更履歴を保全

S3 データ漏洩対応

Macie がパブリック S3 + 機密データを検出
    ↓
1. バケットのパブリックアクセスをブロック
2. バケットポリシー/ACL を確認・修正
3. アクセスログで誰がダウンロードしたか確認
4. AWS Macie の調査結果を Security Hub へエスカレーション
5. 必要に応じてデータ主体への通知

AWS 証跡・監査ログ完全ガイド

ログソース一覧と用途

CloudTrail 詳細設定

CloudTrail イベントタイプ:

• Management Events: API コール（デフォルト有効）
  • Write: リソース作成/変更/削除
  • Read: リソース一覧/詳細取得
• Data Events: S3 オブジェクト/Lambda 実行（追加設定が必要）
• Insights Events: 異常な API 使用パターン（追加費用）

CloudTrail セキュリティ設定:

証跡の改ざん防止:
  - Log File Validation 有効化 → SHA-256 ハッシュで整合性検証
  - S3 バケットの MFA Delete 有効化
  - S3 Object Lock (Compliance Mode) で不変性保証
  - 別アカウントの S3 バケットにログを集約

Organizations CloudTrail:

管理アカウント（Organization Trail 作成）
    ↓
全メンバーアカウントのイベントを自動収集
    ↓
中央 S3 バケットに集約
（メンバーアカウントは無効化不可）

ネットワークセキュリティ詳細

AWS WAF 詳細

WAF ルールの評価順序:

WebACL
  ├── ルール 1 (Priority 0): IP Set 許可ルール
  ├── ルール 2 (Priority 1): Rate-Based ルール（DDoS 対策）
  ├── ルール 3 (Priority 2): AWS Managed Rules（OWASP Top 10）
  └── デフォルトアクション: Block

AWS マネージドルールグループ:

• AWSManagedRulesCommonRuleSet: OWASP Top 10 基本対策
• AWSManagedRulesSQLiRuleSet: SQL インジェクション
• AWSManagedRulesKnownBadInputsRuleSet: 既知の悪意あるパターン
• AWSManagedRulesAmazonIpReputationList: 悪意ある IP
• AWSManagedRulesBotControlRuleSet: ボット対策

WAF Captcha / Challenge:

• Captcha: 人間確認（画像認証）
• Challenge: JavaScript チャレンジ（ボット判定）

AWS Shield Advanced

Shield Advanced の追加機能:

Shield Standard（無料）:
  - L3/L4 DDoS 自動防御
  - SYN Flood, UDP Reflection 等

Shield Advanced（有料: $3,000/月〜）:
  - L7 DDoS 対応（WAF 統合）
  - DDoS コストプロテクション（スパイク課金の払い戻し）
  - Shield Response Team (SRT) へのアクセス
  - Advanced Visibility（リアルタイム DDoS 可視化）
  - Proactive Engagement（AWS が能動的に連絡）

試験での問い方:

• 「DDoS 攻撃中に AWS サポートへ迅速にエスカレーション」→ Shield Advanced + SRT
• 「DDoS による急激なコスト増加を防ぐ」→ Shield Advanced のコストプロテクション

VPC セキュリティ詳細

セキュリティグループ vs NACL 詳細:

セキュリティグループ（SG）:
  ステートフル → 戻りトラフィック自動許可
  インスタンスレベル（ENI に付与）
  ルール: 許可ルールのみ（拒否ルールなし）
  評価: すべてのルールを評価して最終判断

NACL（Network ACL）:
  ステートレス → 送受信を個別にルール設定
  サブネットレベル
  ルール: 許可 + 拒否ルール
  評価: ルール番号順（最初にマッチしたら終了）

NACL エフェメラルポート:

• クライアント(1024-65535) → サーバー(80/443)
• インバウンドルール: ポート 80/443 を許可
• アウトバウンドルール: ポート 1024-65535 を許可（エフェメラル）
• これを忘れると「インバウンドは許可したのに通信できない」になる！

VPC Endpoint セキュリティ:

Gateway Endpoint (S3, DynamoDB):
  ルートテーブルに自動追加
  エンドポイントポリシーで S3 バケット制限可能

Interface Endpoint (その他 AWS サービス):
  ENI として VPC 内に配置
  プライベートリンク（インターネット不要）
  セキュリティグループで制御可能

暗号化・データ保護

S3 暗号化完全ガイド

サーバーサイド暗号化（SSE）:

SSE-S3:
  鍵管理: AWS（S3 が自動管理）
  ヘッダー: x-amz-server-side-encryption: AES256
  コスト: 追加なし
  監査: 不可（S3 が自動管理）

SSE-KMS:
  鍵管理: AWS KMS（カスタマー管理鍵で制御可能）
  ヘッダー: x-amz-server-side-encryption: aws:kms
  コスト: KMS API コール料金
  監査: CloudTrail で KMS API 記録
  特徴: キーポリシーで細かい制御可能

SSE-C:
  鍵管理: お客様（リクエストごとに鍵を提供）
  AWS は鍵を保存しない
  コンソールでは使用不可（API/CLI のみ）
  注意: 鍵を失うとデータ復号不可

クライアントサイド暗号化（CSE）:
  アップロード前にクライアントが暗号化
  AWS は暗号化データのみ受け取る

試験での問い方:

• 「S3 の暗号化で最も管理が楽」→ SSE-S3
• 「KMS での S3 暗号化で誰がいつアクセスしたか監査したい」→ SSE-KMS
• 「鍵をクライアント管理したい」→ SSE-C

ACM (AWS Certificate Manager)

ACM の主な機能:
  SSL/TLS 証明書の無料発行（パブリック）
  自動更新（有効期限切れを防ぐ）

対応ロードバランサー:
  ALB, NLB, CloudFront, API Gateway

証明書タイプ:
  ドメイン認証（DV）: 最速発行
  組織認証（OV）: 企業確認
  拡張認証（EV）: 最も厳格

ACM Private CA:
  プライベート証明書を発行
  内部サービス用
  費用: 月額 $400〜

重要: ACM 証明書は EC2 インスタンスに直接インストール不可
（ALB/NLB/CloudFront/API GW のみ）

Secrets Manager vs Parameter Store

AWS Secrets Manager:
  シークレット（DB パスワード等）の管理
  自動ローテーション（Lambda 関数）
  クロスアカウントアクセス可能
  料金: $0.40/シークレット/月 + API コール
  
  自動ローテーション対応:
    - RDS（MySQL/PostgreSQL/Oracle/MSSQL）
    - Redshift
    - DocumentDB
    - カスタム Lambda

SSM Parameter Store:
  設定値・シークレットの格納
  Standard Tier: 無料（10,000 パラメータまで）
  Advanced Tier: $0.05/パラメータ/月
  SecureString: KMS 暗号化
  自動ローテーション: なし（手動または Lambda）

選択基準:
  DB パスワードの自動ローテーション → Secrets Manager
  アプリ設定値 + 低コスト → Parameter Store
  大量のパラメータ → Parameter Store（コスト効率）

AWS Organizations セキュリティ

SCP（サービスコントロールポリシー）設計

Organizations 構造:
Root
  ├── Security OU
  │     └── Security Account（GuardDuty/SecurityHub 管理）
  ├── Infrastructure OU
  │     └── Network Account（Transit Gateway/Route 53）
  ├── Production OU
  │     ├── App-A Account
  │     └── App-B Account
  └── Sandbox OU
        └── Dev Accounts

SCP ユースケース別設計:

Root レベル SCP:
  - 特定リージョンへのアクセス制限
  - AWS サポートプランの変更禁止
  - Organizations 操作の禁止

Production OU SCP:
  - IAM ユーザー作成禁止（SSO のみ）
  - CloudTrail 無効化禁止
  - GuardDuty 無効化禁止

Sandbox OU SCP:
  - 本番環境リソースへのアクセス禁止
  - 高コストリソース（大型 EC2 等）禁止

SCP の重要な制限:

• 管理アカウントには SCP が 適用されない
• 許可リスト方式と拒否リスト方式を使い分ける
• SCP は権限を「付与」しない（上限を設定するだけ）

AWS Control Tower

Control Tower コンポーネント:
  Landing Zone → 安全なマルチアカウント環境
  Controls（Guardrails）→ 予防/検出/プロアクティブ制御
  Account Factory → 自動アカウントプロビジョニング
  
Control の種類:
  Preventive（予防）: SCP で実装、違反を事前に防ぐ
  Detective（検出）: AWS Config で実装、違反を検出
  Proactive（プロアクティブ）: CloudFormation Hooks で実装
  
ガードレール例:
  必須: MFA on Root、CloudTrail 有効化（無効化不可）
  強く推奨: S3 パブリックアクセスブロック
  選択的: 各 OU の要件に応じて選択

模擬試験（65問）

問題 1

あなたのチームは、AWS CloudTrail ログが改ざんされていないことを定期的に検証したいと考えています。最もコスト効率の高い方法はどれですか？

• A. すべての CloudTrail ログを別の AWS アカウントの S3 バケットに保存する
• B. CloudTrail の「ログファイルの検証」機能を有効にし、AWS CLI の validate-logs コマンドを使用する
• C. Lambda 関数でログファイルを定期的にハッシュ計算して比較する
• D. CloudWatch Logs に CloudTrail を転送して、メトリクスフィルターで監視する

問題 2

EC2 インスタンスが感染マルウェアにより C2 サーバーと通信していることが判明しました。フォレンジック調査のために最初に実施すべきことはどれですか？

• A. インスタンスを即座に終了する
• B. EBS ボリュームのスナップショットを取得し、インスタンスを隔離セキュリティグループに移動する
• C. インスタンスの OS レベルでマルウェアを削除する
• D. インスタンスを停止して AWS サポートに連絡する

問題 3

マルチアカウント環境で、すべてのアカウントに対してルートアカウントの使用を禁止したいと考えています。最も効果的な方法はどれですか？

• A. 各アカウントで IAM パスワードポリシーを強化する
• B. Organizations の SCP でルートアカウントの全 API を拒否する
• C. AWS Config ルールで root アカウント使用を検出してアラートを出す
• D. GuardDuty の RootCredentialUsage 検出を有効にする

{
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "StringLike": {
      "aws:PrincipalArn": "arn:aws:iam::*:root"
    }
  }
}

問題 4

AWS KMS で管理するカスタマーマネージドキー（CMK）を使用して S3 バケットを暗号化しています。別のアカウントのユーザーが、このバケット内のオブジェクトを復号できるようにしたいと考えています。必要な設定はどれですか？（2つ選択）

• A. CMK のキーポリシーで別アカウントのプリンシパルを許可する
• B. CMK を別アカウントにコピーする
• C. 別アカウントの IAM ポリシーで CMK の kms:Decrypt を許可する
• D. S3 バケットポリシーで別アカウントを許可する
• E. CMK を AWS マネージドキーに変更する

問題 5

Amazon Inspector v2 で EC2 インスタンスの脆弱性スキャンを実施したところ、多数の HIGH 重大度の発見事項がありました。これらを自動的に修復するための最善のアプローチはどれですか？

• A. Inspector の「自動修復」ボタンをクリックする
• B. Security Hub と連携して自動修復ワークフローを構築する
• C. Inspector の調査結果を EventBridge で受け取り、Lambda または SSM Automation で修復を自動化する
• D. AWS Config の自動修復機能を使用する

問題 6

企業の AWS 環境で PCI DSS 準拠のため、すべての S3 バケットに保存されている PAN（プライマリアカウント番号）データを特定する必要があります。最適なサービスはどれですか？

• A. AWS Config でカスタムルールを作成する
• B. Amazon Macie を有効にして機密データ検出を実行する
• C. Lambda 関数で全 S3 オブジェクトをスキャンする
• D. AWS Trusted Advisor のセキュリティチェックを使用する

問題 7

AWS Organizations を使用している企業で、セキュリティチームのみが GuardDuty を管理できるようにしたいと考えています。また、メンバーアカウントが GuardDuty を無効化できないようにする必要があります。どのように実装しますか？

• A. GuardDuty の委任管理者をセキュリティアカウントに設定し、SCP でメンバーアカウントの GuardDuty 無効化を禁止する
• B. 各アカウントに GuardDuty を個別に設定し、IAM ポリシーで制御する
• C. Control Tower のガードレールで GuardDuty を必須設定にする
• D. A と C の両方

問題 8

開発チームが AWS Secrets Manager に保存されている RDS パスワードを自動ローテーションしたいと考えています。実装に必要な要素はどれですか？（2つ選択）

• A. Lambda 関数を使ってローテーションロジックを実装する
• B. AWS Key Management Service でカスタムキーを作成する
• C. Secrets Manager にローテーションを有効にして間隔を設定する
• D. CloudWatch Events でスケジュールを設定する
• E. RDS インスタンスに Secrets Manager エンドポイントへのアクセスを許可する

問題 9

VPC 内のプライベートサブネットにある EC2 インスタンスが S3 にアクセスする必要がありますが、インターネットを経由させたくないと考えています。最もセキュアなアプローチはどれですか？

• A. NAT ゲートウェイを使用してインターネット経由でアクセスする
• B. S3 ゲートウェイエンドポイントを VPC に設定し、エンドポイントポリシーで S3 バケットを制限する
• C. VPN を使用して S3 にアクセスする
• D. VPC ピアリングを使用して S3 にアクセスする

問題 10

AWS WAF を使用しているアプリケーションで、特定の IP アドレスレンジからの DDoS 攻撃を検出しました。手動でブロックする代わりに、今後の攻撃を自動的にブロックするメカニズムを構築したい場合、最適なアーキテクチャはどれですか？

• A. WAF の IP セットを手動で更新する
• B. GuardDuty 検出結果 → EventBridge → Lambda → WAF IP セット自動更新
• C. Shield Advanced を有効にして自動的に対応させる
• D. CloudFront の Geo Restriction を使用する

GuardDuty (脅威検出)
    ↓
EventBridge (イベントルール)
    ↓
Lambda (WAF IP セット更新)
    ↓
WAF (新しいブロックルール適用)

問題 11

企業がコンプライアンス要件として、すべての AWS API 呼び出しに対して誰が・いつ・何をしたかを 7 年間保持する必要があります。CloudTrail ログの長期保存に最適な設定はどれですか？

• A. CloudTrail を CloudWatch Logs に転送し、ロググループのリテンションを 7 年に設定する
• B. CloudTrail ログを S3 に保存し、S3 Glacier Deep Archive ライフサイクルルールと S3 Object Lock（Compliance モード）を設定する
• C. CloudTrail ログを DynamoDB に保存して 7 年間保持する
• D. CloudTrail ログを別の AWS リージョンに定期的にコピーする

問題 12

IAM ロールの権限境界（Permission Boundary）を使用するシナリオとして最も適切なのはどれですか？

• A. 組織全体の AWS サービス利用を制限する
• B. 開発チームに IAM ユーザー作成権限を与えつつ、作成できるユーザーの最大権限を制限する
• C. 特定の S3 バケットへのアクセスをリソースレベルで制御する
• D. マルチアカウント環境でのクロスアカウントアクセスを管理する

問題 13

Amazon Macie でスキャンした結果、開発環境の S3 バケットに本番の個人情報データが誤ってコピーされていることが判明しました。即座に実施すべき対応として正しい順序はどれですか？

• A. バケット内のオブジェクトを削除 → バケットのパブリックアクセスをブロック → アクセスログを確認
• B. バケットのパブリックアクセスをブロック → アクセスログで外部アクセスを確認 → データを安全に移動/削除 → インシデントレポート作成
• C. IT 担当者に連絡 → 週次レビューを待つ → 対応を計画する
• D. データを暗号化してそのまま保持する

問題 14

AWS Network Firewall と AWS WAF を組み合わせて使用する場合、それぞれが担当すべきセキュリティ層はどれですか？

• A. Network Firewall: L7 HTTP 検査 / WAF: L3/L4 フィルタリング
• B. Network Firewall: L3/L4 + Stateful IPS / WAF: L7 HTTP/HTTPS アプリケーション保護
• C. 両者は同じ機能を提供するため、どちらか一方で十分
• D. Network Firewall: インターネット対向 / WAF: 内部トラフィック

インターネット
    ↓
AWS Network Firewall（L3/L4 + Stateful IPS）
  - IP/ポートフィルタリング
  - プロトコル検査
  - Suricata ルール（IDS/IPS）
    ↓
AWS WAF（L7 HTTP/HTTPS）
  - SQLi/XSS 防御
  - レートリミット
  - OWASP Top 10
    ↓
アプリケーション（ALB/CloudFront）

問題 15

ある企業では、Lambda 関数がデータベースのパスワードをコード内にハードコードしており、セキュリティ監査で指摘されました。最もセキュアな修正方法はどれですか？

• A. パスワードを環境変数に移動する
• B. パスワードを AWS Secrets Manager に保存し、Lambda 実行時に API で取得する
• C. パスワードを S3 の非公開バケットに保存する
• D. Lambda のコードをプライベートリポジトリに移動する

import boto3
client = boto3.client('secretsmanager')
secret = client.get_secret_value(SecretId='prod/db/password')

問題 16

AWS Security Hub を導入してセキュリティスコアを向上させたいと考えています。FSBP（AWS Foundational Security Best Practices）の「EC2.8」コントロール（IMDSv2 の強制）に失敗しているインスタンスを一括修正するための最善のアプローチはどれですか？

• A. Security Hub から直接「修正」ボタンを押す
• B. Security Hub の調査結果をもとに Systems Manager Automation を実行して IMDSv2 を有効化する
• C. 各インスタンスに SSH でログインして手動設定する
• D. 影響を受けるインスタンスを停止して新しい AMI から再起動する

Security Hub (FSBP EC2.8 失敗)
    ↓
EventBridge (Security Hub 調査結果イベント)
    ↓
SSM Automation (AWS-ConfigureIMDSv2 ドキュメント)
    ↓
全対象インスタンスで IMDSv2 強制設定

問題 17

企業が AWS への移行において、オンプレミスの Active Directory を IdP として使用して AWS Console へのシングルサインオン（SSO）を実現したいと考えています。推奨されるアーキテクチャはどれですか？

• A. AD のユーザーを IAM ユーザーに手動で複製する
• B. AWS Directory Service (AD Connector) + IAM Identity Center で SSO を実現する
• C. 各ユーザーが AWS CLI のアクセスキーを使用する
• D. SAML 2.0 を直接 IAM ロールに設定する

オンプレ AD
    ↓
AD Connector（既存 AD と AWS の橋渡し）
    ↓
IAM Identity Center
    ↓
Permission Sets → AWS アカウントへのアクセス

問題 18

CloudTrail で S3 データイベントを有効にせずに、誰が特定の S3 オブジェクトをダウンロードしたかを確認する方法として最も有効なのはどれですか？

• A. VPC Flow Logs で確認する
• B. S3 サーバーアクセスログを有効にして確認する
• C. GuardDuty で確認する
• D. AWS Config で確認する

問題 19

AWS Config を使用して、S3 バケットのパブリックアクセスが有効化された場合に自動的にブロックするソリューションを構築したいと考えています。最適な構成はどれですか？

• A. Config ルール（s3-bucket-public-read-prohibited）+ 自動修復アクション（SSM Automation: AWS-DisableS3BucketPublicReadWrite）
• B. CloudWatch Events で S3 のバケット作成を検知して Lambda で設定確認
• C. AWS Trusted Advisor アラートを設定する
• D. GuardDuty の S3 保護を有効にする

Config ルール: s3-bucket-public-read-prohibited
    ↓ 非準拠検出
自動修復アクション
    ↓
SSM Automation: AWS-DisableS3BucketPublicReadWrite
    ↓
S3 バケットのパブリックアクセスを自動ブロック

問題 20

企業のセキュリティポリシーで、本番環境の AWS リソースへの変更はすべて変更管理プロセスを経る必要があります。インフラエンジニアが本番環境で承認なしに変更を加えた場合に即座に検知する方法はどれですか？

• A. CloudTrail + CloudWatch Logs メトリクスフィルター + SNS アラートを設定する
• B. AWS Config で全リソースの変更を記録し、承認外変更を検知してアラートを発行する
• C. IAM ポリシーで本番環境へのアクセスをすべて禁止する
• D. 週次で CloudTrail ログを手動確認する

CloudTrail（API ログ）
    ↓
CloudWatch Logs（転送）
    ↓
メトリクスフィルター（特定の操作パターンを検知）
    ↓
CloudWatch アラーム → SNS → 担当者へ通知

問題 21

AWS KMS の CMK（カスタマーマネージドキー）を使用して暗号化した EBS ボリュームを別の AWS アカウントに共有したいと考えています。手順として正しいものはどれですか？

• A. EBS スナップショットを直接別アカウントに共有する
• B. CMK キーポリシーで別アカウントを許可 → EBS スナップショットを別アカウントのキーで再暗号化して共有
• C. EBS ボリュームを復号化してから共有する
• D. AWS Backup を使用して別アカウントにバックアップする

問題 22

AWS Firewall Manager を使用する主な利点はどれですか？

• A. すべての VPC セキュリティグループを自動的に最適化する
• B. Organizations 全体のセキュリティポリシー（WAF/Shield/SG/Network Firewall）を一元管理・自動適用する
• C. インスタンスの脆弱性スキャンを自動化する
• D. CloudTrail ログの分析を自動化する

問題 23

Lambda 関数に付与する IAM ロールの最小権限設計で最も適切なアプローチはどれですか？

• A. AdministratorAccess マネージドポリシーを付与して開発を簡単にする
• B. Lambda 関数が必要とする特定のサービス・リソースに対してのみ権限を付与し、IAM Access Analyzer で過剰な権限を定期的に確認する
• C. Lambda 関数ごとに同じ共通ロールを使用してロール数を減らす
• D. Lambda 関数の権限は VPC 内であれば制限不要

問題 24

企業が AWS Well-Architected Framework のセキュリティの柱において「全レイヤーでのセキュリティ適用」を実現するために採用すべき「多層防御」のアーキテクチャはどれですか？

• A. 境界に強力なファイアウォールを 1 つ設置する
• B. ネットワーク層（WAF/Shield）+ トランスポート層（SG/NACL）+ アプリ層（認証/認可）+ データ層（暗号化）を組み合わせる
• C. すべての EC2 インスタンスに同じセキュリティグループを適用する
• D. AWS Managed Services を使用してセキュリティ責任を AWS に委託する

インターネット
    ↓ Shield (DDoS防御)
    ↓ WAF (L7フィルタリング)
    ↓ CloudFront (CDN + セキュリティヘッダー)
    ↓ ALB + SG (L4フィルタリング)
    ↓ EC2 インスタンス + OS ファイアウォール
    ↓ アプリケーション認証・認可
    ↓ RDS + 暗号化 + SG
    ↓ KMS (暗号化キー管理)

問題 25

AWS Organizations のセキュリティ設定として、「すべてのメンバーアカウントで東京リージョン（ap-northeast-1）以外のリソース作成を禁止する」SCP を作成したいと考えています。正しいポリシーはどれですか？

A:

{
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "StringNotEquals": {"aws:RequestedRegion": "ap-northeast-1"}
  }
}

B:

{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "StringEquals": {"aws:RequestedRegion": "ap-northeast-1"}
  }
}

C:

{
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "StringEquals": {"aws:RequestedRegion": "us-east-1"}
  }
}

D: グローバルサービス（IAM等）も含めて制限されるため、実装不可能

"Condition": {
  "StringNotEqualsIfExists": {
    "aws:RequestedRegion": "ap-northeast-1"
  },
  "Null": {
    "aws:RequestedRegion": "false"
  }
}

問題 26〜65（追加問題）

問題 26: GuardDuty の「Credential:IAMUser/AnomalousBehavior」検出タイプが発生した場合、最初に確認すべきことは？ → 正解: CloudTrail でその IAM ユーザーの最近の API コールを確認し、不審な操作（新規ユーザー作成、権限変更、未知のリージョンでの操作）を特定する

問題 27: AWS Certificate Manager（ACM）でプロビジョニングした証明書を EC2 インスタンスに直接インストールできますか？ → 正解: できない。ACM 証明書は ALB/NLB/CloudFront/API GW のみで使用可能。EC2 への直接インストールには ACM Private CA またはサードパーティ証明書が必要。

問題 28: CloudHSM と KMS の違いは？ → 正解: CloudHSM は専用の物理 HSM モジュール（FIPS 140-2 Level 3）、KMS はマルチテナントのマネージドサービス（FIPS 140-2 Level 2/3 HSM バックエンド）。CloudHSM は鍵の完全な顧客管理が必要な金融機関等向け。

問題 29: VPC Peering と AWS PrivateLink の違いは？ → 正解: VPC Peering は VPC 間の完全なネットワーク接続（双方向）、PrivateLink はサービスエンドポイントを提供（一方向、サービス公開）。重複 CIDR がある場合は PrivateLink を使用。

問題 30: S3 Object Lock の Compliance モードと Governance モードの違いは？ → 正解: Compliance モードは root を含む誰も削除不可（変更不可）。Governance モードは s3:BypassGovernanceRetention 権限を持つユーザーが変更可能。コンプライアンス要件には Compliance モード。

問題 31: AWS Config と CloudTrail の違いは？ → 正解: CloudTrail は API コールのログ（誰が何の操作をしたか）。AWS Config はリソースの設定状態の変化を記録（リソースがどのような状態になったか）。Config は「現在の設定」と「設定変更の履歴」を管理。

問題 32: IAM ポリシーの評価ロジックで「明示的な Deny」と「暗黙的な Deny」の違いは？ → 正解: デフォルト（暗黙的）Deny は、Allow ルールがない場合に自動的に拒否。明示的 Deny は、Allow があっても上書きして拒否。SCP/Permission Boundary/リソースポリシーすべての明示的 Deny が最優先。

問題 33: AWS WAF の「マネージドルール」を使用する利点は？ → 正解: AWS や AWS Marketplace パートナーが管理する事前定義ルール。OWASP Top 10、既知の悪意ある IP、ボット対策などを手動ルール作成なしに利用可能。定期的に AWS が更新する。

問題 34: Route 53 の DNS Security Extensions（DNSSEC）の目的は？ → 正解: DNS キャッシュポイズニング攻撃を防ぐ。DNS レスポンスにデジタル署名を追加し、レスポンスの真正性を検証。Route 53 はホストゾーンの DNSSEC 署名と DNS レコードの DNSSEC 検証をサポート。

問題 35: Amazon Cognito の User Pool と Identity Pool の違いは？ → 正解: User Pool は認証（Authentication）を提供 - ユーザーディレクトリ、ログイン機能。Identity Pool は認可（Authorization）を提供 - AWS リソースへのアクセス用一時認証情報を発行。両者を組み合わせて使用するのが一般的。

問題 36: AWS WAF の Rate-Based ルールの用途は？ → 正解: 特定の IP アドレスからのリクエストが閾値（例: 5分間に 2000 リクエスト）を超えた場合に自動的にブロック。DDoS・ブルートフォース・スクレイピング対策。

問題 37: CloudTrail の「Management Events」と「Data Events」の違いは？ → 正解: Management Events（デフォルト有効）はコントロールプレーン操作（EC2 起動、IAM ポリシー変更等）。Data Events（追加設定・追加料金）はデータプレーン操作（S3 GetObject、Lambda 実行等）。大量発生するため別途有効化。

問題 38: IAM Access Analyzer の主な機能は？ → 正解: (1) 外部プリンシパルからアクセス可能なリソースを検出（クロスアカウント/パブリックアクセス）、(2) 未使用の権限を特定して最小権限の実現を支援、(3) IAM ポリシーの構文・セキュリティ検証。

問題 39: AWS Security Hub が「集約リージョン」機能を提供する理由は？ → 正解: マルチリージョン環境で全リージョンのセキュリティ調査結果を 1 つのリージョンに集約表示するため。セキュリティチームが複数リージョンのコンソールを切り替えることなく全体のセキュリティ状況を把握できる。

問題 40: VPC Flow Logs で記録されない情報はどれですか？ → 正解: HTTP リクエストのペイロード内容（パケットの中身）は記録されない。Flow Logs は IP アドレス・ポート・プロトコル・バイト数・アクション（ACCEPT/REJECT）を記録するが、アプリケーションレベルのデータは含まない。

問題 41: AWS Organizations の「信頼されたアクセス（Trusted Access）」とは何ですか？ → 正解: AWS サービス（GuardDuty, Security Hub, Config 等）が Organizations の全メンバーアカウントにまたがって動作することを許可する機能。管理アカウントで有効化することで、委任管理者が組織全体を一元管理できる。

問題 42: AWS KMS の「キーローテーション」の動作は？ → 正解: CMK の自動ローテーション（年 1 回）を有効にすると、新しいキーマテリアルが生成され、以降の暗号化に使用される。古いキーマテリアルは過去のデータの復号用に保持される。ユーザーは意識せずに最新の鍵で暗号化が行われる。

問題 43: AWS Artifact の用途は？ → 正解: AWS のコンプライアンスレポート（ISO/PCI DSS/SOC レポート等）と AWS との契約書（NDA/BAA 等）を取得するセルフサービスポータル。コンプライアンス監査時に必要な AWS 側の証跡書類を入手できる。

問題 44: S3 バケットの MFA Delete を有効にした場合の効果は？ → 正解: バケットのバージョン管理を無効にする操作、またはオブジェクトの特定バージョンを完全削除する操作に MFA 認証が必要になる。誤削除や不正削除を防ぐ。有効化にはルートアカウントが必要（IAM ユーザー不可）。

問題 45: AWS PrivateLink の主なユースケースは？ → 正解: VPC から AWS サービスや他の VPC のサービスへの接続をインターネットを介さずにプライベートに接続する。SaaS サービスプロバイダーが顧客 VPC に安全にサービスを提供する場合にも使用（重複 CIDR の問題を回避）。

問題 46: IAM ロールの「信頼ポリシー（Trust Policy）」の役割は？ → 正解: ロールを引き受ける（AssumeRole）ことができるプリンシパルを定義する。「誰がこのロールを使用できるか」を制御。例: EC2 サービスが sts:AssumeRole できる、別アカウントのロールが引き受けられる等。

問題 47: Amazon Detective と Amazon GuardDuty の役割分担は？ → 正解: GuardDuty は脅威の「検出」（アラート発生）。Detective は検出された脅威の「調査・根本原因分析」。GuardDuty のアラートから Detective で「その脅威がどのように発生したか」を時系列グラフで分析。

問題 48: CloudFormation スタックの「ドリフト検出」のセキュリティ上の意義は？ → 正解: CloudFormation で定義した設定からの手動変更（ドリフト）を検出。セキュリティ設定が承認なしに変更された場合（SG ルールの追加等）を特定し、コンプライアンス違反を発見できる。

問題 49: AWS Systems Manager Session Manager のセキュリティ上の利点は？ → 正解: SSH/RDP ポートを開放することなく EC2 インスタンスにアクセス可能。インバウンドポート不要 → 攻撃面の削減。すべてのセッションは CloudTrail + S3/CloudWatch Logs に記録 → 完全な監査証跡。踏み台サーバー不要。

問題 50: SAML 2.0 フェデレーションと OIDC フェデレーションの違いは？ → 正解: SAML 2.0 は主に企業の IdP（AD FS, Okta 等）との統合に使用（Web コンソール SSO）。OIDC は Web/モバイルアプリでの Google/Facebook 等のソーシャル認証や Cognito との統合に使用。Kubernetes の IRSA も OIDC を使用。

問題 51: Amazon Macie のカスタム識別子（Custom Identifier）の用途は？ → 正解: 組織固有の機密データパターンを正規表現で定義してスキャンできる機能。例: 社員番号（EMP-\d{6}）、独自の口座番号形式など、Macie のデフォルトパターンでは検出できないデータを対象にできる。

問題 52: AWS Config の「コンフォーマンスパック（Conformance Pack）」とは？ → 正解: 複数の Config ルールと修復アクションをテンプレート化したパッケージ。PCI DSS、CIS Benchmark 等のコンプライアンスフレームワークを一括で Config ルールとして展開可能。AWS が提供するサンプルパックも利用可能。

問題 53: AWS Control Tower の「必須ガードレール」の例は？ → 正解: 無効化できない必須制御。例: CloudTrail の有効化禁止（メンバーアカウントが無効化不可）、ルートアカウントの MFA 要求、ログアーカイブアカウントへのアクセス制限。これらは Landing Zone の基本セキュリティ保証。

問題 54: AWS Shield Advanced の「DDoS コストプロテクション」の具体的な内容は？ → 正解: DDoS 攻撃によるトラフィックスパイクで増加した AWS の課金（EC2、ELB、CloudFront、Route 53）を Shield Advanced が負担する（クレジット申請）。攻撃を受けてもコスト増加を防ぐ保険的機能。

問題 55: IAM の「パスワードポリシー」と MFA の関係は？ → 正解: パスワードポリシーはパスワードの複雑さ・有効期限・再利用禁止を設定（アカウントレベル）。MFA は追加認証要素（パスワード + デバイス）。両者は独立した制御で、セキュリティ強化のために両方を設定することが推奨。

問題 56: AWS WAF の「ジオマッチング（Geo Match）」ルールの用途は？ → 正解: 特定の国・地域からのリクエストを許可または拒否するルール。例: 日本向けサービスで日本以外のリクエストをブロック。Cloudfront の Geo Restriction（CloudFront レベル）とは異なり、WAF Geo Match は WebACL でより細かく制御可能。

問題 57: AWS Secrets Manager のローテーション中に「中断期間（Staging Labels）」はどう管理されますか？ → 正解: Staging Labels で管理: AWSCURRENT（現在の有効なシークレット）、AWSPENDING（ローテーション中の新シークレット）、AWSPREVIOUS（1世代前のシークレット）。ローテーション完了後、AWSCURRENT が更新され、古い値は AWSPREVIOUS に移動。

問題 58: VPC の DNS ホスト名解決に関するセキュリティ設定は？ → 正解: VPC 属性の enableDnsHostnames と enableDnsSupport を有効化。Route 53 Resolver でオンプレミス↔VPC 間の DNS クエリを転送できる。DNS Firewall（Route 53 Resolver DNS Firewall）で悪意ある ドメインへのクエリをブロック可能。

問題 59: S3 バケットポリシーで aws:SecureTransport 条件を使用する目的は？ → 正解: HTTP（非暗号化）経由の S3 アクセスを拒否し、HTTPS のみを強制する。"Condition": {"Bool": {"aws:SecureTransport": "false"}} で Deny ルールを作成することで、平文通信によるデータ漏洩リスクを排除。

問題 60: AWS Network Firewall の「ステートフルルール」と「ステートレスルール」の違いは？ → 正解: ステートレスルール: 各パケットを個別に評価（パケットフィルタリング）。ステートフルルール: セッション状態を追跡し、Suricata ベースの IDS/IPS ルールを使用可能。URLフィルタリング、ドメインリスト、プロトコル検査が可能。

問題 61: AWS のインシデント対応で「連絡先の分類」が重要な理由は？ → 正解: セキュリティインシデントの影響範囲・緊急度に応じて通知先を分けることで、適切な意思決定者に迅速に情報が届く。AWS では SNS + Lambda + PagerDuty/Slack の組み合わせで重大度に応じた自動通知ワークフローを構築。

問題 62: CloudTrail Lake の特徴は？ → 正解: CloudTrail イベントデータをマネージドデータレイクに最長 7 年保存し、SQL ベースのクエリで分析できるサービス。従来の S3 + Athena アーキテクチャよりも設定が簡単で、Event Data Store として統合管理可能。

問題 63: IAM の「サービスコントロールトークン（SCT）」とは何ですか？ → 正解: そのような用語は存在しません（誤りの選択肢）。正しい用語は SCP（Service Control Policy）、STS（Security Token Service）、または Session Token。試験で紛らわしい用語を使う場合、正確な AWS 用語を確認することが重要。

問題 64: AWS KMS の「外部キーストア（XKS: External Key Store）」の用途は？ → 正解: AWS 外部のオンプレミス HSM や外部キー管理システムで管理する鍵を KMS から参照して使用できる機能。規制要件で鍵をクラウド外に保管する必要がある場合に使用。CloudHSM との違いは、完全に AWS 外部の鍵管理システムを使用できる点。

問題 65: 本番環境へのアクセスに Just-In-Time（JIT）アクセスを実装する AWS ベストプラクティスは？ → 正解: IAM Identity Center の一時的なアクセス許可（Temporary Elevated Access Management: TEAM）パターン。通常は権限なし → 申請 → 承認フロー → 一時的なアクセス許可（数時間）→ 自動失効。CloudTrail で全アクセスを記録。

学習戦略

試験の特徴

AWS Certified Security Specialty（SCS-C02）は、以下の特徴があります：

• 難易度: 高い（Professional レベルに準ずる）
• 前提: Associate レベルの資格と 2〜5 年の IT セキュリティ経験
• 問題数: 65 問（うち 15 問は採点外のテスト問題）
• 時間: 170 分
• 合格点: 750/1000

ドメイン別出題割合と重点分野

ドメイン 1: 脅威検出と対応 (14%)
  重点: GuardDuty/Detective/Security Hub 連携

ドメイン 2: セキュリティのログ記録と監視 (18%)
  重点: CloudTrail/Config/VPC Flow Logs/CloudWatch

ドメイン 3: インフラストラクチャのセキュリティ (20%)
  重点: VPC設計/WAF/Shield/Network Firewall

ドメイン 4: IAM (16%)
  重点: Permission Boundary/ABAC/SCP/SSO

ドメイン 5: データ保護 (18%)
  重点: KMS/Secrets Manager/S3暗号化/ACM

ドメイン 6: 管理とセキュリティガバナンス (14%)
  重点: Organizations/Control Tower/Audit Manager

30日学習プラン

Week 1: 基礎固め
  Day 1-2:  IAM（ポリシー評価ロジック、Permission Boundary、ABAC）
  Day 3-4:  KMS（キーポリシー、Grants、クロスアカウント）
  Day 5-7:  VPC セキュリティ（SG/NACL/Endpoint/Flow Logs）

Week 2: セキュリティサービス
  Day 8-9:  GuardDuty + Detective（検出と調査）
  Day 10-11: Security Hub + Config（統合管理・コンプライアンス）
  Day 12-13: WAF + Shield + Firewall Manager（DDoS/L7保護）
  Day 14:   Inspector + Macie（脆弱性・機密データ検出）

Week 3: 高度なトピック
  Day 15-16: Organizations + SCP + Control Tower
  Day 17-18: CloudTrail + ログ管理（改ざん防止・長期保存）
  Day 19-20: Incident Response（手順・封じ込め・復旧）
  Day 21:   Secrets Manager + Parameter Store

Week 4: 仕上げ
  Day 22-24: ハンズオン（AWS コンソールで実際に設定）
  Day 25-27: 模擬試験 + 弱点補強
  Day 28-30: 直前復習（サービス比較表・よく出る問題パターン）

合格のためのキーポイント

必ず覚えること:

1. IAM ポリシー評価順序: 明示的 Deny > Explicit Allow > 暗黙的 Deny
2. KMS クロスアカウント: キーポリシー + IAM ポリシー の両方が必要
3. CloudTrail ログ保護: Log Validation + S3 Object Lock(Compliance) + 別アカウント
4. GuardDuty → Detective ワークフロー: 検出 → 調査の役割分担
5. SCP vs Permission Boundary: アカウント全体 vs 個別 IAM エンティティ
6. Security Hub: 複数サービスの調査結果を統合（修復機能は別途必要）
7. Secrets Manager vs Parameter Store: 自動ローテーション vs コスト効率

試験直前チェックリスト

セキュリティサービス理解

• [ ] GuardDuty が分析するデータソース（VPC Flow Logs/CloudTrail/DNS/S3等）を説明できる
• [ ] GuardDuty の自動応答（EventBridge → Lambda）を設計できる
• [ ] Security Hub とセキュリティ標準（FSBP/CIS/PCI DSS）の関係を理解している
• [ ] Amazon Inspector v2 のスキャン対象（EC2/ECR/Lambda）を説明できる
• [ ] Amazon Macie の機密データ検出カテゴリを列挙できる
• [ ] Amazon Detective と GuardDuty の役割分担を説明できる

IAM 詳細

• [ ] IAM ポリシー評価ロジック（全 6 ステップ）を説明できる
• [ ] Permission Boundary のユースケースと制限を理解している
• [ ] ABAC のタグベース制御を実装できる
• [ ] IAM Identity Center による SSO アーキテクチャを設計できる
• [ ] SCP と Permission Boundary の違いを説明できる
• [ ] クロスアカウントロールの Trust Policy を作成できる

データ保護

• [ ] S3 暗号化オプション（SSE-S3/SSE-KMS/SSE-C/CSE）の違いを説明できる
• [ ] KMS キーポリシー・Grants・クロスアカウントを設定できる
• [ ] Secrets Manager の自動ローテーション対応サービスを列挙できる
• [ ] ACM の使用可能サービス（ALB/NLB/CloudFront/API GW）を説明できる
• [ ] CloudHSM vs KMS の使い分けを説明できる

ネットワークセキュリティ

• [ ] AWS WAF のルール評価順序とデフォルトアクションを説明できる
• [ ] Shield Standard vs Advanced の違いと Shield Advanced の追加機能を説明できる
• [ ] AWS Network Firewall のステートフル/ステートレスルールを説明できる
• [ ] VPC セキュリティグループとNACLの違い（ステートフル/ステートレス）を説明できる
• [ ] VPC Endpoint（Gateway/Interface）とセキュリティ設定を説明できる

監査・コンプライアンス

• [ ] CloudTrail ログ改ざん防止設定（Log Validation + Object Lock）を説明できる
• [ ] AWS Config ルールの自動修復ワークフローを設計できる
• [ ] Organizations の SCP でリージョン制限を実装できる
• [ ] Control Tower のガードレール（必須/強く推奨/選択的）を説明できる
• [ ] VPC Flow Logs の記録内容と記録されない内容を説明できる

インシデントレスポンス

• [ ] EC2 インスタンス侵害対応の手順（証拠保全→封じ込め→調査）を説明できる
• [ ] IAM 認証情報侵害対応の手順を説明できる
• [ ] S3 データ漏洩対応の手順を説明できる
• [ ] NIST サイバーセキュリティフレームワーク（検出→分析→封じ込め→根絶→復旧）を理解している

付録：サービス比較早見表

セキュリティサービス機能マトリクス

※ Security Hub は EventBridge 経由で自動修復を起動可能

暗号化サービス比較

IAM アクセス制御比較

本ドキュメントは SCS-C02 Security Specialty 試験対策用資料です。最新の試験ガイドは AWS 公式サイトをご参照ください。

高度なセキュリティアーキテクチャ設計

ゼロトラストアーキテクチャ（Zero Trust）

従来の「境界型防御」からゼロトラストへの移行:

従来の境界型（Perimeter-based）:
  外部 → [ファイアウォール] → 内部ネットワーク
  「内部にいれば信頼する」

ゼロトラスト（Zero Trust）:
  「何も信頼しない、常に検証する」
  - アイデンティティの継続的検証（MFA/短期間トークン）
  - デバイスの健全性確認
  - 最小権限アクセス（Just-Enough-Access）
  - マイクロセグメンテーション（サービスごとに SG）
  - ネットワーク暗号化（すべての通信を TLS 化）

AWS でのゼロトラスト実装:

セキュリティ自動化（SecOps）

SOAR（Security Orchestration, Automation and Response）パターン:

検出レイヤー:
  GuardDuty / Security Hub / CloudWatch Alarm
    ↓
オーケストレーションレイヤー:
  EventBridge（イベントルーティング）
    ↓
自動化レイヤー:
  Step Functions（複雑なワークフロー）
  Lambda（シンプルな自動化）
  SSM Automation（インフラ操作）
    ↓
アクション:
  - IAM ユーザー/ロール無効化
  - SG ルール自動変更
  - EC2 インスタンス隔離
  - S3 バケット暗号化強制
  - SNS 通知（Slack/PagerDuty）

自動化ワークフロー例（GuardDuty → Lambda → 自動修復）:

# GuardDuty 高重大度アラートへの自動対応 Lambda
import boto3
import json

def lambda_handler(event, context):
    detail = event['detail']
    finding_type = detail['type']
    
    # 侵害された IAM 認証情報の対応
    if 'UnauthorizedAccess:IAMUser' in finding_type:
        iam = boto3.client('iam')
        user_name = detail['resource']['accessKeyDetails']['userName']
        
        # 1. アクセスキーを無効化
        access_keys = iam.list_access_keys(UserName=user_name)
        for key in access_keys['AccessKeyMetadata']:
            iam.update_access_key(
                UserName=user_name,
                AccessKeyId=key['AccessKeyId'],
                Status='Inactive'
            )
        
        # 2. SNS で通知
        sns = boto3.client('sns')
        sns.publish(
            TopicArn='arn:aws:sns:ap-northeast-1:123456789012:security-alerts',
            Subject=f'🚨 IAM 認証情報侵害を検出: {user_name}',
            Message=f'GuardDuty 検出: {finding_type}
ユーザー: {user_name}
アクセスキーを無効化しました。'
        )

AWS Well-Architected セキュリティの柱

7つのセキュリティ設計原則:

1. 強力なアイデンティティ基盤の実装

   • AWS SSO + MFA の強制
   • 長期認証情報の排除（IAM ロールのみ使用）

2. トレーサビリティの実現

   • CloudTrail + Config + VPC Flow Logs
   • すべての変更を自動的に記録・アラート

3. すべてのレイヤーにセキュリティを適用

   • エッジ: WAF/Shield
   • ネットワーク: NACL/SG/Network Firewall
   • アプリ: 認証・認可
   • データ: 暗号化

4. セキュリティのベストプラクティスの自動化

   • Config ルール + 自動修復
   • 安全な AMI のパイプライン化

5. 転送中および保管中のデータの保護

   • 全通信の TLS 化（aws:SecureTransport 条件）
   • 保管データの KMS 暗号化

6. 人を寄せつけない（人的エラーの削減）

   • Infrastructure as Code (CloudFormation/CDK)
   • 手動操作を承認プロセスで制限

7. セキュリティイベントへの準備

   • インシデント対応 Runbook の整備
   • 定期的なゲームデー（実地訓練）

AWS Audit Manager

Audit Manager は継続的なコンプライアンス証跡収集を自動化します。

監査フレームワーク（事前定義）:
  - PCI DSS 3.2.1
  - HIPAA
  - GDPR
  - SOC 2
  - CIS Foundations Benchmark
  - ISO 27001

動作:
  フレームワーク選択
    ↓
  コントロール定義（何を証跡として収集するか）
    ↓
  AWS サービスから自動収集（Config/CloudTrail/Security Hub）
    ↓
  証跡をレポート化（監査人に提出可能）

AWS Detective 深掘り

行動グラフ（Behavior Graph）

Detective は 1〜2 年間の VPC Flow Logs、CloudTrail、GuardDuty データを分析してグラフデータベースを構築します。

分析エンティティ:
  - AWS アカウント
  - IAM ロール/ユーザー
  - IP アドレス
  - EC2 インスタンス
  - S3 バケット
  - 発見事項（GuardDuty）

グラフのエッジ（関係性）:
  IAM ロール ──使用した── IP アドレス
  IP アドレス ──通信した── EC2 インスタンス
  EC2 ──アクセスした── S3 バケット

典型的な調査フロー:

GuardDuty: 「IAMUser/AnomalousBehavior 検出」
    ↓
Detective で IAM エンティティをピボット
    ↓
過去 30 日間の行動ベースラインとの比較
    ↓
「通常は東京リージョンのみ使用、今回バージニアから操作」
「通常使用する IP アドレスとは異なる」
    ↓
侵害された可能性が高いと判断

コンテナセキュリティ

ECS/EKS でのセキュリティベストプラクティス

コンテナイメージのセキュリティ:
  ECR + Inspector でイメージスキャン
  ECR プライベートリポジトリ（パブリック公開しない）
  ECR イメージスキャン（プッシュ時/定期的）
  
ランタイムセキュリティ:
  ECS タスクロール（最小権限）
  EKS Pod IAM Role（IRSA: IAM Roles for Service Accounts）
  
ネットワークセキュリティ:
  ECS Service Connect / AWS App Mesh（サービス間 mTLS）
  EKS Network Policy（Pod 間通信制限）

EKS セキュリティ（IAM + RBAC）:

AWS IAM ← aws-auth ConfigMap → Kubernetes RBAC
  ↓                                    ↓
IAM ロールを               K8s ClusterRole/Role に
K8s グループにマッピング      権限を定義

IRSA (IAM Roles for Service Accounts):
  Pod の Service Account に IAM ロールを紐付け
  OIDC プロバイダーを使用
  ノードの IAM ロールへの依存をなくす

Security Lake（Amazon Security Lake）

Amazon Security Lake は OCSF（Open Cybersecurity Schema Framework）に基づくセキュリティデータレイクです。

データソース:
  AWS ネイティブ: CloudTrail/VPC Flow Logs/Route 53/S3 Access Logs/EKS Audit
  サードパーティ: Crowdstrike/Palo Alto/Okta 等
    ↓
自動的に OCSF 形式に正規化
    ↓
S3 + Lake Formation に保存
    ↓
分析ツール:
  Amazon Athena（SQL クエリ）
  Amazon OpenSearch（検索・可視化）
  サードパーティ SIEM（Splunk/IBM QRadar 等）

追加練習問題（問題 66〜80）

問題 66

企業がゼロトラストアーキテクチャを AWS で実装する際に、「社内ユーザーが AWS リソースにアクセスする場合でも、常にデバイスの健全性を検証したい」という要件があります。最適なサービスはどれですか？

• A. AWS Client VPN
• B. AWS Verified Access
• C. AWS Direct Connect
• D. AWS Transit Gateway

問題 67

Amazon Security Lake を導入するメリットとして正しいものはどれですか？

• A. AWS リソースへの攻撃を自動的にブロックする
• B. 複数の AWS サービスとサードパーティのセキュリティデータを OCSF 形式に正規化して一元保存する
• C. CloudTrail の代替として API ログを収集する
• D. GuardDuty の検出精度を向上させる

問題 68

AWS CloudHSM のユースケースとして最も適切なものはどれですか？

• A. KMS の代替として S3 暗号化に使用する
• B. 金融規制（FIPS 140-2 Level 3 要件）に対応するため、専用 HSM で PKI プライベートキーを管理する
• C. SSL 証明書の自動更新
• D. CloudTrail ログの暗号化キー管理

問題 69

EC2 インスタンスメタデータサービス（IMDS）の IMDSv1 が持つセキュリティリスクと IMDSv2 の対策はどれですか？

• A. IMDSv1 はメタデータを暗号化しないが、IMDSv2 は暗号化する
• B. IMDSv1 は SSRF 攻撃で IAM 認証情報が盗まれるリスクがある。IMDSv2 は PUT リクエストでセッショントークンを事前に取得する必要があるため、SSRF に対して耐性がある
• C. IMDSv1 は IPv4 のみ、IMDSv2 は IPv6 もサポート
• D. IMDSv2 はメタデータへのアクセス回数を制限する

攻撃者 → SSRF 脆弱なアプリ → http://169.254.169.254/latest/meta-data/iam/security-credentials/
                            → IAM 認証情報を取得!

1. PUT リクエストでセッショントークン取得（TTL 設定）
   PUT http://169.254.169.254/latest/api/token (X-aws-ec2-metadata-token-ttl-seconds: 21600)
   → トークン返却

2. GET リクエストにトークンを付与
   GET http://169.254.169.254/latest/meta-data/ (X-aws-ec2-metadata-token: TOKEN)

問題 70

AWS で「Infrastructure as Code のセキュリティ（IaC Security）」を実現するために、CloudFormation テンプレートの脆弱な設定を事前に検出するサービスはどれですか？

• A. AWS Config
• B. CloudFormation Guard（cfn-guard）または AWS CloudFormation Linter（cfn-lint）
• C. Amazon Inspector
• D. AWS Security Hub

問題 71

マルチアカウント環境でのセキュリティログ一元管理として、最も推奨されるアーキテクチャはどれですか？

• A. 各アカウントで個別に CloudTrail と S3 を設定する
• B. Organizations Trail を作成し、専用の Log Archive アカウントの S3 に集約し、Object Lock と MFA Delete を設定する
• C. CloudWatch Logs に集約して 7 年間保持する
• D. 各アカウントの CloudTrail を中央アカウントにクロスアカウント転送する

Organization Trail（管理アカウントで作成）
    ↓
Log Archive アカウントの S3 バケット（集約）
    ↓
S3 バケット保護:
  - Object Lock（Compliance モード）: 改ざん・削除不可
  - MFA Delete: 削除に MFA 必須
  - バケットポリシー: ログアーカイブアカウント以外の削除を拒否
  - 別 KMS キーで暗号化

問題 72

AWS IAM の「条件キー（Condition Keys）」を活用したセキュリティ制御の例として正しいものはどれですか？

• A. aws:MultiFactorAuthPresent: true → MFA を使用した場合のみ S3 削除を許可
• B. aws:SourceIp → 特定の IP からの IAM ユーザー作成を拒否
• C. aws:RequestedRegion → 東京リージョン以外の EC2 起動を拒否
• D. 上記すべて正しい

// MFA を要求する高特権操作の保護
"Condition": {
  "Bool": {"aws:MultiFactorAuthPresent": "true"},
  "NumericLessThan": {"aws:MultiFactorAuthAge": "3600"}
}

// 特定 IP からのみアクセス許可
"Condition": {
  "IpAddress": {"aws:SourceIp": ["10.0.0.0/8", "203.0.113.0/24"]}
}

// リージョン制限
"Condition": {
  "StringNotEquals": {"aws:RequestedRegion": "ap-northeast-1"}
}

問題 73

AWS Config の「集約機能（Config Aggregator）」を Organizations で使用する主な目的は？

• A. Config ルールを自動的に全アカウントに配布する
• B. 全アカウント・全リージョンのリソース設定とコンプライアンス状況を一元的に可視化する
• C. Config のコストを削減する
• D. CloudTrail ログを集約して分析する

問題 74

AWS でエンドツーエンドの暗号化を実現する際に、「転送中のデータ」と「保管中のデータ」それぞれに使用すべき技術の組み合わせとして最も包括的なものはどれですか？

• A. 転送中: VPN / 保管中: S3 SSE-S3
• B. 転送中: TLS（ACM + ALB）+ AWS VPN/Direct Connect / 保管中: KMS（SSE-KMS/EBS/RDS 暗号化）
• C. 転送中: SSH トンネル / 保管中: OS レベルの暗号化
• D. 転送中: WAF / 保管中: Inspector

問題 75

セキュリティの「最小権限の原則」を継続的に維持するために最も有効な AWS ツールはどれですか？

• A. AWS Trusted Advisor のセキュリティチェック
• B. IAM Access Analyzer の「未使用のアクセス」分析 + IAM Policy Generation
• C. AWS Config の IAM 関連ルール
• D. CloudTrail の API ログ手動確認

セキュリティ重要概念まとめ

暗号化アルゴリズム参照

認証・認可用語集

AWS セキュリティサービス略語一覧

SCS-C02 試験対策ノート完了 - IAM・KMS・GuardDuty・Security Hub・インシデントレスポンス・Organizations セキュリティ・ゼロトラストを網羅

第8章: インシデント対応・フォレンジック

8.1 セキュリティインシデント対応フレームワーク

┌─────────────────────────────────────────────────────────────┐
│              AWS セキュリティインシデント対応                  │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  フェーズ1: 検出・分類                                       │
│  ・GuardDuty Findingのトリアージ                             │
│  ・Security Hubでの集約・優先度付け                          │
│  ・CloudTrailで初期アクション確認                            │
│                                                             │
│  フェーズ2: 封じ込め                                         │
│  ・EC2インスタンスの隔離（隔離SG）                            │
│  ・IAMポリシーのDeny追加（被害拡大防止）                      │
│  ・アクセスキーの無効化                                      │
│  ・S3 Deny All Policyの適用（重要バケット保護）              │
│                                                             │
│  フェーズ3: 証拠保全                                         │
│  ・EBSボリュームのスナップショット                           │
│  ・メモリダンプ（SSM Run Command）                           │
│  ・CloudTrailログのS3コピー（Read-Only）                    │
│  ・VPCフローログの保存                                       │
│                                                             │
│  フェーズ4: 根本原因分析                                     │
│  ・CloudTrail Lakeでのイベント分析                           │
│  ・Amazon Detective（関連エンティティの可視化）               │
│  ・GuardDuty 調査機能                                        │
│                                                             │
│  フェーズ5: 修復・復旧                                       │
│  ・脆弱性の修正                                              │
│  ・クリーンなAMIからの再デプロイ                             │
│  ・IAMポリシーの見直し                                       │
│                                                             │
│  フェーズ6: 事後分析                                         │
│  ・インシデントレポートの作成                                │
│  ・セキュリティ改善策の実施                                   │
│  ・Runbookの更新                                            │
└─────────────────────────────────────────────────────────────┘

import boto3
import json
from datetime import datetime, timedelta

# インシデント対応自動化Lambda
def incident_response_handler(event, context):
    """GuardDuty Findingへの自動対応"""
    
    finding = event['detail']
    finding_type = finding['type']
    severity = finding['severity']
    account_id = finding['accountId']
    region = finding['region']
    
    ec2_client = boto3.client('ec2', region_name=region)
    iam_client = boto3.client('iam')
    s3_client = boto3.client('s3')
    
    # 重大度7以上のみ対応
    if severity < 7.0:
        return {'action': 'no-action', 'reason': 'severity_below_threshold'}
    
    actions_taken = []
    
    # EC2インスタンスの侵害
    if finding_type.startswith('UnauthorizedAccess:EC2') or \
       finding_type.startswith('Behavior:EC2') or \
       'CryptoCurrency:EC2' in finding_type:
        
        instance_id = finding.get('resource', {}).get('instanceDetails', {}).get('instanceId')
        
        if instance_id:
            # 隔離SG適用（全通信ブロック）
            ec2_client.modify_instance_attribute(
                InstanceId=instance_id,
                Groups=['sg-quarantine-isolation']  # 全通信ブロックSG
            )
            actions_taken.append(f'isolated_instance:{instance_id}')
            
            # フォレンジックスナップショット作成
            response = ec2_client.describe_instances(InstanceIds=[instance_id])
            volumes = response['Reservations'][0]['Instances'][0]['BlockDeviceMappings']
            
            for vol_mapping in volumes:
                vol_id = vol_mapping['Ebs']['VolumeId']
                snapshot = ec2_client.create_snapshot(
                    VolumeId=vol_id,
                    Description=f'FORENSIC-{finding["id"][:8]}-{datetime.now().strftime("%Y%m%d")}',
                    TagSpecifications=[{
                        'ResourceType': 'snapshot',
                        'Tags': [
                            {'Key': 'Purpose', 'Value': 'ForensicEvidence'},
                            {'Key': 'FindingId', 'Value': finding['id']},
                            {'Key': 'InstanceId', 'Value': instance_id},
                            {'Key': 'Severity', 'Value': str(severity)}
                        ]
                    }]
                )
                actions_taken.append(f'snapshot:{snapshot["SnapshotId"]}')
    
    # IAM認証情報の侵害
    elif 'UnauthorizedAccess:IAMUser' in finding_type or \
         'Recon:IAMUser' in finding_type:
        
        user_name = finding.get('resource', {}).get('accessKeyDetails', {}).get('userName')
        access_key_id = finding.get('resource', {}).get('accessKeyDetails', {}).get('accessKeyId')
        
        if access_key_id:
            # アクセスキーの無効化
            iam_client.update_access_key(
                UserName=user_name,
                AccessKeyId=access_key_id,
                Status='Inactive'
            )
            actions_taken.append(f'disabled_key:{access_key_id}')
            
            # 明示的なDenyポリシーをアタッチ（全アクション禁止）
            deny_policy = {
                'Version': '2012-10-17',
                'Statement': [{
                    'Effect': 'Deny',
                    'Action': '*',
                    'Resource': '*',
                    'Condition': {
                        'StringEquals': {
                            'aws:PrincipalTag/Quarantined': 'true'
                        }
                    }
                }]
            }
            
            # タグを付けてリソースへのアクセスをブロック
            iam_client.tag_user(
                UserName=user_name,
                Tags=[{'Key': 'Quarantined', 'Value': 'true'}]
            )
            actions_taken.append(f'quarantined_user:{user_name}')
    
    # S3の不審アクセス
    elif 'UnauthorizedAccess:S3' in finding_type or 'Policy:S3' in finding_type:
        bucket_name = finding.get('resource', {}).get('s3BucketDetails', [{}])[0].get('name')
        
        if bucket_name:
            # バケットへのパブリックアクセスブロック
            s3_client.put_public_access_block(
                Bucket=bucket_name,
                PublicAccessBlockConfiguration={
                    'BlockPublicAcls': True,
                    'IgnorePublicAcls': True,
                    'BlockPublicPolicy': True,
                    'RestrictPublicBuckets': True
                }
            )
            actions_taken.append(f'blocked_public_access:{bucket_name}')
    
    # SNS通知
    sns_client = boto3.client('sns')
    sns_client.publish(
        TopicArn=f'arn:aws:sns:{region}:{account_id}:SecurityIncidents',
        Subject=f'SECURITY INCIDENT: {finding_type} (Severity: {severity})',
        Message=json.dumps({
            'finding_id': finding['id'],
            'finding_type': finding_type,
            'severity': severity,
            'actions_taken': actions_taken,
            'timestamp': datetime.now().isoformat()
        }, indent=2)
    )
    
    return {'actions_taken': actions_taken}

8.2 Amazon Detective

import boto3

detective_client = boto3.client('detective', region_name='ap-northeast-1')

# Detective グラフ作成
def enable_detective():
    response = detective_client.create_graph(
        Tags={'Name': 'SecurityInvestigation'}
    )
    return response['GraphArn']

def get_investigation_data(graph_arn, entity_arn, start_time, end_time):
    """特定エンティティの調査データ取得"""
    
    # サマリー（関連エンティティの統計）
    response = detective_client.list_investigations(
        GraphArn=graph_arn,
        FilterCriteria={
            'CreatedTime': {
                'StartInclusive': start_time,
                'EndInclusive': end_time
            }
        }
    )
    
    return response['InvestigationDetails']

# CloudTrailからの攻撃経路分析クエリ（CloudTrail Lake）
ATTACK_PATH_QUERY = """
SELECT
    eventTime,
    eventName,
    userIdentity.arn AS principal,
    userIdentity.type AS principal_type,
    sourceIPAddress,
    userAgent,
    requestParameters,
    responseElements.errorCode
FROM
    $EDS_ID
WHERE
    eventTime > DATE_ADD('day', -7, NOW())
    AND (
        -- 高リスクアクション
        eventName IN (
            'CreateUser', 'AttachUserPolicy', 'CreateAccessKey',
            'CreateRole', 'AssumeRole', 'PutRolePolicy',
            'AuthorizeSecurityGroupIngress', 'CreateInternetGateway',
            'ConsoleLogin', 'GetPasswordData'
        )
        OR errorCode = 'AccessDenied'  -- 拒否されたアクション
    )
    AND userIdentity.arn LIKE '%:role/compromised-role%'
ORDER BY
    eventTime ASC
"""

8.3 AWS Systems Manager OpsCenter + Incident Manager

import boto3

ssm_client = boto3.client('ssm', region_name='ap-northeast-1')

# OpsCenter OpsItem 作成（インシデントチケット）
def create_ops_item(title, description, severity, related_resources):
    response = ssm_client.create_ops_item(
        Title=title,
        Description=description,
        Source='GuardDuty',
        Severity=str(severity),  # 1=Critical, 2=High, 3=Medium, 4=Low
        Category='Security',
        OperationalData={
            'incident_type': {'Type': 'SearchableString', 'Value': 'security_incident'},
            'affected_resources': {'Type': 'SearchableString', 'Value': str(related_resources)}
        },
        Notifications=[
            {'Arn': 'arn:aws:sns:ap-northeast-1:123456789012:SecurityTeam'}
        ],
        RelatedOpsItems=[]
    )
    return response['OpsItemId']

# Incident Manager インシデント作成
def create_incident(title, impact, response_plan_arn):
    ssmincidents_client = boto3.client('ssm-incidents', region_name='ap-northeast-1')
    
    response = ssmincidents_client.start_incident(
        title=title,
        impact=impact,  # 1=Critical, 2=High, 3=Medium, 4=Low, 5=No Impact
        responsePlanArn=response_plan_arn,
        triggerDetails={
            'source': 'aws.guardduty',
            'timestamp': '2025-01-01T00:00:00Z'
        }
    )
    
    return response['incidentRecordArn']

模擬試験 セット2（15問）

問題1 AWS CloudHSM と AWS KMS の主な違いは？

A) CloudHSMはより安価 B) KMS: マネージドサービス、共有HSM、FIPS 140-2 Level 3。CloudHSM: 専用物理HSM、単一テナント、FIPS 140-2 Level 3、ユーザーが完全管理（Rootキーへのアクセス） C) CloudHSMはAWSによって管理される D) KMSとCloudHSMは同一の機能

正解: B 解説: KMS vs CloudHSM: KMS: マルチテナント共有HSM、AWSが管理（CMK削除可）、CloudHSM/外部キーストアと統合可能、コスト低(1/キー/月)。CloudHSM: 専用HSMクラスター（シングルテナント）、ユーザーがHSMユーザー/パーティションを完全管理、AWSはキーにアクセス不可、PKCS#11/JCE/CNG対応、高コスト(2/時間/HSM)。規制要件（金融、政府）でRootキー完全管理が必要な場合はCloudHSM。

問題2 AWS IAMのアイデンティティベースポリシーとリソースベースポリシーの評価順序は？

A) アイデンティティベースポリシーが常に優先 B) 明示的なDenyが最優先→SCPs→権限境界→セッションポリシー→アイデンティティポリシーとリソースポリシーの双方でAllowが必要（異なるアカウントの場合） C) リソースベースポリシーが常に優先 D) ランダムに評価

正解: B 解説: IAMポリシー評価ロジック: ①明示的なDeny: いずれかのポリシーにDenyがあれば拒否。②SCPs（Organizations）: 管理アカウント以外に適用される最大権限境界。③権限境界（Permissions Boundary）: ユーザー/ロールに設定されたポリシー上限。④セッションポリシー（AssumeRole時）: セッションに追加制限。⑤同一アカウント: アイデンティティポリシーまたはリソースポリシーのどちらかにAllowで許可。クロスアカウント: 両方にAllowが必要。

問題3 AWS Certificate Manager（ACM）でプライベート証明書を使用する場合のACM Private CAとの違いは？

A) ACM Private CAは不要 B) ACMはパブリック証明書（ALB、CloudFront等向け）を無料発行・自動更新。ACM Private CA（PCA）は内部/プライベート証明書を発行し、mTLS・内部ドメイン等に使用（月額課金） C) ACM Private CAの証明書はパブリックドメインにも使用可能 D) ACMはプライベート証明書をサポートしない

正解: B 解説: ACM と ACM Private CA: ACM（パブリック）: パブリックDNS検証済み証明書を無料発行。ELB/CloudFront/API Gatewayに自動デプロイ。有効期限の自動更新。ACM Private CA: 独自のCA（ルート/下位）を構築。内部ドメイン（*.internal）の証明書発行。マイクロサービス間mTLS、VPN証明書等に使用。$400/CA/月 + 証明書発行費用。ACM統合でELBへの内部証明書配布も可能。

問題4 Amazon Macieの「マネージドデータ識別子（Managed Data Identifier）」と「カスタムデータ識別子」の違いは？

A) マネージドはより高精度 B) マネージドデータ識別子: AWSが維持する事前定義パターン（クレジットカード、SSN、AWS認証情報等）。カスタムデータ識別子: ユーザーが正規表現とキーワードで独自の機密データパターンを定義 C) カスタムデータ識別子はスキャン精度が低い D) マネージドデータ識別子はすべて有効化されている

正解: B 解説: Macie データ識別子: マネージド（100以上のパターン）: クレジットカード番号、パスポート番号、各国のSSN等。AWSが継続的に更新。カスタム: regexでパターン定義（例: 社員ID:EMP-\d{6}）、最大20のキーワードで精度向上（false positive削減）、除外ワードで除外設定。両方を組み合わせてコンプライアンス要件に対応。

問題5 AWS Secrets Manager のシークレットローテーションが失敗する一般的な原因は？

A) ネットワーク接続の問題のみ B) Lambda関数がSecretsManager APIへのアクセス、Lambdaのタイムアウト、ターゲットDB/サービスへの接続失敗、4ステップのいずれかのエラー、Lambda VPC設定の問題 C) Secrets Managerはローテーション失敗をサポートしない D) シークレットのサイズが大きすぎる

正解: B 解説: ローテーション失敗の主な原因: ①Lambda→SecretsManager API通信: VPCのLambdaがSecretsManagerエンドポイントに接続できない→Interface VPCエンドポイント追加②Lambda→DBサービス通信: LambdaのSGがDB SGへのアクセスを許可していない③ローテーションLambdaのタイムアウト: 大規模DBでは延長が必要④DBユーザーの権限不足: ローテーション実行ユーザーがパスワード変更権限を持たない⑤4ステップのいずれかでエラー。

問題6 AWS Security Token Service（STS）の「セッションタグ」の使用目的は？

A) IAMユーザーへのメタデータ追加 B) AssumeRole時にセッション固有のタグを付与し、タグベースのリソースアクセス制御（ABAC）を実現。例: 部門=Financeのユーザーが同じロールを引き受けてもFinanceリソースのみアクセス可能 C) CloudTrailログへのラベル付け D) マルチアカウントアクセスの制御

正解: B 解説: STS Session Tags（属性ベースアクセス制御）: sts:TagSessionでAssumeRole時に属性を追加（Department:Finance等）。IAMポリシーのConditionでaws:PrincipalTag/Departmentを参照→Finance部門はFinanceリソースのみ許可。利点: 少数のIAMロールで多くのアクセスパターンを管理（役割ベースでなく属性ベース）。ロール数が爆発的に増えることを防止。

問題7 S3バケットのデータ保護のベストプラクティスとして「S3 Object Lock」をコンプライアンスモードで設定した場合の挙動は？

A) S3管理者が削除可能 B) 保持期間中はroot/AWSサポートも含めて誰もオブジェクトを削除・上書き不可。法的保持（Legal Hold）は保持期間に関わらず削除不可 C) Object Lockはライフサイクルポリシーと組み合わせ不可 D) コンプライアンスモードはGovern モードより弱い

正解: B 解説: S3 Object Lock モード: Compliance Mode: 保持期間中は誰も（rootユーザー・AWSサポート含む）削除・変更・モード変更・期間短縮不可。SEC 17a-4(f)等の厳格な規制要件に対応。Governance Mode: s3:BypassGovernanceRetention権限を持つユーザーが削除可能。Legal Hold: 保持日付に依存せず明示的に解除するまで保護（特定オブジェクトを訴訟保持等に使用）。Object Lock有効化にはバージョニングが必要。

問題8 Amazon Inspectorの「Network Reachability」検出結果の意味は？

A) ネットワーク速度の測定 B) EC2インスタンスのネットワーク設定（SG、NACL、ルートテーブル、IGW）を分析してインターネットから到達可能なポート・プロトコルを特定 C) VPNトンネルの健全性チェック D) EC2のOSレベルのファイアウォール設定

正解: B 解説: Inspector Network Reachability: EC2インスタンスに対してインターネットからどのポートが到達可能かを自動分析。分析対象: セキュリティグループ、NACL、ルートテーブル、IGW、NATゲートウェイ、ELBの設定。Finding例: HIGH: Port 22 (SSH) open to internet→修正推奨。OSやアプリの脆弱性スキャン（CVE）とは別機能。エージェントレスで定期的に再評価。

問題9 AWS KMSのキーポリシーとIAMポリシーの評価はどのように機能しますか？

A) IAMポリシーのみで制御可能 B) KMSキーへのアクセスはキーポリシーとIAMポリシーの両方が必要（キーポリシーがAllowで、かつIAMポリシーがAllow）。ただし、キーポリシーがAWSアカウントのルートアクセスをEnableすれば、IAMポリシーで制御可能 C) キーポリシーがIAMポリシーを完全に上書きする D) AWSアカウントのrootユーザーのみKMSにアクセス可能

正解: B 解説: KMS アクセス制御: キーポリシーに"Principal": {"AWS": "arn:aws:iam::ACCOUNT:root"}と"Action": "kms:*"が含まれる場合（デフォルト）→IAMポリシーで制御可能。キーポリシーが特定ロールのみ許可→IAMポリシーでAllowでも拒否（キーポリシーが優先）。つまり: キーポリシーで許可されている範囲をIAMポリシーでさらに絞り込む形。

問題10 AWS Configの「自動修復アクション（Auto Remediation）」の設定方法は？

A) CloudWatchアラームで自動修復 B) Config Ruleに対してSystems Manager AutomationドキュメントをAutomatic Remediationとして設定し、非準拠リソースが検出された際に自動実行 C) AWS Lambdaで直接修復処理を記述 D) Auto Remediationはマネージドルールのみサポート

正解: B 解説: AWS Config Automatic Remediation: ConfigルールにRemediationConfigurationを設定。ターゲット: SSM Automation Document（例: AWSConfigRemediation-RemoveVPCDefaultSecurityGroupRules）。実行タイミング: 自動（非準拠検出後すぐ）またはManual（手動トリガー）。最大再試行回数と待機時間も設定可能。カスタムドキュメントも使用可能（Lambda関数をバックエンドとするカスタムAutomation）。

問題11 AWS Shield AdvancedのDDRT（DDoS Response Team）の役割は？

A) DDoS攻撃を自動的にブロックする B) Shield Advanced契約者が大規模DDoS攻撃を受けた際に24/7でAWSのセキュリティエキスパートが対応を支援し、WAFルールの最適化等を実施 C) DDRTはフィッシング対策のみ D) DDRTへのアクセスは別途有料

正解: B 解説: Shield Advanced DDRT: 大規模・複雑なDDoS攻撃時にAWSのDDoSエキスパートチームに24/7でアクセス可能（AWS Support Business/Enterpriseが必要）。支援内容: ①攻撃分析・特性評価②WAFルールのリアルタイム最適化③ルーティング変更の推奨④攻撃後のコスト保護（DDoS Mitigation Costs申請）。Shield Standardは自動保護のみで人的支援なし。

問題12 IAM Access Analyzerを使用して「意図しない外部アクセス」を検出する仕組みは？

A) IAMユーザーのアクセスログを分析する B) IAMリソースポリシー（S3、KMS、SQS等）を分析してゾーン外（アカウント/組織外）のプリンシパルへのアクセス許可を検出 C) EC2インスタンスの外部接続を検出する D) IAM Access Analyzerは手動でのみ実行可能

正解: B 解説: IAM Access Analyzer: リソースベースポリシーをリアルタイム分析。検出対象: S3バケット（パブリック/クロスアカウント）、KMSキー、IAMロール、SQSキュー、Lambda関数ポリシー、Secrets Manager等。ゾーンオブトラスト（Organizations またはアカウント）外のアクセスをFinding として通知。未使用のアクセス（Unused Access）も検出可能（IAMロールの権限棚卸しに活用）。

問題13 AWS Control TowerのProactive Controls（予防的コントロール）の仕組みは？

A) CloudWatch Alarmsで制御する B) CloudFormation Hooksを使用して、CloudFormationでのリソースプロビジョニング前にポリシー違反をチェックし、違反リソースのデプロイを防ぐ C) Proactive ControlsはSCPと同一の機能 D) Proactive ControlsはTerraformのみ対応

正解: B 解説: Control Tower Proactive Controls: CloudFormation Hooks機能を利用。CloudFormationスタックの作成/更新前にHookが評価を実行。違反（例: S3バケットに暗号化なし）が検出された場合はCFNデプロイを失敗させる。SCPとの違い: SCP（予防的）はIAM APIコールをブロック。Proactive ControlsはCFNデプロイ前に評価→インフラコード（IaC）レベルでの標準化に有効。

問題14 AWS Artifact の主な用途は？

A) AWSインフラストラクチャの自動設定 B) AWSのコンプライアンスドキュメント（SOC2、PCI DSS、ISO 27001等のAWSセキュリティ認証レポート）とAWSとの契約書（NDA、BAA等）を入手するサービス C) セキュリティインシデントの記録 D) IAMポリシーの自動生成

正解: B 解説: AWS Artifact: 2つの機能: ①Artifact Reports: AWSのセキュリティ・コンプライアンスレポート（SOC1/2/3、PCI DSS AOC、ISO 27001/27017/27018、FedRAMP等）。監査人・規制機関への提出に使用。②Artifact Agreements: Business Associate Agreement（BAA）、Non-Disclosure Agreement（NDA）等の契約書の確認・同意。HIPAA準拠のためのBAA締結等に利用。

問題15 Amazon Cognito の「アドバンスドセキュリティ機能」（OIDC/Threat protection）の主な機能は？

A) 多要素認証のみ B) アダプティブ認証（リスクスコアに基づく追加認証要求）、侵害された認証情報の検出（データ漏洩リストとの照合）、ブルートフォース対策、ユーザーフローの異常検知 C) IP制限のみ D) Cognitoはセキュリティ機能を持たない

正解: B 解説: Cognito Advanced Security: ①Adaptive Authentication: サインインリスクスコアを評価（新デバイス、不審なIP等）→リスクが高い場合に追加MFA要求またはブロック②Compromised Credentials: 既知の漏洩認証情報との照合（パスワードデータベース）③Bot Protection: Captcha、レート制限④User Activity Logging: CloudWatch Logsへの詳細な認証ログ出力。Cognitoの標準プランに追加料金で有効化。

SCS試験 最終チェックリスト（補足）

追加重要トピック

• [ ] AWS Nitro Enclaves（機密コンピューティング）
• [ ] AWS Private CA + ACM統合
• [ ] Amazon Detective（グラフ分析）
• [ ] IAM Access Analyzer（外部アクセス検出）
• [ ] Control Tower Proactive Controls（CloudFormation Hooks）
• [ ] VPC Endpoint Policy（ゲートウェイ/インターフェース）
• [ ] AWS Verified Access（ゼロトラスト）

セキュリティサービスの役割分担