Gambaran Umum Keamanan

Kerangka kerja keamanan di Windows Web Services API (WWSAPI) menyediakan:

• Integritas pesan, kerahasiaan, deteksi pemutaran ulang, dan autentikasi server menggunakan keamanan transport.
• Autentikasi klien seperti validasi token keamanan, kepercayaan sertifikat, dan pemeriksaan pencabutan, dll menggunakan keamanan pesan SOAP atau keamanan transportasi.

Model Pemrograman Keamanan

Keamanan dikaitkan dengan saluran komunikasi . Mengamankan saluran terdiri dari langkah-langkah berikut.

• Membuat dan menginisialisasi satu atau beberapa pengikatan keamanan sesuai dengan persyaratan keamanan aplikasi.
• Buat deskripsi keamanan yang berisi pengikatan keamanan tersebut.
• Buat saluran atau proksi layanan (di sisi klien), atau buat pendengar atau host layanan (di sisi server) dengan memberikan deskripsi keamanan tersebut.
• Lakukan langkah-langkah pemrograman saluran normal dari Buka, Terima, Kirim, Terima, Tutup, dll.

Pesan yang dikirim dan diterima di saluran diamankan secara otomatis oleh runtime sesuai dengan deskripsi keamanan yang disediakan. Secara opsional, langkah-langkah ini dapat disempurnakan dengan menentukan satu atau beberapa pengaturan keamanan di seluruh saluran dalam deskripsi keamanan atau pengaturan keamanan di seluruh pengikatan dalam pengikatan keamanan.

Setiap otorisasi identitas pengirim yang diperlukan harus dilakukan oleh aplikasi menggunakan hasil pemrosesan keamanan dilampirkan ke setiap pesan yang diterima. Langkah-langkah otorisasi tidak ditentukan dalam deskripsi keamanan, juga tidak dilakukan secara otomatis oleh runtime.

Kesalahan dalam deskripsi keamanan, seperti pengikatan yang tidak didukung, properti/bidang yang tidak dapat diaplikasikan, kurangnya properti/bidang yang diperlukan atau nilai properti/bidang yang tidak valid, akan menyebabkan pembuatan saluran atau pendengar gagal.

Memilih Pengikatan Keamanan

Saat merancang keamanan untuk aplikasi, keputusan utama adalah pemilihan pengikatan keamanan yang akan disertakan dalam deskripsi keamanan. Berikut ini adalah beberapa panduan untuk memilih pengikatan keamanan yang cocok untuk skenario keamanan aplikasi. Heuristik yang berguna adalah terlebih dahulu memahami jenis kredensial keamanan apa (seperti sertifikat X.509, nama pengguna/kata sandi domain Windows, nama pengguna/kata sandi yang ditentukan aplikasi) akan tersedia untuk aplikasi, dan kemudian memilih pengikatan keamanan yang dapat menggunakan jenis kredensial tersebut.

• Keamanan transportasi, di mana keamanan diterapkan pada tingkat aliran byte transportasi (di bawah batas pesan SOAP), adalah opsi pertama yang perlu dipertimbangkan.

  • Untuk skenario Internet, dan untuk skenario Intranet di mana sertifikat X.509 dapat disebarkan di server, aplikasi dapat menggunakan WS_SSL_TRANSPORT_SECURITY_BINDING. Contoh berikut mengilustrasikan opsi ini. Klien: HttpClientWithSslExample Server: HttpServerWithSslExample.

    Jika autentikasi klien melalui autentikasi header HTTP diinginkan, WS_HTTP_HEADER_AUTH_SECURITY_BINDING dapat ditambahkan untuk menyediakan fungsionalitas tersebut.

  • Untuk skenario Intranet di mana protokol Autentikasi Terintegrasi Windows seperti Kerberos, NTLM, dan SPNEGO sesuai, aplikasi dapat menggunakan WS_TCP_SSPI_TRANSPORT_SECURITY_BINDING. Contoh berikut mengilustrasikan opsi ini: Klien: RequestReplyTcpClientWithWindowsTransportSecurityExample Server: RequestReplyTcpServerWithWindowsTransportSecurityExample.

    Klien melalui pipa bernama: RequestReplyNamedPipesClientWithWindowsTransportSecurityExample

    Server melalui pipa bernama: RequestReplyNamedPipesServerWithWindowsTransportSecurityExample

  • Untuk skenario komputer lokal di mana protokol Autentikasi Terintegrasi Windows seperti Kerberos, NTLM, dan SPNEGO sesuai, aplikasi dapat menggunakan WS_TCP_SSPI_TRANSPORT_SECURITY_BINDING atau WS_NAMEDPIPE_SSPI_TRANSPORT_SECURITY_BINDING. WS_NAMEDPIPE_CHANNEL_BINDING lebih disukai dalam skenario seperti itu karena menjamin bahwa lalu lintas tidak akan meninggalkan mesin (ini adalah properti WS_NAMEDPIPE_CHANNEL_BINDING).

