# Безопасность перед первым корпоративным пилотом: что важно

> Безопасность перед первым корпоративным пилотом начинается с контроля доступа, базовой защиты ноутбуков, резервных копий и проверки подрядчиков — а не с длинных политик.

## Почему это важно до пилота

Перед первым корпоративным пилотом безопасность в основном про контроль. Покупатели обычно задают простые вопросы: кто имеет доступ? что случится, если потеряли ноутбук? где резервные копии? какие внешние инструменты касаются данных?

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

Бумажки не решат проблему неправильных доступов или утерянного ноутбука. Основатель может потратить два дня на написание политики и при этом пропустить то, что важно сегодня: у бывшего подрядчика всё ещё есть доступ в продакшен, или один инженер работает на незашифрованном ноутбуке. Покупатели отличают команду, которая написала правила, от команды, которая решила базовые проблемы.

Маленьким командам обычно лучше короткий список задач, который можно закрыть. В большинстве случаев первыми идут четыре области: доступ к системам и данным, безопасность ноутбуков, резервные копии, которые можно восстановить, и быстрая проверка подрядчиков, вовлечённых в пилот.

Этот порядок соответствует реальным рискам. Старая учётная запись, украденное устройство или подрядчик с нестрогими контролями могут быстро замедлить или остановить сделку. Решение редко требует гигантской программы безопасности: это несколько привычек, которые снижают очевидный риск и дают вам возможность чётко ответить покупателю.

Такой практичный подход часто подходит для этой стадии. Oleg Sotnikov работает с компактными командами именно в таком режиме: исправлять важное, избегать церемоний и добиваться чистой, пригодной в работе конфигурации.

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

## Начните с контроля доступа

Самая распространённая ранняя проблема безопасности проста: у неправильного человека слишком долгий доступ. Для стартапа, который идёт на корпоративный пилот, это обычно самая быстрая работа с наибольшей отдачей.

Сначала перечислите все системы, к которым прикоснётся пилот. Не останавливайтесь на продакшене. Включите и смежные инструменты, потому что ошибки и перехваты аккаунтов часто начинаются там. Подумайте про почту, календарь, хостинг кода, CI/CD, облачные аккаунты, админ‑панели, документы, тикеты, общие диски, инструменты поддержки, аналитику и биллинг.

Затем жёстко почистите аккаунты. Удалите бывших сотрудников, старых подрядчиков, тестовые пользователи — всё, что никто не может объяснить. Общие логины тоже должны уйти. Они удобны неделю, а потом никто не помнит, кто что изменил или экспортировал.

После очистки сократите доступ до того, что человеку нужно именно сейчас. Инженеру может понадобиться репозиторий, логи и staging, но не биллинг. Основателю может нужен биллинг и контракты, но не админ базы данных. Если кто‑то просит большой доступ «на всякий случай», начните с меньшего. Позже вы сможете добавить права.

Включите MFA везде, где от аккаунта зависит остальная часть стека. Начните с почты. Затем защитите хост кода, облачный аккаунт, менеджер паролей и админ‑инструменты, связанные с данными клиентов. Приложения‑аутентификаторы или ключи безопасности обычно лучше, чем SMS.

Одна и та же роль должна одобрять каждый новый запрос на доступ. В маленькой команде это может быть основатель, CTO или ведущий по операциям. Инструмент важен меньше, чем правило. Короткий тикет, запись в чате, скопированная в документ, или небольшая таблица — всё годится, если фиксирует три вещи: какой доступ нужен, зачем он нужен и когда его пересмотреть.

Если покупатель спросит, кто может получить доступ к данным пилота, вы должны ответить за считанные минуты.

## Сначала базовые настройки ноутбуков

Большинство ранних проблем безопасности начинаются на ноутбуке, а не на сервере. Один потерянный девайс, один устаревший браузер или одно личное приложение, залогиненное в рабочую учётную запись, могут быстро создать проблему на клиентской стороне.

Начните с настроек, которые уже есть в каждой ОС. Требуйте короткого авто‑блокирования и полного шифрования диска на каждом устройстве, включая ноутбук основателя. Если кто‑то оставит устройство в такси или в аэропорту, шифрование и блокировка экрана не дадут быстрого доступа и купят вам время.

Держите ОС, браузер и менеджер паролей в актуальном состоянии. Команды любят откладывать обновления из‑за перезагрузок. Эта привычка делает один ноутбук слабым звеном для всех остальных.

Разделяйте работу и личное. Разработчик, тестирующий какие‑то расширения в том же профиле, что и почта клиентов, приглашает проблемы. Используйте отдельный рабочий логин, рабочий профиль браузера и рабочие аккаунты, которые не смешиваются с семейными фото, аккаунтами для покупок или случайными загрузками.

