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

تحلیلی انتقادی بر فرهنگ «مارکتینگ‌محور» و بی‌توجهی به حریم خصوصی کاربران

مقدمه: کشوری که همه‌چیز را «بیزنس» می‌بیند، نه «سیستم»

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

«چطور سریع‌تر رشد کنیم، مشتری بیشتری بگیریم، درآمد را بالا ببریم؟»

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

• نشت مداوم داده‌ها؛

• بی‌تفاوتی سازمان‌ها نسبت به حریم خصوصی کاربران؛

• بی‌معنا بودن «مسئولیت‌پذیری» در قبال داده؛

• و فرسودگی و دل‌زدگی متخصصان امنیت و باگ‌هانترها.

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

-

۱. اولویت شماره یک: مارکتینگ، مارکتینگ، و باز هم مارکتینگ

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

• رشد تعداد کاربران (User Acquisition)

• افزایش سهم بازار

• جذب سرمایه

• بالا بردن درآمد ماهانه (MRR/Revenue)

• بهبود KPIهای مارکتینگ (CPI, CAC, LTV, …)

در ذهن بسیاری از این مدیران، امنیت چیزی است شبیه:

• «فعلاً بیخیال، بعداً درستش می‌کنیم.»

• «الآن باید محصول را لانچ کنیم، امنیت را بعداً اضافه می‌کنیم.»

• «اگر مشکلی پیش آمد، آن موقع یک کارشناس امنیت می‌آوریم.»

این مدل فکر کردن، ریشه در چند نکته دارد:

۱.۱. نبود فشار قانونی و مقرراتی جدی

در بسیاری از کشورهای دنیا، اگر یک شرکت، داده‌های کاربرانش را از دست بدهد (Leak یا Breach):

• موظف است به کاربران اطلاع دهد؛

• در معرض جریمه‌ی سنگین و诉های حقوقی قرار می‌گیرد؛

• ممکن است مجوز فعالیتش تعلیق شود؛

• رسانه‌ها موضوع را در سطح ملی مطرح می‌کنند.

در ایران، غالباً:

• نه جریمه‌ی جدی وجود دارد؛

• نه فشار رسانه‌ای پایدار و سیستماتیک؛

• نه دادگاهی که در عمل، حقوق کاربران را پیگیری کند؛

• و نه فرهنگ «حق حریم خصوصی» در سطح عمومی جا افتاده است.

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

۱.۲. فشار سرمایه‌گذارها و ذی‌نفعان روی رشد

در اکوسیستم سرمایه‌گذاری، معمولاً رشد و عدد مهم است:

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

در چنین فضایی، هزینه‌کرد روی امنیت، از نگاه بسیاری از مدیران:

• «هزینه‌ی غیرقابل‌دیدن» است؛

• یعنی چیزی که نشان‌دادنی نیست؛

• در جلسات با سرمایه‌گذار به عدد تبدیل نمی‌شود؛

• و تا وقتی حادثه‌ای رخ نداده، ارزشش دیده نمی‌شود.

به همین دلیل، یک مدیر اغلب ترجیح می‌دهد بودجه را صرف:

• کمپین تبلیغاتی؛

• اینفلوئنسر مارکتینگ؛

• توسعه‌ی فیچرهای جدید؛

کند تا چیزی مثل:

• PenTest دوره‌ای

• ساختن تیم امنیت داخلی

• باگ‌بانتی برنامه‌ریزی‌شده

--

۲. دیتاست؛ و اینجا، حریم خصوصی شوخی است

در سطح جهانی، یکی از مهم‌ترین دارایی‌های هر شرکت «داده» است. اما این اهمیت، دو وجه دارد:

• داده به‌عنوان سرمایه‌ی کسب‌وکار

• داده به‌عنوان مسئولیت در برابر کاربر

در ایران، اغلب مورد اول دیده می‌شود (داده به‌عنوان ابزار مارکتینگ، تحلیل رفتار مشتری، فروش و …)، اما مورد دوم تقریباً نادیده گرفته می‌شود.

۲.1. بی‌تفاوتی نسبت به نشت داده‌های حساس

