Newsgroup: it.comp.lang.visual-basic
Titolo: Gestione sicurezza programma/file-system

Devo scrivere un programma di archiviazione documenti. Vorrei tenere i
files
su disco e gli indici su un database e non tutto su database. Con
questa impostazione il problema è che anche se implemento un sistema
di restrizioni sugli utenti del mio programma chiunque abbia accesso
al disco puo' fare cio' che vuole con i file.
Vorrei sapere se è possibile su win 2000 impostare delle restrizioni
totali
su una cartella in modo che l'utente che si loga non abbia l'accesso
diretto ai files e creare un profilo (account) con tutti i permessi
abilitati per il
mio programma di modo che l'utente mentre usa il mio programma sia
vincolato dalle impostazioni di sicurezza integrate, ma se tenta di
accedere alla
cartella dei files da gestione risorse o shell di dos sia
impossibilitato a farlo.
In poche parole è possibile creare un account utente che funzioni
pero' solo per l'applicazione mentre l'utente in quanto tale agiusca
su un account con
possibilità limitate (nulle) sulla cartella che mi interessa?
Avete altre idee per gestire una situazione del genere?
Grazie Mille
Ciao
Galex


Se il database e' un client-server, come msde, mysql, sql server,
oracle puoi sfruttare l'utente del servizio di database, al quale
assegni i diritti sul filesystem che ti servono.
-- 
ciao, hal

[*hal1961* = 
aldoc...@inwind.it
 in
news:rpnc10tbl6i9eah7p...@4ax.com
] ha scritto:

hal, vabbè che c'hai il dentino avvelenato con Access, ma qui si parla di
documenti in genere (per esempio un file word) dei quali solo il path viene
messo sul database, ma il file con i contenuti resta su disco...

Si si puň fare ...
ogni account di windows nt e/o superiori, quindi niente
95/98/Me, nella gestione dell'utente integra anche dei
permessi su cartelle e file vari.
Puoi quindi creare, tramite api e similari un utente o
anche piů di uno, per esempio per tutti gli utenti che
utilizzano la tua app e fare in modo che quando serve
un dato documento lo vada a pescare dentro quella cartella
alla quale per default avrai dato accesso everyone = nessun
accesso e poi per ogni utente accesso completo o solo
lettura o lettura modifica. Questo vedilo tu.
Attenzione perň che con questa strada ti complichi notevolemente
le cose, perchč devi essere certo che l'utente che sia loggato su
nt non nella tua applicazione, esista nel dominio o comunque nel
pc locale e abbia quei diritti su quella cartella.
Alternativa unica che vedo č quella di creare un account generico
per tutti e quando andari a richiedere quel file, gli dovrai dire "esegui
come", ovvero passare alla shellexecute (se lo permette) anche
il nome dell'utente che vuoi che impersoni quella sessione e relativo
tentativo di apertura file, altrimenti non funziona un tubo.
Ciao
Andrea


Ho avuto il tuo medesimo problema qualche mese fa: sviluppare un DMS
(Document management system) utilizzando un db per la indicizzazione
mantenendo i file nel filesystem, ma alla fine ho desistito.
In effetti è molto piu semplice inserire i file nel db come oggetti Blob (io
ho usato Oracle), la gestione della sicurezza la puoi eseguire completamente
a livello applicativo senza dover ogni volta impostare autorizzazioni ad
utenti / gruppi di W2K, alla fine la mia scelta si è rivelata nettamente
superiore in semplicità ed elasticità, un esempio?: gli utenti di sistema li
posso creare a livello applicativo in modalità completamente svincolata dal
DB o da W2K, questo significa che chi fa amministrazione del sistema
documentale è completamente svincolato dall'amministrazione di dominio,
posso utilizzare l'autenticazione integrata associando un utente applicativo
ad un utente di dominio, etc, ma soprattutto qualsiasi nuova caratteristica
che coinvolge gli utenti è completamente svincolata da W2K.
Un'altro esempio: nel record di indicizzazione del documento ho inserito dei
flag che definiscono se il documento è pubblico, in visione solamente al
gruppo di lavoro emittente, se non è pubblico, se è criptato, chi lo puo
modificare, chi lo puo solo visualizzare; tutto cio l'ho fatto in modo
significativamente semplice, se avessi tenuto i documenti nel file system mi
sarebbe risultato tutto estremamente piu difficile. Usando la criptazione
dei documenti in modo trasparente per l'utente finale, puoi veramente
ottenere un livello di sicurezza superiore, in quanto il documento puo
essere letto solo mediante la tua interfaccia, cio significa che nemmeno i
sistemisti di rete o gli amministratori di dominio potranno accedere ai
documenti in quanto illeggibili, forse da te non è un problema, ma nella mia
azienda siamo in circa 9000/10000 utenti ed i sistemisti di varia natura
sono centinaia (Help desk, Sysadmin, etc)
Se ti spaventa inserire i documenti nel db ti posso dire che ho eseguito
alcuni test di performance in scrittura conetmporanea: ho continuato ad
inserire 80 documenti al minuto contemporaneamente da tre postazioni (per
circa 250 documenti minuto: circa 15000 documentui ora) per diverse ore
,sono arrivato ad inserire 120.000 documenti in una giornata di lavoro senza
il minimo problema, si trattava di documenti estremamente contenuti.
Ripescare un documento comporta lo stesso impiego di tempo che copiarlo da
file system: documenti da 7/8 Mbyte nell'arco di 10/20 secondi in base
all'impegno della rete (Tieni presente che il mio db stava a 400 Km di
distanza in una lan di tutto rispetto).
In sintesi prima di partire fai bene le tue considerazioni, è meglio
sbattersi un po all'inizio e coglierne i frutti in seguito