Pengantin untuk mengamankan pengembangan aplikasi Windows

2024-07-08

Artikel pengantar ini membantu arsitek dan pengembang aplikasi lebih memahami berbagai kemampuan platform Windows 10 yang mempercepat pembuatan aplikasi Platform Windows Universal aman (UWP). Ini merinci cara menggunakan fitur keamanan Windows yang tersedia di setiap tahap berikut: autentikasi, data dalam penerbangan, dan data tidak aktif. Anda dapat menemukan informasi lebih mendalam tentang setiap topik dengan meninjau sumber daya tambahan yang disertakan dalam setiap bab.

1 Pendahuluan

Mengembangkan aplikasi yang aman bisa menjadi tantangan. Dalam dunia aplikasi perusahaan yang serba cepat saat ini, seluler, sosial, cloud, dan kompleks, pelanggan mengharapkan aplikasi tersedia dan diperbarui lebih cepat dari sebelumnya. Mereka juga menggunakan banyak jenis perangkat, semakin menambah kompleksitas menciptakan pengalaman aplikasi. Jika Anda membangun untuk Windows Platform Windows Universal (UWP), yang dapat mencakup daftar tradisional desktop, laptop, tablet, dan perangkat seluler; selain daftar perangkat baru yang berkembang yang mencakup Internet of Things, Xbox One, Microsoft Surface Hub, dan HoloLens. Sebagai pengembang, Anda harus memastikan aplikasi Anda berkomunikasi dan menyimpan data dengan aman, di semua platform atau perangkat yang terlibat.

Berikut adalah beberapa manfaat memanfaatkan fitur keamanan Windows.

Anda akan memiliki keamanan standar di semua perangkat yang mendukung Windows, dengan menggunakan API yang konsisten untuk komponen dan teknologi keamanan.
Anda menulis, menguji, dan mempertahankan lebih sedikit kode daripada yang Anda lakukan jika Anda menerapkan kode kustom untuk mencakup skenario keamanan ini.
Aplikasi Anda menjadi lebih stabil dan aman karena Anda menggunakan sistem operasi untuk mengontrol bagaimana aplikasi mengakses sumber dayanya dan sumber daya sistem lokal atau jarak jauh.

Selama autentikasi, identitas pengguna yang meminta akses ke layanan tertentu divalidasi. Windows Hello adalah komponen di Windows yang membantu membuat mekanisme autentikasi yang lebih aman di aplikasi Windows. Dengan itu, Anda dapat menggunakan Nomor Identifikasi Pribadi (PIN) atau biometrik seperti sidik jari, wajah, atau iris pengguna untuk menerapkan autentikasi multifaktor untuk aplikasi Anda.

Data dalam penerbangan mengacu pada koneksi dan pesan yang ditransfer di seluruhnya. Contohnya adalah mengambil data dari server jarak jauh menggunakan layanan web. Penggunaan Secure Sockets Layer (SSL) dan Secure Hypertext Transfer Protocol (HTTPS) memastikan keamanan koneksi. Mencegah pihak perantara mengakses pesan-pesan ini, atau aplikasi yang tidak sah berkomunikasi dengan layanan web, adalah kunci untuk mengamankan data dalam penerbangan.

Terakhir, data tidak aktif berkaitan dengan data yang berada di memori atau di media penyimpanan. Aplikasi Windows memiliki model aplikasi yang mencegah akses data yang tidak sah antara aplikasi, dan menawarkan API enkripsi untuk lebih mengamankan data di perangkat. Fitur yang disebut Credential Locker dapat digunakan untuk menyimpan kredensial pengguna dengan aman di perangkat, dengan sistem operasi yang mencegah aplikasi lain mengaksesnya.

2 Faktor Autentikasi

Untuk melindungi data, orang yang meminta akses ke data tersebut harus diidentifikasi dan diizinkan untuk mengakses sumber daya data yang mereka minta. Proses mengidentifikasi pengguna disebut autentikasi, dan menentukan hak istimewa akses ke sumber daya disebut otorisasi. Ini adalah operasi yang terkait erat, dan kepada pengguna mereka mungkin tidak dapat dibedakan. Mereka bisa operasi yang relatif sederhana atau kompleks, tergantung pada banyak faktor: misalnya, apakah data berada di satu server atau didistribusikan di banyak sistem. Server yang menyediakan layanan autentikasi dan otorisasi disebut sebagai Penyedia Identitas.

Untuk mengautentikasi diri mereka dengan layanan dan/atau aplikasi tertentu, pengguna menggunakan kredensial yang terdiri dari sesuatu yang mereka ketahui, sesuatu yang mereka miliki, dan/atau sesuatu yang mereka miliki. Masing-masing disebut faktor autentikasi.

Sesuatu yang diketahui pengguna biasanya merupakan kata sandi, tetapi juga dapat menjadi nomor identifikasi pribadi (PIN) atau pasangan tanya jawab "rahasia".
Sesuatu yang paling sering dimiliki pengguna adalah perangkat memori perangkat keras seperti stik USB yang berisi data autentikasi yang unik bagi pengguna.
Sesuatu yang sering kali mencakup sidik jari mereka, tetapi ada faktor-faktor yang semakin populer seperti karakteristik ucapan, wajah, mata (mata) pengguna, atau pola perilaku. Ketika disimpan sebagai data, pengukuran ini disebut biometrik.

Kata sandi yang dibuat oleh pengguna adalah faktor autentikasi itu sendiri, tetapi sering kali tidak cukup; siapa pun yang tahu kata sandi dapat meniru pengguna yang memilikinya. Kartu pintar dapat memberikan tingkat keamanan yang lebih tinggi, tetapi mungkin dicuri, hilang, atau salah taruh. Sistem yang dapat mengautentikasi pengguna dengan sidik jari mereka atau dengan pemindaian okular mungkin memberikan tingkat keamanan tertinggi dan paling nyaman, tetapi memerlukan perangkat keras mahal dan khusus (misalnya, kamera Intel RealSense untuk pengenalan wajah) yang mungkin tidak tersedia untuk semua pengguna.

