Kebijakan Penggunaan yang Dapat Diterima

Kebijakan Penggunaan yang Dapat Diterima

Ini merupakan ikhtisar aturan penggunaan yang dapat diterima pada layanan proksi di seluruh industri. Pembatasan di bawah berasal dari berbagai penyedia; ketentuan ProxyCompass dijelaskan secara terpisah di bagian akhir.

Kebijakan Penggunaan yang Dapat Diterima, atau AUP, menjelaskan apa yang boleh dilakukan pelanggan melalui layanan proksi. Kebijakan ini menjadi bagian dari kebijakan layanan penyedia dan dapat diterbitkan terpisah atau dimasukkan dalam Ketentuan Layanan. Tujuan praktisnya terlihat ketika dua layanan mengiklankan proksi untuk tugas yang sama tetapi mengizinkan cara pelaksanaan yang berbeda.

Misalnya, satu kebijakan yang diterbitkan melarang pengumpulan informasi di balik login. Kebijakan lain mengizinkan akses informasi nonpublik dengan otorisasi. Di tempat lain, persetujuan tertulis diperlukan untuk uji beban meskipun pelanggan memiliki situs web tersebut. Perbedaan ini dapat menentukan apakah proksi yang telah dibayar dan berfungsi secara teknis cocok untuk tugasnya.

Pengumpulan data: apa yang berubah ketika halaman memerlukan login?

Misalkan perusahaan mengumpulkan harga dari situs web pemasok. Sebagian harga terlihat oleh semua orang; harga grosir muncul setelah perusahaan masuk ke akun pelanggannya. Bagi perusahaan, ini satu proyek pemantauan harga. Bagi AUP yang hanya mengizinkan data publik, kedua bagian itu berada di sisi berbeda dari penggunaan yang diizinkan: login sah milik pelanggan sendiri tidak menghilangkan pembatasan penyedia.

Kebijakan yang mengizinkan akses berotorisasi ke data nonpublik memungkinkan penilaian berbeda. Pertanyaan yang relevan menjadi apakah pelanggan memiliki izin untuk pengumpulan itu sendiri. Izin melihat halaman akun, mengekspor isinya, dan mendistribusikan kembali data hasilnya merupakan hal terpisah. Langganan yang membolehkan pegawai membaca materi belum tentu mengizinkan program menyalin dan menjualnya kembali.

Klausul lain menyangkut cara pengumpulan berjalan. AUP yang diterbitkan secara tegas mewajibkan kepatuhan pada petunjuk robots.txt, batas API, dan batas laju teknis milik tujuan. Dengan klausul seperti itu, menyebar permintaan ke banyak IP tidak dengan sendirinya membuat pengumpulan yang dilarang menjadi diizinkan. Pelanggan menyetujui ketentuan tersebut saat membeli layanan proksi; ini bukan pernyataan bahwa setiap petunjuk robots.txt adalah hukum.

Isi halaman juga penting. Harga produk publik dan detail kontak pribadi yang terlihat publik merupakan data berbeda. AUP dapat mewajibkan dasar hukum untuk pengumpulan data pribadi dan ketentuan lebih ketat untuk informasi medis, data anak, atau pelacakan orang yang dapat dikenali. Pembatasan juga dapat mencakup publikasi berikutnya atau pelatihan AI. Keberhasilan mengunduh halaman tidak menentukan izin untuk penggunaan lanjutan tersebut.

Otomatisasi dinilai dari tindakannya

“Scraper”, “bot”, dan “alat media sosial” menjelaskan perangkat lunak, tetapi sedikit menjelaskan perilakunya. Otomatisasi browser yang sama dapat memeriksa iklan atau menghasilkan klik berbayar palsu. AUP yang diterbitkan membedakan aktivitas berikut; dukungan untuk tugas di kolom kiri tidak berarti izin untuk tindakan di kanan.

