فهم AWS KMS: هل تستخدم مفتاحاً مُدَاراً من AWS أم مفتاح CMK لتشفير S3؟

عندما تحتاج إلى تشفير حاوية S3 في بيئة إنتاجية، يظهر السؤال الأول دائماً: هل أستخدم المفتاح المُدار من AWS أم أنشئ مفتاحاً خاصاً بي؟ الإجابة ليست تقنية بحتة — بل تعتمد على متطلبات الامتثال، ونموذج التحكم، والتكلفة التشغيلية. فهم AWS KMS بشكل صحيح يحميك من قرارات مكلفة يصعب التراجع عنها لاحقاً.

ملخص سريع (TL;DR) — فهم AWS KMS وخيارات التشفير

المعيار	AWS Managed Key (aws/s3)	Customer Managed Key (CMK)
التحكم في دورة حياة المفتاح	AWS تتحكم بالكامل	أنت تتحكم بالكامل
سياسة المفتاح (Key Policy)	غير قابلة للتخصيص	قابلة للتخصيص بالكامل
التدوير التلقائي (Rotation)	كل سنة تلقائياً	اختياري — يمكن تفعيله
الرسوم الشهرية للمفتاح	مجاني	رسوم شهرية لكل مفتاح
رسوم عمليات API	رسوم على كل استدعاء	رسوم على كل استدعاء
مناسب لـ	تشفير بسيط بدون متطلبات امتثال معقدة	امتثال PCI-DSS / HIPAA / فصل الصلاحيات

كيف يعمل AWS KMS — الأساس المعماري

AWS KMS هو خدمة إدارة مفاتيح مُدارة بالكامل تعتمد على وحدات أمان الأجهزة (HSM) المعتمدة بمعيار FIPS 140-2. المفتاح نفسه لا يغادر KMS أبداً — بدلاً من ذلك، يُرسَل البيانات إلى KMS ليتم تشفيرها أو فك تشفيرها داخل الخدمة، أو تُستخدم آلية Envelope Encryption حيث يُشفَّر مفتاح بيانات (Data Key) بواسطة مفتاح KMS الرئيسي.

عند تشفير S3، لا يُرسَل محتوى الملف إلى KMS مباشرةً. بدلاً من ذلك، تطلب S3 من KMS مفتاح بيانات (Data Encryption Key)، تستخدمه لتشفير الكائن محلياً، ثم تخزن النسخة المشفرة من مفتاح البيانات مع الكائن. هذا هو جوهر Envelope Encryption.

sequenceDiagram participant App as التطبيق participant S3 as Amazon S3 participant KMS as AWS KMS App->>S3: PutObject (الكائن) S3->>KMS: GenerateDataKey (باستخدام CMK) KMS-->>S3: مفتاح البيانات (نصي + مشفر) S3->>S3: تشفير الكائن بمفتاح البيانات النصي S3->>S3: حذف مفتاح البيانات النصي من الذاكرة S3->>S3: تخزين الكائن المشفر + مفتاح البيانات المشفر S3-->>App: 200 OK App->>S3: GetObject S3->>KMS: Decrypt (مفتاح البيانات المشفر) KMS-->>S3: مفتاح البيانات النصي S3->>S3: فك تشفير الكائن S3-->>App: الكائن النصي

1. طلب PutObject: يرسل التطبيق الكائن إلى S3.
2. طلب GenerateDataKey: تطلب S3 من KMS مفتاح بيانات مشفراً باستخدام مفتاح KMS المحدد.
3. تشفير محلي: تستخدم S3 النسخة النصية من مفتاح البيانات لتشفير الكائن، ثم تحذف النسخة النصية من الذاكرة.
4. التخزين: يُخزَّن الكائن المشفر + النسخة المشفرة من مفتاح البيانات معاً في S3.
5. عند القراءة: تطلب S3 من KMS فك تشفير مفتاح البيانات، ثم تفك تشفير الكائن وتعيده للمستخدم.

أنواع مفاتيح KMS — فهم AWS KMS بعمق

