Cassandra מעל VPN: גישה נפרדת ללקוחות ולצמתים

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

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

שלושה קהלים, שלוש החלטות

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

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

מה שלקוחות צריכים, ולא יותר

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

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

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

הצפינו בנפרד לקוח-לצומת ובין-צמתי

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

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

client_encryption_options:
  enabled: true
  optional: false
server_encryption_options:
  internode_encryption: all

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

השאירו את הניהול בנתיב משלו

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

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

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

מה התכנון מבטיח

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

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