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

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

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

האם הקבלן צריך גישה ישירה למסד הנתונים?

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

• מסד נתונים של staging עם עותק עדכני ומנוקה מכסה את רוב עבודת האבחון וההעברה, בלי לחשוף רשומות של לקוחות אמיתיים.
• API של האפליקציה או API ניהולי מספיק לעיתים קרובות כשהקבלן צריך לשנות נתונים ולא את הסכמה.
• עותק קריאה (read replica) נותן לעבודת ניתוח שדורשת קריאה בלבד מקום לרוץ בלי לגעת במסד הראשי.

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

צרו משתמש עם הרשאות מוגבלות ותפוגה מובנית

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

ב-PostgreSQL, משתמש שיכול לקרוא רק שתי טבלאות ומפסיק לעבוד בתאריך קבוע נראה כך:

CREATE ROLE contractor_jo LOGIN PASSWORD 'generated-elsewhere'
  VALID UNTIL '2026-11-08 18:00+00';
GRANT CONNECT ON DATABASE app TO contractor_jo;
GRANT USAGE ON SCHEMA public TO contractor_jo;
GRANT SELECT ON orders, order_items TO contractor_jo;

ב-MySQL יש CREATE USER ... PASSWORD EXPIRE INTERVAL 14 DAY, ושירותים מנוהלים כמו RDS, Cloud SQL ו-Supabase מאפשרים לעשות את אותו הדבר מהקונסולה שלהם או עם טוקנים קצרי חיים מבוססי IAM. השתמשו במה שהפלטפורמה שלכם תומכת בו, וצרו את הסיסמה במנהל סיסמאות במקום להקליד אחת בעצמכם.

תנו את ההרשאות המינימליות שמספיקות למשימה שהוגדרה. לעבודת אבחון זה SELECT על טבלאות מסוימות. להעברה זו גישת כתיבה לאובייקטים שישתנו ולשום דבר אחר. תפקידי owner ו-superuser אף פעם לא מתאימים לחשבון זמני.

איך שולחים לקבלן פרטי התחברות זמניים למסד הנתונים

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

1. אמתו את זהות הנמען בערוץ שאתם כבר סומכים עליו, למשל שרשור האימייל של החוזה או שיחה. כתובות שנראות דומות הן דרך נפוצה שבה פרטי התחברות מגיעים לתיבה הלא נכונה.
2. צרו קישור סודי חד-פעמי שמכיל רק את הסיסמה. ב-LinkPilot הטקסט מוצפן בדפדפן שלכם לפני שהוא נשמר, העותק השמור מושמד בפעם הראשונה שהקישור נפתח, ואפשר לבחור תפוגה של שעה אחת, 24 שעות או שבעה ימים. בחשבונות Pro אפשר לקבוע תפוגה מותאמת, להוסיף ביטוי סיסמה ולראות ביומן הביקורת מתי הקישור נפתח.
3. שלחו את הקישור בשרשור הרגיל, עם הערה של שורה אחת: למה הוא משמש ומתי פג תוקפו. אל תכתבו את שם המשתמש באותה הודעה עם הקישור.
4. שלחו את פרטי החיבור בנפרד: שרת, פורט, מסד נתונים, שם משתמש והאם נדרש TLS. אימייל שני או תגובה בכרטיס מספיקים, כי שום דבר שם לא סודי כשהוא לבדו.
5. העבירו את ביטוי הסיסמה בערוץ אחר אם הגדרתם אחד, למשל בהודעת SMS או בשיחה.
6. בקשו מהקבלן לאשר שהקישור נפתח. אם מופיעה הודעה שהוא כבר נצפה והקבלן לא פתח אותו, התייחסו לסיסמה כאל סיסמה שדלפה והחליפו אותה.

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

הגבילו את החיבור

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

• דרשו TLS בחיבור, ובקשו מהקבלן להגדיר sslmode=require או את המקבילה בתוכנה שלו. תוכנות רבות חוזרות בשקט לטקסט גלוי אם לא מתעקשים.
• הגבילו את המקור באמצעות רשימת IP מורשים, VPN או שרת bastion. הוספת הכתובת של הקבלן לרשימת ההיתרים למשך העבודה מהירה להגדרה ומהירה להסרה.
• שתפו רק את מה שהמשימה דורשת. הקבלן לא צריך את תרשים הרשת הפנימית, את מסדי הנתונים האחרים בשרת או את כתובת ה-URL של קונסולת הניהול.

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

עקבו אחרי החשבון וסגרו אותו

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

כשהמשימה מסתיימת, או כשההיקף משתנה, עשו ארבעה דברים באותו יום:

1. מחקו או השביתו את המשתמש וודאו שהוא כבר לא יכול להתחבר.
2. הסירו את היתר הרשת שהוספתם לקבלן.
3. החליפו כל סוד שעבר יחד עם פרטי ההתחברות, למשל סיסמה של אפליקציה שהייתה באותו כרטיס.
4. תעדו את המסירה: למי הייתה גישה ולאילו משאבים, ממתי ועד מתי ומה הסיבה. שמרו את התיעוד, לא את הסיסמה.

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

קריאה נוספת

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