מדריך

העבר הוצאות IT מרכישות חומרה גדולות וחד-פעמיות למודל תשלום לפי שימוש.

→השתמש במודל מבוסס צריכה של הענן.

למה: זה ממיר הוצאות הון (CapEx) להוצאות תפעוליות (OpEx) צפויות, ומבטל את הצורך ברכישה וניהול של מרכזי נתונים.

הבן את חלוקת האחריות בתחומי האבטחה והניהול בין ספק הענן ללקוח.

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

למה: ב-IaaS, הלקוח מנהל את מערכת ההפעלה ומעלה. ב-PaaS, הספק מנהל את מערכת ההפעלה, והלקוח מנהל את היישום והנתונים. ב-SaaS, הספק מנהל הכל למעט נתונים ותצורת גישה.

מקור↗

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

→השתמש בענן ציבורי (תשתית משותפת), פרטי (תשתית ייעודית, מקומית או מתארחת), או היברידי (שילוב של ציבורי ופרטי).

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

בחר את מודל שירות הענן הנכון בהתבסס על רמת בקרת הניהול הרצויה.

→IaaS (לדוגמה, Azure VMs) לשליטה מקסימלית על מערכת ההפעלה. PaaS (לדוגמה, Azure App Service, Azure SQL) כדי להתמקד בקוד, לא בתשתית. SaaS (לדוגמה, Microsoft 365) לתוכנה מוכנה לשימוש.

למה: הפשרה היא שליטה מול נוחות. ככל שאתה עובר מ-IaaS ל-SaaS, הספק מנהל יותר מהערימה, ומפחית את העומס התפעולי של הלקוח.

טפל בעליות תנועה דינמיות ובלתי צפויות לעומת צמיחה מתוכננת ומתמשכת.

→השתמש ב-Elasticity להרחבה אוטומטית (פנימה/החוצה) כדי להתאים לדרישה בזמן אמת. השתמש ב-Scalability להגדלת קיבולת מתוכננת (החוצה/למעלה) כדי לטפל בצמיחה צפויה.

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

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

→הטמע High Availability (HA) באמצעות Availability Zones כדי לשרוד כשלי מרכזי נתונים. הטמע Disaster Recovery (DR) באמצעות שכפול בין-אזורי (לדוגמה, GRS) כדי לשרוד אסון אזורי.

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

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

→השתמש בענן ריבוני כמו Azure Government.

למה: אלו הן מופעים מבודדים פיזית של Azure, המנוהלים על ידי צוות מאושר, ומתוכננים לעמוד בתקני תאימות ממשלתיים מחמירים (לדוגמה, FedRAMP, DoD).

תכנן יישום גמיש שיכול לעמוד בכשל של מרכז נתונים.

→פרוס משאבים על פני מספר Availability Zones בתוך אזור Azure יחיד.

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

מקור↗

קבץ משאבי Azure קשורים לניהול אחיד, בקרת גישה וחיוב.

→מקם את כל המשאבים עבור יישום בקבוצת משאבים אחת של Azure.

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

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

→VMs (IaaS) לשליטה מלאה. App Service (PaaS) ליישומי ווב/APIs. Azure Functions לקוד Serverless מונחה אירועים. AKS לניהול קונטיינרים. ACI למופעי קונטיינר פשוטים.

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

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

→השתמש ב-Azure Kubernetes Service (AKS).

למה: AKS הוא שירות ה-Kubernetes המנוהל לתיאום קונטיינרים בקנה מידה מלא. השתמש בזה על פני ACI כאשר אתה זקוק לניהול אשכולות ואינטראקציות שירות מורכבות.

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

→השתמש ב-Azure Container Instances (ACI).

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

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

→השתמש ב-Azure ExpressRoute.

למה: ExpressRoute אינו עובר דרך האינטרנט הציבורי, ומציע אמינות, אבטחה ושיהוי נמוכים יותר מ-VPN Gateway, המשתמש במנהור מעל האינטרנט.

מקור↗

פרוס תעבורה למכונות וירטואליות ב-backend בהתבסס על כללי רמת רשת לעומת כללי רמת יישום.

→השתמש ב-Azure Load Balancer להפצת Layer 4 (TCP/UDP). השתמש ב-Azure Application Gateway לתכונות Layer 7 (HTTP/HTTPS) כמו פריקת SSL וניתוב מבוסס URL.

