أضف رؤوس الأمان باستخدام Lambda @ Edge و Terraform في AWS S3 / CloudFront

عند تسجيل الدخول إلى https://app.sendgrid.com للتحقق من تفاصيل حسابك أو زيارة https://mc.sendgrid.com للحملات التسويقية ، فأنت تزور تطبيقات الويب الأمامية المستضافة في حاويات AWS S3 باستخدام توزيعات CloudFront فوقها.

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

تعمل البنية الأساسية لـ AWS S3 و CloudFront بشكل جيد لتطبيقات الويب الخاصة بنا على نطاق واسع في استضافة الملفات عبر شبكة توصيل المحتوى ، لكن تكويناتنا الأولية افتقرت إلى تدابير حماية أكثر إحكامًا في شكل رؤوس أمان.

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

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

كما ترى ، كان هناك مجال كبير للتحسين. لقد بحثنا في كيفية تكوين موارد AWS S3 و CloudFront الخاصة بنا للرد مرة أخرى برؤوس الأمان للتخفيف من المخاطر ونقاط الضعف المذكورة.

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

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

ما نوع رؤوس الأمان التي نود إضافتها؟

كجزء من التوصيات المقدمة من فريق "أمان المنتج" ، تم تكليفنا بإضافة رؤوس أمان مثل "Strict-Transport-Security" و "X-Frame-Options". نوصيك أيضًا بمراجعة الموارد مثل MDN Web Security Cheatsheet للحصول على السرعة. فيما يلي ملخص قصير لرؤوس الأمان التي يمكنك تطبيقها على تطبيقات الويب الخاصة بك.

أمن النقل الصارم (HSTS)

هذا لتوفير تلميحات للمتصفح للوصول إلى تطبيق الويب الخاص بك من خلال HTTPS بدلاً من HTTP.

سياسة أمن المحتوى (CSP)

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

نصيحة: استخدم رأس Content-Security-Policy-Report-Only لمساعدتك في الاختبار في بيئات معينة. إذا انتهكت بعض الموارد السياسات ، فقد لاحظنا نتائج مفيدة لوحدة التحكم للموارد التي نحتاجها للسماح بها في سياساتنا.

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

X- نوع المحتوى- خيارات

هذا للحفاظ على الأصول وتحميلها بأنواع MIME الصحيحة في صفحة الويب الخاصة بك.

X- خيارات الإطار

هذا لتوفير قواعد حول كيفية تحميل تطبيق الويب الخاص بك في إطار iframe.

حماية X-XSS

يؤدي هذا إلى إيقاف تحميل الصفحات إذا تم اكتشاف هجوم البرمجة النصية عبر المواقع في متصفحات معينة.

سياسة المُحيل

يدير هذا كيفية تمرير عنوان "المُحيل" بمعلومات حول أصل الطلب عند اتباع روابط لمواقع أو موارد خارجية.

مع وضع رؤوس الأمان هذه في الاعتبار ، دعنا نعود إلى كيفية إعداد توزيعات CloudFront اليوم وكيف ستساعدنا وظائف Lambda @ Edge في تحقيق هدفنا.

استخدام Lambda @ Edge مع توزيعات CloudFront الخاصة بنا

بالنسبة لتوزيعات CloudFront الخاصة بنا ، نقوم بإعداد أشياء مثل:

• • شهادات SSL للنطاقات المراد إرفاقها أعلى عنوان URL الخاص بـ CloudFront مثل https://app.sendgrid.com
  • أصول الجرافة S3
  • مجموعات الأصل التي تحتوي على حاويات أساسية ومتماثلة لتجاوز الفشل تلقائيًا
  • سلوكيات ذاكرة التخزين المؤقت

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

في حالتنا ، يمكننا تغيير رؤوس استجابة الأصل قبل تخزينها مؤقتًا بواسطة خوادم الحافة. ستضيف وظيفة Lambda @ Edge الخاصة بنا رؤوس أمان مخصصة إلى استجابة الأصل قبل أن تعود في النهاية إلى خادم الحافة وقبل أن يتلقى المستخدم النهائي ملفات JavaScript و CSS و HTML مع تلك الرؤوس.

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

كيف نختبر وظيفة Lambda @ Edge؟

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

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

نصيحة: ألق نظرة على مستندات Terraform لمعرفة ما إذا كان بإمكانها مساعدتك في الحفاظ على التكوينات المعقدة دون الحاجة إلى تذكر جميع الخطوات التي قمت بها في وحدات التحكم السحابية.

