‏تطوير تطبيق Meta‏
عودة إلى اللغة ‏العربية‏
تم تحديث هذا المستند.
لم تكتمل الترجمة إلى اللغة ‏العربية‏ حتى الآن.
تاريخ تحديث المصدر باللغة الإنجليزية: ‏٣٠ أبريل‏

الأسئلة المتكررة حول تقييم حماية البيانات

ما المقصود بتقييم حماية البيانات

  1. ما المقصود بتقييم حماية البيانات؟

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

  2. ما المقصود ببيانات المنصة؟

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

  3. كيف يختلف ذلك عن مراجعة التطبيقات وفحص استخدام البيانات؟

    1. مراجعة التطبيقات هي عملية مسبقة تتيح لك طلب الموافقة على الأذونات والميزات الفردية.
    2. فحص استخدام البيانات هي عملية سنوية يتم من خلالها اعتماد المطوِّرين ذاتيًا لإثبات امتثال استخدامهم ووصولهم المستمر إلى بيانات معينة من خلال واجهات Meta API لشروط المنصة وسياسات المطوِّرين.
    3. تقييم حماية البيانات هو استبيان سنوي يطرح أسئلة على المطوِّرين بشأن استخدامهم للبيانات ومشاركتها وأمانها وذلك فيما يتعلق ببيانات المنصة.

  4. ما الذي يمكنني تنفيذه استعدادًا لتقييم حماية البيانات؟

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

لماذا يعتبر تقييم حماية البيانات ضروريًا

  1. لماذا يلزمني إكمال تقييم حماية البيانات؟

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

العملية

  1. كيف أعلم ما إذا كان يلزمني إكمال تقييم حماية البيانات؟

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

  2. كيف أتأكد من أنني أتلقى مراسلات البريد الإلكتروني المتعلقة بتقييم حماية البيانات؟

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

  3. كيف أعرف أنه يمكنني بدء تقييم حماية البيانات؟

    1. إذا كنت مسؤولاً بأحد التطبيقات التي تتطلب تقييم حماية البيانات، فسيتم إرسال إشعار لك بالطرق التالية:
      1. الإشعارات:
        1. إرسال رسالة بريد إلكتروني إلى عنوان البريد الإلكتروني المخصص للتواصل مع المطوّر أو الشركة. يمكنك تعديل إعدادات الإشعارات الشخصية الخاصة بك كمطوّر من هنا.
        2. إرسال رسالة إلى البريد الوارد للتنبيهات في لوحة معلومات التطبيق.
        3. إرسال إشعار إلى مسؤول التطبيق من خلال لوحة معلومات التطبيق.
      2. الإجراءات المطلوبة:
        1. في صفحة تطبيقاتي، سترى عبارة "الإجراء مطلوب" في بطاقة معلومات التطبيق بعنوان "تقييم حماية البيانات".
        2. في لوحة معلومات التطبيق، سترى عبارة "الإجراء مطلوب" في الجزء العلوي.
        3. في صفحة الإعدادات الأساسية للتطبيق، سترى سطرًا بعنوان "تقييم حماية البيانات".

  4. هل يمكنني طرح أسئلة عن الموضوعات الواردة في تقييم حماية البيانات؟

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

الإرسال

  1. كم المدة التي يلزمني خلالها إرسال تقييم حماية البيانات؟

    1. لديك 60 يومًا تقويميًا لإكمال تقييم حماية البيانات بدءًا من أول إشعار تلقيته.

  2. كم مرة يلزمني فيها إرسال تقييم حماية البيانات؟

    1. يجب إكمال هذا التقييم سنويًا.

  3. الاستبيان طويل للغاية، هل يمكنني حفظه وإكماله عبر عدة جلسات؟

    1. نعم. يتم حفظ النموذج تلقائيًا حتى تتمكن من المتابعة من حيث توقفت.

  4. كيف سأعرف حالة إرسال التقييم؟

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

  5. لقد أرسلت تقييم حماية البيانات العام الماضي، أين يمكنني تنزيل إجاباتي؟

    1. للأسف، لن تتمكن من تنزيل إجاباتك عن التقييم السابق، لأننا غيرنا الاستبيان لإضفاء مزيد من الوضوح. بعد إرسال إجاباتك عن أسئلة هذا التقييم، ستتمكن من عرض وتنزيل إجاباتك في صورة ملف بتنسيق PDF.

