<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Keamanan Jaringan on Nalar</title>
    <link>https://nalar.dev/id/tags/keamanan-jaringan/</link>
    <description>Recent content in Keamanan Jaringan on Nalar</description>
    <generator>Hugo</generator>
    <language>id-id</language>
    <lastBuildDate>Tue, 22 Sep 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://nalar.dev/id/tags/keamanan-jaringan/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>DNSSEC Mengautentikasi Data DNS dengan Rantai Bertanda Tangan</title>
      <link>https://nalar.dev/id/dnssec-mengautentikasi-data-dns-dengan-rantai-bertanda-tangan/</link>
      <pubDate>Tue, 22 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/dnssec-mengautentikasi-data-dns-dengan-rantai-bertanda-tangan/</guid>
      <description>&lt;h1 id=&#34;dnssec-mengautentikasi-data-dns-dengan-rantai-bertanda-tangan&#34;&gt;DNSSEC Mengautentikasi Data DNS dengan Rantai Bertanda Tangan&lt;/h1&gt;&#xA;&lt;p&gt;DNS pada dasarnya menjawab pertanyaan penamaan: record apa yang terkait dengan sebuah domain? Jalur respons dasar protokol tidak dengan sendirinya memberi resolver pemvalidasi bukti kriptografis bahwa kumpulan record yang diterima merupakan data yang diotorisasi pemilik zone.&lt;/p&gt;&#xA;&lt;p&gt;DNS Security Extensions, atau DNSSEC, menambahkan bukti tersebut. Zone yang ditandatangani memublikasikan public key dan signature yang memungkinkan resolver pemvalidasi mengautentikasi data DNS melalui rantai yang berakar pada trust anchor terkonfigurasi. DNSSEC melindungi autentisitas dan integritas data DNS. Mekanisme ini tidak mengenkripsi query atau response, serta tidak menyembunyikan nama yang diminta.&lt;/p&gt;</description>
    </item>
    <item>
      <title>DNSSEC Memvalidasi Data DNS melalui Delegasi Bertanda Tangan</title>
      <link>https://nalar.dev/id/dnssec-memvalidasi-data-dns-melalui-delegasi-bertanda-tangan/</link>
      <pubDate>Mon, 21 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/dnssec-memvalidasi-data-dns-melalui-delegasi-bertanda-tangan/</guid>
      <description>&lt;h1 id=&#34;dnssec-memvalidasi-data-dns-melalui-delegasi-bertanda-tangan&#34;&gt;DNSSEC Memvalidasi Data DNS melalui Delegasi Bertanda Tangan&lt;/h1&gt;&#xA;&lt;p&gt;DNS pada dasarnya menjawab pertanyaan tentang nama dan resource record tanpa bukti kriptografis bahwa data yang dikembalikan benar-benar berasal dari operator zone. DNS Security Extensions (DNSSEC) menambahkan signature dan rantai delegasi yang dapat diperiksa resolver validator sebelum data DNS bertanda tangan diperlakukan sebagai autentik.&lt;/p&gt;&#xA;&lt;p&gt;Proteksinya memiliki batas yang jelas. DNSSEC menyediakan autentikasi asal data dan integritas untuk data DNS. Mekanisme ini tidak mengenkripsi query atau response, menyembunyikan nama yang ditanyakan, atau mengautentikasi aplikasi yang dicapai setelah resolusi. Record &lt;code&gt;A&lt;/code&gt; bertanda tangan yang valid dapat membuktikan bahwa record tersebut autentik dalam rantai DNSSEC; hal itu tidak membuktikan bahwa server pada alamat tersebut aman.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Mutual TLS Mengautentikasi Kedua Sisi Koneksi</title>
      <link>https://nalar.dev/id/mutual-tls-mengautentikasi-kedua-sisi-koneksi/</link>
      <pubDate>Mon, 21 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/mutual-tls-mengautentikasi-kedua-sisi-koneksi/</guid>
      <description>&lt;h1 id=&#34;mutual-tls-mengautentikasi-kedua-sisi-koneksi&#34;&gt;Mutual TLS Mengautentikasi Kedua Sisi Koneksi&lt;/h1&gt;&#xA;&lt;p&gt;Koneksi HTTPS konvensional mengautentikasi server dengan certificate, sementara client biasanya membuktikan identitasnya kemudian melalui mekanisme aplikasi seperti session cookie, bearer token, atau password. Mutual TLS, yang umum disingkat mTLS, menambahkan autentikasi client berbasis certificate ke dalam exchange TLS.&lt;/p&gt;&#xA;&lt;p&gt;Hasilnya adalah transport channel tempat setiap peer dapat memverifikasi certificate chain dan proof of possession atas private key dari sisi lainnya. Hal itu mengubah boundary autentikasi, tetapi tidak menjadikan certificate sebagai authorization policy. Identitas client yang valid tetap dapat ditolak saat mengakses resource tertentu.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Verifikasi Host Key SSH Mengikat Koneksi ke Identitas Server</title>
      <link>https://nalar.dev/id/verifikasi-host-key-ssh-mengikat-koneksi-ke-identitas-server/</link>
      <pubDate>Mon, 21 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/verifikasi-host-key-ssh-mengikat-koneksi-ke-identitas-server/</guid>
      <description>&lt;h1 id=&#34;verifikasi-host-key-ssh-mengikat-koneksi-ke-identitas-server&#34;&gt;Verifikasi Host Key SSH Mengikat Koneksi ke Identitas Server&lt;/h1&gt;&#xA;&lt;p&gt;SSH mengenkripsi koneksi, tetapi enkripsi saja tidak memastikan endpoint yang dicapai merupakan server yang dituju. Saat key exchange, server membuktikan kepemilikan host private key. Client kemudian harus memutuskan apakah identitas publik yang terkait dapat dipercaya untuk host tersebut.&lt;/p&gt;&#xA;&lt;p&gt;Keputusan itu merupakan boundary autentikasi host. Jika client menerima host key milik penyerang tanpa dasar trust yang valid, channel yang terbentuk tetap dapat terenkripsi tetapi berakhir pada mesin yang salah. Password, command, forwarded agent, dan data sesi kemudian dapat melintasi boundary yang tidak dimaksudkan operator.&lt;/p&gt;</description>
    </item>
    <item>
      <title>DNS Rebinding Mengubah Validasi Nama Menjadi Risiko Saat Koneksi Dibuka</title>
      <link>https://nalar.dev/id/dns-rebinding-mengubah-validasi-nama-menjadi-risiko-saat-koneksi-dibuka/</link>
      <pubDate>Sun, 20 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/dns-rebinding-mengubah-validasi-nama-menjadi-risiko-saat-koneksi-dibuka/</guid>
      <description>&lt;h1 id=&#34;dns-rebinding-mengubah-validasi-nama-menjadi-risiko-saat-koneksi-dibuka&#34;&gt;DNS Rebinding Mengubah Validasi Nama Menjadi Risiko Saat Koneksi Dibuka&lt;/h1&gt;&#xA;&lt;p&gt;Fitur HTTP outbound dapat terlihat aman setelah menolak alamat IP loopback dan private yang ditulis secara langsung. Service mem-parsing URL dari user, me-resolve hostname, memeriksa alamat hasil resolusi terhadap allowlist, lalu membiarkan HTTP client membuka koneksi.&lt;/p&gt;&#xA;&lt;p&gt;Urutan tersebut memiliki celah. Keputusan policy berlaku pada alamat yang terlihat pada satu waktu, sedangkan koneksi jaringan dapat melakukan lookup DNS lain beberapa saat kemudian. Jika hostname dikendalikan attacker, jawaban DNS dapat berubah di antara kedua tahap itu. Nama yang sudah divalidasi tetap sama, tetapi alamat tujuan berubah.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
