אם הארגון שלכם משתמש ב-Okta לניהול זהויות (Identity Provider), אתם כבר עובדים עם אחת מהפלטפורמות המובילות בעולם לניהול גישה דיגיטלית. כל עובד מחובר ל-Okta – Salesforce, Slack, GitHub, AWS – הכל מנוהל ממקום אחד. אבל מה עם הדלת לבניין? מה עם גישה לחדר השרתים?
שאלה זו – איך לחבר את Okta לאבטחה הפיזית – היא בדיוק מה שמאמר זה עונה עליה. זהו המדריך המקיף לאינטגרציה בין Okta לבין מערכת בקרת כניסה פיזית.
למה Okta ולא רק Active Directory?
שאלה שעולה לעיתים: 'כבר כתבתם על Entra ID (Azure AD) – למה צריך מאמר נפרד על Okta?' התשובה: Okta ו-Entra ID הם שני שחקנים שונים עם ארכיטקטורות שונות, ועם בסיסי לקוחות שונים.
Okta היא Identity Platform עצמאית שמנהלת זהויות Cloud-First, לרוב בארגונים שאינם Microsoft-centric. היא נפוצה במיוחד בחברות טכנולוגיה, סטארטאפים, ויצרנים. Entra ID, לעומתה, היא חלק ממערכת האקוסיסטם של Microsoft ונפוצה בארגונים שמשתמשים ב-Microsoft 365.
ארגון שמשתמש ב-Okta כ-IdP הראשי שלו – ומחפש לחבר אותו לגישה פיזית – צריך ארכיטקטורה ותצורה שונה מאלה של Entra ID. המאמר הזה הוא בשבילו.
הארכיטקטורה: איך Okta מתחבר לבקרת כניסה?
שתי גישות עיקריות לאינטגרציה:
גישה א׳ – SCIM (System for Cross-domain Identity Management): פרוטוקול סטנדרטי שמאפשר ל-Okta לדחוף אוטומטית שינויים בזהויות (יצירה, עדכון, מחיקה) ישירות למערכת בקרת הכניסה. זוהי הגישה המועדפת – אוטומציה מלאה.
גישה ב׳ – Webhook / Event Hook: Okta מפעיל Webhook בכל אירוע (עובד הצטרף, שינוי קבוצה, עובד הושבת). מערכת בקרת הכניסה מאזינה ל-Webhook ומעדכנת בהתאם. גמיש יותר, דורש פיתוח קל.
SCIM עם Okta – איך זה עובד בפועל?
SCIM הוא הלב של האינטגרציה. הנה התהליך בפרק זמן של Onboarding:
- HR פותח Ticket לעובד חדש במערכת HR (Workday, BambooHR וכו').
- Okta מקבל את פרטי העובד (שם, מחלקה, תפקיד) ויוצר User חדש.
- Okta מוסיף את העובד לקבוצות הרלוונטיות (לדוגמה: 'RD_Team', 'Floor3_Access').
- SCIM Provisioning מעביר את פרטי היוזר החדש למערכת בקרת הכניסה.
- מערכת בקרת הכניסה יוצרת פרופיל עובד ומקצה הרשאות לפי מיפוי הקבוצות.
- כרטיס / Mobile Credential מונפק ונשלח לעובד.
כל זה קורה אוטומטית – ללא מגע ידני מ-IT.
מיפוי קבוצות Okta להרשאות פיזיות
המפתח לאינטגרציה מוצלחת הוא מיפוי נכון בין קבוצות ב-Okta לבין הרשאות פיזיות במערכת. דוגמה:
Okta Group: Engineering_All → גישה: לובי, קומה 3, חדר מחשבים
Okta Group: Engineering_Leads → גישה: כל הנ"ל + חדר שרתים
Okta Group: Finance_Team → גישה: לובי, קומה 5, חדר כספות
Okta Group: HR_Department → גישה: לובי, קומה 2, ארכיון
Okta Group: All_Employees → גישה: לובי, חניון, חדרי שירותים
כאשר עובד עובר מ-Engineering ל-Finance, עדכון הקבוצה ב-Okta מעביר את ההרשאות הפיזיות אוטומטית – בלי שאיש IT נגע במערכת בקרת הכניסה.
Event Hooks – ניטור אירועים בזמן אמת
מעבר לסנכרון, Okta מאפשר הגדרת Event Hooks שמפעילים פעולות אוטומטיות בהתרחש אירועים. דוגמאות לאירועים שניתן לחבר לפעולות פיזיות:
- user.lifecycle.deactivate → ביטול מיידי של כרטיס פיזי כשחשבון Okta מושבת.
- user.lifecycle.suspend → השעיית גישה פיזית זמנית (עובד בחל"ת).
- group.user_membership.add → הוספת הרשאת גישה כשעובד נוסף לקבוצה.
- group.user_membership.remove → הסרת גישה כשעובד עוזב קבוצה.
- user.authentication.auth_via_mfa_failure (3 כישלונות) → נעילת גישה פיזית בנוסף לדיגיטלית.
MFA פיזי – שילוב מרתק
אחד השימושים המתקדמים והמרתקים ביותר: שימוש ב-Okta MFA גם לאימות פיזי. הרעיון:
עובד מגיע לדלת רגישה (חדר שרתים, כספת). הוא מציג כרטיס/Mobile. הקורא מאמת את הכרטיס מול מסד הנתונים. לאחר מכן – Push Notification נשלח ל-Okta Verify על הטלפון של העובד. הוא מאשר, והדלת נפתחת. אם הוא לא מאשר תוך 30 שניות – הדלת נשארת נעולה.
זהו Multi-Factor Authentication פיזי ממשי – שמשתמש בתשתית שכבר יש לכם ב-Okta, ומרחיב אותה לגישה הפיזית.
דרישות טכניות לאינטגרציה
כדי לממש את האינטגרציה, נדרשים:
- Okta: חשבון Okta עם תמיכה ב-API (Okta Developer / Workforce Identity). הגדרת SCIM Provisioning מופעלת.
- מערכת בקרת כניסה: תמיכה ב-SCIM 2.0 ו/או REST API. רשימת ספקים תואמים: Brivo, Openpath, Verkada, Honeywell Pro-Watch, ומוצרים שסקיי סקיוריטי מספקת.
- רשת: חיבור HTTPS מאובטח בין מערכת בקרת הכניסה לשרתי Okta. אין צורך ב-VPN אם המערכת Cloud-based.
- הגדרת Attribute Mapping: מיפוי שדות בין Okta (firstName, lastName, department, title) לשדות במערכת הגישה.
מה הבדל מול Entra ID?
שאלה שמנהלי IT שואלים לעיתים: 'יש לנו גם Okta וגם Microsoft – מה עדיף לחבר?' התשובה תלויה בארכיטקטורה:
- אם Okta הוא ה-IdP הראשי (כל ה-Apps מחוברים דרכו) – חיברו דרך Okta. זו נקודת האמת.
- אם יש Federation בין Okta ל-Entra ID – לרוב Okta הוא ה-Primary IdP, ועדיף לחבר דרכו.
- אם Entra ID הוא ה-IdP הראשי ו-Okta רק Relay – חיברו דרך Entra ID.
הכלל: חיברו את מערכת בקרת הכניסה לנקודה שבה מתבצע ה-User Lifecycle Management האמיתי.
Offboarding – הבדיקה האמיתית
הרגע שמוכיח שהאינטגרציה עובדת הוא Offboarding של עובד. עם אינטגרציה מלאה:
מנהל HR מסמן עובד כ'עוזב' ב-Workday. Okta מקבל את ה-Trigger. חשבון Okta מושבת. SCIM / Webhook מעדכן את מערכת בקרת הכניסה. כרטיס פיזי מבוטל. Mobile Credential מרוחק. הכל – בפחות מ-60 שניות, ללא מגע ידני.
לעומת זאת, בארגון ללא אינטגרציה: HR מסמן ב-Workday. IT מקבל מייל. מישהו נזכר לבטל ב-Active Directory. שלושה ימים אחר כך, מישהו אחר נזכר לבטל את כרטיס הגישה. לפעמים אחרי שבוע. לפעמים בכלל לא.
סקיי סקיוריטי – מומחיות בחיבור Okta לגישה פיזית
סקיי סקיוריטי עורכת פרויקטי אינטגרציה בין Okta לבין מערכות בקרת כניסה פיזיות. אנו מתחילים ממיפוי הארכיטקטורה הקיימת, ממשיכים בהגדרת ה-SCIM והמיפוי, ומסיימים בבדיקות קבלה מלאות. רוב הפרויקטים מסתיימים בתוך 2-4 שבועות.
משתמשים ב-Okta ורוצים לסגור את הפרצה הפיזית? דברו איתנו לפגישת ייעוץ טכנית ראשונה.