איך משתפים מפתחות API בצורה מאובטחת

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

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

למה לא בטוח לשלוח מפתח API ב-Slack או באימייל?

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

• בשניהם אפשר לחפש לנצח. מפתח ששותף ב-2023 הוא המפתח שממנו תתחיל התקרית הבאה שלכם. תוקפים שנכנסים לצ'אט או לתיבת דואר של חברה מחפשים בהם באופן קבוע בדיוק את המחרוזות שנראות כמו מפתחות API: sk_live, AKIA, ghp_, Bearer.
• שניהם מסתנכרנים לכל מקום. טלפונים, מחשבים ניידים אישיים, טאבלטים: מכשירים שבקרות האבטחה שלכם לא חלות עליהם ומדיניות המחיקה מרחוק לא מגיעה אליהם.
• שניהם מיוצאים. בדיקות ציות, גילוי מסמכים בהליך משפטי וייצוא של סביבת העבודה יוצרים כולם עותקים של ההיסטוריה. כל ייצוא הוא עוד מקום שבו המפתח נמצא.
• שניהם שורדים את עזיבת העובד. ההתקשרות עם הקבלן מסתיימת, אבל שרשור ההודעות הפרטיות עם מפתח ה-Stripe שלכם נשאר.

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

לפני השיתוף: צמצמו את המפתח

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

• הגבילו את ההרשאות. מפתחות מוגבלים של Stripe, טוקני גישה אישיים מפורטים (fine-grained) של GitHub, מדיניות IAM של AWS שמוגבלת לפעולות ולמשאבים מסוימים: רוב הספקים הרציניים מאפשרים ליצור מפתח שיכול לעשות רק את הדבר האחד שהנמען צריך.
• העדיפו הרשאת קריאה בלבד, אלא אם באמת צריך גם הרשאות כתיבה.
• הגדירו תפוגה אצל הספק כשהפלטפורמה תומכת בזה (טוקנים מפורטים של GitHub, פרטי התחברות זמניים של AWS דרך STS). כך גם למפתח שדלף יש תאריך תפוגה, בלי קשר לכל מה שתעשו בהמשך.
• תנו למפתח שם על פי הנמען (vendor-x-readonly), כדי שבעוד חצי שנה ביטול המפתח יהיה החלטה של מבט אחד ולא חפירה ארכיאולוגית.

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

דפוס המסירה

1. צרו את המפתח במערכת המקור (AWS, Stripe, ה-API שלכם) עם ההרשאות המינימליות, כמו שתואר למעלה.
2. הדביקו אותו בקישור סודי חד-פעמי כשהאפשרות מחיקה לאחר קריאה מופעלת, ועם התפוגה הקצרה ביותר שמתאימה: 1 שעה היא ההגדרה הקצרה ביותר, אחריה 24 שעות ו-7 ימים, ובתוכנית Pro אפשר לבחור תאריך ושעה משלכם. מספיק זמן למסירה עצמה, ולא יותר.
3. הוסיפו ביטוי סיסמה ושלחו אותו בערוץ אחר: את הקישור באימייל, את ביטוי הסיסמה ב-SMS או בהודעה פרטית ב-Slack. ב-LinkPilot ביטוי הסיסמה, תפוגה מותאמת אישית ויומן הביקורת הם תכונות של תוכנית Pro ב-$29 לחודש. אם אחד הערוצים דולף, לתוקף עדיין יש רק חצי מהפאזל. (LinkPilot מחשב hash לביטוי הסיסמה בדפדפן עם SHA-256 לפני שהוא נשלח; ביטוי הסיסמה עצמו לעולם לא מגיע למסד הנתונים או ללוגים של השרת, ומספר הניסיונות מוגבל ל-5 בדקה לכל כתובת IP.)
4. שלחו את הקישור.
5. ודאו בערוץ נפרד שהנמען קיבל אותו, ובדקו את ציר הזמן של יומן הביקורת: צפייה אחת, בשעה הצפויה, מהמיקום הצפוי. זה האישור שלכם.

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

דוגמה: העברת מפתח מוגבל של Stripe

# generate a restricted key with the minimum needed scopes
stripe api_keys create \
  --restricted \
  --display-name "vendor-x-readonly"

