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

Клиентът на облачни услуги иска да знае кои защитни мерки прилага доставчикът и кои остават негова собствена отговорност. Федералната служба за информационна сигурност на Германия (BSI) публикува Каталога с критерии за съответствие при облачните изчисления, C5, като структурирана основа за проверка на тази увереност. За техническия директор подготовката означава границата на услугата, внедряването на контролите и оперативните записи да станат проверими, а не просто да се съберат политики.

C5 е каталог с критерии, използван за независима атестация, а не сертифициране от типа на ISO. Документацията на BSI за C5 е основният източник. Започнете, като договорите с независимия одитор приложимото издание, целта на увереността и обхвата на проверката.

Определете точно коя услуга ще обхваща докладът

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

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

Решете тези въпроси за обхвата, преди да събирате доказателства:

• Кои продукти, региони и среди са включени?
• Кои екипи администрират продукционната среда или имат достъп до клиентска информация?
• Кои основни доставчици поддържат услугата и как се третират техните контроли?
• Кои конфигурации и задачи по сигурността остават за клиентите?
• Какви съществени промени са настъпили или са планирани по време на периода на проверка?

Дайте изрична обосновка за изключенията. Ако дадено наследено внедряване е изключено, уверете се, че изявленията към клиентите не внушават, че то е обхванато. Резултатът е версионирано описание на системата, подкрепено от записи за архитектурата, зависимостите и отговорностите.

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

Увереността по C5 обикновено се изразява чрез доклад за атестация от одитор. Тип 1 се отнася до дизайна и внедряването на контролите към определен момент. Тип 2 допълнително проверява ефективността на функционирането им през определен период.

Тип 1 може да бъде полезен етап при изграждането на контролна среда, но не отговаря на същия въпрос като Тип 2. Потвърдете какво реално изискват клиентите, преди да изберете междинен доклад.

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

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

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

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

Това са практически примери, а не пълен контролен списък по C5. Използвайте договорения каталог и обхват, за да определите изискваното покритие, включително организационните контроли, контролите, свързани с персонала, физическите и техническите контроли.

Направете доказателствата възпроизводими

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

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

Разграничавайте наследените контроли от запазените задължения

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

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

Провеждайте подготовката като инженерна програма

Започнете с оценка на пропуските спрямо договорените критерии. Разграничавайте липсващото внедряване от липсващите доказателства: те изискват различни мерки. Недокументиран преглед може да изисква по-добри записи; преглед на достъпа, който никога не е бил извършен, изисква оперативен контрол.

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

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

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

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

Практически пример: управлявано приложение върху външна инфраструктура

Да приемем, за илюстрация, че доставчик експлоатира приложение с много клиенти в един регион, използва външен доставчик на инфраструктура и търси увереност по Тип 2. Екипът му контролира изданията на приложението, правата в клиентските екземпляри, администрирането на продукционната среда и процедурите за възстановяване.

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

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

За привилегирования достъп екипът пази съвкупността от администратори, одобренията за предоставяне на права, решенията от прегледите и записите за премахване. Да предположим, че преглед открие неизползван акаунт за поддръжка. Екипът записва откриването, отнемането на достъпа, оценката на експозицията и превантивното действие. Това е по-достоверно от подаването само на изчистения списък с акаунти.

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

Използвайте повторно работата по увереността, без да твърдите равностойност

ISO/IEC 27001 се отнася до система за управление на информационната сигурност с определен обхват. SOC 2 е доклад за атестация, който използва собствени критерии и контекст на докладване. C5 е съсредоточен върху увереността за облачни услуги по каталога на BSI.

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

Избирайте портфолиото от увереност според действителните изисквания на клиентите и рисковете за услугата. C5 не е универсално задължителен за всеки доставчик на облачни услуги; изискванията от тръжни процедури, договори или приложими секторни правила трябва да бъдат прегледани отделно. Нито докладът по C5, нито друг документ за увереност сам по себе си установява съответствие с ОРЗД или NIS2.

Подгответе доклада за решенията на клиентите

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

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

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

Въпроси, които трябва да решите преди първата проверка

BSI ли издава доклада?

BSI публикува каталога. Независим одитор извършва проверката и издава доклада за атестация; потвърдете приложимата рамка за увереност и условията на ангажимента с този одитор.

Какво да направим, ако не е имало реален инцидент?

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

Какво трябва да направи екипът след това?

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