Одитни доказателства за облачни услуги за ISO 27001, NIS2 и DORA

Мария, директор по информационна сигурност (CISO) в бързоразвиваща се компания за финансови анализи, имаше шест седмици, преди три крайни срока да се съберат в една точка. Надзорният ѝ одит по ISO 27001:2022 вече беше планиран. NIS2 беше поставила компанията на ново ниво на управленска отчетност като важен субект. DORA предстоеше да провери дали финтех операциите ѝ могат да докажат цифрова оперативна устойчивост. В същото време голям корпоративен клиент задържаше договор, докато екипът ѝ не премине подробен преглед за уверение по сигурността.

Компанията не беше несигурна. Тя изпълняваше продукционни работни натоварвания в AWS и Azure, използваше Microsoft 365 и няколко критични SaaS платформи, прилагаше MFA, архивираше данни, сканираше за уязвимости и събираше облачни журнали. Проблемът беше доказването.

Доказателствата бяха разпръснати между екранни снимки от Slack, wiki страници на разработчиците, експорти от облачни конзоли, папки на екипа по снабдяване, правни договори и устни уверения от собственици на платформи. Когато одитор попита: „Покажете ми как контролирате облачната си среда“, връзка към страница за съответствие на облачния доставчик не е достатъчна. Сертификатите на доставчика доказват контролите на доставчика. Те не доказват частта на Мария в модела на споделена отговорност.

Точно там се провалят много програми за одитни доказателства за сигурността на облачни услуги. Не защото липсват контроли, а защото организацията не може да докаже по структуриран и проследим начин кои отговорности са на доставчика, кои са на клиента, как са конфигурирани контролите за SaaS и IaaS, как се прилагат ангажиментите на доставчиците и как доказателствата се съхраняват за одитори, регулатори и клиенти.

Съответствието в облака вече не е техническо приложение. За доставчик на SaaS по NIS2, финансова организация по DORA или всяка организация по ISO 27001:2022, която използва IaaS, PaaS и SaaS, управлението на облачни услуги е част от обхвата на ISMS, плана за третиране на риска, жизнения цикъл на доставчиците, процеса за инциденти, отчетността за поверителност и прегледа от ръководството.

Практическата цел е проста: изграждане на единна архитектура за облачни доказателства, готова за регулаторна проверка, която отговаря на въпроси по ISO 27001:2022, NIS2, DORA, GDPR, клиентско уверение и вътрешен одит, без доказателствата да се изграждат наново за всяка рамка.

Облакът винаги е в обхват, дори когато инфраструктурата е възложена на външен изпълнител

Първият одитен капан е допускането, че външно възложената инфраструктура е извън ISMS. Не е така. Външното възлагане променя границата на контролите, но не премахва отчетността.

ISO/IEC 27001:2022 изисква организацията да дефинира своя контекст, заинтересовани страни, обхват на ISMS, интерфейси, зависимости и процеси. В бизнес, ориентиран към облака, доставчикът на идентичност, акаунтът за облачен хостинг, CRM, платформата за електронна поща, хранилището за данни, CI/CD конвейерът, системата за билети и услугата за резервни копия често са основна бизнес инфраструктура.

Zenith Blueprint: 30-стъпкова пътна карта за одитори на Clarysec Zenith Blueprint поставя този акцент във фазата ISMS Foundation & Leadership, Step 2, Stakeholder Needs and ISMS Scope:

„Ако възложите своята ИТ инфраструктура на доставчик на облачни услуги, това не я изключва от обхвата; напротив, включвате управлението на това взаимоотношение и облачните активи като част от обхвата (защото сигурността на вашите данни в облака е ваша отговорност).“

Това твърдение е одитна опорна точка. Обхватът не трябва да казва: „AWS е изключен, защото Amazon го управлява.“ Той трябва да посочва, че информационните активи и процеси, свързани с услуги, хоствани в AWS, са в обхват, включително управление на контролите за облачна сигурност, идентичност, журналиране, шифроване, архивиране, уверение от доставчици и реагиране при инциденти.

За ISO 27001:2022 това подкрепя клаузи 4.1 до 4.4 относно контекста, заинтересованите страни, обхвата и процесите на ISMS. За NIS2 подкрепя очакванията по Article 21 за анализ на риска, обработване на инциденти, непрекъсваемост на дейността, сигурност на веригата на доставки, сигурно придобиване и поддръжка, контрол на достъпа, управление на активите, криптография, ефективност на контролите и MFA, когато е приложимо. За DORA подкрепя принципа, че финансовите организации остават отговорни за ИКТ риска дори когато ИКТ услугите са възложени на външен изпълнител.

