تقوية أمن السحابة وKubernetes

الهوية هي الحدود الأمنية

18 دقيقة الدرس 3 من 28

الهوية هي الحدود الأمنية

في أمن مراكز البيانات التقليدية، كان طرف الشبكة هو الحد الفاصل. كانت جدران الحماية تحرس الخندق. إذا كنت داخل أسوار القلعة، كنت موثوقًا. لكن السحابة دمّرت هذا النموذج. تمتد البنية التحتية الآن عبر سحابات متعددة، وأجهزة لابتوب، ومشغّلات CI/CD، وواجهات برمجية SaaS، وحاويات Kubernetes — وكلها تتواصل عبر الإنترنت العام. الخندق اختفى. الهوية الآن هي نقطة التطبيق الوحيدة الثابتة التي تمتلكها.

يركّز هذا الدرس على ثلاث مهارات على مستوى الإنتاج تُميّز مهندسي DevOps الكبار عن الصغار: تطبيق الصلاحية الدنيا على نطاق واسع، وإدارة الأدوار بشكل مستمر، ونشر محللات الوصول الآلية التي ترصد الانحرافات قبل المهاجمين.

الصلاحية الدنيا على نطاق واسع: لماذا هي صعبة وكيف تطبّقها الشركات الكبرى

مبدأ الصلاحية الدنيا سهل الصياغة وشبه مستحيل الصيانة على نطاق واسع دون أدوات. فبمجرد أن يضيف مطوّر AdministratorAccess إلى دور "للاختبار فقط" ويُدمج طلب السحب يوم الجمعة، يتضاعف نطاق الضرر المحتمل. على النطاق الواسع — مئات الأدوار، وعشرات خطوط CI، وآلاف حسابات الخدمة في Kubernetes — المراجعة اليدوية مجرد مسرحية.

تطبيق الصلاحية الدنيا على مستوى الإنتاج يستلزم ثلاثة أشياء تعمل معًا:

ابدأ بالحد الأدنى، وارفع الصلاحيات عمدًا. تبدأ الأدوار الجديدة بلا صلاحيات. تُضاف الصلاحيات فقط عندما تكون هناك متطلبات خدمة موثّقة، لا عندما يحصل أحدهم على خطأ AccessDenied ويصعّد الأمر.
قِس الاستخدام الفعلي، لا المفترض. يُنشئ AWS IAM Access Analyzer توصيات بناءً على نشاط CloudTrail خلال الـ 90 يومًا الماضية. كل شيء غير مُستخدم يُزال دوريًا.
عامِل سياسات IAM ككود. تعيش جميع تعريفات الأدوار في Terraform. تمر التغييرات عبر مراجعة طلبات السحب، تمامًا مثل كود التطبيق. لا يُسمح بأي تغييرات من واجهة الكونسول فحسب؛ يمكن لـ SCPs (سياسات التحكم بالخدمة) تطبيق هذا على مستوى المؤسسة.

مثال ملموس: دالة Lambda تقرأ من جدول DynamoDB واحد يجب أن يكون لها دور مُقيّد بالضبط بذلك الجدول وتلك العمليات. ليس وصولًا كاملًا لـ DynamoDB. ليس قراءةً لجميع الجداول. جدول واحد، مجموعة واحدة من العمليات.

# Terraform: minimal IAM role for a Lambda reading one DynamoDB table
resource "aws_iam_role" "order_reader_lambda" {
  name = "order-reader-lambda-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect    = "Allow"
      Principal = { Service = "lambda.amazonaws.com" }
      Action    = "sts:AssumeRole"
    }]
  })
}

resource "aws_iam_role_policy" "order_reader_policy" {
  name = "order-reader-policy"
  role = aws_iam_role.order_reader_lambda.id

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Sid    = "ReadOrdersTable"
        Effect = "Allow"
        Action = [
          "dynamodb:GetItem",
          "dynamodb:Query",
          "dynamodb:BatchGetItem"
        ]
        Resource = "arn:aws:dynamodb:us-east-1:123456789012:table/orders"
      },
      {
        Sid    = "WriteLogs"
        Effect = "Allow"
        Action = [
          "logs:CreateLogGroup",
          "logs:CreateLogStream",
          "logs:PutLogEvents"
        ]
        Resource = "arn:aws:logs:*:*:*"
      }
    ]
  })
}

