Bagikan melalui


Penyimpanan terisolasi

Untuk aplikasi desktop, penyimpanan terisolasi adalah mekanisme penyimpanan data yang memberikan isolasi dan keamanan dengan mendefinisikan cara standar dalam mengaitkan kode dengan data yang disimpan. Standardisasi juga memberikan manfaat lain. Administrator dapat menggunakan alat yang dirancang untuk memanipulasi penyimpanan terisolasi untuk mengonfigurasi ruang penyimpanan file, mengatur kebijakan keamanan, dan menghapus data yang tidak digunakan. Dengan penyimpanan terisolasi, kode Anda tidak lagi memerlukan jalur unik untuk menentukan lokasi yang aman dalam sistem file, dan data dilindungi dari aplikasi lain yang hanya memiliki akses penyimpanan terisolasi. Informasi yang dikodekan secara permanen yang menunjukkan di mana area penyimpanan aplikasi berada tidak perlu.

Penting

Penyimpanan terisolasi tidak tersedia untuk aplikasi Store Windows 8.x. Sebagai gantinya, gunakan kelas data aplikasi di namespace Windows.Storage yang disertakan dalam API Runtime Windows untuk menyimpan data dan file lokal. Untuk informasi selengkapnya, lihat Data aplikasi di Windows Dev Center.

Kompartemen dan Store Data

Ketika aplikasi menyimpan data dalam file, nama file dan lokasi penyimpanan harus dipilih dengan hati-hati untuk meminimalkan kemungkinan bahwa lokasi penyimpanan akan diketahui oleh aplikasi lain dan, oleh karena itu, rentan terhadap kerusakan. Tanpa sistem standar untuk mengelola masalah ini, teknik improvisasi yang meminimalkan konflik penyimpanan bisa rumit, dan hasilnya tidak dapat diandalkan.

Dengan penyimpanan terisolasi, data selalu diisolasi oleh pengguna dan assembly. Informasi masuk seperti asal atau nama kuat assembly menentukan identitas assembly. Data juga dapat diisolasi oleh domain aplikasi, menggunakan informasi masuk serupa.

Saat Anda menggunakan penyimpanan terisolasi, aplikasi Anda menyimpan data ke kompartemen data unik yang terkait dengan beberapa aspek identitas kode, seperti penerbit atau tanda tangannya. Kompartemen data adalah abstraksi, bukan lokasi penyimpanan tertentu; ini terdiri dari satu atau beberapa file penyimpanan terisolasi, yang disebut store, yang berisi lokasi direktori aktual tempat data disimpan. Misalnya, aplikasi mungkin memiliki kompartemen data yang terkait dengannya, dan direktori dalam sistem file akan mengimplementasikan store yang benar-benar mempertahankan data untuk aplikasi tersebut. Data yang disimpan di store dapat berupa segala jenis data, mulai dari informasi preferensi pengguna hingga status aplikasi. Untuk pengembang, lokasi kompartemen data harus transparan. Penyimpanan biasanya berada di klien, tetapi aplikasi server dapat menggunakan store terisolasi untuk menyimpan informasi dengan meniru pengguna atas nama siapa aplikasi tersebut berfungsi. Penyimpanan terisolasi juga dapat menyimpan informasi di server dengan profil roaming pengguna sehingga informasi akan melakukan perjalanan dengan pengguna roaming.

Kuota untuk Storage Terisolasi

Kuota adalah batas jumlah penyimpanan terisolasi yang dapat digunakan. Kuota mencakup byte ruang file serta overhead yang terkait dengan direktori dan informasi lainnya di store. Penyimpanan terisolasi menggunakan kuota izin, yang merupakan batas penyimpanan yang diatur dengan menggunakan IsolatedStoragePermission objek. Jika Anda mencoba menulis data yang melebihi kuota, IsolatedStorageException pengecualian akan dimunculkan. Kebijakan keamanan, yang dapat dimodifikasi menggunakan .NET Framework Configuration Tool (Mscorcfg.msc), menentukan izin mana yang diberikan ke kode. Kode yang telah diberikan IsolatedStoragePermission dibatasi untuk menggunakan tidak lebih banyak penyimpanan daripada yang UserQuota diizinkan properti. Namun, karena kode dapat melewati kuota izin dengan menampilkan identitas pengguna yang berbeda, kuota izin berfungsi sebagai pedoman tentang bagaimana kode harus berperilaku daripada sebagai batasan tegas pada perilaku kode.

