מדריך

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

→Azure AD Connect עם Pass-through Authentication (PTA) ו-Password Hash Sync (PHS) מופעלים כגיבוי.

למה: PTA שומר גיבובי סיסמאות באתר על ידי אימות מול AD מקומי. PHS מספק מעבר כשל באימות אם ה-AD באתר או סוכן ה-Connect אינם זמינים.

מקור↗

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

→מדיניות Microsoft Entra Conditional Access המשלבת Named Locations, תאימות מכשירים (Intune), וסיכון כניסה (Identity Protection) עם בקרות הענקה כמו MFA.

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

מקור↗

אכיפת מדיניות עקבית (לדוגמה, תיוג, אזורים מותרים) על פני עשרות או מאות מנויים.

→היררכיה של קבוצות ניהול (management groups) עם יוזמות Azure Policy המוקצות ברמת קבוצת הניהול הראשית או ההורית.

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

מקור↗

מתן גישה מועדפת (privileged access) בדיוק בזמן (JIT) למנהלים עם זרימות עבודה של אישור וביקורת.

→Microsoft Entra Privileged Identity Management (PIM) כדי להפוך משתמשים לזכאים לתפקידים במקום פעילים באופן קבוע.

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

מקור↗

איסוף יומנים מכל משאבי Azure על פני מספר מנויים לצורך ניתוח ושאילתות מרכזיים.

→סביבת עבודה אחת, מרכזית, של Log Analytics עם RBAC בהקשר משאב (resource-context) לבקרת גישה.

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

משאב Azure (לדוגמה, App Service, Function, VM) צריך לגשת בצורה מאובטחת למשאבי Azure אחרים (Key Vault, SQL, Storage) ללא פרטי כניסה מאוחסנים.

→הקצה Managed Identity (מנוהלת על ידי המערכת או על ידי משתמש) למשאב המחשוב והענק לה תפקידי RBAC על משאבי היעד.

למה: Managed Identities מבטלות את הצורך בניהול פרטי כניסה (סודות, אישורים), ומטפלות באופן אוטומטי ברכישת ואף סבב אסימונים. השתמש בזהות מנוהלת על ידי משתמש לשיתוף זהות על פני מספר משאבים.

מקור↗

תיקון אוטומטי של משאבי Azure קיימים, שאינם תואמים, אשר זוהו על ידי Azure Policy.

→השתמש באפקט מדיניות "DeployIfNotExists" או "Modify". עבור משאבים קיימים, יש ליצור משימת תיקון עבור הקצאת המדיניות, הדורשת זהות מנוהלת (managed identity) עם הרשאות מספיקות.

למה: מדיניות עם אפקטים אלה חלה רק על משאבים חדשים/מעודכנים כברירת מחדל. נדרשת משימת תיקון כדי לסרוק ולתקן משאבים קיימים שאינם תואמים.

אכיפת תגים נדרשים על כל המשאבים והורשה אוטומטית של תגים (לדוגמה, CostCenter) מקבוצת המשאבים ההורית.

→השתמש ב-Azure Policy עם אפקט "Deny" עבור תגים נדרשים ומדיניות נפרדת עם אפקט "Modify" כדי להוריש תגים מקבוצת המשאבים אם הם חסרים.

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

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

→כייל את כל השירותים באמצעות Application Insights. השתמש במפת היישום (Application Map) כדי לדמות תלויות ובמעקב מבוזר (distributed tracing) לניתוח בקשות מקצה לקצה.

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

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

→ניהול זכאויות של Microsoft Entra ID Governance. צור חבילות גישה המאגדות משאבים, מגדירות זרימות עבודה של אישור, קובעות מדיניות תפוגה ומתזמנות סקירות גישה.

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

ספק שירות מנוהל (MSP) או צוות IT מרכזי צריך לנהל משאבים על פני מספר דיירי Azure AD של לקוחות/מחלקות.