Въпросът не е дали вашият доставчик на облачни услуги е сигурен. Въпросът е дали управлявате използването му, конфигурирате правилно своята част, наблюдавате услугата, управлявате ангажиментите на доставчика и съхранявате доказателства.

Споделената отговорност трябва да се превърне в споделени доказателства

Доставчиците на облачни услуги обясняват споделената отговорност. Одиторите проверяват дали сте я приложили на практика.

При IaaS доставчикът обикновено защитава физическите съоръжения, базовата инфраструктура и хипервайзора. Клиентът контролира идентичността, конфигурацията на работните натоварвания, укрепването на операционната система, сигурността на приложенията, класификацията на данните, настройките за шифроване, мрежовите правила, журналирането, резервните копия, прилагането на корекции и реагирането при инциденти.

При SaaS доставчикът контролира повечето платформени операции, но клиентът продължава да контролира конфигурацията на клиентската среда, потребителите, администраторските роли, интеграциите, споделянето на данни, съхранението, опциите за журналиране и процедурите за ескалация.

Zenith Controls: ръководство за кръстосано съответствие на Clarysec Zenith Controls третира ISO/IEC 27002:2022 control 5.23, информационна сигурност при използването на облачни услуги, като централен контрол за управление на облачни услуги с превантивна цел за поверителност, цялостност и наличност. Той свързва облачните услуги с взаимоотношенията с доставчици, сигурния пренос на информация, инвентара на активите, предотвратяването на изтичане на данни, сигурността на крайните точки и мрежите и практиките за сигурна разработка.

Ключова интерпретация в Zenith Controls посочва:

„Доставчиците на облачни услуги (CSP) функционират като критични доставчици и поради това всички контроли относно избор на доставчици, договаряне и управление на риска по 5.19 се прилагат. 5.23 обаче отива по-далеч, като разглежда специфични за облака рискове, като мултитенантност, прозрачност на местонахождението на данните и модели на споделена отговорност.“

Това разграничение е критично. Сертификатите на доставчика сами по себе си не удовлетворяват Annex A.5.23. Необходими са клиентски доказателства, че облачната услуга се управлява, конфигурира, наблюдава и преглежда.

Това е разликата между наличие на облачни контроли и наличие на облачни контроли, готови за одит.

Започнете с Регистър на облачните услуги, който одиторите могат да използват

Най-бързият начин за подобряване на готовността за облачен одит е създаването на пълен Регистър на облачните услуги. Той не трябва да бъде списък на покупките или финансов експорт. Трябва да свързва облачните услуги с данни, собственици, региони, достъп, договори, критичност, регулаторна релевантност и доказателства.

Политика за използване на облачни услуги за МСП на Clarysec Cloud Usage Policy-sme дава компактна и удобна за одит база в клауза 5.3:

„Регистър на облачните услуги трябва да се поддържа от доставчика на ИТ услуги или от управителя. Той трябва да записва: 5.3.1 Името и предназначението на всяка одобрена облачна услуга 5.3.2 Отговорното лице или екип (собственик на приложение) 5.3.3 Видовете данни, които се съхраняват или обработват 5.3.4 Държавата или региона, в който се съхраняват данните 5.3.5 Разрешенията за потребителски достъп и административните акаунти 5.3.6 Данни за договора, дати за подновяване и контакти за поддръжка“

За корпоративни среди Политика за използване на облачни услуги на Clarysec Cloud Usage Policy установява по-широкия мандат:

„Тази политика установява задължителните изисквания на организацията за сигурно, съответстващо и отговорно използване на услуги за облачни изчисления в моделите инфраструктура като услуга (IaaS), платформа като услуга (PaaS) и софтуер като услуга (SaaS).“

Политика за използване на облачни услуги изисква централизиран регистър, собственост на CISO, и одобрени базови конфигурации за облачни среди. Този регистър се превръща в доказателствена основа за няколко задължения едновременно.

