تیم‌ها و دسترسی

به هر یک از اعضای تیم خود دقیقاً همان دسترسی مورد نیازش را بدهید

چهار نقش مشتری، حساب‌های فرعی متناسب با ساختار واقعی کسب‌وکار شما، کلیدهای API برای هر سازمان، ورود یکپارچه و گزارش بازرسی برای هر اقدام دارای مجوز. همین مدل دسترسی در داشبورد، API، CLI، Terraform و سرور MCP ما اجرا می‌شود. در دسترس بودن: ارائه‌دهنده Terraform در حال توسعه فعال است و هنوز در دسترس نیست. تمام موارد دیگری که در اینجا شرح داده شده‌اند هم‌اکنون فعال هستند.

چندین نفر متصل به یک حساب، هر یک با مجوزهای محدود و مختص به خود.
  • +۷۰۰٬۰۰۰سایت‌های میزبانی‌شده در سراسر جهان
  • 4نقش‌های مشتری، ایجاد اولیه شده و آماده است
  • 35کلیدهای دسترسی دقیق
  • ۱۴ روزآزمایشی بدون کارت

چهار نقش، مشخص‌شده در جایی که کار واقعاً تقسیم می‌شود

دسترسی صرفاً یک کلید روشن/خاموش نیست. هر سازمان مشتری با چهار نقش ارائه می‌شود که هر کدام بسته‌ای ثابت از مجوزهای دقیق module.action هستند — بنابراین رابط مالی هرگز به سرور دسترسی ندارد و توسعه‌دهنده نیز هرگز فاکتوری را مشاهده نمی‌کند.

مالک

کنترل کامل سازمان و حساب‌های فرعی آن: ایجاد سازمان‌های فرعی، دعوت و حذف اعضا، تغییر نقش‌ها، مدیریت کلیدهای API، راه‌اندازی، راه‌اندازی مجدد، تعلیق و حذف سایت‌ها، مدیریت صورت‌حساب‌ها و روش‌های پرداخت، و خواندن گزارش بازرسی. دو مورد عمداً خارج از این حیطه قرار دارند — بستن یک سازمان و صدور بازپرداخت‌ها از اقدامات کارکنان است، نه نقش مشتری.

مدیر صورت‌حساب

همه موارد مالی و نه هیچ چیز دیگر: صورت‌حساب‌ها، اشتراک‌ها، روش‌های پرداخت و کاتالوگ پلن‌ها، به همراه مشاهده سازمان و فهرست اعضای آن. بدون هیچ‌گونه دسترسی به سایت — یک رابط مالی یا حسابدار خارجی نمی‌تواند هیچ چیزی را راه‌اندازی مجدد، تعلیق یا حذف کند.

توسعه‌دهنده

بدون دسترسی به امور مالی روی سایت‌ها کار کنید: مشاهده و راه‌اندازی سایت‌ها، راه‌اندازی مجدد سرویس‌ها، پاکسازی حافظه موقت (کش)، مدیریت کلیدهای API، و ایجاد یا پاسخ به تیکت‌های پشتیبانی. بدون مشاهده صورت‌حساب، بدون مدیریت اعضا، بدون تعلیق و بدون حذف — اقدامات مخرب و تجاری در اختیار مالک باقی می‌ماند.

فقط‌خواندنی

یک نمای کامل بدون امکان ایجاد هرگونه تغییر — اعضا، سایت‌ها، صورت‌حساب، طرح‌ها، تیکت‌ها، وضعیت ترجمه و گزارش بازرسی. نقشی مناسب برای ذی‌نفعان مشتری، یک حسابرس داخلی یا کارمند جدیدی که هنوز در حال آشنایی با کار است.

حساب‌های فرعی متناسب با ساختار واقعی شما

