حسابرسی خدمات رایانش ابری

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

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

مسئله در مقیاس دولت

معماری مرجع ابر دولت ایران (GCRA) ابر دولت را «یک مرکز داده» نمی‌داند، بلکه «زیست‌بومی ابری و فدراسیونی» می‌داند که می‌تواند از ابرهای تجاری هم به‌عنوان یکی از اجزای خود استفاده کند؛ به شرط آنکه حکمرانی، امنیت، حفاظت داده، تعامل‌پذیری و جانمایی مناسب بارهای کاری برقرار باشد. این کتاب درباره همین «به شرط» است.

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

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

سه ابزار اصلی

1. حسابرسی انطباق: بر پایه ISO/IEC TR 3445 و چارچوب SLA در ISO/IEC 19086، همراه با حق قراردادی دسترسی به شواهد فنی.

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

3. تولید داده رخداد: ثبت سیستماتیک رخدادها و شواهد پایش، تا روزی بتوان ریسک را مدل کرد و بیمه‌پذیر ساخت.

کتاب برای چه کسانی است؟

• حسابرسان فناوری اطلاعات و امنیت که با خدمات ابری روبه‌رو می‌شوند

• مدیران فناوری دستگاه‌های اجرایی که باید درباره جانمایی بار کاری تصمیم بگیرند

• تنظیم‌گران، نهاد ناظر ابر دولت و سیاست‌گذاران حوزه ابر و مرکز داده

• ارائه‌دهندگان خدمات ابری که می‌خواهند آمادگی خود برای حسابرسی را نشان دهند

• بیمه‌گران و پژوهشگرانی که به داده و مدل ریسک این حوزه علاقه‌مندند

مسیر کتاب

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

یادآوری درباره منابع: این کتاب برای آموزش و تصمیم‌سازی نوشته شده و جایگزین متن رسمی استانداردها، مقررات یا مشاوره حقوقی نیست. آستانه‌های عددی کتاب «نمونه» هستند و تعیین مقادیر رسمی بر عهده نهاد ناظر است. پیش از استناد رسمی، ویرایش جاری هر استاندارد را از مرجع منتشرکننده بررسی کنید.

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

برای حسابرس دو ویژگی از بقیه مهم‌تر است: تجمیع منابع (چند مشتری روی یک زیرساخت) و قابل‌اندازه‌گیری بودن (هر مصرف ثبت می‌شود). اولی دسترسی مستقیم را محدود می‌کند و دومی امکان می‌دهد شواهد را از خود سرویس بگیریم.

در هر مدل خدمت، بخشی از کنترل‌ها با ارائه‌دهنده و بخشی با مشتری است. این همان مدل مسئولیت مشترک^۱ است. اما مسئولیت اجرا قابل واگذاری است، پاسخگویی نه. اگر داده شهروندان از طریق خطای ارائه‌دهنده فاش شود، مراجع نظارتی و مردم همچنان از همان دستگاه اجرایی پاسخ می‌خواهند.

در ماتریس کنترل ابری CSA (نسخه ۴٫۱) برای هر کنترل مشخص شده که در هر مدل خدمت، مالکیت آن با ارائه‌دهنده است یا مشترک. برای نمونه کنترل‌های حسابرسی و اطمینان‌بخشی (A&A) در هر سه مدل «مشترک» علامت خورده‌اند؛ یعنی هیچ‌یک از دو طرف نمی‌تواند آن را کاملاً به دیگری واگذار کند.

قاعده عملی: برای هر کنترل مهم سه پرسش بپرسید: چه کسی آن را اجرا می‌کند؟ چه کسی آن را پایش می‌کند؟ چه شاهدی نشان می‌دهد که اجرا و پایش واقعاً انجام شده است؟ اگر پاسخ پرسش سوم «اعتماد به ارائه‌دهنده» باشد، یک شکاف حسابرسی دارید.

معماری مرجع رایانش ابری (CCRA) که امروز در ISO/IEC 22123-3:2023 آمده و جایگزین ISO/IEC 17789:2014 شده، سه نقش اصلی تعریف می‌کند: مشتری خدمت ابری^۲، ارائه‌دهنده خدمت ابری^۳ و شریک خدمت ابری^۴. «حسابرس ابری» در این معماری یکی از زیرنقش‌های شریک است.

GCRA این فهرست را برای دولت گسترش می‌دهد: در کنار شهروند، کسب‌وکار و دستگاه اجرایی، بازیگرانی مانند اپراتور ابر دولت، تنظیم‌گر، حسابرس، مرجع امنیتی و مالک داده هم حضور دارند. دو تمایز GCRA برای حسابرسی اهمیت ویژه دارد:

• فراهم‌کننده در برابر اپراتور: ممکن است کسی که سرویس را ارائه می‌دهد با کسی که آن را بهره‌برداری می‌کند یکی نباشد. حسابرس باید بداند هر کنترل در دست کدام است.

• نهاد ناظر ابر دولت: نقشی حاکمیتی که در CCRA وجود ندارد و مسئول سیاست‌گذاری، حکمرانی معماری، ممیزی و انطباق است. GCRA تصریح می‌کند این نقش الزاماً به معنای ایجاد سازمان جدید نیست و می‌تواند در یک ساختار موجود یا چندنهادی تحقق یابد.

