Wie kann ich die gemeinsame Nutzung interner API-Schlüssel in einem Unternehmen verhindern?

37

Wir arbeiten an einem neuen Dienst - dieser Dienst wird möglicherweise direkt von Anwendungen auf Benutzergeräten aufgerufen. Diese Anwendungen werden von mehreren Entwicklungsteams aus der gesamten Organisation entwickelt und unterstützt, abhängig von den von uns bereitgestellten Daten.

Wir möchten herausfinden, welche Anwendungen welche Anforderungen senden, damit wir Verwendungsmuster und verantwortliche Entwickler identifizieren können. (Zur Vermeidung von Zweifeln wird die Benutzerauthentifizierung separat behandelt.)

Als Lösung benötigen wir einen API-Schlüssel pro Anwendung. Dann haben wir die Kontaktdaten für das Entwicklungsteam.

Wir möchten nicht, dass die API-Schlüssel zu Problemen führen, befürchten jedoch, dass Entwickler sie an Kollegen in anderen Teams weitergeben, sodass wir den Datenverkehr nicht mehr nur für eine Anwendung identifizieren können.

Wie können wir Entwickler dazu motivieren, API-Schlüssel nicht intern gemeinsam zu nutzen?

api enterprise-development

— Oli
quelle

5

Wie werden diese Teams auf die API zugreifen? Über das interne Netzwerk? Im Allgemeinen werden unterschiedliche Teams in unterschiedliche Subnetze eingeteilt, sodass Sie die Verwendung eines bestimmten API-Schlüssels durch das Netzwerk erzwingen können. Wie auch immer, die soziale Lösung lautet: "Es ist wichtig, dass Sie diesen API-Schlüssel nicht für die Sicherheit freigeben, sondern für uns die Metriken verschiedener Benutzer benötigen, um sie zu verbessern. Wenn jemand Sie bittet, teilen Sie ihm einfach mit, dass er uns fragen soll, und wir stellen ihnen gerne und effizient einen API-Schlüssel zur Verfügung. "

— Giacomo Alzetta

3

Wenn Sie nicht möchten, dass Personen Schlüssel an Kollegen weitergeben, können Sie auf einfache Weise eine Konfigurationsdatei hinzufügen, die vom Versionsverwaltungssystem ignoriert wird (sodass der Schlüssel niemals festgeschrieben wird), und das Erstellen neuer Schlüssel vereinfachen. Niemand wird sich die Mühe machen, einen geheimen Schlüssel zu teilen, wenn ein anderer Entwickler leicht selbst einen neuen Schlüssel erstellen kann. Das Problem beim Freigeben persönlicher Schlüssel ist in der Regel darauf zurückzuführen, dass das Abrufen neuer Schlüssel einige Zeit in Anspruch nimmt.

— Sulthan,

Haben Sie darüber nachgedacht, beim ersten Start der Anwendung eine Registrierung erforderlich zu machen? Es könnte ein Begrüßungsbildschirm angezeigt werden, in dem Sie nach den Kontaktdaten des Benutzers gefragt werden (oder nach den Informationen, die Sie benötigen), und der den API-Schlüssel sofort ausgibt.

— John Wu

"Wie können wir Entwickler dazu motivieren, API-Schlüssel nicht intern gemeinsam zu nutzen?" Einfach ausgedrückt, binden Sie jeden Schlüssel an die MAC-Adresse der Netzwerkkarte (n) in den Computern, auf denen sie ausgeführt werden. Netzwerkprotokolle verhindern, dass dieselben MAC-Adressen in demselben Netzwerk verwendet werden, sodass Benutzer nicht immer wieder dieselben Schlüssel verwenden. Ich hätte das zu einer Antwort gemacht, aber ich habe momentan nicht den Repräsentanten dafür.

— Blerg,