За ISO 27001:2022 той подкрепя инвентара на активите, управлението на използването на облачни услуги, взаимоотношенията с доставчици, контрола на достъпа, правните и договорните изисквания, третирането на риска и документираната информация. За NIS2 подкрепя сигурността на веригата на доставки, управлението на активите, анализа на риска, обработването на инциденти и непрекъсваемостта. За DORA подкрепя картографирането на ИКТ активи и зависимости, регистрите за ИКТ трети страни, картографирането на критични или важни функции и анализа на риска от концентрация. За GDPR идентифицира дали се обработват лични данни, къде се намират, кой доставчик действа като обработващ лични данни и кои условия за трансфер или обработване на данни се прилагат.

Ако регистърът не идентифицира категориите данни и регионите, доказателствата за поверителност и устойчивост ще бъдат непълни. Ако не идентифицира собствениците на приложения, прегледите на правата за достъп ще останат без отговорник. Ако не идентифицира договорите и датите за подновяване, клаузите за сигурност на доставчиците не могат да бъдат тествани.

Превърнете ISO 27001:2022 в гръбнак на облачните доказателства

ISO 27001:2022 е най-добрият гръбнак за облачни доказателства, защото свързва бизнес контекста, риска, контролите, оперативните доказателства, мониторинга и подобрението.

Ключовите изисквания на ISO 27001:2022, релевантни за облака, включват:

• Клаузи 4.1 до 4.4 за контекст, заинтересовани страни, обхват на ISMS, интерфейси, зависимости и процеси.
• Клаузи 5.1 до 5.3 за лидерство, политика, роли, отговорности и отчетност.
• Клаузи 6.1.1 до 6.1.3 за оценка на риска, третиране на риска, сравнение с Annex A, Декларация за приложимост и приемане на остатъчния риск.
• Клауза 7.5 за контролирана документирана информация.
• Клаузи 8.1 до 8.3 за оперативно планиране, изпълнение на оценката на риска и изпълнение на третирането на риска.
• Клаузи 9.1 до 9.3 за мониторинг, измерване, вътрешен одит и преглед от ръководството.
• Клауза 10 за несъответствие, коригиращо действие и непрекъснато подобрение.

Контролите от Annex A, които носят най-голяма тежест за облачните доказателства, включват A.5.19 Информационна сигурност във взаимоотношенията с доставчици, A.5.20 Разглеждане на информационната сигурност в споразуменията с доставчици, A.5.21 Управление на информационната сигурност във веригата на доставки на ИКТ, A.5.22 Мониторинг, преглед и управление на промените в услугите на доставчици, A.5.23 Информационна сигурност при използване на облачни услуги, A.5.24 до A.5.27 управление на инциденти, A.5.29 Информационна сигурност по време на прекъсване, A.5.30 готовност на ИКТ за непрекъсваемост на дейността, A.5.31 Правни, законови, регулаторни и договорни изисквания, A.5.34 Поверителност и защита на PII, A.5.36 Съответствие с политики, правила и стандарти за информационна сигурност, A.8.8 Управление на технически уязвимости, A.8.9 Управление на конфигурацията, A.8.13 Архивиране на информация, A.8.15 Журналиране, A.8.16 Дейности по мониторинг, A.8.24 Използване на криптография, A.8.25 Сигурен жизнен цикъл на разработка, A.8.29 Тестване на сигурността при разработка и приемане и A.8.32 Управление на промените.

В Zenith Blueprint фазата Controls in Action, Step 23, обяснява облачните услуги с език, който резонира с одиторите:

„Преминаването към облачни услуги въвежда съществени промени в модела на доверие. Вече не контролирате сървъра, мрежовия периметър или хипервайзора. Често дори не знаете къде физически се намират данните. Това, което контролирате, и което този контрол налага, е управлението на това взаимоотношение, видимостта върху това, което използвате, и очакванията за сигурност, които поставяте към своите доставчици.“

Силна позиция в Декларацията за приложимост за A.5.23 не трябва да казва само „Приложимо, облачният доставчик е сертифициран“. Тя трябва да обяснява защо контролът се прилага, кои рискове третира, как е внедрен и къде се съхраняват доказателствата.

Добавете колона за местоположението на доказателствата в SoA или инструмента за проследяване на контролите. Одиторите не трябва да търсят в електронна поща, системи за билети и споделени дискове, за да намерят доказателства.

Използвайте един модел на доказателства за ISO 27001:2022, NIS2 и DORA

NIS2 и DORA изискват документирана, риск-базирана и управлявана от ръководството киберсигурност. Припокриването е значително, но надзорният натиск е различен.

