הגדרת PostgreSQL SSL/TLS להצפנת חיבורים

למה התעבורה ל-PostgreSQL יוצאת בטקסט גלוי

כברירת מחדל השרת עולה עם הצפנה כבויה: ב-pg_hba.conf עבור רוב הרשתות קיים כלל host, שמתיר באותה מידה גם ערוץ פתוח וגם ערוץ מאובטח. לקוח עם sslmode=prefer יסכים בשקט לווריאנט הלא מוצפן, אם לחיצת היד מסיבה כלשהי לא הצליחה — ואף אחד לא ידע שהנתונים עברו כטקסט גלוי.

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

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

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

הגדרת SSL/TLS עבור PostgreSQL: מה זה סוגר

לפני הפעלת ההצפנה, התקשורת בין הלקוחות ל-PostgreSQL עוברת כטקסט גלוי: פרטי ההזדהות ברגע האימות והנתונים עצמם גלויים לכל מי שמקבל גישה לתעבורה — שיקוף פורט, פרוקסי מתווך או הקלטת דאמפ. SSL/TLS הופך את הערוץ לזרם מוצפן, וסוג הכשל הזה נעלם לחלוטין, ולא נחלש חלקית.

המצב נקבע משני הצדדים. ב-pg_hba.conf השורה host מוחלפת ב-hostssl — חיבורים לא מוצפנים מפסיקים להתקבל באופן מנהלי, ותצורת ברירת המחדל ה"נשכחת" לא משאירה דלת פתוחה.

בצד הלקוח sslmode=require מבטיח רק הצפנה, בעוד verify-ca ו-verify-full בודקים בנוסף את שרשרת התעודות ואת התאמת שם המארח — הם בדיוק סוגרים את החלפת השרת על ידי מתווך.

ההשפעה של ההצפנה על זמן התגובה חלשה ממה שנהוג לחשוב: עלויות נלוות נופלות על לחיצת היד בעת כינון החיבור, ולא על העברת הנתונים.

מאגר החיבורים עושה שימוש חוזר בסשנים שכבר הוקמו, ולכן סדרת שאילתות מוחזרת באותה המהירות, וחידוש סשן מסיר לחיצות יד חוזרות אצל לקוחות שמתחברים מחדש לעתים קרובות.

סיפור נפרד — ניתוק הערוץ. סשן מוצפן נשבר באופן מפורש: הלקוח מקבל מיד שגיאה ועובר לחיבור מחדש, במקום להמתין לטיימאאוט עם טרנזקציה "תקועה" ותשובה שאבדה בשקט.

עבור בדיקות אבטחה, הצפנה בתעבורה היא סעיף חובה: סריקות וביקורת בודקות את גרסת הפרוטוקול, ערכות הצפנים ותוקף התעודות. פרוטוקולים מיושנים מושבתים, תעודות מתחדשות לפי לוח זמנים, ודוח תאימות נאסף ללא הסתייגויות ידניות.

מצבי הגנה על חיבורים: מבדיקת תעודה ועד מנהרה

ב-PostgreSQL הצפנת הערוץ מופעלת על ידי פרמטרים של ssl ב-postgresql.conf, אבל את המצב בוחר הלקוח — דרך sslmode במחרוזת החיבור וכללי pg_hba.conf. ההבדל בין המצבים אינו בחוזק הצופן, אלא בשאלה אם נבדקת תעודת השרת, אם נדרשת תעודת לקוח והיכן מסתיים הקטע המוצפן.

את השילוב בוחרים לפי גבולות האמון, ולא לפי העיקרון "כמה שיותר חמור, יותר טוב": אימות הדדי בתוך המתחם מוסיף רק רוטציה של תעודות, ואילו require בכתובת ציבורית משאיר החלפת שרת כאפשרית. את מגבלות המצבים כדאי לתעד בכתב — אחרת בחקירת אירוע מתברר שנבדק רק עצם ההצפנה.

סדר היישום: מביקורת תצורה ועד מסירת נהלים

העבודה מתבצעת ברצף: כל שלב הבא נשען על תוצאה מאושרת של הקודם, ולכן המעבר להצפנה אינו מנתק שירותים שכבר פועלים. להלן הסדר שבו אנו מובילים את הפרויקט.