گزارش فنی ISO/IEC TR 3445 یکی از کارهای مفیدش را جدا کردن چند واژه می‌داند که اغلب به‌جای هم به کار می‌روند:

• دید محدود: مشتری به لایه‌های پایین‌تر از لایه تحت کنترل خود دسترسی ندارد.

• پویایی: منابع در دقیقه ایجاد و حذف می‌شوند؛ نمونه‌گیری سالانه کافی نیست.

• چندمستأجری: شواهد ممکن است داده مشتریان دیگر را هم دربر بگیرد.

• مرز مسئولیت پیچیده: بین مشتری، ارائه‌دهنده، اپراتور و زیرپیمانکاران.

• زنجیره تأمین: ارائه‌دهنده خود به زیرساخت و نرم‌افزار دیگران وابسته است.

• تمرکز: خطای یک ارائه‌دهنده ممکن است هم‌زمان ده‌ها دستگاه را از کار بیندازد.

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

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

برای هر چارچوب چهار پرسش بپرسید: چه چیزی را توصیف می‌کند؟ (واژگان، معماری، کنترل، سطح خدمت، فرایند حسابرسی)، برای چه کسی نوشته شده؟، آیا قابل گواهی است؟ و چه چیزی را پوشش نمی‌دهد؟

ISO/IEC 22123-1 واژگان و ISO/IEC 22123-2 مفاهیم را تعریف می‌کنند و ISO/IEC 22123-3:2023 معماری مرجع رایانش ابری است که از سپتامبر ۲۰۲۳ جایگزین ISO/IEC 17789:2014 شده است. ارزش اصلی این خانواده برای حسابرس زبان مشترک است: وقتی همه از «مشتری»، «ارائه‌دهنده»، «شریک» و «فعالیت‌های ابری» یک معنا برداشت کنند، دامنه حسابرسی دقیق تعریف می‌شود.

دقت در ارجاع: ISO/IEC 22123-3:2023 را نباید «معادل مستقیم» ITU-T Y.3502 معرفی کرد. Y.3502 با نسل قبلی یعنی ISO/IEC 17789 هم‌راستا بود؛ در اسناد رسمی، نسل قدیم و جدید را جدا ذکر کنید.

گزارش فنی ISO/IEC TR 3445 (منتشرشده در مارس ۲۰۲۲) با عنوان حسابرسی خدمات ابری^۱ راهنمایی برای برنامه‌ریزی و اجرای حسابرسی داخلی و خارجی خدمات ابری است. این سند بر نقش «حسابرس ابری» در 17789 و 22123 بنا شده و برای مشتریان، ارائه‌دهندگان و شرکا کاربرد دارد. مهم‌ترین محتوای آن عبارت است از:

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

• تمایز حسابرسی، ارزیابی، انطباق، ارزیابی انطباق و اطمینان‌بخشی

• موانع خاص ابر: چندمستأجری، نبود دسترسی فیزیکی، پویایی منابع و پیچیدگی مرز مسئولیت

• روش‌ها و رویکردهای عملی اجرای حسابرسی

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

مجموعه 19086 چارچوب نوشتن SLA ابری است: بخش ۱ (۲۰۱۶) مفاهیم و ساختار، بخش ۲ (۲۰۱۸، با اصلاحیه ۲۰۲۳) مدل متریک^۲، بخش ۳ (۲۰۱۷) الزامات انطباق اصلی و بخش ۴ ملاحظات امنیت و حفاظت از داده شخصی. فصل ۶ این مجموعه را باز می‌کند.

برداشتی رایج این است که C5 به SLA نمی‌پردازد. در نسخه ۲۰۲۶ این برداشت دقیق نیست. دامنه GC (شفافیت و اطلاعات قراردادی) شش شرط دارد که از جمله می‌خواهد:

• GC-02: اطلاعات الزام‌آور و شفاف درباره دسترس‌پذیری، دسته‌بندی رخداد، زمان پاسخ، زمان بازیابی و پیامد قراردادی نقض، در قرارداد (مثلاً SLA)

• GC-03: پارامترهای بازیابی در شرایط اضطراری مانند MTPD، RTO، RPO و MBCO

• GC-04: رویکرد تأمین دسترس‌پذیری، شامل متریک‌ها و اصول طراحی تاب‌آوری

• COM-02 (زیرمعیار تکمیلی): اعطای حقوق قراردادی اطلاعات و حسابرسی به مشتری، به‌صورت فردی یا حسابرسی گروهی^۳

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

تفاوت نسخه‌ها: بسیاری از نگاشت‌های موجود هنوز بر پایه C5:2020 (۱۲۱ معیار پایه، ۱۷ دامنه) هستند و شناسه‌ها و ساختار آن با C5:2026 یکی نیست. در هر گزارش، نسخه کاتالوگ را صریح بنویسید.

