Amazon Virtual Private Cloud

VPC (קיצור של Virtual Private Cloud) היא רשת מבודדת לוגית ב Data Center של AWS. היא באה לדמות Data Center פרטי של ארגון (כלומר: ב On-Premises), בו תעבורת הרשת, והגישה לשרתים מוגבלת למי שנמצא בתוך ה Data Center.

• מבחינה טכנית, ניתן לחשוב עליה כתת-רשת (subnet) בתוך אמזון שמוקצה רק לכם.
• מבחינת אבטחה, ניתן לחשוב עליה כ VLAN [א] - רשת משותפת שהתשתית יודעת להפריד בין packets של תתי-רשתות נפרדות - הפרדה מוחלטת.

VPC הוא לא שירות פרימיום. הוא כמעט חינם, ואם אתם פועלים ב AWS ולא משתמשים בו - כדאי להכיר.

בניגוד לניהול רשת "קלאסי" בו צריך להכיר את הראטורים השונים ולתכנת אותם, העבודה ב VPC היא ברמת התוכנה ובממשק אחיד של אמזון - סוג של Software Defined Networking (קונספט שגם תופס תאוצה ברשתות On-Premises).

למרות שה VPC מבודד אותנו משאר העולם, ניתן לבצע קשרים מאובטחים עם רשתות אחרות:

• VPN שיחבר בין רשת אחרת של הארגון (למשל - המשרד) ל VPC בו נמצאים השרתים.
• VPC Peering - חיבור (שניתן להגדיר את מידת החופש שלו) בין שני VPCs, למשל: VPC של ספק שירות או לקוח, או אולי VPC אחר של הארגון שלכם (כי לעתים נכון ליצור בענן כמה VPCs לאותו הארגון).

אם אתם רוצים אבטחה אפילו גבוהה יותר, אז VPC תומך במצב של הפרדה מוגברת - מה שנקרא "dedicated tenant".
כל ה EC2 instances שנוצרים בתוך VPC שהוא dedicated tenant הם dedicated instances (כלומר: השרת הפיסי רק משרת אתכם - אין לכם "שכנים"), וגם חלק מתשתיות הרשת יהיו מופרדות בצורה טובה יותר - עבורכם.
השירות הזה, באופן טבעי - מגדיל את העלויות בצורה משמעותית.

מה החשיבות של VPC, ומדוע לא כדאי לעבוד באמזון בלעדיו?

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

אמנם גם ללא VPC ניתן להגן בעזרת "Firewall" על השרתים שלכם: ניתן לאגד שרתים דומים בקבוצה הנקראת "קבוצת אבטחה" (Security Group), ואז להגדיר:

• תקשורת נכנסת - כתובות IP, פורטים, ופרוטוקולים (tcp, HTTP, וכו') ספציפיים שיכולים לגשת למשאבים בקבוצת האבטחה.
• תקשורת יוצאת - כתובות IP, פורטים, ופרוטוקולים אליהם יכולים המשאבים בקבוצת האבטחה לפנות.

הגישה הזו היא מוגבלת:

• ניתן להגדיר רק הרשאות (whitelist) ולא חסימות (blacklist).
• אם אתם רוצים לבודד בין קבוצות שרתים שלכם ("ניתן לגשת לבסיסי הנתונים רק מתוך ה Application Servers") היא הגדרה כמעט בלתי אפשרית ללא VPC: כתובות ה IP משתנות כל הזמן, ויהיה עליכם לעקוב אחר השינוי ולעדכן את ה Security Groups. נתקן: אפשרי - אך לא סימפטי לתחזוקה.

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

עוד צורך חשוב ש VPC פותר הוא בידוד הרמטי יותר בין חלקים במערכת, למשל: משאבים המשרתים מחלקות שונות, בין dev ל production, וכו'. הפתרון שהיה מקובל קודם ל VPC הוא לנהל חשבונות (account) שונים ב Amazon - מה שהקשה מאוד על כמה פעולות אחרות (למשל: העברת נתונים בצורה מאובטחת בין החשבונות).

עוד כמה שימושים ל VPC:

• Compliance - אם יש תקן שמחייב אתכם להגביל ו/או לעשות Audit לכל מי שניגש לקבוצה מסוימת של משאבים - VPC יהפוך את המלאכה לקלה יותר.
• הפרדה בין dev/test ל production - לצורך הגנה בפני טעויות אנוש.
• הפרדה דומה בין יחידות שונות בארגון, למשל: ארגון ה BI רוצה אחריות משלו על החשבון, והפרדה מכל מה שמתרחש ב R&D.

"The "Default VPC

החל מ 2014 [ב] כל חשבון חדש שנוצר באמזון, נוצר ב Default VPC - שזו בעצם תשתית התקשורת המשופרת של אמזון שמאפשרת הגדרה של VPCs. אם אתם נמצאים "ב Default VPC" - אין הכוונה שבאמת אתם משתמשים ב VPC, אלא שאתם נמצאים על התשתית החדישה יותר של אמזון, ברשת משותפת… ביחד עם עוד כמה אלפי ארגונים.

תשתית הרשת הישנה יותר של AWS נקראת "EC2 Classic". היא מוגבלת יותר:

• לא מאפשרת יצירה של VPC.
• פחות גמישות ב Security Groups: לא ניתן להגביל outbound traffic, לא ניתן להחליף באופן דינאמי Security Group למשאב).
• פחות גמישות בהגדרות רשת בסיסיות: לא ניתן לתת למשאב יותר מכתובת IP אחת, קשה יותר לשלוט בהגדרות ה DHCP, DNS, ו NTS של המשאבים.
• לא ניתן להשתמש ב Enhanced Networking (משלמים יותר, מקבלים רשת יותר "יציבה" ומהירה).
• וכו'.

