Urutan evaluasi aturan

Evaluasi aturan menentukan apakah permintaan web harus diizinkan atau ditolak dengan menggunakan aturan yang Anda tetapkan dalam kebijakan. Alat ini mempertimbangkan atribut berikut untuk membuat keputusannya:

  • Prioritas aturan: Bilangan bulat yang lebih rendah menunjukkan prioritas yang lebih tinggi.
  • SessionMatcher: Mencocokkan atribut tingkat sesi berikut:
    • Alamat IP mesin sumber
    • Akun layanan perangkat sumber
    • Tag Aman mesin sumber
    • Nama host mesin target
  • ApplicationMatcher: Mencocokkan atribut permintaan HTTP berikut:
    • URL
    • Jalur
    • Header permintaan

Untuk daftar semua atribut SessionMatcher dan ApplicationMatcher, lihat Atribut yang tersedia di SessionMatcher dan ApplicationMatcher.

Cara kerja evaluasi aturan

Aturan dievaluasi dalam urutan berikut:

  1. Aturan berprioritas tinggi akan dievaluasi terlebih dahulu.
  2. Aturan prioritas tertinggi yang cocok dengan atribut SessionMatcher dan ApplicationMatcher menentukan tindakan yang akan dilakukan pada traffic.
  3. Jika permintaan tidak cocok dengan atribut SessionMatcher dan ApplicationMatcher aturan tersebut, aturan berikutnya dengan prioritas tertinggi akan dievaluasi.
  4. Proses ini berlanjut hingga ditemukan aturan yang cocok dengan permintaan, atau semua aturan telah dievaluasi. Jika tidak ditemukan kecocokan, permintaan akan ditolak.

Sebelum mengonfigurasi pemeriksaan TLS

Anda harus memahami skenario evaluasi aturan berikut sebelum mengonfigurasi pemeriksaan TLS:

  • Klien dapat mengirim permintaan HTTP ke server proxy. Permintaan kemudian dievaluasi menggunakan semua data yang tersedia, termasuk nama host, identitas sumber, header HTTP, dan jalur.

    Jika permintaan diizinkan, traffic HTTP akan dikirim ke tujuan. Namun, jika permintaan ditolak, traffic HTTP tidak akan diizinkan untuk diteruskan.

  • Klien dapat mengirim permintaan HTTP CONNECT ke proxy untuk membuat terowongan TCP ke tujuan. Hal ini dilakukan saat klien ingin mengirim traffic TCP arbitrer atau membuat koneksi TLS end-to-end dengan tujuan melalui proxy, seperti halnya HTTPS.

  • Jika aturan memiliki atribut SessionMatcher yang cocok dan tidak berisi atribut ApplicationMatcher, dan evaluasi aturan menghasilkan traffic yang diizinkan, tunnel ke tujuan akan dibuat dan traffic akan di-proxy-kan TCP. Ini berlaku untuk traffic HTTPS dan TCP.

  • Jika aturan berprioritas lebih tinggi tidak dapat menentukan tindakan yang harus dilakukan pada permintaan, evaluasi aturan akan dilanjutkan. Jika evaluasi dilanjutkan ke aturan dengan atribut ApplicationMatcher, traffic yang di-tunnel akan ditafsirkan sebagai HTTP atau HTTPS.

    Jika data yang mendasarinya bukan HTTP atau HTTPS, koneksi akan gagal.

    Jika data yang mendasari adalah HTTP, permintaan akan dievaluasi, termasuk nama host, identitas sumber, header HTTP, dan jalur. Berdasarkan hasil evaluasi, traffic diizinkan atau ditolak.

  • Untuk traffic HTTPS, aturan hanya dievaluasi jika tanda pemeriksaan TLS diaktifkan; jika tidak, aturan tersebut akan dilewati.

  • Untuk traffic HTTPS, aturan hanya diperiksa jika kondisi berikut terpenuhi:

    • Tanda inspeksi TLS diaktifkan.
    • Traffic cocok dengan atribut SessionMatcher.

Rekomendasi untuk mengonfigurasi aturan pemeriksaan TLS

  • Jika Anda ingin mengizinkan traffic TCP, maka aturan yang mengizinkan traffic TCP harus memiliki prioritas yang lebih tinggi daripada aturan yang mengizinkan traffic HTTP.
  • Aturan dengan atribut ApplicationMatcher harus dicakup secara erat menggunakan atribut SessionMatcher untuk meminimalkan penafsiran alur yang tidak terkait sebagai HTTP.
  • Aturan yang mengizinkan traffic TLS (termasuk HTTPS) tetapi tidak melakukan pemeriksaan TLS dapat ditafsirkan sebagai aturan proxy TCP.
  • Untuk menghindari pemeriksaan TLS atas traffic yang tidak perlu, prioritas aturan pemeriksaan TLS harus lebih rendah daripada aturan pemeriksaan non-TLS. Atau, untuk menggagalkan dengan cepat untuk traffic yang tidak cocok, aturan pemeriksaan TLS harus dicakup secara ketat menggunakan atribut SessionMatcher.

Contoh konfigurasi aturan pemeriksaan TLS

Pertimbangkan dua aturan dalam contoh berikut.

