Keycloak: נקודת כניסה אחודה לכל השירותים
כל עוד יש שלושה שירותים, כניסה עצמאית שנוצרה בבית נראית כפתרון הגיוני: טופס, טבלת משתמשים, הנפקת טוקן. הבעיה מתגלה בשירות העשירי, כאשר חשבונות מתפזרים בין בסיסי נתונים, לחלק מהעובדים נשארת גישה לאחר פיטורין, וסיסמה יש לשנות בכל אפליקציה בנפרד. כל אינטגרציה חדשה היא עוד דרך לאימות שירותים, שיש לתחזק, לבדוק ולהגן עליה.
Keycloak מסיר את ההסתעפות הזו: כניסה אחודה נבנית מעל ספק זהות אחד, והאפליקציות מפסיקות לאחסן סיסמאות ולבדוק אותן בעצמן. השירות מקבל טוקן חתום וסומך עליו — כללי ההנפקה, תוקף החיים והרכב הנתונים מתוארים במקום אחד. ניהול הגישה עובר מהקוד של כל אפליקציה לתפקידים ולקבוצות, שמנהל משנה ללא הוצאה לאור.
בהמשך פועלת פדרציה: ספריית העובדים מתחברת כמקור משתמשים, קבלנים חיצוניים נכנסים דרך ספק ארגוני, ופניות שירות-לשירות מאושרות באמצעות חשבונות מכונה.
המשתמש עובר אימות פעם אחת ומגיע לכל המערכות ללא הקלדת סיסמה חוזרת, ושלילת גישה פועלת באופן מרוכז — ההפעלה נסגרת, הטוקנים מפסיקים להתחדש.
מפרקים כיצד זה נפרס: מתרשים ה-realms וה-clients ועד למתאר עמידות לתקלות עם צומת גיבוי, כדי שכניסה אחודה לא תהפוך לנקודת כשל אחודה.
מה מספקת ניהול זהויות מבוקר
נקודת כניסה אחודה מסירה מהצוות עבודה ידנית שבזבזה בעבר זמן על כל שירות חדש. במקום מסד נתונים נפרד של משתמשים ואימות עצמאי בכל אפליקציה, השירות נרשם כלקוח ב-Keycloak — חיבור אפליקציה חדשה אורך שעות, לא ימים, ואינו דורש כתיבה ותחזוקה של קוד אימות עצמאי.
פעולות ידניות מצטמצמות הודות לריכוזיות. משתמשים, קבוצות והרשאות חיים במקום אחד: קליטת עובד, העברה בין מחלקות, פיטורים — כל אלה הם פעולה אחת שמשתקפת מיד בכל המערכות המחוברות. מבטלים גישה במקום אחד — היא נעלמת בכל מקום, ולא נשארות חשבונות "נשכחים" בשירותים נפרדים.
מדיניות גישה אחודה מפסיקה להיות אוסף של הסכמות והופכת לכלל שאכיף לביצוע. דרישות לסיסמאות, אימות דו-שלבי חובה, משך חיי הפעלה, הגבלות לפי תפקידים — הכול מוגדר פעם אחת ומיושם באופן זהה בכל האפליקציות. שירות חדש יורש את המדיניות הזו בעת החיבור, ולא בונה מדיניות משל עצמו.
שקיפות הכניסות סוגרת מחלקה שלמה של תקלות הקשורות לגישה. כל כניסה, סירוב ושינוי הרשאות מתועדים ביומן אחוד: רואים מי, מתי ובאיזה שירות נכנס, ולמי נותרו הפעלות פעילות. בעת חקירת תקלה אין צורך לאסוף לוגים מעשרות מערכות — התמונה נאספת ממקור אחד, וניתן לסיים הפעלה חשודה בכפייה.
בנפרד מוסר הסיכון שבדרך כלל צף בביקורת: חוסר סנכרון בין חשבונות במערכות שונות. כאשר מקור האמת הוא אחד, וחיבור השירותים נעשה לפי תבנית מוכחת, הגישות מפסיקות "לחיות חיים משל עצמן" — וזו בדיוק ניהול הזהויות המבוקר שהלקוח מקבל כתוצאה.
אפשרויות פריסה והמגבלות שלהן
פריסה של Keycloak היא לעתים רחוקות "פשוט להרים קונטיינר": בחירת הפלטפורמה קובעת מי אחראי לזמינות, לעדכונים ולטוהר המשפטי של אחסון נתוני הזיהוי. להלן שלוש סכמות שביניהן באמת בוחרים בשלב ההתחלה, והמגבלות שלהן.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| מתחם מנוהל בצד שלנו | נדרשת הפעלה מהירה, אין צוות תחזוקה משלכם, מותר אחסון מחוץ להיקף שלכם | פחות שליטה על בידוד רשת ועדכונים; נדרש תיאום בנוגע לנתונים |
| פריסה בתשתית של הלקוח | דרישות מחמירות לאחסון נתונים אישיים, יש יכולות מחשוב וכוננות משלכם | עדכונים ועמידות לתקלות — באחריותכם; נדרש גישה לצורך תחזוקה |
| סכמה היברידית | המתחם הראשי בתוך ההיקף, וחלק מהשירותים או שותפים חיצוניים — בחוץ | ניתוב וסנכרון הפעלות מורכבים יותר; נדרשת הגדרה מדויקת של פדרציה |
מה קובע את הבחירה
מתחם מנוהל מעניק התחלה צפויה: אנחנו מחזיקים את האשכול, השכפול וגיבויי הגיבוי, ואתם מקבלים כניסה עובדת ללא תשתית משלכם. המגבלה — הנתונים נמצאים מחוץ להיקף שלכם, וזה לא תמיד עובר תיאום.
פריסה אצלכם — הצד השני של המטבע: שליטה מלאה על הרשת והאחסון, אך התחזוקה, העדכונים והשחזור נופלים על הצוות שלכם. ההיברידי מסיר חלק מהמגבלות, ומוסיף עבודה על פדרציה בין המתחמים.
נדון בדרישות שלכם להיקף ולנתונים — נחזור עם הערכה ותוכנית.
איך מתבצעת ההטמעה: שלבי העבודה
הטמעת SSO אינה התקנה של מוצר, אלא ארגון מחדש של כל נקודות הכניסה למערכות. לכן מתחילים במיפוי מלאי, ולא בפריסה: כל עוד אין תמונה מלאה, כל הגדרת מדיניות נעשית באופן עיוור.
איך בנוי התהליך
- ביקורת כניסות. אוספים את כל המערכות שאליהן מתחברים עובדים ומשתמשים חיצוניים: שירותים פנימיים, לוחות ניהול, אזורי שותפים. מתעדים היכן מאוחסנים החשבונות, אילו פרוטוקולים נתמכים, האם קיימות מסדי נתונים מקומיים של סיסמאות וחשבונות שירות עם credentials משותפים.
- תרשים אינטגרציה. קובעים אילו אפליקציות מחברים בפרוטוקולים מודרניים, ואילו דורשות שכבת פרוקסי או התאמה. מתאמים מודל תפקידים וקבוצות, כדי שלא יהיה צורך לכתוב מחדש את ההרשאות לאחר ההפעלה.
- פריסה והגדרת מדיניות. מקימים קלאסטר עם רפליקציה, מגדירים פדרציה עם ספריית המשתמשים הקיימת, כללי סיסמאות, אימות רב-גורמי וזמן חיים של הפעלות. את המדיניות מתארים באופן דקלרטיבי — התצורה משוחזרת, ולא נבנתה ידנית.
- בדיקת תרחישים. מריצים מסלולים אמיתיים: כניסה ראשונה, איפוס סיסמה, פקיעת הפעלה, שלילת גישה בעת פיטורים, כניסת קבלן חיצוני עם הרשאות מוגבלות. בנפרד בודקים עמידות לתקלות — מה קורה כאשר צומת אחד אינו זמין.
- מסירה לתפעול. מוסרים תיעוד, נהלי ניהול והוראות לשירות התמיכה. מאמנים את צוות הלקוח בפעולות שגרתיות: הוספת אפליקציה, הענקת תפקיד, טיפול באירוע כניסה.
מה חשוב בכל שלב
ביקורת ותרשים האינטגרציה אורכים יותר זמן מאשר ההגדרה עצמה — והם בדיוק אלה שקובעים אם יהיה צורך לעשות מחדש כעבור חודש. בדיקת התרחישים מתבצעת לפני המסירה, ולא אחריה: אירועי כניסה משתקים את העבודה מהר יותר מכל תקלה אחרת.
תארו את המשימה שלכם — נחזור עם הערכה ותוכנית לפי שלבים.
מה הלקוח מקבל לאחר ההטמעה
הכניסה למערכת מפסיקה להיות אוסף של חשבונות מקומיים: נקודת אימות אחודה משרתת שירותים פנימיים, פאנלים לניהול וממשקי שותפים חיצוניים. להלן מה שנשאר לצוות שלכם לאחר המסירה, כדי שהתמיכה והפיתוח לא יהיו תלויים בקבלן.
- תצורות realm ולקוחות — הגדרות מיוצאות לקבצים של פדרציית משתמשים, מיפוי תפקידים וקבוצות, זמני פסק זמן של הפעלות וחידוש אסימונים. נפרסות בסביבה בפקודה אחת, ולא נבנות מחדש מהזיכרון.
- תרשימי זרימות כניסה — דיאגרמות לכל תרחיש: כניסת עובד דרך ספריית הארגון, משתמש חיצוני באמצעות קוד חד-פעמי, חשבון שירות באמצעות אסימון מכונה. ניתן לראות היכן פועל אימות רב-גורמי והיכן מתחבר ספק זהות חיצוני.
- מדיניות גישה — כללים להענקת תפקידים ותחומי ראייה, הגבלות לפי כתובות והתקנים, זמני חיים של הפעלות ותנאים ליציאה כפויה. כל כלל משויך לקבוצה מסוימת, ולא לאדם בודד.
- נהלי תמיכה — סדר הוספה וחסימה של משתמשים, סבב מפתחות חתימה, חידוש תעודות ותגובה לאירועי כניסה. בציון מי ובאיזה מועד מבצע כל שלב.
- תיעוד — מפת אינטגרציות, תיאור תפקידים וייעודם, הנחיות לשירות התמיכה ורשימת בדיקה לאבחון תקלות אימות אופייניות.
- ניטור ויומנים — ייצוא אירועי כניסה וסירובים למערכת איסוף היומנים שלכם, מערך התראות על זינוק בניסיונות כושלים ואי-זמינות של הספק.
- סקריפטים לגיבוי ושחזור — תרחיש מאומת להעלאת תצורה ונתונים בסביבה נקייה עם מדידת זמן השחזור.
כל האמור לעיל נמסר במאגר שלכם עם היסטוריית שינויים: עריכות בתצורות עוברות סקירה, ולא מבוצעות ידנית בממשק. תארו את המשימה שלכם — נחזור עם הערכה ותוכנית עבודה.
מקרה בוחן: כניסה אחודה לשירותים פנימיים
לפני: האימות היה מפוזר בין השירותים. חלק מהמערכות התבססו על טבלאות משתמשים משלהן, חלקן — על ספריית LDAP, ועוד כמה — על טוקנים שנכתבו בעצמם. הסיסמאות נשמרו בשלושה מקומות, ההרשאות ניתנו ידנית, ובעת פיטורי עובד הגישה נשללה לפי רשימת בדיקה שבה באופן קבוע משהו נשכח.
חיבור שירות חדש ארך 3-4 שבועות: לתאם את הסכימה, לכתוב אינטגרציה, לבדוק תרחישי כניסה, להעלות לפרודקשן.
אחרי: פרסנו את Keycloak כספק זהות אחוד. הגדרנו פדרציה עם הספרייה הקיימת כדי לא להעביר חשבונות, וחיברנו שירותים לפי פרוטוקולים תקניים — OIDC לאפליקציות ווב, SAML למערכות legacy שלא יודעות אחרת.
את התפקידים והקבוצות העברנו למרשם אחד, ואת הפרוביז'נינג של המשתמשים קשרנו לספרייה: פיטורים במערכת ה-HR סוגרים אוטומטית גישות בכל השירותים המחוברים.
מה השתנה במספרים
- זמן חיבור שירות חדש: מ-3-4 שבועות ל-2-3 ימים — אינטגרציה טיפוסית מצטמצמת לרישום לקוח והגדרת הפניות מחדש.
- פניות לתמיכה בנושא סיסמאות וגישות: מינוס 70% ברבעון הראשון — איפוס סיסמה והענקת הרשאות עברו לשירות עצמי.
- שלילת גישה בעת פיטורים: מכמה שעות של עבודה ידנית להפעלה אוטומטית תוך דקות.
- מספר מקומות אחסון הסיסמאות: משלושה לאחד, עם מדיניות מורכבות אחודה ואימות דו-שלבי חובה לתפקידים ניהוליים.
מדוע זה עבד
העיקר — לא המוצר עצמו, אלא מודל הגישה שהובא לצורה אחודה: מקור אמת אחד למשתמשים, תפקידים צפויים, פרוטוקולים תקניים במקום פתרונות שנכתבו בעצמם. מכאן כל שירות חדש מתחבר לפי תבנית מוכנה, ולא ממציא אימות מחדש.
אנחנו מחזיקים את הקונפיגורציה במאגר ופורסים שינויים דרך אוטומציה — הסביבות משוחזרות אחת לאחת, כולל הגדרות הפדרציה והמדיניות.
במה שונה Keycloak מכניסה עצמאית?
כניסה עצמאית כמעט תמיד מתחילה באותו אופן: טופס התחברות, טבלת משתמשים, האש סיסמה, סשן ב-cookie. כעבור חצי שנה מתווספים לכך איפוס סיסמה, אימות דוא"ל, חסימה לאחר סדרת ניסיונות כושלים, תפקידים והרשאות, וכן כניסה דרך ספריית ארגונית וגורם שני. כל סעיף הוא משימה נפרדת עם מקרי קצה, ועליהם מתבזבז עיקר הזמן, ולא על טופס הכניסה עצמו.
פתרון מוכן מכסה את המערך הזה מהקופסה: פרוטוקולי פדרציה, תיווך ספקים חיצוניים, מדיניות סיסמאות, יומן אירועי כניסה, כיוונון עדין של הרשאות לפי תפקידים וקבוצות. המהנדסים שלנו פורסים אותו בתצורה עמידה בכשלים, מחברים לספריית המשתמשים שלכם ומגדירים הנפקה ורענון של טוקנים. אין צורך לתכנן סכימת אחסון סודות ולחשוב מה יקרה כאשר צומת האימות אינו זמין.
עלות התמיכה היא הטיעון המרכזי. כניסה עצמאית מתכסה בתלויות מבלי משים: החלפת ספרייה, עדכון עקב פגיעות, התאמה לשירות חדש. כל שינוי מבוצע על ידי אדם אחד, ועזיבתו הופכת את המערכת לקופסה שחורה.
לפתרון מוכן יש קהילה, תיעוד ומחזור עדכוני אבטחה צפוי — עדכון גרסה אינו מחייב לכתוב מחדש את לוגיקת הכניסה.
גם מהירות השינויים שונה. חיבור שירות חדש לפתרון מוכן הוא הגדרת לקוח והרשאות, שעות עבודה. בסכימה עצמאית זה תיקון קוד, בדיקות ופריסה. כאשר העסק מבקש כניסה אחודה למוצר חדש, ההבדל נמדד בימים מול שבועות.
אבטחה אינה רק עניין של האשים. פתרון מוכן עובר במשך שנים בדיקות על ידי הקהילה ובדיקות חדירה, בעוד כניסה עצמאית פגיעה בדיוק במידה שבה היה מחברה קשוב בעת כתיבתה. איננו טוענים שפיתוח עצמי הוא חסר טעם — לעיתים הוא מוצדק על ידי דרישות צרות. אך אם המשימה היא כניסה אמינה ללא תחזוקה מתמדת, פתרון מוכן מנצח בעלות הבעלות הכוללת.
ספקות טכניים נפוצים
ספקות בנוגע ל-Keycloak בדרך כלל מצטמצמים לארבעה נושאים: תאימות ליישומים קיימים, העברת משתמשים מהמערכת הנוכחית, התנהגות תחת עומס ואינטגרציה עם שירותים שכבר פועלים. להלן ניתוח של כל אחד מהם, מהצד ההנדסי.
תאימות: האם יהיה צורך לכתוב מחדש את היישומים?
ברוב המקרים לא. Keycloak פועל לפי פרוטוקולי פדרציית הזהויות הסטנדרטיים — OIDC ו-SAML, ולכן יישומים שכבר תומכים באימות דרך ספק חיצוני מתחברים באמצעות שינוי פרמטרי החיבור, ללא שינויים בקוד. עבור מערכות legacy ללא תמיכה בפרוטוקולים אלה אנו מגדירים אימות פרוקסי או מתאם. בנפרד אנו בודקים תרחישים: כניסה אחודה, יציאה מכל ההפעלות, רענון טוקן, תפקידים וקבוצות.
הגירה: כיצד להעביר משתמשים קיימים?
אנו מעבירים חשבונות, האשות סיסמאות וקשרי תפקידים מהמאגר הנוכחי — Active Directory, LDAP או בסיס נתונים עצמאי. אם פורמט ההאשות תואם, המשתמשים ממשיכים להיכנס עם הסיסמאות הישנות; אם לא — אנו מגדירים החלפה כפויה בכניסה הראשונה, כדי לא לאפס את כולם בבת אחת.
את ההגירה אנו מבצעים בשלבים: תחילה סנכרון, לאחר מכן העברת התעבורה, עם אפשרות חזרה למערכת הקודמת עד לרגע המעבר המלא.
עומס: האם יעמוד בכניסה של כל החברה בו-זמנית?
Keycloak מתרחב אופקית: מספר מופעים מאחורי מאזן עומסים, בסיס נתונים משותף ומטמון הפעלות מבוזר. שיא הבוקר, כאשר מאות עובדים נכנסים בתוך מספר דקות, הוא מצב שגרתי עבור תצורה כזו. את האשכול אנו פורסים על פני אזורי זמינות, כך שכשל של צומת אחת לא יפריע לכניסה.
לפני העלייה לאוויר אנו מריצים מבחן עומס על פרופיל כניסות אמיתי וקובעים מרווח במספר ההפעלות בו-זמניות.
אינטגרציה: מה עם שירותים ארגוניים והרשאות גישה?
אנו מחברים את הספרייה הארגונית כמקור משתמשים, מגדירים סנכרון קבוצות וניתוק אוטומטי של גישה עם עזיבת עובד. תפקידים מהספרייה מוקרנים על היישומים, ולכן ההרשאות משתנות במקום אחד. עבור קבלנים חיצוניים אנו פותחים קו מתאר נפרד עם סט מוגבל של שירותים ותוקף לחשבון.
תארו את הנוף שלכם — אילו יישומים, ספרייה ופרופיל עומס — נחזור עם הערכה ותוכנית הגירה.
נדון במשימת הזיהוי שלכם
פריסת Keycloak במפתח מתחילה בשיחה, ולא בהתקנה. חשוב לנו להבין את סכמת הזיהוי הנוכחית שלכם: היכן מאוחסנים חשבונות, אילו אפליקציות ושירותים יש לחבר, האם יש קבלנים חיצוניים ומערכות שותפים שזקוקים לגישה. מכך תלויה ארכיטקטורת הפדרציה, בחירת הפרוטוקולים, וכיצד תיבנה נסיגה לאחור אם משהו לא יתקדם כמתוכנן.
תארו את המשימה בצורה חופשית — נחזור עם הערכה ותוכנית עבודה. בשיחה הראשונה נבהיר:
- אילו אפליקציות ושירותים מחברים ובאילו פרוטוקולים (SAML, OIDC) הם יודעים לעבוד;
- מהיכן מהגרים חשבונות וכיצד מעבירים סיסמאות וקבוצות ללא איפוס המוני;
- האם נדרשת פדרציה עם ספריות חיצוניות ודומיינים ארגוניים;
- מהן הדרישות לאימות רב-גורמי ולמדיניות סיסמאות;
- כיצד בנויים תפקידים והרשאות: מי וממה מקבל גישה;
- האם נדרשת אינטגרציה עם מערכות ניטור ותיוע עדכניות;
- אילו תרחישי עמידות לתקלות קריטיים: צומת גיבוי, שחזור, עדכונים מתוכננים;
- מי מצד הלקוח מקבל את התוצאה ולפי אילו קריטריונים.
לאחר השיחה תקבלו תוכנית עבודה עם שלבים, לוחות זמנים ואזורי אחריות, וכן תרשים של הארכיטקטורה המיועדת. אנו עובדים מרחוק ומתחברים לתשתית שלכם באופן הנוח לצוות האבטחה שלכם. נדון במשימה — ונחזור עם הערכה קונקרטית.