אם אתם נמצאים על EC2-Classic - אז כדאי לעבור "Default VPC" גם אם אתם לא מתכננים לנהל VPC משלכם. יבוא היום ואמזון תכריח אתכם לעבור. בכל מקרה, מעבר שכזה הוא תהליך מורכב - אם אתם לא מוכנים לספוג downtime. כלי שיכול להקל בכזה מעבר הוא AWS ClassicLink.

ב Default VPC, כל מכונה חדשה שתוסיפו תקבל אוטומטית כתובת IP ציבורית באינטרנט - בכדי לתאום לאחור להתנהגות של EC2 Classic. זה לא יקרה ב VPC שהוגדר על ידכם.

כמו כן, ב Default VPC כל שרת שלכם יוכל לגשת לאינטרנט - כי הוגדר לו Internet Gateway כברירת מחדל.
ב VPC משלכם, ברירת המחדל היא ששרתים לא יכולים לגשת לאינטרנט - אלא אם חיברתם אותם בעצמכם ל Internet Gateway.
מדוע זה חשוב? כי אם יש לכם שרת שלא אמור מתוקף תפקידו לגשת לאינטרנט (למשל Database Server) - גישה לרשת יכולה לרמז על תוכנה עוינת שרצה על המחשב ושולחת מידע לתוקף. תוכלו למנוע זאת ע"י בקרה ושליטה בתקשורת היוצאת מהרשת שלכם.

יוצאים לדרך!

יצירה של VPC היא פעולה דיי פשוטה, והיא נראית כך:

1. אנו יוצרים את ה VPC ומגדירים לו טווח כתובות (cidr-block) של בטווח הכתובות השמורות לרשתיות פרטיות, בכדי לא להתנגש עם כתובות באינטרנט.

--

CIDR (קיצור של Classless Inter-Domain Routing) היא שיטה להגדרת תתי-רשתות (subnets) שיכולה לנצל את טווח הכתובת של IPv4 בצורה יעילה יותר, ואולי מעט יותר קלה להגדרה מהשיטה של subnet-masks.

התחביר של CIDR נראה כך:

<Base IP address> / <suffix>

כאשר כתובת ה IP הבסיסית היא כתובת בת 4 מספרים בני 8 ביט (0-255) - סה"כ 32 ביט, וה Suffix הוא מספר בין 0 ל 32 - המתאר כמה ביטים בכתובת הבסיס הם "קבועים" ומתארים בעצם את טווח תת-הרשת.

למשל:
127.0.0.0/24 - היא צורה לתאר תת-רשת עם טווח הכתובות 127.0.0.0 עד 127.0.0.255.
24 ביט הם שלשה מספרים, ולכן 127.0.0 הוא החלק ה"קבוע" בטווח הכתובת.

עוד דוגמה:
30.0.0.0/8 היא צורה לתאר תת-רשת שטווח הכתובת שלה הוא 30.0.0.0 עד 30.255.255.255.
8 ביט הם מספר אחד, ולכן רק 30 הוא החלק ה"קבוע" בטווח הכתובות.


