RFP akses jarak jauh: 20 pertanyaan yang memaksa keterbukaan

Membeli perangkat lunak akses-jarak jauh dengan ceklis terasa aman sampai semua vendor menjawab "ya" untuk setiap poin. Pekerjaan nyata dalam sebuah RFP adalah memaksa vendor menunjukkan bukti — diagram, nama protokol, sertifikat, log — sehingga Anda dapat membandingkan kompromi, bukan pemasaran. Artikel ini memberikan 20 pertanyaan terarah yang memisahkan klaim vendor dari realitas operasional, menjelaskan seperti apa jawaban yang baik, dan menandai lubang berbahaya yang harus Anda tolak.

Cara membaca jawaban ini

Jangan menilai vendor berdasarkan apakah mereka mengatakan "kami mendukung X" — nilai mereka berdasarkan artefak yang mereka sediakan. Minta diagram arsitektur, sidik jari sertifikat TLS, contoh catatan log (disanitasi), garis waktu insiden yang terdokumentasi, dan akun uji yang mereproduksi perilaku yang diklaim. Jika vendor menolak menyediakan bukti, penolakan itu sendiri adalah jawaban.

20 pertanyaan yang membongkar klaim vendor

1. Apa model koneksi Anda (P2P, brokered, relay)?

   Mengapa ini penting: Kinerja, latensi, dan siapa yang dapat mengamati lalu lintas bergantung pada apakah sesi bersifat langsung atau diproksikan. Mintalah diagram dan deskripsi aliran paket.

   Bukti yang dapat diterima: Diagram jaringan yang menunjukkan traversal NAT, penggunaan STUN/TURN, dan fallback; contoh rentang IP yang digunakan oleh relay.

   Tanda bahaya: Jawaban samar seperti "kami melakukan apa pun yang tercepat" atau menolak untuk menjelaskan mekanisme fallback.

2. Jika sesi menggunakan relay, siapa yang mengoperasikannya dan di mana regionnya?

   Mengapa ini penting: Operator relay dapat melihat lalu lintas yang didekripsi jika TLS berakhir di sana. Anda perlu tahu apakah relay bersifat multi‑region, region tunggal, atau dioperasikan oleh pelanggan.

   Bukti yang dapat diterima: Daftar entitas operator relay, peta region, dan SLA untuk failover regional. Untuk Tenvo: kami mengoperasikan relay yang dikelola (server di Jerman). Jika Anda memerlukan relay sendiri, pertimbangkan untuk meng-hosting RustDesk secara mandiri.

   Tanda bahaya: Tidak ada informasi region atau jawaban seperti "kami menggunakan penyedia cloud" tanpa menyebutkan region atau perilaku failover.

3. Bagaimana enkripsi sesi diimplementasikan dan di mana TLS berakhir?

   Mengapa ini penting: Vendor sering mengiklankan enkripsi kuat sambil tidak menyebutkan di mana kunci disimpan. Jalur P2P langsung mempertahankan TLS end‑to‑end antara perangkat; ketika lalu lintas jatuh ke relay, TLS berakhir di relay tersebut.

   Bukti yang dapat diterima: Nama protokol (TLS), proses penerbitan sertifikat per‑perangkat, dan diagram yang menunjukkan titik‑titik terminasi. Tanyakan mekanisme yang digunakan untuk membuat sertifikat perangkat dan berapa lama sertifikat tersebut berlaku.

   Tanda bahaya: Klaim seperti "relay tidak pernah melihat data" tanpa bukti kriptografi atau detail kepemilikan kunci.

4. Siapa yang memegang private key dan bagaimana kunci tersebut dilindungi?

   Mengapa ini penting: Kepemilikan kunci menentukan apakah vendor — atau siapa pun yang memiliki akses ke infrastruktur mereka — dapat menyamar sebagai perangkat atau mendekripsi sesi yang melewati relay.

   Bukti yang dapat diterima: Deskripsi siklus hidup kunci, penggunaan HSM jika ada, dan pemisahan tugas untuk penandatanganan. Jika vendor menerbitkan sertifikat per‑perangkat, mintalah untuk melihat kebijakan penandatanganan CA.

   Tanda bahaya: "Kami menjaga kunci dengan aman" tanpa detail prosedural atau teknis.

