Urutan evaluasi aturan

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

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

Untuk mengetahui 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 prioritas tinggi 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 dari 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 Anda mengonfigurasi pemeriksaan TLS

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

  • Klien dapat mengirim permintaan HTTP ke server proxy. Permintaan tersebut 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 diizinkan untuk diteruskan.

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

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

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

    Jika data pokoknya bukan HTTP atau HTTPS, koneksi akan gagal.

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

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

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

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

Rekomendasi untuk mengonfigurasi aturan pemeriksaan TLS

  • Jika Anda ingin mengizinkan traffic TCP, aturan yang mengizinkan traffic TCP harus memiliki prioritas yang lebih tinggi daripada aturan yang mengizinkan traffic HTTP.
  • Aturan dengan atribut ApplicationMatcher harus memiliki cakupan yang ketat dengan menggunakan atribut SessionMatcher untuk meminimalkan interpretasi aliran 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 yang tidak perlu terhadap traffic, prioritas aturan pemeriksaan TLS harus lebih rendah daripada aturan pemeriksaan non-TLS. Atau, untuk gagal cepat pada traffic yang tidak cocok, aturan pemeriksaan TLS harus dibatasi dengan ketat menggunakan atribut SessionMatcher.

Contoh konfigurasi aturan pemeriksaan TLS

Perhatikan dua aturan dalam contoh berikut.

Contoh 1

Dalam contoh ini, kami mengasumsikan adanya aturan prioritas 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'

Dalam contoh ini, Secure Web Proxy menafsirkan kedua aturan tersebut sebagai berikut:

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

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

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

    • Cakupan aturan 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'

Dalam contoh ini, Secure Web Proxy menafsirkan kedua aturan tersebut sebagai berikut:

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

  • Untuk menghindari pemeriksaan TLS dalam 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 ini sebelum mengonfigurasi pemeriksaan TLS:

  • Server hanya diverifikasi menggunakan sertifikat root publik. Set 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 tidak dapat dilakukan saat ini, traffic ke server dengan sertifikat pribadi atau yang ditandatangani sendiri tidak dapat disadap.

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

  • Agar pemeriksaan TLS berfungsi, klien saat ini harus mengirim 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 memerlukan Encrypted Client Hello (ECH) (sebelumnya dikenal sebagai Encrypted SNI).

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

  • Klien harus dikonfigurasi untuk memercayai root certificate pribadi Anda.

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