ניתן להשתמש ב CIDR בכתיבה מקוצרת, ולהשמיט מכתובת הבסיס אפסים שאינם קבועים. למשל הדוגמה הראשונה יכולה להיכתב כ 127.0.0/24 והדוגמה השניה יכולה להיכתב כ 30/8. ניתן למצוא עוד מגוון דוגמאות בערך בוויקיפדיה.

--

בדוגמה שלנו הגדרנו את 10.0.0/16 - הטווח בין 10.0.0.0 ל 10.0.255.255 - טווח אפשרי של 65K כתובות (המקסימום של VPC מאפשר). אנו כמובן משתמשים באחד הטווחים של פרוטוקול ה IP לרשתות פרטיות - לא נרצה התנגשות עם כתובות של שירותים ברחבי האינטרנט. התוצאה של הפעולה מחזירה לנו id של ה VPC שרק נוצר, במקרה שלנו: vpc-a01106c2.


2. בתוך ה VPC עלינו להגדיר subnet לכל Availability Zone. ה VPC, כקונספט לוגי שמכיל הגדרות, יכול להתפרס על גבי Region של אמזון, אבל ה subnet הספציפי יכול לחיות רק ב Availability Zone - שהרי זהו Data Center פיסי.

ה Subnet יהיה בטווח קטן יותר של כתובות IP - כ 256 כתובות, בכדי לא "לשתות" את כל הכתובות של ה VPC, ואנו נייצר אותו ב AZ בסימון a של אירלנד (eu-west1).

3. הנה אנו מגדירים subnet נוסף ב AZ בסימון b, ובאופן דומה. שימו לב שמרחב הכתובות של ה subnet הזה הוא שונה.


התוצאה היא המבנה הבא:

לכל subnet יהיה id, למשל "subnet-d38d91dd" וברגע שנבקש להקים EC2 instance - יהיה עלינו לציין באיזה subnet ליצור אותם.

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

1. אנו יוצרים Internet Gateway, רכיב של AWS שמאפשר גישה לאינטרנט. בהפעלת הפעולה - נקבל id (למשל "igw-c0a643a9")

2. אנו מוסיפים route ל "router הווירטואלי שלנו", שאומר שכל כתובת בעולם (0.0.0.0/0), אם לא נמצאה בתוך ה subnet - הולכת ל internet gateway שלנו.

ה VPC מחזיק טבלת ניתוב (routing table) לכל ה subnets, אך ניתן להגדיר טבלאות ניתוב שונות - ולקשר כל subnet לטבלת ניתוב שונה.


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

לשמחתנו ניתן לבצע את כל הפעולות עם ה aws console - ממשק אחיד לו ניתן לכתוב סקריפטים (ניתן גם דרך ה UI של אמזון - למי שמעדיף). לא צריך להתחבר ל router החומרה ולעשות את זה מולו ישירות - כמו פעם.


החיבור של העולם פנימה לתוך ה VPC הוא קצת יותר מורכב: יהיו שם כנראה ELB, Route53, NAT, ואולי גם WAF. לא אכנס לפרטים כיצד להגדיר חיבור שכזה.

אז איך מתכננים VPC?

"VPC ניתן להגדיר ב-2 אופנים: VPC יחיד, או ריבוי VPCs - אך יש אלפי תצורות שונות בהן ניתן להגדיר את שני האופנים" -- יועץ AWS זקן וחכם.

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

• VPCs בניהול ה R&D:
• Production
• Dev/Test - ההפרדה נעשתה כדי למצמצם טעויות אנוש שישפיעו על production.
  יש גם ארגונים שלא מאפשרים למפתחים בכלל לגשת ל production - וזו דרך פשוטה לנהל זאת.
• VPC עבור ה IT:
• מערכות ה Active Directory, מערכת ניהול הכספים, נוכחות משתמשים ומערכת ה HR - לא צריכות להשפיע על production, ואף מפתח לא זקוק לגישה אליהן. לכולם יותר נוח שרק לאנשי ה-IT תהיה גישה לרשת זו.
• VPC עבור ה Data Science
• צוות ה Data Science זקוק להרשאות Admin ל AWS כי הם מרימים ומורידים מכונות (למשל EMR) בכמויות סיטונאיות, וחס וחלילה לא נרצה שיפגעו בפרודקשיין. "אופס סגרתי לכם 100 מכונות בפרודקשיין, לא שמתי לב בגלל המספר הקטן" - הוא לא מה שאתם רוצים לשמוע...

