امنیت دسترسی به درگاه پرداخت و حفاظت از API Key چگونه تأمین می‌شود؟

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

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

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

امنیت دسترسی به درگاه پرداخت چه بخش‌هایی دارد؟

دسترسی به درگاه را می‌توان در سه لایه اصلی دید:

• دسترسی سرویس‌ها: اطلاعاتی مانند API Key، Token یا دیگر موارد محرمانه‌ای که Backend کسب‌وکار برای ارتباط با API درگاه استفاده می‌کند.
• دسترسی کارکنان: حساب‌هایی که افراد برای مشاهده تراکنش‌ها، گزارش‌ها یا انجام عملیات مجاز در پنل در اختیار دارند.
• کنترل مبدأ و جریان درخواست: تنظیماتی مانند IPهای مجاز، Callback و Referrer که مشخص می‌کنند درخواست از کجا ارسال شود و جریان پرداخت در چه دامنه و مسیری انجام گیرد.

این کنترل‌ها جایگزین یکدیگر نیستند. امن‌نگه‌داشتن API Key، نیاز به مدیریت دسترسی کاربران را از میان نمی‌برد و ثبت IPهای مجاز هم به این معنی نیست که Secretها دیگر نیازی به محافظت ندارند. امنیت زمانی معنی پیدا می‌کند که این لایه‌ها در کنار هم مدیریت شوند.

API Key در درگاه پرداخت چه نقشی دارد؟

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

API Key با حساب کاربری کارکنان تفاوت دارد. OWASP نیز API Key را برای احراز هویت کلاینت API در نظر می‌گیرد و توصیه می‌کند از آن به‌عنوان جایگزین احراز هویت کاربران انسانی استفاده نشود.

این تفاوت مهم است؛ چون امنیت درگاه دو سؤال جدا دارد:

• کدام سرویس اجازه فراخوانی API را دارد؟
• کدام فرد اجازه مشاهده یا تغییر اطلاعات و تنظیمات را دارد؟

داشتن پاسخ مناسب برای یکی، مسئله دیگری را حل نمی‌کند.

اگر API Key افشا شود چه اتفاقی می‌افتد؟

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

بنابراین هنگام طراحی دسترسی فقط نباید پرسید API Key را کجا نگه داریم. این سؤال‌ها هم اهمیت دارند:

• کدام سرویس به آن نیاز دارد؟
• چه افراد یا سیستم‌هایی امکان مشاهده آن را دارند؟
• آیا Credential محیط عملیاتی از محیط تست جداست؟
• درصورت افشا چگونه می‌توان دسترسی آن را لغو کرد؟
• وابستگی کدام سرویس‌ها باید هنگام تغییر Key در نظر گرفته شود؟

این همان جایی است که مدیریت Secret از «مخفی نگه‌داشتن یک رشته متن» فراتر می‌رود.

API Key درگاه پرداخت را کجا نباید نگهداری کرد؟

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

در کد Front-end

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

داخل سورس‌کد و Repository

Hard-codeکردن API Key داخل سورس‌کد نیز ریسک افشا را افزایش می‌دهد. حتی اگر Repository خصوصی باشد، افراد بیشتری ممکن است در طول زمان به کد دسترسی پیدا کنند. از طرف دیگر، حذف Key از نسخه فعلی کد الزاماً آن را از تاریخچه Commitها پاک نمی‌کند.

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

داخل Log

ثبت Request یا Error برای عیب‌یابی ضروری است، اما Log نباید به آرشیوی از موارد محرمانه قابل استفاده تبدیل شود.

API Key، Token و سایر Secretها باید هنگام Logging حذف یا Mask شوند. OWASP نیز توصیه می‌کند Secretها به‌صورت Plain Text در Log ذخیره نشوند.

در پیام‌رسان، ایمیل یا تیکت

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

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

اصول امنیت API Key درگاه پرداخت

برای حفاظت از API Key باید چرخه کامل آن، از ایجاد و استفاده تا لغو دسترسی، در نظر گرفته شود:

دسترسی را فقط به سرویس‌های ضروری بدهید

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

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

محیط تست و عملیاتی را جدا نگه دارید

موارد محرمانه عملیاتی نباید بدون ضرورت در محیط Development یا Test استفاده شود. جداسازی موارد محرمانه محیط‌ها باعث می‌شود مشکل امنیتی در یک محیط، مستقیماً دسترسی به محیط Production ایجاد نکند.

