Кто-то из сотрудников ввёл пароль на странном сайте, а разработчик нашёл ключ в репозитории. В такие моменты безопасность зависит от того, кому они напишут, что команда сделает дальше и какие ограничения уже стоят на пути у атакующего.
Кто-то из сотрудников ввёл пароль на странном сайте, а разработчик нашёл ключ в репозитории. В такие моменты безопасность зависит от того, кому они напишут, что команда сделает дальше и какие ограничения уже стоят на пути у атакующего.
В статье есть ссылки партнеров. Это значит, что если вы что-то покупаете с нашей помощью — вы также поддерживаете dev.by. (Вот другой способ).
При этом редакция и авторы независимы в выборе темы, концепции материала, фокуса описания, подхода к услугам или товарам. Прежде чем что-то советовать, мы много читаем и смотрим по теме, говорим с экспертами.
Редакция может выражать свое мнение и пробовать всё на себе.
Если рекомендательный материал обновляется, мы указываем, что и когда поменялось, в самом начале.
Специалисты по кибербезу встревожены: в отчёте Verizon за 2025 год человеческий фактор присутствовал примерно в 60% разобранных инцидентов. Среди утечек, где известен начальный вектор и исключены ошибки и злоупотребления, эксплуатация уязвимостей составила 20%. По сравнению с предыдущим отчётом показатель вырос на 34%.
Даже внимательные сотрудники иногда открывают подозрительные ссылки, вводят пароли не на тех сайтах или случайно публикуют секретные ключи. Но проблемы с безопасностью возникают и без их участия: например, когда атакующие используют уязвимости в программном обеспечении.
В октябре нидерландский центр кибербезопасности на время отключил собственный сайт. Причиной стали две критические уязвимости PHP: они потенциально позволяли выполнить код извне без авторизации. Команда PHP выпустила исправления, а организациям пришлось выяснять, какие приложения используют уязвимые версии.
Такие истории показывают, почему безопасность не сводится к инструкциям вроде «не переходите по подозрительным ссылкам» и «используйте сложные пароли». Сотрудники должны знать, куда сообщать о возможной ошибке, а техническая команда — кто проверяет угрозу, принимает решение и устраняет последствия.
При этом даже удачная фишинговая атака не обязательно заканчивается взломом. Многое зависит от того, какие средства защиты компания предусмотрела заранее. Хороший пример — история Cloudflare.
В 2022 году людям в Cloudflare пришли сообщения со ссылкой на поддельную страницу входа. Трое ввели данные, но войти в систему атакующие не смогли: требовался аппаратный ключ. Так описывает случай сама компания, по словам которой её системы не были скомпрометированы.
После атаки Эван Джонсон и Дерек Питтс рассказали в блоге Cloudflare, как переходили от одноразовых кодов к аппаратным ключам. У ключа ответ привязан к адресу сайта: поддельная страница не получает тот же ответ, что настоящий сервис. Это защита на случай, когда правдоподобное письмо всё же сработало.
С учебным фишингом тоже бывает непросто. Автор одного поста на Reddit рассказал, как разослал тестовое письмо и получил неожиданную реакцию: коллеги подняли тревогу и стали предупреждать друг друга. После раскрытия теста некоторые рассердились. Это рассказ участника, а не независимо подтверждённый кейс.
Phishing simulation caused chaos
by u/AspiringTechGuru in sysadmin
Инженер по безопасности GitHub Майкл Рекачинас описывает в блоге компании, как сканер нашёл в репозиториях GitHub больше 20 тысяч подозрительных секретов. Около 18 тысяч срабатываний пришлись на пять репозиториев с тестовыми или уже неактивными ключами. Остальные пришлось разбирать: выяснять, действует ли ключ, кто за него отвечает и как его заменить. Замена, или ротация, означает выпуск нового ключа и отзыв старого.
Само обнаружение — только начало. Рекачинас пишет, что поиск владельцев оказался отдельной задачей: без человека, который может отозвать ключ, предупреждение легко остаётся висеть в списке.
Для новых секретов команде нужен понятный способ хранения. В OWASP Secrets Management Cheat Sheet описывают специализированные хранилища, ограничение доступа, ротацию и отзыв. Сканер помогает заметить ошибку, а заранее определённый владелец — разобраться с ней.
С подозрительным письмом примерно так же: фильтр способен остановить часть сообщений, а необычную просьбу можно проверить через другой канал и переслать тому, кто разберётся. В рекомендациях CISA рядом с распознаванием фишинга стоят менеджер паролей, многофакторная защита и обновления.
Другой участник Reddit рассказывает, что узнал об утечке токенов у поставщика документации. Эти электронные ключи открывали доступ к репозиториям его компании. Он начал менять ключи и проверять журналы, а потом попросил коллег на форуме подсказать, что ещё проверить.
Nightmare situation — our companies GitHub read / write access token has been compromised for months.
by u/Impressive_Lab_6551 in ExperiencedDevs
Допустим, коллега пишет в рабочий чат: «Я ввёл пароль на странном сайте». По рекомендации британского центра кибербезопасности, о таком случае на рабочем устройстве нужно сообщить в IT-службу. В сообщении можно указать, какой аккаунт затронут и что именно произошло, не пересылая сам пароль.
Дальше подключается тот, кто отвечает за доступ. В зависимости от системы он поможет сменить пароль, проверить входы и при необходимости закрыть активные сессии. Конкретный порядок зависит от инфраструктуры: у небольшой команды эти действия может выполнять администратор, у другой есть дежурная служба.
Похожий разбор можно провести для ключа в репозитории. GitHub рекомендует считать утёкший секрет скомпрометированным: просто удалить его из кода недостаточно. Владельцу нужно оценить доступ и быстро отозвать ключ; если от него зависит работа сервиса, замена потребует согласования с командой.
Теперь попробуйте проиграть один из сценариев без настоящих паролей и ключей. Кто получает первое сообщение? Доступен ли этот человек вне рабочего дня? У кого есть права закрыть сессию или заменить ключ? Если ответ нашёлся только после нескольких звонков, команда знает, что уточнить до настоящего инцидента.
В NIST SP 800-61 Rev. 3 подготовку и восстановление рассматривают вместе с реагированием. Такое упражнение помогает проверить, как этот порядок работает у вас.
Где лежат секреты. Если для ключей есть общее хранилище, а система сборки получает их штатным способом, разработчику проще обойтись без ключа в коде. О том, какие права получают инструменты разработки, говорит и OWASP.
Как устроен вход. Менеджер паролей помогает создавать и хранить отдельные пароли для сервисов. Многофакторная аутентификация, или MFA, добавляет второй шаг при входе. А для важных аккаунтов можно рассмотреть устойчивые к фишингу способы, в том числе аппаратные ключи; их свойства описаны в справке FIDO Alliance.
Куда сообщать о подозрительном. Письмо от руководителя с необычной срочной просьбой, неожиданное подтверждение входа или поддельная страница GitHub — поводы перепроверить запрос. Когда понятен канал связи с технической командой, сообщить проще, даже если человек уже успел ошибиться.
Кому и что доступно. Сервисам и людям можно выдавать только те права, которые нужны для работы. Например, процессу сборки, которому нужно одно хранилище, не обязательно выдавать доступ ко всему облачному аккаунту. OWASP разбирает этот принцип для разных частей процесса сборки и доставки кода.
Кто отвечает, когда что-то случилось. Найденный в репозитории ключ и чужой вход в аккаунт требуют разных действий. В обоих случаях важно знать, кто принимает сообщение и кто может отозвать доступ.
В статье об аппаратных ключах инженеры Cloudflare рассказывают не только про саму технологию: компании пришлось менять способ входа во внутренние приложения. Без этого одного выданного ключа было бы мало.
В других командах работа, скорее всего, начнётся с более простых вещей: готового шаблона для секретов, менеджера паролей или канала, куда можно отправить подозрительное письмо. А проверить, работает ли новый порядок, можно на обычной задаче: выдать доступ новому человеку или выяснить, кто отзовёт ключ из старого репозитория.
В большой инфраструктуре руками не проверить каждый коммит и каждое изменение прав. Здесь нужны мониторинг, автоматические проверки и люди, которые следят за уязвимостями. OWASP Top 10:2025 включает проблемы доступа, зависимости и наблюдения за событиями — это задачи шире одного фишингового письма.
История GitHub показывает и другую сторону автоматизации: сканер нашёл подозрительные ключи, но каждое срабатывание ещё нужно было оценить и направить тому, кто может что-то исправить.
Курс Cybersecurity Awareness Essentials for Employees на Coursera рассчитан на людей без технической подготовки: там разбирают фишинг, пароли, MFA и безопасную удалённую работу. Учебная программа может дать общий словарь, но не расскажет, кто именно принимает сообщения об инцидентах в вашей компании.
Курс Security Awareness Training Майкла Бьокки на Udemy подойдёт для знакомства с безопасностью в работе и личной жизни: в программе есть подозрительные письма, случайные утечки и защита устройств. Отдельные занятия посвящены данным в инструментах генеративного ИИ. Курс вводный и не рассчитан на углублённое изучение безопасности.
Возьмите один простой сценарий: подозрительное письмо или ключ в репозитории. Попробуйте пройти его вместе с теми, кто будет реагировать на самом деле: кому написать, у кого есть доступ и что произойдёт дальше. Найденный пробел станет первой конкретной задачей, которую можно будет считать решенной.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.