Tugas yang mungkin didukung layanan Aktivitas yang dibatasi AUP yang diterbitkan
Memeriksa penempatan dan keterlihatan iklan Membuat tayangan atau klik berbayar palsu, termasuk klik yang dimaksudkan untuk menghabiskan anggaran pengiklan lain.
Memantau hasil dan posisi pencarian Membuat klik untuk memanipulasi peringkat atau membuat trafik tampak berasal dari pengguna yang berminat.
Mengelola akun sosial perusahaan Membuat profil, ulasan, pengikut, atau interaksi palsu; pendaftaran akun massal juga dapat dilarang.
Memantau harga dan ketersediaan tiket Pembelian otomatis untuk perolehan massal atau penjualan kembali dengan harga tinggi. Sebagian kebijakan melarang bot pembelian tiket sebagai kategori.

Perbedaan yang sama menjelaskan mengapa aturan antispam dapat berlaku meskipun port email diblokir. Pesan dapat dikirim melalui formulir, komentar, atau antarmuka pesan pribadi situs web. Menutup port SMTP mencegah satu jalur pengiriman email; tindakan itu tidak menghentikan setiap bentuk pesan yang tidak diminta.

Bentuk penyalahgunaan yang lebih langsung mencakup brute force, yang mencoba berbagai kemungkinan kata sandi, dan credential stuffing, yang menguji pasangan login dan kata sandi curian. Kebijakan juga melarang phishing, pemeriksaan kartu curian, penyebaran malware, serangan DDoS, dan konten ilegal, termasuk eksploitasi anak dan pelanggaran hak cipta. Larangan ini menyangkut aktivitas itu sendiri: sedikit percobaan dapat melanggar AUP walaupun hampir tidak memakai volume data.

Pembatasan yang melampaui serangan dan penipuan

AUP juga memuat pengecualian komersial. Daftar yang benar-benar diterbitkan mencakup survei berbayar, perdagangan barang dalam gim, domain terkait streaming, perdagangan mata uang kripto, perjudian, dan konten dewasa. Ini merupakan contoh dari aturan layanan berbeda, bukan larangan bersama di seluruh industri. Penyedia dapat mengecualikan kegiatan bisnis tanpa menyatakan bahwa setiap pelaksanaannya merupakan kejahatan.

Penjualan kembali merupakan pembatasan konkret lainnya. Menjual akses kredensial proksi sewaan kepada pelanggan mungkin memerlukan perjanjian terpisah atau dilarang oleh kontrak standar. Fitur subpengguna pada dasbor tidak menyelesaikan persoalan ini: kredensial terpisah mungkin dimaksudkan untuk tim pelanggan sendiri. Agensi yang memakai proksi untuk menyiapkan laporan dan bisnis yang menjual akses proksi itu sendiri menawarkan layanan berbeda.

Sebagian ketentuan melindungi kumpulan proksi itu sendiri. Ketentuan tersebut melarang pemberian informasi yang diperoleh tentang alamat dan simpulnya kepada basis data yang mendeteksi proksi, menilai reputasi IP, atau memblokir trafik. Misalnya, menyewa akses untuk mengatalogkan IP yang dipakai penyedia mengakses situs web dan menyumbangkannya ke basis data deteksi proksi dapat melanggar klausul tersebut meskipun tidak ada situs tujuan yang diserang. Pembatasan ini melindungi nilai komersial jaringan.

Klausul tersebut menjelaskan mengapa AUP tidak dapat dipersempit menjadi daftar kejahatan. Klausul dapat menentukan apakah model bisnis yang sah cocok dengan layanan tertentu. Perubahan dari riset internal menjadi penjualan kembali, atau dari pengumpulan harga publik menjadi pembuatan kumpulan data tentang orang, dapat mengubah penilaian kontraktual meskipun program dan pengaturan proksi tetap sama.

Menguji situs web sendiri tetap dapat memerlukan persetujuan

