עבודה ברשת (לענן)— נקודת התהצגה של אדריכל אחד

מאמר
07/16/2023

במאמר זה, Ed Fisher, Security & Compliance Architect ב- Microsoft, מתאר כיצד למטב את הרשת שלך לקישוריות ענן על-ידי הימנעות מהבעיות הנפוצות ביותר.

אודות המחבר

צילום מסך של תמונת Ed Fisher.

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

עם רקע במהלך 25 השנים האחרונות הכולל אבטחה, תשתית והנדסת רשת, והעברתי שניים מהמעסיקים הקודמים שלי ל- Office 365 לפני שהצטרפתי ל- Microsoft, הייתי בצד שלך הרבה פעמים בטבלה, וזכור איך זה. אף על פי שאין שני לקוחות זהים, לרוב הלקוחות יש צרכים דומים, ולצרוך שירות סטנדרטי כגון כל פלטפורמת SaaS או PaaS, הגישות הטובות ביותר נוטות להיות זהות.

זו לא הרשת — זו הדרך שבה אתה משתמש בה!

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

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

עקרונות מנחים

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

רק בגלל שאתה יכול, לא אומר שאתה צריך: או לנקוף מחדש ד"ר איאן מלקולם מסרט הפארק היורה "... כן, כן, אבל צוות האבטחה שלך היה כל כך עסוק בשאלה אם הם יכולים או לא, שהם לא הפסיקו לחשוב אם הם צריכים."
המשמעות של אבטחה אינה מורכבות: אינך מאובטח יותר רק משום שאתה מבזבז יותר כסף, מנתב דרך מכשירים נוספים או לוחץ על לחצנים נוספים.
Office 365 גישה דרך האינטרנט: אך זה לא אותו הדבר Office 365 הוא האינטרנט. זהו שירות SaaS המנוהל על-ידי Microsoft ומנוהל על-ידיך. בניגוד לאתרי אינטרנט שבהם אתה מבקר באינטרנט, אתה למעשה יכול להציץ מאחורי הווילון, ואתה יכול להחיל את אמצעי הבקרה הדרושים לך כדי לעמוד בתקני התאימות שלך, כל עוד אתה מבין כי למרות שאתה יכול לעמוד ביעדים שלך, ייתכן שתצטרך לעשות אותם בדרך אחרת.
נקודות משנק הן חלוקה גרועה, חלוקה מותאמת לשפות אחרות הן טובות: כל אחד תמיד רוצה לרכז את כל תעבורת האינטרנט שלהם עבור כל המשתמשים לנקודה מרכזית מסוימת, בדרך כלל כדי לאפשר להם לנטר אותה ולאכוף מדיניות, אך לעתים קרובות מכיוון שהיא זולה יותר מהקצאת גישה לאינטרנט בכל המיקומים שלהם, או שזה פשוט האופן שבו הם עושים זאת. אבל נקודות החנק האלה הן בדיוק... נקודות שבהן משנקי תנועה. אין כל בעיה במניעת הגלישה של המשתמשים שלך ל- Instagram או הזרמת סרטוני חתול, אך אל תתייחס לתעבורה של אפליקציות עסקיות קריטיות למשימה באותו אופן.
אם DNS אינו שמח, אין שום דבר שמח: הרשת המעוצבת הטובה ביותר יכולה לעבור חיסוני DNS, בין אם על-ידי החזרת בקשות לשרתים באזורים אחרים של העולם או שימוש בשרתי ה- DNS של ספק שירותי האינטרנט או בשרתי DNS ציבוריים אחרים המאוחסנים במטמון של מידע על רזולוציית DNS.
רק משום שבהם השתמשת לעשות זאת, אין פירוש הדבר שבהם עליך לעשות זאת כעת: הטכנולוגיה משתנה כל הזמן Office 365 היא לא חריגה. החלת אמצעי אבטחה שפותחו ונפרסו עבור שירותים מקומיים או לשליטה בגלישה באינטרנט לא תספק את אותה רמת אבטחה, והיא יכולה להיות בעלת השפעה שלילית משמעותית על הביצועים.
Office 365 נבנה כדי שניתן יהיה לגשת אליו דרך האינטרנט: זהו זה ב- nutshell. ללא קשר למה שברצונך לעשות בין המשתמשים שלך לבין הקצה שלך, התעבורה עדיין עוברת דרך האינטרנט ברגע שהיא יוצאת מהרשת ולפני שהיא עוברת לרשת שלנו. גם אם אתה משתמש ב- Azure ExpressRoute כדי לנתב תעבורה רגישה להשהיה מהרשת שלך ישירות לרשת שלנו, קישוריות אינטרנט נדרשת לחלוטין. קבל את זה. אל תחשוב על זה יותר מדי.

