إدارة الأسرار والبنية التحتية للمفاتيح

مخازن الأسرار السحابية الأصيلة

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

مخازن الأسرار السحابية الأصيلة

عند تشغيل الأحمال على AWS، لست بحاجة إلى مجموعة Vault مُدارة ذاتيًا لكل سر. توفر AWS خدمتين مُدارتين متخصصتين — AWS Secrets Manager وAWS Systems Manager Parameter Store (SSM) — إضافةً إلى عمود فقري لإدارة المفاتيح يُسمى KMS يدعم التشفير في كلتيهما. فهم متى تستخدم كل خدمة، وكيف يعمل تشفير الظرف (envelope encryption) في KMS تحت الغطاء، وأين تقع الفِرق الإنتاجية في الفخاخ — هو جوهر هذا الدرس.

AWS Secrets Manager مقابل SSM Parameter Store

كلتا الخدمتين تخزّنان الإعداد الحساس، لكنهما تستهدفان حالات استخدام مختلفة ولهما نماذج تكلفة وخصائص تشغيلية مختلفة بشكل ملحوظ.

AWS Secrets Manager هو الخيار الصحيح عندما تحتاج إلى:

التدوير التلقائي — يمتلك Secrets Manager تكاملًا أصيلًا مع RDS وRedshift وDocumentDB وإطار دوران قابل للتمديد يعتمد على Lambda. يعالج تبادل بيانات الاعتماد بشكل ذري: ينشئ بيانات الاعتماد الجديدة، ويُحدّث قاعدة البيانات، ويُحدّث السر، ويُهمل القديم — كل ذلك دون أي توقف للتطبيق.
مشاركة الأسرار عبر الحسابات — سياسات مستندة إلى الموارد على السر تسمح بمشاركته مع حسابات AWS أخرى في مؤسستك، وهو النمط المعياري لإدارة الأسرار المركزية في البنى متعددة الحسابات.
مسار تدقيق لكل سر — كل عملية قراءة وكتابة وتدوير هي استدعاء CloudTrail API مُعلَّم بـARN السر المحدد. هذه الدقة تلبي متطلبات تدقيق SOC 2 وPCI DSS.

SSM Parameter Store هو الخيار الصحيح عندما تحتاج إلى:

تخزين الإعداد الهرمي — تعيش المعاملات تحت مسارات مثل /prod/myapp/db/password، ويمكن لسياسات IAM منح الوصول لبادئات مسار كاملة. هذا قوي للتطبيقات التي تقرأ كل إعداداتها من SSM عند البدء.
الأحمال الحساسة للتكلفة — المعاملات القياسية مجانية. معاملات SecureString (مشفّرة بـKMS) أيضًا مجانية في الطبقة القياسية. يفرض Secrets Manager $0.40 لكل سر شهريًا. في نطاق الآلاف من الخدمات المصغّرة، الفرق في التكلفة كبير.
إعداد بسيط لا يتطلب دورانًا — أعلام الميزات وأسماء البيئات ومفاتيح API غير المتدورة والإعداد البنيوي الذي لا يحتاج دورة حياة Secrets Manager الكاملة.

القاعدة العملية في الشركات الكبرى: استخدم Secrets Manager لبيانات اعتماد قواعد البيانات ومفاتيح API وأسرار عملاء OAuth التي يجب تدويرها. استخدم SSM Parameter Store لكل إعداد تطبيق آخر، بما في ذلك القيم غير الحساسة والإعداد الذي يتدور بجدول بشري. لا تخزّن أبدًا الأسرار كمعاملات SSM Standard String عادية — استخدم دائمًا SecureString.

تشفير الظرف في KMS: كيف تُحمى بياناتك فعليًا

يستخدم كل من Secrets Manager وSSM SecureString خدمة AWS KMS لتشفير البيانات في حالة السكون. فهم نمط تشفير الظرف أمر ضروري — إنه النفس النمط الذي يستخدمه كل مزود سحابي رئيسي وهو ما يجعل مخازن الأسرار السحابية الأصيلة آمنةً وعاليةَ الأداء في نطاق واسع.

النهج الساذج للتشفير هو: إرسال سرك إلى KMS، ويُشفّره KMS بـCMK (مفتاح الماجستير)، وتخزّن النص المشفر. المشكلة: KMS له حد حمولة 4 كيلوبايت وهو استدعاء شبكي — استدعاء KMS مباشرةً لكل قراءة سيكون مُكلفًا وبطيئًا في معدلات طلب عالية.