عندما لا تكون متأكدًا من الصلاحيات التي يحتاجها حمل العمل، انشره أولًا مع تمكين CloudWatch Logs وسياسة arn:aws:iam::aws:policy/ReadOnlyAccess. دعه يعمل يومًا كاملًا. ثم استخدم IAM Access Analyzer لتوليد السياسة بناءً على أحداث CloudTrail الفعلية. قيّدها بالضبط على ما وجدته، ثم احذف ReadOnlyAccess. هذه هي حلقة البناء-القياس-التضييق التي تستخدمها Google وAmazon داخليًا.

الصلاحية الدنيا لحسابات خدمة Kubernetes مع IRSA وWorkload Identity

داخل Kubernetes، كل Pod يستدعي واجهات AWS يجب أن يستخدم IAM Roles for Service Accounts (IRSA) على EKS، أو Workload Identity على GKE. لا تُضمّن بيانات AWS طويلة الأمد كأسرار. يُصدر مسار IRSA رموز STS قصيرة الأمد مرتبطة بحساب خدمة Kubernetes محدد، مقيّدة بعلاقة ثقة OIDC. لا يعيش أي رمز أطول من عمر الـ Pod.

# Annotate the Kubernetes service account to bind it to an IAM role
apiVersion: v1
kind: ServiceAccount
metadata:
  name: order-reader-sa
  namespace: orders
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/order-reader-lambda-role

---
# The IAM role trust policy must allow the OIDC provider to assume it
# (managed by Terraform eks_iam_role_for_service_account module in practice)

# Verify the token is being injected correctly in the running pod:
# kubectl exec -n orders <pod> -- env | grep AWS
# AWS_ROLE_ARN=arn:aws:iam::123456789012:role/order-reader-lambda-role
# AWS_WEB_IDENTITY_TOKEN_FILE=/var/run/secrets/eks.amazonaws.com/serviceaccount/token

عطل شائع في بيئة الإنتاج: يصبح بصمة OIDC في موفر IAM قديمة عندما تُجدّد AWS الشهادة. جدّد البصمة عبر Terraform بنفس دورة تحديثات AWS SDK، أو ثبّت بصمة الجذر بدلًا من الوسيطة. الأعراض هي فشل صامت في المصادقة داخل الحمل؛ وبصمة OIDC القديمة هي سبب جذري شائع.

صيانة الأدوار: التنظيف المستمر على نطاق واسع

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

الخطة القياسية للشركات الكبرى:

تتبّع آخر استخدام. يسجّل كل دور IAM متى استُخدم آخر مرة وفي أي منطقة. الأدوار غير المستخدمة لـ 90 يومًا تُعزل (ترفض الكل عبر سياسة رفض مدمجة)، ثم تُحذف بعد فترة سماح مدتها 14 يومًا.
وسوم ملكية الأدوار. يحمل كل دور وسوم Owner وTeam وExpires. الأدوار غير الموسومة تُعزل تلقائيًا. تُطبّق خطوط CI الوسوم وقت الإنشاء عبر سياسة كـ كود (OPA أو SCP).
تطبيق حدود الصلاحية. يجب أن تحمل جميع الأدوار التي ينشئها المطورون حدود صلاحية تُقيّد أقصى صلاحيات يمكنهم منحها لأنفسهم. هذا يمنع تصعيد الامتيازات حتى لو أنشأ المطور دورًا بسياسة واسعة.

# AWS CLI: find IAM roles unused for more than 90 days
aws iam generate-credential-report
aws iam get-credential-report --output text --query Content | base64 -d > creds.csv

# Or use the Access Advisor API for per-service last-used data:
aws iam list-roles --query 'Roles[*].[RoleName,RoleLastUsed.LastUsedDate]' \
  --output text | sort -k2 | head -40