NIS2 се прилага за много съществени и важни субекти в ЕС, включително доставчици на цифрова инфраструктура, доставчици на управлявани услуги, доставчици на управлявани услуги за сигурност, банковия сектор, инфраструктури на финансовите пазари и цифрови доставчици. Article 21 изисква подходящи и пропорционални технически, оперативни и организационни мерки, включително анализ на риска, обработване на инциденти, непрекъсваемост на дейността, сигурност на веригата на доставки, сигурно придобиване и поддръжка, обработване на уязвимости, оценка на ефективността на контролите, киберхигиена, обучение, криптография, контрол на достъпа, управление на активите и MFA или сигурни комуникации, когато е приложимо.

За одитните доказателства за сигурността на облачни услуги NIS2 пита дали рисковете, свързани с облака и доставчиците, се управляват като част от риска при предоставяне на услуги. Тя въвежда и структурирано докладване на значими инциденти, включително ранно предупреждение в рамките на 24 часа, уведомление за инцидент в рамките на 72 часа и окончателен доклад в рамките на един месец.

DORA се прилага от 17 януари 2025 г. за много финансови организации в ЕС и създава единни изисквания за управление на ИКТ риска, докладване на съществени ИКТ инциденти, тестване на цифровата оперативна устойчивост, споделяне на информация и ИКТ риск от трети страни. За финансови организации, които също са идентифицирани по NIS2, DORA се третира като секторно-специфичен правен акт на Съюза за припокриващи се оперативни задължения.

За облака DORA е пряка. Финансовите организации остават отговорни за ИКТ риска, когато услугите са възложени на външен изпълнител. Те се нуждаят от стратегии за ИКТ трети страни, договорни регистри, оценки преди сключване на договор, надлежна проверка, права на одит и достъп, условия за прекратяване, анализ на риска от концентрация, контроли за подизпълнители и тествани стратегии за изход.

Zenith Controls картографира ISO/IEC 27002:2022 control 5.23 към EU NIS2 Article 21 и DORA Articles 28 to 31. Той посочва и подкрепящи стандарти като ISO/IEC 27017 за роли и мониторинг при облачна сигурност, ISO/IEC 27018 за защита на PII в публичен облак, ISO/IEC 27701 за управление на поверителността във взаимоотношения с облачни обработващи, ISO/IEC 27036-4 за мониторинг на облачни услуги и споразумения с доставчици и ISO/IEC 27005 за оценка на риска в облака.

Практическото следствие е просто. Не изграждайте отделни пакети с доказателства за ISO 27001:2022, NIS2, DORA и GDPR. Изградете една архитектура за облачни доказателства с картографиране към конкретните рамки.

Договорите с доставчици са доказателства за контрол, а не правни архиви

Одитните доказателства за облачни услуги често се провалят на договорно ниво. Сигурността има въпросник за доставчика. Правният отдел има MSA. Снабдяването има датата за подновяване. Длъжностното лице по защита на данните (DPO) има DPA. Никой няма единен поглед дали споразумението включва клаузите за сигурност, изисквани от ISO 27001:2022, NIS2, DORA и GDPR.

Политика за сигурност на трети страни и доставчици за МСП на Clarysec Third-Party and Supplier Security Policy-sme посочва в клауза 5.3:

„Договорите трябва да включват задължителни клаузи, обхващащи: 5.3.1 Поверителност и неразкриване 5.3.2 Задължения за информационна сигурност 5.3.3 Срокове за уведомяване при нарушение на сигурността на данните (напр. в рамките на 24–72 часа) 5.3.4 Права на одит или наличие на доказателства за съответствие 5.3.5 Ограничения за последващо подизпълнение без одобрение 5.3.6 Условия за прекратяване, включително сигурно връщане или унищожаване на данни“

За одитна последователност превърнете тези клаузи в матрица за преглед на договори. ISO 27001:2022 Annex A.5.20 очаква изискванията за сигурност да бъдат договорени с доставчиците. GDPR Article 28 изисква условия за обработващи, обхващащи поверителност, мерки за сигурност, съдействие, подизпълнители по обработване, изтриване или връщане на данни и одитна подкрепа. DORA Article 30 изисква подробни договорни разпоредби за ИКТ доставчици от трети страни, включително описания на услуги, местонахождение на данните, сигурност, съдействие при инциденти, сътрудничество с органи, права на одит, права на достъп, прекратяване и преходни договорености. Сигурността на веригата на доставки по NIS2 също изисква приложимо сътрудничество от доставчиците.

