Uzak erişim RFP'si: Açıklık zorlayan 20 soru

Uzak erişim yazılımı kontrol listesiyle satın almak güvenli görünür — ta ki tüm satıcılar her maddeye "evet" deyip bitirene kadar. RFP'nin gerçek işi, satıcıları diyagram, protokol adları, sertifikalar ve loglar gibi kanıt göstermeye zorlayıp pazarlamadan çok ödünleşmeleri karşılaştırmanızı sağlamaktır. Bu makale, satıcı iddialarını operasyonel gerçeklikten ayıran 20 hedefli soru sunar, iyi bir cevabın nasıl olması gerektiğini açıklar ve kabul etmemeniz gereken ciddi kusurları işaretler.

Bu cevapları nasıl okuyun

Satıcıları "X'i destekliyoruz" demelerine göre puanlamayın — sundukları artefaktlara göre puanlayın. Mimari diyagram, TLS sertifika parmak izleri, örnek log kayıtları (gizlilik için maskelenmiş), belgelenmiş olay zaman çizelgesi ve iddia edilen davranışı yeniden üretebilecek bir test hesabı isteyin. Bir satıcı kanıt sağlamaya karşı çıkıyorsa, bu kendi başına bir cevaptır.

Satıcıları ayıran 20 soru

1. Bağlantı modeliniz nedir (P2P, brokered, relay)?

   Neden önemli: Performans, gecikme ve trafiği kimin gözlemleyebileceği oturumların doğrudan mı yoksa vekil (proxy) üzerinden mi kurulduğuna bağlıdır. Bir diyagram ve paket akışının açıklamasını isteyin.

   Kabul edilebilir kanıt: NAT geçişini, STUN/TURN kullanımını ve geri düşmeleri gösteren bir ağ diyagramı; relay'lerin kullandığı IP aralıklarına örnekler.

   Kırmızı bayraklar: "ne hızlıysa onu yapıyoruz" gibi belirsiz yanıtlar veya geri düşmeleri tanımlamayı reddetmek.

