המעבר מ-ADCS ל-Microsoft Cloud PKI ב-Intune

By Mirko Peters · 2026-08-13

למדו כיצד לעבור מ-ADCS המסורתי ל-Microsoft Cloud PKI ב-Intune. פשטו אימות מכשירים, בטלו את שרתי NDES ואבטחו רשתות Wi-Fi ו-VPN.

Automatically translated with AI from the original post. Read the English original

המעבר משירותי תעודות Active Directory המסורתיים ל-Microsoft Cloud PKI מבטל את הצורך במחברי אישורים מקומיים, בשרתי NDES ובתצורות מורכבות של שרתי proxy הפוכים. על ידי העברת תשתית רשות האישורים ישירות ל-Microsoft Intune, מנהלי IT יכולים לייעל את אימות המכשירים עבור Windows, macOS והתקנים ניידים, ללא צורך בתחזוקת חומרת שרתים מקומית.

עיקרי הדברים

• Microsoft Cloud PKI מחליף את תשתית ADCS המקומית של Windows Server ברשות אישורים מקורית בענן, המנוהלת ישירות ב-Intune.
• תהליך המעבר מסיר מכשולים מסורתיים כמו שרתי NDES, מחברי אישורים פנימיים ו-proxy הפוכים החשופים לאינטרנט.
• אימות מכשירים מסתמך על SCEP כדי ליצור ולאבטח מפתחות פרטיים מקומיים במחשבים ניידים ובהתקנים ניידים מנוהלים.
• המעבר מסייע לארגונים לבטל סיסמאות Wi-Fi משותפות ולאבטח גישת VPN מרחוק באמצעות אישורי מכשיר אישיים.
• תכנון נכון דורש בדיקה של זכאויות הרישיון ב-Intune ואימות שרשראות האמון של רשות האישורים הבסיסית והמנפיקה לפני הפריסה.

עלויות התשתית הנסתרות של ADCS המסורתי

במשך עשרות שנים, ארגונים הסתמכו על Windows Server ועל Active Directory Certificate Services כדי לנהל את תשתית המפתחות הציבורית הפנימית שלהם. ADCS הוא פתרון יציב, אך הוא דורש עומס תחזוקה משמעותי. הפעלת רשות אישורים מקומית משמעה ניהול מערכות ההפעלה של השרתים, פריסת עדכונים, הגדרת גיבויים לחומרה וניטור תאריכי תפוגה, כדי למנוע השבתות קריטיות בבוקר של יום שני.

יתרה מזאת, חיבור מכשירי קצה ניידים ומרוחקים שמנוהלים בענן לרשות אישורים מקומית יוצר מורכבות ארכיטקטונית. מנהלים חייבים לפרוס מחברי אישורים של Intune, להקים תפקידי Network Device Enrollment Service (NDES), להגדיר web application proxy לגישה חיצונית ולפתוח בזהירות חריגים בחומות האש הארגוניות. עבור צוותי IT קטנים, תשתית מסועפת כזו הופכת דרישה פשוטה כמו Wi-Fi מבוסס אישורים לנטל תפעולי מתמשך.

כיצד Microsoft Cloud PKI מפשט את הארכיטקטורה הארגונית

Microsoft Cloud PKI מעביר את עיקר העבודה של ניהול האישורים ממרכזי הנתונים המקומיים אל הענן של Microsoft. במקום להקים שרתים וירטואליים של Windows Server, מנהלים יכולים להקים היררכיית Root CA ו-Issuing CA מנוהלת במלואה ישירות במרכז הניהול של Microsoft Intune. Microsoft מאבטחת את מפתחות הקריפטוגרפיה הבסיסיים באמצעות מודולי אבטחת חומרה (HSM), מבלי לדרוש מצוותי IT ארגוניים להתקין או לתחזק התקני אבטחה פיזיים.

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

בניית אסטרטגיית המעבר שלכם

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

1. זיהוי עומס העבודה הראשון שלכם

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

2. הגדרת שרשראות אמון ו-SCEP

לפני הנפקת תעודות למכשירים, Intune חייב להעביר לנקודות הקצה את תעודות האמון הנדרשות. כך מובטח שמכשירי הלקוח יזהו את שורש Cloud PKI החדש ואת רשויות ההנפקה שלכם. לאחר שנוצר האמון, המכשירים משתמשים ב-Simple Certificate Enrollment Protocol (SCEP) כנתיב בקשה מאובטח. נקודת הקצה יוצרת את המפתח הפרטי שלה באופן מקומי, כך שהסוד הקריפטוגרפי הרגיש לעולם אינו עובר ברשת, ו-Cloud PKI מאמת את הבקשה דרך Intune וחותם על התעודה הציבורית.

3. אימות תהליכי חידוש וביטול

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

סיכום

המעבר מ-PKI מבוסס Windows Server מסורתי ל-Microsoft Cloud PKI מהווה צעד משמעותי בהתייחסות לאבטחה ארגונית מודרנית. על ידי הסרת שרתים מקומיים, מחברים ופרוקסים, צוותי IT יכולים לספק אימות מבוסס תעודות חלק ל-Wi-Fi, ל-VPN ולאפליקציות פנימיות, ובמקביל להפחית משמעותית את עומס התחזוקה המנהלתי. כדי לשמוע הסבר מעמיק יותר על אופן פעולתם של הרכיבים המבוססי-ענן יחד, האזינו לפרק המלא: Listen to the full episode. הישארו מעודכנים כדי לגלות אסטרטגיות מעשיות לפישוט מרחב העבודה הדיגיטלי של הארגון שלכם.

שאלות נפוצות

האם Microsoft Cloud PKI מחליף לחלוטין סביבת ADCS מקומית קיימת?

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

אילו פלטפורמות מכשירים נתמכות על ידי Microsoft Cloud PKI?

Cloud PKI תומך במערכות האקולוגיות העיקריות של מכשירים המנוהלים דרך Microsoft Intune, כולל מחשבים ניידים ושולחניים עם Windows, מכשירי macOS, מכשירי iOS/iPadOS ונקודות קצה נתמכות של Android.

כיצד מוגנים המפתחות הפרטיים במהלך רישום התעודה?

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

האם אני צריך מחברי תעודות חיצוניים ל-Cloud PKI?

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