الدليل الشامل للأمن السيبراني للمواقع والمتاجر الإلكترونية في السعودية 2026: حماية البيانات والحسابات والمدفوعات من الاختراق والاحتيال

إذا كنت تدير موقعًا إلكترونيًا أو متجرًا رقميًا، فأنت لا تدير مجموعة صفحات على الإنترنت فقط.

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

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

فالاختراق لا يعني دائمًا ظهور صفحة سوداء على الموقع.

قد يبدأ برسالة تصيد تصل إلى موظف، أو كلمة مرور مسربة، أو إضافة لم تُحدَّث، أو حساب يملك صلاحيات أكثر مما يحتاج، أو مفتاح API ظهر في مكان غير آمن.

لهذا فإن السؤال الصحيح ليس:

هل موقعي محمي من الاختراق بنسبة 100%؟

فلا توجد بيئة رقمية يمكن ضمان حمايتها بهذه الصورة.

السؤال الأكثر واقعية هو:

هل بنيت طبقات حماية تقلل احتمال نجاح الهجوم، وتحد من الضرر إذا وقع، وتساعدني على اكتشافه والتعافي منه بسرعة؟

وهذه هي الفكرة التي سيبنى عليها هذا الدليل.

لماذا يحتاج الموقع أو المتجر الإلكتروني إلى خطة أمن سيبراني؟

كلما توسع المشروع الرقمي زاد عدد الأبواب التي يمكن أن يدخل منها الخطر.

فقد يمتلك متجر إلكتروني:

حساب مدير للمتجر.
لوحة تحكم للاستضافة.
حسابًا لإدارة النطاق.
بريدًا إلكترونيًا رسميًا.
بوابة دفع.
خدمة شحن.
أدوات تحليلات.
حسابات إعلانية.
إضافات وقوالب.
خدمات سحابية.
حسابات للموظفين أو المتعاونين.
مفاتيح API وخدمات مرتبطة بأنظمة أخرى.

المشكلة أن المهاجم لا يحتاج بالضرورة إلى كسر أقوى باب.

يكفي أن يجد أضعف باب.

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

أبرز المخاطر التي تواجه المواقع والمتاجر الإلكترونية

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

1. سرقة الحسابات وبيانات تسجيل الدخول

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

وتزداد الخطورة عندما تكون بيانات الدخول المسروقة تخص حسابًا إداريًا يملك صلاحيات واسعة.

لذلك فإن كلمة المرور القوية وحدها ليست خطة حماية كاملة.

2. التصيد والهندسة الاجتماعية

قد تكون الأنظمة التقنية جيدة، لكن رسالة واحدة مقنعة تكفي أحيانًا لخداع المستخدم.

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

وهنا يصبح الإنسان نفسه جزءًا من سطح الهجوم.

3. ثغرات التطبيقات والإضافات

المواقع والمتاجر تعتمد غالبًا على عدة مكونات برمجية.

وقد يؤدي استخدام برنامج قديم أو إضافة ضعيفة أو إعداد غير آمن إلى فتح ثغرة يمكن استغلالها.

وتبرز هنا مخاطر معروفة في أمن تطبيقات الويب مثل:

Broken Access Control.
Security Misconfiguration.
Software Supply Chain Failures.
Injection.
Authentication Failures.
Security Logging and Alerting Failures.

ولهذا لا ينبغي النظر إلى تحديث الموقع والإضافات باعتباره تحسينًا شكليًا؛ فقد يكون تحديثًا أمنيًا مهمًا.

4. الصلاحيات الزائدة

ليس كل شخص يعمل على الموقع بحاجة إلى صلاحية Administrator.

إذا كان الموظف مسؤولًا عن المنتجات فقط، فلا يحتاج بالضرورة إلى التحكم الكامل في إعدادات النظام.

وإذا تم اختراق حساب محدود الصلاحيات، فقد يكون الضرر أقل بكثير من اختراق حساب إداري كامل.

وهنا تأتي قاعدة:

Least Privilege — أقل قدر لازم من الصلاحيات.

امنح كل مستخدم ما يحتاج إليه لأداء عمله فقط.

5. هجمات حجب الخدمة DDoS

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

وبالنسبة إلى متجر إلكتروني، فإن توقف الموقع قد يعني توقف المبيعات نفسها.

6. برمجيات الفدية والبرمجيات الخبيثة

