0Pricing
AWS Solutions Architect · レッスン

セキュアアーキテクチャのシナリオ

IAMの最小権限、暗号化、VPCの分離、WAF/Shieldに関するシナリオ問題に取り組み、セキュリティ分野の知識を定着させます。

「セキュアアーキテクチャのシナリオ」はCoddyKit上の無料AWS Solutions Architectレッスンです。 これはレッスン1/4です。 下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。 これはAWS Solutions Architect学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 AWS Solutions Architectコースには全4レッスンが含まれています。

シナリオ1:最小権限によるEC2からS3へのアクセス

シナリオ:EC2インスタンスでWebアプリケーションが稼働しており、特定のS3バケットからオブジェクトを読み取る必要があります。セキュリティチームは、インスタンス上に長期認証情報を保存せず、最小権限の原則に従ってアクセスすることを求めています。解決策:特定のバケットARNに対するs3:GetObjectのみを許可するポリシーを持つIAMロールを作成します。そのロールをインスタンスプロファイルとしてEC2インスタンスにアタッチします。アプリケーションはインスタンスメタデータサービス(IMDS)を使用して一時認証情報を自動的に取得するため、キーを保存する必要はありません。

# IAM policy for least-privilege EC2 -> S3 read
{
  'Version': '2012-10-17',
  'Statement': [{
    'Effect': 'Allow',
    'Action': ['s3:GetObject'],
    'Resource': 'arn:aws:s3:::my-app-bucket/*'
  }]
}

# Attach role to EC2 instance
aws ec2 associate-iam-instance-profile \
  --instance-id i-1234567890abcdef0 \
  --iam-instance-profile Name=EC2S3ReadRole

シナリオ2:RDSデータベースのデータの暗号化

シナリオ:ある企業が、顧客のPIIをRDS PostgreSQLデータベースに保存しています。コンプライアンスチームは、保存時の暗号化とキー使用状況の監査機能を求めています。解決策:Customer Managed Key(CMK)を使用して、AWS KMSによるRDSの暗号化を有効にします。CMKを使用すると、セキュリティチームはキーのローテーションを管理し、CloudTrailでキーの使用状況を確認し、必要に応じてアクセスを取り消せます。注意:暗号化はRDSインスタンスの作成時に有効にする必要があります。暗号化されていない既存のRDSインスタンスを、その場で暗号化することはできません。既存のDBを暗号化するには、スナップショットを作成し、暗号化を有効にしてコピーした後、暗号化されたスナップショットから復元します。

# Create an encrypted RDS instance
aws rds create-db-instance \
  --db-instance-identifier prod-postgres \
  --db-instance-class db.t3.medium \
  --engine postgres \
  --master-username admin \
  --master-user-password SecurePass123! \
  --storage-encrypted \
  --kms-key-id arn:aws:kms:us-east-1:123456789012:key/mrk-abc123 \
  --allocated-storage 100

シナリオ3:S3バケット — パブリックアクセスのブロック

シナリオ:開発者が誤ってS3バケットを公開し、顧客データを漏えいさせました。セキュリティチームは、開発者が試みた場合でも、アカウント内のどのS3バケットも決して公開できないようにしたいと考えています。解決策:アカウントレベルでS3 Block Public Accessを有効にします。これにより、個々のチームがどのように設定しても、パブリックアクセスを許可するバケットレベルのポリシーやACLが上書きされます。さらにAWS Configルール(s3-bucket-public-read-prohibited)を組み合わせ、準拠していないバケットを継続的に検出してアラートを出します。

# Block all public access at account level
aws s3control put-public-access-block \
  --account-id 123456789012 \
  --public-access-block-configuration \
    'BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true'

# Deploy Config rule to detect violations
aws configservice put-config-rule \
  --config-rule '{"ConfigRuleName": "s3-bucket-public-read-prohibited", "Source": {"Owner": "AWS", "SourceIdentifier": "S3_BUCKET_PUBLIC_READ_PROHIBITED"}}'

