Мы работаем над новым сервисом - этот сервис потенциально будет вызываться непосредственно из приложений на пользовательских устройствах. Эти приложения будут разрабатываться и поддерживаться несколькими группами разработчиков по всей организации, все в зависимости от данных, которые мы предоставляем.
Мы стремимся определить, какие приложения отправляют какие запросы, чтобы мы могли определить шаблоны использования и ответственных разработчиков. (Во избежание сомнений, аутентификация пользователя обрабатывается отдельно.)
Наше решение состоит в том, чтобы требовать ключи API, по одному на приложение - тогда у нас есть контактная информация для команды разработчиков.
Мы не хотим, чтобы получение ключей API было источником трений, но мы обеспокоены тем, что разработчики будут делиться ими с коллегами из других команд, а это означает, что мы больше не можем идентифицировать трафик только для одного приложения.
Как мы можем стимулировать разработчиков не делиться ключами API внутри компании?
Ответы:
Чтобы поделиться этими ключами между командами, команды должны поговорить друг с другом, согласиться поделиться, а затем поделиться ими. Это требует времени. Так что, если команда может запросить ключи API у вас быстрее и проще, нет никаких стимулов для обмена.
И самый простой способ для них запросить эти ключи - это упредить их. Предполагая, что вы знаете все другие команды, которым понадобятся ключи API, создайте их и поделитесь ими, прежде чем предоставлять им доступ к сервису.
Есть еще один стимул, который вы можете предложить: поддержка отладки. Эти команды будут нуждаться в вашей помощи, когда что-то не работает должным образом, когда они интегрируют свою работу с вашим сервисом. Эти API-ключи позволяют вам отслеживать их конкретные запросы и, таким образом, помогать в отладке того, что идет не так. Так что продавайте это как причину для ключей, а не « определяйте шаблоны использования и ответственных разработчиков », что звучит так, будто вы шпионите за их действиями.
источник
Хорошие ответы уже, я просто подумал о другом подходе, который может или не может работать для вас.
Вместо того, чтобы выдавать ключи, которые нужно включить, вы можете потребовать, чтобы заголовок запросов включал в себя имя приложения переднего плана, которое должно быть создано и отформатировано разработчиком приложения переднего плана, как это делают веб-браузеры. Таким образом, внешние интерфейсы могут все еще претендовать на роль другого приложения, но это не принесет никакой пользы, так что это кажется маловероятным. Просто позвольте внешнему интерфейсу идентифицировать себя и принять любую непустую строку.
источник
Короче:
Первое: содействие и выгоды; При необходимости: трения и полиция.
Еще несколько слов
Упрощение : во-первых, упростите для команды получение нового ключа API. Например, добавьте напоминание в корпоративные процедуры запуска новых проектов и предложите простой в использовании сервис для запроса новых ключей, не запрашивая обоснования.
Преимущества : сделайте использование собственного ключа API полезным для команды или владельца продукта. Например, предложите некоторые отзывы об использовании приложения на основе этого ключа.
Трение : в зависимости от ключевой функции вы можете создать трение, например, если ключ связан с определенным приложением доменом (то есть повторное использование ключей не обязательно даст доступ ко всем желаемым службам).
Охрана общественного порядка: наконец, вам может потребоваться предусмотреть некоторые меры полицейского характера. Например, вы можете отслеживать использование функций API по ключу API и по истечении заданного времени установить базовый уровень, запрос об использовании частей API, который не ожидается с учетом базового уровня. Или, если это нереально, просто включите в корпоративные контрольные списки проверки проекта подтверждение того, что использовался действительный ключ.
Примечание . Возможно, вам необходимо четко определиться с политикой ключей API. Требуется ли для новой основной версии собственный ключ API? Что с вилкой, или если приложение разделено? что, если другая команда отвечает и т.д ...
источник
Как правило, самый простой способ заставить разработчиков «делать правильные вещи» - это облегчить им задачу.
Для этого я бы предложил создать веб-страницу / сайт выдачи ключей API. В простейшей форме это может быть просто логин (в идеале связанный с вашей корпоративной AD / LDAP) и страница, которая просто запрашивает имя приложения и выдает ключ.
В конце дня вы всегда можете отозвать ключи позже, поэтому все, что вам действительно нужно, чтобы сайт сделал, это запишите, кто (имя пользователя) запросил ключ и что (имя приложения) они хотят с ним сделать - вместе с любой информацией, необходимой для отозвать ключ позже.
Вы могли бы сделать что-то подобное с системой тикетов, но в конце концов мне очень легко скопировать и вставить ключ из одного приложения в другое, поэтому очень просто запросить новый ключ, чтобы избежать плохого поведение.
источник
Быть инициативным.
Определите потенциальных разработчиков и предоставьте им уникальные ключи API в безопасном канале, заблаговременно. Обеспечить простой способ запроса новых ключей API. Обеспечить простой способ для новых людей, запрашивающих новые ключи API. Когда в команду вступают новые стажеры или сотрудники, дайте им билет JIRA или аналогичный «Запрос ключа API», выполнив действия, описанные в описании.
Отслеживайте, какие ключи API были использованы, а какие нет. Если Боб отправил заявки в проект, но не использовал свои ключи API, он, вероятно, позаимствовал чужие.
Иметь поддержку менеджмента. Не будь любопытной Нэнси, придерживаясь каких-либо правил придумывания, которые не имеют значения. Буквально убедить руководство в том, что это важно, и тогда они - те, кто убедит группу в том, что это важно. Не работайте, чтобы убедить всех.
И самое досадное и предрасположенное к тирании предложение: будьте осторожны и злоупотребляйте им в тот же день. Тот же час самый лучший. Не говорите «Bad Naughty Developer», говорите «Вот правильные шаги». Если они делают это несколько раз, отключите неправильно используемый ключ. Это доставляет неудобства как Участнику, так и Одному Заемщику, и этот участник скажет «Нет, делай это правильно» в будущем. Избегайте отключения ключей, которые есть в живых проектах.
источник
Вы также должны реализовать ограничение скорости . Это само по себе может препятствовать обмену ключами. Это в некоторой степени защищает вашу систему от злоупотреблений. (И совершенно злонамеренные.) И это гарантирует, что вы будете в некоторой степени информированы до значительного увеличения исправного трафика. (Надеюсь, что у вас будет время для наращивания потенциала!)
И с ограничением скорости, когда приложение требует более высокого предела, оно открывает диалог с POC, зарегистрированным для ключа. Вы получаете возможность спросить, передаются ли ключи, объясните, почему это вредно и т. Д., И вы можете предложить дополнительные ключи, когда это уместно, вместо запрошенных изменений ограничения скорости. И т.п.
источник
Один из способов сделать это, особенно если команды используют общую систему сборки (или, по крайней мере, достаточно общую), - это настроить внутренний сервер, который создает и выдает ключи API (учитывая несколько основных сведений о продукте, использующем его). ). Затем используйте сценарий, который получает новый ключ API с сервера для каждой сборки или для каждого обновления версии. Позвольте разработчикам запустить скрипт, чтобы получить другой ключ для своих локальных сборок. (Где это возможно, автоматизируйте это как часть сборки, чтобы им даже не нужно было об этом думать.)
Это позволит вам определить, было ли это что-то в производстве, QA или dev, и с какой версии / сборки начались проблемы.
источник
Первое и лучшее, что вы можете сделать, это отформатировать ключи так, чтобы они включали имя приложения в легко читаемой форме, и не работали, если вы его изменили.
Если очевидно, что команды используют неправильный ключ, они будут стараться не делать этого.
Затем периодически истекают ключи. Вы должны сделать это в любом случае , и когда срок действия ключа приближается к сроку действия, вы можете отправить новый команде, которой он принадлежит. Команда, которая использует ключ, будет мотивирована, чтобы убедиться, что она является командой, которая владеет им, так что они получат новый, когда он истечет.
источник