Bingkai Keamanan: Autentikasi | Mitigasi

Produk/Layanan Artikel
Aplikasi Web
Basis Data
Azure Event Hub
Batas Kepercayaan Microsoft Azure
Batas Kepercayaan Service Fabric
Server Identitas
Batas Kepercayaan Mesin
WCF
API Web
Microsoft Entra ID
Gateway Bidang IoT
Gerbang Awan IoT
Azure Storage

Mempertimbangkan untuk menggunakan mekanisme autentikasi standar untuk mengautentikasi ke Aplikasi Web

Judul Detail
Komponen Aplikasi Web
Fase SDL Membangun
Teknologi yang Berlaku Generik
Atribut Tidak Berlaku
Referensi Tidak Berlaku
Detail

Autentikasi adalah proses di mana entitas membuktikan identitasnya, biasanya melalui info masuk, seperti nama pengguna dan kata sandi. Ada beberapa protokol autentikasi yang tersedia yang mungkin dipertimbangkan. Beberapa di antaranya tercantum di bawah ini:

  • sertifikat klien
  • Berbasis Windows
  • Berbasis formulir
  • Federasi - ADFS
  • Federasi - Microsoft Entra ID
  • Federasi - Server Identitas

Pertimbangkan untuk menggunakan mekanisme autentikasi standar untuk mengidentifikasi proses sumber

Aplikasi harus menangani skenario autentikasi yang gagal dengan aman

Judul Detail
Komponen Aplikasi Web
Fase SDL Membangun
Teknologi yang Berlaku Generik
Atribut Tidak Berlaku
Referensi Tidak Berlaku
Detail

Aplikasi yang secara eksplisit mengautentikasi pengguna harus menangani skenario autentikasi yang gagal dengan aman. Mekanisme autentikasi harus:

  • Menolak akses ke sumber daya hak istimewa saat autentikasi gagal
  • Menampilkan pesan kesalahan generik setelah autentikasi gagal dan akses ditolak terjadi

