متطلبات أمان البيانات

الاستعداد للإجابة عن الأسئلة المتعلقة بأمن البيانات

عمليات دفق البيانات

يجب إنشاء (أو تحديث، إذا اقتضت الضرورة) وصف أو مخطط دفق بيانات يوضّح كيفية معالجة التطبيق أو النظام لبيانات المنصة.

1. جهة العميل - قم بتضمين كل برامج العميل، مثل المتصفحات والأجهزة المحمولة وأي أنواع أجهزة أخرى مدعومة.
2. جهة الخادم - قم بتضمين أي بيئة (بيئات) سحابية أو متعلقة بالخادم ذات صلة وقم بتحديد:
1. المكونات حيث بيانات المنصة:
1. تدخل إلى بيئة (بيئات) الخادم أو تخرج منها (على سبيل المثال، أدوات تسجيل أحداث الويب أو واجهات REST API)
2. تمت كتابتها على وحدات تخزين دائمة أو مستدامة مثل قواعد البيانات أو الأقراص أو ملفات السجلات
2. نموذج الاستضافة، على سبيل المثال:
1. الاستضافة الذاتية - خوادم مملوكة للمؤسسة يتم تشغيلها من خلال مركز بيانات مملوك لها أو مركز بيانات مشترك.
2. البنية الأساسية كخدمة (IaaS) - مثل AWS EC2 وMicrosoft Azure IaaS وGoogle Compute Engine.
3. المنصة كخدمة (PaaS) - مثل AWS Elastic Beanstalk وGoogle App Engine وForce.com.
4. الواجهة الخلفية كخدمة (BaaS) - مثل AWS Amplify وتطبيقات Azure للهواتف المحمولة وFirebase وMongoDB Switch.
5. مختلط - بعض التوليفات التي تجمع بين النماذج السابقة.

في النهاية، يجب أن يتضمن وصف أو مخطط دفق البيانات ما يلي:

1. أماكن إنشاء ونقل/تخزين/تجديد رموز الوصول إلى واجهة Meta API، في كل من برنامج العميل والخادم (إذا كان ذلك مناسبًا لتصميم النظام)
2. كيفية قيامك باستدعاء بيانات المنصة من واجهات Meta API، مع التركيز بشكل خاص على المعلومات التي تحدد الهوية الشخصية (PII) مثل اسم الشخص وعنوان بريده الإلكتروني وجنسه وتاريخ ميلاده وبيانات المستخدم الأخرى
3. كيفية قيامك باستخدام وتخزين ونقل هذه البيانات
4. أي جهات تابعة (جهات رابعة) يتم إرسال بيانات المنصة إليها

تجهيز الإثبات

قد يُطلب منك إرسال إثبات لدعم الإجابات المتعلقة بعمليات حماية أمن البيانات التي تقوم بتنفيذها. ننصحك بقراءة دليل الإثباتات في هذا المستند للتعرف على أمثلة للإثباتات المقبولة ومن ثمّ تجهيز الإثباتات وفقًا لذلك. نقبل أنواع ملفات المستندات الشائعة إلى جانب لقطات الشاشة وتسجيلات الشاشة. يرجى التأكد من أن الملفات غير محميّة بكلمة سر. يمكنك تحميل عدة ملفات على أن يكون حجم كل ملف 2 جيجابايت بحد أقصى. نقبل الملفات بتنسيقات ‎.xls و‎.xlsx و‎.csv و‎.doc و‎.docx و‎.pdf و‎.txt و‎.jpeg و‎.jpg و‎.png و‎.ppt و‎.pptx و‎.mov و‎.mp4 و‎.zip و‎.zipx.

أنواع الإثباتات

بالنسبة إلى التطبيقات التي يُطلب منها تحميل إثبات يتعلق بعمليات حماية أمن البيانات، فإن Meta تطلب نوعين مختلفين من المستندات:

1. إثبات السياسة أو الإجراءات - مستند سياسة أو إجراءات يشرح طريقة أمن البيانات التي يتبعها [أسلوب الحماية هذا]
2. إثبات التنفيذ - إثبات من النظام أو التطبيق، على سبيل المثال تكوين أداة أو لقطة شاشة، تعرض كيفية تنفيذك لأسلوب حماية معيّن.

إثبات السياسة أو الإجراءات

إثبات السياسة أو الإجراءات، والذي يُشار إليه في بعض الأحيان باسم "عنصر تحكم إداري"، هو مستند مكتوب يصف الأسلوب المتّبع في عملية حماية أمن بيانات محددة. يمكن أن يختلف شكل هذا الإثبات - حيث يمكن أن يكون عبارة عن مقتطف من مجموعة من السياسات الداخلية أو جزء من صفحة wiki أو صفحة كاملة أو مستند تم إنشاؤه مؤخرًا تستخدمه لوصف الأسلوب إذا لم يكن لديك أي وثائق موجودة مسبقًا. في كل الحالات، يجب أن يشرح إثبات السياسة أو الإجراءات الذي تقوم بتحميله بوضوح كيفية ارتباط الأسلوب الخاص بعملية حماية محددة بمتطلبات Meta. يرجى تقديم السياسة أو النص المناسب والضروري فقط لإجراء مراجعة الأمان لدى Meta، أو يمكنك استخدام مربع النص الحر المرتبط بالسؤال لإرشاد المراجعين إلى القسم (الأقسام) ذات الصلة.

إثبات التنفيذ

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

اكتمال الإثبات

نتفهم جيدًا أنه قد يكون من الصعوبة بمكان تجهيز إثبات تنفيذيوضح بشكل شامل تنفيذ عملية حماية أمن بيانات بعينها. مع أخذ ذلك في الاعتبار، يجب عليك تقديم إثبات وفقًا للإرشادات الواردة هنا، مع الحرص على إزالة البيانات الحسّاسة من الإثبات قبل إرساله:

1. إثبات السياسة أو الإجراءات يجب أن يستوفي بكل وضوح متطلبات Meta التي نفرضها أو يتجاوزها
1. ستقوم Meta بمراجعة إثبات السياسة أو الإجراءات للبحث عن العبارات التي تتوافق مع متطلبات Meta لعملية الحماية المعنية.
2. يجب عليك إضافة تعليقات توضيحية إلى المستند لتمييز الأقسام ذات الصلة
3. على سبيل المثال، بالنسبة إلى عملية حماية تمكين تشفير TLS 1.2 أو الإصدارات الأحدث لكل اتصالات الشبكة التي يتم من خلالها نقل بيانات المنصة، ستتضمن الإثباتات المقبولة مستندًا ينصّ بوضوح تام على ما يلي:
1. يجب ألا يتم نقل بيانات المنصة من Meta مطلقًا عبر شبكات غير موثوق بها بتنسيق غير مشفّر
2. كل أدوات تسجيل أحداث الويب (مثل، أدوات موازنة الحمولة جهة الإنترنت) التي تتلقى أو تعرض بيانات المنصة سيتم تكوينها بحيث يتم تمكين TLS 1.2
3. كل أدوات تسجيل أحداث الويب التي تتلقى أو تعرض بيانات المنصة سيتم تكوينها بحيث يتم تعطيل ما يلي: SSL v2 وSSL v3 وTLS 1.0 وTLS 1.1
2. إثبات التنفيذ يجب أن يعرض مثالاً أو أكثر من تنفيذ كل سياسة أو إجراء
1. يجب عليك تحميل واحد أو أكثر من المستندات أو لقطات الشاشة أو تكوين الأدوات التي توضح كيفية تنفيذ كل واحدة من وسائل الحماية
2. ستقوم Meta بمراجعة إثبات التنفيذ للتأكد من توافقه مع إثبات السياسة أو الإجراءات
3. على سبيل المثال، بالنسبة إلى وسيلة حماية تمكين تشفير TLS 1.2 أو الإصدارات الأحدث لكل اتصالات الشبكة التي يتم من خلالها نقل بيانات المنصة، ستتضمن الإثباتات المقبولة تقرير اختبار Qualys SSL لأحد نطاقات الويب التي تم تكوينها طبقًا للسياسة أو الإجراء.

البيانات الحسّاسة التي يجب عليك إزالتها من الإثبات

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

• بيانات الصحة
• البيانات المالية
• عناوين IP
• كلمات السر وبيانات الاعتماد ورموز الوصول
• مفاتيح التشفير
• العناوين الفعلية
• المعلومات التي تحدد الهوية الشخصية لشخص طبيعي (ولا يتضمن ذلك الأنشطة التجارية أو مؤسسات الأعمال الأخرى) أو الموظفين أو الشركات التابعة التي يمكن من خلالها تحديد هوية ذلك الشخص بشكل مباشر أو غير مباشر، مثل:

  • الاسم
  • عناوين البريد الإلكتروني
  • معرفات المستخدمين
  • تواريخ الميلاد
  • بيانات الموقع
  • بيانات الصحة
  • الهوية السياسية أو الاجتماعية أو الثقافية
  • البيانات التي يمكن من خلالها بأي شكل تحديد هوية شخص ما ضمن السياق المحدد للإثبات
• خطوات إعادة الإنتاج التفصيلية للثغرات الأمنية (على سبيل المثال، في تقرير اختبار اختراق)
• البيانات التي يعرفها المطوّرون أو من المفترض أن يعرفوها بشكل معقول على أنها من أو عن أطفال تقل أعمارهم عن 13 عامًا

حماية بيانات المنصة المخزنة في الخادم بالتشفير في حالة السكون

سؤال: هل يتم فرض التشفير في حالة السكون على كل بيانات المنصة المخزنة في بيئة سحابية أو على الخادم أو في مركز بيانات؟

الغرض

التشفير في حالة السكون يحمي بيانات المنصة من خلال جعل البيانات غير قابلة لفك التشفير دون مفتاح فك تشفير منفصل. يوفر ذلك طبقة إضافية من الحماية ضد وصول القراءة غير المُصرح به.

• على الخوادم أو في بيئة سحابية - حيث تكون بيانات المنصة المرتبطة بكل مستخدمي التطبيق مركزة - يقلل التشفير في حالة السكون مخاطر اختراق البيانات
• على سبيل المثال، يحمي التشفير في حالة السكون من تهديدات مثل الوصول غير المُصرح به للنسخة الاحتياطية من قاعدة البيانات، والتي قد لا تتم حمايتها بنفس قدر حماية قاعدة البيانات الأصلية ذاتها.

ملخص المتطلبات

إذا كنت تخزِّن بيانات المنصة على الخادم:

• يجب عليك حماية هذه البيانات:

  • من خلال التشفير في حالة السكون، أو
  • بوسائل حماية بديلة مقبولة (راجع وسائل الحماية البديلة المقبولة)

• تبعًا لنوع التشفير المستخدم:

  • يعد استخدام أي من التشفير على مستوى التطبيق (على سبيل المثال، قيام البرنامج بتشفير/فك تشفير أعمدة معينة في قاعدة البيانات) أو تشفير القرص بالكامل مقبولاً
  • في حين أننا نوصي باستخدام التشفير القياسي المتبع في المجال (على سبيل المثال، AES أو BitLocker أو Blowfish أو TDES أو RSA)، فإننا لا نفرض خوارزمية معينة أو طول معين لمفتاح التشفير

إذا لم يكن المطوّر يخزن بيانات المنصة في الخادم، فلن يكون هذا المتطلب ساريًا.

حالات خاصة

التخزين على الخادم باستخدام البنية الأساسية كخدمة (IaaS) أو الاستضافة الذاتية أو الاستضافة المختلطة

إذا كنت تخزن بيانات المنصة باستخدام استضافة البنية الأساسية كخدمة (IaaS) (على سبيل المثال AWS EC2، وMicrosoft Azure IaaS وGoogle Compute Engine)، أو الاستضافة الذاتية أو الاستضافة المختلطة، فلن يسري عليك هذا السؤال.

التخزين على الخادم باستخدام منتجات البرمجيات كخدمة (SaaS) أو المنصة كخدمة (PaaS) أو الواجهة الخلفية كخدمة (BaaS)

مع هذا، هناك نماذج استضافة خلفية أخرى تمثل حالات خاصة:

إذا كنت تخزّن بيانات المنصة من خلال أي من هذه الخيارات فقط (ولم تستخدم البنية الأساسية كخدمة (IaaS) أو الاستضافة الذاتية أو الاستضافة المختلطة)، فلن يسري عليك هذا السؤال. وينبغي عليك بدلاً من ذلك وصف هذه العلاقة في قسم موفر الخدمة في تقييم حماية البيانات (DPA).

• الواجهة الخلفية كخدمة (BaaS) - على سبيل المثال AWS Amplify وتطبيقات Azure للهواتف المحمولة وAzure Playfab وGoogle Firebase وMongoDB Switch
• المنصة كخدمة (PaaS) - على سبيل المثال AWS Elastic Beanstalk وGoogle App Engine وForce.com
• البنية الأساسية كخدمة (IaaS) - على سبيل المثال MailChimp أو Salesforce

التخزين على الخادم باستخدام واجهات Meta API

إذا كنت تخزّن بيانات المنصة من خلال واجهات Meta API فقط، على سبيل المثال باستخدام player.setDataAsync()، في مجموعة SDK الألعاب الفورية، فلن يسري عليك هذا السؤال.