• Keamanan mode campuran, di mana keamanan transportasi melindungi koneksi dan header WS-Security dalam pesan SOAP menyediakan autentikasi klien, adalah opsi berikutnya untuk dipertimbangkan. Ikatan berikut digunakan bersama dengan salah satu ikatan keamanan transportasi yang dijelaskan di bagian sebelumnya.

  • Ketika klien diautentikasi oleh pasangan nama pengguna/kata sandi tingkat aplikasi, aplikasi dapat menggunakan WS_USERNAME_MESSAGE_SECURITY_BINDING untuk memberikan data autentikasi. Contoh berikut mengilustrasikan penggunaan pengikatan ini bersama dengan WS_SSL_TRANSPORT_SECURITY_BINDING:

    • Klien: HttpClientWithUsernameOverSslExample
    • Server: HttpServerWithUsernameOverSslExample

  • Ketika klien diautentikasi oleh tiket Kerberos, aplikasi dapat menggunakan WS_KERBEROS_APREQ_MESSAGE_SECURITY_BINDING untuk memberikan data autentikasi.

  • Saat menggunakan konteks keamanan , klien terlebih dahulu membuat konteks keamanan dengan server lalu menggunakan konteks tersebut untuk mengautentikasi pesan. Untuk mengaktifkan fungsionalitas ini, deskripsi keamanan harus berisi WS_SECURITY_CONTEXT_MESSAGE_SECURITY_BINDING. Setelah ditetapkan, konteks keamanan dapat ditransmisikan dengan token ringan, yang menghindari harus mengirim kredensial klien yang berpotensi besar dan mahal secara komputasi dengan setiap pesan.

  • Dalam skenario keamanan federasi, klien terlebih dahulu mendapatkan token keamanan yang dikeluarkan oleh layanan token keamanan (STS), lalu menyajikan token yang dikeluarkan ke layanan. Sisi klien: Untuk mendapatkan token keamanan dari STS, aplikasi dapat menggunakan WsRequestSecurityToken. Atau, aplikasi dapat menggunakan pustaka penyedia token keamanan sisi klien seperti CardSpace atau LiveID, lalu menggunakan output mereka untuk membuat token keamanan secara lokal menggunakan WsCreateXmlSecurityToken. Bagaimanapun, setelah token keamanan tersedia untuk klien, token tersebut dapat disajikan ke layanan menggunakan deskripsi keamanan yang berisi WS_XML_TOKEN_MESSAGE_SECURITY_BINDING. Sisi server: Jika token keamanan yang dikeluarkan oleh STS adalah token SAML, maka server dapat menggunakan deskripsi keamanan dengan WS_SAML_MESSAGE_SECURITY_BINDING.

    Nota

    Windows 7 dan Windows Server 2008 R2: WWSAPI hanya mendukung Ws-Trust dan Ws-SecureConversation seperti yang didefinisikan oleh Lightweight Web Services Security Profile (LWSSP). Untuk detail mengenai implementasi Microsoft, silakan lihat bagian Sintaks MESSAGE dari LWSSP.

     

