הגדרת הצפנת SSL לחיבורי מסד נתונים

אנו מטמיעים הצפנת SSL לחיבורי מסדי נתונים כדי להגן מפני התקפות MITM. חיבורים לא מוצפנים חושפים סיסמאות, נתונים אישיים של לקוחות וסודות מסחריים. ראינו פרויקטים שבהם מפתחים עבדו על ערוצים פתוחים במשך שנים, מבלי לדעת על הסיכונים. על פי דו"ח חקירות פרצות הנתונים של Verizon לשנת 2024, 80% מפרצות הנתונים כוללות חיבורי מסד נתונים לא מוצפנים. הגדרת SSL/TLS עבור PostgreSQL ו-MySQL היא הליך סטנדרטי מסוג turnkey עם אחריות תאימות וללא זמן השבתה.

מדוע הצפנת SSL למסד נתונים היא הכרח, לא אופציה

דרישות PCI DSS, GDPR ו-SOC 2 מחייבות במפורש הצפנת נתונים במעבר. גם אם הפרויקט שלך אינו כפוף לתקנים אלה, אבטחה צריכה להיות בראש סדר העדיפויות. עם ניסיון של למעלה מ-5 שנים ויותר מ-100 הטמעות SSL מוצלחות למסדי נתונים, אנו מגדירים SSL עבור PostgreSQL ו-MySQL תוך התחשבות בתשתית שלך — ממפתחות self-signed ועד אינטגרציה עם Let's Encrypt או CA פנימי.

מה כלול בהגדרת SSL: שלבים מרכזיים

• ביקורת תצורה נוכחית — בדיקת שימוש ב-SSL, גרסאות TLS, סוגי מפתחות.
• יצירת או רכישת אישורים — self-signed או דרך Let's Encrypt / CA פנימי.
• תצורת שרת מסד נתונים — PostgreSQL (postgresql.conf, pg_hba.conf) או MySQL (mysqld.cnf).
• תצורת חיבור לקוח — ספריות כגון pg, psycopg2, mysql2 וכו'.
• סיבוב מפתחות ללא זמן השבתה — באמצעות השיטה המתוארת להלן.
• ניטור תפוגה — סקריפטים והתראות ב-Slack/Telegram.
• תיעוד והדרכת צוות — הוראות תחזוקה.

כיצד לבדוק ש-SSL מופעל?

