Zendesk جعلت بيانات الدعم القديمة اختبارًا للمساءلة في ثقة العملاء

ملخص

• يقول الأسئلة الشائعة المحدثة من Zendesk أنها تم تنبيهها في 2019 إلى مسألة أمنية تتعلق بحسابات عملاء الدعم والمحادثة التي تم تنشيطها قبل نوفمبر 2016، وأن معلومات حساب العميل تم الوصول إليها دون إذن قبل ذلك التاريخ.
• سؤال المساءلة المركزي هو: من كان لديه السيطرة العملية على الاحتفاظ بقاعدة بيانات الدعم، وتعرض بيانات الاعتماد والرمز، وتوقيت إشعار العميل، وتجزئة المستأجرين، وإعادة بناء التدقيق، وإثبات أن محتوى التذكرة كان محدودًا؟
• وأفادت التقارير العامة المبكرة أن المجموعة المتضررة تضم حوالي 10,000 حساب دعم ومحادثة؛ وتحدد الأسئلة الشائعة اللاحقة من Zendesk حوالي 15,000 حساب وتقول إن بعض معلومات المصادقة تم الوصول إليها لمجموعة تضم حوالي 7,000 حساب عميل.
• كان على العملاء الذين يستخدمون Zendesk للدعم والدردشة ومراكز المساعدة والتكاملات وعمليات العملاء تحديد ما إذا كانت بيانات الدعم الوصفية القديمة لا تزال قادرة على كشف الوكلاء أو المستخدمين النهائيين أو التكاملات أو الشهادات أو ثقة العميل في المراحل اللاحقة.
• يدعم السجل نتيجة مساءلة عالية الثقة حول الاحتفاظ والمصادقة والإشعار وحدود الأدلة. لا يدعم اختراع حقائق خاصة حول كل مستأجر أو كل تذكرة أو كل بيانات اعتماد تطبيق أو كل مفتاح TLS أو كل قرار عميل في المراحل اللاحقة.

سجل الأدلة وكيفية استخدامه

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

إطار المساءلة أضيق من اللوم وأوسع من قاعدة بيانات قديمة

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

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

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

كان لكل طرف دور، لكن Zendesk وحدها يمكنها جعل حدود الخرق مرئية من جانب الخدمة.

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

ما يثبته السجل العام

يثبت الأسئلة الشائعة المحدثة من Zendesk عدة نقاط ثابتة. قالت الشركة إنها تم تنبيهها من قبل طرف ثالث بخصوص مسألة أمنية قد تؤثر على منتجات الدعم والمحادثة وحسابات العملاء التي تم تنشيطها قبل نوفمبر 2016. وقالت إن فرق الأمن في Zendesk وخبراء الطب الشرعي الخارجيين قاموا بالتحقيق. وقالت إن معلومات تنتمي إلى نسبة صغيرة من العملاء تم الوصول إليها قبل نوفمبر 2016. يحدد الأسئلة الشائعة الحالي حوالي 15,000 حساب دعم ومحادثة، بما في ذلك حسابات التجربة المنتهية الصلاحية والحسابات غير النشطة، التي تم الوصول إلى معلومات حسابها دون إذن.

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

يضيف الأسئلة الشائعة أيضًا طبقة ثانية. قالت Zendesk إن بعض معلومات المصادقة تم الوصول إليها لحوالي 7,000 حساب عميل، بما في ذلك حسابات التجربة المنتهية الصلاحية والحسابات غير النشطة. أدرجت مفاتيح تشفير TLS التي قدمها العميل وإعدادات تكوين التطبيق من تطبيقات السوق أو التطبيقات الخاصة، والتي قد تتضمن مفاتيح التكامل التي تستخدمها هذه التطبيقات للمصادقة على خدمات الطرف الثالث. نصحت Zendesk عملاء معينين بتدوير بيانات اعتماد التطبيق واستبدال الشهادات التي تم تحميلها والتي لا تزال سارية المفعول، والنظر في تدوير مواد المصادقة الأخرى المستخدمة قبل نوفمبر 2016. وقالت أيضًا إنها لم تجد أي دليل على الوصول إلى بيانات التذكرة فيما يتعلق بهذه الحادثة.

التقارير الثانوية تلتقط الشكل العام الأولي للحادثة. أفادت CyberScoop وSecurityWeek وBleepingComputer في أكتوبر 2019 أن Zendesk كشفت عن خرق قديم يؤثر على حوالي 10,000 حساب. هذا الاختلاف في العدد ليس سببًا لاختيار سجل واحد والتخلص من الآخر. إنه سبب لقراءة الحادثة كمرحلة. انتقل الفهم العام من تأطير أولي لـ 10,000 حساب إلى أسئلة شائعة لاحقة مع تفاصيل إضافية عن الحسابات ومواد المصادقة.

عدم تطابق العدد العام هو في حد ذاته دليل مساءلة

يستخدم بيان هذه المقالة السجل العام الذي قالته Zendesk في 2019 بأنها حددت وصولًا غير مصرح به مرتبطًا بحوالي 10,000 حساب دعم ومحادثة من حادثة 2016. كان هذا هو التأطير العام المبكر. يقول الأسئلة الشائعة الحالي من Zendesk حوالي 15,000 حساب ويحدد أيضًا حوالي 7,000 حساب عميل مع بعض معلومات المصادقة ضمن النطاق. كلا الحقيقتين مهمتان. الرقم المبكر يظهر ما كان على العملاء والمراسلين التعامل معه أولاً. الرقم المحدث يظهر أن السجل العام أصبح لاحقًا أكثر تفصيلاً وأكثر تعقيدًا.

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

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

