משימה מתוזמנת או התחברות אנושית: איזו זהות ה-API צריך לראות?

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

שלושה שערים שנראים כאחד

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

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

הנתיב האינטראקטיבי הוא תבנית אוטומציה גרועה

כתיבת התחברות של אדם כסקריפט מפתה כי היא עובדת פעם אחת. הסקריפט שומר סיסמה, אולי זרע סיסמה חד-פעמית, ואז תלוי באתגר שנועד לדרוש אדם. השיטה המומלצת הנוכחית לאבטחת OAuth, RFC 9700, אוסרת את מענק resource-owner-password-credentials ומסבירה מדוע הוא מתאים באורח רע לאימות דו-גורמי ולריבוי שלבים.

החלופה הנתמכת היא בדרך כלל זרימת לקוח חסוי שבה שרת ההרשאות מאמת את היישום ומנפיק אסימון. מענק client-credentials ב-RFC 6749 סעיף 4.4 הוא דוגמה אחת. עצם קיומו אינו אומר שכל API מקבל אותו, או שניתן להחליף בו משימה שהואצלה על ידי משתמש, כי אלה שאלות לבעל השירות. שאלו איזה מודל ללא השגחה השירות תומך בו לפני שתכתבו קוד.

היכן עדיין מקומו של VPN

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

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

השוו את שני התכנונים בכנות

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

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

מה לאמת לפני המסירה

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

curl -sS -o /dev/null -w '%{http_code}\n' \
  -H "Authorization: Bearer TOKEN" https://api.example.com/v1/records

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