Come impedire la scansione dei dati tramite API pubbliche?

Question

Come impedire la scansione dei dati tramite API pubbliche?

#1 da (3 voti)
#2 da (1 voti)
#3 da (1 voti)
#4 da (0 voti)

4

Il nostro cliente (una banca) ha bisogno di pubblicare un'API del servizio web per l'utilizzo da parte di applicazioni di terze parti. La sicurezza coinvolgerà OAuth2 e JWT (Token Web JSON). Il problema è che il cliente ha paura dell'uso improprio delle API pubblicate dalle terze parti a cui non si fidano completamente (per favore, non commentare su questo). Uno scenario di base è simile a questo:

L'API pubblica contiene un'operazione IsOurCustomer () che restituisce true / false se la persona ha un prodotto nella banca. L'operazione successiva è CreateNewCustomer () e viene chiamata quando IsOurCustomer () restituisce false.

La banca teme che una terza parte possa analizzare la propria base di clienti controllando chi è / non è il loro cliente chiamando IsOurCustomer () in sequenza per tutte le persone prese da un'altra fonte (ad esempio da un registro pubblico). (Non posso dire se il presunto danno è reale o se è solo una paranoia.)

C'è un modo per prevenire la possibilità di scansione dei dati?

Ci sono alcune soluzioni parziali con cui siamo venuti, ma nessuno di loro attenua completamente il problema:

Throttling - È difficile impostare il limite corretto che non limiti il lavoro legale della società di terze parti, ma impedirebbe loro di utilizzare male l'API nello stesso momento. Soprattutto quando la terza parte ha molti dipendenti e abbastanza tempo. La terza parte potrebbe emettere migliaia di assegni cliente (giustificati) al giorno, che potrebbero consentire loro di eseguire la scansione di 1 milione di persone all'anno.
Minacce legali - quando viene rilevato un uso improprio dell'API (che richiede registrazione e monitoraggio).
Pagamenti per chiamata API - sopra un limite concordato
Euristica - ad es. segnala un avviso quando il rapporto delle chiamate verso IsOurCustomer () e CreateNewCustomer () è troppo alto.
"Sistema Prevenzione delle perdite di dati" - Non conosco nessun DLP utilizzabile per il nostro scopo.

api-design security web-services

posta xarx 15.11.2016 - 17:38

fonte

4 risposte

Leggi altre domande sui tag api-design security web-services

Design pattern per ruolo utente free / premium Sicurezza gateway API (per architettura microservizi)

score 3 · Answer 1

Mi sembra una preoccupazione legittima.

Non ti addentrati nei dettagli sullo scopo per cui a terzi viene dato l'uso dell'API.

Ma se non dovrebbero essere in grado di vedere chi è un cliente o meno e non richiedono tali informazioni, esiste una soluzione semplice:
Rimuovi IsOurCustomer ()

Chiedi a ciascun "titolare" dell'API di creare i propri clienti e collegarli di nuovo ai clienti delle banche in caso di necessità per la segnalazione.

Forse hai uno scenario più complesso però.

La terza parte HA BISOGNO di sapere se il cliente è già cliente o no, come parte di una procedura di registrazione, ma la banca non vuole dirglielo
Richiede alla terza parte di firmare un contratto affermando che lo farà usa solo le informazioni dall'api per uno scopo particolare.

Questo sarebbe abbastanza comune in questi giorni di protezione dei dati. La banca deve riconoscere che si tratta di un problema umano piuttosto che tecnico.

Tuttavia, forse hai una situazione ancora più delicata !!

La terza parte richiede le informazioni per poter eseguire l'operazione che la banca ha scelto. Ma quando l'ufficio legale lo esamina, ha affermato che la banca non è in grado di comunicare legalmente al cliente tali informazioni.
Qui sei un po 'fregato. Tuttavia, forse è possibile ottenere la terza parte per dimostrare che già conoscono le informazioni che stai divulgando. Ad esempio: IsOurCustomer (string bankAccountNumber)

score 1 · Answer 2

Potresti considerare di combinare le due operazioni. Chiedi a CreateNewCustomer di verificare i clienti esistenti e restituire un messaggio che indica che si trattava di un cliente esistente e contiene l'ID cliente esistente. In questo modo non puoi eseguire la scansione di un grande database senza creare nuovi clienti, che presumibilmente ha una sorta di passaggio per la verifica della posta elettronica o qualcos'altro che potrebbe essere notato.

score 1 · Answer 3

Questo è un rischio serio, penso, ma c'è un modo per aggirarlo che ti permette di fidarti di certe persone.

Suppongo che una terza parte abbia un legittimo bisogno di sapere se qualcuno è il tuo cliente.

Darei a ciascuna terza parte un identificatore di cui sono responsabili che li identifica nell'API. Questo identificatore si collega quindi a una tabella denormalizzata che fa riferimento a un ID univoco per un cliente. Se quella combinazione denormalizzata non è nella tabella, quindi a tutti gli effetti, quella terza parte non sa che il cliente esiste.

Quindi hai il cliente A che ha una relazione con Terze parti 1, ma non Terza parte 2. Ovviamente, vuoi che Terzo utente 1 veda questo cliente, quindi quando Terza parte effettua una chiamata con le informazioni del cliente A, ma il loro id, ottengono una risposta che questo cliente non esiste (o qualunque errore tu voglia dare). Terza parte 1, tuttavia, può tranquillamente chiamare la stessa API e ottenere informazioni sul cliente.

EDIT: Suppongo anche che tu stia facendo la messa in sicurezza appropriata di questi endpoint in modo che solo le tue terze parti fidate possano accedervi, e non un ragazzo casuale fuori strada. Poiché questi dati sono probabilmente regolati dalla FINRA, sei obbligato a proteggerli.

score 0 · Answer 4

Sembra che tu stia cercando di risolvere un problema umano con mezzi tecnici. Mentre la tecnologia può soffocare l'abuso umano, qualcuno che è determinato abbastanza troverà un modo. L'unico modo per fermarlo è mettere tanta tecnologia nel modo di usare l'API che diventa impossibile da usare (legittimamente o meno). Escludendo rendendo l'API inutilizzabile, prova a risolvere un problema umano con soluzioni umane, che in questo caso sono probabilmente avvocati.

Innanzitutto, proteggi l'API. Fai in modo che per poter utilizzare l'API, ogni richiesta richieda una chiave API unica per terze parti. (Se necessario, aggiungi la crittografia, possibilmente asimmetrica.) Richiede a terze parti di firmare un accordo legale sul modo in cui i dati possono essere utilizzati prima di emetterli una chiave API.

Secondo, registro, molto. Far firmare a qualcuno un accordo per non abusare dei dati è inutile se non si ha modo di rilevare o provare l'uso improprio. Dal momento che tutti hanno una chiave API unica, dovrebbe essere abbastanza facile sapere chi sta facendo le richieste e con quale frequenza. Quindi fare analizzare periodicamente i registri e sollevare avvisi se qualcosa di sospetto si presenta. Quindi lascia che un umano prenda la decisione finale se l'uso sembra legittimo.