شاخص بانکداری ابری‌بومی در ۲۰۲۶: DORA، مهندسی پلتفرم، ابر مستقل، و تاب‌آوری عملیاتی

شاخص بانکداری ابری‌بومی در �2026: DORA، مهندسی پلتفرم، ابر مستقل، و تاب‌آوری عملیاتی

بانکداری ابری‌بومی در سال ۲۰۲۶ در مرحله‌ی حسابرسی DORA است. مقرره (EU) 2022/2554 ⧉ از ۱۷ ژانویه ۲۰۲۵ لازم‌الاجرا بوده است. رژیم تعیین ارائه‌دهنده‌ی حیاتی شخص ثالث (CTPP) بر اساس مواد ۲۸ تا ۴۴ در طول ۲۰۲۵–۲۰۲۶ در حال گشایش بوده، به‌طوری‌که AWS، Microsoft (Azure)، Google (GCP) و Salesforce درون یا نزدیک به محیط تعیین قرار دارند. مقامات نظارتی اروپایی (EBA، EIOPA، ESMA) نسخه‌ی نهایی RTS و ITS مربوط به رجیستر اطلاعات ⧉ را در سال ۲۰۲۴ منتشر کردند. تیم نظارت بانکی ECB در اولویت‌های نظارتی ۲۰۲۶–۲۸ ⧉ برنامه‌های صریحی درباره‌ی آمادگی در برابر اختلال ابری و آزمون نفوذ مبتنی بر تهدید دارد. پرسش نهادی این نیست که آیا راهبرد ابری باید با DORA هم‌راستا شود یا نه — این موضوع حل شده است — بلکه این است که آیا بنیان‌های مهندسی پلتفرم مؤسسه شواهد را با سرعت خط لوله‌ی استقرار تولید می‌کنند یا در قالب PDFهایی که هفته‌ی پیش از حسابرسی سرِ هم می‌شوند.

خلاصه‌ی اجرایی / نکات کلیدی

• تاب‌آوری ابری DORA از ۱۷ ژانویه ۲۰۲۵ در اجرای فعال است. مواد ۶، ۸، ۱۸، ۲۶ و ۲۸ تا ۴۴ همگی لازم‌الاجرا هستند. یافته‌های نظارتی از نخستین موج حسابرسی در سه‌ماهه‌ی چهارم ۲۰۲۵ به دست آمد. قاب‌بندی «آماده‌سازی» دو چرخه عقب افتاده است.
• رژیم تعیین CTPP در حال گشایش. AWS، Microsoft، Google، Salesforce — درون یا نزدیک. تعیین‌شدن به مقامات نظارتی اروپایی حقوق نظارت مستقیم می‌دهد، از جمله درخواست اطلاعات، بازرسی‌های حضوری و توصیه‌های نظارتی.
• مهندسی پلتفرم همان دستاورد است. جاده‌های هموار Kubernetes (EKS / AKS / GKE / OpenShift)، پرتال توسعه‌دهنده به سبک Backstage، GitOps (ArgoCD یا Flux)، Open Policy Agent در پذیرش، OpenTelemetry سرتاسری. پنج بنیان نام‌برده؛ هر چیز غایب یک یافته است.
• ابر مستقل مهندسی است، نه برندسازی. AWS European Sovereign Cloud، Microsoft EU Data Boundary، Bleu (Capgemini + Orange + Microsoft)، Thales / S3NS، Oracle EU Sovereign Cloud — هرکدام به یک بُعد مشخص از Schrems II + ماده ۲۸ DORA می‌پردازند؛ هیچ‌کدام پاسخی کلید در دست نیست.
• شواهد خروجِ آزموده‌شده الزامی است. بندهای ۸۱ و ۱۱۳ تا ۱۱۷ سند EBA/GL/2019/02. تمرین رومیزی فصلی کافی نیست؛ ناظران برای هر کارکرد حیاتی یا مهم انتظار آزمون سالانه‌ی سرتاسری اجرای خروج را دارند.
• RTO / RPO از فهرست‌برداری CIF. لایه ۱: ۲ ساعت / ۱۵ دقیقه. لایه ۲: ۴ ساعت / ۱ ساعت. لایه ۳: ۲۴ ساعت / ۴ ساعت. مشتق‌شده از تحلیل تأثیر کسب‌وکار، نه از ظرفیت تیم پلتفرم.

چرا تاب‌آوری ابری DORA در مرحله‌ی حسابرسی است

سه دلیل که چرا قاب‌بندی «آماده‌سازی» در سال ۲۰۲۶ نادرست است.

