בקרת כניסה מקומית מול ענן: השוואת פתרונות

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

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

מה באמת נותן פתרון מקומי

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

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

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

מה משנה ניהול בענן

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

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

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

השאלות שבאמת מכריעות

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

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

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

מה באמת עובר כשמחליפים פלטפורמה

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

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

הכרטיסים הם האילוץ השני, והיקר. כרטיס פרוקסימיטי 125 kHz, כרטיס MIFARE Classic וכרטיס DESFire EV3 אינם ניתנים להחלפה זה בזה, ומספר הכרטיס ששמור במערכת אחת לא בהכרח נקרא בפורמט שמערכת אחרת מצפה לו. באתרים שמשתמשים בכרטיס קנייני או במפתחות ייעודיים, מפתחות ההצפנה עשויים להיות בידי האינטגרטור הקודם ולא בידי בעל הבניין. שאלו בכתב מי מחזיק במפתחות, וקבלו תשובה לפני שמזמינים כרטיס אחד.

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

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

מה לבדוק בהרצת פיילוט

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

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

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

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

הדרך האמצעית

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

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