پرش به محتوا
موتور تصمیمگزارش و آنالیتیکسحاکمیت دادهمهاجرت و قیمتبوم سناریومستندات
EN
وروددرخواست دمو
موتور تصمیمگزارش و آنالیتیکسحاکمیت دادهمهاجرت و قیمتبوم سناریومستنداتورود
EN
درخواست دمو

سند امنیت

نسخه 1.0 · منتشرشده در ۲۲ مرداد ۱۴۰۵

این سند درباره چیست

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

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

این سند گواهینامه نیست و جای ممیزی مستقل را نمی‌گیرد.

ماده ۱محل نگهداری داده

همه داده روی زیرساخت داخل ایران نگهداری و پردازش می‌شود و نسخه‌های پشتیبان هم از کشور بیرون نمی‌روند.

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

ماده ۲رمزنگاری

**در انتقال.** همه نقطه‌های عمومی، یعنی دریافت رویداد، رابط برنامه‌نویسی و داشبورد، فقط روی TLS جواب می‌دهند و درخواست بدون رمزنگاری به نسخه امن هدایت می‌شود. گواهی‌ها خودکار صادر و تمدید می‌شوند.

**در حالت سکون.** رازهایی که خواندنشان از دیتابیس به‌تنهایی خطرناک است، پیش از نوشته شدن با AES-GCM رمز می‌شوند و کلید در محیط فرایند است نه در دیتابیس. یعنی یک نسخه دامپ یا یک تزریق SQL در آینده، به‌تنهایی کافی نیست. امروز این اقلام رمز شده‌اند: کلید خصوصی DKIM دامنه ارسال مشتری، اعتبارنامه درگاه‌های ارسال، راز اتصال‌های شخص ثالث، راز سرویس‌دهنده ورود یکپارچه، و راز عامل دوم احراز هویت هم برای کاربران مشتری و هم برای کارکنان ما.

بند ۱ـ۴ دستورالعمل اجرایی بهبود حفاظت از حریم خصوصی کاربران، مصوب ۱۴۰۲، می‌گوید داده شخصی مربوط به هویت «صرفاً باید به صورت رمزنگاری شده ذخیره شود». این بهترین شیوه نیست، الزام است، و ما آن را به‌عنوان تعهد می‌پذیریم.

تبصره ۱: امروز رمزنگاری فیلد به فیلد روی اقلام هویتی پروفایل کاربر نهایی، یعنی شماره موبایل و رایانامه، هنوز کامل اجرا نشده است. این کار در دست انجام است و تا تمام نشدنش، همین جمله در این سند می‌ماند.

ماده ۳جداسازی مستأجرها

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

این جداسازی منطقی است نه فیزیکی. استقرار اختصاصی ممکن است ولی پیش‌فرض نیست و در قرارداد جدا توافق می‌شود.

ماده ۴نقش‌ها و کنترل دسترسی مشتری

ثبت‌نام خودسرویس وجود ندارد. هر حساب فقط با دعوت ساخته می‌شود، پس هیچ مسیری برای ساختن حساب بدون دخالت ما نیست.

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

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

ماده ۵دسترسی کارکنان ما به داده مشتری

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

  • **عامل دوم اجباری است** و خود ساختار دیتابیس اجرایش می‌کند، نه یک تنظیم قابل

خاموش کردن. رکورد یک کارمند فعال که عامل دوم تأییدشده ندارد اصلاً معتبر نیست، پس حسابی که ثبت‌نام عامل دوم را رد کرده باشد نمی‌تواند وارد شود.

  • **خواندن هم لاگ می‌شود، نه فقط نوشتن.** سؤالی که این لاگ باید جواب بدهد

«کدام کارمند پرونده این شخص را باز کرد» است و لاگ نوشتن‌ها به آن جواب نمی‌دهد.

  • **هر تغییر دلیل نوشتاری می‌خواهد**، دست کم ده نویسه. این کف جلوی دلیل

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

  • **کار پرخطر تأیید دوباره عامل دوم می‌خواهد**، در ده دقیقه اخیر: ورود به حساب

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

  • **ورود به حساب مشتری پیش‌فرضش فقط خواندن است.** هر تغییری در حالت نوشتن، در