کاتالوگ‌ها هم‌پوشانی زیادی دارند. ماتریس کنترل ابری CSA را می‌توان محور نگاشت^۴ گرفت و هر کنترل آن را به C5، ISO/IEC 27001:2022، NIST SP 800-53، FedRAMP و مقررات DORA اتحادیه اروپا وصل کرد. نتیجه عملی این است که یک شاهد خوب گردآوری‌شده می‌تواند هم‌زمان چند الزام را پوشش دهد و حسابرسی‌های تکراری کاهش یابد. پیوست ۳ نمونه‌ای از این نگاشت را برای کنترل‌های مرتبط با این کتاب نشان می‌دهد.

نگاشت اثبات انطباق نیست: نگاشت‌ها «موضوعی»اند. اینکه کنترل الف به کنترل ب نگاشت شده، به معنای برآورده شدن ب نیست. خود BSI هم درباره نگاشت C5 به ISO 27001 همین هشدار را می‌دهد.

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

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

جایگاه این کتاب: GCRA شرط استفاده از ابر تجاری را مطرح می‌کند؛ این کتاب می‌کوشد این شرط را قابل اندازه‌گیری و قابل حسابرسی کند.

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

پس در GCRA، ابر عمومی ممنوع نیست؛ «قلمرو بیرونی»ای است که ورود بار کاری به آن تابع طبقه‌بندی و سیاست است.

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

نتایج طبقه‌بندی وارد یک موتور سیاست جانمایی^۲ می‌شود که محل مناسب را تعیین می‌کند. پیشنهاد این کتاب ساده است: «سنجش سه تمرکز» باید یکی از ورودی‌های همین موتور باشد، درست پیش از آنکه بار کاری به قلمرو بیرونی اختصاص یابد.

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

GCRA درباره راهبرد خروج هم صریح است: هر استفاده از ابر خارجی باید راهبرد خروج داشته باشد، یعنی سازمان بتواند در صورت تغییر سیاست، هزینه، نیاز امنیتی یا الزام تنظیم‌گر، بار کاری را به محیط دیگری منتقل کند. این قابلیت مستقیماً با حاکمیت، جابه‌جاپذیری^۳ و تعامل‌پذیری گره خورده است.

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

GCRA در مقایسه مدل‌های استقرار، افزایش ریسک تمرکز و نقطه شکست واحد را از محدودیت‌های مدل کاملاً متمرکز می‌شمارد و کاهش ریسک تمرکز و امکان چندارائه‌دهنده‌ای را از مزایای فدراسیون. چندابری هم در GCRA «انتخاب فنی صرف نیست، بلکه راهبردی حاکمیتی» برای تضمین استقلال و پایداری است.

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

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

GCRA در چارچوب ارزیابی خود چهار نوع ارزیابی (آمادگی، انطباق معماری، بلوغ و امنیتی) و چهار نوع ممیزی (داخلی فصلی، خارجی ناظر سالانه، امنیتی شش‌ماهه و مالی سالانه) تعریف کرده و «عملکرد و دسترس‌پذیری سرویس‌ها (SLA)» را صریحاً یکی از حوزه‌های بررسی ممیزی دانسته است. حسابرسی ابر عمومی باید در همین چرخه جا بگیرد، نه موازی با آن.

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

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

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

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

حسابرسی انطباق بر پایه ISO/IEC TR 3445 و الزامات انطباق SLA در ISO/IEC 19086-3، همراه با حق قراردادی و الزام‌آور دسترسی به شواهد فنی (Audit Right^۱). هدف این است که «حسابرسی‌پذیری» از یک ادعا به یک اهرم نظارتی قابل اجرا تبدیل شود.

در عمل این شرط سه جزء دارد: گزارش یا گواهی مستقل معتبر با دامنه‌ای که خدمت مورد نظر را پوشش دهد؛ SLA با متریک استاندارد و داده اندازه‌گیری قابل‌دسترس؛ و بند حق حسابرسی در قرارداد (فصل ۶ و ۷).

پیش از اجازه میزبانی، سه نوع تمرکز سنجیده می‌شود: تمرکز تأمین‌کننده، تمرکز جغرافیایی/منطقه‌ای و تمرکز زنجیره تأمین مشترک. این سنجش، مبنای تعیین سقف تمرکز و الزامات چندابری و چندمنطقه‌ای برای بارهای حساس است. فصل ۵ روش آن را شرح می‌دهد.

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

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

گاهی ارائه‌دهنده‌ای نمی‌تواند همه الزامات را برآورده کند اما ارزش فنی یا اقتصادی بالایی دارد. به‌جای رد قاطع یا پذیرش بی‌قید، از سازوکار استثنا همراه با کنترل جبرانی^۲ استفاده می‌شود. GCRA این سازوکار را با فرایندی پنج‌مرحله‌ای (ثبت درخواست، بررسی اولیه، ارزیابی ریسک و تعیین کنترل جبرانی، تصمیم و ثبت و پایش) و قالب ثبت مشخصی تعریف کرده است:

مراقب باشید: استثنای بدون تاریخ پایان و بدون مالک، به‌سرعت به رویه دائمی تبدیل می‌شود. در چارچوب خودارزیابی CSP در GCRA، پاسخ «خیر» به یک کنترل فقط با ثبت استثنا و کنترل جبرانی پذیرفتنی است.

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

