Comment puis-je décourager le partage de clés API internes au sein d'une entreprise?

37

Nous travaillons sur un nouveau service - ce service sera potentiellement appelé directement à partir d'applications situées sur les machines des utilisateurs. Ces applications seront développées et prises en charge par plusieurs équipes de développement de toute l'organisation, en fonction des données fournies.

Nous souhaitons identifier quelles applications envoient quelles demandes afin de pouvoir identifier les modèles d'utilisation et les développeurs responsables. (Pour éviter tout doute, l'authentification de l'utilisateur est traitée séparément.)

Notre solution consiste à exiger des clés API, une par application. Nous avons ensuite les coordonnées de l'équipe de développement.

Nous ne voulons pas que les clés d'API soient une source de friction, mais nous craignons que les développeurs les partagent avec des collègues d'autres équipes, ce qui signifie que nous ne pouvons plus identifier le trafic pour une seule application.

Comment inciter les développeurs à ne pas partager les clés d'API en interne?

Oli
la source
5
Comment ces équipes vont-elles accéder à l'API? Via le réseau interne? Généralement, différentes équipes sont réparties dans différents sous-réseaux, ce qui vous permet de forcer le réseau à utiliser une certaine clé d'API ... Quoi qu'il en soit, la solution sociale consiste à leur dire "il est important que vous ne partagiez pas cette clé d'API non pour des raisons de sécurité, mais besoin des métriques de différents utilisateurs pour l’améliorer. Si quelqu'un vous le demande, il vous suffit de leur demander de nous le demander et nous leur fournirons volontiers et efficacement une clé API ".
Giacomo Alzetta
3
Si vous ne souhaitez pas que les personnes partagent les clés avec leurs collègues, simplifiez l'inclusion d'un fichier de configuration ignoré par le système de gestion des versions (afin que la clé ne soit jamais validée) et facilitez également la création de nouvelles clés. Personne ne se souciera de partager une clé secrète si un autre développeur peut facilement créer une nouvelle clé par lui-même. Le problème du partage des clés personnelles est généralement un problème dû au fait que l'obtention de nouvelles clés prend du temps.
Sulthan
Avez-vous envisagé d’exiger une inscription dès le démarrage de l’application? Il pourrait afficher un écran de démarrage demandant les coordonnées de l'utilisateur (ou toute autre information dont vous avez besoin), puis émettre la clé d'API sur-le-champ.
John Wu
"Comment pouvons-nous inciter les développeurs à ne pas partager les clés d'API en interne?" En termes simples, reliez chaque clé à l’adresse MAC de la ou des cartes réseau des ordinateurs qui les exécutent. Les protocoles de réseau empêchent l'utilisation des mêmes adresses MAC sur le même réseau, ce qui empêche les utilisateurs d'utiliser les mêmes clés à maintes reprises. J'en aurais fait une réponse, mais je n'ai pas le représentant pour le moment.
Blerg
Curieusement, je ne vois pas le mot "rotation" (comme dans la rotation de clé - expiration / rotation des identifiants) nulle part sur cette page pour le moment. Une fois que quelqu'un a obtenu une clé, a-t-elle une durée de vie finie après laquelle elle doit être désactivée et remplacée par une nouvelle? Si non pourquoi pas
Michael - sqlbot le

Réponses:

76

Afin de partager ces clés entre les équipes, celles-ci doivent se parler, accepter de les partager, puis les partager. Cela prend du temps. Par conséquent, si une équipe peut vous demander des clés d'API plus rapidement et plus facilement, rien ne vous incite à partager.

Et le moyen le plus simple pour eux de demander ces clés est de les préempter. En supposant que vous connaissiez toutes les autres équipes qui auront besoin de clés API, créez-les et partagez-les avant de mettre le service à leur disposition.