• Opsi akhir yang perlu dipertimbangkan adalah menggunakan pengikatan autentikasi tanpa menggunakan pengikatan perlindungan seperti WS_SSL_TRANSPORT_SECURITY_BINDING. Ini akan mengakibatkan kredensial dikirimkan dalam teks yang jelas dan dapat memiliki implikasi keamanan. Penggunaan opsi ini harus dievaluasi dengan hati-hati untuk memastikan bahwa tidak ada kerentanan sebagai hasilnya. Contoh penggunaan potensial adalah bertukar pesan antara server back-end melalui jaringan privat yang aman. Konfigurasi berikut mendukung opsi ini.

  • WS_HTTP_HEADER_AUTH_SECURITY_BINDING mendukung opsi ini di semua konfigurasi.
  • WS_USERNAME_MESSAGE_SECURITY_BINDING mendukung opsi ini di server saat menggunakan HTTP sebagai transportasi.
  • WS_KERBEROS_APREQ_MESSAGE_SECURITY_BINDING mendukung opsi ini di server saat menggunakan HTTP sebagai transportasi.
  • WS_SECURITY_CONTEXT_MESSAGE_SECURITY_BINDING mendukung opsi ini di server saat menggunakan HTTP sebagai transportasi.
  • WS_SAML_MESSAGE_SECURITY_BINDING mendukung opsi ini di server saat menggunakan HTTP sebagai transportasi.

  Mengaktifkan opsi ini memerlukan pengaturan WS_PROTECTION_LEVEL secara eksplisit ke nilai selain WS_PROTECTION_LEVEL_SIGN_AND_ENCRYPT.

Saluran dan Keamanan

Seperti disebutkan di atas, keamanan terbatas pada saluran. Selain itu, operasi saluran dipetakan ke langkah-langkah keamanan secara konsisten di semua ikatan keamanan.

• Membuat saluran: Kumpulan pengikatan keamanan yang ditentukan dalam deskripsi keamanan divalidasi dan tetap stabil untuk saluran setelahnya. Bentuk tumpukan saluran, termasuk saluran tambahan apa pun yang akan digunakan untuk negosiasi berbasis WS-Trust, juga ditentukan.
• Saluran dibuka: Setiap kredensial yang disediakan sebagai bagian dari pengikatan keamanan dimuat, dan sesi keamanan dijalankan. Secara umum, saluran terbuka berisi status keamanan yang aktif. Membuka saluran klien juga menentukan alamat endpoint server tempat otentikasi server akan dilakukan oleh runtime.
• Antara saluran terbuka dan ditutup: Pesan dapat dikirim dan diterima dengan aman selama fase ini.
• Kirim pesan: Token konteks keamanan diperoleh atau diperbarui sesuai kebutuhan dan keamanan diterapkan ke setiap pesan yang dikirimkan sesuai dengan deskripsi keamanan. Kesalahan yang ditemui saat menerapkan keamanan dikembalikan ke aplikasi sebagai kesalahan pengiriman.
• Pesan diterima: Keamanan diverifikasi pada setiap pesan yang diterima sesuai dengan deskripsi keamanan. Kesalahan pada verifikasi keamanan pesan dikembalikan ke aplikasi sebagai kesalahan penerimaan. Kesalahan per pesan ini tidak memengaruhi status saluran atau penerimaan berikutnya. Aplikasi dapat membuang penerimaan yang gagal dan memulai ulang penerimaan untuk pesan lain.
• Pembatalan saluran: Saluran dapat dibatalkan kapan saja untuk menghentikan semua I/O di saluran. Jika dibatalkan, saluran akan masuk ke status rusak dan tidak akan mengizinkan pengiriman atau penerimaan lagi. Namun, saluran mungkin masih mempertahankan beberapa status keamanan 'langsung', sehingga penutupan saluran berikutnya akan diperlukan untuk menghapus semua status dengan bersih.
• Saluran ditutup: Status keamanan yang dibuat saat saluran dibuka dibuang dan sesi dihentikan. Token konteks keamanan dibatalkan. Tumpukan saluran tetap ada, tetapi tidak berisi status keamanan 'aktif' atau kredensial yang dimuat.
• Saluran dibebaskan: Tumpukan saluran yang dibangun saat pembuatan, bersama dengan semua sumber daya keamanan, dibebaskan.

API Keamanan

Dokumentasi API untuk keamanan dikelompokkan ke dalam topik berikut.

