گواهی بومی مشکل اتصال اینترنت‌بانک‌ها را حل نمی‌کند؛ نظام پرداخت و بانکی در معرض خطر است
عضو هیئت‌مدیره انجمن تحول دیجیتال ایران، با اشاره به تلاش‌ها برای استفاده از گواهی‌های بومی در اتصال بانک‌ها، گفت: گواهی بومی از سوی مرورگرهای استاندارد بین‌المللی معتبر شناخته نمی‌شود و استفاده از این روش نه‌تنها مشکل اینترنت‌بانک‌ها را برطرف نمی‌کند، بلکه می‌تواند احتمال فیشینگ را نیز افزایش دهد.
علیرضا بزرگمهری، عضو هیئت‌مدیره انجمن تحول دیجیتال ایران، در گفت‌وگو با خبرنگار سیتنا، درباره آخرین وضعیت اتصال بانک‌ها و استفاده از گواهی‌های بومی برای رفع اختلال در خدمات بانکی، گفت: اساساً حل این مشکل از طریق جایگزینی گواهی‌های بومی با گواهی‌های مورد تأیید مرورگرهای بین‌المللی امکان‌پذیر نیست.
وی با اشاره به نحوه اعتبارسنجی گواهی‌های امنیتی در مرورگرها، افزود: وقتی گواهی یک وب‌سایت باطل می‌شود، مرورگر آن را نامعتبر اعلام می‌کند؛ از سوی دیگر، اگر گواهی بومی نیز جایگزین شود، مرورگرهای استاندارد بین‌المللی این گواهی را نمی‌شناسند و باز هم آن را معتبر تلقی نمی‌کنند.
بزرگمهری با بیان اینکه این روش مشکل اصلی را برطرف نمی‌کند، اظهار کرد: این راهکارهایی است که دوستان ارائه می‌دهند، اما به این موضوع توجه نشده که با چنین روشی مشکل همچنان سر جای خود باقی می‌ماند و حتی احتمال فیشینگ نیز به‌شدت افزایش پیدا می‌کند.
عضو هیئت‌مدیره انجمن تحول دیجیتال ایران ادامه داد: در شرایط فعلی، کل نظام پرداخت و بانکی کشور در معرض خطر قرار دارد و با این روش نمی‌توان مشکل اتصال خدمات بانکی را به‌صورت اساسی حل کرد.
وی درباره امکان استفاده از گواهی‌های بومی در اپلیکیشن‌های بانکی نیز توضیح داد: در اپلیکیشن‌های موبایلی که نیازی به مرورگر ندارند، امکان استفاده از گواهی بومی وجود دارد؛ چراکه در این محیط می‌توان نحوه اعتبارسنجی گواهی را در خود اپلیکیشن مدیریت کرد.
بزرگمهری تأکید کرد: اما در وب، موضوع متفاوت است؛ چراکه اینجا مرورگر گواهی را بررسی می‌کند و اعتبار آن باید از طریق زنجیره ریشه‌های مورد اعتماد مرورگر تأیید شود.
وی خاطرنشان کرد: مرکز ریشه داخلی ما از سوی مرورگرهای بین‌المللی مورد اعتماد نیست و گواهی‌هایی که از این مرکز صادر می‌شوند، در مرورگرهای استاندارد بین‌المللی اعتبار لازم را ندارند.
عضو هیئت‌مدیره انجمن تحول دیجیتال ایران در پاسخ به این پرسش که آیا استفاده از گواهی‌های بومی می‌تواند اختلال موجود در موبایل‌بانک‌ها را برطرف کند، گفت: برای موبایل‌بانک‌ها، به دلیل اینکه اپلیکیشن هستند، امکان استفاده از این گواهی‌ها وجود دارد و می‌توان اختلال مربوط به آن بخش را برطرف کرد؛ اما مشکل اینترنت‌بانک‌ها همچنان باقی خواهد ماند.
بزرگمهری افزود: در اپلیکیشن می‌توان گواهی را به شکلی تعریف کرد که مورد پذیرش قرار گیرد، اما مرورگر استاندارد بین‌المللی، مرکز ریشه داخلی را به‌عنوان یک مرجع معتبر نمی‌شناسد.
وی تأکید کرد: بنابراین اگر امروز گواهی فعلی باطل شود و فردا گواهی دیگری از یک مرجع دیگر دریافت شود، تا زمانی که آن مرجع از سوی مرورگرهای استاندارد مورد اعتماد نباشد، مشکل اینترنت‌بانک‌ها با تغییر گواهی حل نخواهد شد.
دیدگاه‌ها
این موضوع باید در لایه‌های مختلف و کاملاً تفکیک‌شده بررسی شود:
۱. لایه هویت و اعتماد — PKI
در این لایه، CA، Root CA، Intermediate CA، گواهی دیجیتال، زنجیره اعتماد و سیاست‌های اعتبارسنجی مطرح هستند. صرف صدور یک گواهی جدید، بدون وجود زنجیره اعتماد مورد پذیرش کلاینت، مشکل اعتبارسنجی را حل نمی‌کند. «بومی‌بودن» گواهی به‌تنهایی معیار Trusted بودن آن برای کلاینت نیست.
۲. لایه ارتباط امن — TLS/HTTPS
در HTTPS، کلاینت باید گواهی را از نظر نام دامنه، اعتبار زمانی، زنجیره گواهی و وضعیت اعتماد مرجع صدور بررسی کند. TLS مسئول فراهم‌کردن ارتباط امن و سازوکارهای رمزنگاری و احراز اصالت ارتباط است. بنابراین صرف تعویض یک گواهی با گواهی دیگر، بدون فراهم‌بودن زنجیره اعتماد مناسب، راهکار رفع مشکل اعتبارسنجی نیست.
۳. لایه مرورگر و کلاینت — Trust Store
اعتبار گواهی در سمت کاربر به زنجیره اعتماد و Trust Store سیستم‌عامل، مرورگر یا محیط اجرایی بستگی دارد. اگر Root CA مربوطه در محیط مورد استفاده کاربر Trusted نباشد، صرف صدور گواهی جدید باعث نمی‌شود مرورگر عمومی آن را معتبر تلقی کند. سیاست‌های اعتماد مرورگرها و سیستم‌عامل‌ها نیز باید به‌صورت مستقل بررسی شوند.
۴. لایه DNS و نام دامنه
ارتباط صحیح میان نام دامنه، DNS و سرویس HTTPS بخش مهمی از معماری سرویس است. DNSSEC نیز در حوزه اصالت و تمامیت داده‌های DNS مطرح می‌شود و نباید با PKI یا TLS یکی تلقی شود. بنابراین در عیب‌یابی باید مشخص شود اختلال واقعاً در DNS، دسترسی شبکه، مسیریابی، TLS، گواهی یا لایه دیگری قرار دارد.
۵. لایه کاربرد — اینترنت‌بانک و وب
امنیت اینترنت‌بانک صرفاً به گواهی محدود نیست. احراز هویت، مدیریت نشست، کنترل دسترسی، HSTS، سیاست‌های امنیتی مرورگر، حفاظت در برابر جعل و فیشینگ و سایر کنترل‌های امنیتی باید در معماری سرویس بررسی شوند. تغییر گواهی، بدون شناسایی و رفع علت اصلی اختلال، راهکار ریشه‌ای محسوب نمی‌شود.
۶. لایه اپلیکیشن موبایل
این لایه با وب تفاوت اساسی دارد. یک اپلیکیشن می‌تواند در چارچوب معماری و پلتفرم خود، سیاست اعتماد و اعتبارسنجی گواهی را مدیریت کند. بنابراین امکان استفاده از CA داخلی یا خصوصی در یک اپلیکیشن به این معنا نیست که همان CA در مرورگرهای عمومی نیز Trusted خواهد بود. این دو محیط نباید با یکدیگر خلط شوند.
۷. لایه شبکه و مسیریابی — IP/BGP
در این لایه موضوعاتی مانند BGP، Route Leak، Route Hijacking و امنیت مسیریابی مطرح هستند. در این حوزه چارچوب‌هایی مانند MANRS (Mutually Agreed Norms for Routing Security) مرتبط‌اند. MANRS جایگزین PKI یا TLS نیست؛ بلکه بر اصول و اقدامات مرتبط با بهبود امنیت و تاب‌آوری مسیریابی اینترنت تمرکز دارد.
۸. لایه تبادل ترافیک — IXP
IXP یا Internet Exchange Point مربوط به تبادل ترافیک میان شبکه‌ها و اپراتورهاست. معماری، سیاست‌های Peering، کنترل‌های امنیتی و تاب‌آوری IXP اهمیت دارند؛ اما IXP نیز جایگزین CA، PKI، TLS یا Trust Store مرورگر نیست. این موضوع باید در لایه مربوط به زیرساخت تبادل ترافیک بررسی شود.
بنابراین نمی‌توان مسئله‌ای با این ابعاد را با گزاره ساده «گواهی فعلی باطل شود و گواهی بومی دیگری جایگزین شود» حل‌شده تلقی کرد. اگر مشکل در زنجیره اعتماد یا Trust Store باشد، صدور گواهی جدید از مرجعی که کلاینت آن را Trusted نمی‌داند، مشکل اعتماد مرورگر را برطرف نخواهد کرد.
اشتباه اصلی دقیقاً از جایی آغاز می‌شود که لایه‌های متفاوت فناوری با یکدیگر خلط شوند و برای مسئله‌ای در یک لایه، راهکاری از لایه‌ای دیگر ارائه شود. PKI و CA در لایه هویت و اعتماد قرار دارند؛ TLS/HTTPS در لایه ارتباط امن؛ Trust Store در لایه اعتماد کلاینت؛ DNS/DNSSEC در لایه نام و زیرساخت DNS؛ BGP و اصول MANRS در لایه مسیریابی؛ و IXP در لایه تبادل ترافیک.
از این رو، اگر قرار است درباره امنیت اینترنت‌بانک و زیرساخت پرداخت راهکار ارائه شود، ابتدا باید علت واقعی اختلال، محل وقوع آن، مدل تهدید، معماری سرویس، زنجیره اعتماد، مسیر ارتباطی و کنترل‌های امنیتی هر لایه مشخص و سپس راهکار متناسب با همان لایه ارائه شود.
مطرح‌کردن و انتشار مکرر راهکارهای فنی بدون چنین تحلیل چندلایه‌ای، صرفاً یک اختلاف‌نظر فنی نیست؛ می‌تواند موجب تصمیم‌گیری نادرست، اتلاف منابع و ایجاد تصور امنیتی کاذب در کاربران شود. چنین پیشنهادهایی باید پیش از طرح عمومی، توسط متخصصان حوزه‌های مربوطه بررسی، آزمایش، اعتبارسنجی و از نظر پیامدهای امنیتی ارزیابی شوند.
امنیت اینترنت‌بانک و زیرساخت پرداخت محل آزمون‌وخطا نیست. این حوزه نیازمند دانش تخصصی واقعی، تحلیل دقیق علت اختلال، معماری امنیتی لایه‌ای، استانداردهای فنی معتبر، زنجیره اعتماد قابل اعتبارسنجی و کنترل‌های امنیتی قابل آزمون و ممیزی است؛ نه تعویض شتاب‌زده یک گواهی و انتظار برای حل مشکلی که ممکن است اساساً در لایه دیگری قرار داشته باشد.
افزودن دیدگاه جدید