Perusahaan mempekerjakan kontraktor untuk memindai kerentanan situs webnya. Perusahaan dapat mengizinkan pengujian, tetapi tidak mengendalikan jaringan proksi kontraktor. Aturan proksi yang diterbitkan mencakup persyaratan tegas untuk persetujuan tertulis penyedia sebelum pemindaian kerentanan atau pengujian stres dan beban. Karena itu, izin pemilik situs belum tentu melengkapi semua persetujuan yang diperlukan untuk tugas tersebut.

Jaringan yang membawa pengujian juga menghadapi trafik dan keluhan yang dihasilkan. Pemindaian mungkin mencapai sistem di luar sasaran yang disepakati; uji beban dapat memengaruhi hosting bersama atau layanan perlindungan. Jika penyedia mengizinkan pengujian ini, kesepakatan tentang sasaran, metode, dan periode mengidentifikasi trafik yang disetujui untuk dibawa. Deskripsi umum seperti “riset keamanan” tidak memastikan cakupan itu.

Bagaimana aktivitas melalui proksi menjadi laporan penyalahgunaan

Klien A17 dapat mengakses IP 198.51.100.24 dan 198.51.100.25 dan memakainya untuk menebak kata sandi di situs web. Situs mengirim keluhan kepada penyedia yang mencantumkan IP tersebut dan waktu 14:03–14:06 UTC. Penyedia mencocokkan catatan koneksi pada 14:04 dan 14:05 dan mengidentifikasi klien A17 secara tepat. Klien diminta menghentikan aktivitas dan menjelaskan kejadian; akses ke situs ini dihentikan. Baru setelah itu penyedia melaporkan tindakan yang diambil kepada situs. Bagian bawah: serangan dapat membuat subnet penyedia masuk daftar blokir. Situs web menggunakan daftar ini dan juga memblokir IP pelanggan lain. Pelanggan tidak dapat bekerja, dan penyedia kehilangan pelanggan serta pendapatan.
Contoh: situs web melaporkan IP dan waktu penebakan kata sandi. Penyedia mencocokkan kejadian dengan catatannya, mengidentifikasi klien A17, menghentikan akses klien tersebut ke situs, dan melaporkan tindakan yang diambil.

Tujuan melihat IP yang digunakan proksi. Jika operatornya mengamati serangan kata sandi atau pemindaian jaringan, bukti awalnya mengidentifikasi alamat tersebut. Laporan dapat dikirim kepada penyedia proksi atau perusahaan hosting yang memasok alamat dan server. Pada kasus kedua, penjual proksi menerima masalah itu dari pemasoknya sendiri.

Dokumentasi hosting yang diterbitkan menunjukkan isi yang mungkin ada dalam bukti tersebut. Catatan pemindaian jaringan mencantumkan waktu, IP sumber, IP tujuan, dan port tujuan. Misalnya, koneksi berulang dari satu sumber ke port 22 pada server berbeda dapat dilaporkan sebagai pemindaian layanan SSH. Sebaliknya, laporan banjir trafik mungkin memuat laju paket dan ringkasan trafik menurut tujuan. Catatan ini menjelaskan insiden berbeda dan memerlukan penjelasan berbeda.

Penyedia kemudian perlu menghubungkan kejadian eksternal dengan aktivitas pelanggan. Pada alamat khusus, alokasi dapat membantu; pada IP proksi bersama atau berotasi, alamat saja mungkin tidak cukup. Pelanggan dapat memakai IP yang sama pada waktu berbeda atau secara bersamaan. Waktu yang tepat, zona waktunya, dan port sumber jika tersedia serta relevan membantu membedakan koneksi. Ini bergantung pada catatan yang benar-benar dimiliki jaringan.

Waktu kedatangan keluhan juga berbeda dari waktu aktivitas yang dijelaskannya. Tugas yang sedang menganggur saat dukungan menghubungi pelanggan mungkin menghasilkan trafik yang dilaporkan sebelumnya. Karena itu, hanya memeriksa daftar proses saat ini atau apakah proksi berfungsi sekarang tidak menjawab laporan tersebut.

