Etki alanı güveni olmadan Excel’den iş ortağının SQL Server’ına

Başka bir kuruluşun SQL Server’ında tablo açan bir Excel çalışma kitabı, genellikle tek bir şey olarak tartışılan üç şeye ihtiyaç duyar: sunucunun kabul ettiği bir kimlik, istemcinin doğruladığı bir taşıma ve iki tarafın da izin verdiği bir ağ yolu. Etki alanı güveni birinciyi karşılamanın bir yoludur ve en geniş olanıdır. TLS ikinciyi karşılar ve birinci hakkında hiçbir şey söylemez. Yol üçüncüyü karşılar ve kendi başına hiçbir şeyi korumaz.

Bu üçünü ayırmak, elektronik tabloyu idari bir ilişki yerine küçük ve gözden geçirilebilir bir istek hâline getirir.

Sorunun sakladığı üç karar

Kimlik, veritabanının sizi kim sandığıdır: güvenilen bir etki alanından Windows hesabı, kendi parolasına sahip bir SQL oturum açma veya sertifikaya dayalı bir kimlik. Taşıma, oturumun şifrelenip şifrelenmediği ve istemcinin sunucunun sertifika zincirini denetleyip denetlemediğidir. Yol, paketlerin dinleyiciye nasıl ulaştığıdır; bu bir VPN, özel bir bağlantı veya güvenlik duvarı kuralları olan genel bir uç nokta olabilir. Her biri farklı bir yerde yaşar ve her biri tek başına başarısız olabilir.

Orman güveni birinciye geniş bir yanıt verir ve tek bir çalışma kitabının ayarı değil, kuruluşlar arası bir ilişkidir. Ayrıca hiçbir şeyi şifrelemez; bu da güvenin güvenlik denetimi olduğunu varsayanları şaşırtır.

Orman güveni olmadan kimlik

Hedef ortamda bilerek hazırlanmış bir hesap, istemcinin iş akışı onu kullanabildiği sürece hiçbir güven olmadan daha dar bir gereksinimi karşılayabilir. SQL kimlik doğrulaması, ilke izin verdiğinde diğer yaygın yanıttır: oturum açma kendi kimlik bilgisi yaşam döngüsünü taşır ve etki alanlarına katılmaz veya Windows tümleşik kimlik doğrulaması üretmez. Sertifika veya belirteç tabanlı kimlik, daha yeni platformlarda üçüncü seçenektir. Hangisini seçerseniz seçin, yalnızca çalışma kitabının gerçekten ihtiyaç duyduğu veritabanı izinlerini verin.

Birinin kişisel oturum açması yerine özel bir hesabı tercih edin. Elektronik tabloda paylaşılan kimlik bilgisi, olmayı bekleyen bir destek sorunudur ve adlandırılmış hesap, proje bittiğinde iptali mümkün kılar.

Şifreleme evet, ama sertifikaya güvenelim mi?

ODBC Driver 18 ile Encrypt=Yes;TrustServerCertificate=No, sertifikası gerçekten denetlenen şifreli bir oturum ister. Bağlantı dizesi o zaman sertifikanın kapsadığı sunucuyu adlandırmalı ve istemci onun zincirine güvenmelidir. Driver 18 ayrıca önceki sürümlerden farklı olarak varsayılan olarak şifreler, bu yüzden eski bir bağlantı dizesi artık bunu söylemeden TLS pazarlığı yapabilir. Açık ayarlar amaçlanan ilkeyi tüm makinelerde görünür kılar; bu, birkaç kişi aynı çalışma kitabını sürdürdüğünde önemlidir.

TrustServerCertificate=Yes şifreler ve doğrulamayı atlar; bu, ad uyuşmazlığı veya güvenilmeyen zincir için eşdeğer bir onarım değildir. İstemcinin yanlış uç noktaya ulaştığını size söyleyecek sinyali ortadan kaldırır, bu yüzden bunun yerine sertifikayı veya adı düzeltin.

Sunucu tarafındaki zorlama ayrı bir denetimdir. Şifreleme her istemciye uygulanacaksa, sunucunun zorunlu şifreleme ayarını yapılandırın ve doğrulayın, çünkü tek bir uyumlu bağlantı dizesi hiçbir şeyi zorlamaz.

Ağ yolu koruma değildir

VPN üzerinden erişilen özel bir dinleyici maruziyeti azaltır ve bunun işlemesi için VPN doğru hedef ve dönüş yollarını taşımalıdır. Çalışan bir tünel kimlik doğrulama veya sertifika doğrulama ihtiyacını ortadan kaldırmaz ve TLS hangi uzak sistemlerin bağlantı deneyebileceğini sınırlamaz. Bunlar üç ayrı gözlemdir: bir TLS el sıkışması, bir VPN oturum açması ve yetkilendirilmiş bir sorgu. Yalnızca üçüncüsü, çalışma kitabının okumasına izin verilen verileri okuduğunu kanıtlar.

Bu yüzden güven sorusunu veritabanını internete açarak yanıtlama kestirmesine karşı koyun. Dar yanıt genellikle özel bir hesap, doğrulanmış şifreleme ve onaylanmış tek bir yoldur; bu sırayla.

Olağan Excel iş akışıyla doğrulayın: kabul edilen kimlik, etkin izinler ve pazarlık edilen şifreleme; her biri sunucunun kendi oturum görünümü üzerinden.