0Pricing
AWS Solutions Architect · درس

سيناريوهات البنية الآمنة

تدرّب على أسئلة سيناريوهات حول أقل صلاحية في IAM والتشفير وعزل VPC وWAF وShield لترسيخ معرفتك بمجال الأمان

سيناريوهات البنية الآمنة درس مجاني في AWS Solutions Architect على CoddyKit. هذا هو الدرس 1 من أصل 4. يمكنك قراءة الدرس كاملاً أدناه مجاناً — ثم تمرن عليه مباشرة في المتصفح باستخدام محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7. هذا الدرس جزء من مسار التعلم في AWS Solutions Architect، وتقدمك يتزامن عبر الويب وتطبيق CoddyKit. تتضمن دورة AWS Solutions Architect 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 مع مفتاح تتم إدارته من العميل (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 في جميع المناطق. يحلل 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. ولا يمكن تعديل التطبيق فورًا. الحل: اربط AWS WAF بـ ALB. انشر مجموعة قواعد AWS Managed Rules for Common Threats (مجموعة Core Rule Set + مجموعة قواعد SQL Database)، التي تتضمن اكتشافًا مُعدًّا مسبقًا لحقن SQL. يفحص 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: افتراض دور عبر الحسابات

السيناريو: يحتاج حساب أمان مركزي إلى وصول للقراءة فقط إلى جميع حسابات أحمال العمل في AWS Organisation لإجراء عمليات تدقيق أمنية. الحل: أنشئ في كل حساب من حسابات أحمال العمل دور IAM يتضمن سياسة ثقة تسمح لحساب الأمان (بحسب معرّف الحساب) بافتراضه. أرفق به سياسة للقراءة فقط (مثل سياسة 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: تقييد الإجراءات باستخدام SCPs

السيناريو: تستخدم شركة AWS Organizations وتريد منع أي حساب في OU غير إنتاجية من تشغيل مثيلات GPU باهظة التكلفة. الحل: أنشئ Service Control Policy (SCP) ترفض ec2:RunInstances لعائلات مثيلات GPU (p3 وp4 وg4 وg5)، وأرفقها بـ OU غير الإنتاجية. تنطبق SCPs حتى على المستخدمين الجذر ومستخدمي IAM ذوي مستوى Administrator في حسابات الأعضاء — فهي تعمل كحواجز وقائية لا يمكن لأي هوية في الحساب تجاوزها. ويمنع ذلك الإنفاق الكبير العرضي أو الضار في حسابات التطوير والاختبار.

# 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 سنوات. الحل: أنشئ مسار 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 للوصول الخاص إلى S3

السيناريو: تحتاج مثيلات EC2 في VPC خاصة إلى الوصول إلى S3 دون عبور حركة المرور عبر الإنترنت العام. ويُستخدم حاليًا NAT Gateway، لكن التكاليف مرتفعة بسبب رسوم معالجة البيانات الخاصة به. الحل: أنشئ S3 Gateway VPC Endpoint. أضف إدخال مسار إلى جدول مسارات الشبكة الفرعية الخاصة، بحيث يوجّه قائمة بادئات S3 إلى نقطة النهاية. ستبقى حركة المرور إلى S3 الآن داخل العمود الفقري لشبكة AWS بالكامل — دون NAT Gateway أو بوابة إنترنت. وتكون S3 Gateway Endpoints مجانية (بخلاف Interface Endpoints التي تُفرض عليها رسوم لكل ساعة ولكل منطقة توافر). كما يحسّن ذلك الأمان بإزالة وصول 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 لإنشاء سجلات امتثال محمية من العبث. ننتقل بعد ذلك إلى سيناريوهات البنى resilient وعالية التوافر.

الأسئلة الشائعة

هل درس «سيناريوهات البنية الآمنة» مجاني؟

نعم — نص درس «سيناريوهات البنية الآمنة» كامل متاح مجاناً هنا على الويب. لتمرينه بشكل تفاعلي (محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7) وفتح باقي دورة AWS Solutions Architect، انتقل إلى CoddyKit PRO. تتضمن دورة AWS Solutions Architect 4 دروس في المجموع.

ماذا ستتعلم في «سيناريوهات البنية الآمنة»؟

تدرّب على أسئلة سيناريوهات حول أقل صلاحية في IAM والتشفير وعزل VPC وWAF وShield لترسيخ معرفتك بمجال الأمان تتمرن على AWS Solutions Architect مع أكواد عملية تشغلها مباشرة في المتصفح، ومدرس ذكاء اصطناعي متاح 24/7 يجيب على أسئلتك أثناء عملك.

هل أحتاج إلى خبرة سابقة لأبدأ AWS Solutions Architect؟

لا تُشترط خبرة سابقة. AWS Solutions Architect على CoddyKit منظم للمبتدئين حتى المتقدمين، لذا يمكنك البدء من هنا أو من البداية والتقدم بسرعتك الخاصة. هذا هو الدرس 1 من أصل 4.

كم من الوقت يستغرق درس «سيناريوهات البنية الآمنة»؟

معظم دروس CoddyKit تستغرق حوالي 5–10 دقائق. كل منها موجز وتفاعلي، لذا تحرز تقدماً مستمراً وتستأنف من حيث توقفت عبر الويب والتطبيق.

هل يمكنني كتابة وتشغيل أكواد في درس AWS Solutions Architect هذا؟

نعم. كل درس في AWS Solutions Architect يتضمن محرر أكواد مدمج، لذا تكتب وتشغل أكواداً حقيقية مباشرة في متصفحك وتحصل على تعليقات فورية من الذكاء الاصطناعي — بدون إعداد محلي.

جميع الدروس في هذه الدورة

  1. سيناريوهات البنية الآمنة
  2. سيناريوهات البنى المرنة وعالية التوافر
  3. سيناريوهات الأداء العالي وتحسين التكلفة
  4. اختبار مصغّر شامل بطول كامل للمجالات المختلطة
← العودة إلى AWS Solutions Architect