الامتثال والسياسات ككود

الحواجز الأمنية السحابية الأصيلة

18 دقيقة الدرس 7 من 27

الحواجز الأمنية السحابية الأصيلة

تتعامل سياسة الكود على مستوى Kubernetes (OPA وKyverno) مع قرارات الأحمال. لكن الحواجز التي تحكم حسابك السحابي بالكامل — ما المناطق المسموح بها، ما الخدمات التي يمكن توفيرها، ما التشفير الواجب تطبيقه — تعيش في طبقة أعلى داخل مستوى التحكم السحابي نفسه. في AWS، ثلاث آليات متداخلة تفرض هذه الطبقة: سياسات التحكم في الخدمات (SCPs)، وقواعد AWS Config، وحزم المطابقة (Conformance Packs). فهم متى تستخدم كلًا منها، وكيف تفشل، هو الفرق بين وضع امتثال يصمد تحت الضغط وآخر ينكسر أول مرة يتجاوز فيه مهندس القواعد.

سياسات التحكم في الخدمات: السياج الخارجي

SCPs هي مستندات سياسة IAM مرفقة بحسابات أو وحدات تنظيمية (OUs) في AWS Organizations. على خلاف سياسات IAM التي تمنح الأذونات، تحدد SCPs حد الأذونات القصوى. حتى المستخدم الجذر للحساب لا يمكنه فعل ما تحظره SCP. هذه الخاصية هي ما يجعل SCPs فريدة القوة: إنها تنطبق على كل مبدأ في الحساب دون استثناء.

مبادئ التصميم الأساسية لـ SCPs على مستوى الإنتاج:

نموذج الرفض الافتراضي هو النموذج الصحيح. تأتي AWS Organizations بسياسة FullAWSAccess المدمجة التي تسمح بكل شيء. تضيف SCPs الخاصة بك رفضًا صريحًا إضافيًا فوقها. تعمل SCPs كمرشح للسماح على ما يمكن أن تمنحه IAM، وليس كمنح بحد ذاتها.
SCPs لا تمنح الأذونات. لا يزال المبدأ بحاجة إلى سياسة IAM تسمح بالإجراء. SCP + IAM allow = الأذونات الفعلية. SCP deny = محظور بصرف النظر عن IAM.
الاستثناءات تتطلب شرطًا وليس سياسة منفصلة. بدلًا من إنشاء سياستين، استخدم شروط ArnNotLike أو StringNotEquals لإعفاء أدوار محددة مضمنة. يبقي هذا سطح السياسة الأدنى.
اختبر في OU الاختبار أولًا. SCP معطوبة تحظر sts:AssumeRole في حساب إنتاج ستغلق كل أتمتة عابرة للحسابات. لا يمكنك إصلاحها من داخل الحساب — فقط مشرف Organizations يمكنه إزالة SCP.

# SCP: رفض أي إجراء خارج المناطق المعتمدة
# ارفقها بـ Workloads OU؛ تعفي الخدمات العالمية التي لا تحمل مفهوم المنطقة
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyNonApprovedRegions",
      "Effect": "Deny",
      "NotAction": [
        "iam:*",
        "organizations:*",
        "route53:*",
        "budgets:*",
        "cloudfront:*",
        "sts:*",
        "support:*",
        "trustedadvisor:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "us-east-1",
            "eu-west-1"
          ]
        }
      }
    }
  ]
}

SCP تقييد المنطقة من أكثر متجهات قفل الحسابات شيوعًا. إن نسيت إضافة IAM وSTS إلى NotAction، ستفشل عمليات نشر CloudFormation بصمت لأن CloudFormation يستدعي sts:AssumeRole داخليًا — وستحظره SCP حتى لو كان لدى دور النشر سياسات IAM الصحيحة. احرص دومًا على إدراج الخدمات العالمية في NotAction قبل نشر هذا النوع من SCPs على OU الإنتاج.

SCP ثانية شائعة تفرض أن كل حاويات S3 يجب أن تحتوي على تشفير وتحظر الوصول العام. هذا لا يتكرر مع AWS Config — فـ Config يكشف بعد وقوع الأمر، بينما تمنع SCP التوفير من الأصل:

# SCP: رفض PutObject على S3 إلا إذا كان رأس التشفير حاضرًا من جانب الخادم
# يمنع الرفعات غير المشفرة على مستوى واجهة برمجة التطبيقات
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUnencryptedS3Uploads",
      "Effect": "Deny",
      "Action": "s3:PutObject",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "s3:x-amz-server-side-encryption": [
            "aws:kms",
            "AES256"
          ]
        }
      }
    },
    {
      "Sid": "DenyS3PublicAccess",
      "Effect": "Deny",
      "Action": [
        "s3:PutBucketPublicAccessBlock",
        "s3:DeletePublicAccessBlock"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "s3:publicAccessBlockConfiguration": "false"
        }
      }
    }
  ]
}

الطبقات الثلاث للحواجز في AWS: SCPs تمنع، قواعد Config تكشف، حزم المطابقة تُبلِّغ.

قواعد AWS Config: الضوابط الكاشفة على نطاق واسع

حيث تكون SCPs وقائية — تحظر قبل حدوث أي شيء — فإن قواعد AWS Config كاشفة. يسجّل Config حالة تكوين كل مورد AWS مدعوم ويقيّمه مقابل القواعد التي تحددها. عندما يتحول مورد إلى حالة غير ممتثلة، يصنفه Config بـ NON_COMPLIANT ويمكنه تشغيل معالجة آلية عبر مستند SSM Automation أو دالة Lambda.

تأتي قواعد Config في شكلين:

القواعد المُدارة من AWS: قواعد مبنية مسبقًا لأكثر فحوصات الامتثال شيوعًا. encrypted-volumes وrds-storage-encrypted وs3-bucket-ssl-requests-only وiam-password-policy وmfa-enabled-for-iam-console-access — أكثر من 200 قاعدة متاحة. استخدم هذه القواعد قبل كتابة قواعد مخصصة؛ فهي مُصانة من قِبل AWS.
القواعد المخصصة: دوال Lambda تكتبها وتنشرها وتستقبل لقطة تكوين وتُعيد حكم امتثال. استخدم هذه القواعد عندما يكون الضابط خاصًا ببنيتك — مثل فرض أن كل كتلة RDS يجب أن تحمل مجموعة محددة من الوسوم لتخصيص التكاليف.

تُقيّم قواعد Config عند التغيير أو بجدول زمني. تنطلق القواعد المُشغَّلة بالتغيير في غضون دقائق من تعديل المورد — مثالية لضوابط التشفير والوصول. أما القواعد الدورية (1h، 3h، 6h، 12h، 24h) فهي أفضل للضوابط الباهظة التقييم عند كل استدعاء API، كفحص وثائق سياسة IAM بحثًا عن أحرف بدل. معظم القواعد الحرجة للامتثال يجب أن تكون مُشغَّلة بالتغيير.

نشر قاعدة Config عبر Terraform — الطريقة الصحيحة لإدارة Config على نطاق واسع:

# Terraform: نشر قاعدتي Config مُدارتين مع معالجة آلية
resource "aws_config_config_rule" "rds_encrypted" {
  name = "rds-storage-encrypted"

  source {
    owner             = "AWS"
    source_identifier = "RDS_STORAGE_ENCRYPTED"
  }

  depends_on = [aws_config_configuration_recorder.main]
}

resource "aws_config_config_rule" "s3_ssl_only" {
  name = "s3-bucket-ssl-requests-only"

  source {
    owner             = "AWS"
    source_identifier = "S3_BUCKET_SSL_REQUESTS_ONLY"
  }

  depends_on = [aws_config_configuration_recorder.main]
}

# معالجة آلية: تفعيل تشفير RDS على المثيلات غير الممتثلة
resource "aws_config_remediation_configuration" "rds_encrypt_remediation" {
  config_rule_name = aws_config_config_rule.rds_encrypted.name
  target_type      = "SSM_DOCUMENT"
  target_id        = "AWS-EnableRDSEncryption"
  automatic        = true

  maximum_automatic_attempts = 3
  retry_attempt_seconds      = 60

  parameter {
    name           = "DBInstanceIdentifier"
    resource_value = "RESOURCE_ID"
  }
}

المعالجة الآلية يمكنها تدمير البيانات إن أسأت إعدادها. تفعيل التشفير على مثيل RDS يعمل يتطلب إيقافه وإنشاء لقطة مشفرة جديدة — وهي عملية مُخِلّة تستدعي توقفًا. اختبر دومًا مستندات المعالجة في حساب غير إنتاجي، واضبط automatic = false في البداية، واشترط موافقة بشرية عبر إشعار SNS قبل التحويل إلى معالجة آلية كاملة على الموارد الحاملة للحالة.

