Come proteggere il servizio Web sulla rete privata?

La risposta breve è "sì - dovresti preoccuparti".

Gli attacchi moderni sono quasi sempre rivolti ai clienti; e una volta che un utente malintenzionato ha un punto di appoggio nella rete, può ruotare su qualsiasi risorsa a cui il cliente abbia accesso. Potrebbe anche essere in grado di "man in the middle" traffico sulla tua LAN; o meglio ancora - ottieni credenziali per gli switch / router e sniffer nella tua rete.

Quindi suggerirei che dovresti usare https (TLS 1.2 o superiore) sul servizio web. Le sessioni dovrebbero anche essere autenticate: per comodità dell'utente potrebbe essere necessario utilizzare un qualche tipo di cookie di sessione o "Single Sign-On" con Kerberos o simili.

Inoltre: il server del database deve essere protetto. C'è qualche motivo per i clienti di connettersi direttamente ad esso? Probabilmente no. Quindi utilizza una specie di firewall davanti al server del database per limitare le connessioni in entrata: solo i server web / applicativi e i server di gestione dei sistemi devono accedere!

I firewall sul perimetro sono importanti ma non sono l'unica difesa di cui hai bisogno. Per lo sfondo, considera alcune delle violazioni di alto profilo che abbiamo visto nelle notizie di recente! L'accesso non è stato ottenuto sfondando un firewall - quasi sempre è stato ottenuto compromettendo un client che è già all'interno della rete.

Dovrei preoccuparmi che avremo un webservice su http senza alcuna autenticazione?

Sì, dovresti !

Your worst enemy could very well be inside your network. We'll show you how to prevent insiders from sharing/destroying your critical data.

Dal momento che il tuo database sarà accessibile da chiunque all'interno della tua rete è meglio averli autenticati, così sarai in grado di determinare chi ha fatto cosa ...

In molte aziende sono disponibili le seguenti best practice per i servizi Web / le applicazioni Web esposte solo all'interno:

• Gli HTTP devono essere applicati per impostazione predefinita. Il costo del supporto di https è trascurabile. L'unica trappola è il certificato SSL, ma dal momento che è interno è possibile creare il proprio ca e distribuire internamente il certificato CA radice sulle macchine.
• AAA (autenticazione, autorizzazione e contabilità). Dovresti sempre avere una sorta di soluzione IAM / UAM per i tuoi servizi web al fine di rispettare il principio meno privilegiato. Se le persone non hanno bisogno di avere accesso ai dati, non lasciarli! Contabilità (log, monitoraggio ...) può fornire dati importanti quando succede qualcosa di brutto. Non dare troppa fiducia ai tuoi dipendenti / colleghi. segnala

Se ci sono utenti che possono raggiungere questi servizi Web interni con lo stesso browser delle richieste verso siti esterni, una visita a una pagina esterna potrebbe attivare richieste al tuo sito interno, ad esempio CSRF. Sebbene l'autore dell'attacco non possa leggere i dati direttamente in questo modo, potrebbe almeno scrivere dati e con un ulteriore attacco rebindung DNS potrebbe persino leggere anche i dati.

Si noti che TLS da solo non sarà di aiuto in questo caso. Ciò che aiuterà è l'uso dei certificati client con TLS o con una password, in modo che solo i client autorizzati (ad esempio gli altri server) possano accedere al servizio web. Suppongo che questi server non eseguiranno browser normali ma solo programmi per accedere solo al servizio Web, in modo che non sia possibile utilizzare il mount di un attacco CSRF con questi programmi lato server.

Se la tua rete privata è invece completamente separata dal resto del sistema (nessun accesso diretto o indiretto) di quanto probabilmente non ti debba preoccupare molto per ora. Si noti tuttavia che le strutture di rete cambiano e che oggi una rete isolata potrebbe essere connessa a un'altra rete domani e spesso senza un'analisi più approfondita delle implicazioni sulla sicurezza.

The "issue" really seemed to be around wasting time to setup TLS for "nothing".

Se puoi garantire che nessuno nella tua rete sia in grado di fiutare il traffico, TLS potrebbe non essere necessario. Naturalmente questo è facile a dirsi, ma difficile da controllare: potrebbero esserci utenti malintenzionati ma più pericolosi sono probabilmente sistemi compromessi. Poiché i tuoi commenti mostrano che gli utenti della tua rete possono accedere a Internet, è molto probabile che prima o poi un sistema client venga compromesso. E a meno che la tua rete sia realmente protetta da tutti i modi di sniffare la password potrebbe probabilmente essere rilevata (vedi anche Quali sono i rischi dell'esecuzione di Team Fundation Server su HTTP? ).

Puoi elaborare i passaggi e replicarli per ciascun server.

Puoi proteggere l'ambiente del tuo server: proibisci l'accesso fisico da parte di persone non autorizzate

Puoi filtrare gli indirizzi IP che sono autorizzati ad accedere al server (forse la finestra di dialogo del server database solo con il server web e gli amministratori pc)

Puoi limitare le porte aperte sui tuoi server e limitare i servizi in esecuzione.

Per ogni servizio è possibile applicare le politiche di sicurezza, ad esempio per il proprio servizio web:

• forza https, forza l'autenticazione con password complessa o certificats
• limite tentativi di connessione
• controlla le connessioni con fail2ban o ohter
• applica i diritti sui tuoi database il più rigorosamente possibile (quale utente può leggere e / o scrivere in quale tabella), proibisci all'utente di connettersi al tuo database dalla rete.

L'idea alla base è applicare le buone politiche su ogni aspetto della tua rete e dei tuoi server.

Nel tuo caso,

the webservice is able to make modification to the data in our databases so if an attacker could access it, he would be able to alter our important data.

sembra importante applicare queste politiche di sicurezza essenziali.