Руководства по безопасности
Базовая безопасность для инди-разработчиков и малых операторов: весь стандартный набор
Чек-лист базовой безопасности для инди-разработчиков и малых операторов: отраслевые стандартные меры — MFA, гигиена секретов, мониторинг CVE, резервные копии — в порядке приоритета «ключи от королевства → секреты и код → приложение → обнаружение».
Для инди-разработчиков и малых операторов, не уверенных, «сколько же минимум» для безопасности. Здесь нет шагов атаки — лишь фундамент, считающийся отраслевым стандартом, в порядке приоритета. Каждый пункт ссылается на более глубокую статью, так что можно начать здесь и читать только нужное.
Взгляд этого сайта: не «делать всё», а «заполнять в этом порядке»
Одиночка или малая команда не могут сделать всё сразу — именно поэтому порядок решает всё. Если верхний слой, «ключи от королевства», захвачен, любая мера ниже него становится бессмысленной (атакующий сбросит всё от вашего имени). Заполняйте от фундамента вверх — и вы сильнее всего снизите вероятность инцидента за имеющееся время. Эта статья написана не как исчерпывающее знание, а как карта, позволяющая мгновенно решить, что заполнять дальше.
Уровень 0 — ключи от королевства
MFA · домен · DNS · почта · платежи
Уровень 1 — секреты и код
секреты вне git · обнаружение в pre-commit · разделение/ротация ключей
Уровень 2 — само приложение
валидация ввода · аутентификация/сессии · TLS/заголовки · аутентификация почты
Уровень 3 — патчи, обнаружение, восстановление
CVE зависимостей · обновления ОС · SSH/FW · логи · резервные копии
Уровень 0 — защитите ключи от королевства (первым делом)
Это предпосылка для всего остального. Если ваш домен, почта или панель хостинга захвачены, любая другая мера обнуляется. Атакующий сбрасывает пароли от вашего имени, переписывает DNS, входит на ваш сервер. Поэтому это вы запираете в первую очередь.
Поставьте устойчивую к фишингу MFA
Считайте почту «родительским ключом», берегите её сильнее всего
Храните коды восстановления и резервные коды безопасно
Разделяйте аккаунты, чтобы снизить единые точки отказа
Уровень 1 — не дайте утечь секретам или коду
Учредительный инцидент этого сайта, как и многие в мире, происходит из пробела здесь: секреты вроде файлов .env и API-ключей, проскальзывающие в код или публичный репозиторий.
Держите секреты вне исходников и документов
.env и исключайте их из git (.gitignore). Вообще не вписывать их — сильнейшая мера.Останавливайте секреты машинно до коммита
Если утекло, считайте, что утекло ВСЁ — ротируйте всё
Ограничивайте токены узко и держите их короткоживущими
Самохостинг Git? Дополнительная осторожность
Самохостинг из-за того, что «случайно публичный» в GitHub пугает, не убирает случайный коммит. Без встроенной блокировки секретов GitHub хук pre-commit для секретов обязателен на самохостинге. См. самохостинг Git vs GitHub: что безопаснее.
Уровень 2 — укрепите само приложение
Минимум для веб-приложения, которое вы выставляете наружу. Суть не в остановке новых атак, а в закрытии распространённых, хорошо известных дыр. Этот сайт переформулирует каждую в защиту на своих страницах глоссария.
Никогда не доверяйте вводу (закройте классические дыры)
Сделайте правильными аутентификацию, сессии и доступ
Сделайте TLS и заголовки безопасности значимыми
Предотвратите подделку почты
Уровень 3 — патчи, обнаружение, восстановление
Фундамент для «держать ущерб малым и быстро восстановиться даже после взлома». Мониторинг зависимостей вроде osv-scanner живёт здесь.
Машинно отслеживайте CVE зависимостей непрерывно
Автообновляйте ОС и сервер
Укрепите SSH и фаервол
Наименьшие привилегии для сужения зоны поражения
Резервные копии 3-2-1 + проверенное восстановление
Храните логи, чтобы замечать аномалии
С чего начать
«Всё, прямо сейчас» нереалистично. Сравните порядок, который люди обычно берут, с тем, что рекомендует этот сайт.
Порядок, который люди обычно берут (неэффективно)
- начинают с эффектной работы над уязвимостями приложения
- оставляют MFA «на потом» бесконечно
- есть резервные копии, но восстановление ни разу не пробовали
- секреты в
.env, но нет хука обнаружения
Порядок, который рекомендует этот сайт
- Уровень 0: сначала запереть ключи от королевства (MFA, почта, домен)
- Уровень 1: структурно остановить утечки секретов (обнаружение в pre-commit + политика ротировать-всё)
- Уровень 2: закрыть классические дыры приложения
- Уровень 3: дойти до «восстановимого» через мониторинг зависимостей, обновления, проверенные восстановлением резервные копии
Этот сайт тоже защищается в этом порядке
Этот сайт применяет тот же фундамент к себе: выделенный сервер без соседства (разделение зоны поражения) / отдельный ключ на хост / секреты никогда в git или документах / мониторинг CVE зависимостей перед каждым развёртыванием и ежедневно / резервные копии вне площадки на отдельный сервер / внешние запросы через границу безопасности. Сайт, который учит безопасности, не может иметь собственных дыр — поэтому мы прогоняем этот порядок приоритетов на себе первыми. Наш учредительный инцидент тоже произошёл не из новой атаки, а из единственного пробела в этом фундаменте. Поэтому мы и повторяем: фундамент прежде эффектной работы.
Читать дальше
- Версия для организаций / команд: базовая безопасность для средних и крупных организаций
- Самохостинг: самохостинг Git vs GitHub: что безопаснее
- Зависимости: установка и использование osv-scanner · не отставать от CVE
- Секреты: файлы .env и секреты · инцидент ключ утёк и пошли мошеннические счета
- Инструменты: проверка заголовков безопасности · проверка аутентификации почты · поиск CVE/KEV
FAQ
QКакую меру безопасности инди-разработчику настроить первой?
Защитить «ключи от королевства»: поставить устойчивую к фишингу MFA (passkey/аппаратные ключи) на регистратора домена, DNS, панель хостинга, почту и платёжные аккаунты. Если их захватят, любая другая мера обнуляется — поэтому они идут первыми.
QВсе базовые меры одинаково важны?
Нет. Есть чёткий порядок. Этот сайт рекомендует заполнять так: 1) ключи от королевства, 2) секреты и код, 3) само приложение, 4) патчи/обнаружение/восстановление. При конечных ресурсах сверху вниз снижает число инцидентов сильнее всего.
QСчитается ли мониторинг CVE зависимостей базой?
Да. Непрерывная машинная проверка зависимостей на известные уязвимости с помощью osv-scanner или pnpm audit теперь отраслевой стандарт. Большинство серьёзных взломов происходит из заброшенных известных дыр (CVE), а не из новых атак.