سیاست حریم خصوصی

چرا حریم خصوصی کاربران سایت به فروش شما ربط دارد

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

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

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

کمتر جمع کنید: اولین قانون امنیت اطلاعات سایت

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

چند نمونه‌ی رایج از داده‌ای که بی‌دلیل جمع می‌شود:

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

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

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

ورود امن بدون نگه‌داشتن رمز عبور

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

اگر سایت‌تان رمز عبور دارد، کمترین کار این است که رمز هیچ‌وقت به شکل خام ذخیره نشود. باید «هش» شود. هش یعنی تبدیل یک متن به یک رشته‌ی ثابت با روشی که برگشت ندارد: سایت هنگام ورود، رمزی را که کاربر نوشته دوباره هش می‌کند و با هش ذخیره‌شده مقایسه می‌کند، بدون اینکه رمز اصلی را بداند. برای رمز عبور باید از روش‌های مخصوص و عمدا کند استفاده کرد که حدس زدن را گران می‌کنند؛ راهنمای ذخیره‌ی رمز عبور OWASP این روش‌ها را معرفی کرده است. وردپرس و بیشتر فریم‌ورک‌های امروزی این کار را خودشان انجام می‌دهند؛ کافی است افزونه یا کد سفارشی‌ای آن را دور نزند.

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

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

رمزنگاری اطلاعات: وقتی چیزی را باید نگه دارید

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

رمزنگاری دو جا لازم است:

1. در راه: وقتی داده از مرورگر کاربر به سرور شما می‌رود. این کار HTTPS است، یعنی همان قفل کنار نشانی سایت. بر اساس فصل امنیت Web Almanac 2024، سهم صفحه‌های اصلی که روی موبایل با HTTPS باز می‌شوند به ۹۵٫۶ درصد رسیده است؛ یعنی سایت بدون HTTPS امروز یک استثنای نگران‌کننده است، نه یک حالت عادی. گوگل هم از سال‌ها پیش HTTPS را یکی از نشانه‌های رتبه‌بندی اعلام کرده است. کنار HTTPS، هدر HSTS به مرورگر می‌گوید از این به بعد این سایت را فقط با HTTPS باز کند، حتی اگر کسی نشانی بی‌قفل را بزند.
2. در حال استراحت: وقتی داده در دیتابیس یا روی دیسک نشسته است. HTTPS این‌جا کمکی نمی‌کند. اگر کسی نسخه‌ی پشتیبان دیتابیس شما را پیدا کند، هر چه خام نوشته شده باشد را می‌خواند.

در تیم سفید، برای انجام سفارش گاهی دسترسی هاست، وردپرس یا سرور مشتری را لازم داریم. این اطلاعات فقط بعد از پرداخت گرفته می‌شود (پیش از پرداخت، فرمش اصلا باز نمی‌شود) و با AES-256-GCM ذخیره می‌شود. AES روشی استاندارد و جاافتاده برای رمزنگاری است و GCM بخشی است که اگر کسی متن رمزشده را دست‌کاری کند، هنگام باز کردن معلوم می‌شود. کلید هر سفارش هم جداست و از یک راز اصلی ساخته می‌شود که فقط در تنظیم‌های سرور است، نه در دیتابیس؛ یعنی دیتابیس به‌تنهایی برای خواندن رمزها کافی نیست.

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

برای سایت شما، پرسش عملی این است: کدام داده‌ها را خام نگه می‌دارید که نباید؟ فایل‌های پشتیبان کجا ذخیره می‌شوند و چه کسی به آن‌ها دسترسی دارد؟ کلیدها کنار همان داده‌ها نشسته‌اند یا جای دیگری؟

اسکریپت‌های شخص ثالث؛ در پشتی حریم خصوصی کاربران سایت

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

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

این موضوع کوچک نیست. بر اساس فصل حریم خصوصی Web Almanac 2024، ۹۵ درصد سایت‌ها در دسکتاپ و ۹۴ درصد در موبایل دست‌کم یک ردیاب دارند. یعنی تقریبا هر سایتی که می‌بینید، اطلاعات بازدیدش را به جای دیگری هم می‌فرستد.

چه می‌شود کرد؟

• فهرست بگیرید. بنویسید سایت شما از چه دامنه‌هایی کد بارگذاری می‌کند. معمولا چند ابزار پیدا می‌شود که سال‌ها پیش نصب شده و دیگر کسی از آن استفاده نمی‌کند.
• هر چه لازم نیست را حذف کنید. هر اسکریپت کمتر هم امنیت را بیشتر می‌کند و هم صفحه را سریع‌تر؛ این دو هدف این‌جا با هم همسو هستند. در صفحه‌ی بهینه‌سازی سرعت سایت هم «کدهای شخص ثالث» یکی از بخش‌های کار است.
• صفحه‌های حساس را خلوت کنید. صفحه‌ی پرداخت و ورود جای ابزار چت و پیکسل تبلیغاتی نیست.
• CSP بگذارید. Content-Security-Policy یک هدر است که به مرورگر می‌گوید این صفحه اجازه دارد از چه جاهایی اسکریپت، عکس و فونت بارگذاری کند و به کجا داده بفرستد. اگر کد مخربی هم به صفحه راه پیدا کند، مرورگر جلوی ارتباطش با سرور مهاجم را می‌گیرد. راهنمای CSP در MDN آن را کامل توضیح داده است. بر اساس Web Almanac 2024، فقط ۱۹ درصد هاست‌ها هدر CSP دارند.

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