# pipe the resulting key into a LinkPilot secret
curl -X POST https://api.uselinkpilot.com/v1/secrets \
  -H "Authorization: Bearer $LP_KEY" \
  -d 'payload=sk_restricted_…' \
  -d 'expires_in=3600' \
  -d 'burn_after_read=true'

מה הנמען רואה: פתיחת הקישור מציגה דף הצגה, ולא את המפתח. בוטים של תצוגה מקדימה וסורקי אימייל שטוענים את הכתובת מראש מקבלים רק מטא-נתונים, כי צפייה נרשמת רק בפעולת ההצגה המפורשת, אף פעם לא בבקשת GET. כשהנמען לוחץ על "הצגה" (ומזין את ביטוי הסיסמה, אם הוגדר), הוא רואה את המפתח פעם אחת בלבד. אחרי זה התוכן השמור נדרס והקישור מחזיר HTTP 410. גם אם האימייל מועבר הלאה בכל החברה, רק מי שצפה ראשון יכול היה לקרוא אותו, ויומן הביקורת מראה לכם מי זה היה.

איזה ערוץ לאיזו מסירה

מה עושים אם מפתח API דלף?

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

1. הנפיקו קודם את המפתח החלופי, אם הספק מאפשר שני מפתחות פעילים. כך שירותים לגיטימיים שמשתמשים במפתח לא יושבתו.
2. בטלו את המפתח שדלף אצל הספק. זה הצעד היחיד שבאמת מסיים את החשיפה; מחיקת ההודעה ב-Slack לא מסיימת אותה.
3. מסרו את המפתח החדש כמו שצריך: קישור חד-פעמי, ביטוי סיסמה, תפוגה קצרה, לפי הדפוס שלמעלה.
4. בדקו ביומני השימוש של הספק את המפתח שדלף, בין רגע החשיפה לרגע הביטול. קריאות API לא צפויות אומרות שזו כבר תקרית אבטחה, ולא רק ניקיון.
5. תקנו את המקור של ההדבקה: העבירו את הסוד לכלי משתני הסביבה שלכם שמוחרגים ב-.gitignore, הפעילו סריקת סודות בשירות אירוח המאגרים, או עדכנו את נוהל העבודה שהורה למישהו לשלוח אותו בהודעה פרטית.

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

ממה להימנע

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

מתי קישור חד-פעמי הוא הכלי הלא נכון

כדי להיות כנים, לדפוס הזה יש גבולות:

• פרטי התחברות בין מכונות שייכים למנהל סודות או למאגר המובנה של הפלטפורמה, ומוזרקים בזמן הפריסה או בזמן הריצה. אדם שלוחץ על קישור אינו שלב בפריסה.
• פרטי התחברות משותפים לטווח ארוך שייכים למנהל סיסמאות עם בקרת גישה אמיתית ואפשרות לבטל גישה לכל אדם בנפרד.
• החלפה בתדירות גבוהה (מפתחות שמתחלפים כל שעה) צריכה להיות אוטומטית מקצה לקצה; לאנשים ולקישורים אין מקום בתהליך הזה בכלל.
• סודות שאסור בשום אופן שצד שלישי כלשהו ייגע בהם: העבירו את המסירה לערוץ לא מקוון. עדכון, 29 בספטמבר 2026: במקור נכתב בסעיף הזה ש-LinkPilot לא טוען להצפנה מקצה לקצה (E2EE), ושכדאי להשתמש במקומו בכלי עם הצפנה מקצה לקצה. היום LinkPilot מצפין טקסט בדפדפן, כך שהוא שומר רק טקסט מוצפן, וגם קבצים מצורפים מוצפנים יחד איתו. הדף ארכיטקטורת האבטחה מפרט בדיוק מה מוגן ומה לא.

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

לקריאה נוספת

• למה כתובות URL מדליפות מידע רגיש
• שיתוף סיסמאות מאובטח: השוואה בין 5 שיטות
• ארכיטקטורת האבטחה של LinkPilot
• השוואת ממשקי API של מקצרי קישורים
• מחולל קישורים סודיים בחינם

מקורות

• Stripe Docs, API keys: limit access with restricted keys.
• GitHub Docs, Managing your personal access tokens.
• AWS IAM User Guide, Temporary security credentials in IAM.