Come posso scoraggiare la condivisione delle chiavi API interne all'interno di un'azienda?

37

Stiamo lavorando a un nuovo servizio: questo servizio sarà potenzialmente chiamato direttamente dalle applicazioni sui dispositivi degli utenti. Queste applicazioni saranno sviluppate e supportate da più team di sviluppo di tutta l'organizzazione, a seconda dei dati forniti.

Desideriamo identificare quali applicazioni stanno inviando quali richieste, in modo da poter identificare i modelli di utilizzo e gli sviluppatori responsabili. (A scanso di equivoci, l'autenticazione dell'utente viene gestita separatamente.)

La nostra soluzione è richiedere chiavi API, una per applicazione, quindi abbiamo i dettagli di contatto per il team di sviluppo.

Non vogliamo che le chiavi API siano fonte di attrito, ma siamo preoccupati che gli sviluppatori le condividano con colleghi di altri team, il che significa che non possiamo più identificare il traffico per una sola applicazione.

Come possiamo incentivare gli sviluppatori a non condividere le chiavi API internamente?

api enterprise-development

— oli
fonte

5

In che modo questi team accederanno all'API? Tramite la rete interna? Generalmente team diversi vengono inseriti in sottoreti diverse in modo da poter applicare l'uso di una determinata chiave API dalla rete ... Comunque la soluzione sociale è dire loro "è importante non condividere questa chiave API non per sicurezza ma perché noi hanno bisogno delle metriche di diversi utenti per migliorarlo. Se qualcuno ti chiede basta dirglielo e noi saremo lieti ed efficienti di fornire loro una chiave API ".

— Giacomo Alzetta,

3

Se non desideri che le persone condividano le chiavi con i colleghi, semplifica l'inclusione di un file di configurazione che viene ignorato dal sistema di controllo delle versioni (in modo che la chiave non venga mai assegnata) e semplifica anche la creazione di nuove chiavi. Nessuno si preoccuperà di condividere una chiave segreta se un altro sviluppatore può facilmente creare una nuova chiave da solo. Il problema con la condivisione delle chiavi personali è di solito un problema causato dal fatto che ottenere nuove chiavi richiede tempo.

— Sulthan,

Hai pensato di richiedere la registrazione al primo avvio dell'applicazione? Potrebbe mostrare una schermata iniziale che richiede i dettagli di contatto dell'utente (o qualsiasi informazione sia necessaria) e quindi rilasciare la chiave API sul posto.

— John Wu,

"Come possiamo incentivare gli sviluppatori a non condividere le chiavi API internamente?" In poche parole, associare ogni chiave all'indirizzo MAC delle schede di rete nei computer che le eseguono. I protocolli di rete impediscono di utilizzare gli stessi indirizzi MAC nella stessa rete, in modo da impedire alle persone di utilizzare le stesse chiavi più e più volte. Lo avrei trasformato in una risposta, ma al momento non ho il rappresentante.

— Blerg,

Curiosamente, non vedo la parola "rotazione" (come nella rotazione dei tasti - scadenza / rotazione delle credenziali) ovunque in questa pagina al momento. Una volta che qualcuno ottiene una chiave, ha una durata limitata dopo la quale deve essere ruotata fuori uso e sostituita con una nuova? In caso contrario, perché no?

— Michael - sqlbot,

76

Per condividere le chiavi tra i team, i team devono parlare tra loro, accettare di condividerli, quindi condividerli. Questo richiede tempo. Quindi, se un team può richiedere le tue chiavi API più rapidamente e più facilmente, non c'è alcun incentivo a condividere.

E il modo più semplice per loro di richiedere quelle chiavi è quello di prevederle. Supponendo di conoscere tutti gli altri team che avranno bisogno di chiavi API, crearli e condividerli prima di rendere disponibile il servizio.

C'è un altro incentivo che puoi offrire: supporto per il debug. Quei team vorranno il tuo aiuto quando le cose non funzionano correttamente quando integrano il loro lavoro con il tuo servizio. Queste chiavi API ti consentono di tenere traccia delle loro richieste specifiche e quindi di assistere nel debug di ciò che non va. Quindi vendilo come il motivo delle chiavi, piuttosto che " identificare i modelli di utilizzo e gli sviluppatori responsabili ", che sembra che tu stia spiando le loro attività.

— David Arno
fonte

2