Включите отслеживание устройств и удалённое стирание заранее. Это скучная настройка, но окупается в первый раз, когда ноутбук исчезает. Кто‑то в команде должен видеть, какие устройства у вас есть, кто ими пользуется и может ли он заблокировать или стереть устройство в тот же день.

Для маленькой команды базовый набор прост:

- блокировка экрана через несколько минут бездействия
- включённое и подтверждённое полное шифрование диска
- автообновления для ОС, браузера и менеджера паролей
- включённый трекинг устройств и возможность удалённого стирания
- включённый встроенный брандмауэр и защита от вредоносного ПО

Не спешите покупать дополнительное ПО, если встроенные средства уже покрывают базовые требования. Windows, macOS и современные браузеры умеют больше, чем многие стартапы используют. Сначала убедитесь, что каждый ноутбук действительно использует эти защиты.

Если пять человек готовятся к пилоту, проверьте все пять ноутбуков за один вечер. Обычно вы найдёте один и тот же беспорядок: одна машина без шифрования, один старый браузер и один человек, хранящий рабочие пароли в личном хранилище. Исправить это заранее гораздо дешевле, чем объяснять во время аудита безопасности.

## Сделайте резервное копирование скучным и надёжным

Большинство маленьких команд делают бэкапы самого простого и забывают про то, что действительно будет больно потерять. Сначала назовите данные, которые вы не можете позволить себе потерять даже на один день. Обычно это production‑база данных, исходный код, конфиги окружения, документы по доставке и файлы клиентов.

Разумная область резервирования часто включает репозитории и скрипты деплоя, продуктовые документы и руны, настройки инфраструктуры, такие как записи DNS и конфиги серверов, и данные клиентов в базах или хранилищах файлов. Если вы полагаетесь на выгрузки из сторонних инструментов, включите и их.

Держите хотя бы одну копию отдельно от основной системы. Если приложение, бэкапы и админ‑доступ находятся в одном облачном аккаунте, одно некорректное удаление или заблокированный аккаунт может испортить вам неделю. Используйте отдельное место, отдельный аккаунт или и то, и другое. Вам не нужна сложная система — нужна такая, которая работает после плохого дня.

Проверьте восстановление до старта пилота. Это важнее, чем добавление ещё одной задачи резервирования. Выберите реальный сценарий и выполните его от начала до конца. Восстановите недавний снимок базы в безопасной среде. Скачайте код на чистый ноутбук. Откройте восстановленные документы и конфиги. Засеките время. Если процесс занимает четыре часа, запишите это. Теперь вы знаете, как реально выглядит восстановление.

Назначьте одного человека владельцем резервных копий. Когда «все отвечают», никто не проверяет. Владелец не обязан делать каждую операцию вручную, но он должен еженедельно подтверждать, что бэкапы прошли, хранилище не переполнено и инструкции по восстановлению соответствуют текущему продукту.

Короткая еженедельная проверка достаточна:

- подтверждение времени последнего успешного бэкапа
- проверка наличия резервной копии вне основного окружения и её целостности
- обзор заметок по восстановлению или повторное выполнение небольшого теста восстановления

Скучные бэкапы — цель. Когда пилот начнётся, команда должна сосредоточиться на доставке и обратной связи от клиента, а не на восстановлении данных, которые вы считали безопасными.

## Проверьте подрядчиков по короткому списку

Маленькие команды обычно несут больше риска от подрядчиков, чем думают. Проблема редко начинается с продвинутой атаки. Чаще это инструмент, который никто не проверял, бывший подрядчик с админ‑доступом или сервис, который хранит данные клиентов, хотя команда им почти не пользуется.

Перечислите каждого подрядчика, который хранит данные компании или клиентов, отправляет почту от вашего имени или участвует в входе в систему. Включите очевидные — хостинг, контроль версий, и забываемые — формы, аналитику, чат поддержки и обмен файлами.

Для каждого подрядчика прочитайте три вещи: страницу безопасности, условия по данным и админ‑настройки, которые вы контролируете сами. Вам не нужен длинный аудит. Нужны простые ответы.

Держите одну простую таблицу с одной строкой на инструмент. Отмечайте, какие данные инструмент хранит, вмешивается ли он в аутентификацию или продакшен, какие админ‑контролы вы можете включить, имеют ли сотрудники провайдера доступ к вашим данным и нужен ли он вам для пилота.

Последний вопрос важнее, чем многие ожидают. Если инструмент не нужен для пилота — отключите его. Каждый лишний подрядчик добавляет новый логин, ещё одно место распространения данных и ещё одну службу поддержки, у которой может быть какой‑то уровень доступа.

Особое внимание уделяйте доступу сотрудников у провайдера. Некоторые сервисы позволяют инженерам поддержки или внутренним администраторам просматривать данные клиентов в отдельных случаях. Это не всегда критично, но вы должны знать правило, понимать, как они согласовывают доступ и можно ли его ограничить.

