Ecto迁移日志中的敏感字段处理问题解析

问题背景

在使用Ecto进行数据库迁移时，开发者可能会遇到敏感信息在日志中暴露的问题。特别是在执行数据初始化操作时，如创建初始用户账号，密码哈希值等敏感字段会被完整记录到日志中，这显然不符合安全最佳实践。

问题重现

考虑以下典型的Ecto迁移场景：我们需要在迁移过程中创建一个初始用户账号。开发者通常会这样编写迁移代码：

defmodule CaseManager.Repo.Migrations.FirstUser do
  use Ecto.Migration

  def change do
    execute(fn ->
      repo().insert(
        %CaseManager.Accounts.User{
          email: "EMAIL@EXAMPLE",
          hashed_password: Bcrypt.hash_pwd_salt("EXAMPLE"),
          inserted_at: DateTime.truncate(DateTime.utc_now(), :second),
          updated_at: DateTime.truncate(DateTime.utc_now(), :second)
        },
        log: :error
      )
    end)
  end
end

执行此迁移后，日志中会完整显示SQL查询内容，包括密码哈希值：

INSERT INTO "private"."users" ("inserted_at","email","hashed_password","updated_at") 
VALUES ($1,$2,$3,$4) RETURNING "id" 
[~U[2024-07-19 08:43:03Z], "[e-mail]", "$2b$12$P/59vWqWER.jmqWPuHFFvuJ34V/j508XaXF4Euju.Iv.YuBkRuKAu", ~U[2024-07-19 08:43:03Z]]

问题分析

虽然Ecto的Schema定义中可以将字段标记为redacted（如密码字段），但这种标记在迁移日志中并不生效。这是因为：

1. 日志记录层级问题：查询日志记录发生在数据库适配器层面，此时已经丢失了原始Schema的元数据信息，包括字段的redacted标记。

2. 日志目的不同：查询日志主要用于调试和审计，需要完整记录执行的SQL语句，因此默认会显示所有参数值。

解决方案

针对这个问题，Ecto核心开发者建议采用以下两种解决方案：

方案一：禁用日志并自定义记录

execute(fn ->
  Logger.error("正在创建初始用户: EMAIL@EXAMPLE")
  
  repo().insert(
    %CaseManager.Accounts.User{
      email: "EMAIL@EXAMPLE",
      hashed_password: Bcrypt.hash_pwd_salt("EXAMPLE"),
      inserted_at: DateTime.truncate(DateTime.utc_now(), :second),
      updated_at: DateTime.truncate(DateTime.utc_now(), :second)
    },
    log: false
  )
end)

这种方法完全禁用自动日志记录，转而使用自定义的日志输出，可以精确控制哪些信息需要记录。

方案二：使用环境变量控制

对于生产环境，可以考虑通过环境变量来动态控制日志行为：

log_level = if System.get_env("REDACT_LOGS"), do: false, else: :error

repo().insert(
  %User{...},
  log: log_level
)

安全建议

1. 生产环境注意事项：在生产环境中执行包含敏感数据的迁移时，务必确保日志级别设置为足够安全的值。

2. 密码处理：即使日志中不显示密码哈希值，也应确保迁移文件本身的安全，因为其中可能包含生成密码的代码。

3. 审计追踪：如果确实需要记录某些操作，可以考虑将其记录到专门的审计日志中，而非普通应用日志。

总结

Ecto的查询日志设计初衷是提供完整的SQL执行信息，这在调试时非常有用，但也带来了敏感数据暴露的风险。开发者需要理解这一设计决策，并在需要保护敏感信息时采取适当的措施。通过禁用自动日志记录并实现自定义日志输出，可以在保持必要审计能力的同时保护敏感数据安全。