面向少量租户的多租户应用数据库凭证存储及自动化配置咨询

场景回顾 #

你当前构建的是面向高付费客户的多租户应用，采用**单租户单库（one-database-per-tenant）**架构，租户总数400-500，核心需求是数据完全隔离，计划为每个租户配置独立数据库凭证，且租户表含tenant_id字段优化管理。

问题1：如何安全存储租户数据库凭证？ #

首先纠正一个误区：bCrypt是单向哈希算法，无法解密，所以不能用来加密需要还原使用的数据库凭证——它只能用来存储用户登录密码的哈希值（验证时对比哈希，无需还原明文）。你的思路里混淆了加密（可逆）和哈希（不可逆）的用途，下面给出可行方案：

推荐方案：对称加密存储+密钥与代码分离 #

1. 加密算法选择：使用AES-256-GCM这类安全的对称加密算法（自带完整性校验，防止篡改），将租户的数据库密码（及其他敏感凭证字段）加密后，存入主数据库的租户表中。
2. 密钥管理：
   • 绝对不要把加密密钥硬编码到代码里，也不要存在主数据库中。
   • 优先将密钥存储在服务器环境变量中（比如Nginx的fastcgi_param、PHP的环境配置文件，或服务器操作系统的环境变量），确保密钥与代码、数据完全隔离。
   • 如果追求更高安全性，可使用专业密钥管理服务（KMS），比如HashiCorp Vault、AWS KMS等——这类服务提供密钥的安全存储、访问控制和自动轮转，避免密钥直接暴露在服务器环境中。
3. 凭证使用流程：
   • 用户登录后，根据租户标识从主库取出加密后的凭证。
   • 用环境变量/KMS获取的密钥解密凭证，建立租户数据库连接。
   • 不要将解密后的凭证存入Session或长期缓存，用完即销毁；如果需要复用连接，可建立连接池并确保连接池的内存安全（比如加密连接池中的敏感信息）。

你提到的方案问题分析 #

• 代码内置salt：完全不可取，代码一旦泄露，salt也会泄露，等于直接暴露加密逻辑的核心，攻击者可轻松破解加密内容。
• 解密后存Session：Session若存储在服务器端（文件/Redis），一旦服务器被入侵，Session中的明文凭证会直接泄露，违背数据隔离的安全要求。

问题2：PHP能否自动化写入配置文件？ #

可以，但要注意安全风险和最佳实践：

可行实现方式 #

PHP的file_put_contents()函数可以直接写入文件，配合var_export()可安全生成PHP配置数组。示例代码如下（假设审批通过后触发）：

// 假设审批通过后生成的租户凭证信息
$tenantId = 'tenant_001';
$dbCredentials = [
    'host' => 'db-tenant-001.example.com',
    'dbname' => 'tenant_001_db',
    'username' => 'tenant_001_user',
    'password' => 'generated_secure_password'
];

// 配置文件路径（必须放在Web根目录之外，防止被外部访问）
$configPath = '/var/www/your-app/config/tenants.php';

// 读取现有配置（如果存在）
$existingConfigs = file_exists($configPath) ? include $configPath : [];
// 新增/更新租户配置
$existingConfigs[$tenantId] = $dbCredentials;

// 写入配置文件
$configContent = '<?php return ' . var_export($existingConfigs, true) . ';';
file_put_contents($configPath, $configContent);

// 设置严格的文件权限：仅所有者（Web服务器用户，如www-data）可读写，其他用户无权限
chmod($configPath, 0600);

关键安全注意事项 #

1. 配置文件位置：必须放在Web根目录之外，避免被HTTP请求直接访问泄露敏感信息。
2. 文件权限：设置为0600，确保只有Web服务器用户能读写，其他用户无法访问。
3. 避免注入风险：不要直接拼接字符串生成配置内容，必须用var_export()处理数组，防止代码注入。

更优替代方案 #

其实不需要写入配置文件——既然你已经用主数据库存储租户信息，直接将加密后的凭证存在主库的租户表中，每次需要时解密使用即可。这种方式更灵活，无需维护配置文件，也避免了配置文件版本管理、多服务器同步的问题，更适合你的租户规模。

内容的提问来源于stack exchange，提问作者opcode-devops