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

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

عدم انطباق با NIS2 می‌تواند پیامدهای مالی و حقوقی سنگینی داشته باشد. برای نهادهای حیاتی (Essential Entities) جریمه‌ها می‌تواند تا ۱۰ میلیون یورو یا ۲ درصد از گردش مالی جهانی برسد. برای نهادهای مهم (Important Entities) نیز سقف جریمه تا ۷ میلیون یورو یا ۱.۴ درصد از گردش مالی جهانی تعیین شده است. علاوه بر این، اعضای هیئت‌مدیره و مدیران ارشد نیز ممکن است با مسئولیت شخصی و حتی ممنوعیت موقت از تصدی سمت‌های مدیریتی مواجه شوند.

بیشتر سازمان‌ها می‌دانند که باید با NIS2 منطبق شوند. اما سؤال دشوارتر این است:

از کجا شروع کنیم، بدون اینکه تیم امنیت و فناوری اطلاعات پیش از اولین ممیزی فرسوده شود؟

واقعیت این است که هیچ سازمانی نمی‌تواند همه الزامات NIS2 را یک‌باره اجرا کند. رویکرد عملی این است که ابتدا کنترل‌هایی را شناسایی کنید که:

• در مدت کوتاهی قابل اجرا هستند؛
• بلافاصله شواهد قابل ارائه در ممیزی تولید می‌کنند؛
• مهم‌ترین مسیرهای حمله را مسدود می‌کنند.

مدیریت دسترسی و بهداشت اطلاعات احراز هویت (Credential Hygiene) هر سه ویژگی را دارند.

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

IAM چیست؟ راهنمای جامع مدیریت هویت و دسترسی (Identity and Access Management) در ادامه حتما بخوانید

چرا اطلاعات احراز هویت همچنان یک نقطه بحرانی هستند؟

بر اساس گزارش ۲۰۲۶ Verizon Data Breach Investigations Report (DBIR)، سوءاستفاده از آسیب‌پذیری‌ها با سهم ۳۱ درصدی از رخدادها، از سرقت اطلاعات احراز هویت به‌عنوان مهم‌ترین بردار اولیه دسترسی عبور کرده است.

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

اگر به جای تمرکز صرف بر مرحله اولیه نفوذ، کل زنجیره حمله را بررسی کنیم، تصویر متفاوتی به دست می‌آید. سوءاستفاده از اطلاعات احراز هویت در ۳۹ درصد از تمام رخنه‌ها مشاهده شده است. خود Verizon نیز Credential Abuse را یک نقطه مداخله مؤثر برای کاهش ریسک معرفی می‌کند.

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

برای درک بهتر اولویت‌بندی، زمان اجرای دو الزام NIS2 در ماده ۲۱ را مقایسه کنید:

اجرای سیاست رمز عبور دقیق در Active Directory، انتقال اطلاعات احراز هویت مشترک به یک خزانه مدیریت‌شده و فعال‌سازی MFA مقاوم در برابر فیشینگ برای حساب‌های دارای دسترسی ممتاز، برای یک تیم متخصص می‌تواند پروژه‌ای ۲ تا ۴ هفته‌ای باشد.

از نظر بازده سرمایه‌گذاری در انطباق، تفاوت قابل‌توجهی وجود دارد.

سه شکاف مهم مدیریت دسترسی که می‌توانند ممیزی NIS2 را با شکست مواجه کنند

۱. حساب‌های سرویس و کلیدهای API بدون مدیریت

بخش زیادی از بحث‌های مربوط به مدیریت دسترسی در NIS2 بر کاربران انسانی متمرکز است؛ اما ممیزان امنیتی بیش از گذشته به هویت‌های غیرانسانی (Non-Human Identities) نیز توجه می‌کنند.

حساب‌های سرویس، کلیدهای API، رشته‌های اتصال پایگاه داده و توکن‌های استقرار، همگی هویت‌های غیرانسانی هستند و در بسیاری از سازمان‌ها به شکلی مدیریت می‌شوند که اگر مربوط به یک کاربر انسانی بود، از نظر امنیتی قابل قبول محسوب نمی‌شد.

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

این اطلاعات اغلب در مکان‌هایی مانند موارد زیر ذخیره می‌شوند:

• فایل‌های .env
• تنظیمات Pipelineهای CI/CD
• فایل‌های پیکربندی
• درایوهای اشتراکی
• اسکریپت‌های استقرار

