Матрица на споделената отговорност в облака за ISO, NIS2, DORA
Главният оперативен директор (COO) на fintech дружество се обажда на главния директор по информационна сигурност (CISO) в 07:15 в понеделник.
Европейски банков клиент иска доказателства, че SaaS платформата на дружеството може да изпълни изискванията на DORA за ИКТ риск от трети страни. Търговският екип вече е изпратил стандартния пакет за сигурност на доставчика: ISO сертификат, резюме за ръководството от тестове за проникване, сертификат за киберзастраховка, уведомление за поверителност и доклад за уверение от доставчика на облачни услуги.
Банката се връща с по-конкретен въпрос:
„Покажете ни кой отговаря за всеки контрол във вашата облачна среда: вие, вашият доставчик на облачни услуги, доставчикът на управлявана база данни, доставчикът на идентичност, доставчикът на услуги за регистриране и всички подизпълнители по обработването. След това покажете доказателствата.“
По-късно същата сутрин CISO има заседание на съвета. CEO ще зададе същия въпрос на бизнес език: „Сигурни ли сме, че тази платформа е защитена, и кой носи отговорност, ако нещо се обърка?“
Точно тук много програми за съответствие в облака блокират.
Организацията може да има надежден доставчик на облачни услуги, добри инструменти, разумни политики и регистър на риска. Но когато бъде поискано доказване на границите на отговорност, доказателствата са разпилени. Отдел „Закупуване“ държи договорите. Правният отдел държи DPA. Инженерният екип държи архитектурните схеми. Екипът по сигурността държи журналите и облачните конфигурации. Екипът по поверителност държи списъка на подизпълнителите по обработването. Екипът по съответствие държи Декларацията за приложимост. Никой няма един контролиран артефакт, който да посочва, контрол по контрол, какво прави доставчикът, какво трябва да конфигурира клиентът, кой подизпълнител по обработването участва, коя клауза прави задължението приложимо и какви доказателства следва да очаква одиторът.
Този артефакт е матрицата на споделената отговорност в облака.
Не общият слайд на хипермащабния облачен доставчик, който казва, че доставчикът защитава облака, а клиентът защитава това, което е в облака. Реалната матрица на споделената отговорност в облака за ISO/IEC 27001:2022, NIS2, DORA и GDPR е управленски запис. Тя издържа клиентска комплексна проверка, ISO одит, преглед по DORA, проверка на отчетността по GDPR и разследване на инцидент.
Защо споделената отговорност в облака се превръща в одитен въпрос
Моделът на споделена отговорност обикновено се представя като техническа граница. При IaaS доставчикът управлява физическите съоръжения, хардуера, виртуализацията и базовата инфраструктура. Клиентът управлява идентичностите, данните, работните натоварвания, мрежовите правила, избора на шифроване и конфигурациите. При SaaS доставчикът поема повече оперативна отговорност, но клиентът продължава да отговаря за потребителския достъп, управлението на данните, правното основание, конфигурацията, очакванията за мониторинг и ескалацията при инциденти.
Това обяснение е полезно, но непълно.
Одиторите, регулаторите и корпоративните клиенти питат не само „кой изпълнява контрола?“. Те искат да знаят:
- Кой носи отчетност за риска?
- Коя договорна клауза прави тази отчетност приложима?
- Коя политика изисква контрола?
- Коя облачна услуга, SaaS платформа или подизпълнител по обработването е в обхвата?
- Кои доказателства потвърждават, че контролът е функционирал през периода на преглед?
- Кое изискване на рамка се покрива от доказателствата?
- Какво се случва, ако доставчикът промени услугата, местоположението, подизпълнителя по обработването или рисковия профил на контролите?
ISO/IEC 27001:2022 ISO/IEC 27001:2022 превръща това във въпрос на система за управление. Клаузи 4.1 до 4.4 изискват организацията да разбира вътрешните и външните обстоятелства, заинтересованите страни, правните и договорните задължения, обхвата на СУИС, интерфейсите и зависимостите. Клаузи 6.1.1 до 6.1.3 изискват оценка на риска, третиране на риска, одобрение от собственика на риска, приемане на остатъчния риск и Декларация за приложимост. Клауза 8.1 изисква оперативно планиране и контрол, включително контрол върху външно предоставяни процеси, продукти и услуги, релевантни за СУИС.
Казано просто, ако доставчик на облачни услуги, SaaS доставчик или подизпълнител по обработването поддържа бизнес процес в обхвата, той не може да остане извън СУИС. Той трябва да бъде видим в обхвата, риска, третирането, договорния контрол и доказателствата.
NIS2 повишава залога. Article 21 изисква съществените и важните субекти да прилагат подходящи и пропорционални технически, оперативни и организационни мерки, включително анализ на риска, обработване на инциденти, непрекъсваемост, сигурност на веригата на доставки, сигурно придобиване, сигурна разработка, обработване на уязвимости, оценка на ефективността, киберхигиена, криптография, сигурност на човешките ресурси, контрол на достъпа, политика за управление на активите и многофакторна автентикация или непрекъсната автентикация, когато е приложимо. Article 20 възлага управленската отговорност на органите за управление.
DORA е още по-конкретен за финансовите субекти. Той се прилага от 17 януари 2025 г. и изисква финансовите субекти да управляват ИКТ риск, докладване на съществени инциденти, свързани с ИКТ, тестване на цифровата оперативна устойчивост и ИКТ риск от трети страни. Articles 28 до 30 изискват управление на ИКТ риска от трети страни, предварителна оценка на риска от концентрация, договорни защитни мерки, права на одит и достъп, видимост върху подизпълнителите, права за прекратяване и стратегии за изход.
GDPR добавя теста за отчетност. Article 5 изисква личните данни да се обработват при спазване на цялостност и поверителност, а Article 5(2) изисква администраторът да може да докаже съответствие. Article 28 урежда договорите с обработващи лични данни и подизпълнителите по обработването. Article 32 изисква сигурност на обработването. Articles 33 и 34 изискват уведомяване за нарушение на сигурността на личните данни, когато е приложимо.
Матрицата на споделената отговорност в облака се превръща в мост между тези задължения.
Дефиницията на Clarysec: управленски артефакт, а не диаграма
В ангажиментите на Clarysec матрицата на споделената отговорност в облака е контролиран запис на СУИС, който свързва облачни услуги, доставчици, подизпълнители по обработването, контроли, политики, договорни задължения, доказателства и одитни очаквания.
Най-силното обяснение е в Zenith Blueprint Zenith Blueprint, във фазата Controls in Action, Step 23:
„Доставчиците на облачни услуги защитават инфраструктурата, но вие продължавате да носите отчетност за вашите данни, вашите конфигурации, вашите политики за достъп и вашата готовност за реагиране при инциденти.“
Същата стъпка обяснява, че използването на облачни услуги трябва да се третира като част от СУИС, включително класификация на облачните услуги, разбиране на обработваните или съхраняваните данни, оценка на доставчика, договорни клаузи и управление на промените в услугите. Това превръща споделената отговорност от концепция в проследима контролна структура.
Zenith Controls Zenith Controls разглежда контролите от ISO/IEC 27001:2022, Приложение A, и указанията на ISO/IEC 27002:2022 5.20, 5.21 и 5.23 като централни опорни точки:
- 5.20, адресиране на информационната сигурност в споразуменията с доставчици.
- 5.21, управление на информационната сигурност във веригата за доставки на ИКТ.
- 5.23, информационна сигурност при използване на облачни услуги.
Това не са изолирани елементи от контролен списък. Те определят гръбнака на матрицата.
| Въпрос в матрицата | Опорна точка в ISO/IEC 27001:2022, Приложение A | Практическо значение |
|---|---|---|
| С какво трябва договорно да се ангажира доставчикът? | 5.20 | Сигурността, поверителността, правата на одит, докладването на инциденти, подизпълнението и прекратяването трябва да бъдат приложими. |
| Как контролираме доставчика на нашия доставчик? | 5.21 | Рискът във веригата за доставки на ИКТ и рискът от низходящи зависимости трябва да бъдат идентифицирани, оценени, наблюдавани и прехвърлени надолу по веригата. |
| Как управляваме избора, използването и изхода от облачна услуга? | 5.23 | Отговорностите в облака, конфигурациите, доказателствата, регистрирането, местонахождението на данните и изходът трябва да се управляват през целия жизнен цикъл. |
Поддържащите стандарти могат да засилят матрицата. ISO/IEC 27017 подпомага специфичните за облака практики за сигурност. ISO/IEC 27018 и ISO/IEC 27701 подпомагат управлението на лично идентифицираща информация (PII) и поверителността. ISO/IEC 27005 подпомага оценката на риска. ISO 22301 подпомага непрекъсваемостта и устойчивостта. ISO/IEC 27035 подпомага управлението на инциденти. ISO/IEC 20000-1 може да помогне, когато облачните услуги са част от предоставянето на управлявани услуги.
Минимално жизнеспособна матрица на споделената отговорност
Зрялата матрица не започва с 200 реда. Тя започва с облачните услуги, които имат най-голямо значение.
За SaaS, fintech или регулирано МСП Clarysec обикновено започва с:
- Продукционна облачна среда, насочена към клиенти.
- Доставчик на идентичност.
- Услуга за управлявана база данни или съхранение.
- Платформа за регистриране, мониторинг и SIEM.
- SaaS за плащания, KYC, анализи или клиентска поддръжка.
- Услуга за резервни копия и аварийно възстановяване.
- Доставчик на управлявани услуги или доставчик на управлявани услуги по сигурността.
- Подизпълнители по обработването, които осъществяват достъп до, съхраняват или обработват клиентски данни.
Първата матрица следва да включва следните колони.
| Колона | Защо е важна |
|---|---|
| Услуга или област на контрол | Идентифицира точната облачна услуга, SaaS продукт или подпроцес в обхвата. |
| Данни и бизнес функция | Свързва услугата с лични данни, критични услуги, финансови функции или съществени операции. |
| Собственик на отговорността | Определя доставчик, клиент, споделена отговорност, подизпълнител по обработването или вътрешен собственик на контрол. |
| Задължение на клиента | Показва какво вашата организация трябва да конфигурира, одобрява, наблюдава или доказва. |
| Задължение на доставчика | Показва какво доставчикът на облачни услуги или SaaS доставчикът трябва да предостави чрез договор, уверение или възможност на платформата. |
| Зависимост от подизпълнител по обработването | Проследява низходящи доставчици, които могат да засегнат сигурността, поверителността, непрекъсваемостта или местонахождението на данните. |
| Контрол от ISO/IEC 27001:2022, Приложение A | Свързва реда с Декларацията за приложимост и обосновката на контрола. |
| Съпоставяне с NIS2, DORA, GDPR, NIST CSF или COBIT 2019 | Показва релевантност към множество рамки за съответствие без дублиране на контроли. |
| Доказателства | Определя готови за одит доказателства. |
| Честота на преглед | Определя ритъма на мониторинг, особено за критични или високорискови доставчици. |
Практически ред за регистриране може да изглежда така.
| Услуга или област на контрол | Собственик на отговорността | Задължение на клиента | Задължение на доставчика | Зависимост от подизпълнител по обработването | Контроли и рамки | Доказателства |
|---|---|---|---|---|---|---|
| Одитно регистриране в продукционен облак | Споделена | Активиране на одитни журнали, определяне на срок за съхранение, ограничаване на достъпа, преглед на предупрежденията и тестване на извличането | Осигуряване на възможност за регистриране, събития на платформата, опции за съхранение и ангажименти за наличност | Доставчик на услуги за регистриране или SIEM, ако журналите се експортират | ISO/IEC 27001:2022, Приложение A, 5.20, 5.23, 8.15, 8.16; NIS2 Article 21; DORA Articles 6, 8, 10, 17; резултати Detect и Govern от NIST CSF 2.0 | Стандарт за регистриране, експорт на облачна конфигурация, примерни журнали, SIEM предупреждения, преглед на достъпа, договорна клауза на доставчика, доказателства за съхранение |
Този ред не е просто документация. Той казва на екипа по сигурност какво да конфигурира, на екипа по закупуване какъв договорен текст да провери, на екипа по поверителност какъв поток от данни да запише и на одиторите какви доказателства да поискат.
Политическа основа: превръщане на матрицата в приложимо изискване
Матрица на споделената отговорност в облака без подкрепа от политика е само електронна таблица. Политиките на Clarysec я правят приложима.
За МСП, Политика за използване на облачни услуги - МСП Политика за използване на облачни услуги - МСП, раздел „Управленски изисквания“, клауза 5.3 изисква:
„Регистър на облачните услуги трябва да се поддържа от ИТ доставчика или GM. Той трябва да записва:“
Същата политика за МСП, клауза 5.2.3, свързва управлението на облачните услуги с поверителността и риска, свързан с местоположението:
„Местонахождението на данните и практиките за поверителност са в съответствие с приложимите правни изисквания (напр. GDPR)“
За корпоративни среди, Политика за използване на облачни услуги Политика за използване на облачни услуги, раздел „Управленски изисквания“, клауза 5.1 посочва:
„Организацията трябва да поддържа централизиран Регистър на облачните услуги, притежаван от CISO, който съдържа:“
След това клауза 5.4 прави облачните отговорности договорно приложими:
„Всички договори с CSP (доставчик на облачни услуги) трябва да включват приложими разпоредби за:“
Управлението на доставчиците разширява матрицата отвъд непосредствения доставчик. Политика за сигурност на трети страни и доставчици - МСП Политика за сигурност на трети страни и доставчици - МСП, раздел „Управленски изисквания“, клауза 5.3.5 изисква:
„Ограничения върху последващо подизпълнение без одобрение“
Същата политика за доставчици за МСП, раздел „Изисквания за внедряване на политиката“, клауза 6.3.1 добавя периодичен преглед:
„Критичните или високорисковите доставчици трябва да се преглеждат най-малко веднъж годишно. Прегледът трябва да проверява:“
На корпоративно ниво, Политика за сигурност на трети страни и доставчици Политика за сигурност на трети страни и доставчици, раздел „Управленски изисквания“, клауза 5.3 посочва:
„Договорите с доставчици трябва да включват:“
За лични данни, Политика за защита на данните и поверителност Политика за защита на данните и поверителност, раздел „Прилагане и съответствие“, клауза 8.5.1 изисква:
„Договорите с обработващи лични данни трябва да включват:“
За видимост върху зависимостите, Политика за управление на риска от зависимости към доставчици Политика за управление на риска от зависимости към доставчици, клауза 6.5.4 изисква:
„Използване на взаимоотношението с доставчика за получаване на актуализации относно подизпълнители или зависимости във веригата на доставки едно ниво надолу по веригата, когато те могат да ни засегнат (например, ако критичен доставчик на софтуер разчита в голяма степен на библиотека от трета страна, това трябва да бъде записано).“
За журналите, Политика за регистриране и мониторинг - МСП Политика за регистриране и мониторинг - МСП, раздел „Управленски изисквания“, клауза 5.5.1.3 предоставя конкретно договорно изискване:
„Договорите трябва да изискват от доставчиците да съхраняват журнали най-малко 12 месеца и да предоставят достъп при поискване“
Заедно тези политики правят матрицата задължителен управленски запис, който подпомага одобрението на доставчици, въвеждането на облачни услуги, отчетността за поверителността, годишния преглед и одиторските доказателства.
Съпоставяне на матрицата спрямо ISO/IEC 27001:2022, NIS2, DORA и GDPR
Класическата грешка е създаването на четири отделни работни книги за съответствие. Един контрол може да покрива няколко задължения, ако отговорността и доказателствата са проследими.
| Област на контрол | ISO/IEC 27001:2022, Приложение A | Доказателства от доставчика | Доказателства от клиента | Съпоставяне между рамки |
|---|---|---|---|---|
| Споразумения с доставчици | 5.20 | Договор, приложение за сигурност, DPA, доклад за уверение, ангажимент за уведомяване при инцидент | Оценка на риска, свързан с доставчика, контролен списък за преглед на договора, запис за одобрение | NIS2 Article 21; DORA Article 30; GDPR Article 28; NIST CSF 2.0 GV.SC |
| Верига за доставки на ИКТ | 5.21 | Списък на подизпълнителите по обработването, условия за подизпълнение, низходящо уверение, уведомления за промени | Регистър на зависимостите, преглед на концентрацията, годишен преглед на доставчика | NIS2 Article 21; DORA Articles 28 and 29; цели за управление на доставчици по COBIT 2019 |
| Използване на облачни услуги | 5.23 | Документация на услугата, опции за местонахождение на данните, инструменти за експорт, поддръжка при изтриване | Регистър на облачните услуги, стандарти за конфигурация, план за изход, преглед на услугата | DORA Articles 6, 8, 28 and 30; GDPR Articles 5, 28 and 32 |
| Идентичност и достъп | 5.15, 5.16, 5.18 | Възможности на IAM, опции за MFA, административни контроли, одитни събития на платформата | Прилагане на MFA, минимално необходим достъп, прегледи на правата за достъп, записи за постъпващи, преместващи се и напускащи служители | NIS2 Article 21(2)(i); DORA Article 9; GDPR Article 32 |
| Регистриране и мониторинг | 8.15, 8.16 | Журнали на платформата, одитни приложно-програмни интерфейси (API), опции за съхранение, уведомления за услугата | Приемане в SIEM, прегледи на предупреждения, настройки за съхранение на журналите, ограничения на достъпа | NIS2 Article 21; DORA Articles 10 and 17; GDPR Article 32 |
| Управление на инциденти | 5.24, 5.25, 5.26, 5.27 | Уведомления за инциденти от доставчика, билети за поддръжка, доклади за анализ на първопричините | Наръчник за инциденти, доказателства за триаж, оценка от регулаторна гледна точка, извлечени поуки | NIS2 Article 23; DORA Articles 17, 18 and 19; GDPR Articles 33 and 34 |
| Непрекъсваемост и изход | 5.29, 5.30, 5.23 | Ангажименти за наличност, инструменти за експорт, сертификат за унищожаване, поддръжка при възстановяване | Тестове на резервни копия, упражнения за възстановяване, тест на изход, отнемане на достъп | DORA Articles 11, 24, 28 and 30; NIS2 Article 21; GDPR Article 28 |
ISO/IEC 27001:2022 предоставя двигателя на СУИС: контекст, заинтересовани страни, обхват, лидерство, третиране на риска, цели, оперативен контрол, оценка на резултатността и подобрение. Приложение A предоставя практическата контролна структура.
NIS2 Article 21 се съпоставя естествено със същата матрица чрез сигурност на веригата на доставки, обработване на инциденти, непрекъсваемост, контрол на достъпа, управление на активите и сигурно придобиване. Article 20 прави матрицата релевантна за съвета, защото органите за управление трябва да одобряват и упражняват надзор върху мерките за управление на риска за киберсигурността.
DORA превръща матрицата в инструмент за ИКТ риск от трети страни. Articles 5, 6 и 8 изискват управление, документирано управление на ИКТ риска и идентификация на активи, функции и зависимости. Articles 17 до 19 изискват откриване, класификация, ескалация, комуникация и докладване на инциденти. Articles 28 до 30 изискват управление на риска от трети страни, анализ на риска от концентрация, договорни клаузи, контроли за подизпълнение, права на одит, права за прекратяване и стратегии за изход.
GDPR добавя гледната точка на личните данни. Всеки ред за облачна услуга трябва да посочва дали се обработват лични данни, дали доставчикът е обработващ лични данни или подизпълнител по обработването, дали местонахождението на данните има значение и какви договорни доказателства или доказателства по DPA съществуват.
NIST CSF 2.0 помага същата матрица да се комуникира на езика на резултатите. Функцията GOVERN обхваща организационен контекст, правни и регулаторни изисквания, зависимости, управление на риска, роли, политики и надзор. Резултатите GV.SC са особено полезни за киберриска, свързан с доставчици, включително роли на доставчици, критичност, договорни изисквания, комплексна проверка, мониторинг, координация при инциденти и планиране на прекратяване.
COBIT 2019 добавя гледна точка за уверение и управление. Той поставя въпроса дали отчетността, управленските практики, собствеността, мониторингът и отстраняването на проблеми са повторяеми и подкрепени с доказателства.
Изграждане на матрицата от регистър до доказателство
Представете си SaaS дружество, което използва хипермащабна IaaS платформа, управлявана база данни, доставчик на идентичност от трета страна, SaaS платформа за клиентска поддръжка и външен SIEM. Потокът за внедряване е ясен.
Стъпка 1: Започнете с Регистъра на облачните услуги
Използвайте Политика за използване на облачни услуги или Политика за използване на облачни услуги - МСП като задействащ механизъм. Запишете всяка облачна услуга, собственик, цел, категории данни, местоположение, бизнес функция, ниво на доставчика, собственик на договора и дата на преглед.
Ако услугата съхранява клиентски записи, журнали за автентикация или билети за поддръжка, маркирайте я като релевантна за поверителността. Ако поддържа наличност на продукционна среда, маркирайте я като оперативно критична. Ако поддържа критична или важна функция на финансов клиент, маркирайте я като релевантна за DORA.
Стъпка 2: Добавете области на споделена отговорност
За всяка услуга определете отговорностите в основните области.
| Област | Типична отговорност на доставчика | Типична отговорност на клиента | Типичен въпрос за подизпълнител по обработването |
|---|---|---|---|
| Физическа и инфраструктурна сигурност | Съоръжения, хардуер, контроли на средата, устойчивост на платформата | Преглед на доклади за уверение и договорни ангажименти | Разчита ли доставчикът на център за данни, CDN или хостинг подизпълнител по обработването? |
| Идентичност и достъп | Възможности на платформата за IAM, административни функции за сигурност, поддръжка на федерация | MFA, дизайн на роли, минимално необходим достъп, прегледи за постъпващи, преместващи се и напускащи служители | Има ли брокер на идентичности или доставчик на поддръжка достъп до акаунти? |
| Защита на данните | Опции за шифроване, опции за местонахождение на данните, функции за резервни копия | Класификация, конфигурация на шифроването, срок за съхранение, правно основание | Съхранява ли или осъществява ли достъп до лични данни някой подизпълнител по обработването? |
| Регистриране и мониторинг | Генериране на събития, одитни приложно-програмни интерфейси (API), телеметрия на платформата | Активиране на журнали, експорт към SIEM, преглед на предупреждения, съхраняване на доказателства | Обработва ли доставчикът на SIEM или MDR журнали, съдържащи лични данни? |
| Реагиране при инциденти | Откриване от доставчика, уведомления за инциденти на платформата, ескалация към поддръжка | Вътрешен триаж, уведомления до регулатори и клиенти, форензично запазване на доказателства | Могат ли низходящи инциденти да забавят уведомяването или анализа на първопричините? |
| Непрекъсваемост и изход | Ангажименти за наличност на платформата, инструменти за експорт, поддръжка при изтриване | Цели за възстановяване, тестване на резервни копия, план за изход, връщане или унищожаване на данни | Има ли ограничения за възстановяване, произтичащи от подизпълнени услуги или местоположения? |
Стъпка 3: Свържете контролите с риска и Декларацията за приложимост
Zenith Blueprint, фазата Risk Management, Step 13, обяснява изискването за проследимост:
„Кръстосано съпоставяне с регулациите: ако определени контроли се внедряват специално за спазване на GDPR, NIS2 или DORA, можете да отбележите това или в Регистъра на риска (като част от обосновката на въздействието на риска), или в бележките към SoA.“
Например рискът „неоторизиран достъп до клиентски продукционни данни чрез неправилна облачна конфигурация“ може да се съпостави с контрол на достъпа, използване на облачни услуги, регистриране, криптография, управление на уязвимостите и споразумения с доставчици. SoA може да посочва ISO/IEC 27001:2022, Приложение A, 5.15, 5.16, 5.20, 5.23, 8.8, 8.15, 8.16 и 8.24, с бележки за GDPR Article 32, NIS2 Article 21 и управление на ИКТ риска по DORA, когато е приложимо.
Стъпка 4: Прикрепете доказателствата преди одитния сезон
Доказателствата трябва да бъдат проектирани в матрицата, а не да се събират в паника.
| Ред в матрицата | Доказателства за съхраняване |
|---|---|
| Комплексна проверка на доставчик на облачни услуги | Оценка на доставчика, въпросник по сигурност, доклад за уверение, сертификации, рискова оценка, запис за одобрение |
| Договорни ангажименти за сигурност | MSA, DPA, приложение за сигурност, права на одит, клауза за подизпълнение, клауза за уведомяване при инцидент, условия за местонахождение на данните |
| Отговорност на клиента за конфигурацията | Експорт на облачна конфигурация, IAM политика, отчет за MFA, настройки за шифроване, мрежови правила, билети за промени |
| Регистриране и мониторинг | Настройки за съхранение на журналите, примерни одитни журнали, доказателство за приемане в SIEM, записи от преглед на предупреждения, билети за ескалация |
| Проследимост на подизпълнители по обработването | Списък на подизпълнителите по обработването на доставчика, запис за одобрение, карта на потока на данните, бележки от годишен преглед, уведомление за промени |
| Изход и възстановяване | Резултати от тестове на резервни копия, тест за експорт на данни, сертификат за унищожаване, план за изход, доклад от упражнение за възстановяване |
Списъкът с доказателства превръща отговорността в доказуемост. Той също така помага на търговските екипи да отговарят по-бързо на корпоративни комплексни проверки, защото могат да покажат не само сертификации, а и собственост върху контролите и оперативни доказателства.
Подизпълнителите по обработването: сляпата зона в повечето матрици
Подизпълнителите по обработването са мястото, където споделената отговорност се превръща в реален риск във веригата на доставки.
SaaS доставчик може да бъде вашият обработващ лични данни по GDPR. Този доставчик може да разчита на доставчик на облачен хостинг, CDN, услуга за анализи, платформа за поддръжка, услуга за изпращане на електронна поща, управлявана база данни, доставчик на наблюдаемост и обработващ плащания. Някои могат да имат достъп до лични данни. Други могат да поддържат критично предоставяне на услуги, без директно да виждат данни. Някои могат да бъдат извън ЕС. Някои могат да бъдат заменяеми. Други могат да създадат риск от концентрация.
DORA Article 29 изисква оценка на риска от концентрация за критични или важни ИКТ услуги, включително възможност за замяна, множество договорености със същите или свързани доставчици, вериги на подизпълнение, подизпълнители в трети държави, право по несъстоятелност, ограничения за възстановяване на данни и приложимост на защитата на данните в Съюза. DORA Article 30 изисква договорни разпоредби относно условията за подизпълнение, местоположенията, обработването и съхранението на данни, достъпа и възстановяването, съдействието при инциденти, сътрудничеството с органи, правата на одит, прекратяването и изхода.
NIS2 Article 21 по сходен начин изисква сигурност на веригата на доставки за преки доставчици и доставчици на услуги, както и отчитане на специфични за доставчика уязвимости, практики за киберсигурност на доставчика и процедури за сигурна разработка.
Затова Clarysec третира картирането на подизпълнителите по обработването като задължително разширение на управлението на доставчици, а не като списък само за целите на поверителността. Регистърът на подизпълнителите по обработването трябва да показва кой доставчик използва подизпълнителя по обработването, коя услуга зависи от него, дали се обработват лични данни, дали поддържа критична функция, регион на обработване, когато е релевантно, прехвърляне на договорни изисквания надолу по веригата, права за одобрение или възражение, налично уверение, метод за мониторинг и опция за изход.
Zenith Blueprint, фазата Controls in Action, Step 23 посочва:
„За всеки критичен доставчик идентифицирайте дали използва подизпълнители (подизпълнители по обработване), които могат да имат достъп до вашите данни или системи. Документирайте как вашите изисквания за информационна сигурност се прехвърлят към тези страни чрез договорните условия на вашия доставчик или чрез ваши преки клаузи.“
Това е нивото на доказателства, което одиторите очакват, когато питат дали облачните отговорности са контролирани надолу по веригата.
Как одиторите тестват същата матрица
Силната матрица на споделената отговорност в облака издържа различни одитни подходи, защото е изградена около собственост, приложимост и доказателства.
| Одитна гледна точка | Какво ще тества одиторът | Какви доказателства ще очаква |
|---|---|---|
| Одитор по ISO/IEC 27001:2022 | Обхват на СУИС, заинтересовани страни, оценка на риска, приложимост на SoA, контроли за доставчици, използване на облачни услуги, оперативни доказателства и непрекъснато подобрение | Обхват на СУИС, регистър на риска, SoA, регистър на доставчиците, регистър на облачните услуги, договори, записи от прегледи, констатации от вътрешен одит, коригиращи действия |
| Преглеждащ готовността по NIS2 | Одобрение от ръководството, покритие на контролите по Article 21, сигурност на веригата на доставки, обработване на инциденти, непрекъсваемост, достъп, управление на активи и оценка на ефективността | Доклади до съвета, одобрения на политики, прегледи на риска, свързан с доставчици, наръчници за инциденти, тестове за непрекъсваемост, доказателства за MFA, записи за уязвимости и регистриране |
| Оценител по DORA | Управление на ИКТ, рамка за ИКТ риск, инвентар на активи и зависимости, критични договорености с трети страни за ИКТ, договорни клаузи, риск от концентрация, тестване и стратегия за изход | Рамка за управление на ИКТ риска, регистър на ИКТ услугите, оценка на критичността, договори, права на одит, записи за инциденти, тестове за устойчивост, тестове за изход, анализ на подизпълнение |
| Преглеждащ по GDPR | Роли на администратор и обработващ лични данни, цели на обработването на данни, цялостност и поверителност, готовност при нарушение, договори с обработващи лични данни и прозрачност на подизпълнителите по обработването | Регистър на дейностите по обработване, DPA, списък на подизпълнителите по обработването, карта на потока на данните, мерки за сигурност, процедура при нарушение, доказателства за съхранение и изтриване |
| Оценител по NIST CSF | Резултати по GOVERN, киберриск, свързан с доставчици, инвентар на активите, контрол на достъпа, сигурност на данните, мониторинг, реагиране и възстановяване | Текущи и целеви профили, процес за риск, свързан с доставчици, инвентар на активите, отчети за достъп, записи от мониторинг, упражнения за инциденти, доказателства за възстановяване |
| Одитор по COBIT 2019 или ISACA | Управленска отчетност, управленски практики, собственост върху контролите, мониторинг на резултатността, управление на проблеми и проследимост на уверението | RACI, протоколи от управленски срещи, изключения от политики, KPI, оценъчни карти на доставчици, журнали за проблеми, резултати от прегледа от ръководството |
Матрицата не е крайната цел. Тя е картата, която одиторите използват, за да тестват дали системата за управление е реална.
ISO одитор може да избере облачен риск за достъп с високо въздействие и да го проследи от регистъра на риска до SoA, след това до прегледи на достъпа, доказателства за MFA и предупреждения от мониторинг. Оценител по DORA може да избере критичен ИКТ доставчик и да поиска теста за изход, анализа на подизпълнение и договорните права на одит. Преглеждащ по GDPR може да се фокусира върху изтриване, местонахождение на данните, уведомяване при нарушение и прозрачност на подизпълнителите по обработването.
Чести модели на неуспех
Най-честите неуспехи при споделената отговорност не са екзотични.
Първо, организациите разчитат на доклади за уверение от доставчика, без да ги съпоставят с отговорностите на клиента. Доставчик на облачни услуги може да докаже физическа сигурност, устойчивост на инфраструктурата и контроли на платформата, но не и дали вашето облачно хранилище е било частно, IAM ролите са били с минимално необходим достъп или журналите са били активирани.
Второ, договорите съдържат общ език за сигурност, но без срокове за инциденти, права за достъп до журнали, права на одит, ограничения за подизпълнение, разпоредби за връщане на данни или поддръжка при изход. Zenith Blueprint, фазата Controls in Action, Step 23 подчертава типични области в споразуменията с доставчици, като поверителност, контрол на достъпа, технически и организационни мерки, срокове при инциденти, право на одит, контроли за подизпълнители и разпоредби при приключване на договора.
Трето, подизпълнителите по обработването са изброени за целите на поверителността, но не са свързани със сигурността, непрекъсваемостта или риска от концентрация. Низходящ доставчик за наблюдаемост или поддръжка може изобщо да не се появи в регистъра на риска, въпреки че негово прекъсване или нарушение може да засегне предоставянето на клиентска услуга.
Четвърто, SoA посочва, че даден контрол е приложим, но никой не може да предостави оперативни доказателства. Регистрирането в облака може да е отбелязано като внедрено, но организацията да не може да докаже настройки за съхранение, прегледи на достъпа, обработване на предупреждения или ангажименти на доставчика за достъп до журнали.
Пето, плановете за реагиране при инциденти не отразяват зависимостта от доставчика. Ако доставчикът уведоми за инцидент в платформата, кой оценява въздействието върху клиента? Кой определя дали е необходимо уведомяване по NIS2, DORA или GDPR? Кой се свързва със засегнатите клиенти? Какво става, ако първопричината е при подизпълнител по обработването?
Отчетност на ръководството: защо съветът трябва да се интересува
NIS2 Article 20 изисква органите за управление да одобряват мерките за управление на риска за киберсигурността, да упражняват надзор върху внедряването и да получават обучение. DORA Article 5 изисква органът за управление да определя, одобрява, упражнява надзор и носи отговорност за договореностите за управление на ИКТ риска, включително политики за трети страни в областта на ИКТ, планове за непрекъсваемост и възстановяване, планове за одит, обучение и канали за докладване.
Това променя предназначението на матрицата. Тя вече не е само работен лист за сигурността. Тя се превръща в доказателство, че ръководството знае:
- Кои облачни услуги поддържат критични операции.
- Кои трети страни и подизпълнители по обработването са съществени.
- Кои задължения се прилагат по клиентски договори, GDPR, NIS2 и DORA.
- Кои отговорности остават в организацията.
- Кои ангажименти на доставчика са договорно приложими.
- Кои пропуски изискват финансиране, отстраняване или приемане на риска.
За МСП пропорционалността има значение. По-малък субект не се нуждае от тежка бюрокрация, но все пак се нуждае от документация, мониторинг, устойчиви системи, откриване на източници на ИКТ риск, идентифициране на ключови зависимости от трети страни, мерки за непрекъсваемост, тестване, извлечени поуки и периодичен преглед, когато е в обхвата.
Матрицата е един от най-ефективните пропорционални инструменти, защото консолидира задълженията, вместо да ги умножава.
30-дневен спринт, за да направите вашия облачен модел готов за одит
Ако не можете да отговорите кой отговаря за всеки облачен контрол, какви доказателства го потвърждават и кой подизпълнител по обработването може да му повлияе, вашият модел на споделена отговорност все още е диаграма, а не управленски артефакт.
Практическият 30-дневен спринт изглежда така:
- Създайте или актуализирайте Регистъра на облачните услуги, като използвате Политика за използване на облачни услуги или Политика за използване на облачни услуги - МСП.
- Идентифицирайте критични услуги, обработване на лични данни, клиентски системи и релевантност към DORA или NIS2.
- Изградете първата матрица около контролите 5.20, 5.21 и 5.23 от ISO/IEC 27001:2022, Приложение A, като използвате Zenith Controls.
- Свържете всеки ред с регистъра на риска и Декларацията за приложимост, като използвате Step 13 от Zenith Blueprint.
- Валидирайте клаузите за доставчици и обработващи лични данни, като използвате Политика за сигурност на трети страни и доставчици, Политика за сигурност на трети страни и доставчици - МСП и Политика за защита на данните и поверителност.
- Добавете доказателства за съхранение на журнали, ескалация при инциденти, одобрение на подизпълнители по обработването, права на одит и изход.
- Преглеждайте критичните доставчици ежегодно и след съществени промени, инциденти, нови подизпълнители по обработването или одитни констатации.
Целта е проста. Когато клиентът, одиторът, регулаторът или съветът попита „кой отговаря за този контрол?“, не търсите в договори, билети и папки. Отваряте матрицата, показвате собственика, показвате клаузата, показвате доказателствата и показвате следата надолу по веригата.
Clarysec може да ви помогне да превърнете пакетите за уверение от доставчици на облачни услуги в интегрирана матрица на споделената отговорност за одити по ISO/IEC 27001:2022, готовност по NIS2, ИКТ риск от трети страни по DORA, отчетност по GDPR и комплексна проверка от корпоративни клиенти.
Започнете с регистъра. Изградете матрицата. Прикрепете доказателствата. След това я използвайте като готово за съвета доказателство, че облачният риск не е възложен навън — той се управлява.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
