הרשמה אחת מחברת את הצוות שלכם ל-Priority דרך AI — Claude, ChatGPT, Gemini, BI ויצירת אפליקציות.
ההרשמה אורכת כחמש דקות. אישור אחד מקים את כל השאר: כניסה לכל משתמש, מפתח שער חתום, פרטי התחברות מוצפנים לשרתי ה-Priority, וסביבת עבודה ב-BI.
אותה אפליקציה מתארגנת מחדש סביב מי שנכנס אליה. הלקוחות מקבלים פורטל שירות עצמי. המפעילים והשותפים מקבלים את מישור הבקרה.
מנהל הלקוח
ממלאים טופס אחד, מחכים לאישור, ומכאן מנהלים את הגישה לבד: להוסיף שרת Priority, להנפיק טוקן מחבר, לתת גישה לאפליקציה לעמית, להזמין משתמש חדש. בלי קריאת שירות, בלי שרשור מיילים, בלי להמתין לספק.
המפעיל או המשווק
כל מפתח לקוח נושא בתוכו את המגבלות שלו: לאילו שרתי Priority מותר לו להגיע, כמה חברות, מתי הוא פג, ולאילו יכולות מתקדמות הוא רשאי לגעת. ביטול נוחת על שערים פעילים תוך שניות. שותפים מנפיקים בתוך תקרות שאתם קובעים.
הלקוח ממלא טופס אחד. האישור עושה את כל השאר, בפעולה אחת, ומודיע לו על כך בשפה שלו.
המפעיל שולח קישור חתום, חד-פעמי ומוגבל בזמן. אין דף הרשמה פתוח ואין כתובת רישום משותפת, כך שהדרך היחידה להיכנס לפורטל היא קישור שמישהו הנפיק בכוונה.
כרטיס אחד אוסף את הכול: פרטי החברה ואיש הקשר, כתובת כל שרת Priority עם ה-tabula.ini שלו, משתמש API ראשי, ורשימת האנשים שזקוקים לגישה. הטופס אומר במפורש שהפרטים נשלחים בצורה מאובטחת ומוצפנת, ושסיסמת המשתמש הראשי אינה מוצגת לאיש.
המפעיל בודק את הבקשה ומאשר אותה. הפעולה האחת הזו יוצרת את קבוצות הכניסה ואת המשתמשים, כותבת את פרטי ההתחברות ל-Priority מוצפנים ל-AWS SSM, מרעננת את תצורת השער, מנפיקה את מפתח השער של הלקוח עם רשימת השרתים המורשים ורושמת אותו על השער החי, פותחת את סביבת ה-BI ומתחילה את בניית הסכמה, וכותבת את רשומת הביקורת.
הראשון נושא סיסמה זמנית שתוקפה פג אחרי 7 ימים. השני, ”הגישה שלך מוכנה.“, הוא ההגדרה לפי הסדר: פתיחת גישה נכנסת לשער אם שרת ה-Priority סגור לאינטרנט, מפתח ה-API הענני של הארגון, מחולל הטוקנים, נקודת הקצה של MCP עבור Claude, ChatGPT ו-Gemini, כלי הרשת, צומת ה-n8n, והפורטל עצמו.
שני המיילים קיימים במלואם בשתי השפות. מחרוזת עברית חסרה שוברת את הבילד, ולכן העברית לעולם אינה הצד המיושן.
הלקוח מנהל בעצמו טננטים, משתמשים, טוקנים וגישה לאפליקציות. השינויים שעדיין דורשים מפעיל — שרת Priority חדש, החלפת סיסמת המשתמש הראשי — נשלחים כהצעה מהפורטל של הלקוח ונוחתים בתור האישורים של המפעיל.
חמש לשוניות, ורצועת התחלה שמסבירה למנהל חדש מה לעשות עכשיו. שרתי Priority, מפתחות שער, חיבורים, משתמשים ואפליקציות.
האשף מבקש טננט, חברה, שפה, ואת שם המשתמש והסיסמה שלכם ב-Priority. שם המשתמש והסיסמה עוברים ישירות לשער ה-Priority כדי להנפיק את הטוקן — הם אינם נשמרים ואינם נרשמים בלוג.
לשונית החיבורים מחלקת חבילת .mcpb מוכנה ל-Claude Desktop. מורידים, לוחצים פעמיים, ול-Claude יש Priority. אין מה להרכיב ידנית.
שרת Priority חדש או החלפת סיסמת המשתמש הראשי דורשים מפעיל. הלקוח מציע את השינוי מהפורטל, והוא מגיע לתור האישורים כשפרטי ההתחברות מוצפנים לכל אורך הדרך.
כל לקוח מקבל מפתח חתום אחד. כל מה שהשער יאפשר לו לעשות כתוב בתוכו.
מפתח הוא מחרוזת אחת: pk_<payload>.<signature>. ה-payload נושא את ההרשאות. החתימה מוכיחה שקונסולת הרישוי היא זו שהנפיקה אותן.
החברה שהמפתח שייך לה, מזהה הלקוח שלה, ומזהה המפתח עצמו. מזהה המפתח הוא מה שביטול מצביע עליו.
customer · customerId · keyId
תקופה שנקבעת בהנפקה: חצי שנה, שנה או שנתיים. מסך ”פג בקרוב“ בקונסולה עוקב אחרי אופק של 30 יום, כך שהחידוש קורה לפני שהלקוח מרגיש.
6 months · 1 year · 2 years
או רשימה מפורשת של שרתים שהמפתח רשאי להגיע אליהם, או תקרה במודל אמון בשימוש ראשון, שבו N השרתים הראשונים שהמפתח מתחבר אליהם הופכים לרשימה המורשית שלו. מפתחות ענן חייבים לשאת את הרשימה המפורשת.
allowedTenants[] or maxTenants
אותן שתי צורות, רמה אחת למטה: רשימה מפורשת של חברות Priority, או מספר מרבי שנתפס בשימוש הראשון.
allowedCompanies[] or maxCompanies
להתקנות On-Prem בלבד. המפתח נקשר לטביעת האצבע של מכונת השער אצל הלקוח; אי-התאמה הופכת את המפתח לבלתי שמיש. קובץ מפתח שהועתק אינו שווה דבר במכונה אחרת.
deployment: on-prem · MID-…
ביטים אופציונליים שקובעים לאילו יכולות מתקדמות המפתח מגיע: כתיבת קוד, שינויי סכמה, שינויי סכמה הרסניים, ניהול שאילתות, מפתחות שירות, וניהול מערכת.
authoring · schema · sqli-admin · admin
ההרשאות חיות בתוך המפתח ומאומתות ללא רשת. השער בודק את החתימה מקומית מול סוד מוטמע ואינו פונה חזרה לשרת הרישוי, ולכן תקלה ברישוי אינה יכולה להפיל את האינטגרציה של הלקוח. הסוד שחותם את המפתחות לעולם אינו עוזב את צד המפעיל. רק קונסולת הרישוי יכולה להנפיק מפתח שהשער יקבל.
האימות המקומי הוא מה שהופך את המפתח למהיר. הרישום והביטול החיים הם מה שמשאיר אותו בשליטה.
מפתחות נרשמים ומבוטלים על שערי ענן פעילים. אין הפעלה מחדש, אין פריסה מחדש, ואין חלון זמן שבו מפתח שנשלל עדיין עובד. תור הביטולים גם סורק ומבטל את טוקני המחבר של אותו משתמש.
מנגנון השוואה בודק את מרשם הרישוי מול המפתחות שעל השער החי ומול מאגר המשתמשים, ומתקן את ההפרש בשני הכיוונים. עריכות ידניות ושינויים שנקטעו באמצע אינם מצטברים.
לכל לקוח יש מפתח קנוני אחד, ורשימת השרתים המורשים שלו היא איחוד מנוכה כפילויות של הטננטים של אותו לקוח. הוספה או הסרה של טננט מנפיקה את המפתח מחדש: מנפיקים חדש, מבטלים ישן, ומקדמים. אף אחד לא עורך רשימה ביד.
מסך על אופק של 30 יום מציג כל מפתח שמתקרב לסוף התקופה. תפוגה היא כלי מסחרי, לא תקלה שממתינה לקרות.
מוצר הוא קבוצה. הרשאה על משתמש פעיל של לקוח פעיל היא הרישיון. אין מדרגות מושבים ואין חשבונאות רישיונות: מזכים את האדם, והמוצרים שהוא מחזיק הולכים אחריו.
פרופילי גישה מקבצים מוצרים תחת שם אחד. עריכה של פרופיל מחלחלת לכל מי שמחזיק בו, כך שהחלטת הרשאה מתקבלת פעם אחת ולא חוזרת על עצמה לכל משתמש.
משווק הוא לקוח שסומן כמשווק וקיבל פרופיל מגבלות. כל נתיב הנפקה נבדק מול הפרופיל הזה בנקודת חנק אחת, כך שיש מקום יחיד שבו נקבעים הגבולות של שותף.
נקבע פעם אחת לכל שותף. נבדק בכל פריט שהוא מנסה להנפיק.
שותף בלי פרופיל מגבלות אינו יכול להנפיק דבר. שום שותף אינו יכול להנפיק טוקן ניהול.
בתוך המכסה שהוקצתה להם, שותפים מריצים את אותו אישור בלחיצה אחת שאתם מריצים. הם אינם ממתינים בתור אליכם, והם אינם יכולים לחרוג מהמכסה הכוללת שהוקצתה להם.
מסך הבעלות מעביר לקוח בין שותף לבין מכירה ישירה. עסקה שמחליפה ידיים היא העברת בעלות, לא הצטרפות מחדש.
שותף שגם משתמש בחבילה בעצמו מחליף בין תצוגת המשווק לבין הפורטל של הארגון שלו במקום, בלי כניסה נוספת.
קונסולת רישוי שמחזיקה פרטי התחברות ל-ERP היא הצורה הלא נכונה. זו מחזיקה כמה שפחות, ואומרת בדיוק איפה יושב כל השאר.
פרטי ההתחברות נשמרים מוצפנים ב-AWS SSM — לעולם לא במסד הנתונים של הקונסולה. סיסמת המשתמש הראשי מוצפנת ואינה מוצגת לאיש, וטננט יכול לשאת משתמש התחברות מוגבל נפרד כדי שהתעבורה היומיומית לא תרוץ תחת המשתמש הראשי.
שם המשתמש והסיסמה שלכם עוברים ישירות לשער ה-Priority כדי להנפיק את הטוקן — הם אינם נשמרים ואינם נרשמים בלוג. הפורטל מתאם את ההחלפה; הוא לא יושב באמצע שלה.
הסוד שחותם את המפתחות נשאר בצד המפעיל. הקונסולה חותמת ומאמתת מחדש מפתח בדיקה בכל עלייה, ובדיקת בילד חוסמת מהקונסולה בדפדפן לייבא בכלל את קוד שמירת המפתחות.
שום דבר לא נעצר. המפתחות חתומים ומאומתים מקומית, כך שהשער עונה לבקשות בלי לפנות אף פעם לשירות הרישוי. שליטה בזמן ההנפקה, לא תלות בזמן הבקשה.
מפתח On-Prem נקשר לטביעת האצבע של מכונת השער אצל הלקוח. אי-התאמה הופכת אותו לבלתי שמיש, כך שקובץ מפתח שדלף אינו הופך למפתח עובד במקום אחר.
טננט יכול לשאת עד עשר כותרות יוצאות, עבור לקוחות שמציבים לפני Priority שער כמו Cloudflare Access. השער מציג אותן בכל פנייה לאותו טננט.
הפורטל עצמו רץ על Amazon Web Services, באזור תל אביב של Amazon, כש-Cloudflare יושב לפני כל בקשה: הצפנת TLS, הגנה מפני מתקפות מניעת שירות, חומת אש לאפליקציות, הגבלת קצב וסינון בוטים. השרתים לא מקבלים חיבורים נכנסים — הם יוצרים קשר החוצה אל Cloudflare והתעבורה חוזרת דרך אותה מנהרה, כך שאין פורט ציבורי לסרוק, וממשקי התפעול יושבים מאחורי שער נוסף. הפריסות רצות מצינור גרסאות מסודר, והסודות שלמעלה שמורים מוצפנים ב-AWS Parameter Store.
הפורטל הוא דלת הכניסה. מאחוריו יושב השער שדרכו כל מוצר מדבר עם Priority, והכלים שהצוות שלכם נכנס אליהם עם החשבון האחד שההרשמה הזו יצרה.