Руководства по безопасности
Пароли, MFA, устройства, публичный Wi-Fi, серверы, зависимости, Git, открытые окружения — практичные руководства по защите, которые можно применить уже сегодня.
Как безопасно хранить пароли — правильный способ хеширования и соли
Практическое руководство по безопасному хранению паролей на сервере. Поймите, почему открытый текст, шифрование и сырые хеши все проваливаются, затем сойдитесь на одном ответе: соль для каждого пользователя плюс намеренно медленный хеш (рекомендуется Argon2id, bcrypt/scrypt как альтернативы). Не изобретайте своё — используйте стандартную функцию, со временем повышайте стоимость и переносите слабые хеши перехешированием при входе.
Безопасность для эпохи ИИ: что закрыть прямо сейчас (приоритетный чек-лист)
ИИ в основном усиливает атаки на СУЩЕСТВУЮЩИЕ слабые места (незакрытые CVE, повторно используемые пароли, открытые секреты), а не изобретает новые — найденные автоматически, быстро, в масштабе. Поэтому лучшая подготовка — закрыть основы в правильном порядке: закрытие CVE + мониторинг зависимостей, искоренение повторного использования + MFA, удаление открытых секретов, минимум привилегий, сокращение публичной поверхности, логи/IOC, резервные копии.
Что работает (и что нет) для безопасности эпохи ИИ — почему по малым сайтам тоже бьют
Четыре мифа эпохи ИИ развенчаны: (1) слишком мал, чтобы стать целью → автоматизация убирает «человек выбирает вас»; (2) нужен особый новый механизм → основы по-прежнему побеждают; (3) продукт делает вас безопасными → проектирование профилактики раньше обнаружения; (4) код от ИИ быстрый, значит безопасный → он выходит с уязвимостями, проверяйте перед публикацией. Работают скучные основы в правильном порядке.
Фишинговое письмо подделало ваш собственный домен? Подделка против взлома и как это остановить
Подозрительное письмо, которое будто пришло с вашего домена, обычно не взлом, а поддельный From, потому что SMTP позволяет кому угодно вписать строку From. Чтение заголовков (Authentication-Results, Received, Reply-To) отличает взлом от подделки. Главная причина, почему оно доходит до входящих, — отсутствие политики DMARC. Исправьте это через SPF → DKIM → DMARC (p=none → reject).
Основы резервного копирования: правило 3-2-1 и план восстановления, переживающий программу-вымогатель
«У меня есть резервная копия» недостаточно — настоящей является только та копия, восстановление из которой вы проверили. Основа: правило 3-2-1 (три копии, два типа носителей, одна вне площадки). Против программы-вымогателя также нужна хотя бы одна «офлайновая или неизменяемая» копия — постоянно подключённая копия шифруется вместе с оригиналом. Облачная синхронизация — не резервная копия (она тиражирует и удаления, и шифрование). Версионирование и периодический тест восстановления завершают практику.
Останавливайте секреты до коммита с gitleaks: ловите утечки API-ключей до push
Секреты нельзя «удалить после утечки». Раз закоммиченный, секрет остаётся в истории Git, а раз запушенный — его надо считать утёкшим: ключ нужно отозвать/сменить. gitleaks — бесплатный инструмент, сканирующий весь репозиторий и историю коммитов по regex/энтропии, чтобы найти API-ключи, приватные ключи и токены. Ядро защиты — двое ворот: хук pre-commit, останавливающий локально до push, и CI/cron, ловящий то, что просочилось. .gitignore лишь предотвращает новое отслеживание — он не умеет обнаруживать, так что сканер всё равно нужен.
Как правильно выбирать MFA: что значит «устойчивый к фишингу» и почему SMS слаб
MFA — это второй замок, чтобы один лишь утёкший пароль не пустил внутрь, но то, что вы включаете, меняет его силу по трём уровням. Коды SMS/email падают перед релейным фишингом и SIM-swap; приложения-аутентификаторы (TOTP) — средний уровень; passkey/аппаратные ключи (FIDO2) вообще нельзя предъявить поддельному сайту — это и есть устойчивость к фишингу. Высший приоритет: поставьте устойчивый к фишингу MFA на ключи от королевства (почта, домен, платежи). Хранение кодов восстановления и наличие резервного фактора завершают настройку.
Всё ещё на Windows 10? Риски безопасности после окончания поддержки
Windows 10 достигла окончания поддержки 14 октября 2025 года. Главный риск дальнейшего использования в том, что вновь найденные дыры никогда не патчатся (вечные уязвимости) и накапливаются, делая машину излюбленной мишенью. Потребительская ESU — это одногодичная заглушка только для безопасности до 13 октября 2026 года (бесплатные пути регистрации есть, но бесплатный первый год EEA не действует в большинстве регионов). Настоящее исправление — переход на Windows 11 или замена оборудования; используйте ESU лишь как мост до завершения миграции.
BitLocker против «Шифрования устройства» — одна и та же технология: полная версия против автоматической облегчённой
BitLocker и Шифрование устройства используют один и тот же движок шифрования. Шифрование устройства = автоматическая облегчённая версия, работающая на Home (включается автоматически с учётной записью Microsoft, ключ восстановления автоматически депонируется, минимум опций). BitLocker = полная версия на Pro+ (PIN при старте, шифрование внешних дисков через To Go, тонкое управление). Для частных лиц обычно достаточно быть автоматически зашифрованным и знать, где ключ восстановления. Состояние важнее названия.
Как по-настоящему закрывать CVE в зависимостях: сканировать, исправлять, изолировать и продолжать следить
Работа с уязвимостями не закончена, когда вы «исправили». Готово = 1) скан, 2) фикс, 3) изоляция/передача, 4) мониторинг. Пока не налажен мониторинг (ежедневное обнаружение изменений), это незавершённо — зависимости снова станут уязвимыми завтра. Идеальное исправление, которое перезаписывает следующий деплой, стоит ноль. Малые команды остаются в безопасности за счёт двух дисциплин: автоматического обнаружения изменений и «локально→push→деплой».
Защита ноутбука, который вы носите с собой — от кражи, потери и подглядывания через плечо
Носить ноутбук — значит исходить из того, что вы его потеряете или его украдут. Настоящая защита спроектирована так, чтобы потеря не привела к утечке содержимого: шифрование диска (BitLocker/FileVault), надёжный вход с короткой автоблокировкой и удалённое стирание/поиск. С повсеместным HTTPS перехват в публичном Wi-Fi менее приоритетен; реальные угрозы — поддельные точки доступа, подглядывание через плечо и отход от устройства. Не переоценивайте VPN — сначала укрепите устройство.
Установка и использование osv-scanner: найти CVE в ваших зависимостях
osv-scanner сканирует lock-файлы и контейнеры, выявляя CVE в ваших зависимостях, бесплатно. Здесь разобраны установка, запуск и интеграция в CI, плюс когда применять его vs npm/pnpm audit vs Dependabot. Взгляд этого сайта: правильный инструмент определяется ВАШЕЙ конфигурацией — берите osv-scanner для проектов с несколькими экосистемами или без GitHub, и встроенный pnpm audit для одного npm-дерева.
Безопасны ли менеджеры паролей? Как они работают, облако vs локально и как выбрать
Менеджер паролей безопаснее переиспользования или хранения открытым текстом. Ключ — шифрование с нулевым разглашением: ваш мастер-пароль расшифровывает хранилище только на вашем устройстве, провайдер держит только шифртекст, поэтому взлом провайдера не раскрывает ваши пароли. Настоящая единая точка — это ваш мастер-пароль плюс MFA на хранилище. Выбирайте облако (Bitwarden/1Password) или локально (KeePass) по применению.
Опасности публичного Wi-Fi — настоящий риск не «прослушка», а злые двойники и игнор предупреждений о сертификате
«Прослушка» публичного Wi-Fi в основном смягчена HTTPS и теперь менее приоритетна. Настоящие риски — (1) самому подключиться к поддельной точке доступа «злому двойнику», (2) проигнорировать предупреждение о сертификате и (3) выставить своё устройство в общую сеть. Сильнейшее средство на удивление простое — используйте раздачу с телефона, доверяйте HTTPS и предупреждениям о сертификате и не подключайтесь автоматически к неизвестным SSID. VPN — следующий слой.
Оставили файл с секретом в публичной директории? Проверьте свой webroot
Всё, что в вашем webroot, любой может скачать по URL. Забытый JSON с токеном/учётными данными, .env или резервная копия означают мгновенную утечку — и если он пришёл из общего шаблона, дыра одна и та же у каждого сайта. Исправление: кладите в публичную директорию только то, чем можно публично делиться, держите секреты вне webroot с правами 600, а найдя один — проверьте каждый сайт и хост.
Базовая безопасность для инди-разработчиков и малых операторов: весь стандартный набор
База — это не «всё одинаково важно». Порядок приоритета этого сайта: 1) ключи от королевства (MFA, домен, почта), 2) секреты и код, 3) само приложение, 4) патчи, обнаружение, восстановление. При конечном времени заполняйте сверху вниз. Большинство серьёзных взломов происходит не из-за новых атак, а из-за пробела в этом фундаменте.
Базовая безопасность для средних и крупных организаций: стандартный фундамент для команд
В масштабе база смещается от «чек-листа» к «программам с владельцами». Порядок приоритета совпадает с инди-версией: 1) идентичность, 2) секреты и цепочка поставок, 3) приложение и инфраструктура, 4) обнаружение и реагирование, плюс сквозной слой людей и управления. Большое изменение: ведущая причина взломов смещается от оплошностей к людям, процессам, доступу уволенных и третьим сторонам.
Инвентаризация безопасности — 7 проверок, которые упускают владельцы нескольких серверов
Для одиночек/малых операторов инциденты происходят не столько из отсутствующих мер, сколько из неотслеживаемого состояния. Граница — это ПК, хранящий ваши ключи. Ранжируйте 2FA по корню доверия, составьте матрицу SSH-ключей, чтобы убить дубликаты/неиспользуемые/осиротевшие, уберите пароли открытым текстом из облака, устраняйте обратимо по одному и держите секреты вне реестра. Инвентаризация прежде добавления инструментов.
Самохостинг Git vs GitHub: что на самом деле безопаснее?
Самохостинг Git не делает вас «безопаснее» — он перемещает риск. Класс случайной публичной выставленности исчезает, но патчинг сервера, резервные копии и обнаружение секретов в pre-commit переходят на вас. Правильный выбор, если вы платите цену; хуже GitHub, если запускаете. Взгляд этого сайта: самохостинг работает только в связке с компенсирующими мерами.
Основы безопасности смартфона — защита устройства, которое держит ваши ключи, хранилище и удостоверение в одном
Телефон концентрирует 2FA, почту, банкинг и удостоверение в одну единую точку отказа. Настоящая защита — не приложение безопасности: (1) сильная блокировка + короткая автоблокировка (код-пароль — это ключ шифрования); (2) автоматические обновления ОС/приложений; (3) официальный магазин + ревизия разрешений; (4) заранее настроить удалённую блокировку/стирание; (5) держать резерв вашей 2FA. iOS/Android уже шифруют и изолируют по умолчанию.
Не давайте root-ключи средам, которые можно скомпрометировать: наименьшие привилегии SSH-ключа
Регистрация root-ключа в продакшене из эфемерной, компрометируемой среды (под GPU, раннер CI, одноразовая ВМ) означает, что в тот миг, когда среда скомпрометирована, продакшен забирают с root. Исправление: никаких root-ключей в эфемерных средах; убирать ключи, когда не используются; если снова нужно — пользователь не root плюс ключ с ограничением команды, ограничивающий ключ одной операцией. Переиспользуемый ключ — ваш самый критичный актив; никогда не стройте конфигурацию «одна утечка — всё».
Безопасно ли хранить пароли в Google Drive? Как держать их правильно
Держать пароли в документе/таблице Google открытым текстом опасно: один аккаунт Google становится единой точкой отказа для каждого пароля — захват аккаунта, вредоносное подключённое приложение или фишинг утекают их все разом. Исправление — специализированный менеджер паролей (содержимое остаётся зашифрованным даже при синхронизации). Если вы обязаны использовать Drive, храните только зашифрованный файл хранилища и поставьте устойчивую к фишингу MFA на аккаунт.
Почему блокируют аккаунт OpenAI: украденные API-ключи и политика дистилляции
Когда украденный API-ключ используют для «дистилляции», даже аккаунт жертвы может быть автоматически заблокирован. Защитное, обезличенное руководство по механизму, профилактике и апелляциям.
Что такое подделка X-Forwarded-For (XFF) — ловушка конфигурации доверенного прокси
XFF — заголовок, подделываемый клиентом. Слепой сканер прячет пробы инъекций в подделанном XFF; «доверять всем прокси (wildcard)» пропускает это. Патч = санировать IP-заголовок на границе; корневое исправление = доверять правильным прокси (или никаким). Нулевое воздействие всё равно оставило настройку для исправления.
Код, написанный ИИ, привёл к утечке API-ключа и мошенническим списаниям — настоящей причиной была незакрытая уязвимость CVSS 10.0
Скачок счёта был симптомом. Настоящей причиной была незакрытая публичная RCE с CVSS 10.0. Обезличенный случай, сведённый к урокам по защите.
Основы безопасности: чем на самом деле опасны .env и API-ключи
Начните здесь. Поймите, что происходит при утечке .env и API-ключей (запасной ключ → выдача себя за вас → мошеннические счета), затем заведите четыре привычки сегодня: не выставлять их наружу, не коммитить, сменить всё при утечке и самопроверяться.
У Laravel-приложений .env был доступен всему миру — самая частая ошибка шаред-хостинга
Причина: всё приложение сидело под веб-корнем; видимым должен быть только public/. Исправление в три шага — первая помощь через .htaccess, смена ключей, реструктуризация — затем профилактика процессом.
Безопасный запуск Next.js: не отставать от опубликованных CVE
Главный риск фреймворка — заброшенные опубликованные CVE. Защищайтесь четырьмя столпами: судите по работающей версии, мониторьте Dependabot/osv-scanner, быстро обновляйтесь и работайте с минимумом привилегий. Взгляд этого сайта: инди-разработчики проигрывают не на знаниях, а на операционной непрерывности — побеждайте системой, которая не пропускает, а не скоростью.
Как держать .env вне публичного веба на общем хостинге
Настоящее исправление: тело приложения вне docroot, наружу только public/. Остановите кровотечение через .htaccess, сделайте постоянным реструктуризацией, затем самопроверка. Взгляд этого сайта: это не оплошность одного человека, а отраслево-стандартизированный плохой паттерн — чините процессом, а не бдительностью. bootstrap-redirect лучше симлинка.