5. Jelaskan model autentikasi Anda: identitas perangkat, identitas pengguna, dan opsi MFA.

   Mengapa ini penting: Model identitas yang tidak jelas menyebabkan perluasan hak istimewa dan jejak audit yang buruk. Anda menginginkan identitas tingkat‑perangkat ditambah autentikasi pengguna dengan opsi MFA yang kuat (TOTP, push, hardware token, atau passkeys).

   Bukti yang dapat diterima: Diagram alur autentikasi, mekanisme MFA yang didukung, dan contoh entri audit yang mengikat sesi ke ID pengguna.

   Tanda bahaya: Akun bersama tunggal untuk akses tanpa pengawasan atau tidak ada MFA untuk tindakan administratif.

6. Apakah Anda mendukung SSO / SCIM / provisioning dan bagaimana grup dipetakan?

   Mengapa ini penting: Onboarding/offboarding enterprise harus diotomatisasi untuk menghindari akses yang kadaluarsa.

   Bukti yang dapat diterima: Dukungan skema SCIM, langkah integrasi SAML/OIDC SSO, frekuensi sinkronisasi grup, dan contoh CSV atau payload SCIM.

   Tanda bahaya: Provisioning manual hanya lewat CSV tanpa jejak audit.

7. Telemetri apa yang dikumpulkan dan dapatkah pelanggan menonaktifkan atau mengontrol retensi?

   Mengapa ini penting: Telemetri dapat berisi metadata sensitif (nama pengguna, hostname, alamat jaringan). Anda harus dapat mengontrol apa yang dikumpulkan dan berapa lama disimpan.

   Bukti yang dapat diterima: Daftar telemetri (kategori, bukan PII mentah), default retensi, dan kontrol opt‑out/enterprise. Mintalah contoh skema catatan telemetri.

   Tanda bahaya: "Kami mengumpulkan banyak metrik" dan penolakan untuk menentukan retensi atau menyediakan kontrol redaksi.

8. Bagaimana sesi dicatat dan seberapa rinci lognya?

   Mengapa ini penting: Untuk kepatuhan dan forensik Anda memerlukan start/stop sesi, identitas pengguna, perangkat target, dan idealnya metadata sesi seperti IP dan hop relay. Jika perekaman sesi didukung, Anda memerlukan detail penyimpanan, enkripsi dan retensi.

   Bukti yang dapat diterima: Contoh baris log (disamarkan), dokumentasi integrasi SIEM, dan opsi retensi/arsip.

   Tanda bahaya: Log hanya tersedia di portal vendor tanpa ekspor atau API.

9. Apakah Anda menawarkan perekaman sesi dan bagaimana hal itu diamankan?

   Mengapa ini penting: Perekaman membantu audit tetapi meningkatkan eksposur. Anda memerlukan kontrol yang jelas tentang siapa yang dapat membaca rekaman, bagaimana rekaman dienkripsi dan disimpan, serta proses penghapusan.

   Bukti yang dapat diterima: Pendekatan enkripsi rekaman, kontrol akses, retensi, dan opsi ekspor API atau yang kompatibel dengan S3.

   Tanda bahaya: Tidak ada RBAC pada rekaman atau rekaman disimpan tanpa enkripsi.

10. Peran administratif dan primitif RBAC apa yang Anda sediakan?

    Mengapa ini penting: RBAC yang granular mengurangi risiko. Carilah template peran, kebijakan least‑privilege, dan pemisahan antara staf bantuan dan superadmin.

    Bukti yang dapat diterima: Model RBAC, batas cakupan (per tim, per perangkat), dan contoh kebijakan untuk peran helpdesk vs sysadmin.

    Tanda bahaya: Peran admin serba‑ada atau backdoor superadmin tersembunyi.

11. Bagaimana Anda menangani akses unattended dan peningkatan sementara?

    Mengapa ini penting: Akses unattended nyaman tetapi berbahaya. Anda menginginkan peningkatan just‑in‑time, gerbang persetujuan, dan token bertoken waktu (timeboxed).

    Bukti yang dapat diterima: Diagram alur kerja, TTL token, dan jejak audit yang menghubungkan peningkatan dengan seorang penyetuju.

    Tanda bahaya: Kunci unattended permanen tanpa proses persetujuan.