نخست، جدول زمانی. DORA در دسامبر ۲۰۲۲ منتشر شد. دوره‌ی ۲۴ ماهه‌ی اجرا در ۱۷ ژانویه ۲۰۲۵ به پایان رسید. نسخه‌ی نهایی RTS و ITS مقامات نظارتی اروپایی — از جمله ITS مربوط به رجیستر اطلاعات که برای تعیین CTPP به کار می‌رود — در طول ۲۰۲۴ منتشر شد. نخستین موج حسابرسی‌های نظارتی در طول ۲۰۲۵ اجرا شد؛ یافته‌ها درباره‌ی کامل بودن چارچوب مدیریت ریسک ICT در ماده ۶ و تطبیق رجیستر ماده ۸ در سه‌ماهه‌ی چهارم ۲۰۲۵ در چندین مؤسسه‌ی لایه‌یک به دست آمد.

دوم، رژیم تعیین CTPP. ماده ۳۱ معیارهای تعیین به‌عنوان ارائه‌دهنده‌ی حیاتی شخص ثالث را تعیین می‌کند: تأثیر سیستمی در صورت شکست، حیاتی بودن خدمات ارائه‌شده، مقیاس و پیچیدگی خدمات، جایگزین‌پذیری. مقامات نظارتی اروپایی رجیستر را نگهداری و تصمیم‌های تعیین را منتشر می‌کنند. AWS، Microsoft (Azure)، Google (GCP) و Salesforce بسته به سهم بازار خدمات مالی در هر کشور عضو، درون یا نزدیک به محیط تعیین قرار دارند. تعیین‌شدن به ناظر پیشرو (یکی از مقامات نظارتی اروپایی که به‌ازای هر ارائه‌دهنده تخصیص می‌یابد) اختیار نظارت مستقیم می‌دهد: درخواست اطلاعات بر اساس ماده ۳۷، بازرسی‌های حضوری بر اساس ماده ۳۸، توصیه‌ها بر اساس ماده ۳۵، و رژیم افشای عمومی بر اساس ماده ۴۱. بانک‌هایی که بر آن CTPPها نظارت می‌شوند، مشمول انتظارات نظارتی متناظر درباره‌ی نحوه‌ی مدیریت آن وابستگی تعیین‌شده هستند.

سوم، اولویت‌های نظارتی ۲۰۲۶–۲۸ بانک مرکزی اروپا. سند اولویت‌ها دو برنامه‌ی صریح را نام می‌برد که مستقیماً بر بانکداری ابری‌بومی اثر می‌گذارند: آمادگی در برابر اختلال عمده‌ی خدمات ابری (سناریوهای نظارتی مدل‌سازی‌شده توانایی مؤسسه در جذب یک قطعی پایدار از یک CTPP تعیین‌شده را می‌آزمایند) و TLPT هم‌راستا با TIBER-EU (هر تمرین TIBER-EU دامنه‌ی کارکردهای حیاتی و مهم مؤسسه را در بر می‌گیرد که اکنون شامل خدمات میزبانی‌شده روی ابر عمومی است). موج حسابرسی ۲۰۲۶ درباره‌ی هر دو یافته تولید خواهد کرد.

قاب‌بندی برای ۲۰۲۶ «DORA در راه است» نیست؛ بلکه «یافته‌های حسابرسی DORA در حال رسیدن به صندوق پستی مؤسسه‌ی شماست، و تصمیم‌های مهندسی پلتفرمی که در طول ۲۰۲۴–۲۰۲۵ گرفتید همان چیزی است که ناظر در آن یافته‌ها موشکافی می‌کند» است.

معماری شاخص ۲۰۲۶

سیگنال‌های کنونی برای پایش

مهندسی پلتفرم: پنج بنیان نام‌برده

بلوغ ابری‌بومی در سال ۲۰۲۶ به پنج بنیان مهندسی تقلیل می‌یابد که درهم می‌تنند تا شواهد نظارتی را با سرعت خط لوله‌ی استقرار تولید کنند. نبود هر یک از آن‌ها یک یافته‌ی در‌کمین‌نشسته است.

۱. جاده‌های هموار مبتنی بر Kubernetes