Команды часто находят лёгкие победы: два инструмента аналитики, делающие одно и то же, неиспользуемый виджет поддержки на сайте или приложение для обмена файлами, заполненное старыми экспортами. Удаление таких инструментов снижает риск быстрее, чем написание десяти страниц политики.

Если вы работаете с внешним CTO или опытным оператором, эта таблица подрядчиков становится полезным инструментом принятия решений. Она подскажет, что оставить, что заблокировать, а что удалить перед стартом пилота.

## Простой порядок работ

Четыре сфокусированные недели лучше двух месяцев написания политики. Цель не в том, чтобы выглядеть зрелыми. Цель — убрать очевидные риски, которые могут сорвать сделку или превратить мелкую ошибку в реальный инцидент.

Начните с идентичности. Если у бывших подрядчиков всё ещё есть доступ или двое людей используют один админ‑логин, исправьте это в первую очередь. Включите MFA для почты, облака, репозиториев и менеджеров паролей. Удаляйте устаревшие доступы в тот же день, когда вы их находите.

Простой порядок обычно срабатывает:

- Неделя 1: проверьте все аккаунты, которые могут касаться данных клиентов, биллинга, исходников или продакшен‑систем.
- Неделя 2: пропатчьте ноутбуки, включите авто‑блокировку, включите шифрование диска и ограничьте локальные права админа.
- Неделя 3: настройте автоматические бэкапы для критичных систем, затем протестируйте восстановление одного файла и одного полного восстановления.
- Неделя 4: проверьте подрядчиков по короткому чек‑листу и закройте самые большие пробелы в первую очередь.

Эта последовательность упрощает жизнь. Сначала очистите аккаунты — и меньше людей смогут менять настройки или сливаться данные. Затем закрепите ноутбуки — и утерянное устройство станет проблемой, а не утечкой. Протестируйте бэкапы до обзора подрядчиков — и у вас уже будет чёткий ответ, как вы восстанавливаетесь.

Маленькая команда часто завершает первые две недели быстрее, чем ожидает. Один основатель или внешний CTO обычно может почистить аккаунты за день‑два, а потом провести несколько дней на настройку ноутбуков. Резервные копии тянут время только тогда, когда у них нет владельца.

Пишите политику после того, как контролы уже существуют. Короткое правило доступа, соответствующее реальным настройкам, поможет. Длинный документ, который никто не соблюдает, только создаёт шум. Держите правила короткими, назначьте владельца для каждого контроля и проверяйте их ежемесячно до запуска пилота.

## Ошибки, которые тратят время впустую

Команды часто тратят силы на работу, которая выглядит серьёзной, но мало снижает риск. Самая распространённая ошибка — отшлифованная административная работа при отсутствии базовых контролей.

Классический пример — написание длинной политики безопасности, пока старые подрядчики всё ещё имеют админ‑доступ к коду, облаку, почте или менеджеру паролей. Документ не защитит данные клиентов. Очистка доступов — защитит.

Обычные траты времени легко заметить:

- общие логины, которые скрывают, кто что изменил
- бэкапы, которые запускаются каждую ночь, но никогда не восстанавливались
- новые инструменты, добавленные прямо перед пилотом, потому что «кажутся полезными»
- личные ноутбуки, используемые для работы с клиентами при слабой локальной защите
- широкие админ‑права, оставленные для удобства повседневной работы

Общие аккаунты особенно вредны. Они экономят пять минут сегодня и создают часы путаницы позже. Если кто‑то уходит, вы не можете убрать только его доступ. Если что‑то ломается, вы не можете отследить действия до одного пользователя.

Нетестированные бэкапы тратят время более тихо. Зелёная галочка по утрам создаёт ощущение безопасности. Потом удаляют файл, ломается ноутбук или некорректный деплой, и никто не знает, сработает ли восстановление. Резервная копия, которую никогда не восстанавливали, — это просто обнадёживающий файл.

Новый подрядчик в последний момент создаёт тот же беспорядок. Каждый новый инструмент добавляет место, где нужно проверить права, обработку данных и условия. Перед пилотом такая работа редко окупается.

Личные ноутбуки создают проблемы по той же причине. Если одно устройство слабо защищено локально, всей команде приходится отвечать на жёсткие вопросы клиентов с плохими данными. Гораздо быстрее требовать обновлений, шифрования диска, блокировки экрана и отдельных рабочих аккаунтов до того, как клиентские данные окажутся на машине.

Если задача не снижает риск на этой неделе — отложите её. Сначала исправьте доступы. Заблокируйте ноутбуки. Протестируйте восстановление. Уменьшите стек подрядчиков.

## Короткий чек‑лист перед пилотом

