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