يحل تشفير الظرف هذا بأناقة:

تُنشئ AWS مفتاح تشفير البيانات (DEK) قصير الأمد باستخدام CMK في KMS. يُعاد DEK بشكلين: نص عادي (يُستخدم فورًا للتشفير) ونص مشفر (DEK مشفّر بالـCMK، يُخزَّن مع البيانات).
تُشفَّر بياناتك (قيمة السر) محليًا باستخدام DEK العادي مع AES-256-GCM. هذا سريع وليس له حد للحمولة.
يُهمَل DEK العادي فورًا بعد الاستخدام. يُحفظ فقط DEK المشفر والبيانات المشفرة.
عند فك التشفير، يُرسَل DEK المشفر إلى KMS. يستخدم KMS الـCMK لفك تشفيره ويعيد DEK العادي. ثم تُفك شفرة بياناتك محليًا.

النتيجة: الـCMK لا يلمس أبدًا بياناتك الصريحة مباشرةً ولا يغادر أبدًا أجهزة KMS. جميع عمليات KMS مُسجَّلة في CloudTrail. إلغاء الوصول إلى الـCMK يجعل فورًا جميع البيانات المحمية غير قابلة للوصول بشكل دائم — حتى لموظفي AWS.

تشفير الظرف في KMS: تُشفَّر البيانات محليًا بـDEK؛ DEK وحده هو من يتنقل إلى KMS. كل عملية KMS مُسجَّلة في CloudTrail.

العمل مع AWS Secrets Manager

تُظهر الأمثلة التالية دورة الحياة الكاملة: إنشاء سر، واسترجاعه في الكود، وتهيئة التدوير التلقائي لبيانات اعتماد قاعدة بيانات RDS.

# Create a secret with a KMS Customer Managed Key (CMK)
aws secretsmanager create-secret \
  --name "prod/myapp/db" \
  --description "Production RDS credentials for myapp" \
  --kms-key-id "arn:aws:kms:us-east-1:123456789012:key/mrk-abc123" \
  --secret-string '{"username":"myapp","password":"s3cret-r0tates"}'

# Retrieve a secret value at runtime (returns JSON)
aws secretsmanager get-secret-value \
  --secret-id "prod/myapp/db" \
  --query SecretString --output text

# Enable automatic rotation every 30 days (RDS MySQL single-user rotation Lambda)
aws secretsmanager rotate-secret \
  --secret-id "prod/myapp/db" \
  --rotation-lambda-arn "arn:aws:lambda:us-east-1:123456789012:function:SecretsManagerRDSMySQLRotationSingleUser" \
  --rotation-rules AutomaticallyAfterDays=30

# Retrieve in a Python application (best practice: cache in memory, refresh on AWSSDK exception)
# import boto3, json
# client = boto3.client('secretsmanager', region_name='us-east-1')
# secret = json.loads(client.get_secret_value(SecretId='prod/myapp/db')['SecretString'])
# conn = psycopg2.connect(host=DB_HOST, user=secret['username'], password=secret['password'])

لا تستدعِ أبدًا GetSecretValue في كل استعلام لقاعدة البيانات. استرجع السر مرة واحدة عند بدء تشغيل التطبيق، خزّنه في الذاكرة، ونفّذ نمط إعادة المحاولة عند فشل المصادقة: إذا رفضت قاعدة البيانات بيانات الاعتماد، استدعِ GetSecretValue مجددًا (ربما حدث تدوير) وأعد الاتصال. يعمل هذا النمط بشكل صحيح مع دوران Secrets Manager دون أي توقف للتطبيق.

العمل مع SSM Parameter Store