2. Bir oturum relay kullanıyorsa, relay'i kim işletiyor ve bölgeler nereler?

   Neden önemli: Bir relay operatörü TLS burada sonlanıyorsa şifrelenmiş trafiği görebilir. Relay'in çok bölgeli, tek bölgeli veya müşteri tarafından işletilen olup olmadığını bilmeniz gerekir.

   Kabul edilebilir kanıt: Relay operatörlerine ait varlık listesi, bölge haritası ve bölgesel failover için SLA. Tenvo için: biz yönetilen bir relay işletiyoruz (sunucular Almanya'da). Eğer kendi relay'inize ihtiyaç duyuyorsanız, RustDesk'i kendi sunucunuzda barındırmayı düşünebilirsiniz.

   Kırmızı bayraklar: Bölge bilgisi yok veya "bulut sağlayıcıları kullanıyoruz" diyerek bölgeleri veya failover davranışını isimlendirmemek.

3. Oturum şifrelemesi nasıl uygulanıyor ve TLS nerede sonlanıyor?

   Neden önemli: Satıcılar sıklıkla güçlü şifrelemeyi öne çıkarırken anahtarların nerede tutulduğunu atlar. Doğrudan bir P2P yol, cihazlar arasında uçtan uca TLS'yi korur; trafik relay'e düştüğünde TLS o relay'de sonlanır.

   Kabul edilebilir kanıt: Protokol isimleri (TLS), cihaz başına sertifika verilme süreci ve sonlanma noktalarını gösteren bir diyagram. Cihaz sertifikalarını üretmek için kullanılan mekanizmayı ve bu sertifikaların ne kadar süreyle geçerli olduğunu sorun.

   Kırmızı bayraklar: Kriptografik kanıt veya anahtar takibi ayrıntısı olmadan "relay hiç veriyi görmez" gibi iddialar.

4. Özel anahtarları kim tutuyor ve nasıl korunuyorlar?

   Neden önemli: Anahtarların kimde olduğu, bir satıcının — veya altyapılarına erişimi olan herhangi birinin — cihazları taklit edip relay oturumlarını çözebilip çözemeyeceğini belirler.

   Kabul edilebilir kanıt: Anahtar yaşam döngüsü açıklaması, varsa HSM kullanımı ve imzalama için görev ayrımı. Satıcı cihaz başına sertifika veriyorsa, CA imzalama politikasını gösterin.

   Kırmızı bayraklar: Prosedürel veya teknik ayrıntı olmadan "Anahtarları güvende tutuyoruz" demek.

5. Kimlik doğrulama modelinizi açıklayın: cihaz kimlikleri, kullanıcı kimlikleri ve MFA seçenekleri.

   Neden önemli: Belirsiz kimlik modelleri yetki sürünmesine ve zayıf denetim izlerine yol açar. Cihaz seviyesinde kimlik ile birlikte güçlü MFA seçeneklerine (TOTP, push, donanım tokenleri veya passkey'ler) sahip kullanıcı doğrulaması istersiniz.

   Kabul edilebilir kanıt: Kimlik doğrulama akış diyagramları, desteklenen MFA mekanizmaları ve oturumları kullanıcı kimliklerine bağlayan örnek denetim kayıtları.

   Kırmızı bayraklar: Gözetimsiz erişim için tek paylaşılan hesap kullanılması veya yönetimsel işlemler için MFA olmaması.

6. SSO / SCIM / sağlama (provisioning) destekliyor musunuz ve gruplar nasıl eşleniyor?

   Neden önemli: Kurumsal işe alım/işten çıkarma işlemlerinin otomatikleştirilmesi, eski erişimlerin önlenmesi için gereklidir.

   Kabul edilebilir kanıt: SCIM şema desteği, SAML/OIDC SSO entegrasyon adımları, grup senkronizasyon sıklığı ve örnek CSV veya SCIM payload'ları.

   Kırmızı bayraklar: Denetim izi olmayan yalnızca manuel CSV ile sağlama.

7. Hangi telemetri toplanıyor ve müşteriler bunu devre dışı bırakabilir veya saklama süresini kontrol edebilir mi?

   Neden önemli: Telemetri kullanıcı adları, ana bilgisayar adları, ağ adresleri gibi hassas meta veriler içerebilir. Ne toplandığını ve ne kadar süre saklandığını kontrol etmelisiniz.

   Kabul edilebilir kanıt: Telemetri listesi (kategoriler, ham PII değil), varsayılan saklama süreleri ve devre dışı bırakma/kurumsal kontroller. Bir telemetri kayıt şeması örneği isteyin.

   Kırmızı bayraklar: "Çok sayıda metrik topluyoruz" demek ve saklama süresini tanımlamayı veya kırpma kontrollerini sağlamayı reddetmek.

8. Oturumlar nasıl kaydediliyor ve günlükler ne kadar ayrıntılı?

   Neden önemli: Uyum ve adli inceleme için oturum başlama/bitirme, kullanıcı kimliği, hedef cihaz ve ideal olarak IP'ler ve relay atlamaları gibi oturum meta verilerine ihtiyacınız vardır. Oturum kaydı destekleniyorsa depolama, şifreleme ve saklama ayrıntılarını bilmelisiniz.

   Kabul edilebilir kanıt: Örnek günlük satırları (gizliliklendirildi), SIEM entegrasyon dokümanları ve saklama/arşivleme seçenekleri.

   Kırmızı bayraklar: Günlüklerin yalnızca satıcı portalında olması ve dışa aktarım veya API olmaması.

9. Oturum kaydı sunuyor musunuz ve nasıl güvence altına alınıyor?

   Neden önemli: Kayıtlar denetimler için yardımcı olur ama riskleri artırır. Kayıtları kimlerin okuyabileceği, kayıtların nasıl şifrelendiği, saklama ve silme süreçleri konusunda net kontroller olmalıdır.

   Kabul edilebilir kanıt: Kayıt şifreleme yaklaşımı, erişim kontrolleri, saklama ve bir API veya S3-uyumlu dışa aktarma seçeneği.

   Kırmızı bayraklar: Kayıtlarda RBAC olmaması veya kayıtların şifrelenmeden saklanması.

10. Hangi idari roller ve RBAC ilkeleri sağlıyorsunuz?

    Neden önemli: Ayrıntılı RBAC riski azaltır. Rol şablonları, en az ayrıcalık politikaları ve destek personeli ile süperadminler arasında ayrım arayın.

    Kabul edilebilir kanıt: RBAC modeli, kapsam sınırları (takım başına, cihaz başına) ve yardım masası rolü ile sistem yöneticisi için politika örnekleri.

    Kırmızı bayraklar: Her şey veya hiçbir şey şeklinde idari roller veya gizli süperadmin arka kapıları.

11. Gözetimsiz erişimi ve geçici yükseltmeleri nasıl ele alıyorsunuz?

    Neden önemli: Gözetimsiz erişim kullanışlıdır ama tehlikelidir. Anlık yetki yükseltme (just-in-time), onay mekanizmaları ve zaman sınırlı token'lar istersiniz.

    Kabul edilebilir kanıt: İş akışı diyagramları, token TTL'leri ve yükseltmeyi bir onaylayıcıya bağlayan denetim izi.

    Kırmızı bayraklar: Onaysız, kalıcı gözetimsiz anahtarlar.

12. İstemci ve sunucu kodu için yama, derleme ve sürüm uygulamalarınız nelerdir?

    Neden önemli: Açıklar istemcilerde ve relay'lerde bulunur. Güncelleme sıklığı, imzalı derlemere dair bilgiler ve CVE açıklama süreçleri hakkında hazır yanıtlar isteyin.

    Kabul edilebilir kanıt: Sürüm sıklığı (ör. haftalık güvenlik yamaları), kod imzalama ayrıntıları ve halka veya müşteriye dönük CVE politikası.

    Kırmızı bayraklar: Belirlenmiş sürüm veya imzalama süreci olmayanlar.

13. On‑prem veya müşteri tarafından yönetilen relay'leri destekliyor musunuz ve maliyeti nedir?

    Neden önemli: Bazı düzenlemeler yerel altyapı gerektirir. Ancak self‑hosting operasyonel yükü artırır; maliyeti ve destek farklarını nicelleştirin.

    Kabul edilebilir kanıt: Dağıtım kılavuzu, bir relay için kaynak profili ve yönetilen vs self‑hosted için fiyatlandırma. Not: Tenvo bizim tarafımızdan işletilen bir yönetilen relay'dir (sunucular Almanya'da); on‑prem altyapıya ihtiyacınız varsa RustDesk'i kendi sunucunuzda barındırmayı düşünün; birçok kuruluş için yönetilen relay, nöbet, yamalama ve sertifika yenileme hesaba katıldığında daha ucuzdur.

    Kırmızı bayraklar: Self‑host vaadi ama dokümantasyon yok veya pahalı kurumsal sözleşmeler gerektirmek.

14. Kullanılabilirlik, failover ve destek yanıtı için SLA şartlarınız nelerdir?

    Neden önemli: Çalışırlık, bölgesel failover ve yanıt süreleri sözleşmeye bağlanmalıdır. MTTR, uptime % ve kredi şartlarını isteyin.

    Kabul edilebilir kanıt: Çalışırlık hedefleri, destek seviyeleri ve olay yükseltme matrisini gösteren SLA PDF'i.

    Kırmızı bayraklar: Sözlü SLA veya ceza/kredi içermeyen "hedefliyoruz" ifadeleri.

15. Bir hesap veya cihazın kompromize edilmesini nasıl tespit edip yanıt veriyorsunuz?

    Neden önemli: Zamanında tespit ve izolasyon patlama alanını sınırlar. Net iptal (revocation) mekanikleri ve örnek bir olay zaman çizelgesi isteyin.

    Kabul edilebilir kanıt: Revocation API'si, gizliliklendirilmiş örnek olay raporu ve geçmiş olaylar için ortalama containment süresi.

    Kırmızı bayraklar: Revocation API'si yok veya acil iptaller için "destekle iletişime geçin"e dayanmak.

16. Müşteri denetimleri nasıl destekleniyor ve hangi delilleri sağlayabilirsiniz?

    Neden önemli: Denetçiler günlükler, kontroller ve erişim listeleri ister. Satıcılar dışa aktarılabilir kanıtlar ve denetim paketleri üretme süreci sunmalıdır.

    Kabul edilebilir kanıt: Denetim paketi şablonu, örnek günlükler, varsa SOC/ISO raporları ve ad‑hoc talepler için belgelenmiş süreç.

    Kırmızı bayraklar: Yalnızca portal ekran görüntüleri veya "canlı gösterebiliriz" ama dışa aktarım yok.

17. Hangi telemetri veya bileşenler üçüncü taraf (CDN, analytics) ve bu verilerin sahibi kim?

    Neden önemli: Üçüncü taraf servisler tedarik zinciri ve veri bulunurluğu sorunları getirir.

    Kabul edilebilir kanıt: Üçüncü taraf listesi, her sağlayıcıya hangi verinin gittiğini gösteren veri akışları ve ilgili yerlerde sözleşmeler veya DPA şartları.

    Kırmızı bayraklar: "Üçüncü tarafları kullanıyoruz" ama isim vermemek veya gönderilen veriyi açıklamamak.

18. Büyük filolar için nasıl ölçekleniyorsunuz ve hangi dağıtım araçları mevcut?

    Neden önemli: Büyük işletmeler toplu dağıtım, MSI/PKG seçenekleri ve uzaktan yapılandırma ister.

    Kabul edilebilir kanıt: MSI/PKG, sessiz kurulum bayrakları, MDM şablonları, cihaz dağıtımı için API ve örnek verimlilik sayıları (relay başına oturumlar).

    Kırmızı bayraklar: Yalnızca manuel yükleyiciler veya binlerce cihaz için rehber yok.

19. Müşterilere hangi hata ayıklama ve tanılama araçlarını sunuyorsunuz?

    Neden önemli: Sorun çıktığında yerel günlükler, paket yakalamalar ve yeniden üretilebilir veri ile vendor desteğine başvurmak istersiniz.

    Kabul edilebilir kanıt: Yerel debug günlük lokasyonları, günlük ayrıntı düzeyi kontrolleri ve örnek anonimleştirilmiş günlüklerle destek yükleme iş akışı.

    Kırmızı bayraklar: Kullanıcının şeffaflık olmadan satıcının yönlendirdiği uzaktan araçları çalıştırmaya zorlanması.

20. Faturalama nasıl ölçümleniyor ve hangi beklenmedik ücretler ortaya çıkabilir?

    Neden önemli: Cihaz başına, kullanıcı başına, eşzamanlı oturumlar ve relay bant genişliği veya bölge çıkış ücretleri alıcıları şaşırtabilir.

    Kabul edilebilir kanıt: Fiyatlandırma matrisi, filonuz için örnek 3‑yıllık TCO ve bant genişliği maliyeti varsayımları. (Bkz. ayrıca Uzaktan erişim TCO.)

    Kırmızı bayraklar: Her fiyat detayı için "Satışla iletişime geçin" demek veya gizli GB başına ücretler.

21. Bağımsız üçüncü taraf kanıtları yayınlıyor musunuz (SOC 2, ISO 27001) ve kapsam nedir?

    Neden önemli: Bağımsız raporlar faydalıdır ama gerçekten neyi kapsadığını kontrol edin (uygulama, altyapı, devops). En son raporu ve kapsamı isteyin.

    Kabul edilebilir kanıt: Rapor PDF'i veya mektup, bridge letter'lar ve dışlanan servislerin listesi.

    Kırmızı bayraklar: Eski veya mevcut olmayan raporlar ya da kapsam detayı olmadan uyumluluk iddiaları.

22. Geçmiş bir üretim kesintisi veya ihlali için anonimleştirilmiş bir olay zaman çizelgesi gösterin.

    Neden önemli: Gerçek olaylar olgunluğu ortaya koyar. Zaman çizelgesini, kök nedeni, düzeltmeleri ve alınan dersleri görmek istersiniz.

    Kabul edilebilir kanıt: Koyu renkleri temizlenmiş (redacted) olay raporu; somut düzeltme adımları ve düzeltmelerin doğrulanması.

    Kırmızı bayraklar: Hiç olay geçmişi paylaşmayı reddetmek veya yalnızca genel PR ifadeleri sunmak.

Niçin Tenvo'nun yönetilen relay'i pragmatik varsayılandır

Operasyonel maliyet önemlidir. Self‑host edilen bir relay üçüncü taraf altyapıyı ortadan kaldırır ama nöbet, yamalama, sertifika yenileme, HA ve geçiş testlerini ekibinize yükler. Çoğu alıcı için bu daha yüksek toplam maliyet ve daha yavaş kurtarma anlamına gelir. Tenvo, macOS, Windows ve Linux için yerel istemciler, genel betada bir tarayıcı istemcisi ve sizin için işlettiğimiz, Almanya'da sunucuları olan yönetilen bir relay sunar. Fiyatlandırma: Ücretsiz $0 / Lite $2.99/ay / Pro $7.99/ay. Yönetilen relay'imiz günlük operasyon yükünü ortadan kaldırır; açıkça yazılı bir gereksinim — örn. veri yerleşimi, hava‑aralı ağ veya üçüncü taraf relay'leri yasaklayan bir politika — olmadıkça varsayılan olarak bunu öneririz.

Ne zaman self‑hosting konusunda ısrar etmelisiniz

Self‑hosting sadece dar gerekçelerle doğrudur: üçüncü taraf relay'leri yasaklayan bir uyum zorunluluğu, genel İnternet'ten ulaşılamayan izole ağlar veya yönetilen servisle karşılanamayacak katı veri yerleşimi yasaları. Bu yolu seçerseniz dağıtım otomasyonu, yükseltme playbook'u ve belgelenmiş bir runbook isteyin. Gizli maliyetlere gerçekçi bakış için bkz. Self‑Hosted Remote Desktop: Why, How, and What Breaks ve toplam maliyet analizimiz Remote access TCO.

Değerlendirme kontrol listesi ve sonraki adımlar

• P2P geri düşüşlerini ve relay kullanımını test eden bir proof‑of‑concept çalıştırın; paket‑seviyesinde kanıt ve sertifika parmak izleri yakalayın.
• Kırpılmış loglar ve bir denetim paketi talep edin; formatları SIEM'inizle karşılaştırın. Denetçilerin beklentileri için bkz. Remote Desktop Audit Logging.
• Her satıcıdan nöbet, yamalama ve relay çıkış maliyetlerini içeren 3 yıllık TCO isteyin; Tenvo'nun yönetilen fiyatlandırmasıyla karşılaştırın.
• Ürün doğrulamaları okuyun ve ilgili durumlarda bridge letter isteyin. Kurulmuş satıcılarla daha derin karşılaştırma gerekiyorsa TeamViewer comparison, AnyDesk comparison ve RustDesk comparison inceleyin.
• Satın alma dili gerekiyorsa, yukarıdaki 20 soruyu zorunlu kanıt maddelerine (diyagramlar, sertifika parmak izleri, loglar) çevirin ve satıcıları iddialara değil kanıtlara göre puanlayın.

Yönetilen relay ve yerel bir istemciyi test etmeye hazır mısınız? Bir istemci indirin ve kısa bir pilotta aynı 20 kontrolü çalıştırın: Get Tenvo.