→Azure Lighthouse. הצטרף מנויי לקוחות כדי להעניק לדייר המנהל גישה מואצלת עם תפקידי RBAC ספציפיים.

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

ספק גישה מרחוק מאובטחת ליישום ווב באתר למשתמשים חיצוניים ללא VPN או חשיפת היישום לאינטרנט.

→Microsoft Entra Application Proxy.

למה: Application Proxy משתמש במחבר קל משקל באתר המבצע חיבור יוצא ל-Azure. הוא פועל כפרוקסי הפוך, ומאפשר אימות מוקדם של Entra ID וגישה מאובטחת ללא כללי חומת אש נכנסים או IP ציבורי ביישום.

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

→Azure Cosmos DB עם multi-region writes מופעלים. יש לבחור מפתח מחיצה (partition key) שיפזר את עומס העבודה באופן שווה.

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

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

→השתמש ב-/deviceId כמפתח המחיצה (partition key). הגדר TTL על הקונטיינר למחיקה אוטומטית של מסמכים ישנים. השתמש ב-Change Feed כדי ללכוד נתונים לפני מחיקה לצורך ארכיון לאחסון קר (לדוגמה, Blob Storage).

למה: מחיצה לפי `deviceId` ממקמת נתונים עבור מכשיר בודד יחד, מה שהופך את השאילתות ליעילות. TTL מספק מחיקה אוטומטית וחינמית. Change Feed מאפשר צינור ארכיון ריאקטיבי.

בחירת מודל תמחור חסכוני עבור Azure SQL DB לעומס עבודה עם תעבורה בלתי צפויה, קופצנית ותקופות סרק משמעותיות.

→השתמש במודל מבוסס vCore עם שכבת המחשוב Serverless.

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

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

→Azure Data Lake Storage Gen2 (חשבון עם מרחב שמות היררכי מופעל).

למה: ADLS Gen2 ממוטב לאנליטיקת ביג דאטה, ומשלב מדרגיות אחסון אובייקטים עם מערכת קבצים היררכית אמיתית ו-ACLs תואמי POSIX לאבטחה מדויקת.

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

→1. עמידות מירבית/קריאה: RA-GZRS. 2. רק לשחזור מאסון: GRS. 3. בתוך האזור: ZRS.

למה: התאם את אפשרות היתירות לדרישות ה-RPO/RTO הספציפיות ולצרכי הגישה. RA-GZRS היא הרמה הגבוהה ביותר. GRS מיועד רק למעבר כשל. ZRS מגן מפני כשל דאטה סנטר בתוך אזור.

שאילתות נתונים מובנים גדולים במחסן נתונים ונתונים מובנים למחצה ב-data lake באמצעות פלטפורמת אנליטיקה מאוחדת.

→Azure Synapse Analytics. השתמש ב-dedicated SQL pool עבור הנתונים המובנים וב-serverless SQL pool עבור שאילתות ad-hoc על ה-data lake.

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

פתרון מטמון עבור מצב סשן (session state) ונתוני מוצרים הדורש מעל 100 GB זיכרון וזמינות גבוהה.

→Azure Cache for Redis Enterprise או Premium tier עם אשכולות (clustering) מופעלים.

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

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

→Azure SQL Elastic Pools. קבץ דיירים למאגרים כדי לחלוק משאבים, עם מסדי נתונים ייעודיים עבור דיירים גדולים ו"מרעישים".

למה: מאגרים גמישים (Elastic pools) מספקים את היתרונות העלותיים של שיתוף משאבים תוך אכיפת מגבלות ביצועים לכל מסד נתונים, ומציעים איזון בין בעיית "השכן המרעיש" לבין העלות הגבוהה של מסד נתונים אחד לכל דייר.

העברת מסד נתונים מורכב של SQL Server באתר המשתמש בתכונות כמו SQL Agent, שאילתות חוצות מסדי נתונים ו-CLR לשירות PaaS.