Kuota tidak diberlakukan pada store roaming. Karena itu, tingkat izin yang sedikit lebih tinggi diperlukan agar kode dapat menggunakannya. Nilai enumerasi AssemblyIsolationByRoamingUser dan DomainIsolationByRoamingUser menentukan izin untuk menggunakan penyimpanan terisolasi untuk pengguna roaming.

Akses Aman

Menggunakan penyimpanan terisolasi memungkinkan aplikasi tepercaya sebagian untuk menyimpan data dengan cara yang dikontrol oleh kebijakan keamanan komputer. Ini sangat berguna untuk komponen yang diunduh yang mungkin ingin dijalankan pengguna dengan hati-hati. Kebijakan keamanan jarang memberikan izin kode semacam ini saat Anda mengakses sistem file dengan menggunakan mekanisme I/O standar. Namun, secara default, kode yang berjalan dari komputer lokal, jaringan lokal, atau Internet diberikan hak untuk menggunakan penyimpanan terisolasi.

Administrator dapat membatasi seberapa banyak penyimpanan terisolasi yang dimiliki aplikasi atau pengguna, berdasarkan tingkat kepercayaan yang sesuai. Selain itu, administrator dapat menghapus data pengguna yang tersimpan sepenuhnya. Untuk membuat atau mengakses penyimpanan terisolasi, kode harus diberikan IsolatedStorageFilePermission izin yang sesuai.

Untuk mengakses penyimpanan terisolasi, kode harus memiliki semua hak sistem operasi platform asli yang diperlukan. Daftar kontrol akses (ACL) yang mengontrol pengguna mana yang memiliki hak untuk menggunakan sistem file harus dipenuhi. Aplikasi .NET sudah memiliki hak sistem operasi untuk mengakses penyimpanan terisolasi kecuali mereka melakukan peniruan identitas (khusus platform). Dalam hal ini, aplikasi bertanggung jawab untuk memastikan bahwa identitas pengguna yang ditiru memiliki hak sistem operasi yang tepat untuk mengakses penyimpanan yang terisolasi. Akses ini menyediakan cara mudah untuk kode yang dijalankan atau diunduh dari web untuk membaca dan menulis ke area penyimpanan yang terkait dengan pengguna tertentu.

Untuk mengontrol akses ke penyimpanan terisolasi, runtime bahasa umum menggunakan IsolatedStorageFilePermission objek. Setiap objek memiliki properti yang menentukan nilai berikut:

  • Penggunaan yang diizinkan, yang menunjukkan jenis akses yang diizinkan. Nilai adalah anggota IsolatedStorageContainment enumerasi. Untuk informasi selengkapnya tentang nilai-nilai ini, lihat tabel di bagian berikutnya.

  • Kuota penyimpanan, seperti yang dibahas di bagian sebelumnya.

Runtime bahasa umum menuntut IsolatedStorageFilePermission izin ketika kode pertama kali mencoba membuka store. Ini memutuskan apakah akan memberikan izin ini, berdasarkan berapa banyak kode yang dipercaya. Jika izin diberikan, nilai penggunaan dan kuota penyimpanan yang diizinkan ditentukan oleh kebijakan keamanan dan oleh permintaan kode untuk IsolatedStorageFilePermission. Kebijakan keamanan diatur dengan menggunakan .NET Framework Configuration Tool (Mscorcfg.msc). Semua pemanggil dalam tumpukan panggilan diperiksa untuk memastikan bahwa setiap penelepon memiliki setidaknya penggunaan yang diizinkan yang sesuai. Runtime bahasa umum juga memeriksa kuota yang dikenakan pada kode yang membuka atau membuat store tempat file akan disimpan. Jika kondisi ini terpenuhi, izin diberikan. Kuota diperiksa lagi setiap kali file ditulis ke store.

