تعزيز أمان خادم الإنتاج: قائمة مرجعية شاملة

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

الوجبات الرئيسية

• تعمل مصادقة مفتاح SSH فقط والمنافذ غير القياسية على حظر 99% من هجمات القوة الغاشمة الآلية
• يؤدي جدار الحماية الذي تم تكوينه بشكل صحيح إلى تقليل مساحة الهجوم من آلاف نقاط الدخول إلى أقل من عشرة
• تعمل جدران الحماية لتطبيقات الويب على حظر حقن SQL وXSS وأهم 10 هجمات OWASP على طبقة الشبكة
• يضمن التصحيح التلقائي إصلاح الثغرات الأمنية خلال ساعات من الكشف عنها، وليس أسابيع

---

تصلب SSH

التكوين

# /etc/ssh/sshd_config

# Disable password authentication
PasswordAuthentication no
ChallengeResponseAuthentication no

# Disable root login
PermitRootLogin no

# Use SSH keys only
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

# Limit login attempts
MaxAuthTries 3
MaxSessions 5

# Set idle timeout (5 minutes)
ClientAliveInterval 300
ClientAliveCountMax 0

# Restrict SSH to specific users
AllowUsers deploy ubuntu

# Disable X11 forwarding
X11Forwarding no

# Use only strong algorithms
KexAlgorithms [email protected],diffie-hellman-group-exchange-sha256
Ciphers [email protected],[email protected],[email protected]
MACs [email protected],[email protected]

Fail2Ban

# /etc/fail2ban/jail.local
[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 3600
findtime = 600

[nginx-http-auth]
enabled = true
filter = nginx-http-auth
logpath = /var/log/nginx/error.log
maxretry = 5
bantime = 3600

---

تكوين جدار الحماية

UFW (أوبونتو)

# Reset and set default policies
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Allow SSH (consider changing port)
sudo ufw allow 22/tcp

# Allow HTTP/HTTPS
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Allow specific IPs for management
sudo ufw allow from 203.0.113.10 to any port 9090 comment "Grafana"
sudo ufw allow from 203.0.113.10 to any port 9093 comment "Alertmanager"

# Deny everything else (implicit with default deny)
sudo ufw enable
sudo ufw status verbose

مجموعات أمان AWS

# Terraform security group
resource "aws_security_group" "app" {
  name_prefix = "app-"
  vpc_id      = aws_vpc.main.id

  # Allow HTTPS from anywhere
  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
    description = "HTTPS from internet"
  }

  # Allow SSH from office IP only
  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["203.0.113.0/24"]
    description = "SSH from office"
  }

  # Allow all outbound
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

# Database security group - no public access
resource "aws_security_group" "db" {
  name_prefix = "db-"
  vpc_id      = aws_vpc.main.id

  ingress {
    from_port       = 5432
    to_port         = 5432
    protocol        = "tcp"
    security_groups = [aws_security_group.app.id]
    description     = "PostgreSQL from app servers only"
  }
}

---

رؤوس أمان Nginx

# Security headers for all responses
add_header X-Frame-Options "DENY" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
add_header Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self'; connect-src 'self' https://api.example.com;" always;

# Hide server version
server_tokens off;

# Limit request size
client_max_body_size 10m;

# Rate limiting
limit_req_zone $binary_remote_addr zone=general:10m rate=10r/s;
limit_req_zone $binary_remote_addr zone=api:10m rate=30r/s;
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

server {
    location / {
        limit_req zone=general burst=20 nodelay;
    }

    location /api/ {
        limit_req zone=api burst=50 nodelay;
    }

    location /auth/ {
        limit_req zone=login burst=3 nodelay;
    }
}

---

تكوين SSL/TLS

# Modern TLS configuration
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
ssl_prefer_server_ciphers off;

# OCSP stapling
ssl_stapling on;
ssl_stapling_verify on;

# Session configuration
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;

# Certificate (Let's Encrypt)
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

تجديد الشهادة آليا

# /etc/cron.d/certbot
0 0,12 * * * root certbot renew --quiet --post-hook "nginx -s reload"

---

أمن الحاويات

في حالة تشغيل Docker في الإنتاج، قم بتطبيق إجراءات التقوية الإضافية هذه:

