Delen via

Geïsoleerde opslag

  • Artikel

Voor desktop-apps is geïsoleerde opslag een mechanisme voor gegevensopslag dat isolatie en veiligheid biedt door gestandaardiseerde manieren te definiëren om code te koppelen aan opgeslagen gegevens. Standaardisatie biedt ook andere voordelen. Beheerders kunnen hulpprogramma's gebruiken die zijn ontworpen voor het bewerken van geïsoleerde opslag om de opslagruimte van bestanden te configureren, beveiligingsbeleid in te stellen en ongebruikte gegevens te verwijderen. Bij geïsoleerde opslag heeft uw code geen unieke paden meer nodig om veilige locaties in het bestandssysteem op te geven en worden gegevens beveiligd tegen andere toepassingen die alleen geïsoleerde toegang tot opslag hebben. Vastgelegde informatie die aangeeft waar het opslaggebied van een toepassing zich bevindt, is overbodig.

Belangrijk

Geïsoleerde opslag is niet beschikbaar voor Windows 8.x Store-apps. Gebruik in plaats daarvan de toepassingsgegevensklassen in de Windows.Storage naamruimten die zijn opgenomen in de Windows Runtime-API om lokale gegevens en bestanden op te slaan. Zie Toepassingsgegevens in de Windows-Ontwikkelaarscentrum voor meer informatie.

Gegevenscompartimenten en winkels

Wanneer een toepassing gegevens opslaat in een bestand, moeten de bestandsnaam en opslaglocatie zorgvuldig worden gekozen om de mogelijkheid te minimaliseren dat de opslaglocatie bekend is bij een andere toepassing en daarom kwetsbaar is voor beschadiging. Zonder een standaardsysteem om deze problemen te beheren, kunnen improvisatietechnieken die opslagconflicten minimaliseren complex zijn en kunnen de resultaten onbetrouwbaar zijn.

Met geïsoleerde opslag worden gegevens altijd geïsoleerd door gebruiker en assembly. Referenties zoals de oorsprong of de sterke naam van de assembly bepalen de assembly-identiteit. Gegevens kunnen ook worden geïsoleerd door toepassingsdomein, met vergelijkbare referenties.

Wanneer u geïsoleerde opslag gebruikt, slaat uw toepassing gegevens op in een uniek gegevenscompartiment dat is gekoppeld aan een bepaald aspect van de identiteit van de code, zoals de uitgever of handtekening van de code. Het gegevenscompartiment is een abstractie, geen specifieke opslaglocatie; het bestaat uit een of meer geïsoleerde opslagbestanden, opslagbestanden genaamd, die de werkelijke maplocaties bevatten waar gegevens worden opgeslagen. Aan een toepassing kan bijvoorbeeld een gegevenscompartiment zijn gekoppeld en een map in het bestandssysteem zou het archief implementeren dat de gegevens voor die toepassing daadwerkelijk bewaart. De gegevens die in het archief zijn opgeslagen, kunnen elk soort gegevens zijn, van gebruikersvoorkeurinformatie tot toepassingsstatus. Voor de ontwikkelaar is de locatie van het datacompartiment transparant. Winkels bevinden zich meestal op de client, maar een servertoepassing kan geïsoleerde archieven gebruiken om informatie op te slaan door de gebruiker te imiteren namens wie deze werkt. Geïsoleerde opslag kan ook informatie opslaan op een server met een zwervend profiel van een gebruiker, zodat de gegevens met de zwervende gebruiker worden gereisd.

Quota voor geïsoleerde opslag

Een quotum is een limiet voor de hoeveelheid geïsoleerde opslag die kan worden gebruikt. Het quotum bevat bytes aan bestandsruimte, evenals de overhead die is gekoppeld aan de map en andere informatie in het archief. Geïsoleerde opslag maakt gebruik van machtigingsquota, wat opslaglimieten zijn die worden ingesteld met behulp van IsolatedStoragePermission objecten. Als u gegevens probeert te schrijven die het quotum overschrijden, wordt er een IsolatedStorageException uitzondering gegenereerd. Beveiligingsbeleid, dat kan worden gewijzigd met behulp van het .NET Framework Configuration Tool (Mscorcfg.msc), bepaalt welke machtigingen worden verleend aan code. Code die is verleend IsolatedStoragePermission , is beperkt tot het gebruik van niet meer opslagruimte dan de UserQuota eigenschap toestaat. Omdat code echter machtigingsquota kan omzeilen door verschillende gebruikersidentiteiten weer te geven, dienen machtigingsquota als richtlijnen voor het gedrag van code in plaats van als een vaste limiet voor het gedrag van code.

