Come effettuare chiamate API automatiche che sono almeno minimamente sicure? [duplicare]

5

Come faccio a scrivere script (per l'automazione) in Powershell (e possibilmente anche Python) che mi aiutano ad accedere alle API mantenendo le informazioni di credenza protette nello script e / o all'esterno (se memorizzate e recuperate dall'esterno)

Inizialmente, avevo pensato di utilizzare Lastpass, come faccio per i browser web, e in qualche modo recuperare le credenziali in modo sicuro, ma non hanno alcun supporto per nessuna di queste cose.

Ho quindi studiato l'API di protezione dei dati di Windows e la chiave utilizzata per crittografare la password è specifica sia per l'utente sia per la macchina su cui è in esecuzione il codice, ma poiché distribuisco e configuro molto VM e contenitori, e devo accedere a SOME delle API come parte del processo di installazione, non posso usare il metodo.

Quindi come dovrei fare questo?

Ho sentito che possiamo usare keepass o simili, ma come utilizzeresti per mantenere le tue credenziali al sicuro per il tuo codice mentre li recuperi per le tue chiamate API?

Che cosa dovrei fare?

    
posta AdilZ 01.12.2016 - 19:13
fonte

2 risposte

2

Come ha fatto notare Anders che esiste un duplicato, non copre bene il tuo caso che differisce dal fatto che non è la chiave per la crittografia ma la password per l'API.

Puoi utilizzare un altro servizio web che potrebbe offrire password monouso, potrebbe funzionare in questo modo:

  1. Lo script Python dal server A si collega al server B che è "server password"
  2. Invia credenziali al server delle password per autorizzarti
  3. Si recupera una password monouso (o password di 1 giorno) per l'API
  4. Ti connetti dal server A al server C in cui si trova l'API e invii la tua password singola o di 1 giorno
  5. Il server API C controlla con il server B qualunque sia la password da utilizzare
  6. Se le chiavi corrispondono, ottieni una risposta positiva dal server C (API) al server A (client Python).

Dovresti utilizzare SSL (TLS) per tutte le connessioni e verificare se i certificati sono OK per prevenire attacchi MITM. Potresti anche utilizzare certificati utente per autorizzarti con la password.

Puoi estendere la sicurezza di tale sistema in molti modi, ad esempio limitando la password monouso al tuo indirizzo IP dello script Python.

Inoltre, il server API C può memorizzare le password in modo che non vengano recuperate dal server B ogni volta che effettui una chiamata API (idealmente nella RAM).

Il vantaggio per la sicurezza è che hai un controllo completo sul server C e non hai password permanenti, quindi non è necessario cambiarle.

    
risposta data 01.12.2016 - 19:36
fonte
2

Ci sono molti modi per andare oltre. Un breve elenco include:

  • Servizi Web
  • Archiviazione locale crittografata
  • Archiviazione accessibile crittografata condivisa tra macchine virtuali / contenitori

Mentre alcuni di loro hanno molte funzionalità avanzate (auditing, controllo completo, sicurezza molto migliore) spesso TUTTI richiedono una sorta di configurazione. Quindi, dal momento che hai accennato al fatto di aver implementato la distribuzione dei contenitori, ti consigliamo di utilizzare una route intermedia del metodo congelata e di difficile accesso.

Le migliori immagini

Poiché è possibile distribuire facilmente container, questa opzione è di avere un contenitore il cui scopo SOLE è quello di inviare i metodi di autenticazione crittografati per gli script e restituire prima di scomparire che è accessibile solo dalla LAN dei contenitori nel VPL (Virtual Lan privato) in modo che non comunichi MAI con il mondo esterno. A questo punto tutto ciò che si trova nel contenitore dello script è una chiave di decodifica. Nessuno con i tuoi contenitori interni e le macchine docker nella tua zona remota può ascoltarlo. Ciò significherebbe che lo script avrebbe la chiave di decodifica e sarà accessibile solo localmente. Se mai viene compromesso, carica 2 nuove immagini del contenitore e il gioco è fatto.

Pro:

  • Utilizza già un modello che stai implementando
  • solo LAN. Utilizzare un IP interno riservato (intervallo 172.X.X.X) su un controller per comunicare con questa finestra mobile
  • Più punti di sicurezza significa che, se vengono compromesse, è possibile caricare nuove credenziali nelle immagini di finestra mobile appena create e pulite
  • ESTREMAMENTE difficile da compromettere (non la stessa macchina, non lo stesso codice, dovrebbe compromettere ENTRAMBI fine per renderlo utile)
  • Facilmente protetto (chi ha bisogno di SSH su un contenitore, giusto?)
  • Controllo della porta ESATTO (non usare quelli comuni, usa uno veramente oscuro solo per i tuoi scopi)
  • Molti altri

Contro:

  • Due contenitori da mantenere con pezzo cifrato e pezzo di decrittografia
  • Oh no, due caricamenti

Dal momento che questo non va mai fuori rete, nessuno all'esterno della rete può afferrare i pacchetti e tentare di fare passaggi per scoprirlo. L'elenco dei professionisti è decisamente più grande della piccola quantità di impegno che sarebbe necessario per impostare questo dato poiché si tratta di un'immagine del contenitore. Basta caricare il nuovo codice, fatto.

Ora che non ti preoccupi di memorizzare la password sui contenitori con lo script, o il contenitore con la chiave di decrittografia, puoi essere certo che a riposo è quasi impossibile decifrare. Soprattutto se utilizzi TLS con il blocco dei certificati. Ora devi fare il meglio di OGNI mondo, anche se i contenitori in qualche modo finiscono sullo stesso host.

Le uniche persone che potrebbero decifrare a questo punto sarebbero te e chiunque altro sa come è stato impostato esattamente. Tuttavia, perché il collegamento più pericoloso nella catena di Cyber Security è Human (s).

    
risposta data 01.12.2016 - 20:05
fonte

Leggi altre domande sui tag