چندمستأجری یک ساختار درختی است، نه یک فهرست مسطح. سازمان نمایندگی فروش در سطحی بالاتر از سازمان‌های مشتریان خود قرار دارد و وب‌سایت‌ها زیرمجموعه آن‌ها قرار می‌گیرند. یک عضو تیم نشان‌دهنده یک عضویت است — یک کاربر، یک سازمان، یک نقش — بنابراین همین عنصر بنیادین، قدرت‌بخش یک تیم دو نفره، یک آژانس با مدیریت صد حساب مشتری و یک نمایندگی فروش با مدیریت حساب‌های فرعی تحت برند خود خواهد بود.

نقش‌ها به ازای هر سازمان اعطا می‌شوند و اعمال آن‌ها نیز به ازای هر سازمان صورت می‌گیرد. نقشی در یک سازمان، هیچ‌گونه دسترسی در سازمانی مجزا و نامرتبط ایجاد نمی‌کند — یک پیمانکار می‌تواند با همان ورود، در حساب کاربری یک مشتری Developer و در دومی فقط‌خواندنی باشد. با این حال، دسترسی در سلسله‌مراتب خودتان به سمت پایین جریان دارد: نقشی در سازمان اصلی، برای سازمان‌های زیرمجموعه آن نیز اعمال می‌شود؛ روشی که ارائه‌دهندگان خدمات و آژانس‌ها از طریق آن مشتریان خود را مدیریت می‌کنند.

جداسازی نه فقط در کد برنامه، بلکه در پایگاه داده اعمال می‌شود. امنیت در سطح سطر در Postgres دامنه هر پرس‌وجوی مستأجر را به زیردرخت فراخواننده محدود می‌کند، و هر چیزی خارج از آن زیردرخت به جای خطای مجوز، وضعیت «یافت نشد» را بازمی‌گرداند — بنابراین این پلتفرم حتی وجود سازمان یا سایت مستأجر دیگری را نیز تأیید نمی‌کند.

مجوزهای یکسان در تمام سطوح

نقش‌ها صرفاً قابلیتی برای راحتی در داشبورد نیستند. هر راه ورودی به پلتفرم به همان کلیدهای مجوز منتهی می‌شود، بنابراین هیچ در پشتی‌ای وجود ندارد که قوانین دسترسی شما را دور بزند.

داشبورد

وب‌سایت‌ها، صورت‌حساب، تیکت‌ها، اطلاعیه‌ها، اعلان‌ها، کلیدهای API و مدیریت تیم در یک محیط واحد. رابط کاربری بر اساس دسترسی‌های نقش کاربری که وارد شده است موارد را نمایش می‌دهد، بنابراین کنترل‌هایی که قابل استفاده نیستند به افراد نشان داده نمی‌شوند.

API و CLI عمومی

ای‌پی‌آی (API) منتشرشده، همان API موتوری است که داشبورد استفاده می‌کند. کلیدهای API برای هر سازمان با دامنه‌های دقیق مرتبط با مجوزهای RBAC صادر می‌شوند و حالت‌های مجزای سندباکس و زنده بدین معناست که می‌توانید یکپارچه‌سازی‌ها را بدون دست‌زدن به صورت‌حساب یا تدارکات واقعی آزمایش کنید.

ارائه‌دهنده Terraform

سایت‌ها، دامنه‌ها، DNS، صندوق‌های پستی و پلن‌ها را به صورت زیرساخت به عنوان کد مدیریت کنید و terraform apply را برای راه‌اندازی میزبانی اجرا نمایید — تحت نظارت همان محدوده‌هایی که بر سایر موارد حاکم است.

سرور MCP

Claude Code، Cursor، ChatGPT، Claude Desktop یا هر ابزار دارای قابلیت MCP را متصل کنید. توکن‌ها به یک سازمان و مجوزهای RBAC آن محدود می‌شوند، برای هر ابزار قابل لغو هستند و همراه با تأیید برای اقدامات مخرب، سقف هزینه و گزارش کامل حسابرسی ارائه می‌شوند.

مدیریت کلیدها