→Azure SQL Managed Instance.

למה: SQL Managed Instance מציע תאימות כמעט 100% למנוע SQL Server באתר, ותומך בתכונות ברמת המופע ש-Azure SQL Database אינו תומך בהן. זה אידיאלי עבור "lift-and-shift" עם מינימום שינויים בקוד.

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

→פרוס את כל המשאבים לאזורים בתוך הגבול. השתמש ב-Azure Policy עם אפקט "Allowed locations" כדי לאכוף זאת. אחסן מפתחות הצפנה המנוהלים על ידי הלקוח (CMK) ב-Azure Key Vault הממוקם גם הוא בתוך הגבול.

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

גלה, סווג, ועקוב אחר אילן יוחסין (lineage) עבור נתונים על פני נכסי נתונים היברידיים (Azure, באתר, עננים אחרים).

→Microsoft Purview.

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

אחסון נתונים (לדוגמה, רשומות פיננסיות) במצב בלתי מחיק, בלתי ניתן לשינוי (WORM) למשך תקופת שמירה מוגדרת.

→Azure Blob Storage עם מדיניות בלתי ניתנת לשינוי מבוססת זמן על הקונטיינר, אשר ננעלת לאחר מכן.

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

תכנן פתרון DR (שחזור מאסון) עבור יישום ווב (App Service + SQL DB) עם RPO של דקות ו-RTO מתחת לשעה.

→קבוצת מעבר כשל אוטומטי של Azure SQL Database, פריסת App Service משנית, ו-Azure Front Door או Traffic Manager לניתוב.

למה: תבנית זו מטפלת ב-DR עבור כל שכבה. קבוצת מעבר הכשל של SQL מטפלת בשכפול נתונים ומעבר כשל. ה-App Service שנפרס מראש מונע עיכובי פריסה. נתב גלובלי (Front Door/Traffic Manager) מנתב תעבורה לאזור הפעיל.

ה-SLA המורכב של יישום סדרתי (A -> B -> C) נמוך מדי. כיצד ניתן לשפר אותו?

→זהה את הרכיב בעל ה-SLA האינדיבידואלי הנמוך ביותר ("החוליה החלשה") והפוך אותו ליתיר על ידי פריסת מופעים מקבילים (לדוגמה, על פני אזורים או אזורי זמינות עם מאזן עומסים).

למה: SLA מורכב לשרשרת סדרתית מחושב על ידי הכפלת SLAs (SLA_A * SLA_B * SLA_C). הוספת מופעים מקבילים לרכיב משפרת את ה-SLA האפקטיבי שלו, דבר שיש לו את ההשפעה החיובית הגדולה ביותר על ה-SLA המורכב.

השגת זמינות גבוהה ביותר אפשרית למכונות וירטואליות בתוך אזור Azure יחיד.

→פרוס מספר מכונות וירטואליות על פני כל Availability Zones הזמינים באזור.

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

ספק פתרון שחזור מאסון עבור מכונות וירטואליות של VMware או Hyper-V באתר ל-Azure.

→Azure Site Recovery (ASR). הגדר שכפול ל-Azure, צור תוכניות שחזור למעבר כשל מתוזמר, והשתמש במעברי כשל בדיקה לתרגילי DR שאינם מפריעים.

למה: ASR הוא שירות Azure ייעודי לשכפול DR של מכונות וירטואליות באתר (וגם ב-Azure), המספק שכפול רציף, שחזור מתוזמר ויכולות בדיקה מבודדות.

השגת זמינות גבוהה מקסימלית בתוך האזור עבור Azure SQL Database עם אובדן נתונים אפס (RPO=0) ויכולת הרחבת קריאה.

→השתמש בשכבת השירות Business Critical עם יתירות אזורים (zone redundancy) מופעלת.