Il existe une autre incitation que vous pouvez offrir: le support de débogage. Ces équipes voudront votre aide lorsque les choses ne fonctionneront pas correctement lorsqu'elles intégreront leur travail à votre service. Ces clés d'API vous permettent de suivre leurs demandes spécifiques et ainsi d'aider au débogage de ce qui ne va pas. Alors vendez cela comme la raison des clés, plutôt que "d' identifier les modèles d'utilisation et les développeurs responsables ", ce qui ressemble à de l'espionnage de leurs activités.

David Arno
la source
2
Re: partage, dans un monde idéal, vous avez raison - mais vous présupposez qu'ils disposent d'informations parfaites (bien que je puisse les aider en les dirigeant vers des documents du schéma, de la racine du point de terminaison et d'éventuelles erreurs) et en gestion coopérative, et la réalité où ils ne disposent que du point final et de certains codes copiés d’une autre équipe qui leur ont été transmis par un cadre supérieur.
Oli
3
Re: Préemptant, vous avez absolument raison, nous devons créer et envoyer de manière agressive les clés aux parties intéressées. Ce que je n'ai pas mentionné, c'est que certaines de ces applications utilisent un framework / interface commun, et nous pourrions peut-être injecter ou appliquer de manière semi-automatique des clés uniques sur cette couche, mais cela ne s'applique pas à toutes les applications.
Oli
1
@Ewan si vous désactivez simplement l'accès à une clé donnée, tous les utilisateurs s'exécutent sur vous - inutile de les pourchasser. Et puis, vous pouvez leur donner des clés uniques :)
Alexei Levenkov
15
La préemption doit prendre la forme suivante: accéder à l'API sans la clé produit un message d'erreur avec un lien vers la page où vous postulez pour la clé. Ne vous attendez pas à ce que quelqu'un lise la documentation. Les incitations ne fonctionnent pas quand personne ne les connaît.
candied_orange
1
Si des messages d'erreur ou des journaux de débogage étaient automatiquement envoyés par courrier électronique à une adresse liée à la clé, toute personne souhaitant utiliser les données serait incitée à utiliser sa propre clé. Toute personne utilisant une clé partagée aurait également intérêt à la retrouver. et les amener à arrêter.
Robin Bennett le
20

Bonnes réponses déjà, je viens de penser à une approche différente qui peut ou peut ne pas fonctionner pour vous.

Plutôt que d'émettre des clés à inclure, vous pouvez demander à l'en-tête des demandes d'inclure le nom de l'application frontale, à créer et à formater par le développeur de l'application frontale, comme le font les navigateurs Web. De cette façon, les serveurs frontaux pourraient toujours prétendre être une application différente, mais cela ne présenterait aucun avantage, ce qui semble peu probable. Laissez simplement le front-end s'identifier et accepter toute chaîne non vide.

Martin Maat
la source
Cela rendrait la vie un peu plus difficile si la propriété d'une application change - par exemple, nous pourrions simplement mettre à jour les détails de la clé d'API stockée de notre côté, mais si nous acceptons le texte de forme libre nécessitant que l'application modifie le code.
Oli
1
@Oli Si la propriété d'une application change et que le (nouveau) développeur juge approprié de mettre à jour l'identité de l'application (ce qui est le cas car quelqu'un d'autre la maintient), quel serait le problème? Vous pouvez faire la différence entre un changement pré-propriété et un changement post-propriété, il suffit de les considérer comme deux applications différentes. Je ne m'attendrais pas à ce qu'un nouveau propriétaire remarque le nom dans l'en-tête de si tôt.
Martin Maat
3
C'est ce que je fais. demandez au client d'avoir un paramètre de construction qui correspond au nom de l'application et / ou utilisez la réflexion pour extraire d'autres éléments tels que la machine sur laquelle elle tourne, sa version, etc. L'essentiel est de vous permettre de signaler lorsque des personnes NE suivent PAS votre API politique
Ewan
1
Si l'organisation utilise une approche commune du contrôle de version, par exemple, tout le monde conserve son code sur le serveur GitHub de l'organisation, demande à chaque application d'envoyer une URL à son référentiel et au hachage de validation à partir duquel elle a été créée. Le hachage de validation peut être inclus dans le code dans le cadre du processus de construction, évitant ainsi aux développeurs de mettre à jour quoi que ce soit. Avoir l'URL du référentiel vous permet de savoir qui est le propriétaire, et obtenir des validations spécifiques vous permettrait de remarquer les différences de comportement entre les versions.
Caleb
@Caleb Si les choses étaient centralisées de la sorte, le PO n'aurait probablement pas ce problème. D'après ce que je comprends, les développeurs d'applications front-end sont un lot anonyme pour l'OP, avec des méthodes privées de développement de logiciels.
Martin Maat
16