Proses ini tidak mengharuskan penyedia proksi membaca setiap halaman HTTPS. Dengan TLS ujung ke ujung biasa melalui terowongan proksi, jalur halaman, kata sandi yang dikirim, dan isi respons terenkripsi. Sasaran dapat memberikan bukti dari sisinya sendiri, sementara penyedia atau hosting memiliki informasi jaringan yang tersedia baginya. Browser terkelola atau API pengambilan data yang benar-benar memproses halaman memiliki peran dan kemampuan melihat yang berbeda.

Mengapa satu tujuan bisa berhenti berfungsi sementara yang lain tetap dimuat

Penegakan aturan tidak selalu menonaktifkan akun. Prosedur penanganan keluhan yang diterbitkan mengizinkan pembatasan sementara hanya pada situs atau host yang disebut dalam laporan. Trafik lain dapat berlanjut. Dalam situasi ini, alat pemeriksa proksi dapat melaporkan koneksi berfungsi meskipun tugas utama pelanggan tidak dapat mencapai tujuannya.

Ada pula aturan pencegahan. Sebagian layanan memantau laju permintaan ke tujuan sensitif, seperti halaman login bank, dan menerapkan pembatasan tambahan ketika aktivitas menjadi berlebihan. Karena itu, suatu kategori dapat dijangkau dalam penggunaan normal tanpa tersedia untuk permintaan otomatis tanpa batas. Ini merupakan kendali tujuan, belum tentu kuota volume data bulanan.

AUP dan penggunaan wajar dapat bertumpang tindih di sini, tetapi alasan tindakan tetap penting. Pengumpul harga dapat membebani sumber daya bersama secara berlebihan ketika menjalankan tugas yang diizinkan. Serangan kata sandi dapat melanggar AUP pada volume jauh lebih rendah. Membeli volume data tambahan hanya mengatasi masalah pertama jika mengubah kapasitas terkait; pembelian itu tidak mengizinkan aktivitas kedua.

Penyedia hosting di hulu dapat menerapkan pembatasan lebih luas. Aturan hosting menjelaskan penguncian satu IP, beberapa alamat, atau seluruh server setelah serangan dan pemindaian. Penjual proksi yang memakai infrastruktur tersebut mungkin harus menyelesaikan insiden dengan hosting sebelum akses kembali. Mengganti IP proksi sambil melanjutkan aktivitas yang sama membiarkan penyebabnya tetap ada.

Tidak ada pula urutan peringatan yang berlaku universal. Sebagian kebijakan menjelaskan upaya menyelesaikan masalah bersama pelanggan sambil tetap berhak menangguhkan setelah pelanggaran pertama. Sistem akun yang diterbitkan juga membedakan laporan penyalahgunaan, pelanggaran AUP yang terdeteksi, dan masalah penipuan pembayaran. Pelanggan perlu mengetahui alasan serta cakupan pembatasan yang dinyatakan; satu kata “ditangguhkan” tidak memberikan informasi itu.

Jika kontraktor atau pengguna lain yang mengirim trafik

Kredensial proksi dapat dipasang pada beberapa aplikasi atau diserahkan kepada agensi. Ketentuan penyedia dapat menetapkan pemegang akun bertanggung jawab atas aktivitas melalui akses tersebut. Hubungan penyedia adalah dengan pelanggan yang membeli layanan, sehingga penjelasan bahwa kontraktor menjalankan program tidak dengan sendirinya menyelesaikan insiden.

Tugas praktisnya adalah mengidentifikasi aplikasi atau orang yang memakai kredensial pada waktu yang dilaporkan dan menghentikan aktivitas terkait. Jika akses bocor, kredensial yang terekspos perlu dicabut atau diganti. Kredensial terpisah dan catatan tugas, jika didukung layanan, dapat mempermudah pekerjaan ini. Keduanya tidak menciptakan pengecualian terhadap AUP.