Seltsamerweise sehe ich das Wort "Rotation" (wie bei der Schlüsselrotation - Ablauf / Rotation von Berechtigungsnachweisen) auf dieser Seite im Moment nirgendwo. Hat jemand, der einen Schlüssel erhalten hat, eine begrenzte Lebensdauer, nach der er außer Betrieb gesetzt und durch einen neuen ersetzt werden muss? Wenn nein, warum nicht?

— Michael - sqlbot

76

Um diese Schlüssel zwischen Teams zu teilen, müssen die Teams miteinander sprechen, sich darauf einigen, sie zu teilen und sie dann zu teilen. Das braucht Zeit. Wenn ein Team API-Schlüssel schneller und einfacher von Ihnen anfordern kann, gibt es keinen Anreiz zum Teilen.

Und der einfachste Weg für sie, diese Schlüssel anzufordern, ist für Sie, sie vorab zu sichern. Angenommen, Sie kennen alle anderen Teams, die API-Schlüssel benötigen, und erstellen sie und geben sie frei, bevor Sie ihnen den Service zur Verfügung stellen.

Es gibt noch einen weiteren Anreiz, den Sie anbieten können: Debugging-Unterstützung. Diese Teams werden Ihre Hilfe brauchen, wenn die Dinge nicht richtig funktionieren, wenn sie ihre Arbeit in Ihren Service integrieren. Mit diesen API-Schlüsseln können Sie ihre spezifischen Anforderungen nachverfolgen und so das Debuggen von Fehlern unterstützen. Verkaufen Sie das als Grund für die Schlüssel, anstatt " Nutzungsmuster und verantwortliche Entwickler zu identifizieren ", was so klingt, als würden Sie ihre Aktivitäten ausspionieren.

— David Arno
quelle

2

Re: sharing, in einer idealen Welt haben Sie Recht - aber Sie setzen voraus, dass sie perfekte Informationen enthalten (obwohl ich sie an Dokumente aus dem Schema, dem Stammverzeichnis des Endpunkts und etwaigen Fehlern weiterleiten kann) und kooperatives Management Nicht die Realität, in der sie möglicherweise nur den Endpunkt und einen Code haben, der von einem anderen Team kopiert und von einem Senior Manager weitergeleitet wurde.

— Oli,

3

Wenn Sie vorwegnehmen, haben Sie vollkommen Recht, wir sollten aggressiv Schlüssel erstellen und an interessierte Parteien verschicken. Was ich nicht erwähnt habe, ist, dass einige dieser Apps ein gemeinsames Framework / Interface verwenden, und wir könnten möglicherweise halbautomatisch eindeutige Schlüssel auf dieser Ebene einspeisen oder erzwingen, aber das gilt nicht für alle Apps.

— Oli

1

@Ewan Wenn Sie einfach den Zugriff auf einen bestimmten Schlüssel deaktivieren, werden alle Benutzer zu Ihnen geführt - Sie müssen sie nicht verfolgen. Und dann können Sie ihnen eindeutige Schlüssel geben :)

— Alexei Levenkov

15

Die Vorauswahl sollte folgendermaßen erfolgen: Wenn Sie ohne Schlüssel auf die API zugreifen, wird eine Fehlermeldung mit einem Link zu der Seite angezeigt, auf der Sie den Schlüssel beantragen. Erwarten Sie nicht, dass jemand die Dokumentation liest. Anreize funktionieren nicht, wenn niemand etwas darüber weiß.

— candied_orange

1

Wenn Fehlermeldungen oder Debug-Protokolle automatisch per E-Mail an eine mit dem Schlüssel verknüpfte Adresse gesendet werden, hat jeder, der die Daten haben möchte, einen Anreiz, seinen eigenen Schlüssel zu verwenden und sie dazu bringen, aufzuhören.

— Robin Bennett

20

Gute Antworten, ich habe mir gerade einen anderen Ansatz überlegt, der für Sie vielleicht funktioniert oder auch nicht.

