TLS, כניסת רשת והרשאות SQL עונות על שאלות שונות
הצפנת חיבור, קבלת מקור והענקת טבלה הן שלוש החלטות. עברו עליהן לפי הסדר לפני שתשאלו אם TLS יכול להחליף VPN.
מישהו מציע לתת ללקוח התחברות ל-PostgreSQL כדי שתביעת הוצאות תעבור מוצפנת מקצה לקצה. מנהל בסיס נתונים זקוק לסשן SQL אמיתי, ומישהו אחר מציע במקום זאת טופס אינטרנטי. שתי ההצעות פותרות את הבעיה הלא נכונה, משום שאף אחת מהן לא החלה מהפעולה שהלקוח באמת מבצע. עברו על שלוש ההחלטות לפי הסדר והשאלה אם TLS יכול להחליף VPN עונה על עצמה.
התחילו מהפעולה שהלקוח צריך
רשמו מה הלקוח צריך להשיג. שליחת תביעה, קריאת שורה אחת מדוח והרצת שאילתה מיוחדת הן שלוש פעולות שונות עם שלושה פרופילי סיכון שונים.
לאחר מכן רשמו מי מבצע את הבקשה. לקוח, סוכן תמיכה ומנהל אינם ניתנים להחלפה גם כשהם נוגעים באותה טבלה. ההבדל קובע כמה משפת השאילתות הלקוח אמור לראות אי פעם.
זוג התשובות קובע את הממשק. כל מה שאחר כך הוא מימוש, ורוב הוויכוחים על הצפנה הם בעצם ויכוחים על איזה ממשק נבחר.
שלושה בקרות, שלוש החלטות
TLS מאומת מגן על החיבור וקובע אילו זהויות TLS מתקבלות. כניסת רשת קובעת אילו מקורות בכלל יכולים להגיע למאזין. הרשאות בסיס הנתונים קובעות אילו אובייקטים ופעולות תפקיד רשאי להשתמש.
אף אחד מהשלושה אינו מחליף את האחרים, מה שהטבלה מבהירה במפורש.
| Control | What it decides | What it leaves open |
|---|---|---|
| Authenticated TLS | Connection protection and which TLS identities are accepted | Which tables a database user may touch |
| Restricted network entry | Which sources reach the listener | Whether an authenticated user should run a given statement |
| Database authorization | Which objects and actions a role may use | Whether the connection arrived by an approved path |
קראו את השורה שאתם נשענים עליה לפני שאתם מסירים אחרת. רוב העיצובים האלה נכשלים משום שבקרה הונחה ולא הוגדרה.
SQL ישיר משאיר את מדיניות בסיס הנתונים באחריות
בחיבור ישיר מאושר, שמרו גם על אימות זהות השירות וגם על מדיניות הגישה המיועדת. הפעלת TLS הופכת חיבורים מוצפנים לזמינים; היא אינה דוחה חיבורים לא מוצפנים אלא אם הגדרות הגישה דורשות זאת דרך רשומות hostssl.
כדאי לבדוק את ההבחנה הזו בהגדרות הפעילות ולא בתבנית. שרת שמציע TLS ומקבל טקסט פשוט אינו העיצוב שרוב האנשים חושבים שפרסו. קראו את כללי הגישה וראו אילו רשומות באמת דורשות זאת. בדיקה אחת זו מפרידה בין שרת שמסוגל להצפין לבין שרת מוצפן בלבד.
השתמשו בתפקידים עם ההרשאות שהעבודה דורשת בלבד, וסקרו בעלות, חברות בירושה והרשאות שניתנו באופן רחב. מודל ההרשאות של PostgreSQL הוא גבול הסמכות לאובייקטים של בסיס הנתונים.
VPN יכול להגביל אילו מכשירים מגיעים לשירות לפני שאימות בסיס הנתונים מתרחש, ושער גישה יכול לעשות משהו דומה. אף אחד מהם אינו מסיר את הצורך לתחזק את הרכיב החשוף, לנהל אישורים ולהגביל שימוש במשאבים.
תעודות לקוח הן אישור, לא ACL
תעודת לקוח יכולה להוסיף דרישה בזמן החיבור. ההגדרה clientcert יכולה לדרוש תעודה מהימנה ובמצב המחמיר יותר קשר בין שם התעודה למשתמש בסיס הנתונים.
זהו אישור חזק יותר. היא אינה רשימת הרשאה ואינה הופכת את השרת לבלתי נראה, משום שהרכיב שמקבל את החיבור עדיין מעבד תעבורת רשת ולחיצת יד. התייחסות לתעודה כרשימת גישה משאירה את ההרשאות בפועל ללא שינוי. היא גם נוטה להרחיב את הפצת התעודות, מה שיוצר את הבעיה הבאה.
תעודה חזקה שמחוברת לתפקיד עם הרשאות יתר מייצרת מנהל מאומת היטב. בדקו את התפקיד לפני שאתם חוגגים את התעודה.
בחרו בממשק הצר יותר כשהוא מתאים
עבור תביעת הוצאות, נקודת קצה של יישום שמקבלת את התביעה, אוכפת את כללי העסק ומחזירה את התוצאה המותרת של אותו משתמש מייצגת את הפעולה טוב יותר מחשבון SQL כללי.
לאחר מכן היישום משתמש בזהות בסיס הנתונים המוגבלת שלו, והלקוח לעולם אינו מקבל שפת שאילתות כתכונה. זהו משטח קטן יותר עם פחות דרכים לטעות.
זו אפשרות עיצוב ולא טענה שקוד יישום בטוח יותר אוטומטית. הקוד הזה חייב לאמת את קוראיו, להרשות כל פעולה ולאמת את הקלט שלו, וההרשאות שלו עצמו בבסיס הנתונים עדיין חשובות.
SQL ישיר נשאר נכון לאנשים ולכלים שעבודתם המאושרת דורשת זאת. הגבילו את העיצוב הזה בתפקידים, בהיקף רשת ובמגבלות תפעוליות, והשאירו ללקוחות האחרים את הממשק הצר יותר. ערבוב שתי האוכלוסיות בתפקיד אחד הוא המקום שבו הוויכוחים מתחילים.