دليل الإثباتات

إذا طُلب منك تقديم إثبات لهذه الحماية، فاتبع الإرشادات الواردة في تجهيز الإثبات لتجهيز كل من السياسة/الإجراء وإثبات التنفيذ.

نموذج لإثبات التنفيذ

AWS RDS

AWS RDS - يمكن تكوين التشفير في حالة السكون في AWS RDS، وبالتالي يجب على المطوِّرين التأكد من تعيين خيار التكوين بحيث يطبق هذه الحماية.

بالنسبة إلى مثيل RDS تمثيلي يحتوي على بيانات المنصة، يمكنك استخدام أداة AWS CLI لجلب تكوين StorageEncrypted الخاص به.

# List RDS instances in default region
$ aws rds describe-db-instances \
  --query 'DBInstances[*].DBInstanceIdentifier'

[
    "database-1",
    "database-2"
]

# For each instance returned, retrieve the storage encrypted config
$ aws rds describe-db-instances \
  --db-instance-identifier database-1 \
  --query 'DBInstances[*].StorageEncrypted'
[
    true
]

$ aws rds describe-db-instances \
  --db-instance-identifier database-2 \
  --query 'DBInstances[*].StorageEncrypted'
[
    true
]

AWS DynamoDB

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

$ aws dynamodb list-tables --output table

--------------
| ListTables |
+------------+
||TableNames||
|+----------+|
||  Users   ||
|+----------+|


$ aws dynamodb describe-table \
 --table-name Users \
 --query "Table.SSEDescription.Status"

"ENABLED"

AWS DocumentDB

يجب تكوين AWS DocumentDB لتطبيق التشفير في حالة السكون. بالنسبة إلى مجموعة تمثيلية تحتوي على بيانات المنصة، يمكنك استخدام هذه الأوامر لجلب تكوين StorageEncrypted.

$ aws docdb describe-db-clusters --query 'DBClusters[*].DBClusterIdentifier'

[
    "docdb-users"
]

$ aws docdb describe-db-clusters \
  --db-cluster-identifier 'docdb-users' \
  --query 'DBClusters[*].StorageEncrypted'
[
    true
]

AWS S3

يمكن تكوين وسائط تخزين AWS S3 بحيث يتم تطبيق التشفير في حالة السكون على كل الكائنات الموجودة داخل وسيط التخزين. ويمكنك استخدام هذه الأوامر لإدراج وسائط التخزين وجلب التكوين لتشفير وسيط التخزين الافتراضي.

$ aws s3api list-buckets --output table --query "Buckets[*].Name"

---------------------------------------------
|                ListBuckets                |
+-------------------------------------------+
|  platform.storage                         |
+-------------------------------------------+

$ aws s3api get-bucket-encryption \
  --bucket  platform.storage \
  --query "ServerSideEncryptionConfiguration.Rules[*].ApplyServerSideEncryptionByDefault" \
  --output table
---------------------
|GetBucketEncryption|
+-------------------+
|   SSEAlgorithm    |
+-------------------+
|  AES256           |
+-------------------+

Microsoft Azure

يمكنك الرجوع إلى وثائق Microsoft بشأن التشفير في حالة السكون في Azure ذات الصلة باستخدام المؤسسة لخدماتها.

منصة Google Cloud

يمكنك الرجوع إلى وثائق Google بشأن التشفير في حالة السكون على منصة Google Cloud.

وسائل الحماية البديلة المقبولة

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

1. حساسية بيانات المنصة - يمثل تخزين بيانات معينة من بيانات المنصة خطورة منخفضة أو عالية. وسيلزمك إجراء بحث لتحديد أي من سمات مستخدم بيانات المنصة يتم تخزينها في الخادم.
2. عناصر التحكم المستخدمة لتقليل احتمالية حدوث أضرار معينة
1. عناصر التحكم المستخدمة لمنع اختراق الشبكات التي تحتوي عل بيانات المنصة
2. عناصر التحكم المستخدمة لمنع اختراق التطبيقات/الأنظمة التي تتمتع بصلاحية الوصول إلى بيانات المنصة
3. عناصر التحكم المستخدمة لمنع فقدان وسائط التخزين المادية (على سبيل المثال، أجهزة تخزين الشبكة التي تم إيقاف استخدامها) والتي تحتوي على بيانات المنصة
4. عناصر التحكم المستخدمة لمنع فقدان وسائط التخزين المادية (على سبيل المثال، أجهزة تخزين الشبكة التي تم إيقاف استخدامها) والتي تحتوي على بيانات المنصة
5. عناصر التحكم المستخدمة لمنع الوصول غير المُصرح به للنسخ الاحتياطية من وسائط التخزين التي تحتوي على نسح احتياطية من بيانات المنصة
3. قوة الإثبات - احرص على الإشارة إلى ما إذا كانت وسائل الحماية هذه قد تم تقييمها بواسطة جهة تدقيق مستقلة، على سبيل المثال كجزء من تدقيق SOC2.

حماية بيانات المنصة المخزنة على أجهزة المؤسسة والوسائط القابلة للإزالة من الضياع

سؤال: فيما يتعلق بالبيانات المخزنة على أجهزة المؤسسة والأجهزة الشخصية تحديدًا: هل تفرض التشفير في حالة السكون، أم أن لديك سياسات وقواعد لتقليل مخاطر ضياع البيانات، لكل بيانات المنصة المخزنة على هذه الأجهزة؟

الغرض

إذا كان المطوّر يسمح بوجود بيانات المنصة على أجهزة مثل الكمبيوتر المحمول أو وسائط التخزين القابلة للإزالة (على سبيل المثال، محركات أقراص USB)، فستكون هذه البيانات معرضة بشكل كبير لمخاطر الوصول غير المُصرح به في حالة ضياع الجهاز أو سرقته. ينبغي على المطوّرين اتخاذ خطوات للحد من هذا الخطر.

ملخص المتطلبات

• للحد من مخاطر الوصول غير المُصرح به لبيانات المنصة، على المطوّرين استخدام إما عناصر تحكم تقنية (الخيار المفضل) أو عناصر تحكم إدارية (خيار غير مفضل لكنه مقبول) فيما يتعلق ببيانات المنصة المخزنة على أجهزة المؤسسة (على سبيل المثال، أجهزة الكمبيوتر المحمول) والوسائط القابلة للإزالة.

  • عناصر التحكم التقنية - تتضمن أمثلة عناصر التحكم التقنية: 1) السماح فقط للأجهزة المُدارة بالاتصال بشبكة الشركة، 2) تطبيق تشفير القرص بالكامل على الأجهزة المُدارة (على سبيل المثال، BitLocker) 3) حظر اتصال الوسائط القابلة للإزالة (على سبيل المثال، محركات أقراص USB) بالأجهزة المُدارة، 4) استخدام تكنولوجيا منع فقدان البيانات (DLP) على الأجهزة المُدارة.
  • عناصر التحكم الإدارية - تتضمن أمثلة عناصر التحكم الإدارية وثائق السياسة المكتوبة والتدريبات السنوية التي تتناول الطرق المقبولة للتعامل مع بيانات المنصة على أجهزة المؤسسة والأجهزة الشخصية.

دليل الإثباتات

إذا طُلب منك تقديم إثبات لهذه الحماية، فاتبع الإرشادات الواردة في تجهيز الإثبات لتجهيز كل من السياسة/الإجراء وإثبات التنفيذ.

ربما تستخدم أحد هذين الخيارين أو كليهما: أ) عناصر التحكم التقنية (على سبيل المثال، تشفير القرص)، أو ب) قواعد/سياسات للحد من مخاطر فقدان البيانات فيما يتعلق ببيانات المنصة التي يتم تخزينها على أجهزة المؤسسة مثل أجهزة الكمبيوتر المحمول والهواتف المحمولة.

قد تتضمن عناصر التحكم التقنية:

• منع اتصال الأجهزة غير المُدارة بالخدمات الحساسة، مثل شبكة الإنتاج
• تطبيق تشفير القرص على الأجهزة المُدارة (على سبيل المثال، من خلال BitLocker على Windows أو FileVault على Mac)
• منع استخدام الوسائط القابلة للإزالة (على سبيل المثال، محركات أقراص USB) على الأجهزة المُدارة
• استخدام برامج منع فقدان البيانات على الأجهزة المُدارة لمنع التعامل بشكل غير صحيح مع بيانات المنصة (على سبيل المثال، إرسال مرفق في رسالة بريد إلكتروني)

قد تتضمن القواعد/السياسات:

• الوثائق التي تصف الطرق المقبولة وغير المقبولة للتعامل مع البيانات، بوجه عام، وبيانات المنصة بوجه خاص
• آلية لتوعية أعضاء المؤسسة بالإرشادات (على سبيل المثال، اتفاقية تعاقدية كشرط للتوظيف، والتدريب، والتذكيرات الدورية عبر البريد الإلكتروني)

نموذج الإثبات

تصنّف المؤسسة بيانات المنصة المستمدة من Meta باعتبار أنها "بيانات خاصة" وفقًا لمعيار تصنيف البيانات الخاص بها. قامت المؤسسة بإنشاء إرشادات للتعامل مع البيانات وتُلزم جميع العاملين بفهم هذه السياسات والالتزام بها.

حماية بيانات المنصة التي يتم إرسالها عبر الشبكات باستخدام التشفير أثناء الإرسال

سؤال: هل تقوم بتمكين بروتوكول الأمان TLS 1.2 أو أعلى لكل اتصالات الشبكة التي تمر عبر الشبكات العامة التي يتم نقل بيانات المنصة إليها أو تتصل بها أو تعبر خلالها؟ بالإضافة إلى ذلك، هل تضمن عدم نقل بيانات المنصة مطلقًا عبر الشبكات العامة في شكل غير مشفر (على سبيل المثال، عبر HTTP أو FTP) وعدم استخدام بروتوكولات الأمان SSL بالإصدار 2 وSSL بالإصدار 3 مطلقًا؟

الغرض

تكون كل بيانات المنصة المنقولة عبر الإنترنت عرضة للوصول إليها بواسطة أي شخص يمكنه مراقبة حركة البيانات على الشبكة. بالتالي يجب حمايتها من خلال التشفير لمنع الجهات غير المُصرح لها من قراءة هذه البيانات.

• التشفير أثناء النقل يحمي بيانات المنصة عند نقلها عبر شبكات غير موثوق بها (على سبيل المثال، الإنترنت) من خلال جعلها غير قابلة لفك الشفرة باستثناء الأجهزة الأصلية وأجهزة الوجهة
• بعبارة أخرى، لن تتمكن الأطراف في منتصف عملية النقل من قراءة بيانات المنصة حتى إذا تمكنت من الاطلاع على حركة بيانات الشبكة (يعرف ذلك أيضًا باسم هجوم رجل في الوسط)
• TLS هي الشكل الأكثر شيوعًا للتشفير أثناء النقل لأنه يمثل تقنية تستخدمها المتصفحات لتأمين عمليات التواصل مع مواقع الويب مثل البنوك

ملخص المتطلبات

إذا كنت تعالج بيانات المنصة على الخادم أم لا:

• يجب ألا يتم نقل بيانات المنصة مطلقًا عبر شبكات غير موثوق بها بتنسيق غير مشفّر
• بالنسبة إلى كل أدوات تسجيل أحداث الويب (مثل، أدوات موازنة الحمولة جهة الإنترنت) التي تتلقى أو تعرض بيانات المنصة، يجب عليك:

  • تمكين TLS 1.2 أو أعلى
  • تعطيل SSL v2 وSSL v3
• يمكن استخدام 1.0 وTLS 1.1 فقط من أجل التوافق مع أجهزة العميل غير القادرة على استخدام TLS 1.2+
• توصي Meta، ولكن لا تشترط، تطبيق التشفير أثناء الإرسال على عمليات إرسال بيانات المنصة التي تتم بالكامل داخل الشبكات الخاصة، مثل خدمة سحابية خاصة افتراضية (VPC).

يلخص الجدول التالي سياسة التشفير أثناء الإرسال لأنواع الإرسال المختلفة.

دليل الإثباتات

إذا طُلب منك تقديم إثبات لهذه الحماية، فاتبع الإرشادات الواردة في تجهيز الإثبات لتجهيز كل من السياسة/الإجراء وإثبات التنفيذ. تُعد من الطرق المباشرة لإنتاج إثبات تنفيذ يوضح تكوين أحد أدوات تسجيل أحداث الويب استخدام أداة Qualys SSL Server Test.

• قم بتشغيل أداة Qualys SSL Server Test في مقابل واحدة أو أكثر من أدوات تسجيل أحداث الويب التي تم تكوينها بشكل مماثل (بما في ذلك أي أدوات يتم تشغيلها على منافذ غير قياسية).
• قم بتحديد خيار "عدم إظهار النتائج على اللوحات" لمنع إضافة النتائج إلى موقع ويب Qualys. قم بطبع صفحة نتيجة (نتائج) الاختبار بالكامل إلى تنسيق PDF. وقم بتكرار الخطوات السابقة لأي أداة تسجيل أحداث الويب تقوم بإرسال بيانات المنصة إليها أو تلقيها منها يكون لديها تكوين TLS مختلف