دوكر الشيطان الأمن

{
  "userns-remap": "default",
  "no-new-privileges": true,
  "live-restore": true,
  "userland-proxy": false,
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

قيود وقت تشغيل الحاوية

# docker-compose.yml security settings
services:
  api:
    security_opt:
      - no-new-privileges:true
    read_only: true
    tmpfs:
      - /tmp
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE

المبادئ الأساسية:

• أسقط كل الإمكانيات وأضف ما هو مطلوب فقط
• نظام الملفات للقراءة فقط يمنع المهاجمين من تعديل محتويات الحاوية
• لا توجد امتيازات جديدة تمنع تصعيد الامتيازات داخل الحاويات
• مستخدم غير جذري في ملف Dockerfile (راجع دليل نشر Docker)

أمن الصور

• استخدم الصور الأساسية الرسمية البسيطة (متغيرات جبال الألب)
• تثبيت إصدارات الصور (لا تستخدم مطلقًا :latest في الإنتاج)
• مسح الصور بحثًا عن نقاط الضعف باستخدام Trivy أو Grype
• قم بتوقيع الصور باستخدام Docker Content Trust
• استخدام سجل خاص مع ضوابط الوصول

---

أمن قاعدة البيانات

تصلب PostgreSQL

# postgresql.conf security settings
listen_addresses = 'localhost'        # Only listen on localhost
ssl = on                              # Require SSL for connections
ssl_cert_file = '/path/to/server.crt'
ssl_key_file = '/path/to/server.key'
password_encryption = scram-sha-256   # Modern password hashing
log_connections = on                  # Log all connections
log_disconnections = on               # Log disconnections
log_statement = 'ddl'                 # Log DDL statements

# pg_hba.conf - restrict connections
# TYPE  DATABASE  USER  ADDRESS      METHOD
local   all       all                scram-sha-256
host    all       all   10.0.0.0/8   scram-sha-256
hostssl all       all   0.0.0.0/0    scram-sha-256

• لا تعرض PostgreSQL مطلقًا للإنترنت العام
• استخدم مستخدمي قاعدة البيانات المخصصة مع الحد الأدنى من الأذونات المطلوبة
• تمكين تشفير الاتصال (SSL)
• تعيين سياسات كلمة مرور قوية
• التحقق من النسخ الاحتياطي بشكل منتظم (راجع دليل التعافي من الكوارث)

---

كشف التسلل

تكوين OSSEC

<!-- /var/ossec/etc/ossec.conf -->
<ossec_config>
  <syscheck>
    <!-- Monitor critical files for changes -->
    <directories check_all="yes">/etc,/usr/bin,/usr/sbin</directories>
    <directories check_all="yes">/opt/app/dist</directories>

    <!-- Ignore frequently changing files -->
    <ignore>/etc/mtab</ignore>
    <ignore>/etc/resolv.conf</ignore>

    <!-- Run integrity check every 6 hours -->
    <frequency>21600</frequency>
  </syscheck>

  <rootcheck>
    <rootkit_files>/var/ossec/etc/shared/rootkit_files.txt</rootkit_files>
    <rootkit_trojans>/var/ossec/etc/shared/rootkit_trojans.txt</rootkit_trojans>
  </rootcheck>
</ossec_config>

AWS GuardDuty

resource "aws_guardduty_detector" "main" {
  enable = true

  datasources {
    s3_logs {
      enable = true
    }
    kubernetes {
      audit_logs {
        enable = true
      }
    }
  }
}

---

التصحيح الأمني الآلي

# Ubuntu: Enable unattended security updates
sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

# /etc/apt/apt.conf.d/50unattended-upgrades
Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
};

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "03:00";
Unattended-Upgrade::Mail "[email protected]";

---

قائمة التحقق من تشديد الأمان

مستوى الخادم

• مصادقة SSH بمفتاح فقط، تم تعطيل تسجيل الدخول إلى الجذر
• تم تكوين جدار الحماية باستخدام سياسة الرفض الافتراضي
• Fail2Ban نشط على SSH وخادم الويب
• تمكين التحديثات الأمنية التلقائية
• تم تعطيل الخدمات غير الأساسية
• مراقبة سلامة الملفات (OSSEC أو ما يعادلها)
• تمكين تسجيل التدقيق (auditd)