Kode aplikasi tidak diperlukan untuk meminta izin karena runtime bahasa umum akan memberikan apa pun yang IsolatedStorageFilePermission sesuai berdasarkan kebijakan keamanan. Namun, ada alasan yang baik untuk meminta izin khusus yang dibutuhkan aplikasi Anda, termasuk IsolatedStorageFilePermission.

Risiko Penggunaan dan Keamanan yang Diizinkan

Penggunaan yang diizinkan yang ditentukan oleh IsolatedStorageFilePermission menentukan tingkat kode mana yang akan diizinkan untuk membuat dan menggunakan penyimpanan terisolasi. Tabel berikut ini memperlihatkan bagaimana penggunaan yang diizinkan yang ditentukan dalam izin sesuai dengan jenis isolasi dan meringkas risiko keamanan yang terkait dengan setiap penggunaan yang diizinkan.

Penggunaan yang diizinkan Jenis isolasi Dampak keamanan
None Tidak ada penggunaan penyimpanan terisolasi yang diizinkan. Tidak ada dampak keamanan.
DomainIsolationByUser Isolasi oleh Pengguna, Domain, dan Assembly. Setiap assembly memiliki substore terpisah dalam domain. Store yang menggunakan izin ini juga secara implisit diisolasi oleh komputer. Tingkat izin ini membuat sumber daya terbuka untuk penggunaan berlebihan yang tidak sah, meskipun kuota yang diberlakukan membuatnya lebih sulit. Ini disebut penolakan serangan layanan.
DomainIsolationByRoamingUser Sama seperti DomainIsolationByUser, tetapi store disimpan ke lokasi yang akan menjelajah jika profil pengguna roaming diaktifkan dan kuota tidak diberlakukan. Karena kuota harus dinonaktifkan, sumber daya penyimpanan lebih rentan terhadap penolakan serangan layanan.
AssemblyIsolationByUser Isolasi oleh Pengguna dan Assembly. Store yang menggunakan izin ini juga secara implisit diisolasi oleh komputer. Kuota diberlakukan pada tingkat ini untuk membantu mencegah penolakan serangan layanan. Assembly yang sama di domain lain dapat mengakses store ini, membuka kemungkinan bahwa informasi dapat bocor di antara aplikasi.
AssemblyIsolationByRoamingUser Sama seperti AssemblyIsolationByUser, tetapi store disimpan ke lokasi yang akan menjelajah jika profil pengguna roaming diaktifkan dan kuota tidak diberlakukan. Sama seperti dalam AssemblyIsolationByUser, tetapi tanpa kuota, risiko penolakan serangan layanan meningkat.
AdministerIsolatedStorageByUser Isolasi oleh pengguna. Biasanya, hanya alat administratif atau penelusuran kesalahan yang menggunakan tingkat izin ini. Akses dengan izin ini memungkinkan kode untuk melihat atau menghapus salah satu file atau direktori penyimpanan pengguna yang terisolasi (terlepas dari isolasi assembly). Risiko mencakup, tetapi tidak terbatas pada, membocorkan informasi dan kehilangan data.
UnrestrictedIsolatedStorage Isolasi oleh semua pengguna, domain, dan assembly. Biasanya, hanya alat administratif atau penelusuran kesalahan yang menggunakan tingkat izin ini. Izin ini menciptakan potensi kompromi total semua store terisolasi untuk semua pengguna.

Keamanan komponen penyimpanan terisolasi sehubungan dengan data yang tidak tepercaya

Bagian ini berlaku untuk kerangka kerja berikut:

  • .NET Framework (semua versi)
  • .NET Core 2.1+
  • .NET 5+

.NET Framework dan .NET Core menawarkan penyimpanan terisolasi sebagai mekanisme untuk mempertahankan data bagi pengguna, aplikasi, atau komponen. Ini adalah komponen lama yang terutama dirancang untuk skenario Keamanan Akses Kode yang sekarang tidak digunakan lagi.