Contoh 1

Dalam contoh ini, kami mengasumsikan adanya aturan berprioritas lebih rendah lainnya. Pertimbangkan dua aturan berikut:

  • Aturan 1

    description: do not allow POST requests
priority: 10
basicProfile: DENY
sessionMatcher: true
tlsInspectionEnabled: true
applicationMatcher: request.method == 'POST'

  • Aturan 2

    description: allow TCP proxying from tag 12345 to example.com
priority: 20
basicProfile: ALLOW
sessionMatcher: source.matchTag('tagValues/12345') && host() == 'example.com'

Pada contoh ini, Secure Web Proxy menafsirkan dua aturan sebagai berikut:

  • Mengizinkan traffic TCP tetapi melarang jenis permintaan HTTP tertentu tidak dapat terjadi bersamaan karena traffic TCP dapat berisi permintaan POST.
  • Traffic dalam aturan 2 tidak pernah diizinkan. Permintaan ini ditolak karena traffic dari tag 12345 ke example.com dicegat dan ditafsirkan sebagai HTTP untuk mengevaluasi metode HTTP.

  • Agar aturan 2 dapat diterapkan, Anda dapat menggunakan salah satu solusi berikut:

    • Direkomendasikan: Tingkatkan prioritas aturan 2 ke tingkat yang lebih tinggi (prioritas: 5).

    • Aturan cakupan 1 untuk menghindari tumpang-tindih traffic yang diizinkan dengan atribut SessionMatcher-nya:

      sessionMatcher: !(source.matchTag('tagValues/12345') && host() == 'example.com')

      Kami tidak merekomendasikan solusi ini karena akan sulit untuk mempertahankan banyak aturan yang tumpang-tindih.

Contoh 2

Pertimbangkan dua aturan berikut:

  • Aturan 1

    description: allow to specific GitHub repository (TLS inspect to match specific path)
priority: 10
basicProfile: ALLOW
sessionMatcher: true
tlsInspectionEnabled: true
applicationMatcher: request.url().startsWith('github.com/grpc/grpc')

  • Aturan 2

    description: allow TCP proxying from tag 12345 to example.com
priority: 20
basicProfile: ALLOW
sessionMatcher: host() == 'bankofamerica.com'

Pada contoh ini, Secure Web Proxy menafsirkan dua aturan sebagai berikut:

  • Semua traffic, termasuk yang ditujukan untuk bankofamerica.com, diperiksa untuk TLS agar cocok dengan request.url() aturan prioritas tinggi 1.

  • Untuk menghindari pemeriksaan TLS di aturan 2, Anda dapat menggunakan salah satu solusi berikut:

    • Tingkatkan prioritas aturan 2 ke tingkat yang lebih tinggi (prioritas: 5). Akibatnya, aturan 2 diterapkan sebelum mengevaluasi aturan 1, dan traffic dari bankofamerica.com diizinkan tanpa diperiksa TLS.

    • Direkomendasikan: Persempit cakupan aturan 1 untuk mengizinkan pemeriksaan TLS khusus untuk domain github.com. Untuk mempersempit cakupan, tambahkan atribut sessionMatcher yang ditargetkan:

      sessionMatcher: host() == 'github.com'

Batasan

Anda harus mempertimbangkan batasan berikut sebelum mengonfigurasi pemeriksaan TLS:

  • Server hanya diverifikasi menggunakan root certificate publik. Kumpulan root certificate authority (CA) didasarkan pada Mozilla Root Program. Perilaku verifikasi sertifikat dapat berubah dan sesuai dengan cara browser web memverifikasi sertifikat.

    Karena verifikasi backend saat ini tidak dapat dilakukan, traffic ke server dengan sertifikat pribadi atau yang ditandatangani sendiri tidak dapat dicegat.

  • Proxy Web Aman tidak menjalankan pemeriksaan daftar pencabutan sertifikat (CRL).

  • Agar pemeriksaan TLS berfungsi, klien saat ini harus mengirimkan Server Name Indication (SNI). SNI adalah ekstensi spesifikasi TLS yang bersifat opsional, tetapi sebagian besar klien mengaktifkannya secara default.

  • Pemeriksaan TLS tidak berfungsi jika klien mewajibkan Encrypted Client Hello (ECH) (sebelumnya dikenal sebagai Encrypted SNI).

    ECH adalah draf standar IETF yang memungkinkan klien untuk mengenkripsi awal handshake TLS menggunakan kunci server yang sudah ditetapkan. Karena pemeriksaan TLS bertindak sebagai proxy pencegat, proxy tidak memiliki akses ke kunci server yang telah ditetapkan sebelumnya. Akibatnya, ECH tidak berfungsi.

  • Klien harus dikonfigurasi agar memercayai root certificate pribadi Anda.

  • Jika menghapus CA dari kumpulan CA pribadi, Anda akan melihat sertifikat yang di-cache yang ditandatangani oleh CA tersebut hingga 28 jam. Untuk mencegah penggunaan sertifikat yang di-cache, Anda dapat memperbarui kebijakan pemeriksaan TLS agar mengarah ke kumpulan CA baru. Akibatnya, Secure Web Proxy terpaksa membuat sertifikat baru.