كان هدف الثقة هو علاقة الدعم

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

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

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

جعل الاحتفاظ القديم الحسابات القديمة قيد التشغيل حاليًا

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

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

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

تتطلب تجزئة كلمات المرور خطة عمل للعميل

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

تناولت خطة تدوير كلمة المرور من Zendesk فئة المخاطر هذه. يقول الأسئلة الشائعة إن التدوير طبق على وكلاء معينين ومستخدمين نهائيين تم إنشاؤهم قبل 1 نوفمبر 2016، حيث لم تستطع Zendesk تحديد أن المستخدم قد غير كلمة المرور منذ ذلك التاريخ وحيث لم يكن المستخدم يستخدم تسجيل الدخول الموحد. أثر التدوير أيضًا على المنتجات التي تشترك في المصادقة مع الدعم، بما في ذلك Guide وTalk وExplore. هذه تفاصيل مساءلة لأنها تخبر العملاء من كان عليه التصرف ولماذا.

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

جعلت مواد المصادقة القضية أكبر من إعادة تعيين كلمة المرور

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

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

نصحت Zendesk العملاء الذين قاموا بتثبيت تطبيقات السوق أو التطبيقات الخاصة قبل 1 نوفمبر 2016 وحفظوا بيانات اعتماد المصادقة أثناء التثبيت بتدوير بيانات الاعتماد للتطبيقات ذات الصلة. كما نصحت العملاء الذين قاموا بتحميل شهادة TLS لا تزال سارية المفعول قبل ذلك التاريخ باستبدالها وإلغاء الشهادة القديمة. كانت هذه التعليمات ملموسة، وهي تظهر لماذا لا يمكن إغلاق الحادثة بتدوير كلمة مرور الحساب وحدها.

حولت التطبيقات والتكاملات الدعم إلى نظام متصل

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

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

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

خلقت مواد شهادة TLS عبء إثبات منفصل

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

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

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

كان محتوى التذكرة هو الحدود التي يحتاجها العملاء أكثر من غيره

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

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

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

غيرت أدوار وحدة التحكم والمعالج عبء الإشعار

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

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

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

كان تجزئة المستأجرين طبقة ضمان غير مرئية

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

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

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

كانت إعادة بناء التدقيق جزءًا من التعافي، وليس عملًا خلفيًا

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

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

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

سجلات الثقة الحالية هي سياق مفيد، وليست دليلاً بأثر رجعي

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

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

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

ما لا يثبته السجل العام

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

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

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

سجل عام أقوى سيفصل كل سطح متأثر

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

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

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

يجب على المشترين السؤال عن بيانات الدعم القديمة قبل التجديد

لا ينبغي لعملاء ومشتري Zendesk انتظار حادثة للسؤال عن بيانات الدعم القديمة. يمكن لمنصة الدعم أن تتراكم بهدوء وكلاء ومستخدمين نهائيين وتذاكر وحقول مخصصة ووحدات ماكرو وتطبيقات وخطافات ويب وشهادات ورموز API وعملاء OAuth وسجلات تجربة. قد تكون بعض هذه البيانات مطلوبة للتدقيق أو خدمة العملاء أو الدفاع القانوني. قد يبقى بعضها ببساطة لأن الحذف صعب. لحظة التجديد هي عندما يكون لدى العملاء نفوذ لسؤال أيها أيها.

الأسئلة المفيدة عملية. كم من الوقت يتم الاحتفاظ بالحسابات غير النشطة؟ كيف تتم إزالة التجارب المنتهية الصلاحية أو إزالة تحديد هويتها؟ ماذا يحدث لسجلات الوكلاء والمستخدمين النهائيين القدامى؟ كيف تتم حماية مدققي كلمة المرور؟ كيف يمكن للعملاء سرد التطبيقات المثبتة وتواريخ تثبيتها؟ هل يمكن للمسؤولين مراجعة رموز OAuth ورموز API؟ كيف يتم تخزين مفاتيح TLS التي رفعها العميل وتقاعدها؟ كيف يتم تجزئة مخازن التذاكر عن بيانات تعريف الحساب؟ ما الأدلة التي سيشاركها المزود إذا تم اكتشاف حادثة قديمة؟

هذه الأسئلة ليست عدائية. تجعل كلا الجانبين أفضل أثناء الفشل. يعرف المزود أي الأدلة يجب الحفاظ عليها والكشف عنها. يعرف العميل أي الملاك المحليين يجب أن يتصرفوا. تظل حادثة Zendesk مفيدة لأنها تظهر كيف للسجلات القديمة أن تخلق عملًا جديدًا.

يجب على مجالس الإدارة معاملة أنظمة الدعم كبنية تحتية لثقة العملاء

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

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

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

يجب أن تتبع لغة العقد أسطح منصة الدعم

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

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

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

المؤشرات التشغيلية ستجعل الادعاءات المستقبلية قابلة للاختبار

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

لبيانات التذكرة، يمكنه ذكر أي المخازن تمت مراجعتها وما الأدلة التي تدعم الاستبعاد.

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

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

سؤال التكرار أوسع من Zendesk

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

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

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

الخلاصة للمساءلة

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

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

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

قرار القارئ

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

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