المراجعة

  1. هل سيتواصل معي مراجعو Meta لطرح مزيد من الأسئلة قبل اتخاذ أي قرار؟

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

  2. لقد تلقيت رسالة بريد إلكتروني تقول إن Meta بحاجة إلى مزيد من المعلومات. لماذا؟

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

  3. كيف أرد على أسئلة مراجعي Meta؟

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

  4. كم المدة المتاحة لي للرد على أسئلة مراجعي Meta؟

    1. إذا تلقيت طلب "مطلوب المزيد من المعلومات"، سيكون أمامك 5 أيام عمل للرد. إذا لم ترد في غضون مدة الخمسة أيام الأولى، فسيتم تمديد المدة تلقائيًا مرتين بإجمالي 15 يوم عمل.

الرد على الانتهاكات

  1. هل سيتم تقييد تطبيقي بسبب انتهاكات شروط المنصة؟

    1. نعم. تبعًا للانتهاك، قد يتم فرض قيود مختلفة ضد التطبيق.

  2. هل سيتواصل معي مراجعو Meta في حالة العثور على انتهاك؟

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

  3. ماذا يحدث إذا لم أرد؟

    1. عدم الرد يعتبر انتهاكًا لأحد شروط المنصة.
      1. بعد 60 يومًا من عدم الرد، سيتم إلغاء تنشيط تطبيقك.
        1. يمكنك استعادة التطبيق بإكمال التقييم وإرساله.
        2. إذا تلقيت طلب "مطلوب المزيد من المعلومات"، سيكون أمامك 5 أيام عمل للرد. إذا لم ترد في غضون مدة الخمسة أيام الأولى، فسيتم تمديد المدة تلقائيًا مرتين بإجمالي 15 يوم عمل. بعد مرور 15 يوم عمل، سيتم إنفاذ المعايير على تطبيقك.
        3. إذا تجاوزت هذه الجداول الزمنية فقد يتم تقييد التطبيق. يمكنك الانتقال إلى صفحة تطبيقاتي لعرض أي تطبيقات مقيدة نتيجة للانتهاكات.
          1. تبعًا لخطورة الانتهاك، قد تكون هناك فرصة لحل الانتهاك قبل تقييد التطبيق. مع هذا، لا تتضمن أشد الانتهاكات خطورة فترة تحذير. لحل انتهاك، ابحث في صفحة تطبيقاتي عن الرابط "حل"، واتبع الخطوات الموضحة.

  4. كيف أطلب تمديدًا للرد على الانتهاك؟

    1. بالنسبة لكل انتهاك، إذا كان الموعد النهائي للرد يقع في غضون 3 أيام، فسيظهر الزر "طلب تمديد". يمكنك طلب التمديد مرتين بما يعادل طول فترة التحذير (والتي تتباين تبعًا للانتهاك) وهو ما ستتم الموافقة عليه تلقائيًا.

  5. كيف يمكنني حل انتهاك تم اكتشافه من خلال تقييم حماية البيانات؟

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

شروط المنصة 3 (استخدام البيانات)

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

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

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

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

  3. ما الذي يحدث إذا لم يكن تطبيقي يحذف بيانات المنصة في بعض أو كل السيناريوهات التي تتطلبها Meta لأننا لا نستطيع حذف البيانات تلقائيًا؟

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

  4. تنص شروط Meta على أن أحذف بيانات المنصة الخاصة بالمستخدم عندما يحذف المستخدم حسابه في تطبيقي. ومع هذا، لا يمكنني القيام بذلك لأن تطبيقي يفتقد إلى وظيفة الاستدعاء الضرورية لمعرفة متى حذف المستخدم حسابه على فيسبوك. هل يعني ذلك أن تطبيقي ينتهك شروط Meta؟

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

شروط المنصة 4 (سياسة الخصوصية)

  1. تحتوي سياسة الخصوصية لتطبيقي على عبارة تخبر المستخدمين بأنه يمكنهم طلب حذف بياناتهم. هل يكفي ذلك؟

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