למה: שכבת Business Critical משתמשת ב-Always On Availability Group עם שכפול סינכרוני על פני עותקים מרובים, ומספקת RPO של 0. יתירות אזורים ממקמת עותקים ב-AZs שונים עבור SLA של 99.995%. היא כוללת עותק משני קריא.

יישום גלובלי חייב לשרת משתמשים מהאזור הקרוב ביותר ולבצע מעבר כשל (failover) אוטומטית ומיידית.

→השתמש בתבנית פריסה פעילה-פעילה על פני אזורים מרובים עם Azure Front Door לניתוב מבוסס זמן אחזור ומעבר כשל מבוסס בדיקת תקינות.

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

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

→השתמש ב-Azure Backup עבור AKS.

למה: Azure Backup עבור AKS הוא הפתרון המקורי המספק גיבוי משולב, מבוסס מדיניות, עבור מצב אשכול (etcd) ונתוני נפח קבוע (באמצעות CSI snapshots) לכספת גיבוי מאובטחת ומרכזית.

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

→אפשר כספות בלתי ניתנות לשינוי (immutable vaults) בכספת Azure Backup או Recovery Services.

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

App Service Environment v3 (ASEv3) מארח יישום קריטי באזור אחד ודורש פתרון DR (שחזור מאסון) באזור אחר.

→פרוס ASEv3 שני באזור ה-DR. השתמש ב-Azure Front Door לאיזון עומסים גלובלי ומעבר כשל. שכפל נתונים באמצעות הטכנולוגיה המתאימה (לדוגמה, קבוצות מעבר כשל אוטומטי של SQL).

למה: ASEv3s הם פריסות אזוריות. עבור DR, עליך לפרוס ASE שני ולהשתמש בנתב גלובלי כמו Front Door לניהול תעבורה. ASR אינו משמש עבור DR של App Service.

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

→טופולוגיית Hub-and-Spoke. ה-VNet המרכזית (hub) מכילה את השער, Azure Firewall ושירותים משותפים אחרים. VNets הקצה (spoke) מכילות עומסי עבודה של יישומים ומקושרות (peered) למרכז.

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

יישום ווב גלובלי דורש איזון עומסים בשכבה 7, Web Application Firewall (WAF), פריקת SSL וניתוב מבוסס URL.

→Azure Front Door (Standard או Premium).

למה: Front Door הוא CDN ענן מודרני ומאזן עומסים גלובלי המשלב יכולות אלה לשירות יחיד, ומספק ביצועים טובים יותר וניהול פשוט יותר מאשר שילוב Traffic Manager עם Application Gateways אזוריים.

תכנן אשכול AKS ברמת ייצור עבור צוותים מרובים עם סוגי עומסי עבודה משתנים (דורשי CPU, GPU, זיכרון).

→השתמש במאגר צמתים ייעודי למערכת (system node pool) ובמאגרי צמתים מרובים למשתמשים (user node pools) עם יחידות SKU שונות של VM (לדוגמה, F-series עבור CPU, E-series עבור זיכרון, N-series עבור GPU). השתמש באוטו-סקיילר של האשכול ואפשר את שכבת Standard/Premium עבור SLA הזמינות.

למה: מאגרי צמתים מרובים מאפשרים התאמת החומרה הנכונה לעומס העבודה הנכון עבור ביצועים ויעילות עלות. הפרדת פודים (pods) של המערכת משפרת יציבות. שכבת Standard/Premium נדרשת עבור SLA מגובה כלכלית.

זרימת עבודה מונעת אירועים ללא שרתים (serverless) דורשת זמני ביצוע ארוכים יותר ממגבלת ה-10 דקות של תוכנית Consumption של Functions.

→השתמש ב-Azure Functions בתוכנית Premium או בתוכנית App Service, או השתמש ב-Azure Durable Functions לתזמור.