«سنجش سه تمرکز» یعنی قبل از اینکه اجازه دهیم بار کاری دولتی روی ابر عمومی برود، بپرسیم:

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

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

تمرکز تأمین‌کننده^۱ یعنی وابستگی بیش از حد بارهای کاری دولت به یک ارائه‌دهنده. خطر آن فقط قطعی فنی نیست؛ ورشکستگی، تحریم، تغییر یک‌جانبه قیمت و شرایط، یا اختلاف حقوقی هم می‌تواند هم‌زمان ده‌ها دستگاه را درگیر کند. این همان چیزی است که GCRA با «اصل عدم قفل‌شدگی» (Vendor Lock-in^۲) و الزام راهبرد خروج می‌خواهد مهار کند.

چه چیزی را اندازه بگیریم؟

• سهم هر ارائه‌دهنده از بارهای کاری دولتی، به تفکیک رده حساسیت (تعداد، یا بهتر: وزن‌دار با اهمیت)

• شاخص هرفیندال-هیرشمن (HHI): مجموع مربع سهم‌ها بر حسب درصد؛ از نزدیک صفر (پراکندگی کامل) تا ۱۰٬۰۰۰ (یک ارائه‌دهنده)

• تعداد مؤثر ارائه‌دهندگان: برابر ۱۰٬۰۰۰ تقسیم بر HHI؛ نشان می‌دهد بازار «در عمل» معادل چند ارائه‌دهنده هم‌اندازه است

• جایگزین‌پذیری: آیا بار کاری با فناوری‌های باز ساخته شده و راهبرد خروج آن آزموده شده است؟

مثال: ده دستگاه: فرض کنید بارهای حساس ده دستگاه این‌طور تقسیم شده‌اند: ارائه‌دهنده الف ۶۰٪، ب ۲۰٪، ج ۱۰٪ و د ۱۰٪. شاخص HHI برابر است با ۳۶۰۰ + ۴۰۰ + ۱۰۰ + ۱۰۰ = ۴۲۰۰ و تعداد مؤثر ارائه‌دهندگان حدود ۲٫۴ است؛ یعنی با وجود چهار ارائه‌دهنده، اکوسیستم در عمل به دو و نیم ارائه‌دهنده تکیه دارد. اگر سهم‌ها به ۳۵٪، ۲۵٪، ۲۰٪ و ۲۰٪ برسد، HHI به ۲۶۵۰ و تعداد مؤثر به حدود ۳٫۸ می‌رسد.

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

چه چیزی را اندازه بگیریم؟

• سهم هر منطقه از بارهای حیاتی و حساس (و HHI جغرافیایی به همان روش)

• وجود منطقه ثانویه و فاصله آن از منطقه اصلی؛ چارچوب خودارزیابی CSP در GCRA (کنترل RES-02) فاصله دست‌کم ۲۰۰ کیلومتر مرکز پشتیبان از مرکز اصلی را برای سطح تأثیر متوسط و بالا می‌پرسد

• الگوی تاب‌آوری: فعال-آماده‌باش یا فعال-فعال، متناسب با RTO و RPO؛ همان‌طور که GCRA برای بارهای حساس توصیه می‌کند

• استقلال زیرساخت پایه دو منطقه: برق، مسیر شبکه و نقطه تبادل ترافیک

تمرکز زنجیره تأمین مشترک^۴ پنهان‌ترین نوع است. دو ارائه‌دهنده ممکن است برند و قرارداد متفاوت داشته باشند اما از یک مرکز داده اجاره‌ای، یک اپراتور ارتباطی، یک نرم‌افزار مجازی‌سازی یا سکوی ابری، یک سرویس DNS یا CDN، یک تأمین‌کننده سخت‌افزار یا یک پیمانکار عملیات استفاده کنند. در این صورت تنوع «ظاهری» است و یک آسیب‌پذیری یا اختلال در آن لایه مشترک، همه را با هم از کار می‌اندازد.

چه چیزی را اندازه بگیریم؟

• ثبت وابستگی‌ها: برای هر ارائه‌دهنده، فهرست مؤلفه‌ها و تأمین‌کنندگان حیاتی؛ معادل خدماتی «فهرست مواد» (Service BOM^۵) که در کنترل STA-09 ماتریس CSA آمده است

• ماتریس هم‌پوشانی: کدام لایه‌ها میان ارائه‌دهندگان «مستقل» مشترک‌اند؟

• تعداد مؤثر ارائه‌دهندگان مستقل: ارائه‌دهندگانی که در لایه‌های حیاتی وابستگی مشترک دارند، یک ارائه‌دهنده حساب می‌شوند

• شفافیت زنجیره تأمین: کنترل SUP-01 در خودارزیابی CSP در GCRA می‌پرسد آیا فهرست کامل تأمین‌کنندگان سخت‌افزار و نرم‌افزار به‌روز و شفاف است