نموذج لإثبات التنفيذ

هذا مثال مخرجات من أداة Qualys SSL Server Test. لاحظ التعليقات التوضيحية باللون الأحمر الموجودة في قسم التكوين، والتي تلخّص إصدارات SSL/TLS المدعومة. ملاحظة: يتضمن هذا المثال أول صفحتين فقط ولكن يجب عليك تضمين مخرجات الاختبار بالكامل.

وسائل الحماية البديلة المقبولة

ربما تقوم بحماية بيانات المنصة أثناء الإرسال باستخدام نوع تشفير مختلف عن TLS؛ قد يكون ذلك مقبولاً إذا كانت الطريقة المستخدمة توفر حماية مماثلة. في هذه الحالة، يجب عليك إرسال التفاصيل بشأن التشفير المستخدم إلى Meta لمراجعته:

• تشفير متزامن أم غير متزامن؟
• خوارزمية التشفير (على سبيل المثال، AES، BitLocker، TDES، RSA)؟
• ما الحد الأدنى لطول المفتاح؟

اختبار التطبيق والأنظمة لاكتشاف الثغرات الأمنية ومشكلات الأمان

سؤال: هل تختبر التطبيق والأنظمة لاكتشاف الثغرات الأمنية ومشكلات الأمان مرة على الأقل كل 12 شهرًا؟ (على سبيل المثال، هل تجري اختبار اختراق يدوي؟)

الغرض

يجب على المطوِّرين إجراء اختبار لاكتشاف الثغرات الأمنية ومشكلات الأمان بشكل استباقي، ومنع حوادث الأمان قبل حدوثها في الوضع المثالي

• مطوّرو التطبيقات الذين يستخدمون منصة Meta لمعالجة بيانات المنصة باستخدام برامج يطورونها من خلال تطبيقات/أنظمة يقومون بتكوينها وتشغيلها
• قد تنطوي البرامج وتكوينات الأنظمة على ثغرات أمنية يمكن للمحتالين استغلالها، مما يؤدي إلى وصول غير مُصرح به إلى بيانات المنصة

ملخص المتطلبات

تسري على كل المطوّرين:

• يجب أن تكون قد اختبرت البرنامج المستخدم لمعالجة بيانات المنصة لاكتشاف الثغرات الأمنية من خلال إجراء أي مما يلي:

  • اختبار اختراق للتطبيق/النظام، أو
  • فحص لاكتشاف الثغرات الأمنية/تحليل ثابت للبرنامج
• يجب أن تُظهر نتائج الاختبار عدم وجود ثغرات أمنية خطيرة أو شديدة الحساسية لم يتم حلها
• يجب أن يكون الاختبار مكتملاً خلال آخر 12 شهرًا

متطلبات إضافية للمطوّرين الذين يعالجون بيانات المنصة على الخادم:

• يجب أن تكون قد اختبرت التطبيق الموجود على الخادم تحديدًا لاكتشاف الثغرات الأمنية من خلال إجراء أي مما يلي:

  • اختبار اختراق للتطبيق/النظام، أو
  • فحص لاكتشاف الثغرات الأمنية/تحليل ثابت يجب أن تكون قد اختبرت أيضًا تكوين السحابة لاكتشاف مشكلات الأمان إذا كنت تستخدم موفر خدمة استضافة سحابية ينطبق هذا المتطلب بغض النظر عن أسلوب الاستضافة (على سبيل المثال، BaaS أو PaaS أو IaaS أو استضافة ذاتية أو هجينة)

دليل الإثباتات

إذا طُلب منك تقديم إثبات لهذه الحماية، فاتبع الإرشادات الواردة في تجهيز الإثبات لتجهيز كل من السياسة/الإجراء وإثبات التنفيذ.

إذا كانت المؤسسة تعالج بيانات المنصة في بيئة سحابية أو على الخادم:

• أرسل ما يثبت اكتمال تنفيذ اختبار الاختراق أو أداة اختبار أمان التطبيق الثابت. يجب أن يتضمن الإثبات:

  • بيان يوضح نطاق الاختبار
  • تاريخ اكتمال الاختبار - يجب أن يكون التاريخ خلال آخر 12 شهرًا
  • إما ملخص أو قائمة بالثغرات الأمنية المكتشفة خلال الاختبار. يجب أن يتضمن الملخص أو قائمة الثغرات الأمنية تصنيف الخطورة (على سبيل المثال، حرجة، مرتفعة، متوسطة، منخفضة، لأغراض المعلومات). نتوقع في العادة عدم وجود ثغرات أمنية خطيرة أو شديدة الحساسية لم يتم حلها

• إن كان ذلك ينطبق على حالتك (أي إذا كنت تستخدم استضافة سحابية مثل AWS أو GCP أو Azure أو استضافة مشابهة) فأرسل ما يثبت إجراء مراجعة لتكوين السحابة، على سبيل المثال ناتج تشغيل NCC Scout Suite أو AWS Config أو مراجعة مشابهة. إذا لم يكن ذلك ينطبق على المؤسسة، فاحرص على تضمين مستند عند إرسال الإثبات يوضح سبب عدم انطباق مراجعة التكوين على مؤسستك.
• احرص على إزالة أو تنقيح المعلومات الحساسة مثل الخطوات التفصيلية لإعادة إنتاج الثغرة من الإثبات قبل إرساله

إذا لم تكن المؤسسة تعالج بيانات المنصة في بيئة سحابية أو على الخادم:

• أرسل ما يثبت اكتمال تنفيذ اختبار الاختراق أو أداة اختبار أمان التطبيق الثابت. يجب أن يتضمن الإثبات:

  • بيان يوضح نطاق الاختبار
  • تاريخ اكتمال الاختبار - يجب أن يكون التاريخ خلال آخر 12 شهرًا
  • إما ملخص أو قائمة بالثغرات الأمنية المكتشفة خلال الاختبار. يجب أن يتضمن الملخص أو قائمة الثغرات الأمنية تصنيف الخطورة (على سبيل المثال، حرجة، مرتفعة، متوسطة، منخفضة، لأغراض المعلومات). نتوقع في العادة عدم وجود ثغرات أمنية خطيرة أو شديدة الحساسية لم يتم حلها.
• احرص على إزالة أو تنقيح المعلومات الحساسة مثل الخطوات التفصيلية لإعادة إنتاج الثغرة من الإثبات قبل إرساله

نموذج الإثبات

اختبار الاختراق - تقوم مؤسسة ما بالتكليف بإجراء اختبار اختراق لبرنامجها الذي يعمل على الخادم والذي يدمج واجهات Meta API ويعالج بيانات المنصة. تكمل الشركة المكلفة بالاختبار إجراء الاختبار وتُصدر خطابًا مختصرًا يشبه الخطاب أدناه. لاحظ التعليقات التوضيحية باللون الأحمر، والتي تشير إلى تاريخ إجراء الاختبار (يجب أن يكون التاريخ خلال آخر 12 شهرًا) وهناك تلخيص لنتائج الثغرات الأمنية الحرجة/عالية الخطورة التي لم يتم حلها عند نهاية الاختبار (أو إعادة الاختبار، إن وجدت). يرجى تنقيح المعلومات الحساسة من التقرير (وتحديدًا، أي خطوات تفصيلية لإعادة إنتاج الثغرة) قبل إرساله.

التحليل الثابت - إذا كنت تستخدم نهج مختلف، على سبيل المثال، أداة اختبار أمان التطبيق الثابت (SAST)، فقم بتصدير النتائج إلى مستند يتضمن تاريخ إجراء هذا الاختبار وقائمة بالنتائج التي تتضمن نوع كل نتيجة وتصنيفها من حيث الخطورة/الأهمية.

مراجعة تكوين السحابة

يستخدم المطوّر NCC Scout Suite باستخدام مجموعة القواعد الافتراضية لموفر خدمة السحابة (في هذه الحالة، AWS) لمراجعة تكوين السحابة لاكتشاف الثغرات الأمنية ومشكلات الأمان. تقوم الأداة بإخراج ملف JSON يحتوي على نتائج التشغيل التفصيلية. في هذا المثال، هناك عدد من المشكلات التي تم تمييز مستوى خطورتها باعتبار أنها "خطرة" وأن على المطوّر مراجعتها وحلها.

$ python3 scout.py aws –-no-browser
2022-08-22 11:39:38 localhost scout[76981] INFO Saving data to scoutsuite-report/scoutsuite-results/scoutsuite_results_aws-043954759379.js

$ cd scoutsuite-report/scoutsuite-results
$ tail -n +2 scoutsuite_results_aws-043954750000.js| jq '. | {last_run}' | pbcopy

{
  "last_run": {
    "ruleset_about": "This ruleset consists of numerous rules that are considered standard by NCC Group. The rules enabled range from violations of well-known security best practices to gaps resulting from less-known security implications of provider-specific mechanisms. Additional rules exist, some of them requiring extra-parameters to be configured, and some of them being applicable to a limited number of users.",
    "ruleset_name": "default",
    "run_parameters": {
      "excluded_regions": [],
      "regions": [],
      "services": [],
      "skipped_services": []
    },
    "summary": {
      "acm": {
        "checked_items": 4,
        "flagged_items": 2,
        "max_level": "warning",
        "resources_count": 2,
        "rules_count": 2
      },
      "awslambda": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "cloudformation": {
        "checked_items": 11,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 11,
        "rules_count": 1
      },
      "cloudfront": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 3
      },
      "cloudtrail": {
        "checked_items": 153,
        "flagged_items": 4,
        "max_level": "danger",
        "resources_count": 17,
        "rules_count": 9
      },
      "cloudwatch": {
        "checked_items": 2,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 2,
        "rules_count": 1
      },
      "codebuild": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "config": {
        "checked_items": 17,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 1227,
        "rules_count": 1
      },
      "directconnect": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "dynamodb": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 1,
        "rules_count": 0
      },
      "ec2": {
        "checked_items": 760,
        "flagged_items": 108,
        "max_level": "danger",
        "resources_count": 44,
        "rules_count": 28
      },
      "efs": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "elasticache": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "elb": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 3
      },
      "elbv2": {
        "checked_items": 42,
        "flagged_items": 4,
        "max_level": "danger",
        "resources_count": 0,
        "rules_count": 5
      },
      "emr": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "iam": {
        "checked_items": 801,
        "flagged_items": 27,
        "max_level": "danger",
        "resources_count": 87,
        "rules_count": 37
      },
      "kms": {
        "checked_items": 15,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 15,
        "rules_count": 1
      },
      "rds": {
        "checked_items": 1,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 27,
        "rules_count": 9
      },
      "redshift": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 6
      },
      "route53": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 1,
        "rules_count": 3
      },
      "s3": {
        "checked_items": 121,
        "flagged_items": 34,
        "max_level": "warning",
        "resources_count": 7,
        "rules_count": 18
      },
      "secretsmanager": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 1,
        "rules_count": 0
      },
      "ses": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 4
      },
      "sns": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 7
      },
      "sqs": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 8
      },
      "vpc": {
        "checked_items": 271,
        "flagged_items": 211,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 9
      }
    },
    "time": "2022-08-22 11:42:25-0400",
    "version": "5.11.0"
  }
}

يتمثل نهج آخر يمكن للمطوّرين اتباعه لإجراء مراجعة تكوين السحابة في استخدام مجموعة قواعد Amazon Web Services.

# Show that AWS Foundational Security Best Practices are enabled
$ aws securityhub get-enabled-standards                                                                                                            
{
    "StandardsSubscriptions": [
        {
            "StandardsSubscriptionArn": "arn:aws:securityhub:us-west-1:043954759379:subscription/aws-foundational-security-best-practices/v/1.0.0",
            "StandardsArn": "arn:aws:securityhub:us-west-1::standards/aws-foundational-security-best-practices/v/1.0.0",
            "StandardsStatus": "READY"
        }
    ]
}

# Show that aggregator is configured for a representative region used to process Platform Data
$ aws securityhub list-finding-aggregators

$ aws securityhub get-finding-aggregator --finding-aggregator-arn '{REPLACE-WITH-FINDING-AGGREGATOR-ARN}'


# Demonstrate that the ruleset is running by fetching active findings and counting the number of lines of output
$ aws securityhub get-findings --query 'Findings[?RecordState==`ACTIVE`]' --filters '{"GeneratorId":[{"Value": "aws-foundational-security","Comparison":"PREFIX"}]}' --output text | wc -l                                     

4876
# Demonstrate that there are no active critical severity findings
$ aws securityhub get-findings --query 'Findings[?Severity.Label==`CRITICAL`] | [?RecordState==`ACTIVE`] | [*][Title, GeneratorId]' --filters '{"GeneratorId":[{"Value": "aws-foundational-security","Comparison":"PREFIX"}]}'

[]

وسائل الحماية البديلة المقبولة

إذا كنت تقوم بتشغيل برنامج عامل للكشف عن الثغرات الأمنية (VDP)، على سبيل المثال باستخدام منصات BugCrowd أو HackerOne، يمكنك تقديم ذلك كوسيلة حماية بديلة عن اختبار الاختراق أو فحص اكتشاف الثغرات الأمنية. لتبرهن على ذلك، يجب عليك إرسال ما يثبت:

• عدم وجود استثناءات لنطاق برنامج الكشف عن الثغرات الأمنية المرتبط بطريقة معالجتك لبيانات المنصة.
• وجود أبحاث فعلية مستمرة للكشف عن الثغرات وتقارير خلال آخر 12 شهرًا، والتي تتأكد عادة من خلال ما لا يقل عن تقرير اختبار كشف ثغرات واحد صالح كل شهر.
• تعيين درجة خطورة للثغرات (الصالحة) المرسلة، على سبيل المثال باستخدام CVSS 3.1
• حل الثغرات في وقت معقول، أقل من 90 يومًا في العادة من تاريخ الإرسال

في هذه الحالة، يجب أن يتضمن الإثبات:

• بيان يوضح النطاق وكيفية ارتباط ذلك بالبرنامج المستخدم لمعالجة بيانات المنصة
• وتقرير للثغرات الفعلية المرسلة في البرنامج على مدار آخر 12 شهرًا. ينبغي أن يتضمن التقرير عنوان الثغرة، وتاريخ الإرسال، وتاريخ الحل (إذا تم حلها) وفئة/درجة الخطورة.

حماية المفتاح السري للتطبيق ورموز الوصول لواجهة Meta API

سؤال: هل تتم حماية رموز وصول واجهة Meta API والمفاتيح السرية للتطبيقات بكلا الطريقتين التاليتين؟

1. من خلال عدم تخزين رموز وصول واجهة Meta API على أجهزة العميل عند إمكانية الوصول إليها بعيدًا عن التطبيق والمستخدم الحالي.
2. باستخدام مخزن بيانات (على سبيل المثال Vault بواسطة Hashicorp) مع خدمة إدارة مفاتيح منفصلة (KMS) في حالة تخزينها في بيئة سحابية أو خادم أو مركز بيانات.

الغرض

تحظى المفاتيح السرية للتطبيقات والرموز السرية بأهمية كبيرة لأمان كيفية اتخاذ واجهات Meta API للقرارات بشأن الإجراءات التي يتم السماح بها. إذا تمكنت جهة غير مُصرح لها بالوصول إلى بيانات الاعتماد تلك، فقد تتمكن من استدعاء واجهات Meta API - وانتحال شخصية المطوّر الحقيقي - واتخاذ أي إجراءات منحناها للتطبيق (على سبيل المثال، قراءة بيانات من واجهات Meta API عن مستخدمي التطبيق).

• أنت تتمتع بصلاحية الوصول إلى بيانات اعتماد حساسة كجزء من استخدام منصة Meta. وبشكل خاص:

  • رمز الوصول - عندما يصرح الأشخاص للتطبيق، يحصل التطبيق على بيانات اعتماد تعرف باسم رمز الوصول والذي يمكن استخدامه في عمليات الاستدعاء اللاحقة لواجهة API.
  • المفتاح السري للتطبيق - تشارك Meta المفتاح السري للتطبيق مع المطوِّرين وتتوقع ألا يصل إليه إلا الأطراف الموثوق بها (على سبيل المثال، مسؤول التطبيق) داخل المؤسسة
• يمكن لطرف غير مُصرح به يستطيع قراءة بيانات الاعتماد الحساسة تلك استخدامها لاستدعاء واجهات Meta API كأنه أنت (يعرف ذلك أحيانًا باسم انتحال الرمز) مما يؤدي إلى وصول غير مُصرح به لبيانات المنصة
• من هذا المنطلق، يجب حماية بيانات الاعتماد تلك من الوصول غير المُصرح به لمنع الانتحال

ملخص المتطلبات

رموز الوصول

1. في أجهزة العملاء - يجب ألا تتم كتابة رموز وصول Meta على نحو يسمح لمستخدم آخر أو عملية أخرى بقراءتها.
2. جهة الخادم - إذا كنت تعالج رموز وصول Meta أو تخزنها في الخادم، فإن رموز الوصول تلك:
1. يجب أن تتم حمايتها باستخدام مخزن بيانات (مثل، Vault بواسطة Hashicorp) مع خدمة إدارة مفاتيح منفصلة (KMS) وعندما يكون الوصول إلى مفتاح فك التشفير مقتصرًا على التطبيق
2. يجب ألا يتم كتابتها في ملفات السجلات

المفتاح السري للتطبيق - يجب أن يتحقق أي مما يلي:

1. يجب عليك ألا تكشف عن المفتاح السري خارج بيئة الخادم الآمنة (على سبيل المثال، عدم إعادته من خلال استدعاء شبكة إلى متصفح أو تطبيق هواتف محمولة وألا يتم تضمين المفتاح السري للتطبيق في رمز يتم توزيعه إلى عملاء الهواتف المحمولة أو الأصلية/أجهزة الكمبيوتر)
2. أو يجب أنت تكون قد قمت بتكوين التطبيق باستخدام النوع الأصلي/أجهزة الكمبيوتر حتى لا تثق واجهات Meta API الخاصة بنا بعد ذلك في استدعاءات واجهة API التي تتضمن المفتاح السري للتطبيق

دليل الإثباتات

إذا طُلب منك تقديم إثبات لهذه الحماية، فاتبع الإرشادات الواردة في تجهيز الإثبات لتجهيز كل من السياسة/الإجراء وإثبات التنفيذ.

قم بتضمين وثائق عن سياسة حماية رموز الوصول لواجهة Meta API والمفتاح السري للتطبيق إذا كان التطبيق يعالج رموز وصول Meta على الخادم، وقم بتضمين إثبات يبرهن على أن وسائل الحماية التي تتبعها (على سبيل المثال، استخدام مخزن، وإثبات أن القيم مخزنة بتنسيق مشفر، وأن التطبيق قد تم تكوينه بحيث يطلب إثباتات المفاتيح السرية للتطبيقات).

نموذج الإثبات

تستخدم مؤسسة ما AWS Secrets Manager لتخزين البيانات الحساسة بأمان، بما في ذلك المفتاح السري للتطبيق من Meta.

قامت مؤسسة ما بتكوين تطبيق Meta الخاص بها بحيث يطلب إثبات المفتاح السري للتطبيق لاستدعاءات API.

وسائل الحماية البديلة المقبولة

1. إذا لم تكن تحمي رموز الوصول المخزنة على الخادم من خلال مخزن بيانات أو من خلال التشفير على مستوى التطبيق، فإنه:
1. حماية المفتاح السري للتطبيق باستخدام مخزن بيانات أو تشفير التطبيق حيث لا يمكن الوصول إلى المفتاح إلا من التطبيق
2. وتكوين التطبيق من أجل طلب إثبات المفتاح السري للتطبيق لكل استدعاءات واجهة API إلى Meta
2. إذا لم يكن النهج الأول أعلاه قابلاً للتطبيق (أي لا يمكن أن يطلب إثبات المفتاح السري للتطبيق لأنه سيحظر استدعاءات معينة ضرورية لواجهة API)، فستنظر Meta في أي عناصر تحكم أخرى تستخدمها للحد من خطر الاستخدام غير المُصرح به لرموز الوصول مقارنة بمخاطر إساءة استخدام رموز الوصول المخزنة

وضع خطة استجابة لحوادث الأمان واختبار أنظمة وعمليات الاستجابة للحوادث

سؤال: هل تختبر الأنظمة والعمليات التي يتم استخدامها للتعامل مع حوادث الأمان (على سبيل المثال، خرق البيانات والهجمات الإلكترونية) مرة واحدة على الأقل كل 12 شهرًا؟

الغرض

تتعرض كل الشركات لحوادث الأمان عاجلاً أو آجلاً، ولذلك من الضروري أن تخطط المؤسسات مسبقًا وتحدد من يجب عليه القيام بالمهام المختلفة لاحتواء الحادث، والتواصل مع أصحاب المصالح، والتعافي والتعلم مما حدث.

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

ملخص المتطلبات

يجب أن تكون لدى المطوّر:

• خطة استجابة للحوادث تستوفي الحد الأدنى من معايير Meta.
• يجب أن يتضمن هذا المستند (على الأقل): (1) الأدوار والمسؤوليات، (2) الاكتشاف، (3) خطوات التفاعل امتثالاً للالتزامات القانونية المعمول بها (على سبيل المثال، إشعار اختراق البيانات للهيئة الإشرافية ذات الصلة وأصحاب البيانات) والتعافي، و(4) عملية ما بعد مراجعة الحادث
• إثبات موثّق لإخضاع الخطة للاختبار مؤخرًا (خلال آخر 12 شهرًا) وأن جميع الموظفين المعينين في الخطة قد شاركوا في الاختبار.

دليل الإثباتات

اتبع الإرشادات الواردة في تجهيز الإثبات لتجهيز كل من السياسة/الإجراء وإثبات التنفيذ.

• أرسل خطة الاستجابة للحوادث (مستند أو أكثر). ويجب أن تحتوي على الموضوعات التالية: الأدوار والمسؤوليات والاكتشاف والتفاعل والتعافي ومراجعة ما بعد الحادث

  • إذا لم تكن لديك خطة استجابة للحوادث، فهناك الكثير من الموارد المتاحة على الإنترنت والتي يمكنك الاستعانة بها، على سبيل المثال يمكنك الاطلاع على قالب خطة الاستجابة للحوادث من Counteractive والمراجع والقراءات الإضافية
• أرسل ما يثبت أنك اختبرت الخطة خلال آخر 12 شهرًا. قد يأتي هذا الإثبات بأشكال مختلفة، ولكن يجب أن يتضمن ما يلي:

  • وصف السيناريو (على سبيل المثال، تمرين محاكاة استجابة لهجوم الفدية)
  • تاريخ إجراء الاختبار
  • دور كل مشارك
  • في حالة عدم مشاركة أي فرد ذُكر اسمه في قسم الأدوار والمسؤوليات، يجب توضيح السبب لكل فرد
• يرجى تنقيح المعلومات الحساسة (على سبيل المثال معلومات تحديد الهوية الشخصية مثل الاسم وعنوان البريد الإلكتروني) من هذا الإثبات قبل إرساله نموذج الإثبات

خطة الاستجابة للحوادث

أنشأ أحد المطوّرين خطة شاملة للاستجابة للحوادث استنادًا إلى هذا القالب. تصف هذه الصور جدول المحتويات فقط ولكن يوجد رابط أدناه للقالب الكامل.

اطلع على النسخة الكاملة من قالب خطة الاستجابة للحوادث من Counteractive (بتنسيق docx)

اختبار الاستجابة للحوادث

أجرى أحد المطوّرين اختبارًا لخطة الاستجابة للحوادث من خلال تمرين محاكاة ووثق النتيجة استنادًا إلى هذا القالب.

طلب مصادقة متعددة العوامل للوصول عن بُعد

سؤال: هل تطلب مصادقة متعددة العوامل من أجل الوصول عن بُعد بالنسبة إلى كل حساب يمكنه الوصول إلى بيئة السحابة أو الخادم و/أو الوصول إلى الخدمات التي تستخدمها لنشر أنظمة تخزين بيانات المنصة من Meta وصيانتها ومراقبتها وتشغيلها؟

الغرض

يتمثل أحد الأساليب الشائعة التي يتبعها المحتالون للوصول إلى البيانات السرية في البدء بالوصول إلى الأدوات التي يستخدمها المطوّر لبناء تطبيقه/نظامه أو تشغيلهما. هناك أدوات متطورة لاختراق الحسابات المحمية بكلمات السر فقط؛ ولذلك فإن المصادقة متعددة العوامل توفر طبقة أمان إضافية للحماية من هذا الخطر.

• يستخدم مطوّرو البرامج مجموعة متنوعة من الأدوات لبناء ونشر وإدارة تطبيقاتهم/أنظمتهم
• ومن الشائع استخدام هذه الأدوات عن بعد من خلال الإنترنت (على سبيل المثال، موظف يعمل من المنزل وينقل ميزة جديدة في البرنامج أو يحدّث تكوين السحابة)
• تعتبر الأدوات المحمية بمصادقة من عامل واحد (اسم المستخدم وكلمة السر) عرضة بدرجة كبيرة لهجمات الاستيلاء على الحساب. على سبيل المثال، يمكن للمهاجمين استخدام أدوات لتجربة توليفات من اسم المستخدم وكلمة السر والتي قد جرى تسريبها من إحدى الأدوات للوصول إلى أداة أخرى
• تحمي المصادقة متعددة العوامل من هذه الهجمات من خلال المطالبة بعامل إضافي إلى جانب كلمة السر عند تسجيل الدخول، على سبيل المثال، رمز يتم إنشاؤه بواسطة تطبيق مصادقة

ملخص المتطلبات

على نحو يرتبط بمعالجة المؤسسة لبيانات المنصة، يجب حماية الوصول عن بُعد إلى هذه الأدوات من خلال المصادقة متعددة العوامل (أي عدم الاكتفاء بكلمة السر فقط):

• الأدوات المستخدمة لنشر تغييرات الرمز/التكوين إلى النظام/التطبيق
• الوصول الإداري إلى بيئة سحابة أو خادم، إن وجد

تحديدًا، يجب تشغيل المصادقة متعددة العوامل أو وسيلة حماية بديلة مقبولة لما يلي:

• أدوات التعاون/التواصل - على سبيل المثال، البريد الإلكتروني للعمل أو Slack
• مستودع الرموز - على سبيل المثال GitHub أو أي أداة أخرى تستخدم لتتبع التغييرات على رمز/تكوين التطبيق/النظام
• وإذا كنت تعالج بيانات المنصة على الخادم:

  • أدوات نشر البرامج - الأدوات المستخدمة لنشر الرمز على بيئة السحابة/الخادم، على سبيل المثال Jenkins أو أي أداة أخرى للدمج المستمر/النشر المستمر (CI/CD)
  • الأدوات الإدارية - البوابات أو أنواع الوصول الأخرى المستخدمة لإدارة/مراقبة بيئة السحابة أو الخادم
  • الوصول عن بُعد إلى الخوادم - بروتوكول النقل الآمن أو سطح المكتب البعيد أو الأدوات المشابهة المستخدمة لتسجيل الدخول عن بُعد إلى الخوادم التي تعمل من جهة الخادم

فيما يتعلق بتنفيذ المصادقة متعددة العوامل:

• يوصى باستخدام تطبيق أو جهاز مصادقة (على سبيل المثال، YubiKey) ويفضّل عن إرسال الرموز عبر رسالة SMS
• لكن بإمكان المؤسسات استخدام أي شكل من أشكال تنفيذ المصادقة متعددة العوامل

دليل الإثباتات

إذا طُلب منك تقديم إثبات لهذه الحماية، فاتبع الإرشادات الواردة في تجهيز الإثبات لتجهيز كل من السياسة/الإجراء وإثبات التنفيذ.

• يجب أن يوضح إثبات التنفيذ أن المصادقة متعددة العوامل قد تم تنفيذها على الأدوات المناسبة للبيئة الواردة أعلاه (أي أدوات التعاون، ومستودع الرموز، ونشر السحابة/الخادم، وبوابة السحابة/الخادم الإدارية، والوصول عن بُعد للسحابة/الخادم)
• يتباين التنفيذ تبعًا للتكوين:

  • على سبيل المثال، إذا كنت تستخدم موفر خدمة تسجيل دخول موحد، قد يمثل ذلك لقطة شاشة لتكوين عام من المؤسسة أو لقطة شاشة لتكوين لكل تطبيق.
  • إذا لم يكن لديك موفر خدمة تسجيل دخول موحد، قد يمثل ذلك لقطة شاشة لتكوين أداة معينة
• على أي حال، نحن بحاجة إلى ما يثبت تمكين المصادقة بعوامل متعددة لكل المستخدمين وليس فقط مثالاً على حساب تم تمكين المصادقة متعددة العوامل له

نموذج الإثبات

AzureAD

تستخدم إحدى المؤسسات AzureAD كحل تسجيل دخول موحد. تنص السياسة على ضرورة استخدام المصادقة متعددة العوامل.

ومن ثم يتم ربط السياسة بالتطبيقات السحابية التي تنطبق عليها. من خلال استخدام هذا النهج، يجب أن يعرض الإثبات قسم العناصر المحددة بالكامل لتوضيح التطبيقات السحابية التي تتطلب المصادقة متعددة العوامل.

Okta

تتطلب هذه القاعدة المصادقة متعددة العوامل لكل عمليات تسجيل الدخول.

AWS IAM

يعتبر ذلك مثالاً على سياسة AWS IAM تتيح تكوين المصادقة متعددة العوامل وتمنع الإجراءات الأخرى في حالة عدم وجود المصادقة متعددة العوامل.

GitHub

قامت مؤسسة بتكوين مصادقة GitHub بحيث تطلب المصادقة متعددة العوامل لجميع الأشخاص في المؤسسة.

وسائل الحماية البديلة المقبولة

• لأي شكل من أشكال الوصول عن بُعد داخل المؤسسة لا يتم فيه فرض المصادقة متعددة العوامل، ينبغي عليك توضيح ما إذا كنت تستخدم واحدة أو أكثر من هذه المنهجيات لمنع الاستيلاء على الحسابات:

  • متطلبات استخدام كلمة سر قوية - على سبيل المثال، حد أدنى من تعقيد كلمة السر، وحظر استخدام الكلمات المعجمية، وحظر كلمات السر المعروف أنه سبق اختراقها
  • إيقاف المصادقة - استخدام أداة توفر فترات انتظار بمدد تزيد تدريجيًا بين محاولات تسجيل الدخول غير الناجحة من نفس المصدر
  • الإقفال التلقائي على سبيل المثال، آلية لحظر تسجيل الدخول تلقائيًا للحساب بعد 10 محاولات فاشلة لتسجيل الدخول

اتباع نظام لصيانة حسابات المستخدمين

سؤال: هل لديك نظام لصيانة الحسابات (تعيين صلاحيات الوصول والامتيازات وإلغائها ومراجعتها)؟

الغرض

يعتبر اتباع نظام جيد لإدارة الحسابات جزءًا مهمًا من جهود منع استخدام الحسابات بشكل غير مُصرح به للوصول إلى بيانات المنصة. وبوجه خاص، يجب على المطوّرين التأكد من إلغاء الوصول إلى الموارد أو الأنظمة عند عدم الحاجة.

• تعتبر الحسابات هي وحدة الإدارة الأساسية لمنح الأشخاص صلاحية الوصول إلى الأنظمة والبيانات والوظائف الإدارية
• يتم منح الحسابات أذونات تتيح لها اتخاذ إجراءات معينة؛ ومن الممارسات الجيدة أن يتم منح أقل عدد أذونات تحتاج إليه الحسابات - ويعرف ذلك باسم مبدأ أقل الامتيازات
• عندما يترك الشخص مؤسسة ما، من المهم أن يتم تعطيل حساباته على الفور لسببين:

  • (1) منع وصول هذا الشخص (أي الموظف السابق).
  • (2) تقليل احتمال استخدام شخص غير مُصرح به للحساب دون أن يلاحظ أحد ذلك. على سبيل المثال، يمكن لشخص محتال استخدام الهندسة الاجتماعية ليطلب من مكتب المساعدة المعني بتكنولوجيا المعلومات إعادة تعيين كلمة السر الخاصة بالحساب. إذا كان هذا الحساب يخص موظف حالي، من المحتمل أن يبلغ الموظف عن عدم قدرته على تسجيل الدخول، بينما إذا ظل الحساب نشطًا لكنه يخص موظف سابق، فقد لا يلاحظ ذلك أحد.
• مع أخذ هذا في الحسبان، يجب على المؤسسات اتباع طريقة نظامية لإدارة الحسابات، ومنح الأذونات أو الامتيازات، وإلغاء الوصول عند انقضاء الحاجة إليه

ملخص المتطلبات

• يجب عليك استخدام أداة أو عملية لإدارة الحسابات لكل من هذه الأدوات/الأنظمة/التطبيقات:

  • المستخدمة للتواصل فيما بينهم، على سبيل المثال Slack أو البريد الإلكتروني للعمل
  • المستخدمة لنقل البرامج، على سبيل المثال مستودعات الرموز
  • إدارة وتشغيل الأنظمة (على النحو الذي ينطبق على معالجة بيانات المنصة)
• يجب عليك إجراء مراجعة دورية (أي بما لا يقل عن مرة كل 12 شهرًا) لصلاحيات الوصول الممنوحة واتباع عملية لإلغاء صلاحيات الوصول في الحالات التالية: (1) عند انقضاء الحاجة إلى هذا الوصول، و(2) توقف استخدامه
• يجب عليك أيضًا اتباع عملية لإلغاء الوصول على الفور إلى هذه الأدوات عند توقف الشخص عن العمل بالمؤسسة
• لا تفرض Meta

  • استخدام أداة معينة - يجوز للمطوّر استخدام منتج من أحد الأدلة مثل Google Cloud identity أو Microsoft Azure Active Directory، أو منتج سحابي مثل AWS Identity وAccess Management (IAM)، أو استخدام ورقة بيانات يتم تحديثها بانتظام.
  • وجود أداة واحدة موحدة لإدارة الحسابات على مستوى أنواع الوصول المختلفة هذه.

دليل الإثباتات

اتبع الإرشادات الواردة في تجهيز الإثبات لتجهيز كل من السياسة/الإجراء وإثبات التنفيذ.

• السياسة/الإجراء - قم بتقديم سياسات موثقة ومستندات إجراءات تغطي ممارسات إدارة الحساب. نتوقع أن يحتوي هذا المستند على إجراءات إنشاء الحسابات، ومنح الأذونات، والحد الأدنى لتعقيد كلمة السر، وسياسة إغلاق الحسابات، وسياسة المصادقة متعددة العوامل، وإجراءات إعادة تعيين الحسابات، وعملية إلغاء صلاحية الوصول بعد فترة من عدم النشاط وعند مغادرة الأشخاص للمؤسسة (على سبيل المثال عند استقالة الموظف أو إنهاء عقده مع المؤسسة).
• إثبات التنفيذ - قم بتقديم إثبات من واحدة على الأقل من الأدوات أو العمليات التالية المستخدمة لإدارة الحسابات (أو أشر إلى أن ذلك لا ينطبق على هذه البيئة): (1) البريد الإلكتروني للعمل وأدوات التعاون، (2) مستودع الرموز، (3) أدوات نشر السحابة/الخادم، (4) بوابة السحابة/الخادم الإدارية، (5) تسجيل الدخول عن بُعد إلى السحابة/الخادم (على سبيل المثال بروتوكول النقل الآمن أو سطح المكتب البعيد). وبالنسبة إلى الأداة أو العملية التمثيلية المميزة، احرص على تضمين إثبات يوضح ما يلي:

  • إلغاء صلاحية وصول الأشخاص الذين غادروا المؤسسة إلى هذه الأدوات (على سبيل المثال، تقرير تسوية يقارن حسابات المستخدمين بالبيانات الموثوقة لأعضاء المؤسسة الحاليين)
  • إلغاء صلاحيات الوصول التي لم يتم استخدامها لفترة من الوقت (على سبيل المثال تقرير يوضح أن تاريخ آخر وصول لمالك حساب مستخدم تمثيلي نشط يقع خلال آخر 90 يومًا إذا كان الحد الأقصى لمدة عدم النشاط هو ثلاثة أشهر)

نموذج الإثبات

السياسة/الإجراء - أنشأ أحد المطوّرين معيار لإدارة دورة حياة الوصول يتضمن إجراءات لمنح صلاحية الوصول ومراجعتها وإلغائها.

مثال للتنفيذ - إلغاء صلاحية وصول الموظفين الذين غادروا المؤسسة

يستخدم أحد المطوّرين Workday كمصدر موثوق لبيانات الموارد البشرية، بما في ذلك الحالة الوظيفية الحالية. يستخدم هذا المطوّر Google Cloud Identity كموفر خدمات هوية (IdP) لإدارة حسابات المستخدمين ومنح صلاحية الوصول للأدوات وأنظمة المعلومات.

يرسل أحد المطوّرين ما يثبت إلغاء صلاحية وصول الموظفين الذين غادروا المؤسسة من خلال إرسال تقرير يوضح أنه قد تم إعداد تقرير تسوية حديث (أي خلال آخر 12 شهرًا) يظهر عدم وجود حسابات مستخدمين نشطة في Google Cloud Identity للأشخاص غير المدرجين في قائمة الموظفين النشطين وفقًا لتقرير Workday عن الموظفين الحاليين.

مثال للتنفيذ - إلغاء صلاحية الوصول التي لم تعد مستخدمة

يستخدم أحد المطوّرين Google Cloud Identity كموفر خدمات هوية (IdP) لإدارة حسابات المستخدمين ومنح صلاحية الوصول للأدوات وأنظمة المعلومات.

يرسل أحد المطوّرين ما يثبت إلغاء صلاحية الوصول عندما لم تعد تُستخدم (على سبيل المثال عدم تسجيل الدخول خلال آخر 6 أشهر) من خلال إرسال إثبات من دليل المستخدمين مرتب حسب آخر تسجيل دخول ليبرهن على عدم وجود حسابات مستخدمين نشطة إذا كان تاريخ آخر تسجيل دخول أقدم من ذلك.

مثال للتنفيذ - GitHub (مستودع رموز)

يستخدم أحد المطوّرين أداة تسجيل دخول موحد (SSO) لإدارة الهوية ومنح صلاحية الوصول إلى الأدوات وأنظمة المعلومات. قام المطوّر بتكوين GitHub ليطلب المصادقة من خلال تسجيل الدخول الموحد.

المحافظة على البرامج محدّثة بصفة دائمة

سؤال: هل تقوم باتباع نظام للحفاظ على تحديث رمز النظام وبيئاته، بما في ذلك الخوادم والأجهزة الافتراضية والتوزيعات، والمكتبات، والحِزم، وبرامج الحماية من الفيروسات؟

الغرض

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

• يعتمد مطوّرو التطبيقات على مجموعة متنوعة من البرامج التابعة لجهات خارجية لتشغيل التطبيقات/الأنظمة التي تعالج بيانات المنصة
• على سبيل المثال، سيعتمد المطوّر على بعض أو كل مما يلي:

  • المكتبات ومجموعات SDK والحزم - يقوم المطوّرون بتجميعها برمز برمجي مخصص خاص بهم لإنشاء تطبيق
  • صور الأجهزة الافتراضية وحاويات التطبيقات وأنظمة التشغيل - يتم تشغيل التطبيق داخل واحدة أو أكثر من هذه الحاويات، والتي توفر خدمات مثل المحاكاة الافتراضية والوصول إلى الشبكات والتخزين
  • المتصفحات وأنظمة التشغيل والتطبيقات الأخرى التي يستخدمها الموظفون/المساهمون - البرامج التي تعمل على الأجهزة المحمولة وأجهزة الكمبيوتر المحمولة التي يستخدمها المطوّر لبناء نظامه وتشغيله
• يتم العثور على ثغرات أمنية في هذه المكونات بشكل دوري، مما يؤدي إلى إصدار تصحيحات
• وبعد ذلك يتم الإفصاح عن الثغرات الأمنية التي تم إصلاحها بواسطة التصحيحات في قواعد البيانات العامة بتصنيف خطورة (منخفض أو متوسط أو مرتفع أو حرج)
• لذلك، يجب أن يكون لدى المطوّرين الذين يستخدمون منصة Meta طريقة منهجية لإدارة التصحيحات من خلال

  • تحديد التصحيحات ذات الصلة بتطبيقهم/نظامهم
  • تحديد الأولوية على أساس الانتشار
  • تطبيق التصحيحات كنشاط أعمال مستمر

ملخص المتطلبات

بالنسبة إلى مكونات البرامج التالية، حسب الاقتضاء، يجب أن يكون لديك طريقة محددة وقابلة للتكرار لتحديد التصحيحات المتاحة التي تعمل على حل الثغرات الأمنية، وتحديد الأولويات استنادًا إلى المخاطر، وتطبيق التصحيحات كنشاط مستمر:

1. المكتبات ومجموعات SDK والحِزم وحاويات التطبيقات وأنظمة التشغيل المستخدمة في بيئة سحابية أو بيئة خادم
2. المكتبات ومجموعات SDK والحِزم المستخدمة على أجهزة عميلة، مثل داخل تطبيقات الهواتف المحمولة
3. أنظمة التشغيل والتطبيقات التي يستخدمها الأعضاء لإنشاء وتشغيل التطبيق/النظام، على سبيل المثال، أنظمة التشغيل والمتصفحات التي تعمل على أجهزة الكمبيوتر المحمولة للموظفين

لا تتطلب Meta استخدام أي أداة بعينها لهذه النشاطات. من الشائع أن تستخدم المؤسسة طرقًا مختلفة للحفاظ على تحديث أنواع البرامج المختلفة بصفة دائمة (على سبيل المثال، المكتبات التي تضمينها مع التطبيق في مقابل تحديثات أنظمة التشغيل لأجهزة الكمبيوتر المحمولة للموظفين).

يوضح المخطط التالي المواضع التي قد يكون التصحيح فيها مطلوبًا لأنواع الهياكل المختلفة.

دليل الإثباتات

إذا طُلب منك تقديم إثبات لهذه الحماية، فاتبع الإرشادات الواردة في تجهيز الإثبات لتجهيز كل من السياسة/الإجراء وإثبات التنفيذ.

ابدأ بتحديد أنواع البرامج داخل النطاق ضمن البيئية، على سبيل المثال، المكتبات ومجموعات SDK والحِزم وصور الأجهزة الافتراضية وحاويات التطبيقات وأنظمة التشغيل والمتصفحات والتطبيقات الأخرى التي يستخدمها الموظفون/المساهمون.

يمكن أن يكون لديك أداة واحدة أو أكثر تستخدمها من أجل النشاطات التالية:

• المخزون - توثيق من خلال لقطة شاشة أو مستند يوضح أن أداة أو عملية تمثل، في النهاية، قائمة بالمكتبات داخل النطاق والحِزم ومجموعات SDK والحاويات وخوادم التطبيقات وأنظمة التشغيل التي تحتاج إلى تصحيح. يجب أن تتوفر مخزونات لممثل لأنواع البرامج (على سبيل المثال، التطبيق (التطبيقات) السحابية وتطبيق (تطبيقات) البرنامج وأجهزة الموظفين).
• تحديد تصحيحات البرامج المتوفرة - يجب توفير أداة أو عملية بغرض تحديد تصحيحات بالأمان الموجودة وذات الصلة بالمخزون.
• تعيين الأولوية - يجب توفير أداة أو عملية (على سبيل المثال، تذاكر Jira أو مشكلات GitHub أو جدول بيانات تتبع) يتم من خلالها تعيين أولوية التصحيحات ذات الصلة

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

نموذج الإثبات

Snyk لتطبيق NodeJS - يستخدم المطوّر واجهة سطر الأوامر Synk لتحديد التبعيات المصنّفة إلى حزم التابعة لجهات خارجية والتي تحتوي على ثغرات أمنية معروفة ويتم تعيين الأولوية استنادًا إلى مدى خطورة تلك الثغرات الأمنية.

تدقيق NPM

يستخدم المطوّر تدقيق NPM للبحث عن الثغرات الأمنية في التبعيات المستخدمة في تطبيق Node. تعرض صورة المثال أدناه عدة ثغرات أمنية شديدة الخطورة تحتاج إلى تصحيح.

Trivy

يستخدم المطوّر Trivy للعثور على الثغرات الأمنية في صورة جهاز. تعرض صورة المثال أدناه ثغرات أمنية شديدة الخطورة في المكتبات المضمّنة في هذه الصورة تحتاج إلى تصحيح.

خدمات تحديث Windows Server ‏(WSUS)

مطوّر يستخدم خدمات تحديث Windows Server ‏(WSUS) لإدارة مجموعة خوادمه وأجهزة الكمبيوتر/أجهزة الكمبيوتر المحمولة التي يستخدمها. تعرض صورة المثال أدناه طريقة عرض المسؤول لأداة WSUS، التي تتيح إمكانية مراجعة تحديثات Windows والموافقة عليها ونشرها.

توفير نظام لتسجيل الوصول إلى بيانات المنصة وتتبع أماكن إرسال وتخزين بيانات المنصة

الغرض

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

• تتيح سجلات التدقيق للمؤسسة إمكانية تسجيل حقيقة وقوع الحدث بالفعل، على سبيل المثال أن مستخدمًا بعينه قد قام بتنفيذ استعلام في جداول قواعد البيانات التي تحتوي على بيانات المنصة
• ومن ثمّ يمكن لهذه السجلات دعم عمليات مثل تشغيل تنبيهات تلقائية استنادًا إلى النشاطات المشكوك فيها أو تحليل استقصائي بعد تحديد وقوع حادثة تتعلق بالأمان

ملخص المتطلبات

إذا كنت تقوم بمعالجة بيانات المنصة على الخادم، فإنك ضمن هذه البيئة:

• يجب عليك الاحتفاظ بسجلات تدقيق تقوم بتسجيل الأحداث الأساسية (على سبيل المثال، الوصول إلى بيانات المنصة أو استخدام الحسابات ذات الأذونات المتقدمة أو التغييرات في تكوين سجل التدقيق)
• يجب دمج سجلات التدقيق في مخزن مركزي وحمايتها ضد التغيير أو الحذف

دليل الإثباتات

إذا طُلب منك تحميل إثبات، يجب أن يثبت ما يلي:

• أنك تفهم جيدًا في الوقت الحالي كيفية تخزين بيانات المنصة والوصول إليها ونقلها، على سبيل المثال عبر مخطط دفق بيانات موجود يعرض نظرة عامة على النظام، ويعيّن الخدمات التي تقوم بتخزين بيانات المنصة ويعرض نقاط الدخول والخروج، بما في ذلك عمليات النقل المتوقعة إلى أي خدمات تابعة لجهة خارجية (جهة رابعة)
• قيامك بتنفيذ سجلات تدقيق لمكافحة التلاعب
• تسجيل الأحداث المتعلقة بالوصول إلى بيانات المنصة في السجلات

مراقبة عمليات نقل بيانات المنصة والنقاط المهمة التي يمكن أن تغادر منها بيانات المنصة النظام (على سبيل المثال، الجهات الخارجية ونقاط النهاية العامة)

الغرض

يُعد فهم كيفية توقع معالجة بيانات المنصة ثم مراقبة المعالجة الفعلية طريقة مهمة بالنسبة إلى المؤسسة للتأكد من أن بيانات المنصة تُستخدم فقط للأغراض المقصودة

• يجب على المطوّر أن يكوّن فهمًا حاليًا لكيفية تخزين بيانات المنصة ونقلها عبر الشبكات وكتابتها في النُسخ الاحتياطية (والتي يمكن تكرارها في أي مكان آخر)
• على سبيل المثال، يمكن أن تحدد المراقبة المواقف التي يتم خلالها نقل بيانات المنصة بطريقة غير متوقعة أو إذا كان يتم نقلها عبر شبكة دون تشفير ملائم بشكل انتقالي حتى تتمكن من اتخاذ إجراء

ملخص المتطلبات

إذا كنت تقوم بمعالجة بيانات المنصة على الخادم، فإنك ضمن بيئة الخادم هذه، يجب عليك القيام بما يلي:

• الاحتفاظ بمخطط دفق بيانات دقيق يعرض الأماكن التي يتم فيها تخزين بيانات المنصة ومعالجتها ونقلها عبر الشبكات
• تكوين المراقبة (على سبيل المثال، تدقيق السجلات باستخدام منتج مراقبة تلقائي) لتحديد عمليات نقل بيانات المنصة خارج النظام
• تكوين نظام المراقبة، إذا كان ممكنًا، لإصدار التنبيهات التي تتم مراجعتها على الفور في حالة وجود عمليات نقل غير متوقعة لبيانات المنصة (وراجع المتطلب أدناه أيضًا - توفير نظام تلقائي لمراقبة السجلات وأحداث الأمان الأخرى وإنشاء تنبيهات للأحداث غير المعتادة أو المرتبطة بالأمان)

دليل الإثباتات

إذا طُلب منك تقديم إثبات لهذه الحماية، فاتبع الإرشادات الواردة في تجهيز الإثبات لتجهيز كل من السياسة/الإجراء وإثبات التنفيذ.

يجب عليك توفير إثبات لما يلي:

• أنك تفهم جيدًا في الوقت الحالي كيفية تخزين بيانات المنصة والوصول إليها ونقلها، على سبيل المثال عبر مخطط دفق بيانات موجود يعرض نظرة عامة على النظام، ويعيّن الخدمات التي تقوم بتخزين بيانات المنصة ويعرض نقاط الدخول والخروج، بما في ذلك عمليات النقل المتوقعة إلى أي خدمات تابعة لجهة خارجية (جهة رابعة)
• تنفيذ سجلات تدقيق لمكافحة التلاعب
• تسجيل الأحداث المرتبطة بعمليات نقل بيانات المنصة في السجلات؛ يجب أن تتضمن الأحداث الوقت ومعرّف المستخدم أو التطبيق الذي يقوم باتخاذ الإجراء والمصدر والوجهة

توفير نظام تلقائي لمراقبة السجلات وأحداث الأمان الأخرى وإنشاء تنبيهات للأحداث غير المعتادة أو المرتبطة بالأمان

الغرض

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

ملخص المتطلبات

إذا كنت تقوم بمعالجة بيانات المنصة على الخادم، فإنك ضمن بيئة الخادم هذه، يجب عليك القيام بما يلي:

• توفير أداة قادرة على استيعاب ملفات السجلات والأحداث الأخرى وإنشاء قواعد يجب عليها إصدار تنبيه إذا تم استيفاؤها وآلية لتوجيه التنبيهات إلى الأشخاص (على سبيل المثال، أحد محققي الأمان المكلفين بذلك)
• استيعاب الإشارات ذات الصلة داخل الأداة (على سبيل المثال، سجلات الوصول إلى الويب ومحاولات المصادقة والإجراءات التي يتخذها المستخدمون الذين يتمتعون بامتيازات متقدمة)
• بمرور الوقت، يمكنك تنقيح وتحسين القواعد للموازنة بين الإشارات الحقيقية والإشارات الزائفة (على سبيل المثال، تجنب ظهور تنبيهات زائفة بشكل أكثر من اللازم ولكن أيضًا مع عدم تجاهل الأحداث التي تضمن إجراء تحقيق)

دليل الإثباتات

يجب على المطوّر عادة تبنّي استخدام أداة إدارة الأحداث والمعلومات المتعلقة بالأمان (SIEM) لهذا الغرض، على سبيل المثال:

• McAfee Enterprise Security Manager
• SolarWinds Security Event Manager
• Splunk Enterprise Security
• Sumo Logic

يجب عليك تقديم إثبات يؤكد أن مصادر الإشارات ذات الصلة يتم توجيهها إلى الأداة التي يقومون باختيارها، وأنه تم تكوين قواعد التشغيل أو التنبيهات، وإثبات أن التنبيهات يتم توجيهها إلى الأشخاص المسؤولين عن المتابعة، وأخيرًا أنه توجد عملية يتم من خلالها تنقيح التنبيهات بشكل دوري (على سبيل المثال، من خلال المراجعة الشهرية ودورات التحديث).

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

أ

