Spazio di memorizzazione isolato
Per le applicazioni desktop, lo spazio di memorizzazione isolato è un meccanismo di archiviazione dati che offre isolamento e sicurezza definendo modi standardizzati di associare il codice ai dati salvati. La standardizzazione offre anche altri vantaggi. Gli amministratori possono utilizzare strumenti in grado di modificare l'archiviazione isolata per configurare lo spazio di archiviazione dei file, per impostare i criteri di sicurezza e per eliminare dati inutilizzati. Con lo spazio di memorizzazione isolato, non occorre più fornire al codice percorsi univoci per individuare posizioni sicure nel file system e i dati sono protetti da altre applicazioni che dispongono esclusivamente dell'accesso allo spazio di memorizzazione isolato. Non è necessario specificare informazioni hardcoded che indicano il percorso dell'area di archiviazione di un'applicazione.
Importante
Lo spazio di memorizzazione isolato non è disponibile per le app di Windows 8.x Store. Al contrario, usare le classi di dati dell'applicazione negli spazi dei nomi Windows.Storage
inclusi nell'API di Windows Runtime per archiviare dati e file locali. Per altre informazioni, vedere Dati dell'applicazione nel Centro per sviluppatori Windows.
Raggruppamenti e archivi dati
Quando un'applicazione memorizza dati in un file, il nome del file e il percorso di archiviazione devono essere scelti attentamente, per ridurre la possibilità che il percorso di archiviazione venga individuato da un'altra applicazione e sia quindi soggetto a danneggiamenti. Senza un sistema standard in grado di gestire questi problemi, può risultare complesso improvvisare tecniche che riducano i conflitti di archiviazione e i risultati conseguiti potrebbero non essere affidabili.
Con l'archiviazione isolata i dati vengono sempre isolati in base all'utente o all'assembly. L'identità dell'assembly viene determinata da credenziali quali l'origine o il nome sicuro. I dati possono essere isolati anche in base al dominio applicazione, utilizzando credenziali analoghe.
Quando si utilizza lo spazio di memorizzazione isolato, le applicazioni salvano i dati in un raggruppamento dati univoco, associato ad alcuni aspetti dell'identità del codice quali l'autore o la firma. Il contesto dati è un'astrazione, non è un percorso di archiviazione specifico. È costituito da uno o più file di archiviazione isolata, denominati archivi, contenenti i percorsi di directory in cui sono effettivamente memorizzati i dati. È possibile, ad esempio, che a un'applicazione sia associato un raggruppamento dati e che una directory del file system implementi l'archivio in cui sono effettivamente conservati i dati dell'applicazione. Nell'archivio è possibile salvare qualsiasi tipo di dati, dalle preferenze utente allo stato dell'applicazione. Per lo sviluppatore, la posizione del contesto dati è trasparente. Gli archivi solitamente risiedono sul client, ma un'applicazione server può utilizzare gli archivi isolati per archiviare le informazioni impersonando l'utente sta funzionando. Tramite l'archiviazione isolata è inoltre possibile memorizzare informazioni su un server con un profilo utente comune, in modo che sia possibile spostare le informazioni insieme all'utente.
Quote per lo spazio di memorizzazione isolato
Una quota è un limite allo spazio che può essere utilizzato per l'archiviazione isolata. La quota definisce i byte di spazio su file, l'overhead associato alla directory e altre informazioni dell'archivio. Lo spazio di memorizzazione isolato utilizza le quote di autorizzazione, ovvero limiti di archiviazione impostati utilizzando gli oggetti IsolatedStoragePermission . Se si tenta di scrivere dati oltre il limite definito dalla quota, verrà generata un'eccezione IsolatedStorageException . I criteri di protezione , modificabili tramite lo strumento .NET Framework Configuration (Mscorcfg.msc), determinano le autorizzazioni concesse al codice. Il codice a cui è stata concessa IsolatedStoragePermission è limitato all'utilizzo di spazio di archiviazione non superiore a quanto consente la proprietà UserQuota . Poiché tuttavia il codice può eludere le quote presentando diverse identità utente, le quote rappresentano per il codice un limite indicativo piuttosto che un limite di protezione.
Le quote non si applicano agli archivi roaming. Perché il codice possa farne uso, occorre pertanto un livello di autorizzazione leggermente superiore. I valori di enumerazione AssemblyIsolationByRoamingUser e DomainIsolationByRoamingUser specificano un'autorizzazione a utilizzare lo spazio di memorizzazione isolato per un utente mobile.
Accesso sicuro
L'utilizzo dell'archiviazione isolata consente alle applicazioni parzialmente attendibili di archiviare i dati in modo controllato dal criterio di sicurezza del computer. Questa caratteristica si rivela particolarmente utile per l'esecuzione controllata di componenti scaricati. I criteri di sicurezza concedono raramente questo tipo di autorizzazione del codice quando si accede al file system utilizzando meccanismi di I/O standard. Tuttavia, per impostazione predefinita, all'esecuzione di codice dal computer locale, da una rete locale o da Internet è concesso il diritto di utilizzare lo spazio di memorizzazione isolato.
Gli amministratori possono limitare lo spazio di archiviazione isolata a disposizione di un'applicazione o di un utente, in base a un appropriato livello di attendibilità. Gli amministratori possono inoltre rimuovere completamente i dati persistenti di un utente. Per creare o accedere a spazio di memorizzazione isolato è necessario che il codice disponga di un'autorizzazione IsolatedStorageFilePermission appropriata.
Per accedere all'archiviazione isolata, il codice deve disporre di tutti i diritti nativi del sistema operativo della piattaforma. È necessario soddisfare gli elenchi di controllo di accesso (ACL, Access Control List) che determinano quali utenti dispongono dei diritti per l'utilizzo del file system. Le applicazioni .NET dispongono già dei diritti del sistema operativo per accedere allo spazio di memorizzazione isolato, a meno che non eseguano la rappresentazione (specifica della piattaforma). In questo caso l'applicazione deve verificare che l'identità dell'utente impersonato disponga di appropriati diritti del sistema operativo per accedere all'archiviazione isolata. Tale tipo di accesso consente al codice in esecuzione o che viene scaricato dal Web di leggere e scrivere in un'area di archiviazione relativa a un particolare utente.
Per controllare l'accesso allo spazio di memorizzazione isolato, Common Language Runtime utilizza gli oggetti IsolatedStorageFilePermission . Ogni oggetto dispone di proprietà che specificano i seguenti valori:
Utilizzo consentito, che indica il tipo di accesso consentito. I valori sono i membri dell'enumerazione IsolatedStorageContainment . Per ulteriori informazioni su questi valori, vedere la tabella nella sezione successiva.
Quota di archiviazione, come illustrato nella sezione precedente.
Il runtime richiede l'autorizzazione IsolatedStorageFilePermission la prima volta che il codice tenta di aprire un archivio. Decide quindi se concedere o meno questa autorizzazione in base al grado di attendibilità del codice. Se l'autorizzazione viene concessa, i valori di quota di archiviazione e di utilizzo consentito verranno determinati dai criteri di sicurezza e dalla richiesta avanzata dal codice per IsolatedStorageFilePermission. I criteri di sicurezza vengono impostati mediante lo strumento .NET Framework Configuration (Mscorcfg.msc). Tutti i chiamanti nello stack di chiamate vengono controllati per garantire che ciascun chiamante disponga almeno dell'utilizzo consentito appropriato. Il runtime controlla inoltre la quota imposta al codice che ha aperto o creato l'archivio in cui si deve salvare il file. Se le condizioni vengono soddisfatte, verrà concessa l'autorizzazione. La quota viene controllata nuovamente ogni volta che un file viene scritto nell'archivio.
Non occorre che il codice dell'applicazione richieda l'autorizzazione, perché Common Language Runtime concederà qualsiasi IsolatedStorageFilePermission appropriato in base ai criteri di sicurezza. Tuttavia, esistono buone ragioni per richiedere le autorizzazioni specifiche necessarie all'applicazione, comprese IsolatedStorageFilePermission.
Utilizzo consentito e rischi di sicurezza
L'utilizzo consentito specificato da IsolatedStorageFilePermission determina il grado in cui al codice verrà consentito di creare e utilizzare lo spazio di memorizzazione isolato. Nella tabella riportata di seguito viene illustrato come l'utilizzo consentito specificato nell'autorizzazione corrisponde ai tipi di isolamento. Vengono inoltre riepilogati i rischi di sicurezza associati a ciascun utilizzo consentito.
Utilizzo consentito | Tipi di isolamento | Impatto sulla sicurezza |
---|---|---|
None | Non è consentito alcun utilizzo dell'archiviazione isolata. | Non vi è impatto per la sicurezza. |
DomainIsolationByUser | Isolamento in base all'utente, al dominio e all'assembly. Ciascun assembly presenta un archivio secondario all'interno del dominio. Gli archivi che utilizzano questa autorizzazione vengono isolati in modo implicito dal computer. | Questo livello di autorizzazione lascia le risorse vulnerabili all'utilizzo eccessivo non autorizzato, nonostante la resistenza offerta dall'adozione delle quote. Tale abuso viene definito denial of service (negazione del servizio). |
DomainIsolationByRoamingUser | Come DomainIsolationByUser , ma l'archivio viene salvato in un percorso di cui verrà effettuato il roaming se i profili degli utenti mobili sono attivati e le quote non sono applicate. |
Poiché le quote devono essere disabilitate, le risorse di archiviazione sono più soggette ad attacchi denial of service. |
AssemblyIsolationByUser | Isolamento in base all'utente e all'assembly. Gli archivi che utilizzano questa autorizzazione vengono isolati in modo implicito dal computer. | A questo livello vengono attivate le quote, per offrire una maggior resistenza agli attacchi denial of service. Lo stesso assembly in esecuzione in un altro dominio può accedere a questo archivio, rendendo possibile la fuga di informazioni tra applicazioni. |
AssemblyIsolationByRoamingUser | Come AssemblyIsolationByUser , ma l'archivio viene salvato in un percorso di cui verrà effettuato il roaming se i profili degli utenti mobili sono attivati e le quote non sono applicate. |
Come AssemblyIsolationByUser , ma senza quote. Aumenta il rischio che i servizi vengano attaccati. |
AdministerIsolatedStorageByUser | Isolamento in base all'utente. In genere questo livello di autorizzazione viene utilizzato solo per gli strumenti di debug e di amministrazione. | L'accesso con questa autorizzazione consente al codice di visualizzare o rimuovere i file o le directory dell'archiviazione isolata di un utente, indipendentemente dall'isolamento dell'assembly. I rischi includono, tra l'altro, la fuga di informazioni e la perdita di dati. |
UnrestrictedIsolatedStorage | Isolamento in base a tutti gli utenti, i domini e gli assembly. In genere questo livello di autorizzazione viene utilizzato solo per gli strumenti di debug e di amministrazione. | Questa autorizzazione crea la possibilità che vengano compromessi tutti gli archivi isolati di tutti gli utenti. |
Sicurezza dei componenti dello spazio di memorizzazione isolato rispetto ai dati non attendibili
Questa sezione si applica ai framework seguenti:
- .NET Framework (tutte le versioni)
- .NET Core 2.1+
- .NET 5+
.NET Framework e .NET Core offrono uno spazio di memorizzazione isolato come meccanismo per rendere persistenti i dati per un utente, un'applicazione o un componente. Si tratta di un componente legacy progettato principalmente per scenari di sicurezza dall'accesso di codice ormai deprecati.
È possibile usare varie API e strumenti dello spazio di memorizzazione isolato per leggere i dati oltre i limiti di attendibilità. Ad esempio, la lettura dei dati da un ambito a livello di computer può aggregare i dati di altri account utente possibilmente meno attendibili nel computer. I componenti o le applicazioni che leggono da ambiti dello spazio di memorizzazione isolato a livello di computer devono essere consapevoli delle conseguenze della lettura di questi dati.
API sensibili alla sicurezza che possono leggere dall'ambito a livello di computer
I componenti o le applicazioni che chiamano una delle API seguenti leggono dall'ambito a livello di computer:
- IsolatedStorageFile.GetEnumerator, passando un ambito che include il flag IsolatedStorageScope.Machine
- IsolatedStorageFile.GetMachineStoreForApplication
- IsolatedStorageFile.GetMachineStoreForAssembly
- IsolatedStorageFile.GetMachineStoreForDomain
- IsolatedStorageFile.GetStore, passando un ambito che include il flag IsolatedStorageScope.Machine
- IsolatedStorageFile.Remove, passando un ambito che include il flag
IsolatedStorageScope.Machine
Lo strumento per lo spazio di memorizzazione isolato storeadm.exe
è interessato se viene chiamato con l'opzione /machine
, come illustrato nel codice seguente:
storeadm.exe /machine [any-other-switches]
Lo strumento per lo spazio di memorizzazione isolato viene fornito come parte di Visual Studio e .NET Framework SDK.
Se l'applicazione non prevede chiamate alle API precedenti o se il flusso di lavoro non implica la chiamata a storeadm.exe
in questo modo, questo documento non è applicabile.
Impatto in ambienti multiutente
Come accennato in precedenza, l'impatto sulla sicurezza di queste API deriva dal fatto che i dati scritti da un ambiente di trust vengono letti da un ambiente di trust diverso. Lo spazio di memorizzazione isolato usa in genere una delle tre posizioni per leggere e scrivere dati:
%LOCALAPPDATA%\IsolatedStorage\
: ad esempio,C:\Users\<username>\AppData\Local\IsolatedStorage\
, per l'ambitoUser
.%APPDATA%\IsolatedStorage\
: ad esempio,C:\Users\<username>\AppData\Roaming\IsolatedStorage\
, per l'ambitoUser|Roaming
.%PROGRAMDATA%\IsolatedStorage\
: ad esempio,C:\ProgramData\IsolatedStorage\
, per l'ambitoMachine
.
Le prime due posizioni sono isolate per utente. Windows garantisce che diversi account utente nello stesso computer non possano accedere alle cartelle del profilo utente dell'altro. Due diversi account utente che usano gli archivi User
o User|Roaming
non vedranno i dati dell'altro e non potranno interferire con i dati dell'altro.
La terza posizione viene condivisa da tutti gli account utente del computer. I diversi account possono leggere e scrivere in questa posizione e possono visualizzare i dati degli altri.
I percorsi precedenti possono differire in base alla versione di Windows in uso.
Si consideri ora un sistema multiutente con due utenti registrati Mallory e Bob. Mallory ha la possibilità di accedere alla directory del proprio profilo utente C:\Users\Mallory\
e può accedere alla posizione di archiviazione condivisa a livello di computer C:\ProgramData\IsolatedStorage\
. Non può accedere alla directory del profilo utente di Bob C:\Users\Bob\
.
Se Mallory vuole attaccare Bob, potrebbe scrivere i dati nella posizione di archiviazione a livello di computer, quindi tentare di influenzare Bob affinché legga dall'archivio a livello di computer. Quando Bob esegue un'app che legge da questo archivio, l'app funzionerà sui dati inseriti da Mallory, ma nel contesto dell'account utente di Bob. Il resto di questo documento contempla vari vettori di attacco e i passaggi che le app possono eseguire per ridurre al minimo il rischio di questi attacchi.
Nota
Per poter eseguire un attacco di questo tipo, Mallory richiede:
- Un account utente nel computer.
- Possibilità di inserire un file in un percorso noto del file system.
- Conoscenza del fatto che Bob, a un certo punto, eseguirà un'app che tenterà di leggere questi dati.
Questi non sono vettori di minaccia che si applicano agli ambienti desktop standard per utente singolo come i PC domestici o le workstation aziendali con un solo dipendente.
Elevazione dei privilegi
Un attacco di elevazione dei privilegi si verifica quando l'app di Bob legge il file di Mallory e tenta automaticamente di eseguire alcune azioni in base al contenuto del payload. Si consideri un'app che legge il contenuto di uno script di avvio dall'archivio a livello di computer e passa tale contenuto a Process.Start
. Se Mallory riesce a inserire uno script dannoso all'interno dell'archivio a livello di computer, quando Bob avvia la sua app:
- La sua app analizza e avvia lo script dannoso di Mallory nel contesto del profilo utente di Bob.
- Mallory ottiene l'accesso all'account di Bob nel computer locale.
Denial of Service
Un attacco Denial of Service si verifica quando l'app di Bob legge il file di Mallory e si arresta in modo anomalo o smette di funzionare correttamente. Prendere in considerazione di nuovo l'app menzionata in precedenza, che tenta di analizzare uno script di avvio dall'archivio a livello di computer. Se Mallory riesce a inserire un file con contenuti non corretti nell'archivio a livello di computer, potrebbe:
- Fare in modo che l'app di Bob generi un'eccezione all'inizio del percorso di avvio.
- Impedire l'avvio corretto dell'app a causa dell'eccezione.
In questo modo ha negato a Bob la possibilità di avviare l'app con il proprio account utente.
Diffusione di informazioni
Un attacco di diffusione di informazioni si verifica quando Mallory può indurre Bob a rivelare il contenuto di un file a cui Mallory normalmente non ha accesso. Si consideri che Bob abbia un file segreto C:\Users\Bob\secret.txt che Mallory vuole leggere. Conosce il percorso di questo file, ma non può leggerlo perché Windows le impedisce di accedere alla directory del profilo utente di Bob.
Mallory inserisce invece un collegamento reale nell'archivio a livello di computer. Si tratta di un tipo speciale di file che di per sé non contiene alcun contenuto, ma punta a un altro file sul disco. Se si tenta di leggere il file del collegamento reale, si leggerà invece il contenuto del file a cui punta il collegamento. Dopo aver creato il collegamento reale, Mallory non riesce ancora a leggere il contenuto del file perché non ha accesso alla destinazione (C:\Users\Bob\secret.txt
) del collegamento. Tuttavia, Bob ha accesso a questo file.
Quando l'app di Bob legge dall'archivio a livello di computer, ora legge inavvertitamente il contenuto del suo file secret.txt
, proprio come se il file stesso fosse presente nell'archivio a livello di computer. Quando l'app di Bob viene chiusa, se tenta di salvare nuovamente il file nell'archivio a livello di computer, finisce per inserire una copia effettiva del file nella directory *C:\ProgramData\IsolatedStorage*. Poiché questa directory è leggibile da qualsiasi utente del computer, Mallory può ora leggere il contenuto del file.
Procedure consigliate per difendersi da questi attacchi
Importante: se l'ambiente ha più utenti reciprocamente non attendibili, non chiamare l'API IsolatedStorageFile.GetEnumerator(IsolatedStorageScope.Machine)
né richiamare lo strumento storeadm.exe /machine /list
. Entrambi presuppongono di funzionare su dati attendibili. Se un utente malintenzionato riesce a eseguire il seeding di un payload dannoso nell'archivio a livello di computer, tale payload può causare un attacco di elevazione dei privilegi nel contesto dell'utente che esegue questi comandi.
Se si opera in un ambiente multiutente, riconsiderare l'uso di funzionalità di archiviazione isolate destinate all'ambito del computer. Se un'app deve leggere i dati da una posizione a livello di computer, preferire la lettura dei dati da una posizione scrivibile solo dagli account amministratore. La directory %PROGRAMFILES%
e l'hive del Registro di sistema HKLM
sono esempi di percorsi scrivibili solo dagli amministratori e leggibili da tutti. I dati letti da tali posizioni sono quindi considerati attendibili.
Se un'app deve usare l'ambito computer in un ambiente multiutente, convalidare il contenuto di qualsiasi file letto dall'archivio a livello di computer. Se l'app deserializza i grafici di oggetti da questi file, è consigliabile usare serializzatori più sicuri come XmlSerializer
anziché serializzatori pericolosi come BinaryFormatter
o NetDataContractSerializer
. Prestare attenzione con grafici di oggetti annidati o grafici di oggetti che eseguono l'allocazione delle risorse in base al contenuto del file.
Percorsi dello spazio di memorizzazione isolato
Talvolta risulta utile verificare una modifica nello spazio di memorizzazione isolato utilizzando il file system del sistema operativo. È possibile che si voglia conoscere il percorso dei file di spazio di memorizzazione isolato. Il percorso varia in base al sistema operativo. Nella tabella che segue vengono illustrati i percorsi principali in cui viene creata l'archiviazione isolata in alcuni sistemi operativi. Cercare la directory Microsoft\IsolatedStorage in questo percorso radice. Per visualizzare cartelle e file nascosti, in modo da poter individuare l'archiviazione isolata nel file system, è necessario modificare le impostazioni della cartella.
Sistema operativo | Percorso nel file system |
---|---|
Windows 2000, Windows XP, Windows Server 2003 - (aggiornamento da Windows NT 4.0) | Archivi con supporto roaming = <SYSTEMROOT>\Profiles\<user>\Application Data Archivi non abilitati al roaming = <SYSTEMROOT>\Profiles\<user>\Local Settings\Application Data |
Windows 2000 - installazione pulita (e aggiornamenti da Windows 98 e Windows NT 3.51) | Archivi con supporto roaming = <SYSTEMDRIVE>\Documents and Settings\<user>\Application Data Archivi non abilitati al roaming = <SYSTEMDRIVE>\Documents and Settings\<user>\Local Settings\Application Data |
Windows XP, Windows Server 2003 - installazione pulita (e aggiornamenti da Windows 2000 e Windows 98) | Archivi con supporto roaming = <SYSTEMDRIVE>\Documents and Settings\<user>\Application Data Archivi non abilitati al roaming = <SYSTEMDRIVE>\Documents and Settings\<user>\Local Settings\Application Data |
Windows 8, Windows 7, Windows Server 2008, Windows Vista | Archivi con supporto roaming = <SYSTEMDRIVE>\Users\<user>\AppData\Roaming Archivi non abilitati al roaming = <SYSTEMDRIVE>\Users\<user>\AppData\Local |
Creazione, enumerazione ed eliminazione dello spazio di memorizzazione isolato
.NET fornisce tre classi dello spazio dei nomi System.IO.IsolatedStorage per aiutare ad eseguire attività che coinvolgono lo spazio di memorizzazione isolato:
IsolatedStorageFile, che deriva da System.IO.IsolatedStorage.IsolatedStorage e fornisce la gestione di base di file di applicazione e assembly archiviati. Un'istanza della classe IsolatedStorageFile rappresenta un singolo archivio contenuto nel file system.
IsolatedStorageFileStream , che deriva da System.IO.FileStream e fornisce l'accesso ai file di un archivio.
IsolatedStorageScope è un'enumerazione che consente di creare e selezionare un archivio con il tipo di isolamento appropriato.
Le classi di archiviazione isolata consentono di creare, enumerare ed eliminare l'archiviazione isolata. I metodi per l'esecuzione di queste attività sono disponibili tramite l'oggetto IsolatedStorageFile . Per alcune operazioni occorre disporre dell'autorizzazione IsolatedStorageFilePermission , che rappresenta il diritto di amministrare lo spazio di memorizzazione isolato. Potrebbero essere necessari anche i diritti di sistema operativo per accedere al file o alla directory.
Per una serie di esempi che illustrano le attività dello spazio di memorizzazione isolato comuni, vedere gli argomenti relativi alle procedure elencati in Argomenti correlati.
Scenari per l'utilizzo dell'archiviazione isolata
Lo spazio di memorizzazione isolato risulta utile in molte situazioni, inclusi i seguenti quattro scenari:
Controlli di cui è stato eseguito il download. Ai controlli di codice gestito scaricati da Internet non è consentito scrivere sul disco fisso mediante le normali classi di I/O, ma è permesso l'utilizzo dell'archiviazione isolata per la memorizzazione degli stati dell'applicazione e delle impostazioni dell'utente.
Archiviazione di componenti condivisi. I componenti condivisi tra le applicazioni possono utilizzare l'archiviazione isolata per fornire accesso controllato agli archivi di dati.
Archiviazione server. Le applicazioni server possono utilizzare l'archiviazione isolata per fornire singoli archivi a un ampio numero di utenti che inoltrano richieste all'applicazione. Poiché l'archiviazione isolata è sempre isolata dall'utente, il server deve impersonare l'utente che inoltra la richiesta. In questo caso, i dati vengono isolati in base all'identità del principale, che è la stessa usata dall'applicazione per distinguere gli utenti.
Roaming. Le applicazioni possono anche utilizzare l'archiviazione isolata con i profili di utente roaming. In questo modo gli archivi isolati di un utente possono spostarsi con il profilo.
Non utilizzare lo spazio di memorizzazione isolato nelle seguenti situazioni:
Per archiviare informazioni segrete di grande importanza quali password o chiavi non crittografate, in quanto lo spazio di memorizzazione isolato non è protetto da codice a elevata attendibilità, da codice non gestito o da utenti attendibili del computer.
Per archiviare codice.
Per salvare le impostazioni di distribuzione e di configurazione controllate dagli amministratori. Si noti che le preferenze utente non sono considerate impostazioni di configurazione, poiché gli amministratori non le controllano.
Molte applicazioni utilizzano un database per memorizzare e isolare dati. In questo caso una o più righe di un database possono rappresentare l'archiviazione di un utente specifico. È possibile utilizzare l'archiviazione isolata invece di un database quando il numero di utenti è ridotto, quando l'overhead per l'utilizzo di un database è notevole o quando non si dispone di un database. Inoltre, l'archiviazione isolata rappresenta una valida alternativa quando l'applicazione richiede un'archiviazione più flessibile e complessa di quanto non consenta una riga in un database.
Articoli correlati
Posizione | Descrizione |
---|---|
Tipi di isolamento | Vengono descritti i vari tipi di isolamento. |
Procedura: Recuperare archivi per lo spazio di memorizzazione isolato | Viene fornito un esempio di utilizzo della classe IsolatedStorageFile per ottenere uno spazio di memorizzazione isolato in base all'utente e all'assembly. |
Procedura: Enumerare gli archivi per lo spazio di memorizzazione isolato | Viene illustrato come utilizzare il metodo IsolatedStorageFile.GetEnumerator per calcolare la dimensione dell'intero spazio di memorizzazione isolato dell'utente. |
Procedura: Eliminare gli archivi nello spazio di memorizzazione isolato | Vengono illustrati i due possibili utilizzi del metodo IsolatedStorageFile.Remove per l'eliminazione degli spazi di memorizzazione isolati. |
Procedura: Anticipare le condizioni di spazio insufficiente con lo spazio di memorizzazione isolato | Viene illustrato come misurare lo spazio rimanente in un archivio isolato. |
Procedura: Creare file e directory nello spazio di memorizzazione isolato | Vengono forniti alcuni esempi di creazione di file e directory in un archivio isolato. |
Procedura: Trovare file e directory esistenti nello spazio di memorizzazione isolato | Viene illustrato come leggere la struttura di directory e i file dell'archiviazione isolata. |
Procedura: Leggere e scrivere sui file nello spazio di memorizzazione isolato | Viene fornito un esempio di scrittura e rilettura di una stringa in un file di spazio di memorizzazione isolato. |
Procedura: Eliminare file e directory nello spazio di memorizzazione isolato | Viene illustrato come eliminare file e directory di uno spazio di memorizzazione isolato. |
I/O di file e di flussi | Illustra le modalità di esecuzione di un file sincrono e asincrono e dell'accesso al flusso di dati. |