Zenith Controls картографира ISO/IEC 27002:2022 control 5.20 към споразумения с доставчици и отбелязва връзки с 5.19 взаимоотношения с доставчици, 5.14 пренос на информация, 5.22 мониторинг на доставчици, 5.11 връщане на активи и 5.36 съответствие.

Ключовият момент е прилагането на практика. Ако облачен договор предоставя достъп до SOC 2 доклади, одиторите могат да попитат дали сте получили доклада, прегледали сте изключенията, проследили сте коригиращите действия и сте преоценили риска. Ако договорът обещава уведомяване при нарушение, те могат да попитат дали вашият наръчник за инциденти включва пътя за контакт с доставчика и регулаторните точки за вземане на решение. Ако промените при подизпълнители изискват одобрение или уведомление, те могат да попитат дали уведомленията за подизпълнители по обработване се преглеждат преди приемане.

Договор без доказателства за преглед е архив. Договор, свързан с риск от доставчика, записи за мониторинг и работни потоци за инциденти, е контрол.

Журналирането и конфигурацията на SaaS са чести слепи петна при одит

Констатациите за облака често идват от SaaS, а не от IaaS. Инфраструктурните екипи обикновено имат инженерни собственици, потоци за журналиране, базови контроли и записи за промени. SaaS платформите са разпокъсани между продажби, HR, финанси, customer success, маркетинг и операции. Всяка от тях може да обработва чувствителни или регулирани данни.

Политика за журналиране и мониторинг за МСП на Clarysec Logging and Monitoring Policy-sme разглежда това директно в клауза 5.5:

„5.5 Облачни услуги и журналиране от трети страни 5.5.1 За платформи, при които журналирането не е под пряк ИТ контрол (напр. SaaS електронна поща), се прилагат следните изисквания: 5.5.1.1 Журналирането трябва да бъде активирано и конфигурирано, когато е налично 5.5.1.2 Предупрежденията трябва да се маршрутизират към доставчика на ИТ поддръжка 5.5.1.3 Договорите трябва да изискват от доставчиците да съхраняват журнали поне 12 месеца и да предоставят достъп при поискване“

За корпоративни среди Политика за използване на облачни услуги добавя:

„Облачните услуги трябва да бъдат интегрирани в SIEM на организацията за непрекъснат мониторинг.“

Това изискване премества SaaS от „бизнес инструмент“ към „наблюдавана информационна система“. Доказателствата трябва да включват експорти на настройки за журналиране, доказателство за SIEM конектор, правила за предупреждения, билети за триаж, настройки за съхранение и прегледи на административния достъп.

За критични SaaS подгответе доказателства за създаване на администраторски акаунти, подозрителни вписвания, масови изтегляния, публично споделяне, деактивиране на MFA, създаване на API токени, дейност на външни гости и ескалация на привилегии. За IaaS подгответе CloudTrail или еквивалентно журналиране на контролната равнина, журнали за достъп до хранилища, IAM промени, flow logs, когато е приложимо, CSPM констатации, сканирания за уязвимости, доказателства за корекции, настройки за шифроване, статус на резервни копия, прегледи на групи за мрежова сигурност и билети за промени.

Одитната методология на Zenith Controls за control 5.23 отбелязва, че одит в стил ISO/IEC 27007 може да инспектира разрешения на AWS S3 bucket, шифроване, IAM политики и CloudTrail журналиране. Одитор, ориентиран към COBIT, може да преглежда конфигурации на предупреждения, DLP контроли, използване на Microsoft 365 Secure Score и журнали за управление на промените. Подход по NIST SP 800-53A може да тества управление на акаунти и мониторинг, включително дали облачните работни натоварвания се коригират, сканират и наблюдават със същата строгост като вътрешните системи.

Различните одитори говорят на различни диалекти. Вашите доказателства трябва да бъдат едни и същи.

Изградете готов за регулаторна проверка пакет с доказателства за една SaaS и една IaaS услуга

Практическият работен поток започва с една критична SaaS платформа и една критична IaaS среда. Например Microsoft 365 за сътрудничество и AWS за продукционен хостинг.

Стъпка 1: Актуализирайте Регистъра на облачните услуги

