Gambaran Umum Perlindungan Data Inti ASP.NET

  • Artikel

Perlindungan data ASP.NET Core menyediakan API kriptografi untuk melindungi data, termasuk manajemen dan rotasi kunci.

Aplikasi web sering kali perlu menyimpan data sensitif keamanan. Windows menyediakan API perlindungan data, DPAPI, tetapi Windows DPAPI tidak dimaksudkan untuk digunakan dalam aplikasi web.

Tumpukan perlindungan data ASP.NET Core dirancang untuk berfungsi sebagai pengganti jangka panjang untuk <elemen machineKey> di ASP.NET 1.x - 4.x. Ini dirancang untuk mengatasi banyak kekurangan tumpukan kriptografi lama sambil menyediakan solusi out-of-the-box untuk sebagian besar kasus penggunaan aplikasi modern yang mungkin ditemui.

Pernyataan masalah

Pernyataan masalah keseluruhan dapat dinyatakan dengan tepat dalam satu kalimat: Saya perlu mempertahankan informasi tepercaya untuk pengambilan nanti, tetapi saya tidak mempercayai mekanisme persistensi. Dalam istilah web, ini mungkin ditulis sebagai "Saya perlu melakukan pulang-pergi status tepercaya melalui klien yang tidak tepercaya."

Contoh kanonis dari ini adalah token autentikasi cookie atau pembawa. Server menghasilkan token "Saya Groot dan memiliki izin xyz" dan menyerahkannya kepada klien. Pada tanggal mendatang klien akan menyajikan token itu kembali ke server, tetapi server membutuhkan semacam jaminan bahwa klien belum memalsukan token. Dengan demikian persyaratan pertama: keaslian (alias integritas, pemeriksa perubahan).

Karena status yang bertahan dipercaya oleh server, kami mengantisipasi bahwa status ini mungkin berisi informasi yang khusus untuk lingkungan operasi. Ini bisa dalam bentuk jalur file, izin, handel atau referensi tidak langsung lainnya, atau beberapa bagian lain dari data khusus server. Informasi tersebut umumnya tidak boleh diungkapkan kepada klien yang tidak tepercaya. Dengan demikian persyaratan kedua: kerahasiaan.

Akhirnya, karena aplikasi modern digabungkan, apa yang telah kita lihat adalah bahwa masing-masing komponen akan ingin memanfaatkan sistem ini tanpa memperhatikan komponen lain dalam sistem. Misalnya, jika komponen token pembawa menggunakan tumpukan ini, komponen tersebut harus beroperasi tanpa gangguan dari mekanisme anti-CSRF yang mungkin juga menggunakan tumpukan yang sama. Dengan demikian persyaratan akhir: isolasi.

Kami dapat memberikan batasan lebih lanjut untuk mempersempit cakupan kebutuhan kami. Kami berasumsi bahwa semua layanan yang beroperasi dalam cryptosystem sama-sama dipercaya dan bahwa data tidak perlu dihasilkan atau dikonsumsi di luar layanan di bawah kontrol langsung kami. Selain itu, kami mengharuskan operasi secepat mungkin karena setiap permintaan ke layanan web mungkin melalui cryptosystem satu atau beberapa kali. Ini membuat kriptografi simetris ideal untuk skenario kami, dan kami dapat mendiskon kriptografi asimetris sampai waktu yang diperlukan.

Filsafat desain

Kami mulai dengan mengidentifikasi masalah dengan tumpukan yang ada. Setelah kami memilikinya, kami menyurvei lanskap solusi yang ada dan menyimpulkan bahwa tidak ada solusi yang cukup memiliki kemampuan yang kamicari. Kami kemudian merekayasa solusi berdasarkan beberapa prinsip panduan.

  • Sistem harus menawarkan kesederhanaan konfigurasi. Idealnya sistem akan menjadi konfigurasi nol dan pengembang dapat mencapai tanah yang berjalan. Dalam situasi di mana pengembang perlu mengonfigurasi aspek tertentu (seperti repositori kunci), pertimbangan harus diberikan untuk membuat konfigurasi spesifik tersebut sederhana.

  • Menawarkan API sederhana yang menghadap konsumen. API harus mudah digunakan dengan benar dan sulit digunakan dengan benar.

  • Pengembang seharusnya tidak perlu mempelajari prinsip manajemen utama. Sistem harus menangani pemilihan algoritma dan masa pakai kunci atas nama pengembang. Idealnya pengembang bahkan tidak boleh memiliki akses ke bahan kunci mentah.

  • Kunci harus dilindungi saat tidak aktif jika memungkinkan. Sistem harus mencari tahu mekanisme perlindungan default yang sesuai dan menerapkannya secara otomatis.

Dengan mengingat prinsip-prinsip ini, kami mengembangkan tumpukan perlindungan data yang sederhana dan mudah digunakan .

API perlindungan data ASP.NET Core terutama tidak ditujukan untuk persistensi muatan rahasia yang tidak terbatas. Teknologi lain seperti Windows CNG DPAPI dan Azure Rights Management lebih cocok untuk skenario penyimpanan yang tidak terbatas, dan mereka memiliki kemampuan manajemen kunci yang sesuai dan kuat. Meskipun demikian, tidak ada yang melarang pengembang menggunakan API perlindungan data ASP.NET Core untuk perlindungan jangka panjang data rahasia.

Audiens

Sistem perlindungan data dibagi menjadi lima paket utama. Berbagai aspek API ini menargetkan tiga audiens utama;

  1. Aplikasi target gambaran umum API Konsumen dan pengembang kerangka kerja.

    "Saya tidak ingin mempelajari tentang bagaimana tumpukan beroperasi atau tentang bagaimana tumpukan dikonfigurasi. Saya hanya ingin melakukan beberapa operasi sesingkat mungkin dengan kemungkinan besar menggunakan API dengan sukses."

  2. API konfigurasi menargetkan pengembang aplikasi dan administrator sistem.

    "Saya perlu memberi tahu sistem perlindungan data bahwa lingkungan saya memerlukan jalur atau pengaturan non-default."

  3. API ekstensibilitas menargetkan pengembang yang bertugas menerapkan kebijakan kustom. Penggunaan API ini akan terbatas pada situasi langka dan pengembang sadar keamanan yang berpengalaman.

    "Saya perlu mengganti seluruh komponen dalam sistem karena saya memiliki persyaratan perilaku yang benar-benar unik. Saya bersedia mempelajari bagian yang jarang digunakan dari permukaan API untuk membangun plugin yang memenuhi kebutuhan saya."

Tata letak paket

Tumpukan perlindungan data terdiri dari lima paket.

Sumber Daya Tambahan: