สถานการณ์สถาปัตยกรรมที่ปลอดภัย
ฝึกทำคำถามสถานการณ์เกี่ยวกับสิทธิ์น้อยที่สุดของ IAM การเข้ารหัส การแยก VPC และ WAF/Shield เพื่อเสริมความรู้ด้านความปลอดภัย
สถานการณ์สถาปัตยกรรมที่ปลอดภัย เป็นบทเรียน Cloud & IT Cert Prep ฟรีบน CoddyKit นี่คือบทเรียนที่ 1 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Cloud & IT Cert Prep และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Cloud & IT Cert Prep มีบทเรียนทั้งหมด 4 บทเรียน
สถานการณ์ที่ 1: การเข้าถึง EC2 ไปยัง S3 ตามสิทธิ์น้อยที่สุด
สถานการณ์: อินสแตนซ์ EC2 เรียกใช้แอปพลิเคชันเว็บที่จำเป็นต้องอ่านออบเจ็กต์จากบักเก็ต S3 ที่ระบุ ทีมรักษาความปลอดภัยกำหนดว่าต้องไม่มีการจัดเก็บข้อมูลประจำตัวระยะยาวไว้บนอินสแตนซ์ และการเข้าถึงต้องเป็นไปตามหลักสิทธิ์น้อยที่สุด วิธีแก้ไข: สร้าง บทบาท IAM พร้อมนโยบายที่อนุญาตเฉพาะ s3:GetObject บน ARN ของบักเก็ตที่ระบุ จากนั้นแนบบทบาทเข้ากับอินสแตนซ์ 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 ทีมกำกับดูแลการปฏิบัติตามข้อกำหนดกำหนดให้เข้ารหัสข้อมูลขณะจัดเก็บ และต้องสามารถตรวจสอบการใช้คีย์ได้ วิธีแก้ไข: เปิดใช้ การเข้ารหัส RDS โดยใช้ AWS KMS พร้อม Customer Managed Key (CMK) โดย CMK ช่วยให้ทีมรักษาความปลอดภัยควบคุมการหมุนเวียนคีย์ ดูการใช้คีย์ใน CloudTrail และเพิกถอนการเข้าถึงได้เมื่อจำเป็น โปรดทราบว่า ต้องเปิดใช้การเข้ารหัสขณะสร้างอินสแตนซ์ RDS — คุณไม่สามารถเข้ารหัสอินสแตนซ์ RDS ที่ไม่ได้เข้ารหัสอยู่แล้วแบบเดิมได้ หากต้องการเข้ารหัสฐานข้อมูลที่มีอยู่ ให้สร้างสแนปชอต คัดลอกสแนปชอตโดยเปิดใช้การเข้ารหัส แล้วกู้คืนจากสแนปชอตที่เข้ารหัสแล้ว
# 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 มีฟังก์ชัน Lambda สำหรับการหมุนเวียน RDS ในตัว) ปรับปรุงแอปพลิเคชันให้ดึงข้อมูลประจำตัวจาก Secrets Manager ขณะทำงานโดยใช้ SDK แอปพลิเคชันจะได้รับข้อมูลประจำตัวใหม่โดยอัตโนมัติ โดยไม่ต้องนำระบบไปใช้งานใหม่ทุกครั้งที่มีการหมุนเวียน เปิดใช้แม่แบบการหมุนเวียนข้อมูลลับของ 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 ในทุก Region GuardDuty วิเคราะห์เหตุการณ์ CloudTrail, บันทึกโฟลว์ VPC และบันทึก DNS โดยใช้แมชชีนเลิร์นนิงเพื่อตรวจจับความผิดปกติ เช่น การเรียก API จากพื้นที่ทางภูมิศาสตร์ที่ไม่คุ้นเคย รูปแบบการขุด Bitcoin บน 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 กำลังได้รับการโจมตีแบบ SQL injection และไม่สามารถแก้ไขแอปพลิเคชันได้ทันที วิธีแก้ไข: เชื่อมโยง AWS WAF กับ ALB นำกลุ่มกฎ AWS Managed Rules for Common Threats (Core Rule Set + กลุ่มกฎ SQL Database) ไปใช้งาน ซึ่งมีการตรวจจับ SQL injection ที่สร้างไว้ล่วงหน้า WAF จะตรวจสอบคำขอ HTTP ก่อนส่งไปยัง ALB และบล็อกคำขอที่ตรงกับรูปแบบการโจมตี โดยไม่ต้องเปลี่ยนแปลงโค้ดแอปพลิเคชัน นอกจากนี้ให้เปิดใช้การบันทึกของ 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: การใช้ Assume Role ข้ามบัญชี
สถานการณ์: บัญชีรักษาความปลอดภัยส่วนกลางต้องการสิทธิ์อ่านอย่างเดียวในบัญชีเวิร์กโหลดทั้งหมดภายใน AWS Organisation เพื่อดำเนินการตรวจสอบความปลอดภัย วิธีแก้ไข: ในแต่ละบัญชีเวิร์กโหลด ให้สร้าง บทบาท IAM พร้อมนโยบายความน่าเชื่อถือที่อนุญาตให้บัญชีรักษาความปลอดภัย ซึ่งระบุด้วย ID บัญชี สามารถเข้ารับบทบาทได้ แนบนโยบายแบบอ่านอย่างเดียว เช่น นโยบายที่ AWS จัดการ SecurityAudit ทีมรักษาความปลอดภัยในบัญชีส่วนกลางใช้ 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 ราคาแพง วิธีแก้ไข: สร้าง นโยบายควบคุมบริการ (SCP) ที่ปฏิเสธ ec2:RunInstances สำหรับกลุ่มอินสแตนซ์ GPU (p3, p4, g4, g5) และแนบนโยบายดังกล่าวกับ OU ที่ไม่ใช่ระบบผลิต SCP มีผลแม้กับผู้ใช้รูทและผู้ใช้ IAM ระดับผู้ดูแลระบบในบัญชีสมาชิก โดยทำหน้าที่เป็นรั้วป้องกันที่ไม่มีข้อมูลประจำตัวใดในบัญชีสามารถข้ามได้ วิธีนี้ป้องกันการใช้จ่ายจำนวนมากโดยไม่ตั้งใจหรือโดยประสงค์ร้ายในบัญชีพัฒนาและบัญชีทดสอบ
# 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: บันทึกการตรวจสอบเพื่อการปฏิบัติตามข้อกำหนด
สถานการณ์: บริษัทให้บริการทางการเงินต้องแสดงต่อผู้ตรวจสอบว่าการเรียกใช้ API ของ AWS ทั้งหมดได้รับการบันทึก ป้องกันการแก้ไข และเก็บรักษาไว้เป็นเวลา 7 ปี วิธีแก้ไข: สร้าง เส้นทาง AWS CloudTrail แบบหลายรีเจียน ที่ส่งบันทึกไปยังบักเก็ต S3 เฉพาะในบัญชีสำหรับการบันทึก เปิดใช้ การตรวจสอบความถูกต้องของไฟล์บันทึก ซึ่งใช้ไฟล์ไดเจสต์แบบเข้ารหัสเพื่อค้นหาการแก้ไขบันทึก ตั้งค่านโยบาย Object Lock ของ S3 ในโหมด Compliance พร้อมระยะเวลาเก็บรักษา 7 ปีบนบักเก็ตสำหรับการบันทึก วิธีนี้ทำให้ไม่สามารถลบหรือแก้ไขบันทึกได้ แม้โดยผู้ใช้รูท ตลอดระยะเวลาเก็บรักษาที่กำหนด
# 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: VPC Endpoint สำหรับการเข้าถึง S3 แบบส่วนตัว
สถานการณ์: อินสแตนซ์ EC2 ใน VPC ส่วนตัวจำเป็นต้องเข้าถึง S3 โดยไม่ให้ทราฟฟิกเดินทางผ่านอินเทอร์เน็ตสาธารณะ ขณะนี้ใช้ NAT Gateway อยู่ และมีต้นทุนสูงเนื่องจากค่าประมวลผลข้อมูลของ NAT Gateway วิธีแก้ไข: สร้าง S3 Gateway VPC Endpoint เพิ่มรายการเส้นทางในตารางเส้นทางของซับเน็ตส่วนตัว โดยชี้รายการคำนำหน้า S3 ไปยังเอนด์พอยต์ ขณะนี้ทราฟฟิกไปยัง S3 จะอยู่ภายในโครงข่ายหลักของ AWS ทั้งหมด ไม่จำเป็นต้องใช้ NAT Gateway หรือเกตเวย์อินเทอร์เน็ต เอนด์พอยต์เกตเวย์ของ S3 ไม่มีค่าใช้จ่าย แตกต่างจากเอนด์พอยต์อินเทอร์เฟซที่คิดค่าบริการรายชั่วโมงต่อ AZ วิธีนี้ยังช่วยเพิ่มความปลอดภัยด้วยการนำการเข้าถึง 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) จากบทเรียนนี้
สรุปบทเรียน
ในบทเรียนนี้ คุณได้ฝึกทำความเข้าใจสถานการณ์เกี่ยวกับ: บทบาท IAM และโปรไฟล์อินสแตนซ์สำหรับการเข้าถึง EC2 โดยไม่ต้องใช้ข้อมูลรับรอง, Secrets Manager สำหรับการหมุนเวียนข้อมูลรับรองฐานข้อมูลโดยอัตโนมัติ, AWS WAF สำหรับบล็อกการโจมตีแบบฉีดโค้ดโดยไม่ต้องเปลี่ยนแปลงโค้ด และ CloudTrail ร่วมกับ S3 Object Lock สำหรับบันทึกการปฏิบัติตามข้อกำหนดที่ป้องกันการแก้ไข ต่อไปเราจะศึกษาสถานการณ์เกี่ยวกับสถาปัตยกรรมที่ทนทานและมีความพร้อมใช้งานสูง
คำถามที่พบบ่อย
บทเรียน “สถานการณ์สถาปัตยกรรมที่ปลอดภัย” ฟรีหรือไม่
ใช่ — ข้อความเต็มของ “สถานการณ์สถาปัตยกรรมที่ปลอดภัย” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Cloud & IT Cert Prep ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Cloud & IT Cert Prep มีบทเรียนทั้งหมด 4 บทเรียน
คุณจะเรียนรู้อะไรในบทเรียน “สถานการณ์สถาปัตยกรรมที่ปลอดภัย”
ฝึกทำคำถามสถานการณ์เกี่ยวกับสิทธิ์น้อยที่สุดของ IAM การเข้ารหัส การแยก VPC และ WAF/Shield เพื่อเสริมความรู้ด้านความปลอดภัย คุณปฏิบัติ Cloud & IT Cert Prep ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน
คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Cloud & IT Cert Prep หรือไม่
ไม่จำเป็นต้องมีประสบการณ์มาก่อน Cloud & IT Cert Prep บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 1 จากทั้งหมด 4 บทเรียน
บทเรียน “สถานการณ์สถาปัตยกรรมที่ปลอดภัย” ใช้เวลานานแค่ไหน
บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย
ฉันเขียนและรันโค้ดในบทเรียน Cloud & IT Cert Prep นี้ได้ไหม
ได้ บทเรียน Cloud & IT Cert Prep ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ
บทเรียนทั้งหมดในหลักสูตรนี้
- สถานการณ์สถาปัตยกรรมที่ปลอดภัย
- สถานการณ์สถาปัตยกรรมที่ยืดหยุ่นและพร้อมใช้งานสูง
- สถานการณ์ประสิทธิภาพสูงและการเพิ่มประสิทธิภาพต้นทุน
- ข้อสอบจำลองฉบับสั้นแบบเต็มชุดจากหลายหมวด