قد تؤدي الإصابة ببرمجية خبيثة إلى سرقة البيانات أو تعطيل الأنظمة أو تشفير الملفات.

وتزداد خطورة الحادث إذا لم تكن هناك نسخة احتياطية سليمة ومستقلة يمكن استخدامها لاستعادة العمل.

طبقات الحماية الأساسية للموقع والمتجر الإلكتروني

أفضل استراتيجية ليست الاعتماد على أداة واحدة، وإنما بناء دفاع متعدد الطبقات Defense in Depth.

إذا فشلت طبقة، توجد أخرى خلفها.

أولًا: حماية الحسابات

ابدأ بالحسابات التي تمنح السيطرة على المشروع:

البريد الإلكتروني الأساسي.
لوحة إدارة الموقع أو المتجر.
الاستضافة.
حساب النطاق DNS.
الخدمات السحابية.
بوابات الدفع.
الحسابات الإعلانية.
حسابات المطورين والخدمات الخارجية.

استخدم المصادقة متعددة العوامل MFA

تضيف المصادقة متعددة العوامل حاجزًا إضافيًا بعد كلمة المرور.

وبذلك لا يعني تسرب كلمة المرور وحدها بالضرورة أن المهاجم أصبح قادرًا على الدخول إلى الحساب.

ابدأ بالحسابات الأكثر حساسية أولًا.

لا تعِد استخدام كلمة المرور نفسها

استخدم كلمة مرور فريدة لكل خدمة، واستعن بـ Password Manager موثوق لإدارة كلمات المرور بدل الاعتماد على الذاكرة أو إعادة استخدام كلمة واحدة.

راجع الحسابات القديمة

الحساب الذي لم يعد صاحبه يعمل في المشروع ولا يزال يمتلك صلاحيات يمثل بابًا مفتوحًا بلا حاجة.

ضع إجراءً واضحًا لإلغاء وصول الموظف أو المتعاون بمجرد انتهاء حاجته إليه.

ثانيًا: إدارة الصلاحيات

استخدم مبدأ Least Privilege.

راجع بصورة دورية:

من يملك صلاحية الإدارة؟
من يستطيع تغيير إعدادات الدفع؟
من يستطيع تصدير بيانات العملاء؟
من يستطيع تثبيت الإضافات؟
من يستطيع إنشاء مستخدمين جدد؟
من يملك مفاتيح API؟

وخصص حسابًا مستقلًا لكل مستخدم بدل مشاركة حساب إداري واحد بين عدة أشخاص.

فالحسابات الفردية تجعل عملية المراجعة والتتبع أكثر وضوحًا.

ثالثًا: تحديث الموقع والمتجر باستمرار

تراكم البرمجيات القديمة يزيد مساحة الخطر.

لذلك ضع سياسة تحديث تشمل:

نظام إدارة المحتوى.
القالب.
الإضافات.
مكتبات البرمجة.
الخادم.
مكونات التجارة الإلكترونية.
الخدمات والتكاملات الخارجية عند الحاجة.

لكن لا تجعل التحديث عملية عشوائية.

في الأنظمة المهمة، احتفظ بنسخة احتياطية واختبر التغييرات بطريقة تقلل احتمال تعطيل الخدمة.

رابعًا: حماية الاتصال باستخدام HTTPS

يجب أن يعمل الموقع عبر HTTPS مع شهادة TLS صالحة.

يساعد ذلك في حماية البيانات أثناء انتقالها بين المستخدم والموقع.

لكن انتبه:

HTTPS لا يعني أن الموقع نفسه آمن بالكامل.

فهو يحمي الاتصال، لكنه لا يعالج كلمة مرور ضعيفة أو إضافة مصابة أو صلاحية إدارية خاطئة.

خامسًا: حماية لوحة الإدارة

لوحة الإدارة من أكثر أجزاء الموقع حساسية.

ومن الإجراءات المفيدة:

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

والهدف ليس مجرد جعل صفحة تسجيل الدخول «أصعب»، وإنما جعل الاستيلاء على حساب إداري أكثر صعوبة وأسرع اكتشافًا.

حماية بيانات العملاء

إذا كنت تجمع بيانات لا تحتاج إليها، فأنت تتحمل مخاطر لا تحتاج إليها أيضًا.

لذلك اسأل عن كل معلومة:

هل أحتاج فعلًا إلى تخزينها؟