دقیقاً همان مکان‌هایی که مهاجمان پس از دستیابی اولیه به سیستم به دنبال آن‌ها می‌گردند.

ماده ۲۱(۲)(ی) NIS2 الزام می‌کند سیاست‌های کنترل دسترسی، تمام حساب‌هایی را که به شبکه‌ها و سیستم‌های اطلاعاتی دسترسی دارند پوشش دهند.

عبارت «تمام حساب‌ها» شامل حساب‌های سرویس نیز می‌شود.

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

راهکار چیست؟

نقطه شروع، فهرست‌برداری کامل (Inventory) است:

• تمام حساب‌های سرویس را از Active Directory استخراج کنید؛
• تمام کلیدهای API را از سامانه مدیریت Secrets یا فایل‌های پیکربندی پیدا کنید؛
• مالک هر Credential را مشخص کنید؛
• اطلاعات را به یک سیستم مدیریت‌شده منتقل کنید؛
• برای آن‌ها برنامه چرخش دوره‌ای Credential تعریف کنید.

۲. حساب‌های غیرفعال و فرایند ناقص خروج کارکنان

یک Dormant Account حسابی است که همچنان وجود دارد و اطلاعات ورود معتبر دارد، اما صاحب آن دیگر به دسترسی مربوطه نیاز ندارد.

این حساب می‌تواند متعلق به:

• کارمند سابق؛
• پیمانکاری که همکاری‌اش تمام شده؛
• فروشنده‌ای که پروژه‌اش ماه‌ها قبل به پایان رسیده؛
• یا کاربری باشد که دیگر مسئولیت مربوطه را بر عهده ندارد.

چنین حساب‌هایی یکی از نقاط ضعف مستقیم در ممیزی کنترل دسترسی هستند؛ زیرا ماده ۲۱(۲)(ی) NIS2 مدیریت چرخه عمر دسترسی‌ها را نیز دربرمی‌گیرد.

مشکل Offboarding معمولاً ناشی از حمله یا سوءنیت نیست؛ بلکه یک مشکل فرایندی است.

برای مثال، واحد منابع انسانی درخواست خروج کارمند را ثبت می‌کند، تیم IT حساب Active Directory را غیرفعال می‌کند و فرایند تمام می‌شود.

اما چه کسی بررسی می‌کند که همان فرد:

• دسترسی مستقیم به پایگاه داده نداشته باشد؟
• گواهی VPN او لغو شده باشد؟
• حساب AWS IAM نداشته باشد؟
• کلید SSH روی سرورهای Production باقی نگذاشته باشد؟
• به سیستم‌های SaaS سازمان دسترسی نداشته باشد؟

هرکدام از این موارد یک Credential یا مجوز دسترسی جداگانه است که باید لغو شود.

در بسیاری از سازمان‌ها نیز هیچ سیستم واحدی وجود ندارد که تمام این دسترسی‌ها را در یک مکان ردیابی کند.

ممیزی فقط به «بررسی دسترسی» نیاز ندارد؛ به مدرک بررسی نیاز دارد.

بازبینی‌های دسترسی باید ثبت، مستند و قابل Export باشند.

ممیز به جای زنجیره‌ای از ایمیل‌ها، گزارشی می‌خواهد که مشخص کند:

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

۳. نبود MFA مقاوم در برابر فیشینگ

ماده ۲۱(۲)(ج) NIS2 استفاده از احراز هویت چندعاملی یا سایر راهکارهای احراز هویت امن را در شرایط مناسب مورد توجه قرار می‌دهد.

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

در چنین محیط‌هایی، SMS OTP دیگر بهترین استاندارد امنیتی محسوب نمی‌شود.

استاندارد NIST SP 800-63B نیز OTP مبتنی بر SMS را در دسته روش‌های احراز هویت محدودشده قرار می‌دهد؛ از جمله به دلیل ریسک‌هایی مانند SIM Swapping و رهگیری ارتباطات.

در مقابل، روش‌های Phishing-Resistant MFA مانند موارد زیر سطح امنیتی بالاتری ارائه می‌کنند:

• FIDO2
• WebAuthn
• کلیدهای امنیتی سخت‌افزاری
• احراز هویت مبتنی بر Certificate

با این حال، بسیاری از سازمان‌ها MFA را به‌صورت گسترده فعال کرده‌اند اما همچنان برای سیستم‌های Legacy، حساب‌های اشتراکی و حساب‌های سرویس استثناهایی در نظر گرفته‌اند.

