Newsgroup: it.comp.java
Titolo: Progetto WEB

Vi chedo un consiglio.
Lavoro in un'azienda media (300 utenti e 6-7 persone all'IT) con un 550 e:
-parte di ACG 10%
-e un sacco di custom RPG 80%
-e un poco di Java batch 5%
-e un poco di Java Web 5%
Tutto in LAN (nulla di pubblico su internet).
Il sito ufficiale dell'azienda è da un provider, in PHP e solo informativo.
Si richede di integrare il sito ufficiale con una sezione riservata solo a
certi clienti,
per permettere essenzialmente:
-la visione dell'estratto conto
-l'inserimento di ordini (solo su pochi articoli "selezionati", perchè in
totale sono 100.000)
-consultazione stato avanzamento ordini e commesse
E' il mio primo progetto WEB pubblico.
Alcuni dei miei dubbi sono:
-mi metto il sito pubblico in casa su un server in DMZ?
-non avendo skill interno su PHP mi conviene staccarmi, per la sola sezione
 riservata, e dalla home page del sito ufficiale finire con un link su un 
application
 server WebSphere java (lo skill su java c'è)?
-questo server in DMZ come lo faccio colloquiare col DB2 dell'AS400?
 (pensavo ad una porta aperta sul firewall, dalla DMZ verso l'AS400, ed
andare via jdbc, ma se
 mi bucano il server in DMZ potrebbero lavorare di SQL sui file di
produzione)
-per evitare di mettere in linea l'AS400 metto un "SQL server" in DMZ e
aggiorno quello, dalla
 LAN verso la DMZ direttamente dall'AS400 (però ogni quanto)?
-cosa altro non sto considerando, che mi potrebbe fare molto male in futuro?
-faccio fare tutto ad una software house esterna (cosa poco accettabile da
chi ci paga)?
Ciao e grazie, Ferro. 

 chi ci paga)?
Se vuoi rispondo in dettaglio alle tue domande precedenti, ma considera 
un fattore: creare una applicazione solida e sicura non si improvvisa, e 
la manutenzione ha un suo costo.
Sicuro che alla fin fine non spenderete di più a farvelo in casa?
Ciao,
Paolo

 Sicuro che alla fin fine non spenderete di più a farvelo in casa?
Quello che dici non è da sottovalutare e ci ho già pensato.
Ma data la forte integrazione tra RPG e Java, la particolarità del DB,
le 1000 eccezioni non previste che nasceranno su cammino, e non da
meno la stabilità "politica" delle cose, opto per farlo in casa.
Non siamo proprio a zero.
Abbiamo skill differenziati all'interno. Non è una cosa fuori dalla
nostra portata.
Solo che non siamo ferratissimi, soprattutto sull'aspetto sicurezza.
Ciao e grazie.
Ferro. 

 Solo che non siamo ferratissimi, soprattutto sull'aspetto sicurezza.
Ok, è chiaro.
Rispondo quindi alle tue domande precedenti:
 > -mi metto il sito pubblico in casa su un server in DMZ?