تنها یک هش از هر کلید API ذخیره می‌شود — هرگز خود کلید خام ذخیره نمی‌شود. کلیدها دارای یک نام و یک پیشوند قابل مشاهده هستند تا بتوانید آن‌ها را از یکدیگر تشخیص دهید، زمان آخرین استفاده از آن‌ها ثبت می‌شود و بدون ایجاد اختلال در سایر کلیدها، به‌صورت جداگانه قابل ابطال هستند.

یک بار ورود، مبتنی بر استانداردها، در همه جا

مدیریت هویت بر پایه Keycloak اجرا می‌شود، بنابراین احراز هویت به جای یک فرم ورود سفارشی که به یک کنترل‌پنل میزبانی متصل شده باشد، مبتنی بر OIDC و SAML استاندارد است.

  • ورود از طریق ایمیل با پیوند جادویی به‌صورت پیش‌فرض، همراه با ایمیل و گذرواژه به‌عنوان روش جایگزین برای افرادی که آن را ترجیح می‌دهند.
  • کلیدهای عبور و WebAuthn برای ورود مقاوم در برابر فیشینگ، به‌علاوه احراز هویت دو مرحله‌ای TOTP که طبق خط‌مشی برای همه اجباری شده است.
  • ورود از طریق شبکه‌های اجتماعی با Google، Microsoft، GitHub و سایر ارائه‌دهندگان هویت.
  • ورود یکپارچه SAML برای مشتریان سازمانی و آژانس‌ها، تا دسترسی تیم از فهرست راهنمای موجود شما پیروی کند.
  • یک نشست در داشبورد، کنسول مدیریت، وب‌سایت عمومی و پایگاه دانش، و تیکت‌های پشتیبانی — یک بار وارد شوید، نه پنج بار.
  • هر ایمیل ثبت‌نام قبل از ایجاد حساب تأیید می‌شود، بنابراین آدرس‌های نامعتبر و غیرقابل‌تحویل هرگز به تیم شما راه پیدا نمی‌کنند.
  • از آنجا که این سرویس مبتنی بر استانداردها است، خود ارائه‌دهنده هویت بدون نیاز به بازطراحی معماری پیرامون آن قابل تعویض است — همان قاعده عدم وابستگی به ارائه‌دهنده که برای هر فروشنده دیگری نیز اعمال می‌کنیم.

مسئولیت‌پذیری قابل ارائه به یک حسابرس

هر اقدام ممتاز، یک رکورد بازرسی صرفاً الحاقی ثبت می‌کند: چه کسی آن را انجام داده است، چه کاری انجام داده است، بر روی چه چیزی انجام داده است، شواهد پشتیبان و آدرس IP مبدأ. این گزارش صرفاً الحاقی است — رویدادها اضافه می‌شوند، نه اینکه در محل ویرایش شوند — و در محیط عملیاتی بر اساس زمان تقسیم‌بندی شده است تا با رشد آن سریع باقی بماند.

خواندن آن گزارش، خود یک مجوز محسوب می‌شود. مالکان و اعضای فقط-خواندنی دارای این مجوز هستند، بنابراین فرد مسئول حساب و فرد بازرس می‌توانند هر دو بدون نیاز به داشتن دسترسی‌های ارتقایافته، تاریخچه کامل را مشاهده کنند.

در کنار آن، کنترل‌هایی قرار دارند که تیم‌های بزرگ‌تر خواستار آن‌ها هستند: خط‌مشی‌های نشست، فهرست‌های اختیاری مجاز IP به ازای هر سازمان، و احراز هویت تکمیلی در اقدامات حساس تا صرفاً یک نشست فعال برای انجام کارهای مهم کافی نباشد.

چگونه مجوزها با شما رشد می‌کنند

