Diritti scrittura su inetpub e directory temp

[alsen]

In contesti applicativi ed aziendali in cui occorre curare la sicurezza del server web una delle policy a cui devo sottostare con le applicazioni INDE è quello di lasciare solo l'accesso in lettura a tutta la directory inetpub (figli compresi) del server IIS e quindi anche alla dir temp delle webapp INDE
Le directory che devono avere accesso in lettura scrittura sono fornite come virtual directory per cui occorrerebbe che INDE tenga conto di questo aspetto quando costruisce il path assoluto della temp della webapp.

[g.lanzi]

L'esigenza è chiara, ma c'è una cosa che mi viene da chiederti. Anzi, forse da chiedere al sistemista.
Ma che vantaggi di sicurezza ci sono?

Mi spiego meglio: se il problema è la sicurezza, allora ciò che si vuole evitare è che un malintenzionato possa intrufolarsi nel web server sfondandolo e prendendo i privilegi di un'applicazione. Una volta fatto questo, se può scrivere dei file allora potrà anche introdurre qualcosa di brutto, diciamo un virus.
Se l'applicazione può scrivere su una cartella, che questa cartella sia dentro la root di iis o fuori, cosa cambia? Tra l'altro nei sistemi operativi microsoft le cartelle speciali come inetpub e program files sono più protette delle altre.

Se il malware viene messo su una cartella esterna o interna a inetpub, non dovrebbe cambiare niente per quanto riguarda la pericolosità del malware stesso.
Perché è l'utente dell'application pool che deve poter scrivere, mica l'utente anonimo della directory.

Non è una critica, intendiamoci, è proprio una domanda sincera derivante da una mia ignoranza. Ci ho pensato, ma non ho trovato vantaggi.

[alsen]

Posso girare la tua osservazione al responsabile della sicurezza per sapere cosa ci risponde.

[g.cassanelli]

Per curiosità... il responsabile della sicurezza che cosa ha risposto ?

[alsen]

Ma sostanzialmente i motivi sono due (ti riassumo brevemente una lunga risposta da un tecnico "molto" MS oriented....)
1. il primo è legato ad una best practice dettata dalla MS stessa che sembra molto scontata, ma di cui non mi ha spiegato i veri motivi tecnici ed io non ho avuto tempo di approfondire.
2. ii secondo sostanzialmente legato ad aspetti di gestione sistemistica della server farm (nel caso in oggetto vi sono circa più di 50 server fisici...): si possono gestire e mappare le vari directory read only e read write a livello di SAN e per tipologia come le directory che contengono solo dati temporanei, soprattutto se sono in load balancing, ed è più semplice gestire configurazioni standard su IIS e quindi ripristinare i vari server a fronte di malfunzionamenti o eventuali aggiornamenti.
Spero di essere stato chiaro.

[g.cassanelli]

Supponevo che il motivo non fosse specificamente e solo la sicurezza, infatti il ragionamento di Giuseppe non fa una grinza.
Grazie Alberto.