1. ביקורת תצורת החיבורים. אוספים מפת צרכנים: אילו שירותים פונים למסד, מאילו כתובות, אילו דרייברים תומכים בהצפנה והיכן מחרוזת החיבור מוטבעת בתמונה או בצינור הבנייה. בלי המפה הזאת כל הגדרה נעשית בעיוורון ומנתקת חלק מהלקוחות.
2. תכנון סכמת האמון. מגדירים את רמת החומרה: רק הצפנת ערוץ או בדיקה הדדית של תעודות לקוח, מי חותם, מה תוחלת החיים, כיצד מבוטלת תעודה. את ההחלטה מתעדים בכתב — ממנה תלויים שאר השלבים.
3. הנפקת תעודות. מייצרים בצומת מאובטח, מפתחות פרטיים אינם עוזבים את השרת, מגדירים הרשאות לקבצים ומכינים שרשרת אמון לבדיקה.
4. הגדרת השרת. מפעילים הצפנה, קובעים אילו חיבורים מותרים, וטוענים מחדש את התצורה ללא עצירת השירות. ההרצה הראשונה — במצב רך: תחילה אזהרות בלוג, לאחר מכן איסור על סשנים לא מוצפנים.
5. בדיקת ההצפנה. מתחברים בכפייה עם הצפנה ובלעדיה, מנתחים לוגים, מוודאים שהמדיניות מיושמת ולא רק מוצהרת. בנפרד בודקים התנהגות עם תעודה שפג תוקפה ותעודה מוחלפת.
6. מסירת נהלים. מוסרים הוראות לרוטציה, נקודות בקרה, סדר שחזור גישה בעת אובדן מפתח ותסריט רולבק.

חבילת מסירה: תצורות, שרשראות אמון, נהלי רוטציה

בפלט הלקוח מקבל לא אוסף פקודות מפוזרות, אלא ערכה ניתנת לשחזור עבור PostgreSQL: תצורות, סכמת אמון של תעודות ונהלים שלפיהם המתחם ממשיך להתקיים. כל סעיף מתקבל לפי עובדות בשטח — הגדרה שהופעלה, חיבור שנבדק, רולבק שהורץ בסביבת בדיקות.

• תצורות שרת: SSL מופעל, נתיבים לתעודה, למפתח ולשרשרת, גרסת פרוטוקול מינימלית מותרת — בתבניות מנוהלות, ולא בעריכות על מסד חי.
• כללי גישה: pg_hba.conf, שבו מארחים יישומיים מותרים רק דרך hostssl, וחיבורים לא מוצפנים מבחוץ אסורים במפורש.
• שרשראות אמון: תעודות שורש ותעודות ביניים, סדר פריסתן ובדיקת התאמת המפתח לתעודה.
• רוטציה של מפתחות: לוח זמנים להנפקה מחדש, סדר החלפה ללא ניתוק חיבורים פעילים ודרך ביטול באמצעות רשימת ביטולים.
• נוהל רולבק: היכן נשמר הזוג הקודם, אילו צעדים מחזירים את המתחם לפעולה ובתוך כמה זמן זה נבדק בסביבת בדיקות.
• תיעוד חיבורים: מחרוזות חיבור, דרישות ללקוחות, צ'ק-ליסט מוכן לשירותים וקבלנים חדשים.
• בקרת תוקף: התראות לפי תאריכי תעודות ושגיאות לחיצת יד — אזהרה לפני פקיעה, ולא אחריה.
• מטריצת אחריות: מי מנפיק, מי מאשר, מי מבטל.

מקרה בוחן: סגרנו תעבורה פתוחה בין שירותים לרפליקות

מה היה

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

עבור «ТрансЛайн» הביקורת תיעדה זאת כסיכון מהקטגוריה הראשונה: הגישה למסד התבססה על אמון, ולא על בדיקת תעודה.

איך התקדמנו בלי השבתה

תחילה הקמנו מרכז תעודות פנימי והנפקנו תעודה נפרדת לכל שירות ולכל רפליקה. את השרת העברנו למצב שבו חיבורים מאובטחים ורגילים מתקבלים בו-זמנית — זה נתן חלון למעבר הדרגתי.