تمرین: برای ده سامانه مهم سازمانتان جدولی بسازید: ارائه‌دهنده، منطقه، مرکز داده، اپراتور ارتباطی، سکوی مجازی‌سازی و سرویس DNS. احتمالاً در همان نگاه اول تمرکزی می‌بینید که تصورش را نمی‌کردید.

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

آستانه‌ها نمونه‌اند: اعداد جدول برای نشان دادن منطق‌اند، نه توصیه رسمی. در ادبیات رقابت معمولاً HHI بالای حدود ۱۸۰۰ تا ۲۵۰۰ «متمرکز» شمرده می‌شود، اما مقادیر رسمی باید با توجه به اندازه بازار داخلی، رده حساسیت و ظرفیت ابر داخلی توسط نهاد ناظر تعیین و دوره‌ای بازنگری شوند.

سهم هر ارائه‌دهنده (یا منطقه) را از بارهای کاری حساس وارد کنید تا HHI، تعداد مؤثر و وضعیت نسبت به آستانه‌های نمونه این فصل را ببینید.

مقررات تاب‌آوری عملیاتی دیجیتال اتحادیه اروپا (DORA) برای نهادهای مالی همین منطق را دارد: پیش از عقد قرارداد خدمات فناوری، باید سنجیده شود که آیا قرارداد به تقویت ریسک تمرکز ICT کمک می‌کند (ماده ۲۸ و ۲۹)، و برای خدمات حیاتی، راهبرد خروج الزامی است. این پیشینه نشان می‌دهد سنجش تمرکز پیش از قرارداد، ایده‌ای آزموده در تنظیم‌گری است و نه سلیقه‌ای محلی.

خروجی این فصل یک سند ساده است: کارنامه تمرکز که برای هر درخواست میزبانی پر می‌شود و نسخه تجمیعی آن به‌صورت دوره‌ای نزد نهاد ناظر به‌روز می‌شود. الگوی آن در پیوست ۲ آمده است. این کارنامه، هم ورودی موتور سیاست جانمایی GCRA است و هم یکی از اقلامی که بازارگاه ابری باید منتشر کند (فصل ۱۰).

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

• اگر SLA قابل اندازه‌گیری نباشد، اجرای آن هم قابل راستی‌آزمایی نیست.

• اگر تعاریف یکسان نباشد، مقایسه ارائه‌دهندگان در بازارگاه ناممکن است.

• اگر داده نقض SLA ثبت نشود، هیچ مدل ریسک و بیمه‌ای روی آن بنا نمی‌شود.

GCRA هم «عملکرد و دسترس‌پذیری سرویس‌ها (SLA)» را صریحاً یکی از حوزه‌های بررسی در ممیزی ابر دولت می‌داند و برای دسترس‌پذیری سرویس‌های هسته، هدف ماهانه ۹۹٫۹۹٪ را به‌عنوان شاخص کلیدی پیشنهاد کرده است.

ارزش این مجموعه در دو چیز است: فهرست ثابتی از موضوعات که هر SLA باید درباره آن‌ها صحبت کند و روش تعریف متریک به گونه‌ای که اندازه‌گیری شود، نه فقط ادعا. 19086-2 الزامی به استفاده از مجموعه خاصی از متریک‌ها ندارد؛ آنچه الزامی می‌کند «شیوه تعریف» است.

شرط GC-02 در C5:2026 از ارائه‌دهنده می‌خواهد در قرارداد اطلاعات الزام‌آور، شفاف و قابل‌فهم درباره دسترس‌پذیری، دسته‌بندی و اولویت رخداد، زمان پاسخ، زمان بازیابی و پیامد قراردادی نقض ارائه دهد؛ آن هم با تعاریفی که کارشناس مشتری بتواند خدمت را با نیاز کسب‌وکار خود بسنجد. GC-03 پارامترهای بازیابی اضطراری (MTPD، RTO، RPO، MBCO) و GC-04 رویکرد تأمین دسترس‌پذیری را می‌خواهد.

چند معیار عملیاتی C5 هم به SLA گره خورده‌اند: OPS-02 تأکید می‌کند ارائه‌دهنده باید انطباق با SLA را تضمین کند و PS-02 می‌خواهد افزونگی عملیاتی، و در زیرمعیار تشدیدی افزونگی جغرافیایی، چنان طراحی شود که الزامات دسترس‌پذیری SLA برآورده شود.

جمع‌بندی برای حسابرس: C5 به شما می‌گوید SLA باید شفاف و الزام‌آور باشد؛ 19086 به شما می‌گوید متریک آن چگونه تعریف شود؛ داده پایش مستقل به شما می‌گوید واقعاً چه شد. حسابرسی کامل SLA به هر سه نیاز دارد.

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

2. منبع داده اندازه‌گیری مشخص است و مشتری، ناظر یا ثالث به آن دسترسی دارد.

3. رخدادها با قالب یکسان ثبت و گزارش می‌شوند و نسخه‌ای به نهاد ناظر می‌رسد.

4. جبران به‌روشنی و بر پایه متریک تعریف شده است.

5. استثناها محدود، مستند و قابل‌بررسی‌اند.