За Microsoft 365 запишете предназначение, собственик, типове данни, регион, администраторски акаунти, договор, DPA, контакт за поддръжка, дата за подновяване и критичност. За AWS запишете продукционния акаунт, региони, категории данни, работни натоварвания, собственик на акаунта, статус на root акаунта, план за поддръжка, договорни условия и свързани бизнес услуги.

Използвайте полетата от Политика за използване на облачни услуги за МСП като минимален набор от данни. Добавете критичност, регулаторна релевантност и местоположение на доказателствата.

Стъпка 2: Документирайте споделената отговорност

За Microsoft 365 отговорностите на клиента включват жизнения цикъл на потребителите, MFA, условен достъп, споделяне с гости, етикети за съхранение, DLP, когато се използва, журналиране и ескалация при инциденти. За AWS отговорностите на клиента включват IAM, мрежови правила, укрепване на работните натоварвания, конфигурация за шифроване, архивиране, журналиране, прилагане на корекции и сигурност на приложенията.

Прикачете документацията на доставчика за споделена отговорност, след което картографирайте всяка клиентска отговорност към собственик на контрол и източник на доказателства.

Стъпка 3: Съберете доказателства за конфигурацията

За Microsoft 365 експортирайте или направете екранни снимки на MFA и политики за условен достъп, администраторски роли, настройки за външно споделяне, одитно журналиране, конфигурация за съхранение и действия по Security Score. За AWS експортирайте IAM политика за пароли, статус на MFA за привилегировани акаунти, CloudTrail конфигурация, S3 public access block, статус на шифроване, преглед на security group, задачи за архивиране и статус на сканиране за уязвимости.

Политика за използване на облачни услуги изисква облачните среди да съответстват на документирана базова конфигурация, одобрена от архитект по сигурност на облачни услуги. Вашият пакет с доказателства трябва да включва както базовата конфигурация, така и доказателство за съответствие с нея.

Стъпка 4: Свържете доказателствата за доставчика и поверителността

Прикачете договора, DPA, списъка с подизпълнители по обработване, условията за уведомяване при нарушение, докладите за одиторско уверение и доказателствата за местонахождение на данните. Ако се обработват лични данни, запишете дали доставчикът действа като обработващ лични данни, как се обработва изтриването, как работи поддръжката за искания от субекти на данни и кои предпазни мерки за трансфер се прилагат.

За DORA идентифицирайте дали облачната услуга поддържа критична или важна функция. Ако да, свържете доказателствата с регистъра на ИКТ трети страни, файла за надлежна проверка, правата на одит, плана за изход и прегледа на риска от концентрация.

Стъпка 5: Свържете журналирането с реагирането при инциденти

Покажете, че журналите са активирани, маршрутизирани, преглеждани и използвани. Прикачете SIEM табла, правила за предупреждения и поне един затворен билет за предупреждение. След това картографирайте работния поток към точките за вземане на решение за докладване по NIS2 и DORA.

За NIS2 процесът за инциденти трябва да поддържа ранно предупреждение в рамките на 24 часа, уведомление за инцидент в рамките на 72 часа и окончателен доклад в рамките на един месец за значими инциденти. За DORA процесът за ИКТ инциденти следва да класифицира инцидентите по засегнати клиенти, трансакции, продължителност, престой, географски обхват, въздействие върху данните, критичност на услугата и икономическо въздействие.

Стъпка 6: Съхранявайте доказателствата дисциплинирано

Клауза 6.2 от Политика за одит и мониторинг на съответствието за МСП на Clarysec Audit and Compliance Monitoring Policy-sme дефинира практическа дисциплина за доказателствата:

„6.2 Събиране и документиране на доказателства 6.2.1 Всички доказателства трябва да се съхраняват в централизирана одитна папка. 6.2.2 Имената на файловете трябва ясно да посочват темата на одита и датата. 6.2.3 Метаданните (напр. кой ги е събрал, кога и от коя система) трябва да бъдат документирани. 6.2.4 Доказателствата трябва да се съхраняват поне две години или по-дълго, когато това се изисква от сертификация или клиентски споразумения.“

Корпоративната Политика за одит и мониторинг на съответствието Audit and Compliance Monitoring Policy посочва целта:

„Да се генерират правно обосновани доказателства и одитна следа в подкрепа на регулаторни запитвания, съдебни производства или искания от клиенти за потвърждение на контролите.“

