على نطاق واسع، الحوكمة ليست بيروقراطية — بل هي الانضباط الهندسي الذي يمنع مئتي فريق من تدمير بعضهم عن طريق الخطأ، أو إنفاق 800 ألف دولار على نسخ GPU منسية، أو فتح المنفذ 22 للإنترنت العام لأن أحدهم تجاوز مراجعة الأمان. في Amazon وGoogle وMicrosoft، الآلية واحدة: السياسة كبرمجيات مطبّقة على مستوى المنصة، لا مراجعتها لاحقاً من قِبل إنسان يقرأ جدول بيانات.
يغطي هذا الدرس أربع طبقات متشابكة من الحواجز الوقائية: سياسات التحكم في الخدمات (SCPs) لتحديد حدود الصلاحيات بشكل صارم، وقواعد AWS Config للامتثال المستمر، ومعايير الوسوم لمحاسبة الموارد، والميزانيات للتحكم في التكلفة. كل طبقة تعمل في نقطة مختلفة من مستوى التحكم — وبمجملها تشكّل نموذج حوكمة دفاعي متعمق لا يتطلب الثقة الكاملة بكل مطوّر.
سياسات التحكم في الخدمات (SCPs)
SCPs هي حدود قصوى للصلاحيات تُربط بالوحدات التنظيمية (OUs) أو الحسابات الفردية في AWS Organizations. هي لا تمنح صلاحيات — بل تخفّض السقف الأعلى لما يمكن لسياسات IAM أن تمنحه. يمكن لـSCP أن تمنع أي مبدأ في الحساب (بما فيه مستخدم الحساب الجذر لمعظم عمليات API) من استدعاء واجهات API معينة، بغض النظر عمّا تقوله سياسة IAM الخاصة به.
النموذج الذهني: سياسات IAM تحدد ما يُسمح للهوية القيام به. تحدد SCPs ما يُسمح للحساب بالسماح به. الصلاحية الفعلية هي تقاطع الاثنين. هذا يعني أن SCPs هي الطبقة المناسبة للقواعد التنظيمية الصارمة — الأشياء التي يجب ألا تحدث أبداً مهما كان الطالب.
تشمل أنماط SCPs الشائعة في الإنتاج: منع ec2:ModifyInstanceAttribute لتعطيل حماية الإنهاء على صناديق الإنتاج، ومنع organizations:LeaveOrganization لمنع مشرف مارق من إخراج حساب من الحوكمة، ومنع جميع استدعاءات API خارج المناطق المعتمدة (إقامة البيانات)، ومنع iam:CreateUser في حسابات العمل لفرض الوصول الفيدرالي فقط.
# منع أي إجراء خارج المناطق المعتمدة (SCP إقامة البيانات)
# استثناءات للخدمات العالمية: IAM, STS, Route 53, CloudFront, WAF
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyNonApprovedRegions",
"Effect": "Deny",
"NotAction": [
"iam:*",
"sts:*",
"route53:*",
"cloudfront:*",
"waf:*",
"support:*",
"trustedadvisor:*"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": [
"eu-west-1",
"eu-central-1"
]
}
}
}
]
}
# تطبيق عبر AWS CLI على وحدة تنظيمية
aws organizations attach-policy \
--policy-id p-xxxxxxxxxxxx \
--target-id ou-root-xxxxxxxx
تنطبق SCPs على كل مبدأ في الحساب بما فيه المستخدم الجذر (لمعظم واجهات API). اختبر SCPs في وحدة تنظيمية غير إنتاجية أولاً. SCP خاطئة تمنع sts:AssumeRole دون استثناءات يمكنها قطع الوصول عن كل إنسان ونظام CI في الحساب فوراً — والاسترداد يتطلب تدخل من حساب الإدارة.
يجب إدارة SCPs كموارد Terraform (aws_organizations_policy + aws_organizations_policy_attachment)، مُودَعة في مستودع منطقة الهبوط، ومُطبَّقة عبر خط CI يملك خطوة مراجعة إلزامية لـterraform plan. لا تطبّق تغييرات SCP يدوياً.
قواعد AWS Config
إذا كانت SCPs هي جدار الحماية — يمنع الإجراءات قبل حدوثها — فإن قواعد AWS Config هي المراجعة المستمرة — تكتشف متى ينتهك الوضع الحالي للموارد معاييرك. يسجّل Config كل تغيير على مستوى API للموارد المدعومة ويقيّم كل مورد بالنسبة للقواعد التي تحددها. تُطلق الموارد غير المتوافقة إشعارات (SNS)، أو نتائج (Security Hub)، أو معالجة تلقائية (وثائق SSM Automation).
تُوفّر AWS نحو 200 قاعدة مُدارة. تلك التي تُمكّن كل منظمة إنتاجية منذ اليوم الأول تشمل: restricted-ssh، وs3-bucket-public-read-prohibited، وencrypted-volumes، وrds-storage-encrypted، وmfa-enabled-for-iam-console-access، وrequired-tags. يمكن كتابة قواعد مخصصة كدوال Lambda (أو باستخدام لغة Guard) للفحوصات الخاصة بالعمل.
انشر قواعد Config عبر CloudFormation StackSets أو Terraform aws_config_conformance_pack عبر جميع الحسابات في وحدة تنظيمية في آنٍ واحد. يُجمّع معيار AWS Security Hub "Foundational Security Best Practices" نتائج Config من جميع الحسابات في لوحة واحدة — مكّنه في حساب أدوات الأمان وقم بتهيئة مجمّع حسابات متقاطعة.
معايير الوسوم
الوسوم هي النسيج الضام لحوكمة السحابة. بدون وسوم متسقة لا يمكنك الإجابة على: "من يملك هذه النسخة EC2؟" "ما التكلفة الشهرية لخدمة المدفوعات؟" "أي الموارد تخضع للائحة GDPR؟" كل انفجار تكلفة كبير في السحابة رأيته يعود إلى موارد غير موسومة أو موسومة بشكل غير متسق.
يحدث التطبيق في نقطتين. أولاً، تُعلّم قاعدة required-tags في Config أي مورد يفتقد وسوماً إلزامية بـNON_COMPLIANT — لكنها لا تمنع الإنشاء. للحجب، استخدم SCP أو حد صلاحيات IAM يضع شروطاً على ec2:RunInstances بالنسبة لمفاتيح الوسوم المطلوبة عبر شروط aws:RequestTag. ثانياً، تُطبّق وحدات Terraform الوسوم على مستوى الوحدة باستخدام merge(local.mandatory_tags, var.tags) حتى لا يتمكن المطوّرون من إغفالها.
# Terraform: وسوم إلزامية في كل وحدة مورد
locals {
mandatory_tags = {
Owner = var.owner # مثال: "payments-team@company.com"
Project = var.project # مثال: "PAY"
CostCenter = var.cost_center # مثال: "CC-4210"
Environment = var.environment # prod | staging | dev
DataClass = var.data_class # public | internal | confidential
Terraform = "true"
}
}
resource "aws_instance" "app" {
ami = var.ami_id
instance_type = var.instance_type
# دمج الوسوم المُقدَّمة من المستدعي؛ mandatory_tags تفوز عند التعارض
tags = merge(var.extra_tags, local.mandatory_tags)
}
# شرط SCP يمنع إطلاق EC2 بدون وسم Owner
# (أضفه إلى SCP رفض غير الموسوم)
"Condition": {
"Null": {
"aws:RequestTag/Owner": "true"
}
}
نموذج الحوكمة ذو الأربع طبقات: SCPs تمنع، قواعد Config تكتشف، الوسوم تُحقق المساءلة، الميزانيات تتحكم في التكلفة.
الميزانيات وحواجز التكلفة
ميزانية بلا إجراء هي مجرد إشعار لا يقرأه أحد. تستخدم حوكمة التكلفة الإنتاجية على نطاق واسع AWS Budgets مع إجراءات آلية لفرض حدود الإنفاق دون تدخل بشري. هناك ثلاثة مستويات من الاستجابة تستحق التهيئة في كل حساب:
تنبيه عند 80% — إخطار قناة Slack للفريق (عبر SNS → Lambda → Slack webhook). لا يُتخذ إجراء؛ إنذار مبكر.
تنبيه عند 100% — إخطار قيادة الهندسة وفريق FinOps. تُطلق موضوع SNS تقرأه دالة Lambda لنشر تذكرة P2 في نظام تتبع الحوادث.
إجراء عند 110% — تُطبق AWS Budgets سياسة IAM تمنع إطلاق نسخ EC2 أو RDS أو NAT Gateways جديدة في ذلك الحساب حتى إعادة ضبط الميزانية. هذه هي نقطة الإيقاف الصارمة التي تمنع حدث auto-scaling الجامح من إنفاق 50 ألف دولار خلال الليل.
أضف إلى ميزانيات مستوى الحساب اكتشاف الشذوذات في التكلفة. يستخدم AWS Cost Anomaly Detection التعلم الآلي لتحديد أنماط الإنفاق التي تنحرف عن الخطوط الأساسية التاريخية — سيكتشف وظيفة تدريب p3.16xlarge منسية أو حاوية S3 جُعلت عامة عن طريق الخطأ ويقصفها الروبوتات قبل أن تفعل فوترة نهاية الشهر.
على نطاق big-tech، تُحدَّد الميزانيات لكل حساب (لا للمنظمة بأكملها) حتى لا يُخفي إنفاق فريق واحد إشارات الآخرين. يمتلك فريق FinOps حساب "حوكمة التكلفة" الذي يُجمّع بيانات Cost Explorer عبر المنظمة عبر تقرير التكلفة والاستخدام (CUR) المُسلَّم إلى حاوية S3 في حساب الفوترة، والذي تستعلم عنه Athena وتصوّره Grafana أو QuickSight.
الجمع معاً: خط أنابيب الحوكمة
هذه الآليات الأربع أكثر فاعلية عندما تُدار كبرمجيات في نفس مستودع منطقة الهبوط. سير العمل الموصى به: تعيش SCPs وحزم امتثال Config في Terraform، مُطبَّقة بواسطة خط governance مخصص يتطلب موافقة مهندسَين كبيرَين. تُخزَّن حدود الميزانية كمتغيرات لكل حساب في خريطة budgets.tfvars. تُفرض معايير الوسوم على مستوى وحدة Terraform حتى يكون الامتثال تلقائياً لا طموحاً. أي انجراف من أي من هذه الطبقات يُطلق نتيجة Security Hub تُنبّه فريق المنصة — لا مجرد بريد إلكتروني لا يُقرأ.
أضف لوحة حالة الحواجز الوقائية إلى دليل تشغيلك: تقرير أسبوعي آلي يوضح نسبة تغطية SCP (الحسابات المُربوطة مقابل الإجمالي)، ودرجات امتثال Config لكل حساب، ومعدل امتثال الوسوم (من aws resourcegroupstaggingapi get-resources --tag-filters)، ومعدلات استهلاك الميزانية. اجعله مرئياً لقيادة الهندسة — الرؤية تخلق المساءلة.
نستخدم ملفات تعريف الارتباط لتشغيل هذا الموقع وتحليل الزيارات وعرض إعلانات مخصّصة. يمكنك قبول كل ملفات تعريف الارتباط أو رفض غير الأساسية منها.
سياسة الخصوصية