وقتی صحبت از «تأییدیهٔ سازمان بورس» میشود، بیشتر گفتوگوها روی الزامات کسبوکاری متمرکز میماند. اما مرکز نظارت بر امنیت اطلاعات بازار سرمایه سند جداگانهای دارد که دامنهاش از پیکربندی فایروال بسیار فراتر میرود.
در ابلاغیهٔ مورخ ۱۴۰۵/۰۴/۰۲ مرکز مبارزه با پولشویی و تأمین مالی تروریسم سازمان بورس، رعایت حداقل الزامات «کسبوکاری، فنی و امنیتی» شرط بررسی نرمافزار اعلام شده است. بخش امنیتی به سند جامع الزامات امنیت اطلاعات و ارتباطات بازار سرمایه ارجاع دارد. این نوشته ساختار آن سند را مرور میکند تا مشخص شود دامنهٔ آمادهسازی چقدر است.
سند را مرکز نظارت بر امنیت اطلاعات بازار سرمایه — که به اختصار «مکنا» نامیده میشود — بر اساس مصوبهٔ چهارصد و چهلوهشتمین جلسهٔ هیأت مدیرهٔ سازمان تدوین کرده است. نکتهای که در ارجاعدهی اهمیت دارد: سند شماره نسخه دارد و نسخهٔ جاری ۶٫۰ است؛ خودِ سند هم تصریح میکند «در صورت لزوم اصلاحات مقتضی انجام و بهصورت رسمی اطلاعرسانی خواهد شد». پس مستندات آمادگی باید به شمارهٔ نسخه ارجاع دهند، نه صرفاً به عنوان سند.
فصل اول: پنج حوزهٔ سازمانی
نکتهٔ مهم برای برنامهریزی پروژه این است که فصل اول سند اصلاً فنی نیست. پنج حوزهٔ آن عبارتاند از:
- الزامات ساختار سازمانی: جایگاه واحد امنیت اطلاعات و تفکیک وظایف در چارت سازمان
- الزامات استقرار: چگونگی پیادهسازی و نگهداشت خود این الزامات
- الزامات تعامل با طرفهای ثالث: پیمانکاران، تأمینکنندگان و سرویسدهندگان بیرونی
- الزامات منابع انسانی: از احراز صلاحیت تا آموزش و خاتمهٔ همکاری
- الزامات حفظ انطباق: سازوکار پایش مستمر رعایت الزامات
به بیان دیگر، حتی اگر سامانهای از نظر فنی بیعیب باشد، نبودِ ساختار سازمانی و رویهٔ منابع انسانی متناظر، خلأ محسوب میشود. این بخش را نمیتوان به تأمینکنندهٔ نرمافزار واگذار کرد؛ کار خود مؤسسه است.
فصل دوم: هفت حوزهٔ فنی
فصل دوم دامنهٔ فنی را در هفت حوزه تعریف میکند:
- امنیت شبکه و ارتباطات — پرحجمترین بخش سند
- امنیت سیستمها و برنامههای کاربردی، از جمله چرخهٔ توسعهٔ امن نرمافزار
- حفاظت از دادهها
- مدیریت حادثه
- امنیت فیزیکی
- پشتیبانگیری
- تداوم کسبوکار و بازیابی از بحران
سند برای این حوزهها به چارچوبهای شناختهشده ارجاع میدهد — از جمله سامانهٔ مدیریت امنیت اطلاعات، منابع NIST، استاندارد PCI DSS برای دادهٔ کارت، چرخهٔ توسعهٔ امن، و ITIL برای مدیریت خدمات. یعنی انتظار میرود آمادگی مؤسسه با زبان همین چارچوبها مستند شود، نه با توصیف آزاد.
هر الزام یک سطح بلوغ دارد
ساختار سند چیزی است که در برنامهریزی پروژه بیش از فهرست فصلها اهمیت دارد: الزامات در جدولهایی با ستونهای «شماره الزام»، «عنوان الزام»، «سطح بلوغ» و «توضیحات» آمدهاند، و هر الزام به یکی از سه سطح A، B یا C نسبت داده شده است.
- سطح C الزامات پایهایتر — مانند خطمشی میز پاک و صفحه پاک، و آموزش و آگاهیرسانی.
- سطح B لایهٔ میانی — بیانیهٔ خطمشی امنیت اطلاعات، جانشینپروری، تعهدنامهٔ عدم افشا، رویهٔ تعامل با طرف ثالث.
- سطح A سختگیرانهترین — تأمین نیروی متخصص و فرآیند ممیزی داخلی با مهلتهای مشخص.
پیامد این ساختار برای زمانبندی روشن است: برنامهٔ استقرار نباید فصلبهفصل پیش برود، باید سطحبهسطح پیش برود. تیمی که فصل اول را کامل میکند و بعد سراغ فصل دوم میرود، ممکن است الزامات سطح A فصل دوم را تا انتهای پروژه عقب انداخته باشد.
فصل چهارم: منابع انسانی، جایی که پروژهها گیر میکنند
چهار الزام این فصل نشان میدهد چرا نمیتوان این بخش را به تأمینکنندهٔ نرمافزار سپرد:
- ۴-۱ تأمین نیروی متخصص (سطح A): شرکت باید کارشناسان باتجربه و مسلط به «تمامی تخصصهای مورد نیاز حوزهٔ امنیت و فناوری اطلاعات» را متناسب با گسترهٔ سرویسدهی خود در اختیار داشته باشد. قید تناسب یعنی معیار، عدد ثابتی نیست.
- ۴-۲ جانشینپروری (سطح B): برای سمتها و نقشهای کلیدی، جانشینپروری باید در دستور کار باشد تا در زمان قطع همکاری فرد اصلی، ادامهٔ انجام وظایف آن سمت تضمین شود. یعنی وابستگی به یک نفر، خودش یک عدمانطباق است.
- ۴-۳ تعهدنامهٔ منع افشای اطلاعات (سطح B): همهٔ کارکنان، پیمانکاران و مشاوران باید تعهدنامهٔ حفظ محرمانگی را به مدت نامحدود امضا کنند. قید «نامحدود» یعنی تعهد با پایان قرارداد منقضی نمیشود.
- ۴-۴ آموزش و آگاهیرسانی (سطح C): از نیازسنجی آموزشی تا اجرا.
این چهار بند در کنار مواد آموزشی آییننامهٔ مبارزه با پولشویی مینشینند و نه بهجای آنها؛ تفصیل آن تکلیف موازی را در برنامهٔ آموزش مبارزه با پولشویی آوردهایم.
فصل سوم: طرف ثالث
سند برای دریافت یا ارائهٔ خدمات از/به طرف ثالث، تدوین و مستندسازی یک رویه را الزامی میکند و حداقل محتوای آن را هم تعیین میکند: محدودهٔ دسترسی طرف ثالث «در ابعاد فیزیکی و منطقی، سیستمی، فرآیندی، فناوری و منابع اطلاعاتی» بر اساس اصل حداقل دسترسی و بهصورت دقیق و شفاف مستند شود؛ طرف ثالث تعهدنامهٔ عدم افشای اطلاعات را — شامل تعهد به همهٔ خطمشیها و قوانین امنیتی شرکت، محرمانگی، مسئولیتهای متناظر، عواقب عدم اجرا و محدودیتهای نسخهبرداری — امضا کند؛ و به اجرای توافقنامهٔ سطح خدمت متعهد باشد.
برای پروژهای که با تأمینکنندهٔ نرمافزار مبارزه با پولشویی کار میکند، این فصل مستقیماً به قرارداد برمیگردد: بندهای دسترسی، محرمانگی و SLA باید در همان قرارداد باشند، نه در یک تفاهم شفاهی.
فصل پنجم: حفظ انطباق و مهلتهای ممیزی
فصل پنجم تنها جایی است که سند مهلت عددی میدهد. الزام ۵-۱ (سطح A) مدیر امنیت اطلاعات شرکت را مکلف میکند فرآیند ممیزی داخلی را با سه قید اجرا کند:
- حداکثر شش ماه پس از توافق روی حوزهٔ ممیزی با مرکز مکنا — و حداقل دو بار در سال؛
- پیگیری عدمانطباقهای اعلامشده توسط مرکز مکنا طی بازهٔ دو ماه؛
- ارسال نتایج بهصورت مکتوب و با شواهد قابل دفاع به مرکز مکنا.
الزام ۵-۱-۱ هم بهبود مستمر را میخواهد: بر اساس نتایج ممیزی داخلی، اقدامات اصلاحی برای رفع اساسی مشکلات انجام و در صورت نیاز طرحهای فنی و امنیتی بهروز شود.
عبارت «شواهد قابل دفاع» همان چیزی است که در فصل اول هم به شکل دیگری آمده: الزام ۱-۴ بیانیهٔ خطمشی امنیت اطلاعات را میخواهد که شامل تعهد مدیریت به ارتقای مداوم باشد و به تأیید عالیترین مقام شرکت برسد، و الزام ۱-۵ معرفی رسمی و مکتوب مسئول فناوری اطلاعات به مرکز مکنا را الزامی میکند. در هر سه مورد، آنچه ارزیابی میشود سند است، نه ادعا.
مفاهیمی که در سند وزن دارند
چند اصطلاح در واژگان سند تعریف شدهاند که نشان میدهد ارزیابی چگونه انجام میشود:
- نقطهٔ اتکای منفرد (Single Point of Failure): معماریای که یک جزء آن، کل سرویس را از دسترس خارج کند، پذیرفته نیست. افزونگی الزام است، نه توصیه.
- RTO و RPO: هدف زمان بازیابی و هدف نقطهٔ بازیابی. این دو عدد باید تعیین و آزموده شده باشند. پشتیبانگیریای که هرگز بازیابیاش آزمایش نشده، این الزام را برآورده نمیکند.
- توافقنامهٔ سطح خدمت (SLA): تعهدات سرویسدهنده باید مکتوب و قابل سنجش باشد.
- مدیریت خارج از باند (Out of Band): مسیر مدیریتی جدا از مسیر دادهٔ عملیاتی.
این برای پروژهٔ استقرار چه معنایی دارد
سه پیامد عملی دارد. نخست، آمادهسازی امنیتی موازی با آمادهسازی کسبوکاری پیش میرود و اگر به انتهای پروژه موکول شود، زمانبندی تأییدیه را عقب میاندازد. دوم، بخشی از الزامات — ساختار سازمانی، منابع انسانی، طرف ثالث — بر عهدهٔ مؤسسه است و تأمینکنندهٔ نرمافزار نمیتواند آن را جبران کند. سوم، مستندسازی بهاندازهٔ پیادهسازی اهمیت دارد: در بررسی، آنچه ارائه میشود سند است، نه توضیح شفاهی.
فرآیند کلی تأیید و اینکه درخواست را چه کسی باید ارسال کند را در الزامات سامانه مبارزه با پولشویی در بازار سرمایه و نگاشت قابلیتها به بندهای الزامات را در صفحهٔ سامانه مبارزه با پولشویی بازار سرمایه آوردهایم.
این نوشته صرفاً جنبه اطلاعرسانی دارد. برای اقدام، به متن رسمی سند و آخرین نسخهٔ ابلاغی آن مراجعه کنید.
میخواهید ببینید این الزامات در عمل چگونه اجرا میشوند؟
بازگشت به فهرست مقالات مقالات بازار سرمایه