Екранна снимка с име „screenshot1.png“ е слабо доказателство. Файл с име „AWS-Prod-CloudTrail-Enabled-2026-05-10-CollectedBy-JSmith.png“ е по-силен, защото описва системата, контрола, датата и събиращото лице. Метаданните са важни, защото одиторите трябва да имат доверие кога е събрано доказателството, кой го е събрал и от коя система.

Как одиторите тестват един и същ облачен контрол

Най-силните пакети с облачни доказателства са проектирани за множество одитни гледни точки. Одиторите по ISO 27001:2022 проверяват дали контролът е в ISMS, оценката на риска, третирането на риска и SoA. Оценители, ориентирани към NIST, проверяват техническото внедряване. Одиторите по COBIT 2019 проверяват управлението, резултатността на доставчиците и интеграцията на процесите. Одиторите по поверителност се фокусират върху задълженията на обработващите, местонахождението на данните, готовността при нарушения и правата на субектите на данни. Надзорните прегледи по DORA се фокусират върху ИКТ риска от трети страни и устойчивостта.

Zenith Controls включва тези различия в одитната методология за облачни услуги, споразумения с доставчици и мониторинг на доставчици. За 5.22, Мониторинг, преглед и управление на промените в услугите на доставчици, той подчертава, че одиторите могат да инспектират протоколи от тримесечни прегледи на доставчици, KPI отчети, оценки на SOC доклади, журнали на промените, оценки на риска, инциденти при доставчици и проследяване на проблеми. За 5.20, Разглеждане на информационната сигурност в споразуменията с доставчици, той подчертава извадково тестване на договори за поверителност, задължения за сигурност, уведомяване при нарушение, права на одит, одобрение на подизпълнители и условия за прекратяване.

Контроли за кръстосано съответствие, които носят тежестта на облачния одит

Готовият за регулаторна проверка модел за облачни доказателства се изгражда около малък брой високоефективни контроли. Тези контроли носят голяма част от тежестта на съответствието по ISO 27001:2022, NIS2, DORA, GDPR, NIST и COBIT 2019.

NIST SP 800-53 Rev.5 добавя техническа дълбочина чрез управление на акаунти, услуги на външни системи, непрекъснато наблюдение, наблюдение на системите и защита на границите. COBIT 2019 добавя управленска дълбочина чрез управление на взаимоотношенията с доставчици, риск, свързан с доставчици, обмен на данни, мрежова сигурност и готовност за промени.

Подкрепящите ISO стандарти изострят модела на доказателствата. ISO/IEC 27017 предоставя специфични за облака насоки относно споделени роли, конфигурация на виртуални машини и мониторинг на дейността на клиентите. ISO/IEC 27018 се фокусира върху защитата на PII в публичен облак. ISO/IEC 27701 разширява задълженията за поверителност към операциите на обработващи и администратори. ISO/IEC 27036-4 подкрепя споразуменията с облачни доставчици и мониторинга. ISO/IEC 27005 е за оценка на риска в облака.

Прегледът от ръководството трябва да вижда облачния риск, а не само cloud uptime

Един от най-често пренебрегваните одитни артефакти е прегледът от ръководството. ISO 27001:2022 очаква прегледът от ръководството да разглежда промени, нужди на заинтересованите страни, тенденции в резултатността, резултати от одити, статус на третирането на риска и възможности за подобрение. NIS2 изисква управителните органи да одобряват мерките за управление на риска в киберсигурността и да надзирават внедряването. DORA изисква управителният орган да дефинира, одобрява, надзирава и да остава отговорен за управлението на ИКТ риска.

Тримесечно табло за облачна сигурност и доставчици трябва да показва:

• Брой одобрени облачни услуги.
• Критични облачни услуги и собственици.
• Услуги, обработващи лични данни.
• Услуги, поддържащи критични или важни функции.
• Отворени високорискови неправилни конфигурации в облака.
• Статус на MFA и преглед на привилегирован достъп.
• Покритие на журналирането за критични SaaS и IaaS платформи.
• Получени и прегледани отчети за уверение от доставчици.
• Договорни изключения и приети рискове.
• Облачни инциденти, предотвратени инциденти и извлечени поуки.
• Резултати от тестове за архивиране и възстановяване.
• Статус на риска от концентрация и плановете за изход.

Това табло се превръща в доказателство за лидерство и оценка на резултатността по ISO 27001:2022, управление по NIS2 и управленска отчетност по DORA.

