מעבדה מעשית — SCS-C03 AWS Certified Security Specialty

סקירה כללית

דרישות קדם

שלבים

1. 1.בחרו את גרסת Terraform ואזור AWS שלנו

   פתיחה סטנדרטית. 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" {}

2. 2.צרו מפתח KMS מנוהל על ידי לקוח עם רוטציה להצפנת נתוני יישומים

   משאבים:

   • AWS KMS

   SCS-C03 בודק את ההבדל בין מפתחות KMS מנוהלים על ידי AWS (חינם, רוטציה אוטומטית, ללא מדיניות מפתח בשליטתך) לבין מפתחות מנוהלים על ידי לקוח ($1 לחודש, אתה הבעלים של המדיניות, אתה שולט ברוטציה, אתה מקבל נראות ביקורתית לכל קריאת Encrypt/Decrypt דרך CloudTrail). בסביבת פרודקשן תמיד יש להשתמש במפתחות מנוהלים על ידי לקוח.

   אנו מאפשרים רוטציה שנתית (enable_key_rotation = true) וכותבים מדיניות מפתח שמעניקה לשורש החשבון את היכולת לנהל את המפתח (ברירת המחדל של AWS לכל מפתח המנוהל על ידי לקוח) ומעניקים במפורש לשירות IAM Access Analyzer הרשאה להעריך את מדיניות המפתח. ה-alias מאפשר הפניה למפתח בשם קריא אנושית בקוד המשך במקום ב-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
   }

3. 3.הפעילו את IAM Access Analyzer כדי לזהות גישה ציבורית או צולבת חשבונות בלתי מכוונת

   משאבים:

   • AWS IAM Access Analyzer

   Access Analyzer מעריך באופן רציף מדיניות מבוססת משאבים (מדיניות S3 bucket, מדיניות מפתח KMS, מדיניות אמון תפקידי IAM, הרשאות Lambda, מדיניות תורי SQS, מדיניות רוטציה של Secrets Manager, ועוד) ומציף ממצא בכל פעם שהוא מזהה משאב נגיש מחוץ לחשבון או לגבולות האמון שלך. תחום Threat Detection and Incident Response של SCS-C03 בודק בדיוק תבנית זו — ממצאי Access Analyzer הם האות הקאנוני ל-"אוי, ה-bucket הזה עכשיו ציבורי".

   type = "ACCOUNT" מגביל את ה-analyzer לחשבון שלך; type = "ORGANIZATION" דורש AWS Organizations ומגביל לכל הארגון (התשובה למצב מרובה חשבונות ב-SCS-C03). כך או כך, הוא תמיד חינמי ודורש אפס תצורה לאחר ההפעלה.

   העתק

   resource "aws_accessanalyzer_analyzer" "main" {
     analyzer_name = "certlabpro-scs-c03"
     type          = "ACCOUNT"
   }

4. 4.הפעילו את GuardDuty כדי שנקבל הודעה כשמשהו תוקף אותנו בפועל

   משאבים:

   • Amazon GuardDuty

   GuardDuty הוא שירות זיהוי איומים מנוהל של AWS. הוא מנתח באופן רציף יומני CloudTrail, VPC Flow Logs ויומני DNS אל מול פידים של מודיעין איומים של AWS — רשימות מפורסמות של כתובות IP ידועות כגרועות, דומייני כריית קריפטו, תשתית פיקוד ובקרה, ותבניות התנהגות חשבון חשודות. ממצאים מגיעים מתויגים ברמת חומרה (Low / Medium / High) ובסוג הניתן לניתוח מכונה כמו 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"
   }

5. 5.הנחיתו הכל ב-bucket מרכזי ליומני ביקורת לשמירה וסקירה

   משאבים:

   • Amazon S3

   כל שאלת Security Logging and Monitoring של SCS-C03 מצפה שיהיה לכם Bucket מרכזי, מוצפן, בסגנון 'כתוב פעם אחת' שאליו כותבים כלי אבטחה אחרים — CloudTrail, VPC Flow Logs, יומני גישה של ELB, ייצוא GuardDuty, רשמי Config — כותבים לתוכו. ה-Bucket מוצפן עם מפתח ה-KMS המנוהל על ידי הלקוח משלב 2, גישה ציבורית חסומה לחלוטין, ומדיניות Bucket אוכפת שכל אובייקט שנכתב חייב לעבור דרך המפתח משלב 2 (לא מתקבלות כתיבות בטקסט רגיל).

   אנו משתמשים בהגדרת הבעלות bucket-owner-enforced (מצב ACLs מושבתים, מומלץ על ידי AWS מאז 2023) — זוהי אחת מתכונות אבטחת S3 הנבדקות ביותר ב-SCS-C03 מכיוון שהיא מבטלת סוג שלם של תצורות שגויות של ACLs בין חשבונות.

   עם ה-Bucket במקום, קו הבסיס הושלם: KMS למפתחות הצפנה, Access Analyzer לחשיפה בלתי מכוונת, GuardDuty לזיהוי איומים, ו-Bucket ביקורת לכל מה שצריך להישמר לצורך סקירת תאימות. כל תרחיש מרובה שירותים של SCS-C03 מצפה שתהיה לכם את ארבעת אלה; השאלות המתקדמות יותר מוסיפות 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"
           }
         }
       }]
     })
   }

ניקוי משאבים