Есть категория ошибок, цена которых измеряется не переделкой, а скандалом. Когда через интеграцию утекают данные клиентов — телефоны, адреса, история заказов — это уже не баг, который тихо правят ночью. Это звонки от встревоженных клиентов, репутационный удар и разговор с регулятором про 152-ФЗ. И самое обидное: почти все такие утечки происходят из-за пары банальных промахов, которые ничего не стоило не допустить.
Хорошая новость в том, что базовая безопасность интеграции — это не высшая математика и не дорогая надстройка. Это несколько простых принципов, которые грамотный исполнитель соблюдает по умолчанию, а заказчик может проверить парой вопросов, даже не разбираясь в технике. Разберём, где нельзя хранить ключи, зачем ограничивать права, что требует 152-ФЗ простыми словами и как понять, что вашу интеграцию сделали безопасно, а не «лишь бы работало».
Эта статья — часть раздела про интеграции и API. Смежные темы: приём оплаты, как выбрать исполнителя, стоимость интеграции.
Что вы узнаете из статьи
- Где категорически нельзя хранить ключи и токены
- Почему принцип минимальных прав спасает при утечке
- Что требует 152-ФЗ при обмене персональными данными
- Как проверить безопасность интеграции, не зная кода
- Что делать, если ключ всё-таки утёк
Ключи и токены: где хранить нельзя
Ключ доступа к API — это, по сути, пароль ко всему, что отдаёт внешний сервис: к вашим заказам, платежам, данным клиентов. И самая частая утечка в мире интеграций происходит из-за того, что этот пароль кладут не туда.
Главный антипример — ключ, зашитый прямо в код. Разработчик вписал его в исходник «чтобы работало», код отправился в репозиторий, а репозиторий оказался открытым — и ключ теперь доступен всем, кто умеет искать. Так утекают доступы у компаний любого размера, и это до сих пор причина номер один. Второй антипример — хранить ключ на стороне браузера, в коде, который грузится пользователю: всё, что попало в браузер, может прочитать кто угодно, открыв инструменты разработчика.
Как правильно: ключи лежат в защищённом хранилище секретов или в серверных переменных окружения, недоступных снаружи. Оперирует ими только сервер — браузер пользователя ключ не видит вообще. Это особенно критично при приёме оплаты, где ключ — это доступ к деньгам. Проверить элементарно: спросите исполнителя, где хранятся ключи. Ответ «в защищённом хранилище / в серверных переменных» — норма. Ответ «в коде» или заминка — повод насторожиться.
Минимальные права: страховка, которая ничего не стоит
Второй принцип безопасности недооценивают, потому что он невидим, пока всё хорошо. Называется он минимальными правами, и суть проста: каждый ключ должен уметь ровно то, что нужно для его задачи, и ни на грамм больше.
Представьте, что вы даёте курьеру ключ от дома. Можно дать ключ от всех дверей и сейфа, а можно — только от прихожей, куда он ставит посылку. Если курьер потеряет ключ, в первом случае вор получит всё, во втором — пустую прихожую. С API так же. Если интеграции нужно лишь читать остатки, ключ должен уметь только читать остатки — не удалять товары, не менять цены, не трогать заказы. Тогда даже если ключ украдут, ущерб ограничен.
Это страховка, которая не стоит ничего, но кардинально меняет последствия инцидента. Всемогущий ключ превращает одну утечку в катастрофу; ограниченный — в неприятность. Грамотный исполнитель раздаёт права по этому принципу автоматически. Если же все ключи в проекте всемогущие «чтобы не возиться» — это техническая лень, которая однажды дорого обойдётся. Вопрос исполнителю простой: «права у ключей ограничены под задачу или они полные?»
152-ФЗ: что нужно знать про персональные данные
Как только через интеграцию начинают ходить персональные данные — имена, телефоны, адреса, тем более паспорта, — в игру вступает 152-ФЗ, и его лучше учесть заранее, чем объясняться потом.
Без юридических дебрей, по сути закон требует трёх вещей. Первое: персональные данные надо защищать при передаче — гонять их по шифрованному соединению, а не открытым текстом, и ограничивать к ним доступ. Второе: на обработку этих данных нужно правовое основание — согласие клиента или иное законное основание. Третье, про что часто забывают при выборе внешних сервисов: первичная обработка персональных данных россиян по закону должна вестись на серверах в России. Это значит, что место хранения данных и расположение используемых сервисов нужно проверять до интеграции, а не выяснять, что данные уехали за рубеж, во время проверки.
Для заказчика практический вывод такой: если в обмене участвуют персональные данные, проговорите это с исполнителем отдельно. Спросите, по какому соединению ходят данные и где они хранятся. Это не паранойя — это разница между спокойной работой и риском штрафа. Подобные требования к безопасности стоит заложить в смету сразу: защищённая интеграция чуть дороже дырявой, но несравнимо дешевле последствий утечки.
Как проверить безопасность, не зная кода
Заказчику кажется, что оценить безопасность может только специалист. На деле достаточно задать четыре вопроса и послушать, насколько уверенно и конкретно на них отвечают.
Где хранятся ключи и токены? (Ответ: в защищённом хранилище или серверных переменных, не в коде.) Кто имеет к ним доступ после сдачи проекта? (Ответ: круг лиц ограничен, и вы знаете, кто это.) По какому соединению передаются данные? (Ответ: по шифрованному.) Можно ли быстро отозвать доступ, если ключ утечёт? (Ответ: да, за минуты.) Спокойные, конкретные ответы — признак того, что безопасность закладывали сразу. Отговорки «обычно и так нормально», «потом настроим», ключи в коде — признак, что не закладывали вовсе. Этот разговор — часть того, как вообще проверить исполнителя перед сделкой.
Если ключ всё-таки утёк
Даже при аккуратной работе утечка возможна — кто-то по ошибке выложил ключ, увели ноутбук, случился человеческий фактор. Поэтому важно не только защищаться, но и уметь быстро реагировать.
План действий простой. Немедленно отозвать скомпрометированный ключ и выпустить новый — и здесь окупается то, что хорошая интеграция позволяет сделать это за минуты, а не требует переписывать половину кода. Проверить по логам, не было ли подозрительной активности с момента утечки. Если утекли персональные данные, оценить обязанность уведомить регулятора в установленные сроки. Всё это возможно ровно тогда, когда интеграцию изначально сделали с расчётом на такой сценарий: ключи отзываемы, логи ведутся. Если же ничего этого нет, утечка превращается из управляемого инцидента в катастрофу с неизвестным масштабом — а это уже вопрос к тому, как интеграцию проектировали.
Как платформа помогает с безопасной интеграцией
На Где.Эксперт специалистов выбирают по реальным отзывам и истории заказов. Видно, кто работал с чувствительными данными и платежами, как заказчики оценили аккуратность, не было ли историй с утечками. В вопросах безопасности репутация исполнителя значит особенно много, и отзывы прошлых клиентов её показывают.
Можно начать с обсуждения и сразу задать вопросы про хранение ключей, шифрование и отзыв доступов — по ответам видно, кто закладывает безопасность с самого начала. Оплата идёт по факту выполнения, а отзывы работают страховкой от исполнителя, который экономит на защите и оставляет ключи в коде.
Часто задаваемые вопросы
Где нельзя хранить ключи и токены?
В коде, который попадает в репозиторий, в коде на стороне браузера и в открытых файлах на сервере. Самая частая утечка — ключ в коде, выложенном в открытый репозиторий. Ключи хранят в защищённом хранилище или серверных переменных.
Что требует 152-ФЗ при обмене?
Защищать персональные данные при передаче (шифрование), ограничивать доступ, иметь основание на обработку. Отдельно: первичная обработка данных россиян должна вестись на серверах в России — это учитывают при выборе сервисов.
Зачем ограничивать права доступа?
Чтобы при утечке ключа ущерб был ограничен. Если ключ умеет только нужное, кража не даст удалить данные или вывести деньги. Минимальные права ничего не стоят, но спасают при инциденте.
Как проверить безопасность без знания кода?
Спросите, где хранятся ключи, кто к ним имеет доступ, по какому соединению ходят данные, можно ли быстро отозвать доступ. Конкретные спокойные ответы — норма, отговорки и ключи в коде — тревожный сигнал.
Что делать при утечке ключа?
Немедленно отозвать ключ и выпустить новый, проверить логи на подозрительную активность, при утечке персональных данных оценить обязанность уведомить регулятора. Поэтому отзыв ключей и логи закладывают заранее.
Заключение
Безопасность интеграции пугает сложностью только на словах. На деле почти все утечки случаются из-за пары банальностей: ключ положили в код, который утёк, и раздали всем ключам полные права. Избежать этого ничего не стоит — нужно лишь хранить ключи в защищённом месте и давать каждому ровно те права, что нужны.
Добавьте к этому шифрование данных, внимание к 152-ФЗ там, где ходят персональные данные, и возможность быстро отозвать доступ при утечке — и интеграция из источника риска превращается в надёжный механизм. Проверить всё это заказчик может четырьмя вопросами, не зная ни строчки кода. А выбрать того, кто закладывает безопасность сразу, а не «потом», проще там, где видно отзывы и историю аккуратной работы с чувствительными данными.
Найдите специалиста на Где.Эксперт — выбирайте по реальным отзывам, спрашивайте про безопасность до старта и платите по факту выполнения.