هر CIF روی یک پلتفرم مدیریت‌شده‌ی Kubernetes اجرا می‌شود — EKS، AKS، GKE، یا OpenShift روی یک CTPP تعیین‌شده، یا یک جایگزین مدیریت‌شده توسط فروشنده. تیم پلتفرم یک الگوی خوشه‌ی طلایی یگانه با انحراف کنترل‌شده را اداره می‌کند: گره‌ها از یک ایمیج پایه‌ی مستند؛ ایزوله‌سازی فضای‌نام‌به‌ازای‌تیم؛ پروفایل محدودشده‌ی استانداردهای امنیت پاد؛ سیاست‌های شبکه؛ تزریق مِش سرویس (Istio یا Linkerd) برای احراز هویت میان‌سرویسی و رصدپذیری. سرویس‌های جدید از طریق یک گردش‌کار پیوستنِ قالب‌بندی‌شده به جاده‌ی هموار می‌پیوندند که ورودی رجیستر ماده ۸ را همچون یک مصنوع استقرار تولید می‌کند.

۲. پرتال توسعه‌دهنده به سبک Backstage

یک پرتال توسعه‌دهنده‌ی مرکزی — Backstage ⧉ متن‌باز Spotify پیاده‌سازی مرجع است، با انواع جایگزین‌های سازمانی — سامانه‌ی ثبت آنچه در کجا اجرا می‌شود را فراهم می‌کند. کاتالوگ هر سرویس، مالک، وابستگی، طبقه‌بندی حیاتی بودن، دفترچه‌ی اجرا و نوبت‌بندی آماده‌باش را فهرست می‌کند. پرتال با رجیستر ماده ۸ درهم می‌تند: هر ورودی کاتالوگ به یک ورودی رجیستر نگاشت می‌شود؛ ورودی‌های بدون ارجاع رجیستر باعث شکست CI می‌شوند؛ ورودی‌های رجیستر بدون حضور در کاتالوگ هشدارهای پیش‌دستانه بر ناظر را فعال می‌کنند.

۳. استقرار GitOps از طریق ArgoCD یا Flux

استقرار در تولید از طریق یک کنترلر GitOps اجرا می‌شود — ArgoCD یا Flux در سال ۲۰۲۶ استاندارد تولید است — که یک حالت اعلانیِ نسخه‌بندی‌شده در Git را با خوشه‌ی در حال اجرا هماهنگ می‌کند. kubectl apply دستی غیرفعال است؛ تنها مسیر به تولید یک درخواست ادغام‌شده‌ی pull است. مخزن Git همان رد حسابرسی است؛ ناظرانی که می‌پرسند «پیکربندی سرویس X در تاریخ Y را نشانم بده» یک برچسب Git دریافت می‌کنند، نه یک اسکرین‌شات.

۴. Open Policy Agent در پذیرش

Open Policy Agent (OPA) در زنجیره‌ی پذیرش خوشه قرار می‌گیرد و سیاست پلتفرم را اِعمال می‌کند: انطباق با پروفایل امنیت پاد، منشأ ایمیج، محدودیت‌های منابع، وجود سیاست شبکه، تکثیرِ متناسب با لایه‌ی حیاتی، جای‌گذاری زیرمنطقه‌ای تحت محدودیت‌های ابر مستقل. سیاست‌ها در Git نسخه‌بندی و در کنار پیکربندی سرویس‌ها تغییر‌مدیریت می‌شوند. استقرارهای ردشده توجیه‌های قابل‌بازبینی تولید می‌کنند که به بسته‌ی شواهد مدیریت تغییر تغذیه می‌شوند.

۵. OpenTelemetry سرتاسری

هر سرویس ردیابی‌ها، سنجه‌ها و لاگ‌های OpenTelemetry منتشر می‌کند. تیم پلتفرم یک خط لوله‌ی رصدپذیری متمرکز را اداره می‌کند — معمولاً Tempo یا Jaeger برای ردیابی‌ها، Prometheus برای سنجه‌ها، Loki یا OpenSearch برای لاگ‌ها — که سلامت سرتاسری CIF، نگاشت وابستگی و ورودی‌های طبقه‌بندی حادثه را نمایان می‌کند. پنجره‌ی ۴ ساعته‌ی طبقه‌بندی ماده ۱۸ با تشخیص آغاز می‌شود؛ خط لوله‌ی OTel مسیر از تشخیص تا طبقه‌بندی را به یک جست‌وجوی قابل‌پرس‌وجو کوتاه می‌کند، نه یک جلسه‌ی سنجش اولیه.

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

راهبرد ابر مستقل در سال ۲۰۲۶ باید به چهار پرسش مشخص Schrems II + DORA + برون‌سپاری EBA پاسخ دهد:

۱. داده کجا پردازش و ذخیره می‌شود؟ موقعیت در کشور عضو اتحادیه اروپا؛ زیرمنطقه برای جریان‌های با حیاتی بودن بالا؛ تعهدات کتبی اقامت داده. ۲. چه کسی دسترسی قانونی به داده دارد؟ عملیات تنها با کارمندان محلی؛ درخواست‌های دسترسی دولت خارجی مشمول فرایند دادگاه محلی؛ پاسخ آزموده‌شده به درخواست‌های دسترسی قانونی. ۳. پروفایل جایگزین‌پذیری چیست؟ ارزیابی جایگزین‌پذیری بند ۸۱ سند EBA/GL/2019/02؛ اجرای خروجِ آزموده‌شده؛ ارائه‌دهنده‌ی جایگزینِ شناسایی و قرارداد‌بسته‌شده (یا مستندسازی چرایی عملی‌نبودن آن). ۴. مدل استقلال فنی چیست؟ کلیدهای تحت‌کنترل مشتری؛ جداسازی رمزنگاشتی؛ صفحه‌ی مدیریت مستقل؛ زنجیره‌ی تأمین قابل‌حسابرسی.

گزینه‌های فروشنده در سال ۲۰۲۶ که به این پرسش‌ها می‌پردازند:

• AWS European Sovereign Cloud (اعلام‌شده در ۲۰۲۳، عرضه‌ی عمومی مورد انتظار در نیمه‌ی دوم ۲۰۲۶): منطقه‌ی فیزیکی که توسط زیرمجموعه‌ی مقیمِ اتحادیه اروپای AWS اداره می‌شود؛ عملیات و پشتیبانی مقیم اتحادیه اروپا؛ کلیدهای تحت‌کنترل مشتری از طریق الگوی KMS-XKS. هم‌راستایی محتوای قراردادی ماده ۲۸ DORA در سال ۲۰۲۶ در دست انجام است.
• Microsoft EU Data Boundary (عرضه‌ی عمومی ۲۰۲۴) + Bleu (Capgemini + Orange + Microsoft، تنها فرانسه): Data Boundary داده‌ی مشتری اتحادیه اروپا را در مناطق اتحادیه اروپا نگه می‌دارد؛ Bleu ابر مستقل فرانسویِ هم‌راستا با SecNumCloud است که پشته‌ی Microsoft Azure را تحت کنترل عملیاتی فرانسه اجرا می‌کند.
• مشارکت‌های مستقل Google Cloud: Thales / S3NS در فرانسه (معادل Bleu)؛ T-Systems در آلمان.
• Oracle EU Sovereign Cloud (عرضه‌ی عمومی ۲۰۲۳): الگوی دومنطقه‌ای (فرانکفورت + مادرید) با عملیات مقیم اتحادیه اروپا؛ به‌صورت تمیز منطبق با Schrems II.
• ارائه‌دهندگان هم‌راستا با Gaia-X (OVHcloud، Scaleway، Stackit، Aruba Cloud، IONOS): ارائه‌دهندگان بومی اتحادیه اروپا با برچسب‌گذاری Gaia-X؛ مقیاس و اکوسیستم کوچک‌تر از فوق‌مقیاس‌ها اما بدون در‌معرض‌قرار‌گرفتن در برابر قانون نظارت بر اطلاعات خارجی.

تصمیم راهبردی به‌ندرت دوگانه است. بانک‌های لایه‌یک معمولاً یک پیکربندی فوق‌مقیاس‌همراه‌با‌Data-Boundary را برای عمده‌ی بارهای کاری، یک گزینه‌ی ابر مستقل را برای جریان‌های تعیین‌شده‌ی با حساسیت بالا (مثلاً سامانه‌های مدیریت پرونده‌ی AML / تحریم‌ها که داده‌ی شخصیِ مقیمِ اتحادیه اروپا را پردازش می‌کنند)، و یک مسیر جایگزین‌پذیریِ احتیاطی را که سالانه بر اساس ماده ۲۸ DORA آزموده می‌شود، اجرا می‌کنند.

اجرای خروجِ آزموده‌شده