Pengujian untuk:

  • Perlindungan sumber daya hak istimewa setelah gagal masuk
  • Pesan kesalahan generik ditampilkan pada saat peristiwa otentikasi gagal dan peristiwa akses ditolak.
  • Akun dinonaktifkan setelah jumlah upaya gagal yang berlebihan

    Mengaktifkan autentikasi berjenjang atau adaptif

    Judul Detail
    Komponen Aplikasi Web
    Fase SDL Membangun
    Teknologi yang Berlaku Generik
    Atribut Tidak Berlaku
    Referensi Tidak Berlaku
    Detail

    Verifikasi aplikasi memiliki otorisasi tambahan (seperti peningkatan atau autentikasi adaptif, melalui autentikasi multifaktor seperti mengirim OTP dalam SMS, email, dll. atau meminta autentikasi ulang) sehingga pengguna ditantang sebelum diberikan akses ke informasi sensitif. Aturan ini juga berlaku untuk membuat perubahan penting pada akun atau tindakan

    Ini juga berarti bahwa adaptasi autentikasi harus diimplementasikan sedemikian rupa sehingga aplikasi menerapkan otorisasi peka konteks dengan benar sehingga tidak memungkinkan manipulasi yang tidak sah dengan cara, misalnya, gangguan parameter

    Memastikan bahwa antarmuka administratif dikunci dengan tepat

    Judul Detail
    Komponen Aplikasi Web
    Fase SDL Membangun
    Teknologi yang Berlaku Generik
    Atribut Tidak Berlaku
    Referensi Tidak Berlaku
    Detail Solusi pertama adalah memberikan akses hanya dari rentang IP sumber tertentu ke antarmuka administratif. Jika solusi tersebut tidak mungkin dilakukan, selalu disarankan untuk menegakkan autentikasi berjenjang atau adaptif saat masuk ke antarmuka administratif.

    Menerapkan fungsionalitas kata sandi yang terlupakan dengan aman

    Judul Detail
    Komponen Aplikasi Web
    Fase SDL Membangun
    Teknologi yang Berlaku Generik
    Atribut Tidak Berlaku
    Referensi Tidak Berlaku
    Detail

    Langkah pertama adalah memastikan bahwa fitur lupa kata sandi dan jalur pemulihan kata sandi lainnya mengirimkan tautan yang menyertakan token aktivasi yang dibatasi oleh waktu, bukan kata sandi itu sendiri. Autentikasi tambahan berdasarkan soft-token (misalnya token SMS, aplikasi seluler asli, dll.) juga dapat diperlukan sebelum tautan dikirim. Kedua, Anda tidak boleh mengunci akun pengguna saat proses mendapatkan kata sandi baru sedang berlangsung.

    Ini dapat menyebabkan serangan penolakan layanan (DoS) setiap kali penyerang memutuskan untuk secara sengaja mencegah pengguna mengakses layanan dengan serangan otomatis. Ketiga, setiap kali permintaan kata sandi baru sedang berlangsung, pesan yang Anda tampilkan harus digeneralisasi untuk mencegah enumerasi nama pengguna. Keempat, selalu larang penggunaan kata sandi lama dan terapkan kebijakan kata sandi yang kuat.

    Memastikan bahwa kebijakan kata sandi dan akun diterapkan

    Judul Detail
    Komponen Aplikasi Web
    Fase SDL Membangun
    Teknologi yang Berlaku Generik
    Atribut Tidak Berlaku
    Referensi Tidak Berlaku
    Detail

    Kebijakan kata sandi dan akun sesuai dengan kebijakan organisasi dan praktik terbaik harus diterapkan.

    Untuk bertahan melawan brute force dan tebakan berbasis kamus: Kebijakan kata sandi yang kuat harus diterapkan untuk memastikan bahwa pengguna membuat kata sandi yang rumit (mis., panjang minimum 12 karakter, alfanumerik, dan karakter khusus).

    Kebijakan penguncian akun dapat diterapkan dengan cara berikut:

    • Penguncian lunak: Ini dapat menjadi pilihan yang baik untuk melindungi pengguna Anda dari serangan brute force. Misalnya, setiap kali pengguna memasukkan kata sandi yang salah tiga kali, aplikasi dapat mengunci akun selama satu menit untuk memperlambat proses pemaksaan kata sandinya sehingga kurang menguntungkan bagi penyerang untuk melanjutkan. Jika Anda menerapkan tindakan pencegahan penguncian keras untuk contoh ini, Anda akan mencapai "DoS" dengan mengunci akun secara permanen. Atau, aplikasi dapat menghasilkan OTP (Kata Sandi Satu Kali) dan mengirimkannya di luar band (melalui email, sms, dll.) kepada pengguna. Pendekatan lain mungkin adalah menerapkan CAPTCHA setelah ambang batas jumlah upaya gagal yang tercapai.
    • Penguncian keras: Jenis penguncian ini harus diterapkan setiap kali Anda mendeteksi pengguna yang menyerang aplikasi Anda dan melawannya dengan cara mengunci akunnya secara permanen hingga tim respons memiliki waktu untuk melakukan forensiknya. Setelah proses ini, Anda dapat memutuskan untuk mengembalikan akun pengguna atau mengambil tindakan hukum lebih lanjut terhadapnya. Jenis pendekatan ini mencegah penyerang menembus aplikasi dan infrastruktur Anda lebih jauh.

    Untuk mempertahankan diri dari serangan terhadap akun default dan akun yang dapat diprediksi, verifikasi bahwa semua kunci dan kata sandi dapat diganti, dan dibuat atau diganti setelah waktu penginstalan.

    Jika aplikasi harus membuat kata sandi secara otomatis, pastikan kata sandi yang dihasilkan acak dan memiliki entropi tinggi.

    Menerapkan kontrol untuk mencegah enumerasi nama pengguna

    Judul Detail
    Komponen Aplikasi Web
    Fase SDL Membangun
    Teknologi yang Berlaku Generik
    Atribut Tidak Berlaku
    Referensi Tidak Berlaku
    Langkah-langkah Semua pesan kesalahan harus digeneralisasi untuk mencegah enumerasi nama pengguna. Terkadang Anda juga tidak dapat menghindari kebocoran informasi dalam fungsionalitas seperti halaman pendaftaran. Di sini Anda perlu menggunakan metode pembatasan kecepatan seperti CAPTCHA untuk mencegah serangan otomatis oleh penyerang.

    Jika memungkinkan, gunakan Autentikasi Windows untuk menyambungkan ke SQL Server

    Judul Detail
    Komponen Basis data
    Fase SDL Membangun
    Teknologi yang Berlaku di tempat
    Atribut Versi SQL - Semua
    Referensi SQL Server - Pilih Mode Autentikasi
    Langkah-langkah Autentikasi Windows menggunakan protokol keamanan Kerberos, menyediakan pemberlakuan kebijakan kata sandi sehubungan dengan validasi kompleksitas untuk kata sandi yang kuat, memberikan dukungan untuk penguncian akun, dan mendukung kedaluwarsa kata sandi.

    Jika memungkinkan, gunakan autentikasi Microsoft Entra untuk Menyambungkan ke SQL Database

    Judul Detail
    Komponen Basis data
    Fase SDL Membangun
    Teknologi yang Berlaku SQL Azure
    Atribut Versi SQL - V12
    Referensi Menyambungkan ke SQL Database Menggunakan autentikasi Microsoft Entra
    Langkah-langkah Versi minimum: Azure SQL Database V12 diperlukan untuk mengizinkan Azure SQL Database menggunakan autentikasi Microsoft Entra terhadap Microsoft Directory

    Saat mode autentikasi SQL digunakan, pastikan bahwa kebijakan akun dan kata sandi diberlakukan di server SQL

    Judul Detail
    Komponen Basis data
    Fase SDL Membangun
    Teknologi yang Berlaku Generik
    Atribut Tidak Berlaku
    Referensi Kebijakan kata sandi SQL Server
    Langkah-langkah Saat menggunakan Autentikasi SQL Server, login dibuat di SQL Server yang tidak didasarkan pada akun pengguna Windows. Nama pengguna dan kata sandi dibuat dengan menggunakan SQL Server dan disimpan di SQL Server. SQL Server dapat menggunakan mekanisme kebijakan kata sandi Windows. Itu dapat menerapkan kebijakan kompleksitas dan kedaluwarsa yang sama yang digunakan di Windows untuk kata sandi yang digunakan di dalam SQL Server.

    Jangan gunakan Autentikasi SQL dalam database terpisah

    Judul Detail
    Komponen Basis data
    Fase SDL Membangun
    Teknologi yang Berlaku Lokal, SQL Azure
    Atribut Versi SQL - MSSQL2012, Versi SQL - V12
    Referensi Praktik Terbaik keamanan dengan Database Terkendali
    Langkah-langkah Tidak adanya kebijakan kata sandi yang diberlakukan dapat meningkatkan kemungkinan kredensial lemah yang ditetapkan dalam database yang terkandung. Manfaatkan Autentikasi Windows.

    Gunakan info masuk autentikasi per perangkat menggunakan token SaS

    Judul Detail
    Komponen Azure Event Hubs
    Fase SDL Membangun
    Teknologi yang Berlaku Generik
    Atribut Tidak Berlaku
    Referensi Ringkasan autentikasi dan model keamanan Azure Event Hubs
    Langkah-langkah

    Model keamanan Event Hubs didasarkan pada kombinasi token Shared Access Signature (SAS) dan penerbit acara. Nama penerbit mewakili DeviceID yang menerima token. Ini akan membantu mengaitkan token yang dihasilkan dengan perangkat masing-masing.

    Semua pesan ditandai dengan pengirim di sisi layanan yang memungkinkan deteksi upaya pemalsuan asal di dalam muatan. Saat mengautentikasi perangkat, buat token SaS untuk setiap perangkat yang cakupannya ke penerbit unik.

    Mengaktifkan autentikasi multifaktor Microsoft Entra untuk Administrator Azure

    Judul Detail
    Komponen Batas Kepercayaan Azure
    Fase SDL Penyebaran
    Teknologi yang Berlaku Generik
    Atribut Tidak Berlaku
    Referensi Apa itu autentikasi multifaktor Microsoft Entra?
    Langkah-langkah

    autentikasi multifaktor (MFA) adalah metode autentikasi yang memerlukan lebih dari satu metode verifikasi dan menambahkan lapisan keamanan kedua yang penting untuk masuk dan transaksi pengguna. Ini bekerja dengan meminta dua atau lebih dari metode verifikasi berikut:

    • Sesuatu yang Anda ketahui (biasanya kata sandi)
    • Sesuatu yang Anda miliki (perangkat tepercaya yang tidak mudah diduplikasi, seperti telepon)
    • Sesuatu yang Anda adalah (biometrik)

      Membatasi akses anonim ke Kluster Service Fabric

      Judul Detail
      Komponen Batas Kepercayaan Service Fabric
      Fase SDL Penyebaran
      Teknologi yang Berlaku Generik
      Atribut Lingkungan - Azure
      Referensi Skenario keamanan kluster Service Fabric
      Langkah-langkah

      Kluster harus selalu diamankan untuk mencegah pengguna yang tidak sah tersambung ke kluster Anda, terutama saat beban kerja produksi sedang berjalan di dalamnya.

      Saat membuat kluster fabric layanan, pastikan mode keamanan diatur ke "aman" dan konfigurasikan sertifikat server X.509 yang diperlukan. Membuat kluster "tidak aman" akan memungkinkan pengguna anonim untuk tersambung jika kluster tersebut mengekspos titik akhir manajemen ke Internet publik.

      Memastikan bahwa sertifikat klien-ke-simpul Service Fabric berbeda dari sertifikat simpul-ke-simpul

      Judul Detail
      Komponen Batas Kepercayaan Service Fabric
      Fase SDL Penyebaran
      Teknologi yang Berlaku Generik
      Atribut Lingkungan - Azure, Lingkungan - Mandiri
      Referensi Keamanan sertifikat klien-ke-simpul Service Fabric, Sambungkan ke kluster aman menggunakan sertifikat klien
      Langkah-langkah

      Keamanan sertifikat klien-ke-simpul dikonfigurasi saat membuat kluster baik melalui portal Microsoft Azure, templat Resource Manager, atau templat JSON mandiri dengan menentukan sertifikat klien admin dan/atau sertifikat klien pengguna.

      Sertifikat klien admin dan klien pengguna yang Anda tentukan harus berbeda dari sertifikat utama dan sekunder yang Anda tentukan untuk keamanan Simpul-ke-simpul.

      Menggunakan ID Microsoft Entra untuk mengautentikasi klien ke kluster service fabric

      Judul Detail
      Komponen Batas Kepercayaan Service Fabric
      Fase SDL Penyebaran
      Teknologi yang Berlaku Generik
      Atribut Lingkungan - Azure
      Referensi Skenario keamanan kluster - Rekomendasi Keamanan
      Langkah-langkah Kluster yang berjalan di Azure juga dapat mengamankan akses ke titik akhir manajemen menggunakan ID Microsoft Entra, selain sertifikat klien. Untuk kluster Azure, disarankan agar Anda menggunakan keamanan Microsoft Entra untuk mengautentikasi klien dan sertifikat untuk keamanan node-to-node.

      Memastikan bahwa sertifikat service fabric diperoleh dari Otoritas Sertifikat (CA) yang disetujui.

      Judul Detail
      Komponen Batas Kepercayaan Service Fabric
      Fase SDL Penyebaran
      Teknologi yang Berlaku Generik
      Atribut Lingkungan - Azure
      Referensi Sertifikat X.509 dan Service Fabric
      Langkah-langkah

      Service Fabric menggunakan sertifikat server X.509 untuk mengautentikasi simpul dan klien.

      Beberapa hal penting yang perlu dipertimbangkan saat menggunakan sertifikat dalam layanan fabric:

      • Sertifikat yang digunakan dalam kluster yang menjalankan beban kerja produksi harus dibuat dengan menggunakan layanan sertifikat Windows Server yang dikonfigurasi dengan benar atau diperoleh dari Otoritas Sertifikat (OS) yang disetujui. CA dapat berupa CA eksternal yang disetujui atau Infrastruktur Kunci Publik (PKI) internal yang dikelola dengan baik
      • Jangan pernah menggunakan sertifikat sementara atau sertifikat uji apa pun dalam produksi yang dibuat dengan alat seperti MakeCert.exe
      • Anda dapat menggunakan sertifikat yang ditandatangani sendiri, tetapi hanya boleh digunakan untuk kluster pengujian dan bukan dalam produksi

      Menggunakan skenario autentikasi standar yang didukung oleh Server Identitas

      Judul Detail
      Komponen Server Identitas
      Fase SDL Membangun
      Teknologi yang Berlaku Generik
      Atribut Tidak Berlaku
      Referensi Tidak Berlaku
      Langkah-langkah

      Di bawah ini adalah interaksi umum yang didukung oleh Server Identitas:

      • Browser berkomunikasi dengan aplikasi web
      • Aplikasi web berkomunikasi dengan API web (terkadang sendiri, terkadang atas nama pengguna)
      • Aplikasi berbasis browser berkomunikasi dengan API web
      • Aplikasi asli berkomunikasi dengan API web
      • Aplikasi berbasis server berkomunikasi dengan API web
      • Web API berkomunikasi dengan API web (terkadang sendiri, terkadang atas nama pengguna)

      Gantikan cache token Server Identitas yang default dengan alternatif yang dapat diskalakan

      Judul Detail
      Komponen Server Identitas
      Fase SDL Penyebaran
      Teknologi yang Berlaku Generik
      Atribut Tidak Berlaku
      Referensi Tidak Berlaku
      Langkah-langkah

      IdentityServer memiliki cache dalam memori bawaan yang sederhana. Meskipun ini baik untuk aplikasi asli skala kecil, ini tidak menskalakan untuk aplikasi tingkat menengah dan backend karena alasan berikut:

      • Aplikasi ini diakses oleh banyak pengguna sekaligus. Menyimpan semua token akses di penyimpanan yang sama menimbulkan masalah isolasi dan menghadirkan tantangan saat beroperasi dalam skala besar: banyak pengguna, masing-masing dengan token sebanyak sumber daya yang diakses aplikasi atas nama mereka, dapat berarti jumlah yang sangat besar dan operasi pencarian yang sangat mahal.
      • Aplikasi ini biasanya digunakan pada topologi terdistribusi, di mana banyak simpul harus memiliki akses ke cache yang sama
      • Token yang di-cache harus bertahan dari proses daur ulang dan penonaktifan
      • Untuk semua alasan di atas, saat menerapkan aplikasi web, disarankan untuk mengambil alih cache token Server Identitas default dengan alternatif yang dapat diskalakan seperti Azure Managed Redis

      Memastikan bahwa biner aplikasi yang disebarkan ditandatangani secara digital

      Judul Detail
      Komponen Batas Kepercayaan Komputer
      Fase SDL Penyebaran
      Teknologi yang Berlaku Generik
      Atribut Tidak Berlaku
      Referensi Tidak Berlaku
      Langkah-langkah Pastikan biner aplikasi yang disebarkkan ditandatangani secara digital sehingga integritas biner dapat diverifikasi

      Mengaktifkan autentikasi saat menyambungkan ke antrean MSMQ di WCF

      Judul Detail
      Komponen WCF
      Fase SDL Membangun
      Teknologi yang Berlaku Generik, NET Framework 3
      Atribut Tidak Berlaku
      Referensi MSDN
      Langkah-langkah Program gagal mengaktifkan autentikasi saat menyambungkan ke antrean MSMQ, penyerang dapat secara anonim mengirimkan pesan ke antrean untuk diproses. Jika autentikasi tidak digunakan untuk menyambungkan ke antrean MSMQ yang digunakan untuk mengirimkan pesan ke program lain, penyerang dapat mengirimkan pesan anonim yang berbahaya.

      Contoh

      Elemen <netMsmqBinding/> dari file konfigurasi WCF di bawah ini menginstruksikan WCF untuk menonaktifkan autentikasi saat menyambungkan ke antrean MSMQ untuk pengiriman pesan.

      <bindings>
    <netMsmqBinding>
        <binding>
            <security>
                <transport msmqAuthenticationMode=""None"" />
            </security>
        </binding>
    </netMsmqBinding>