シナリオ4:データベース層のVPC分離

シナリオ:ある企業が、RDSデータベースにはアプリケーションサーバーからのみアクセスでき、インターネットからはアクセスできないようにしたいと考えています。解決策:インターネットゲートウェイへのルートがないプライベートサブネットにRDSを配置します。RDS用のセキュリティグループを作成し、ポート5432(PostgreSQL)へのインバウンドトラフィックを、任意のIPアドレス範囲ではなく、アプリケーションサーバーのセキュリティグループからのみ許可します。これにより、アプリケーションサーバーが侵害された場合でも、攻撃者がVPC外部からデータベースに到達することを防ぎ、セキュリティグループのルールによって横方向の移動も制限できます。

# Create RDS security group allowing only the app tier SG as source
aws ec2 create-security-group \
  --group-name rds-sg \
  --description 'RDS security group' \
  --vpc-id vpc-abc123

aws ec2 authorize-security-group-ingress \
  --group-id sg-rds \
  --protocol tcp \
  --port 5432 \
  --source-group sg-app  # app tier security group ID only

シナリオ5:データベース認証情報のローテーション

シナリオ:現在、アプリケーションコードにデータベース認証情報が設定ファイルへハードコードされています。セキュリティ監査で、これが重大なリスクとして指摘されました。解決策:認証情報をAWS Secrets Managerに保存し、自動ローテーションを設定します(Secrets ManagerにはRDS用の組み込みLambdaローテーション関数があります)。アプリケーションを更新し、SDKを使用して実行時にSecrets Managerから認証情報を取得するようにします。ローテーションのたびにデプロイしなくても、アプリケーションは自動的に新しい認証情報を取得します。完全に管理された、ダウンタイムなしの認証情報ローテーションを実現するため、RDSシークレットのローテーションテンプレートを有効にします。

# Store RDS credentials in Secrets Manager
aws secretsmanager create-secret \
  --name prod/myapp/rds \
  --secret-string '{"username":"admin","password":"OldPass123!","host":"rds-endpoint.amazonaws.com","port":5432}'

# Enable automatic rotation every 30 days
aws secretsmanager rotate-secret \
  --secret-id prod/myapp/rds \
  --rotation-lambda-arn arn:aws:lambda:us-east-1:123:function:SecretsManagerRDSPostgreSQLRotationSingleUser \
  --rotation-rules AutomaticallyAfterDays=30

シナリオ6:通常と異なるAPIアクティビティの検出

シナリオ:ある企業が、AWSアカウントの認証情報が侵害され、予期しない場所から使用されていないかを検出したいと考えています。解決策:すべてのリージョンでAmazon GuardDutyを有効にします。GuardDutyは、機械学習を使用してCloudTrailイベント、VPC Flow Logs、DNSログを分析し、通常と異なる地域からのAPI呼び出し、EC2でのビットコインマイニングのパターン、Tor出口ノードとの通信、認証情報の窃取パターンなどの異常を検出します。GuardDutyが生成した検出結果をトリガーとしてEventBridgeルールを実行し、SNS経由でセキュリティチームに自動通知したり、サポートチケットを作成したりできます。

# Enable GuardDuty in a Region
aws guardduty create-detector \
  --enable \
  --finding-publishing-frequency FIFTEEN_MINUTES

# EventBridge rule to react to GuardDuty HIGH severity findings
aws events put-rule \
  --name guardduty-high-severity \
  --event-pattern '{
    "source": ["aws.guardduty"],
    "detail-type": ["GuardDuty Finding"],
    "detail": {"severity": [{"numeric": [">=", 7]}]}
  }'

シナリオ7:悪意のあるリクエストをブロックするWAF