Berbagai API dan alat penyimpanan terisolasi dapat digunakan untuk membaca data di seluruh batas kepercayaan. Misalnya, membaca data dari cakupan di seluruh komputer dapat menggabungkan data dari akun pengguna lain yang mungkin kurang tepercaya di komputer. Komponen atau aplikasi yang membaca dari cakupan penyimpanan terisolasi di seluruh komputer harus mengetahui konsekuensi membaca data ini.

API sensitif keamanan yang dapat membaca dari cakupan di seluruh komputer

Komponen atau aplikasi yang memanggil salah satu API berikut yang dibaca dari cakupan di seluruh komputer:

Alat storeadm.exe penyimpanan terisolasi terpengaruh jika dipanggil dengan /machine sakelar, seperti yang ditunjukkan dalam kode berikut:

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

Alat penyimpanan terisolasi disediakan sebagai bagian dari Visual Studio dan SDK .NET Framework.

Jika aplikasi tidak melibatkan panggilan ke API sebelumnya, atau jika alur kerja tidak melibatkan panggilan dengan storeadm.exe cara ini, dokumen ini tidak berlaku.

Dampak di lingkungan multi-pengguna

Seperti disebutkan sebelumnya, dampak keamanan dari API ini dihasilkan dari data yang ditulis dari satu lingkungan kepercayaan dibaca dari lingkungan kepercayaan yang berbeda. Penyimpanan terisolasi umumnya menggunakan salah satu dari tiga lokasi untuk membaca dan menulis data:

  1. %LOCALAPPDATA%\IsolatedStorage\: Misalnya, C:\Users\<username>\AppData\Local\IsolatedStorage\, untuk User cakupan.
  2. %APPDATA%\IsolatedStorage\: Misalnya, C:\Users\<username>\AppData\Roaming\IsolatedStorage\, untuk User|Roaming cakupan.
  3. %PROGRAMDATA%\IsolatedStorage\: Misalnya, C:\ProgramData\IsolatedStorage\, untuk Machine cakupan.

Dua lokasi pertama diisolasi per pengguna. Windows memastikan bahwa akun pengguna yang berbeda pada komputer yang sama tidak dapat mengakses folder profil pengguna satu sama lain. Dua akun pengguna berbeda yang menggunakan User atau User|Roaming store tidak akan melihat data satu sama lain dan tidak dapat mengganggu data satu sama lain.

Lokasi ketiga dibagikan di semua akun pengguna di komputer. Akun yang berbeda dapat membaca dari dan menulis ke lokasi ini, dan mereka dapat melihat data satu sama lain.

Jalur sebelumnya mungkin berbeda berdasarkan versi Windows yang digunakan.

Sekarang pertimbangkan sistem multi-pengguna dengan dua pengguna terdaftar Mallory dan Bob. Mallory memiliki kemampuan untuk mengakses direktori C:\Users\Mallory\profil penggunanya, dan dia dapat mengakses lokasi C:\ProgramData\IsolatedStorage\penyimpanan di seluruh komputer bersama. Dia tidak dapat mengakses direktori C:\Users\Bob\profil pengguna Bob.

Jika Mallory ingin menyerang Bob, dia mungkin menulis data ke lokasi penyimpanan di seluruh komputer, lalu mencoba memengaruhi Bob untuk membaca dari store di seluruh komputer. Ketika Bob menjalankan aplikasi yang membaca dari store ini, aplikasi tersebut akan beroperasi pada data mallory yang ditempatkan di sana, tetapi dari dalam konteks akun pengguna Bob. Sisa dokumen ini membahas berbagai vektor serangan dan langkah apa yang dapat dilakukan aplikasi untuk meminimalkan risiko mereka terhadap serangan ini.

Catatan

Agar serangan seperti itu terjadi, Mallory memerlukan:

  • Akun pengguna di komputer.
  • Kemampuan untuk menempatkan file ke lokasi yang diketahui pada sistem file.
  • Pengetahuan bahwa Bob pada titik tertentu akan menjalankan aplikasi yang mencoba membaca data ini.