كيف تبدأ في AWS Console

لنبدأ بكيفية إعداد الأشياء يدويًا من خلال وحدة تحكم AWS.

1. أولاً ، تحتاج إلى إنشاء وظيفة Lambda @ Edge في منطقة "us-east-1". بالانتقال إلى صفحة خدمات Lambda ، سننقر على "إنشاء وظيفة" ونسميها شيئًا مثل "testSecurityHeaders1".

2. يمكنك استخدام دور موجود به أذونات لتشغيل الوظيفة على خوادم الحافة أو يمكنك استخدام أحد قوالب نهج الأدوار الخاصة بها ، مثل "أذونات Lambda @ Edge الأساسية ..." وتسميته "lambdaedgeroletest".

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

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

5. بعد حفظ رمز الوظيفة ، دعنا نختبر ما إذا كانت وظيفة Lambda تعمل من خلال التمرير إلى الأعلى والضغط على الزر "اختبار". ستقوم بإنشاء حدث اختبار باسم "samplecloudfrontresponse" باستخدام قالب الحدث "cloudfront-edit-response-header" للسخرية من حدث استجابة أصل CloudFront الفعلي ولمعرفة كيفية تشغيل وظيفتك مقابلها.

ستلاحظ أشياء مثل كائن رؤوس "cf.response" الذي سيعدله كود دالة Lambda.

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

رائع ، يبدو أن وظيفة Lambda قد ألحقت رؤوس الأمان بالاستجابة بشكل صحيح!

7. لنعد إلى منطقة "المصمم" وننقر على زر "إضافة مشغل" حتى تتمكن من ربط وظيفة Lambda بسلوكيات ذاكرة التخزين المؤقت لتوزيع CloudFront في حدث استجابة الأصل. تأكد من تحديد مشغل "CloudFront" وانقر على الزر "Deploy to Lambda @ Edge".

8. بعد ذلك ، حدد توزيع CloudFront (في مثالنا ، مسحنا الإدخال هنا لأسباب أمنية) وسلوك ذاكرة التخزين المؤقت لربطها به.

يمكنك بعد ذلك اختيار سلوك ذاكرة التخزين المؤقت "*" وتحديد حدث "Origin response" للمطابقة في جميع مسارات الطلبات لتوزيع CloudFront الخاص بك وللتأكد من تشغيل وظيفة Lambda دائمًا لجميع استجابات الأصل.

بعد ذلك ، تقوم بإلغاء تحديد الإقرار قبل النقر فوق "نشر" لنشر وظيفة Lambda الخاصة بك رسميًا.

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

إجراء تغييرات على كود Lambda الخاص بك

متى احتجت إلى إجراء تغييرات على كود Lambda الخاص بك ، فإننا نوصي بما يلي:

1. 1. انشر نسخة جديدة من خلال القائمة المنسدلة لزر "الإجراءات"
   2. احذف المشغلات في الإصدار الأقدم (يمكنك النقر فوق القائمة المنسدلة "Qualifiers" لمشاهدة جميع إصدارات Lambda الخاصة بك)
   3. اربط المشغلات برقم الإصدار الأحدث الذي نشرته مؤخرًا

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

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

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

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

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

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

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

تعديل Lambda @ Edge الناجم عن توزيع CloudFront الخاص بنا

بعد التكرار على وظيفة Lambda @ Edge لرؤوس الأمان في منطقة "us-east-1" ، أردنا إضافة هذا إلى قاعدة كود Terraform الخاصة بنا لصيانة الكود والتحكم في الإصدار على الطريق.

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

تفترض الخطوات التالية أن لديك بالفعل معظم توزيعات CloudFront وحاويات S3 التي تم تكوينها من خلال Terraform. سنركز على الوحدات والخصائص الرئيسية التي تتعلق بـ Lambda @ Edge ونضيف المشغل إلى سلوكيات ذاكرة التخزين المؤقت لتوزيع CloudFront. لن نتعرف على كيفية إعداد حاويات S3 وإعدادات توزيع CloudFront الأخرى من البداية عبر Terraform ، ولكننا نأمل أن تتمكن من رؤية مستوى الجهد المبذول لإنجاز ذلك بنفسك.