جهة خارجية (ثالثة) - في مصطلحات إدارة المخاطر، يشير مصطلح "جهة خارجية" إلى المطوّرين على منصة Meta (الجهة الأساسية (الأولى) هي Meta نفسها؛ في حين تشير الجهة الفرعية (الثانية) إلى الأشخاص الذين يستخدمون منتجات Meta)

جهة تابعة (رابعة) - في مصطلحات إدارة المخاطر، يشير مصطلح "جهة تابعة" إلى الشركات التي يعتمد عليها المطوّرون لتزويدهم بخدمات تعمل تمكين نشاطهم التجاري (تشير الجهة الأساسية إلى Meta، والجهة الفرعية إلى مستخدمي Meta، والجهة الخارجية إلى المطوّرين على منصة Meta).رمز الوصول - بيانات اعتماد، مثل كلمة السر، تتيح للبرامج استدعاء واجهة API لاتخاذ إجراء ما (على سبيل المثال: قراءة البيانات من الملف الشخصي للمستخدم).

خدمات Amazon على الويب (AWS) - مجموعة خدمات الكمبيوتر السحابية من Amazon

معرف على مستوى التطبيق (ASID) - معرف فريد تقوم Meta بإنشائه عندما يختار شخص ما استخدام أحد التطبيقات. وتساعد المعرفات على مستوى التطبيقات في تحسين خصوصية المستخدمين من خلال زيادة درجة صعوبة ربط مجموعات البيانات بين المستخدمين على مستوى التطبيقات، نظرًا لأن المستخدم الذي يستخدم تطبيقين سيكون لديه معرفات على مستوى التطبيقات مختلفة في كل تطبيق.

مفتاح سري للتطبيق - مفتاح سري مشترك توفره شركة Meta للمطوّرين عبر لوحة معلومات التطبيق. تسمح حيازة المفتاح السري للتطبيق للبرنامج باتخاذ بعض الإجراءات عبر واجهة Graph API، لذلك يحتاج المطوّرون إلى ضرورة عدم تمكن الأطراف غير المصرح لها من الوصول إلى المفتاح السري للتطبيق.

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

حاوية التطبيق - تضم الحاوية الرمز البرمجي والتبعيات ذات الصلة حتى يتم تشغيل التطبيق على مختلف أنواع الخوادم (على سبيل المثال: الخوادم التي تعمل بأنظمة تشغيل مختلفة مثل Linux أو Windows Server). سيقوم المطوّر بإنشاء صورة حاوية تضم تطبيقه. ويستضيف (يشغّل) محرك حاوية التطبيق أو وقت التشغيل صورة الحاوية.

تشفير التطبيق - طريقة لحماية البيانات حيث تقوم برامج التطبيقات نفسها بإجراء عمليات التشفير وفك التشفير. في المقابل، يقوم بروتوكول أمان طبقة النقل (TLS) بتشفير البيانات أثناء النقل بسلاسة عندما يقوم تطبيق ما بإنشاء اتصال آمن مع خادم بعيد (على سبيل المثال، باستخدام HTTPS) ويقدم موفرو الخدمات السحابية خدمات لتشفير البيانات بشفافية في حالة السكون.

واجهة برمجة التطبيقات (API) - تتيح لجهازي كمبيوتر التحدث والاتصال فيما بينهما عبر شبكة، على سبيل المثال قيام تطبيق هواتف محمولة باستدعاء بيانات طقس اليوم لموقع معين من نظام مركزي للتنبؤ بالطقس.

إثبات المفتاح السري للتطبيق - طبقة أمان إضافية لعمليات استدعاء واجهة API إلى Meta حيث يقوم المطوّر بإنشاء معلمة (إثبات المفتاح السري للتطبيق) توضح أنه يملك المفتاح السري للتطبيق. ويشير إثبات المفتاح السري للتطبيق إلى منتج لوظيفة تجزئة (والتي يُطلق عليها أيضًا وظيفة أحادية الاتجاه) استنادًا إلى المفتاح السري للتطبيق ورمز الوصول. يؤدي تكوين التطبيق لطلب إثباتات المفاتيح السرية للتطبيقات أثناء استدعاءات واجهة Graph API إلى الحد من الضرر المحتمل الناتج عن خرق رموز وصول المستخدمين، نظرًا لأنه لا يمكن استخدام رموز الوصول هذه دون معلمة إثبات المفتاح السري للتطبيق الإضافية.

ب

الواجهة الخلفية كخدمة (BaaS) - نمط من الحوسبة السحابية يوفر مجموعة من الإمكانات الخاصة بالخادم لمطوّر التطبيق حيث يمكن للمطوّر التركيز على بناء الواجهة الأمامية (أي، جزء التطبيق الذي يتفاعل معه المستخدمون). تشبه حلول الواجهة الخلفية كخدمة (BaaS) حلول المنصة كخدمة (PaaS)، بالإضافية إلى أنها تضيف خدمات مثل مصادقة المستخدمين والإشعارات المباشرة على الهواتف المحمولة. على سبيل المثال، هذه بعض منتجات "الواجهة الخلفية كخدمة" الشائعة: AWS Amplify وتطبيق Azure للهواتف المحمولة وFirebase وMongoDB Switch.

ت

نص مشفر - النص المشفر عبارة عن مرادف للبيانات المشفرة، ويشير إلى الاسم الذي تم منحه للبيانات التي تم تعيينها إلى وضع عدم القراءة عبر خوارزمية تشفير ما. ونقيض النص المشفر هو النص العادي.

جانب العميل - يتفاعل الأشخاص عادةً مع الخدمات التي يمكن الوصول إليها عبر الإنترنت من خلال فتح موقع ويب في متصفح أو من خلال تشغيل تطبيق هواتف محمولة على هاتف أو جهاز لوحي. تتم الإشارة إلى تطبيقات المتصفح أو الهواتف المحمولة كبرامج عميلة محلية أو جانب العميل. وترسل البرامج العميلة طلبات من أجهزة كمبيوتر بعيدة (خوادم) عبر الإنترنت.

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

تكوين الخدمة السحابية - مجموعة خيارات الحوسبة السحابية التي قامت بتعيينها المؤسسة فيما يتعلق باستخدامها لموفر خدمة سحابية يقوم بتشغيل بعض البرامج. تتضمن أمثلة تكوين الخدمة السحابية أنواع اتصالات الشبكة المسموح بها أو المحظورة، ومكان كتابة ملفات السجل ومدة الاحتفاظ بها، ومجموعة المستخدمين المصرح لهم بإجراء تغييرات على تكوين الخدمة السحابية.

عناصر التحكم البديلة - عنصر تحكم أمني يختلف عن مجموعة المتطلبات الأساسية ولكنه يهدف إلى توفير حماية مماثلة ضد المخاطر.

ث

قاعدة البيانات - برامج تتيح إمكانية تخزين البيانات العشوائية وقراءتها وتحديثها وحذفها. يمكن تشغيل قواعد البيانات على البرامج العميلة على الخوادم. عادةً ما تقوم المؤسسات التي تندمج مع منصة Meta بتخزين البيانات التي تقوم باستدعائها من واجهة Graph API في قاعدة بيانات تقوم بتشغيل الخادم.

فك التشفير - عميلة يتم من خلالها إعادة تحويل البيانات المشفرة إلى تنسيقها الأصلي. بمعنى آخر، يتم من خلال فك التشفير تغيير النص المشفر إلى نص عادي.

ج

تشفير - عملية يتم من خلالها تحويل البيانات إلى تنسيق لا يمكن استخدامه إلى أي تنسيق لا يمكن فك تشفيره. بمعنى آخر، يتم من خلال التشفير تغيير النص العادي إلى نص مشفر.

التشفير في حالة السكون - بيانات تمت حمايتها باستخدام التشفير عند الكتابة إلى مساحة تخزين دائمة (على سبيل المثال: محرك أقراص). يوفر التشفير في حالة السكون طبقة حماية إضافية ضد الوصول غير المصرح به لأن المحتال القادر على قراءة الملفات الأولية على جهاز التخزين سيرى نصًا مشفرًا ولن يكون قادرًا على فك تشفيره ما لم يتمكن أيضًا من الوصول إلى مفتاح فك التشفير.

التشفير أثناء الإرسال - بيانات تمت حمايتها باستخدام التشفير عند إرسالها عبر شبكة. يوفر التشفير أثناء الإرسال الحماية ضد التنصت على طول مسار الشبكة نظرًا لأن المحتال القادر على قراءة حزم بيانات الشبكة سيرى نصًا مشفرًا ولن يكون قادرًا على فك تشفيره ما لم يتمكن أيضًا من الوصول إلى مفتاح فك التشفير.

برنامج توقف استخدامه (EOL) - عندما تختار مؤسسة إيقاف الدعم (على سبيل المثال: إنشاء ملفات تصحيح لحل الثغرات الأمنية) لمنتج برمجي، يتم اعتبار هذا البرنامج قد وصل إلى نهاية عمره الافتراضي. ونتيجة لعدم صيانة هذا البرنامج، يصبح من الخطر تمامًا تشغيل أي برنامج وصل إلى نهاية عمره الافتراضي.

ح

منصة Google السحابية (GCP) - مجموعة خدمات الحوسبة السحابية من Google. واجهة Graph API - الطريقة الأساسية تتيح للتطبيقات القراءة والكتابة إلى مخطط التواصل الاجتماعي من Meta. تتفاعل جميع مجموعات Meta SDK ومنتجات Meta مع واجهة Graph API بطريقة ما.

خ

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

بيئة مستضافة - تشير إلى مجموعة من الخوادم البعيدة والشبكات وأجهزة التخزين التي تقوم المؤسسة بتشغيلها في مركز البيانات لديها أو داخل مركز بيانات في موقع مشترك (مركز تنظيم) مع عملاء آخرين. وهذا الترتيب غير شائع نسبيًا في العصر الحديث حيث أصبحت الحوسبة السحابية أكثر شيوعًا.

د

موفر بيانات المستخدمين (IdP) - خدمة سحابية يتم استخدامها لإدارة الهويات الرقمية بشكل مركزي ومصادقة المستخدمين. وعادةً ما تقوم المؤسسات التي تستعين بموفر بيانات المستخدمين بتكوين التطبيقات السحابية للاعتماد على موفر بيانات المستخدمين لمصادقة المستخدمين. ويمكن للمؤسسة بعد ذلك إدارة المستخدمين عن طريق إنشاء تطبيقات محددة ومنح الوصول إليها وتعطيل حسابات المستخدمين بشكل مركزي داخل موفر بيانات المستخدمين بدلاً من الاضطرار إلى تكرار ذلك في كل تطبيق سحابي.

إدارة الهوية والوصول (IAM) - يشير المصطلح إلى فئة الأدوات والعمليات التي يتم استخدامها لإدارة الحسابات ومنح الوصول إلى الأنظمة.

البنية الأساسية كخدمة (IaaS) - نهج حوسبة سحابية يتيح للعملاء إمكانية تكوين خدمات الحوسبة والتخزين والشبكات دون تحمّل المسؤولية عن الأصول المادية نفسها (على سبيل المثال، إدارة مركز بيانات مليء بالخوادم وأجهزة الشبكة ومصفوفات التخزين). مقارنةً بحلول المنصة كخدمة (PaaS)، تمنح البنية الأساسية كخدمة (IaaS) المؤسسة المزيد من التحكم في تكوين أصولها السحابية لكن على حساب المزيد من التعقيد لإدارة هذه الأصول. على سبيل المثال، هذه بعض منتجات "البنية الأساسية كخدمة" الشائعة: AWS EC2 وMicrosoft Azure IaaS وGoogle Compute Engine.

ذ

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

ر

برنامج هواتف محمولة أو تطبيق هواتف محمولة - تطبيق يقوم الشخص بتثبيته على هاتف أو جهاز لوحي من متجر تطبيقات هواتف محمولة (على سبيل المثال: iOS App Store أو Google Play Store). من الشائع في برامج الهواتف المحمولة التواصل عبر الإنترنت مع واجهة REST API الخاصة بالمؤسسة وقد تتواصل البرامج أيضًا مع أطراف أخرى (على سبيل المثال، بواجهة Graph API عبر Facebook SDK لنظام Android).

مصادقة متعددة العوامل (MFA) - نهج مصادقة يتطلب أكثر من عامل واحد للحصول على صلاحية وصول إلى تطبيق أو نظام. على عكس المصادقة أحادية العوامل التي تعتمد على كلمة سر فقط لمصادقة المستخدم، عادةً ما تتطلب المصادقة متعددة العوامل كلمة سر بالإضافة إلى عنصر أو أكثر من هذه العناصر: رمز يتم إرساله عبر البريد الإلكتروني أو رسالة SMS أو رمز من تطبيق مصادقة أو مسح بيانات حيوية أو مفتاح أمان. تعمل المصادقة متعددة العوامل على حماية عمليات الاستيلاء على الحساب من خلال زيادة درجة الصعوبة على المحتالين غير المصرح لهم بالدخول إلى حساب ما، على سبيل المثال، من خلال المحاولة المتكررة لتسجيل الدخول إلى حساب باستخدام عنوان بريد إلكتروني معروف وكلمات سر شائعة لحين تحقيق النجاح.

ز