يتميز SSM Parameter Store في الإعداد الهرمي للتطبيقات. البنية المستندة إلى المسار تتوافق جيدًا مع مبدأ الأذونات الأدنى في IAM: يمكن منح دور مهمة الخدمة المصغّرة ssm:GetParametersByPath على /prod/myapp/* فحسب.

# Store a SecureString parameter encrypted with a CMK
aws ssm put-parameter \
  --name "/prod/myapp/stripe/secret-key" \
  --type "SecureString" \
  --key-id "alias/prod-app-secrets" \
  --value "sk_live_XXXXXXXXXXXX" \
  --overwrite

# Retrieve a single parameter (--with-decryption is required for SecureString)
aws ssm get-parameter \
  --name "/prod/myapp/stripe/secret-key" \
  --with-decryption \
  --query "Parameter.Value" --output text

# Retrieve ALL parameters under a path prefix (use in container entrypoint to build env)
aws ssm get-parameters-by-path \
  --path "/prod/myapp" \
  --recursive \
  --with-decryption \
  --query "Parameters[*].{Name:Name,Value:Value}"

# Terraform: reference SSM parameter in infra code
# data "aws_ssm_parameter" "stripe_key" {
#   name = "/prod/myapp/stripe/secret-key"
# }
# Then reference: data.aws_ssm_parameter.stripe_key.value

تصميم سياسة IAM لأذونات الحد الأدنى

أهم ضابط أمني لكلتا الخدمتين هو سياسة IAM المرفقة بدور الحوسبة (دور مهمة ECS، ملف تعريف نسخة EC2، دور تنفيذ Lambda). يجب تحديد الوصول بـARN موارد محددة — لا تستخدم أبدًا Resource: "*" مع إجراءات قراءة الأسرار.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowReadSpecificSecrets",
      "Effect": "Allow",
      "Action": [
        "secretsmanager:GetSecretValue",
        "secretsmanager:DescribeSecret"
      ],
      "Resource": [
        "arn:aws:secretsmanager:us-east-1:123456789012:secret:prod/myapp/*"
      ]
    },
    {
      "Sid": "AllowKMSDecrypt",
      "Effect": "Allow",
      "Action": [
        "kms:Decrypt",
        "kms:GenerateDataKey"
      ],
      "Resource": "arn:aws:kms:us-east-1:123456789012:key/mrk-abc123",
      "Condition": {
        "StringEquals": {
          "kms:ViaService": "secretsmanager.us-east-1.amazonaws.com"
        }
      }
    }
  ]
}

شرط kms:ViaService في عبارة KMS مهم: يقيّد إذن kms:Decrypt بحيث لا يستطيع الدور استخدامه إلا عندما يأتي الطلب عبر Secrets Manager. لا يستطيع الدور استخدام مفتاح KMS نفسه لفك تشفير أي نص مشفر مباشرةً — مما يُقلّص نطاق الضرر في حالة اختراق الدور.

أكثر الأخطاء الإعدادية شيوعًا في الإنتاج هو منح secretsmanager:GetSecretValue مع Resource: "*". أي حاوية مخترقة في الحساب يمكنها حينئذٍ استخراج كل الأسرار. احدّد دائمًا بادئة ARN الدقيقة للخدمة. استخدم aws secretsmanager list-secrets مع الكشف عن شذوذات CloudTrail (نتائج GuardDuty: UnauthorizedAccess:IAMUser/AnomalousBehavior) لاكتشاف الاستعراض غير المصرح به.

Secrets Manager في Kubernetes وECS

على Amazon EKS، يقوم Secrets Store CSI Driver مع مزود AWS بتحميل قيم Secrets Manager أو SSM Parameter Store مباشرةً كملفات وحدة تخزين Kubernetes (أو مزامنتها في Kubernetes Secrets الأصيلة). يتحكم دور IRSA لحساب خدمة الـpod في الوصول. على Amazon ECS، يقوم تكامل ECS Secrets بحقن قيم Secrets Manager كمتغيرات بيئة عند بدء تشغيل الحاوية دون أي تغييرات في كود التطبيق — تشير إلى ARN السر في تعريف المهمة.

يُلغي كلا النمطين بيانات الاعتماد المُبرمجة على مستوى البنية التحتية. غير أن حقن متغيرات البيئة (الافتراضي في ECS) له دقة: يُقرأ السر مرةً واحدة عند إطلاق الحاوية ولا يُحدَّث إذا تدوّر السر. للأحمال الحساسة للتدوير على ECS، استخدم نمط CSI Driver (على EKS) أو ابنِ منطق التحديث في التطبيق.

يُخزّن AWS Secrets Manager مؤقتًا الأسرار في AWS SDK (يمتلك كل من Java SDK وPython SDK مساعد SecretCache). في معدلات الطلب العالية — خدمة تُجري عشرات الآلاف من اتصالات قاعدة البيانات في الثانية — يُلغي التخزين المؤقت تقييد API لـSecretManager (الحصة الافتراضية هي 10,000 استدعاء API في الثانية لكل منطقة، مشتركة بين جميع المبادئ في الحساب). ابنِ التخزين المؤقت في كل مستهلك عالي الإنتاجية منذ اليوم الأول.