الزامات امنیتی پذیرندگان درگاه اینترنتی چیست؟

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

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

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

این راهنما از همین نقطه شروع می‌کند: رخداد اتفاق افتاده یا نشانه‌ای جدی از آن دیده شده است؛ حالا چه باید کرد؟

رخداد امنیتی در سایت پذیرنده چه شکل‌هایی دارد؟

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

زمانی احتمال یک رخداد امنیتی جدی‌تر می‌شود که نشانه‌ای از دسترسی، تغییر یا رفتار غیرمجاز دیده شود؛ برای مثال:

• ورود غیرمجاز به پنل مدیریت، هاست یا سرور
• تغییر فایل‌ها، کد یا تنظیمات سایت بدون اطلاع تیم
• مشاهده رفتار غیرعادی در صفحه Checkout، مسیر انتقال به درگاه یا Callback
• افشای رمز عبور، کلید API یا سایر اطلاعات دسترسی

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

اگر سایت هک شد، در ساعات اولیه چه کار کنیم؟

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

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

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

۱. مشخص کنید کدام بخش‌ها درگیر شده‌اند

اولین قدم این نیست که دقیقاً بدانید مهاجم چه کسی بوده یا حمله چگونه انجام شده است. ابتدا باید بفهمید دامنه احتمالی مشکل چقدر است.

این سؤال‌ها می‌توانند بررسی اولیه را جهت دهند:

• اولین رفتار مشکوک چه زمانی دیده شد؟
• کدام صفحه، حساب یا سرویس تحت‌تأثیر قرار گرفته است؟
• آیا تغییری در فایل‌ها یا تنظیمات سایت دیده می‌شود؟
• آیا دسترسی مدیریتی غیرعادی ثبت شده است؟
• آیا Checkout ،Callback یا مسیر انتقال به درگاه تغییر کرده است؟
• آیا رمز، کلید API یا اطلاعات دسترسی دیگری ممکن است افشا شده باشد؟

اگر یک حساب یا بخش مشخص مشکوک است، دسترسی آن را محدود کنید تا بررسی ادامه پیدا کند.

لازم نیست در هر رخداد کل سایت فوراً از دسترس خارج شود. تصمیم به محدودکردن یک بخش یا توقف کامل سرویس باید متناسب با دامنه مشکل باشد.

۲. اگر سلامت مسیر پرداخت مشخص نیست، دریافت وجه را ادامه ندهید

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

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

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

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

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

در حملات تجارت الکترونیکی حتی اسکریپت‌های موجود در صفحات مرتبط با پرداخت می‌توانند هدف دست‌کاری قرار بگیرند. PCI SSC در راهنمای امنیت صفحات پرداخت، کنترل تغییرات غیرمجاز در اسکریپت‌ها و پایش آن‌ها را از اقدامات مهم در کاهش ریسک حملات E-skimming می‌داند.

۳. رخداد را به ارائه‌کننده خدمات پرداخت اطلاع دهید

رخداد امنیتی یک پذیرنده دارای درگاه پرداخت فقط موضوعی برای تیم فنی یا شرکت هاستینگ نیست.

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

در گزارش اولیه بهتر است حداقل این اطلاعات آماده باشند:

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

در مراحل اولیه ممکن است هنوز پاسخ همه سؤال‌ها مشخص نباشد. همین موضوع نباید باعث تأخیر در اطلاع‌رسانی شود.

۴. لاگ‌ها و شواهد را پیش از پاک‌سازی حفظ کنید

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

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

• لاگ‌های سایت و سرور
• سابقه ورود به حساب‌های مدیریتی
• تغییرات فایل‌ها و تنظیمات
• درخواست‌های غیرعادی ثبت‌شده در API
• لاگ‌های مرتبط با Checkout و Callback
• زمان ایجاد یا تغییر حساب‌های کاربری مشکوک

هدف این نیست که سرویس آلوده همچنان فعال بماند. می‌توان رخداد را مهار کرد و در عین حال اطلاعات لازم برای بررسی آن را حفظ کرد.

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

۵. دسترسی‌هایی را که ممکن است افشا شده باشند کنترل کنید

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

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

• حساب‌های مدیریتی سایت
• دسترسی هاست یا سرور
• رمز دیتابیس
• کلیدهای API
• توکن یا کلید سرویس‌های متصل
• حساب‌های ایمیل مدیریتی

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

۶. علت نفوذ را پیدا کنید؛ فقط نشانه آن را پاک نکنید