シナリオ:ALBの背後で稼働しているWebアプリケーションが、SQLインジェクション攻撃を受けています。アプリケーションはすぐには変更できません。解決策:ALBにAWS WAFを関連付けます。AWS Managed Rules for Common Threatsルールグループ(Core Rule Set + SQL Databaseルールグループ)を導入します。このルールグループには、事前構築済みのSQLインジェクション検出機能が含まれています。WAFはALBに到達する前にHTTPリクエストを検査し、攻撃パターンに一致するリクエストをブロックします。アプリケーションコードを変更する必要はありません。さらに、セキュリティ分析のためにWAFのログ記録をKinesis Firehoseへ有効にします。

# Create WAF Web ACL with SQL injection protection
aws wafv2 create-web-acl \
  --name AppProtection \
  --scope REGIONAL \
  --default-action Allow={} \
  --rules '[{
    "Name": "AWSManagedRulesSQLiRuleSet",
    "Priority": 1,
    "Statement": {
      "ManagedRuleGroupStatement": {
        "VendorName": "AWS",
        "Name": "AWSManagedRulesSQLiRuleSet"
      }
    },
    "OverrideAction": {"None": {}},
    "VisibilityConfig": {"SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "SQLi"}
  }]' \
  --region us-east-1

シナリオ8:クロスアカウントでのロール引き受け

シナリオ:中央のセキュリティアカウントが、AWS Organisation内のすべてのワークロードアカウントに対して読み取り専用アクセスを行い、セキュリティ監査を実施する必要があります。解決策:各ワークロードアカウントに、セキュリティアカウント(アカウントIDで指定)が引き受けることを許可する信頼ポリシーを持つIAMロールを作成します。読み取り専用ポリシー(例:SecurityAudit AWS管理ポリシー)をアタッチします。中央アカウントのセキュリティチームは、STS AssumeRoleを使用して各ワークロードアカウントのロールを一時的に引き受けます。これにより最小権限の原則に従えます。ワークロードアカウントに永続的なIAMユーザーを作成する必要はありません。

# Trust policy in workload account (allows security account to assume role)
{
  'Version': '2012-10-17',
  'Statement': [{
    'Effect': 'Allow',
    'Principal': {
      'AWS': 'arn:aws:iam::SECURITY_ACCOUNT_ID:root'
    },
    'Action': 'sts:AssumeRole'
  }]
}

# From security account: assume role in workload account
aws sts assume-role \
  --role-arn arn:aws:iam::WORKLOAD_ACCOUNT_ID:role/SecurityAuditRole \
  --role-session-name audit-2024-01

シナリオ9:SCPによるアクションの制限

シナリオ:ある企業がAWS Organizationsを使用しており、本番環境以外のOUにあるアカウントで高価なGPUインスタンスを起動できないようにしたいと考えています。解決策:GPUインスタンスファミリー(p3、p4、g4、g5)に対するec2:RunInstancesを拒否するService Control Policy(SCP)を作成し、本番環境以外のOUにアタッチします。SCPはメンバーアカウントのrootユーザーや管理者レベルのIAMユーザーにも適用されます。SCPは、アカウント内のどのアイデンティティも上書きできないガードレールとして機能します。これにより、開発・テストアカウントでの意図しない、または悪意のある多額の支出を防げます。

# SCP to deny GPU instance types in non-prod OU
{
  'Version': '2012-10-17',
  'Statement': [{
    'Sid': 'DenyGPUInstances',
    'Effect': 'Deny',
    'Action': 'ec2:RunInstances',
    'Resource': 'arn:aws:ec2:*:*:instance/*',
    'Condition': {
      'StringLike': {
        'ec2:InstanceType': ['p3.*', 'p4d.*', 'g4.*', 'g5.*']
      }
    }
  }]
}

シナリオ10:コンプライアンスのための監査証跡