کاتالوگ مجوزها داده است، نه منطق کدگذاری‌شده سخت — به همین دلیل می‌توان آن را بدون بازطراحی ساختار پلتفرم گسترش داد.

  • امروز ۳۵ کلید جزئی module.action، شامل سازمان‌ها، اعضا، کلیدهای API، سایت‌ها، صورت‌حساب، پلن‌ها، ناوگان، تیکت‌ها، مشتریان، سوءاستفاده، کمپین‌ها، ترجمه‌ها و بازرسی.
  • کاتالوگ در هر استقرار به صورت غیرتکراری (idempotent) مقداردهی اولیه می‌شود و اگر نقشی به مجوزی اشاره کند که وجود ندارد، اعتبارسنجی با خطای واضح متوقف می‌شود — یک اشتباه تایپی نمی‌تواند بی‌صدا به اعطای هیچ مجوزی ختم شود.
  • قابلیت‌های جدید محصول، پیش از عرضه نقطه پایانی، کلیدهای مجوز خود را به کاتالوگ اضافه می‌کنند، بنابراین کنترل دسترسی هرگز پس از فعال شدن یک قابلیت، به صورت عطف به ماسبق اعمال نمی‌شود.
  • محدود کردن دامنه یک عضویت به سایت‌های خاص یا یک منطقه مشخص، یک بهبود برنامه‌ریزی‌شده است و قابلیتی نیست که امروز بتوانید آن را فعال کنید. الگوی فعلی این است که آن سایت‌ها را در یک سازمان فرعی قرار دهید و به فرد نقشی در آنجا اختصاص دهید — که همان تفکیک را با استفاده از ساختار درختی مستأجرها برای شما فراهم می‌کند.
  • کلیدهای API در سطح سازمان صادر می‌شوند و نه برای هر فرد، بنابراین آن‌ها را به عنوان اعتبارنامه‌های سرویس برای یکپارچه‌سازی‌ها در نظر بگیرید و برای دسترسی افراد از عضویت‌ها استفاده کنید.

پرسش‌های متداول

هر نقش دقیقاً چه کارهایی می‌تواند انجام دهد؟

مالک کنترل کامل سازمان و حساب‌های فرعی آن، از جمله اعضا، کلیدهای API، سایت‌ها و روش‌های پرداخت را در دست دارد. مدیر صورت‌حساب، فاکتورها، اشتراک‌ها، روش‌های پرداخت و طرح‌ها را بدون دسترسی به سایت‌ها مشاهده می‌کند. توسعه‌دهنده، سایت‌ها و کلیدهای API را مدیریت می‌کند و به تیکت‌ها رسیدگی می‌نماید، بدون اینکه کنترلی بر صورت‌حساب یا اعضا داشته باشد. نقش فقط-خواندنی می‌تواند بدون تغییر هیچ موردی، اعضا، سایت‌ها، صورت‌حساب، طرح‌ها، تیکت‌ها و گزارش حسابرسی را مشاهده کند.

آیا می‌توانم فقط به یک سایت به کسی دسترسی بدهم؟

هنوز به‌عنوان یک تنظیم برای هر سایت در دسترس نیست — محدود کردن یک عضویت واحد به سایت‌های خاص یک بهینه‌سازی برنامه‌ریزی‌شده است. امروز می‌توانید به همین جداسازی با درخت سلسله‌مراتب مشترکین (tenancy tree) دست یابید: آن سایت‌ها را در یک سازمان زیرمجموعه قرار دهید و به فرد در آنجا نقشی اختصاص دهید. از آنجا که نقش‌ها برای هر سازمان اعطا می‌شوند، این دسترسی به هیچ بخش دیگری در حساب شما منتقل نمی‌شود.

آیا کلیدهای API به اعضای جداگانه تیم متصل هستند؟

خیر — کلیدهای API برای هر سازمان صادر می‌شوند، با دامنه‌های دقیق مرتبط با همان مجوزهای RBAC، و حالت‌های آزمایشی (sandbox) و زنده جداگانه. از آن‌ها به‌عنوان اعتبارنامه‌های سرویس برای یکپارچه‌سازی‌ها، CI یا Terraform استفاده کنید، و برای افراد از عضویت‌ها بهره ببرید. فقط هش هر کلید ذخیره می‌شود، هر کلید زمان آخرین استفاده را ثبت می‌کند، و هر کلیدی را می‌توان به‌تنهایی لغو کرد.

