做工控或者做物联网平台的同学应该都跟Modbus/TCP打过交道。这东西在PLC、HMI、上位机、电表之间几乎是无处不在的可也正是因为到处都是它的安全隐患才容易被忽略。默认的Modbus/TCP报文完全是明文裸奔的无论你是读保持寄存器还是下发写指令谁在网络上拿个抓包工具都能看得清清楚楚这在讲究生产安全的工业环境里是挺要命的事。这次我就用C#把一套完整的加密与认证方案拆开讲透从TLS握手到证书校验再到Modbus报文在安全通道里的收发给出可以直接落地的实现和踩坑经验。如果你正在做设备联网、上位机开发、工业网关或者SCADA对接这篇内容应该能帮你省不少事。1. 先搞清楚裸奔的Modbus/TCP到底缺什么1.1 明文报文的杀伤力被严重低估Modbus/TCP的报文结构大家应该都熟悉7字节的MBAP头加上功能码和数据体。MBAP里的事务标识、协议标识、长度、单元标识全是明文功能码和寄存器值同样不带任何混淆。这意味着只要有人能接入生产网络就可以用Wireshark抓到完整的读写指令轻轻松松还原出当前各设备的寄存器状态甚至直接构造一个写命令去改写PLC里的设定值。很多年前我帮某团队调试一套设备采集系统当时上位机和PLC之间就跑了上千个点位的实时数据网络里还有一条视频监控链路。因为监控摄像头接入太随意整个交换网络实际上没法做到严格隔离抓包时能看到各种设备在互发广播包其中就包括几台PLC的Modbus/TCP请求。那一刻我意识到工业现场里“网络能通”和“网络是安全的”完全是两码事。如果攻击者已经拿到内网权限明文Modbus/TCP几乎等于把设备操作权也一并交了出去。1.2 加密和认证其实管的是两件事很多人一听到“加安全通道”第一反应是“把数据加密一下”。但一个真正可用的方案至少要覆盖三个不同维度机密性报文内容不能被窃听者读懂。读寄存器、写参数、上传配方这些数据都可能在攻击者眼里成为有价值的情报。完整性报文不能被中间人篡改。比如把写保持寄存器的值从气温100改成1000或者把功能码调包这些改动必须能在接收端被识别出来。认证性通信双方必须证明自己是谁。上位机不能随便冒充PLC的服务端口也不能被随意连上。TLS恰好能同时解决这三个问题通过证书交换确认身份通过握手协商出会话密钥通过记录层的MAC或AEAD标签保证每条报文没有被改动过。这也是为什么我后来在项目里优先选TLS而不是自己写一套简单的异或加密或者固定AES密钥——后者虽然也能把数据变乱但密钥分发和管理在工业环境里是个巨大的坑。你总不能每台PLC旁边安排一个人去维护一份密码表。1.3 为什么不在应用层自己搞加密也有些工程师会问“我干脆把Modbus报文里的寄存器值先AES一下再拼上签名不也一样吗”从纯理论角度确实有点像但落到工程上你就会发现麻烦事接踵而来。你要自己设计会话状态自己管理对称密钥的轮换自己处理重放攻击自己实现防篡改的校验逻辑还要为不同品牌的PLC和上位机都实现一遍相同的算法。这是一条通向兼容性地狱的路。TLS是经过无数场景锤炼的标准协议操作系统和开发框架都内置了实现。在C#里直接用SslStream包装一下NetworkStream就能把一个普通的TCP Socket升级成加密通道。底层对握手细节、证书链验证、密码套件选择、重协商机制都处理好了。工业项目里多一事不如少一事能用经过验证的标准方案就尽量不要自创密码学协议。1.4 结合现场环境评估风险在设计方案之前最好先盘一下现场的网络拓扑。常见的隐患有三类一是把视频监控、办公网络和生产网络混在一个二层网络里二是设备默认口令没有改或者PLC本身不设口令三是远程运维通道直接开放相当于给外部攻击者递了把钥匙。加密与认证解决的是“传输链路”这一段但它不是万能的。设备自身的访问控制、网络安全分区、端口屏蔽、补丁管理这些纵深防御措施同样要做。我在项目里通常是先把网络分区和访问白名单搭好再在Modbus/TCP链路上加TLS双向认证这样即使内网里出现一台被攻陷的主机它也没办法轻易冒充合法客户端去操作PLC。2. 从握手到报文加密认证整体流程设计2.1 单向认证还是双向认证单一的TLS方案可以只做“服务端认证”也就是客户端校验服务端的证书确保自己连的是真的Modbus Server。这个模式相当于你打电话过去先听对方声音对不对但对方并不知道是你。在工业场景里我强烈建议做“双向认证”也就是requireClientCertificatetrue。服务端同样要求客户端出示证书验证通过后才允许建立安全通道。这样做的价值在于不是随便一台电脑装上Modbus客户端工具就能连上你的PLC网关只有那些证书被加入信任列表的合法上位机才有权限接入。你可以想象成门禁系统里刷脸还要刷工卡双重确认更稳妥。有些项目里客户端不是PC而是另一台PLC或嵌入式设备。只要设备支持TLS和证书存储双向认证完全可以落地。如果设备实在没法内置证书就在前端加一个安全网关网关负责证书管理和TLS终结设备和网关之间走车间内受控网络。这种架构也是工业现场常见的妥协方案。2.2 应用层认证在TLS之上再加一道锁双向证书认证解决的是“设备身份”但它不能解决“操作者身份”。一台合法的上位机可能被不同的人使用这时候就需要在TLS通道之上再做一次应用层认证。常见做法是定义一个简单的登录帧在TLS握手完成后客户端先发送用户名和口令摘要服务端校验通过才会继续处理Modbus请求。有人会觉得这有点重复但实际项目里“设备合法”和“用户合法”确实是两个不同层面的问题。证书是长期有效的如果某位操作员离职了你可以直接停用他的账户而不必去吊销一台设备的证书。这也是我在方案里始终坚持两层认证的原因TLS管机器应用层管人。具体的登录帧设计不需要太复杂。我在项目里用的是一个固定魔数加命令字加定长字段的格式比如0xAA 0x01 [用户名长度] [用户名] [口令哈希长度] [口令哈希]。口令不要传明文传SHA256摘要服务端从数据库里取出对应账户的密文进行比对用固定时间比较函数避免时序攻击。这样即使日志被人抓了包也拿不到可逆的凭据。2.3 长连接优先与握手开销对比TLS的握手过程需要几次消息往返对短连接来说这个延迟会被放大。假设一次握手需要20毫秒如果上位机每采集一个点位就新建连接1000个点位就会有20秒的时间纯花在握手上这在实时性要求高的场景是不能接受的。所以我建议所有Modbus/TLS客户端和服务端都保持长连接建立起安全通道后持续复用只有在断线或需要重连时才再次握手。长连接带来的另一个好处是可以减少证书链校验频率因为校验只发生在握手阶段。需要注意的是长连接并不意味着一条连接发完请求就不管了工业网关通常会对空闲连接做超时管理比如超过30秒没有活跃流量就主动断开客户端检测到断线后自动重新握手并恢复会话。超时时间要根据现场轮询周期来定太短会频繁重连太长又可能让半死不活的连接一直占着资源。2.4 证书怎么生成和管理要用TLS首先得有一批证书。生产环境建议用内部CA签发客户端和服务端的证书都挂在同一个CA下面这样验证时只需要信任CA根证书而不必为每张证书单独配置信任关系。开发测试阶段可以直接生成自签名证书但要注意自签名证书默认不受系统信任客户端校验时要么手动添加到证书存储要么在校验回调里做固定指纹比对。生成证书的方法很多用OpenSSL就能搞定。我常用的简化命令是# 生成CA根证书 openssl req -x509 -newkey rsa:2048 -keyout ca_key.pem -out ca_cert.pem -days 3650 -nodes -subj /CNDemo-CA # 生成服务端证书 openssl req -newkey rsa:2048 -keyout server_key.pem -out server_req.pem -nodes -subj /CNmodbus-server openssl x509 -req -in server_req.pem -CA ca_cert.pem -CAkey ca_key.pem -CAcreateserial -out server_cert.pem -days 365 openssl pkcs12 -export -out server.pfx -inkey server_key.pem -in server_cert.pem # 生成客户端证书 openssl req -newkey rsa:2048 -keyout client_key.pem -out client_req.pem -nodes -subj /CNmodbus-client openssl x509 -req -in client_req.pem -CA ca_cert.pem -CAkey ca_key.pem -CAcreateserial -out client_cert.pem -days 365 openssl pkcs12 -export -out client.pfx -inkey client_key.pem -in client_cert.pem证书签发之后要关注有效期。工业设备经常连续运行好几年证书过期是很多安全项目的隐形炸弹。建议在服务器和网关上加上证书到期监测提前邮件或告警提醒别等到现场突然连不上才去翻日志。另外所有工控设备的系统时钟都建议和NTP时间服务器同步否则证书有效期校验会因为时钟偏差而误判。3. 用代码说话C#服务端和客户端的落地实现3.1 环境准备和公共辅助函数开发环境我用的是.NET 8System.Net.Security命名空间里直接提供了SslStream类不需要额外安装NuGet包。如果你还在用.NET Framework 4.7也可以用同样API只是异步命名是Begin/End那套。下文代码以.NET 6/8为准。在处理Modbus/TCP报文时最大的坑是大小端问题。Modbus/TCP是网络字节序也就是大端在前而C#的BitConverter在绝大多数平台上读取的是小端。我干脆写了两个辅助函数后面所有解析都统一走这两个函数避免到处手动反转字节static ushort ReadUInt16BE(ReadOnlySpanbyte data, int offset) { return (ushort)((data[offset] 8) | data[offset 1]); } static void WriteUInt16BE(Spanbyte data, int offset, ushort value) { data[offset] (byte)(value 8); data[offset 1] (byte)(value 0xFF); } static async Taskbool ReadFullAsync(Stream stream, byte[] buffer) { int offset 0; while (offset buffer.Length) { int read await stream.ReadAsync(buffer.AsMemory(offset, buffer.Length - offset)); if (read 0) { return false; } offset read; } return true; }ReadFullAsync非常关键。Socket流的Read每次未必返回你要的完整长度尤其在加密通道上一次读取可能只返回半个帧。我在很多项目里见过因为没处理半包导致解析错乱的问题所以统一用循环读取来凑满指定字节数。3.2 服务端实现TLS监听、认证与Modbus应答服务端的核心逻辑分几步监听TCP端口接受客户端连接用SslStream包裹底层网络流开启TLS双向认证然后做应用层认证最后循环读取Modbus请求并返回响应。代码骨架如下using System.Net; using System.Net.Security; using System.Net.Sockets; using System.Security.Authentication; using System.Security.Cryptography; using System.Security.Cryptography.X509Certificates; var serverCert new X509Certificate2(server.pfx, your-password); var listener new TcpListener(IPAddress.Any, 502); listener.Start(); Console.WriteLine(Modbus/TLS server started on port 502); var registerTable new Dictionaryushort, ushort { [100] 1234, [101] 5678, }; while (true) { var client await listener.AcceptTcpClientAsync(); _ Task.Run(() HandleClientAsync(client, serverCert, registerTable)); } static async Task HandleClientAsync( TcpClient client, X509Certificate2 serverCert, Dictionaryushort, ushort registers) { try { using var networkStream client.GetStream(); using var ssl new SslStream(networkStream, false); await ssl.AuthenticateAsServerAsync( serverCert, requireClientCertificate: true, SslProtocols.Tls12, checkCertificateRevocation: false); Console.WriteLine($TLS handshake completed, client cert: {ssl.RemoteCertificate?.Subject}); if (!await AuthenticateAppAsync(ssl)) { Console.WriteLine(App-level authentication failed); return; } byte[] header new byte[7]; while (true) { if (!await ReadFullAsync(ssl, header)) { break; } ushort transactionId ReadUInt16BE(header, 0); ushort length ReadUInt16BE(header, 4); byte unitId (byte)ssl.ReadByte(); byte[] pdu new byte[length - 1]; if (!await ReadFullAsync(ssl, pdu)) { break; } byte[] response BuildModbusResponse(transactionId, unitId, pdu, registers); await ssl.WriteAsync(response); } } catch (Exception ex) { Console.WriteLine($Connection error: {ex.Message}); } }AuthenticateAsServerAsync里我传了四个参数服务端证书、是否要求客户端证书、最低TLS协议版本、是否检查证书吊销列表。在工业内网环境证书吊销检查经常因为网络隔离而超时所以我把最后一个参数设成了false同时靠手动构建证书链来保证验证强度。requireClientCertificate打开之后如果客户端没带证书握手阶段就会被抛出异常等于在传输层就拦掉了一大批不合法连接。BuildModbusResponse负责解析PDU并返回对应的响应帧。目前项目里最常用的功能码是03读保持寄存器和06写单个寄存器我在这段代码里把这两个都实现了static byte[] BuildModbusResponse( ushort transactionId, byte unitId, byte[] pdu, Dictionaryushort, ushort registers) { byte functionCode pdu[0]; byte[] body; if (functionCode 0x03) { ushort start ReadUInt16BE(pdu, 1); ushort count ReadUInt16BE(pdu, 3); int byteCount count * 2; body new byte[2 byteCount]; body[0] 0x03; body[1] (byte)byteCount; for (int i 0; i count; i) { ushort val registers.TryGetValue((ushort)(start i), out var v) ? v : (ushort)0; WriteUInt16BE(body, 2 i * 2, val); } } else if (functionCode 0x06) { ushort addr ReadUInt16BE(pdu, 1); ushort value ReadUInt16BE(pdu, 3); registers[addr] value; body new byte[] { 0x06, pdu[1], pdu[2], pdu[3], pdu[4] }; } else { body new byte[] { (byte)(functionCode | 0x80), 0x01 }; } byte[] frame new byte[7 body.Length]; WriteUInt16BE(frame, 0, transactionId); WriteUInt16BE(frame, 2, 0); WriteUInt16BE(frame, 4, (ushort)(1 body.Length)); frame[6] unitId; body.CopyTo(frame, 7); return frame; }这里有个细节MBAP里的长度字段计算方式是“单元标识符1字节加上PDU长度”所以我在第4个字段写入的是1 body.Length千万别直接填body.Length不然客户端解析会直接卡住。这个错误我在初次实现时踩过抓包看了大半天才反应过来长度少算了一位。应用层认证函数如下。服务端先读取一个认证帧帧头0xAA是固定魔数0x01表示登录请求接着是用户名和口令哈希。口令哈希用的是SHA256比较时用了.NET的CryptographicOperations.FixedTimeEquals避免用比较数组造成的时序泄露static async Taskbool AuthenticateAppAsync(SslStream ssl) { byte[] magic new byte[1]; if (!await ReadFullAsync(ssl, magic) || magic[0] ! 0xAA) { return false; } byte[] meta new byte[3]; if (!await ReadFullAsync(ssl, meta)) { return false; } byte command meta[0]; byte userLen meta[1]; byte hashLen meta[2]; if (command ! 0x01 || userLen 0 || hashLen ! 32) { return false; } byte[] userBytes new byte[userLen]; if (!await ReadFullAsync(ssl, userBytes)) { return false; } byte[] hashBytes new byte[hashLen]; if (!await ReadFullAsync(ssl, hashBytes)) { return false; } string username System.Text.Encoding.UTF8.GetString(userBytes); byte[] expected SHA256.HashData( System.Text.Encoding.UTF8.GetBytes(${username}:your-password)); bool ok CryptographicOperations.FixedTimeEquals(hashBytes, expected); byte[] reply new byte[] { 0xAA, 0x01, ok ? (byte)0x00 : (byte)0xFF }; await ssl.WriteAsync(reply); return ok; }生产环境里口令字段不会被硬编码在代码里而是存到配置中心、数据库或者密钥管理系统里。我这里把格式简化了重点是演示帧结构和校验逻辑。你真正落地时可以把hashLen设计成32字节定长也可以在帧里携带一个随机数nonce防止攻击者用截获的登录帧重放。实际操作里我还会在口令哈希里拼一个会话级的随机盐进一步降低重放风险。3.3 客户端实现证书校验、登录帧与Modbus读写客户端这边的流程正好跟服务端对应先连接TCP端口再用SslStream包裹流加载客户端证书触发TLS握手。握手成功后发送应用层登录帧然后就可以正常收发Modbus请求了。using System.Net.Security; using System.Net.Sockets; using System.Security.Authentication; using System.Security.Cryptography.X509Certificates; var clientCert new X509Certificate2(client.pfx, your-password); using var tcp new TcpClient(); await tcp.ConnectAsync(192.168.1.100, 502); using var ssl new SslStream(tcp.GetStream(), false, ValidateServerCert); await ssl.AuthenticateAsClientAsync( modbus-server, new X509CertificateCollection { clientCert }, SslProtocols.Tls12, true); Console.WriteLine(TLS channel established); await SendAppAuthAsync(ssl, admin); await ReadHoldingRegistersAsync(ssl, 100, 2); await WriteSingleRegisterAsync(ssl, 100, 8888);ValidateServerCert是服务端证书校验回调。生产环境里应该让系统自动校验证书链不过在实际项目中经常要用到固定证书指纹。我用自签名证书做测试时就在回调里比对证书指纹只有指纹匹配的服务器才会被信任static bool ValidateServerCert( object sender, X509Certificate? cert, X509Chain? chain, SslPolicyErrors errors) { if (errors SslPolicyErrors.None) { return true; } var x509 new X509Certificate2(cert!); Console.WriteLine($Server cert thumbprint: {x509.Thumbprint}); // 严格环境下对比预期的指纹 return x509.Thumbprint ! null x509.Thumbprint.Equals(5A3F9C2B8E1D4F6A7C0E1234567890ABCDEF1234, StringComparison.OrdinalIgnoreCase); }注意固定证书指纹适合确定拓扑的小规模系统。如果现场设备很多还是建议部署内部CA让客户端直接信任CA根证书这样新设备接入时不需要一个个改客户端代码。发送登录帧和读保持寄存器的逻辑如下static async Task SendAppAuthAsync(SslStream ssl, string username) { string credential ${username}:your-password; byte[] hash SHA256.HashData(System.Text.Encoding.UTF8.GetBytes(credential)); var body new Listbyte { 0xAA, 0x01, (byte)username.Length, 32 }; body.AddRange(System.Text.Encoding.UTF8.GetBytes(username)); body.AddRange(hash); byte[] frame body.ToArray(); await ssl.WriteAsync(frame); byte[] reply new byte[3]; await ReadFullAsync(ssl, reply); if (reply[2] ! 0x00) { throw new InvalidOperationException(App-level authentication failed); } } static async Task ReadHoldingRegistersAsync(SslStream ssl, ushort start, ushort count) { byte[] request new byte[12]; WriteUInt16BE(request, 0, 1); WriteUInt16BE(request, 2, 0); WriteUInt16BE(request, 4, 6); request[6] 1; request[7] 0x03; WriteUInt16BE(request, 8, start); WriteUInt16BE(request, 10, count); await ssl.WriteAsync(request); byte[] header new byte[7]; await ReadFullAsync(ssl, header); ushort length ReadUInt16BE(header, 4); byte[] pdu new byte[length - 1]; await ReadFullAsync(ssl, pdu); if (pdu[0] 0x03) { int byteCount pdu[1]; Console.WriteLine($Read {byteCount} bytes from holding registers); for (int i 0; i byteCount; i 2) { ushort value ReadUInt16BE(pdu, 2 i); Console.WriteLine($Register 0x{(start (ushort)(i / 2)):X4}: {value}); } } }请求帧里request[6] 1是单元标识符如果服务端下挂了多个从站这里要换成实际的单元地址。事务ID我用的是固定值1实际项目中应该维护一个单调递增的计数器并在读取响应时校验返回的事务ID是否和请求一致。Modbus/TCP协议本身允许多个请求并发在途事务ID就是用来匹配响应的如果忽略这点高并发下响应会乱套。写单个寄存器的方法类似只是功能码换成0x06寄存器值和地址都放进请求里。响应帧应该回显请求内容我这里就不重复展开了。3.4 关于并发和异常处理的经验上面的服务端代码是单连接示例_ Task.Run(...)的方式能支撑一定并发但靠的是每个连接一个独立Task遇到大量设备上报的场景可能会造成线程切换开销。如果现场设备规模比较大建议在服务端套上用Channel或者信号量实现的控制并发数不要让无限制的Task堆积拖垮网关。IO密集型的TLS加解密本身不会长时间占用线程但连接数上来以后GC和内存占用也要注意。另外服务端在处理完异常后一定要把连接关闭并释放资源。I或我用using包裹了SslStream和TcpClient但如果你在SslStream之上又封装了缓冲层更要留意层层释放。偶发的连接中断在工业网络里太常见了代码一定要能扛住客户端拔网线、网关重启、PLC断电这些场景别一遇到异常就整个进程崩掉。我的习惯是在catch里把异常对象日志写下来同时不影响主监听循环继续接受新连接。4. 踩坑实录证书、兼容性和性能问题4.1 证书验证失败的四种典型场景我见过最多的就是证书验证报错。第一种是系统时间不对设备刚开机时RTC电池没电时间停留在两年前TLS握手时证书还没生效或已经过期直接抛出异常。解决方法是所有工控设备都配置NTP同步至少在上位机和网关层面保证时钟准确。第二种是证书链不完整。服务端把证书发过去了但客户端本地的CA根证书没有安装于是找不到信任锚点。我处理过很多现场最后发现都是因为省事用了自签名证书却没把自签名证书手动加到客户端信任库。这个问题的标准做法是统一生成CA然后把CA根证书预置到所有客户端和服务端。第三种是主机名不匹配。客户端调用AuthenticateAsClientAsync时传了服务器名称这个名称会参与证书的CN或SAN校验。如果服务端证书CN写的modbus-server而代码里连的是IP地址校验就会失败。我后来在证书里加了IP地址的SAN扩展或者证书校验回调里关闭主机名校验。强调一下关闭主机名校验会降低安全性仅建议在完全可信的内网里使用。第四种是证书吊销检查超时。很多工控网络的DNS和HTTP出口是受限的checkCertificateRevocation设为true时会去查OCSP或CRL查询超时白白拖住握手。我在内网环境都设成false然后通过自定义X509Chain策略把信任控制权拿回手里。4.2 老设备不支持TLS怎么兼容现场有不少用了七八年的老PLC固件根本不支持TLS。这种情况不可能指望设备升级只能在它前面放一个安全网关或者协议转换器。网关一边用明文Modbus/TCP和PLC通信另一边用TLS加密通道和上位机通信PLC完全感知不到加密层的存在。网关要放在受控的隔离网络区和PLC之间用VLAN或防火墙限制访问避免攻击者直接物理接触到明文链路。另一个思路是在串口服务器上启用TLS透传。很多串口转以太网设备支持给TCP端口套一层TLS但这类产品往往只能做单向认证客户端证书的配置能力也弱。如果安全等级要求比较高优先考虑自研网关或者选择支持双向证书的工业防火墙。总之老设备兼容问题的核心是“在哪终结TLS”而不是“如何让老设备也学会TLS”。4.3 性能实测和优化建议我在本地环境做了一轮性能验证用Intel赛扬处理器当网关开启TLS后读取1000个寄存器单次请求的额外延迟大约在1毫秒到3毫秒之间整个握手过程一次约20毫秒左右。对大多数工艺设备的轮询场景来说这个开销完全可接受工业现场真正的瓶颈通常是网络带宽不足或PLC本身的Modbus处理速度。如果对延迟敏感优化方向有几个第一是优先用TLS 1.3它把握手精简到了单次往返。第二是选用ECC证书减少握手时的非对称运算时间。第三是保持长连接切断频繁握手的开销。第四是尽量把多个寄存器读取合并到一个请求里减少报文往返次数。上面的代码里已经体现了第3点和第4点实际效果非常明显。加密的CPU开销主要消耗在对称算法和哈希上现代工控机的CPU普遍支持AES指令集密钥交换的RSA运算也只出现在握手阶段。运行一段时间后如果发现CPU占用异常高先去查是不是有大量短连接在反复握手而不是一开始就怀疑TLS本身。4.4 项目落地时最容易忽略的维护细节安全方案上线只是第一步真正让运维头疼的是长期的证书管理。很多工业项目一做就是五六年证书过期、密钥丢失、人员变动、设备台账混乱这些问题比攻击者带来的威胁还要常见。我的建议是提前把证书有效期、签发对象、绑定设备信息写进资产台账每次巡检确认一遍别等着现场告警了才反应过来。另一个容易被忽略的点是日志审计。TLS和认证只是阻止了非法访问但合法操作者的误操作同样能造成生产事故。我在网关层会记录每个认证成功的连接来源、操作时间、功能码和寄存器地址范围日志只存摘要不存明文口令方便事后追溯。这个设计不花太多成本却能在出了问题后节省大量排查时间。最后再提一个细节不要在客户端代码里硬编码生产环境的证书密码。密码要放到独立的配置文件或者系统环境中用密钥管理服务来保护。我在调试时吃过亏把密码直接写进源码后来提交版本库时差点泄露出去。从那之后我就养成了习惯所有证书口令和认证凭据一律走环境变量或外置机密管理源码仓库里永远不出现真实密码。