لاگ ممیزی خود مشتری با برچسب جدا ثبت می‌شود تا تغییری که مشتری نداده از تغییری که داده قابل تشخیص باشد.

تبصره ۲: کار پرخطر تأیید یک نفر دوم هم می‌خواهد، ولی تا وقتی فقط یک کارمند فعال هست این قفلی است که کلیدش داخل خودش است. در آن حالت سامانه خودتأییدی را می‌پذیرد و با برچسب جدا ثبتش می‌کند، تا دوره‌ای که شرکت با یک جفت چشم اداره می‌شده بعداً قابل تشخیص باشد. با فعال شدن حساب دوم، قاعده خودش سخت می‌شود.

ماده ۶لاگ ممیزی

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

لاگ و داده ترافیک دست کم ۱۸۰ روز نگه داشته می‌شود. اینکه تکلیف قانونی نگهداری داده ترافیک دقیقاً به ما بخورد روشن نیست و آن را تکلیف قطعی خودمان اعلام نمی‌کنیم؛ این عدد محافظه‌کارانه‌ترین خوانش است. درخواست حذف مشتری هم این لاگ‌ها را برنمی‌دارد، و تفصیلش در سیاست نگهداری و حذف داده آمده که همان سند ملاک است.

ماده ۷پشتیبان‌گیری و بازیابی

پشتیبان‌گیری خودکار هر شب ساعت ۰۳:۲۰ به وقت تهران اجرا می‌شود.

چه چیزیهر چند وقتنگهداری
پایگاه داده اصلی، همراه نقش‌های دسترسیروزانه۱۴ روز
انبار رویداد، با دستور پشتیبان‌گیری خود سرورروزانه۱۴ روز
فایل‌های بارگذاری‌شدهروزانه۱۴ روز
کلیدهای رمزنگاری، جدا از بقیهروزانه۳۰ نسخه

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

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

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

ماده ۸راز و کلید

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

ماده ۹گزارش آسیب‌پذیری

اگر آسیب‌پذیری‌ای پیدا کردید، به support@segmentic.net با کلمه «امنیت» در موضوع بفرستید. دریافت را حداکثر تا دو روز کاری تأیید می‌کنیم و تا رفع، وضعیت را دوره‌ای می‌گوییم.

اگر گزارش‌دهنده از حد لازم برای اثبات یافته فراتر نرود، داده‌ای برندارد، سرویس را مختل نکند و پیش از رفع افشا نکند، پیگرد قانونی نمی‌کنیم و همین را کتباً تأیید می‌کنیم.

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

ماده ۱۰آنچه نداریم

کوتاه‌تر شدن این ماده خبر خوبی است و هر بار که کوتاه شود، همین‌جا عوض می‌شود. امروز:

  • گواهینامه ISO ۲۷۰۰۱ یا SOC ۲ نداریم.
  • گزارش تست نفوذ شخص ثالث نداریم.
  • گواهی افتا نداریم. آن گواهی برای ارائه‌دهندگان خدمات امنیت سایبری و

پیمانکاری پروژه‌های دولتی است نه برای یک سکوی بازاریابی، ولی مشتری بانکی یا دولتی ممکن است خودش آن را بخواهد و ما امروز نداریم.

  • رمزنگاری فیلد به فیلد اقلام هویتی کاربر نهایی هنوز کامل نیست.
  • جداسازی فیزیکی مستأجرها پیش‌فرض نیست.

ماده ۱۱دسترسی به داده مستأجر دیگر، جرم است

ماده ۱ قانون جرایم رایانه‌ای مصوب ۱۳۸۸، که در تنقیح به ماده ۷۲۹ قانون مجازات اسلامی رفته است، دسترسی غیرمجاز به داده‌ها یا سامانه‌های رایانه‌ای «که به وسیله تدابیر امنیتی حفاظت شده است» را جرم می‌داند، با نود و یک روز تا یک سال حبس یا جزای نقدی یا هر دو. جرم مطلق است، یعنی صرف دسترسی کافی است و لازم نیست ضرری وارد شده یا سودی برده شده باشد.

