Ключи доступа к API: где хранить и как не потерять данные

Ключ доступа к API — это строка символов, предъявив которую, любая программа получает право делать в вашей системе то, что вы этому ключу разрешили. Разрешают ему обычно всё, потому что так быстрее запускается интеграция. Хранится он чаще всего в переписке с подрядчиком и в поле настроек сценария открытым текстом, а срока жизни у него нет. Такая связка живёт в компании годами и обнаруживается ровно в двух ситуациях: при аудите и после инцидента.

Разница между «есть порядок» и «нет порядка» здесь измеряется в деньгах и в часах. Утечка одного ключа, выпущенного отдельно под одну интеграцию и с урезанными правами, обходится в 8 100 ₽ и двадцать минут простоя. Утечка общего ключа с полными правами — в 37 200 ₽ и остановку всех шести интеграций, потому что менять его придётся везде одновременно, а понять, что успели прочитать, будет нечем.

Разберём по порядку: чем ключ отличается от пароля, куда расползаются его копии, как выглядит на практике «отдельный ключ с минимальными правами», сколько занимает плановая смена, что делать в первый час после утечки и что из этого должно быть записано в договоре с подрядчиком.

Ключ — не пароль, и это не придирка к словам

Отличий от пароля три, и все три работают против вас. Первое: пароль вводит человек, ключ предъявляет программа, поэтому по нему не видно, кто именно сейчас за клавиатурой, — обращение с чужого компьютера выглядит точно так же, как обращение вашего сценария. Второе: у ключа нет второго фактора. Подтверждения по СМС, приложения-аутентификатора и вопроса «это точно вы» здесь не существует: предъявил строку — получил доступ. Третье: у ключа по умолчанию нет срока жизни. Пароль сотрудника рано или поздно меняется по регламенту, а ключ, выданный в 2023 году, работает и сегодня, если его никто не отозвал.

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

Куда расползаются копии ключа

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

• Поле настройки сценария или интеграции. Единственная копия, о которой все знают. Если она вписана открытым текстом, а не подставляется ссылкой на хранилище, она автоматически попадает в две следующие строки списка.
• Журнал прогонов площадки. Тело запроса сохраняется целиком, а ключ едет в теле или в заголовке запроса. Значит, он лежит в журнале ровно столько, сколько площадка хранит журналы, — на массовых тарифах это 7–30 дней, и вы этим сроком не управляете.
• Экспорт сценария. Файл выгрузки содержит настройки узлов вместе с вписанными в них значениями. Сотрудник, выгрузивший копию «на всякий случай» перед увольнением, уносит с собой действующий доступ к вашим системам.
• Переписка с подрядчиком. Первая передача ключа почти всегда идёт через мессенджер или почту. Эта переписка не удаляется, синхронизируется на личные устройства и переживает и проект, и договор.
• Резервные копии и рабочие ноутбуки. Копия настроек в бэкапе, черновик в заметках, скриншот в папке «на память». Эти копии не отзываются вместе с ключом — они просто перестают работать в момент, когда его сменили, и это единственная причина менять ключи по расписанию.

Отдельный ключ на каждую интеграцию с минимальными правами

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

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

Имя ключа — отдельная мелочь, которая экономит часы при разборе. Не «Интеграция» и не «API», а «Обмен_сайт_заказы_чтение» или «Подрядчик_Иванов_до_2026-12-31». По такому имени через год понятно, что отзывать и что при этом сломается. Общие правила хранения секретов трёх разных классов и выбор хранилища мы разбирали отдельно — где хранить пароли и ключи компании; здесь речь только о ключах интеграций.

Плановая смена: регламент на 20 минут в квартал

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

1. 1
   Шаг 1. Открыть список ключей в каждой системе-источнике

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

2. 2
   Шаг 2. Отозвать всё, что не опознано

   Ключ, назначение которого никто не может назвать, отзывается. Если что-то сломается, вы узнаете об этом в тот же день и восстановите за десять минут; если не сломается — вы только что закрыли доступ, о котором не знали. Это самый выгодный шаг всего регламента.

3. 3
   Шаг 3. Сменить ключи, которым больше года, — с перекрытием

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

4. 4
   Шаг 4. Записать дату следующей проверки

   В календарь, а не в память. Плюс отдельное правило-исключение: ключ подрядчика отзывается не по расписанию, а в день окончания работ, и это условие пишется в договор заранее одной строкой.