Quota worden niet afgedwongen voor roamingarchieven. Daarom is een iets hoger machtigingsniveau vereist voor het gebruik van code. De opsommingswaarden AssemblyIsolationByRoamingUser en DomainIsolationByRoamingUser geven een machtiging op voor het gebruik van geïsoleerde opslag voor een zwervende gebruiker.

Beveiligde toegang

Door geïsoleerde opslag te gebruiken, kunnen gedeeltelijk vertrouwde toepassingen gegevens opslaan op een manier die wordt beheerd door het beveiligingsbeleid van de computer. Dit is vooral handig voor gedownloade onderdelen die een gebruiker mogelijk voorzichtig wil uitvoeren. Beveiligingsbeleid verleent dit soort codemachtigingen zelden wanneer u toegang hebt tot het bestandssysteem met behulp van standaard I/O-mechanismen. Standaard krijgt code die wordt uitgevoerd vanaf de lokale computer, een lokaal netwerk of internet echter het recht om geïsoleerde opslag te gebruiken.

Beheerders kunnen beperken hoeveel geïsoleerde opslag een toepassing of een gebruiker beschikbaar heeft, op basis van het juiste vertrouwensniveau. Daarnaast kunnen beheerders de persistente gegevens van een gebruiker volledig verwijderen. Als u geïsoleerde opslag wilt maken of openen, moet aan code de juiste IsolatedStorageFilePermission machtiging worden verleend.