Merancang metode autentikasi yang digunakan oleh sistem adalah aspek keamanan data yang kompleks dan penting. Secara umum, semakin banyak faktor yang Anda gunakan dalam autentikasi, semakin aman sistemnya. Pada saat yang sama, autentikasi harus dapat digunakan. Pengguna biasanya akan masuk berkali-kali sehari, sehingga prosesnya harus cepat. Pilihan jenis autentikasi Anda adalah trade-off antara keamanan dan kemudahan penggunaan; autentikasi faktor tunggal adalah autentikasi yang paling tidak aman dan paling mudah digunakan, dan autentikasi multifaktor menjadi lebih aman, tetapi lebih kompleks karena lebih banyak faktor ditambahkan.

2.1 Autentikasi faktor tunggal

Bentuk autentikasi ini didasarkan pada satu kredensial pengguna. Ini biasanya kata sandi, tetapi juga bisa menjadi nomor identifikasi pribadi (PIN).

Berikut proses autentikasi faktor tunggal.

Pengguna menyediakan nama pengguna dan kata sandi mereka ke idP. Penyedia identitas adalah proses server yang memverifikasi identitas pengguna.
IdP memeriksa apakah nama pengguna dan kata sandi sama dengan yang disimpan dalam sistem. Dalam kebanyakan kasus, kata sandi akan dienkripsi, memberikan keamanan tambahan sehingga orang lain tidak dapat membacanya.
IdP mengembalikan status autentikasi yang menunjukkan apakah autentikasi berhasil.
Jika berhasil, pertukaran data dimulai. Jika tidak berhasil, pengguna harus diautentikasi ulang.

autentikasi faktor tunggal

Saat ini, metode autentikasi ini adalah yang paling umum digunakan di seluruh layanan. Ini juga merupakan bentuk autentikasi yang paling tidak aman ketika digunakan sebagai satu-satunya cara autentikasi. Persyaratan kompleksitas kata sandi, "pertanyaan rahasia," dan perubahan kata sandi reguler dapat membuat penggunaan kata sandi lebih aman, tetapi mereka lebih membebani pengguna dan mereka bukan jera yang efektif terhadap peretas.

Tantangan dengan kata sandi adalah lebih mudah untuk menebaknya dengan sukses daripada sistem yang memiliki lebih dari satu faktor. Jika mereka mencuri database dengan akun pengguna dan kata sandi yang di-hash dari toko web kecil, mereka dapat menggunakan kata sandi yang digunakan di situs web lain. Pengguna cenderung menggunakan kembali akun sepanjang waktu, karena kata sandi yang kompleks sulit diingat. Untuk departemen IT, mengelola kata sandi juga membawa kompleksitas harus menawarkan mekanisme reset, membutuhkan pembaruan kata sandi yang sering, dan menyimpannya dengan cara yang aman.

Untuk semua kelemahannya, autentikasi faktor tunggal memberi pengguna kontrol kredensial. Mereka membuatnya dan memodifikasinya, dan hanya keyboard yang diperlukan untuk proses autentikasi. Ini adalah aspek utama yang membedakan faktor tunggal dari autentikasi multifaktor.

2.1.1 Broker autentikasi web

Seperti yang telah dibahas sebelumnya, salah satu tantangan dengan autentikasi kata sandi untuk departemen IT adalah overhead tambahan dalam mengelola basis nama pengguna/kata sandi, mekanisme reset, dll. Opsi yang semakin populer adalah mengandalkan penyedia identitas pihak ketiga yang menawarkan autentikasi melalui OAuth, standar terbuka untuk autentikasi.

Menggunakan OAuth, departemen TI dapat secara efektif "mengalihdayakan" kompleksitas memelihara database dengan nama pengguna dan kata sandi, mengatur ulang fungsionalitas kata sandi, dll. ke penyedia identitas pihak ketiga seperti Facebook, X atau Microsoft.

Pengguna memiliki kontrol penuh atas identitas mereka di platform ini, tetapi aplikasi dapat meminta token dari penyedia, setelah pengguna diautentikasi dan dengan persetujuan mereka, yang dapat digunakan untuk mengotorisasi pengguna yang diautentikasi.

Broker autentikasi web di Windows menyediakan sekumpulan API dan infrastruktur bagi aplikasi untuk menggunakan protokol autentikasi dan otorisasi seperti OAuth dan OpenID. Aplikasi dapat memulai operasi autentikasi melalui WEBAuthenticationBroker API, yang menghasilkan pengembalian WebAuthenticationResult. Gambaran umum alur komunikasi diilustrasikan dalam gambar berikut.

alur kerja wab

Aplikasi ini bertindak sebagai broker, memulai autentikasi dengan penyedia identitas melalui WebView di aplikasi. Ketika penyedia identitas telah mengautentikasi pengguna, idP mengembalikan token ke aplikasi yang dapat digunakan untuk meminta informasi tentang pengguna dari penyedia identitas. Sebagai langkah keamanan, aplikasi harus terdaftar di IdP sebelum dapat memperantarai proses autentikasi dengan penyedia identitas. Langkah-langkah pendaftaran ini berbeda untuk setiap penyedia.

Berikut adalah alur kerja umum untuk memanggil WEBAuthenticationBroker API untuk berkomunikasi dengan penyedia.