حدد البيانات التي يجمعها المشروع، ولماذا يجمعها، وأين تُخزن، ومن يستطيع الوصول إليها، ومدة الاحتفاظ بها.

وطبق ضوابط وصول مناسبة للبيانات الحساسة، مع التشفير عندما يكون ذلك ملائمًا.

قاعدة عملية جيدة:

البيانات التي لا تجمعها أصلًا لا يمكن سرقتها من قاعدة بياناتك.

حماية المدفوعات الإلكترونية

إذا كنت تدير متجرًا، فبوابة الدفع جزء بالغ الحساسية من سلسلة العمل.

والقاعدة المهمة هنا هي:

لا تخزن بيانات بطاقات الدفع بنفسك ما لم تكن لديك حاجة واضحة وبنية امتثال وأمن مناسبة لذلك.

استخدم مزودي دفع موثوقين، وقلل تعرض نظامك المباشر لبيانات الدفع الحساسة قدر الإمكان.

وراجع أيضًا:

صلاحيات حساب بوابة الدفع.
MFA.
المستخدمين المصرح لهم.
Webhooks.
مفاتيح API.
التكاملات مع المتجر.
إشعارات العمليات غير المعتادة.

حماية API Keys والأسرار الرقمية

قد يستخدم الموقع مفاتيح للوصول إلى خدمات الدفع أو البريد أو الذكاء الاصطناعي أو التخزين أو خدمات أخرى.

تعامل مع API Keys وTokens كما تتعامل مع كلمات المرور.

لا تضعها:

في كود عام.
داخل مستودع GitHub مفتوح.
في صفحات يمكن للزائر الوصول إليها.
داخل ملفات يتم إرسالها بلا حاجة.

استخدم وسائل مناسبة لإدارة الأسرار، ودوّر المفاتيح عند الاشتباه بتسربها، وألغِ المفاتيح القديمة التي لم تعد مستخدمة.

النسخ الاحتياطي: آخر خط دفاع

وجود Backup لا يكفي.

المهم أن تستطيع استعادة النظام منه.

لذلك ينبغي أن تكون لديك سياسة تحدد:

ما الذي يتم نسخه؟
كم مرة؟
أين تحفظ النسخ؟
من يستطيع الوصول إليها؟
كم نسخة تاريخية تحتفظ بها؟
متى تم اختبار Restore آخر مرة؟

ولا تعتمد على نسخة واحدة موجودة على النظام نفسه الذي تحاول حمايته.

فالنسخة الاحتياطية التي لم تختبر استعادتها ليست ضمانًا حقيقيًا للتعافي.

المراقبة والسجلات Logging

كيف ستعرف أن هناك مشكلة إذا لم تكن لديك سجلات؟

راقب الأحداث المهمة مثل:

محاولات تسجيل الدخول المتكررة.
إنشاء حساب إداري جديد.
تغيير الصلاحيات.
تعديل إعدادات حساسة.
تغييرات غير معتادة في الملفات.
نشاط API غير طبيعي.
عمليات تصدير كبيرة للبيانات.
تغييرات بوابة الدفع.

لكن لا تجمع Logs لمجرد جمعها.

ينبغي أن توجد آلية لمراجعتها أو إطلاق تنبيه عندما يحدث شيء يستحق الانتباه.

WAF وCDN والحماية من الهجمات

يمكن أن تضيف خدمات CDN وWeb Application Firewall طبقة مفيدة أمام الموقع.

وقد تساعد في:

تصفية بعض الطلبات الضارة.
الحد من أنماط هجوم معينة.
إدارة حركة المرور.
تخفيف بعض هجمات DDoS.
تطبيق Rate Limiting.

لكنها طبقة حماية وليست بديلًا عن تأمين التطبيق نفسه.

الأمن السحابي: مسؤولية مشتركة

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

هناك مفهوم مهم يسمى:

Shared Responsibility — المسؤولية المشتركة.

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

ولهذا يجب أن تعرف بدقة:

ما الذي يحميه المزود، وما الذي يقع على عاتقك أنت؟

حماية النطاق DNS والبريد الإلكتروني

قد يكون الموقع نفسه محميًا، ثم يأتي الهجوم من مكان آخر.

حساب النطاق

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

لذلك:

فعّل MFA.
استخدم كلمة مرور فريدة.
راقب التغييرات.
قلل عدد من يملكون الوصول.

البريد الإلكتروني

