Безопасность ключей для мерчантов, принимающих крипту

Что вы на самом деле защищаете?

Зависит от модели кастоди, и два случая совсем не похожи.

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

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

Учётные данные, которые имеют значение

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

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

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

Какие контроли стоит иметь?

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

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

Оповещения об исходящей активности, доставляемые туда, где их читает человек, а не в лог, который никто не открывает.

Особенности некастодиальной модели

Если вы держите настоящие ключи, режим отказа меняется с кражи на потерю, а потеря случается чаще. Кошелёк, фраза восстановления которого существует в одном месте и известна одному человеку, — риск непрерывности бизнеса, а не поза безопасности.

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

Минимальный набор контролей

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

Ничего экзотического, и не каждый провайдер предлагает всё. Какие части доступны — честный вопрос для оценки, а не для времени после неё.

Ротация, и почему её пропускают

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

Привяжите ротацию к тому, что и так происходит: уход сотрудников, ежегодный аудит, продление договора с провайдером. График, за который никто не отвечает, — график, которому никто не следует.

Для некастодиальных конфигураций отдельно

Фраза восстановления — артефакт непрерывности бизнеса, а не секрет одного человека. Восстановить должны уметь несколько человек, а храниться она должна там, где переживёт потерю офиса и уход сотрудника.

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

Что проверить при настройке

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

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

Куда дальше

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

Что делать после инцидента

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

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

Ревизия доступа как привычка

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

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

Что стоит автоматизировать

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

Замечание об общих учётных данных

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

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

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