Ini bukan vektor ancaman yang berlaku untuk lingkungan desktop pengguna tunggal standar seperti PC rumah atau stasiun kerja perusahaan karyawan tunggal.

Peningkatan hak istimewa

Peningkatan serangan hak istimewa terjadi ketika aplikasi Bob membaca file Mallory dan secara otomatis mencoba mengambil beberapa tindakan berdasarkan konten payload tersebut. Pertimbangkan aplikasi yang membaca konten skrip startup dari store di seluruh komputer dan meneruskan konten tersebut ke Process.Start. Jika Mallory dapat menempatkan skrip berbahaya di dalam store di seluruh mesin, ketika Bob meluncurkan aplikasinya:

  • Aplikasinya mengurai dan meluncurkan skrip berbahaya Mallory di bawah konteks profil pengguna Bob.
  • Mallory mendapatkan akses ke akun Bob di komputer lokal.

Penolakan layanan

Penolakan serangan layanan terjadi ketika aplikasi Bob membaca file Mallory dan crash atau berhenti berfungsi dengan benar. Pertimbangkan lagi aplikasi yang disebutkan sebelumnya, yang mencoba mengurai skrip startup dari store di seluruh komputer. Jika Mallory dapat menempatkan file dengan konten cacat di dalam store di seluruh komputer, dia mungkin:

  • Menyebabkan aplikasi Bob memunculkan pengecualian di awal jalur startup.
  • Mencegah aplikasi berhasil diluncurkan karena pengecualian.

Dia kemudian menolak Bob kemampuan untuk meluncurkan aplikasi di bawah akun penggunanya sendiri.

Pengungkapan informasi

Serangan pengungkapan informasi terjadi ketika Mallory dapat mengelabui Bob untuk mengungkapkan konten file yang biasanya tidak dapat diakses Mallory. Pertimbangkan bahwa Bob memiliki file rahasia C:\Users\Bob\secret.txt yang ingin dibaca Mallory. Dia tahu jalur ke file ini, tetapi dia tidak dapat membacanya karena Windows melarangnya mendapatkan akses ke direktori profil pengguna Bob.

Sebaliknya, Mallory menempatkan tautan keras ke penyimpanan di seluruh mesin. Ini adalah jenis file khusus yang tidak berisi konten apa pun, melainkan menunjuk ke file lain pada disk. Mencoba membaca file tautan keras akan membaca konten file yang ditargetkan oleh tautan. Setelah membuat tautan keras, Mallory masih tidak dapat membaca konten file karena dia tidak memiliki akses ke target (C:\Users\Bob\secret.txt) tautan. Namun, Bob memang memiliki akses ke file ini.

Ketika aplikasi Bob membaca dari store di seluruh komputer, sekarang secara tidak sengaja membaca konten filenya secret.txt, sama seperti jika file itu sendiri telah ada di penyimpanan di seluruh komputer. Ketika aplikasi Bob keluar, jika mencoba menyimpan kembali file ke store di seluruh komputer, akhirnya akan menempatkan salinan file aktual di direktori *C:\ProgramData\IsolatedStorage*. Karena direktori ini dapat dibaca oleh pengguna mana pun di komputer, Mallory sekarang dapat membaca konten file.

Praktik terbaik untuk bertahan dari serangan ini

Penting: Jika lingkungan Anda memiliki beberapa pengguna yang saling tidak tepercaya, jangan panggil API IsolatedStorageFile.GetEnumerator(IsolatedStorageScope.Machine) atau panggil alat storeadm.exe /machine /list. Keduanya mengasumsikan bahwa mereka beroperasi pada data tepercaya. Jika penyerang dapat menyemai payload berbahaya di store di seluruh mesin, payload tersebut dapat menyebabkan peningkatan serangan hak istimewa di bawah konteks pengguna yang menjalankan perintah ini.