Anstatt Schlüssel auszugeben, die einbezogen werden sollen, kann es erforderlich sein, dass der Header der Anforderungen den Namen der Front-End-Anwendung enthält, die vom Entwickler der Front-End-Anwendung erstellt und formatiert wird, wie dies bei Webbrowsern der Fall ist. Auf diese Weise könnten Front-Ends immer noch so tun, als ob sie eine andere Anwendung wären, aber dies hätte keinen Vorteil, so dass dies unwahrscheinlich erscheint. Lassen Sie das Frontend sich identifizieren und akzeptieren Sie alle nicht leeren Zeichenfolgen.

— Martin Maat
quelle

Dies würde das Leben etwas erschweren, wenn sich der Besitz einer Anwendung ändert. Beispielsweise könnten wir nur die API-Schlüsseldetails aktualisieren, die auf unserer Seite gespeichert sind, aber wenn wir Freiformtext akzeptieren, für den die Anwendung eine Codeänderung vornehmen muss.

— Oli

1

@Oli Wenn sich das Eigentum an einer Anwendung ändert und der (neue) Entwickler es für angemessen hält, die Identität der Anwendung zu aktualisieren (die er wirklich hat, weil sie von einer anderen Person verwaltet wird), was wäre das Problem? Sie können zwischen Vorbesitzerwechsel und Nachbesitzerwechsel unterscheiden. Betrachten Sie sie einfach als zwei verschiedene Anwendungen. Ich würde jedoch nicht erwarten, dass ein neuer Besitzer den Namen in der Kopfzeile bald bemerkt.

— Martin Maat

3

Das ist was ich mache. Lassen Sie den Client einen Konstruktionsparameter haben, der der Name der App ist, und / oder verwenden Sie Reflection, um andere Elemente wie die Maschine, auf der sie ausgeführt wird, die Version usw. abzurufen Politik

— Ewan

1

Wenn die Organisation einen gemeinsamen Ansatz zur Versionskontrolle verfolgt, z. B. alle Benutzer ihren Code auf dem GitHub-Server der Organisation speichern, senden Sie jeder Anwendung eine URL an das Repo und den Commit-Hash, aus dem sie erstellt wurde. Der Festschreibungs-Hash kann als Teil des Erstellungsprozesses in den Code aufgenommen werden, sodass Entwickler nichts aktualisieren müssen. Wenn Sie die Repo-URL haben, können Sie sehen, wer der Eigentümer ist, und wenn Sie bestimmte Commits erhalten, können Sie Verhaltensunterschiede zwischen den Versionen feststellen.

— Caleb

@Caleb Wenn die Dinge so zentralisiert wären, hätte das OP dieses Problem wahrscheinlich nicht. Soweit ich weiß, sind die Entwickler von Front-End-Anwendungen anonym und verfügen über private Möglichkeiten der Softwareentwicklung.

— Martin Maat

16

Zusamenfassend:

Erstens: Erleichterung und Nutzen; Bei Bedarf: Reiberei und Polizei.

Noch ein paar Worte

Erleichterung : Machen Sie es einem Team zunächst einfach, einen neuen API-Schlüssel zu erhalten. Fügen Sie beispielsweise eine Erinnerung in die Unternehmensabläufe zum Starten neuer Projekte ein und bieten Sie einen benutzerfreundlichen Service zum Anfordern neuer Schlüssel an, ohne nach einer Begründung zu fragen.

Vorteile : Nutzen Sie die Verwendung eines eigenen API-Schlüssels für das Team oder den Product Owner. Schlagen Sie beispielsweise ein Feedback zur App-Nutzung basierend auf diesem Schlüssel vor.

Reibung : Abhängig von der Schlüsselfunktion können Sie Reibungen erstellen, zum Beispiel wenn der Schlüssel mit einer von der Software definierten Domäne verknüpft ist (dh die Wiederverwendung von Schlüsseln würde nicht notwendigerweise den Zugriff auf alle gewünschten Dienste ermöglichen).