Buat string permintaan yang akan dikirim ke IdP. Jumlah string, dan informasi di setiap string, berbeda untuk setiap layanan web tetapi biasanya mencakup dua string URI yang masing-masing berisi URL: satu di mana permintaan autentikasi dikirim, dan satu di mana pengguna dialihkan setelah otorisasi selesai.
Panggil WebAuthenticationBroker.AuthenticateAsync, meneruskan string permintaan, dan tunggu respons dari IdP.
Panggil WebAuthenticationResult.ResponseStatus untuk mendapatkan status saat respons diterima.
Jika komunikasi berhasil, proses string respons yang dikembalikan oleh IdP. Jika tidak berhasil, proses kesalahan.

Jika komunikasi berhasil, proses string respons yang dikembalikan oleh IdP. Jika tidak berhasil, proses kesalahan.

Contoh kode C# yang untuk proses ini ada di bawah ini. Untuk informasi dan panduan terperinci, lihat WebAuthenticationBroker. Untuk sampel kode lengkap, lihat sampel WebAuthenticationBroker di GitHub.

string startURL = "https://<providerendpoint>?client_id=<clientid>";
string endURL = "http://<AppEndPoint>";

var startURI = new System.Uri(startURL);
var endURI = new System.Uri(endURL);

try
{
    WebAuthenticationResult webAuthenticationResult = 
        await WebAuthenticationBroker.AuthenticateAsync( 
            WebAuthenticationOptions.None, startURI, endURI);

    switch (webAuthenticationResult.ResponseStatus)
    {
        case WebAuthenticationStatus.Success:
            // Successful authentication. 
            break;
        case WebAuthenticationStatus.ErrorHttp:
            // HTTP error. 
            break;
        default:
            // Other error.
        break;
    }
}
catch (Exception ex)
{
    // Authentication failed. Handle parameter, SSL/TLS, and
    // Network Unavailable errors here. 
}

2.2 Autentikasi multifaktor

Autentikasi multifaktor menggunakan lebih dari satu faktor autentikasi. Biasanya, "sesuatu yang Anda ketahui," seperti kata sandi, dikombinasikan dengan "sesuatu yang Anda miliki," yang bisa menjadi ponsel atau kartu pintar. Bahkan jika penyerang menemukan kata sandi pengguna, akun masih tidak dapat diakses tanpa perangkat atau kartu. Dan jika hanya perangkat atau kartu yang disusupi, itu tidak berguna bagi penyerang tanpa kata sandi. Oleh karena itu, autentikasi multifaktor lebih aman, tetapi juga lebih kompleks, daripada autentikasi faktor tunggal.

Layanan yang menggunakan autentikasi multifaktor akan sering memberi pengguna pilihan dalam cara mereka menerima kredensial kedua. Contoh jenis autentikasi ini adalah proses yang umum digunakan di mana kode verifikasi dikirim ke ponsel pengguna menggunakan SMS.

Pengguna menyediakan nama pengguna dan kata sandi mereka ke idP.
IdP memverifikasi nama pengguna dan kata sandi seperti dalam otorisasi faktor tunggal, lalu mencari nomor ponsel pengguna yang disimpan dalam sistem.
Server mengirimkan pesan SMS yang berisi kode verifikasi yang dihasilkan ke ponsel pengguna.
Pengguna menyediakan kode verifikasi kepada IdP; melalui formulir yang disajikan kepada pengguna.
IdP mengembalikan status autentikasi yang menunjukkan apakah autentikasi kedua kredensial berhasil.
Jika berhasil, pertukaran data dimulai. Jika tidak, pengguna harus diautentikasi ulang.

autentikasi dua faktor

Seperti yang Anda lihat, proses ini juga berbeda dari autentikasi faktor tunggal karena kredensial pengguna kedua dikirim ke pengguna alih-alih dibuat atau disediakan oleh pengguna. Oleh karena itu, pengguna tidak memegang kendali penuh atas kredensial yang diperlukan. Ini juga berlaku ketika kartu pintar digunakan sebagai kredensial kedua: organisasi bertanggung jawab untuk membuat dan memberikannya kepada pengguna.

2.2.1 Azure Active Directory

Azure Active Directory (Azure AD) adalah layanan manajemen identitas dan akses berbasis cloud yang dapat berfungsi sebagai penyedia identitas dalam autentikasi faktor tunggal atau multifaktor. Autentikasi Azure ACTIVE Directory dapat digunakan dengan atau tanpa kode verifikasi.

Meskipun Azure AD juga dapat menerapkan autentikasi faktor tunggal, perusahaan biasanya memerlukan keamanan autentikasi multifaktor yang lebih tinggi. Dalam konfigurasi autentikasi multifaktor, pengguna yang mengautentikasi dengan akun Microsoft Azure AD memiliki opsi untuk mengirim kode verifikasi sebagai pesan SMS baik ke ponsel atau aplikasi seluler Azure Authenticator.

Selain itu, Azure ACTIVE Directory dapat digunakan sebagai penyedia OAuth, menyediakan mekanisme autentikasi dan otorisasi kepada pengguna standar ke aplikasi di berbagai platform. Untuk mempelajari selengkapnya, lihat Azure Active Directory dan Autentikasi Multifaktor di Azure.

2.4 Windows Hello

Di Windows, mekanisme autentikasi multifaktor yang nyaman dibangun ke dalam sistem operasi. Windows Hello adalah sistem masuk biometrik baru yang terpasang di Windows. Karena dibangun langsung ke dalam sistem operasi, Windows Hello memungkinkan identifikasi wajah atau sidik jari untuk membuka kunci perangkat pengguna. Penyimpanan kredensial aman Windows melindungi data biometrik pada perangkat.

Windows Hello menyediakan cara yang kuat bagi perangkat untuk mengenali pengguna individual, yang membahas bagian pertama dari jalur antara pengguna dan layanan atau item data yang diminta. Setelah perangkat mengenali pengguna, perangkat masih harus mengautentikasi pengguna sebelum menentukan apakah akan memberikan akses ke sumber daya yang diminta. Windows Hello juga menyediakan autentikasi dua faktor (2FA) yang kuat yang sepenuhnya diintegrasikan ke dalam Windows dan mengganti kata sandi yang dapat digunakan kembali dengan kombinasi perangkat tertentu, dan gerakan biometrik atau PIN. PIN ditentukan oleh pengguna sebagai bagian dari pendaftaran akun Microsoft mereka.

