הגדרות אבטחה
מדריך זה מכסה את Settings → Security - מדיניות ברמת סביבת העבודה כולה, שחלה על כל החברים ומנוהלת על ידי מנהלים.
להגדרות ההתחברות האישיות שלכם (החלפת סיסמה, רישום 2FA, צפייה במכשירים המהימנים שלכם, חיבור חשבונות Google/Microsoft להתחברות שלכם), ראו My account → Security.
אם אתם מנהלי ארגון, תראו את הדף Security במלואו. מי שאינם מנהלים רואים את אותו דף, אך הכול בו לקריאה בלבד.
מבנה דף ה-Security
לדף Security יש סרגל שמאלי ובו ארבעה תתי־מקטעים - כולם למנהלים בלבד:
| תת-מקטע | מה הוא שולט בו |
|---|---|
| Authentication | מדיניות סיסמאות + אכיפת 2FA |
| Sessions | זמן קצוב לחוסר פעילות + נעילת חשבון + "remember me" |
| Single sign-on | הגדרת ספק זהויות + אכיפת SSO |
| Network access | רשימת היתרים של כתובות IP |
תת־המקטע הפעיל משתקף בכתובת ה־URL (?section=sso וכדומה), כך שאפשר לשמור אותו בסימניות או לשתף קישור ישיר אליו.
Authentication
מדיניות סיסמאות ו־2FA ברמת הארגון.
מדיניות סיסמאות
- Minimum password length - המנהלים קובעים את הרף התחתון. מומלץ להגדיר 12 תווים; המינימום המוחלט הוא 8.
- Prevent reuse of last N passwords - מונע בחירה חוזרת באותה סיסמה בתוך הטווח שהוגדר.
- Require mixed characters - כשהאפשרות מופעלת, כל סיסמה חדשה חייבת להכיל לפחות אות גדולה אחת, אות קטנה אחת וספרה אחת. כבויה כברירת מחדל. מדיניות המבוססת על אורך בלבד חזקה בדרך כלל ממדיניות המבוססת על מורכבות בלבד; הפעילו זאת רק אם יש לכם דרישת תאימות ספציפית.
- Expire passwords periodically - כשהאפשרות מופעלת, החברים נדרשים להחליף סיסמה כל N ימים. כבויה כברירת מחדל מאותה סיבה - החלפה כפויה מובילה לעיתים קרובות לסיסמאות חלשות וצפויות יותר. הפעילו רק לצורכי תאימות.
אימות דו-שלבי (2FA)
- Require 2FA - כשהאפשרות מופעלת, כל חבר חייב להגדיר מאמת TOTP לפני שיוכל לגשת לסביבת העבודה.
הלוח Authentication מיועד למדיניות הארגון בלבד. כדי להגדיר לעצמכם 2FA, ראו My account בהמשך.
Sessions
זמן קצוב לחוסר פעילות
כשהאפשרות מופעלת, חברים מנותקים אוטומטית לאחר N דקות ללא פעילות. במכשירים מהימנים עדיין מוצגת בקשה שקטה לאימות מחדש במקום מסך התחברות מלא.
הגדרת הזמן הקצוב של הסשן נשמרת כיום, אך עדיין אינה נאכפת בשכבת האימות. האכיפה מתוכננת להמשך.
נעילת חשבון
לאחר N ניסיונות התחברות כושלים ברצף, החשבון ננעל למשך הזמן שהוגדר. חברים יכולים לבטל את הנעילה באמצעות קישור שנשלח באימייל, או שמנהל יכול לבטל אותה עבורם.
Allow "remember me" for 30 days
כשהאפשרות מופעלת, חברים יראו בגרסה עתידית תיבת סימון "Stay signed in" בדף ההתחברות, שתאריך את הסשן שלהם ל־30 יום.
אפשר להפעיל את מדיניות המנהל כבר היום והיא נשמרת בשרת, אך תיבת הסימון בדף ההתחברות עצמו תתווסף בגרסה עתידית. השארת האפשרות כבויה אינה יוצרת כרגע הבדל גלוי למשתמשים.
Single sign-on (SSO)
אפשרו לחברים להתחבר באמצעות ספק הזהויות של הארגון. אפשר להגדיר את Google Workspace, Microsoft Entra או Okta. לאחר שספק אחד לפחות מופעל, אפשר לאכוף התחברות באמצעות SSO בלבד בכל סביבת העבודה.
ספקי זהויות
כל ספק מוצג ככרטיס עם הסטטוס שלו:
- Not configured - לחצו על Configure כדי להזין פרטי הזדהות.
- Active (תג ירוק) - הספק מוגדר, והחברים רואים את כפתור ההתחברות שלו בדף ההתחברות.
- Disabled (תג אפור) - פרטי הגישה שמורים, אך הספק כבוי. החברים אינם רואים אותו בדף ההתחברות.
- Auto-create (תג כחול, אם הופעל בהגדרות הספק) - משתמשי SSO חדשים נוצרים אוטומטית עם התפקיד שבחרתם.
הפעילו או כבו ספק באמצעות המתג שבכרטיס שלו. לחצו על Edit כדי לעדכן את פרטי הגישה.
הגדרת ספק
לחצו על Configure (ספק חדש) או על Edit (ספק קיים) בכרטיס ספק כלשהו כדי לפתוח את חלון ההגדרה. כל חלון מכיל:
- Setup guide - רשימת שלבים מתקפלת של הפעולות שיש לבצע אצל ה־IdP (Google Cloud Console / Azure Portal / Okta Admin). השלבים מותאמים לכל ספק.
- Redirect URI - הערך שיש להדביק בשדה "Authorized redirect URIs" של ה־IdP. הכפתור Copy מעתיק אותו ללוח.
- Client ID + Client Secret - מועתקים מה־IdP. הסוד נשמר כשהוא מוצפן; אם אתם עורכים ספק קיים, השאירו את השדה ריק כדי לשמור את הערך הקיים.
- שדה ייעודי לספק:
- Microsoft: Tenant ID - השתמשו ב־
commonלריבוי דיירים או ב־UUID של דייר מסוים. - Okta: Okta domain - שם המארח שלכם בסיומת
*.okta.com.
- Microsoft: Tenant ID - השתמשו ב־
- Allowed email domains (מופרדים בפסיקים) - מגביל את ההתחברות באמצעות SSO לדומייני אימייל מסוימים. השאירו את השדה ריק כדי לאפשר כל דומיין.
- Auto-create members on first sign-in - מתג. כשהוא מופעל, בחרו את ה־Default role לחשבונות חדשים.
Save & test connection
לחלון יש פעולה ראשית אחת. בשמירה הראשונה היא נקראת Save & test connection; בעריכה או בחידוש הגדרה היא נקראת Test & save changes.
לחיצה עליה:
- שומרת את פרטי הגישה כשהספק מושבת (כדי שספק שאינו פועל לעולם לא יופיע בדף ההתחברות).
- פונה ל־IdP כדי לוודא שפרטי הגישה פועלים.
- אם הבדיקה מצליחה - מפעילה את הספק וסוגרת את החלון; בכרטיס מופיע התג Active.
- אם הבדיקה נכשלת - משאירה את הספק מושבת ומציגה את הודעת השגיאה של ה־IdP בפס כתום מעל כפתור הפעולה. תקנו את השדה השגוי ולחצו שוב. השגיאה נעלמת ברגע שתתחילו להקליד.
אם תסגרו את החלון לאחר בדיקת Save & test שנכשלה, הספק יישאר במצב ביניים של "שמור אך מושבת". פתיחה מחדש תציג Resume {provider} sign-on setup כשהשדות כבר מלאים, וכן כפתור Discard setup לצד Cancel - משם אפשר להשלים את ההגדרה או למחוק אותה.
מדריכי הגדרה ב-IdP
Google Workspace
- עברו אל Google Cloud Console
- צרו פרויקט חדש או בחרו פרויקט קיים.
- נווטו אל APIs & Services → Credentials.
- לחצו על Create Credentials → OAuth 2.0 Client IDs.
- הגדירו את מסך ההסכמה של OAuth אם תתבקשו.
- הגדירו את סוג האפליקציה ל-Web application.
- הוסיפו את ה־Redirect URI המוצג בחלון אל Authorized redirect URIs.
- העתיקו את Client ID ואת Client Secret אל Joryio.
Microsoft Entra
- עברו אל Azure Portal
- נווטו אל Microsoft Entra ID → App registrations → New registration.
- בחרו את סוגי החשבונות הנתמכים:
- Common - כל חשבונות Microsoft (עבודה + אישיים)
- Organizations - חשבונות עבודה / לימודים בלבד
- Consumers - חשבונות אישיים בלבד
- הוסיפו את ה־Redirect URI המוצג בחלון תחת הפלטפורמה Web.
- תחת Certificates & secrets, צרו Client Secret חדש.
- העתיקו את Application (client) ID, את ה־Client Secret ואת Directory (tenant) ID אל Joryio.
Okta
- פתחו את Okta Admin Console.
- Applications → Create App Integration.
- בחרו OIDC – OpenID Connect, ואז Web Application.
- הוסיפו את ה־Redirect URI המוצג בחלון אל Sign-in redirect URIs.
- תחת Assignments, הגדירו מי יכול להשתמש באפליקציה.
- העתיקו את Client ID, את Client secret ואת דומיין Okta שלכם (למשל
your-company.okta.com) אל Joryio.
אכיפת SSO
זהו הכרטיס התחתון בתת־המקטע SSO. כשהאכיפה מופעלת, התחברות באמצעות סיסמה מושבתת בכל סביבת העבודה - החברים חייבים להשתמש בספק הזהויות שלהם. המתג מושבת עד שמופעל ספק אחד לפחות, ומוצגת אזהרה כתומה שמסבירה מדוע.
המנהלים שומרים קוד שחזור חד־פעמי למקרה שה־IdP לא יהיה זמין.
Network access
כרטיס יחיד של IP allowlist. כשהוא מופעל, רק ניסיונות התחברות שמקורם באחת מכתובות IPv4 או מטווחי CIDR שברשימה יתקבלו. חברים שמתחברים מחוץ לרשימת ההיתרים יקבלו שגיאת הרשאה.
השאירו ריק (או כבו את הכרטיס) כדי לאפשר התחברות מכל מקום.
הגדרות התחברות אישיות
בקרות ההתחברות האישיות (ה-2FA שלכם, מכשירים מהימנים, החלפת סיסמה, חשבונות Google/Microsoft/Okta מחוברים, "sign out everywhere") נמצאות תחת My account בדף נפרד.
שיטות עבודה מומלצות
- חייבו 2FA לכולם - הפעילו זאת ב־Authentication לאחר שכל חברי הצוות נרשמו.
- הגבילו את דומייני האימייל המורשים בכל ספק SSO. זה מונע מחשבונות Google אקראיים להתחבר לסביבת העבודה שלכם.
- הגדירו לפחות ספק SSO אחד לפני אכיפת SSO - המתג מושבת עד שתעשו זאת, אבל האזהרה שם לא בכדי.
- השתמשו ברשימת היתרי ה־IP אם יש לכם טווח מוגדר של המשרד או ה־VPN. ותרו עליה בצוותים שעובדים מרחוק בלבד - נעילות שווא גורמות להפרעה משמעותית.