Visto quello che hai appena detto direi di sì.
Considera però che la manutenzione porta via tempo e lavoro, ma questo 
già lo sai.
 > -non avendo skill interno su PHP mi conviene staccarmi, per la sola
 > sezione riservata, e dalla home page del sito ufficiale finire con
 > un link su un application server WebSphere java (lo skill su java
 > c'è)?
Lascia perdere PHP, il fatto che il sito sia fatto con questo linguaggio 
  è ininfluente.
Semplicemente nel sito metterai un link che porterà alla (pagina di 
login della) tua applicazione.
 > -questo server in DMZ come lo faccio colloquiare col DB2 dell'AS400?
 >  (pensavo ad una porta aperta sul firewall, dalla DMZ verso l'AS400,
 > ed andare via jdbc, ma se mi bucano il server in DMZ potrebbero
 >  lavorare di SQL sui file di produzione)
No, assolutamente: la produzione va isolata.
Usa un database di mezzo, questo sì, e una procedura che a intervalli 
schedulati prenda i dati necessari dal gestionale (non direttamente, 
tramite esportazione) e li porti sul db.
Io di solito per fare questo uso i file csv, che con AS400 (e non solo) 
sono ben gestiti: una procedura schedulata (di solito ogni 12 ore) 
esporta i dati necessari sui rispettivi file che vengono lasciati in una 
directory condivisa. Dopo n ore parte uno script che via ssh sposta i 
file e lancia una classe java che usando csvjdbc 
(
http://csvjdbc.sourceforge.net/
) carica i file sul db usato 
dall'applicazione web.
 > -per evitare di mettere in linea l'AS400 metto un "SQL server" in DMZ
 > e aggiorno quello, dalla LAN verso la DMZ direttamente dall'AS400
 > (però ogni quanto)?
Ribadisco quanto detto sopra: togli il "direttamente" dalla frase 
precedente. ;)
Per essere ragionevolmente sicuri bisogna evitare di avere un server 
esposto sul web che sia in grado di comunicare con la lan protetta.
Sui tempi dipende dalle vostre esigenze e da quanto carico di lavoro 
comporta esportare i dati da AS400. Noi di solito proponiamo di fare le 
esportazioni a ora di pranzo (12:30-14:30) quando in pochi ci lavorano e 
dopo le dieci di sera.
 > -cosa altro non sto considerando, che mi potrebbe fare molto male in
 > futuro?
Finché si lavora in sola lettura (pubblicazione da gestionale a web) non 
ci sono grossi problemi, quando si inizia con l'inserimento di dati 
(ordini, nel tuo caso) le possibili problematiche aumentano di almeno un 
ordine di grandezza.
Integrando con una verifica manuale da parte di un operatore i rischi si 
riducono parecchio. A livello di codice si tratta di poco: un flag che 
indica che l'ordine è arrivato dal web e va verificato e attivato.
 > -faccio fare tutto ad una software house esterna (cosa poco
 > accettabile da chi ci paga)?
Fatelo pure voi, come dicevamo, ma se conoscete qualcuno in gamba un 
paio di giorni di consulenza possono aiutare parecchio (e costano poco).
Ciao,
Paolo

 di giorni di consulenza possono aiutare parecchio (e costano poco).
Hai ragione.
Ciao e super grazie.
Ferro. 

 Ciao e super grazie.
Neanche dirlo! :)
Paolo

Un'ultima domanda. Giusto per didattica.
Ma se io dovessi dare un servizio aggiornato in tempo reale?
La regola, super sicura per carità, dell'aggiornamento in polling dalla LAN
alla DMZ non sarebbe più sufficiente.
Vedi ad esempio lo stato avanzamento ordine.
Se uno lo volesse in tempo reale?
Mi volete dire che nessuno fa di queste cose?
Forse si potrebbe gestire una replicazione real time del DB, sempre dalla
LAN verso la DMZ, in  modo da avere il DB nella DMZ aggiornatissimo,
ma pur sempre non in produzione.
Che ne pensate?
Ciao e grazie.
Ferro. 

 Che ne pensate?
Che si può fare, ma con oculatezza.
Tutti i db più consistenti (Oracle, PostGres, SQL Server) hanno un 
sistema di mirroring/sincronizzazione che permette cose di questo tipo.
Sinceramente però ci starei un po' attento, usare lo stesso db (inteso 
come versione e configurazione) sia pubblico che privato fornisce delle 
informazioni potenzialmente molto utili a un attaccante.
Per fare un esempio: se hai due SQL Server che comunicano in tempo 
reale, e uno dei due (quello pubblico) viene sputtanato per una 
vulnerabilità o un virus, chi/cosa/quando evita che lo sputtanamento dei 
dati si propaghi in senso opposto?
Ricordo che qualche hanno fa, quando ci fu l'"impestazione" del worm di 
SQL Server, il virus entrò in un nostro server di produzione e riuscì a 
far saltare tutti i db installati sulle macchine degli sviluppatori (che 
erano in una lan con policy molto restrittive, senza neanche accesso ad 
internet).
Forse ora le cose son cambiate, sinceramente non lo so.
Ciao,
Paolo

 informazioni potenzialmente molto utili a un attaccante.
