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