Voor toegang tot geïsoleerde opslag moet code alle benodigde systeemeigen platformbesturingssysteemrechten hebben. Aan de toegangsbeheerlijsten (ACL's) die bepalen welke gebruikers de rechten hebben om het bestandssysteem te gebruiken, moet worden voldaan. .NET-toepassingen hebben al besturingssysteemrechten voor toegang tot geïsoleerde opslag, tenzij ze imitatie (platformspecifiek) uitvoeren. In dit geval is de toepassing verantwoordelijk voor het garanderen dat de geïmiteerde gebruikersidentiteit de juiste besturingssysteemrechten heeft voor toegang tot geïsoleerde opslag. Deze toegang biedt een handige manier voor code die wordt uitgevoerd of gedownload van internet om te lezen en te schrijven naar een opslagruimte die is gerelateerd aan een bepaalde gebruiker.

Voor het beheren van de toegang tot geïsoleerde opslag gebruikt de algemene taalruntime IsolatedStorageFilePermission objecten. Elk object heeft eigenschappen die de volgende waarden opgeven:

  • Toegestaan gebruik, wat aangeeft welk type toegang is toegestaan. De waarden zijn lid van de IsolatedStorageContainment opsomming. Zie de tabel in de volgende sectie voor meer informatie over deze waarden.

  • Opslagquotum, zoals besproken in de vorige sectie.

De runtime vereist IsolatedStorageFilePermission toestemming wanneer code voor het eerst probeert een winkel te openen. Er wordt bepaald of deze machtiging moet worden verleend op basis van hoeveel de code wordt vertrouwd. Als de machtiging wordt verleend, worden de toegestane gebruiks- en opslagquotumwaarden bepaald door beveiligingsbeleid en door de aanvraag van de code voor IsolatedStorageFilePermission. Beveiligingsbeleid wordt ingesteld met behulp van het .NET Framework Configuration Tool (Mscorcfg.msc). Alle bellers in de oproepstack worden gecontroleerd om ervoor te zorgen dat elke beller ten minste het juiste toegestane gebruik heeft. De runtime controleert ook het quotum dat is opgelegd aan de code die het archief heeft geopend of gemaakt waarin het bestand moet worden opgeslagen. Als aan deze voorwaarden wordt voldaan, wordt toestemming verleend. Het quotum wordt opnieuw gecontroleerd telkens wanneer een bestand naar het archief wordt geschreven.

Toepassingscode is niet vereist om toestemming aan te vragen, omdat de algemene taalruntime alles verleent wat IsolatedStorageFilePermission geschikt is op basis van beveiligingsbeleid. Er zijn echter goede redenen om specifieke machtigingen aan te vragen die uw toepassing nodig heeft, waaronder IsolatedStorageFilePermission.

Toegestane gebruiks- en beveiligingsrisico's

Het toegestane gebruik dat is opgegeven door IsolatedStorageFilePermission bepaalt in welke mate code is toegestaan om geïsoleerde opslag te maken en te gebruiken. In de volgende tabel ziet u hoe het toegestane gebruik dat is opgegeven in de machtiging overeenkomt met typen isolatie en geeft een overzicht van de beveiligingsrisico's die zijn gekoppeld aan elk toegestaan gebruik.

Toegestaan gebruik Isolatietypen Beveiligingsimpact
None Er is geen geïsoleerd opslaggebruik toegestaan. Er is geen beveiligingsimpact.
DomainIsolationByUser Isolatie per gebruiker, domein en assembly. Elke assembly heeft een afzonderlijk subarchief binnen het domein. Winkels die deze machtiging gebruiken, worden ook impliciet geïsoleerd door de computer. Dit machtigingsniveau laat resources openstaan voor onbevoegde overgebruik, hoewel afgedwongen quota het moeilijker maken. Dit wordt een Denial of Service-aanval genoemd.
DomainIsolationByRoamingUser Hetzelfde als DomainIsolationByUser, maar de opslag wordt opgeslagen op een locatie die roamt als zwervende gebruikersprofielen zijn ingeschakeld en quota niet worden afgedwongen. Omdat quota moeten worden uitgeschakeld, zijn opslagresources kwetsbaarder voor een Denial of Service-aanval.
AssemblyIsolationByUser Isolatie per gebruiker en assembly. Winkels die deze machtiging gebruiken, worden ook impliciet geïsoleerd door de computer. Quota worden op dit niveau afgedwongen om een Denial of Service-aanval te voorkomen. Dezelfde assembly in een ander domein heeft toegang tot dit archief, waardoor de mogelijkheid wordt geopend dat informatie tussen toepassingen kan worden gelekt.
AssemblyIsolationByRoamingUser Hetzelfde als AssemblyIsolationByUser, maar de opslag wordt opgeslagen op een locatie die roamt als zwervende gebruikersprofielen zijn ingeschakeld en quota niet worden afgedwongen. Hetzelfde als in AssemblyIsolationByUser, maar zonder quota, neemt het risico van een Denial of Service-aanval toe.
AdministerIsolatedStorageByUser Isolatie per gebruiker. Normaal gesproken gebruiken alleen beheer- of foutopsporingsprogramma's dit machtigingsniveau. Met toegang met deze machtiging kan code een van de geïsoleerde opslagbestanden of mappen van een gebruiker weergeven of verwijderen (ongeacht de assembly-isolatie). Risico's zijn onder meer, maar zijn niet beperkt tot het lekken van informatie en gegevensverlies.
UnrestrictedIsolatedStorage Isolatie door alle gebruikers, domeinen en assembly's. Normaal gesproken gebruiken alleen beheer- of foutopsporingsprogramma's dit machtigingsniveau. Met deze machtiging wordt het potentieel voor een totale inbreuk op alle geïsoleerde winkels voor alle gebruikers gemaakt.

Veiligheid van geïsoleerde opslagonderdelen met betrekking tot niet-vertrouwde gegevens

Deze sectie is van toepassing op de volgende frameworks:

  • .NET Framework (alle versies)
  • .NET Core 2.1+
  • .NET 5+

.NET Framework en .NET Core bieden geïsoleerde opslag als mechanisme voor het behouden van gegevens voor een gebruiker, een toepassing of een onderdeel. Dit is een verouderd onderdeel dat voornamelijk is ontworpen voor nu afgeschafte scenario's voor codetoegangsbeveiliging.

Verschillende geïsoleerde opslag-API's en hulpprogramma's kunnen worden gebruikt om gegevens over de grenzen van vertrouwensrelaties te lezen. Het lezen van gegevens van een machinebreed bereik kan bijvoorbeeld gegevens uit andere, mogelijk minder vertrouwde gebruikersaccounts op de computer aggregeren. Onderdelen of toepassingen die lezen uit geïsoleerde opslagbereiken voor de hele machine, moeten rekening houden met de gevolgen van het lezen van deze gegevens.

Beveiligingsgevoelige API's die kunnen worden gelezen vanuit het bereik van de machine

Onderdelen of toepassingen die een van de volgende API's aanroepen, worden gelezen uit het bereik van de machine:

Het geïsoleerde opslaghulpprogramma storeadm.exe wordt beïnvloed als deze wordt aangeroepen met de /machine switch, zoals wordt weergegeven in de volgende code:

storeadm.exe /machine [any-other-switches]

Het geïsoleerde opslagprogramma wordt geleverd als onderdeel van Visual Studio en de .NET Framework SDK.

Als de toepassing geen aanroepen naar de voorgaande API's omvat of als de werkstroom niet op deze manier aanroept storeadm.exe , is dit document niet van toepassing.

Impact in omgevingen met meerdere gebruikers

Zoals eerder vermeld, is de beveiligingsimpact van deze API's afkomstig van gegevens die zijn geschreven uit één vertrouwensomgeving, gelezen uit een andere vertrouwensomgeving. Geïsoleerde opslag maakt over het algemeen gebruik van een van de drie locaties voor het lezen en schrijven van gegevens:

  1. %LOCALAPPDATA%\IsolatedStorage\: bijvoorbeeld voor C:\Users\<username>\AppData\Local\IsolatedStorage\User bereik.
  2. %APPDATA%\IsolatedStorage\: bijvoorbeeld voor C:\Users\<username>\AppData\Roaming\IsolatedStorage\User|Roaming bereik.
  3. %PROGRAMDATA%\IsolatedStorage\: bijvoorbeeld voor C:\ProgramData\IsolatedStorage\Machine bereik.

De eerste twee locaties worden geïsoleerd per gebruiker. Windows zorgt ervoor dat verschillende gebruikersaccounts op dezelfde computer geen toegang hebben tot elkaars gebruikersprofielmappen. Twee verschillende gebruikersaccounts die gebruikmaken van de User of User|Roaming winkels, zien elkaars gegevens niet en kunnen elkaars gegevens niet verstoren.

De derde locatie wordt gedeeld tussen alle gebruikersaccounts op de computer. Verschillende accounts kunnen van en naar deze locatie lezen en schrijven, en ze kunnen elkaars gegevens zien.

De voorgaande paden kunnen verschillen op basis van de versie van Windows die wordt gebruikt.

Overweeg nu een systeem voor meerdere gebruikers met twee geregistreerde gebruikers Mallory en Bob. Mallory heeft de mogelijkheid om toegang te krijgen tot haar gebruikersprofielmap C:\Users\Mallory\en ze heeft toegang tot de gedeelde opslaglocatie voor C:\ProgramData\IsolatedStorage\de hele machine. Ze heeft geen toegang tot de gebruikersprofielmap C:\Users\Bob\van Bob.

Als Mallory Bob wil aanvallen, kan ze gegevens schrijven naar de opslaglocatie voor de hele machine en vervolgens proberen Bob te beïnvloeden in het lezen vanuit de machinebrede opslag. Wanneer Bob een app uitvoert die uit deze store wordt gelezen, wordt die app uitgevoerd op de gegevens die Mallory daar is geplaatst, maar vanuit de context van het gebruikersaccount van Bob. De rest van dit document beschouwt verschillende aanvalsvectoren en de stappen die apps kunnen uitvoeren om hun risico op deze aanvallen te minimaliseren.

Notitie

Om een dergelijke aanval te kunnen uitvoeren, vereist Mallory:

  • Een gebruikersaccount op de computer.
  • De mogelijkheid om een bestand op een bekende locatie in het bestandssysteem te plaatsen.
  • Weet dat Bob op een bepaald moment een app uitvoert waarmee deze gegevens worden gelezen.

Dit zijn geen bedreigingsvectoren die van toepassing zijn op standaard bureaubladomgevingen met één gebruiker, zoals thuis-pc's of werkstations voor één werknemer.

Verhoging van bevoegdheden

Er treedt een uitbreiding van bevoegdheden op wanneer de app van Bob het bestand van Mallory leest en automatisch probeert actie te ondernemen op basis van de inhoud van die nettolading. Overweeg een app die de inhoud van een opstartscript leest vanuit het computerbrede archief en die inhoud doorgeeft aan Process.Start. Als Mallory een schadelijk script in de computerbrede store kan plaatsen, start Bob zijn app:

  • Zijn app parseert en start het schadelijke script van Mallory onder de context van het gebruikersprofiel van Bob.
  • Mallory krijgt toegang tot Bob's account op de lokale computer.

Denial of Service

Er treedt een denial of service-aanval op wanneer de app van Bob het bestand van Mallory leest en vastloopt of anderszins niet meer goed werkt. Overweeg opnieuw de eerder genoemde app, die probeert een opstartscript te parseren vanuit de computerbrede store. Als Mallory een bestand met ongeldige inhoud in de hele computer kan plaatsen, kan ze het volgende doen:

  • Ervoor zorgen dat de app van Bob vroeg in het opstartpad een uitzondering genereert.
  • Voorkom dat de app kan worden gestart vanwege de uitzondering.

Vervolgens heeft ze Bob de mogelijkheid geweigerd om de app onder zijn eigen gebruikersaccount te starten.

Openbaarmaking van informatie

Een aanval op openbaarmaking van informatie treedt op wanneer Mallory Bob kan misleiden om de inhoud van een bestand te onthullen waartoe Mallory normaal gesproken geen toegang heeft. Houd er rekening mee dat Bob een geheim bestand C:\Users\Bob\secret.txt heeft dat Mallory wil lezen. Ze kent het pad naar dit bestand, maar ze kan het niet lezen omdat Windows haar verbiedt toegang te krijgen tot de gebruikersprofielmap van Bob.

In plaats daarvan plaatst Mallory een harde koppeling in de machinebrede winkel. Dit is een speciaal type bestand dat zelf geen inhoud bevat, maar verwijst naar een ander bestand op schijf. Als u het bestand met een vaste koppeling probeert te lezen, wordt in plaats daarvan de inhoud van het bestand gelezen waarop de koppeling betrekking heeft. Nadat de harde koppeling is gemaakt, kan Mallory de bestandsinhoud nog steeds niet lezen omdat ze geen toegang heeft tot het doel (C:\Users\Bob\secret.txt) van de koppeling. Bob heeft echter wel toegang tot dit bestand.

Wanneer de app van Bob uit de hele computer wordt gelezen, wordt nu per ongeluk de inhoud van het secret.txt bestand gelezen, net zoals het bestand zelf aanwezig was in de computerbrede store. Wanneer de app van Bob wordt afgesloten en het bestand opnieuw wordt opgeslagen in de opslag voor de hele computer, wordt er uiteindelijk een kopie van het bestand in de map *C:\ProgramData\IsolatedStorage* geplaatst. Aangezien deze map door elke gebruiker op de computer kan worden gelezen, kan Mallory nu de inhoud van het bestand lezen.

Best practices voor bescherming tegen deze aanvallen

Belangrijk: Als uw omgeving meerdere wederzijds niet-vertrouwde gebruikers heeft, roept u de API IsolatedStorageFile.GetEnumerator(IsolatedStorageScope.Machine) niet aan of roept u het hulpprogramma storeadm.exe /machine /listaan. Beide gaan ervan uit dat ze werken op vertrouwde gegevens. Als een aanvaller een schadelijke nettolading kan zaaien in de computerbrede opslag, kan die nettolading leiden tot een uitbreiding van bevoegdheden in de context van de gebruiker die deze opdrachten uitvoert.

Als u in een omgeving met meerdere gebruikers werkt, moet u het gebruik van geïsoleerde opslagfuncties die gericht zijn op het machinebereik , opnieuw overwegen. Als een app gegevens van een computerbrede locatie moet lezen, wilt u de gegevens liever lezen van een locatie die alleen door beheerdersaccounts kan worden geschreven. De %PROGRAMFILES% map en de HKLM register hive zijn voorbeelden van locaties die door alleen beheerders kunnen worden beschrijfbaar en door iedereen leesbaar zijn. Gegevens die van deze locaties worden gelezen, worden daarom beschouwd als betrouwbaar.

Als een app het machinebereik in een omgeving met meerdere gebruikers moet gebruiken, valideert u de inhoud van een bestand dat u in de hele computer hebt gelezen. Als de app objectgrafieken van deze bestanden deserialiseert, kunt u overwegen om veiligere serializers te gebruiken, zoals XmlSerializer in plaats van gevaarlijke serializers, zoals BinaryFormatter of NetDataContractSerializer. Wees voorzichtig met diep geneste objectgrafieken of objectgrafieken die resourcetoewijzing uitvoeren op basis van de bestandsinhoud.

Geïsoleerde opslaglocaties

Soms is het handig om een wijziging in geïsoleerde opslag te controleren met behulp van het bestandssysteem van het besturingssysteem. Mogelijk wilt u ook de locatie van geïsoleerde opslagbestanden weten. Deze locatie is afhankelijk van het besturingssysteem. In de volgende tabel ziet u de hoofdlocaties waar geïsoleerde opslag wordt gemaakt op een aantal algemene besturingssystemen. Zoek naar Microsoft\IsolatedStorage-mappen onder deze hoofdlocatie. U moet de mapinstellingen wijzigen om verborgen bestanden en mappen weer te geven om geïsoleerde opslag in het bestandssysteem te kunnen zien.

Besturingssysteem Locatie in bestandssysteem
Windows 2000, Windows XP, Windows Server 2003 (upgrade van Windows NT 4.0) Winkels met roaming =

<SYSTEMROOT>\Profiles\<user>\Application Data

Niet-roaming winkels =

<SYSTEMROOT>\Profiles\<user>\Local Settings\Application Data
Windows 2000 - schone installatie (en upgrades van Windows 98 en Windows NT 3.51) Winkels met roaming =

<SYSTEMDRIVE>\Documents and Settings\<user>\Application Data

Niet-roaming winkels =

<SYSTEMDRIVE>\Documents and Settings\<user>\Local Settings\Application Data
Windows XP, Windows Server 2003 - schone installatie (en upgrades van Windows 2000 en Windows 98) Winkels met roaming =

<SYSTEMDRIVE>\Documents and Settings\<user>\Application Data

Niet-roaming winkels =

<SYSTEMDRIVE>\Documents and Settings\<user>\Local Settings\Application Data
Windows 8, Windows 7, Windows Server 2008, Windows Vista Winkels met roaming =

<SYSTEMDRIVE>\Users\<user>\AppData\Roaming

Niet-roaming winkels =

<SYSTEMDRIVE>\Users\<user>\AppData\Local

Geïsoleerde opslag maken, inventariseren en verwijderen

.NET biedt drie klassen in de System.IO.IsolatedStorage naamruimte waarmee u taken kunt uitvoeren die betrekking hebben op geïsoleerde opslag:

Met de geïsoleerde opslagklassen kunt u geïsoleerde opslag maken, inventariseren en verwijderen. De methoden voor het uitvoeren van deze taken zijn beschikbaar via het IsolatedStorageFile object. Voor sommige bewerkingen moet u beschikken over de IsolatedStorageFilePermission machtiging die het recht vertegenwoordigt om geïsoleerde opslag te beheren. Mogelijk moet u ook besturingssysteemrechten hebben voor toegang tot het bestand of de map.

Zie de procedures die worden vermeld in verwante onderwerpen voor een reeks voorbeelden die algemene geïsoleerde opslagtaken demonstreren.

Scenario's voor geïsoleerde opslag

Geïsoleerde opslag is handig in veel situaties, waaronder deze vier scenario's:

  • Gedownloade besturingselementen. Beheerde codebesturingselementen die van internet zijn gedownload, mogen niet naar de harde schijf schrijven via normale I/O-klassen, maar ze kunnen geïsoleerde opslag gebruiken om de instellingen en toepassingsstatussen van gebruikers te behouden.

  • Opslag van gedeelde onderdelen. Onderdelen die worden gedeeld tussen toepassingen kunnen geïsoleerde opslag gebruiken om beheerde toegang tot gegevensarchieven te bieden.

  • Serveropslag. Servertoepassingen kunnen geïsoleerde opslag gebruiken om afzonderlijke winkels te bieden voor een groot aantal gebruikers die aanvragen indienen bij de toepassing. Omdat geïsoleerde opslag altijd wordt gescheiden door de gebruiker, moet de server de gebruiker imiteren die de aanvraag indient. In dit geval worden gegevens geïsoleerd op basis van de identiteit van de principal. Dit is dezelfde identiteit die de toepassing gebruikt om onderscheid te maken tussen de gebruikers.

  • Roaming. Toepassingen kunnen ook geïsoleerde opslag gebruiken met zwervende gebruikersprofielen. Hierdoor kunnen de geïsoleerde winkels van een gebruiker roamen met het profiel.

Gebruik in de volgende situaties geen geïsoleerde opslag:

  • Voor het opslaan van geheimen met hoge waarde, zoals niet-versleutelde sleutels of wachtwoorden, omdat geïsoleerde opslag niet wordt beveiligd tegen zeer vertrouwde code, van niet-beheerde code of van vertrouwde gebruikers van de computer.

  • Code opslaan.

  • Configuratie- en implementatie-instellingen opslaan, die beheerders beheren. (Gebruikersvoorkeuren worden niet beschouwd als configuratie-instellingen omdat beheerders deze niet beheren.)

Veel toepassingen gebruiken een database om gegevens op te slaan en te isoleren. In dat geval kunnen een of meer rijen in een database de opslag voor een specifieke gebruiker vertegenwoordigen. U kunt ervoor kiezen om geïsoleerde opslag te gebruiken in plaats van een database wanneer het aantal gebruikers klein is, wanneer de overhead van het gebruik van een database aanzienlijk is of wanneer er geen databasefaciliteit bestaat. Wanneer de toepassing opslag vereist die flexibeler en complexer is dan wat een rij in een database biedt, kan geïsoleerde opslag een levensvatbaar alternatief bieden.

Title Beschrijving
Typen isolatie Beschrijft de verschillende typen isolatie.
Procedure: Winkels verkrijgen voor geïsoleerde opslag Biedt een voorbeeld van het gebruik van de IsolatedStorageFile klasse om een winkel te verkrijgen die is geïsoleerd door gebruiker en assembly.
Procedure: Stores opsommen voor geïsoleerde opslag Laat zien hoe u de IsolatedStorageFile.GetEnumerator methode gebruikt om de grootte van alle geïsoleerde opslag voor de gebruiker te berekenen.
Procedure: Winkels verwijderen in Geïsoleerde opslag Laat zien hoe u de IsolatedStorageFile.Remove methode op twee verschillende manieren kunt gebruiken om geïsoleerde winkels te verwijderen.
Procedure: Verwachte out-of-space-omstandigheden met geïsoleerde opslag Laat zien hoe u de resterende ruimte in een geïsoleerde opslag kunt meten.
Procedure: Bestanden en mappen maken in Geïsoleerde opslag Hier vindt u enkele voorbeelden van het maken van bestanden en mappen in een geïsoleerde opslag.
Procedure: Bestaande bestanden en mappen zoeken in geïsoleerde opslag Demonstreert hoe u de mapstructuur en bestanden in geïsoleerde opslag kunt lezen.
Procedure: Lezen en schrijven naar bestanden in geïsoleerde opslag Biedt een voorbeeld van het schrijven van een tekenreeks naar een geïsoleerd opslagbestand en het teruglezen.
Procedure: Bestanden en mappen verwijderen in Geïsoleerde opslag Demonstreert hoe u geïsoleerde opslagbestanden en mappen verwijdert.
Bestands- en stream-I/O Hierin wordt uitgelegd hoe u synchrone en asynchrone toegang tot bestanden en gegevensstromen kunt uitvoeren.

Verwijzing