Best practice per API relativamente semplici per i nostri clienti

4

Ho letto molte considerazioni sulla sicurezza dell'API, le differenze di terminologia, OAUTH, OpenID, ecc. Benché comprenda la loro assoluta necessità quando si tratta di proteggere un'API in modo corretto, mi trovo di fronte al mio (forse ingenuo ) visione di come potrebbero essere le cose. Speravo che potessi dirmi quanto sono sbagliato o giusto e indirizzarmi nella giusta direzione. Sarebbe certamente apprezzato.

Quindi, che cosa esattamente è stato chiesto di fare? - La società per cui lavoro, denominata Azienda X, ha molti dati memorizzati internamente . Ora abbiamo finalmente un db PostgreSQL esterno e un server web che utilizza Amazon EC2. Funziona molto bene Ora, utilizzo Slim Framework per creare percorsi, gestire richieste GET / POST / PUT / DELETE, inviare query usando PDO e così via. Ora sono arrivato al punto in cui l'azienda X mi chiede come i loro clienti saranno in grado di comunicare con l'API. Ora ovviamente non potrei concedere l'accesso a tutti, quindi inizialmente pensavo a una chiave API per client. Ho usato Instagram e altre API simili e sembrano funzionare in modo simile. Tuttavia, sono anche leggendo che "le chiavi API non sono sufficienti". Posso capire perché questo metodo può essere troppo semplicistico per una delicata questione di scambio di informazioni, ma non so se le altre opzioni sono STRATEGIE complesse per gli obiettivi che sto affrontando.

Quindi, di nuovo per essere chiari, ciò che vorrei realizzare è il seguente compito: voglio che gli utenti OTTIENI (diciamo) le note dal nostro server, voglio che siano in grado di prendere appunti POST, aggiornarli ed eliminarli pure.

La mia domanda è come posso farlo in un modo sicuro , senza doverti immergere in dozzine di documenti di protocollo. Certo, se questa è la via da seguire, allora sono sicuro che potrebbero esserci altri modi per dimostrarsi altrettanto sicuri.

Grazie per la lettura e soprattutto se decidi di aiutarmi o almeno di dirmi quanto mi allontano dal pensare con il giusto stato d'animo. : -)

    
posta digifrog 21.04.2016 - 17:22
fonte

1 risposta

2

Modifica: Chiarito in base al caso d'uso

Prima di tutto, nessun sistema è perfetto. L'ingegneria è l'arte di fare i migliori compromessi.

Per le API back-end-back-end (ad esempio, l'app del server e il servizio API di terze parti): le chiavi API sono davvero buone. La maggior parte dei problemi con le chiavi API viene dagli sviluppatori che trascurano il modo in cui li memorizzano (in code = > si impegnano a github repository pubblici ecc.). Le chiavi API sono

  1. stringhe ad alta entropia
  2. può essere revocato immediatamente
  3. non scade automaticamente (ottimo per le API I.e. di automazione della macchina)

Molte società di sicurezza come Amazon (fornitore cloud), Stripe (pagamenti) o Crypteron (sicurezza dei dati come servizio) utilizzano le chiavi API. Se sei il creatore dell'API, devi assolutamente progettare

  • una corretta gestione del ciclo di vita delle chiavi API (gli sviluppatori dei clienti possono aggiornare le chiavi API senza molti interventi) e
  • dovrebbe applicare rigorosamente TLS.

Come consumatore di chiavi API, idealmente si vogliono avere chiavi API separate per lo sviluppo e la produzione, quindi il team di sviluppo non vede i dati di produzione. Fondamentalmente hanno risorse di sviluppo / istanze vs risorse di produzione / istanze

Le cose cambiano per l'utente finale alle comunicazioni back-end , ad esempio app per cellulari = > la tua app del server. In questo caso, veramente non vuoi utilizzare le chiavi API perché stai tecnicamente autenticando gli utenti finali, non una API in sé. Se si utilizza una chiave API statica, chiunque può disassemblare il binario dell'app mobile e cercare la chiave API. Non saprai quando ciò accadrà, ma anche se lo sapessi, dovrai immediatamente aggiornare tutti i client con una nuova chiave API e tornerai al punto 1.

In sostanza, non utilizzare mai le chiavi API nelle app client come app mobili o app browser. Mai . È male come avere i client collegati direttamente al tuo DB piuttosto che avere un server web / app nel mezzo.

Stai meglio con le credenziali memorizzate nella cache + l'autenticazione di base + TLS per un sistema di due parti (utente, il tuo servizio). Se si utilizza una terza parte per verificare l'identità (ad esempio Facebook), OAuth è un'altra opzione per orchestrare tra le tre parti (utente, Facebook, il servizio). In base alla tua preoccupazione, suppongo che i tuoi clienti finali (mobili o browser) si colleghino direttamente agli endpoint REST di Slim Framework? Slim Framework sembra supportare l'autenticazione di base in modo che più TLS dovrebbe essere un buon punto di partenza. Se hai dubbi specifici, chiariscili nella domanda.

Divulgazione: lavoro per Crypteron . Controllaci!

    
risposta data 21.04.2016 - 17:35
fonte

Leggi altre domande sui tag