Безопасность приложения для нетехов: 10 вопросов до запуска

Что может пойти не так после запуска

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

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

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

Если у вас нет глубоких техзнаний, вы все равно можете проверить базовые вещи:

• У каждого ли пользователя свой вход, и можно ли быстро отключить доступ одному человеку.
• Понятно ли, кто что может делать (создать, изменить, удалить, экспортировать).
• Записываются ли важные действия и видно ли, кто именно их сделал.
• Понимаете ли вы, где хранятся данные и кто к ним имеет доступ (включая подрядчиков и админов).

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

Сначала определите роли и самые опасные действия

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

Обычно в продукте есть несколько групп: клиенты, сотрудники, подрядчики и админы. Для каждой группы выпишите типовые действия: что можно смотреть, что можно менять, что можно удалять, что можно выгружать. Важно фиксировать не только «доступ есть или нет», но и границы. Например, сотрудник видит только свои заявки, а руководитель - заявки отдела.

Дальше решите, какие данные для вас чувствительные. Это не только паспорт или карта. Часто «болит» то, что кажется обычным:

• персональные данные (ФИО, телефон, email)
• финансы (счета, акты, история оплат)
• коммерческие детали (цены, скидки, условия договоров)
• внутренние заметки и переписка
• файлы и вложения (сканы, фото, документы)

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

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

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

Вопросы 1-2: Как устроен вход и восстановление доступа

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

Сначала выберите подходящий способ входа: пароль, одноразовый код (например, по SMS или email) или корпоративный вход (SSO). Для внутреннего сервиса корпоративный вход обычно снижает хаос с паролями. Для внешнего сервиса одноразовые коды могут быть проще для пользователей, но требуют защиты от перехвата и повторного использования.

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

Мини-чек перед запуском:

• есть ли лимит попыток входа и понятная реакция на перебор
• понятные требования к паролю (длина, запрет слишком простых комбинаций)
• обязательна ли 2FA для админов и техподдержки
• можно ли быстро отключить доступ конкретному аккаунту
• понятно ли, кто выдает доступ новым пользователям

Восстановление доступа часто оказывается самой уязвимой точкой. Спросите себя: может ли злоумышленник восстановить доступ, зная только email или телефон? Хорошая схема восстановления проверяет несколько признаков (например, код плюс подтверждение через уже привязанное устройство) и оставляет след в журнале.

Пример: менеджер уволился, но почта еще активна пару дней. Если восстановление пароля идет только через email, доступ к аккаунту можно вернуть тихо. Если для восстановления нужен второй фактор или подтверждение админом, риск заметно ниже.

Вопросы 3-4: Кто кому что может делать в системе

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

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

Как выдаются права и кто это подтверждает

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

Проверка, которая помогает избежать хаоса:

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

Кто назначает админов и что делать при увольнении

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

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

Вопрос 5: Есть ли журнал действий и можно ли ему доверять

Журнал действий (аудит-лог) нужен не для красоты. Он помогает быстро понять, что произошло, когда «что-то сломалось», пропали данные или клиент говорит: «Я этого не делал». Это один из самых практичных инструментов: он снижает споры и ускоряет разбор проблем.

Проверьте, что именно пишется в журнал. Минимум - кто сделал действие, что именно сделал, когда и откуда. «Откуда» - это не только IP, но и устройство или сессия, если у вас это есть. Важно, чтобы лог фиксировал не просто факт «изменено», а контекст: какой объект, какое поле, какое значение было и каким стало (хотя бы для критичных полей).

Что стоит логировать в первую очередь:

• вход/выход, смена пароля, сброс доступа
• создание, изменение, удаление важных сущностей (клиенты, заявки, счета)
• изменения прав и ролей
• операции с платежами, документами и выгрузками
• массовые действия (импорт, «удалить все», пересчет)

Дальше вопрос доверия. Может ли администратор «подчистить хвосты»? Логи должны быть защищены от правок: доступ на чтение отдельно, изменения и удаление запрещены или строго контролируются. Продумайте, кто имеет право смотреть журнал, и как долго он хранится (например, 90-180 дней или дольше, если это нужно по процессам).

Простая проверка: сможете ли вы за 5 минут ответить на вопрос «кто это сделал» и показать доказательство, которое не стыдно положить в отчет. Если нет, журнал есть, но пользы от него мало.

Вопрос 6: Где хранятся данные и кто к ним прикасается

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

Сначала про место. Узнайте, в какой стране находятся серверы и резервные копии, и кто является провайдером. Это важно и для закона, и для практики: где реально окажутся персональные данные, туда же придут запросы и риски.

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

• контакты и учетные записи (почта, телефон)
• платежная информация и счета
• документы и файлы
• переписки и комментарии
• служебные данные (IP, устройства, история действий)

Теперь самое чувствительное: кто имеет доступ к базе. Правило простое: доступ должен быть минимальным и по понятным причинам. Договоритесь, у кого есть прямой доступ к продакшн-базе, как он выдается, как фиксируется, и как быстро его можно отозвать. Частая ошибка - один общий пароль «для всех» или доступ разработчиков без ограничений.

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

Вопрос 7: Как вы переживете ошибку, сбой или неудачный релиз

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

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

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

Еще один вопрос - откат релиза. Должно быть понятно, как быстро вернуть прошлую версию, если после обновления перестал работать вход, платежи или заявки. Ориентир для нетехнической команды: «можем вернуться назад за 15-30 минут и без ручных правок данных».

Заранее договоритесь о доступах и ответственности:

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

