قم بإعداد الدوران قبل لمس أي من المفتاحين
A DKIM التناوب هو تغيير منسق للموقع، أ محدد ويكتشف مستلمو مواد التحقق العامة. لا يؤدي إنشاء مفتاح جديد أو نسخ سجل DNS إلى إكماله. يجب أن يحدد الإعداد من يحمل المفتاح الخاص، وكيف تغير الخدمة سلوك التوقيع، وما هي الرسائل التي قد لا تزال تتطلب المفتاح العام السابق وكيف سيستجيب الفريق في حالة فشل التحقق.
سير العمل أدناه مقترح ومحايد للمنتج. ولا يتحقق من مخزن مفتاح EmailAuth أو محرك التدوير أو تكامل الموفر أو ميزة الموافقة. لم يتم إنشاء أي مفتاح أو استيراده أو تصديره أو إبطاله أو نشره، ولم يتم فحص أي موقع أو إعداد DNS . يجب أن يظل إعداد الخطة منفصلاً عن تلك الإجراءات الأمنية الحساسة.
بناء مخزون محدد وحضانة
بالنسبة لكل تدفق إرسال داخل النطاق، قم بتسجيل مجال التوقيع والمحدد الحالي والخوارزمية وبصمة المفتاح العام ومثيل الخدمة المسؤولة. تحديد هوية حارس المفتاح الخاص دون نسخ المواد الخاصة إلى المخزون. لاحظ ما إذا كان الموفر المُدار يقوم بإنشاء المفتاح والاحتفاظ به أو ما إذا كان الموقّع الذي تتحكم فيه المؤسسة يقوم بذلك. إن ملكية DNS ليست مثل ملكية مفتاح التوقيع.
يحدد المحدد مفتاح التحقق في سياق مجال التوقيع. تتيح المحددات المختلفة تواجد مفاتيح مميزة معًا، وهو ما يدعم الانتقال المرحلي حيثما يسمح التنفيذ بذلك. تجنب الكتابة فوق محدد موجود لمجرد أن أحد الأمثلة القصيرة يطلق عليه "الافتراضي". قد تظل هناك حاجة للمحدد القديم للرسائل الموقعة بالفعل بمفتاحه. RFC 6376 ، الأقسام 3.1 و3.6.
تطبيق متطلبات التشفير الحالية بشكل صريح
يقوم RFC 8301 بتحديث قواعد خوارزمية DKIM الأقدم: rsa-sha1 غير مقبول للتوقيع أو التحقق؛ يجب على موقعي RSA استخدام مفاتيح لا تقل عن 1024 بت ويجب أن يستخدموا 2048 بت على الأقل. قم بتسجيل الخوارزمية والحجم المختارين بدلاً من وصف مفتاح غير محدد بأنه "آمن". قد تكون متطلبات المزود والمتطلبات التنظيمية الحالية أكثر صرامة. RFC 8301 ، الأقسام 3.1 و3.2.
يضيف RFC 8463 Ed25519-SHA256 ويصف استخدام محددات منفصلة عند التوقيع باستخدام الخوارزميات القديمة والجديدة. لا تثبت متطلبات التحقق الخاصة بها أن كل جهاز استقبال منشور أو خدمة إرسال مُدارة يدعم التكوين المقصود اليوم. يحتاج أي انتقال للخوارزمية إلى دليل من الخدمة الفعلية ومسارات الاستلام ذات الصلة. المفتاح الأصغر ليس سببًا لتخطي عمليات التحقق من إمكانية التشغيل التفاعلي. RFC 8463 ، الأقسام 5 و 6.
تحقق من تسلسل الموفر بدلاً من افتراضه
تحديد ما إذا كانت الخدمة تدعم إعداد مفتاح جديد دون مقاطعة الموقّع الحالي، وكيفية كشف المواد العامة وما هي العملية التي تؤدي إلى الاستبدال. قد يكون لإجراء "إنشاء" أو "تمكين" الخاص بموفر الخدمة تأثيرات تتجاوز إعداد النص. يجب على الوكيل وضع علامة على عدم اليقين قبل أن يستدعيه المسؤول. لا تعد بالتناوب بدون انقطاع من تسلسل DNS العام وحده.
عرضت صفحة إعداد Google Workspace DKIM عملية إعادة توجيه لا يمكن الوصول إليها أثناء هذا البحث ولم تتم إعادة المحاولة. لا يتم استخدام مناقشات المجتمع لتحديد سلوك التناوب الحالي. تصف إرشادات مرسل Gmail المتوفرة بشكل منفصل توقعات طول المفتاح للمستلم، ولكن هذا لا يمثل دليلاً على تسلسل لوحة تحكم Google Workspace . يظل إجراء الموفر الفعلي بمثابة بوابة للتطبيق. إرشادات مرسل Google.
مرحلة النشر وتغيير التوقيع كتغييرات منفصلة
عندما تكون الخطة مدعومة، يجب أن تفصل بين إنشاء المفتاح المعتمد ونشر المفتاح العام والتحقق من المواد المنشورة والتغيير الذي يجعل الموقع يستخدم المحدد الجديد. كل مرحلة تحتاج إلى نتيجة متوقعة وشرط التوقف. يمكن للوكيل تجميع المعاينة ومقارنة القيم العامة المعتمدة، ولكن إنشاء المفتاح الخاص أو نقله ينتمي إلى سير عمل الحضانة المصرح به بشكل صريح.
قم بتسجيل مالك DNS المقترح بالكامل والمواد العامة الدقيقة، بالإضافة إلى أدلة الحالة الحالية والمستأجر المعتمد. قد يكون المفتاح العام عامًا، إلا أن نشره يغير من يمكنه إنتاج مستلمي التوقيعات المرتبطة بهذا المحدد. يعد تفويض المحدد إلى الموفر أيضًا قرارًا تحكميًا. يجب أن تشمل الموافقة التشغيل الفعلي، وليس فقط النية العامة للتدوير.
تعامل مع التداخل باعتباره فاصلًا قائمًا على الأدلة
قد يؤدي التدوير الخيالي إلى نقل الخدمة من المحدد r2026a إلى r2026b مع الاحتفاظ بالمفتاح العام السابق أثناء التداخل المعتمد. سيحتاج الفريق إلى تحديد الوقت الذي توقف فيه جميع الموقعين عن استخدام المحدد القديم وحساب الرسائل الموضوعة في قائمة الانتظار أو المتأخرة التي تحمله بالفعل. تعتبر المحددات هذه تسميات توضيحية، وليست سجلات منشورة أو نتائج اختبار.
يعد سلوك ذاكرة التخزين DNS وعمر قائمة انتظار الرسائل وانتهاء صلاحية التوقيع وتشغيل الموفر اعتبارات مختلفة. لا يوجد TTL واحد يثبت أنه يمكن إيقاف المفتاح القديم في كل مكان. تحديد قرار التقاعد من الأدلة ذات الصلة والمخاطر التشغيلية. إذا كان هناك اشتباه في اختراق المفتاح الخاص القديم، فيجب إعادة النظر في افتراضات التداخل الروتيني والتراجع من قبل مالك الحادث؛ لا تعد استعادة المُوقع المخترق إجراء استرداد افتراضيًا آمنًا.
تحديد الأدلة التي يمكن أن توقف التغيير أو تكمله
يجب أن يلتقط الاختبار المقترح رسالة خاضعة للرقابة موقعة بالنطاق المقصود والمحدد الجديد والتحقق من جهاز الاستقبال الموثوق به DMARC تنسيق. التوقيع الصالح من مجال غير ذي صلة لا يغلق اختبار المحاذاة المقصود. يعد بحث DNS الذي يعرض المفتاح الجديد شرطًا أساسيًا واحدًا فقط. RFC 9989 ، القسم 4.4.
تقارير مجمعة يمكن أن تقدم ملاحظات داعمة لاحقًا، بما في ذلك معلومات DKIM ، لكن فترات الإبلاغ والتغطية تحد مما تحدده على الفور. لا تقم بإيقاف المحدد لمجرد أن لوحة المعلومات لم تعرضه مؤخرًا. احتفظ بالرسالة الخاضعة للتحكم وأدلة تكوين المُوقع وملاحظات الإبلاغ بشكل منفصل. RFC 9990 ، القسمان 3.1.3 و3.3.
تسليم الخطة المختبرة وسجل الحضانة
خطة تم اختبارها لتناوب المفاتيح أو الحوادث مع جرد محدد وأدلة الحضانة والاسترداد. هذا المطلب الدقيق يظل مفتوحا. قبل أن تصبح الخطة توصية تنفيذ، يجب على الحافظ الرئيسي ومالك البريد الموافقة على تسلسل الموفر وشروط التحويل ومعايير التقاعد ومسار الاسترداد. لم يتم هنا توضيح ضوابط المنتج الحالية ومخزون المحدد الحقيقي وأدلة الحضانة ونتائج التحقق القابلة للتكرار.