#РазборКейса
🔑 Выстроили контроль подрядчиков и доступов без CISO
Какие механики реально держатся в крупной компании?
В крупной компании отсутствие отдельной позиции CISO само по себе не является главной проблемой. Проблема начинается там, где подрядчики получают доступы по переписке, контроль прав никто не проводит, а ответственность размазана между ИТ и ИБ. Формально функция есть, управляемости нет.
Практический риск понятен: доступы живут дольше, чем работы; права выдаются шире, чем нужно; а в момент инцидента становится неясно, кто именно что согласовал, кто подключался и кто должен был это закрыть. Для CTO это уже не вопрос идеальной модели ИБ, а вопрос управляемости доступа к системам и данным.
В одном из таких кейсов решение оказалось не в попытке срочно построить “мини-SOC” и не в назначении одного ответственного за все, а в сборке простого контура управления.
Сначала закрепили владельца процесса на уровне руководства, затем развели роли: кто согласует привлечение подрядчика, кто проверяет основания для доступа, кто выдает доступ, кто контролирует срок, кто закрывает его по завершении работ.
💬 Для обработки персональных данных и доступа к системам этого подхода уже достаточно, чтобы убрать хаос: закон требует не только договорных формулировок с подрядчиком, но и реальных правовых, организационных и технических мер защиты, а при поручении обработки оператор не снимает с себя ответственность за контур безопасности.
Дальше сработали только те механики, которые не зависят от ручной дисциплины.
Что реально удержалось на практике:
🚪 единая точка входа для доступа подрядчика: без заявки, основания, владельца системы и срока доступ не открывается;
🚪 именные учетные записи и запрет на общие логины;
🚪 доступ не в систему вообще, а в конкретный сегмент, сервис и набор действий;
🚪 доступ по сроку действия, а не бессрочно;
🚪 обязательная фиксация событий: кто подключался, когда, откуда, что делал и кто это согласовал.
В логике требований по защите информации это и есть устойчивый минимум: управление доступом, регистрация событий безопасности, контроль защищенности и формализация правил работы с учетными записями.
Отдельно важно, что в крупной компании держится только то, что встроено в смежные процессы. Поэтому контроль подрядчиков не оставили внутри ИБ. Его привязали к закупке, договору, онбордингу, выдаче доступов и закрытию работ.
Именно это и делает модель применимой на практике. Ее можно использовать как рабочий ориентир, если у вас нет отдельного CISO, но уже есть подрядчики с доступом к инфраструктуре, данным или внутренним системам.
На что стоит посмотреть у себя в первую очередь:
➡️ есть ли единый процесс допуска подрядчика;
➡️ понятно ли, кто согласует доступ и кто его закрывает;
➡️ открывается ли доступ только на срок и под конкретную задачу;
➡️ используются ли именные учетные записи;
➡️ фиксируется ли, кто и что делал в системе;
➡️ встроен ли этот процесс в закупку, договор и завершение работ.
Если договор продлен, но доступ не нужен, доступ закрывается. Если работы завершены, учетная запись не ждет следующего квартала, а закрывается сразу. Если подрядчик меняет сотрудника, новый человек проходит тот же цикл допуска заново. Это скучная механика, но именно она убирает основную массу избыточных и забытых прав.
📎 Главный вывод:
В крупной компании без отдельного CISO реально работают не отдельные меры, а короткий набор обязательных правил: единый процесс допуска, ролевое согласование, срочный и ограниченный доступ, журналирование, периодический пересмотр и безусловное закрытие прав после завершения работ. Все остальное полезно, но именно этот каркас обычно и определяет, управляется ли доступ подрядчиков или живет сам по себе.
Если у вас похожая схема уже работает или только планируется, https://b-152.ru/request?utm_source=telegram&utm_medium=post&utm_content=240426&utm_term=post
😎
💙 https://vk.ru/b152news | 💬 | 💬 https://max.ru/join/QEG1tolDyqkE0lr6wyQvpXLnYNW9dYMXrYaZSo8-QH0 | 📝 https://dzen.ru/b152
