Пустьключпротухнет.

Что происходит с ключом доступа, который разработчик по ошибке выложил в открытый код? Кажется, что ответ один: рано или поздно его кто-нибудь найдёт. Truffle Security проверила это на 224 миллионах публичных репозиториев GitHub, и ответ зависит от того, чей это ключ. Из 101 886 утёкших токенов npm сейчас работает один. Из 126 963 ключей сервисных аккаунтов Google Cloud — 69 041, больше половины. В заголовки попали полмиллиона живых ключей, а меня зацепила эта пара. Ошибка одна и та же, люди примерно те же. Откуда разница в десятки тысяч раз?

Ответ скучный: токен npm умирает сам, а ключ Google Cloud нет. В декабре 2025 года npm отозвал все старые классические токены разом, а новым токенам с правом записи разрешил жить не дольше 90 дней. А в документации Google Cloud прямо написано, что по умолчанию ключи сервисных аккаунтов не истекают никогда. Получается, чем кончится утечка, решили задолго до неё, в день, когда ключ создавали. И, скорее всего, никто там ничего не решал, просто оставили значение по умолчанию.

В том же исследовании есть цифра, после которой это перестаёт быть мелочью. Половина утёкших ключей лежит в открытом доступе дольше 784 дней, больше двух лет. Утечка, выходит, длится годами. С 2024 года GitHub по умолчанию не даёт отправить в репозиторий многие виды ключей. Но эта защита, по словам Truffle, останавливает секреты на входе и ничего не может сделать с теми, что уже внутри. Да и на входе ловит не всё. Около 200 тысяч живых ключей утекли уже после её включения. А больше половины живых относятся к видам, которые она по умолчанию не проверяет, вроде строк подключения к базе данных.

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

Что делают раз в год

С сертификатами для сайтов на прошлой неделе сделали то же, что npm с токенами, только по расписанию. Let's Encrypt бесплатно выдаёт сертификаты для HTTPS, по старой памяти их зовут SSL-сертификатами. 7 октября он объявил: с 10 февраля 2027 года его сертификаты по умолчанию будут жить 64 дня вместо 90, а в 2028-м — 45. Вся отрасль идёт туда же. Правила для удостоверяющих центров принимает CA/Browser Forum, куда входят и сами центры, и разработчики браузеров. Ещё в 2025 году там утвердили график: с марта 2026-го сертификат живёт не больше 200 дней, с марта 2027-го — 100, к 2029-му — 47. Ещё весной сертификат можно было купить на год.

Новость обычно пересказывают как «готовьтесь продлевать чаще», и звучит она как лишняя возня. Но Let's Encrypt объяснил эту логику ещё в 2015 году, когда выбирал 90 дней. Короткий срок ограничивает ущерб, если ключ украли. И он подталкивает к автоматизации, потому что нельзя и дальше рассчитывать, что администраторы будут продлевать сертификаты руками.

По-моему, главное здесь во второй причине. С бессрочным или годовым ключом замена всё равно случится, просто редко. А редкое делают руками, по памяти, по заметке в чьём-то календаре. Человек, который в прошлый раз помнил, где лежит этот ключ и в каких пяти местах его надо поменять, к следующему разу вполне может работать в другой компании.

Как это выглядит, показал Ericsson в декабре 2018-го. В программах его оборудования истекли сертификаты, оборудование отключилось, и без мобильной связи остались миллионы абонентов O2 в Великобритании и абоненты SoftBank в Японии. Никто ничего не взламывал. Просто наступила дата, про которую забыли.

У Мартина Фаулера есть заметка с правилом «если больно — делайте чаще». Он писал её про то, как часто сливать код в общую ветку, но работает правило где угодно. Действие, которое делают раз в год, каждый раз делают как впервые. Раз в два месяца так уже не выйдет, проще один раз автоматизировать. В этом и весь смысл 64 дней: продлевать руками так часто никто не станет.

Даже настроенная автоматизация может держать старое число. Let's Encrypt отдельно просит поискать в расписаниях и скриптах зашитые 83, 80 или 60 дней: скрипт, написанный под 90-дневный сертификат, при 64 днях может просто не успеть. Советуют продлевать на двух третях срока и ставить оповещение, если продление сорвалось. Проверить настройку можно заранее: с 14 октября тестовая среда Let's Encrypt (staging) выдаёт сертификаты на 64 дня. А если клиент поддерживает ARI, Let's Encrypt сам подсказывает ему, когда продлевать.

Где такие ключи у вас

Сертификат сайта часто уже продлевается сам, через хостинг или certbot. С ключами доступа к сервисам хуже, а в обычном бизнесе их полно: CRM, платёжка, рассылки, бот в Telegram, таблицы, нейросеть. Я собирал автоматизации на n8n, где обращения из Instagram и Telegram попадают в CRM, и в такой связке у каждого соединения свой ключ. Создают их обычно один раз, в день запуска, торопясь, а значение по умолчанию у многих сервисов, как у Google Cloud, — «без срока». Это ровно тот ключ, который через два года лежит в чьём-то старом репозитории или в коде страницы и всё ещё открывает дверь.

С чего бы я начал. Новым ключам — срок с первого дня. Выбирайте не «бессрочно», а 90 дней или меньше, где сервис даёт такую настройку: у GitHub это поле при создании токена, у Google Cloud — политика организации. И сразу ставьте замену (её называют ротацией ключей) в автоматизацию, а не в календарь. Если автоматизировать нечем, пусть у ключа хотя бы будут дата, напоминание и имя человека.

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