存储在向量数据库中的数据通常是企业专有的，可能包括敏感信息，例如客户记录、法律合同、电子健康记录 (EHR)、财务数据和知识产权。此外，强大的安全措施对于保护这些数据至关重要。如果存储在向量数据库中的数据未加密，可能会出现一个名为“嵌入反演攻击”的漏洞，恶意行为者可能会从嵌入本身重建原始数据。
严格的合规性法规管理着各个行业中存储在向量数据库中的数据。例如，医疗保健行业必须遵守 HIPAA，该法规规定了如何存储、传输和保护受保护的健康信息 (PHI)。同样，金融服务行业遵循 PCI DSS 来保护敏感的财务数据。这些法规要求开发人员确保数据存储和传输符合不同地区行业特定的法律框架。因此，支持数据隐私、安全和主权的特性是选择合适的向量数据库时的决定性因素。
本文探讨了在利用向量搜索优势的同时确保关键数据安全的各种策略。实施其中一些安全方法可以帮助您构建隐私增强的相似性搜索算法并将其集成到您的 AI 应用程序中。此外，您还将学习如何构建完全数据主权架构，从而让您能够控制数据并遵守相关的法律法规。
要直接跳到代码实现，请点击此处。
向量数据库安全：概述
向量数据库默认通常是不安全的，以方便快速原型设计和实验。这种方法允许开发人员快速摄取数据、构建向量表示并测试相似性搜索算法，而无需初始安全考虑。然而，在生产环境中，不安全的数据库会带来严重的数据泄露风险。
对于生产用途，强大的安全系统至关重要。身份验证，特别是使用静态 API 密钥，是控制访问和防止未经授权修改的常用方法。然而，简单的 API 身份验证不足以满足企业数据需求，因为企业数据需要精细控制。
静态 API 密钥的主要挑战在于它们的“全有或全无”访问权限，这对于企业应用程序中基于角色的数据隔离是不够的。此外，泄露的密钥可能授予攻击者完全访问权限，从而操纵或窃取数据。为了加强向量数据库的安全性，开发人员通常需要以下功能：
- 加密：这确保敏感数据在应用程序和向量数据库之间传输时被混淆。这可以防止中间人 (MitM) 攻击，恶意行为者可能试图在传输过程中拦截和窃取数据。
- 基于角色的访问控制：如前所述，传统的静态 API 密钥授予“全有或全无”的访问权限，这在企业环境中是一个重大的安全风险。RBAC 通过定义用户角色并根据这些角色分配特定的数据访问权限来提供更精细的方法。例如，分析师可能对特定数据集具有只读访问权限，而管理员可能对整个数据库具有完全的 CRUD（创建、读取、更新、删除）权限。
- 部署灵活性：数据驻留法规（如 GDPR（通用数据保护条例））和行业特定的合规性要求规定了数据可以存储、处理和访问的位置。开发人员需要选择能够提供符合这些法规的部署选项的数据库解决方案。这可能包括公司私有云中的本地部署或遵守数据驻留法律的地理分布式云部署。
Qdrant 如何处理数据隐私和安全
Qdrant 设计选择的基石之一是专注于安全功能。我们设计了一系列功能，考虑到企业用户，这些功能允许在完全数据主权的架构上构建精细的访问控制。
Qdrant 实例默认是不安全的。但是，当您准备好在生产环境中部署时，Qdrant 提供了一系列安全功能，可让您控制对数据的访问、保护数据免受泄露并遵守法规要求。使用 Qdrant，您可以构建精细的访问控制、隔离角色和权限，并创建完全数据主权的架构。
API 密钥和 TLS 加密
对于更简单的用例，Qdrant 提供基于 API 密钥的身份验证。这包括常规 API 密钥和只读 API 密钥。常规 API 密钥授予对读取、写入和删除操作的完全访问权限，而只读密钥将访问权限限制为仅数据检索操作，从而阻止写入操作。
在 Qdrant Cloud 上，您可以使用 Cloud Dashboard 创建 API 密钥。这允许您生成可以访问单个节点或集群或多个集群的 API 密钥。您可以在此处阅读如何操作的步骤。
对于本地部署，您需要配置 API 密钥身份验证。这涉及在 Qdrant 配置文件中或作为环境变量指定密钥。这确保所有对服务器的请求都必须在头部中包含有效的 API 密钥。
使用简单的基于 API 密钥的身份验证时，您还应该打开 TLS 加密。否则，您将使连接暴露于嗅探和 MitM 攻击。要使用 TLS 保护您的连接，您需要创建证书和私钥，然后在配置中启用 TLS。
API 身份验证，加上 TLS 加密，为您的 Qdrant 实例提供了第一层安全性。但是，要启用更精细的访问控制，建议的方法是利用 JSON Web Tokens (JWTs)。
Qdrant 上的 JWT
JSON Web Tokens (JWTs) 是一种紧凑、URL 安全且无状态的表示在两方之间传输的声明的方式。这些声明以 JSON 对象编码并进行加密签名。
JWT 由三部分组成：头部、有效负载和签名，它们用点号 (.) 连接起来形成一个字符串。头部包含令牌的类型和正在使用的算法。有效负载包含声明（稍后详细解释）。签名是加密哈希，确保令牌的完整性。
在 Qdrant 中，JWT 构成了构建强大访问控制的基础。让我们了解它是如何工作的。
通过在配置中指定 API 密钥并打开 jwt_rbac 功能（或者，它们可以设置为环境变量）来在 Qdrant 实例上启用 JWT。对于任何后续请求，API 密钥用于编码或解码令牌。
JWT 的工作方式是，仅 API 密钥就足以生成令牌，并且不需要与 Qdrant 实例或服务器进行任何通信。有几个库可以帮助通过编码有效负载来生成令牌，例如 PyJWT（用于 Python）、jsonwebtoken（用于 JavaScript）和 jsonwebtoken（用于 Rust）。Qdrant 使用 HS256 算法对令牌进行编码或解码。
我们很快就会查看有效负载结构，但这里是如何使用 PyJWT 生成令牌的方法。
import jwt
import datetime
# Define your API key and other payload data
api_key = "your_api_key"
payload = { ...
}
token = jwt.encode(payload, api_key, algorithm="HS256")
print(token)
生成令牌后，您应该将其包含在后续请求中。您可以通过在 Authorization 头部中将其作为不记名令牌提供，或在请求的 API Key 头部中提供。
以下是使用 Python 中的 QdrantClient 执行此操作的示例：
from qdrant_client import QdrantClient
qdrant_client = QdrantClient(
"https://:6333",
api_key="<JWT>", # the token goes here
)
# Example search vector
search_vector = [0.1, 0.2, 0.3, 0.4]
# Example similarity search request
response = qdrant_client.search(
collection_name="demo_collection",
query_vector=search_vector,
limit=5 # Number of results to retrieve
)
为方便起见，我们已在 Qdrant Web UI 的 🔑 选项卡中添加了 JWT 生成工具。对于您的本地部署，您可以在 https://:6333/dashboard#/jwt 找到它。
有效负载配置
您可以在 JWT 有效负载中使用多种不同的选项（声明），这些选项有助于控制访问和功能。让我们逐一了解它们。
exp：此声明是令牌的过期时间，是一个以秒为单位的 Unix 时间戳。过期时间过后，令牌将失效。
value_exists：此声明根据集合中存储的特定键值验证令牌。通过使用此声明，您可以简单地更改值来撤销访问权限，而无需使 API 密钥失效。
access：此声明定义令牌的访问级别。访问级别可以是全局读取 (r) 或管理 (m)。它也可以是特定于集合的，甚至是集合的子集的，使用读取 (r) 和读写 (rw)。
让我们看几个 JWT 有效负载配置示例。
场景 1：1 小时过期时间，以及对集合的只读访问权限
{
"exp": 1690995200, // Set to 1 hour from the current time (Unix timestamp)
"access": [
{
"collection": "demo_collection",
"access": "r" // Read-only access
}
]
}
场景 2：1 小时过期时间，以及对具有特定角色的用户的访问权限
假设您有一个“用户”集合，并为每个用户定义了特定的角色，例如“开发人员”、“经理”、“管理员”、“分析师”和“已撤销”。在这种情况下，您可以使用 exp 和 value_exists 的组合。
{
"exp": 1690995200,
"value_exists": {
"collection": "users",
"matches": [
{ "key": "username", "value": "john" },
{ "key": "role", "value": "developer" }
],
},
}
现在，如果您想撤销用户的访问权限，只需更改其角色的值即可。所有未来的请求都将使用上述类型的令牌有效负载无效。
场景 3：1 小时过期时间，以及对集合子集的读写访问权限
您甚至可以指定特定于集合子集的访问级别。当您利用多租户并希望隔离访问权限时，这尤其有用。
{
"exp": 1690995200,
"access": [
{
"collection": "demo_collection",
"access": "r",
"payload": {
"user_id": "user_123456"
}
}
]
}
通过组合这些声明，您可以完全自定义用户或角色在向量存储中的访问级别。
使用 JWT 创建基于角色的访问控制 (RBAC)
如上所述，JWT 声明创建了强大的杠杆，您可以通过它们在 Qdrant 上创建精细的访问控制。让我们将所有这些结合起来，了解它如何帮助您创建基于角色的访问控制 (RBAC)。
在典型的企业应用程序中，您会根据用户角色和权限对用户进行划分。这些可以是：
- 管理员或所有者：拥有完全访问权限，并可以生成 API 密钥。
- 编辑者：对特定集合具有读写访问级别。
- 查看者：对特定集合具有只读访问权限。
- 数据科学家或分析师：对特定集合具有只读访问权限。
- 开发人员：对开发或测试特定集合具有读写访问权限，但对生产数据访问受限。
- 访客：对公共可用集合具有有限的只读访问权限。
此外，您可以在集合的各个部分创建访问级别。在多租户应用程序中，如果使用了基于负载的分区，则可以为属于该用户的集合子集创建特定用户角色的只读访问权限。
您的应用程序需求最终将帮助您决定应该创建的角色和访问级别。例如，在管理客户数据的应用程序中，您可以创建额外的角色，例如：
客户支持代表：对客户服务相关数据具有读写权限，但无权访问账单信息。
账单部门：对账单数据具有只读权限，对支付记录具有读写权限。
营销分析师：对匿名客户数据具有只读权限，用于分析。
每个角色都可以分配一个 JWT，其中包含指定过期时间、集合的读/写权限和验证条件的声明。
在此类应用程序中，客户支持代表角色的 JWT 有效负载示例如下：
{
"exp": 1690995200,
"access": [
{
"collection": "customer_data",
"access": "rw",
"payload": {
"department": "support"
}
}
],
"value_exists": {
"collection": "departments",
"matches": [
{ "key": "department", "value": "support" }
]
}
}
如您所见，通过实施 RBAC，您可以确保角色及其权限的适当隔离，并避免应用程序中的隐私漏洞。
Qdrant 混合云和数据主权
数据治理因国家/地区而异，特别是对于处理不同数据隐私、安全和访问法规的全球组织。这通常需要将基础设施部署在特定的地理边界内。
为了满足这些需求，您选择的向量数据库应支持在受控基础设施内进行部署和扩展。Qdrant 混合云提供了这种灵活性，以及分片、副本、JWT 身份验证和监控等功能。
Qdrant 混合云将来自各种环境（云、本地或边缘）的 Kubernetes 集群集成到统一的托管服务中。这允许组织通过 Qdrant Cloud UI 管理 Qdrant 数据库，同时将数据库保留在其基础设施内。
凭借 JWT 和 RBAC，Qdrant 混合云提供了一个安全、私有且主权的向量存储。企业可以按地域扩展其 AI 应用程序，遵守当地法律，并保持严格的数据控制。
结论
向量相似性正日益成为利用非结构化数据的 AI 应用程序的支柱。通过将数据转换为向量——它们的数字表示——组织可以构建强大的应用程序，利用语义搜索，从更好的推荐系统到有助于个性化的算法，或者强大的客户支持聊天机器人。
然而，为了充分利用 AI 在生产中的力量，组织需要选择一个提供强大隐私和安全功能，同时帮助他们遵守当地法律法规的向量数据库。
Qdrant 提供了卓越的效率和性能，以及实现对数据的精细访问控制、基于角色的访问控制 (RBAC) 以及构建完全数据主权架构的能力。
对掌握向量搜索安全和部署策略感兴趣？加入我们的 Discord 社区，探索更高级的搜索策略，与行业中的其他开发人员和研究人员联系，并及时了解最新创新！