Кибербезопасность малого бизнеса: 12 практик без корпоративного бюджета

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

1. Включите двухфакторную авторизацию

Почта, GitHub, CRM, хостинг, домены, админки — все критичные аккаунты должны быть защищены 2FA. Пароль может утечь. Второй фактор сильно снижает риск.

2. Не используйте общие аккаунты

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

3. Храните секреты отдельно от кода

Пароли базы, токены, API-ключи и JWT-секреты не должны попадать в репозиторий. Используйте environment variables, секреты CI/CD и менеджеры паролей.

4. Делайте резервные копии

Backup должен быть не только создан, но и проверен. Самый опасный сценарий — думать, что копии есть, а при восстановлении узнать, что они не работают.

Минимум: регулярный pg_dump, хранение нескольких версий, периодическая тестовая проверка восстановления.

5. Обновляйте зависимости

Уязвимости часто закрываются обновлениями. Важно иметь регулярный процесс: проверка зависимостей, обновление базовых Docker-образов, контроль критичных CVE.

6. Ограничьте доступ к базе

PostgreSQL не должна смотреть в интернет. База должна быть доступна только приложению внутри сервера или приватной сети.

7. Закройте админки от индексации

CMS, панели управления и служебные интерфейсы не должны попадать в поисковую выдачу. Используйте robots.txt, X-Robots-Tag, а лучше еще VPN, IP allowlist или Basic Auth.

8. Логируйте важные действия

Авторизация, загрузка файлов, изменение статусов, ошибки API — все это должно попадать в логи. Без логов расследование превращается в догадки.

9. Проверяйте загрузку файлов

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

10. Используйте HTTPS везде

Сайт, CMS, API, вебхуки — все должно работать через HTTPS. Это базовый уровень доверия и защиты данных в пути.

11. Разделяйте роли

Не всем нужен полный доступ. Менеджеру не нужны настройки сервера, редактору не нужен доступ к базе, подрядчику не нужен root.

12. Пишите инструкции

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

Итог

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

Лучший момент начать — до инцидента.

<!-- bitex-longform-v2 -->

С чего начать за один день

Если времени мало, начните с критичных доступов. Проверьте домены, хостинг, GitHub, почту, CRM, платежные сервисы и серверы. Включите 2FA, уберите общие аккаунты, сохраните recovery-коды в менеджере паролей.

Это простое действие закрывает один из самых частых рисков: потерю контроля над инфраструктурой из-за скомпрометированного аккаунта.

Как организовать backup

Backup должен отвечать на три вопроса: что копируем, как часто и как восстанавливаем. Для сайта и CMS обычно нужны база данных, загруженные файлы и переменные окружения. Код хранится в Git, но данные пользователей и контент — нет.

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

Почему приватная база важна

PostgreSQL не должна быть доступна из интернета. Если база нужна только приложению, она должна жить внутри Docker-сети или приватного контура. Это снижает поверхность атаки и убирает целый класс рисков.

То же относится к внутренним API: если endpoint нужен только сайту или CMS, не обязательно публиковать его на отдельном домене.

Загрузка файлов

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

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

Доступ подрядчиков

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

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

Итоговая мысль

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