Вопрос 8: Как устроены хранение, удаление и сроки

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

Сначала определите, какие данные вам реально нужны для работы сервиса и как долго. Например, заявки и счета могут быть нужны для отчетности, а технические события (типа попыток входа) - только для расследований и обычно на короткий срок. Для каждого типа данных задайте срок хранения и причину: бизнес, безопасность, закон.

Удаление по запросу: что это означает на практике

Заранее ответьте на простой вопрос: «Пользователь нажал удалить аккаунт - что именно исчезнет?» Варианты обычно такие:

• удаление профиля и персональных данных, но сохранение обезличенных записей для статистики
• закрытие доступа, но хранение части данных, которые нельзя удалять по закону
• полное удаление, если нет причин держать информацию дальше

Проверьте и «хвосты»: данные в копиях и логах. Многие думают, что удаление в интерфейсе удаляет все, но резервные копии могут жить неделями, а журналы действий пользователей часто нужны для безопасности. Нормально, если вы не удаляете запись из бэкапов сразу, но это должно быть описано: сколько живут копии, кто может их восстановить, и что происходит при восстановлении (не возвращаются ли «удаленные» данные обратно).

Ответственность и сроки

Назначьте владельца процесса: кто принимает запросы на удаление, кто подтверждает личность, кто выполняет действие. Зафиксируйте срок реакции и срок фактического удаления. Хороший минимум - понятный ответ пользователю и внутренняя процедура, чтобы запрос не «застрял» между поддержкой и разработкой.

Вопрос 9: Что вы делаете, если случился инцидент

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

Сначала проверьте, какие сигналы вы вообще получите. Если о проблеме вы узнаете от клиента, значит, у вас нет базовых уведомлений. Минимум: алерт на подозрительные входы (необычная география, много попыток), резкий рост ошибок, массовые изменения данных, неожиданные права у роли, скачок запросов к базе.

Первые 60 минут: короткий план

В первые минуты цель одна - остановить ущерб и сохранить следы:

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

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

После тушения пожара важна работа над причинами. Сделайте простой отчет: что случилось, как заметили, почему допустили, какие действия предотвратят повтор. Например: добавили обязательный 2FA для админов, сузили права роли, включили снимки и откат, сделали алерты на массовые операции.

Частые ошибки, которые делают даже аккуратные команды

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

Частые ошибки:

• один «общий админ» на всех: пароль кидают в рабочий чат, а потом его знают бывшие сотрудники, подрядчики и случайные участники переписки
• подрядчику выдали доступ «на пару дней», но забыли убрать: через месяц он все еще видит данные и может менять настройки
• логи есть, но им нельзя доверять: их может удалить админ, они не собирают важные события (входы, смену прав, выгрузки) или хранятся слишком мало
• для тестов используют реальные данные: их копируют в тестовую базу «на минутку», а потом они разъезжаются по ноутбукам, скриншотам и чатам
• резервные копии существуют только на бумаге: бэкапы делают, но ни разу не пробовали восстановиться, и в день сбоя выясняется, что копия неполная или восстановление занимает сутки

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

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

Короткий чеклист перед запуском

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

Проверьте 5 вещей

• Роли и владельцы: перечислите роли (пользователь, менеджер, админ) и назначьте владельца за каждую зону (доступы, данные, релизы, инциденты). У каждой «красной кнопки» должен быть ответственный.
• Вход и восстановление: включите 2FA хотя бы для админов, задайте понятные правила пароля и проверьте, что восстановление доступа не обходится «через поддержку по просьбе в чате».
• Права и отзыв доступов: проверьте принцип минимальных прав, продумайте отзыв доступов при увольнении, и отдельно - доступ подрядчиков (срок, роль, кто выдает и кто закрывает).
• Журнал действий: убедитесь, что ключевые события пишутся в лог (вход, смена прав, удаление, выгрузка данных, изменения настроек), и что по нему реально найти: кто, когда и что сделал.
• Данные и восстановление: зафиксируйте, где лежат данные, как долго хранятся, как удаляются по запросу, есть ли бэкапы и, главное, проверяли ли вы восстановление.

Быстрый тест: попросите человека «не из команды» выполнить один опасный сценарий (например, попытаться выдать себе права администратора) и посмотрите, что сработало: запреты, уведомления, записи в журнале.

Пример сценария: сервис заявок для небольшой компании

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

Роли стоит разделить так, чтобы у каждой были только нужные кнопки и данные:

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

Дальше определите, что писать в журнал действий. Он должен отвечать на вопрос «кто, что, когда и откуда сделал», а не быть просто техническим логом:

• вход, выход, неудачные попытки входа, смена пароля
• создание заявки и изменение важных полей (контакты, получатель, приоритет)
• смена статуса и назначение ответственного
• выгрузка данных (отчет, список заявок), особенно если есть персональные данные
• удаление заявки, вложения или пользователя

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

И наконец, план на случай неудачного релиза. Должна быть понятна точка отката:

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

Следующие шаги: как быстро привести это в порядок

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

Дальше назначьте конкретных людей (или роли) за четыре зоны: доступы, логи, бэкапы и удаление данных. Без владельца у задачи почти всегда появляется «ничейная» часть, и именно она потом ломает запуск.

План на 1-2 дня, который реально сделать без глубокой техподготовки:

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

Если вы собираете продукт в TakProsto (takprosto.ai), заранее проверьте организационные вещи, которые чаще всего спасают в реальном инциденте: понятные роли и доступы, доступ к журналам, а также сценарий снимков и отката, чтобы возвращаться в рабочее состояние быстро.

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