Polizeiarbeit : Schließlich müssen Sie möglicherweise einige Polizeimaßnahmen vorsehen. Beispielsweise können Sie die Verwendung von API-Funktionen mit einem API-Schlüssel überwachen und nach einer bestimmten Zeit eine Anfrage zur Verwendung von API-Teilen erstellen, die im Hinblick auf die Baseline nicht zu erwarten ist. Oder wenn dies nicht realistisch ist, fügen Sie einfach in die Checklisten für die Überprüfung von Unternehmensprojekten die Bestätigung ein, dass ein gültiger Schlüssel verwendet wurde.

Anmerkung : Möglicherweise müssen Sie Ihre API-Schlüsselrichtlinie klar definieren: Benötigt eine neue Hauptversion einen eigenen API-Schlüssel? Was ist mit einer Gabelung oder wenn eine App aufgeteilt ist? was ist, wenn ein anderes Team verantwortlich ist, etc ...

— Christophe
quelle

6

Im Allgemeinen ist es der einfachste Weg, Entwickler dazu zu bringen, "das Richtige zu tun", es ihnen einfach zu machen.

Zu diesem Zweck würde ich vorschlagen, einen API-Schlüssel für die Ausgabe von Webseiten / Websites zu erstellen. In seiner einfachsten Form kann es sich lediglich um ein Login (idealerweise an Ihr AD / LDAP-Unternehmen gebunden) und die Seite handeln, auf der nur der Anwendungsname abgefragt und der Schlüssel ausgegeben wird.

Am Ende des Tages können Sie Schlüssel später jederzeit widerrufen. Sie müssen also nur aufzeichnen, wer (Benutzername) den Schlüssel angefordert hat und was (Anwendungsname) er damit tun möchte - zusammen mit den erforderlichen Informationen den Schlüssel später widerrufen.

Mit einem Ticketsystem könnte man etwas Ähnliches machen, aber am Ende des Tages ist es für mich sehr einfach, einen Schlüssel von einer App in eine andere zu kopieren und einzufügen. Es muss also wirklich einfach sein, einen neuen Schlüssel anzufordern, um Fehler zu vermeiden Verhalten.

— DavidT
quelle

1

Sei proaktiv.

Identifizieren Sie mögliche Entwickler und GEBEN Sie ihnen eindeutige API-Schlüssel in einem sicheren Kanal im Voraus. Bieten Sie eine einfache Möglichkeit, neue API-Schlüssel anzufordern. Bieten Sie eine einfache Möglichkeit für neue Benutzer, die neue API-Schlüssel anfordern. Wenn neue Praktikanten oder Angestellte dem Team beitreten, geben Sie ihnen ein JIRA-Ticket oder ein ähnliches "Request an API Key" (API-Schlüssel anfordern) mit den Schritten in der Beschreibung.

Verfolgen Sie, welche API-Schlüssel verwendet wurden und welche nicht. Wenn Bob Tickets für das Projekt eingereicht hat, aber seine API-Schlüssel nicht verwendet hat, hat er wahrscheinlich die eines anderen ausgeliehen.

Haben Sie die Unterstützung des Managements. Sei keine neugierige Nancy, die Regeln aufstellt, die keine Rolle spielen. Überzeugen Sie das Management buchstäblich davon, dass es wichtig ist, und überzeugen Sie die Gruppe dann davon, dass es wichtig ist. Arbeiten Sie nicht daran, alle zu überzeugen.

Und der nervigste und tyrannischste Vorschlag: Seien Sie sich des Missbrauchs bewusst und gehen Sie noch am selben Tag hart durch. Gleiche Stunde ist am besten. Sagen Sie nicht "Bad Naughty Developer", sondern "Here are the proper steps". Wenn sie es wiederholt tun, deaktivieren Sie den missbrauchten Schlüssel. Dies belastet sowohl den Sharer als auch denjenigen, der geliehen hat, und der Sharer wird in Zukunft "Nein, mach es richtig" sagen. Vermeiden Sie das Deaktivieren von Schlüsseln in Live-Projekten.

