Пароль — это только входная дверь

Когда в команде разработки заходит разговор о безопасности, он почти всегда начинается с паролей. Сложные пароли, регулярная смена, менеджеры паролей, запрет на повторное использование. Всё это полезно и правильно. Но если свести безопасность к паролю, картина получается неполной — примерно как обсуждать безопасность здания, разглядывая только замок на входной двери. Замок нужен, кто бы спорил. Но в здание попадают не только через парадный вход.

Компрометация учётных данных по-прежнему остаётся одним из главных векторов атак. Об этом из года в год пишет Verizon в отчёте DBIR. Слабые пароли — действительно плохо. Но за последние годы контекст сильно изменился.

Даже регуляторы передумали

Долгое время считалось аксиомой: пароли надо менять регулярно, раз в 30–90 дней. Потом за эту практику взялись исследователи и обнаружили занятную вещь. Люди, которых заставляют менять пароль каждый месяц, не придумывают новый хороший пароль. Они берут старый и меняют цифру на конце. Winter2023 превращается в Winter2024, и злоумышленнику это помогает, а не мешает.

В итоге NIST, американский институт стандартов, чьи рекомендации де-факто задают тон всей индустрии, прямо написал в рекомендациях SP 800-63B: принудительная периодическая смена паролей без признаков компрометации не улучшает безопасность. Может даже ухудшить.

Это показательный сдвиг. Индустрия постепенно уходит от ритуальных практик к системному мышлению, где важны контекст доступа, управление сессиями, минимизация прав и контроль сервисных учётных записей.

Кто получает доступ к вашей системе

Возьмём обычный SaaS среднего размера — не гигант, просто типичный продукт. Кто обращается к его ресурсам?

пользователь через веб или мобильное приложение;
серверная часть — к базам данных и очередям;
конвейер сборки и доставки деплоит релизы;
внешние интеграции читают и пишут данные через API;
внутренние сервисы вызывают друг друга;
подрядчики работают с частью инструментов;
боты в Slack или Telegram автоматизируют процессы.

Кто из них использует пароль в привычном смысле? Почти никто, кроме конечного пользователя. Остальные работают с токенами, ключами, сертификатами, подписями запросов, секретами в специализированных хранилищах. И как раз там, где нет привычного пароля, чаще всего и случается взлом.

Атаки происходят не потому, что кто-то выбрал qwerty123. Атаки происходят потому, что в репозиторий попал секрет, потому что токен живёт месяцами без ротации, сервисный аккаунт имеет лишние права, а сессию нельзя быстро отозвать.

Как ломают на самом деле

Теория — дело хорошее, но убедительнее всего говорят реальные случаи. Вот четыре инцидента последних лет, в которых пароль не был главной проблемой.

Украденная сессия: CircleCI, 2023

В январе 2023 года CircleCI сообщила об инциденте: злоумышленник получил доступ к ноутбуку инженера, извлёк токен сессии и обошёл многофакторную аутентификацию. Второй фактор не помог — атакующий переиспользовал уже установленную сессию. Компания попросила всех клиентов сменить секреты, потому что те могли быть скомпрометированы.

Пароль был надёжным, второй фактор стоял. Атака прошла мимо них, через токен сессии.

Токены в диагностических файлах: Okta, 2023

Okta — один из крупнейших провайдеров аутентификации — сообщила, что злоумышленники похитили токены из HAR-файлов, которые клиенты отправляли в службу поддержки. Внутри этих диагностических файлов лежали действующие токены сессий. Результат: доступ к учётным записям сторонних организаций без знания единого пароля.

Если токен можно скопировать в файл и использовать без дополнительной проверки, модель доверия довольно хрупкая.

Отравленный конвейер: Codecov, 2021

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

Цепочка доверия: Uber, 2022

Инцидент Uber — хрестоматийный пример каскадной атаки. Злоумышленник добыл учётные данные подрядчика, прошёл многофакторную аутентификацию бомбардировкой push-уведомлениями, а затем обнаружил во внутренней сети скрипты с привилегированными секретами и двинулся дальше по инфраструктуре.

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

Причём тут разработчик