Jika beroperasi di lingkungan multi-pengguna, pertimbangkan kembali penggunaan fitur penyimpanan terisolasi yang menargetkan cakupan Mesin . Jika aplikasi harus membaca data dari lokasi di seluruh komputer, lebih suka membaca data dari lokasi yang hanya dapat ditulis oleh akun admin. Direktori %PROGRAMFILES% dan HKLM sarang registri adalah contoh lokasi yang dapat ditulis oleh hanya administrator dan dapat dibaca oleh semua orang. Oleh karena itu, data yang dibaca dari lokasi tersebut dianggap dapat dipercaya.

Jika aplikasi harus menggunakan cakupan Mesin di lingkungan multi-pengguna, validasi konten file apa pun yang Anda baca dari store di seluruh komputer. Jika aplikasi mendeserialisasikan grafik objek dari file-file ini, pertimbangkan untuk menggunakan serializer yang lebih aman seperti XmlSerializer bukan serializer berbahaya seperti BinaryFormatter atau NetDataContractSerializer. Berhati-hatilah dengan grafik objek atau grafik objek berlapis dalam yang melakukan alokasi sumber daya berdasarkan konten file.

Lokasi Penyimpanan Terisolasi

Terkadang sangat membantu untuk memverifikasi perubahan pada penyimpanan terisolasi dengan menggunakan sistem file sistem operasi. Anda mungkin juga ingin mengetahui lokasi file penyimpanan yang terisolasi. Lokasi ini berbeda tergantung pada sistem operasi. Tabel berikut menunjukkan lokasi akar tempat penyimpanan terisolasi dibuat pada beberapa sistem operasi umum. Cari direktori Microsoft\IsolatedStorage di bagian lokasi akar ini. Anda harus mengubah pengaturan folder untuk menampilkan file dan folder tersembunyi untuk melihat penyimpanan terisolasi dalam sistem file.

Sistem operasi Lokasi dalam sistem file
Windows 2000, Windows XP, Windows Server 2003 (tingkatkan dari Windows NT 4.0) Store mendukung roaming =

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

Store nonroaming =

<SYSTEMROOT>\Profiles\<user>\Local Pengaturan\Application Data
Windows 2000 - instalasi bersih (dan peningkatan dari Windows 98 dan Windows NT 3.51) Store mendukung roaming =

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

Store nonroaming =

<SYSTEMDRIVE>\Documents and Pengaturan\<user>\Local Pengaturan\Application Data
Windows XP, Windows Server 2003 - penginstalan bersih (dan peningkatan dari Windows 2000 dan Windows 98) Store mendukung roaming =

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

Store nonroaming =

<SYSTEMDRIVE>\Documents and Pengaturan\<user>\Local Pengaturan\Application Data
Windows 8, Windows 7, Windows Server 2008, Windows Vista Store mendukung roaming =

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

Store nonroaming =

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

Membuat, Menghitung, dan Menghapus Penyimpanan Terisolasi

.NET menyediakan tiga kelas di System.IO.IsolatedStorage namespace layanan untuk membantu Anda melakukan tugas yang melibatkan penyimpanan terisolasi:

Kelas penyimpanan terisolasi memungkinkan Anda membuat, menghitung, dan menghapus penyimpanan terisolasi. Metode untuk melakukan tugas-tugas ini tersedia melalui IsolatedStorageFile objek . Beberapa operasi mengharuskan Anda memiliki IsolatedStorageFilePermission izin yang mewakili hak untuk mengelola penyimpanan terisolasi; Anda mungkin juga perlu memiliki hak sistem operasi untuk mengakses file atau direktori.

Untuk serangkaian contoh yang menunjukkan tugas penyimpanan terisolasi umum, lihat topik cara penggunaan yang tercantum dalam Topik Terkait.

Skenario untuk Penyimpanan Terisolasi