مستوى التطبيق

• TLS 1.2+ على جميع نقاط النهاية، مع تمكين HSTS
• تكوين رؤوس الأمان (CSP، X-Frame-Options، وما إلى ذلك)
• تحديد المعدل على جميع نقاط النهاية العامة
• التحقق من صحة الإدخال والاستعلامات ذات المعلمات (لا يوجد sql.raw())
• HttpOnly، تأمين ملفات تعريف الارتباط للمصادقة
• يقتصر CORS على أصول معروفة
• لا تؤدي استجابات الأخطاء إلى تسرب آثار المكدس

مستوى الشبكة

• قاعدة البيانات غير متاحة للعامة
• الخدمات الداخلية على الشبكات الفرعية الخاصة
• نقاط نهاية VPC لخدمات AWS (لا يوجد إنترنت عام)
• WAF على نقاط النهاية المواجهة للعامة
• حماية DDoS (Cloudflare، AWS Shield)

المراقبة

• تم تكوين التنبيه بالحدث الأمني
• الاحتفاظ بالسجل لمدة 90 يومًا على الأقل
• رصد محاولات المصادقة الفاشلة
• تم اكتشاف أنماط مرور غير عادية

---

الأسئلة المتداولة

كم مرة يجب علينا إجراء عمليات تدقيق الأمان؟

عمليات فحص آلية ربع سنوية (فحص الثغرات الأمنية، وتدقيق التبعية) واختبارات الاختراق اليدوية السنوية. يجب أن تخضع التطبيقات عالية المخاطر (معالجة الدفع، وبيانات الرعاية الصحية) لاختبارات اختراق خارجية كل 6 أشهر. يجب أن تتضمن كل عملية نشر للإنتاج فحصًا أمنيًا تلقائيًا في مسار CI/CD --- راجع دليل أفضل ممارسات CI/CD.

هل WAF ضروري إذا كان لدينا بالفعل حد للمعدل؟

نعم. يمنع تحديد المعدل إساءة الاستخدام ولكنه لا يفحص محتوى الطلب. يحظر WAF حقن SQL وXSS وهجمات طبقة التطبيق الأخرى من خلال تحليل حمولات الطلب. فكر في تحديد المعدل كحماية من الفيضانات وWAF كفحص للمحتوى --- فأنت بحاجة إلى كليهما.

كيف نقوم بتأمين خادم إنتاج Odoo؟

بالإضافة إلى التشديد العام أعلاه: قم بتعطيل مدير قاعدة البيانات في الإنتاج (list_db = False)، وقم بتعيين admin_passwd قوي، واستخدم dbfilter لتقييد الوصول إلى قاعدة البيانات، وقم بتشغيل Odoo خلف Nginx (لا تعرض Odoo مباشرة أبدًا)، وحافظ على تحديث Odoo وجميع الوحدات. توفر ECOSIRE تعزيز أمان Odoo كجزء من خدمات الاستضافة المُدارة لدينا.

ما هو الإجراء الأمني الأكثر تأثيرًا؟

تمكين MFA (المصادقة المتعددة العوامل) على جميع الحسابات الإدارية. يمنع عنصر التحكم الفردي هذا 99% من الهجمات المستندة إلى بيانات الاعتماد. قم بتنفيذ MFA على SSH (عبر PAM)، ووحدة تحكم AWS، وأدوات إدارة قاعدة البيانات، ولوحات إدارة التطبيقات قبل أي إجراء تقوية آخر.

---

ما يأتي بعد ذلك

التشديد الأمني ​​هو ممارسة مستمرة. اجمعها مع المراقبة والتنبيه للكشف، والتعافي من الكوارث للمرونة، والفحص الأمني ​​لـ CI/CD للوقاية.

اتصل بـ ECOSIRE للحصول على استشارات حول تعزيز الأمان، أو استكشف دليل DevOps للحصول على خريطة طريق البنية التحتية الكاملة.

---

تم النشر بواسطة ECOSIRE - مساعدة الشركات على تأمين البنية التحتية للإنتاج.