6. RTO و RPO تعهدشده با برنامه تداوم کسب‌وکار مشتری تطبیق داده شده است.

هشدار: SLAهایی که «بهترین تلاش» یا «در حد معقول» را تعهد می‌کنند، از دید حسابرسی تعهد به شمار نمی‌آیند؛ مگر اینکه تعریف و آستانه عددی داشته باشند.

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

حق حسابرسی^۱ یعنی تعهد قراردادی و الزام‌آور ارائه‌دهنده به اینکه مشتری، نماینده مستقل او یا نهاد ناظر را به شواهد فنی لازم دسترسی بدهد. بدون این حق، «حسابرسی‌پذیری» تنها ادعایی تبلیغاتی است؛ با آن، به اهرمی نظارتی تبدیل می‌شود.

C5:2026 هم در زیرمعیار تکمیلی COM-02 می‌خواهد ارائه‌دهنده حقوق قراردادی اطلاعات و حسابرسی را به مشتری اعطا کند، به‌صورت فردی یا در قالب حسابرسی گروهی؛ و در SSO-01 می‌خواهد اگر گزارش مستقل درباره خدمات زیرپیمانکار موجود نیست، حق حسابرسی متناسب توافق شود.

حسابرسی گروهی برای دولت: ده دستگاه که از یک ارائه‌دهنده استفاده می‌کنند، به‌جای ده حسابرسی جدا می‌توانند به نمایندگی نهاد ناظر یک حسابرسی گروهی^۲ انجام دهند. این کار هزینه هر دو طرف را کم و قدرت چانه‌زنی دولت را زیاد می‌کند.

چارچوب خودارزیابی CSP در GCRA یک الزام مفید دیگر هم دارد: گزارش تغییرات اساسی (معماری، مکان، تأمین‌کننده، آسیب‌پذیری بحرانی) ظرف ۷۲ ساعت به نهاد ناظر. این الزام دقیقاً همان داده‌ای را تأمین می‌کند که کارنامه تمرکز برای به‌روز ماندن لازم دارد.

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

اصل «خوداظهاری با راستی‌آزمایی»: GCRA در چارچوب خودارزیابی CSP این اصل را مبنا قرار داده است: ارائه‌دهنده ابتدا خود را ارزیابی می‌کند و سپس ارزیاب مستقل ادعاها را تأیید می‌کند. پرسشنامه پرشده شاهد نیست؛ شروع کار است.

حسابرسی سنتی «عکس لحظه‌ای» می‌گیرد. اما در ابر، وضعیت یک سیستم ممکن است ساعتی پس از پایان حسابرسی عوض شود. جایگزین، حسابرسی پیوسته^۳ است: بررسی‌های خودکار که پیکربندی‌ها و رخدادها را مداوم با سیاست‌ها مقایسه می‌کنند. GCRA هم «انطباق خودکار» و «سیاست به‌مثابه کد» را از اصول خودکارسازی از ابتدا می‌داند.

نکته: حسابرسی پیوسته جایگزین قضاوت حسابرس نیست؛ فقط داده را به‌هنگام‌تر می‌کند. هنوز کسی باید تصمیم بگیرد کدام انحراف مهم است.

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

1. تعیین دامنه و مرز: خدمت ابری، محل‌های استقرار، مؤلفه‌های داخلی و برون‌سپاری‌شده و مرز مسئولیت را مکتوب کنید. شفافیت دامنه خودش بخشی از ارزیابی است.

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

3. تعیین نوع مأموریت: ارزیابی طراحی کنترل‌ها (نوع ۱) برای غربالگری، یا ارزیابی اثربخشی در یک بازه (نوع ۲) برای اتکا در قرارداد.

4. برنامه‌ریزی شواهد: برای هر الزام، شاهد، منبع، روش آزمون و معیار پذیرش را از پیش تعیین کنید.

5. گردآوری و ارزیابی شواهد: شواهد را خودتان از منبع اصلی بگیرید و صحت، کفایت و به‌هنگام بودن هر کدام را ثبت کنید.

6. درجه‌بندی یافته‌ها: هر یافته را با ساختار مشخص ثبت و شدت آن را تعیین کنید.

7. گزارش و پیگیری: دامنه، معیارها، روش، شواهد، یافته‌ها و محدودیت‌ها را روشن کنید و یافته‌های باز را در دوره بعد پیگیری کنید.

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

هر یافته با پنج جزء ثبت می‌شود و یافته بدون «معیار» قابل دفاع نیست:

برای شدت، می‌توان از سطوح عدم انطباق چارچوب خودارزیابی CSP در GCRA استفاده کرد:

GCRA برای ورود ارائه‌دهندگان به فهرست رسمی، فرایندی شش‌مرحله‌ای تعریف کرده که ممیزی خدمت ابری عمومی هم باید با آن سازگار باشد:

1. ثبت درخواست و تعیین سطح تأثیر (پایین، متوسط، بالا) بر پایه محرمانگی، یکپارچگی و دسترس‌پذیری

2. تکمیل چک‌لیست خوداظهاری توسط ارائه‌دهنده

3. بررسی اولیه برای احراز شرایط پایه