היכן שבחירות שגויות נוצרות לעתים קרובות

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

אין די משאבים בקצה

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

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

חלוקה מותאמת לשפות אחרות

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

תעבורת זיהוי DNS צריכה לעקוב אחר נתיב היציאה של האינטרנט

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

ל- Proxy או לא ל- Proxy, זו השאלה

אחד הדברים הראשונים שיש לשקול הוא אם להוסיף חיבורים של משתמשי Proxy Office 365. זה קל. אל ת- Proxy. Office 365 גישה דרך האינטרנט, אך הוא אינו האינטרנט. זו הרחבה של שירותי הליבה שלך ויש להתייחס אליה ככאלה. כל דבר שייתכן שתרצה ש- Proxy ייעשה, כגון DLP או נגד תוכנות זדוניות או בדיקת תוכן, כבר זמין עבורך בשירות, ובאפשרותך להשתמש בו בקנה מידה רחב וללא צורך לפצח חיבורים המוצפנים באמצעות TLS. אך אם אתה באמת רוצה תעבורת Proxy שלא תוכל לשלוט בה באופן אחר, https://aka.ms/pnc שים לב להדרכה שלנו ב- ובקטגוריות התעבורה בכתובת https://aka.ms/ipaddrs. יש לנו שלוש קטגוריות של תעבורה עבור Office 365. מיטוב ו-Allow אמורים להיות ישירים ועקפים את ה- Proxy שלך. ניתן להציג ברירת מחדל. הפרטים מופיעים במסמכים האלה... לקרוא אותם.

רוב הלקוחות שהתעקשו להשתמש ב- Proxy, כאשר הם למעשה מבצעים את הפעולה שהם מבצעים, מבינים כי כאשר הלקוח מבצע בקשת HTTP CONNECT ל- Proxy, ה- Proxy הוא כעת רק נתב יקר נוסף. הפרוטוקולים הנמצאים בשימוש, כגון MAPI ו- RTC, אינם פרוטוקולים שרכיבי Proxy של אינטרנט מבינים, כך גם אם פיצוח TLS לא באמת מקבל אבטחה נוספת. אתה מקבל השהיה נוספת. ראה https://aka.ms/pnc מידע נוסף בנושא זה, כולל הקטגוריות מיטוב, אפשר וברירת מחדל עבור תעבורת Microsoft 365.

לבסוף, שקול את ההשפעה הכוללת על ה- Proxy ועל התגובה התואמת שלו כדי לטפל בהשפעה זו. ככל שנוצרים חיבורים רבים יותר באמצעות ה- Proxy, ייתכן שהוא יפחית את פקטור קנה המידה של TCP כך שלא תכלול תעבורה רבה כל כך. ראיתי לקוחות שבהם שרתי ה- Proxy שלהם היו עמוסים כל כך שהם משתמשים במתן קנה מידה של 0. מאחר ש- Scale Factor הוא ערך מעריכי ואנחנו אוהבים להשתמש ב- 8, כל צמצום בערך Scale Factor הוא השפעה שלילית עצומה על התפוקה.

בדיקת TLS פירושה אבטחה! אבל לא ממש! לקוחות רבים בעלי שרתי Proxy רוצים להשתמש בהם כדי לבדוק את כל התעבורה, ו משמעות הדבר היא TLS "break and inspect". כאשר אתה עושה זאת עבור אתר אינטרנט שניגישה אליו דרך HTTPS (חששות לפרטיות, למרות זאת), ייתכן שה- Proxy שלך תצטרך לעשות זאת עבור 10 או אפילו 20 הזרמות בו-זמניות במשך כמה מאות אלפיות שניה. אם יש הורדה גדולה או אולי סרטון וידאו שמעורב בו, ייתכן שחיבור אחד או יותר מחיבורים אלה יעבירו זמן רב יותר, אך ברוב החיבורים האלה יבססו, יעבירו ויסגרו במהירות רבה. ביצוע עצירה ובדיקה פירושם שה- Proxy חייב לבצע עבודה כפולה. עבור כל חיבור מהלקוח ל- Proxy, על ה- Proxy גם ליצור חיבור נפרד בחזרה אל נקודת הקצה. אז, 1 הופך ל- 2, 2 הופך ל- 4, 32 הופך ל- 64...רואה לאן אני הולך? סביר להניח שהגודל של פתרון ה- Proxy בסדר גמור עבור גלישה באינטרנט טיפוסית, אך כאשר אתה מנסה לעשות את אותו הדבר עבור חיבורי לקוח ל- Office 365, מספר החיבורים המתבצעים בו-זמנית והארוך עשוי להיות הזמנות בסדר גודל גדול יותר ממה שגודלן השתנה.

זרימה אינה חשובה, אלא אם כן