— Christopher Geisel
quelle

1

Wie können wir Entwickler dazu motivieren, API-Schlüssel nicht intern gemeinsam zu nutzen?

Generieren Sie Schlüssel als Ergebnis der Registrierung von Self-Service-Anwendungen .
Benötigen Sie einen Ansprechpartner, bevor die Tasten aktiv werden.
Und bitte sie, nicht zu teilen. (Erstellen Sie Nutzungsbedingungen und / oder erklären Sie ihnen, warum es für sie besser ist, diese nicht zu teilen.)

Sie sollten auch eine Ratenbegrenzung implementieren . Dies kann die gemeinsame Nutzung von Schlüsseln verhindern. Es schützt Ihr System in gewissem Maße vor missbräuchlichen Anwendungen. (Und geradezu böswillige.) Und es stellt sicher, dass Sie vor einem massiven Anstieg des zu wartenden Datenverkehrs einigermaßen informiert sind. (Ich hoffe, Sie haben Zeit, Kapazität hinzuzufügen!)

Bei der Ratenbegrenzung wird ein Dialogfeld mit dem für den Schlüssel registrierten POC geöffnet, wenn für eine Anwendung ein höheres Limit erforderlich ist. Sie haben die Möglichkeit, zu fragen, ob Schlüssel gemeinsam genutzt werden, zu erklären, warum dies schädlich ist usw. Sie können bei Bedarf zusätzliche Schlüssel anstelle der angeforderten Änderungen des Ratenlimits anbieten . Etc.

— Svidgen
quelle

0

Eine Möglichkeit, Dinge zu tun, insbesondere wenn die Teams ein gemeinsam genutztes Build-System verwenden (oder zumindest ein ausreichend verbreitetes), besteht darin, einen internen Server einzurichten, der API-Schlüssel erstellt und ausgibt (mit ein paar grundlegenden Informationen über das Produkt, das es verwendet ). Verwenden Sie dann ein Skript, das für jeden Build oder für jedes Versionsupdate einen neuen API-Schlüssel vom Server abruft. Lassen Sie die Entwickler das Skript ausführen, um auch einen anderen Schlüssel für ihre lokalen Builds zu erhalten. (Wenn möglich, automatisieren Sie dies als Teil des Builds, damit sie nicht einmal darüber nachdenken müssen.)

Auf diese Weise können Sie feststellen, ob es sich um eine Produktion, eine Qualitätssicherung oder eine Entwicklung handelt und ab welcher Version / welchem Build die Probleme begonnen haben.

— Miral
quelle

0

Das erste und beste, was Sie tun können, ist, die Schlüssel so zu formatieren, dass sie den Anwendungsnamen in einer leicht lesbaren Form enthalten und nicht funktionieren, wenn Sie ihn ändern.

Wenn es offensichtlich ist, dass Teams den falschen Schlüssel verwenden, werden sie sich bemühen, dies nicht zu tun.

Lassen Sie die Schlüssel dann regelmäßig ab. Sie sollten dies trotzdem tun , und wenn sich ein Schlüssel dem Verfallsdatum nähert, können Sie einen neuen an das Team senden, dem er gehört. Das Team, das einen Schlüssel verwendet, wird dann motiviert, sicherzustellen, dass es das Team ist, das ihn besitzt, damit es den neuen erhält, wenn er abläuft.

— Matt Timmermans
quelle

1

In der Praxis ist das Ablaufen von Schlüsseln möglicherweise eine zu große Hürde für die Annahme der Anwendung. Ich sehe Manager, die "fuggetaboutit" sagen, da es später nur noch Ärger geben wird.

— Davidbak