قید «حفاظت شده به وسیله تدابیر امنیتی» را باید دقیق خواند، چون همه این سند به آن وصل است. اگر ما واقعاً کنترل امنیتی نداشته باشیم، این حمایت کیفری اصلاً فعال نمی‌شود. یعنی احراز هویت، رمزنگاری، جداسازی مستأجر و کنترل دسترسی که در ماده‌های بالا آمد فقط تعهد ما به مشتری نیستند؛ همان چیزی‌اند که استفاده از این ماده را برای هر دوی ما ممکن می‌کنند. به همین دلیل مستند نگه داشتن این سند خودش بخشی از کنترل است.

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

تبصره ۴: ماده ۲ همان قانون، که به ماده ۷۳۰ قانون مجازات اسلامی رفته، شنود غیرمجاز داده در حال انتقال را با شش ماه تا دو سال حبس جرم می‌داند. متقابلاً ما هم محتوای داده مشتری را فراتر از آنچه برای ارائه خدمت لازم است بازرسی نمی‌کنیم.

ماده ۱۲اعلام نقض امنیتی

اگر نقض امنیتی مؤثر بر داده مشتری احراز شود، ظرف ۷۲ ساعت به شخص رابط نام‌برده در قرارداد اعلام می‌کنیم. مبدأ مهلت لحظه احراز است نه لحظه وقوع، و این تفاوت عمدی است: پیش از فهمیدن، هیچ مهلتی معنا ندارد.

اعلام دست کم می‌گوید چه اتفاقی افتاد، چه زمانی، کدام دسته‌های داده درگیر بودند، اگر معلوم است چند رکورد، ما چه کردیم و مشتری چه باید بکند. اگر تصویر هنوز کامل نباشد اعلام موقت می‌دهیم و بعد تکمیلش می‌کنیم، چون سکوت تا روشن شدن همه‌چیز بدترین گزینه است.

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

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

ماده ۱۳تغییر این سند

تغییر این سند دست کم ۶۰ روز پیش از اجرایی شدن اعلام می‌شود. تغییری که یک کنترل را ضعیف‌تر کند، ویرایش بی‌صدا نمی‌شود و نسخه پیشین در دسترس می‌ماند تا مشتری بتواند دو نسخه را کنار هم بگذارد.

تماس

پرسش امنیتی و گزارش آسیب‌پذیری: support@segmentic.net

درخواست‌های مربوط به داده شخصی: privacy@segmentic.net

کارگستران نسل جوان باختر https://segmentic.net

سگمنتیک

سگمنتی به اندازهٔ یک نفر

محصول

  • موتور تصمیم
  • تحلیل اثر
  • گزارش و آنالیتیکس
  • هستهٔ پلتفرم
  • حاکمیت داده
  • بوم سناریو
  • سؤال‌های پرتکرار

شرکت

  • مهاجرت و قیمت
  • درخواست دمو
  • ورود به پنل
  • وضعیت سرویس

قانونی

  • شرایط استفاده
  • حریم خصوصی
  • سیاست ارسال پیام
  • امنیت
  • کوکی
  • سطح خدمات
  • شرایط دورهٔ ارزیابی
  • لغو و بازگشت وجه
  • نسخه‌بندی API

راهنماها

  • اتوماسیون بازاریابی چیست
  • ریتنشن مارکتینگ
  • نرخ حفظ مشتری
  • ارزش طول عمر مشتری
  • سبد خرید رها شده
  • ارسال خودکار پیام
  • دسته‌بندی مشتریان
  • بازگشت مشتری
  • تحلیل کوهورت
  • راهنماها
  • نرخ ریزش مشتری

مقایسه پلتفرم‌ها

  • همه مقایسه‌ها
  • سگمنتیک و ادتریس
  • سگمنتیک و زبلاین
  • سگمنتیک و متریکس
  • سگمنتیک و Braze
  • سگمنتیک و CleverTap
  • سگمنتیک و MoEngage
  • سگمنتیک و سامانه پیامکی
  • سگمنتیک و باشگاه مشتریان
  • سگمنتیک و سی‌آرام
  • سگمنتیک و WebEngage
تلفن
02182803208
نشانی
قم، پردیسان، پارک علم و فناوری قم، شرکت سگمنتیک
ایمیل
sales@segmentic.net
شمارهٔ ثبت
21522
نماد اعتماد الکترونیکی
© ۱۴۰۵ سگمنتیکEnglish