Distingue tra chiamate di rete interne ed esterne

2

Possediamo un'API REST che viene utilizzata dalle macchine sulla nostra rete aziendale, pertanto al momento non abbiamo alcuna autenticazione. Il piano è di esporre l'API a Internet utilizzando Apigee, mentre esistono anche i nostri utenti della rete interna. Quali sono i metodi standard per sapere in modo sicuro se è stata effettuata una chiamata all'interno della rete aziendale o all'esterno?

L'autenticazione basata su IP è un metodo sicuro per sapere se è stata effettuata una chiamata API da macchine su una rete interna? Le nostre API sono scritte utilizzando il framework .NET e sono in esecuzione su computer Windows Server 2008.

    
posta Gaurav Waghmare 02.04.2018 - 12:24
fonte

3 risposte

1

Is IP based authentication a secure method to know if an API call was made from machines on internal network?

Che cosa intendi per sicuro? Cosa succede se una macchina all'interno della rete viene attaccata e utilizzata come proxy? Accesso illimitato alle chiamate API?

L'API REST richiede autenticazione e autorizzazione prima che tu possa fingere di avere una vera sicurezza. Naturalmente quelli devono essere fatti correttamente, ma questo è all'estremità inferiore di quello che ti serve.

    
risposta data 02.04.2018 - 12:39
fonte
1

In linea generale, è sconsigliabile provare a controllare l'accesso a un servizio di rete con mezzi così vaghi. Nella pratica di pentesting, non è insolito che l'attaccante sia in grado di possedere, ad esempio, una stampante o macchina da caffè in rete e usarlo come trampolino di lancio per eseguire richieste sul proprio servizio con privilegi di "rete locale". A un livello più filosofico, se stai cercando di dividere i clienti come "locali" e "stranieri", significa che non hai fatto un'analisi corretta di chi ha bisogno di quale tipo di accesso. I sistemi messi insieme senza un'analisi sistematica tendono ad errare al lato dell'aspetto accessibilità della sicurezza dei dati, e tali errori possono portare a un fallimento, a volte massiccio, dell'aspetto riservatezza .

Se stai sviluppando quello che è essenzialmente un singolo servizio, ma con più accesso concesso agli agenti della tua organizzazione rispetto agli anonimi su Internet, dovresti impostare un meccanismo di autenticazione e distribuire password, certificati client, token OTP, o qualche altro mezzo di identificazione sicura per le persone con necessità specifiche di accedere ai dati che non intendete rendere accessibili pubblicamente dai randos. Nel contesto dei servizi basati su Windows, i tuoi utenti probabilmente avranno già voci in Active Directory e potrebbero essere stati configurati per autenticarsi da esso quando accedono alle loro workstation. Se la tua analisi suggerisce che questo livello di autenticazione è appropriato per il tuo servizio, potresti, ad esempio, configurare il tuo server web per richiedere che i browser degli utenti presentino i ticket Kerberos quando accedono al tuo servizio e determinare il livello di accesso appropriato in base all'identità dell'utente in questo modo.

Se l'analisi mostra che quello che stai cercando di fare è meglio modellato come due servizi distinti, potresti preferire impostare un servizio per l'accesso pubblico, e un altro per la rete locale, magari con una sorta di regolare processo di migrazione dei dati tra i loro datastore. Sarai comunque ben consigliato di autenticare le persone che consideri "locali" prima di fornire loro dati non pubblici o accettare comandi da loro che non vorresti accettare da randos, naturalmente.

    
risposta data 03.04.2018 - 06:00
fonte
1

Risponderò rigorosamente solo a questa domanda:

Is IP based authentication a secure method to know if an API call was made from machines on internal network?

La risposta è SI, gli indirizzi IP di origine possono essere utilizzati per convalidare in modo affidabile il traffico originato dalla LAN con i seguenti avvertimenti:

  • L'altra API è accessibile solo tramite TCP. (L'indirizzo di spoofing IP dell'origine UDP è più facilmente raggiunto a causa della natura stateless del protocollo. Tale spoofing è molto meno pratico su TCP)
  • Non hai gateway esposti che consentano a qualcuno di ruotare nella tua LAN, come un proxy aperto, un sistema di accesso remoto accessibile al pubblico, ecc.
risposta data 03.04.2018 - 06:34
fonte

Leggi altre domande sui tag