Penyimpanan terisolasi berguna dalam banyak situasi, termasuk empat skenario ini:

  • Kontrol yang diunduh. Kontrol kode terkelola yang diunduh dari Internet tidak diizinkan untuk menulis ke hard drive melalui kelas I/O normal, tetapi mereka dapat menggunakan penyimpanan terisolasi untuk mempertahankan pengaturan pengguna dan status aplikasi.

  • Penyimpanan komponen bersama. Komponen yang dibagikan antar aplikasi dapat menggunakan penyimpanan terisolasi untuk menyediakan akses terkontrol ke store data.

  • Penyimpanan Server. Aplikasi server dapat menggunakan penyimpanan terisolasi untuk menyediakan store individual untuk sejumlah besar pengguna yang membuat permintaan ke aplikasi. Karena penyimpanan terisolasi selalu dipisahkan oleh pengguna, server harus meniru pengguna yang membuat permintaan. Dalam hal ini, data diisolasi berdasarkan identitas prinsipal, yang merupakan identitas yang sama yang digunakan aplikasi untuk membedakan antara penggunanya.

  • Roaming. Aplikasi juga dapat menggunakan penyimpanan terisolasi dengan profil pengguna roaming. Ini memungkinkan store terisolasi pengguna untuk menjelajah dengan profil.

Jangan gunakan penyimpanan terisolasi dalam situasi berikut:

  • Untuk menyimpan rahasia bernilai tinggi, seperti kunci atau kata sandi yang tidak terenkripsi, karena penyimpanan terisolasi tidak dilindungi dari kode yang sangat tepercaya, dari kode yang tidak dikelola, atau dari pengguna tepercaya komputer.

  • Untuk menyimpan kode.

  • Untuk menyimpan pengaturan konfigurasi dan penyebaran, administrator mana yang mengontrol. (Preferensi pengguna tidak dianggap sebagai pengaturan konfigurasi karena administrator tidak mengontrolnya.)

Banyak aplikasi menggunakan database untuk menyimpan dan mengisolasi data, dalam hal ini satu atau beberapa baris dalam database mungkin mewakili penyimpanan untuk pengguna tertentu. Anda dapat memilih untuk menggunakan penyimpanan terisolasi bukan database ketika jumlah pengguna kecil, ketika overhead penggunaan database signifikan, atau ketika tidak ada fasilitas database. Selain itu, ketika aplikasi memerlukan penyimpanan yang lebih fleksibel dan kompleks daripada apa yang disediakan baris dalam database, penyimpanan terisolasi dapat memberikan alternatif yang layak.

Judul Deskripsi
Jenis Isolasi Menjelaskan berbagai jenis isolasi.
Cara: Mendapatkan Store untuk Penyimpanan Terisolasi Menyediakan contoh penggunaan IsolatedStorageFile kelas untuk mendapatkan toko yang diisolasi oleh pengguna dan assembly.
Cara: Melakukan Enumerasi untuk Penyimpanan Terisolasi Memperlihatkan cara menggunakan IsolatedStorageFile.GetEnumerator metode untuk menghitung ukuran semua penyimpanan terisolasi untuk pengguna.
Cara: Menghapus Store di Penyimpanan Terisolasi Menunjukkan cara menggunakan metode dengan IsolatedStorageFile.Remove dua cara berbeda untuk menghapus penyimpanan terisolasi.
Cara: Mengantisipasi Kondisi Kehabisan Ruang dengan Penyimpanan Terisolasi Menunjukkan cara mengukur ruang yang tersisa di penyimpanan yang terisolasi.
Cara: Membuat File dan Direktori di Penyimpanan Terisolasi Menyediakan beberapa contoh pembuatan file dan direktori di penyimpanan terisolasi.
Cara: Menemukan File dan Direktori yang Ada di Penyimpanan Terisolasi Menunjukkan cara membaca struktur direktori dan file dalam penyimpanan terisolasi.
Cara: Membaca dan Menulis ke File di Penyimpanan Terisolasi Menyediakan contoh penulisan string ke file penyimpanan yang terisolasi dan membacanya kembali.
Cara: Menghapus File dan Direktori di Penyimpanan Terisolasi Menunjukkan cara menghapus file dan direktori penyimpanan yang terisolasi.
I/O File dan Aliran Menjelaskan bagaimana Anda dapat melakukan akses file dan aliran data yang sinkron dan asinkron.

Referensi