Devo implementare il controllo dell'accesso sui database all'interno di una rete affidabile?

Question

Devo implementare il controllo dell'accesso sui database all'interno di una rete affidabile?

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

2

Estratto da Redis articolo sulla sicurezza :

Redis is designed to be accessed by trusted clients inside trusted environments. This means that usually it is not a good idea to expose the Redis instance directly to the internet or, in general, to an environment where untrusted clients can directly access the Redis TCP port or UNIX socket.

% di comando diAUTH a parte per un minuto, penso che abbia senso: se il tuo programma è progettato solo per funzionare in condizioni attendibili, perché preoccuparsi di aggiungere l'autenticazione ad esso? Credo che questa sia la via che i micro servizi normalmente adottano. Ogni servizio è libero di comunicare con altri servizi nella stessa rete.

Ma i database (MySQL e simili) hanno una storia diversa? In genere, configurerò più account utente, uno per ogni micro servizio che ha accesso solo al proprio database (sotto l'intero server database). Tuttavia con la rotta che sta prendendo Redis, è ancora necessario?

I controlli di accesso sono ridondanti o Redis meno sicuro rispetto ai database classici?

databases

posta Chris Smith 06.09.2018 - 00:17

fonte

2 risposte

1

Affidabile come? Puoi garantire che un intruso non entrerà mai nella tua rete? No Pertanto, sebbene possa essere considerato affidabile all'interno della tua rete, devi comunque implementare i controlli all'interno di una rete affidabile.

10 anni fa questo era l'approccio: oggi l'approccio migliore è, nulla è considerato attendibile fino a prova contraria.

risposta data 06.09.2018 - 00:53

fonte

Leggi altre domande sui tag databases

Bypassing rate limit sul router domestico Perché è possibile prevenire l'attacco CSRF emettendo token CSRF?

score 5 · Accepted Answer

Sì, "progettato per operare in un ambiente fidato" è una cosa abbastanza comune per i server di back-end, anche se di solito lo si vede come giustificazione per non utilizzare TLS tra i servizi o per i nuovi nodi per unirsi al cluster senza autenticazione. Nel caso Redis, lo stanno usando per giustificare una porta senza autenticazione, sostenendo che un utente malintenzionato dovrebbe essere in grado di eseguire il ping direttamente sulla porta per fare qualsiasi danno. Fondamentalmente, questo è un modo per smistare la responsabilità della sicurezza lontano dal software e dagli ingegneri della rete. Forse sei a tuo agio con quello e forse non lo sei, ma Redis lo sta facendo di testa in modo che tu possa decidere se Redis sia una tecnologia appropriata per i tuoi obiettivi di sicurezza.

Con i database un utente malintenzionato a volte può attaccare il db attraverso la tua app (ad esempio se hai una vulnerabilità SQL Injection), quindi parliamo di Principle of Least Privilege ; cioè ogni nodo ha solo la minima quantità di accesso in lettura / scrittura di cui ha bisogno per fare il suo lavoro per limitare il danno che un nodo compromesso può causare. Così fai la tua due diligence e vedi se l'argomento "progettato per operare in un ambiente fidato" si applica al tuo scenario, ma se fossi l'ingegnere appsec responsabile del tuo prodotto, avresti avuto difficoltà a convincermi che è sicuro ignora il Principio del Privilegio qui.