Zenith Blueprint, във фазата Risk Management, Step 14, препоръчва кръстосано съпоставяне на регулаторните изисквания при внедряване на третиране на риска и политики. Той посочва, че картографирането на ключови регулаторни изисквания към ISMS контроли е полезно вътрешно упражнение и „също впечатлява одиторите/оценителите, че не управлявате сигурността във вакуум, а отчитате правния контекст“.

Това е зрелостта, която регулаторите и корпоративните клиенти очакват.

Чести констатации при облачен одит и как да ги избегнете

В работата по готовност за облачен одит повтарящите се констатации са предвидими:

1. Регистърът на облачните услуги съществува, но SaaS инструментите липсват.
2. Местонахождението на данните не е записано или е копирано от маркетингови страници, а не от договорни доказателства.
3. MFA се прилага за служители, но не за всички административни или аварийни акаунти.
4. Облачните журнали са активирани, но не се преглеждат, съхраняват или свързват с реагиране при инциденти.
5. SOC докладите на доставчиците са архивирани, но не са оценени.
6. Договорни клаузи съществуват за нови доставчици, но не и за наследени критични услуги.
7. Уведомленията за подизпълнители по обработване се получават по имейл, но не се оценяват за риск.
8. Задачите за архивиране завършват успешно, но тестовете за възстановяване не са доказани.
9. Споделената отговорност се разбира от инженерите, но не е документирана за одитори.
10. SoA маркира облачните контроли като приложими, но не ги свързва с записи за риск, доказателства или собственици.

Това са проблеми с проследимостта. Решението е да се свържат политика, риск, контрол, собственик, доказателства и преглед.

Когато Мария стигна до деня на одита, тя вече не разчиташе на разпръснати екранни снимки. Тя отвори централизирано табло, показващо Регистъра на облачните услуги, оценките на риска, SoA записите, доказателствата за базова конфигурация, файловете от прегледи на доставчици, доказателствата за журналиране и прегледа на риска от концентрация по DORA. Когато одиторът попита как се управляват облачните рискове, тя показа ISMS. Когато одиторът попита как услугите са конфигурирани сигурно, тя показа базовата конфигурация и CSPM доказателствата. Когато одиторът попита за ИКТ риска от трети страни, тя показа прегледа на договорите, мониторинга на доставчиците и планирането на изход.

Резултатът не беше перфектна среда. Няма перфектна облачна среда. Разликата беше, че решенията за риска бяха документирани, доказателствата бяха обосновани и отчетността беше видима.

Изградете своя пакет с облачни доказателства, преди одиторът да го поиска

Ако организацията ви разчита на SaaS, IaaS или PaaS, следващият ви одит няма да приеме „доставчикът се грижи за това“ като достатъчен отговор. Трябва да докажете споделена отговорност, клиентска конфигурация, клаузи за доставчици, журналиране, готовност за инциденти, устойчивост и управленски надзор.

Започнете с три практически действия тази седмица:

1. Създайте или актуализирайте своя Регистър на облачните услуги, като използвате Политика за използване на облачни услуги на Clarysec Cloud Usage Policy или Политика за използване на облачни услуги за МСП Cloud Usage Policy-sme.
2. Картографирайте петте си най-важни облачни услуги към контролите от ISO 27001:2022 Annex A, NIS2 Article 21, задълженията на DORA за ИКТ трети страни, когато е приложимо, и изискванията на GDPR към обработващи.
3. Изградете централизирана папка с доказателства, като използвате дисциплината за съхранение и метаданни от Политика за одит и мониторинг на съответствието Audit and Compliance Monitoring Policy или Политика за одит и мониторинг на съответствието за МСП Audit and Compliance Monitoring Policy-sme.

След това използвайте Zenith Blueprint Zenith Blueprint, за да поставите работата в 30-стъпковата пътна карта за одит на ISMS, и Zenith Controls Zenith Controls, за да валидирате картографиранията за кръстосано съответствие, подкрепящите ISO стандарти и очакванията към одитната методология.

Clarysec може да ви помогне да превърнете разпръснати облачни екранни снимки, файлове на доставчици и SaaS настройки в готов за регулаторна проверка пакет с доказателства, който издържа на сертификационни одити по ISO 27001:2022, надзорни въпроси по NIS2, прегледи на ИКТ трети страни по DORA и изисквания за уверение от корпоративни клиенти.