شروط المنصة 5 (موفرو الخدمات وموفرو الخدمات التقنية)

  1. ما المقصود بموفر الخدمة؟

    1. "موفر الخدمة" هو كيان تستعين به ليوفر لك خدمات تتعلق بالمنصة أو أي من بيانات المنصة. يعتبر كل من Google Cloud وAmazon Web Services (AWS) أمثلة لموفري الخدمات الكبار والشائعين.

  2. ما المقصود بموفر الخدمة الفرعي؟

    1. موفر الخدمة الفرعي هو موفر خدمة يستعين به موفر خدمة آخر لتوفير خدمات على نحو يرتبط بالمنصة أو أي من بيانات المنصة.

  3. ما المقصود بموفر الخدمات التقنية؟

    1. موفر الخدمات التقنية هو مطوّر لتطبيق غرضه الأساسي تمكين مستخدميه من الوصول إلى المنصة أو بيانات المنصة واستخدامها. "عادة ما يتمثل الغرض الأساسي لموفر الخدمات التقنية في تمكين مستخدميه من الوصول إلى أو استخدام Meta للمطوّرين أو بيانات المنصة.

  4. ما الذي يمكن اعتباره اتفاقية مكتوبة لأغراض "أخرى"، كما هو موضح في السؤال 4؟

    1. تتضمن أمثلة الاتفاقيات المكتوبة شروط الخدمة، أو الاتفاقيات القياسية غير المتفاوض عليها، أو العقود الموقعة.