למה: תוכנית Premium תומכת בביצוע עד 60 דקות (ברירת מחדל 30) ומונעת התנעות קרות. Durable Functions אידיאליים לתזמור זרימות עבודה ארוכות טווח ושומרות מצב שעשויות לכלול אינטראקציה אנושית או המתנות ארוכות.

בחר שירות הודעות עבור מערכת התראות אירועים מסוג fan-out לעומת מערכת עיבוד פקודות אמינה ומסודרת.

→השתמש ב-Azure Event Grid עבור eventing מבוסס fan-out וריאקטיבי. השתמש ב-Azure Service Bus Queues (עם סשנים לסדר) עבור עיבוד פקודות אמין וטרנזקציוני.

למה: Event Grid הוא שירות ניתוב אירועים קל משקל, מבוסס push, ממוטב לתכנות ריאקטיבי. Service Bus הוא ברוקר הודעות חזק עם תכונות כמו FIFO (סשנים), dead-lettering, וטרנזקציות להודעות ארגוניות.

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

→פרוס Azure API Management (APIM) במצב VNet פנימי, כשהוא מוגן על ידי Azure Application Gateway עם WAF לכניסה ציבורית.

למה: תבנית זו מספקת הגנה לעומק (defense-in-depth). APIM ב-VNet יכול לגשת ל-backend הפרטי. ה-App Gateway מסיים SSL, בודק תעבורה עם WAF, ומעביר אותה למופע APIM הפרטי. מדיניות APIM מטפלת באימות, הגבלת קצב וכו'.

חבר מאות משרדי סניפים ו-VNets גלובלית עם קישוריות אוטומטית, מכל-אחד-לכל-אחד.

→Azure Virtual WAN.

למה: Virtual WAN הוא פתרון מנוהל של מיקרוסופט לרשתות מעבר גלובליות בקנה מידה גדול. הוא ממכן ניתוב מורכב ומספק מרכז מאוחד לחיבור VPN, ExpressRoute ו-VNet spokes.

הרץ משימת אצווה מקבילית בקנה מידה גדול (לדוגמה, סימולציית CFD) הדורשת אלפי ליבות ותקשורת MPI עם זמן אחזור נמוך.

→Azure Batch עם מאגר של מכונות וירטואליות התומכות ב-InfiniBand (לדוגמה, סדרת HB) המשתמשות בתמחור בעדיפות נמוכה (Spot).

למה: Azure Batch הוא מתזמן עבודות המיועד ל-HPC. מכונות וירטואליות התומכות ב-InfiniBand מספקות את רשת ה-RDMA בעלת התפוקה הגבוהה וזמן האחזור הנמוך הנדרשת עבור MPI. מכונות וירטואליות בעדיפות נמוכה מפחיתות באופן דרסטי עלויות עבור עומסי עבודה סובלניים לתקלות.

יישום ב-VNet צריך לגשת לשירותי PaaS (SQL, Storage) ללא תעבורה העוברת דרך האינטרנט הציבורי.

→צור נקודות קצה פרטיות (private endpoints) עבור שירותי ה-PaaS. זה נותן לשירות כתובת IP פרטית בתוך ה-VNet שלך.

למה: Private Endpoints הם השיטה המאובטחת ביותר לקישוריות PaaS פרטית. הם מבטיחים שהתעבורה נשארת על עמוד השדרה של מיקרוסופט ומאפשרים לך להשבית לחלוטין את נקודת הקצה הציבורית של שירות ה-PaaS.

אירוח יישום דף יחיד (SPA) מודרני עם backend API ללא שרתים, אינטגרציית CI/CD ודומיין מותאם אישית.

→Azure Static Web Apps.

למה: זהו שירות ייעודי ויעיל במיוחד עבור תבנית זו. הוא משלב אירוח תוכן סטטי, Azure Functions משולבים עבור ה-API, אינטגרציית GitHub/Azure DevOps, ודומיינים מותאמים אישית מנוהלים עם אישורי SSL חינם.