در بسیاری از دیتالیـک‌هایی که تا امروز رخ داده:

• شماره تلفن

• کد ملی

• آدرس منزل

• تاریخ تولد

• اطلاعات شناسنامه‌ای

• سوابق تراکنش یا ثبت‌نام

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

اما واکنش معمول چیست؟

• «خب لو رفته که رفته…»

• «چه اهمیتی داره شماره تلفن مردم لو بره؟»

• «کد ملی که چیز خاصی نیست!»

این نگاه، عملاً حریم خصوصی را به یک مفهوم تزئینی تبدیل می‌کند.

در حالی که در بسیاری از کشورها:

• همین اطلاعات پایه‌ای (Phone, National ID, Address) به‌عنوان داده‌ی حساس محسوب می‌شود؛

• شرکت‌ها موظف‌اند آن را در حد استاندارد بالا محافظت کنند؛

• و نشت آن می‌تواند به معنای نقض قانون و جرایم سنگین باشد.

2.2. نبود سازمان‌های مدافع حقوق کاربران

یکی از مشکلات اساسی این است که در ایران، کاربر معمولاً:

• نماینده‌ی حقوقی یا سازمانی قدرتمند ندارد که از او دفاع کند؛

• سازمان‌های ناظر اغلب روی موضوعات دیگری تمرکز دارند (مجوز، محتوا، ساختار اداری…)؛

• و مفهوم «مطالبه‌گری حقوق داده» هنوز کاملاً جا نیفتاده است.

نتیجه:

• اگر دیتای شما لو برود، معمولاً نه شرکت پاسخگو است، نه سازمان ناظر، نه سازوکار جبران خسارت وجود دارد؛

• حداکثر واکنش: سکوت، یا یک اطلاعیه‌ی مبهم که «ما اهمیت می‌دهیم و در حال بررسی هستیم.»

۳. نمونه‌ی نمادین: نشت داده در سامانه‌هایی شبیه «1404»

در سال‌های اخیر، بارها و بارها خبر نشت داده‌ی کاربران از سامانه‌های مختلف (اعم از دولتی، شبه‌دولتی و خصوصی) منتشر شده است.

یکی از الگوهای تکراری این است:

• یک سامانه‌ی ملی/سراسری برای ثبت‌نام یا احراز هویت (مثلاً مشابه آنچه در رسانه‌ها برای سایت‌هایی با کارکرد مشابه «1404» مطرح شده)

• کاربران مجبورند اطلاعات کامل خود را وارد کنند (کد ملی، شماره موبایل، آدرس، گاهی اسکن مدارک)

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

مسئله‌ی مهم اینجا دو چیز است:

• حجم و حساسیت داده

• سطح پاسخگویی و مسئولیت‌پذیری

اغلب این سامانه‌ها:

• بر بسترهایی توسعه یافته‌اند که امنیت به‌عنوان «افزونه» در نظر گرفته شده، نه بخشی از طراحی؛

• تست امنیت جدی روی آن‌ها انجام نشده؛

• تیم امنیت از ابتدا در چرخه‌ی توسعه درگیر نبوده است؛

• و حتی بعد از نشت، فرآیند Incident Response حرفه‌ای دیده نمی‌شود.

یکی از مشکلات کلیدی:

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

۴. بی‌توجهی به باگ‌بانتی: وقتی هکر را دشمن می‌بینند، نه شریک

در دنیا، شرکت‌ها به‌طور جدی از:

• Bug Bounty Programs

• Responsible Disclosure

• Security Researcher Engagement

استفاده می‌کنند تا:

• پیش از این‌که مهاجم سوءاستفاده کند، ضعف‌ها را کشف کنند؛

• با امنیت‌پژوه‌ها رابطه‌ی همکاری داشته باشند، نه تقابل؛

• و در مقابل، به این پژوهشگران پاداش عادلانه بدهند.

در ایران، وضعیت بسیار متفاوت است:

۴.۱. بی‌اعتمادی ساختاری به امنیت‌پژوه‌ها

در بسیاری از سازمان‌ها، اگر یک پژوهشگر امنیتی:

• باگ را پیدا کند؛

• به‌صورت محترمانه اطلاع دهد؛

• و با رعایت اصول Responsible Disclosure عمل کند؛

ممکن است با این واکنش مواجه شود:

• «شما هکر هستید، چرا وارد سیستم ما شدید؟»

• «این کار غیرقانونی است، به پلیس گزارش می‌دهیم.»

• «اصلاً چه کسی به شما اجازه داده تست کنید؟»

در نتیجه:

• به جای تبدیل امنیت‌پژوه به چشم امنیتی سازمان، او را به عنوان تهدید می‌بینند؛

• و این فرهنگ، عملاً هرگونه Bug Bounty جدی را فلج می‌کند.

۴.۲. پاداش‌های ناچیز و بی‌ارزش کردن تخصص

فرض کنیم سازمانی باگ‌بانتی خام یا محدودی دارد.

بسیاری از باگ‌هانترهای ایرانی تجربه کرده‌اند که:

• برای گزارش یک آسیب‌پذیری جدی (مثلاً SQL Injection، Data Exposure، Misconfiguration خطرناک)

• پاداش‌های در حد چند صد هزار تومان، یا حتی «یک تیشرت» گرفته‌اند؛

• یا اصلاً هیچ پاداشی، فقط یک «تشکر خشک و خالی»؛

• یا در برخی موارد، بعد از گزارش باگ، حتی پاسخی هم نگرفته‌اند.

در حالی که:

• پیدا کردن یک باگ جدی، ممکن است ده‌ها ساعت زمان، تحقیق، ابزار و مهارت بخواهد؛

• در بازار جهانی، همین باگ‌ها می‌توانند بین صدها تا هزاران دلار ارزش داشته باشند؛

• و در بسیاری از پلتفرم‌های بین‌المللی، باگ‌هانترها زندگی‌شان را از همین راه می‌گذرانند.

این تضاد، باعث می‌شود:

• انگیزه‌ی باگ‌هانتر ایرانی برای همکاری با شرکت‌های داخلی کم شود؛

• و به‌جای آن، به سمت پلتفرم‌های بین‌المللی و هدف‌های خارجی برود؛

یا کلاً از این مسیر کنار بکشد، چون «زحمتش نمی‌ارزد».

۵. شرکت‌هایی که فقط «نام امنیت» را یدک می‌کشند

یکی از پدیده‌های رایج، سازمان‌هایی هستند که:

• در اسلایدها و سایت رسمی خود، از «Security» و «Privacy» به‌عنوان شعار استفاده می‌کنند؛

• اما در عمل، جای خالی این موارد به‌شدت محسوس است.

چند نمونه از نشانه‌های این وضعیت:

• Policy و Terms نوشتاری دارند، اما هیچ‌کدام در عمل پیاده‌سازی نمی‌شود؛

• صفحه‌ای با عنوان «امنیت داده‌ی کاربران برای ما مهم است» دارند، اما:

TLS نادرست

API بدون Rate Limit

احراز هویت ضعیف

لاگ‌گیری ناامن

فایل‌های Backup قابل‌دسترس

• شعار «ما از آخرین استانداردهای امنیتی استفاده می‌کنیم» می‌دهند، اما حتی:

PenTest دوره‌ای ندارند؛

یا حداقل یک نفر متخصص تمام‌وقت امنیت در تیم ندارند.

در چنین شرکت‌هایی، «امنیت» بیشتر:

• یک واژه‌ی تزئینی برای مارکتینگ است؛

• نه یک فرآیند مداوم در چرخه‌ی توسعه‌ی محصول.

۶. سازمان‌های ناظر و ذی‌نفع: بازرسی روی کاغذ، سکوت در عمل

در تئوری، متولیان مختلفی برای:

• نظارت بر امنیت سامانه‌ها

• حفاظت از حریم خصوصی

• و ایجاد استانداردهای فنی

وجود دارد. اما در عمل، چند مشکل اساسی دیده می‌شود:

۶.۱. تمرکز روی «شکل» نه «محتوا»

بسیاری از بازرسی‌ها:

• روی مدارک، فرم‌ها، چک‌لیست‌های اداری تمرکز دارند؛

• اما تست فنی واقعی از سامانه‌ها انجام نمی‌دهند؛

• یا اگر هم انجام می‌دهند، نتايج آن به صورت شفاف منتشر نمی‌شود.

۶.۲. عدم پاسخگویی عمومی

وقتی یک دیتالیـک بزرگ رخ می‌دهد:

• کاربران نمی‌دانند کدام سازمان ناظر مسئول است؛

• هیچ گزارش عمومی و شفافی ارائه نمی‌شود؛

• مسئولیت مشخص نمی‌شود که «چه کسی کوتاهی کرده؟»؛

• و فرآیند درس‌آموخته (Post-Incident Review) عمومی شکل نمی‌گیرد.

نتیجه این است که:

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

۷. طولانی بودن زمان پچ: از کشف باگ تا اصلاح، یک راه پر از اصطکاک

در مدل ایده‌آل امنیت:

• باگ کشف می‌شود؛

• به‌صورت مسئولانه گزارش می‌شود؛

• سازمان، ظرف مدت مشخص (مثلاً ۳۰ روز) آن را پچ می‌کند؛

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

اما در بسیاری از سازمان‌های ایرانی:

• تیم توسعه و امنیت، ساختار سازمانی مشخص و کانال ارتباطی شفافی ندارند؛

• برای هر تغییر، باید مسیرهای اداری طولانی طی شود؛

• اگر باگ روی سرویس در حال بهره‌برداری باشد، می‌ترسند تغییری بدهند که «نکند سیستم Down شود»؛

• گاهی، مدیر پروژه یا مدیر محصول، اهمیت باگ را درک نمی‌کند و آن را در اولویت پایین قرار می‌دهد.

این‌ها باعث می‌شود:

• فاصله‌ی زمانی بین کشف باگ و پچ شدن باگ، به جای چند روز یا چند هفته، به ماه‌ها بکشد؛

• در این مدت، سامانه در معرض سوءاستفاده قرار دارد؛

• و اگر هم حادثه‌ای رخ بدهد، دوباره همان چرخه‌ی «انکار – سکوت – فراموشی» تکرار می‌شود.

۸. وضعیت باگ‌هانتر ایرانی: تخصص جهانی، پاداش محلی

بسیاری از متخصصان امنیت و باگ‌هانترهای ایرانی:

• مهارت‌های فنی بسیار بالایی دارند؛

• در پلتفرم‌های جهانی (HackerOne, Bugcrowd, …) فعال‌اند؛

• و برای شرکت‌های بین‌المللی باگ‌های جدی کشف کرده‌اند.

اما وقتی وارد بازار داخلی می‌شوند:

• با نگاه امنیت‌ستیز یا امنیت‌هراس مواجه می‌شوند؛

• یا با پاداش‌های ناچیز ریالی روبه‌رو می‌شوند که ارزش زمانی که صرف کرده‌اند را هم پوشش نمی‌دهد؛

• در برخی موارد، حتی با انواع اتهام‌ها و تهدیدها مواجه شده‌اند.

این تضاد، باعث می‌شود:

• فاصله‌ی بین «سطح واقعی تهدید» و «آمادگی سازمان‌ها» هر روز بیشتر شود؛

• متخصص امنیت، انگیزه‌ی همکاری با شرکت‌های داخلی را از دست بدهد؛

• و عملاً، فضای داخلی از یک سرمایه‌ی ارزشمند محروم شود.

۹. چرا این چرخه باید شکسته شود؟

ممکن است برخی بگویند:

«خب، تا حالا هم دیتای مردم بارها لو رفته، چه اتفاق مهمی افتاده؟»

این نگاه خطرناک است، چون:

1.اثر تراکمی نشت داده‌ها را نادیده می‌گیرد

وقتی در طول چند سال، چندین دیتالیـک رخ دهد، یک مهاجم می‌تواند:

• پروفایل نسبتاً دقیقی از افراد بسازد؛

• از ترکیب داده‌ها (مثلاً تلفن + کد ملی + آدرس + سابقه‌ی خرید) سوءاستفاده کند؛

