הצפנת החוט של Firebird 3 וה-VPN הן שני גבולות שונים

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

שני גבולות, והם אינם חופפים

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

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

גבול ראשון: מי רשאי לפתוח את המאזין

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

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

גבול שני: על מה Firebird מנהל משא ומתן

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

על פי הערות השחרור של Firebird 3 Arc4 רשום כמודול ברירת המחדל להצפנת חוט עבור אותה מהדורה. Arc4 הוא ברירת מחדל היסטורית, לא המלצה לצופן מודרני, והוא אינו אותו דבר כמו הגנת ה-VPN החיצונית.

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

מלכודת Legacy_Auth

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

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

בדקו את החיבור שחשוב

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

SELECT RDB$GET_CONTEXT('SYSTEM', 'WIRE_ENCRYPTED')
FROM RDB$DATABASE;

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

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

הרשאות ונתיב השדרוג

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

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