למה: בחר Application Gateway כאשר אתה צריך לקבל החלטות ניתוב בהתבסס על כותרות HTTP, נתיבים או שמות מארח. Load Balancer פשוט ומהיר יותר לתעבורה שאינה HTTP.

נתב תעבורת ווב גלובלית ל-backend האופטימלי, ספק מטמון CDN, והגן באמצעות WAF.

→השתמש ב-Azure Front Door.

למה: Front Door היא נקודת כניסה גלובלית הפועלת ב-Layer 7 ומשלבת איזון עומסים גלובלי, CDN, WAF והגנת DDoS לשירות יחיד.

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

→השתמש ב-Azure Blob Storage.

למה: אחסון Blob הוא מדרגי מאוד וחסכוני עבור נתוני אובייקטים. הוא נבדל מ-Azure Files (לשיתופי קבצים מסוג SMB) ו-Azure Disk Storage (לדיסקים של VMs).

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

→השתמש בשכבות גישה של Blob Storage: Hot (גישה תכופה), Cool/Cold (גישה לא תכופה), ו-Archive (גישה נדירה, שמירה לטווח ארוך).

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

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

→LRS (מרכז נתונים יחיד), ZRS (על פני AZs באזור אחד), GRS (לאזור משני), GZRS (ZRS באזור ראשי + LRS באזור משני).

למה: ZRS מגן מפני כשל במרכז נתונים. GRS/GZRS מגן מפני אסון אזורי. הפשרה היא עלות גבוהה יותר עבור עמידות רבה יותר.

אפשר למכונה וירטואלית ב-VNet לגשת לשירות PaaS (כמו Azure SQL או Storage) ללא יציאת התעבורה מרשת Microsoft.

→צור Private Endpoint עבור שירות ה-PaaS בתוך ה-VNet של המכונה הווירטואלית.

למה: Private Endpoint מעניק לשירות ה-PaaS כתובת IP פרטית מה-VNet שלך, ומבטיח שכל התעבורה זורמת דרך עמוד השדרה הפרטי של Microsoft, ולא דרך האינטרנט הציבורי.

העבר שרת קבצי Windows מקומי לשירות ענן מנוהל הנגיש באמצעות פרוטוקול SMB.

→השתמש ב-Azure Files.

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

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

→ארגן מנויים להיררכיה של קבוצות ניהול.

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

מקור↗

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

→השתמש ב-Azure Policy.

למה: Policy אוכף כללים על תצורות משאבים. זה מיועד לממשל, בעוד ש-RBAC שולט בהרשאות משתמשים (פעולות).

הבחן בין בקרת פעולות משתמשים לבקרת מאפייני משאבים.

→השתמש ב-Role-Based Access Control (RBAC) כדי להגדיר אילו פעולות משתמש יכול לבצע (לדוגמה, "Contributor" יכול ליצור VMs). השתמש ב-Azure Policy כדי להגדיר אילו תצורות מותרות (לדוגמה, "VMs יכולים להיות רק בגודל מסדרת D").

למה: RBAC עוסק ב"מי יכול לעשות מה". Policy עוסק ב"מה מותר". הם עובדים יחד לממשל מקיף.

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

→החל נעילת משאב `CanNotDelete` על המשאב או על קבוצת המשאבים שלו.

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

ארגן לוגית משאבים למעקב עלויות, אוטומציה או זיהוי בעלות.

→החל תגיות (זוגות מפתח-ערך) על משאבים.

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

תגית שהוחלה על קבוצת משאבים אינה מופיעה על המשאבים שבתוכה.

→תגיות אינן יורשות אוטומטית מקבוצות משאבים. כל משאב חייב להיות מתויג במפורש.

למה: כדי לאכוף ירושת תגיות, השתמש ב-Azure Policy עם אפקט "Modify" או "DeployIfNotExists" כדי להוסיף תגיות מקבוצת המשאבים ההורה.

הערך עלויות Azure עתידיות לעומת חישוב חיסכון ממעבר מקומי לענן.

→השתמש ב-Pricing Calculator כדי להעריך את עלות שירותי Azure ספציפיים. השתמש ב-Total Cost of Ownership (TCO) Calculator כדי להשוות עלויות מקומיות מול עלויות Azure.

למה: ה-Pricing Calculator מיועד לפריסות חדשות (greenfield) או הוספת שירותים חדשים. ה-TCO Calculator מיועד לבניית תוכנית עסקית עבור מעבר לענן.

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