• حملات مهندسی اجتماعی پیشرفته‌تری پیاده کند؛

• یا حتی زیرساخت‌های مالی و هویتی را هدف قرار دهد.

2.اعتماد عمومی را فرسایش می‌دهد

اگر مردم مدام حس کنند داده‌هایشان در امان نیست:

• اعتماد به سرویس‌های دیجیتال کاهش می‌یابد؛

• مقاومت در برابر ثبت‌نام و احراز هویت افزایش می‌یابد؛

• و در نهایت، تحول دیجیتال واقعی به تعویق می‌افتد.

3.هزینه‌ی اصلاح بعد از حادثه، بسیار بیشتر از پیشگیری است

• بعد از یک دیتالیـک، هزینه‌ی جبران (اگر واقعاً بخواهند جبران کنند) بسیار بالاست؛

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

۱۰. چه باید کرد؟ (در حد حداقل‌های منطقی)

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

1.امنیت را جزئی از بیزنس‌پلن و مارکتینگ بدانیم، نه در تضاد با آن

• شرکت‌ها باید درک کنند که «اعتماد کاربر» یکی از مهم‌ترین دارایی‌های برند است؛

• امنیت، هزینه‌ی اضافی نیست؛ سرمایه‌گذاری روی اعتماد است.

2.الزام قانونی و استانداردهای روشن برای حفاظت از داده

• تدوین و اجرای جدی قانون حریم خصوصی؛

• تعریف جریمه‌های واقعی برای نشت داده؛

• الزام سازمان‌ها به گزارش‌دهی و شفاف‌سازی.

3.تشویق و حمایت از باگ‌بانتی و Responsible Disclosure

• ایجاد کانال رسمی برای گزارش باگ؛

• تعریف پاداش‌های واقعی و متناسب با ارزش آسیب‌پذیری؛

• آموزش مدیران و تیم‌های فنی برای تعامل حرفه‌ای با امنیت‌پژوه‌ها.

4.ساخت تیم امنیت داخلی، نه صرفاً برون‌سپاری مقطعی

• داشتن حداقل یک تیم کوچک SecOps / AppSec / Blue Team؛

• انجام دوره‌ای تست نفوذ؛

• فرهنگ‌سازی امنیت در بین توسعه‌دهندگان (Secure Coding).

5.سازمان‌های ناظر، از روی کاغذ وارد میدان واقعی شوند

• بازرسی‌های فنی واقعی، نه فقط چک‌لیست‌های اداری؛

• انتشار گزارش‌های عمومی (در حد غیرمحرمانه) برای افزایش شفافیت؛

• پاسخ‌گو بودن در برابر کاربران.

جمع‌بندی: امنیت، لوکس نیست؛ پایه‌ی بقاست

جوهره‌ی مسئله این است که در اکوسیستم فعلی:

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

• داده‌ی کاربر صرفاً ابزار تبلیغات و تحلیل بازار نیست؛ یک مسئولیت حقوقی، اخلاقی و انسانی است.

• و امنیت چیزی نیست که «اگر وقت شد» به آن فکر کنیم؛ اگر از ابتدا جزئی از DNA سازمان نباشد، دیر یا زود خودش را به بدترین شکل یادآوری می‌کند.

تا زمانی که:

• نشت داده‌ی کاربران بدون پیامد جدی برای سازمان‌هاست؛

• باگ‌هانتر ایرانی انگیزه‌ی مالی و معنوی کافی برای همکاری ندارد؛

• سازمان‌های ناظر از حریم خصوصی به‌صورت واقعی دفاع نمی‌کنند؛

امنیت، در حاشیه‌ی کسب‌وکار باقی خواهد ماند و تیترهایی مثل «لو رفتن دیتای کاربران فلان سامانه» ادامه پیدا خواهد کرد.

اما همان‌طور که تجربه‌ی دنیا نشان داده:

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

و در آخر هم جمله :

" امنیت نسبی است مثل رضایت از زندگی ... "

امیدوارم این مقاله براتون مفید باشه

ممنونم که نظرتون رو کامنت میکنید