برامج أصلية - تتم الإشارة إلى التطبيقات التي يتم تنزيلها وتثبيتها على أجهزة الكمبيوتر المحمول أو الأجهزة المحمولة على أنها برامج أصلية (على سبيل المثال تطبيق فيسبوك لنظام iOS). وعلى العكس من ذلك، تتم الإشارة إلى التطبيق الذي يتم تشغيله داخل متصفح على أنه تطبيق ويب (على سبيل المثال، فتح فيسبوك باستخدام متصفح Chrome).

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

فحص الشبكة - عملية ضمن إدارة الأزمات تستخدم البرامج من أجل ما يلي: (1) تحديد الخوادم النشطة على شبكة ما ولاتي ستستجيب للاتصالات عن بُعد، ثم (2) معرفة ما إذا كان أي من هذه الخوادم يقوم بتشغيل إصدارات قديمة من البرامج المعروف أنها معرضة لثغرة أو أكثر من الثغرات الأمنية. يمكن أن تستخدم المؤسسة عملية فحص الشبكة بشكل دوري للتأكد من عدم وجود منافذ مفتوحة غير متوقعة على محيط الشبكة، على سبيل المثال.

مدير حزم العُقد (NPM) - أداة يتم استخدامها بواسطة مطوّري JavaScript لتسريع التطوير من خلال السماح بتضمين الحزم المُنشأة مسبقًا في نظام أو تطبيق المطوّر. وتتضمن أداة مدير حزم العُقد ميزات لتدقيق مجموعة الحزم المستخدمة بواسطة أحد التطبيقات وتحديد الحزم التي تتضمن ثغرات أمنية معروفة.

س

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

نظام تشغيل - البرنامج الذي يتم تشغيله على جهاز كمبيوتر أو جهاز محمول يتيح للتطبيقات إمكانية تشغيل واستخدام معالج وذاكرة ومساحة تخزين وموارد شبكة هذا الجهاز. على سبيل المثال، Microsoft’s Windows وApple’s macOS أو iOS وLinux.

عضو المؤسسة - شخص لديه دور ومسؤولية داخل مؤسسة ما، على سبيل المثال موظف أو مقاول أو عامل مؤقت أو متدرب داخلي أو متطوع.

جهاز المؤسسة - جهاز كمبيوتر أو جهاز محمول يتم استخدامه بواسطة أحد أعضاء المؤسسة في سياق تنفيذ أعمال للمؤسسة.

ش

شرط المنصة 6.أ.1 - يشير إلى قسم شروط منصة Meta (6) العنوان (أ) الفقرة (1)، والذي يوضح التزامات مطوّري المنصة المرتبطة بأمان البيانات.

حزمة - مرادف للمكتبة

تصحيح - تحديثات البرامج التي تعمل على حل الثغرات الأمنية أو إصلاح الأخطاء أو إضافة وظائف جديدة. يتم تصحيح جميع أنواع البرامج، بما في ذلك أنظمة التشغيل والحاويات والمكتبات ومجموعات SDK.

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

نص عادي - يشير النص العادي، كمرادف للبيانات التي يتم فك تشفيرها، إلى الاسم الذي تم منحه للبيانات التي لم تتم حمايتها من خلال التشفير. المنصة كخدمة (PaaS) - نهج الحوسبة السحابية الذي يقوم من خلاله العميل بنشر تطبيق في منصة تُدار بواسطة موفر الخدمة السحابية. مقارنةً بحلول البنية التحتية كخدمة (IaaS)، تتميز المنصة كخدمة (PaaS) بأنها أكثر بساطة للعملاء على مستوى الإدارة حيث لا تتم إدارة الأصول المادية فقط (على سبيل المثال: الخوادم وأجهزة التخزين وأجهزة الشبكة) بواسطة مضيف الخدمة السحابية لكن أيضًا نظام التشغيل وحاوية التطبيق التي يتم تشغيل تطبيق العميل عليها. على سبيل المثال، هذه بعض منتجات "المنصة كخدمة" الشائعة: AWS Elastic Beanstalk وGoogle App Engine وForce.com.

منفذ - عندما يتصل البرنامج العميل بخادم عبر الإنترنت، يتضمن العنوان الوجهة جزأين: (1) عنوان بروتوكول الإنترنت (IP) للخادم و(2) رقم المنفذ على ذلك الخادم الذي سيستجيب له تطبيق معين. تستخدم البروتوكولات الشائعة منافذ محجوزة (على سبيل المثال، يستخدم HTTPS منفذ 443) ولكن يمكن للمطوّر استخدام منافذ مخصصة لاتصالات الشبكة إذا أراد ذلك.

ص

واجهة REST API - أسلوب معتمَد على نطاق واسع لبناء خدمات يمكن الوصول إليها عبر الويب حيث يتصل البرنامج العميل والخادم باستخدام بروتوكول HTTP. قد يستضيف المطوّر على منصة Meta واجهة REST API على نطاق فرعي مثل api.example.com الذي يقوم تطبيق الهواتف المحمولة الخاص به بإرسال واستقبال بيانات المنصة إليه/منه.

ض

بروتوكول النقل الآمن (SSH) - نظام اتصالات يسمح للمسؤولين بتسجيل الدخول عن بُعد إلى الخوادم وتشغيل البرامج على تلك الخوادم. وتتم الإشارة إليه على أنه آمن نظرًا لأن الاتصالات بين البرنامج العميل والخادم محمية ضد التنصت على عكس البروتوكولات السابقة مثل Telnet. ويُطلق عليه أيضًا اسم بروتوكول النقل الآمن عبر المنافذ.

بروتوكول طبقة المنافذ الآمنة (SSL) - إصدار قديم وغير آمن من التشفير أثناء الإرسال. يُطلق على الإصدار الآمن الحديث اسم بروتوكول طبقة المقابس الآمنة (TLS).

خادم - جهاز كمبيوتر يوفر خدمات عن بُعد عبر شبكة ما. تتصل المتصفحات وتطبيقات الهواتف المحمولة بالخوادم عبر الإنترنت.

الحوسبة عديمة الخادم - نمط من الحوسبة السحابية يدير فيها مضيف الخدمة السحابية البنية الأساسية المادية ونظام تشغيل الخادم والحاوية. ولا يكون المطوّر مسؤولاً إلا عن الرمز التعليمي المخصص والمكتبات المقترنة فقط مع تكوين الخدمة السحابية.

جانب الخادم - تتم الإشارة إلى البيانات أو العمليات الحسابية على الجانب الآخر من اتصال الشبكة (على سبيل المثال، على خادم) على أنها جانب الخادم. في المقابل، تتم الإشارة إلى البيانات أو العمليات الحسابية الموجودة على جهاز محلي مثل الكمبيوتر المحمول أو الجهاز المحمول على أنها جانب العميل.

تسجيل الدخول الموحد (SSO) - ترتيب تعتمد فيه التطبيقات على دليل مركزي للمستخدمين (أي، موفر بيانات مستخدمين) لمصادقة المستخدمين. وبالإضافة إلى إعداد مركزية حساب المستخدم وإدارة الوصول إلى التطبيق للمؤسسة، يستفيد المستخدمون من خلال امتلاك مجموعة واحدة من بيانات الاعتماد بدلاً من مطالبة المستخدمين بالاحتفاظ ببيانات اعتماد مختلفة (على سبيل المثال، اسم المستخدم وكلمة السر) لكل تطبيق مختلف.

مجموعة أدوات تطوير البرامج (SDK) - عنصر برمجي أساسي يمكن للمطوّر استخدامه لتبسيط عملية التطوير لغرض معين. على سبيل المثال، تقوم Meta بإنشاء وصيانة مجموعات SDK التي تبسط استخدام واجهة Graph API لمطوّري iOS وAndroid. وعلى غرار المكتبة، يحتاج المطوّرون الذين يستخدمون مجموعات SDK في تطبيقاتهم إلى تحديثها بمرور الوقت.

البرمجيات كخدمة (SaaS) - تتيح للعملاء استخدام التطبيقات السحابية عبر الإنترنت. وعلى عكس PaaS أو IaaS، لا ينشر عميل تطبيق SaaS رمزًا برمجيًا مخصصًا ولا يتحمل مسؤولية تكوين تطبيق SaaS أو ترقيته أو تصحيحه حيث تقع كل هذه الأمور على عاتق مورّد برامج SaaS. على سبيل المثال، هذه بعض منتجات "البرمجيات كخدمة" الشائعة: Dopbox وMailChip وSalesforce وSlack.

تحليل الرموز البرمجية - راجع اختبار أمان التطبيق الثابت

اختبار أمان التطبيق الثابت (SAST) - نهج للعثور على الثغرات الأمنية في البرامج عن طريق تشغيل أداة متخصصة لاختبار الرمز البرمجي المصدر. ستحدد أداة اختبار أمان التطبيق الثابت (SAST) الثغرات الأمنية المحتملة، مثل تلك المدرجة في مشروع OWASP Top 10، ومن ثم يكون المطوّر مسؤولاً عن مراجعة النتائج، وتمييز الإيجابيات الحقيقية عن الإيجابيات الزائفة، وإصلاح الثغرات الأمنية في البرامج. وقد تكون أداة اختبار أمان التطبيق الثابت (SAST) مفيدة لأنها يمكن أن تسمح للمطوّرين بالعثور على الثغرات الأمنية قبل نشرها في إصدار التشغيل، لكن على خلاف اختبار الاختراق، لن تتمكن أداة SAST من العثور على ثغرات أمنية فيما يتعلق بتكوين التشغيل على التطبيق.

ط

تشفير البيانات الشفاف - نوع من التشفير في حالة السكون ينطبق عادةً على تخزين قواعد البيانات (على سبيل المثال، محتويات قواعد البيانات نفسها وملفات السجل الخاصة بها). في هذا الترتيب، تدير برامج قواعد البيانات مفاتيح التشفير وتتعامل بشفافية مع عمليات التشفير (عند الكتابة) وعمليات فك التشفير (عند القراءة).

بروتوكول طبقة المقابس الآمنة (TLS) - نظام تشفير أثناء الإرسال يستخدم التشفير لحماية البيانات المرسلة عبر الشبكات من المتلصصين على طول مسار الشبكة. وهذا البروتوكول هو الإصدار الآمن الحديث من التقنية القديمة السابقة التي كان يُطلق عليها بروتوكول طبقة المنافذ الآمنة (SSL).

مصادقة ثنائية (2Fac) - مرادف للمصادقة متعددة العوامل. مخزن - نظام إدارة سري للبيانات الحساسة مثل مفاتيح التشفير ورموز الوصول وبيانات الاعتماد الأخرى. يسمح المخزن بالتحكم الصارم في تحديد مَن يمكنه الوصول إلى المفاتيح السرية التي عليها ويقدم خدمات إضافية مثل الاحتفاظ بسجلات التدقيق.

ظ

جهاز افتراضي(VM) - يشبه إلى حد بعيد حاوية التطبيق - يتم تشغيل الجهاز الافتراضي في مضيف يُسمى "مراقب الأجهزة الافتراضية" بينما يتم تشغيل حاوية التطبيق في محرك حاوية. ويتمثل الفرق الرئيسي في أن صورة الجهاز الافتراضي تحتوي على نظام تشغيل بينما لن تحتوي حاوية التطبيق على هذه الصورة. وتحتوي كل من الأجهزة الافتراضية وحاويات التطبيقات على تطبيق (تطبيقات) وتبعيات مثل المكتبات.

خدمة سحابية خاصة افتراضية (VPC) - مصطلح تستخدمه خدمات AWS للإشارة إلى مجموعة من موارد الخدمة السحابية التي تشبه شبكة تقليدية في مركز بيانات في عصر ما قبل الخدمات السحابية.

ثغرة أمنية - خلل في نظام أو تطبيق يمكن استغلاله، على سبيل المثال، لقراءة البيانات التي لا يحق للمحتال قراءتها

برنامج كشف الثغرات الأمنية (VDP) - نهج تطلب من خلاله المؤسسات تقارير عن الثغرات الأمنية من الباحثين (يُطلق عليهم أحيانًا اسم المخترقين الأخلاقيين) حيث يمكن اكتشاف الثغرات وإصلاحها قبل أن يتم استغلالها من جانب المحتالين الضارين. يتطلب برنامج كشف الثغرات الأمنية الفعّال مجموعة من الباحثين الذين يبحثون بنشاط عن الثغرات الأمنية، ومحللين داخل المؤسسة لمراجعة وترتيب عمليات الكشف الواردة، والمهندسين المطلعين على الأمن السيبراني القادرين على إنشاء ونشر إصلاحات للثغرات الأمنية.

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

ع

تطبيق ويب - تطبيقات الويب عبارة عن برامج تعمل داخل المتصفحات وتتألف من موارد مثل مستندات HTML ورموز JavaScript البرمجية ومقاطع الفيديو والوسائط الأخرى وCSS للتصميم. على عكس تطبيق الهواتف المحمولة الذي يقوم الشخص بتثبيته على هاتف محمول من متجر تطبيقات، يقوم الأشخاص ببساطة باستدعاء تطبيق ويب من خادم بعيد باستخدام متصفحهم (على سبيل المثال، www.facebook.com) دون الحاجة إلى خطوة التثبيت.