12. Apa praktik patching, build, dan release untuk kode klien dan server?

    Mengapa ini penting: Kerentanan ada di klien dan relay. Anda memerlukan jawaban baku tentang frekuensi pembaruan, build yang ditandatangani, dan proses pengungkapan CVE.

    Bukti yang dapat diterima: Frekuensi rilis (mis. patch keamanan mingguan), detail penandatanganan kode, dan kebijakan CVE publik atau yang tersedia untuk pelanggan.

    Tanda bahaya: Tidak ada proses rilis atau penandatanganan terdokumentasi.

13. Apakah Anda mendukung relay on‑prem atau dikelola pelanggan, dan berapa biayanya?

    Mengapa ini penting: Beberapa regulasi mengharuskan infrastruktur lokal. Namun self‑hosting memindahkan beban operasional; kuantifikasikan biaya dan perbedaan dukungan.

    Bukti yang dapat diterima: Panduan deployment, profil sumber daya untuk sebuah relay, dan harga untuk managed vs self‑hosted. Catatan: Tenvo adalah relay yang dikelola oleh kami (server di Jerman); jika Anda membutuhkan infrastruktur on‑prem, pertimbangkan untuk meng‑host RustDesk sendiri; bagi banyak organisasi relay yang dikelola lebih murah ketika on‑call, patching dan perpanjangan sertifikat diperhitungkan.

    Tanda bahaya: Mengklaim self‑host tanpa dokumentasi atau mensyaratkan kontrak enterprise yang mahal.

14. Apa ketentuan SLA Anda untuk ketersediaan, failover, dan respons dukungan?

    Mengapa ini penting: Waktu aktif, failover regional, dan waktu respons harus bersifat kontraktual. Mintalah MTTR, persentase uptime, dan ketentuan kredit.

    Bukti yang dapat diterima: PDF SLA yang menunjukkan target uptime, tingkatan dukungan, dan matriks eskalasi insiden.

    Tanda bahaya: SLA lisan atau pernyataan "kami berusaha" tanpa penalti atau kredit.

15. Bagaimana Anda mendeteksi dan merespons kompromi akun atau perangkat?

    Mengapa ini penting: Deteksi dan kontainmen yang cepat membatasi radius ledakan. Anda memerlukan mekanisme pencabutan yang jelas dan contoh garis waktu insiden.

    Bukti yang dapat diterima: API pencabutan, laporan insiden contoh yang disamarkan, dan rata‑rata waktu kontainmen untuk insiden masa lalu.

    Tanda bahaya: Tidak ada API pencabutan atau bergantung pada "hubungi dukungan" untuk pencabutan mendesak.

16. Bagaimana audit pelanggan didukung dan bukti apa yang dapat Anda berikan?

    Mengapa ini penting: Auditor meminta log, kontrol, dan daftar akses. Vendor harus menyediakan artefak yang dapat diekspor dan proses untuk menghasilkan paket audit.

    Bukti yang dapat diterima: Template paket audit, contoh log, laporan SOC/ISO jika tersedia, dan proses terdokumentasi untuk permintaan ad hoc.

    Tanda bahaya: Hanya screenshot portal atau "kami dapat menunjukkannya secara langsung" tanpa ekspor.

17. Telemetri atau komponen apa yang pihak ketiga (CDN, analytics) dan siapa pemilik datanya?

    Mengapa ini penting: Layanan pihak ketiga memperkenalkan isu supply‑chain dan residensi data.

    Bukti yang dapat diterima: Daftar pihak ketiga, aliran data yang menunjukkan apa yang dikirim ke setiap penyedia, dan kontrak atau ketentuan DPA yang relevan.

    Tanda bahaya: "Kami menggunakan pihak ketiga" tanpa menyebutkan siapa atau menjelaskan data yang dikirim.

18. Bagaimana Anda menskalakan untuk armada besar dan alat deployment apa yang ada?

    Mengapa ini penting: Enterprise besar membutuhkan deployment massal, opsi MSI/PKG, dan konfigurasi jarak jauh.

    Bukti yang dapat diterima: MSI/PKG, flag silent‑install, template MDM, API untuk rollout perangkat, dan contoh angka throughput (sesi per relay).

    Tanda bahaya: Hanya installer manual atau tidak ada panduan untuk ribuan perangkat.