Стоимость всей подготовки — 27 000 ₽ разово: девять часов работы на разделение общего ключа на отдельные, урезание прав и включение журнала обращений. Поддержание — 20 минут в квартал, около 1 500 ₽ в год по полной стоимости часа сотрудника. Ниже видно, с чем это сравнивается.

Утечка: первый час и как понять, что ключом пользовались

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

1. 1Выпустить новый ключ и перевести на него интеграцию. Именно в этом порядке, а не «сначала отозвать». Отзыв до перевода останавливает процесс, а вам сейчас нужна не тишина, а контроль.
2. 2Отозвать скомпрометированный ключ. С этого момента все существующие копии — в переписке, в экспорте, в журнале, на ноутбуке — превращаются в бесполезные строки. Это и есть главное действие, остальные нужны для оценки ущерба.
3. 3Поднять журнал обращений по этому ключу за максимально доступный период. Здесь выясняется, пользовался им кто-то посторонний или нет. Без журнала этот шаг невыполним, и дальше приходится исходить из худшего.
4. 4Оценить, что именно можно было прочитать этим ключом. Если права были урезаны — список короткий и конкретный. Если ключ был общий с полными правами — список равен всему содержимому системы, и это ровно та разница, ради которой права урезают.
5. 5Проверить, не проходили ли через ключ персональные данные. Если да, включается отдельный контур: фиксация факта, оценка объёма и уведомление в Роскомнадзор в течение 24 часов, с последующим уведомлением о результатах разбирательства.
6. 6Записать, откуда взялась утечка, и закрыть этот путь. Иначе через квартал вы повторите весь список заново — только уже с другим ключом.

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

• Обращения с адресов, которых нет в вашем списке. Самый прямой признак. Ваша интеграция ходит с одного-двух известных адресов, и всё остальное подлежит объяснению.
• Обращения в нерабочее время. Если сценарий работает по расписанию с 8 до 20, обращение в 03:40 не бывает случайным. Исключение — ночные регламентные выгрузки, о которых вы знаете.
• Вызовы методов, которых ваша интеграция не делает. Интеграция читает заказы за сутки; в журнале видна выгрузка всего справочника контрагентов целиком. Это не сбой, это чужой интерес.
• Всплеск числа обращений. Обычный день — 900 обращений, в среду было 40 000. Массовая выгрузка выглядит именно так, и она же обычно упирается в лимит, что становится первым заметным симптомом.

Подготовка стоит 27 000 ₽ и окупается одной предотвращённой утечкой почти полностью, а второй — с запасом. Но считать её надо не по этой арифметике: основная цена утечки не в часах разбора, а в том, что именно утекло. Минимальный штраф за утечку персональных данных от тысячи субъектов по КоАП в редакции с 30 мая 2025 года составляет 3 000 000 ₽, и на этом фоне разница между 8 100 и 37 200 ₽ перестаёт быть главной цифрой в разговоре.

Подрядчик, 152-ФЗ и шесть вопросов

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

• Перечень данных и действий. Не «данные клиентов», а конкретно: телефон, имя, адрес доставки; действия — чтение и передача, без хранения. Чем уже перечень, тем меньше поверхность ответственности у обеих сторон.
• Где физически находятся серверы. Локализация баз персональных данных в России — базовое требование, а не пожелание. У облачной площадки это проверяется по документам, а не по фразе на сайте.
• Срок хранения журналов у подрядчика и у площадки — числом. Именно журналы прогонов чаще всего оказываются теневой копией вашей клиентской базы: тело запроса сохраняется целиком, и через полгода их накапливается больше, чем в самой CRM.
• Обязанность уведомить вас об инциденте — с указанием времени. У вас есть 24 часа на первое уведомление в Роскомнадзор, и это время начинает идти не с того момента, когда вам сообщили. Если подрядчик обязан уведомить «в разумный срок», вы этот срок не выдержите.
• Порядок возврата и уничтожения доступов при завершении работ. Отзыв ключей в день окончания, письменное подтверждение удаления копий, отсутствие остаточных доступов в системах.

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

Когда этим можно не заниматься

Разделение ключей, урезание прав и квартальный регламент стоят 27 000 ₽ и внимания. Три случая, в которых это избыточно, и один, в котором нельзя откладывать ни на день.

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

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