הזהות שלך, תמיד
כל שותף שיתוף פעולה מתחבר בשם עצמו דרך Keycloak, שכבת זהות שלנו. איש אינו מקליד את הסיסמה שלך, איש אינו משתף הפעלת דפדפן, והסרת אדם מסוים היא פעולה אחת במקום החלפת סיסמה ומאמץ קדחתני לברר מי עוד ידע אותה.
גישה מואצלת
תן לאנשים בדיוק את הגישה שהם צריכים — ולא מעבר לכך
תנו גישה למפתח, העבירו את החשבונות לרואה החשבון שלכם, תנו ללקוח צפייה בלבד באתרים שלו, או תנו לצוות התמיכה שלנו לבדוק בעיה. כל הרשאה היא תפקיד עם הרשאות מוגדרות, המוגבל לארגון מסוים, נכפה במסד הנתונים ונכתב ליומן ביקורת שניתן רק להוסיף אליו.
- 94הרשאות מפורטות
- 12תפקידים מובנים מראש
- 8מחלקות צוות
- 650,000+אתרים המאוחסנים ברחבי העולם
גישה היא חברות, לא סיסמה משותפת
שיתוף שם משתמש וסיסמה הוא הדרך שבה גישה לחשבון משתבשת. ב-Zinn Digital® לכל אדם יש זהות משלו, והגישה היא חברות – משתמש, ארגון ותפקיד – שניתן להעניק, לשנות או לבטל באופן עצמאי.
ארגונים יוצרים מבנה עץ
חשבונות בנויים בהיררכיה — ארגון משווק מורשה מכיל ארגוני לקוחות, וארגוני לקוחות מכילים אתרים. חברות חלה על ארגון ועל כל מה שמתחתיו, כך שתוכלו להעניק ללקוח סוכנות שליטה על הארגון שלו מבלי לחשוף כלל את הלקוחות האחרים שלכם.
בידוד נכפה במסד הנתונים
הפרדת דיירים אינה מסנן בקוד היישום שבאג עלול לדלג עליו. אבטחת רמת השורות של Postgres מגבירה את טווח כל שאיתת לתת-עץ הארגון של הקורא, כך שלבקשה מחוץ לטווח שלך אין מה להחזיר.
היעדרות בלתי נראית
בקשה לגבי ארגון או אתר שאינם בטווח שלך נענית על ידי ה-API בשגיאת "לא נמצא" פשוטה במקום בשגיאת הרשאה. שגיאת הרשאה הייתה מאשרת שהרשומה קיימת; שגיאת "לא נמצא" אינה מגלה לגורם חיצוני שום דבר.
ארבעה תפקידי לקוח, שלושים וחמש הרשאות
הרשאות הן מפתחות מפורטים — מודול בתוספת פעולה, כמו sites.restart או billing.refund — ותפקידים מאגדים אותן יחד. ארבעה תפקידים מכסים את המבנים שצוותים אמיתיים צריכים, וכל אחד מהם הוא נתונים שאנו מטמיעים, ולא לוגיקה שמוסתרת בקוד.
בעלים
שליטה מלאה: יצירת ארגוני-בת, הזמנה והסרה של חברים, שינוי תפקידים, ניהול מפתחות API, יצירה, הפעלה מחדש, ניקוי, השעיה ומחיקה של אתרים, טיפול בחיוב ובחשבוניות, פתיחת פניות וקריאת יומן הרישום (audit log). התפקיד שאתה שומר לעצמך.
מנהל חיובים
רואה את הארגון, את חבריו ואת קatalog התוכניות, ומנהל חשבוניות, אמצעי תשלום וחיובים. אין לו גישה ליצור, לשנות או למחוק אתר בודד – בדיוק המבנה שרואה חשבון חיצוני אמור לקבל.
מפתח
צופה ויוצר אתרים, מפעיל מחדש שירותים, מנקה מטמון, מנהל מפתחות API ומטפל בפניות. מוחרגים במכוון: חיובים, חשבוניות, אמצעי תשלום, ניהול חברים, השעיית אתרים ומחיקת אתרים. קבלן יכול לבנות מבלי שתהיה לו אפשרות לחייב אתכם או להרוס דבר.
לקריאה בלבד
רואה את הארגון, את חבריו, את האתרים שלו, את החיוב, את קטלוג התוכניות, את הפניות, את סטטוס התרגום ואת יומן הביקורת — ואינו יכול לשנות דבר מכל אלה. ההרשאה המתאימה ללקוח המעוניין בנראות, למבקש, או לבעל עניין שצריך רק לצפות.
כניסת הצוות שלך אינה יכולה להיחלש בשקט
האצלת גישה בטוחה רק אם החשבונות שאליהם אתם מאצילים קשים להשתלטות. האימות פועל דרך Keycloak עבור כל אדם בחשבון, בכל ממשק.
- מפתחות גישה (Passkeys) ו-WebAuthn כהגנה מפני פישינג בכניסה למערכת, בתוספת אימות דו-שלבי מסוג TOTP שאכיפתו מחויבת על ידי המדיניות לכל המשתמשים — ולא כהגדרה אופציונלית שחבר צוות יכול לדלג עליה.
- התחברות באמצעות אימייל עם קישור קסם כברירת מחדל, עם אימייל וסיסמה כאפשרות חלופית, והתחברות חברתית דרך Google, Microsoft, GitHub ואחרים.
- כניסה יחידה (SSO) באמצעות SAML ללקוחות ארגוניים וסוכנויות, כך שניהול העובדים המצטרפים והעוזבים מתבצע דרך ספק הזהויות שלך ולא באופן ידני.
- ספה אחת בכל רחבי לוח הבקרה של הלקוח, האתר הציבורי ובסיס הידע, וכרטיסי התמיכה – היכנסו פעם אחת, ובטלו הרשאה פעם אחת.
- מדיניות סשנים, אימות מוגבר בפעולות רגישות, ורשימות היתרי IP אופציונליות לפי-ארגון עבור חשבונות המעוניינים בגישה המוגבלת לרשתות מוכרות.
- כל אימייל הרשמה עובר אימות לפני שנוצר חשבון, כך שכתובות שאינן ניתנות למסירה, כתובות חד פעמיות וכתובות תפקיד נתפסות בכניסה במקום להפוך לחברים נטושים בשלב מאוחר יותר.
כאשר הצוות שלנו זקוק לגישה, היא מוגבלת בהיקפה ומתועדת
עבודת תמיכה פירושה לעיתים להסתכל בתוך החשבון שלך. גישה זו כפופה לאותו מודל הרשאות כמו כל דבר אחר – אנשי הצוות פשוט יושבים בארגון צוות, המאורגן במחלקות עם הרשאות מצומצמות.
מחלקות, לא ניהול גורף
הצוותים מחולקים לתמיכה, חיוב ופיננסים, שימוש לרעה ואמון-ובטיחות, מכירות, קליטת לקוחות, הנדסה ותפעול, שיווק והנהלה. כל תפקיד מעניק מודולים ופעולות ספציפיים, כך שכל נציג רואה רק את החלק בקונסולת הניהול הנדרש לתפקידו ולא מעבר לכך.
התקרה האמיתית של נציג תמיכה
תפקיד נציג התמיכה מעניק בדיוק את הדברים הבאים: צפייה בלקוחות, צפייה ומענה לפניות, צפייה באתרים, הפעלה מחדש של אתר וניקוי המטמון שלו. הוא אינו כולל הגדרות חיוב, החזרים כספיים, עריכת תוכניות או ניהול צי. הפעולות המתקנות שנציג יכול לבצע מוגבלות על ידי התפקיד, ולא על ידי כוונות טובות.
הכניסה כלקוח מוגבלת ומאובטחת היטב
הרשאות customer.impersonate אינן חלק מתפקיד ה-Manager — הן שמורות ל-Super Admin בלבד. כאשר מופעלת הפעלה בשמך, לוח הבקרה מציג באנר התחזות קבוע כך שלעולם לא יהיה ספק מי פועל.
כל מה שבעל הרשאות נכתב
כל פעולה מורשית וניהולית מתווספת ליומן ביקורת חד-כיווני המתעד את המבצע, הפעולה, היעד, מטא-נתונים נלווים, כתובת ה-IP וחותמת הזמן — המחולקת לפי זמן בסביבת הייצור. בעלים וחברים בעלי הרשאת קריאה בלבד יכולים לקרוא את היומן של הארגון שלהם בעצמם.
שערי אישור לפעולות הרסניות
פעולות צוות רגישות והרסניות עשויות לדרוש אימות נוסף או אישור של שני אנשים לפני ביצוען, ומחלקות ותפקידים חדשים הם עניין של הגדרה ולא של שינוי קוד.
גם למכונות ניתנת גישה מורשית
סקים, צינורות CI, ממשק ה-CLI, ספק ה-Terraform וסוכני בינה מלאכותית מאמתים כולם את זהותם דרך אותו מודל הרשאות כמו בני אדם — ללא אישורים אנושיים משותפים, וללא סודות ארוכי טווח המודבקים לתוך תהליך בנייה.
מפתחות ה-API הם לפי ארגון ובעלי הרשאות מוגדרות
מפתחות שייכים לארגון ונושאים הרשאות מפורטות המקושרות לאותן הרשאות RBAC – קריאה בלבד, חיוב, והקצאה. הענק לצינור עיבוד נתונים (pipeline) את ההרשאה המצומצמת הנדרשת לו במקום את כל חשבון החבר.
מפתחות סביבת הניסוי נפרדים מסביבת הייצור
מפתחות במצב בדיקה ובמצב חי הם נפרדים, כך שאינטגרציה שנמצאת בפיתוח אינה יכולה לגשת לנתוני ייצור בטעות או עקב משתנה סביבה שהועתק.
רק ההאש נשמר
אנו שומרים את מקודד ה-SHA-256 של הסוד ואת קידומת החיפוש — לעולם לא את המפתח הגולמי. מפתח מוצג פעם אחת בעת היצירה. כל מפתח עוקב אחר השימוש האחרון בו וניתן לביטול בנפרד מבלי להשפיע על שום דבר אחר.
כלי בינה מלאכותית מתחברים תחת הרשאותיך
שרת ה-MCP שלנו מאפשר לכל סוכן תומך-MCP לנהל את האחסון שלך בשפה טבעית, מאומת עם OAuth 2.1 ומוגבל בהיקפו לארגון ולתפקיד ה-RBAC שלך, עם אסימונים הניתנים לביטול לכל כלי, אישור על פעולות הרסניות, תקרות הוצאות ורישום ביקורת מלא.
גישה לאתרים עצמם
גישה לחשבון וגישה לשרת הן בעיות שונות. אישורי גישה ברמת האתר מנוהלים בלוח הבקרה, מונפקים על בסיס הרשאות מינימליות, ומבודדים כך שה-shell של משתמש שותף אחד הוא ה-shell של אתר אחד בלבד.
- SSH עם מעטפת כלואה (jailed shell), לצד SFTP ו-FTP — בידוד CageFS אומר שכל דייר רואה רק את הקבצים שלו.
- WP-CLI מתוך מסוף הניהול ובאמצעות SSH, עבור הפעולות שמפתחים באמת רוצים לכתוב עבורן סקריפטים.
- עורך VS Code מלא בדפדפן באמצעות code-server — תוספים, מסוף משולב ו-git, המאפשרים לערוך את קבצי האתר ישירות מלוח הבקרה.
- phpMyAdmin ו-Adminer מוטמעים עבור מסדי נתונים ומנהל קבצים מוטמע, שניהם עם התחברות יחידה (SSO) מלוח הבקרה במקום הגנה מאחורי מערכת אישורים שנייה.
- מפתחות גישה ופרטי זיהוי נוצרים, מנויים, עוברים רוטציה ומבוטלים בלוח הבקרה, מונפקים בהרשאות מינימליות (least-privilege), והשימוש בהם מתועד ביומני ביקורת.
- העלאת אתר סביבת בדיקות (Staging) באמצעות שכפול (clone) ודחיפה ל-production (push-to-live) מרחיקה עבודה מסוכנת מסביבת הייצור, כך שהשינוי הראשון של משתף פעולה חדש לעולם אינו מגיע ישירות לאתר פעיל.
איך לבנות את הגישה שמתאימה לדרך שבה אתה באמת עובד
מפעיל יחיד מנהל ארגון בודד וחברות אחת בבעלות, ומוסיף תפקיד של מפתח (Developer) כאשר קבלן נכנס לפרויקט. כאשר הפרויקט מסתיים, החברות מוסרת והגישה שלהם לחשבון נפסקת באופן מיידי — לא נותרו פרטי התחברות משותפים שצריך להחליף.
סוכנות משתמשת בעץ הארגונים. כל לקוח מקבל ארגון-בן משלו, המכיל את האתרים של אותו לקוח, וחברי הצוות של הלקוח מקבלים שם חברויות – קריאה בלבד לבעל עניין שרוצה ראות, או בעלות ללקוח שרוצה שירות עצמי. אנשי הצוות שלך מחזיקים בחברויות גבוה יותר בעץ ורואים את תיק הפרויקטים; לקוח רואה רק את הענף שלו, ואבטחת רמת-השורה היא זו שעושה את זה לאמת ולא להבטחה.
משווק עובד באותו האופן, רמה אחת למעלה: ארגון משווק מחזיק בארגוני לקוחות, ולכל אחד מהם חברים, תצוגת חיוב ואתרים משלו. אותו פרימיטיב מפעיל תת-חשבונות, צוותי סוכנות והיררכיות של משווקים — אין מנגנון נפרד וחלש יותר עבור אף אחד מהם.
הכול זמין במסגרת תקופת הניסיון בת 14 הימים ללא צורך בכרטיס אשראי. היʽרשמו ללא פרטי תשלום, הזמינו קולגה, בדקו לאילו תכנים כל תפקיד יכול או לא יכול לגשת, ועיינו ביומן הביקורת (audit log) שלכם.
שאלות נפוצות
האם אדם מסוים יכול לקבל גישה לאתר אחד בלבד?
כיום, חברות מעניקה את התפקיד שלה ברחבי ארגון וכל מה שתחתיו בעץ, לכן הדרך להפריד בין קבוצות אתרים היא להפריד ארגונים — לשים את אותos האתרים בארגון-בת משלהם ולהעניק שם את החברות. זהו מודל נקי עבור סוכנויות ומשווקים מורשים, שבהם כל לקוח כבר רוצה את הגבולות שלו. תחום משאבים לפי חברות, כלומר הצמדת חברות בודדת לאתרים מוגדרים בתוך ארגון אחד, הוא שיפור מתוכנן ולא משהו שזמין כעת.
האם מפתח שאני מזמין יכול למחוק אתר או לבצע פוש לסביבת הייצור (live)?
תפקיד המפתח (Developer) אינו כולל מחיקת אתרים או השעיית אתרים — הרשאות אלו שייכות לתפקיד הבעלים (Owner). הוא מעניק הרשאה לצפות וליצור אתרים, להפעיל מחדש שירותים, לנקות מטמון, לנהל מפתחות API ולטפל בפניות תמיכה. הרשאות פריסה (Deployment) והעברה ל-live אינן כלולות גם הן בהרשאות המפתח, כך שקידום לסביבת הייצור נשאר בידי בעל החשבון. שלבו זאת עם סביבת סטייג'ינג (staging) כדי שסביבת הפיתוח תפעל מחוץ לאתר החי מלכתחילה.
מה צוות Zinn Digital® יכול לראות בחשבון שלי?
הדבר תלוי לחלוטין בתפקיד צוות העובדים, וכל תפקיד מורכב מקבוצה מצומצמת של מפתחות הרשאה. נציג תמיכה, לדוגמה, יכול לצפות בחשבון ובאתרים שלך, לצפות בפניות שלך ולהשיב עליהן, להפעיל מחדש אתר ולנקה את מטמון הזיכרון שלו — ואינו יכול לגעת בהגדרות החיוב, בהחזרים הכספיים, בתוכניות או בציוד. התחברות כלקוח היא הרשאה נפרדת המוחזקת אך ורק על ידי מנהל-על (Super Admin), וכאשר הדבר מתרחש, לוח הבקרה מציג באנר התחזות מתמיד. כל פעולה בעלת הרשאות מיוחדות מתועדת ביומן הביקורת יחד עם הגורם הפעיל, הפפעולה, היעד, כתובת ה-IP וחותמת הזמן, ובאפשרותך לקרוא בעצמך את היומן של הארגון שלך.
איך מבטלים גישה מהר אם מישהו עוזב?
הסרת החברות תסיים את הגישה שלהם לארגון שברשותך — נשארת להם הזהות משלהם, אך ללא תפקיד ולכן ללא הרשאות בחשבון שלך. מפתחות API מבוטלים באופן פרטני, כך שניתן לנתק מפתח של צינור עיבוד נתונים מבלי להפריע לרכיבים אחרים. אם הנך משתמש בהתחברות אחידה מסוג SAML, ביטול ההרשאות בספק הזהויות שלך מנהל את ההתחברות באופן מרכזי. אישורי גישה ברמת האתר, כגון מפתחות SSH, מבוטלים בלוח הבקרה, ועצם ההסרה נרשמת ביומן הביקורת.
האם חברי צוות משתפים את מפתחות ה-API שלי?
לא — אבל שווה לדייק לגבי הסיבה. מפתחות API שייכים לארגון, לא לחבר צוות יחיד, והם נושאים הרשאות מפורטות משלהם הקשורות לאותו קטלוג הרשאות. לכן, במקום למסור לאדם מפתח, יוצרים מפתח עבור המשימה שהוא מבצע עם ההרשאה המצומצמת ביותר שהמשימה דרישה, ומבטלים את המפתח כאשר המשימה מסתיימת. רק גיבוב (hash) של הסוד נשמר אי פעם, וכל מפתח מתעד מתי נעשה בו שימוש לאחרונה כך שקל לאתר מפתחות לא בשימוש ולהוציא אותם משימוש.
האם אני יכול לחבר סוכן בינה מלאכותית בלי לתת לו גישה להכל?
כן. שרת ה-MCP שלנו מאמת סוכנים באמצעות OAuth 2.1 ומגביל אותם לארגון שלך ולתפקיד ה-RBAC שלך, עם אסימונים הניתנים לביטול לכל כלי, כך שאתה מעניק יכולת ספציפית במקום גישה גורפת. פעולות הרסניות דורשות אישור, חליפות תקציב הוצאות חלות, וכל פעולה נרשמת באותו יומן ביקורת כמו פעילות אנושית.
מה מונע מדייר אחד להגיע לנתונים של דייר אחר?
אבטחת השורה של Postgres (Row-Level Security) מגבילה שאילתות לתת-עץ הארגוני של הקורא בתוך מסד הנתונים עצמו, כאשר המסנן ברמת היישום משמש הגנה לעומק ולא כקו ההגנה היחיד. בקשות לרשומות מחוץ לטווח מחזירות שגיאת "לא נמצא" במקום שגיאת הרשאה, כך ששום דבר אינו נחשף לגבי מה שקיים. בצד השרת, בידוד לכל אתר באמצעות CageFS שומר את המעטפת והקבצים של כל דייר באתר שלו בלבד.
האם אפשר לנסות את זה לפני התשלום?
כן. תקופת הניסיון בת 14 הימים אינה דורש כרטיס אשראי – ללא פרטי תשלום, ללא התחייבות – והיא כוללת את Footprint-Free Hosting עבור עד חמישה אתרים. היא מספיקה כדי להזמין עמית, להקצות תפקיד ולאמת שהגבולות פועלים בדיוק כפי שאתה צריך לפני שאתה מתחייב.
קשורים
להאציל סמכות עם גבול שאפשר להצביע עליו
התחל את תקופת הניסיון בת 14 הימים ללא צורך בכרטיס אשראי, הזמן מישהו, וראה כיצד מודל ההרשאות עושה את העבודה – תפקידים שתוכל לקרוא להם בשם, היקפים שתוכל לבטל, ויומן ביקורת שאומר בדיוק מי עשה מה.
התחל בחינם