→השתמש ב-Azure Cost Management. צור תקציבים (Budgets) כדי להפעיל התראות כאשר ספי ההוצאה מתמלאים.

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

הפחת עלויות עבור עומסי עבודה צפויים ורצים באופן רציף כמו מכונות וירטואליות או מסדי נתונים.

→רכוש Azure Reserved Instances או Savings Plans לתקופה של שנה או שלוש שנים.

למה: הזמנות מציעות הנחות משמעותיות (עד 72%) בהשוואה לתמחור לפי שימוש בתמורה להתחייבות ארוכת טווח. אידיאלי לעומסי עבודה יציבים.

פרוס תשתית Azure באופן חוזר, עקבי ועם בקרת גרסאות.

→השתמש ב-Infrastructure as Code (IaC) הצהרתי עם ARM Templates (JSON) או Bicep.

למה: Bicep היא שפה פשוטה ותמציתית יותר ספציפית לתחום (DSL) המקומפלת ל-ARM JSON, ומספקת חווית כתיבה וקריאות טובות יותר.

נהל ושלט בשרתים הפועלים מקומית או בעננים אחרים באמצעות כלי Azure.

→קלוט את השרתים שאינם Azure ל-Azure Arc.

למה: Azure Arc מקרין משאבים חיצוניים ל-Azure Resource Manager, ומאפשר לך להשתמש ב-Azure Policy, RBAC וניטור עבור נכסים היברידיים ורב-ענניים ממישור בקרה יחיד.

מקור↗

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

→השתמש ב-Microsoft Entra ID (לשעבר Azure AD).

למה: Entra ID הוא מישור בקרת הזהויות, המספק Single Sign-On (SSO), Multi-Factor Authentication (MFA) ו-Conditional Access ליישומי ענן ומקומיים.

דרוש MFA למשתמשים הנכנסים מרשת לא מהימנה אך לא ממשרדי החברה.

→הגדר מדיניות Microsoft Entra Conditional Access.

למה: Conditional Access פועל כמנוע מדיניות "אם-אז". אם תנאי משתמש/מיקום/מכשיר מתקיים, אזי בקרת גישה (כמו דרישת MFA) נאכפת.

אפשר למשאב Azure (כמו מכונה וירטואלית או App Service) לאמת את עצמו לשירות Azure אחר (כמו Key Vault) מבלי לאחסן סודות בקוד.

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

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

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

→השתמש ב-Azure Key Vault.

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

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

→השתמש ב-Microsoft Defender for Cloud.

למה: Defender for Cloud מספק Cloud Security Posture Management (CSPM) ו-Cloud Workload Protection (CWP) על פני סביבות Azure, היברידיות ורב-ענניות.

סנן תעבורת רשת ברמת תת-רשת/NIC לעומת באופן מרכזי עבור כל ה-VNet.

→השתמש ב-Network Security Groups (NSGs) לסינון מנות בסיסי מבוסס מצב בשכבות 3/4. השתמש ב-Azure Firewall לחומת אש מרכזית, מבוססת מצב מלאה כשירות עם סינון Layer 7 ומודיעין איומים.

למה: NSGs פשוטים ומבוזרים. Azure Firewall מספק יכולות מתקדמות וניהול מדיניות מרכזי, המשמש לעיתים קרובות בטופולוגיית hub-spoke.

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

→הפעל גישת Just-In-Time (JIT) למכונות וירטואליות ב-Microsoft Defender for Cloud.

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

פקח על תקינות תשתית Azure לעומת ביצועי קוד היישום.

→השתמש ב-Azure Monitor למדדי ויומני פלטפורמה. השתמש ב-Application Insights (תכונה של Azure Monitor) לניהול ביצועי יישומים (APM).

למה: Azure Monitor אוסף נתוני תשתית (מעבד, זיכרון). Application Insights מספק אבחון מעמיק ברמת הקוד (זמני תגובה, תלויות, חריגות).

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

→השתמש ב-Azure Service Health.

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

קבל המלצות מותאמות אישית וניתנות לביצוע כדי למטב את משאבי Azure.

→סקור את המלצות Azure Advisor.

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

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

→הטמע ארכיטקטורת Azure Landing Zone.

למה: Landing Zones מספקות מסגרת מוגדרת מראש מתוך Cloud Adoption Framework, הכוללת מבנה קבוצות ניהול, רשת, זהות ומדיניות ממשל, כדי להאיץ אימוץ ענן באופן מאובטח.