Как я могу препятствовать совместному использованию внутренних ключей API внутри компании?

37

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

Мы стремимся определить, какие приложения отправляют какие запросы, чтобы мы могли определить шаблоны использования и ответственных разработчиков. (Во избежание сомнений, аутентификация пользователя обрабатывается отдельно.)

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

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

Как мы можем стимулировать разработчиков не делиться ключами API внутри компании?

api enterprise-development

— Oli
источник

5

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

— Джакомо Альзетта

3

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

— Султан

Рассматривали ли вы необходимость регистрации при первом запуске приложения? На нем может отображаться заставка с запросом контактных данных пользователя (или любой другой информации, которая вам нужна), а затем выдача ключа API на месте.

— Джон Ву

«Как мы можем стимулировать разработчиков не делиться ключами API внутри компании?» Проще говоря, свяжите каждый ключ с MAC-адресом сетевой карты на компьютерах, на которых они работают. Сетевые протоколы предотвращают использование одних и тех же MAC-адресов в одной и той же сети, поэтому люди не могут использовать одни и те же ключи снова и снова. Я бы сделал это в ответ, но у меня нет представителя для этого в настоящее время.

— Блерг

Любопытно, что в настоящий момент я не вижу слова «вращение» (как в случае вращения ключа - срок действия / вращение учетных данных) нигде на этой странице. Когда кто-то получает ключ, имеет ли он конечное время жизни, после чего его нужно повернуть из использования и заменить новым? Если нет, то почему?

— Майкл - sqlbot

76

Чтобы поделиться этими ключами между командами, команды должны поговорить друг с другом, согласиться поделиться, а затем поделиться ими. Это требует времени. Так что, если команда может запросить ключи API у вас быстрее и проще, нет никаких стимулов для обмена.

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

Есть еще один стимул, который вы можете предложить: поддержка отладки. Эти команды будут нуждаться в вашей помощи, когда что-то не работает должным образом, когда они интегрируют свою работу с вашим сервисом. Эти API-ключи позволяют вам отслеживать их конкретные запросы и, таким образом, помогать в отладке того, что идет не так. Так что продавайте это как причину для ключей, а не « определяйте шаблоны использования и ответственных разработчиков », что звучит так, будто вы шпионите за их действиями.

— Дэвид Арно
источник

2

Re: совместное использование, в идеальном мире вы правы - но вы предполагаете, что они имеют совершенную информацию (хотя я могу помочь, направив их в документы из схемы, корень конечной точки и любые ошибки), а также в совместное управление и не реальность, когда все, что они могут иметь, - это конечная точка и некоторый код, скопированный из другой команды, который был передан старшим менеджером.

— Оли

3

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

— Оли

1

@Ewan, если вы просто отключите доступ к данному ключу, все пользователи будут работать с вами - не нужно их преследовать. И тогда вы сможете дать им уникальные ключи :)

— Алексей Левенков

15

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

— Candied_Orange

1

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

— Робин Беннетт

20

Хорошие ответы уже, я просто подумал о другом подходе, который может или не может работать для вас.

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

— Мартин Маат
источник

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

— Оли

1

@Oli Если владелец приложения изменился, и (новый) разработчик посчитал бы целесообразным обновить удостоверение приложения (которое у него действительно есть, потому что кто-то другой поддерживает его), в чем будет проблема? Вы можете различать до смены владельца и после смены владельца, просто рассматривая их как два разных приложения. Я не ожидал бы, что новый владелец заметит имя в заголовке в ближайшее время.

— Мартин Маат

3

Это то, что я делаю. иметь у клиента параметр конструкции, который является именем приложения, и / или использовать отражение, чтобы извлекать другие вещи, такие как машина, на которой он работает, его версия и т. д. Главное, чтобы вы могли сообщать, когда люди НЕ следуют вашему API политика

— Ewan

1

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

— Калеб

@Caleb Если бы все было так централизовано, у ОП, вероятно, не было бы этой проблемы. Из того, что я понимаю, разработчики приложений переднего плана являются анонимными для OP с частными способами разработки программного обеспечения.

— Мартин Маат

16

Короче:

Первое: содействие и выгоды; При необходимости: трения и полиция.

Еще несколько слов

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

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

Трение : в зависимости от ключевой функции вы можете создать трение, например, если ключ связан с определенным приложением доменом (то есть повторное использование ключей не обязательно даст доступ ко всем желаемым службам).

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

Примечание . Возможно, вам необходимо четко определиться с политикой ключей API. Требуется ли для новой основной версии собственный ключ API? Что с вилкой, или если приложение разделено? что, если другая команда отвечает и т.д ...

— Christophe
источник

6

Как правило, самый простой способ заставить разработчиков «делать правильные вещи» - это облегчить им задачу.

Для этого я бы предложил создать веб-страницу / сайт выдачи ключей API. В простейшей форме это может быть просто логин (в идеале связанный с вашей корпоративной AD / LDAP) и страница, которая просто запрашивает имя приложения и выдает ключ.

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

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

— DavidT
источник

1

Быть инициативным.

Определите потенциальных разработчиков и предоставьте им уникальные ключи API в безопасном канале, заблаговременно. Обеспечить простой способ запроса новых ключей API. Обеспечить простой способ для новых людей, запрашивающих новые ключи API. Когда в команду вступают новые стажеры или сотрудники, дайте им билет JIRA или аналогичный «Запрос ключа API», выполнив действия, описанные в описании.

Отслеживайте, какие ключи API были использованы, а какие нет. Если Боб отправил заявки в проект, но не использовал свои ключи API, он, вероятно, позаимствовал чужие.

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

И самое досадное и предрасположенное к тирании предложение: будьте осторожны и злоупотребляйте им в тот же день. Тот же час самый лучший. Не говорите «Bad Naughty Developer», говорите «Вот правильные шаги». Если они делают это несколько раз, отключите неправильно используемый ключ. Это доставляет неудобства как Участнику, так и Одному Заемщику, и этот участник скажет «Нет, делай это правильно» в будущем. Избегайте отключения ключей, которые есть в живых проектах.

— Кристофер Заложник
источник

1

Как мы можем стимулировать разработчиков не делиться ключами API внутри компании?

Генерация ключей в результате регистрации приложения самообслуживания .
Требуется точка контакта, прежде чем ключи станут активными.
И попросите их не делиться. (Создать условия обслуживания и / или сказать им , почему это лучше для них , чтобы не разделить.)

Вы также должны реализовать ограничение скорости . Это само по себе может препятствовать обмену ключами. Это в некоторой степени защищает вашу систему от злоупотреблений. (И совершенно злонамеренные.) И это гарантирует, что вы будете в некоторой степени информированы до значительного увеличения исправного трафика. (Надеюсь, что у вас будет время для наращивания потенциала!)

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

— svidgen
источник

0

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

Это позволит вам определить, было ли это что-то в производстве, QA или dev, и с какой версии / сборки начались проблемы.

— Miral
источник

0

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

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

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

— Мэтт Тиммерманс
источник

1

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

— Давидбак