فرض کنید تیم فنی یک فایل مخرب را پیدا و حذف می‌کند و سایت دوباره بدون مشکل بالا می‌آید. هنوز یک سؤال اصلی باقی مانده است:

آن فایل چگونه وارد سیستم شد؟

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

علت می‌تواند یکی از این موارد باشد:

• نرم‌افزار، افزونه یا کتابخانه آسیب‌پذیر
• رمز یا اطلاعات دسترسی افشاشده
• پیکربندی نادرست سرور یا سرویس
• ضعف امنیتی در کد یا یکی از سرویس‌های متصل

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

۷. سایت و مسیر پرداخت را از یک وضعیت قابل اعتماد بازیابی کنید

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

پیش از بازگشت کامل سرویس بررسی کنید:

• مسیر نفوذ برطرف شده باشد
• حساب‌ها یا دسترسی‌های غیرمجاز حذف شده باشند
• اطلاعات دسترسی افشاشده تغییر کرده باشند
• فایل‌ها و تنظیمات اصلی سایت در وضعیت موردانتظار باشند
• Checkout و مسیر انتقال به درگاه درست کار کنند
• بررسی Callback و ثبت نتیجه تراکنش به‌درستی انجام شوند

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

برای بررسی درست‌بودن آدرس بازگشت، دامنه‌های مرتبط و مسیر رفت‌وبرگشت پرداخت، می‌توانید از راهنمای بررسی Callback و Referrer استفاده کنید.

چه زمانی می‌توان پرداخت اینترنتی را دوباره فعال کرد؟

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

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

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

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

اگر اطلاعات کاربران تحت‌تأثیر قرار گرفته باشد چه باید کرد؟

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

در این حالت باید مشخص شود:

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

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

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

در صورت افشای اطلاعات مالی، آگاهی کاربران از روش‌های حفاظت از اطلاعات مالی و داده‌های بانکی می‌تواند به کاهش ریسک سوءاستفاده‌های بعدی کمک کند.

بعد از رفع رخداد، چه چیزی باید تغییر کند؟

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

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

این نگاه یکی از پایه‌های مدیریت پاسخ به رخداد است: تجربه هر حادثه باید آمادگی برای حادثه بعدی را بهتر کند. NIST نیز در نسخه سوم SP 800-61 پاسخ به رخداد را بخشی از مدیریت مستمر ریسک سایبری در سازمان در نظر می‌گیرد.

چگونه برای یک رخداد امنیتی آماده باشیم؟

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

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

برای یک پذیرنده اینترنتی، حداقل این موارد باید از قبل مشخص باشند:

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

این موارد یک سایت را دربرابر تمام حملات مصون نمی‌کنند؛ چنین تضمینی عملاً وجود ندارد؛ اما می‌توانند باعث شوند فاصله میان «مشاهده یک رفتار مشکوک» و «کنترل‌کردن وضعیت» بسیار کوتاه‌تر شود تا امنیت اطلاعات مالی کسب‌وکار تأمین شود.

چک‌لیست پاسخ به رخداد امنیتی برای پذیرندگان اینترنتی

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

مرحله	اقدام
شناسایی	زمان و نشانه اولیه رخداد ثبت شده است
ارزیابی	بخش‌های احتمالی درگیر مشخص شده‌اند
مهار	دسترسی یا بخش مشکوک محدود شده است
پرداخت	سلامت مسیر پرداخت بررسی یا دریافت وجه موقتاً متوقف شده است
اطلاع‌رسانی	ارائه‌دهنده خدمات پرداخت از رخداد مطلع شده است
شواهد	لاگ‌ها و اطلاعات لازم برای بررسی حفظ شده‌اند
دسترسی	رمزها، کلیدها یا دسترسی‌های در معرض خطر کنترل شده‌اند
ریشه‌یابی	علت اصلی رخداد مشخص شده است
اصلاح	مسیر نفوذ و مؤلفه آسیب‌پذیر برطرف شده‌اند
بازیابی	سایت از یک وضعیت سالم بازیابی شده است
پرداخت	Checkout، Callback و مسیر پرداخت آزمایش شده‌اند
بازگشت سرویس	در صورت نیاز، هماهنگی لازم برای فعال‌شدن ابزار پذیرش انجام شده است
بازنگری	اقدام لازم برای جلوگیری از تکرار رخداد مشخص شده است

امنیت سایت بخشی از فرایند پذیرندگی است

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

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

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