לאחר מכן החלפנו לקוחות אחד-אחד: מחרוזת חיבור עם בדיקת תעודה מחייבת (sslmode=verify-full), הפעלה מחדש של מופע בודד, בדיקת קריאה מהרפליקה. את הרפליקציה העברנו למצב זרימה עם בדיקת תעודה, הגיבוי הבסיסי נלקח כבר דרך ערוץ מאובטח, ואת החיבורים הרגילים השבתנו בסוף — בשינוי נפרד.

מה השתנה

• שיעור החיבורים דרך ערוץ מאובטח: 0 → 100%, כולל רפליקציה;
• השבתה במעבר: אפס, רולבק לכל שלב ארך דקות;
• השהיית תגובה ב-p99 לא גדלה באופן מורגש;
• רוטציה של תעודות במקום עריכות ידניות בארבעים שירותים — אוטומטית.

במה שונה סיום במאזן עומסים מהצפנה מקצה לקצה?

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

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

הצפנה מקצה לקצה מעבירה את גבול ההגנה עד למופע PostgreSQL עצמו: סשן TLS מתקיים בין הלקוח לשרת, וצומת הביניים רואה רק כתובות, פורטים ונפח מועבר.

הדרישות להגדרת ssl postgresql מחמירות יותר: תעודה ומפתח נדרשים לכל שרת, לקוחות עוברים לבדיקת שרשרת ושם מארח — אחרת החיבור מוצפן, אבל החלפת צומת נשארת אפשרית.

המחיר — אובדן המודעות לתוכן: ניתוב לפי סוג שאילתה והפרדת קריאה וכתיבה ברמת הפרוקסי מפסיקים לעבוד, בדיקת מצב השרת עוברת לחיבור שירותי.

הבחירה נקבעת לפי מודל האיומים: אם הרשת הפנימית מבודדת והגישה מוגבלת, די בסיום; אם התעבורה עוברת בין אתרים, דרך סגמנטים זרים או ערוצי ענן, הצפנה מקצה לקצה היא האפשרות היחידה שבה צומת ביניים אינו הופך לנקודת דליפה.

ספקות טכניים: תאימות, תעודות, רולבק

הספקות בזמן יישום הצפנה הם בדרך כלל אותם ספקות: האם לקוח ישן יפסיק לעבוד, מה יקרה בעת הנפקה מחדש של תעודה במערכת חיה, איך לוודא שההצפנה באמת עובדת ואיך לחזור אחורה אם משהו ישתבש. להלן תשובות שאנו נותנים לפני תחילת העבודה, כדי שהתמונה תהיה מלאה.

איך להנפיק תעודות מחדש בלי לעצור את השירות?

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

האם אפשר להחזיר הכול אחורה?

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

איך לבדוק שההצפנה באמת עובדת?

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

נדון במשימה: נצלם את התצורה הנוכחית ונחזור עם תוכנית

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

• הפלט של SHOW ssl; והפרמטרים ssl_cert_file, ssl_key_file, ssl_ca_file מתוך postgresql.conf (או ציון שהם לא הוגדרו) — זה ליבת ההערכה.
• רשימת לקוחות שפונים למסד: אפליקציה, שירותי אנליטיקה, רפליקציה, קונסולות ניהול — עם ציון אילו מהם תומכים ב-TLS ואילו לא.
• כיצד מונפקות והיכן נשמרות התעודות: מרכז אישורים פנימי, חיצוני או חתומות עצמית; מי ומתי מבצע רוטציה.
• כללי הגישה ב-pg_hba.conf לפי שורות — לפחות קטע שבו נראים שיטות האימות, כדי להבין מה יהיה צורך לשנות במעבר להצפנה.
• מפת הרשת: היכן מאזני עומסים, היכן פרוקסי חיבורים, האם יש צמתי ביניים שגם הם צריכים להעביר תעבורה מוצפנת.
• מצב עמידות התקלות הנוכחי: רפליקות, גיבוי, חלונות תחזוקה — מהם תלויים לוחות הזמנים של היישום.

לפי הנתונים האלה נצלם את תמונת החיבורים בפועל, נתעד אילו צמתים יהיה צורך לעדכן ובאיזה סדר, כדי לא לכבות שירותים פעילים.

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