ניהול והחלת ממשל (Azure Policy) על שרתים הפועלים באתר ובעננים אחרים (לדוגמה, AWS) מ-Azure.

→התקן את סוכן Azure Arc על השרתים שאינם Azure כדי להציג אותם כשרתים מותאמי Azure Arc.

למה: Azure Arc מרחיב את מישור הבקרה של Azure לכל תשתית. ברגע ששרת מותאם ל-Arc, ניתן לנהל אותו באמצעות Azure Policy, Monitor, Defender for Cloud וכו', בדיוק כמו VM מקורי של Azure.

העברה הדרגתית של פונקציונליות מיישום מונולית מדור קודם למיקרו-שירותים חדשים ללא מעבר חד פעמי ("big bang").

→החל את תבנית Strangler Fig באמצעות פרוקסי הפוך כמו Azure API Management או Application Gateway.

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

מכונות וירטואליות נמצאות ב-VNet עם מנהור כפוי (כל תעבורת האינטרנט מנותבת לאתר), אך הן אינן יכולות לגשת לשירותי Azure PaaS.

→מנהור כפוי שובר גישה ישירה לנקודות קצה ציבוריות של Azure. השתמש ב-service endpoints או private endpoints לגישת PaaS. לחלופין, הוסף UDRs עבור תגי שירות ספציפיים של Azure עם next hop של "Internet" לעקיפת המנהור.

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

רשת Hub-Spoke צריכה לפתור שמות DNS באתר מ-Azure, ואזורי DNS פרטיים של Azure מהאתר.

→פרוס Azure DNS Private Resolver ב-VNet המרכזית (hub). הגדר נקודת קצה נכנסת עבור אתר כדי לפתור DNS של Azure, ונקודת קצה יוצאת עם מערכי כללי העברה (forwarding rulesets) כדי לפתור DNS באתר מ-Azure.

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

מספר VNets זקוקות ל-IP ציבורי סטטי וצפוי עבור כל התעבורה היוצאת לצורך הכללה ברשימה לבנה (whitelisting) על ידי שירותים חיצוניים.

→בטופולוגיית Hub-Spoke, נתב את כל התעבורה היוצאת (0.0.0.0/0) מה-spokes דרך Azure Firewall או NAT Gateway ב-VNet המרכזית (hub).

למה: ריכוז היציאה במרכז מבטיח שכל התעבורה היוצאת תשתמש ב-IPs הציבוריים של חומת האש/NAT Gateway המרכזית, מה שמפשט את הניהול וההכללה ברשימה לבנה חיצונית. NAT Gateway פשוט יותר עבור SNAT טהור, בעוד שחומת אש מוסיפה בדיקת אבטחה.

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

→השתמש במכונות וירטואליות של Azure Confidential Computing (סדרות DCsv3/ECsv3) עם Intel SGX או AMD SEV-SNP כדי להריץ קוד בסביבת ביצוע מהימנה מבוססת חומרה (TEE) או זיכרון מוצפן.

למה: Confidential Computing מטפל בעמודת האבטחה של "נתונים בשימוש" (data-in-use), שאותה הצפנה מסורתית במנוחה ובתעבורה אינן מטפלות. הוא מספק בידוד ברמת חומרה, ניתן לאימות.

ספק SaaS צריך לחשוף את השירות שלו, הפועל ב-VNet שלו, ללקוח ב-VNet של הלקוח, כולו על פני הרשת הפרטית של Azure.

→הספק יוצר Azure Private Link Service על גבי ה-Standard Load Balancer שלו. הלקוח יוצר Private Endpoint ב-VNet שלו המתחבר לשירות.

למה: Private Link היא התבנית המובהקת לחשיפת שירות מאובטחת, פרטית, וחוצת דיירים. היא מונעת חשיפה לאינטרנט הציבורי, בעיות חפיפת IP, ותצורות VNet peering מורכבות.