Pembatasan akun juga dapat mencakup upaya menghindari aturan penyedia sendiri: membuka akun pengganti setelah pelarangan, mengklaim uji coba berulang yang melanggar ketentuan, atau menghindari verifikasi identitas. Akun baru atau IP yang baru dialokasikan tidak mengubah operasi terlarang yang sama menjadi operasi yang disetujui.

Apa yang terjadi pada paket berbayar dan saldonya

Ada beberapa konsekuensi keuangan yang mungkin timbul, dan semuanya perlu dibedakan. Salah satunya adalah biaya pekerjaan penanganan keluhan. Lainnya adalah hilangnya hak layanan yang belum digunakan ketika kontrak dihentikan karena pelanggaran. Ketiga adalah kewajiban menanggung klaim atau pengeluaran pihak ketiga tertentu akibat perilaku pelanggan. Jumlah yang dibayar untuk paket proksi belum tentu membatasi seluruh kewajiban tersebut.

Ini merupakan perbedaan kontraktual yang nyata. Ketentuan yang diterbitkan mencakup hangusnya kredit yang belum digunakan setelah penghentian karena pelanggaran, sambil memberikan perlakuan berbeda ketika penyedia mengakhiri layanan atas pertimbangannya sendiri. Sebagian juga menyatakan bahwa penangguhan untuk kepatuhan tidak otomatis memperpanjang langganan atau masa berlaku kredit. Karena itu, akun yang menganggur belum tentu berarti periode berbayarnya dijeda.

Biaya penanganan keluhan tidak memiliki jumlah standar di seluruh industri. Membayarnya melunasi biaya yang dinyatakan dalam perjanjian; pembayaran itu tidak membeli izin untuk melanjutkan aktivitas terlarang atau menjamin pemulihan. Sebaliknya, kedatangan laporan saja tidak memastikan setiap konsekuensi keuangan. Dasar pembatasan atau penghentian yang relevan dan ketentuan pembayaran yang berlaku menentukan hasil kontraktual, dengan tetap tunduk pada hak hukum yang wajib berlaku.

Apa yang perlu dikirim ketika dukungan menghubungi Anda

Dukungan memerlukan tanggapan tentang aktivitas yang dijelaskan dalam laporan. “Proksi berfungsi”, “paket sudah dibayar”, dan “kami hanya melakukan scraping” tidak mengidentifikasi penyebab koneksi yang dilaporkan. Tanggapan yang berguna menghubungkan kejadian dengan tugas pelanggan yang sebenarnya dan menjelaskan tindakan yang telah dilakukan.

  1. Jeda tugas yang terdampak dan simpan pengaturan serta log yang tersedia. Gunakan waktu aktivitas yang dilaporkan, termasuk zona waktunya, bukan waktu Anda menerima pesan.
  2. Identifikasi aplikasi, tugas terjadwal, pegawai, atau kontraktor yang menggunakan akses. Bandingkan tujuan dan IP proksi dengan catatan Anda. Mintalah detail yang belum tersedia melalui saluran dukungan penyedia.
  3. Jelaskan penyebab dan perubahan yang dibuat: misalnya, tugas dihentikan, tujuan yang tidak disengaja dihapus, atau akses yang terekspos dicabut. Untuk pengujian yang telah disepakati, sertakan izin tertulis dan cakupannya.
  4. Pastikan pembatasan mana yang masih berlaku dan apa yang diperlukan penyedia sebelum pekerjaan yang diizinkan dapat dilanjutkan. Hindari memulai operasi yang sama pada IP lain selama penyebabnya belum diselesaikan.

Penyedia dapat menggunakan tiket, formulir dasbor, atau proses tanggapan khusus. Sebagian layanan menyediakan teks keluhan dan statusnya melalui API. Ini merupakan cara menangani insiden; tidak ada yang menetapkan waktu pemulihan universal. Tenggat untuk meninjau tanggapan pelanggan juga berbeda dari janji mengaktifkan kembali layanan.

Kembali ke pusat pengetahuan