امنیت فروشگاه اینترنتی: پرداخت، رمزها و دسترسی تیم

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

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

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

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

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

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

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

لاگ و نگه‌داری داده: چه چیزی، تا کی

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

دو قاعده کمک می‌کند:

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

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

بات‌ها را دور نگه دارید، بدون آزار آدم‌ها

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

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

سیاست حفظ حریم خصوصی: متنی که با کد یکی باشد

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

یک سیاست خوب به این پرسش‌ها جواب می‌دهد:

• چه داده‌ای جمع می‌کنید، و برای هر کدام چرا؟
• چه کسی آن را می‌بیند؟ آیا به شرکت دیگری (آمار، تبلیغات، پیامک، ارسال) داده می‌شود؟
• چطور از آن محافظت می‌کنید؟
• چه مدت نگه‌اش می‌دارید؟
• چه کوکی‌ها و ردیاب‌هایی در سایت هست؟
• کاربر چطور می‌تواند داده‌اش را ببیند یا حذفش را بخواهد؟
• آخرین بار کی به‌روز شده است؟

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

یک فهرست کوتاه برای شروع

اگر از همه‌ی این نوشته فقط چند کار را بخواهید انجام دهید، این‌ها را به ترتیب انجام دهید:

1. مطمئن شوید همه‌ی صفحه‌ها با HTTPS باز می‌شوند و نسخه‌ی بی‌قفل به نسخه‌ی قفل‌دار می‌رود.
2. فرم‌ها را مرور کنید و هر فیلدی را که دلیل روشنی برایش ندارید حذف کنید.
3. فهرست اسکریپت‌های شخص ثالث را بنویسید و هر چه استفاده نمی‌شود را بردارید.
4. ببینید رمزها هش می‌شوند و هیچ رمزی در لاگ یا ایمیل یا پیام‌رسان نمی‌ماند.
5. وردپرس، قالب، افزونه‌ها و PHP را به‌روز کنید.
6. برای هر کسی که به سایت دسترسی دارد حساب جدا بسازید و حساب‌های قدیمی را ببندید.
7. هدرهای امنیتی (HSTS، CSP و بقیه) را اضافه کنید.
8. سیاست حریم خصوصی را طوری بازنویسی کنید که با همه‌ی این‌ها یکی باشد.

از کجا بفهمیم سایت ما امروز کجاست

برای قدم اول لازم نیست کسی را استخدام کنید. تست رایگان سرعت تیم سفید کنار سرعت، گواهی SSL سایت و نسخه‌های TLS آن را بررسی می‌کند، می‌بیند نشانی بی‌قفل به HTTPS می‌رود یا نه، و شش هدر امنیتی (از جمله HSTS و Content-Security-Policy) را یکی‌یکی نشان می‌دهد که کدام هست و کدام نیست؛ بدون ثبت‌نام و از سروری در ایران. فقط صفحه‌ی اصلی سایت باز می‌شود و همان چیزهایی سنجیده می‌شود که هر بازدیدکننده‌ای از بیرون می‌بیند.

اگر سایت وردپرسی شما روی هاست اشتراکی است و می‌خواهید سروری داشته باشید که از روز اول امن ساخته شده باشد، در پیکربندی سرور وردپرس فایروال، گواهی SSL خودکار، به‌روزرسانی امنیتی خودکار و پشتیبان‌گیری روزانه بخشی از همان کار است. هزینه‌اش ۱۵ میلیون تومان است و ۳ روز طول می‌کشد، و سرور به نام خود شماست. و اگر پروژه‌ی بزرگ‌تری دارید، مثلا فروشگاه یا پنلی که باید از اول با همین قاعده‌ها ساخته شود، از صفحه‌ی تماس برایمان بنویسید.

پرسش‌های رایج

سایت من کوچک است؛ کسی سراغ داده‌ی من می‌آید؟

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

داشتن گواهی SSL یعنی سایت امن است؟

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

ابزار آمار را کنار بگذارم؟

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

رمز سرور را به تیم سفید بدهم امن است؟

فقط بعد از پرداخت و فقط از داخل پنل گرفته می‌شود، با AES-256-GCM ذخیره می‌شود، به خودتان هم دوباره نشان داده نمی‌شود و هر بار دیدنش در پنل تیم ثبت می‌شود. با این حال پیشنهاد ما همیشه این است که بعد از تحویل کار، رمزها را عوض کنید.

این نوشته جای مشاوره‌ی حقوقی است؟

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