• Deskripsi Keamanan
  • Pengaturan Saluran Keamanan
  • Pengikatan Keamanan
    • Kredensial Keamanan
    • Pengaturan Pengikatan Keamanan
• Federasi
• Konteks Keamanan
• Identitas Titik Akhir
• Hasil Pemrosesan Keamanan

Keamanan

Saat menggunakan API Keamanan WWSAPI, aplikasi menghadapi beberapa risiko keamanan:

Kesalahan konfigurasi yang tidak disengaja

WWSAPI mendukung berbagai opsi konfigurasi terkait keamanan. Lihat misalnya WS_SECURITY_BINDING_PROPERTY_ID. Beberapa opsi ini, seperti WS_SECURITY_BINDING_PROPERTY_ALLOW_ANONYMOUS_CLIENTS, memungkinkan aplikasi untuk menurunkan tingkat default keamanan yang disediakan oleh berbagai Pengikatan Keamanan. Penggunaan opsi tersebut harus dievaluasi dengan hati-hati untuk memastikan bahwa tidak ada vektor serangan yang dihasilkan.

Selain itu, seperti yang dijelaskan di atas, WWSAPI memungkinkan aplikasi untuk dengan sengaja menonaktifkan langkah-langkah tertentu yang diperlukan untuk sepenuhnya mengamankan pertukaran pesan, seperti memungkinkan untuk menonaktifkan enkripsi meskipun kredensial keamanan dikirimkan. Ini diizinkan untuk mengaktifkan skenario tertentu dan tidak boleh digunakan untuk komunikasi umum. WS_PROTECTION_LEVEL harus diturunkan secara khusus untuk mengaktifkan skenario ini, dan aplikasi tidak boleh mengubah nilai tersebut kecuali benar-benar diperlukan, karena itu akan menonaktifkan banyak pemeriksaan yang dirancang untuk memastikan konfigurasi yang aman.

Menyimpan informasi rahasia dalam memori

Informasi rahasia, seperti kata sandi, yang disimpan dalam memori rentan diekstraksi oleh penyerang dengan hak akses istimewa melalui, misalnya, berkas halaman. WWSAPI membuat salinan kredensial yang disediakan dan mengenkripsi salinan tersebut, sehingga data asli tidak terlindungi. Ini adalah tanggung jawab aplikasi untuk melindungi instans asli. Selain itu, salinan terenkripsi didekripsi secara singkat saat digunakan, membuka jendela untuk mengekstraknya.

Penolakan layanan

Pemrosesan keamanan dapat menggunakan sumber daya yang signifikan. Setiap pengikatan keamanan tambahan meningkatkan biaya tersebut. WWSAPI membatalkan pemrosesan keamanan segera setelah kegagalan verifikasi keamanan ditemui, tetapi pemeriksaan tertentu seperti keputusan otorisasi mungkin tidak terjadi sampai setelah pekerjaan signifikan dilakukan.

Saat pesan diproses di server, status keamanan disimpan pada tumpukan pesan. Aplikasi dapat membatasi konsumsi memori selama pemrosesan keamanan dengan mengurangi ukuran tumpukan tersebut melalui WS_MESSAGE_PROPERTY_HEAP_PROPERTIES. Selain itu, pengikatan keamanan tertentu seperti WS_SECURITY_CONTEXT_MESSAGE_SECURITY_BINDING dapat menyebabkan server mengalokasikan sumber daya atas nama klien. Batasan untuk sumber daya tersebut dapat dikonfigurasi dengan cara nilai WS_SECURITY_BINDING_PROPERTY_ID berikut:

• WS_SECURITY_BINDING_PROPERTY_SECURITY_CONTEXT_MAX_PENDING_CONTEXTS
• Properti_Pengikatan_Keamanan_Konteks_Maksimal_Konteks_Aktif
• Properti_Konteks_Keamanan_WS_Perpanjangan_Interval
• WS_SECURITY_BINDING_PROPERTY_INTERVAL_PERGANTIAN_KONTEKS_KEAMANAN

Mengatur batas tersebut ke nilai rendah mengurangi konsumsi memori maksimum tetapi dapat menyebabkan klien yang sah ditolak ketika kuota tercapai.