Windows Hello bukan hanya pengganti sistem 2FA tradisional. Ini secara konseptual mirip dengan kartu pintar: autentikasi dilakukan dengan menggunakan primitif kriptografi alih-alih perbandingan string, dan materi kunci pengguna aman di dalam perangkat keras tahan perubahan. Microsoft Hello juga tidak memerlukan komponen infrastruktur tambahan yang diperlukan untuk penyebaran kartu pintar. Secara khusus, Anda tidak memerlukan Infrastruktur Kunci Umum (PKI) untuk mengelola sertifikat, jika Saat ini Anda tidak memilikinya. Windows Hello menggabungkan keuntungan utama kartu pintar—fleksibilitas penyebaran untuk kartu pintar virtual dan keamanan yang kuat untuk kartu pintar fisik—tanpa kekurangannya.

Perangkat harus didaftarkan dengan Windows Hello sebelum pengguna dapat mengautentikasi dengannya. Windows Hello menggunakan enkripsi asimetris (kunci publik/privat) di mana satu pihak menggunakan kunci publik untuk mengenkripsi data yang dapat didekripsi pihak lain menggunakan kunci privat. Dalam kasus Windows Hello, ia membuat sekumpulan pasangan kunci publik/privat dan menulis kunci privat ke chip Trusted Platform Module (TPM) perangkat. Setelah perangkat terdaftar, aplikasi UWP dapat memanggil API sistem untuk mengambil kunci publik pengguna, yang dapat digunakan untuk mendaftarkan pengguna di server.

Alur kerja pendaftaran aplikasi mungkin terlihat seperti berikut ini:

pendaftaran windows hello

Informasi pendaftaran yang Anda kumpulkan mungkin mencakup lebih banyak informasi identifikasi daripada dalam skenario sederhana ini. Misalnya, jika aplikasi Anda mengakses layanan aman seperti untuk perbankan, Anda harus meminta bukti identitas dan hal-hal lain sebagai bagian dari proses pendaftaran. Setelah semua kondisi terpenuhi, kunci publik pengguna ini akan disimpan di back-end dan digunakan untuk memvalidasi saat pengguna menggunakan layanan berikutnya.

Untuk informasi selengkapnya tentang Windows Hello, lihat gambaran umum Windows Hello untuk Bisnis dan panduan pengembang Windows Hello.

3 Metode keamanan data-in-flight

Metode keamanan dalam penerbangan data berlaku untuk data saat transit antar perangkat yang terhubung ke jaringan. Data dapat ditransfer antara sistem pada lingkungan keamanan tinggi intranet perusahaan privat, atau antara klien dan layanan web di lingkungan web yang tidak aman. Aplikasi Windows mendukung standar seperti SSL melalui API jaringan mereka, dan bekerja dengan teknologi seperti Azure API Management yang dengannya pengembang dapat memastikan tingkat keamanan yang sesuai untuk aplikasi mereka.

3.1 Autentikasi sistem jarak jauh

Ada dua skenario umum di mana komunikasi terjadi dengan sistem komputer jarak jauh.

Server lokal mengautentikasi pengguna melalui koneksi langsung. Misalnya, ketika server dan klien berada di intranet perusahaan.
Layanan web dikomunikasikan dengan melalui Internet.

Persyaratan keamanan untuk komunikasi layanan web lebih tinggi daripada yang ada dalam skenario koneksi langsung, karena data tidak lagi hanya bagian dari jaringan yang aman dan kemungkinan penyerang berbahaya yang ingin mencegat data juga lebih tinggi. Karena berbagai jenis perangkat akan mengakses layanan, mereka kemungkinan akan dibangun sebagai layanan RESTful, dibandingkan dengan WCF, misalnya, yang berarti autentikasi dan otorisasi ke layanan juga memperkenalkan tantangan baru. Kita akan membahas dua persyaratan untuk komunikasi sistem jarak jauh yang aman.

Persyaratan pertama adalah kerahasiaan pesan: Informasi yang diteruskan antara klien dan layanan web (misalnya, identitas pengguna dan informasi pribadi lainnya) tidak boleh dibaca oleh pihak ketiga saat transit. Ini biasanya dicapai dengan mengenkripsi koneksi tempat pesan dikirim dan dengan mengenkripsi pesan itu sendiri. Dalam enkripsi kunci privat/publik, kunci publik tersedia untuk siapa saja, dan digunakan untuk mengenkripsi pesan yang akan dikirim ke penerima tertentu. Kunci privat hanya dipegang oleh penerima dan digunakan untuk mendekripsi pesan.

Persyaratan kedua adalah integritas pesan: Klien dan layanan web harus dapat memverifikasi bahwa pesan yang mereka terima adalah yang dimaksudkan untuk dikirim oleh pihak lain, dan bahwa pesan belum diubah saat transit. Ini dicapai dengan menandatangani pesan dengan tanda tangan digital dan menggunakan autentikasi sertifikat.

3.2 Koneksi SSL

Untuk membuat dan memelihara koneksi aman ke klien, layanan web dapat menggunakan Secure Sockets Layer (SSL), yang didukung oleh Secure Hypertext Transfer Protocol (HTTPS). SSL memberikan kerahasiaan dan integritas pesan dengan mendukung enkripsi kunci publik serta sertifikat server. SSL digantikan oleh Keamanan Lapisan Transportasi (TLS), tetapi TLS sering disebut dengan santai sebagai SSL.

