Quando si scrive un'API che si collega al database, quali informazioni sono sensibili e dovrebbero essere protette?

Question

Quando si scrive un'API che si collega al database, quali informazioni sono sensibili e dovrebbero essere protette?

#1 da (2 voti)
#2 da (1 voti)

1

Sono in un team che sta scrivendo un'API .NET Core per la manutenzione di un'applicazione desktop. Questa applicazione usava gestire la propria connessione al database attraverso un OracleConnection e tutti i valori usati per connettersi al database, inclusa la password, erano codificati nel codice (sì, lo so).

Attualmente stiamo spostando questi valori in un luogo sicuro, ma la mia domanda è: quali valori dobbiamo nascondere? Ovviamente la password dovrebbe essere su questa lista. Ma dovremmo nascondere anche l'host, il nome del servizio, i nomi dei pacchetti, la porta, il nome del servizio o l'ID utente? Qualche cosa non su questa lista che dovrebbe assolutamente essere nascosta?

.net sensitive-data-exposure

posta kleineg 02.02.2017 - 23:01

fonte

2 risposte

Leggi altre domande sui tag .net sensitive-data-exposure

Sono un idiota. Hai bisogno di aiuto con JavaScript "codebreaking" e analisi [duplicato] Distanza tra il sito principale e il sito di ripristino di emergenza

score 2 · Answer 1

La vera risposta è che dipenderà dai requisiti di sicurezza del client e dal loro modello di minaccia, ma ti darò ciò che ritengo siano le migliori pratiche.

Le credenziali effettive del database non dovrebbero mai lasciare il server del database. L'applicazione desktop chiamerebbe il servizio e il servizio chiamerebbe il database. Questo ti permetterà di mettere il tuo server di database in una parte isolata della rete, e ridurrà la tua superficie di attacco.
Ogni utente deve avere credenziali univoche per il servizio. Questo è assolutamente un requisito. Non ha senso fare nulla se non si dispone di accessi unici.
Anche la comunicazione con il server dovrebbe essere crittografata. Usa SSL. Anche se si tratta di un'applicazione intranet.
Un sistema SSO (single sign-on) è ideale per la gestione delle credenziali univoche. Pensa a Active Directory, se ti trovi in un ambiente Windows.
Se un sistema SSO non è possibile, le password dovrebbero essere crittografate su disco. Ci sono molti modi per farlo. Se possibile, utilizzare un portachiavi integrato nel sistema operativo o un'altra soluzione preesistente che è stata testata professionalmente. Non consiglierei di crittografare qualcosa di più della password, dal momento che può potenzialmente aprire più attacchi sul cryptosystem. Tutti i dettagli del server (nome host, porta, ecc.) Saranno visibili a chiunque abbia accesso alla rete o comunque esegua netstat sulla macchina.

Spero che ti aiuti.

score 1 · Answer 2

Per un'applicazione interna per autenticare una connessione al database, il cliente dovrà ovviamente conoscere il nome e la porta del server. Ma qualsiasi informazione che presenti agli utenti ha il potenziale per semplificare il lavoro di un aggressore. Se i tuoi utenti non ne hanno bisogno, prova a non darglielo.

Scopri quali tipi di meccanismi di autenticazione sono disponibili che non implicano che il tuo cliente debba memorizzare o gestire nomi utente e password. Per una macchina Windows che si connette a Oracle, prova ad aggiungere Integrated Security=yes nella stringa di connessione. Ciò trasmetterà l'identità e l'autorità dell'utente al server e non sarà necessario memorizzare nulla sul client. Ovviamente, è necessario assicurarsi che gli utenti siano membri di gruppi che dispongono dei diritti di accesso necessari per connettersi al database e utilizzarlo. Ma puoi gestire tutto ciò tramite Active Directory e non dovresti inserire i nomi utente nella tua app o nel tuo database Oracle.