Security is not a post-launch patch. Four defensive layers for accounts, encryption in transit and at rest, the four compliance questions, and incident drills — organized around one principle: build it in.
安全投入的特点是：花的时候看不见回报，出事的时候全是回报的反面。包网平台涉及会员资产与个人数据，安全架构必须在设计阶段就进场。这篇按账号、加密、合规、应急四块拆。
传输层：TLS 全站覆盖，没有商量余地。证书自动续期（Let's Encrypt 加 certbot 就够），别让证书过期成为故障来源。
存储层：敏感字段（手机号、证件号）落库加密，密钥与数据分离存放——密钥在配置服务里，数据在库里，攻破数据库的人拿不到明文。展示层脱敏（138****5678），日志层屏蔽，备份同密级。保留期限写进策略，到期自动清理——「永久留存」是最常见的违规形态。
不构成法律意见，但技术侧准备材料时先回答这四个问题，法务的工作量能减一半：
第四问最容易被忽略，也最容易在检查时露馅。备份的删除策略要和主库一致，这需要在架构设计时就写清楚。
没演练过的预案等于没有预案。真实故障现场不是整理思路的地方，是执行肌肉记忆的地方。
接口层的验签与密钥轮换，是账号防线在系统边界的延伸，详见API对接指南。多可用区部署、密钥管理服务的容灾，属于架构议题，见高可用架构。数据跨境与多语言平台的关系，在多语言实务里讨论过。合规是上线检查的阻断项——这条原则也写进了周期拆解的测试阶段。
常被问到「安全上该花多少钱」。一个可参考的锚点：安全投入占搭建总预算的一到两成，低于一成的项目，大概率把钱省在了看不见的地方；高于两成，要么是合规要求特殊，要么是被供应商吓的。分配上建议倒着排：先保账号体系和数据加密（出事就是事故级），再补异常检测（对抗批量注册），最后才是渗透测试这类锦上添花。顺序反了，就是把钱花在了报告好看、防线漏风的组合上。
Security spending has an awkward profile: invisible when nothing happens, and its absence is the whole story when something does. A platform holding member assets and personal data cannot treat security as a post-launch course. This page covers four blocks: accounts, encryption, compliance and incident response.
In transit: TLS across the entire site. Not negotiable. Automate certificate renewal — an expired certificate should never be an outage cause.
At rest: sensitive fields (phone numbers, identity numbers) encrypted at write time, with keys stored separately from data — keys in a configuration service, data in the database, so someone who breaches the database holds no plaintext. Masking at the display layer (138****5678), suppression in logs, backups at the same classification. Retention periods belong in policy with automatic expiry — "keep forever" is the most common violation pattern there is.
This is not legal advice, but answering these four before the lawyers arrive halves their workload:
The fourth question is the most overlooked and the most exposed under inspection. Backup deletion must match primary-store policy, and that has to be designed in from the start.
An untested playbook is no playbook. A live incident is where you execute muscle memory, not where you organize your thoughts.
We are often asked what security "should" cost. One usable anchor: one to two tenths of the total build budget. Below one tenth, the money was almost certainly saved in places no one can see. Above two tenths, either the compliance regime is genuinely unusual or a vendor did an effective job of frightening someone. Within the budget, allocate in reverse order of glamour: accounts and encryption first (failures here are incident-grade), anomaly detection second (the fight against bulk registration), and penetration testing last, as polish. Reverse that order and you get reports that read well in front of a defense line with holes in it.
Signature verification and key rotation at the interface layer are the account defense extended to the system boundary — details in the API integration guide. Multi-zone deployment and key-management failover are architecture topics, covered in high availability. How cross-border data concerns multilingual platforms was discussed in the multilingual practice. And compliance is a blocking item in launch checks — a principle also written into the testing stage of the timeline breakdown.
Walk the four checklists in order — and bring the items you are unsure about.
Contact us