حزم المطابقة: ربط القواعد بالأطر

حزمة المطابقة هي قالب YAML يجمع مجموعة من قواعد Config — وربما إجراءات معالجتها — في وحدة قابلة للنشر واحدة مرسومة على إطار امتثال. تشحن AWS حزمًا جاهزة لـ CIS AWS Foundations Benchmark وPCI DSS وHIPAA وNIST 800-53 وSOC 2. تنشرها على حسابات فردية أو عبر مؤسسة كاملة عبر AWS Config أو CLI أو Terraform.

القيمة الأساسية لحزم المطابقة هي أدلة التدقيق. بدلًا من تشغيل استعلامات قواعد Config يدويًا وجمع جداول بيانات، يمكنك توجيه المدقق إلى لوحة Conformance Pack: صفحة واحدة تُظهر نسبة الامتثال لكل قاعدة وقائمة الموارد غير الممتثلة وطوابع وقت جميع التقييمات.

# نشر حزمة CIS Level 2 المُدارة من AWS عبر CLI
# يُفعّل ~52 قاعدة Config متوافقة مع CIS AWS Foundations Benchmark v1.4
aws configservice put-conformance-pack \
  --conformance-pack-name "CISLevel2Benchmark" \
  --template-s3-uri "s3://aws-service-catalog-us-east-1-artifacts/conformance-packs/operational-best-practices-for-cis-aws-benchmark-level-2.yaml" \
  --region us-east-1

# التحقق من درجة الامتثال الإجمالية للحزمة
aws configservice describe-conformance-pack-compliance \
  --conformance-pack-name "CISLevel2Benchmark" \
  --query "ConformancePackRuleComplianceList[?ComplianceType==\'NON_COMPLIANT\']" \
  --output table

# إدراج جميع الموارد غير الممتثلة لقاعدة محددة ضمن الحزمة
aws configservice get-compliance-details-by-config-rule \
  --config-rule-name "CIS-2-1-ensure-cloudtrail-enabled-in-all-regions" \
  --compliance-types NON_COMPLIANT \
  --output json

تطبيق الآليات الثلاث في طبقات

في المؤسسات المُدارة جيدًا، هذه الأدوات الثلاثة ليست بدائل — بل تشكّل دفاعًا متعدد الطبقات حيث تتعامل كل طبقة مع الحالات التي لا تستطيع الأخريات التعامل معها:

SCPs تفرض الحدود المطلقة لما يمكن للحساب فعله. قيود المناطق، قفل الحساب الجذر، تعطيل الخدمات غير المستخدمة. لا تستطيع SCPs تقييم سمات الموارد — فهي تعمل على استدعاء API، وليس على حالة المورد الناتجة.
قواعد Config تقيّم تكوين المورد باستمرار. تلتقط الانجراف الذي لا تستطيع SCPs التقاطه — كحاوية كانت موجودة قبل تطبيق SCP التشفير، أو وسم أُزيل بعد التوفير.
حزم المطابقة تجمع نتائج قواعد Config في تقارير مرسومة على إطار. لا تضيف فرضًا جديدًا؛ بل تضيف رؤية جاهزة للتدقيق وطبقة حوكمة تُسمّي الإطار الذي تُرضيه كل قاعدة.

النمط الإنتاجي المتبع في بيئات AWS واسعة النطاق: تعيش SCPs في JSON مُصدَر إلى مجلد scp/ وتُنشر عبر وحدة Terraform جذرية في حساب الإدارة. تُنشر قواعد Config وحزم المطابقة عبر وحدة config/ منفصلة تعمل في كل حساب عضو من خلال Organizations StackSet. يجمع Config Aggregator مركزي في حساب الإدارة حالة الامتثال من جميع الحسابات في لوحة واحدة. النتائج غير الممتثلة التي تتجاوز عمرًا قابلًا للإعداد تُطلق تذكرة Jira عبر EventBridge + Lambda، وتُربط التذكرة بتقييم Config كدليل تدقيق. هذا يُغلق الحلقة بين الكشف والمعالجة دون أي عمل جداول بيانات يدوي.