4. ارزیابی مستقل توسط شخص ثالث مورد تأیید (ممیزی میدانی و آزمون فنی)

5. صدور تأییدیه، تعیین اعتبار و درج در فهرست رسمی

6. ارزیابی مستمر: گزارش ماهانه عملکرد و امنیت، خودارزیابی خلاصه هر ۶ ماه، ارزیابی کامل هر ۱۲ ماه و گزارش تغییرات اساسی ظرف ۷۲ ساعت

پیوند با این کتاب: پیشنهاد کتاب این است که «کارنامه تمرکز» و «داده رخداد» به گام‌های ۵ و ۶ افزوده شوند؛ یعنی تأییدیه ارائه‌دهنده علاوه بر انطباق کنترل‌ها، سهم او در تمرکز اکوسیستم را هم ثبت کند.

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

تمایز با لایه‌های GCRA: این چهار لایه، لایه‌های نظام تنظیم‌گری است و نباید با چهار لایه معماری فنی CCRA و GCRA (کاربری، دسترسی، خدمت، منابع) اشتباه گرفته شود.

L1 · لایه نظارتی و سیاست‌گذاری

چارچوب انطباق، الزامات حسابرسی، استاندارد SLA، آستانه‌های تمرکز، سازوکار تصمیم و پروتکل حل اختلاف در این لایه تعریف می‌شود. خروجی آن «قواعد بازی» است.

L2 · لایه یکپارچه‌سازی و حسابرسی

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

L3 · لایه بازارگاه ابری ملی

بازارگاهی که ارائه‌دهندگان خدمات خود را همراه با شرایط استفاده، SLA استاندارد، قیمت، گزارش حسابرسی و شاخص تمرکز منتشر می‌کنند (فصل ۱۰).

L4 · لایه ارائه سرویس

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

GCRA ساختار حکمرانی سه‌سطحی دارد (راهبردی، معماری، اجرایی) و نهادهایی مانند شورای عالی ابر دولت، کمیته حکمرانی معماری، زیرکمیته‌های امنیت و داده و نهاد ناظر. معماری چهارلایه را می‌توان این‌طور روی آن نشاند:

GCRA دوره‌های ممیزی زیر را پیشنهاد کرده است؛ حسابرسی ابر عمومی باید در همین چرخه جا بگیرد:

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

در این معماری بازیگران متعددی حضور دارند و منافع آن‌ها همیشه هم‌راستا نیست. توصیه‌ها:

• نقش «تنظیم‌گر» از «اجراکننده خدمت» جدا باشد؛ همان تمایز فراهم‌کننده و اپراتور در GCRA

• ماتریس تعارض منافع تهیه و به‌روز شود

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

• ارزیاب مستقل توسط مرجع مشخص تأیید صلاحیت شود

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

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

1. انتشار موارد بالا در قالب یکسان و ماشین‌خوان

2. به‌روزرسانی در بازه مشخص و اعلام تاریخ آخرین بازنگری

3. امکان بررسی توسط ارزیاب مستقل مورد تأیید

4. سازوکار شکایت و اعلام نقض

5. تعلیق یا خروج ارائه‌دهنده در صورت نقض مکرر

ملاحظه عملی: الزامات سنگین ابتدا بازیگران کوچک را از بازار بیرون می‌کند و خودش تمرکز را بیشتر می‌کند. اگر هدف تنوع بازار است، سطح‌بندی ارائه‌دهندگان را متناسب با سطح تأثیر (پایین، متوسط، بالا) در نظر بگیرید؛ همان منطقی که خودارزیابی CSP در GCRA دارد.

هر ارائه‌دهنده یک شناسنامه استاندارد دارد: فهرست خدمات، گواهی‌ها، سطح تأثیر مجاز، سابقه رخداد، شاخص‌های سطح خدمت و سهم تمرکز. بر اساس آن در سطحی قرار می‌گیرد و دستگاه‌ها بار حساس را فقط به ارائه‌دهندگان سطح مشخص می‌سپارند. شناسنامه، پل میان «فهرست رسمی CSPها» در GCRA و تصمیم خرید هر دستگاه است.

یکی از اشتباهات پرهزینه، خلط حسابرسی با اکچوئری است. حسابرس می‌پرسد: «آیا کنترل‌ها همان‌طور که ادعا می‌شود وجود دارند و کار می‌کنند؟» اکچوئر می‌پرسد: «با توجه به داده گذشته، احتمال و شدت خسارت چقدر است و حق بیمه چه باید باشد؟»

بیمه بر «پراکندگی» ریسک تکیه دارد: بیمه‌گر فرض می‌کند خسارت‌ها هم‌زمان رخ نمی‌دهند. تمرکز این فرض را می‌شکند. اگر بخش بزرگی از بارهای دولتی روی یک ارائه‌دهنده یا منطقه باشد، یک رخداد می‌تواند خسارت هم‌زمان و هم‌بسته ایجاد کند که بیمه‌گر نمی‌تواند آن را بپذیرد یا قیمت آن بسیار بالا می‌رود. به همین دلیل کارنامه تمرکز فصل ۵، پیش‌نیاز هر گفت‌وگوی جدی با بیمه‌گر است.