</bindings>

      Konfigurasikan MSMQ untuk mewajibkan autentikasi Domain atau Sertifikat Windows setiap saat untuk setiap pesan masuk atau keluar.

      Contoh

      Elemen <netMsmqBinding/> dari file konfigurasi WCF di bawah ini menginstruksikan WCF untuk mengaktifkan autentikasi sertifikat saat menyambungkan ke antrean MSMQ. Klien diautentikasi menggunakan sertifikat X.509. Sertifikat klien harus ada di penyimpanan sertifikat server.

      <bindings>
    <netMsmqBinding>
        <binding>
            <security>
                <transport msmqAuthenticationMode=""Certificate"" />
            </security>
        </binding>
    </netMsmqBinding>
</bindings>

      WCF-Jangan atur Message clientCredentialType ke tidak ada

      Judul Detail
      Komponen WCF
      Fase SDL Membangun
      Teknologi yang Berlaku .NET Framework 3
      Atribut Jenis Kredensial Klien - Tidak Ada
      Referensi MSDN, Fortify
      Langkah-langkah Tidak adanya autentikasi berarti semua orang dapat mengakses layanan ini. Layanan yang tidak mengautentikasi kliennya memungkinkan akses ke semua pengguna. Mengonfigurasi aplikasi untuk autentikasi dengan kredensial klien. Ini dapat dilakukan dengan mengatur pesan clientCredentialType ke Windows atau Sertifikat.

      Contoh

      <message clientCredentialType=""Certificate""/>

      WCF-Jangan atur Transport clientCredentialType ke tidak ada

      Judul Detail
      Komponen WCF
      Fase SDL Membangun
      Teknologi yang Berlaku Umum, .NET Framework 3
      Atribut Jenis Kredensial Klien - Tidak Ada
      Referensi MSDN, Fortify
      Langkah-langkah Tidak adanya autentikasi berarti semua orang dapat mengakses layanan ini. Layanan yang tidak mengautentikasi kliennya memungkinkan semua pengguna untuk mengakses fungsionalitasnya. Mengonfigurasi aplikasi untuk autentikasi dengan kredensial klien. Ini dapat dilakukan dengan mengatur transportasi clientCredentialType ke Windows atau Sertifikat.

      Contoh

      <transport clientCredentialType=""Certificate""/>

      Memastikan bahwa teknik autentikasi standar digunakan untuk mengamankan Web API

      Judul Detail
      Komponen API Web
      Fase SDL Membangun
      Teknologi yang Berlaku Generik
      Atribut Tidak Berlaku
      Referensi Autentikasi dan Otorisasi di API Web ASP.NET, Layanan Autentikasi Eksternal dengan API Web ASP.NET (C#)
      Langkah-langkah

      Autentikasi adalah proses di mana entitas membuktikan identitasnya, biasanya melalui info masuk, seperti nama pengguna dan kata sandi. Ada beberapa protokol autentikasi yang tersedia yang mungkin dipertimbangkan. Beberapa di antaranya tercantum di bawah ini:

      • sertifikat klien
      • Berbasis Windows
      • Berbasis formulir
      • Federasi - ADFS
      • Federasi - Microsoft Entra ID
      • Federasi - Server Identitas

      Tautan di bagian referensi memberikan detail tingkat rendah tentang bagaimana setiap skema autentikasi dapat diterapkan untuk mengamankan Web API.

      Gunakan skenario autentikasi standar yang didukung oleh ID Microsoft Entra

      Judul Detail
      Komponen Microsoft Entra ID
      Fase SDL Membangun
      Teknologi yang Berlaku Generik
      Atribut Tidak Berlaku
      Referensi Skenario Autentikasi untuk ID Microsoft Entra, Sampel kode Microsoft Entra, panduan pengembang Microsoft Entra
      Langkah-langkah

      MICROSOFT Entra ID menyederhanakan autentikasi untuk pengembang dengan menyediakan identitas sebagai layanan, dengan dukungan untuk protokol standar industri seperti OAuth 2.0 dan OpenID Connect. Di bawah ini adalah lima skenario aplikasi utama yang didukung oleh ID Microsoft Entra:

      • Browser Web ke Aplikasi Web: Pengguna perlu masuk ke aplikasi web yang diamankan oleh ID Microsoft Entra
      • Aplikasi Halaman Tunggal (SPA): Pengguna perlu masuk ke aplikasi satu halaman yang diamankan oleh ID Microsoft Entra
      • Aplikasi Asli ke API Web: Aplikasi asli yang berjalan di ponsel, tablet, atau PC perlu mengautentikasi pengguna untuk mendapatkan sumber daya dari API web yang diamankan oleh ID Microsoft Entra
      • Aplikasi Web ke API Web: Aplikasi web perlu mendapatkan sumber daya dari API web yang diamankan oleh ID Microsoft Entra
      • Daemon atau Aplikasi Server ke API Web: Aplikasi daemon atau aplikasi server tanpa antarmuka pengguna web perlu mendapatkan sumber daya dari API web yang diamankan oleh ID Microsoft Entra

      Harap periksa tautan di bagian referensi untuk detail penerapan tingkat rendah

      Ganti cache token MSAL default dengan cache terdistribusi

      Judul Detail
      Komponen Microsoft Entra ID
      Fase SDL Membangun
      Teknologi yang Berlaku Generik
      Atribut Tidak Berlaku
      Referensi Serialisasi cache token di MSAL.NET
      Langkah-langkah

      Cache default yang digunakan MSAL (Pustaka Autentikasi Microsoft) adalah cache dalam memori, dan dapat diskalakan. Namun ada berbagai opsi yang tersedia yang dapat Anda gunakan sebagai alternatif, seperti cache token terdistribusi. Ini memiliki mekanisme L1/L2, di mana L1 berada dalam memori dan L2 adalah implementasi cache terdistribusi. Ini dapat dikonfigurasi dengan sesuai untuk membatasi memori L1, mengenkripsi, atau mengatur kebijakan pengeluaran. Alternatif lainnya termasuk cache Redis, SQL Server, atau Azure Cosmos DB. Implementasi cache token terdistribusi dapat ditemukan dalam Tutorial berikut : Mulai menggunakan ASP.NET Core MVC.

      Pastikan bahwa TokenReplayCache digunakan untuk mencegah pemutaran ulang token autentikasi MSAL

      Judul Detail
      Komponen Microsoft Entra ID
      Fase SDL Membangun
      Teknologi yang Berlaku Generik
      Atribut Tidak Berlaku
      Referensi Autentikasi Modern dengan ID Microsoft Entra untuk Aplikasi Web
      Langkah-langkah

      Properti TokenReplayCache memungkinkan pengembang untuk menentukan cache pemutaran ulang token, penyimpanan yang dapat digunakan untuk menyimpan token dengan tujuan memverifikasi bahwa tidak ada token yang dapat digunakan lebih dari sekali.

      Ini adalah langkah penanggulangan terhadap serangan umum, yang tepat disebut serangan memainkan ulang token: penyerang yang mencegat token yang dikirim saat masuk mungkin mencoba mengirimkannya kembali ke aplikasi untuk membuat sesi baru. Misalnya, dalam alur pemberian kode OIDC, setelah autentikasi pengguna berhasil, permintaan ke titik akhir "/ signin-oidc" dari pihak yang mengandalkan dibuat dengan parameter "id_token", "code" dan "state".

      Pihak yang mengandalkan memvalidasi permintaan ini dan membuat sesi baru. Jika musuh mengambil permintaan ini dan memutarnya kembali, dia dapat membuat sesi yang berhasil dan menipu pengguna. Kehadiran nonce di OpenID Connect dapat membatasi tetapi tidak sepenuhnya menghilangkan keadaan di mana serangan dapat berhasil dilakukan. Untuk melindungi aplikasinya, pengembang dapat menyediakan implementasi ITokenReplayCache dan menetapkan instans ke TokenReplayCache.

      Contoh

      // ITokenReplayCache defined in MSAL
public interface ITokenReplayCache
{
bool TryAdd(string securityToken, DateTime expiresOn);
bool TryFind(string securityToken);
}

      Contoh

      Berikut adalah contoh implementasi antarmuka ITokenReplayCache. (Harap sesuaikan dan terapkan kerangka kerja penyimpanan sementara khusus proyek Anda)

      public class TokenReplayCache : ITokenReplayCache
{
    private readonly ICacheProvider cache; // Your project-specific cache provider
    public TokenReplayCache(ICacheProvider cache)
    {
        this.cache = cache;
    }
    public bool TryAdd(string securityToken, DateTime expiresOn)
    {
        if (this.cache.Get<string>(securityToken) == null)
        {
            this.cache.Set(securityToken, securityToken);
            return true;
        }
        return false;
    }
    public bool TryFind(string securityToken)
    {
        return this.cache.Get<string>(securityToken) != null;
    }
}

      Cache yang diimplementasikan harus dirujuk dalam opsi OIDC melalui properti "TokenValidationParameters" sebagai berikut.

      OpenIdConnectOptions openIdConnectOptions = new OpenIdConnectOptions
{
    AutomaticAuthenticate = true,
    ... // other configuration properties follow..
    TokenValidationParameters = new TokenValidationParameters
    {
        TokenReplayCache = new TokenReplayCache(/*Inject your cache provider*/);
    }
}

      Harap dicatat bahwa untuk menguji efektivitas konfigurasi ini, silakan masuk ke aplikasi lokal Anda yang dilindungi OIDC dan tangkap permintaan ke titik akhir "/signin-oidc" di Fiddler. Saat perlindungan tidak ada, memutar ulang permintaan ini di Fiddler akan mengatur cookie sesi baru. Saat permintaan diputar ulang setelah perlindungan TokenReplayCache ditambahkan, aplikasi akan mengeluarkan pengecualian sebagai berikut: SecurityTokenReplayDetectedException: IDX10228: The securityToken has previously been validated, securityToken: 'eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik1uQ19WWmNBVGZNNXBPWWlKSE1iYTlnb0VLWSIsImtpZCI6Ik1uQ1......

      Menggunakan pustaka MSAL untuk mengelola permintaan token dari klien OAuth2 ke ID Microsoft Entra (atau AD lokal)

      Judul Detail
      Komponen Microsoft Entra ID
      Fase SDL Membangun
      Teknologi yang Berlaku Generik
      Atribut Tidak Berlaku
      Referensi MSAL
      Langkah-langkah

      Pustaka Autentikasi Microsoft (MSAL) memungkinkan pengembang memperoleh token keamanan dari platform identitas Microsoft untuk mengautentikasi pengguna dan mengakses API web aman. Ini dapat digunakan untuk menyediakan akses aman ke Microsoft Graph, Microsoft API lainnya, API web pihak ketiga, atau API web Anda sendiri. MSAL mendukung berbagai arsitektur dan platform aplikasi termasuk .NET, JavaScript, Java, Python, Android, dan iOS.

      MSAL memberi Anda banyak cara untuk mendapatkan token, dengan API yang konsisten untuk banyak platform. Tidak perlu langsung menggunakan pustaka atau kode OAuth terhadap protokol dalam aplikasi Anda, dan dapat memperoleh token atas nama pengguna atau aplikasi (jika berlaku untuk platform).

      MSAL juga mempertahankan cache token dan menyegarkan token untuk Anda saat hampir kedaluwarsa. MSAL juga dapat membantu Anda menentukan audiens mana yang Anda inginkan untuk masuk aplikasi Anda, dan membantu Anda menyiapkan aplikasi dari file konfigurasi, dan memecahkan masalah aplikasi Anda.

      Autentikasi perangkat yang tersambung ke Gateway Lapangan

      Judul Detail
      Komponen Gateway Bidang IoT
      Fase SDL Membangun
      Teknologi yang Berlaku Generik
      Atribut Tidak Berlaku
      Referensi Tidak Berlaku
      Langkah-langkah Pastikan setiap perangkat diautentikasi oleh Gateway Bidang sebelum menerima data dari perangkat tersebut dan sebelum memfasilitasi komunikasi upstream dengan Gateway Cloud. Selain itu, pastikan perangkat tersambung dengan info masuk per perangkat sehingga masing-masing perangkat dapat diidentifikasi secara unik.

      Memastikan bahwa perangkat yang tersambung ke gateway Cloud diautentikasi

      Judul Detail
      Komponen Gateway IoT Cloud
      Fase SDL Membangun
      Teknologi yang Berlaku Generik, C#, Node.js,
      Atribut T/A, pilihan Gateway - Azure IoT Hub
      Referensi T/A, Azure IoT Hub dengan .NET, Memulai dengan IoT Hub dan Node JS, Mengamankan IoT dengan SAS dan sertifikat, repositori Git

      | Langkah-langkah |

      • Generik: Mengautentikasi perangkat menggunakan Keamanan Lapisan Transportasi (TLS) atau IPsec. Infrastruktur harus mendukung penggunaan kunci yang dibagikan sebelumnya (PSK) pada perangkat yang tidak dapat menangani kriptografi asimetris penuh. Manfaatkan ID Microsoft Entra, OAuth.
      • C#: Saat membuat instans DeviceClient, secara default, metode Buat membuat instans DeviceClient yang menggunakan protokol AMQP untuk berkomunikasi dengan IoT Hub. Untuk menggunakan protokol HTTPS, gunakan penggantian metode buat yang memungkinkan Anda untuk menentukan protokol. Jika menggunakan protokol HTTPS, Anda juga harus menambahkan paket Microsoft.AspNet.WebApi.Client NuGet ke dalam proyek untuk menyertakan namespace System.Net.Http.Formatting.
      |

      Contoh

      static DeviceClient deviceClient;

static string deviceKey = "{device key}";
static string iotHubUri = "{iot hub hostname}";

var messageString = "{message in string format}";
var message = new Message(Encoding.ASCII.GetBytes(messageString));

deviceClient = DeviceClient.Create(iotHubUri, new DeviceAuthenticationWithRegistrySymmetricKey("myFirstDevice", deviceKey));

await deviceClient.SendEventAsync(message);

      Contoh

      Node.js: Autentikasi

      Kunci simetris

      • Membuat IoT Hub di Azure
      • Membuat entri di registri identitas perangkat 
        var device = new iothub.Device(null);
device.deviceId = <DeviceId >
registry.create(device, function(err, deviceInfo, res) {})
      • Membuat perangkat yang disimulasikan 
        var clientFromConnectionString = require('azure-iot-device-amqp').clientFromConnectionString;
var Message = require('azure-iot-device').Message;
var connectionString = 'HostName=<host-name>DeviceId=<device-id>SharedAccessKey=<shared-access-key>';
var client = clientFromConnectionString(connectionString);

        Token SAS

      • Dihasilkan secara internal saat menggunakan kunci simetris tetapi kita dapat menghasilkan dan menggunakannya secara eksplisit juga
      • Tentukan protokol : var Http = require('azure-iot-device-http').Http;
      • Buat token sas : 
        resourceUri = encodeURIComponent(resourceUri.toLowerCase()).toLowerCase();
var deviceName = "<device-name>";
var expires = (Date.now() / 1000) + expiresInMins * 60;
var toSign = resourceUri + '\n' + expires;
// using crypto
var decodedPassword = new Buffer(signingKey, 'base64').toString('binary');
const hmac = crypto.createHmac('sha256', decodedPassword);
hmac.update(toSign);
var base64signature = hmac.digest('base64');
var base64UriEncoded = encodeURIComponent(base64signature);
// construct authorization string
var token = "SharedAccessSignature sr=" + resourceUri + "%2fdevices%2f"+deviceName+"&sig="
+ base64UriEncoded + "&se=" + expires;
if (policyName) token += "&skn="+policyName;
return token;
      • Sambungkan menggunakan token sas: 
        Client.fromSharedAccessSignature(sas, Http);

        Sertifikat

      • Hasilkan sertifikat X509 yang ditandatangani sendiri menggunakan alat apa pun seperti OpenSSL untuk menghasilkan file .cert dan .key untuk masing-masing menyimpan sertifikat dan kunci
      • Provisikan perangkat yang menerima koneksi aman menggunakan sertifikat. 
        var connectionString = '<connection-string>';
var registry = iothub.Registry.fromConnectionString(connectionString);
var deviceJSON = {deviceId:"<device-id>",
authentication: {
    x509Thumbprint: {
    primaryThumbprint: "<primary-thumbprint>",
    secondaryThumbprint: "<secondary-thumbprint>"
    }
}}
var device = deviceJSON;
registry.create(device, function (err) {});
      • Menyambungkan perangkat menggunakan sertifikat 
        var Protocol = require('azure-iot-device-http').Http;
var Client = require('azure-iot-device').Client;
var connectionString = 'HostName=<host-name>DeviceId=<device-id>x509=true';
var client = Client.fromConnectionString(connectionString, Protocol);
var options = {
    key: fs.readFileSync('./key.pem', 'utf8'),
    cert: fs.readFileSync('./server.crt', 'utf8')
};
// Calling setOptions with the x509 certificate and key (and optionally, passphrase) will configure the client //transport to use x509 when connecting to IoT Hub
client.setOptions(options);
//call fn to execute after the connection is set up
client.open(fn);

      Menggunakan kredensial autentikasi untuk setiap perangkat

      Judul Detail
      Komponen Gateway IoT Cloud
      Fase SDL Membangun
      Teknologi yang Berlaku Generik
      Atribut Pilihan Gateway - Azure IoT Hub
      Referensi Token Keamanan Azure IoT Hub
      Langkah-langkah Gunakan info masuk autentikasi per perangkat menggunakan token SaS berdasarkan kunci Perangkat atau Sertifikat Klien, bukan kebijakan akses bersama tingkat IoT Hub. Ini mencegah penggunaan kembali token autentikasi dari satu perangkat atau gerbang lapangan oleh perangkat lain.

      Memaastikan hanya kontainer dan blob yang diperlukan yang diberikan akses baca anonim

      Judul Detail
      Komponen Azure Storage
      Fase SDL Membangun
      Teknologi yang Berlaku Generik
      Atribut TipePenyimpanan - Gumpalan
      Referensi Mengelola akses baca anonim ke kontainer dan blob, Tanda Tangan Akses Bersama, Bagian 1: Memahami model SAS
      Langkah-langkah

      Secara default, kontainer dan blob apa pun di dalamnya mungkin hanya diakses oleh pemilik akun penyimpanan. Untuk memberikan izin baca kepada pengguna anonim ke kontainer dan blob-nya, seseorang dapat mengatur izin kontainer untuk mengizinkan akses publik. Pengguna anonim dapat membaca blob dalam kontainer yang dapat diakses publik tanpa mengautentikasi permintaan.

      Kontainer menyediakan opsi berikut untuk mengelola akses kontainer:

      • Akses baca publik penuh: Data kontainer dan blob dapat dibaca melalui permintaan anonim. Klien dapat menghitung blob dalam kontainer berdasarkan permintaan anonim, tetapi tidak dapat menghitung kontainer dalam akun penyimpanan.
      • Akses baca publik hanya untuk blob: Data blob dalam kontainer ini dapat dibaca melalui permintaan anonim, tetapi data kontainer tidak tersedia. Klien tidak dapat menghitung blob dalam kontainer melalui permintaan anonim
      • Tidak ada akses baca publik: Data kontainer dan blob hanya dapat dibaca oleh pemilik akun

      Akses anonim adalah yang terbaik untuk skenario di mana blob tertentu harus selalu tersedia untuk akses baca anonim. Untuk kontrol yang lebih halus, seseorang dapat membuat tanda tangan akses bersama, yang memungkinkan untuk mendelegasikan akses terbatas menggunakan izin yang berbeda dan selama interval waktu tertentu. Pastikan bahwa kontainer dan blob, yang mungkin berpotensi berisi data sensitif, tidak diberikan akses anonim secara tidak sengaja

      Memberikan akses terbatas ke objek di penyimpanan Azure menggunakan SAS atau SAP

      Judul Detail
      Komponen Azure Storage
      Fase SDL Membangun
      Teknologi yang Berlaku Generik
      Atribut Tidak Berlaku
      Referensi Tanda Tangan Akses Bersama, Bagian 1: Memahami model SAS, Tanda Tangan Akses Bersama, Bagian 2: Membuat dan menggunakan SAS dengan penyimpanan Blob, Cara mendelegasikan akses ke objek di akun Anda menggunakan Tanda Tangan Akses Bersama dan Kebijakan Akses yang Disimpan
      Langkah-langkah

      Menggunakan tanda tangan akses bersama (SAS) adalah cara yang ampuh untuk memberikan akses terbatas ke objek dalam akun penyimpanan ke klien lain, tanpa harus mengekspos kunci akses akun. SAS adalah URI yang mencakup dalam parameter kuerinya semua informasi yang diperlukan untuk akses terautentikasi ke sumber daya penyimpanan. Untuk mengakses sumber daya penyimpanan dengan SAS, klien hanya perlu meneruskan SAS ke konstruktor atau metode yang sesuai.

      Anda dapat menggunakan SAS ketika Anda ingin memberikan akses ke sumber daya di akun penyimpanan Anda ke klien yang tidak dapat dipercaya dengan kunci akun. Kunci akun penyimpanan Anda mencakup kunci utama dan sekunder, keduanya memberikan akses administratif ke akun Anda dan semua sumber daya di dalamnya. Mengekspos salah satu kunci akun Anda membuka akun Anda terhadap kemungkinan penggunaan yang berbahaya atau lalai. Tanda tangan akses bersama memberikan alternatif aman yang memungkinkan klien lain membaca, menulis, dan menghapus data di akun penyimpanan Anda sesuai dengan izin yang Anda berikan, dan tanpa memerlukan kunci akun.

      Jika Anda memiliki sekumpulan parameter logis yang serupa setiap kali, menggunakan Stored Access Policy (SAP) adalah ide yang lebih baik. Karena menggunakan SAS yang berasal dari Kebijakan Akses Tersimpan memberi Anda kemampuan untuk segera mencabut SAS tersebut, disarankan sebagai praktik terbaik untuk selalu menggunakan Kebijakan Akses Tersimpan jika memungkinkan.
      • Last updated on