После утечки переменных окружения в облаке новый ключ нельзя снова слать в чат

В конце августа 2026 года облачная платформа деплоя Zeabur опубликовала инцидент «Unauthorized Access to Project Environment Variable Data». На официальной странице статуса сказано: злоумышленник воспользовался утёкшими внутренними административными учётными данными AWS, добрался до основной базы и точечно выгружал Variables проектов. Цель — API-ключи ИИ-сервисов и другие секреты, которыми можно пользоваться сразу.

Там же перечислены имена переменных: OPENAI_API_KEY, ANTHROPIC_API_KEY, OPENROUTER_API_KEY, DATABASE_URL, AWS_ACCESS_KEY_ID, а также типичные формы JWT, Stripe и GitHub. Пользовательские имена считались скомпрометированными, если значение совпадало с такими форматами. Zeabur просил отозвать и заменить перечисленные секреты и проверить расход у сторонних провайдеров. Скриншот «полный дамп в продаже» на странице статуса назван неподтверждённым: имеющихся у компании доказательств недостаточно. В этой статье его тоже не считаем фактом.

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

Имя платформы здесь только якорит дату и открытый источник. Вывод годится для любой схемы «сначала ротация, потом передача»: пароль базы, токен CI, временный пароль SSH. Опасность не в том, что коллега увидит секрет. Опасность в том, что каждый прыжок может оставить полную открытую копию. Статья не чинит hardening хостинга и не продаёт UsePwd как сейф, который мог бы остановить чтение на стороне платформы.

Вставьте в канал строку, которая начинается с sk-, и сразу появится несколько копий. Тело сообщения попадает в историю рабочего пространства. Десктоп и телефон держат свой кэш. Многие продукты ещё кладут текст в серверный поисковый индекс, чтобы через три месяца по слову «openai» вытащить его обратно. Выгрузка для админа, юридический hold и архив переписки при увольнении уносят тот же открытый текст. Удалить одно сообщение обычно недостаточно: пуш уже прочитан, клиент уже скачал историю, а утилита скриншотов уже сохранила кадр.

Это другой вопрос, чем «я доверяю коллеге». Коллеге ключ нужен, чтобы сервис снова заработал. Канал по умолчанию хранит искомую рабочую запись, а не секрет, который должен жить только пока его читают. Написать «новый ключ ниже» — значит сообщить всем, кто когда-нибудь сможет искать по этому каналу: людям, которых добавят в следующем квартале, тем, у кого есть право на аудиторскую выгрузку, и тем, кто в будущем доберётся до бэкапа. Обзоры по поиску секретов давно называют это известным путём расползания; в рекомендациях GitGuardian по API-ключам прямо сказано: не передавайте секреты в открытом виде в мессенджерах вроде Slack. Журнал «Код» формулирует жёстче: любая передача токена через мессенджер, почту или демонстрацию экрана приравнивается к компрометации — контроль над строкой вы теряете в момент отправки.

Разложите типичный аварийный runbook на стол: опасность не в клике «войти в консоль провайдера и выпустить новый ключ». Опасность — в шагах вокруг. Кто-то снимает старый ключ и спрашивает коллегу «это тот?». Кто-то захватывает всю страницу консоли, и в «Фото» вместе с ключом уезжают адресная строка, имена других проектов и цифра из биллинга. Кто-то выпускает новый ключ, коллеги нет на месте, и в канал летит «пока вот этим». Все три превращают открытый текст в объект, который будут хранить.

Общий диск и git пропускают ещё легче. Сырой .env в папке команды или коммит-пример, в котором ключ всё ещё есть, — ещё одна копия. Облачная синхронизация пишет файл на каждое вошедшее устройство: Яндекс Диск, Google Диск, общий каталог на NAS. Позже поменять файл недостаточно: строка остаётся в старых коммитах. Локальную копию одного файла до 5 ГБ лучше превратить в шифротекст в текущей вкладке, а не загружать открытый .env как обычный документ. Шифрование файлов UsePwd делает потоковое локальное шифрование AES-256-GCM и пишет .lock / .enc. Файл по умолчанию не загружается. Это «оставить себе файл с шифротекстом», а не «засунуть ключ в чат».

Окно чата отдаёт открытый текст. Копировать удобно обеим сторонам. Цена — рабочее пространство, поисковый индекс и бэкапы держат по копии. Вложение в письме устроено так же: как только .env или блокнот ушёл вложением, почтовый сервер и оба клиента имеют полный файл.

Одноразовая зашифрованная ссылка отдаёт «номер шифротекста плюс материал расшифровки, который остаётся на устройстве». Burn-Link UsePwd шифрует текст в текущей вкладке через Web Crypto и AES-256-GCM, на сервер уходит только шифротекст. Ключ расшифровки дописывается после # в s.html?id={id}#{key}. Создать и прочитать можно сразу — ни одна сторона не регистрируется. Сервер хранит шифротекст, срок в часах и число прочтений. Открытый текст он не видит, и аккаунтов, по которым можно «восстановить по пользователю», нет.

Ключ после # закрывает слой журналов доступа хостинга и строки HTTP-запроса: браузер не отправляет фрагмент как часть запроса. Этот слой разобран в статье Почему фрагмент # в URL не попадает в логи сервера. Здесь — следующий слой. Даже если ключ не входит в строку запроса UsePwd, полная ссылка в чате всё равно сохраняется целиком в этом продукте. У кого есть полный URL, тот откроет страницу чтения и расшифрует, пока не исчерпан лимит прочтений. Burn-Link ограничивает срок жизни шифротекста на сервере и число чтений. Он не мешает получателю снять скриншот или переслать ссылку.

Если секрет нужно хранить долго, синхронизировать между устройствами или когда-нибудь восстановить, не используйте Burn-Link и не держите историю чата как сейф. Это работа менеджера паролей. У UsePwd нет аккаунтов и хранилища. Когда лимит прочтений исчерпан или ссылка потеряна, вернуть секрет за вас нельзя.

Если секрет — ценный мастер-ключ, корневой сертификат или сид кошелька, которым можно перевести деньги, ни ссылки, ни чата недостаточно. Скажите лично, используйте офлайн-носитель или оставайтесь внутри уже установленного сквозного канала. Схема с фрагментом не останавливает уже захваченное устройство, расширение браузера, которое читает текущую страницу, и полный URL на стене переговорки.

Резервная копия файла — другой путь: открытый .env превратите в .lock / .enc на этой машине, затем положите шифротекст на диск. Пароль разблокировки передайте каналом, который не является самим файлом. Не склеивайте два инструмента в одно обещание. Burn-Link задаёт, сколько раз можно прочитать короткий секрет. Шифрование файлов задаёт файл с шифротекстом, который вы оставляете себе.

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