最終確認: 2026年5月
SCS-C03 試験の対象となる AWS サービスを、プレーンな Terraform を使用して構築します。1 ブロックずつ、それぞれ試験ドメインに関連付けられています。同じコードが OpenTofu でも動作します。
このラボの終了までに、自動ローテーション付きのカスタマーマネージドKMSキー、意図しないクロスアカウントまたはパブリックアクセスをスキャンするIAM Access Analyzer、脅威インテリジェンスフィードが有効化されたGuardDuty、および他のワークロードが書き込む一元化された監査ログバケットという、すべてのAWSアカウントが初日から備えるべき4つのセキュリティプリミティブを、プレーンなTerraformでプロビジョニングできます。これはSCS-C03のsecure-by-defaultベースラインです。
すべてのリソースはプレーンなTerraformです。同じコードはOpenTofuでも変更なしで動作します。変数もモジュールもありません。スニペットを単一の main.tf にドロップし、terraform init を実行してから、terraform apply をステップバイステップで実行します。
>= 1.5 または OpenTofu >= 1.6。us-east-1 用に AWS CLIが認証済み であること。ここにある4つのサービスのうち3つは新規アカウントにとって無料です。1つは実際の費用が発生します。
このベースラインを実際のアカウントで実行し続ける場合、合計で月額約5~15ドルの費用がかかると予想されます。得られる可視性を考えれば安価です。不要な場合は、ラボの後に破棄してください。
標準的な開始です。SCS-C03はプロバイダーやリージョンに依存しないスコープですが、安全なベースラインはリージョンごとに適用する必要があります。GuardDutyとAccess Analyzerはリージョナルサービスだからです。ほとんどのチームは、ベースライン用にプライマリリージョン(例: us-east-1)を選択し、アカウントの拡大に合わせてTerraform経由でリージョンごとに複製します。
terraform {
required_version = ">= 1.5"
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.60"
}
}
}
provider "aws" {
region = "us-east-1"
default_tags {
tags = {
Project = "certlabpro-scs-c03"
ManagedBy = "terraform"
}
}
}
data "aws_caller_identity" "current" {}SCS-C03は、AWSマネージドKMSキー(無料、自動ローテーション、制御できないキーポリシー)とカスタマーマネージドキー(月額1ドル、ポリシーを所有、ローテーションを制御、CloudTrail経由でEncrypt/Decrypt呼び出しの監査可視性を取得)の違いをテストします。本番環境では常にカスタマーマネージドを使用すべきです。
年間ローテーションを有効にし(enable_key_rotation = true)、アカウントのルートがキーを管理する能力を与え(あらゆるカスタマーマネージドキーのAWSデフォルト)、IAM Access Analyzerサービスがキーのポリシーを評価する明示的な権限を付与するキーポリシーを作成します。エイリアスを使用すると、キーをUUIDではなく、ダウンストリームコードで人間が読める名前で参照できます。SCS-C03は、この命名規則をCloudTrail監査の前提条件としてテストします。
resource "aws_kms_key" "app_data" {
description = "Customer-managed key for application data encryption."
enable_key_rotation = true
deletion_window_in_days = 30
policy = jsonencode({
Version = "2012-10-17"
Statement = [
{
Sid = "EnableRootAccountAdmin"
Effect = "Allow"
Principal = { AWS = "arn:aws:iam::${data.aws_caller_identity.current.account_id}:root" }
Action = "kms:*"
Resource = "*"
},
{
Sid = "AllowAccessAnalyzerToDescribe"
Effect = "Allow"
Principal = { Service = "access-analyzer.amazonaws.com" }
Action = ["kms:DescribeKey", "kms:GetKeyPolicy"]
Resource = "*"
},
]
})
}
resource "aws_kms_alias" "app_data" {
name = "alias/certlabpro-scs-c03-app-data"
target_key_id = aws_kms_key.app_data.id
}Access Analyzerは、リソースベースのポリシー(S3バケットポリシー、KMSキーポリシー、IAMロール信頼ポリシー、Lambda権限、SQSキューポリシー、Secrets Managerローテーションポリシーなど)を継続的に評価し、アカウントまたは信頼境界外からアクセス可能なリソースを検出すると、結果を表面化します。SCS-C03の「脅威検出とインシデント対応」ドメインは、まさにこのパターンをテストします。Access Analyzerの結果は、「このバケットはパブリックになった」という典型的なシグナルです。
type = "ACCOUNT" はアナライザーをあなたのアカウントにスコープします。type = "ORGANIZATION" はAWS Organizationsを必要とし、組織全体にスコープします(SCS-C03のマルチアカウント回答)。いずれにせよ、有効化されれば常に無料で設定は不要です。
resource "aws_accessanalyzer_analyzer" "main" {
analyzer_name = "certlabpro-scs-c03"
type = "ACCOUNT"
}GuardDutyはAWSのマネージド脅威検出サービスです。既知の不正IP、仮想通貨マイニングドメイン、コマンド&コントロールインフラ、疑わしいアカウント行動パターンなどのAWSの脅威インテリジェンスフィードと照合して、CloudTrail、VPCフローログ、DNSログを継続的に分析します。結果は、重大度(低/中/高)と Recon:EC2/PortProbeUnprotectedPort のような機械でパース可能なタイプでタグ付けされて出力されます。
検出器は15分ごとの発行頻度で有効にします(デフォルトの6時間よりも高速。SCS-C03のMTTRに関する質問は、ほぼ常に頻繁な発行を前提としています)。IAMベースの保護プラグイン(MALWARE_PROTECTION_FOR_EC2、S3_DATA_EVENTS など)は追加費用がかかり、このベースラインの範囲外です。本番環境ではワークロードごとに有効にしてください。
結果はEventBridgeに自動的に発行されます。これにより、ダウンストリームの自動化(Slack通知、Security Hub連携、自動修復Lambda)が連携されます。SCS-C03は、この「結果 → EventBridge → レスポンス」の連鎖を繰り返しテストします。ここではダウンストリームを接続しませんが、ステップ4が完了した瞬間にGuardDutyは発行を開始します。
resource "aws_guardduty_detector" "main" {
enable = true
finding_publishing_frequency = "FIFTEEN_MINUTES"
}SCS-C03のすべての「セキュリティロギングとモニタリング」の質問は、CloudTrail、VPCフローログ、ELBアクセスログ、GuardDutyエクスポート、Configレコーダーなどの他のセキュリティツールが書き込む、一元化され、暗号化され、一度書き込むと変更できないスタイルのバケットを持つことを期待しています。このバケットはステップ2のカスタマーマネージドKMSキーで暗号化され、パブリックアクセスは完全にブロックされ、バケットポリシーによって書き込まれるすべてのオブジェクトがステップ2のキーを通じて行われることが強制されます(プレーンテキストでの書き込みは許可されません)。
bucket-owner-enforced の所有権設定(ACLが無効化されたモードで、2023年以降AWSが推奨)を使用します。これは、クロスアカウントACLの誤設定の全クラスを排除するため、SCS-C03で最もテストされるS3のセキュリティ強化属性の1つです。
このバケットが設定されると、ベースラインは完了です。暗号化キー用のKMS、意図しない露出のためのAccess Analyzer、脅威検出のためのGuardDuty、およびコンプライアンスレビューのために保持する必要があるすべてのもののための監査バケット。SCS-C03のすべてのマルチサービスシナリオでは、これら4つがあることを期待しており、より高度な質問では、この基盤の上にSecurity Hub、Config、Inspector、またはMacieを追加します。
resource "aws_s3_bucket" "audit_logs" {
bucket_prefix = "certlabpro-scs-c03-audit-"
}
resource "aws_s3_bucket_public_access_block" "audit_logs" {
bucket = aws_s3_bucket.audit_logs.id
block_public_acls = true
block_public_policy = true
ignore_public_acls = true
restrict_public_buckets = true
}
resource "aws_s3_bucket_ownership_controls" "audit_logs" {
bucket = aws_s3_bucket.audit_logs.id
rule {
object_ownership = "BucketOwnerEnforced"
}
}
resource "aws_s3_bucket_server_side_encryption_configuration" "audit_logs" {
bucket = aws_s3_bucket.audit_logs.id
rule {
apply_server_side_encryption_by_default {
sse_algorithm = "aws:kms"
kms_master_key_id = aws_kms_key.app_data.arn
}
bucket_key_enabled = true # cuts KMS request costs ~99% on bulk writes
}
}
resource "aws_s3_bucket_versioning" "audit_logs" {
bucket = aws_s3_bucket.audit_logs.id
versioning_configuration {
status = "Enabled"
}
}
resource "aws_s3_bucket_policy" "audit_logs_require_kms" {
bucket = aws_s3_bucket.audit_logs.id
policy = jsonencode({
Version = "2012-10-17"
Statement = [{
Sid = "DenyUnencryptedWrites"
Effect = "Deny"
Principal = "*"
Action = "s3:PutObject"
Resource = "${aws_s3_bucket.audit_logs.arn}/*"
Condition = {
StringNotEquals = {
"s3:x-amz-server-side-encryption" = "aws:kms"
}
}
}]
})
}terraform destroy はこのラボのすべてを削除します。2点注意があります。
deletion_window_in_days = 30 を持っており、destroy は30日後の削除をスケジュールします。すぐに削除されるわけではありません(これはSCS-C03で定められた安全パターンであり、KMSの削除は元に戻せません)。この30日間、コンソールからキャンセルできます。実際に削除するには、期間が終了するのを待つ必要もあります。AWSはこの期間中も月額1ドルを請求し続けます。force_destroy = false です。ログを収集している場合は、破棄する前に空にしてください(aws s3 rm s3://<bucket> --recursive)。SCS-C03は、単一のラボでは収まりきらない広範な範囲をカバーしています。AWS Config(継続的なコンプライアンス評価)、Security Hub(一元化された結果集約)、Macie(S3 PII検出)、Inspector(EC2/Lambda脆弱性スキャン)、Detective(脅威調査)、WAF + Shield(エッジ保護)、Network Firewall、Network Access Analyzer、Cognito(ユーザーアイデンティティ)、Secrets Manager + Systems Manager Parameter Store、ACM(TLS)、Firewall Manager(マルチアカウントポリシー適用)、そしてCloudHSMハードウェアキー全体。
私たちは上記の4つのプリミティブにこだわります。なぜなら、それらが他のすべてが構築される初日のベースラインだからです。ConfigルールはSecurity Hubに結果を書き込み、Security HubはそれをGuardDutyの結果と関連付け、GuardDutyの結果はKMSキーで保護されたリソースを指し示し、Access Analyzerによってポリシーの問題が検出されます。そして、そのすべてがコンプライアンスレビューのために監査バケットに格納されます。まず基盤を構築し、ワークロードのリスクプロファイルが要求するに応じて残りの部分を重ねていきます。
サービスごとのカバー範囲については、この認定ページの閲覧、プレイブック、Editorialセクションを参照してください。Security Hub + Config + GuardDutyからEventBridgeへの自動修復チェーンを追加する次のラボは、自然な次のステップとなるでしょう。