برای Rotation و Revocation آماده باشید

هیچ مورد محرمانه‌ای نباید به چیزی تبدیل شود که همه می‌ترسند تغییرش دهند چون «معلوم نیست کجاها استفاده شده». Rotation یعنی موارد محرمانه موجود با مقدار جدید جایگزین شود و Revocation یعنی دسترسی موارد محرمانه قبلی لغو شود.

OWASP نیز Creation، Rotation، Revocation و Expiration را بخش‌هایی از چرخه مدیریت Secret می‌داند و بر امکان لغو سریع Secretهای مشکوک یا افشاشده تأکید می‌کند.

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

اصل Least Privilege چیست؟

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

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

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

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

RBAC چگونه به مدیریت سطح دسترسی کارکنان کمک می‌کند؟

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

یکی از روش‌های مدیریت این مسئله، Role-Based Access Control یا RBAC است.

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

برای نمونه، یک الگوی دسترسی می‌تواند چنین باشد:

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

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

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

چرا نباید اطلاعات ورود پنل را میان کارکنان مشترک کرد؟

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

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

در ساختارهای چندکاربره، حساب اختصاصی برای هر فرد انتخاب امن‌تری است؛ چون امکان تعیین سطح دسترسی، لغو مستقل دسترسی و ردیابی فعالیت‌ها را حفظ می‌کند.

دسترسی کارکنان باید همراه با نقش آن‌ها تغییر کند

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

هنگام ورود به تیم

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

هنگام تغییر نقش

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

در بازبینی‌های دوره‌ای

فهرست کاربران و Permissionهای حساس باید دوره‌ای بررسی شود:

• آیا تمام حساب‌های فعال هنوز موردنیازند؟
• سطح دسترسی هر فرد با وظیفه فعلی او مطابقت دارد؟
• حساب بلااستفاده وجود دارد؟
• مجوز قدیمی یا غیرضروری باقی مانده است؟

NIST، مؤسسه ملی استانداردها و فناوری امریکا، نیز در کنترل Least Privilege بر بازبینی دوره‌ای مجوزهای تخصیص‌یافته و حذف یا تغییر دسترسی‌های غیرضروری تأکید می‌کند.

هنگام قطع همکاری

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

• حساب پنل
• Sessionهای فعال
• Repositoryهای مرتبط
• سیستم‌های CI/CD
• Secret Manager یا فایل‌های تنظیمات
• Credentialهای مشترک
• دسترسی‌های زیرساختی مرتبط

اگر فرد امکان مشاهده یک Secret مشترک را داشته است، ممکن است صرفاً حذف حساب او کافی نباشد و لازم باشد Credential مربوط نیز Rotate شود.

IPهای مجاز چه نقشی در امنیت درگاه پرداخت دارند؟

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

این کنترل مکمل امنیت محرمانگی است:

• API Key یا Credential مجوز سرویس برای فراخوانی API را مشخص می‌کند؛
• Permission یا مجوز مشخص می‌کند چه عملیاتی مجاز است؛
• IP مجاز مبدأ قابل قبول برای درخواست را محدود می‌کند.

اگر زیرساخت کسب‌وکار، سرور یا IP خروجی تغییر کند، فهرست IPهای ثبت‌شده نیز باید بررسی و درصورت نیاز به‌روزرسانی شود. برای جزئیات این فرایند می‌توانید راهنمای شناسایی IP خروجی برای درگاه پرداخت را بخوانید.

Callback و Referrer را هم بعد از تغییر زیرساخت بررسی کنید

کنترل Callback و Referrer مسئله‌ای متفاوت از API Key و سطح دسترسی کاربران است، اما بخشی از تنظیم صحیح جریان پرداخت محسوب می‌شود.

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

بنابراین تغییر دامنه یا بخشی از زیرساخت پرداخت فقط یک تغییر فنی داخلی نیست و ممکن است به بازبینی تنظیمات ترمینال نیز نیاز داشته باشد.

جزئیات بیشتر این موضوع در مطلب Callback و Referrer درگاه پرداخت قابل بررسی است.

Log و Audit Trail چه کمکی به امنیت دسترسی می‌کنند؟

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

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