Ketika klien meminta akses ke sumber daya di server, SSL memulai proses negosiasi dengan server. Ini disebut jabat tangan SSL. Tingkat enkripsi, sekumpulan kunci enkripsi publik dan privat, dan informasi identitas dalam sertifikat klien dan server disepakati sebagai dasar semua komunikasi selama durasi koneksi SSL. Server mungkin juga mengharuskan klien untuk diautentikasi saat ini. Setelah koneksi dibuat, semua pesan dienkripsi dengan kunci publik yang dinegosiasikan hingga koneksi ditutup.

3.2.1 Penyematan SSL

Meskipun SSL dapat memberikan kerahasiaan pesan menggunakan enkripsi dan sertifikat, SSL tidak melakukan apa pun untuk memverifikasi bahwa server tempat klien berkomunikasi adalah yang benar. Perilaku server dapat dimigrasikan oleh pihak ketiga yang tidak sah, mencegat data sensitif yang dikirimkan klien. Untuk mencegah hal ini, teknik yang disebut penyematan SSL digunakan untuk memverifikasi bahwa sertifikat di server adalah sertifikat yang diharapkan dan dipercaya klien.

Ada beberapa cara berbeda untuk menerapkan penyematan SSL di aplikasi, masing-masing dengan pro dan kontra mereka sendiri. Pendekatan termampu adalah melalui deklarasi Sertifikat dalam manifes paket aplikasi. Deklarasi ini memungkinkan paket aplikasi untuk menginstal sertifikat digital dan menentukan kepercayaan eksklusif padanya. Hal ini mengalihkan koneksi SSL yang diizinkan hanya antara aplikasi dan server yang memiliki sertifikat yang sesuai dalam rantai sertifikat mereka. Mekanisme ini juga memungkinkan penggunaan sertifikat yang ditandatangani sendiri dengan aman, karena tidak ada dependensi pihak ketiga yang diperlukan pada otoritas sertifikasi publik tepercaya.

manifes ssl

Untuk kontrol lebih lanjut atas logika validasi, API tersedia untuk memvalidasi sertifikat yang dikembalikan oleh server sebagai respons terhadap permintaan HTTPS. Perhatikan bahwa metode ini memerlukan pengiriman permintaan dan memeriksa respons, jadi pastikan untuk menambahkan ini sebagai validasi sebelum benar-benar mengirim informasi sensitif dalam permintaan.

Kode C# berikut mengilustrasikan metode penyematan SSL ini. Metode ValidateSSLRoot menggunakan kelas HttpClient untuk menjalankan permintaan HTTP. Setelah klien mengirim respons, klien menggunakan koleksi RequestMessage.TransportInformation.ServerIntermediateCertificates untuk memeriksa sertifikat yang dikembalikan oleh server. Klien kemudian dapat memvalidasi seluruh rantai sertifikat dengan thumbprint yang telah disertakannya. Metode ini memang mengharuskan thumbprint sertifikat diperbarui di aplikasi ketika sertifikat server kedaluwarsa dan diperbarui.

private async Task ValidateSSLRoot()
{
    // Send a get request to Bing
    var httpClient = new HttpClient();
    var bingUri = new Uri("https://www.bing.com");
    HttpResponseMessage response = 
        await httpClient.GetAsync(bingUri);

    // Get the list of certificates that were used to
    // validate the server's identity
    IReadOnlyList<Certificate> serverCertificates = response.RequestMessage.TransportInformation.ServerIntermediateCertificates;
  
    // Perform validation
    if (!ValidateCertificates(serverCertificates))
    {
        // Close connection as chain is not valid
        return;
    }
    // Validation passed, continue with connection to service
}

private bool ValidateCertificates(IReadOnlyList<Certificate> certs)
{
    // In this example, we iterate through the certificates
    // and check that the chain contains
    // one specific certificate we are expecting
    foreach (var cert in certs)
    {
        byte[] thumbprint = cert.GetHashValue();

        // Check if the thumbprint matches whatever you 
        // are expecting
        var expected = new byte[] { 212, 222, 32, 208, 94, 102, 
            252, 83, 254, 26, 80, 136, 44, 120, 219, 40, 82, 202, 
            228, 116 };

        // ThumbprintMatches does the byte[] comparison 
        if (ThumbprintMatches(thumbprint, expected))
        {
            return true;
        }
    }
    return false;
}

3.3 Menerbitkan dan mengamankan akses ke REST API

Untuk memastikan akses resmi ke layanan web, mereka harus memerlukan autentikasi setiap kali panggilan API dilakukan. Mampu mengontrol performa dan skala juga merupakan sesuatu yang perlu dipertimbangkan ketika layanan web diekspos di seluruh web. Azure API Management adalah layanan yang dapat membantu mengekspos API di seluruh web, sekaligus menyediakan fitur pada tiga tingkat.

Penerbit/Administrator API dapat dengan mudah mengonfigurasi API melalui Portal Penerbit Azure API Management. Di sini, set API dapat dibuat dan akses ke set API dapat dikelola untuk mengontrol siapa yang memiliki akses ke API mana.

Pengembang yang menginginkan akses ke API ini dapat membuat permintaan melalui Portal Pengembang, yang dapat segera memberikan akses atau memerlukan persetujuan oleh penerbit/administrator. Pengembang juga dapat melihat dokumentasi API dan kode sampel di Portal Pengembang, untuk mengadopsi API yang ditawarkan oleh layanan web dengan cepat.

Aplikasi yang dibuat pengembang ini kemudian mengakses API melalui proksi yang ditawarkan oleh Azure API Management. Proksi keduanya menyediakan lapisan ketidakjelasan, menyembunyikan titik akhir aktual API di server penerbit/administrator dan juga dapat menyertakan logika tambahan seperti terjemahan API untuk memastikan API yang diekspos tetap konsisten ketika panggilan ke satu API dialihkan ke API lain. Ini juga dapat menggunakan pemfilteran IP untuk memblokir panggilan API yang berasal dari domain IP atau sekumpulan domain tertentu. Azure API Management juga menjaga keamanan layanan webnya dengan menggunakan sekumpulan kunci publik, yang disebut kunci API, untuk mengautentikasi dan mengotorisasi setiap panggilan API. Ketika otorisasi gagal, akses ke API dan fungsionalitas yang didukungnya diblokir.

