يمكن لأنظمة الموارد البشرية إرسال رسائل تبدو مثل البريد الداخلي ولكنها تنشأ من منصات التوظيف وموردي كشوف المرتبات وتطبيقات خدمة الموظفين. المهمة الأولى هي تحديد الحساب الفعلي للمؤسسة والمالك لكل مسار. لا تعد العلامة التجارية المميزة للمورد دليلاً على أن بريدًا إلكترونيًا معينًا أو إشعارًا لكشوف المرتبات قد تم اعتماده من قبل صاحب العمل.
تقسيم الملكية قبل تغيير السياسة
قم بتعيين إخطارات التوظيف إلى مالك عمليات التوظيف، وإشعارات كشوف المرتبات إلى مالك خدمة كشوف المرتبات وتحديثات الموظفين إلى مالك عمليات الأشخاص. سجل مستأجر البائع، الغرض، من الهوية، مجال المغلف، DKIM مجال التوقيع و محدد، توجيه الرد وجهة اتصال الدعم المعتمدة. إذا كان مقدم الخدمة يخدم العديد من الشركات التابعة، فسجل الكيان القانوني والمجال الذي من المفترض أن يستخدمه كل حساب بدلاً من التعامل مع المجموعة كمرسل واحد غير متمايز.
يجب أن يحتوي المخزون على بيانات وصفية تشغيلية، وليس السير الذاتية للمرشحين أو تفاصيل الرواتب أو معرفات الموظفين. قم بتخزين أي أدلة مقيدة ضرورية بموجب ضوابط الوصول والاحتفاظ المناسبة. تصحيح أخطاء المصادقة ليس إذنًا لنسخ بيانات الموظفين إلى تذكرة عامة لاستكشاف أخطاء البريد وإصلاحها.
افهم ماذا تعني النتيجة
RFC 9989 بتقييم استخدام المجال المصادق عليه. ولا يثبت أن العرض صالح، أو أن تعديل كشوف المرتبات صحيح، أو أن مسؤول التوظيف مرخص له بالالتزام. احتفظ بقرارات التوظيف وتغييرات التفاصيل المصرفية ضمن عمليات التحقق الخاصة بها. لا يزال بإمكان الحساب المعتمد الذي تم اختراقه إرسال محتوى مضلل ومصادق عليه.
استخدم نتائج ورؤوس نظام الاستلام الموثوق بها لمقارنة هوية "من" المرئية بالهوية المصادق عليها. لا تعتمد على لقطة شاشة تحتوي على شعار المورد أو رأس غير موثوق به يُدرجه المرسل. اطلب من المورد إجراء المجال المخصص الحالي الخاص بالحساب واحتفظ بأدلة التكوين دون الكشف عن بيانات الاعتماد.
تحقق من إشعار الموظف دون استعارة أدلة الرواتب
لنفترض أن إشعارات المرشحين وكشوف المرتبات تستخدم مجالات التوقيع المطابقة لمجالات "من" الخاصة بها، بينما يظهر employees.hr.example في "من" لإشعار الموظف و provider.example.net هو مجال DKIM d= الخاص به. حتى مع افتراض أن التوقيع تم التحقق منه، فإنه يفشل في DKIM الصارم تنسيق. هذه هويات افتراضية، وليست عينات موقعة أو فحوصات تشفير فعلية. لا يمكن لنتيجة كشف الرواتب إغلاق عدم تطابق منفصل لإشعار الموظف.
RFC 9989 الأقسام 4.4 و5.3.5 تتطلب النظر في المسارات المحاذاة الأخرى ذات الصلة لإكمالها DMARC نتيجة. ل p=reject النشر، يتطلب القسمان 7.4 و8 DKIM صالحًا بدلاً من SPF وحيد. بشكل منفصل، قد يصل رد المرشح إلى قائمة انتظار التوظيف الخاطئة على الرغم من مرور رسالة صادرة. تحقق من وجهة الرد المعتمدة باستخدام السجلات الوهمية والحسابات الخاضعة للرقابة، وليس المتقدمين الحقيقيين أو تفاصيل الموظفين.
اختبار الرحلات الفعلية للموظفين والمرشحين
استخدم حسابًا خياليًا لمقدم الطلب وموظفًا معتمدًا في بيئة اختبار مدعومة. قم بتشغيل إقرار التطبيق، وإشعار كشوف المرتبات غير الضار، وتحديث الموظف من خلال سير عمل التطبيق الحقيقي. تأكيد الاستلام والمصادقة وتوجيه الرد. تأكد من وصول استجابة المرشح إلى قائمة انتظار التوظيف المتوقعة دون الكشف عن تفاصيل مقدم الطلب الآخر. تعامل مع الوصول إلى المستندات وصحة المحتوى كمعايير قبول منفصلة.
إذا كان المورد يقدم هويته الخاصة فقط، فيجب على مالك الأعمال أن يقرر ما إذا كان العنوان المدعوم المقدم بوضوح يلبي احتياجات سير العمل. لا تقم بتزوير هوية صاحب العمل من خلال تكوين غير مدعوم أو إضافة قواعد تجاوز واسعة النطاق فقط لجعل الاختبار يبدو ناجحًا. أعد اختبار التغييرات المدعومة وقم بتوثيق أي قيود متبقية.
حافظ على اتصال offboarding بحوكمة المرسل
قم بمراجعة التفويضات عند انتهاء عقد الوكالة، أو تغيير مزود كشوف المرتبات، أو مغادرة مسؤول الموارد البشرية. قم بتأكيد سير العمل اللاحق قبل سحب المفاتيح أو تبعيات DNS . احتفظ بمالك استرداد محدد للمرشح الحساس للوقت ورسائل كشوف المرتبات. تحديد المسار المقبول فقط عندما يوافق مالك الخدمة على دليل الاختبار الحالي؛ لا يعد سجل DNS ولا تصريح المصادقة بمثابة شهادة توظيف أو خصوصية أو امتثال تنظيمي.