הפרד את פרסום HTTP מהרצת היישום ומהנתונים המתמידים. פרוקסי הפוך יכול לארגן ניתוב ומגבלות, אך גישת המקור, הרשאת היישום, קיבולת ה-upstream והשחזור דורשים כל אחד אמצעי בקרה משלו.
בקשת אינטרנט חוצה מספר תחומי אחריות
שרת אינטרנט מקבל בקשות HTTP ויכול להגיש קבצים סטטיים. תהליך יישום מבצע את ההתנהגות הדינמית של הפרויקט, כגון בדיקת חשבון או שאילתת מסד נתונים. פרוקסי הפוך מקבל בקשות בשם אותו תהליך ומעביר אותן ל-upstream. תוכנית אחת עשויה למלא מספר תפקידים, אך הפרדת תחומי האחריות מקלה על החשיבה לגבי תצורה ושחזור.
עקוב אחר בקשה אחת מפתרון שם המארח ועד לתגובה. תעד היכן TLS מסתיים, איזה תהליך בוחר את הנתיב ואיזה רכיב יכול לקרוא נתוני יישום. עשה זאת גם עבור בקשת ניהול. תרגיל זה חושף לעיתים קרובות מאזין או שם מארח שנוצרו לבדיקה ונשארו נגישים בטעות. התרשים צריך לתאר את הנתיב שנפרס ולא את הארכיטקטורה שקיווית לבנות.
השתמש בקצה כדי לארגן את התנהגות HTTP
NGINX מתעד גם הגשת תוכן סטטי וגם העברת בקשות ל-upstream. ארכיטקטורת ה-worker שלו ומודולי HTTP מספקים מנגנוני תצורה, אך תצורה מסוימת עדיין קובעת את ההתנהגות. הגדר בכוונה שמות מארח, upstreams ושורשי מערכת קבצים. הגבל את הקבצים שניתן להגיש כך שתצורה, פרטי התחברות ומטא-נתוני מאגר לעולם לא יהפכו להורדה רק משום שהם נמצאים בקרבת היישום.
הגדר מגבלות מתאימות לגופי בקשה, פסקי זמן וחיבורים בהתאם ליישום. התייחס למטמונים כהחלטת נתונים: תוכן הקשור למשתמש או להרשאה אינו יכול לרשת כלל מטמון משותף בבטחה ללא סקירה. בדוק אימות והתנהגות מטמון יחד. שמור תצורה ניתנת לשחזור ואמת שינויים לפני טעינת השירות מחדש, עם נתיב חזרה ידוע לגרסה הפעילה הקודמת.
| שכבה | תחום אחריות שימושי | בדוק לפני השקה |
|---|---|---|
| קצה אינטרנט ציבורי | TLS, ניתוב שמות מארח ומגבלות HTTP | תעודות, שורשים ושמות מארח מיועדים |
| תהליך יישום | לוגיקה עסקית והרשאה | אימות, בדיקות קלט וכשל תלות |
| שירות נתונים פנימי | מצב יישום מתמיד | גישה מוגבלת ושחזור נבדק |
| רשת ספק ה-upstream | שירות הרשת החוזי | היקף ההגנה ונתיב ההסלמה |
פרוקסי הפוך אינו מסיר את החשיפה של המקור
אם המקור נשאר נגיש לציבור, לקוח עשוי להגיע אליו מבלי להשתמש בנתיב הפרוקסי המיועד. הגבל גישת מקור באמצעות תכנון הרשת ותצורת היישום כאשר הפריסה דורשת גבול זה. במכונה אחת, backend יכול לעיתים קרובות להאזין על loopback או socket מקומי. בין מכונות, השתמש בנתיבים מוגבלים מפורשים ובהגנה מתאימה לחיבור ה-upstream.
גם כותרות מועברות זקוקות לכלל אמון. קבל מידע על הלקוח המקורי רק מתווכים מהימנים, ומנע מלקוחות שרירותיים לספק ערכים שהיישום מתייחס אליהם כסמכותיים. החלט מה מופיע ביומני גישה ובדוחות שגיאה. פרוקסי יכול לשנות את המידע הזמין בכל שכבה; הוא אינו מוחק מזהי חשבון או הופך את היישום לאנונימי כלפי המפעיל שלו.
החל החלטות גישה בתוך היישום
ארכיטקטורת Zero Trust של NIST מתמקדת בהחלטות גישה למשאבים ולא באמון משתמע המבוסס רק על מיקום ברשת. החל עיקרון זה באופן קונקרטי: אמת את הקורא, הרשא את הפעולה המבוקשת ותן לחשבונות שירות רק את ההיקף הנדרש להם. בקשה המגיעה מתת-רשת פנימית לא אמורה להפוך אוטומטית לבקשת מנהל.
הפרד פונקציות ציבוריות וניהוליות היכן שמעשי. בדוק מחדש הרשאה כאשר משתמש ניגש לרשומה במקום להסתמך רק על ההתחברות הראשונית. שמור פרטי התחברות נפרדים לפרוקסי, ליישום ולמסד הנתונים. הצג שינויים בשלבים הניתנים לבדיקה, החל מנתיב רגיש צר. לקרוא לפריסה Zero Trust פחות שימושי מאשר להדגים שפעולה אסורה נדחית בפועל ברכיב האחראי עליה.
תכנן מניעת שירות ביותר משכבה אחת
קישור רשת רווי ובקשת יישום יקרה נכשלים במקומות שונים. הגבלת קצב בקצה האינטרנט עשויה לעזור להגביל דפוסי בקשות, בעוד מגבלות יישום יכולות לתחום עבודה כגון חיפושים, העלאות או ייצוא. מודול הגבלת הבקשות של NGINX מספק מנגנון אחד; המפתח והספים חייבים להתאים למשתמשים אמיתיים ולהיבדק כדי למנוע דחיית תעבורה לגיטימית.
הנחיות מניעת שירות של OWASP מתייחסות גם למיצוי משאבים בהתנהגות היישום. הצב מגבלות זמן וגודל סביב עבודה יקרה, השתמש בתורים תחומים ונטר אותות כשל. אמצעי בקרה מקומיים אינם יכולים ליצור קיבולת בקישור upstream שכבר רווי. אשר את הגנת הרשת הספציפית הכלולה בהצעה הנבחרת והכן נתיב הסלמה. לעולם אל תניח שהגנת שכבה 3–4 של קטלוג מוכיחה גם הגנה על כל עומס עבודה HTTP.
הפוך את השחזור לחלק מהפרסום
בדוק את האתר מלקוח חיצוני באמצעות שם המארח המיועד שלו. אמת HTTPS, הפניות מחדש, משאבים סטטיים, התחברויות ועסקת יישום מייצגת. אשר שמאזיני ניהול וקבצים פרטיים נשארים בלתי נגישים. סמלץ upstream מופסק ובדוק שהקצה מחזיר כשל מבוקר במקום לחשוף פרטים פנימיים או להמתין ללא הגבלה.
עבור Canvas, קרא את אמצעי הבקרה הזמינים בחשבון האחסון. עבור VPS, תחזק את קצה האינטרנט והיישום כחלק מתוכנית התפעול שלך. פורט רשת גדול הוא מפרט קיבולת, לא הוכחה שהיישום יכול להחזיק בתפוקה זו. שמור ניטור, שחזור ופרטי קשר של הספק ב-runbook. פרסם רק לאחר שאומת נתיב הבקשה בפועל ונתיב שחזור מעשי.
רשימת הבדיקה המעשית שלך.
- עקוב אחר בקשה ציבורית ובקשה ניהולית.
- הגדר שורשים מוגשים ומאזיני upstream.
- סמוך על כותרות מועברות רק מתווכים מאושרים.
- בדוק הרשאה וגבולות מטמון.
- הכן מגבלות והסלמה לכשלי רשת ויישום.
הפרטים שחשובים.
האם שרת אינטרנט יכול לשמש גם כפרוקסי הפוך?+
כן. NGINX הוא דוגמה מתועדת אחת. תפקידיו תלויים בתצורה, והיישום עדיין זקוק להרשאה ולתחזוקה משלו.
האם פרוקסי הפוך מסתיר אוטומטית את המקור?+
לא. המקור עשוי להישאר נגיש אלא אם הגדרות ניתוב, חומת אש ומאזין אוכפות את הגבול המיועד.
האם הגבלת בקשות תעצור כל התקפת DDoS?+
לא. היא מטפלת בדפוסי בקשות HTTP נבחרים. רוויה ברשת וכשלי משאבים אחרים דורשים אמצעי בקרה מתאימים ב-upstream וביישום.
לך למקור.
הפניות אלה תומכות במושגים הטכניים במדריך זה. עקוב אחר התיעוד העדכני לפני שינוי מערכת ייצור.
- NGINX: מדריך למתחילים nginx.org
- NGINX: הגבלת בקשות HTTP nginx.org
- NIST SP 800-207: ארכיטקטורת Zero Trust nvlpubs.nist.gov
- OWASP: מניעת מניעת שירות cheatsheetseries.owasp.org
הדרכה עריכתית מאת SwissOctet. הדוגמאות להמחשה. יש לאמת בנפרד מפרטי שירות, אפשרויות זמינות ותנאים חוזיים.