PostgreSQL דרך VPN: איזו כתובת מקור יראה pg_hba

המאזין, חומת האש וכלל ה-HBA הראשון שמתאים הם שלושה החלטות. בדקו את המקור ש-PostgreSQL באמת מקבל לפני בחירת קידומת.

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

שלושה החלטות שאסור למזג

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

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

היכן השרת מאזין

כרכו לכתובת שבאמת מוקצית למכונה, ולא לשם ממשק:

listen_addresses = '10.20.0.30'

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

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

הכתובת ש-HBA באמת רואה

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

לפריסה שכבר משתמשת ב-TLS וב-SCRAM, דוגמה מכוונת צרה לגישה מרחוק נראית כך:

hostssl appdb app_login 10.8.0.0/24 scram-sha-256
host all all 0.0.0.0/0 reject
host all all ::/0 reject

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

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

ההתאמה הראשונה מנצחת, בלי גיבוי

PostgreSQL קורא את הקובץ מלמעלה למטה ומשתמש ברשומה הראשונה שמתאימה לחיבור. אין ניסיון שני אם האימות של אותה רשומה נכשל, ולכן היתר רחב מוקדם יותר מביס בשקט דחייה מאוחרת יותר.

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

הפניה ל-HBA מגדירה גם את הסדר וגם את ההבדל בין רשומות host ל-hostssl, וזה חשוב כשמטרת הכלל היא שהחיבור חייב להיות מוצפן.

טעינה מחדש, הפעלה מחדש והמקרה הנדחה

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

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

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

מאמרים קשורים