OWASP ثبت رویدادهایی مانند تغییر دسترسی کاربران، فعالیت‌های مدیریتی و تغییرات امنیتی را از موارد مهم Logging می‌داند؛ اما یک مرز مهم وجود دارد: رخداد را ثبت کنید، نه خود Secret را. وجود API Key یا Token کامل در Log، به‌جای کمک به امنیت، یک مسیر تازه برای افشای موارد محرمانه ایجاد می‌کند.

اگر API Key درگاه افشا شد چه باید کرد؟

اگر احتمال می‌دهید موارد محرمانه مرتبط با درگاه در Repository، Log، دستگاه کاربر یا محیط دیگری افشا شده است، بهتر است آن را صرفاً یک «احتمال» بی‌اهمیت تلقی نکنید.

چهار اقدام اصلی باید در اولویت باشند:

۱. دسترسی Credential مشکوک را متوقف کنید

درصورت امکان، موارد محرمانه افشاشده را Revocation کنید و موارد جدیدی جایگزین آن کنید. OWASP نیز در واکنش به افشای Secret، لغو سریع Key افشاشده و Rotation آن را از اقدامات اصلی مهار رخداد می‌داند.

۲. فعالیت‌های مرتبط را بررسی کنید

Logها و دیگر اطلاعات در دسترس را بررسی کنید تا مشخص شود آیا استفاده غیرعادی یا درخواست مشکوکی مبتنی بر موارد محرمانه انجام شده است.

۳. منبع افشا را پیدا کنید

اگر Key در سورس‌کد، CI/CD، فایل تنظیمات، Log یا ابزار ارتباطی قرار داشته، فقط تعویض آن کافی نیست. محل افشا باید اصلاح شود تا موارد محرمانه جدید دوباره از همان مسیر در دسترس قرار نگیرد.

۴. دامنه دسترسی را دوباره ارزیابی کنید

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

امنیت درگاه فقط مسئولیت ارائه‌دهنده سرویس نیست

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

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

این تقسیم مسئولیت به‌این معنی است که حتی یک زیرساخت امن نیز نمی‌تواند اثر API Key منتشرشده در Repository عمومی یا حساب مشترکی را که میان چند نفر دست‌به‌دست می‌شود از بین ببرد.

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

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

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

• API Key و Secretهای درگاه در Front-end قرار نگرفته‌اند.
• موارد محرمانه و حساس داخل سورس‌کد Hard-code نشده‌اند.
• API Key و Token کامل در Log ذخیره نمی‌شوند.
• محیط‌های Test و Production از موارد محرمانه جدا استفاده می‌کنند.
• فقط سرویس‌ها و افرادی که واقعاً نیاز دارند به Secret دسترسی دارند.
• وابستگی موارد محرمانه مشخص است و فرایند Rotation و Revocation برای آن‌ها وجود دارد.
• کاربران پنل تا حد امکان حساب اختصاصی دارند.
• سطح دسترسی هر فرد براساس وظیفه او تعریف شده است.
• مجوزها بعد از تغییر مسئولیت کارکنان بازبینی می‌شوند.
• حساب‌های بلااستفاده و دسترسی‌های قدیمی دوره‌ای بررسی می‌شوند.
• بعد از قطع همکاری، تمام دسترسی‌های مرتبط فرد بررسی و لغو می‌شوند.
• درصورت دسترسی فرد به Secret مشترک، نیاز به Rotation آن بررسی می‌شود.
• IPهای مجاز درگاه با زیرساخت فعلی کسب‌وکار مطابقت دارند.
• بعد از تغییر دامنه یا زیرساخت، Callback و Referrer نیز بررسی می‌شوند.
• فعالیت‌ها و تغییرات حساس، درصورت فراهم‌بودن قابلیت فنی، قابل ردیابی هستند.
• برای افشای موارد محرمانه یا دسترسی غیرمجاز، فرایند مشخصی برای واکنش وجود دارد.

امنیت درگاه پرداخت از کنترل دسترسی شروع می‌شود

امنیت API درگاه پرداخت با یک کنترل واحد تأمین نمی‌شود. نگهداری درست API Key، تعیین سطح دسترسی کارکنان، محدودکردن دسترسی‌ها و مجوزها، بررسی IPهای مجاز و لغو دسترسی‌های قدیمی هرکدام فقط بخشی از مسئله را پوشش می‌دهند.

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

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