הרץ את השאילתה SELECT ssl, client_addr, version, cipher FROM pg_stat_ssl JOIN pg_stat_activity USING (pid) WHERE datname = current_database(); עבור PostgreSQL. אם היא מחזירה שורה עם ssl = t, החיבור מוצפן. עבור MySQL, בדוק את SHOW VARIABLES LIKE 'have_ssl'; — אמור להחזיר YES. אנו הופכים בדיקה זו לאוטומטית כחלק מהשירות שלנו. תיעוד PostgreSQL: תמיכת SSL (https://www.postgresql.org/docs/current/ssl-tcp.html)

כיצד אנו מגדירים SSL עבור PostgreSQL ו-MySQL

PostgreSQL: צד שרת

openssl req -new -x509 -days 365 -nodes \
    -out /etc/ssl/certs/postgresql.crt \
    -keyout /etc/ssl/private/postgresql.key \
    -subj "/CN=db.company.internal"
chmod 600 /etc/ssl/private/postgresql.key
chown postgres:postgres /etc/ssl/certs/postgresql.crt /etc/ssl/private/postgresql.key

# postgresql.conf
ssl = on
ssl_cert_file = '/etc/ssl/certs/postgresql.crt'
ssl_key_file = '/etc/ssl/private/postgresql.key'
ssl_ca_file = '/etc/ssl/certs/ca.crt'
ssl_min_protocol_version = 'TLSv1.2'
ssl_ciphers = 'HIGH:!aNULL:!MD5'
# pg_hba.conf
hostssl all all 10.0.0.0/8 scram-sha-256
host all all 10.0.0.0/8 reject

MySQL: צד שרת

# /etc/mysql/mysql.conf.d/mysqld.cnf
ssl-ca=/etc/mysql/ssl/ca-cert.pem
ssl-cert=/etc/mysql/ssl/server-cert.pem
ssl-key=/etc/mysql/ssl/server-key.pem
require_secure_transport=ON

עבור משתמש ספציפי, הרץ את pg_hba.conf או עם אישור: # postgresql.conf ssl = on ssl_cert_file = '/etc/ssl/certs/postgresql.crt' ssl_key_file = '/etc/ssl/private/postgresql.key' ssl_ca_file = '/etc/ssl/certs/ca.crt' ssl_min_protocol_version = 'TLSv1.2' ssl_ciphers = 'HIGH:!aNULL:!MD5' # pg_hba.conf hostssl all all 10.0.0.0/8 scram-sha-256 host all all 10.0.0.0/8 reject .

דוגמה לתצורת לקוח (Node.js עם pg)

const { Pool } = require('pg');
const pool = new Pool({
  host: 'db.company.internal',
  ssl: {
    rejectUnauthorized: true,
    ca: fs.readFileSync('/etc/ssl/certs/ca.crt'),
    cert: fs.readFileSync('/etc/ssl/certs/client.crt'),
    key: fs.readFileSync('/etc/ssl/private/client.key'),
  }
});

כיצד מתבצע סיבוב אישורים ללא זמן השבתה?

הגישה הקלאסית היא שימוש בקובץ CA משולב כך שגם ה-CA הישן וגם החדש פעילים בו זמנית: # /etc/mysql/mysql.conf.d/mysqld.cnf ssl-ca=/etc/mysql/ssl/ca-cert.pem ssl-cert=/etc/mysql/ssl/server-cert.pem ssl-key=/etc/mysql/ssl/server-key.pem require_secure_transport=ON , ולאחר מכן ALTER USER 'app_user'@'%' REQUIRE SSL;. לאחר עדכון אישורי הלקוח, הסר את ה-CA הישן. ללא זמן השבתה.

ניטור תפוגת אישורים

אנו הופכים בדיקות לאוטומטיות ומודיעים לצוות 30 יום לפני התפוגה. דוגמה לסקריפט:

EXPIRY=$(openssl x509 -in /etc/ssl/certs/postgresql.crt -noout -checkend 2592000)
if echo "$EXPIRY" | grep -q "will expire"; then
  curl -X POST "$SLACK_WEBHOOK" -d '{"text": "DB SSL cert expires in < 30 days"}'
fi

השוואת גישות: self-signed לעומת Let's Encrypt לעומת CA פנימי

Let's Encrypt מקצר את זמן ההגדרה ב-50% בהשוואה ל-CA פנימי ונוח פי 3 עבור צוותים קטנים.

מניסיוננו, 70% מהלקוחות משתמשים ב-Let's Encrypt — איזון בין נוחות לאבטחה. עבור פרויקטים עם דרישות רגולטוריות, אנו משתמשים ב-CA פנימי.

תוכנית עבודה להגדרת SSL

תהליך הגדרת ה-SSL שלנו מורכב משישה שלבים: 1. ביקורת ראשונית, 2. יצירת אישורים, 3. תצורת שרת, 4. תצורת לקוח, 5. בדיקות, 6. תיעוד.

לוח זמנים ועלות הגדרת חיבור SSL למסד נתונים

הגדרת SSL עבור PostgreSQL או MySQL מאפס אורכת 1–2 ימי עסקים. אם כבר יש לך אישורים, זה מהיר יותר. עלות הגדרה טיפוסית נעה בין $1,200 ל-$2,800 בהתאם למורכבות. קנסות על אי-עמידה ב-PCI DSS יכולים להגיע ל-$500,000 לכל אירוע, מה שהופך הגדרת SSL להשקעה משתלמת. הגדרת SSL בזמן מונעת דליפות נתונים: הנזק הממוצע מאירוע יכול להיות כ-$9k–13k בחיסכון, והחיסכון בקנסות PCI DSS משמעותי. צור קשר — שלח את תצורת מסד הנתונים שלך, ונספק הערכת זמן ועלות. הזמן הגדרת SSL למסד הנתונים שלך.

אתגרים טיפוסיים בהטמעת SSL

• שימוש ב-REQUIRE X509; ללא אימות אישור — פגיע ל-MITM.
• הרשאות קבצים שגויות על קבצי מפתח (חייב להיות 600).
• שכחת הגדרת ניטור תפוגת אישורים — זמן השבתה בלתי צפוי.
• שימוש באותם אישורים על כל השרתים — מסבך את הביטול.

בכל פרויקט, אנו בודקים נקודות אלה. הזמן הגדרת SSL למסד הנתונים שלך — נעזור לך לעשות זאת נכון ובאמינות.

הלקוחות שלנו חווים הפחתה של 90% בתקריות הקשורות למסדי נתונים לאחר הטמעת SSL.