Що засновники B2B SaaS дізнаються під час першого корпоративного security review

Засновник B2B SaaS закриває свою першу корпоративну угоду усно. Відкривається шампанське. Два тижні по тому приходить security-опитувальник, ще три тижні — юридичний review, і десь на шостому тижні угода, яка була закрита в принципі, перепрацьовується, відкладається або тихо губиться. Засновник витрачає наступний квартал, щоб наздогнати те, що виявив опитувальник.

Це настільки передбачувано, що перетворилося на стадію розвитку SaaS-компанії. Засновники, які її переживають, засвоюють одні й ті ж уроки. Ті, хто її не переживає, теж засвоюють їх — просто дорогою ціною.

Що насправді запитує опитувальник

Сорокасторінковий security-опитувальник від покупця зі списку Fortune 500 відчувається як вичерпний технічний аудит. Це не так. Він задає набагато простіше питання: якщо нашій команді безпеки доведеться захищати цю покупку перед нашим CISO, чи зможуть вони?

Питання — це не справді про відповіді. Вони про те, чи ви думали над відповідями, чи вони узгоджені між собою, і чи відповідає ваша позиція серйозності даних, які ви зберігатимете. Опитувальник з порожніми полями провалюється. Опитувальник із впевненими, конкретними, внутрішньо послідовними відповідями проходить — навіть якщо деякі з них "ми цього зараз не робимо, ось наш план".

Це означає, що засновник, який сприймає опитувальник як тест, пропускає суть. Опитувальник — це розмова. Покупець запитує, чи може він довірити вам свої дані, і чи зможе його команда безпеки захистити рішення довіритися вам.

П'ять речей, які завжди з'являються

Через достатню кількість корпоративних угод одні й ті ж п'ять речей з'являються майже в кожному опитувальнику — і саме ці п'ять речей, до яких SaaS-засновники зазвичай не готові.

SSO через SAML або OIDC з SCIM-провізіонуванням. IT-команда покупця не хоче керувати окремими обліковими записами у вашому продукті. Вони хочуть провізіонувати користувачів зі свого identity provider і щоб доступ проходив через нього. Якщо у вас немає SSO — у вас немає корпоративного тарифу. SCIM — автоматичне видалення доступу, коли співробітник іде — це наступна вимога, і вона є обов'язковою для будь-якого покупця зі значною кількістю персоналу.

Журнали аудиту, до яких має доступ клієнт. Не "у нас є журнали аудиту з нашого боку." Клієнт хоче свої журнали аудиту — у своєму SIEM, доступні для запитів своєю командою. Зазвичай це формулюється як вимога "надсилати події до нашого security-інструменту". Без цього покупець не може провести власне розслідування інциденту у вашому продукті, а значить не може використовувати вас для чогось чутливого.

Обґрунтована відповідь щодо мультитенантності. "Чи ізольовані наші дані від даних інших ваших клієнтів?" Чесні відповіді зазвичай такі: "так, логічно, у спільній базі даних зі скопінгом по тенанту, що забезпечується на рівні застосунку." Це нормально, якщо ви можете впевнено пояснити і продемонструвати контролі. Відповідь, яка провалюється — засновник, який панікує, перепродає ізоляцію і дає суперечливі відповіді на уточнення. Впевненість у помірній позиції краща за розмиті запевнення в сильній.

Розміщення та експорт даних. Де знаходяться дані? Чи може клієнт їх вивантажити? При розірванні договору, що з ними відбувається? Ці питання короткі в опитувальнику та масштабні на практиці. Багато SaaS-архітектур припускають, що дані назавжди залишаться в одному cloud-регіоні і клієнт ніколи не піде. Обидва припущення руйнують корпоративні угоди.

Прозорість щодо субпроцесорів. Кожен постачальник, якого ви використовуєте і який торкається даних клієнта, має бути розкритий. Stripe, Twilio, OpenAI, Datadog, кожен AI-провайдер. Клієнт прочитає цей список, і хтось із них буде неприйнятним з причин, специфічних для того клієнта. Вам потрібно бути готовими обговорити альтернативи або мати переконливе пояснення, чому залежність не можна прибрати.

В якому порядку їх додавати

Якщо ви ще до корпоративного рівня і намагаєтеся підготуватися — порядок важливий. Будувати всі п'ять одночасно нереально для більшості команд; будувати їх у неправильному порядку залишає вас із незручним частковим покриттям.

Порядок, який спрацював у наших SaaS-проектах:

По-перше, журнали аудиту — бо їх легко додати постфактум, але неможливо заповнити ретроспективно, якщо чекати. Кожна дія в системі повинна логуватися з актором, ціллю, дією, мітками часу та IP — з першого тижня. Потім дякуватимете собі.

По-друге, SSO — бо це питання найчастіше з'являється першим у корпоративній розмові, і саме воно займає найбільше часу, якщо ви його пропустили. Будуйте з підтримкою SAML і OIDC. SCIM може зачекати, поки двоє корпоративних клієнтів не попросять, але SSO-фундамент має бути.

По-третє, строгість моделі мультитенантних даних — бо це найважче змінювати пізніше. Якщо ізоляція тенантів у вас недбала — виправте зараз. Якщо чиста — задокументуйте чітко, щоб можна було захистити в опитувальнику.

По-четверте, інвентаризація субпроцесорів — бо її легко зібрати і вона майже завжди запитується. Ведіть як живий документ. Новий постачальник? Він потрапляє до списку й проходить перевірку.

По-п'яте, розміщення та експорт даних — бо це найімовірніше відкладатиметься. Навіть ручний, підтримуваний процес "експорту ваших даних на запит протягом 30 днів" є достатнім для багатьох покупців і набагато кращим, ніж мовчазне "у нас насправді немає процесу для цього."

Глибший урок

Опитувальник — не перешкода. Перешкода в тому, що корпоративні клієнти купують не просто ваш продукт, а обґрунтоване рішення ним користуватися. Описані вище функції існують, щоб зробити це рішення обґрунтованим.

Засновник, який це засвоїв, перестає боятися корпоративних закупівель і починає сприймати їх як обмеження дизайну, що формує продукт у здоровий бік. SSO — це правильна річ для побудови в будь-якому разі. Журнали аудиту роблять вашу команду підтримки кращою. Експорт даних — це правильна річ для клієнтів. Закупівельний шлюз, у певному сенсі, робить вам послугу, ставлячи це питання.

Просто рідко здається послугою, поки ви заповнюєте опитувальник.