دسترسی تفویضشده
یک توسعهدهنده را بیاورید، صورتحساب را به حسابدار خود بسپارید، به مشتری یک نمای فقطخواندنی از وبسایتهای خودش بدهید، یا به تیم پشتیبانی ما اجازه دهید مشکلی را بررسی کند. هر دسترسی یک نقش با مجوزهای مشخص است، که به یک سازمان محدود شده، در پایگاه داده اعمال میشود و در یک گزارش حسابرسی الحاقفقط ثبت میگردد.
اشتراکگذاری یک ورود به سیستم همان چیزی است که دسترسی به حساب را دچار مشکل میکند. در Zinn Digital® هر فرد هویت خود را دارد و دسترسی یک عضویت است — یک کاربر، یک سازمان و یک نقش — که میتوانید آن را به صورت مستقل اعطا، تغییر یا لغو کنید.
هر همکار با هویت خودش از طریق Keycloak که لایه شناسایی ماست وارد میشود. هیچکس رمز عبور شما را تایپ نمیکند، هیچکس جلسه مرورگر را به اشتراک نمیگذارد، و حذف کردن یک نفر تنها یک اقدام است به جای چرخش رمز عبور و تقلا برای فهمیدن اینکه چه کس دیگری آن را میدانست.
حسابها به صورت سلسلهمراتبی هستند — یک سازمان نمایندهفروش، سازمانهای مشتری را در بر میگیرد و سازمانهای مشتری، وبسایتها را در بر میگیرند. یک عضویت شامل یک سازمان و تمام زیرمجموعههای آن میشود، بنابراین میتوانید کنترل سازمان خودشان را به یک مشتری آژانس واگذار کنید بدون اینکه سایر مشتریانتان هرگز در معرض دید قرار گیرند.
جداسازی تننت یک فیلتر در کد برنامه نیست که یک باگ بتواند از آن عبور کند. امنیت در سطح سطر پوستگرس (Postgres RLS) هر پرسوجو را به زیردرخت سازمان فراخواننده محدود میکند، بنابراین یک درخواست خارج از محدوده شما هیچ چیزی برای بازگرداندن ندارد.
درخواست سازمان یا سایتی خارج از حوزه دسترسی شما، پاسخ API را بهجای خطای دسترسی، با یک پاسخ سادهی یافتنشد (not-found) همراه میکند. خطای دسترسی تأیید میکند که رکورد وجود دارد؛ اما پاسخ یافتنشد هیچگونه اطلاعاتی به فرد خارج از سیستم نمیدهد.
دسترسیها کلیدهایی جزئی و دقیق هستند — ماژول به همراه عمل، مانند sites.restart یا billing.refund — و نقشها آنها را دستهبندی میکنند. چهار نقش الگوهای مورد نیاز تیمهای واقعی را پوشش میدهند، و هر کدام دادهای هستند که ما مقداردهی اولیه میکنیم، نه منطقی که در کد پنهان شده باشد.
کنترل کامل: ایجاد سازمانهای زیرمجموعه، دعوت و حذف اعضا، تغییر نقشها، مدیریت کلیدهای API، ایجاد، راهاندازی مجدد، پاکسازی، مع حالت تعلیق درآوردن و حذف سایتها، مدیریت صورتحسابها و فاکتورها، ثبت تیکتها و مطالعه گزارش حسابرسی. نقشی که برای خود نگه میدارید.
سازمان، اعضای آن و کاتالوگ طرح را میبیند و فاکتورها، روشهای پرداخت و هزینهها را مدیریت میکند. دسترسی به ایجاد، تغییر یا حذف حتی یک سایت وجود ندارد — دقیقاً همان ساختاری که یک حسابدار خارجی باید داشته باشد.
مشاهده و ایجاد سایتها، راهاندازی مجدد سرویسها، پاکسازی کش، مدیریت کلیدهای API و رسیدگی به تیکتها. بهطور عمدی مستثنی شده است: صورتحساب، فاکتورها، روشهای پرداخت، مدیریت اعضا، معلقسازی سایت و حذف سایت. یک پيمانكار میتواند بدون توانایی در صدور صورتحساب برای شما یا تخریب هر چیزی، به ساختوساز بپردازد.
سازمان، اعضای آن، سایتها، صورتحساب، کاتالوگ طرح، تیکتها، وضعیت ترجمه و گزارش حسابرسی را مشاهده میکند — و هیچیک را نمیتواند تغییر دهد. دسترسی مناسب برای مشتریای که خواهان دیدهبانی است، یک حسابرس، یا ذینفعی که فقط نیاز به نگاه کردن دارد.
اعطای دسترسی تنها در صورتی امن است که حسابهایی که به آنها دسترسی واگذار میکنید به سختی قابل نفوذ باشند. احراز هویت برای هر فرد روی حساب کاربری و در تمامی سطوح، از طریق Keycloak انجام میشود.
کار پشتیبانی گاهی اوقات به معنای بررسی درون حساب شماست. این دسترسی تحت همان مدل دسترسی مدیریت میشود که سایر بخشها را کنترل میکند — کارکنان صرفاً در یک سازمانِ کارمندی قرار دارند و در دپارتمانهایی با مجوزهای محدود سازماندهی شدهاند.
کارکنان در دستههای پشتیبانی، صورتحساب و مالی، سوءاستفاده و اعتماد و ایمنی، فروش، آشناسازی، مهندسی و عملیات، بازاریابی و مدیریت دستهبندی میشوند. هر نقش ماژولها و اقدامات خاصی را اعطا میکند، بهطوریکه هر عامل تنها بخشی از کنسول مدیریتی را که شغلش نیاز دارد میبیند و نه بقیه را.
نقش پشتیبان دقیقاً همین امکانات را فراهم میکند: مشاهده مشتریان، مشاهده و پاسخ به تیکتها، مشاهده سایتها، راهاندازی مجدد سایت و پاکسازی کش آن. این نقش شامل هیچگونه تنظیمات صورتحساب، استرداد وجه، ویرایش طرح و مدیریت ناوگان نمیشود. اصلاحاتی که یک عامل پشتیبان میتواند انجام دهد، توسط این نقش محدود میشود، نه با نیتهای خوب.
مجوز customer.impersonate بخشی از نقش مدیر نیست — بلکه فقط در اختیار مدیر کل (Super Admin) است. هنگامی که نشستی از طرف شما در حال اجرا است، داشبورد دارای یک بنر دائمی جعل هویت است تا هرگز ابهامی درباره اینکه چه کسی در حال فعالیت است وجود نداشته باشد.
هر اقدام مدیریتی و دارای دسترسی ویژه به یک سیاهه حسابرسی فقطافزودنی اضافه میشود که عامل، اقدام، هدف، فرادادههای پشتیبان، نشانی IP و زمانسنج را ثبت میکند — که در محیط تولید بر اساس زمان پارتیشنبندی شدهاند. مالکان و اعضای با دسترسی صرفاً خواندنی میتوانند خودشان سیاهه سازمان خود را بخوانند.
اقدامات حساس و مخرب کارمندان ممکن است پیش از اجرا نیازمند احراز هویت مرحلهای یا تأیید دونفره باشند، و دپارتمانها و نقشهای جدید بهجای تغییر کد، از طریق پیکربندی انجام میشوند.
اسکریپتها، خطوط لوله CI، رابط خط فرمان، ارائهدهنده Terraform و عاملیتهای هوش مصنوعی همگی از طریق همان مدل دسترسی کاربران احراز هویت میشوند؛ بدون هیچگونه اعتبارنامه انسانی مشترک و بدون اسرار ماندگاری که در یک ساخت قرار گیرند.
کلیدها متعلق به یک سازمان هستند و دارای محدودههای دسترسی جزئی منطبق با همان مجوزهای RBAC هستند — فقط خواندنی، صورتحساب، و ارائهدهی. به جای کل حساب یک عضو، محدودهٔ دسترسی محدودی را که پایپلاین نیاز دارد به آن اعطا کنید.
کلیدهای حالت تست و حالت زنده متمایز هستند، بنابراین یکپارچهسازی در حال توسعه نمیتواند بهطور تصادفی یا از طریق یک متغیر محیطی کپیشده به دادههای محیط تولید دسترسی پیدا کند.
ما یک هش SHA-256 از راز و یک پیشوند جستجو را ذخیره میکنیم — هرگز کلید خام را. شما یک کلید را فقط یک بار در زمان ایجاد میبینید. هر کلید زمان آخرین استفاده خود را ردیابی میکند و میتواند به طور مستقل و بدون ایجاد اختلال در سایر موارد لغو شود.
سرور MCP ما به هر عامل مجهز به MCP اجازه میدهد تا میزبانی شما را با زبان طبیعی مدیریت کند. این احراز هویت با OAuth 2.1 انجام میشود و به سازمان و نقش RBAC شما محدود است. همچنین دارای توکنهای قابل لغو برای هر ابزار، تأیید برای عملکردهای مخرب، سقف هزینهها و ثبت کامل حسابرسی (audit logging) است.
دسترسی به حساب کاربری و دسترسی به سرور مسائل متفاوتی هستند. اعتبارنامههای سطح سایت در داشبورد مدیریت میشوند، با حداقل دسترسی صادر میگردند و در فضای ایزوله قرار میگیرند تا شل هر همکار تنها متعلق به یک سایت باشد.
یک اپراتور تنها یک سازمان و یک عضویت به عنوان مالک را نگه میدارد و هنگامی که یک پیمانکار برای یک پروژه میآید، نقش «توسعهدهنده» را اضافه میکند. با پایان یافتن پروژه، عضویت حذف میشود و ورود به سیستم آنها بلافاصله متوقف میشود — هیچ اعتبارنامه مشترکی برای تغییر دادن باقی نمیماند.
یک آژانس از ساختار درختی سازمان استفاده میکند. هر مشتری سازمان فرعی خود را دارد که سایتهای آن مشتری را در خود جای داده است و افراد خود مشتری عضویتهایی در آنجا دارند — دسترسی فقط خواندنی برای ذینفعی که میخواهد دید داشته باشد، و مالک برای مشتری که میخواهد خودش کارها را انجام دهد. کارکنان شما عضویتهای بالاتری در درخت دارند و پورتفولیو را میبینند؛ یک مشتری فقط شاخه خود را میبیند، و امنیت سطح رسطری (Row-Level Security) چیزی است که به جای یک وعده، این موضوع را واقعیت میبخشد.
یک نمایندگی فروش به همان روش کار میکند، اما یک سطح بالاتر: یک سازمان نمایندگی فروش، سازمانهای مشتری را در خود جای داده است که هر کدام دارای اعضا، نمای صورتحساب و سایتهای خاص خود هستند. همان ساختار پایهای به زیرحسابها، تیمهای آژانس و سلسلهمراتبهای نمایندگی فروش قدرت میدهد — هیچ مکانیزم جداگانه و ضعیفتری برای هیچیک از آنها وجود ندارد.
همه چیز در دوره آزمایشی ۱۴ روزه بدون نیاز به کارت بانکی در دسترس است. بدون ارائه اطلاعات پرداخت ثبتنام کنید، یک همکار را دعوت کنید، ببینید هر نقش به چه چیزی دسترسی دارد یا ندارد و گزارش حسابرسی خود را مرور کنید.
امروز یک عضویت نقش خود را در کل یک سازمان و تمام زیرمجموعههای آن در ساختار درختی اعمال میکند، بنابراین راه جدا کردن مجموعههای سایت، تفکیک سازمانها است — آن سایتها را در سازمان فرعی خودشان قرار دهید و عضویت را در همانجا اعطا کنید. این یک مدلساختار تمیز برای آژانسها و نمایندگان فروش است، جایی که هر مشتری از قبل میخواهد محدوده خودش را داشته باشد. محدودسازی منابع به ازای هر عضویت، یعنی اختصاص دادن یک عضویت منفرد به سایتهای نامگذاریشده در یک سازمان، بهجای اینکه در حال حاضر در دسترس باشد، یک بهبود برنامهریزیشده است.
نقش توسعهدهنده شامل حذف یا معلقسازی سایت نمیشود — این کلیدها متعلق به نقش مالک هستند. این نقش دسترسی به مشاهده و ایجاد سایتها، راهاندازی مجدد سرویسها، پاکسازی کش، مدیریت کلیدهای API و کار با تیکتها را اعطا میکند. مجوزهای استقرار و ارسال به محیط زنده نیز جزو دسترسیهای توسعهدهنده نیستند، بنابراین ارتقا به محیط پروداکشن نزد مالک حساب باقی میماند. آن را با محیط استیجینگ ترکیب کنید تا کار ساخت در وهله اول دور از سایت زنده انجام شود.
این مسئله کاملاً به نقش کارمند بستگی دارد و هر نقش مجموعهای محدود از کلیدهای دسترسی است. برای مثال، یک عامل پشتیبانی میتواند حساب و سایتهای شما را مشاهده کند، تیکتهای شما را ببیند و به آنها پاسخ دهد، یک سایت را مجدداً راهافازی کرده و حافظه پنهان (کش) آن را پاکسازی کند — و نمیتواند به تنظیمات صورتحساب، استرداد وجه، پلنها یا ناوگان دست بزند. ورود به سیستم به عنوان یک مشتری، یک دسترسی جداگانه است که فقط در اختیار مدیر کل (Super Admin) قرار دارد و هنگام وقوع آن، داشبورد یک بنر دائمی جعل هویت را نمایش میدهد. هر اقدام دارای امتیاز در گزارش حسابرسی همراه با عامل، اقدام، هدف، IP و زمانثبت ضبط میشود و شما میتوانید خودتان گزارش سازمانتان را مطالعه کنید.
عضویت را حذف کنید و دسترسی آنها به آن سازمان پایان مییابد — آنها همچنان هویت خود را دارند، اما هیچ نقش و در نتیجه هیچ مجوزی در حساب شما ندارند. کلیدهای API به صورت جداگانه لغو میشوند، بنابراین یک کلید پایپلاین را میتوان بدون مختل کردن چیز دیگری قطع کرد. اگر از ورود تکمرحلهای SAML استفاده میکنید، سلب تهیهسازی (deprovisioning) در ارائهدهنده هویت شما، ورود به سیستم را به صورت متمرکز مدیریت میکند. اعتبارنامههای سطح سایت مانند کلیدهای SSH در داشبورد لغو میشوند و خود حذف در سیاهه حسابرسی ثبت میگردد.
خیر — اما دقیق بودن درباره دلیل آن ارزشمند است. کلیدهای API متعلق به سازمان هستند، نه به یک عضو منفرد، و دارای محدودههای تفکیکشده خاص خود هستند که به همان کاتالوگ دسترسی مرتبط شدهاند. بنابراین بهجای دادن یک کلید به شخص، شما کلیدی را برای کاری که انجام میدهد با محدودترین دامنه مورد نیاز آن کار ایجاد میکنید و وقتی کار به پایان رسید، آن کلید را باطل میکنید. فقط هش کلید مخفی ذخیره میشود و هر کلید زمان آخرین استفاده خود را ثبت میکند تا پیدا کردن و بازنشستهکردن کلیدهای استفادهنشده آسان باشد.
بله. سرور MCP ما ایجنتها را با OAuth 2.1 احراز هویت کرده و دسترسی آنها را به سازمان شما و نقش RBAC شما محدود میکند. این کار با توکنهای قابل لغو برای هر ابزار انجام میشود تا به جای دسترسی کلی، قابلیت خاصی را اعطا کنید. اقدامات مخرب نیازمند تایید هستند، سقف هزینهها اعمال میشود و تمامی فعالیتها در همان لاگ ممیزی فعالیتهای انسانی ثبت میگردند.
امنیت در سطح سطر در پوستگرس (Postgres)، پرسوجوها را در خود پایگاه داده به زیردرخت سازمان فراخواننده محدود میکند، در حالی که فیلتر در سطح برنامه به عنوان دفاع در عمق عمل میکند نه به عنوان تنها خط دفاعی. درخواستهای مربوط به رکوردهای خارج از محدوده به جای خطای دسترسی، پاسخ یافتنشده برمیگردانند، بنابراین هیچ اطلاعاتی درباره وجود داشتن آنها فاش نمیشود. در سمت سرور، ایزولهسازی هر سایت از طریق CageFS، پوسته و فایلهای هر مشتری را در محدوده سایت خودش نگه میدارد.
بله. دوره آزمایشی ۱۴ روزه بدون نیاز به کارت است - بدون جزئیات پرداخت، بدون تعهد - و هاستینگ Footprint-Free را با حداکثر پنج سایت پوشش میدهد. این زمان برای دعوت از یک همکار، تعیین یک نقش، و تأیید عملکرد محدودهها مطابق با نیاز شما پیش از تعهد کافی است.
آزمایش ۱۴ روزه بدون نیاز به کارت بانکی را شروع کنید، شخصی را دعوت کنید و ببینید مدل دسترسی چگونه کار میکند — نقشهایی که میتوانید نامگذاری کنید، دسترسیهایی که میتوانید لغو کنید، و سیاهه رخدادی که دقیقاً میگوید چه کسی چه کاری انجام داده است.
شروع رایگان