MySQL דרך VPN: אמתו את השרת, לא רק את ההצפנה
הצפנה אל המארח הלא נכון עדיין שגויה. השוו את ערכי ssl-mode, ואז הריצו חיבור שמנקוב בשם השרת שהתכוונתם אליו ומוכיח זאת.
אתם שומרים חיבור אל 10.20.4.15, ה-VPN נופל, והלקוח עדיין מתחבר. אלה אינן חדשות טובות. כתובת פרטית היא מיקום בתוך כל הקשר ניתוב שבו אתם נמצאים, והרבה רשתות משתמשות באותם טווחים. הלקוח הגיע לשרת MySQL, אולי פשוט לא לשלכם.
לתיקון שני חצאים, ורק אחד מהם עוסק ברשת. שמרו את החיבור על המסלול המיועד לו, והכריחו את הלקוח לאמת את השרת שאיתו הוא מדבר. החצי הראשון הוא המקום שבו VPN עוזר; את החצי השני יש להגדיר.
מוצפן אל מה, בדיוק?
TLS מגן על השיחה מפני כל מי שנמצא באמצע, ואינו אומר דבר על מי הקצה טוען שהוא, אלא אם הלקוח בודק זאת. תעודה שמאומתת מול רשות מהימנה מוכיחה שהתעודה הגיעה מאותה רשות. היא אינה מוכיחה שהתעודה הונפקה עבור שם המארח שאליו רציתם להגיע, ואלה שאלות שונות.
זה לא פער תיאורטי. פורטלי לכידה, טעויות עם VRF שגוי ותוכניות כתובות חופפות כולם מייצרים שרת שמוכן לגמרי לנהל איתכם משא ומתן TLS. אם הלקוח דורש רק הצפנה, הסשן פרטי ומופנה למסד הנתונים הלא נכון.
לכן השאלה הרלוונטית אינה אם החיבור מוצפן, אלא אם הוא מוצפן אל הזהות שהתכוונתם אליה. בלקוח של MySQL, ההבחנה הזו חיה כולה בהגדרה ssl-mode.
חמשת ערכי ssl-mode בפועל
קיימים חמישה ערכים, ורק אחד מהם עונה על שאלת מדריך זה. הטבלה מפרטת מה כל אחד מבטיח באמת, ולא מה שמו מרמז.
| Mode | What it guarantees |
|---|---|
DISABLED | No TLS at all; everything on the wire is readable |
PREFERRED | Tries TLS and falls back to plaintext when the account and server allow it, so it is not a fail-closed requirement |
REQUIRED | Refuses to connect without TLS, and does not validate the certificate |
VERIFY_CA | Validates the server certificate against the configured CA and does not check the hostname |
VERIFY_IDENTITY | Validates the CA and checks that the certificate names the host the client used |
רק השורה האחרונה עונה על השאלה במאמר זה. PREFERRED ראוי לציון בפני עצמו, מפני שלקוח שיורד בשקט לטקסט פשוט גרוע מלקוח שמסרב: אתם חושבים שיש לכם הצפנה ולכידת החבילות חולקת על כך.
חיבור שתוכלו להריץ היום
הפקודה למטה היא הצורה שבה יש להשתמש, עם שני מצייני מקום: שם מסד הנתונים המאושר וקובץ CA שהושג בערוץ מאושר. אין לקחת אף אחד מהם ממה שהשרת מציע לכם במגע הראשון.
mysql --host=db.corp.example --user=app_reader \
--ssl-mode=VERIFY_IDENTITY \
--ssl-ca=/approved/path/ca.pem --password--password בלי ערך מבקש קלט, מה שמשאיר את הסוד מחוץ לרשימת התהליכים ומחוץ להיסטוריית ה-shell שלכם. זו הרגל קטן עם תמורה גדולה במארחי קפיצה משותפים, שבהם שורת פקודה גלויה למשתמשים אחרים.
כשזה נכשל, טקסט השגיאה מבחין בין המקרים טוב יותר מאשר אינטואיציה. כשל CA פירושו שהשרשרת אינה מאומתת ועליכם לבדוק איזו CA חתמה על תעודת השרת. כשל בשם מארח פירושו שהשרשרת תקינה והשם אינו תואם, מה שבדרך כלל אומר שהתחברתם לשרת הנכון בשם השגוי ולא לשרת השגוי.
הופעתה של בקשה אינה הוכחה שסיסמה כבר נשלחה, וחיבור כושל אינו מוכיח ששום דבר לא עזב את הלקוח. אם אתם משחזרים אירוע מהעבר, זהו את הלקוח, את תצורתו, את תוסף האימות ואת השלב שנכשל. אומדן החשיפה מתוך הודעת השגיאה האחרונה הוא ניחוש.
כשהשם מגיע ממנהרה
העברת פורט מקומית שוברת את בדיקת הזהות באופן שמפתיע אנשים. אם תעבירו פורט מקומי למסד הנתונים ותתחברו אל localhost, הלקוח מאמת את התעודה מול localhost, ולא הונפקה תעודה לשם הזה. החיבור עשוי להיות בטוח לחלוטין והאימות עדיין ייכשל, וזה הבדיקה פועלת כמתוכנן.
יש שתי תשובות כנות. תנו לקצה המועבר שם שמתפענח לכתובת הלולאה ומופיע בתעודת השרת, או השתמשו בשם המארח מקצה לקצה כדי שהלקוח יאמת את הזהות האמיתית. הראשון נוח למפתחים ודורש עבודת תעודות; השני פשוט יותר לחשוב עליו ולעיתים קרובות ברירת המחדל הנכונה לאוטומציה. השבתת האימות כדי שההעברה תעבוד זורקת את התכונה שניסיתם להוסיף.
קבלה היא שלושה תנאים
כתבו את מבחן הקבלה כשלוש הצהרות נפרדות: החיבור השתמש במסלול המיועד, ההצפנה הייתה נדרשת ולא מועדפת, וזהות השרת אומתה מול חומר מהימן. סמל VPN ירוק אינו מבסס אף אחד מהם.
עבור לקוחות GUI ועבור MariaDB, בדקו את התיעוד של הספק עצמו במקום להניח שכתיב הדגל עובר כמות שהוא. התיעוד של MySQL על חיבורים מוצפנים מכסה את ההבדלים בין המצבים ואת דרישת הפצת ה-CA, וזהו המקור שכדאי לבדוק לפני שתשנו מחרוזת חיבור בייצור.