Распространённое заблуждение: безопасность доступа — дело отдела безопасности и администраторов. На практике разработчик ежедневно принимает решения, которые напрямую определяют, насколько система уязвима.

Простой пример. Вы пишете обработчик /api/invoices/:id.

Вариант А: проверяете только аутентификацию — пользователь вошёл, значит, пускаем.
Вариант Б: проверяете и аутентификацию, и авторизацию на уровне объекта — этот пользователь имеет право видеть именно этот счёт.

Разница не косметическая. Вариант А — готовая утечка чужих данных.

Другой пример. Вы внедряете токены для внешних интеграций.

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

Функционально работают оба варианта. Уровень риска различается на порядок.

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

Аутентификация отвечает на вопрос «кто ты?» — пароль, биометрия, одноразовый код, аппаратный ключ. Авторизация отвечает на вопрос «что тебе можно?» Даже после успешного входа пользователю может быть доступно только чтение собственных данных. Смешивание этих двух проверок — одна из самых частых ошибок в веб-приложениях.

Сессия — период, в течение которого система доверяет субъекту после входа. Важны время жизни, привязка к устройству, возможность отзыва. Все четыре инцидента выше так или иначе связаны с тем, что сессии или токены контролировались недостаточно.

Многофакторная аутентификация добавляет к паролю второй фактор — код из приложения или аппаратный ключ. Это заметно снижает риск, но не обнуляет его: фишинг, перехват сессии, навязчивые push-уведомления остаются возможными. CISA подробно разбирает эти сценарии в руководстве по устойчивой к фишингу аутентификации.

Наконец, принцип нулевого доверия (Zero Trust) — подход, при котором сеть сама по себе не считается безопасной зоной. Каждый запрос проверяется по контексту, идентичности, устройству и политике доступа. NIST описал эту архитектуру в SP 800-207. Для разработчика это означает: меньше неявных допущений, больше явных проверок на каждом уровне.

Что с этим делать

Ниже — не исчерпывающий список, но надёжная отправная точка для команды, которая хочет выйти за рамки «надёжный пароль = безопасность».

Сокращайте время жизни токенов. Короткоживущий токен доступа, отдельный токен обновления, политика ротации, механизм отзыва.
Применяйте принцип минимальных привилегий. По умолчанию запрещено всё. Права выдаются под конкретную задачу и регулярно пересматриваются.
Разделяйте контуры для людей и сервисов. Учётные записи людей, сервисные аккаунты и интеграционные ключи живут по разным правилам.
Храните секреты в специализированных хранилищах. Не в репозитории, не в переменных окружения открытым текстом, не в скриптах.
Стройте наблюдаемость. Журналируйте входы, выдачу токенов, ошибки авторизации, аномальные паттерны запросов.
Проектируйте отзыв доступа заранее. Инцидент случится — вопрос только когда. Сможете ли вы быстро отключить токен, сессию, сервисный ключ без недельного ручного разбирательства?
Делайте безопасный путь удобным. Если правильный способ сложнее обходного, команда будет обходить.

Про пароли всё-таки не забывайте

Важно не впасть в другую крайность. Из того, что пароль — не центр системы безопасности, не следует, что он не важен. Надёжный пароль, менеджер паролей, защита от подстановки украденных учётных данных — это по-прежнему база. Просто база ещё не вся система.

Пароль — один из факторов, один из слоёв. Если остальные слои слабы, один хороший пароль не спасёт. Если слои сильны, даже компрометация пароля не обязана вести к катастрофе.

Поэтому индустрия движется к устойчивым к фишингу методам — в первую очередь к passkeys. Альянс FIDO подробно описывает их преимущества: снижается риск фишинга, исчезает проблема повторного использования секретов.

Итого

Мы слишком часто обсуждаем безопасность как проблему поля «Пароль» в форме входа. Привычка понятная, но она давно не отражает реальную картину.

Современные атаки нацелены на более выгодные точки: токены, сессии, секреты в конвейерах сборки, сервисные аккаунты, ошибки авторизации между сервисами. И именно разработчик во многом определяет, будут ли эти точки защищены.

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

В следующих постах разберём эту картину подробнее: принцип нулевого доверия на практике, почему дедлайны становятся угрозой безопасности и чем опасен чужой код в ваших зависимостях.