Готовність до ISO/IEC 27001 для мультитенантної логістичної SaaS-платформи
Кейс клієнта
Тип бізнесу
Мультитенантна логістична SaaS-платформа
Масштаб
Постачальник WMS/TMS SaaS середнього ринку, що обслуговує десятки клієнтів 3PL та фулфілменту на спільній інфраструктурі.
Мета
Пройти перевірку безпеки постачальника ISO/IEC 27001 корпоративного клієнта протягом одного кварталу, не заморожуючи дорожню карту продукту.
Виклик
Поточний стан
Великий потенційний клієнт зробив підтвердження ISO/IEC 27001 обов'язковою вимогою перед підписанням угоди. Платформа розвивалася чотири роки без формальної СУІБ - рішення щодо доступу приймалися ситуативно, тим, хто налаштовував обліковий запис конкретного клієнта.
- Відсутність задокументованої політики контролю доступу - ролі надавалися за звичкою, а не за задумом
- Колишні співробітники та підрядники досі мали постійний доступ до продакшн-систем
- Відсутність централізованого логування того, хто, коли і до чиїх даних мав доступ
- Відповідальність за безпеку неформально розподілялася між двома інженерами без окремого опису посадових обов'язків
Больова точка
Безпосередній тиск був комерційним, а не технічним:
Природним бажанням було написати політики так, щоб вони відповідали очікуванням аудитора. Це б пройшло паперову перевірку, але провалилося б при першому реальному інциденті.
Приховані ризики
- Ізоляція даних між орендарями ніколи формально не тестувалася, лише передбачалася
- Спільні облікові дані адміністратора існували принаймні для однієї застарілої інтеграції
- Плану реагування на інциденти, окрім «зателефонувати CTO», не існувало
Перевірка безпеки постачальником часто є першим випадком, коли ці прогалини розглядаються напряму.
Обмеження та ризики
Технічні обмеження
- Дедлайн в один квартал, прив'язаний до активних комерційних переговорів
- Нульова толерантність до простою - платформа не могла піти в офлайн для виправлення контролю доступу
- Застарілі інтеграції, що передували будь-якій політиці контролю доступу
- Невелика інженерна команда, вже завантажена роботою над продуктом
Операційні ризики
- Втрата угоди, якщо докази не викликали б довіри, а не просто існували
- Надмірне ускладнення процесів, які інженери тихо обходитимуть
- Ставлення до цього як до одноразової реакції на аудит, а не постійної спроможності
Рішення та компроміси
01. Ключове рішення
Спочатку провести оцінку прогалин ISO/IEC 27001 за контролями Annex A, перш ніж писати хоч один документ політики. Оцінка прогалин стала списком пріоритетів.
- Аудит контролю доступу для кожної продакшн-системи та інтеграції
- Скасування постійного доступу для всіх, хто не мав поточної задокументованої потреби
- Централізоване логування аудиту для доступу до даних між орендарями
- Іменований, підзвітний власник безпеки - а не спільна відповідальність
02. Компроміси
Ми пріоритизували:
- Виправлення реальних прогалин контролю доступу над складанням вичерпної політики спочатку
- Вузький, перевірюваний обсяг СУІБ над переписуванням у масштабах усієї компанії
- Докази, які аудитор міг незалежно перевірити, над самозвітними чек-листами
Розробка функцій продовжувалася паралельно. Робота над безпекою велася як окремий спринт-трек, а не заморожування всієї компанії.
03. Чому просто не написати документи політики?
Тому що документи політики, що описують контролі, які насправді ніхто не виконує, гірші за відсутність документів - вони створюють відповідальність, не знижуючи ризик.
Кожна написана нами політика описувала контроль, який уже було впроваджено та протестовано, а не намір на наступний квартал.
Вплив
Що змінилося після співпраці.
Операційний результат
- Аудит контролю доступу завершено, постійний доступ скасовано в масштабах усієї платформи
- Централізовані, доступні для запитів журнали для всього доступу до даних між орендарями
- Іменований власник безпеки з визначеними повноваженнями, а не спільна другорядна відповідальність
- План реагування на інциденти, протестований на навчальному сценарії перед запуском
Бізнес-цінність
- Корпоративна угода закрилася у визначений термін
- Оцінка прогалин стала повторно використовуваною основою СУІБ, а не одноразовою вправою
- Докази безпеки стали активом продажів для подальших корпоративних угод
- Нуль порушень дорожньої карти продукту під час співпраці
Ключові нотатки
Отримані висновки
Що ми зрозуміли завдяки цій співпраці.
Оцінка прогалин за реальним фреймворком краща за написання політики за шаблоном.
Борг контролю доступу тихо накопичується в командах SaaS, що швидко зростають.
Відповідальність за безпеку потребує конкретного імені, а не спільного розуміння.
Робота з відповідності, що ведеться як окремий спринт-трек, не мусить заморожувати дорожню карту.
“Відповідність вимогам - побічний продукт хорошої архітектури, а не окремий проєкт.”
Дізнайтеся, що перевірка безпеки постачальником знайшла б у ваших системах сьогодні.