Hızlı indeksleme ve kayıt başına sıkı erişim kontrolleriyle izin-bilgili küresel arama nasıl tasarlanır öğrenin; kullanıcılar hızlı sonuç alırken veri sızıntıları önlenir.
Küresel arama genellikle uygulamanın tamamını tarayan tek bir arama kutusu demektir: müşteriler, destek talepleri, faturalar, belgeler, kullanıcılar ve insanların çalıştığı diğer tüm nesneler. Genellikle otomatik tamamlama ve hızlı sonuç sayfası sunar, böylece kullanıcılar doğrudan bir kayda atlayabilir.
Sızıntı, aramanın kullanıcının görmeye yetkili olmadığı bir şeyi döndürdüğünde olur. Kaydı açamasa bile başlık, bir kişinin adı, bir etiket veya vurgulanan bir snippet gibi tek bir satır hassas bilgiyi açığa çıkarabilir.
Arama "sadece-okuma" gibi gelir, bu yüzden ekipler bunu hafife alır. Oysa sonuç başlıkları ve önizlemeler, otomatik tamamlama önerileri, sonuç toplamları, "Customers (5)" gibi yüzeyler ve hatta zamanlama farkları (bazı terimler için hızlı, diğerleri için yavaş) aracılığıyla veri açığa çıkarabilir.
Bu genellikle ilk günden değil, sonra ortaya çıkar. Erken dönemde ekipler aramayı yalnızca tek bir rol varken veya test veritabanında herkes her şeyi görebiliyorken yayına alırlar. Ürün büyüdükçe roller (destek vs satış, yöneticiler vs ajanlar) ve paylaşılan gelen kutuları, özel notlar, kısıtlı müşteriler ve "sadece benim hesaplarım" gibi özellikler eklenir. Arama hâlâ eski varsayımlara dayanıyorsa, ekipler arası veya müşteri çapında ipuçları vermeye başlar.
Yaygın bir hata modu, hız için "her şeyi" indeksleyip sonra arama sorgusundan sonra uygulamada filtrelemeye çalışmaktır. Bu çok geçtir. Arama motoru zaten eşleşenleri belirlemiştir ve öneriler, sayımlar veya kısmi alanlar aracılığıyla kısıtlanmış kayıtları açığa çıkarabilir.
Bir destek ajanını düşünün: sadece atandığı müşterilerin taleplerini görmeli. "Acme" yazdığında otomatik tamamlama "Acme - Hukuki tırmanış" veya "Acme ihlal bildirimi" gösterirse, tıklama "erişim reddedildi" ile sonuçlansa bile başlık tek başına bir veri sızıntısıdır.
İzin-bilgili küresel aramanın hedefi söylemesi kolay, uygulaması zor: hızlı, alakalı sonuçlar döndürürken her kaydı açarken uyguladığınız aynı erişim kurallarını uygulamak. Her sorgu, kullanıcı yalnızca kendi veri dilimini görebiliyormuş gibi davranmalı ve UI o dilimin dışındaki ek ipuçlarını (sayımlar gibi) açığa çıkarmaktan kaçınmalıdır.
Küresel arama basit görünür çünkü kullanıcılar kelimeler yazar ve cevap bekler. Oysa perde arkasında veri açığa çıkması için yeni bir yüzey oluşturuyorsunuz. Bir indeks veya veritabanı özelliği seçmeden önce iki şeye net olun: aradığınız nesneler (varlıklar) ve bu nesnelerin hangi bölümlerinin hassas olduğu.
Bir varlık, birinin hızlıca bulmak isteyebileceği her kayıttır. Çoğu iş uygulamasında bu müşteriler, destek talepleri, faturalar, siparişler ve dosyalar (veya dosya meta verisi) içerir. İnsan kayıtları (kullanıcılar, ajanlar), dahili notlar ve entegrasyonlar veya API anahtarları gibi sistem nesneleri de olabilir. Eğer bir adı, kimliği veya birisi yazabileceği bir durumu varsa, genellikle küresel aramaya düşer.
Tablo başına kurallar kaba olur: ya tüm tabloya erişirsiniz ya da erişemezsiniz. Örnek: sadece Finans Faturalar sayfasını açabilir. Bu anlaşılması kolaydır, ama aynı tabloda farklı kişilerin farklı satırları görmesi gerektiğinde yetersiz kalır.
Kayıt başına kurallar görünürlüğü satır satır karar verir. Örnek: bir destek ajanı ekibine atanmış talepleri görebilir, bir yönetici ise bölgesindeki tüm talepleri görebilir. Bir diğer yaygın kural kiracı sahipliğidir: çok kiracılı bir uygulamada kullanıcı yalnızca customer_id = their_customer_id olan kayıtları görebilir.
Aramanın genellikle sızdırdığı yerler işte bu kayıt başına kurallardır. İndeksiniz bir eşleşme döndürüp sonra satır erişimini kontrol etmeye çalışıyorsa, bir şeyin var olduğunu zaten ifşa etmişsiniz demektir.
"İzinli" nadiren tek bir evet/hayır anahtarıdır. Genellikle sahiplik (benim oluşturduğum, bana atanmış), üyelik (ekibim, departmanım, rolüm), kapsam (bölgem, iş birimim, projem), kayıt durumu (yayınlandı, arşivlenmemiş) ve özel durumların (VIP müşteriler, hukuki beklemeler, kısıtlı etiketler) bileşimidir.
Bu kuralları önce düz ve anlaşılır bir dille yazın. Sonra bunları bir veri modeli ve sunucu tarafı kontrollerine dönüştüreceksiniz.
Arama sonuçları genellikle bir önizleme snippet'i içerir ve snippet'ler kullanıcı kaydı açamasa bile hassas veriyi sızdırabilir.
Güvenli bir varsayılan, erişim doğrulanana kadar yalnızca minimal, hassas olmayan alanları göstermektir: bir görüntüleme adı veya başlık (bazen maskelenmiş), kısa bir tanımlayıcı (sipariş numarası gibi), genel bir durum (Açık, Ödendi, Sevk edildi), bir tarih (oluşturulma veya güncelleme) ve genel bir varlık etiketi (Ticket, Invoice) gibi.
Somut örnek: biri "Acme birleşme" araması yapıp kısıtlı bir talep varsa, "Ticket: Acme merger draft - Legal" döndürmek zaten sızıntıdır. Daha güvenli bir sonuç "Ticket: Restricted" (önizleme yok) veya politika gerektiriyorsa hiç sonuç olmamak olabilir.
Bu tanımları baştan doğru yapmak sonraki kararları (ne indekslenecek, nasıl filtrelenecek, neyi açıklayabileceğiniz) basitleştirir.
İnsanlar küresel aramayı aceleyle kullanır. Bir saniyeden uzun sürerse güvenini kaybeder ve manuel filtrelemeye döner. Ama hız işin yarısıdır. Hızlı bir arama bile bir kayıt başlığını, müşteri adını veya konu satırını sızdırıyorsa arama hiç olmamasından kötüdür.
Temel kural vazgeçilmezdir: izinleri sorgu zamanında uygulayın, sadece UI'da değil. Bir satırı aldıktan sonra gizlemek zaten çok geçtir, çünkü sistem yanlışlıkla erişim verisini işlemiş olur.
Bu, yalnızca sonuç listesinin kendisi için değil aramayı çevreleyen her şey için geçerlidir. Öneriler, en iyi sonuçlar, sayımlar ve hatta "sonuç yok" davranışı bilgi sızdırabilir. Otomatik tamamlama bir kişiye açılma izni olmayan "Acme Yenileme Sözleşmesi"ni gösteriyorsa bu bir sızıntıdır. Bir facet "12 eşleşen fatura" diyorsa ve kullanıcı yalnızca 3 görebiliyorsa bu bir sızdırmadır. Hatta zamanlama bile sınırlandırılmış eşleşmeler sorguyu yavaşlatıyorsa bilgi verebilir.
Güvenli bir küresel arama dört şeye ihtiyaç duyar:
Kullanışlı bir zihin değişimi: aramayı bir UI özelliği değil, başka bir veri API'si olarak düşünün. Bu, liste sayfalarında uyguladığınız aynı erişim kurallarını indeks oluşturma, sorgu yürütme ve ilişkili tüm uç noktalarda (otomatik tamamlama, son aramalar, popüler sorgular) uygulamanız gerektiği anlamına gelir.
Bir arama kutusu oluşturmak kolaydır. İzin-bilgili küresel arama zordur çünkü indeks anında sonuç döndürmek isterken uygulamanız asla erişimi ihlal etmemelidir. Aşağıda ekiplerin en sık kullandığı üç desen var. Doğru seçim erişim kurallarınızın ne kadar karmaşık olduğuna ve ne kadar riski tolere edebileceğinize bağlıdır.
Yaklaşım A: sadece "güvenli" alanları indeksleyin, sonra izin kontrolü ile tam kaydı alın. İndekste minimal bir belge tutarsınız: bir ID ve herkesin görebileceği, göstermek için güvenli bir etiket. Kullanıcı bir sonuca tıkladığında uygulama ana veritabanından tam kaydı yükler ve gerçek izin kurallarını orada uygular.
Bu sızıntı riskini azaltır, ama sonuçlar ince gelebilir çünkü kullanıcılara az bağlam verirsiniz. Ayrıca "güvenli" etiketin kazara sırları açığa çıkarmayacağına dikkat edilmelidir.
Yaklaşım B: indeks içinde izin özniteliklerini saklayın ve orada filtreleyin. Her indekslenmiş belgeye tenant_id, team_id, owner_id, rol bayrakları veya project_id gibi alanlar eklersiniz. Her sorgu, kullanıcının kapsamına uyan filtreler ekler.
Bu hızlı, zengin sonuçlar ve iyi otomatik tamamlama sağlar, ama izinler filtrelerle ifade edilebildiği durumda çalışır. İzinler karmaşık mantığa bağlıysa (ör. "atanmış VEYA bu hafta nöbetçi VEYA bir olaya dahil"), doğru tutmak zorlaşır.
Yaklaşım C: hibrit. İndekste kaba filtre, final kontrol veritabanında. İndekste tenant, workspace, customer gibi geniş, stabil özniteliklerle filtrelersiniz; sonra küçük bir aday ID kümesi için ana veritabanında nihai izin kontrolü yaparsınız.
Gerçek uygulamalar için bu genellikle en güvenli yoldur: indeks hızlı kalır, veritabanı ise hakikat kaynağı olmaya devam eder.
Basit kurulum ve minimal snippet kabul edilebiliyorsa A'yı seçin. Temiz, çoğunlukla statik kapsamlar (çok kiracılı, ekip tabanlı erişim) varsa ve çok hızlı otomatik tamamlama gerekiyorsa B'yi seçin. Çok sayıda rol, istisna veya sık değişen kayıt-spesifik kurallarınız varsa C'yi seçin. İnsan kaynakları, finans, sağlık gibi yüksek riskli veriler için C'yi tercih edin; çünkü "neredeyse doğru" kabul edilemez.
Erişim kurallarınızı yeni bir ekip arkadaşına açıklayacağınız şekilde yazmakla başlayın. "Admin her şeyi görebilir" demekten kaçının, gerçekten doğru olmadıkça. Onun yerine nedenini yazın: "Destek ajanları kendi kiracılarının taleplerini görebilir. Takım liderleri kendi organizasyon birimlerinin taleplerini de görebilir. Özel notları yalnızca kayıt sahibi ve atanmış ajan görebilir." Eğer birinin neden bir kaydı görebileceğini söyleyemiyorsanız, bunu güvenli şekilde kodlamakta zorlanırsınız.
Sonra stabil bir kimlik belirleyin ve minimal bir arama belgesi tanımlayın. İndeks veritabanı satırınızın tam kopyası olmamalı. Yalnızca sonuç listesinde bulunması ve gösterilmesi gereken alanları tutun: başlık, durum ve belki kısa, hassas olmayan bir snippet. Hassas alanları ikinci bir getirme ve izin kontrolünün arkasında tutun.
Hangi izin sinyallerinin hızlıca filtrelenebileceğine karar verin. Bunlar her indekslenmiş belgeye konulabilecek, erişimi engelleyen özniteliklerdir: tenant_id, org_unit_id ve sınırlı sayıda kapsam bayrağı gibi. Amaç, her sorgunun, otomatik tamamlama dahil, sonuç döndürmeden önce filtre uygulayabilmesidir.
Pratik iş akışı şöyle görünür:
Paylaşılan öğeler ve istisnalar tasarımları bozan noktalardır. Bir talep ekipler arasında paylaşılıyorsa, "sadece boolean ekle" demeyin. Filtrelerle kontrol edilebilen açık izin listeleri kullanın. Eğer izin listesi büyükse, bireysel kullanıcılar yerine grup tabanlı izinleri tercih edin.
Güvenli bir arama deneyimi tek bir sıkıcı ama iyi yapılan şeye bağlıdır: indeks gerçeği yansıtmalı. Bir kayıt oluşturulduğunda, değiştiğinde, silindiğinde veya izinleri değiştiğinde arama sonuçları hızlı ve öngörülebilir şekilde takip etmeli.
İndekslemeyi veri yaşam döngünüzün bir parçası olarak ele alın. Kullanışlı bir zihinsel model: kaynak gerçek değiştiğinde bir event yayınlayın ve indexer buna tepki versin.
Yaygın yaklaşımlar veritabanı tetikleyicileri, uygulama olayları veya iş kuyruklarıdır. En önemli olan şey event'lerin kaybolmamasıdır. Uygulamanız kaydı kaydedip indekslemeyi başarısız kılabiliyorsa, "var olduğunu biliyorum ama arama bulamıyor" gibi kafa karıştırıcı davranışlar görürsünüz.
Birçok sızıntı içerik doğru güncellenirken erişim meta verisinin güncellenmemesinden kaynaklanır. İzin değişiklikleri rol güncellemelerinden, takım hareketlerinden, sahiplik transferlerinden, müşteri yeniden atamalarından veya bir talebin başka bir vaka ile birleştirilmesinden gelir.
İzin değişikliklerini birinci sınıf olaylar yapın. İzin-bilgili arama tenant veya takım filtrelerine dayanıyorsa, indekslenmiş belgelerin bu alanları içermesini sağlayın (tenant_id, team_id, owner_id, allowed_role_ids). Bu alanlar değiştiğinde yeniden indeksleyin.
Zor kısım etki alanının büyüklüğüdür. Bir rol değişikliği binlerce kaydı etkileyebilir. İlerleme, yeniden denemeler ve duraklatma yolu olan bir toplu yeniden indeksleme planlayın.
İyi event'lerle bile, indeksin geride kaldığı bir pencere olacaktır. Kullanıcının değişiklikten sonraki ilk birkaç saniyede ne görmesi gerektiğine karar verin.
İki kural yardımcı olur:
Arama keşif içindir, ama detayları görüntülemek sızıntıların zararlı olduğu yerlerdir. Herhangi hassas alanı göstermeden önce detay okuma zamanında ikinci bir izin kontrolü yapın. Bir sonuç indeksin eski olması nedeniyle sızdıysa, detay sayfası yine de erişimi engellemelidir.
İyi bir desen: aramada minimal snippet'ler gösterin, sonra kullanıcı kaydı açtığında (veya önizlemeyi genişlettiğinde) izinleri yeniden doğrulayın. Kontrol başarısız olursa, açık bir mesaj gösterin ve bir sonraki yenilemede öğeyi görünür sonuçlardan kaldırın.
Aramanız "kayıt açma" sayfası kilitliyken bile veri sızdırabilir. Bir kullanıcı sonucu hiç tıklamayabilir ama yine de isimler, müşteri kimlikleri veya gizli bir projenin büyüklüğü gibi şeyleri öğrenebilir. İzin-bilgili küresel arama yalnızca dökümanları değil, aynı zamanda dökümanlara dair ipuçlarını da korumalıdır.
Otomatik tamamlama sık sık sızıntı kaynağıdır. Öneriler genellikle tam yetki kontrollerini atlayan hızlı bir önek araması ile güçlendirilir. UI zararsız görünse de bir harf bile bir müşteri adını veya çalışan e-postasını açığa çıkarabilir. Otomatik tamamlama, tam arama ile aynı erişim filtrelerini çalıştırmalı veya önceden filtrelenmiş bir öneri setinden (ör. kiracı ve rol bazlı) oluşturulmalıdır.
Facet sayımları ve "Yaklaşık 1.243 sonuç" bantları başka bir sessiz sızıntıdır. Sayımlar bir şeyin varlığını doğrulayabilir; eğer sayımları aynı erişim kuralları altında güvenli şekilde hesaplayamıyorsanız, daha az detay gösterin veya sayımları çıkarın.
Önbellekleme bir diğer yaygın suçludur. Kullanıcılar, roller veya kiracılar arasında paylaşılan önbellekler "sonuç hayaletleri" oluşturabilir; bir kullanıcı başka biri için oluşturulmuş sonuçları görebilir. Bu edge cache, uygulama seviyesi cache'leri ve bir arama servisi içindeki bellek içi cache'lerde olabilir.
Erken kontrol edilmesi gereken sızıntı tuzakları:
Son olarak, aşırı geniş filtrelere dikkat edin. "Sadece tenant ile filtrele" klasik çok kiracılı hatadır, ama aynı tenant içinde de olur: "departmana göre filtrele" dediğinizde erişim satır bazlıysa bu yetersiz kalır. Örnek: bir destek ajanı "refund" araması yapıp tenant içindeki tüm müşterilerdeki sonuçları alıyor; oysa VIP hesaplar sadece küçük bir takım tarafından görülmeli. Çözüm başta basittir: arama, otomatik tamamlama, facet'ler ve dışa aktarmalar dahil tüm sorgu yollarında satır düzeyinde kuralları uygulayın, sadece kayıt görüntülemede değil.
Birçok tasarım "kim neyi görebilir"e odaklanır, ama sızıntılar kenarlardan da olur: boş durumlar, zamanlama ve UI'deki küçük ipuçları. İzin-bilgili arama sıfır sonuç döndürdüğünde bile güvenli olmalı.
Kolay bir sızıntı doğrulama yokluğu ile onaylamadır. Yetkisiz bir kullanıcı belirli bir müşteri adı, talep ID'si veya e-posta arayıp "Erişim yok" veya "İzniniz yok" gibi özel bir mesaj alırsa, kaydın varlığını doğrulamış olur. "Bulunamadı"yı hem "yok" hem de "var ama izin yok" için varsayılan sonuç yapın. Yanıt süresi ve ifadeleri tutarlı tutun ki insanlar hızdan tahmin yapamasın.
Otomatik tamamlama ve yazarken arama gizlilik kaybının olduğu yerlerdir. E-postalar, telefon numaraları ve kimlik numaralarında kısmi eşleşmeler planladığınızdan daha fazlasını açığa çıkarabilir. Bu alanların nasıl davranacağını baştan kararlaştırın.
Pratik kurallar seti:
Eğer bir karakter bile birinin veri tahmin etmesine yardımcı oluyorsa, o alanı hassas kabul edin.
Arama uç noktaları sayım saldırıları için idealdir: çok sayıda sorgu deneyerek neyin var olduğunu haritalandırmak. Oran sınırlama ve anomali tespiti ekleyin, ama ne kaydettiğinize dikkat edin. Ham sorguları içeren loglar ikinci bir veri sızıntısı kaynağı olabilir.
Basit tutun: kullanıcı, IP ve kiracı başına oran sınırı; loglarda ham sorgu metninden ziyade sayılar, süreler ve kaba desenler kaydedin; tekrarlayan "yakın kaçırma" sorgularında uyarı verin; tekrarlı başarısızlıklarda engelleme veya ek doğrulama uygulayın.
Hatalarınızı sıkıcı yapın. "Bulunamadı", "izin yok" ve "geçersiz filtre" için aynı mesaj ve boş durumu kullanın. Arama UI ne kadar az söylerse, kazara o kadar az açığa çıkartabilir.
Bir destek ajanı Maya, üç müşteri hesabını yöneten bir ekipte çalışıyor. Uygulama başlık çubuğunda tek bir arama kutusu var. Ürün biletler, kişiler ve şirketler üzerinde küresel bir indeks kullanıyor, ama her sonuç erişim kurallarına uymalı.
Maya "Alic" yazıyor çünkü bir arayanın adı Alice demiş. Otomatik tamamlama birkaç öneri gösteriyor. O "Alice Nguyen - Ticket: Password reset"e tıklıyor. Hiçbir şeyi açmadan önce uygulama o kayıt için erişimi tekrar kontrol ediyor. Eğer talep hâlâ ekibine atanmışsa ve rolü izin veriyorsa, kayda gidiyor.
Maya'nın her adımda ne gördüğüne dair:
Şimdi eğitilen yeni ajan Leo'yu düşünün. Rolü sadece "Destek için herkese açık" olarak işaretlenen talepleri ve yalnızca tek bir müşteriyi görmesine izin veriyor. Leo aynı sorguyu yazar; daha az öneri görür ve eksik olan hiçbir şey hakkında ipucu verilmez. Ayrıca başka eşleşmelerin varlığını doğrulayacak "5 sonuç" gibi bir sayım gösterilmez. UI sadece açabileceğini gösterir.
Daha sonra bir yönetici "Alice Nguyen - Password reset"i Maya'nın ekibinden özel bir tırmanma ekibine yeniden atar. Kısa bir pencere içerisinde (senkronizasyon yaklaşımınıza bağlı olarak genellikle saniyeler ila birkaç dakika), Maya'nın araması bu talebi döndürmeyi bırakır. Eğer detay sayfası açıksa ve yenilerse, uygulama izinleri tekrar kontrol eder ve talep kaybolur.
İstediğiniz davranış budur: hızlı yazma ve hızlı sonuçlar, sayımlar, snippet'ler veya eski indeks girişleri aracılığıyla veri kokusu olmadan.
İzin-bilgili küresel arama, sıkıcı kenarlar güvenli olduğunda ancak "tamamlanmış" olur. Birçok sızıntı zararsız görünen yerlerde olur: otomatik tamamlama, sonuç sayıları, dışa aktarmalar.
Yayınlamadan önce gerçek verilerle (örneklerle değil) şu kontrolleri yapın:
Küçük bir rol matrisi oluşturun (roller x varlıklar) ve paylaşılan kayıtlar, yakın zamanda kaldırılmış erişimler ve tenant'lar arası benzer örnekleri içeren kasıtlı zor vakalarla bir veri seti hazırlayın.
Üç geçişte test edin: (1) rol matrisi testleri—reddedilen kayıtların asla sonuçlarda, önerilerde, sayımlarda veya dışa aktarmalarda görünmediğini doğrulayın; (2) "kırmaya çalış" testleri—ID yapıştırın, e-posta veya telefonla arama yapın ve hiçbir şey dönmemesi gereken kısmi eşleşmeler deneyin; (3) zamanlama ve önbellek testleri—izinleri değiştirin ve sonuçların hızla güncellendiğini, eski öneri kalmadığını doğrulayın.
Operasyonel olarak, arama sonuçları "yanlış göründüğü" gün için plan yapın. Sorgu bağlamını (kullanıcı, rol, kiracı) ve uygulanan izin filtrelerini loglayın, ama ham hassas sorgu metinleri veya snippet'leri saklamaktan kaçının. Güvenli hata ayıklama için yalnızca admin'e açık, bir kaydın neden eşleştiğini ve neden izin verildiğini açıklayan bir araç oluşturun.
Eğer AppMaster (appmaster.io) üzerinde inşa ediyorsanız, pratik bir yaklaşım aramayı sunucu tarafı bir akış olarak tutmaktır: Varlıkları ve ilişkileri Data Designer'da modelleyin, erişim kurallarını Business Processes'te uygulayın ve aynı izin kontrolünü otomatik tamamlama, sonuç listesi ve dışa aktarmalar için yeniden kullanın, böylece doğruluğu tek bir yerde sağlayın.
21 Oca 2026
8 dk
20 Oca 20268 dk
20 Oca 20268 dkÜcretsiz planla AppMaster ile denemeler yapın.
Hazır olduğunuzda uygun aboneliği seçebilirsiniz.