19. Alat debugging dan diagnostik apa yang Anda sediakan untuk pelanggan?

    Mengapa ini penting: Saat terjadi kegagalan Anda memerlukan log lokal, packet capture, dan cara untuk melibatkan dukungan vendor dengan data yang dapat direproduksi.

    Bukti yang dapat diterima: Lokasi log debug lokal, kontrol verbositas log, dan alur kerja unggah dukungan dengan contoh log yang dianonimkan.

    Tanda bahaya: Pengguna dipaksa menjalankan alat jarak jauh atas perintah vendor tanpa transparansi.

20. Bagaimana penagihan dimeter dan biaya tak terduga apa yang dapat muncul?

    Mengapa ini penting: Per‑perangkat, per‑pengguna, sesi bersamaan, dan bandwidth relay atau biaya egress region dapat mengejutkan pembeli.

    Bukti yang dapat diterima: Matriks harga, contoh TCO 3‑tahun untuk ukuran armada Anda, dan asumsi biaya bandwidth. (Lihat juga TCO akses jarak jauh.)

    Tanda bahaya: "Hubungi tim sales" untuk setiap detail harga atau biaya per‑GB tersembunyi.

21. Apakah Anda menerbitkan attestasi pihak ketiga independen (SOC 2, ISO 27001) dan cakupannya?

    Mengapa ini penting: Laporan independen berguna tetapi periksa apa yang sebenarnya mereka cakup (app, infra, devops). Minta laporan terbaru dan cakupannya.

    Bukti yang dapat diterima: PDF laporan atau surat, bridge letter, dan daftar layanan yang dikecualikan.

    Tanda bahaya: Laporan lama atau tidak tersedia, atau klaim kepatuhan tanpa detail cakupan.

22. Tunjukkan garis waktu insiden yang dianonimkan untuk outage produksi atau pelanggaran masa lalu.

    Mengapa ini penting: Insiden nyata mengungkapkan kematangan. Anda ingin garis waktu, penyebab akar, remediasi, dan pelajaran yang dipetik.

    Bukti yang dapat diterima: Laporan insiden yang disamarkan dengan langkah remediasi konkret dan verifikasi perbaikan.

    Tanda bahaya: Menolak membagikan riwayat insiden apa pun atau hanya menawarkan pernyataan PR generik.

Why Tenvo's managed relay is the pragmatic default

Operational cost matters. A self‑hosted relay avoids third‑party infrastructure but moves on‑call, patching, certificate renewal, HA, and failover testing onto your team. For most buyers that means higher total cost and slower recovery. Tenvo menyediakan klien native untuk macOS, Windows, dan Linux, klien browser dalam beta publik, dan relay terkelola yang kami operasikan untuk Anda, dengan server di Jerman. Pricing is Free $0 / Lite $2.99/mo / Pro $7.99/mo. Relay terkelola kami menghilangkan beban operasional sehari-hari; we recommend it as the default unless an explicit written requirement — e.g., data residency, air‑gapped network, or a policy forbidding third‑party relays — forces self‑hosting.

When you should insist on self‑hosting

Self‑hosting is the right call only for narrow reasons: a compliance mandate that prohibits third‑party relays, isolated networks unreachable from the public Internet, or strict data‑residency laws that cannot be satisfied by a managed service. If you take that path, ask for deployment automation, an upgrade playbook, and a documented runbook. For a realistic view of hidden costs see Self‑Hosted Remote Desktop: Why, How, and What Breaks and our analysis of total cost in Remote access TCO.

Evaluation checklist & next steps

• Run a proof-of-concept that exercises P2P fallbacks and relay usage, capturing packet‑level evidence and certificate fingerprints.
• Request redacted logs and an audit package; compare formats against your SIEM. See Remote Desktop Audit Logging for what auditors expect.
• Get a 3‑year TCO from each vendor that includes on‑call, patching, and relay egress costs; compare to Tenvo's managed pricing.
• Read product attestations and, where relevant, request a bridge letter. If you need deeper comparison against established vendors, review TeamViewer comparison, AnyDesk comparison, and RustDesk comparison.
• If you need procurement language, convert the 20 questions above into mandatory proof items (diagrams, cert fingerprints, logs) and score vendors only on evidence, not claims.

Ready to test a managed relay and a native client? Download a client and run the same 20 checks in a short pilot: Get Tenvo.