ثمة ثلاثة أنواع رئيسية من المفاتيح في KMS، ولكل منها نموذج تحكم مختلف:

1. AWS Managed Keys

هذه مفاتيح تُنشئها AWS تلقائياً لكل خدمة تدعم التشفير. معرّفها يتبع نمط aws/<service> — مثل aws/s3 لـ S3. لا يمكنك تعديل سياسة هذا المفتاح، ولا تعطيله، ولا حذفه. AWS تتولى التدوير التلقائي كل سنة تقريباً.

2. Customer Managed Keys (CMK)

مفاتيح تُنشئها أنت في حسابك. تتحكم في سياسة المفتاح بالكامل، يمكنك تفعيل التدوير التلقائي، تعطيل المفتاح، تحديد من يملك صلاحية الاستخدام مقابل من يملك صلاحية الإدارة، وإضافة Grants لمنح صلاحيات مؤقتة. هذا هو الخيار المطلوب في بيئات الامتثال الصارمة.

3. AWS Owned Keys

مفاتيح تملكها AWS وتستخدمها عبر حسابات متعددة لخدمات معينة. لا ترى هذه المفاتيح في حسابك ولا تتحكم فيها بأي شكل. بعض خدمات AWS تستخدمها كخيار افتراضي.

graph TD A["مفاتيح KMS"] --> B["AWS Owned Keys
لا تظهر في حسابك"] A --> C["AWS Managed Keys
aws/s3 - aws/rds"] A --> D["Customer Managed Keys
CMK"] C --> C1["تحكم: AWS فقط"] C --> C2["تكلفة: مجاني"] C --> C3["التعطيل: غير ممكن"] D --> D1["تحكم: أنت بالكامل"] D --> D2["تكلفة: رسوم شهرية"] D --> D3["التعطيل: ممكن فوراً"] D --> D4["Cross-account: مدعوم"]

AWS Managed Key مقابل CMK — متى تختار كلاً منهما؟

اختر AWS Managed Key إذا:

• تحتاج تشفيراً بسيطاً دون متطلبات امتثال تفرض فصل الصلاحيات.
• لا تحتاج إلى تدقيق مفصّل على من استخدم المفتاح ومتى.
• لا تريد تحمّل تكلفة إضافية لكل مفتاح.
• البيانات ليست حساسة بما يكفي لتبرير تعقيد CMK.

اختر CMK إذا:

• تعمل في بيئة تتطلب امتثال PCI-DSS أو HIPAA أو SOC 2 وتحتاج إثبات التحكم في المفاتيح.
• تريد منع حتى مسؤولي AWS من الوصول النظري للبيانات (Key Policy صارمة).
• تحتاج مشاركة الوصول مع حسابات AWS أخرى (Cross-account access).
• تريد تعطيل المفتاح فوراً في حالة اختراق أمني — AWS Managed Key لا يمكن تعطيله.
• تحتاج Grants لمنح صلاحيات مؤقتة لخدمات أخرى.

القدرة على تعطيل CMK فوراً هي ميزة أمنية حقيقية — ليست مجرد خيار إداري. في حالة اختراق بيانات اعتماد، تعطيل المفتاح يوقف أي وصول جديد للبيانات المشفرة بشكل فوري، بغض النظر عن الصلاحيات الأخرى.

تكاليف AWS KMS — ما الذي تدفعه فعلاً؟

التسعير يتغير — تحقق دائماً من صفحة تسعير AWS KMS الرسمية للأرقام الحالية. لكن هيكل التكلفة ثابت:

رسوم المفاتيح الشهرية

• AWS Managed Keys: مجانية — لا رسوم شهرية.
• Customer Managed Keys (CMK): رسوم شهرية لكل مفتاح نشط. المفاتيح المعطّلة (Disabled) لا تزال تُحتسب حتى يتم جدولة حذفها.
• مفاتيح المتجر الخارجي (External Key Store): رسوم مختلفة — راجع التوثيق.

رسوم عمليات API

كل استدعاء لـ KMS API يُحتسب — سواء كان GenerateDataKey أو Decrypt أو Encrypt. هذا يعني أن كل عملية قراءة أو كتابة على S3 مع تشفير SSE-KMS تولّد استدعاء KMS API.

هذه النقطة تُفاجئ كثيراً من المهندسين: حاوية S3 عالية الحركة مع SSE-KMS يمكن أن تولّد ملايين استدعاءات KMS شهرياً. الرسوم تتراكم بسرعة.

نصيحة عملية لخفض التكلفة

فعّل S3 Bucket Keys. هذه الميزة تُقلل عدد استدعاءات KMS بشكل كبير عن طريق توليد مفتاح بيانات على مستوى الحاوية يُستخدم لتشفير كائنات متعددة، بدلاً من استدعاء KMS لكل كائن على حدة. AWS توثّق أن هذا يمكن أن يُقلل استدعاءات KMS بنسبة تصل إلى 99%.

تطبيق عملي — تشفير S3 مع CMK

الخطوة 1: إنشاء Customer Managed Key

أنشئ CMK مع تفعيل التدوير التلقائي. هذا يضمن تجديد مادة المفتاح سنوياً دون تغيير معرّف المفتاح (Key ID).

aws kms create-key \
  --description "CMK for S3 bucket encryption" \
  --key-usage ENCRYPT_DECRYPT \
  --key-spec SYMMETRIC_DEFAULT \
  --region us-east-1

احفظ قيمة KeyId من الناتج — ستحتاجها في الخطوات التالية.

aws kms enable-key-rotation \
  --key-id <KeyId-from-previous-step> \
  --region us-east-1

الخطوة 2: إنشاء Alias للمفتاح

الـ Alias يجعل الإدارة أسهل ويتيح لك تغيير المفتاح الفعلي لاحقاً دون تعديل كل تكوين يشير إليه.

aws kms create-alias \
  --alias-name alias/my-s3-cmk \
  --target-key-id <KeyId-from-step-1> \
  --region us-east-1

الخطوة 3: تفعيل S3 Bucket Keys وتطبيق التشفير

طبّق SSE-KMS مع تفعيل Bucket Keys لخفض تكاليف API في نفس الوقت.

aws s3api put-bucket-encryption \
  --bucket my-production-bucket \
  --server-side-encryption-configuration '{
    "Rules": [
      {
        "ApplyServerSideEncryptionByDefault": {
          "SSEAlgorithm": "aws:kms",
          "KMSMasterKeyID": "arn:aws:kms:us-east-1:123456789012:alias/my-s3-cmk"
        },
        "BucketKeyEnabled": true
      }
    ]
  }' \
  --region us-east-1

