> **Beta Translation:** This document was translated via Machine Learning and as such may not be 100% accurate. All non-English languages are currently classified as Beta.
Mevcut Neo4j üçlü depolama ve sorgu uygulaması, kullanıcı/koleksiyon izolasyonu eksikliği nedeniyle çoklu kiracılık güvenliği sorunlarına yol açmaktadır. Tüm üçlüler, kullanıcıların diğer kullanıcıların verilerine erişmesini veya koleksiyonları karıştırmasını engelleyen herhangi bir mekanizma olmadan aynı grafik alanında saklanmaktadır.
TrustGraph'taki diğer depolama arka uçlarından farklı olarak:
**Cassandra**: Her kullanıcı için ayrı anahtarlar ve her koleksiyon için tablolar kullanır.
**Vektör depoları** (Milvus, Qdrant, Pinecone): Koleksiyona özgü ad alanlarını kullanır.
**Neo4j**: Şu anda tüm verileri tek bir grafik alanında paylaşır (güvenlik açığı).
## Mevcut Mimari
### Veri Modeli
**Düğümler**: `:Node` etiketi ile `uri` özelliği, `:Literal` etiketi ile `value` özelliği.
`Triples` mesajları`metadata.user` ve `metadata.collection` alanlarını içerir.
Depolama hizmeti kullanıcı/koleksiyon bilgilerini alır, ancak bunları yoksayar.
Sorgu hizmeti `TriplesQueryRequest` içinde `user` ve `collection`'i bekler, ancak bunları yoksayar.
### Mevcut Güvenlik Sorunu
```cypher
# Any user can query any data - no isolation
MATCH (src:Node)-[rel:Rel]->(dest:Node)
RETURN src.uri, rel.uri, dest.uri
```
## Önerilen Çözüm: Özellik Tabanlı Filtreleme (Önerilen)
### Genel Bakış
Tüm düğümlere ve ilişkilerlere `user` ve `collection` özelliklerini ekleyin, ardından tüm işlemleri bu özelliklere göre filtreleyin. Bu yaklaşım, güçlü bir izolasyon sağlarken sorgu esnekliğini ve geriye dönük uyumluluğu korur.
### Veri Modeli Değişiklikleri
#### Gelişmiş Düğüm Yapısı
```cypher
// Node entities
CREATE (n:Node {
uri: "http://example.com/entity1",
user: "john_doe",
collection: "production_v1"
})
// Literal entities
CREATE (n:Literal {
value: "literal value",
user: "john_doe",
collection: "production_v1"
})
```
#### Gelişmiş İlişki Yapısı
```cypher
// Relationships with user/collection properties
CREATE (src)-[:Rel {
uri: "http://example.com/predicate1",
user: "john_doe",
collection: "production_v1"
}]->(dest)
```
#### Güncellenmiş İndeksler
```cypher
// Compound indexes for efficient filtering
CREATE INDEX node_user_collection_uri FOR (n:Node) ON (n.user, n.collection, n.uri);
CREATE INDEX literal_user_collection_value FOR (n:Literal) ON (n.user, n.collection, n.value);
CREATE INDEX rel_user_collection_uri FOR ()-[r:Rel]-() ON (r.user, r.collection, r.uri);
// Maintain existing indexes for backwards compatibility (optional)
CREATE INDEX Node_uri FOR (n:Node) ON (n.uri);
CREATE INDEX Literal_value FOR (n:Literal) ON (n.value);
CREATE INDEX Rel_uri FOR ()-[r:Rel]-() ON (r.uri);
Koleksiyonlar arası sorgular (başarısız olmalıdır)
Mevcut verilerle yapılan geçiş testleri
Büyük veri kümeleriyle yapılan performans ölçümleri
### Güvenlik Testleri
Diğer kullanıcıların verilerine erişme girişimleri
Kullanıcı/koleksiyon parametrelerine yönelik SQL enjeksiyonu tarzı saldırılar
Çeşitli sorgu kalıpları altında tam izolasyonu doğrulayın
## Performans Hususları
### İndeks Stratejisi
Optimum filtreleme için `(user, collection, uri)` üzerinde birleşik indeksler
Bazı koleksiyonların çok daha büyük olması durumunda, kısmi indeksleri göz önünde bulundurun
İndeks kullanımını ve sorgu performansını izleyin
### Sorgu Optimizasyonu
Filtrelenmiş sorgularda indeks kullanımını doğrulamak için EXPLAIN'i kullanın
Sık erişilen veriler için sorgu sonucu önbelleklemesini göz önünde bulundurun
Çok sayıda kullanıcı/koleksiyonla bellek kullanımını analiz edin
### Ölçeklenebilirlik
Her kullanıcı/koleksiyon kombinasyonu, ayrı veri adacıkları oluşturur
Veritabanı boyutunu ve bağlantı havuzu kullanımını izleyin
Gerekirse, yatay ölçeklendirme stratejilerini göz önünde bulundurun
## Güvenlik ve Uyumluluk
### Veri İzolasyon Garantileri
**Fiziksel**: Tüm kullanıcı verileri, açık kullanıcı/koleksiyon özellikleri ile saklanır
**Mantıksal**: Tüm sorgular, kullanıcı/koleksiyon bağlamıyla filtrelenir
**Erişim Kontrolü**: Hizmet seviyesindeki doğrulama, yetkisiz erişimi engeller
### Denetim Gereksinimleri
Tüm veri erişimlerini kullanıcı/koleksiyon bağlamıyla kaydedin
Geçiş etkinliklerini ve veri hareketlerini izleyin
İzolasyon ihlali girişimlerini izleyin
### Uyumluluk Hususları
GDPR: Kullanıcıya özel verileri bulma ve silme yeteneğinin geliştirilmesi
SOC2: Açık veri izolasyonu ve erişim kontrolleri
HIPAA: Sağlık verileri için güçlü kiracı izolasyonu
## Riskler ve Önlemler
| Risk | Etki | Olasılık | Önlem |
|------|--------|------------|------------|
| Sorguda eksik kullanıcı/koleksiyon filtresi | Yüksek | Orta | Zorunlu doğrulama, kapsamlı testler |
| Performans düşüşü | Orta | Düşük | İndeks optimizasyonu, sorgu analizi |
| Geçiş sırasında veri bozulması | Yüksek | Düşük | Yedekleme stratejisi, geri alma prosedürleri |
| Karmaşık, koleksiyonlar arası sorgular | Orta | Orta | Sorgu kalıplarını belgeleyin, örnekler sağlayın |
## Başarı Kriterleri
1.**Güvenlik**: Üretimde, kullanıcılar arası veri erişiminin sıfır olması
2.**Performans**: Filtrelenmemiş sorgulara kıyasla %10'dan düşük sorgu performans etkisi
3.**Geçiş**: Mevcut verilerin %100'ü, kayıp olmadan başarıyla geçirilmiştir
4.**Kullanılabilirlik**: Tüm mevcut sorgu kalıpları, kullanıcı/koleksiyon bağlamıyla çalışır
5.**Uyumluluk**: Kullanıcı/koleksiyon verilerine yapılan tüm erişimlerin tam denetim kaydı
## Sonuç
Özellik tabanlı filtreleme yaklaşımı, Neo4j'ye kullanıcı/koleksiyon izolasyonu eklemek için güvenlik, performans ve bakım açısından en iyi dengeyi sağlar. TrustGraph'ın mevcut çok kiracılık kalıplarıyla uyumludur ve aynı zamanda Neo4j'nin grafik sorgulama ve indeksleme konusundaki güçlü yönlerinden yararlanır.
Bu çözüm, TrustGraph'ın Neo4j arka ucunun, diğer depolama arka uçları ile aynı güvenlik standartlarını karşılamasını sağlar ve veri izolasyonu güvenlik açıklarını önlerken, grafik sorgularının esnekliğini ve gücünü korur.