En bref:

Premièrement: la facilitation et les avantages; Si nécessaire: frictions et police.

Quelques mots de plus

Facilitation : Tout d’abord, aidez une équipe à obtenir une nouvelle clé d’API. Par exemple, ajoutez un rappel dans les procédures d'entreprise pour le lancement de nouveaux projets et offrez un service facile à utiliser pour demander de nouvelles clés, sans demander de justification.

Avantages : Faire de l'utilisation d'une propre clé API un avantage pour l'équipe ou le propriétaire du produit. Par exemple, proposez des commentaires sur l'utilisation de l'application en fonction de cette clé.

Friction : en fonction de la fonctionnalité de clé, vous pouvez créer une friction, par exemple si la clé est liée à un domaine défini par l'application (c'est-à-dire que la réutilisation de clés ne donnerait pas nécessairement accès à tous les services souhaités).

Maintien de l'ordre : Enfin, vous devrez peut-être prévoir certaines mesures de maintien de l'ordre. Par exemple, vous pouvez surveiller l'utilisation des fonctions d'api à l'aide de la touche api et, après un certain temps, établir une base de référence, une requête sur l'utilisation des parties de l'api qui n'est pas attendue au vu de la base. Ou, si cela n’est pas réaliste, incluez simplement dans les listes de contrôle de vérification de projet d’entreprise la vérification de l’utilisation d’une clé valide.

Remarque : vous devrez peut-être être très clair sur votre stratégie de clé API: une nouvelle version majeure aurait-elle besoin de sa propre clé API? Qu'est-ce avec une fourchette, ou si une application est divisée? Et si une autre équipe est en charge, etc ...

Christophe
la source
6

Généralement, le moyen le plus simple de faire en sorte que les développeurs «agissent comme il convient» est de leur faciliter la tâche.

