SOC 2 – це формат незалежного аудиту, який показує, як компанія захищає дані своїх клієнтів. Сьогодні він є де-факто стандартом для SaaS-компаній і хмарних сервісів, що працюють із клієнтами у США. Аудитор перевіряє безпеку систем, а за бажанням компанії також доступність сервісу, коректність обробки даних, конфіденційність і приватність. Результатом є звіт (SOC 2 report), який компанія показує клієнтам і партнерам як доказ того, що їхні дані в безпеці.
Якщо ви прагнете досягти SOC 2 комплаєнсу, ключовим доказом безпеки для аудитора та клієнтів стає звіт про оцінку захищеності систем (яким має бути звіт для SOC 2 і навіщо він потрібен, ми пояснимо нижче).
Пентест для SOC 2 не є обовʼязковим заходом, він зазначений як один із прикладів оцінки безпеки, але на практиці аудитори майже завжди очікують бачити пентест. Тому більшість компаній включають його в підготовку до аудиту за замовчуванням. Через це пентест часто сприймають як ще один пункт у списку перед аудитом: знайти підрядника, отримати звіт, покласти його в папку з доказами й перейти до наступного завдання. Але саме тут компанії часто роблять помилку.
Замовити пентест для SOC 2 – це найлегша частина аудиту. Складніше зробити його так, щоб результат мав сенс і для вашої команди безпеки, і для аудитора, і для бізнесу. Який скоуп тестувати? Чи достатньо пентесту веб додатків? Що робити з хмарною інфраструктурою? Що аудитор дивитиметься у звіті? І головне – що буде, якщо пентестер знайде критичну вразливість за кілька днів до аудиту?
У цій статті розберемо, як насправді виглядає penetration testing у контексті SOC 2, де найчастіше виникають проблеми та чому сам факт наявності пентесту ще не означає, що ви добре підготувалися до аудиту.
Якщо ви ще не до кінця розумієте, що таке пентест, радимо спершу прочитати цю статтю.
Що аудитор очікує побачити у звіті (SOC 2 Pentest Report)
Тестування на проникнення не є окремою універсальною вимогою SOC 2, яку кожна компанія повинна виконати однаково. Але на практиці воно часто стає важливою частиною доказової бази для Security.
Політику реагування на інциденти, процес керування вразливостями, контроль доступу – все це можна описати в документі. Пентест дає практичну перевірку частини цих контролів: він показує, чи можна використати вразливості або помилки конфігурації, щоб обійти передбачені механізми захисту. Тому аудитору важливо зрозуміти не лише сам факт тестування, а й те, як результати були опрацьовані: що знайшли, що з цим зробили і хто за це відповідав.
Є ще практичний бік. Ваші клієнти теж читають SOC 2 звіт. Коли служба безпеки клієнта бачить розділ про пентест, перше питання завжди одне: що саме тестували, коли востаннє і чи закрили знайдені вразливості. Для бізнесу це теж важливо: пентест показує клієнтам, що безпека перевіряється не лише на рівні політик і документів.
Чим SOC 2 Penetration Testing відрізняється від звичайного пентесту
Технічно, методологія пентестування та сама: OWASP, PTES, NIST – база не змінюється залежно від того, для чого потрібен звіт. Різниця в іншому – у скоупі, документації та в тому, як звіт буде читатися людиною, яка не знає технічних деталей вашого продукту.
Скоуп прив'язаний до системи, що входить до SOC 2, а не до всього периметра компанії. Якщо у вас є продукт, для якого проводиться аудит, і окремий внутрішній сервіс, який до нього не має відношення, аудитора цікавить тільки перший. Це звучить очевидно, але на практиці компанії часто замовляють пентест “на все”, а потім не можуть чітко показати аудитору, яка частина звіту стосується системи в скоупі SOC 2, а яка ні.
Звіт має бути читабельним для аудитора SOC 2, а не лише для інженера. Аудитор SOC 2 – це не пентестер. Йому потрібно розуміти методологію, дату проведення, хто проводив тестування, який був скоуп, список знайдених вразливостей за рівнем критичності і, головне, статус кожної: виправлено, в процесі, прийнятий ризик. Технічний PoC для SQL-ін'єкції аудитора не цікавить. Йому цікаво, чи довели цю знахідку до закриття.
Час має значення. SOC 2 Type II оцінює, чи контролі працювали стабільно протягом усього періоду аудиту, а не в одну конкретну дату. Конкретні вимоги до частоти пентесту у різних аудиторів і CPA-фірм можуть відрізнятися, тому це варто уточнювати саме з вашим аудитором. Але логіка проста: чим ближче пентест до початку періоду і чим свіжіший звіт, тим менше питань він викликає. Звіт дворічної давнини, навіть із давно закритими знахідками, буде викликати додаткові питання щодо його актуальності.
Що саме перевіряють у рамках SOC 2 пентесту
Найчастіше в скоуп потрапляють:
- зовнішній периметр – все, що доступне з інтернету: веб-застосунки, API, публічні сервіси;
- внутрішня інфраструктура, якщо є значуща внутрішня мережа з доступом до чутливих даних;
- механізми автентифікації та авторизації – саме тут найчастіше знаходять проблеми, які напряму бʼють по критерію Security;
- сегментація середовищ, якщо продакшн і тестові контури розділені формально, а не фактично.
Окремо варто сказати про хмарну інфраструктуру. Класичний пентест і перевірка хмарних конфігурацій (cloud configuration assessment) – це не одне й те саме. Пентест переважно шукає, чи можна проникнути через застосунок, API або мережу. Відкрите хмарне сховище, надлишкові доступи тощо – це радше питання конфігурації, і в скоуп стандартного пентесту вони можуть не входити взагалі, якщо це не обумовлено окремо.
Для SOC 2 це важливо розуміти заздалегідь: якщо у вас значна частина інфраструктури в AWS, GCP чи Azure, варто прямо запитати підрядника, чи входить перевірка хмарних конфігурацій у скоуп, чи це окрема послуга. Це варто зафіксувати й у фінальному звіті: аудитор має одразу бачити, що саме було перевірено, а що залишилося за межами скоупу.
Найпоширеніша помилка: пентест заради галочки
Компанія замовляє пентест за два тижні до дедлайну з аудитором, отримує звіт з критичними знахідками, докладає його до пакета доказів і сподівається, що це задовольнить аудитора. Найчастіше не задовольняє.
Аудитор бачить звіт з критичними вразливостями без жодного статусу виправлення і задає логічне питання: якщо ви знали про критичну проблему і нічого з нею не зробили, як це узгоджується з вашим власним процесом керування вразливостями, описаним у політиках? Тут аудитор уже оцінює, наскільки на практиці працюють контролі, які ви самі описали в документах.
Тому правильна послідовність інша: пентест → пріоритизація знайденого → усунення → ретест, що підтверджує закриття → і лише після цього звіт з фінальним статусом іде в пакет для аудитора. Якщо часу на повний цикл до дедлайну не залишається, чесніше показати аудитору проміжний стан з планом усунення (remediation plan) і датами, ніж підсунути звіт з незакритими критичними знахідками без пояснень.
Детальніше про те, що робити після пентесту, ми розглядали в окремій статті.
Пентест раз на рік – це фіксація одного дня
Жоден стандарт SOC 2 не каже “робіть пентест саме раз на 12 місяців”. Але сама логіка Type II – оцінка того, чи контролі працювали стабільно протягом усього періоду – на практиці підштовхує до того самого висновку: один тест на початку періоду не показує, що відбувалося з продуктом далі.
А відбувається зазвичай багато чого: нові релізи, нові API, оновлені залежності, зміни в інфраструктурі. Кожна з цих змін теоретично може відкрити нову діру, про яку початковий звіт нічого не знає.
Тому на практиці працює простіша схема: повноцінний пентест перед основним аудитом і легші перевірки чи ретести після значних релізів або змін інфраструктури протягом року. Це дешевше за повторне замовлення повного пентесту "з нуля" щоразу, і дає аудитору та вашим клієнтам актуальну картину, а не звіт, якому вже рік.
З самою ідеєю зазвичай ніхто не сперечається. Проблема в іншому: повторний пентест коштує майже стільки ж, скільки перший, і займає майже стільки ж часу. Саме цю проблему і намагається зняти AI Pentest від A42: після основного тестування можна замовити повний ретест усього скоупу за 50% вартості первинного пентесту, і завдяки спеціалізованим AI-агентам його результати ретесту можна отримати так само швидко, як і пентест: тобто до чотирьох днів.
Що з цим робити
Якщо ви готуєтеся до SOC 2 і ще не визначилися зі скоупом пентесту, форматом звіту або тим, як вписати ретест у цикл релізів, краще закрити ці питання до початку аудиту.
Можна обговорити ваш конкретний випадок з технічною командою A42, забронювавши ознайомчий дзвінок.