シナリオ:金融サービス企業が、すべてのAWS API呼び出しが記録され、改ざん不能な状態で7年間保持されていることを監査人に示す必要があります。解決策:ログアカウント内の専用S3バケットにログを配信するマルチリージョンAWS CloudTrailトレイルを作成します。ログファイルの整合性検証(ログの改ざんを検出する暗号学的ダイジェストファイル)を有効にします。ログバケットに対して、7年間の保持期間を設定したS3 Object LockポリシーをComplianceモードで設定します。これにより、必要な保持期間中は、rootユーザーであってもログを削除または変更できません。

# Create multi-region trail with integrity validation
aws cloudtrail create-trail \
  --name compliance-trail \
  --s3-bucket-name central-audit-logs-123 \
  --is-multi-region-trail \
  --enable-log-file-validation \
  --include-global-service-events

aws cloudtrail start-logging --name compliance-trail

シナリオ11:プライベートなS3アクセスのためのVPCエンドポイント

シナリオ:プライベートVPC内のEC2インスタンスが、パブリックインターネットを経由せずにS3へアクセスする必要があります。現在はNAT Gatewayを使用していますが、NAT Gatewayのデータ処理料金によりコストが高くなっています。解決策:S3 Gateway VPC Endpointを作成します。プライベートサブネットのルートテーブルに、S3のプレフィックスリストをエンドポイントへ向けるルートエントリを追加します。これにより、S3へのトラフィックはAWSネットワークのバックボーン内だけを通過し、NAT Gatewayもインターネットゲートウェイも不要になります。S3 Gateway Endpointは無料です(AZごとに時間単位の料金がかかるInterface Endpointとは異なります)。また、S3へのアクセスをパブリックインターネット経由の経路から除外できるため、セキュリティも向上します。

# Create S3 Gateway VPC Endpoint
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-abc123 \
  --service-name com.amazonaws.us-east-1.s3 \
  --route-table-ids rtb-private-1a rtb-private-1b

# Result: route table automatically gets a route:
# Destination: pl-63a5400a (S3 prefix list)
# Target: vpce-xyz456 (the Gateway Endpoint)
# EC2 instances now reach S3 privately at no endpoint cost

クイックチェック

このレッスンで学んだ AWS Solutions Architect(SAA-C03)の概念について理解度を確認しましょう。

レッスンの振り返り

このレッスンでは、認証情報なしで EC2 にアクセスするための IAM ロールとインスタンスプロファイル、データベース認証情報を自動的にローテーションする Secrets Manager、コードを変更せずにインジェクション攻撃をブロックする AWS WAF、改ざん防止されたコンプライアンスログを実現する CloudTrail と S3 Object Lockに関するシナリオに取り組みました。次は、耐障害性と高可用性を備えたアーキテクチャのシナリオに進みます。

よくある質問

「セキュアアーキテクチャのシナリオ」レッスンは無料ですか?

はい。「セキュアアーキテクチャのシナリオ」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し(組み込みコードエディタと24時間対応のAIチューター)、AWS Solutions Architectコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 AWS Solutions Architectコースには全4レッスンが含まれています。

「セキュアアーキテクチャのシナリオ」で何を学びますか?

IAMの最小権限、暗号化、VPCの分離、WAF/Shieldに関するシナリオ問題に取り組み、セキュリティ分野の知識を定着させます。 ブラウザで直接実行するハンズオンコードでAWS Solutions Architectを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

AWS Solutions Architectを始めるのに経験は必要ですか?

事前経験は必要ありません。CoddyKitのAWS Solutions Architectは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。 これはレッスン1/4です。

「セキュアアーキテクチャのシナリオ」レッスンにはどのくらい時間がかかりますか?

ほとんどのCoddyKitレッスンは約5~10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。

このAWS Solutions Architectレッスンでコードを書いて実行できますか?

はい。すべてのAWS Solutions Architectレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。

このコースのすべてのレッスン

  1. セキュアアーキテクチャのシナリオ
  2. レジリエントで高可用性のアーキテクチャシナリオ
  3. 高パフォーマンスとコスト最適化のシナリオ
  4. 全分野横断の本格ミニ試験
← AWS Solutions Architectに戻る