همین استثناها معمولاً در زمان ممیزی مورد توجه قرار می‌گیرند و نیازمند دو چیز هستند:

1. کنترل فنی مناسب؛
2. فرایند مستند برای تأیید و مدیریت استثناها.
   
   

   MFA چیست؟ راهنمای جامع احراز هویت چندعاملی در ادامه حتما بخوانید
   
   

یک نقطه کنترل واحد برای مدیریت Credentialها

هر سه شکاف بالا یک مشکل مشترک دارند:

نبود یک سیستم واحد برای ردیابی Credentialها، اعمال سیاست‌های دسترسی و تولید شواهد قابل ارائه در ممیزی.

یک Password & Secrets Manager سازمانی مانند Passwork می‌تواند این بخش را متمرکز کند و قابلیت‌هایی مانند موارد زیر را در اختیار سازمان قرار دهد:

• ذخیره رمزهای حساب‌های سرویس، API Keyها و Certificateها در یک Vault خودمیزبان؛
• تعیین مالک برای هر Secret؛
• تعریف برنامه چرخش Credentialها؛
• کنترل دسترسی مبتنی بر نقش یا RBAC؛
• اتصال به Active Directory و LDAP؛
• پشتیبانی از WebAuthn و کلیدهای امنیتی سخت‌افزاری؛
• ثبت کامل فعالیت‌ها و رویدادها در Audit Log.

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

مشکل اصلی ممیزی: شواهد

داشتن یک کنترل با اثبات وجود و اجرای آن کنترل دو موضوع متفاوت هستند.

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

ماده ۳۲ NIS2 به مراجع ذی‌صلاح اجازه می‌دهد مستندات مربوط به اقدامات امنیتی اجراشده را درخواست کنند.

در مدیریت Credential و دسترسی، مستندات مناسب باید حداقل سه بخش داشته باشد:

1. سیاست مکتوب و تأییدشده؛
2. کنترل فنی که سیاست را اجرا می‌کند؛
3. لاگ یا گزارش قابل بررسی که نشان دهد کنترل واقعاً فعال بوده و رویدادهای مربوطه را ثبت کرده است.

ممیزان معمولاً انتظار دارند موارد زیر قابل ارائه باشد:

• سیاست کنترل دسترسی، دارای نسخه و تأیید مدیریت؛
• شواهد اجرای فنی سیاست، مانند تنظیمات Fine-Grained Password Policy در AD؛
• گزارش ثبت‌نام و استفاده از MFA؛
• سوابق Access Review؛
• فهرست حساب‌های Privileged همراه با مالک مشخص؛
• گزارش چرخش Credentialهای حساب‌های سرویس و API Keyها؛
• سوابق Offboarding با زمان تکمیل مشخص.

اگر یک کنترل Log نشده و قابل Export نباشد، اثبات اجرای آن در ممیزی بسیار دشوار خواهد بود.

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

پنج گام برای انطباق Credentialها با NIS2

گام اول: همه Credentialها را شناسایی کنید

تمام موارد موجود را فهرست کنید:

• حساب‌های اشتراکی؛
• حساب‌های سرویس؛
• API Keyها؛
• Certificateها؛
• رمزهای پایگاه داده؛
• اطلاعات ذخیره‌شده در Spreadsheetها؛
• Credentialهای موجود در ایمیل؛
• فایل‌های .env و سایر فایل‌های پیکربندی.

این فهرست، Baseline امنیتی شما و یکی از نخستین مدارک قابل ارائه در ممیزی خواهد بود.

گام دوم: یک Credential Vault متمرکز راه‌اندازی کنید

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

• رمزنگاری AES-256؛
• RBAC؛
• اتصال Active Directory/LDAP؛
• Audit Logging؛
• مدیریت Secrets؛
• کنترل متمرکز دسترسی.

ساختار Vault را تا حد امکان مطابق ساختار سازمانی خود طراحی کنید.

برای سازمان‌هایی که سیاست‌های داخلی اجازه ذخیره Credentialها در سرویس‌های ابری شخص ثالث را نمی‌دهد، استقرار Self-Hosted می‌تواند گزینه مناسبی برای حفظ حاکمیت داده و کنترل بیشتر روی زیرساخت باشد.

Passwork یکی از نمونه‌های چنین راهکارهایی است که با قابلیت‌هایی مانند Self-Hosted Deployment، رمزنگاری AES-256، RBAC و اتصال AD/LDAP ارائه می‌شود.

گام سوم: MFA و اصل حداقل دسترسی را اعمال کنید