البريد هو مفتاح إعادة تعيين كلمات المرور لكثير من الخدمات.

ولهذا يجب أن تكون حمايته من أعلى الأولويات.

استخدم MFA، وراجع إعدادات البريد، وطبّق تقنيات المصادقة المناسبة للنطاق مثل SPF وDKIM وDMARC وفق إعداد بيئتك البريدية.

الموظفون والمتعاونون جزء من منظومة الأمن

ليست كل الثغرات برمجية.

قد يبدأ الحادث من:

رابط تصيد.
ملف ضار.
مشاركة كلمة مرور.
إرسال بيانات إلى الشخص الخطأ.
إعطاء صلاحية أكبر من المطلوب.

لذلك ينبغي أن يعرف كل شخص يعمل في المشروع:

ماذا يفعل عندما يشك في رسالة أو نشاط غير طبيعي؟

ثقافة الإبلاغ المبكر أفضل من ثقافة إخفاء الخطأ.

ماذا تفعل إذا تعرض الموقع للاختراق؟

وجود Incident Response Plan — خطة استجابة للحوادث قبل المشكلة أفضل كثيرًا من محاولة اختراع خطة أثناء الأزمة.

يمكن بناء الاستجابة حول مراحل واضحة:

1. الاكتشاف

حدد ما حدث ومتى بدأ وما الأنظمة التي قد تكون متأثرة.

2. الاحتواء

حاول الحد من استمرار الضرر، مثل تعطيل حساب مخترق أو عزل مكون متأثر، وفق طبيعة الحادث.

3. إزالة السبب

لا يكفي حذف الملف الضار.

يجب البحث عن Root Cause — السبب الجذري: كيف دخل المهاجم أصلًا؟

4. الاستعادة

أعد الخدمات بصورة آمنة، وغيّر بيانات الاعتماد المتأثرة، واستعد النسخ عند الحاجة، وراقب النظام بحثًا عن عودة النشاط المشبوه.

5. ما بعد الحادث

وثق ما حدث واسأل:

ما الذي نجح؟
ما الذي فشل؟
كيف اكتشفنا الحادث؟
ماذا كان سيجعله أقل ضررًا؟
ما الإجراء الذي سيمنع تكراره؟

الأمن السيبراني والالتزام في السعودية

بالنسبة للمواقع والمتاجر العاملة في السوق السعودي، لا ينبغي فصل الأمن السيبراني عن حماية البيانات والالتزام التنظيمي.

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

كما تصدر الهيئة الوطنية للأمن السيبراني أطرًا وضوابط للأمن السيبراني تختلف نطاقات تطبيقها بحسب نوع الجهة وطبيعة عملها.

وفي نهاية عام 2025 أصدرت الهيئة ضوابط الأمن السيبراني للجهات الخاصة من غير ذوات البنى التحتية الحساسة NCNICC-1:2025، والتي تحدد الحد الأدنى من متطلبات الأمن السيبراني للجهات الواقعة ضمن نطاق تطبيقها.

وهنا يجب الانتباه إلى نقطة مهمة:

وجود متجر إلكتروني لا يعني تلقائيًا أن كل ضوابط الهيئة تنطبق عليه بالطريقة نفسها.

النطاق التنظيمي يعتمد على طبيعة الجهة وتصنيفها والأنظمة واللوائح ذات الصلة.

لذلك يجب الرجوع إلى المصادر الرسمية أو مختص قانوني/امتثال عند تحديد الالتزامات الخاصة بالمشروع.

قائمة فحص أمنية للمواقع والمتاجر الإلكترونية

استخدم هذه القائمة كمراجعة دورية:

هل MFA مفعلة للحسابات الحساسة؟
هل لكل مستخدم حساب مستقل؟
هل تطبق Least Privilege؟
هل كلمات المرور فريدة وتدار بطريقة آمنة؟
هل النظام والقالب والإضافات محدثة؟
هل توجد مكونات لم تعد مستخدمة ويمكن حذفها؟
هل HTTPS يعمل بصورة صحيحة؟
هل لوحة الإدارة محمية ومراقبة؟
هل مفاتيح API محفوظة بأمان؟
هل توجد نسخ احتياطية دورية؟
هل اختبرت Restore فعليًا؟
هل توجد Logs للأحداث الحساسة؟
هل توجد تنبيهات للنشاط غير المعتاد؟
هل راجعت صلاحيات الخدمات الخارجية؟
هل تعرف ما بيانات العملاء التي تجمعها ولماذا؟
هل تقلل تخزين بيانات الدفع الحساسة؟
هل حساب النطاق والبريد محميان بـMFA؟
هل يعرف الموظفون كيفية اكتشاف التصيد والإبلاغ عنه؟
هل لديك Incident Response Plan؟
هل تعرف من تتصل به عند حدوث حادث؟

