# הפרד את קצה האינטרנט הציבורי שלך מהיישום | SwissOctet Insights

https://swissoctet.com/he/insights/separate-the-web-edge-from-the-app/

SwissOctet / תובנות / ווב ו-onion ווב ו-onion יישומי · 4 דקות קריאה

הפרד את קצה האינטרנט הציבורי שלך מהיישום

תן לשרת האינטרנט, ל-reverse proxy וליישום אחריויות נפרדות, עם גישת מקור מכוונת, TLS, מגבלות בקשות ונתיב אירוע.

מאת SwissOctet Editorial שמור מדריך העתק קישור

בעמוד זה 01 בקשת אינטרנט חוצה מספר תחומי אחריות 02 השתמש בקצה כדי לארגן את התנהגות HTTP 03 פרוקסי הפוך אינו מסיר את החשיפה של המקור 04 החל החלטות גישה בתוך היישום 05 תכנן מניעת שירות ביותר משכבה אחת 06 הפוך את השחזור לחלק מהפרסום רשימת הבדיקה המעשית שלך מקורות וקריאה נוספת חזרה לספרייה התשובה הישירה הפרד את פרסום HTTP מהרצת היישום ומהנתונים המתמידים. פרוקסי הפוך יכול לארגן ניתוב ומגבלות, אך גישת המקור, הרשאת היישום, קיבולת ה-upstream והשחזור דורשים כל אחד אמצעי בקרה משלו.

01 בקשת אינטרנט חוצה מספר תחומי אחריות

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

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

02 השתמש בקצה כדי לארגן את התנהגות HTTP

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

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

שכבה תחום אחריות שימושי בדוק לפני השקה

קצה אינטרנט ציבורי TLS, ניתוב שמות מארח ומגבלות HTTP תעודות, שורשים ושמות מארח מיועדים

תהליך יישום לוגיקה עסקית והרשאה אימות, בדיקות קלט וכשל תלות

שירות נתונים פנימי מצב יישום מתמיד גישה מוגבלת ושחזור נבדק

רשת ספק ה-upstream שירות הרשת החוזי היקף ההגנה ונתיב ההסלמה

03 פרוקסי הפוך אינו מסיר את החשיפה של המקור

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

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

04 החל החלטות גישה בתוך היישום

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

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

05 תכנן מניעת שירות ביותר משכבה אחת

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

הנחיות מניעת שירות של OWASP מתייחסות גם למיצוי משאבים בהתנהגות היישום. הצב מגבלות זמן וגודל סביב עבודה יקרה, השתמש בתורים תחומים ונטר אותות כשל. אמצעי בקרה מקומיים אינם יכולים ליצור קיבולת בקישור upstream שכבר רווי. אשר את הגנת הרשת הספציפית הכלולה בהצעה הנבחרת והכן נתיב הסלמה. לעולם אל תניח שהגנת שכבה 3–4 של קטלוג מוכיחה גם הגנה על כל עומס עבודה HTTP.

06 הפוך את השחזור לחלק מהפרסום

בדוק את האתר מלקוח חיצוני באמצעות שם המארח המיועד שלו. אמת 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. הדוגמאות להמחשה. יש לאמת בנפרד מפרטי שירות, אפשרויות זמינות ותנאים חוזיים.

חבר את הידע תשתית קשורה.

Canvas Web שווייץ Vector VPS שווייץ Pulse NVMe שווייץ Transit 40 שווייץ

שמור על החוט הערות השדה הבאות שלך.

חקור כל מדריך

הערת שדה / 01

+

תפעול היום השני יישומי

בסיס הקשחה של Linux VPS שאפשר לתחזק

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

6 דקות קריאה קרא את המדריך

הערת שדה / 02

+

ווב ו-onion יסודות

אחסון ווב או VPS: בחרו את העבודה שאתם רוצים לקחת עליה אחריות

השוו דרישות יישום, שליטה ואחריות תחזוקה במקום להתייחס ל-VPS כשלב הבא האוטומטי לכל אתר.

6 דקות קריאה קרא את המדריך

הערת שדה / 03

+

ווב ו-onion יישומי

מדריך מעבר לדומיין, DNS ו-TLS לשרת חדש

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

4 דקות קריאה קרא את המדריך