הזהות שלכם, תמיד
כל משתף פעולה מתחבר בשמו באמצעות Keycloak, שכבת הזהויות שלנו. איש אינו מקליד את הסיסמה שלכם, איש אינו משתף הפעלת דפדפן, והסרת אדם היא פעולה אחת בלבד במקום החלפת סיסמה וחיפוש קדחתני אחר מי עוד ידע אותה.
גישה מואצלת
העניקו לאנשים בדיוק את הגישה שהם צריכים — ושום דבר מעבר לכך
צרפו מפתח, העבירו את החיוב לרואה החשבון שלכם, העניקו ללקוח גישת קריאה בלבד לאתרים שלו, או אפשרו לצוות התמיכה שלנו לבדוק תקלה. כל הענקת גישה היא תפקיד בעל הרשאות מוגדרות, המוגבל לארגון, נאכף במסד הנתונים ונרשם ביומן ביקורת המיועד להוספה בלבד.
- 94הרשאות מפורטות
- 12תפקידים מובנים
- 8מחלקות צוות
- +700,000אתרים המאוחסנים ברחבי העולם
גישה היא חברות, לא סיסמה משותפת
שיתוף פרטי התחברות בודדים הוא הגורם לשיבושים בגישה לחשבון. ב-Zinn Digital®, לכל אדם יש זהות משלו, והגישה היא חברות — משתמש, ארגון ותפקיד — שבאפשרותכם להעניק, לשנות או לשלול באופן עצמאי.
ארגונים יוצרים מבנה עץ
החשבונות הם היררכיים — ארגון משווק מכיל ארגוני לקוחות, וארגוני לקוחות מכילים אתרים. חברות חלה על ארגון ועל כל מה שתחתיו, כך שתוכלו להעניק ללקוח סוכנות שליטה על הארגון שלו מבלי לחשוף לעולם את לקוחותיכם האחרים.
בידוד נאכף במסד הנתונים
הפרדת דיירים אינה מסנן בקוד האפליקציה שתקלה עלולה לדלג עליו. אבטחה ברמת השורה (Row-Level Security) של Postgres תוחמת כל שאילתה לתת-העץ הארגוני של הקורא, כך שלבקשה שמחוץ לתחום שלך אין מה להחזיר.
היעדרות אינה נראית
בקשו ארגון או אתר מחוץ לטווח ההרשאות שלכם, וה-API ישיב בשגיאת "לא נמצא" פשוטה במקום בשגיאת הרשאה. שגיאת הרשאה הייתה מאשרת שהרשומה קיימת; שגיאת "לא נמצא" אינה מוסרת לגורם חיצוני דבר.
ארבעה תפקידי לקוח, שלושים וחמש הרשאות
הרשאות הן מפתחות פרטניים — מודול בתוספת פעולה, כמו sites.restart או billing.refund — ותפקידים מאגדים אותן. ארבעה תפקידים מכסים את המבנים שצוותים אמיתיים זקוקים להם, וכל אחד מהם הוא נתונים שאנו מאכלסים מראש, ולא לוגיקה הקבורה בקוד.
בעלים
שליטה מלאה: צרו ארגוני משנה, הזמינו והסירו חברים, שנו תפקידים, נהלו מפתחות API, צרו, הפעילו מחדש, בצעו מחיקה מוחלטת, השעו ומחקו אתרים, נהלו חיובים וחשבוניות, פתחו קריאות שירות וקראו את יומן הביקורת. התפקיד שאתם שומרים לעצמכם.
מנהל חיובים
רואה את הארגון, חבריו וקטלוג התוכניות, ומנהל חשבוניות, אמצעי תשלום וחיובים. ללא גישה ליצירה, שינוי או מחיקה של אף אתר — בדיוק ההגדרה שרואה חשבון חיצוני צריך לקבל.
מפתח
מציג ויוצר אתרים, מפעיל מחדש שירותים, מנקה זיכרון מטמון, מנהל מפתחות API ומטפל בפניות. הוחרגו במכוון: חיוב, חשבוניות, אמצעי תשלום, ניהול חברים, השעיית אתרים ומחיקת אתרים. קבלן יכול לבנות מבלי שתהיה לו אפשרות לחייב אתכם או להרוס דבר.
לקריאה בלבד
רואה את הארגון, את חבריו, את האתרים שלו, את החיובים שלו, את קטלוג התוכניות, את הקריאות, את סטטוס התרגום ואת יומן הביקורת — ואינו יכול לשנות דבר מכל אלה. ההרשאה הנכונה עבור לקוח המעוניין בשקיפות, מבקר, או בעל עניין שרק צריך לצפות.
התחברות שהצוות שלכם אינו יכול להחליש בחשאי
האצלת גישה בטוחה רק אם קשה להשתלט על החשבונות שאתם מאצילים אליהם. האימות מתבצע דרך Keycloak עבור כל אדם בחשבון, בכל ממשק.
- מפתחות גישה (Passkeys) ו-WebAuthn לכניסה מוגנת מפני דיוג (פישינג), בתוספת אימות דו-שלבי באמצעות TOTP הנאכף על כולם בהתאם למדיניות — ולא כהגדרה אופציונלית שחבר צוות יכול לדלג עליה.
- התחברות באימייל באמצעות קישור קסם כברירת מחדל, עם אימייל וסיסמה כגיבוי, והתחברות חברתית דרך Google, Microsoft, GitHub ואחרים.
- התחברות יחידה (SSO) באמצעות SAML עבור לקוחות ארגוניים וסוכנויות, כך שהצטרפות ועזיבה של עובדים מנוהלות על ידי ספק הזהויות שלכם ולא באופן ידני.
- הפעלה אחת בכל ממשק הלקוח, האתר הציבורי, מאגר הידע וקריאות השירות — היכנסו פעם אחת, ובטלו גישה פעם אחת.
- מדיניות הפעלות, אימות מוגבר בפעולות רגישות ורשימות היתרי IP אופציונליות לכל ארגון עבור חשבונות המעוניינים להגביל את הגישה לרשתות מוכרות.
- כל כתובת אימייל להרשמה מאומתת לפני שחשבון נוצר, כך שכתובות שאינן ניתנות למסירה, כתובות חד-פעמיות וכתובות תפקיד נתפסות כבר בכניסה במקום להפוך מאוחר יותר לחברים יתומים.
כאשר הצוות שלנו זקוק לגישה, היא מוגדרת בהיקפה ומתועדת
עבודת התמיכה דורשת לעיתים בדיקה בתוך החשבון שלכם. גישה זו מנוהלת על פי אותו מודל הרשאות כמו כל דבר אחר — אנשי הצוות פשוט משתייכים לארגון צוות, המאורגן במחלקות בעלות הרשאות מצומצמות.
מחלקות, לא מנהל מערכת גורף
אנשי הצוות מחולקים לתמיכה, חיוב וכספים, מניעת שימוש לרעה ואמון ובטיחות, מכירות, קליטת לקוחות, הנדסה ותפעול, שיווק והנהלה. כל תפקיד מעניק גישה לרכיבים ולפעולות ספציפיים, כך שנציג רואה רק את החלק בלוח הבקרה של מנהל המערכת הנדרש לעבודתו ולא את השאר.
התקרה האמיתית של נציג תמיכה
תפקיד נציג התמיכה מעניק בדיוק את הדברים הבאים: הצגת לקוחות, הצגת פניות ומענה עליהן, הצגת אתרים, הפעלה מחדש של אתר וניקוי זיכרון המטמון שלו. הוא אינו כולל שום הגדרת חיוב, החזרי תשלום, עריכת תוכניות וניהול צי אתרים. פעולות התיקון שנציג יכול לבצע מוגבלות על ידי התפקיד, ולא על ידי כוונות טובות.
ההתחברות כלקוח מוגבלת באופן קפדני
הרשאת customer.impersonate אינה חלק מתפקיד Manager — היא מוחזקת על ידי Super Admin בלבד. כאשר הפעלה פועלת מטעמכם, לוח הבקרה מציג כרזת התחזות קבועה כך שלעולם אין עמימות לגבי זהות הפועל.
כל מה שחסוי מועלה על הכתב
כל פעולה מנהלית ובעלת הרשאות מיוחדות מתווספת ליומן ביקורת המאפשר הוספה בלבד, המתעד את המבצע, הפעולה, היעד, מטא-נתונים תומכים, כתובת ה-IP וחותמת הזמן — מחולק לפי זמן בסביבת הייצור. בעלים וחברים בעלי הרשאת קריאה בלבד יכולים לקרוא את היומן של הארגון שלהם בעצמם.
שלבי אישור עבור פעולות הרסניות
פעולות רגישות והרסניות של הצוות עשויות לדרוש אימות מוגבר או אישור של שני אנשים לפני הפעלתן, ומחלקות ותפקידים חדשים מוגדרים באמצעות קביעת תצורה ולא באמצעות שינוי קוד.
מכונות מקבלות גם גישה מואצלת
סקריפטים, צינורות CI, ה-CLI, ספק ה-Terraform וסוכני הבינה המלאכותית מאמתים כולם דרך אותו מודל הרשאות כמו בני אדם — ללא אישורי אנוש משותפים, ללא סודות ארוכי טווח המודבקים לתוך build.
מפתחות ה-API הם ברמת הארגון ובעלי היקף הרשאות מוגדר
מפתחות שייכים לארגון וכוללים הרשאות מפורטות המקושרות לאותן הרשאות RBAC — קריאה בלבד, חיוב, הקצאה. העניקו לצינור העיבוד (pipeline) את ההיקף המצומצם הדרוש לו במקום את כל החשבון של החבר.
מפתחות Sandbox נפרדים מסביבת הייצור
מפתחות מצב בדיקה ומצב חי הם שונים, כך שאינטגרציה בפיתוח אינה יכולה לגשת לנתוני סביבת הייצור בטעות או באמצעות משתנה סביבה שהועתק.
רק ה-hash נשמר
אנו שומרים גיבוב 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) מלוח הבקרה במקום לדרוש מערך הרשאות נוסף.
- מפתחות גישה ופרטי אימות נוצרים, מוצגים, מוחלפים ומבוטלים בלוח הבקרה, מונפקים בהרשאות מינימליות, והשימוש בהם מתועד ביומן ביקורת.
- סביבת בדיקות עם שכפול והעלאה ישירה לאוויר מרחיקה עבודה בעלת סיכון מסביבת הייצור, כך שהשינוי הראשון של משתף פעולה חדש לעולם אינו מגיע ישירות לאתר פעיל.
כיצד להגדיר את מבנה הגישה באופן שמתאים לדרך שבה אתם באמת עובדים
מפעיל יחיד שומר על ארגון בודד ועל חברות בעלים אחת, ומוסיף תפקיד מפתח כאשר קבלן מצטרף לפרויקט. עם סיום הפרויקט, החברות מוסרת והכניסה שלו מפסיקה לפעול באופן מיידי — לא נותרים פרטי גישה משותפים שיש להחליף.
סוכנות משתמשת בעץ הארגון. כל לקוח מקבל ארגון-בת משלו, המכיל את האתרים של אותו לקוח, ואנשי הלקוח עצמו מקבלים חברויות שם — לקריאה בלבד עבור בעל עניין שמעוניין בנראות, בעלים עבור לקוח שמעוניין בשירות עצמי. הצוות שלכם מחזיק בחברויות גבוה יותר בעץ ורואה את הפורטפוליו; לקוח רואה רק את הענף שלו, ו-Row-Level Security הוא מה שהופך זאת לאמת ולא להבטחה בלבד.
משווק פועל באותו האופן, רמה אחת גבוה יותר: ארגון משווק מכיל ארגוני לקוחות, כאשר לכל אחד מהם חברים משלו, תצוגת חיוב ואתרים. אותו רכיב בסיסי מפעיל חשבונות משנה, צוותי סוכנויות והיררכיות של משווקים — אין מנגנון נפרד וחלש יותר עבור אף אחד מהם.
הכול זמין בתקופת הניסיון ל-14 יום ללא צורך בכרטיס אשראי. הירשמו ללא פרטי תשלום, הזמינו עמית לעבודה, צפו לאילו משאבים כל תפקיד יכול או אינו יכול לגשת, ועיינו ביומן הביקורת שלכם.
שאלות נפוצות
האם ניתן להעניק למישהו גישה לאתר אחד בלבד?
כיום, חברות מעניקה את תפקידה בכל רחבי הארגון ובכל מה שנמצא תחתיו בהיררכיה, ולכן הדרך להפריד בין קבוצות אתרים היא להפריד בין ארגונים — הציבו את אותם אתרים בארגון-בן משלהם והעניקו את החברות שם. זהו מודל מסודר עבור סוכנויות ומשווקים, שבהם כל לקוח כבר מעוניין בהפרדה משלו. הגדרת היקף משאבים ברמת החברות, כלומר הצמדת חברות יחידה לאתרים ספציפיים בתוך ארגון אחד, היא שיפור מתוכנן ולא תכונה הזמינה כעת.
האם מפתח שאני מזמין יכול למחוק אתר או להעביר אותו ל-live?
תפקיד ה-Developer אינו כולל מחיקת אתר או השעיית אתר — מפתחות אלה שייכים לתפקיד ה-Owner. הוא מעניק הרשאות לצפייה וליצירת אתרים, להפעלת שירותים מחדש, לניקוי זיכרון מטמון, לניהול מפתחות API ולטיפול בפניות. הרשאות פריסה ו-push-to-live גם הן אינן חלק מהרשאות ה-Developer, ולכן העברה לסביבת הייצור נשארת בידי בעל החשבון. שלבו זאת עם סביבת בדיקות (staging) כדי שעבודת הפיתוח תתבצע מלכתחילה מחוץ לאתר הפעיל.
מה צוות Zinn Digital® יכול לראות בחשבון שלי?
הדבר תלוי לחלוטין בתפקיד איש הצוות, וכל תפקיד מהווה מערך מצומצם של מפתחות הרשאה. נציג תמיכה, לדוגמה, יכול לצפות בחשבונכם ובאתרים שלכם, לצפות בפניות שלכם ולהשיב להן, להפעיל מחדש אתר ולנקות את זיכרון המטמון שלו — אך אינו יכול לגעת בהגדרות החיוב, בהחזרים כספיים, בתוכניות או בצי השרתים. כניסה למערכת כלקוח היא הרשאה נפרדת השמורה ל-Super Admin בלבד, וכאשר היא מתרחשת מופיע בלוח הבקרה באנר התחזות קבוע. כל פעולה בעלת הרשאות מיוחדות מתועדת ביומן הביקורת יחד עם המבצע, הפעולה, היעד, כתובת ה-IP וחותמת הזמן, ובאפשרותכם לקרוא את היומן של הארגון שלכם בעצמכם.
כיצד אוכל לבטל את הגישה במהירות אם מישהו עוזב?
הסירו את החברות והגישה שלהם לאותו ארגון תסתיים — עדיין תהיה להם זהות משלהם, אך ללא תפקיד ולפיכך ללא הרשאות בחשבונכם. מפתחות API מבוטלים בנפרד, כך שניתן לנתק מפתח pipeline מבלי לשבש שום דבר אחר. אם אתם משתמשים ב-SAML single sign-on, ביטול ההקצאה (deprovisioning) בספק הזהויות שלכם מטפל בהתחברות באופן מרוכז. אישורי גישה ברמת האתר כגון מפתחות SSH מבוטלים בלוח הבקרה, וההסרה עצמה מתועדת ביומן הביקורת.
האם חברי הצוות משתפים את מפתחות ה-API שלי?
לא — אך כדאי לדייק לגבי הסיבה. מפתחות API שייכים לארגון ולא לחבר יחיד, והם נושאים הרשאות פרטניות משלהם הקשורות לאותו קטלוג הרשאות. לכן, במקום למסור מפתח לאדם, אתם יוצרים מפתח עבור המשימה שעליו לבצע עם ההרשאה המצומצמת ביותר שהמשימה דורשת, ומבטלים את המפתח עם סיום המשימה. רק גיבוב (hash) של הסוד נשמר אי פעם, וכל מפתח מתעד מתי נעשה בו שימוש לאחרונה, כך שקל לאתר מפתחות שאינם בשימוש ולהוציאם מכלל פעולה.
האם אוכל לחבר סוכן בינה מלאכותית מבלי לתת לו את המפתחות להכול?
כן. שרת ה-MCP שלנו מאמת סוכנים באמצעות OAuth 2.1 ומגביל את תחום הפעולה שלהם לארגון שלכם ולתפקיד ה-RBAC שלכם, עם אסימונים הניתנים לביטול לכל כלי, כך שאתם מעניקים יכולת ספציפית במקום גישה גורפת. פעולות הרסניות דורשות אישור, חלות מגבלות הוצאה, וכל פעולה נרשמת באותו יומן ביקורת של פעילות אנושית.
מה מונע מדייר אחד לגשת לנתונים של דייר אחר?
אבטחה ברמת השורה ב-Postgres מגבילה שאילתות לתת-העץ של ארגון הקורא בתוך מסד הנתונים עצמו, כאשר המסנן ברמת האפליקציה משמש כהגנה רב-שכבתית ולא כקו ההגנה היחיד. בקשות לרשומות שמחוץ להיקף מחזירות שגיאת "לא נמצא" במקום שגיאת הרשאה, כך ששום דבר אינו נחשף על מה שקיים. בצד השרת, בידוד לכל אתר באמצעות CageFS שומר את המעטפת (shell) והקבצים של כל דייר באתר שלו בלבד.
האם אוכל לנסות זאת לפני התשלום?
כן. תקופת הניסיון למשך 14 יום אינה דורשת כרטיס אשראי — ללא פרטי תשלום וללא התחייבות — וכוללת אחסון Footprint-Free עבור עד חמישה אתרים. די בכך כדי להזמין עמית לעבודה, להקצות תפקיד ולוודא שההפרדות מתפקדות כפי שאתם צריכים לפני שתתחייבו.
קשור
האצילו סמכויות עם גבול שתוכלו להצביע עליו
התחילו בתקופת הניסיון למשך 14 יום ללא צורך בכרטיס אשראי, הזמינו משתמש וראו כיצד מודל ההרשאות עושה את עבודתו — תפקידים שבאפשרותכם לתת להם שם, היקפי גישה שבאפשרותכם לבטל ויומן ביקורת המפרט בדיוק מי עשה מה.
התחל בחינם