השירותים היחידים ב- Office 365 UDP הם Skype (בקרוב יוצא משימוש) ו- Microsoft Teams. Teams משתמש ב- UDP עבור תעבורת זרימה, כולל שמע, וידאו ושיתוף מצגות. תעבורת זרימה בשידור חי, למשל כאשר אתה מנהל פגישה מקוונת עם קול, וידאו והצגת חבילות או ביצוע הדגמות. אלה משתמשים ב- UDP מכיוון שאם מנות יורדות, או יוצאות מהת הסדר, המשתמש כמעט אינו מסמן בהן, והזרם יכול פשוט להמשיך.

כאשר אינך מתיר תעבורת UDP יוצאת מהלקוחות לשירות, הם יכולים לחזור להשתמש ב- TCP. אך אם מנות TCP מושמטות, הכל מפסיק עד לתפוגת הזמן הקצוב (RTO) של ההפסקה מחדש ובאפשרותך להעביר מחדש את המנה החסרה. אם מנה מגיעה מחוץ לתוקף, הכל נפסק עד שהמנות האחרות מגיעות ובאפשרותך להקצות אותה מחדש לפי הסדר. שתיהן מובילות ל תקלות מוכללות בשמע (זוכר את Max Headroom?) ווידאו (האם אתה לוחץ על משהו... הנה זה) ולהוביל לביצועים ירודים ולחוויה גרועה של משתמש. וזכור מה אני לשים למעלה על פרוקסיז? כאשר אתה כופה על לקוח Teams להשתמש ב- Proxy, אתה כופה עליו להשתמש ב- TCP. כעת אתה גורם להשפעות שליליות על הביצועים פעמיים.

מנהרות מפוצלות עלולות להיראות מפחידות

אבל זה לא . כל החיבורים Office 365 ב- TLS. אנחנו מציעים TLS 1.2 כבר לא מעט זמן, ונ להשבית גירסאות ישנות יותר בקרוב מכיוון של לקוחות מדור קודם עדיין משתמשים בהם וזה סיכון.

לאלץ חיבור TLS, או 32 מהם, לעבור על VPN לפני שהם לגשת לשירות אינם מוסיפים אבטחה. היא מוסיפה השהיה ומפחיתה את התפוקה הכוללת. בפתרונות VPN מסוימים, הוא גם כופה על UDP ליצור מנהרה דרך TCP, אשר תהיה להם שוב השפעה שלילית מאוד על תעבורת זרימה. וגם, אלא אם כן אתה עושה בדיקת TLS, אין שום יתרון, כל הירידה. ערכת נושא נפוצה מאוד בקרב הלקוחות, כעת שרוב כוח העבודה שלהם מרוחק, היא שהם רואים השפעות משמעותיות על רוחב הפס והביצועים, מהפיכת כל המשתמשים שלהם להתחבר באמצעות VPN, במקום להגדיר מנהור מפוצל לגישה למיטוב קטגוריות Office 365 קצה.

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

חטאי העבר

פעמים רבות, הסיבה לכך שבחירות שגויות נוצרות כתוצאה משילוב של (1) אי הידיעה כיצד השירות פועל, (2) ניסיון לציית למדיניות החברה שנכתבו לפני אימוץ הענן, ו- (3) צוותי אבטחה שלא יוכלו להשתכנע בקלות שקיים יותר מדרך אחת להשיג את מטרותיהם. אנו מקווים שהקישורים שלעיל והקישורים שלהלן יסייעו לך עם הראשון. חסות ניהולית עשויה להידרש כדי לעבור את השני. הטיפול ביעדים של מדיניות האבטחה, ולא בשיטות שלהם, עוזר עם השלישי. מגישה מותנית לפיקוח על תוכן, DLP להגנה על מידע, אימות נקודת קצה לאיומים של אפס ימים - כל מטרה קצה שייתכן שמדיניות אבטחה סבירה יכולה להשיג עם מה שזמין ב- Office 365, וללא תלות בהילוך רשת מקומי, במנהרות VPN כפויות ובפסקת TLS ובדיקה.

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

חריגים לכללים

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

אם בכוונתך להתיר מנהור מפוצל, אך גם להשתמש ב- Proxy עבור תעבורת אינטרנט כללית, ודא שקובץ PAC שלך מגדיר מה חייב להיות ישיר וכן כיצד אתה מגדיר תעבורה מעניינת עבור מה שעובר דרך מנהרת ה- VPN. אנו מציעים קבצי PAC לדוגמה ב https://aka.ms/ipaddrs זה מקל על ניהול.

מסקנה

עשרות אלפי ארגונים, כולל כמעט כל ה- Fortune 500, משתמשים Office 365 כל יום לפונקציות הקריטיות של המשימה שלהם. הם עושים זאת בצורה מאובטחת, והם עושים זאת דרך האינטרנט.

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