MFA را از همان ابتدا برای دسترسی به Vault فعال کنید.

مجوزها را بر اساس نقش‌های سازمانی تعیین کنید و اصل Least Privilege را اجرا کنید.

هر کاربر و حساب سرویس باید فقط به منابعی دسترسی داشته باشد که برای انجام وظیفه خود به آن نیاز دارد.

همچنین ماتریس نقش‌ها و مجوزها را مستند کنید. این مستند می‌تواند بخشی از شواهد کنترل دسترسی موردنیاز برای ماده ۲۱(۲)(ی) NIS2 باشد.

گام چهارم: Secrets مدیریت‌نشده را به Vault منتقل کنید

API Keyها، Credentialهای پایگاه داده، Certificateها و رمزهای حساب‌های سرویس را به سیستم متمرکز منتقل کنید.

فایل‌های .env و Spreadsheetهای حاوی رمز عبور را از چرخه عملیاتی خارج کنید.

در صورت امکان، سیاست‌های Credential Rotation را نیز فعال کنید.

گام پنجم: Audit Logging و بازبینی‌های دوره‌ای را فعال کنید

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

سپس Access Reviewهای دوره‌ای، برای مثال هر سه ماه یک‌بار، انجام دهید و موارد زیر را بررسی کنید:

• حساب‌های غیرفعال؛
• نقش‌های دارای دسترسی بیش از حد؛
• Credentialهایی که بیش از ۹۰ روز استفاده نشده‌اند؛
• حساب‌های Privileged؛
• استثناهای MFA؛
• حساب‌های سرویس بدون مالک مشخص.

هر دوره بررسی باید یک مدرک تاریخ‌دار و قابل ارائه تولید کند؛ دقیقاً همان چیزی که برای اثبات اجرای مداوم کنترل‌ها در فرایند نظارت NIS2 اهمیت دارد.

از کجا شروع کنیم؟

سازمان‌هایی که بیشترین مشکل را در ممیزی NIS2 خواهند داشت، الزاماً سازمان‌هایی نیستند که امنیت کاملی ندارند.

مشکل اصلی سازمان‌هایی است که نمی‌توانند ثابت کنند کنترل‌های امنیتی آن‌ها واقعاً اجرا می‌شوند.

مسیرهای دشوارتر NIS2 مانند مدیریت ریسک زنجیره تأمین، پاسخ به رخدادهای امنیتی و حاکمیت در سطح هیئت‌مدیره باید هم‌زمان دنبال شوند.

اما مدیریت Credential و کنترل دسترسی یکی از بهترین نقاط شروع برای ایجاد یک موفقیت سریع و قابل اثبات است.

برنامه عملی ۳۰ روزه

برای شروع، روی این چهار اقدام تمرکز کنید:

1. حساب‌های سرویس را تحت مدیریت قرار دهید.
2. تمام حساب‌های غیرفعال و دسترسی‌های باقی‌مانده از Offboarding را حذف کنید.
3. MFA مقاوم در برابر فیشینگ را برای دسترسی‌های Privileged و Remote فعال کنید.
4. زیرساخت Audit Logging را ایجاد کنید تا کنترل‌های امنیتی به شواهد قابل Export تبدیل شوند.

این اقدامات می‌توانند در کمتر از ۳۰ روز به مرحله عملیاتی برسند و بخش مهمی از ریسک مرتبط با Credentialها را کاهش دهند.

Passwork و انطباق با NIS2

Passwork یک Password & Secrets Manager خودمیزبان برای محیط‌های سازمانی است که قابلیت‌هایی مانند:

• رمزنگاری AES-256؛
• RBAC؛
• اتصال Active Directory/LDAP؛
• مدیریت متمرکز Password و Secret؛
• Audit Log قابل Export؛
• و کنترل متمرکز دسترسی

را ارائه می‌دهد.

برای سازمان‌هایی که به دنبال ایجاد کنترل‌های قابل اثبات در حوزه مدیریت رمز عبور، Secrets، هویت و دسترسی هستند، این قابلیت‌ها می‌توانند بخشی از مسیر آماده‌سازی برای ممیزی NIS2 باشند.

جمع‌بندی

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

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

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

این رویکرد نه‌تنها سطح امنیت سازمان را افزایش می‌دهد، بلکه به شما کمک می‌کند در زمان ممیزی NIS2 به جای توضیح دادن اینکه «چه کاری انجام داده‌ایم»، بتوانید مدرک اجرای آن را ارائه کنید.