الخطوة 4: التحقق من تطبيق التشفير

aws s3api get-bucket-encryption \
  --bucket my-production-bucket \
  --region us-east-1

الخطوة 5: سياسة IAM للوصول إلى البيانات المشفرة

أي مستخدم أو Role يحتاج قراءة أو كتابة كائنات مشفرة بـ CMK يجب أن يملك صلاحيات على المفتاح. صلاحيات S3 وحدها غير كافية — هذا خطأ شائع يظهر كـ AccessDenied مربك.

🔽 انقر لعرض سياسة IAM المطلوبة

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowKMSForS3",
      "Effect": "Allow",
      "Action": [
        "kms:GenerateDataKey",
        "kms:Decrypt"
      ],
      "Resource": "arn:aws:kms:us-east-1:123456789012:key/<your-key-id>"
    }
  ]
}

لاحظ أن kms:GenerateDataKey مطلوب للكتابة، وkms:Decrypt مطلوب للقراءة. إذا كان الـ Role يحتاج القراءة فقط، اقتصر على kms:Decrypt.

تشخيص مشكلة حقيقية — AccessDenied الخادع

الأعراض: تطبيق يملك صلاحيات S3 كاملة يفشل في قراءة كائنات من حاوية مشفرة بـ CMK. الخطأ: AccessDenied. السجل لا يشير إلى KMS.

