כללי AWS Client VPN שייכים למשאב, לא לתת-הרשת

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

מיקום תת-הרשת הוא ניתוב, לא הרשאה

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

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

קבוצת השיוך של Client VPN היא הידית

בנקודת קצה של AWS Client VPN המשויכת לתת-רשת, הסדר המתועד הוא ספציפי. החילו את קבוצת האבטחה המיועדת על שיוכי רשת היעד של נקודת הקצה, ואז התירו את התעבורה הנדרשת בקבוצת האבטחה של המשאב תוך שימוש באותה קבוצת Client VPN כמקור.

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

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

מה שקבוצת שיוך אחת אינה יכולה להבחין

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

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

שינוי שם הקבוצה אינו יוצר זהות, ושכפולה לכל צוות רק מכפיל את השיוכים שיש לבקר.

אל תעתיקו את הכלל הזה לכל תכנון VPN

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

העברת תעבורה דרך מכשיר תווך אינה משמרת הפניית קבוצת אבטחה של מקור כפי שעושה תעבורה ישירה ממופע למופע. AWS מתעדת שתכנונים כאלה עשויים להזדקק לכתובות המקור הפרטיות או ל-CIDR המתאימים במקום הפניית קבוצה. הנוהל של Client VPN מנוהל אינו הוכחה שהקבוצה המחוברת של כל שער פועלת כאסימון זהות אוניברסלי לחבילות מועברות.

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

בדקו את הגבול האפקטיבי

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

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

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