Your server is running—but is it secure?
A guide to security layers, from server access to tokens, authorization, and databases.
Al-Bahar Al-Tiqni team
تخيل أنك بنيت نظامًا، ورفعته على سيرفر، وربطت الدومين، وفعلت شهادة SSL، وكل شيء شغّال بدون مشاكل.
هل هذا يعني أن نظامك آمن؟
مو بالضرورة.
ممكن يكون عندك HTTPS، لكن منفذ SSH مفتوح للعالم. وممكن تكون قافل SSH بالكامل، لكن التوكنات محفوظة بطريقة غير آمنة. أو تكون كل هالأمور مضبوطة، لكن مستخدم عادي يقدر يوصل لبيانات مستخدم ثاني بسبب خطأ في الصلاحيات.
المشكلة أن كثيرًا من المطورين يتعاملون مع الأمان كأنه خطوة أخيرة قبل إطلاق النظام، مع أنه جزء أساسي من تصميمه وتشغيله.
في هذا المقال بنتعرف على أهم طبقات الحماية، وليش كل طبقة مهمة، وكيف تشتغل مع بعضها لحماية النظام.
أولًا: الأمان ما يعتمد على طبقة واحدة
في الأمن السيبراني عندنا مفهوم اسمه Defense in Depth، أو الدفاع متعدد الطبقات.
الفكرة بسيطة: ما تعتمد على حماية واحدة وتفترض أنها مستحيل تنكسر.
لو أحد حصل على بيانات دخول مستخدم، المفروض ما يقدر يوصل لكل شيء. ولو انكشفت خدمة داخلية، المفروض ما يكون عندها صلاحية الوصول لجميع قواعد البيانات. ولو تسرب مفتاح، المفروض تقدر تلغيه وتحد من الضرر.
كيف تتوزع طبقات الحماية؟
- Network Security: عزل الشبكات والتحكم في الوصول
- Server Hardening: تقليل سطح الهجوم وحماية النظام
- Application Security: حماية الخدمات والـ API
- Identity & Authorization: التحقق من الهوية والصلاحيات
- Data & Secrets: حماية البيانات والمفاتيح
هذه طبقات حماية متكاملة، وليست ترتيبًا ثابتًا أو بديلًا عن المراقبة والاستجابة للحوادث.
كل طبقة تقلل نوعًا معينًا من المخاطر، وما فيه طبقة تغني عن الثانية.
١. تأمين الوصول للسيرفر — SSH Security
الـ SSH هو إحدى أهم طرق إدارة سيرفرات Linux عن بُعد.
لكن السؤال: هل يحتاج أي شخص على الإنترنت يقدر يوصل إلى منفذ SSH عندك؟
غالبًا لا.
بدل ما تترك المنفذ 22 مفتوحًا للعالم، تقدر تخلي الوصول الإداري عن طريق شبكة خاصة مثل VPN، أو نظام Zero Trust Access يتحقق من هوية الشخص وجهازه قبل السماح له بالاتصال.
وأهم الإجراءات هنا:
- استخدام SSH Keys بدل كلمات المرور.
- تعطيل الدخول المباشر بحساب root، واستخدام حساب إداري محدود الصلاحيات.
- تقييد الوصول باستخدام Firewall أو Security Groups.
- استخدام MFA عند بوابة الوصول الإداري متى أمكن.
- تسجيل محاولات الدخول والعمليات الحساسة.
مثال على إعدادات OpenSSH بعد تجهيز حساب إداري واختبار الدخول بالمفتاح:
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yesمهم جدًا تتأكد أن دخولك بالمفتاح شغّال من جلسة ثانية قبل تطبيق التغييرات، عشان ما تقفل الوصول على نفسك.
وبرضه تغيير منفذ SSH من 22 إلى رقم آخر ممكن يقلل محاولات الفحص الآلي، لكنه مو بديل عن المصادقة القوية وتقييد الوصول.
٢. حماية الشبكة — Network Security
مو كل خدمة على السيرفر لازم تكون متاحة للعالم.
تخيل عندك ثلاث خدمات: تطبيق ويب، Backend API، وقاعدة بيانات PostgreSQL.
هل تحتاج تفتح منفذ قاعدة البيانات 5432 لكل الإنترنت؟ أكيد لا.
الأفضل أن تكون الخدمات موزعة حسب الحاجة للوصول:
Internet
↓
Reverse Proxy / WAF — Public HTTPS :443
↓
Backend API — Private Network
↓
PostgreSQL — Private Access Onlyهنا نستخدم مبدأ Network Segmentation، بمعنى تقسيم الشبكة وعزل الخدمات عن بعضها.
ونطبق مبدأ Default Deny: نمنع الاتصالات افتراضيًا، ونسمح فقط بالاتصالات المطلوبة.
مثلًا، قاعدة البيانات تستقبل الاتصالات من خدمات Backend المصرح لها، وليس من أي عنوان IP.
والحماية ما تكون على مستوى السيرفر فقط؛ نقدر نضيف قيودًا على مستوى VPC وSecurity Groups، ونتحكم كذلك بالاتصالات الخارجة من الخدمات.
٣. تشفير الاتصال — HTTPS & TLS
وجود HTTPS أساسي، لكنه مو مجرد قفل يظهر بجانب رابط الموقع.
تقنية TLS تحمي البيانات أثناء انتقالها بين العميل والخادم، وتساعد العميل على التحقق من هوية الخادم.
لكنها ما تحميك من كل شيء.
لو عندك ثغرة في Authorization، فـ HTTPS ما راح يمنع استغلالها؛ هو يشفر الطلب غير المصرح به أيضًا.
ومن المفاهيم المهمة هنا:
- TLS: تشفير الاتصال والتحقق من هوية الخادم
- HSTS: توجيه المتصفح لاستخدام HTTPS مستقبلًا وفق السياسة المعلنة
- mTLS: التحقق المتبادل من هوية طرفي الاتصال باستخدام شهادات
- Certificate Rotation: تجديد واستبدال الشهادات قبل انتهائها أو عند الحاجة
الأفضل استخدام إصدارات TLS الحديثة مثل TLS 1.3، مع إعداد TLS 1.2 الآمن عند الحاجة للتوافق.
٤. تأمين الكوكيز والجلسات — Cookies & Sessions
هنا ندخل في نقطة مهمة جدًا.
بعد ما يسجل المستخدم دخوله، النظام غالبًا يحتاج يحتفظ بحالة تسجيل الدخول باستخدام Session أو Token.
لكن لو انسرقت بيانات الجلسة، ممكن المهاجم يستخدمها للوصول إلى حساب المستخدم.
عشان كذا، عند استخدام Cookies للجلسات، فيه خصائص أمنية مهمة:
Set-Cookie: __Host-session=<session-id>;
Path=/; Secure; HttpOnly; SameSite=Strictوش تعني؟
- HttpOnly: تمنع JavaScript في الصفحة من قراءة الكوكي مباشرة، وهذا يقلل خطر سرقة قيمتها عن طريق بعض هجمات XSS.
- Secure: تخلي المتصفح يرسل الكوكي عبر HTTPS فقط.
- SameSite: تتحكم في إرسال الكوكي مع الطلبات القادمة من مواقع أخرى، وتساعد في تقليل مخاطر CSRF. الاختيار بين Strict وLax يعتمد على تجربة الدخول وتدفق التطبيق.
- __Host-: يفرض شروطًا إضافية على نطاق الكوكي ومسارها، ويساعد في تقليل مخاطر التلاعب بها من النطاقات الفرعية.
لكن انتبه: ضبط هالخصائص ما يكفي وحده.
لازم الجلسة يكون لها عمر محدد، وتُلغى من السيرفر عند تسجيل الخروج، وتتجدد مع أحداث المصادقة الحساسة. وأحيانًا تحتاج CSRF Token مستقل حسب طريقة عمل التطبيق.
المصدر: OWASP Cheat Sheet Series
٥. التوكنات — JWT & Token Security
الـ JWT من الطرق الشائعة لنقل معلومات الهوية والصلاحيات بين الخدمات.
لكن فيه فكرة خاطئة منتشرة: أن استخدام JWT يعني أن نظام المصادقة صار آمنًا تلقائيًا.
الـ JWT غالبًا يكون موقّعًا وليس مشفّرًا؛ وبالتالي محتواه قد يكون قابلًا للقراءة حتى لو ما أمكن تعديله دون إبطال التوقيع.
الأفضل نفرق بين نوعين:
- Access Token: يستخدم للوصول إلى الموارد، ويفضل أن يكون قصير العمر ومحدود الصلاحيات.
- Refresh Token: يستخدم للحصول على Access Token جديد، ويحتاج حماية أقوى وآلية Rotation وكشف إعادة الاستخدام عند تطبيقها.
كذلك لازم نتحقق من التوقيع والخوارزمية المسموحة، والـ issuer والـ audience وتاريخ الانتهاء exp، بدل الاكتفاء بفك التوكن وقراءة بياناته.
ومن الأخطاء الشائعة حفظ التوكنات الحساسة في localStorage في تطبيقات الويب، لأن JavaScript يستطيع الوصول إليها، وبالتالي قد تتعرض للسرقة عند وجود XSS. استخدام Cookies محمية أو نمط Backend-for-Frontend غالبًا أنسب للجلسات الحساسة في المتصفح.
المصدر: OWASP Cheat Sheet Series
٦. الهوية والصلاحيات — Authentication vs Authorization
هنا نصل لواحدة من أهم النقاط في أمن التطبيقات.
فيه فرق كبير بين مفهومين:
- Authentication: من أنت؟
- Authorization: وش مسموح لك تسوي؟
تخيل أنك مسجل دخول في تطبيق عقاري، وعندك عقار رقمه 1001.
ترسل طلبًا:
GET /api/properties/1001وتظهر لك بيانات عقارك بشكل طبيعي.
لكن لو غيرت الرقم إلى 1002، وظهرت لك بيانات عقار مستخدم ثاني، فهنا عندك مشكلة في Authorization حتى لو كانت عملية تسجيل الدخول سليمة.
هذه من صور Broken Object Level Authorization (BOLA)، وهي من أبرز مخاطر أمن الـ API بحسب OWASP.
المصدر: OWASP API Security Top 10
الحل مو مجرد إخفاء الأزرار من الواجهة، أو استخدام UUID بدل الأرقام المتسلسلة.
لازم الـ Backend يتحقق من صلاحية المستخدم على المورد المطلوب والعملية نفسها.
ونقدر نعتمد على نماذج مختلفة للصلاحيات، منها:
- RBAC: الصلاحيات بناءً على الدور، مثل Admin وManager وUser.
- ABAC: الصلاحيات بناءً على خصائص المستخدم والمورد والسياق.
- Least Privilege: إعطاء كل مستخدم أو خدمة أقل قدر من الصلاحيات اللازمة.
والقاعدة الأساسية: لا تثق بقرار الصلاحية القادم من الواجهة.
٧. حماية الـ API
الـ API هو نقطة الاتصال بين التطبيق والخدمات الخلفية، وغالبًا يحتوي على عمليات حساسة مرتبطة بالمستخدمين والمدفوعات والبيانات.
عشان كذا، لازم نحميه بأكثر من آلية.
مثلًا:
- Rate Limiting: للحد من الطلبات المفرطة ومحاولات إساءة الاستخدام.
- Input Validation: للتحقق من المدخلات باستخدام قواعد واضحة، بدل الوثوق بأي بيانات يرسلها العميل.
- CORS: لتحديد المواقع المسموح لها بقراءة استجابات API عبر المتصفح. لكنه مو بديلًا عن Authentication أو Authorization.
- Replay Protection: لمنع إعادة تنفيذ بعض العمليات الحساسة، باستخدام آليات مثل nonce أو timestamp أو idempotency keys بحسب نوع العملية.
- Request Size Limits: لتقليل استهلاك الموارد الناتج عن الطلبات الكبيرة.
وبرضه لا ننسى مخاطر مثل SSRF وSQL Injection وMass Assignment، والتأكد من أن استجابات الـ API ما ترجع حقولًا حساسة أكثر مما يحتاجه العميل.
من المهم كذلك معرفة أن OWASP تصنف أخطاء الإعداد والصلاحيات واستهلاك الموارد ضمن مخاطر API الأساسية.
المصدر: OWASP API Security Top 10
٨. حماية الأسرار — Secrets Management
تخيل أن عندك Backend يتصل بمزود دفع، ويستخدم API Key محفوظًا في ملف إعدادات.
إذا تسرب المفتاح، ممكن أي شخص يملك الصلاحيات المرتبطة به يستخدمه حتى لو ما قدر يدخل إلى السيرفر.
عشان كذا، نحتاج نفصل بين الكود والأسرار.
من أهم المفاهيم:
- Secrets Manager: نظام مركزي لتخزين الأسرار والتحكم في الوصول إليها ومراجعة استخدامها.
- KMS: خدمة لإدارة مفاتيح التشفير وتحديد من يقدر يستخدمها.
- KEK (Key Encryption Key): مفتاح يستخدم لحماية مفاتيح تشفير أخرى، بدل استخدام المفتاح الرئيسي لتشفير كل البيانات مباشرة.
- Secret Rotation: استبدال المفاتيح أو كلمات المرور بصورة منظمة، دوريًا أو عند الاشتباه بتسربها.
ومو معنى هذا أن ملفات Environment Variables ممنوعة دائمًا، لكنها ليست خزنة أسرار بحد ذاتها. لازم ننتبه لطريقة حقن القيم وتشغيل العمليات وصلاحيات الوصول والسجلات.
والأهم، تجنب طباعة المفاتيح والتوكنات في Logs، ولا تخزن أسرار الإنتاج داخل Git.
٩. تأمين قواعد البيانات — Database Security
قاعدة البيانات غالبًا تحتوي على أهم أصول النظام: المستخدمين، الطلبات، المعاملات، وربما معلومات مالية وشخصية.
لهذا، تأمينها لازم يكون مستقلًا عن تأمين التطبيق.
أول شيء، ما نعرض قاعدة البيانات مباشرة للإنترنت إلا إذا كانت هناك ضرورة استثنائية وضوابط مناسبة.
ثاني شيء، ما نخلي التطبيق يتصل باستخدام حساب Superuser.
الأفضل يكون عندنا حساب مخصص للتطبيق، بصلاحيات محدودة على الجداول والعمليات المطلوبة فقط.
ونضيف إلى ذلك تشفير الاتصالات، وتشفير البيانات المخزنة والنسخ الاحتياطية، وسياسة واضحة للاحتفاظ بالبيانات، وسجلات تدقيق للعمليات الحساسة.
ولا ننسى نقطة مهمة: وجود Backup مو معناه أن عندك Disaster Recovery.
لازم تختبر الاستعادة فعلًا، وتحدد:
- RPO: أقصى مقدار فقدان بيانات تستطيع تحمله.
- RTO: أقصى مدة مقبولة لاستعادة الخدمة.
بدون اختبارات استعادة، النسخة الاحتياطية مجرد افتراض أنها شغالة.
١٠. تأمين Docker وKubernetes
الحاويات تسهّل نشر الأنظمة، لكنها ما تعني أن التطبيقات داخلها معزولة أمنيًا بشكل مطلق.
قد تكون صورة Docker تحتوي على حزم قديمة فيها ثغرات، أو تكون الحاوية تعمل بصلاحية root، أو تملك وصولًا غير ضروري لملفات المضيف.
عشان كذا نحتاج:
- Non-root Containers: تشغيل التطبيقات بصلاحيات مستخدم محدود متى أمكن.
- Image Scanning: فحص صور الحاويات لاكتشاف الثغرات المعروفة.
- Read-only Filesystem: منع الكتابة على أجزاء نظام الملفات التي ما تحتاج تعديلًا.
- Resource Limits: الحد من استهلاك الذاكرة والمعالج.
- Kubernetes RBAC & Network Policies: التحكم في صلاحيات مكونات الكلاستر واتصالات الخدمات ببعضها.
والأهم، لا تعطي الحاويات Privileged Mode أو صلاحية الوصول إلى Docker Socket إلا عند ضرورة مبررة ومحدودة جدًا.
١١. المراقبة والاستجابة — Security Monitoring
تخيل أنك ضبطت كل الحمايات السابقة، لكن ما عندك طريقة تعرف فيها إذا أحد يحاول يدخل على حسابات الإدارة، أو إذا خدمة بدأت تتصل بعنوان غير معتاد.
هنا يجي دور المراقبة.
فيه فرق بين ثلاثة مصطلحات مهمة:
- Logs: تسجل الأحداث، مثل عمليات تسجيل الدخول وتغيير الصلاحيات.
- Metrics: تقيس حالة النظام، مثل معدل الأخطاء والاستهلاك والطلبات.
- Traces: تساعدك تتبع رحلة الطلب بين الخدمات لتفهم وين حصلت المشكلة.
وفي الجانب الأمني، نحتاج كذلك Audit Logs توضح من نفّذ العملية، ومتى، وعلى أي مورد، وما نتيجتها.
وممكن نستفيد من SIEM لتجميع الأحداث وربطها واكتشاف الأنماط المشبوهة.
لكن المراقبة بدون استجابة ما تكفي.
لازم تكون عندك إجراءات محددة للتعامل مع الحوادث: كيف تعزل خدمة متضررة، وتلغي التوكنات أو المفاتيح المشكوك فيها، وتحافظ على الأدلة، وتستعيد التشغيل بدون إعادة إدخال نفس المشكلة.
طيب، من وين تبدأ؟
إذا عندك نظام شغّال حاليًا، مو لازم تعيد بناءه من الصفر. ابدأ بمراجعة أولوياتك:
قائمة المراجعة الأمنية
الخلاصة
الأمان مو مجرد Firewall، ولا شهادة SSL، ولا حتى استخدام أحدث تقنيات المصادقة.
الأمان يبدأ من تصميم النظام، ويمر بطريقة إدارة السيرفر والشبكات والهويات والصلاحيات والبيانات، ويستمر حتى بعد إطلاق التطبيق.
السيرفر الآمن مو السيرفر اللي يستحيل اختراقه، بل السيرفر اللي تقل فيه فرص الاختراق، ويكون الضرر محدودًا إذا حصل، وتقدر تكتشف الحادث وتستجيب له وتستعيد عملك.
وهذا هو الهدف الحقيقي من مفهوم Defense in Depth: ما تعتمد على جدار واحد يحمي كل شيء، بل تبني طبقات مستقلة، كل واحدة تسند الثانية.
لأن السؤال الأهم مو بس: هل نظامك شغّال؟
السؤال: هل تقدر تثق فيه إذا تعرض لهجوم؟