управление секретами
8 статей с этим тегом
Останавливайте секреты до коммита с gitleaks: ловите утечки API-ключей до push
Секреты нельзя «удалить после утечки». Раз закоммиченный, секрет остаётся в истории Git, а раз запушенный — его надо считать утёкшим: ключ нужно отозвать/сменить. gitleaks — бесплатный инструмент, сканирующий весь репозиторий и историю коммитов по regex/энтропии, чтобы найти API-ключи, приватные ключи и токены. Ядро защиты — двое ворот: хук pre-commit, останавливающий локально до push, и CI/cron, ловящий то, что просочилось. .gitignore лишь предотвращает новое отслеживание — он не умеет обнаруживать, так что сканер всё равно нужен.
Безопасны ли менеджеры паролей? Как они работают, облако vs локально и как выбрать
Менеджер паролей безопаснее переиспользования или хранения открытым текстом. Ключ — шифрование с нулевым разглашением: ваш мастер-пароль расшифровывает хранилище только на вашем устройстве, провайдер держит только шифртекст, поэтому взлом провайдера не раскрывает ваши пароли. Настоящая единая точка — это ваш мастер-пароль плюс MFA на хранилище. Выбирайте облако (Bitwarden/1Password) или локально (KeePass) по применению.
Базовая безопасность для инди-разработчиков и малых операторов: весь стандартный набор
База — это не «всё одинаково важно». Порядок приоритета этого сайта: 1) ключи от королевства (MFA, домен, почта), 2) секреты и код, 3) само приложение, 4) патчи, обнаружение, восстановление. При конечном времени заполняйте сверху вниз. Большинство серьёзных взломов происходит не из-за новых атак, а из-за пробела в этом фундаменте.
Инвентаризация безопасности — 7 проверок, которые упускают владельцы нескольких серверов
Для одиночек/малых операторов инциденты происходят не столько из отсутствующих мер, сколько из неотслеживаемого состояния. Граница — это ПК, хранящий ваши ключи. Ранжируйте 2FA по корню доверия, составьте матрицу SSH-ключей, чтобы убить дубликаты/неиспользуемые/осиротевшие, уберите пароли открытым текстом из облака, устраняйте обратимо по одному и держите секреты вне реестра. Инвентаризация прежде добавления инструментов.
Безопасно ли хранить пароли в Google Drive? Как держать их правильно
Держать пароли в документе/таблице Google открытым текстом опасно: один аккаунт Google становится единой точкой отказа для каждого пароля — захват аккаунта, вредоносное подключённое приложение или фишинг утекают их все разом. Исправление — специализированный менеджер паролей (содержимое остаётся зашифрованным даже при синхронизации). Если вы обязаны использовать Drive, храните только зашифрованный файл хранилища и поставьте устойчивую к фишингу MFA на аккаунт.
Оставили файл с секретом в публичной директории? Проверьте свой webroot
Всё, что в вашем webroot, любой может скачать по URL. Забытый JSON с токеном/учётными данными, .env или резервная копия означают мгновенную утечку — и если он пришёл из общего шаблона, дыра одна и та же у каждого сайта. Исправление: кладите в публичную директорию только то, чем можно публично делиться, держите секреты вне webroot с правами 600, а найдя один — проверьте каждый сайт и хост.
Самохостинг Git vs GitHub: что на самом деле безопаснее?
Самохостинг Git не делает вас «безопаснее» — он перемещает риск. Класс случайной публичной выставленности исчезает, но патчинг сервера, резервные копии и обнаружение секретов в pre-commit переходят на вас. Правильный выбор, если вы платите цену; хуже GitHub, если запускаете. Взгляд этого сайта: самохостинг работает только в связке с компенсирующими мерами.
Утечка Codecov (2021) — когда «доверенный инструмент» в CI был взломан и утекли секреты
Доверенный инструмент CI (Bash Uploader на curl|bash) был изменён на стороне поставщика. Поскольку ваш собственный код не трогали, это оставалось незамеченным ~2 месяца, пока утекали секреты CI; поймала это проверка контрольной суммы. В вашем CI: проверяйте загружаемые артефакты, минимальные привилегии секретов, ротация, мониторинг исходящего трафика.