החלוקה לתתי-ארגונים היא כמובן שיקול ארגוני: לפעמים היא במקום, ולפעמים לא.

כמו כן, ברוב הפעמים המערכת שלנו תהיה מפוזרת בכמה Regions של אמזון. לצורך הפוסט אני מפשט את התמונה ומניח שאנו פעילים רק ב Region יחיד - ה Region (העתידי) של IL-Center-1 ;-) .


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

לחצו להגדלה!

1. בתוך ה VPC, יש לנו 2 (בד"כ 3 או 4 - לא היה לי כח לצייר) AZs זהים. בגלל שכל AZ הוא Data Center מבודד פיסית (ואנו רוצים את היתירות הזו) - יהיה עלינו להרכיב subnets סימטרים ב AZs השונים, שיבדלו ע"י טווח כתובות שונה (כלומר: ה CIDR שלהם). כמובן שעדיף לעשות זאת בעזרת כלים אוטומטיים (למשל: Cloud Formation) ולא בצורה ידנית.
   לצורך פשוט התרשים, פירטתי רק את המבנה של AZ סימן a - אנא הניחו ש AZ סימן b הוא סימטרי לחלוטין, גם בתוכן וגם בחיבוריות פנימה והחוצה.
2. ה Traffic שמגיע מבחוץ (משתמשים באינרטנט, למשל) עובר דרך ה DNS של אמזון (קרי: route 53). ה DNS מספק Load Balancing ראשוני בין ה AZs השונים. משם ה Traffic עובר ל Router של אמזון שמנתב אותו כל פעם ל AZ שנבחר.
3. הכניסה הראשונית היא ל subnet "ציבורי" אליו ניתן לגשת מכל מקום באינטרנט, ושם אנו מבצעים את הסינון הראשוני של התעבורה. אמזון מספקת לנו שירות, המגיע כ AMI שעלינו להתקין, שנקרא VPN NAT Gateway - שהוא בעצם Reverse Proxy. רוב הסיכויים שנרצה סינון קצת יותר רציני של Traffic, למשל - WAF (קיצור של Web Application Firewall). לאמזון יש גם שירות שכזה - אך הוא עדיין מאוד בסיסי.
1. אם הרעיון של ה public subnet מזכיר לכם DMZ ברשתות On-Premises זה לא במקרה - זה בדיוק אותו התפקיד, ואותו הרעיון של Layered Security.
4. ה Subnets הפנימיים (נקראים "פרטיים" כי אנו מגבילים את הגישה אליהם) מכילים את חלקי המערכת שלנו. למשל, ה Subnet הראשון אליו מגיעים מכיל את ה Web Server ואנו יוצרים כלל שמאפשר רק לתקשורת שמקורה ב public subnet - להגיע ל subnet הזה.
1. באופן דומה, שירות X יסכים לקבל תקשורת רק מה Web Server או כל Subnet שנגדיר לו.
2. הגדרת הכללים היא קלה: אנו יודעים מה ה CIDR (טווח הכתובות הקבוע) של כל subnet, כך שב Security Group של שירות X אנו נאפשר את ה Subnets (אחד לכל AZs) של ה Web Servers.
   אם מתווספים שרתי ווב חדשים - הם עדיין יהיו בטווח הכתובות של ה subnets, ולכן הכללים שהגדרנו - עדיין יהיו תקפים.
3. אנו יודעים איזה חלק של המערכת אמור לתקשר עם איזה חלק אחר - וכך אנו חוצצים את השירותים שלנו למספר subnets, ע"פ פרופיל התקשורת שלהם: הנכנסת והיוצאת.
   יש ארגונים שיחלקו את הרשת שלהם ל 3-4 פרופילים שכאלו, ויש כאלו שיחלקו ל 50. הכל תלוי במידת האבטחה שאתם רוצים להשיג ועד כמה אתה מוכנים לטרוח בכדי להשיג אותה.
5. כפי שציינתי, גם התקשורת היוצאת היא פרופיל שכדאי לשלוט בו. יהיו מעט התקפות יעילות על הרשת שלכם - שלא יידרשו סוג של קשר עם המתקיף.
1. באופן דומה, נהוג גם את התקשורת היוצאת לסנן בעזרת IDS, WAF, או לפחות NAT פשוט. לאחר הסינון התקשורת תגיע ל Internet Gateway שזה שירות של אמזון (highly available, fully elastic) - שמאפשר את תקשורת הנתונים החוצה.
6. סביר שתרצו לאפשר גם לעובדים במשרד לגשת לחלקים מהמערכת, ולכך יש שירותי VPN. אם אתם רוצים לאפשר גישה מה VPN ל Web Server, יהיה עליכם להגדיר כלל נוסף שמאפשר ל subnet של ה Web Server לקבל תקשורת מה VPC Gateway.
7. הזכרנו שהמוטיבציה העיקרית ל VPC היא אבטחה. עוד שירות חשוב של אמזון הוא ה VPC Flow Logs.
   זהו שירות המאפשר לקבל לוגים על כל התעבורה אל ומחוץ ל VPC.
   ישנם שירותי צד-שלישי (כמו Observe Networks, Dome9, SumoLogic, ועוד) שישמחו לאסוף עבורכם את הלוגים הללו, לנתח אותם, להציג ב Dashboard יפה - ואף לנסות ולאתר אנומליות.

עוד כמה פרטים אחרונים

VPN

ניתן לאפשר ערוץ תעבורה בין המשרד, או כל רשת אחרת ל VPC שלכם על גבי VPN. הרכיב באמזון שמאפשר זאת הוא ה VPN Gateway (בקיצור: VGW, נקרא גם Virtual Private Gateway) היודע לעבוד עם פרוטוקול IPSec VPN.

כל חיבור VPN כולל 2 IPSec Tunnels (ערוצים מוצפנים), כך שאם ערוץ אחד כשל, פרוטוקול ה BGP (קיצור של Border Gateway Protocol) ינתב את התעבורה דרך הערוץ השני. ניתן כמובן להגדיר יותר מ VPN Gateway  - וכך לאפשר יתירות של ארבעה Tunnels ויותר.


AWS Direct Connect

AWS Direct Connect הוא שירות של אמזון לחיבור רשת משופר (קווים שאמזון שוכרת לצורך זה, ככל הנראה) בין VPCs ב Regions שונים לרשת של הארגון שלכם. אם יש יש לכם תעבורה משמעותית בין הרשתות - השירות הזה עשוי להפחית עלויות, לשפר latency ולשפר את האבטחה.

התקשורת ב AWS Direct Connect מבודדת ע"י פרוטוקול VLAN - כך שהיא לא תערבב עם תקשורת של VPCs אחרים.

גם בשימוש ב Direct Connect, ניתן להגדיר Tunnels של VPN כ fallback, במידה וה Direct Connect כושל (בעזרת פרוטוקול BGP).

VPC Peering

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


VPC Endpoint

מאפשר להגדיר ערוץ תקשורת פרטי בין ה VPC לשירות של אמזון (ולא דרך הרשת הכללית של ה Data Center).
כרגע השירות היחידי שתומך ביכולת זו הוא S3 - אך עוד שירותים יתווספו בעתיד.

בכדי להשלים את התמונה, ב S3 Bucket ניתן להגדיר (בעזרת Policy) שיסכים לקבל קריאות רק מתוך VPC endpoint מסוים (ע"פ id) - וכך גם לוודא שלא בטעות פניתם ל Bucket שלא דרך הערוץ המאובטח.

סיכום

Virtual Private Cloud היא במידה מסוימת יכולת "לא סקסית" של AWS - אך חשובה מאוד.
לפני כמה שנים דובר כמה ארגונים חוששים, משיקולי אבטחה, לעבור לענן. ראיתי תצורות רשת של כמה חברות גדולות. רובן היו פרימיטיביות יותר ממה שניתן להשיג בעזרת VPC במאמץ סביר. למשל: לחלק כל שירות ל subnet ולהגביל את סוג התקשורת הנכנסת + היוצאת? מבחינת אבטחה - זה נהדר!  בד"כ ארגונים מספקים רמת שליטה שכזו רק על כל ה Data Center או רק בסיסי הנתונים (כולם, כמקשה אחת).

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


שיהיה בהצלחה!



---

קישורים רלוונטיים

AWS re:Invent 2015 | (ARC403) From One to Many: Evolving VPC Design

SDD422) Amazon VPC Deep Dive)

25 טיפים להגדרת VPC


---



[א] מהו VLAN - אפשר לקרוא הסבר קצר בפוסט שפירסמתי על OpenStack.

[ב] 4 בדצמבר 2013, לדקדקנים שביננו.