التشخيص الأول الخاطئ: مشكلة في Bucket Policy أو صلاحيات S3. تُضاف صلاحيات إضافية لـ S3 — المشكلة تستمر.

السبب الفعلي: الـ Role يملك s3:GetObject لكن لا يملك kms:Decrypt على المفتاح. S3 تحاول فك تشفير مفتاح البيانات عبر KMS بهوية الـ Role الطالب، فيرفض KMS الطلب، وتُترجم S3 هذا الرفض إلى AccessDenied على مستوى الكائن.

الإصلاح: أضف kms:Decrypt على ARN المفتاح المحدد لسياسة الـ Role. تحقق من ذلك بـ:

aws kms get-key-policy \
  --key-id <your-key-id> \
  --policy-name default \
  --region us-east-1

تأكد أن الـ Principal الخاص بالـ Role مذكور في سياسة المفتاح أو أن سياسة IAM الخاصة به تمنحه الصلاحية. كلا المسارين صالحان — لكن يجب أن يكون أحدهما موجوداً.

رسالة AccessDenied من S3 لا تعني دائماً مشكلة في S3.

مراقبة استخدام KMS

كل استدعاء KMS يُسجَّل في AWS CloudTrail تلقائياً. يمكنك مراقبة عدد الاستدعاءات ورصد الاستخدام غير المتوقع عبر CloudWatch Metrics لـ KMS.

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventSource,AttributeValue=kms.amazonaws.com \
  --start-time 2024-01-01T00:00:00Z \
  --end-time 2024-01-02T00:00:00Z \
  --region us-east-1

إذا رأيت ارتفاعاً مفاجئاً في استدعاءات Decrypt أو GenerateDataKey، فهذا مؤشر مبكر إما على نشاط غير متوقع أو على أن Bucket Keys غير مفعّلة.

الخلاصة والخطوات التالية — فهم AWS KMS في بيئة الإنتاج

القرار بين AWS Managed Key وCMK ليس تقنياً بحتاً — بل يعكس مستوى التحكم الذي تحتاجه ومتطلبات الامتثال في بيئتك. إذا كنت تبني بيئة إنتاجية جادة، ابدأ بـ CMK من اليوم الأول. تكلفة التحويل لاحقاً أعلى بكثير من تكلفة المفتاح الشهرية.

فعّل S3 Bucket Keys دائماً عند استخدام SSE-KMS — التوفير في تكاليف API يبرر ذلك في أي بيئة ذات حجم معقول.

• راجع توثيق AWS KMS الرسمي لأحدث المعلومات حول أنواع المفاتيح والقيود.
• راجع توثيق S3 Bucket Keys لفهم آلية خفض تكاليف KMS.
• تحقق من صفحة تسعير KMS للأرقام الحالية — التسعير يتغير.

مسرد المصطلحات

المصطلح	التعريف
Envelope Encryption	أسلوب تشفير يستخدم مفتاح بيانات (Data Key) لتشفير البيانات، ثم يشفّر مفتاح البيانات نفسه بمفتاح رئيسي في KMS.
Customer Managed Key (CMK)	مفتاح KMS تُنشئه وتديره في حسابك، مع تحكم كامل في السياسة ودورة الحياة.
Key Policy	سياسة موارد مرتبطة مباشرةً بمفتاح KMS، تحدد من يملك صلاحية استخدامه وإدارته.
S3 Bucket Keys	ميزة في S3 تُقلل عدد استدعاءات KMS عن طريق توليد مفتاح بيانات على مستوى الحاوية بدلاً من كل كائن.
SSE-KMS	تشفير من جانب الخادم (Server-Side Encryption) باستخدام AWS KMS لإدارة المفاتيح.

Related Posts

• 📄 استخدام متغيرات البيئة في Lambda وتشفيرها باستخدام KMS
• 📄 رفض الوصول إلى صورة S3 العامة: لماذا يتجاوز Block Public Access إعداد ACL للكائن؟