Sicherheit von Vektor-Datenbanken
Was ist Sicherheit von Vektor-Datenbanken?
Sicherheit von Vektor-DatenbankenKontrollen, die Vektor-Datenbanken in KI-Systemen vor Datenlecks, Poisoning, Tenant-Vermischung sowie Betriebs- und Supply-Chain-Kompromittierung schuetzen.
Vektor-Datenbanken wie Pinecone, Weaviate, Milvus, Qdrant, Chroma oder die pgvector-Extension fuer PostgreSQL speichern die Embeddings, auf denen RAG, Semantic Search, Empfehlungen und KI-Agenten basieren. Ihr Sicherheitsmodell aehnelt einer Datenbank, hat aber neue Aspekte. Vektoren koennen invertiert werden und so den Quelltext preisgeben; wiederholte Similarity-Queries koennen sensible Inhalte exfiltrieren; mandantenfaehige Indizes lecken zwischen Kunden, wenn Filterregeln falsch greifen; und Korpora koennen vergiftet werden, um Modellausgaben zu beeinflussen. Best Practice umfasst Verschluesselung at rest und in transit, feingranulare AuthN/AuthZ, Filterung nach Namespace und Metadaten, Audit-Logs der Queries, Inhaltspruefung beim Ingest sowie das Behandeln von Embeddings als potenziell personenbezogene Daten.
● Beispiele
- 01
Eine pgvector-Instanz nutzt Postgres-RLS, damit Tenants nur eigene Embeddings sehen.
- 02
Pinecone-Namespaces und API-Key-Scoping verhindern Similarity-Leaks zwischen Mandanten.
● Häufige Fragen
Was ist Sicherheit von Vektor-Datenbanken?
Kontrollen, die Vektor-Datenbanken in KI-Systemen vor Datenlecks, Poisoning, Tenant-Vermischung sowie Betriebs- und Supply-Chain-Kompromittierung schuetzen. Es gehört zur Kategorie KI- und ML-Sicherheit der Cybersicherheit.
Was bedeutet Sicherheit von Vektor-Datenbanken?
Kontrollen, die Vektor-Datenbanken in KI-Systemen vor Datenlecks, Poisoning, Tenant-Vermischung sowie Betriebs- und Supply-Chain-Kompromittierung schuetzen.
Wie funktioniert Sicherheit von Vektor-Datenbanken?
Vektor-Datenbanken wie Pinecone, Weaviate, Milvus, Qdrant, Chroma oder die pgvector-Extension fuer PostgreSQL speichern die Embeddings, auf denen RAG, Semantic Search, Empfehlungen und KI-Agenten basieren. Ihr Sicherheitsmodell aehnelt einer Datenbank, hat aber neue Aspekte. Vektoren koennen invertiert werden und so den Quelltext preisgeben; wiederholte Similarity-Queries koennen sensible Inhalte exfiltrieren; mandantenfaehige Indizes lecken zwischen Kunden, wenn Filterregeln falsch greifen; und Korpora koennen vergiftet werden, um Modellausgaben zu beeinflussen. Best Practice umfasst Verschluesselung at rest und in transit, feingranulare AuthN/AuthZ, Filterung nach Namespace und Metadaten, Audit-Logs der Queries, Inhaltspruefung beim Ingest sowie das Behandeln von Embeddings als potenziell personenbezogene Daten.
Wie schützt man sich gegen Sicherheit von Vektor-Datenbanken?
Schutzmaßnahmen gegen Sicherheit von Vektor-Datenbanken kombinieren typischerweise technische Kontrollen und operative Praktiken, wie in der Definition oben beschrieben.
Welche anderen Bezeichnungen gibt es für Sicherheit von Vektor-Datenbanken?
Übliche alternative Bezeichnungen: Vector-Store-Security, Vektor-DB-Haertung.
● Verwandte Begriffe
- ai-security№ 897
RAG
Retrieval-Augmented Generation: LLM-Muster, das zur Anfragezeit relevante Dokumente aus einem Wissensspeicher abruft und in den Prompt einfuegt, um Antworten zu untermauern.
- ai-security№ 376
Embedding-Angriffe
Angriffsklasse auf KI-Embedding-Vektoren, die das urspruengliche Input oder seine Semantik wiederherstellen, manipulieren oder missbrauchen — etwa Embedding Inversion und Similarity-Poisoning.
- ai-security№ 281
Daten-Poisoning
Angriff auf ein ML-System, bei dem Angreifer Trainingsdaten einschleusen, verändern oder umlabeln, sodass das resultierende Modell fehlerhaft arbeitet oder versteckte Backdoors enthält.
- cryptography№ 379
Verschlüsselung
Kryptographische Umwandlung von Klartext in Geheimtext mittels Algorithmus und Schlüssel, sodass nur autorisierte Parteien die Originaldaten zurückgewinnen können.