Linux Node.js日志安全防护怎么做

Linux Node.js 日志安全防护，说到底是个“看起来小、做起来大”的活儿。很多团队一开始觉得，不就是写个日志嘛，能出什么问题？可一旦遭遇数据泄露、磁盘打满、权限混乱，才意识到当初埋下的坑有多深。下面这几个方面，基本覆盖了从生成到存储再到传输的完整链路，值得逐一过一遍。

权限与目录隔离

日志文件不是什么人都能看的，这一点往往被忽略。正确的做法是：创建专用日志目录，所有者设为运行 Node 进程的系统用户（比如 node），目录权限设为 755，日志文件权限设为 600 或 640。也就是说，只有必要的用户和进程才能访问。举个例子：

mkdir logs && chown node:node logs && chmod 755 logs
chmod 600 /var/log/myapp/*.log

千万别图省事用 777。如果确实需要让其他用户（比如运维）读取，可以用 ACL 做更细粒度的授权：

setfacl -m u:alice:r /var/log/myapp/app.log

同时要确保 Node 进程的运行用户和日志文件的属主一致——否则要么写不进去，要么一不小心让别人越权访问了。总而言之，最小权限原则要贯穿始终，只给“运行所必需的”权限，然后定期审计一下配置。

日志内容安全与脱敏

这块最容易被忽视，也最容易出事故。密码、令牌、信用卡号、个人身份信息（PII）——这些敏感字段，日志里一个都不该出现。请求头里的 Authorization、Cookie 信息，要么脱敏，要么直接跳过。

工具方面，推荐使用 Winston、Pino 或 Bunyan 这类成熟的日志库。生产环境下优先使用 JSON 格式输出，方便检索和脱敏管道处理。日志级别也得管起来：生产环境建议设成 info、warn、error，别把 debug 或 trace 留着，不然日志量能把你淹没。

对于请求日志，更要做精细化控制。比如那些高频但低价值的路径（/health、OPTIONS 请求），可以采样或跳过。User-Agent 这类字段可以过滤，同时为分布式追踪加上 requestId。下面是一个结合 morgan 进行脱敏和采样的示例：

const uuid = require('uuid');
const morgan = require('morgan');

morgan.token('requestId', (req) => req.id || (req.id = uuid.v4()));

const jsonFormat = JSON.stringify({
  method: ':method',
  url: ':url',
  status: ':status',
  ip: ':remote-addr',
  userAgent: ':filteredUserAgent',
  requestId: ':requestId',
  responseTime: ':response-time'
});

morgan.token('filteredUserAgent', (req) => {
  const ua = req.headers['user-agent'] || '';
  return /InternalMonitor|SecretAgent/i.test(ua) ? '***FILTERED***' : ua;
});

const sampleRate = 0.1; // 10% 采样

app.use(morgan(jsonFormat, {
  stream: { write: msg => process.stdout.write(msg) },
  skip: (req, res) => {
    if (res.statusCode >= 400) return false;   // 保留错误
    if (req.method !== 'GET') return false;    // 保留非GET
    return Math.random() > sampleRate;         // 采样GET
  }
}));

这种做法，既能降低敏感信息泄露的风险，也能控制日志成本，同时保持可观测性。

存储轮转与保留策略

日志不能无限制地堆在那里。第一个推荐的方案是用 logrotate 集中管理，按大小或时间轮转、压缩、保留一定天数、自动清理。示例配置：

/var/log/myapp/*.log {
    daily
    missingok
    rotate 30
    compress
    delaycompress
    notifempty
    create 0640 node node
    postrotate
        systemctl reload myapp >/dev/null 2>&1 || true
    endscript
}

关键点在于：保留天数（比如30天）、启用压缩和延迟压缩、按服务账户创建新文件、轮转后通知应用重新打开文件句柄。同时，应用内部也可以设置一道防线，比如用 Winston 的 maxsize 和 maxFiles 参数做兜底。

传输加密与集中监控告警

日志在网络上传输，明文可不行。对外传输一定要启用 TLS 或 HTTPS，集群内或跨机房传输同样要加密，防止中间人截获。

集中化方面，把日志发到 ELK Stack（Elasticsearch、Logstash、Kibana）或 Splunk 这类 SIEM 平台，然后配置告警规则。异常登录、权限变更、频繁的 4xx/5xx 响应、暴力请求——这些场景一旦触发，系统应该能实时告警。配合统一的 requestId，还能在集中平台上实现跨服务的链路追踪和根因分析。

运行期防护与运维审计

生产环境下，错误处理输出要格外小心。堆栈信息和配置详情不能暴露给外界，否则等于给攻击者递刀子。通过全局异常监听来记录错误并安全退出：

process.on('uncaughtException', ...)
process.on('unhandledRejection', ...)

依赖治理也是老生常谈了，但确实管用。定期跑一下 npm audit 和 npm outdated，及时修复依赖漏洞。输入校验要严格，配合 Helmet 设置安全头，能有效降低日志注入和其他攻击风险。

别忘了监控磁盘。日志分区使用率要盯着，增长趋势要分析，不然哪天磁盘写满，服务就跟着挂了。最后，日志的访问、变更、保留和销毁流程要定期审计，满足合规要求——这不只是技术问题，更是责任问题。