Si, conosco questi sistemi di replica, ma non so se siano configurabili
da un lato verso l'altro, piuttosto che in modo bidirezionale. Ma per adesso
non è un mio problema.
Perdonami, ma ti faccio una ultima domanda e poi mi puoi fare la fattura :-)
Molte soluzioni che ho visto, lato WEB, usavano configurare un solo utente
su SQLServer, con cui fare le connessioni al DB e con cui eseguire l'SQL 
necessario.
Gli utenti WEB invece non venivano profilati lato SQLServer, ma venivano 
creati come
record in una tabella UTENTI, con una password più o meno in chiaro.
Quindi l'unico utente SQLServer che fa la connessione al DB è un utente che 
ha diritti
di lettura e scrittura e esecuzione (per eventuali UDF e SP) sugli tutti gli 
oggetti
dell'applicazione. l'unica accortezza era quella di non mettere questo 
utente con gli stessi
diritti di SA.
E seconda dell'utente WEB e dei diritti definiti a livello di programma, e 
non
a livello di SQLServer, venivano dati i vari permessi o le varie negazioni.
Arrivo alla domanda: dove si scrivono le credenziali di questo utente 
SQLServer per averle
disponibili runtime e poter fare la connessione al DB????
Non penso proprio sui famosi .properties o roba del genere!!!!
Una cosa che pensavo io era quella di configurare un datasource lato
application server (AS), con utente e pwd scolpiti nella roccia lato AS.
Ma è prassi?
Ciao e ancora grazie.
Ferro. 

 application server (AS), con utente e pwd scolpiti nella roccia lato AS.
Scusa, che vuol dire "scolpiti nella roccia"? ;)
 > Ma è prassi?
Se ho capito bene quello che vuoi dire: sì.
Ciao,
Paolo

 Scusa, che vuol dire "scolpiti nella roccia"? ;)
Vuol dire scritti a livello di application server.
Non su un XML gestito da me.
Probabilmente l'application lo scriverą su un XML suo, nei posti che sa lui,
senza l'uso di un file XML gestito direttamente da me (almeno con WebSphere
lo posso fare).
Mi spiego?
Se il file XML gestito da me contenesse l'utente e la pwd del profilo 
SQLServer
da usare nella connessione, dovrebbe comunque essere aperto in lettura
per l'applicativo web.
E questo, se non sbaglio, vuol dire essere apribile in lettura anche da un 
utente
remoto (che magari si scarica anche il file e poi te lo manda per email come 
sfida).
Mi spiego?
Sono un po' confuso.
Ciao e grazie.
Ferro. 

 Sono un po' confuso.
;)
il file che contiene i parametri di connessione al database "pubblico" è 
sul server in DMZ e non contiene altre informazioni pericolose.
Male che vada se uno riesce a leggerlo (ma non è pubblico e scaricabile 
facilmente come sembra emergere dalla tua frase) danneggia solo il db web.
Il file di configurazione per la connessione al database DB2 del 
gestionale E a quello pubblico è invece sul server "sicuro", nella LAN.
E' l'applicazione (fatta come voi valuterete opportuno) di 
importazione/esportazione quella che ha i parametri "pericolosi", in 
grado di connettersi al gestionale, e questa risiede e gira su un server 
in LAN, non nella DMZ.
Ciao,
Paolo

 Paolo
Chiarissimo.
Davvero grazie.
Sei stato getilissimo.
Ciao e a buon rendere.
Ferro. 

 Sei stato getilissimo.
Allora posso far partire la fattura? ;))

 Allora posso far partire la fattura? ;))
Faccio come il mio capo.
"Per cosě poco???? Guardi che queste cose si sapevano e facevano giŕ anni 
fa!!!!"
Scherzo.
Grazie ancora.
Ciao, Ferro.