إذا وجدت عدة إجابات بـ«لا»، فقد حصلت للتو على قائمة أولويات أمنية لمشروعك.

خطة عملية لتحسين أمن موقعك خلال 30 يومًا

ليس مطلوبًا تنفيذ كل شيء في يوم واحد.

الأسبوع الأول: الهوية والوصول

راجع جميع الحسابات الإدارية.

فعّل MFA.

ألغ الحسابات القديمة.

طبق Least Privilege.

ابدأ باستخدام Password Manager مناسب.

الأسبوع الثاني: التطبيق والبنية

حدّث الأنظمة والإضافات.

احذف المكونات غير المستخدمة.

راجع HTTPS.

راجع إعدادات الاستضافة والخدمات السحابية.

افحص API Keys والأسرار.

الأسبوع الثالث: البيانات والاستمرارية

حدد البيانات التي تجمعها.

قلل غير الضروري منها.

راجع صلاحيات الوصول.

أنشئ سياسة Backup واضحة.

نفّذ اختبار Restore فعليًا.

الأسبوع الرابع: الكشف والاستجابة

فعّل Logging المناسب.

أنشئ تنبيهات للأحداث المهمة.

راجع حماية النطاق والبريد.

اكتب Incident Response Plan مختصرة.

نفذ تمرينًا افتراضيًا:

ماذا سنفعل لو استولى شخص على حساب المدير الآن؟

إذا لم تعرف الإجابة خلال دقائق، فالخطة تحتاج إلى مزيد من العمل.

أخطاء أمنية شائعة يجب تجنبها

«موقعي صغير، ولن يستهدفني أحد»

الكثير من الهجمات آلية ولا تبحث عن علامة تجارية مشهورة؛ تبحث عن نظام ضعيف يمكن استغلاله.

«لدينا HTTPS، إذن الموقع آمن»

HTTPS يحمي الاتصال، وليس التطبيق كاملًا.

«لدينا نسخة احتياطية»

هل اختبرت استعادتها؟

هذا هو السؤال الأهم.

«المطور مسؤول عن الأمن»

الأمن مسؤولية مشتركة بين الإدارة والمطورين والمستخدمين ومزودي الخدمات بحسب الأدوار.

«لن يحدث لنا اختراق»

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

أسئلة شائعة حول أمن المواقع والمتاجر الإلكترونية

هل يمكن حماية موقع إلكتروني من الاختراق بنسبة 100%؟

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

ما أهم خطوة أبدأ بها اليوم؟

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

هل المتاجر الصغيرة تحتاج إلى أمن سيبراني؟

نعم. حجم المشروع لا يلغي وجود حسابات وبيانات ومدفوعات وخدمات يمكن استهدافها.

لكن مستوى الضوابط والإجراءات ينبغي أن يكون متناسبًا مع المخاطر وحجم المشروع وطبيعة البيانات والالتزامات النظامية.

هل WAF يمنع اختراق الموقع؟

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

كم مرة يجب اختبار النسخ الاحتياطية؟

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

الخاتمة: الأمن السيبراني عملية مستمرة وليس مشروعًا ينتهي

حماية الموقع أو المتجر الإلكتروني لا تبدأ بشراء أداة أمنية ولا تنتهي بتثبيت إضافة.

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

ابدأ بالأشياء الأعلى أثرًا:

الحسابات → MFA → الصلاحيات → التحديثات → البيانات → النسخ الاحتياطية → المراقبة → خطة الاستجابة.

ثم حسّن المنظومة تدريجيًا.

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

وفي المقابل، لا يحتاج صاحب المشروع إلى أن يصبح متخصص أمن سيبراني حتى يبدأ.

يحتاج أولًا إلى أن يعرف:

ما الأصول التي أملكها؟ ما أخطر ما يمكن أن يحدث لها؟ وما أول إجراء عملي يمكنني اتخاذه اليوم لتقليل هذا الخطر؟

ومن هذه الأسئلة تبدأ الحماية الحقيقية.

مدونة فكرة