آیا یک توسعه‌دهنده می‌تواند تغییرات را به یک سایت زنده ارسال کند؟

نقش توسعه‌دهنده شامل مشاهده و راه‌اندازی سایت‌ها، راه‌اندازی مجدد سرویس‌ها، پاکسازی حافظه‌های پنهان، مدیریت کلیدهای API و رسیدگی به تیکت‌ها می‌شود. این نقش شامل حقوق انتشار بر روی یک سایت فعال نیست، بنابراین اگر می‌خواهید فردی بتواند تغییرات را اعمال کند، این دسترسی باید در اختیار یک مالک باشد. نقش‌ها برای هر سازمان به صورت مجزا تعریف می‌شوند، بنابراین شما می‌توانید در یک حساب دیگر، نقش متفاوتی داشته باشید.

آیا از SSO برای دایرکتوری شرکت ما پشتیبانی می‌کنید؟

بله. سیستم احراز هویت بر روی Keycloak با OIDC و SAML اجرا می‌شود، بنابراین ورود یکپارچه SAML برای مشتریان سازمانی و آژانس‌ها در کنار ورود از طریق پیوند جادویی، ایمیل و گذرواژه، ارائه‌دهندگان ورود از طریق شبکه‌های اجتماعی، کلیدهای عبور (passkeys) و احراز هویت دومرحله‌ای TOTP که توسط خط‌مشی اعمال می‌شود، در دسترس است. یک نشست، داشبورد، وب‌سایت عمومی، پایگاه دانش و تیکت‌های پشتیبانی را پوشش می‌دهد.

چگونه بفهمم چه کسی چیزی را تغییر داده است؟

هر اقدام دارای امتیاز در یک گزارش حسابرسیِ فقط الحاقی ثبت می‌شود که انجام‌دهنده، اقدام، هدف، شواهد پشتیبان و نشانی IP را ضبط می‌کند. خواندن آن به خودی خود یک مجوز است که در اختیار هر دو نقش مالک و فقط‌خواندنی قرار دارد، تا مالک حساب و حسابرس بتوانند سابقه یکسانی را بررسی کنند.

آیا افزودن اعضای تیم، مبلغ پرداختی من را تغییر می‌دهد؟

قیمت‌گذاری پلن‌ها بر اساس ظرفیت میزبانی انجام می‌شود، نه تعداد افراد. برای نمونه، در خط Footprint-Free، هر ۴۲ سطح از مجموعه امتیازات کاملاً یکسانی برخوردارند و تفاوت آن‌ها تنها در تعداد سایت‌های مجاز است. قیمت‌گذاری همواره از کاتالوگ زنده و با واحد پول شما نمایش داده می‌شود، بنابراین مبلغی که در صفحه قیمت‌گذاری مشاهده می‌کنید دقیقاً همان مبلغی است که دریافت می‌شود.

آیا می‌توانم این را قبل از متعهد شدن امتحان کنم؟

بله. دوره آزمایشی Footprint-Free به مدت ۱۴ روز فعال است، به اطلاعات کارت نیازی ندارد و تا ۵ وب‌سایت را پوشش می‌دهد، بنابراین می‌توانید پیش از پرداخت هرگونه هزینه، سازمان خود را راه‌اندازی کنید، تیم خود را دعوت نمایید و نقش‌ها را در کارهای واقعی آزمایش کنید. پلن‌های پولی دارای ۳۰ روز ضمانت بازگشت وجه هستند.

تیم خود را در چند دقیقه راه‌اندازی کنید، نه با تیکت

یک دوره آزمایشی ۱۴ روزه بدون نیاز به کارت را در خط Footprint-Free شروع کنید، تیم خود را دعوت نمایید و قبل از پرداخت هرگونه هزینه، نحوه عملکرد نقش‌ها را در سایت‌های واقعی مشاهده کنید.

رایگان شروع کنید