Azure API Management juga dapat mengurangi jumlah panggilan API ke layanan (prosedur yang disebut pembatasan) untuk mengoptimalkan performa layanan web. Untuk mempelajari lebih lanjut, tinjau Azure API Management dan Azure API Management di AzureCon 2015.

4 Metode keamanan data tidak aktif

Ketika data tiba di perangkat, kami menyebutnya sebagai "data tidak aktif." Data ini perlu disimpan di perangkat dengan cara yang aman, sehingga tidak dapat diakses oleh pengguna atau aplikasi yang tidak sah. Model aplikasi di Windows melakukan banyak hal untuk memastikan bahwa data yang disimpan oleh aplikasi apa pun hanya dapat diakses oleh aplikasi tersebut, sambil menyediakan API untuk berbagi data jika diperlukan. API tambahan juga tersedia untuk memastikan bahwa data dapat dienkripsi dan kredensial dapat disimpan dengan aman.

Model aplikasi Windows 4.1

Secara tradisional, Windows tidak pernah memiliki definisi aplikasi. Ini paling sering disebut sebagai executable (.exe), dan ini tidak pernah termasuk penginstalan, penyimpanan status, panjang eksekusi, penerapan versi, integrasi OS, atau komunikasi aplikasi-ke-aplikasi. Model Platform Windows Universal mendefinisikan model aplikasi yang mencakup penginstalan, lingkungan runtime, manajemen sumber daya, pembaruan, model data, dan penghapusan instalasi.

Aplikasi Windows 10 berjalan dalam kontainer, yang berarti bahwa mereka memiliki hak istimewa terbatas secara default (hak istimewa tambahan dapat diminta dan diberikan oleh pengguna). Misalnya, jika aplikasi ingin mengakses file pada sistem, pemilih file dari namespace Layanan Windows.Storage.Pickers harus digunakan untuk membiarkan pengguna memilih file (tidak ada akses langsung ke file yang diaktifkan). Contoh lain adalah jika aplikasi ingin mengakses data lokasi pengguna, aplikasi perlu mengaktifkan kemampuan perangkat lokasi perlu dideklarasikan, meminta pengguna pada waktu pengunduhan bahwa aplikasi ini akan meminta akses ke lokasi pengguna. Selain itu, pertama kali aplikasi ingin mengakses lokasi pengguna, permintaan persetujuan tambahan ditampilkan kepada pengguna, meminta izin untuk mengakses data.

Perhatikan bahwa model aplikasi ini bertindak sebagai "penjara" untuk aplikasi, yang berarti bahwa mereka tidak dapat menjangkau, tetapi bukan "kastil" yang tidak dapat dijangkau dari luar (aplikasi dengan hak istimewa administrator tentu saja masih dapat dijangkau). Device Guard di Windows, yang memungkinkan organisasi/TI menentukan aplikasi (Win32) mana yang diizinkan untuk dijalankan, selanjutnya dapat membantu membatasi akses ini.

Model aplikasi juga mengelola siklus hidup aplikasi. Ini membatasi eksekusi latar belakang aplikasi secara default, misalnya; segera setelah aplikasi masuk ke latar belakang, proses ditangguhkan - setelah memberi aplikasi periode singkat untuk mengatasi penangguhan aplikasi dalam kode - dan memorinya dibekukan. Sistem operasi menyediakan mekanisme bagi aplikasi untuk meminta eksekusi tugas latar belakang tertentu (sesuai jadwal, dipicu oleh berbagai peristiwa seperti konektivitas Internet/Bluetooth, perubahan daya, dll., dan dalam skenario tertentu seperti pemutaran musik atau pelacakan GPS).

Ketika sumber daya memori pada perangkat hampir habis, Windows membebaskan ruang memori dengan mengakhiri aplikasi. Model siklus hidup ini memaksa aplikasi untuk mempertahankan data setiap kali ditangguhkan, karena tidak ada waktu tambahan yang tersedia antara penangguhan dan penghentian.

Untuk informasi selengkapnya, lihat Ini Universal: Memahami Siklus Hidup Aplikasi Windows 10/11.

4.2 Perlindungan kredensial tersimpan

Aplikasi Windows yang mengakses layanan terautentikasi sering kali memberikan opsi kepada pengguna untuk menyimpan kredensial mereka di perangkat lokal. Ini adalah kenyamanan bagi pengguna; ketika mereka memberikan nama pengguna dan kata sandi mereka, aplikasi secara otomatis menggunakannya dalam peluncuran aplikasi berikutnya. Karena ini bisa menjadi masalah keamanan jika penyerang mendapatkan akses ke data tersimpan ini, Windows menyediakan kemampuan bagi aplikasi paket untuk menyimpan kredensial pengguna di loker kredensial yang aman. Aplikasi ini memanggil Credential Locker API untuk menyimpan dan mengambil kredensial dari loker alih-alih menyimpannya di kontainer penyimpanan aplikasi. Loker info masuk dikelola oleh sistem operasi, tetapi akses terbatas pada aplikasi yang menyimpannya, menyediakan solusi yang dikelola dengan aman untuk penyimpanan kredensial.

Ketika pengguna menyediakan kredensial untuk disimpan, aplikasi mendapatkan referensi ke loker kredensial menggunakan objek PasswordVault di namespace Layanan Windows.Security.Credentials. Kemudian membuat objek PasswordCredential yang berisi pengidentifikasi untuk aplikasi Windows dan nama pengguna dan kata sandi. Ini diteruskan ke metode PasswordVault.Add untuk menyimpan kredensial di loker. Contoh kode C# berikut menunjukkan bagaimana hal ini dilakukan.