نقوم حاليًا بتقسيم موارد AWS الخاصة بنا إلى مجلدات وحدة منفصلة وتمرير المتغيرات إلى تلك الوحدات من أجل المرونة في تكويننا. لدينا مجلد apply يحتوي على مجلد فرعي development production ولكل منها ملف main.tf خاص به حيث نسمي هذه الوحدات مع متغيرات إدخال معينة لإنشاء أو تعديل موارد AWS الخاصة بنا.

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

1. أولاً ، نحتاج إلى وحدة قابلة لإعادة الاستخدام لضغط ملف Lambda الخاص بنا قبل تحميله ونشره كإصدار آخر من وظيفة Lambda @ Edge الخاصة بنا. هذا يأخذ مسارًا إلى مجلد Lambda الخاص بنا الذي يحتوي على وظيفة Node.js Lambda النهائية.

2. بعد ذلك ، نضيف إلى وحدة CloudFront الحالية الخاصة بنا ، والتي تغطي حاويات S3 والسياسات وموارد توزيع CloudFront عن طريق أيضًا إنشاء مورد Lambda تم إنشاؤه من ملف Lambda المضغوط. نظرًا لأن مخرجات وحدة Lambda zip يتم تمريرها كمتغيرات في وحدة CloudFront لإعداد مورد Lambda ، فنحن بحاجة إلى تحديد منطقة مزود AWS على أنها "us-east-1" وبسياسة دور العمل مثل هذه.

3. ضمن وحدة CloudFront ، نقوم بعد ذلك بربط وظيفة Lambda @ Edge بسلوكيات ذاكرة التخزين المؤقت لتوزيع CloudFront كما هو موضح أدناه.

4. أخيرًا ، بتجميعها جميعًا في ملف main.tf الخاص بمجلد apply/development أو apply/production ، نسمي كل هذه الوحدات ونضع المخرجات المناسبة كمتغيرات في وحدة CloudFront كما هو موضح هنا.

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

كيف نطرح هذا بأمان في بيئات مختلفة؟

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

كما ذكرنا سابقًا ، اكتشفنا كيف يمكننا الاستفادة من رأس Content-Security-Policy-Report-Only بدلاً من ذلك لتقليل المخاطر حيث نجمع المزيد من نطاقات الموارد لإضافتها في كل من سياساتنا.

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

لكل بيئة ، يمكنك طرح رؤوس الأمان Lambda كما يلي:

• • انشر التغييرات على Lambda إما يدويًا أو من خلال خطة Terraform وقم بالتقدم بطلب للحصول على التغييرات على البيئة باستخدام رؤوس الأمان الأخرى ورأس Content-Security-Policy-Report-Only أولاً.
  • انتظر حتى يتم نشر حالة توزيع CloudFront بشكل كامل مع Lambda المرتبطة بسلوكيات ذاكرة التخزين المؤقت.
  • قم بإلغاء صلاحية ذاكرة التخزين المؤقت على توزيع CloudFront إذا استمرت رؤوس الأمان السابقة في الظهور ، أو أن التغييرات الحالية تستغرق وقتًا طويلاً لتظهر في متصفحك.
  • قم بزيارة صفحات تطبيق الويب الخاص بك وتجول فيها مع فتح أدوات المطور ، وفحص وحدة التحكم بحثًا عن أي رسائل خطأ في وحدة التحكم "Report Only…" لتحسين عنوان Content-Security-Policy.
  • قم بإجراء تغييرات على كود Lambda الخاص بك لمراعاة تلك الانتهاكات المبلغ عنها.
  • كرر من الخطوة الأولى حتى تشعر بالثقة الكافية لتغيير العنوان الخاص بك من Content-Security-Policy-Report-Only إلى Content-Security-Policy ، مما يعني أن البيئة ستفرضه.

تحسين نقاط رؤوس الأمن لدينا

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

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

المضي قدمًا مع رؤوس الأمان

بعد إعداد رؤوس الأمان يدويًا من خلال وحدة تحكم AWS أو تعديل الحل بنجاح وتطبيق التغييرات على كل بيئة من بيئاتك ، أصبح لديك الآن أساس رائع للتكرار بشكل أكبر وتحسين رؤوس الأمان الحالية في المستقبل.

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

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

لمزيد من المقالات التي كتبها ألفريد لوسيرو ، انتقل إلى صفحة مؤلف مدونته: https://sendgrid.com/blog/author/alfred/