À cette fin, je suggérerais de créer une page / un site Web émetteur de clés d’API. Dans sa forme la plus simple, il pourrait ne s'agir que d'un identifiant (idéalement lié à votre AD / LDAP d'entreprise) et de la page qui demande simplement le nom de l'application et délivre la clé.

À la fin de la journée, vous pouvez toujours révoquer les clés ultérieurement. Par conséquent, tout ce que vous avez besoin de faire sur le site est de noter qui (nom d'utilisateur) a demandé la clé et ce que (nom de l'application) il veut en faire - avec toutes les informations nécessaires révoquer la clé plus tard.

Vous pouvez faire quelque chose de similaire avec un système de billetterie, mais à la fin de la journée, il est très facile pour moi de copier et coller une clé d'une application à une autre. Il doit donc être très facile de demander une nouvelle clé pour éviter les erreurs. comportement.

DavidT
la source
1

Etre pro-actif.

Identifiez à l'avance les développeurs potentiels et attribuez-leur des clés d'API uniques dans un canal sécurisé. Fournissez un moyen simple de demander de nouvelles clés d'API. Fournissez un moyen facile aux nouvelles personnes de demander de nouvelles clés d'API. Lorsque de nouveaux stagiaires ou de nouveaux employés rejoignent l’équipe, donnez-leur un ticket JIRA ou une requête similaire "Demander une clé API" avec les étapes décrites dans la description.

Gardez une trace des clés d'API utilisées et de celles qui ne l'ont pas encore été. Si Bob a soumis des tickets dans le projet mais n'a pas utilisé ses clés API, il a probablement emprunté quelqu'un d'autre.

Avoir le soutien de la direction. Ne soyez pas un Nosy Nancy en train de créer des règles sans importance. Convaincre littéralement la direction que c'est important, et ce sont ensuite eux qui convaincront le groupe que c'est important. Ne travaillez pas pour convaincre tout le monde.

Et la suggestion la plus agaçante et sujette à la tyrannie: soyez conscient de l’abus et utilisez le même jour. La même heure est la meilleure. Ne dites pas "Bad Naughty Developer" dites "Voici les étapes à suivre." S'ils le font à plusieurs reprises, désactivez la clé mal utilisée. Cela complique à la fois le partisan et celui qui a emprunté, et le partisan dira "Non, faites-le correctement" à l'avenir. Évitez de désactiver les clés présentes dans des projets réels.

Christopher Hostage
la source
1

Comment inciter les développeurs à ne pas partager les clés d'API en interne?

  • Générez des clés à la suite de l'enregistrement d'une application en libre-service .
  • Requiert un point de contact avant que les clés ne deviennent actives.
  • Et leur demander de ne pas partager. (Créez des conditions de service et / ou expliquez-leur pourquoi il vaut mieux ne pas les partager.)

Vous devez également mettre en place une limitation du débit . Cela en soi pourrait décourager le partage de clés. Cela protège votre système dans une certaine mesure contre les applications abusives. (Et les plus malveillants.) Et, cela garantit que vous serez quelque peu informé avant une augmentation massive du trafic réparable. (En vous donnant le temps d'ajouter de la capacité, j'espère!)

Et, avec la limitation de débit, lorsqu'une application nécessite une limite supérieure, elle ouvre une boîte de dialogue avec le POC enregistré pour la clé. Vous avez la possibilité de demander si les clés sont partagées, d'expliquer pourquoi c'est nuisible, etc., et vous pouvez proposer des clés supplémentaires lorsque cela est approprié au lieu des modifications de limite de débit demandées. Etc.

svidgen
la source
0

Une façon de faire, en particulier si les équipes utilisent un système de build partagé (ou du moins suffisamment commun), consiste à configurer un serveur interne qui crée et émet des clés API (à partir de quelques informations de base sur le produit qui l'utilise. ). Ensuite, utilisez un script qui récupère une nouvelle clé d'API du serveur pour chaque génération ou pour chaque mise à jour de version. Laissez les développeurs exécuter le script pour obtenir une clé différente pour leurs versions locales également. (Autant que possible, automatisez cela dans le cadre de la construction afin qu'ils n'aient même pas besoin d'y penser.)

Cela vous laisserait savoir s'il s'agissait de quelque chose en production, en assurance qualité ou en dev, et à quelle version / construction les problèmes ont commencé.

Miral
la source
0

La première et la meilleure chose à faire est de formater les clés de manière à ce qu'elles incluent le nom de l'application sous une forme facilement lisible, et ne fonctionnent pas si vous le modifiez.

S'il est évident que les équipes utilisent la mauvaise clé, elles s'efforceront de ne pas le faire.

Ensuite, les clés expirent périodiquement. Vous devriez le faire quand même , et quand une clé arrive à expiration, vous pouvez en envoyer une nouvelle à l'équipe qui en est propriétaire. L’équipe qui utilise une clé sera ensuite incitée à s’assurer qu’elle est l’équipe qui la possède, de sorte qu’elle obtienne la nouvelle lorsqu’elle expire.

Matt Timmermans
la source
1
en pratique, bien que l'expiration des clés puisse être un obstacle trop important pour l'application qui l'adopte - je peux voir les gestionnaires dire "fuggetaboutit", car cela ne posera que des problèmes plus tard.
Davidbak