var vault = new PasswordVault();
vault.Add(new PasswordCredential("My App", username, password));

Dalam contoh kode C#berikut, aplikasi meminta semua kredensial yang sesuai dengan aplikasi dengan memanggil metode FindAllByResource dari objek PasswordVault. Jika lebih dari satu dikembalikan, pengguna akan diminta untuk memasukkan nama pengguna mereka. Jika kredensial tidak ada di loker, aplikasi akan memintanya kepada pengguna. Pengguna kemudian masuk ke server menggunakan kredensial.

private string resourceName = "My App";
private string defaultUserName;

private void Login()
{
    PasswordCredential loginCredential = GetCredentialFromLocker();

    if (loginCredential != null)
    {
        // There is a credential stored in the locker.
        // Populate the Password property of the credential
        // for automatic login.
        loginCredential.RetrievePassword();
    }
    else
    {
        // There is no credential stored in the locker.
        // Display UI to get user credentials.
        loginCredential = GetLoginCredentialUI();
    }
    // Log the user in.
    ServerLogin(loginCredential.UserName, loginCredential.Password);
}

private PasswordCredential GetCredentialFromLocker()
{
    PasswordCredential credential = null;

    var vault = new PasswordVault();

    IReadOnlyList<PasswordCredential> credentialList = null;

    try
    {
        credentialList = vault.FindAllByResource(resourceName);
    }
    catch(Exception)
    {
        return null;
    }

    if (credentialList.Count == 1)
    {
        credential = credentialList[0];
    }
    else if (credentialList.Count > 0)
    {
        // When there are multiple usernames,
        // retrieve the default username. If one doesn't
        // exist, then display UI to have the user select
        // a default username.
        defaultUserName = GetDefaultUserNameUI();

        credential = vault.Retrieve(resourceName, defaultUserName);
    }
    return credential;
}

Untuk informasi selengkapnya, lihat Loker info masuk.

4.3 Perlindungan data tersimpan

Ketika Anda berurusan dengan data yang disimpan, biasanya disebut sebagai data tidak aktif, mengenkripsinya dapat mencegah pengguna yang tidak sah mengakses data yang disimpan. Dua mekanisme umum untuk mengenkripsi data menggunakan kunci konten atau menggunakan kunci asimetris. Namun, enkripsi data tidak dapat memastikan bahwa data tidak diubah antara waktu dikirim dan waktu penyimpanannya. Dengan kata lain, integritas data tidak dapat dipastikan. Menggunakan kode autentikasi pesan, hash, dan penandatanganan digital adalah teknik umum untuk menyelesaikan masalah ini.

4.3.1 Enkripsi data

Dengan enkripsi simetris, pengirim dan penerima memiliki kunci yang sama dan menggunakannya untuk mengenkripsi dan mendekripsi data. Tantangan dengan pendekatan ini adalah berbagi kunci dengan aman sehingga kedua belah pihak menyadarinya.

Satu jawaban untuk ini adalah enkripsi asimetris, di mana pasangan kunci publik/privat digunakan. Kunci publik dibagikan secara bebas dengan siapa pun yang ingin mengenkripsi pesan. Kunci privat selalu dirahasiakan sehingga hanya Anda yang dapat menggunakannya untuk mendekripsi data. Teknik umum untuk memungkinkan penemuan kunci publik adalah dengan menggunakan sertifikat digital, juga hanya disebut sebagai sertifikat. Sertifikat menyimpan informasi tentang kunci umum, selain informasi tentang pengguna atau server seperti nama, penerbit, alamat email, dan negara.

Pengembang aplikasi Windows dapat menggunakan kelas SymmetricKeyAlgorithmProvider dan AsymmetricKeyAlgorithmProvider untuk menerapkan enkripsi simetris dan asimetris di aplikasi UWP mereka. Selain itu, kelas CryptographicEngine dapat digunakan untuk mengenkripsi dan mendekripsi data, menandatangani konten, dan memverifikasi tanda tangan digital. Aplikasi juga dapat menggunakan kelas DataProtectionProvider di namespace layanan Windows.Security.Cryptography.DataProtection untuk mengenkripsi dan mendekripsi data lokal yang disimpan.

4.3.2 Mendeteksi perubahan pesan (MAC, hash, dan tanda tangan)

MAC adalah kode (atau tag) yang dihasilkan dari penggunaan kunci konten (disebut kunci rahasia) atau pesan sebagai input ke algoritma enkripsi MAC. Kunci rahasia dan algoritma disepakati oleh pengirim dan penerima sebelum transfer pesan.

MAC memverifikasi pesan seperti ini.

Pengirim memperoleh tag MAC dengan menggunakan kunci rahasia sebagai input ke algoritma MAC.
Pengirim mengirim tag MAC dan pesan ke penerima.
Penerima memperoleh tag MAC dengan menggunakan kunci rahasia dan pesan sebagai input ke algoritma MAC.
Penerima membandingkan tag MAC mereka dengan tag MAC pengirim. Jika mereka sama maka kita tahu bahwa pesan belum dirusak.

verifikasi mac

Aplikasi Windows dapat menerapkan verifikasi pesan MAC dengan memanggil kelas MacAlgorithmProvider untuk menghasilkan kunci dan kelas CryptographicEngine untuk melakukan algoritma enkripsi MAC.

4.3.3 Menggunakan hash

Fungsi hash adalah algoritma kriptografi yang mengambil blok data yang sangat panjang dan mengembalikan string bit ukuran tetap yang disebut nilai hash. Ada seluruh keluarga fungsi hash yang dapat melakukan ini.

