ניהול משתני סביבה וסודות בבקאנד - איך לא לדלוף מפתחות API

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

למה אסור להטמיע סודות בקוד

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

משתני סביבה כפתרון הבסיסי

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

מנהלי סודות ייעודיים בסביבת ייצור

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

סודות נפרדים לכל סביבה

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

סיבוב סודות כהרגל, לא רק כתגובה לאירוע

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

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

לסיכום

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

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

הצטרפו לקהילה בדיסקורד