Минимальная безопасность перед Series A для небольших команд

Почему ранняя безопасность кажется больше, чем есть

Большинство ранних команд представляют безопасность как огромную программу с аудитами, длинными политиками и инструментами, которыми некогда управлять. Такое представление парализует. До Series A безопасность обычно гораздо проще. Она начинается с нескольких понятных правил по админ‑доступу, хранению секретов, бэкапам, логам и правилам для ноутбуков.

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

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

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

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

Решите, что защищать в первую очередь

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

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

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

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

Простой пример проясняет разницу. Если у команды один облачный аккаунт, один хост для Git, Stripe и общий почтовый ящик поддержки, потеря инструмента поддержки — неприятность. Потеря облака или доступа к Git может вывести продукт из строя. Тратьте время там, где ущерб был бы больше.

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

Эта простая карта станет базой для контроля доступа, хранения секретов, тестов восстановления и логирования.

Держите админ‑доступ маленьким и видимым

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

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

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

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

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

Используйте отдельный админ‑аккаунт для рискованных изменений. Повседневная работа должна идти из обычного аккаунта. Админ‑аккаунт оставляйте для действий типа смены DNS, удаления продакшен‑ресурсов или редактирования платёжных настроек. Это лишний шаг немного раздражает — и именно поэтому он помогает.

Храните секреты в одном контролируемом месте

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

Решение простое. Кладите пароли, API‑ключи, ключи подписи и служебные токены в один сейф и делайте его единственным одобренным местом хранения. Хорошее управление секретами до Series A в основном про сокращение разброса. Если секрет живёт в пяти местах — вы им не управляете.

Понятные имена важнее, чем многие думают. Когда команды догадываются, они ошибаются. Имя должно говорить, для чего секрет, где он нужен и безопасно ли его использовать. prod_stripe_api_key, staging_github_deploy_token, aws_billing_readonly и postgres_app_prod — всё это легко понять с первого взгляда.

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

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

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

Делайте бэкапы, которые можно восстановить

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

Начните с того, что команда не сможет быстро восстановить. Для большинства продуктов это продакшен‑база данных, файлы, загруженные пользователями, записи биллинга и конфигурация, нужная для поднятия приложения. Маркетинговые страницы и старые тестовые данные можно восстановить за день — они менее критичны.

Частота бэкапов должна соответствовать тому, какой объём потери вы готовы пережить. Если потеря одного дня новых данных — большая проблема, ежедневные бэкапы слишком редки. Если четыре часа допустимы — бэкапите минимум так часто.

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

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

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

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

Ведите логи, которые отвечают на простые вопросы

Логи должны помогать быстро отвечать на несколько простых вопросов. Кто входил? Кто менял админские права? Что ушло в последний деплой? Выполнялись бэкапы или тихо падали в 3 утра?

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

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

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

После каждого деплоя и после любого простоя один человек должен проверить одну и ту же небольшую панель. Если команда уже пользуется Grafana, Sentry или похожими инструментами, одного экрана достаточно. Покажите недавние деплои, уровень ошибок, неудачные входы и статус бэкапов. Когда что‑то выглядит подозрительно, хочется начинать с одного места, а не из пяти вкладок и догадок.

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

Правила для ноутбуков, которым люди будут следовать

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

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

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

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

Если ноутбук пропал

Напишите процедуру до того, как это понадобится, и протестируйте её раз. Простая версия выглядит так:

1. Сообщить о пропаже в командный чат в тот же день и уведомить одного назначенного ответственного.
2. Отозвать доступ ноутбука к почте, чату, VPN и админ‑инструментам.
3. Поменять любые пароли или токены, сохранённые на устройстве.
4. Проверить, что текущие рабочие файлы есть в общих системах, а не только на ноутбуке.

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

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

Простой пример из маленького стартапа

Пятеро в SaaS‑команде работают на AWS, GitHub, Stripe и Google Workspace. Такая настройка обычна для ранних компаний, как и проблемы.

Один из основателей всё ещё использует общий root‑логин, потому что «иногда всем он нужен». Несколько API‑токенов лежат в заметках телефона и текстовом файле на ноутбуке. Никто не воспринимает это как программу безопасности — так команда выживала в напряжённые недели.

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

Они также сильно урезают админский доступ. Вместо широких прав для всех пяти людей — по два админа на систему. AWS — два, GitHub — два, Google Workspace — два, Stripe — два. Имена видны, список короткий. Тем, кому нужны только отчёты по биллингу или логи деплоев, дают только эти права.

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

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

Постройте это за 30 дней

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

Неделя 1 — инвентаризация. Запишите все системы, от которых зависит компания: почта, облако, репозиторий кода, платежи, аналитика, регистратор доменов, инструменты поддержки и продакшен‑базы. Рядом с каждой укажите владельца и все админ‑аккаунты. Если никто не знает, кто владеет системой — это уже риск.

Неделя 2 — доступ. Сначала включите MFA для всех админов, затем двигайтесь наружу. Перенесите пароли, API‑токены и ключи подписи в одно контролируемое место, например менеджер паролей или секрет‑стор. Общие логины должны исчезнуть сейчас, не позже. Учетные записи на людей упрощают офбординг и проверки.

Неделя 3 — многие команды узнают правду о своих бэкапах. Проведите одно реальное восстановление для базы и одно для файлов/объектного хранилища. Засеките время. Опишите шаги восстановления простым английским (или вашим рабочим языком), чтобы другой человек мог следовать им под стрессом. Добавьте логи по входам, изменениям админов, деплоям и задачам бэкапа. Вам не нужна идеальная обозреваемость, нужно достаточно деталей, чтобы быстро ответить на простые вопросы.

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

К 30‑му дню у небольшой компании должен быть актуальный список систем, владельцев и админов, MFA на админских доступах, секреты в одном месте, протестированное восстановление с записанными шагами и правила для ноутбуков, которым люди действительно следуют. Этого достаточно, чтобы сократить массу избегаемых рисков, не притворяясь, что вы — компания из 200 человек.

Распространённые ошибки, которые тратят время зря

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

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

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

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

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

Быстрые проверки и следующие шаги

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

• Можете ли вы назвать все админ‑аккаунты сегодня для облака, кода, почты и биллинга?
• Может ли один человек восстановить продукт по записанным шагам без звонка обычно ответственного?
• Видите ли вы входы, изменения админов и провалы бэкапов без долгих копаний?
• Можете ли быстро заблокировать потерянный ноутбук и знать, какие данные на нём были?
• Подходят ли правила под реальную работу вашей команды или их обходят?

Если где‑то ответ «нет», не начинайте гигантский проект по безопасности. Назначьте одного владельца, один дедлайн и одно подтверждение, что исправление работает. Скриншот уведомлений бэкапа, актуальный список админов или реальный тест блокировки ноутбука — лучше, чем политика, которую никто не читает.

Один полезный чек, который стоит сделать на этой неделе: попросите человека, не настраивавшего систему, восстановиться по заметкам. Если он застрянет — заметки неполные. Та же логика применима к доступам. Если вы не можете перечислить админов за пару минут, значит их слишком много или вы недостаточно часто проверяете список.

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

Если команда хочет практической внешней проверки, Oleg Sotnikov на oleg.is работает как Fractional CTO и советник стартапов. Полезная версия такого аудита небольшая и прямолинейная: сократить админов, упорядочить секреты, протестировать восстановление, проверить логи и установить простые правила для ноутбуков.