بندهای ۱۱۳ تا ۱۱۷ سند [EBA/GL/2019/02 ⧉](https://www.eba.europa.eu/regulation-and-policy/internal-governance/guidelines-on-outsourcing-arrangements "دستورالعمل‌های برون‌سپاری EBA) مقررات راهبرد خروج هستند. متن درباره‌ی آنچه الزامی است صریح است: «مؤسسات و مؤسسات پرداخت باید اطمینان یابند که می‌توانند بدون اختلال ناروا در فعالیت‌های کسب‌وکاری‌شان از ترتیبات برون‌سپاری خارج شوند… راهبردهای خروج نیز باید همچون بخشی از بازبینی‌های منظم ترتیبات برون‌سپاری مستند و آزموده شوند.»

انتظار نظارتی در سال ۲۰۲۶ آزمون سالانه‌ی سرتاسری اجرای خروج برای هر CIF وابسته به یک CTPP تعیین‌شده است. تمرین‌های رومیزی و بازبینی‌های مستندی کافی نیستند. آزمون باید موارد زیر را تولید کند:

• سنجش زمان‌تا‌بازیابی: زمان سپری‌شده‌ی واقعی از اعلام خروج تا بازیابی بار کاری روی ارائه‌دهنده‌ی جایگزین، در برابر هدف RTO مشتق‌شده از BIA.
• شواهد قابلیت‌حمل داده: صادرات آزموده‌شده‌ی داده از ارائه‌دهنده‌ی اصلی، اعتبارسنجی‌شده در برابر مسیر واردات ارائه‌دهنده‌ی مقصد، با شواهد تطبیق.
• هم‌ارزی کارکردی: بار کاری آزموده‌شده که روی ارائه‌دهنده‌ی جایگزین با SLOهای هم‌ارز اجرا می‌شود.
• شواهد هزینه: هزینه‌ی مستندِ اجرای خروج در برابر مفروضه‌ی هزینه‌ی بازیابی در برنامه‌ریزی احتیاطی مؤسسه.

نخستین تلاش برای آزمون سرتاسری خروج یک CIF معمولاً یک شکاف ۵ تا ۱۰ برابری میان RTO مستند و RTO واقعی را آشکار می‌کند. بستن آن شکاف کاری مهندسی است که ماه‌ها زمان می‌برد. بانک‌هایی که آن را به‌جای چرخه‌ی آزمون سالانه‌ی خود در جریان یک بازرسی نظارتی کشف می‌کنند، با چرخه‌ی یافته‌ای در سه‌ماهه‌ی سوم روبه‌رو می‌شوند که می‌توانستند از آن پرهیز کنند.

اهداف RTO / RPO از فهرست‌برداری CIF

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

این اعداد نمونه هستند — BIA مؤسسه اعداد خود را تولید می‌کند. دستاورد مهندسی پلتفرم یک قابلیتِ رگرسیون‌آزموده‌شده برای برآورده‌کردن اهداف مشتق‌شده از BIA است که از طریق آزمون خودکار بازیابی فاجعه به‌ازای هر سرویس شواهد می‌گیرد و از طریق آزمون سالانه‌ی اجرای خروج برای CIFهای وابسته به CTPP اعتبارسنجی می‌شود.

معنای این موضوع بر حسب نوع بانک

بانک‌های سیستمی مهم جهانی

مسئله‌ی دشوار مقیاس در سراسر خطوط کسب‌وکار است: هزاران سرویس، صدها CIF، در‌معرض‌قرار‌گرفتن‌های چندگانه در برابر CTPPهای تعیین‌شده در سراسر محصولات، حوزه‌های قضایی و پروفایل‌های تاب‌آوری. سرمایه‌گذاری، قابلیت مرکزی مهندسی پلتفرم است — جاده‌های هموار Kubernetes، پرتال Backstage، GitOps، OPA، OTel — که تطبیق رجیستر ماده ۸، نقشه‌ی تمرکز CTPP و قابلیت اجرای خروجِ CIF‌به‌CIF را بدون ساخت سفارشیِ به‌ازای هر خط کسب‌وکار تولید می‌کند.

بانک‌های جامع و متوسط

سرمایه‌گذاری در مهندسی پلتفرم در این لایه توجیه‌پذیر است اما دامنه محدود است: دو یا سه CIF با بالاترین حیاتی بودن را برگزینید، الگوی جاده‌ی هموار را پیرامون آن‌ها بسازید، بپذیرید که میراث موجود در میان‌مدت روی کنترل‌های کنونی ادامه یابد. موضع‌گیری نظارتی از گستره‌ی پلتفرم مهم‌تر است — توانایی ارائه‌ی شواهد یکپارچگی رجیستر ماده ۸ DORA و خروجِ آزموده‌شده برای سه CIF برتر، دغدغه‌های اصلی ناظر را پوشش می‌دهد.

بانک‌های منطقه‌ای و کوچک‌تر

انتخاب فروشنده به‌جای ساخت داخلی. یک فروشنده‌ی پلتفرم بانکی را برگزینید که معماری بومی Kubernetes آن مستند است، یکپارچه‌سازی رجیستر ماده ۸ آن توکار است، و تعهدات محتوای قراردادی ماده ۲۸ DORA آن روشن است. قابلیت مهندسی داخلی پیرامون پیکربندی، پایش و پاسخ به حادثه است — نه ساخت پلتفرم.

فین‌تک‌ها، PSPها و ارائه‌دهندگان SaaS که به بانک‌ها خدمت می‌دهند

پرسش محصولی برای فروشندگانی که در سال ۲۰۲۶ به بانک‌های اتحادیه اروپا می‌فروشند این است که آیا پلتفرم ورودی‌های رجیستر ماده ۸ و محتوای قراردادی ماده ۲۸ DORA را که کارکرد انطباق بانک نیاز دارد تولید می‌کند یا نه. فروشندگان با خروجی‌های ساختارمند معاملات سازمانی را می‌برند؛ فروشندگان با قالب‌های PDF به رقبای دارای JSON ساختارمند می‌بازند.

جمع‌بندی

تاب‌آوری ابری DORA در مرحله‌ی حسابرسی است. آنچه چرخه‌ی نظارتی ۲۰۲۶ موشکافی می‌کند، تصمیم‌های مهندسی پلتفرمی است که در طول ۲۰۲۴–۲۰۲۵ گرفته شده‌اند. مؤسساتی که در نظر ECB و EBA در بازه‌ی ۲۰۲۶–۲۰۲۸ معتبر به نظر می‌رسند، همان‌هایی هستند که جاده‌های هموار Kubernetes را با پرتال‌های به سبک Backstage و استقرار GitOps تحت پذیرش Open Policy Agent با OpenTelemetry سرتاسری اجرا می‌کنند — و شواهد رجیستر ماده ۸ را همچون یک مصنوع استقرار و شواهد اجرای خروجِ آزموده‌شده را همچون یک چرخه‌ی سالانه تولید می‌کنند، نه به‌عنوان پاسخ به یک درخواست نظارتی.

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

پلتفرم را همان‌گونه بسنجید که هر برنامه‌ی عملیاتی را می‌سنجید: پوشش جاده‌ی هموار، نرخ تطبیق رجیستر، امتیاز تمرکز CTPP، زمان خروجِ آزموده‌شده در برابر هدف RTO، میانگین زمان طبقه‌بندی ماده ۱۸، نرخ بستن TLPT. شواهد با سرعت خط لوله؛ بسته‌های مستندسازی تنها زمانی که ناظر یکی از آن‌ها را بخواهد.

پرسش‌های پرتکرار

آیا تاب‌آوری ابری DORA در سال ۲۰۲۶ هنوز در مرحله‌ی آماده‌سازی است؟

خیر. DORA از ۱۷ ژانویه ۲۰۲۵ در اجرای فعال بوده است. رژیم تعیین CTPP بر اساس مواد ۲۸ تا ۴۴ در طول ۲۰۲۵–۲۰۲۶ در حال گشایش است. یافته‌های حسابرسی ECB درباره‌ی مدیریت ریسک ICT در ماده ۶ و یکپارچگی رجیستر ماده ۸ در سه‌ماهه‌ی چهارم ۲۰۲۵ در چندین مؤسسه‌ی لایه‌یک به دست آمد. پرسش نظارتی ۲۰۲۶ شواهد حسابرسی مختص هر مؤسسه است، نه آمادگی مقرراتی.

کدام ارائه‌دهندگان ابری به‌عنوان CTPP تعیین شده‌اند؟

مقامات نظارتی اروپایی تصمیم‌های تعیین را در وب‌گاه‌های خود منتشر می‌کنند. مؤسساتی که در سال ۲۰۲۶ درون یا نزدیک به محیط قرار دارند شامل AWS، Microsoft (Azure)، Google (GCP)، Salesforce و شمار اندکی دیگر بسته به سهم بازار خدمات مالی در هر کشور عضو هستند. بانک‌هایی که بر آن ارائه‌دهندگان نظارت می‌شوند با انتظارات نظارتی متناظر درباره‌ی نحوه‌ی مدیریت آن وابستگی روبه‌رو می‌شوند.

آیا ابر مستقل نیاز به محتوای قراردادی ماده ۲۸ DORA را از میان می‌برد؟

خیر. ابر مستقل به بُعد Schrems II + اقامت داده می‌پردازد؛ محتوای قراردادی ماده ۲۸ DORA یک تعهد جداگانه است که صرف‌نظر از اینکه داده کجا قرار دارد اعمال می‌شود. قرارداد ارائه‌دهنده‌ی ابر مستقل همچنان باید بر اساس ماده ۲۸ دسترسی‌پذیری داده، امنیت، اقامت، حقوق حسابرسی، راهبردهای خروج و تداوم را پوشش دهد.

دستاورد مهندسی‌ای که تاب‌آوری ابری DORA را نشان می‌دهد چیست؟

پنج بنیان مهندسی پلتفرم که درهم می‌تنند: جاده‌های هموار Kubernetes (خوشه‌ی مدیریت‌شده با انحراف سیاست‌کنترل‌شده)، پرتال توسعه‌دهنده به سبک Backstage (کاتالوگی که با رجیستر ماده ۸ تطبیق می‌یابد)، استقرار GitOps (ArgoCD یا Flux)، Open Policy Agent در پذیرش، OpenTelemetry سرتاسری. شواهد با سرعت خط لوله به‌جای زمان حسابرسی.

اجرای خروج هر چند وقت یک‌بار باید آزموده شود؟

آزمون سالانه‌ی سرتاسری اجرای خروج به‌ازای هر CIF وابسته به یک CTPP تعیین‌شده. تمرین‌های رومیزی و بازبینی‌های مستندی کافی نیستند. آزمون باید زمان‌تا‌بازیابی، شواهد قابلیت‌حمل داده، هم‌ارزی کارکردی و شواهد هزینه را تولید کند — که در برابر اهداف RTO و RPO مشتق‌شده از BIA سنجیده می‌شوند.

منابع

• اتحادیه اروپا، (۲۰۲۲). مقرره (EU) 2022/2554 — قانون تاب‌آوری عملیاتی دیجیتال (DORA) ⧉.
• مرجع بانکداری اروپا، (۲۰۱۹). EBA/GL/2019/02 — دستورالعمل‌های ترتیبات برون‌سپاری ⧉.
• مرجع بانکداری اروپا، (۲۰۲۶). قانون تاب‌آوری عملیاتی دیجیتال ⧉.
• مقامات نظارتی اروپایی، (۲۰۲۴). گزارش نهایی درباره‌ی ITS رجیستر اطلاعات بر اساس DORA ⧉.
• نظارت بانکی ECB، (۲۰۲۵). اولویت‌های نظارتی ۲۰۲۶–۲۸ ⧉.
• بانک مرکزی اروپا، (۲۰۲۴). چارچوب TIBER-EU ⧉.
• ENISA، (۲۰۲۴). طرح امنیت سایبری اتحادیه اروپا برای خدمات ابری (EUCS) ⧉.
• Spotify، (۲۰۲۰–۲۰۲۴). پرتال توسعه‌دهنده‌ی Backstage ⧉.
• بنیاد رایانش ابری‌بومی، (۲۰۱۸). Open Policy Agent (OPA) ⧉.
• بنیاد رایانش ابری‌بومی، (۲۰۱۹). OpenTelemetry ⧉.

آخرین بازبینی 2026-07-17.

# شاخص بانکداری ابری‌بومی در ۲۰۲۶: DORA، مهندسی پلتفرم، ابر مستقل، و تاب‌آوری عملیاتی — Sebastien Rousseau

> Originally published at [https://sebastienrousseau.com/fa/2026-06-05-cloud-native-banking-index-dora-resilience-platform-engineering-2026/](https://sebastienrousseau.com/fa/2026-06-05-cloud-native-banking-index-dora-resilience-platform-engineering-2026/)

یک شاخص بانکداری ابری‌بومی برای سال ۲۰۲۶ به‌منظور سنجش آمادگی DORA، بلوغ مهندسی پلتفرم، ریسک تمرکز ابری، شواهد خروج، و تاب‌آوری عملیاتی.

Read the full article on sebastienrousseau.com: https://sebastienrousseau.com/fa/2026-06-05-cloud-native-banking-index-dora-resilience-platform-engineering-2026/

شاخص بانکداری ابری‌بومی در ۲۰۲۶: DORA، مهندسی پلتفرم، ابر مستقل، و تاب‌آوری عملیاتی — Sebastien Rousseau

یک شاخص بانکداری ابری‌بومی برای سال ۲۰۲۶ به‌منظور سنجش آمادگی DORA، بلوغ مهندسی پلتفرم، ریسک تمرکز ابری، شواهد خروج، و تاب‌آوری عملیاتی.

https://sebastienrousseau.com/fa/2026-06-05-cloud-native-banking-index-dora-resilience-platform-engineering-2026/

شاخص بانکداری ابری‌بومی در ۲۰۲۶: DORA، مهندسی پلتفرم، ابر مستقل، و تاب‌آوری عملیاتی — Sebastien Rousseau

یک شاخص بانکداری ابری‌بومی برای سال ۲۰۲۶ به‌منظور سنجش آمادگی DORA، بلوغ مهندسی پلتفرم، ریسک تمرکز ابری، شواهد خروج، و تاب‌آوری عملیاتی.

مهم‌ترین نکات راهبردی به این شرح است:

- شاخص بانکداری ابری‌بومی در �2026: DORA، مهندسی پلتفرم، ابر مستقل، و تاب‌آوری عملیاتی. بانکداری ابری‌بومی در سال ۲۰۲۶ در مرحله‌ی حسابرسی DORA است.
- چرا تاب‌آوری ابری DORA در مرحله‌ی حسابرسی است. سه دلیل که چرا قاب‌بندی «آماده‌سازی» در سال ۲۰۲۶ نادرست است.
- سیگنال‌های کنونی برای پایش. بلوغ ابری‌بومی در سال ۲۰۲۶ به پنج بنیان مهندسی تقلیل می‌یابد که درهم می‌تنند تا شواهد نظارتی را با سرعت خط لوله‌ی استقرار تولید کنند.
- مهندسی پلتفرم: پنج بنیان نام‌برده. بلوغ ابری‌بومی در سال ۲۰۲۶ به پنج بنیان مهندسی تقلیل می‌یابد که درهم می‌تنند تا شواهد نظارتی را با سرعت خط لوله‌ی استقرار تولید کنند.

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

→ https://sebastienrousseau.com/fa/2026-06-05-cloud-native-banking-index-dora-resilience-platform-engineering-2026/

#بانکداریابری‌بومی۲۰۲۶،بانک‌هایDora،ریسکتمرکزابری،مهندسیپلتفرمبانک‌ها،ریسکشخصثالثIct،راهبردخروجازابر،ابرمستقل

Sebastien Rousseau | CC-BY-4.0

@online{rousseau2026شاخص,
  author  = {Rousseau, Sebastien},
  title   = {{شاخص بانکداری ابری‌بومی در ۲۰۲۶: DORA، مهندسی پلتفرم، ابر مستقل، و تاب‌آوری عملیاتی — Sebastien Rousseau}},
  year    = {2026},
  url     = {https://sebastienrousseau.com/fa/2026-06-05-cloud-native-banking-index-dora-resilience-platform-engineering-2026/},
  urldate = {2026}
}

TY  - GEN
AU  - Rousseau, Sebastien
TI  - شاخص بانکداری ابری‌بومی در ۲۰۲۶: DORA، مهندسی پلتفرم، ابر مستقل، و تاب‌آوری عملیاتی — Sebastien Rousseau
PY  - 2026
UR  - https://sebastienrousseau.com/fa/2026-06-05-cloud-native-banking-index-dora-resilience-platform-engineering-2026/
ER  -

Rousseau S. شاخص بانکداری ابری‌بومی در ۲۰۲۶: DORA، مهندسی پلتفرم، ابر مستقل، و تاب‌آوری عملیاتی — Sebastien Rousseau. sebastienrousseau.com. 2026 Jun 5. Available from: https://sebastienrousseau.com/fa/2026-06-05-cloud-native-banking-index-dora-resilience-platform-engineering-2026/

Rousseau, Sebastien. "شاخص بانکداری ابری‌بومی در ۲۰۲۶: DORA، مهندسی پلتفرم، ابر مستقل، و تاب‌آوری عملیاتی — Sebastien Rousseau." sebastienrousseau.com. June 5, 2026. https://sebastienrousseau.com/fa/2026-06-05-cloud-native-banking-index-dora-resilience-platform-engineering-2026/.

Rousseau, S. (2026, June 5). شاخص بانکداری ابری‌بومی در ۲۰۲۶: DORA، مهندسی پلتفرم، ابر مستقل، و تاب‌آوری عملیاتی — Sebastien Rousseau. sebastienrousseau.com. https://sebastienrousseau.com/fa/2026-06-05-cloud-native-banking-index-dora-resilience-platform-engineering-2026/

شاخص بانکداری ابری‌بومی در ۲۰۲۶: DORA، مهندسی پلتفرم، ابر مستقل، و تاب‌آوری عملیاتی — Sebastien Rousseau

یک شاخص بانکداری ابری‌بومی برای سال ۲۰۲۶ به‌منظور سنجش آمادگی DORA، بلوغ مهندسی پلتفرم، ریسک تمرکز ابری، شواهد خروج، و تاب‌آوری عملیاتی.

Originally published at https://sebastienrousseau.com/fa/2026-06-05-cloud-native-banking-index-dora-resilience-platform-engineering-2026/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU · FOUNDER · ENGINEER