Покупатели редко просят толстую папку политик в первый день. Им важнее увидеть, что ваша команда аккуратно выполняет базовые вещи. Если вы можете ответить на проверки ниже «да», вы в гораздо лучшей форме.

- каждый человек использует собственный аккаунт для рабочих систем
- у каждого админа включён MFA, и кто‑то в команде за это отвечает
- рабочие ноутбуки быстро блокируются, используют шифрование диска и быстро ставят обновления
- резервные копии запускаются по расписанию, и команда уже что‑то из них восстановила
- вы можете объяснить каждый инструмент в стеке пилота в одно‑две фразы

Этот список короткий специально. Маленькая команда может закрыть большинство пунктов за дни, не месяцы.

Простой пример. Если ваш пилот использует Google Workspace, GitHub, облачный хост и один инструмент поддержки, вы должны знать, кто имеет админ‑права в каждом из них, включён ли MFA, зашифрованы ли ноутбуки, где хранятся бэкапы и какие данные клиентов попадают в инструмент поддержки. Если вы не можете ответить на один из этих вопросов за минуту — закройте пробел до старта пилота.

Работа проста, немного скучна и очень эффективна. Корпоративные покупатели обычно сначала замечают базовые вещи.

## Реальный пример для маленькой команды

Пятеро сотрудников стартапа собираются начать платный пилот с первым корпоративным клиентом. Продукт работает, демо прошло хорошо, и затем клиент спрашивает: «Как вы решаете вопросы безопасности?» Команде не нужна толстая папка политик. Им нужны несколько исправлений, которые снижают реальный риск.

Компания использует типичный набор: почту, командный чат, хостинг кода и один облачный хост. Два ранних подрядчика ушли месяц назад, но их аккаунты всё ещё существуют. Один общий админ‑логин лежит в командной заметке, потому что «иногда он нужен всем». Покупатели быстро замечают такой беспорядок.

За неделю основатели разбирают базовые вещи. Удаляют старые аккаунты подрядчиков, включают MFA повсюду и дают каждому собственный логин с правами только по необходимости. Если кто‑то уйдёт позже, команда просто удалит один аккаунт вместо смены секрета, известного половине компании.

Потом они берутся за настройки ноутбуков. Каждому ноутбуку включают полное шифрование, авто‑блокировку и обновления системы. Затем они тестируют то, что многие команды пропускают: восстановление. Один инженер поднимает недавний бэкап в чистой среде и проверяет, что приложение и данные действительно возвращаются.

Этот тест занимает полдня. Он же освобождает их от предположений, что бэкапы работают, просто потому что дашборд показывает зелёную галочку.

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

Когда клиент задаёт дополнительные вопросы, стартап может чётко ответить:

- у каждого есть собственный аккаунт
- бывшие подрядчики больше не имеют доступа
- ноутбуки зашифрованы и автоматически блокируются
- бэкапы выполняются, и команда тестировала восстановление
- неиспользуемые инструменты не имеют доступа

Это не делает стартап идеальным. Но показывает то, что покупатели ценят: команда следит за делом, закрывает очевидные пробелы и умеет выполнять базовые требования, чтобы заслужить доверие.

## Что делать дальше

Большинству маленьких команд не нужна толстая книга по безопасности до пилота. Им нужно несколько коротких правил, которые люди будут выполнять на этой неделе. Напишите их простым языком и привяжите к реальной работе: кто получает админ‑доступ, как ноутбуки остаются обновлёнными и зашифрованными, куда идут бэкапы и когда новый подрядчик проходит проверку.

Назначьте одного ответственного. Этот владелец не должен делать всю работу в одиночку, но он должен держать список в актуальном состоянии и следить, чтобы ничего не пропускалось. Если распределить ответственность слишком широко, базовые вещи начнут соскальзывать.

Хороший следующий шаг выглядит так:

- напишите одностраничный набор правил для текущей команды
- составьте простой инвентарный список админ‑аккаунтов, рабочих ноутбуков, задач резервного копирования и подрядчиков, работающих с данными клиентов
- сначала исправьте очевидные пробелы, затем сделайте ещё одну проверку перед тем, как данные клиентов попадут в пилот
- отложите низкорисковую бумажную работу на потом

Эта работа обычно быстро окупается. Быстрый обзор часто обнаруживает устаревшие доступы, отсутствующее шифрование дисков, бэкап‑задачи, которые перестали выполняться, или подрядчика, утверждённого без реальной проверки. Покупателей беспокоят такие пробелы больше, чем политика, которую никто на команде не читал.

Если вам нужна внешняя проверка, Oleg Sotnikov на oleg.is работает со стартапами как внештатный CTO и советник по практической безопасности, инфраструктуре и командным операциям. Для маленькой команды, готовящейся к первому корпоративному пилоту, такой второй взгляд может сэкономить неделю срочных исправлений.