مسیر از دیدن تا بیمه‌پذیری را می‌توان «نردبانی» پنج‌پله‌ای دید. هر پله پایه پله بعدی است و پریدن از پله‌ها جز ادعای توخالی نتیجه‌ای ندارد.

1. دیدن: ثبت وابستگی‌ها؛ مراکز داده، شبکه، نرم‌افزار پایه و پیمانکاران فرعی

2. سنجیدن: تعریف شاخص‌ها، کارنامه تمرکز و بانک داده رخداد

3. سناریوسازی: تحلیل سناریوهای تجمعی (مثلاً قطعی یک منطقه یا یک ارائه‌دهنده)

4. مدل‌سازی: برآورد فراوانی و شدت بر پایه داده انباشته

5. انتقال ریسک: بیمه، از جمله بیمه پارامتریک

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

اینجا SLA استاندارد و داده پایش مستقل ارزش واقعی خود را نشان می‌دهند: بدون متریک قابل‌اعتماد، شاخص بیمه‌ای وجود ندارد.

مرز ادعا: در بازه یک پروژه کوتاه‌مدت «اکچوئری واقعی» ساخته نمی‌شود. آنچه ساخته می‌شود زیرساخت داده‌ای و مدل نمایشی اثبات مفهوم است، نه نرخ بیمه واقعی. نرخ واقعی محصول چند سال انباشت داده رخداد است.

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

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

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

این شاخص‌ها مکمل شاخص‌های کلیدی GCRA (دسترس‌پذیری سرویس‌های هسته، MTTD، MTTR و غیره) و مدل بلوغ پنج‌سطحی آن هستند و می‌توانند در حوزه «حکمرانی» ماتریس بلوغ دستگاه‌ها هم وارد شوند.

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

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

بخش الف: مشخصات

بخش ب: سنجش

بخش ج: تصمیم

جدول زیر چند کنترل ماتریس کنترل ابری CSA (نسخه ۴٫۱) را که به موضوع این کتاب مربوط‌اند، به C5:2020، ISO/IEC 27001:2022 و مقررات DORA وصل می‌کند. منبع، یک اطلس نگاشت با محوریت CCM است.

نکات استفاده: ستون C5 بر پایه C5:2020 است و شناسه‌ها با C5:2026 یکی نیستند. نگاشت‌ها موضوعی‌اند و برآورده شدن یک کنترل را به معنای برآورده شدن دیگری نشان نمی‌دهند.

معیارهای C5:2026 مرتبط با این کتاب

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

بند دسترسی به شواهد

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

بند اعلام رخداد

ارائه‌دهنده رخدادهای امنیتی و قطعی مؤثر بر خدمت مشتری را ظرف [مهلت] ساعت پس از کشف به مشتری و نهاد ناظر اعلام می‌کند و گزارش تحلیل ریشه‌ای را ظرف [مهلت] روز در قالب توافق‌شده ارائه می‌دهد.

بند مکان و زیرپیمانکاران

ارائه‌دهنده منطقه و مرکز داده محل پردازش و فهرست زیرپیمانکاران مؤثر بر خدمت یا داده مشتری را به‌روز نگه می‌دارد و هر تغییر اساسی را دست‌کم [مهلت] روز پیش از اعمال، و در موارد اضطراری ظرف ۷۲ ساعت، اعلام می‌کند.

بند خروج

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

الگوی متریک SLA

واژه‌نامه

منابع اصلی

• سرگلزایی جوان، م. معماری مرجع ابر دولت ایران (GCRA)؛ نسخه آنلاین: gcra.ir

• ISO/IEC TR 3445:2022, Information technology — Cloud computing — Audit of cloud services

• ISO/IEC 19086-1:2016، 19086-2:2018 (+Amd 1:2023)، 19086-3:2017؛ Cloud SLA framework

• ISO/IEC 22123-1، 22123-2 و 22123-3:2023؛ Cloud computing vocabulary, concepts and reference architecture

• BSI, Cloud Computing Compliance Criteria Catalogue (C5:2026)، نسخه ماشین‌خوان، مجوز CC BY-ND 4.0

• Cloud Security Alliance, Cloud Controls Matrix v4.1 و CAIQ v4.1

• Regulation (EU) 2022/2554 on Digital Operational Resilience (DORA)، به‌ویژه مواد ۲۸ و ۲۹

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

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

• سه شرط میزبانی (حسابرسی انطباق، سنجش سه تمرکز، داده رخداد) ابر عمومی را از نقطه کور به دامنه حسابرسی‌پذیر تبدیل می‌کند.

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

• SLA قابل اندازه‌گیری و حق حسابرسی، حسابرسی‌پذیری را از ادعا به اهرم تبدیل می‌کنند.

• معماری چهارلایه، سیاست را بدون گسست به ارائه خدمت وصل می‌کند و در ساختار حکمرانی GCRA جا می‌گیرد.

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

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

ابر عمومی خطرناک نیست؛ ابرِ دیده‌نشده خطرناک است.