Nilai hash dapat digunakan sebagai pengganti MAC dalam skenario transfer pesan di atas. Pengirim mengirim nilai hash dan pesan, dan penerima memperoleh nilai hash mereka sendiri dari nilai hash dan pesan pengirim dan membandingkan dua nilai hash. Aplikasi yang berjalan di Windows dapat memanggil kelas HashAlgorithmProvider untuk menghitung algoritma hash yang tersedia dan menjalankan salah satunya. Kelas CryptographicHash mewakili nilai hash. Metode CryptographicHash.GetValueAndReset dapat digunakan untuk berulang kali melakukan hash data yang berbeda tanpa harus membuat ulang objek untuk setiap penggunaan. Metode Tambahkan kelas CryptographicHash menambahkan data baru ke buffer untuk di-hash. Seluruh proses ini ditampilkan dalam contoh kode C# berikut.

public void SampleReusableHash()
{
    // Create a string that contains the name of the
    // hashing algorithm to use.
    string strAlgName = HashAlgorithmNames.Sha512;

    // Create a HashAlgorithmProvider object.
    HashAlgorithmProvider objAlgProv = HashAlgorithmProvider.OpenAlgorithm(strAlgName);

    // Create a CryptographicHash object. This object can be reused to continually
    // hash new messages.
    CryptographicHash objHash = objAlgProv.CreateHash();

    // Hash message 1.
    string strMsg1 = "This is message 1";
    IBuffer buffMsg1 = CryptographicBuffer.ConvertStringToBinary(strMsg1, BinaryStringEncoding.Utf16BE);
    objHash.Append(buffMsg1);
    IBuffer buffHash1 = objHash.GetValueAndReset();

    // Hash message 2.
    string strMsg2 = "This is message 2";
    IBuffer buffMsg2 = CryptographicBuffer.ConvertStringToBinary(strMsg2, BinaryStringEncoding.Utf16BE);
    objHash.Append(buffMsg2);
    IBuffer buffHash2 = objHash.GetValueAndReset();

    // Convert the hashes to string values (for display);
    string strHash1 = CryptographicBuffer.EncodeToBase64String(buffHash1);
    string strHash2 = CryptographicBuffer.EncodeToBase64String(buffHash2);
}

4.3.4 Tanda tangan digital

Integritas data pesan tersimpan yang ditandatangani secara digital diverifikasi dengan cara yang sama dengan autentikasi MAC. Berikut adalah cara alur kerja tanda tangan digital beroperasi.

Pengirim memperoleh nilai hash (juga dikenal sebagai hash) dengan menggunakan pesan sebagai input ke algoritma hash.
Pengirim mengenkripsi hash menggunakan kunci privat mereka.
Pengirim mengirim pesan, hash terenkripsi, dan nama algoritma hash yang digunakan.
Penerima menggunakan kunci publik untuk mendekripsi hash terenkripsi yang diterimanya. Kemudian menggunakan algoritma hash untuk hash pesan untuk membuat hash sendiri. Dan akhirnya penerima membandingkan dua hash (yang diterima dan didekripsi, dan yang dibuatnya). Hanya jika kedua kecocokan dapat penerima yakin bahwa pesan dikirim oleh pemilik kunci privat, dan oleh karena itu mereka adalah siapa yang mereka katakan, dan bahwa pesan tidak diubah saat transit.

tanda tangan digital

Algoritma hashing sangat cepat, sehingga nilai hash dapat diturunkan dengan cepat dari pesan besar sekalipun. Nilai hash yang dihasilkan adalah panjang sewenang-wenang dan dapat lebih pendek dari pesan lengkap, jadi menggunakan kunci publik dan privat untuk mengenkripsi dan mendekripsi hanya hash daripada pesan lengkap adalah pengoptimalan.

Untuk informasi selengkapnya, lihat artikel tentang Tanda tangan digital, MAC, hash, dan tanda tangan, dan Kriptografi.

5 Ringkasan

Platform Windows Universal di Windows menawarkan sejumlah cara untuk memanfaatkan kemampuan sistem operasi untuk membuat aplikasi yang lebih aman. Dalam skenario autentikasi yang berbeda, seperti autentikasi faktor tunggal, multifaktor, atau broker dengan penyedia identitas OAuth, API ada untuk mengurangi tantangan paling umum dengan autentikasi. Windows Hello menyediakan sistem masuk biometrik baru yang mengenali pengguna dan secara aktif mengalahkan upaya untuk menghindari identifikasi yang tepat. Ini juga memberikan beberapa lapisan kunci dan sertifikat yang tidak pernah dapat diungkapkan atau digunakan di luar modul platform tepercaya. Plus, lapisan keamanan lebih lanjut tersedia melalui penggunaan opsional kunci identitas pengesahan dan sertifikat.

Untuk mengamankan data dalam penerbangan, API ada untuk berkomunikasi dengan sistem jarak jauh dengan aman melalui SSL, sambil memberikan kemungkinan untuk memvalidasi keaslian server dengan penyematan SSL. Menerbitkan API dengan aman dan terkontrol adalah sesuatu di mana Azure API Management membantu dengan menyediakan opsi konfigurasi yang kuat untuk mengekspos API di seluruh web menggunakan proksi yang menyediakan obfuscation tambahan dari titik akhir API. Akses ke API ini diamankan dengan menggunakan kunci API dan panggilan API dapat dibatasi untuk mengontrol performa.

Ketika data tiba di perangkat, model aplikasi Windows memberikan kontrol lebih besar atas cara aplikasi diinstal, diperbarui, dan mengaksesnya data, sambil mencegahnya mengakses data aplikasi lain dengan cara yang tidak sah. Loker info masuk dapat menyediakan penyimpanan kredensial pengguna yang aman yang dikelola oleh sistem operasi dan data lain dapat dilindungi pada perangkat dengan menggunakan API enkripsi dan hashing yang ditawarkan oleh Platform Windows Universal.

Bagikan melalui