# Identify roles with no last-used date (never used):
aws iam list-roles | jq -r \
  '.Roles[] | select(.RoleLastUsed.LastUsedDate == null) | .RoleName'

# Attach a quarantine deny policy to a stale role:
aws iam put-role-policy \
  --role-name stale-migration-role \
  --policy-name QuarantineDenyAll \
  --policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Deny","Action":"*","Resource":"*"}]}'

IAM Access Analyzer: الكشف الآلي عن الانحراف

AWS IAM Access Analyzer هو محرك تحليل مستمر يراقب سياسات الموارد (سياسات دلاء S3، وسياسات مفاتيح KMS، وطوابير SQS، وسياسات دوال Lambda، وأدوار IAM، وغيرها) ويُبلّغ عن أي كيان خارج نطاق ثقتك تم منحه وصولًا. كما يُنشئ توصيات سياسات بأدنى صلاحية من CloudTrail، ويمكنه التحقق من صحة السياسات التي تكتبها مقابل قواعد نحو سياسات AWS وأنماط الأمان المعروفة قبل النشر.

يقرأ IAM Access Analyzer باستمرار سياسات الموارد وأحداث CloudTrail، ويكشف النتائج، ويُغذّي سير عمل المعالجة.

يعمل Access Analyzer على مستوى مؤسسة AWS. فعّله في كل منطقة (بما في ذلك المناطق التي تعتقد أنك لا تستخدمها — يُفضّل المهاجمون المناطق الهادئة). يجب أن تُوجَّه جميع النتائج إلى Security Hub الذي يجمعها مع نتائج GuardDuty وInspector وMacie في لوحة واحدة يراقبها فريق الأمان.

# Enable IAM Access Analyzer at the organization level (run from management account)
aws accessanalyzer create-analyzer \
  --analyzer-name org-analyzer \
  --type ORGANIZATION \
  --region us-east-1

# Generate a least-privilege policy recommendation for a specific role
# based on the last 90 days of CloudTrail activity:
aws accessanalyzer start-policy-generation \
  --policy-generation-details '{"principalArn":"arn:aws:iam::123456789012:role/order-reader-lambda-role"}'

# List unresolved findings (external access alerts):
aws accessanalyzer list-findings \
  --analyzer-arn arn:aws:accessanalyzer:us-east-1:123456789012:analyzer/org-analyzer \
  --filter '{"status":{"eq":["ACTIVE"]}}' \
  --query 'findings[*].[id,resource,resourceType,condition]' \
  --output table

# Validate a policy document before you deploy it:
aws accessanalyzer validate-policy \
  --policy-document file://proposed-policy.json \
  --policy-type IDENTITY_POLICY

يكشف Access Analyzer فئة من الأخطاء يفوتها المراجعون البشريون: الوصول العام الضمني. سياسة مفتاح KMS تقول "Principal": "*" مع شرط يظن الفريق أنه مقيّد لكنه في الواقع صحيح دائمًا — غير مرئية لمراجع يتصفح JSON. يُقيّم المحلل منطق السياسة الكامل ويُبلّغ عنها. فعّله وعامل كل نتيجة نشطة كحادثة درجة 2.

الجمع معًا: حلقة التغذية الراجعة لصيانة الهوية

تُدير المؤسسات الرائدة صيانة الهوية كحلقة تغذية راجعة آلية مستمرة بدلًا من مراجعة ربع سنوية. الدورة هي: تعريف أدوار ضيقة في Terraform → النشر → قياس الاستخدام الفعلي عبر CloudTrail → إنشاء توصيات Access Analyzer → فتح طلبات سحب آلية لإزالة الصلاحيات غير المستخدمة → الدمج → التكرار كل 90 يومًا. أضف إلى ذلك تنبيهات على أي استدعاء AssumeRole يعبر حدود الحسابات بشكل غير متوقع، وأي استدعاء API للجذر جديد، وأي إرفاق سياسة لكيان بعملية بدل النجمة. صيانة الهوية ليست مشروعًا — إنها بند ثابت في دوريات الاستجابة للحوادث.