Ri: condivisione, in un mondo ideale hai ragione - ma stai presupponendo che abbiano informazioni perfette (anche se posso aiutarti indirizzandoli a documenti dallo schema, dalla radice dell'endpoint e da eventuali errori) e dalla gestione cooperativa, e non la realtà in cui tutto ciò che possono avere è l'endpoint e un codice copiato da un'altra squadra che sono stati inoltrati da un senior manager.

— Oli,

3

Ri: anticipando, hai assolutamente ragione, dovremmo creare e inviare in modo aggressivo le chiavi alle parti interessate. Quello che non ho menzionato è che alcune di queste app usano un framework / interfaccia comune e potremmo forse iniettare o imporre semi-automaticamente chiavi univoche a quel livello, ma ciò non si applica a tutte le app.

— Oli,

1

@Ewan se semplicemente disabiliti l'accesso a una determinata chiave, tutti gli utenti ti eseguiranno - non è necessario inseguirli. E poi puoi dare loro chiavi uniche :)

— Alexei Levenkov,

15

La prelazione dovrebbe assumere questa forma: l'accesso all'API senza la chiave produce un messaggio di errore con un collegamento alla pagina in cui si applica la chiave. Non aspettarti che nessuno legga la documentazione. Gli incentivi non funzionano quando nessuno li conosce.

— candied_orange,

1

Se i messaggi di errore o i registri di debug fossero inviati automaticamente tramite e-mail a un indirizzo collegato alla chiave, chiunque desiderasse i dati avrebbe un incentivo a utilizzare la propria chiave e chiunque avesse la chiave condivisa avrebbe un incentivo a rintracciare la persona che li condivideva e farli smettere.

— Robin Bennett,

20

Buone risposte già, ho appena pensato a un approccio diverso che potrebbe o meno funzionare per te.

Anziché emettere chiavi da includere, è possibile che l'intestazione delle richieste includa il nome dell'applicazione front-end, che deve essere creata e formattata dallo sviluppatore dell'applicazione front-end, come fanno i browser Web. In questo modo i front-end potrebbero ancora pretendere di essere un'applicazione diversa, ma non ci sarebbe alcun vantaggio nel farlo, quindi sembra improbabile. Lascia che il front-end si identifichi e accetti qualsiasi stringa non vuota.

— Martin Maat
fonte

Ciò renderebbe la vita un po 'più difficile se cambiasse la proprietà di un'applicazione, ad esempio potremmo semplicemente aggiornare i dettagli della chiave API archiviati da parte nostra, ma se accettiamo il testo in formato libero che richiede all'applicazione di apportare una modifica al codice.

— Oli,

1

@Oli Se la proprietà di un'applicazione fosse cambiata e il (nuovo) sviluppatore lo ritenesse appropriato per aggiornare l'identità dell'applicazione (che ha davvero perché qualcun altro la sta mantenendo), quale sarebbe il problema? È possibile distinguere tra il cambio di pre-proprietà e il cambio di post-proprietà, considerandoli come due diverse applicazioni. Tuttavia, non mi aspetto che nessun nuovo proprietario noti presto il nome nell'intestazione.

— Martin Maat,

3

Questo è ciò che faccio. chiedi al client di avere un parametro di costruzione che è il nome dell'app e / o usa la riflessione per estrarre altre cose come la macchina su cui è in esecuzione, la sua versione ecc. La cosa fondamentale è permetterti di segnalare quando le persone NON seguono la tua api politica

— Ewan

1

Se l'organizzazione ha un approccio comune al controllo della versione, ad esempio tutti mantengono il proprio codice sul server GitHub dell'organizzazione, ogni app invia un URL al proprio repository e l'hash di commit da cui è stato creato. L'hash di commit può essere incluso nel codice come parte del processo di compilazione, quindi non è necessario che gli sviluppatori aggiornino nulla. Avere l'URL repository ti consente di vedere chi è il proprietario e ottenere specifici commit ti farebbe notare differenze di comportamento tra le versioni.

— Caleb,

@Caleb Se le cose fossero centralizzate in quel modo, probabilmente l'OP non avrebbe questo problema. Da quanto ho capito, gli sviluppatori di applicazioni front-end sono molto anonimi all'OP, con modalità private di sviluppo software.

— Martin Maat,

16

In breve:

Primo: facilitazione e benefici; Se necessario: attrito e polizia.

Qualche altra parola

Facilitazione : in primo luogo, per un team è facile ottenere una nuova chiave API. Ad esempio, aggiungere un promemoria nelle procedure aziendali per l'avvio di nuovi progetti e offrire un servizio facile da usare per richiedere nuove chiavi, senza chiedere giustificazioni.

Benefici : l'utilizzo di una propria chiave API è un vantaggio per il team o il proprietario del prodotto. Ad esempio, proporre alcuni feedback sull'utilizzo delle app in base a tale chiave.

Attrito : a seconda della funzione chiave, è possibile creare attrito, ad esempio se la chiave è collegata al dominio definito dall'app somme (ovvero il riutilizzo delle chiavi non darebbe necessariamente accesso a tutti i servizi desiderati).

Polizia : infine, potrebbe essere necessario prevedere alcune misure di polizia. Ad esempio, è possibile monitorare l'utilizzo delle funzioni API mediante il tasto API e, dopo un determinato periodo di tempo, stabilire una linea di base, un'indagine sull'uso delle parti di api che non è prevista in vista della linea di base. O se ciò non è realistico, includere semplicemente negli elenchi di controllo per la revisione dei progetti aziendali la verifica che sia stata utilizzata una chiave valida.

Nota : potrebbe essere necessario essere molto chiari sulla politica della chiave API: una nuova versione principale richiederebbe la propria chiave API? Cosa succede con un fork o se un'app è suddivisa? cosa succede se è responsabile un altro team, ecc ...

— Christophe
fonte

6

Generalmente, il modo più semplice per convincere gli sviluppatori a "fare la cosa giusta", è quello di renderlo facile per loro.

A tal fine, suggerirei di creare una pagina Web / un sito per l'emissione di una chiave API. Nella sua forma più semplice potrebbe essere solo un login (idealmente legato al tuo AD / LDAP aziendale) e la pagina che richiede solo il nome dell'applicazione e rilascia la chiave.

Alla fine della giornata puoi sempre revocare le chiavi in un secondo momento, quindi tutto ciò di cui hai veramente bisogno sul sito è registrare chi (nome utente) ha richiesto la chiave e cosa (Nome applicazione) vogliono farne - insieme a tutte le informazioni necessarie per revocare la chiave in seguito.

Potresti fare qualcosa di simile con un sistema di biglietteria, ma alla fine è molto facile per me copiare e incollare una chiave da un'app all'altra, quindi deve essere davvero facile richiedere una nuova chiave, per evitare problemi comportamento.

— DavidT
fonte

1

Sii proattivo.

Identifica in anticipo i probabili sviluppatori e fornisci loro chiavi API univoche in un canale sicuro. Fornire un modo semplice per richiedere nuove chiavi API. Fornire un mezzo semplice per le nuove persone che richiedono nuove chiavi API. Quando nuovi stagisti o assunzioni si uniscono al team, dai loro un ticket JIRA o simili "Richiedi una chiave API" con i passaggi nella descrizione.

Tieni traccia di quali chiavi API sono state utilizzate e quali no. Se Bob ha inviato i biglietti nel progetto ma non ha utilizzato le sue chiavi API, probabilmente ha preso in prestito qualcun altro.

Avere il supporto della direzione. Non essere una ficcanaso Nancy che sta truccando regole che non contano. Letteralmente convincere il management che è importante, e poi sono loro a convincere il gruppo che è importante. Non lavorare per convincere tutti.

E il suggerimento più fastidioso e incline alla tirannia: essere consapevoli dell'uso improprio e reprimere lo stesso giorno. La stessa ora è la migliore. Non dire "Bad Naughty Developer" dire "Ecco i passaggi corretti". Se lo fanno ripetutamente, disabilitare la chiave utilizzata in modo improprio. Ciò disturba sia il Conduttore che Colui che ha preso in prestito, e il conduttore dirà "No, fallo correttamente" in futuro. Evitare di disabilitare le chiavi presenti nei progetti live.

— Christopher Hostage
fonte

1

Come possiamo incentivare gli sviluppatori a non condividere le chiavi API internamente?

Generare le chiavi come risultato della registrazione dell'applicazione self-service .
Richiedi un punto di contatto prima che le chiavi diventino attive.
E chiedi loro di non condividere. (Crea termini di servizio e / o spiega loro perché è meglio che non condividano.)

Dovresti anche implementare la limitazione della velocità . Questo di per sé potrebbe scoraggiare la condivisione delle chiavi. Protegge il tuo sistema in una certa misura dalle applicazioni offensive. (E decisamente dannosi.) E, ti assicura di essere in qualche modo informato prima di un massiccio aumento del traffico utile. (Ti do tempo per aggiungere capacità, spero!)

E, con la limitazione della velocità, quando un'applicazione richiede un limite superiore, apre una finestra di dialogo con il POC registrato per la chiave. Hai l'opportunità di chiedere se le chiavi vengono condivise, spiegare perché ciò è dannoso e così via e puoi offrire chiavi aggiuntive quando è appropriato invece delle variazioni del limite di velocità richieste. Eccetera.

— svidgen
fonte

0

Un modo di fare le cose, specialmente se i team usano un sistema di compilazione condiviso (o almeno uno abbastanza comune) è quello di impostare un server interno che crei ed emetta chiavi API (dati alcune informazioni di base sul prodotto che lo utilizza) ). Quindi utilizzare uno script che acquisisce una nuova chiave API dal server per ogni build o per ogni aggiornamento di versione. Consenti agli sviluppatori di eseguire lo script per ottenere una chiave diversa anche per le loro build locali. (Laddove possibile, automatizza questo come parte della build in modo che non debbano nemmeno pensarci.)

Ciò ti permetterebbe di sapere se si trattava di qualcosa in produzione, QA o sviluppo e in quale versione / build sono iniziati i problemi.

— Miral
fonte

0

La prima e migliore cosa che puoi fare è formattare le chiavi in modo che includano il nome dell'applicazione in un formato facilmente leggibile e non funzionino se lo cambi.

Se è ovvio quando le squadre usano la chiave sbagliata, si sforzano di non farlo.

Quindi, scadono periodicamente le chiavi. Dovresti farlo comunque , e quando una chiave sta per scadere puoi inviarne una nuova alla squadra che la possiede. Il team che utilizza una chiave sarà quindi motivato per assicurarsi di essere la squadra proprietaria, in modo da ottenere quella nuova quando scade.

— Matt Timmermans
fonte

1

in pratica, anche se le chiavi in scadenza potrebbero essere un grosso ostacolo per l'applicazione adottante, vedo i manager che dicono "fuggetaboutit", poiché sarà solo un problema in seguito.

— davidbak,