امنیت حساب کاربری
امنیت سرور از وبسایتها محافظت میکند. امنیت حساب کاربری از کلیدهای دسترسی به آنها محافظت میکند. هر ورود به Zinn Digital® بر روی یک سیستم هویت مبتنی بر استاندارد اجرا میشود — کلیدهای عبور و WebAuthn، احراز هویت دو مرحلهای TOTP، ورود با لینک جادویی، SAML SSO برای تیمهای سازمانی و آژانس — همراه با نقشهای دقیق، کلیدهای API به تفکیک سازمان و یک گزارش حسابرسی ثبتسیاهه غیرقابلویرایش در پشت آن.
بیشتر حسابهای میزبانی وب یک رمز عبور در یک پایگاه داده هستند که به یک کنترل پنل متصل شدهاند. حساب ما یک سیستم هویت اختصاصی است — Keycloak، که با OIDC و SAML کار میکند — و در جلوی همه چیز قرار دارد: داشبورد مشتری، کنسول مدیریت کارکنان، این سایت عمومی و پایگاه دانش، و تیکتهای پشتیبانی شما. یک بار وارد شوید و در همه آنها وارد شدهاید.
از آنجا که این لایه شناسایی بر پایه استانداردهای باز و نه یک ورود به سیستم انحصاری ساخته شده است، درست مانند سایر اجزای پلتفرم قابل جایگزین است. هیچ بخشی از مدل دسترسی شما در محصول یک فروشنده محبوس نیست و احراز هویت تیم شما به حفظ یک تأمینکننده خاص توسط ما وابسته نیست. این همان اصل عدم قفلشدگی است که ما در مورد حسابهای CDN، DNS و ارائهدهندگان پرداخت نیز اعمال میکنیم.
ورود به سیستم محلیسازی شده است و انتقال از وبسایت به صفحه ورود، زبان شما را به همراه دارد — بنابراین تیمی که در کشورهای مختلف پراکنده است، مجبور نیست از طریق یک صفحه ورود صرفاً انگلیسی وارد شود.
چهار روش، همگی درجه یک، و هر کدام برای هر شخص قابل تنظیم است. هیچکس مجبور نیست به ضعیفترین گزینهای که به ناچار ارائه شده است، تن بدهد.
ایمیل خود را وارد کنید، روی لینک کلیک کنید، وارد شدهاید. نه رمز عبوری برای فیشینگ، استفاده مجدد یا لو رفتن در نشت اطلاعات. این مسیر پیشفرض برای حسابهای کاربری جدید است و برای بیشتر افراد، این تنها مسیری است که تاکنون به آن نیاز خواهند داشت.
یک کلید عبور ثبت کنید — تاچ آیدی، فیس آیدی، ویندوز هلو، یا یک کلید سختافزاری مانند یوبیکی — و بدون نیاز به هیچ رمز عبوری وارد شوید. کلیدهای عبور به مبدأ متصل هستند، بنابراین یک صفحه ورود جعلی نمیتواند آنها را سرقت کند. این پلتفرم از احراز هویتکنندههای ES256 و RS256 پشتیبانی میکند و تأیید کاربر را در اولویت قرار میدهد.
با استفاده از Google از طریق یک اتصال استاندارد ارائهدهنده هویت وارد شوید، به طوری که حساب کاربری هرگونه کنترلی را که Google Workspace شما از قبل اعمال میکند، به ارث میبرد. ارائهدهندگان دیگر به همین صورت متصل میشوند — هیچچیز در آن یکپارچهسازی سفارشی نیست.
حفظشده برای افراد و اسکریپتهایی که به آن نیاز دارند، و منطبق بر یک خطمشی واقعی: حداقل دوازده کاراکتر، هرگز نام کاربری یا آدرس ایمیل شما نباشد، عدم استفاده مجدد از سه رمز عبور قبلی، و هششده با Argon2. آدرسهای ایمیل قبل از فعالسازی حساب کاربری تأیید میشوند.
عوامل دوم بخشی از سیستم هویت هستند، نه یک افزونهای که میخرید یا روی سایت خود نصب میکنید.
اگر سازمان شما در حال حاضر از یک ارائهدهنده هویت — مانند Okta، Entra ID، Google Workspace، یا هر سیستم دیگری که از SAML پشتیبانی میکند — استفاده میکند، میتوانید آن را متصل کنید تا افراد شما با اعتبارنامههای شرکتی موجود خود به Zinn Digital® وارد شوند. هیچ رمز عبور دومی برای مدیریت توسط تیم شما وجود ندارد و هیچ فهرست بررسی تسویه حساب دومی هم برای فراموش شدن باقی نمیماند.
این موضوع در مقیاس آژانسها و ریسلرها که جابجایی کارکنان یک رویداد امنیتی واقعی است، اهمیت بیشتری پیدا میکند. وقتی فردی خارج میشود و شما دسترسی او را در دایرکتوری خود غیرفعال میکنید، مسیر دسترسی او به هاستینگتان نیز قطع شده است. به جای اینکه دسترسیها در دوجین ابزار SaaS به طور دستی دنبال شوند، دسترسیها به صورت متمرکز از وضعیت اشتغال پیروی میکنند.
SAML به جای جایگزینی سیستمهای دیگر، در کنار آنها قرار میگیرد: همچنان میتوان به پیمانکاران یک حساب کاربری با لینک جادویی در یک نقش محدود اختصاص داد، در حالی که کارکنان رسمی از طریق SSO وارد میشوند. یک سازمان، یک مدل دسترسی، دو در ورودی.
دسترسی به ساختار درختی سازمان محدود است — از نماینده فروش گرفته تا مشتری و سایت — و به جای سطح اپلیکیشن، در سطح پایگاه داده و از طریق امنیت در سطح سطر اعمال میشود. دسترسی بینمشتری سیاستی نیست که از افراد بخواهیم به آن احترام بگذارند؛ کوئریای است که نمیتواند هیچ سطری را برگرداند. چهار نقش مشتری، تقسیم وظایف واقعبینانه را پوشش میدهند.
کنترل کامل بر سازمان و زیرحسابهای آن: ایجاد سازمانهای فرزند، دعوت و حذف اعضا، تخصیص نقشها، مدیریت هر سایت، انجام امور صورتحساب و صدور فاکتور، مدیریت کلیدهای API و خواندن گزارش حسابرسی.
صورتحسابها، اشتراکها، روشهای پرداخت و کاتالوگ پلنها — و هیچ چیز دیگر. مسئول مالی یا حسابدار شما میتواند بدون داشتن کوچکترین دسترسی برای لمس، تعلیق یا حذف یک سایت زنده، صورتحساب را تسویه کند.
سایتها و دسترسی به API بدون کنترل صورتحساب: مشاهده و راهاندازی سایتها، راهاندازی مجدد سرویسها، پاکسازی کشها، مدیریت کلیدهای API و کار با تیکتها. بهطور عمدی بدون دسترسی به روشهای پرداخت، صدور فاکتور یا تغییر طرح.
فقطخواندنی در کل سازمان — سایتها، صورتحساب، پلنها، تیکتها، وضعیت ترجمه و لاگ حسابرسی. نقش مناسب برای یک حسابرس، مشتریای که خواستار شفافیت است، یا کارمند تازهکاری که در هفته اول خود است.
داشبورد تنها یکی از راههای ورود است. API، ابزار خط فرمان (CLI)، ارائهدهنده Terraform و سرور MCP راههای دیگر هستند — و همه آنها از مدل دسترسی مشابهی پیروی میکنند، زیرا یک کلید بدون دامنه، دور زدن تمام نقشهایی است که همین الآن پیکربندی کردهاید.
یک کلید API به یک سازمان صادر میشود، نه به یک شخص حقیقی، و دارای حدود دسترسی (اسکوپ) خاص خود است. آن را مانند اطلاعات اعتبارنامهای مشترک در نظر بگیرید: آن را بر اساس کاربردش نامگذاری کنید، محدودترین دسترسیهای ممکن را به آن بدهید و زمانی که فرد ایجادکننده آن تغییر میکند، آن را چرخش (تغییر) دهید.
کلید خام فقط یکبار، در هنگام ایجاد به شما نشان داده میشود. آنچه ما نگهداری میکنیم یک هش SHA-256 و یک پیشوند کوتاه برای جستجو است. ما نمیتوانیم دوباره کلید را به شما نشان دهیم، و نفوذ به پایگاه داده، اعتبارنامههای کاری را در اختیار مهاجم قرار نمیدهد.
هر کلید دارای دامنههای دقیق متصل به همان کاتالوگ مجوزی است که نقشها استفاده میکنند، زمان آخرین استفاده را ثبت میکند و به محض مشکوک به نظر رسیدن میتواند فوراً لغو شود. کلیدهای سندباکس جداگانه، API را بدون هیچگونه صورتحساب یا پروویژنینگ واقعی آزمایش میکنند.
سرور MCP به هر عامل پشتیبان MCP اجازه میدهد هاستینگ شما را مدیریت کند — و این کار را از طریق OAuth 2.1، با دسترسی محدود به سازمان شما و مجوزهای RBAC آن، به همراه توکنهای قابل لغو برای هر ابزار، تأییدیه برای اقدامات مخرب، سقف هزینهها و ثبت کامل ممیزی انجام میدهد. اتصال یک دستیار هوش مصنوعی به معنای سپردن کلید همeth چیز به آن نیست.
هر عملیات سطح دسترسییافته، یک رکورد الحاقمحور مینویسد — اینکه چه کسی آن را انجام داده، چه کاری انجام داده است، آن را روی چه چیزی اعمال کرده، مستندات پشتیبان و آدرس IP منبع، بههمراه یک برچسب زمانی. این یک ابزار سادهسازی عیبیابی نیست؛ بلکه ردپای مدرک است.
نه — و ترجیح میدهیم این کار را نکنید. ورود به سیستم با ایمیل جادویی (Magic-link) پیشفرض است و میتوانید کلید عبور ثبت کنید (Touch ID، Face ID، Windows Hello یا یک کلید سختافزاری) و بدون اینکه هرگز رمز عبوری تنظیم کنید، وارد شوید. ایمیل و رمز عبور به عنوان روش پشتیبان همچنان در دسترس است، که حداقل به دوازده کاراکتر نیاز دارد، استفاده مجدد از سه رمز عبور آخر مجاز نیست و از هش کردن Argon2 استفاده میکند.
احراز هویت دومرحلهای TOTP در لایه شناسایی تعبیه شده است و میتوان آن را از طریق خطمشی در سطح یک سازمان الزامی کرد، بهطوری که نیازی به انتخاب شخصی توسط هر عضو نباشد. کلیدهای عبور (Passkeys) گزینه قویتری هستند که در صورت پشتیبانی دستگاههای تیم شما توصیه میشوند، زیرا رمز عبوری را که مهاجم ممکن است هدف فیشینگ قرار دهد، حذف میکنند.
بله. نقش مدیر صورتحساب (Billing Manager) دسترسی به فاکتورها، اشتراکها، روشهای پرداخت و کاتالوگ طرحها را اعطا میکند و هیچ چیز دیگری ندارد — یعنی هیچ قابلیتی برای مشاهده، راهاندازی، راهاندازی مجدد، تعلیق یا حذف یک سایت وجود ندارد. عکس این موضوع نیز صادق است: نقش توسعهدهنده (Developer) سایتها و دسترسی به API را بدون هیچگونه کنترل صورتحساب مدیریت میکند. نقشها به ازای هر سازمان تخصیص داده میشوند، بنابراین یک نقش در یک سازمان هیچ دسترسیای در یک سازمان جداگانه و بیربط اعطا نمیکند — با این حال، نقشی که در یک سازمان والد وجود دارد، برای سازمانهای زیرمجموعه آن نیز اعمال میشود.
آن را از داشبورد لغو دسترسی کنید تا بلافاصله از کار بیفتد. بازه خسارت به کارهایی محدود میشود که آن کلید در وهله اول قادر به انجامش بوده است؛ به همین دلیل است که کلیدها دارای محدودههای دسترسی تفکیکشده هستند و زمان آخرین استفاده را ثبت میکنند؛ محدودههای دسترسی محدود و ردپای قابلمشاهده از استفاده، مواردی هستند که یک نشت اطلاعات را به جای سازشی کامل در حساب کاربری، به یک حادثه مهارشده تبدیل میکنند. توجه داشته باشید که کلیدها به جای افراد، برای سازمان صادر میشوند؛ بنابراین با آنها مانند اعتبارنامههای اشتراکی رفتار کنید و هنگام جابجایی افراد، آنها را چرخش دهید. از طرف ما تنها هش کلید ذخیره میشود، بنابراین نشت اطلاعات از پایگاه داده ما منجر به ایجاد یک اعتبارنامه قابل استفاده نخواهد شد.
بله. هر اقدام دسترسیدار در یک سیاهه حسابرسی الحاقفقط (append-only) به همراه عامل، اقدام، هدف، مستندات پشتیبان، IP مبدأ و برچسب زمانی ثبت میشود. نقشهای مالک و فقطخواندنی میتوانند مستقیماً آن را بخوانند. اقدامات کارکنان روی حساب شما در همین مسیر ثبت میشود و اقدامات حساس یا تخریبی کارکنان ممکن است ابتدا نیازمند احراز هویت مرحلهای یا تأیید دو نفره باشد.
بله — ورود تکبار (SAML SSO) برای حسابهای سازمانی و آژانسها پشتیبانی میشود، بنابراین کاربران شما با همان اعتبارنامههای سازمانی موجود خود احراز هویت میکنند و خروج آنها از دایرکتوری شما، دسترسیشان را در اینجا نیز قطع میکند. شما میتوانید روشها را با هم ترکیب کنید: SSO برای کارمندان دائمی، و حسابهای دارای لینک جادویی محدود برای پيمانکاران، که همگی در قالب یک مدل دسترسی یکسان قرار دارند.
خیر — گذرواژهها به عمد منتقل نمیشوند. حساب کاربری شما بدون گذرواژه وارد میشود و در اولین ورود، یا از لینک جادویی استفاده میکنید یا تحت سیاست فعلی یک گذرواژه جدید تنظیم میکنید. انتقال هشهای گذرواژه قدیمی، ضعفهای گذشته را به یک سیستم جدید منتقل میکند، بنابراین این کار را انجام نمیدهیم.
آزمایش Footprint-Free چهارده روزه، بدون نیاز به کارت بانکی است و تا پنج سایت را پوشش میدهد. شما در طول دوره آزمایشی به لایه هویت کامل دسترسی دارید — کلیدهای عبور، احراز هویت دو مرحلهای، نقشها، کلیدهای API و گزارش حسابرسی در پشت طرح پولی قفل نشدهاند.
یک کلید عبور ثبت کنید، تیم خود را با نقشهای مناسب دعوت کنید، و یک کلید API محدود صادر کنید — همگی در یک دوره آزمایشی ۱۴ روزه بدون نیاز به کارت و بدون نیاز به وارد کردن اطلاعات کارت.
شروع رایگان