شروط المنصة 6 (أمان البيانات)

  1. ما الذي أحتاج إلى القيام به لإثبات الامتثال لقسم 6.أ.1 حول أمان البيانات في شروط المنصة من Meta؟

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

  2. هل يتعين علي الحصول على شهادة إطار عمل أمن المعلومات (ISF) أو إطار عمل الأمن السيبراني (CSF) من جهة تدقيق خارجي؟

    1. لا، لست مطالبًا بالحصول على شهادة المدقق. يمكن للمؤسسات الحاصلة على شهادات SOC 2 أو ISO 27001 أو ISO 27018 أو PCI DSS تقديم أي منها كإثبات.
      1. يجب أن تكون الشهادة مرتبطة ببيئة الحوسبة التي يتم بداخلها تخزين بيانات المنصة أو معالجتها.
    2. يرجى العلم بأننا سنسأل عن وسائل الحماية التي تنفذها تحديدًا بغض النظر عما إذا كنت قد قدمت شهادة أمان أم لا.

  3. إذا لم أُرسل شهادة أمان، فما الأسئلة التي سيتعين علي الإجابة عنها حول إجراءات حماية أمان البيانات من جانبي؟

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

  4. يُطلب مني تحديد ما إذا كانت مؤسستي تُنفِّذ التشفير في حالة السكون لكل مساحات تخزين بيانات المنصة. ما النطاق الذي ينطبق عليه هذا السؤال؟ هل ينطبق على كل من مساحة تخزين العميل ومساحة التخزين السحابية؟

    1. التشفير في حالة السكون يحمي بيانات المنصة من خلال جعل البيانات غير قابلة لفك التشفير دون مفتاح فك تشفير منفصل. يوفر ذلك طبقة إضافية من الحماية ضد الوصول غير المُصرح به للقراءة.
    2. على الخوادم أو في بيئة سحابية، حيث تكون بيانات المنصة المرتبطة بكل مستخدمي التطبيق مركزة، يقلل التشفير في حالة السكون مخاطر اختراق البيانات. على سبيل المثال، يحمي التشفير في حالة السكون من تهديدات مثل الوصول غير المُصرح به للنسخة الاحتياطية من قاعدة البيانات، والتي قد لا تتم حمايتها بنفس قدر حماية قاعدة البيانات الأصلية ذاتها.
    3. إذا لم تكن مؤسستك تخزن بيانات المنصة سحابيًا، يجب عليك حماية هذه البيانات من خلال التشفير في حالة السكون، أو باستخدام عناصر تحكم تعويضية مناسبة. ويعد استخدام أي من التشفير على مستوى التطبيق (على سبيل المثال، قيام البرنامج بتشفير/فك تشفير أعمدة معينة في قاعدة البيانات) أو تشفير القرص بالكامل مقبولاً. في حين أننا نوصي باستخدام التشفير القياسي المتبع في المجال (على سبيل المثال، AES أو BitLocker أو Blowfish أو TDES أو RSA)، فإننا لا نفرض خوارزمية معينة أو طول معين لمفتاح التشفير.
    4. إذا لم تكن مؤسستك تخزن بيانات المنصة سحابيًا، فلن يكون هذا المتطلب ساريًا.
    5. لتجنب الشك، لا تقع ضمن نطاق هذا السؤال أي بيانات يتم الاحتفاظ بها في برامج الويب أو برامج الهواتف المحمولة للمستخدمين الفرديين لخدماتك.
    6. إذا كانت مؤسستك تخزن بيانات المنصة من خلال منتج laaS سحابي (على سبيل المثال AWS EC2، وMicrosoft Azure IaaS وGoogle Compute Engine)، أو تستخدم استضافة ذاتية أو إذا كنت تستخدم أسلوبًا هجينًا، فلن يسري عليك هذا السؤال.
    7. مع هذا، هناك نماذج استضافة خلفية أخرى تمثل حالات خاصة: استخدام منتجات SaaS - إذا كانت مؤسستك تخزن بيانات المنصة من خلال منتج SaaS (على سبيل المثال، MailChimp أو Salesforce)، فإن هذا السؤال لا ينطبق عليك. وينبغي عليك بدلاً من ذلك وصف هذه العلاقة في قسم موفر الخدمة في تقييم حماية البيانات. استخدام استضافة PaaS - إذا كانت مؤسستك تخزن بيانات المنصة من خلال منتج PaaS (على سبيل المثال، AWS Elastic Beanstalk أو Google App Engine أو Force.com)، فإن هذا السؤال لا ينطبق عليك. وينبغي عليك بدلاً من ذلك وصف هذه العلاقة في قسم موفر الخدمة في تقييم حماية البيانات. استخدام استضافة BaaS - إذا كانت مؤسستك تخزن بيانات المنصة من خلال منتج BaaS (على سبيل المثال، AWS Amplify أو Azure Mobile Apps أو Azure Playfab أو Google Firebaseأو MongoDB Switch)، فإن هذا السؤال لا ينطبق عليك. وينبغي عليك بدلاً من ذلك وصف هذه العلاقة في قسم موفر الخدمة في تقييم حماية البيانات (DPA).

  5. يتم سؤالي عن كيفية منع تخزين بيانات المنصة على أجهزة تابعة للمؤسسة أو أجهزة شخصية. ما نوع تدابير المنع المقبولة؟

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

  6. يُطلب مني تحديد ما إذا كانت مؤسستي تمكِّن TLS 1.2 أو إصدار أحدث لجميع اتصالات الشبكة التي تُرسَل خلالها بيانات المنصة. ما النطاق الذي ينطبق عليه هذا السؤال؟

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

      إلى ومن أجهزة المستخدم النهائي (الهواتف المحمولة وأجهزة الكمبيوتر والأجهزة اللوحية وغير ذلك) وخادمك أو البنية الأساسية للتخزين السحابي

      يجب تمكين تشفير TLS بالإصدار 1.2 أو إصدار أحدث للأجهزة المتوافقة

      يجوز تمكين تشفير TLS بالإصدار 1.0 و1.1 من أجل التوافق مع الأجهزة الأقدم

      إلى ومن الخادم أو البنية الأساسية للتخزين السحابي وأي خادم بعيد أو بنية أساسية للتخزين السحابي أو خدمة التابعة لجهة خارجية

      يجب تنفيذ التشفير TLS بالإصدار 1.2 أو إصدار أعلى

      إلى ومن المكونات الموجودة بالكامل ضمن مركز البيانات أو الخادم أو البنية الأساسية للتخزين السحابي لديك

      نوصي باستخدام تشفير TLS ولكنه ليس مطلوبًا لعمليات نقل بيانات المنصة التي تتم بالكامل ضمن شبكة سحابية خاصة

      إلى ومن فيسبوك وأي جهاز أو خادم أو بنية أساسية للتخزين السحابي

      خارج نطاق تقييم حماية البيانات - يتحكم فيسبوك في سياسة TLS لعمليات النقل هذه

      استشر رئيس قسم حماية البيانات (CISO) أو ما يعادله في مؤسستك، أو شركة أمن سيبراني مؤهلة، لإرشادك بشأن التشفير المناسب وعناصر التحكم التعويضية الأخرى للتطبيق.

  7. يُطلب مني تحديد ما إذا كانت مؤسستي تختبر التطبيق والأنظمة لدينا بحثًا عن الثغرات الأمنية ومشاكل الأمان كل 12 شهرًا على الأقل. ما أنواع الاختبارات المقبولة؟

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

  8. يُطلب مني تحديد ما إذا كانت مؤسستي تحمي البيانات الحساسة، مثل بيانات الاعتماد ورموز الوصول. ما النطاق الذي ينطبق عليه هذا السؤال؟

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

  9. يُطلب مني تحديد ما إذا كانت مؤسستي تختبر أنظمة وعمليات الاستجابة لحوادث الأمان كل 12 شهرًا على الأقل. ما النطاق الذي ينطبق عليه هذا السؤال؟

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

  10. يُطلَب مني تحديد ما إذا كانت مؤسستي تتطلب المصادقة متعددة العوامل للوصول عن بُعد. ما النطاق الذي ينطبق عليه هذا السؤال؟

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

  11. يُطلب مني تحديد ما إذا كانت مؤسستي لديها نظام لصيانة الحسابات (تعيين الوصول والامتيازات وإلغاؤها ومراجعتها). ما النطاق الذي ينطبق عليه هذا السؤال؟

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

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

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

  13. ما الذي يتعين علي فعله إذا لم يكن لدي عنصرًا أو أكثر من عناصر التحكم في الأمان المعمول بها ولكني قمت بتطبيق عناصر تعويضية للتحكم في الأمان؟

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

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

    1. على الرغم من أن سياساتنا لا تفرض وجود قناة منفصلة للإبلاغ عن الثغرات الأمنية (وستكون أي معلومات اتصال يتم متابعتها بانتظام، مثل البريد الإلكتروني أو نموذج الاتصال أو الهاتف، متوافقة مع متطلباتنا) فإننا نوصي بأن يتبع المطوِّرون برنامجًا منظمًا لهذا الغرض، على سبيل المثال من خلال إدارة برنامج للإفصاح عن الثغرات (VDP) على BugCrowd أو HackerOne.

  15. أرى إشارة إلى رقم سؤال في المراسلات التي تلقيتها من فريق مراجعة تقييم حماية البيانات. إلى ماذا تشير هذه الأرقام؟

    1. قد ترى إشارة إلى رقم سؤال في المراسلات التي تتلقاها من فريق المراجعة لدينا. الاستخدام الأساسي لهذه الأرقام هو لعمليات المراجعة الداخلية، لكن للعلم هذا هو المرجع:
      1. س9 - التشفير في حالة السكون في بيئة سحابة أو خادم.
      2. س10 - حماية بيانات المنصة على الأجهزة التنظيمية أو الشخصية.
      3. س11 - حماية بيانات المنصة باستخدام التشفير عند الانتقال.
      4. س12 - اختبار الثغرات الأمنية في التطبيق والأنظمة.
      5. س13 - حماية المفتاح السري لتطبيق Meta ورموز الوصول.
      6. س14 - وضع خطة للاستجابة للحوادث واختبار أنظمة وعمليات الاستجابة للحوادث.
      7. س15 - اشتراط المصادقة متعددة العوامل للوصول عن بُعد.
      8. س16 - تنفيذ نظام للحفاظ على حسابات المستخدمين.
      9. س17 - التحديث المستمر للبرامج.

  16. تلقيت ملاحظات من فريق مراجعة تقييم حماية البيانات حول فقدان أو عدم كفاية أدلة السياسات أو الإجراءات. ما هو دليل السياسة أو الإجراءات؟

    1. قد تتلقى سؤال متابعة حول دليل السياسة أو الإجراء المتعلق بسؤال أو أكثر من أسئلة أمان البيانات، والتي قد تتم الإشارة إليها بأحد الأرقام التالية من فريق المراجعة لدى Meta: س9، س10، س11، س12، س13، س14، س15، س16، س17.

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

  17. تلقيت ملاحظات من فريق مراجعة تقييم حماية البيانات حول فقدان إثبات التنفيذ أو عدم كفايتها. ما هو إثبات التنفيذ؟

    1. قد تحصل على سؤال متابعة حول إثبات التنفيذ المتعلق بسؤال أو أكثر من أسئلة أمن البيانات. يُشار إلى أسئلة أمن البيانات في بعض الأحيان برقم: س9، س10، س11، س12، س13، س14، س15، س16، س17.

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

      لمزيد من المعلومات، راجع وثائق المطوِّرين لدينا حول إعداد إثبات لكل حماية:
      1. التشفير في حالة السكون في بيئة سحابة أو خادم.
      2. حماية بيانات المنصة على الأجهزة المؤسسية أو الشخصية.
      3. حماية بيانات المنصة باستخدام التشفير عند الانتقال.
      4. اختبار التطبيق والأنظمة للكشف عن الثغرات الأمنية.
      5. حماية المفتاح السري لتطبيق Meta ورموز الوصول
      6. وضع خطة للاستجابة للحوادث واختبار أنظمة وعمليات الاستجابة للحوادث.
      7. اشتراط المصادقة متعددة العوامل للوصول عن بُعد.
      8. تنفيذ نظام للحفاظ على حسابات المستخدمين.
      9. التحديث المستمر للبرامج.

  18. يتم سؤالي عن كيفية حماية بيانات المنصة على الأجهزة المؤسسية والشخصية. ما متطلبات Meta؟

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

      تتطلب Meta توضيح أحد الأمور التالية على الأقل:
      1. تتخذ مؤسستك خطوات لمنع الوصول إلى الأنظمة التي تحتوي على بيانات منصة Meta باستثناء الأجهزة التي تحتوي على أحد الأمرين التاليين أو كليهما:
        1. يجب تمكين تشفير القرص بالكامل لجميع الأجهزة، على سبيل المثال عن طريق FileVault أو BitLocker.
        2. يجب أن يكون على جميع الأجهزة برنامج نقطة نهاية لمنع فقدان البيانات ومُشغَّل، على سبيل المثال: Microsoft Intune أو Symantec DLP.
      2. تمتلك مؤسستك سياسة تمنع أي شخص في المؤسسة من تخزين بيانات منصة Meta على أي جهاز تابع للمؤسسة أو شخصي ولديك إثبات مكتوب يفيد بأن الأشخاص في مؤسستك ملزمون باتباع هذه السياسة.
      3. لدى مؤسستك سياسة تنص على ما يلي:
        1. يجوز لهؤلاء الذين يحتاجون إلى الوصول فقط ولديهم غرض تجاري معتمد معالجة بيانات المنصة على أجهزة المنظمة
        2. يجب على الأفراد حذف بيانات المنصة من هذه الأجهزة عندما يزول الغرض التجاري المعتمد.
      4. لا يمكن لأي شخص في مؤسستك الوصول إلى بيانات منصة Meta مُطلقًا بسبب طريقة إنشاء برنامجك (على سبيل المثال: يتم تخزين بيانات منصة Meta في ذاكرة مؤقتة فقط في أجهزة العميل النهائي)

  19. ما المقصود بالمفتاح السري لتطبيق فيسبوك أو Meta؟

    1. قد تتلقى سؤال متابعة حول كيفية حماية المفتاح السري لتطبيق فيسبوك أو Meta. قد يُشار إلى هذا السؤال أيضًا برقم، س13.

      المفتاح السري للتطبيق هو معلمة مرتبطة بتطبيقات فيسبوك يمكن استخدامها كرمز وصول في بعض استدعاءات واجهة API لتغيير تكوين تطبيقك، على سبيل المثال: تكوين عمليات إعادة الاستدعاء لـ Webhook. يمكنك العثور على المفتاح السري لتطبيق فيسبوك لديك في لوحة معلومات المطوِّرين ضمن الإعدادات > الأساسيات. لمزيد من المعلومات حول المفتاح السري للتطبيق، ارجع إلى وثائق المطوِّرين لدينا حول أمان تسجيل الدخول.

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

  20. يتم سؤالي عن كيفية إدارة الحسابات والحفاظ عليها. ما متطلبات Meta؟

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

  21. يتم سؤالي عن كيفية اختبار نظامي/برمجياتي للتعرف على الثغرات. ما متطلبات Meta؟

    1. قد تتلقى سؤال متابعة حول ما إذا كانت مؤسستك تختبر نظامك/برمجياتك للكشف عن الثغرات. قد تتم الإشارة إلى هذا السؤال أيضًا برقم، س12.

      إذا كانت مؤسستك تعالج بيانات منصة Meta في بيئة سحابية (على سبيل المثال: داخل AWS، Azure، GCP، Alibaba Cloud، Tencent Cloud):
      1. يجب أن تكون قد اختبرت برمجياتك السحابية للكشف عن أي ثغرات أمنية عبر:
        1. اختبار اختراق أو مسح خارجي للتطبيق أو النظام؛ أو
        2. أداة أمنية للتحليل الثابت أو الديناميكي للبرمجيات؛ أو
        3. قم بتشغيل برنامج الكشف عن الثغرات الذي يفي بمتطلباتنا
      2. كما يجب أن تكون قد اختبرت تكوين الأصول السحابية للكشف عن أي ثغرات عبر:
        1. أداة مُقدمة من مضيف السحابة؛ أو
        2. أداة أخرى تجارية أو مفتوحة المصدر؛ أو
        3. قم بتشغيل برنامج الكشف عن الثغرات الذي يفي بمتطلباتنا
        4. إذا كانت مراجعة تكوين السحابية غير منطبقة على مؤسستك، يجب أن توضح أسباب ذلك كجزء من أدلتك المثبتة
      3. يجب أن توضِح أن النشاطين المُشار إليهما أعلاه قد حدثا خلال الأشهر الـ 12 الماضية.
      تتطلب Meta بشكل عام حل جميع الثغرات الحرجة أو العالية الخطورة.

      إذا كانت مؤسستك تعالج بيانات منصة Meta في بيئة خادم يتم استضافتها بطريقة مختلفة:
      1. يجب أن تكون قد اختبرت برامج خادمك للكشف عن أي ثغرات أمنية عبر:
        1. اختبار اختراق أو مسح خارجي للتطبيق أو النظام؛ أو
        2. أداة أمنية للتحليل الثابت أو الديناميكي للبرمجيات؛ أو
        3. قم بتشغيل برنامج الكشف عن الثغرات الذي يفي بمتطلباتنا
    تتطلب Meta بشكل عام حل جميع الثغرات الحرجة أو العالية الخطورة.

    بالنسبة لجميع المنظمات الأخرى:
    1. يجب أن تكون قد اختبرت برامج عميلك للكشف عن أي ثغرات أمنية عبر:
      1. اختبار اختراق أو مسح خارجي؛ أو
      2. أداة أمنية للتحليل الثابت أو الديناميكي؛ أو
      3. قم بتشغيل برنامج الكشف عن الثغرات الذي يفي بمتطلباتنا
    2. يجب أن توضِح أن هذا النشاط قد حدث خلال الأشهر الـ 12 الماضية
    تتطلب Meta بشكل عام حل جميع الثغرات الحرجة أو العالية الخطورة.

    لمزيد من المعلومات، بما في ذلك ما يتعلق بأي إثبات قد يكون مطلوبًا منك تقديمه، راجع وثائق المطوِّرين لدينا - اختبر التطبيق والأنظمة للكشف عن الثغرات والمشكلات الأمنية.


  22. يتم سؤالي عن كيفية الحفاظ على تحديث أنظمتي. ما متطلبات Meta؟

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

      لمزيد من المعلومات، راجع وثائق المطوِّرين - الحفاظ على تحديث البرامج.

يرجى العلم أن هذه الأسئلة المتكررة تهدف إلى توفير معلومات وروابط مفيدة لمساعدتك في الامتثال لتقييم حماية البيانات، ومع ذلك فإن متطلبات أمن البيانات تحكم تقييمنا لتقييم حماية البيانات. الأسئلة المتكررة ليست سوى دليل ويجب ألا تُقرأ على أنها تناقض المتطلبات أو تلغيها.

معرفة المزيد