尧图网站建设 
住建部房地产数据安全监管房地产中介个人信息保护与售楼数据加密合规住建部房地产数据安全监管这件事正在从管交易延伸到管数据。过去中介门店和售楼处最在意的是成交与回款现在监管侧还会追到客户姓名与电话怎么存、人脸信息怎么处理、购房意向数据落到哪家系统、谁在什么时间导出了什么。某连锁房产经纪机构在一次行业检查中因为客户联系方式在多个门店系统里明文互传、无加密无脱敏被要求限期整改。坐标先立房地产场景的合规可以按采集—存储—使用—共享—删除五个环节来拆这是国内个人信息保护与数据安全相关法规的通用框架。房地产行业的特殊点在于它同时握有两类高风险数据一类是客户联系方式、家庭结构这类个人信息一类是房源交易与购房意向这类经营数据。本文切入的是最容易被做浅的一块住建部门关于房地产数据安全监管的口径怎么落到中介客户信息保护与售楼数据加密的可核查动作上。01 | 住建部房地产数据安全监管这件事难在哪儿住建部房地产数据安全监管的复杂度不在技术而在数据散、环节多、授权乱、留痕缺。具体难在下面五处。首要难点在客户信息多处明文留存。一个购房客户的信息往往同时躺在中介门店的 CRM、售楼处的来访登记、渠道的分销系统、经纪人的私人通讯录里很多时候还是明文手机号。监管追到个人信息保护这一项时企业拿不出谁在什么时候访问了哪个客户的什么字段的记录整改就卡住。其次人脸信息处理的合规水位参差不齐。不少售楼处和物业用摄像头做身份识别与客流分析但人脸属于敏感个人信息处理前要告知、要取得单独同意、要最小必要、要能证明没被滥用。很多场所只装了设备、没建处理规则监管问起来只有一句我们是为了安全。再有一处难点在售楼数据跨系统流转无管控。购房意向、认购、合同这些经营数据常在 CRM、ERP、渠道平台之间来回同步常常是全量导出、明文传输。监管侧关心的是这些数据有没有加密、有没有按系统分域、导出有没有审批与留痕。还有一处难点在权限与密钥各自为政。门店有门店的访问账号系统有系统的数据库账号加密密钥有的写进配置文件、有的根本没加密。这类授权乱、密钥散的局面让数据保密性和访问控制两项测评或检查都难以自证。最后一处难点在证据无法串联。采集做了告知、存储做了加密、使用做了审批但三件事用的是三套流程、三份台账监管来查时只能分别交材料拼不出一条这条客户数据从采集到删除全程可控的证据链。把这五处难点串起来看住建部房地产数据安全监管的核心矛盾是监管看的是数据全生命周期的闭环而企业交付的是孤岛式的安全动作。02 | 机制拆解住建部房地产数据安全监管的三条线先把三条线各自的职责划清楚再看它们怎么拼成证据链。线对应监管维度要解决的事典型手段缺了会怎样客户信息线个人信息保护·保密性中介客户的联系方式怎么存字段加密 脱敏展示 分域密钥手机号随备份泄露售楼数据线数据安全·保密性购房意向与合同数据怎么保护透明加密 按系统分域 导出审批经营数据全量裸传人脸处理线敏感个人信息·合法性人脸信息怎么合规处理告知同意 最小必要 去标识化被认定过度收集这三条线的边界要讲清楚客户信息线只解决个人信息存得安不安全不解决经营数据怎么流转售楼数据线只解决经营数据是否加密分域它依赖客户信息线给出的密钥与访问规则人脸处理线不直接参与交易但它决定采集动作本身是否合法。很多机构把这三件事分别交给 IT、合规、物业三个部门最后三份材料拼不出一条证据链。住建部房地产数据安全监管里的中介客户信息线中介客户信息线的落点是字段加密 脱敏展示 分域密钥。客户的姓名与手机号这类字段写入时自动加密、查询时按角色决定返回明文还是脱敏值加密所用的会话密钥由主密钥按门店 系统派生每个门店、每个系统各不相同。这样即使某一个系统的数据密钥泄露也解不开其他系统的数据。住建部房地产数据安全监管里的售楼数据线售楼数据线的落点是透明加密 按系统分域 导出审批。购房意向、认购与合同这类经营数据落库时自动加密业务不需要改代码数据按 CRM、ERP、渠道系统分别派生密钥彼此隔离任何导出动作都要审批并留痕。这一线让数据保密性从承诺变成可核查的事实。住建部房地产数据安全监管里的物业人脸线物业与人脸处理线的落点是先合规、再处理。物业人脸识别隐私合规是这条线的底线人脸属于敏感个人信息处理前要明确告知目的、取得单独同意、遵循最小必要、并证明未被超范围使用。它和智慧社区门禁身份认证怎么做是相邻但不同的问题——门禁的技术落点特征不出设备、本地比对在其它文章已专门拆解本文只从监管合规角度谈处理规则不重复技术实现。下面这张图说明三条线在一次客户到访与成交里的位置关系[客户到访] -- [采集告知与同意] -- [客户信息: 字段加密脱敏展示] | | | | 密钥: 按门店系统派生, 根密钥在HSM v v [售楼/中介系统] -- [经营数据透明加密] -- [导出审批访问日志签名] | | 人脸处理: 告知单独同意最小必要去标识化 v [审计: 采集-存储-使用-共享-删除 全链路留痕]03 | 先跑通住建部房地产数据安全监管的四个环节下面这段演示把三条线跑成一条完整链路先对中介客户的姓名与手机号做 SM4 字段加密落库、可还原、密文与明文不同再演示无密钥的普通角色解密被拒接着演示手机号在查询层做确定性脱敏然后演示售楼数据主密钥按门店 系统派生、不同门店派生密钥不同、主密钥轮换后派生值变化最后演示查询与导出日志逐条 SM2 签名被篡改的日志验签失败。# -*- coding: utf-8 -*- 账号3 Day3 #2 演示住建部房地产数据安全监管房地产中介个人信息保护 售楼数据加密 覆盖五件事 1) 客户敏感字段加密落库 —— 中介客户的姓名/电话用 SM4 加密可还原密文≠明文 2) 越权访问被拒 —— 无密钥的普通角色拿不到明文解密直接失败 3) 电话脱敏展示 —— 查询层对手机号做确定性脱敏展示为 138****8000 4) 售楼数据分域加密 —— 主密钥按「门店 系统」派生不同门店派生密钥不同 5) 访问日志完整性 —— 查询与导出日志逐条 SM2 签名被篡改的日志验签失败 演示用固定私钥且固定 K同一私钥同一K会泄露私钥仅演示用。 断言统一 print(f[{t}] {True if ok else False})全部为 True。 from gmssl import sm2, sm4, sm3, func # ---- 固定私钥已过 xxcsdn_keycheck.py 三关预检 ---- LOG_PRIV 6a3a91c46a3a91c46a3a91c46a3a91c46a3a91c46a3a91c46a3a91c46a3a91c4 # 审计/日志 FAKE_PRIV 5b8e27d05b8e27d05b8e27d05b8e27d05b8e27d05b8e27d05b8e27d05b8e27d0 # 冒名 FIXED_K 0101010101010101010101010101010101010101010101010101010101010101 def pub_of(priv: str) - str: P d * Ggmssl 不会从私钥派生公钥必须显式算出再传入 return sm2.CryptSM2(private_keypriv, public_key)._kg( int(priv, 16), sm2.default_ecc_table[g]) LOG_PUB pub_of(LOG_PRIV) FAKE_PUB pub_of(FAKE_PRIV) def sm3_hex(data: bytes) - str: return sm3.sm3_hash(func.bytes_to_list(data)) # ---- 手写 SM4-CBC ---- def sm4_cbc(key: bytes, iv: bytes, data: bytes, enc: bool) - bytes: assert len(key) 16 and len(iv) 16, SM4 KEY / IV 必须 16 字节 c sm4.CryptSM4() c.set_key(key, sm4.SM4_ENCRYPT if enc else sm4.SM4_DECRYPT) out, prev b, iv for i in range(0, len(data), 16): blk data[i:i 16] if enc: x bytes(a ^ b for a, b in zip(blk, prev)) e bytes(c.one_round(c.sk, list(x))) out e prev e else: d bytes(c.one_round(c.sk, list(blk))) out bytes(a ^ b for a, b in zip(d, prev)) prev blk return out def pkcs7_pad(data: bytes, block: int 16) - bytes: pad block - (len(data) % block) return data bytes([pad]) * pad def pkcs7_unpad(data: bytes) - bytes: pad data[-1] if not (1 pad 16): return data return data[:-pad] def decrypt_or_none(key: bytes, iv: bytes, ct: bytes): try: return pkcs7_unpad(sm4_cbc(key, iv, ct, False)) except Exception: # noqa: BLE001 return None def mask_phone(phone: str) - str: return phone[:3] **** phone[-4:] # 1) 客户敏感字段加密落库 CUST_KEY b16BYTEKEYFORCRM0 # 字段级加密密钥由密钥管理平台下发 IV bSM4IVREALESTATE0 cust (客户信息:name张敏|phone13800138000|intent三居室).encode(utf-8) ct_cust sm4_cbc(CUST_KEY, IV, pkcs7_pad(cust), True) ok_cust_enc decrypt_or_none(CUST_KEY, IV, ct_cust) cust ok_cust_ct_diff ct_cust ! cust # 越权角色拿不到字段密钥解密失败 WRONG_KEY b16BYTEKEYFORGUEST ok_unauth decrypt_or_none(WRONG_KEY, IV, ct_cust) ! cust # 电话脱敏展示 ok_mask mask_phone(13800138000) 138****8000 # 2) 售楼数据分域加密主密钥按「门店 系统」派生 MASTER bREAL-ESTATE-KEY-MASTER-2609 k_storeA sm3_hex(MASTER b|storeA01|sysSALE-CRM) k_storeB sm3_hex(MASTER b|storeB02|sysSALE-CRM) ok_k_len len(k_storeA) 64 ok_k_diff k_storeA ! k_storeB ok_k_det k_storeA sm3_hex(MASTER b|storeA01|sysSALE-CRM) ok_k_rotate k_storeA ! sm3_hex(bREAL-ESTATE-KEY-MASTER-2610 b|storeA01|sysSALE-CRM) SALE_KEY bytes.fromhex(k_storeA[:32]) sale (购房意向:clientCMA260928|area89.6|price5200000).encode(utf-8) ct_sale sm4_cbc(SALE_KEY, IV, pkcs7_pad(sale), True) ok_sale_enc decrypt_or_none(SALE_KEY, IV, ct_sale) sale ok_sale_ct_diff ct_sale ! sale # 3) 访问日志完整性查询/导出日志逐条签名 log LOG|SALE-CRM|2026-09-28T10:31:05|export:clientCMA260928 h_log sm3_hex(log.encode(utf-8)) log_signer sm2.CryptSM2(public_keyLOG_PUB, private_keyLOG_PRIV) log_sig log_signer.sign(h_log.encode(utf-8), FIXED_K) ok_log_sign log_signer.verify(log_sig, h_log.encode(utf-8)) ok_log_tamper not log_signer.verify( log_sig, sm3_hex((log |export:ALL).encode(utf-8)).encode(utf-8)) asserts [ (客户敏感字段加密可还原, ok_cust_enc), (密文与明文不同, ok_cust_ct_diff), (越权角色解密被拒绝, ok_unauth), (电话脱敏展示正确, ok_mask), (门店派生密钥64位, ok_k_len), (不同门店派生密钥不同, ok_k_diff), (同一因子派生可复现, ok_k_det), (主密钥轮换后派生变化, ok_k_rotate), (售楼数据加密可还原, ok_sale_enc), (售楼密文与明文不同, ok_sale_ct_diff), (访问日志签名验签通过, ok_log_sign), (被篡改日志验签被拒, ok_log_tamper), (签名为hex字符串, isinstance(log_sig, str)), (密文为bytes, isinstance(ct_cust, bytes)), ] print( * 60) for t, ok in asserts: print(f[{t}] {True if ok else False}) [客户敏感字段加密可还原] True [密文与明文不同] True [越权角色解密被拒绝] True [电话脱敏展示正确] True [门店派生密钥64位] True [不同门店派生密钥不同] True [同一因子派生可复现] True [主密钥轮换后派生变化] True [售楼数据加密可还原] True [售楼密文与明文不同] True [访问日志签名验签通过] True [被篡改日志验签被拒] True [签名为hex字符串] True [密文为bytes] True跑通之后这四个环节要逐个对上环节一客户敏感字段必须加密落库。演示里姓名与手机号用字段密钥做 SM4 加密后落库读取时再还原明文业务侧不需要改代码。透明加密的好处是不打断成交节奏坏处是要保证密钥管理与根密钥保护到位——根密钥必须在硬件密码机里永不明文导出。这一条对应个人信息保密性这一监管项。环节二越权角色拿不到明文。演示里无密钥的普通角色尝试解密直接失败。这一条对应访问控制客户字段密钥只下发给授权服务普通查询角色、运维角色、第三方渠道都拿不到即使拿到库文件也解不开。这是房地产中介个人信息保护能自证的关键。环节三展示层要做确定性脱敏。演示里手机号在查询层被处理成138****8000展示与统计用脱敏值只有授权场景才返回明文。这一条对应最小必要原则——对外呼、对报表、对第三方默认给脱敏值而不是明文。环节四导出与访问要带签名留痕。演示里查询与导出日志逐条做 SM2 签名被篡改的内容验签直接失败。这一条让使用和共享两个环节从承诺变成可核查的事实监管事后调日志任何改动都骗不过验签。这四个环节里最容易被低估的是环节二和环节四——它们都属于平时看不出问题、出事时才发现没做的类型。04 | 落地动作住建部房地产数据安全监管分线怎么做要落到可执行建议按三条线推进每条线都有明确的交付物。线一客户信息治理。梳理所有持有客户联系方式的系统与副本给 CRM、来访登记、渠道分销统一接入字段加密与脱敏能力明确哪些角色可见明文、哪些只可见脱敏值并写进访问控制规范。这条线的交付物是客户字段加密清单与脱敏展示规则。线二售楼数据治理。给购房意向、认购、合同这类经营数据做透明加密落库密钥按门店 系统或系统 日期派生根密钥托管在硬件密码机建立导出审批与访问日志签名机制。这条线要特别注意门店侧、系统侧、渠道侧的密钥应当共用同一套主密钥与派生规则否则密钥数量随系统数量线性膨胀轮换时必然漏换。交付物是密钥分域清单与导出审批记录。线三物业人脸识别隐私合规。对物业与售楼处的人脸采集做告知与单独同意、限制用途与留存期限、做去标识化或加密存储明确哪些场景是人脸的合法用途、哪些应当保留非人脸的替代方式。这条线把人脸这一敏感个人信息从装了就用变成依法处理交付物是物业人脸识别隐私合规的处理规则与同意记录。想知道智慧社区门禁身份认证怎么做门禁侧技术落点可以看我们另一篇专门拆解门禁的文章本文只谈监管合规口径。三条线推进有先后线一是线二的前提没有字段加密与脱敏口径就无法定义售楼数据的保护边界线三独立于前两条但要用同一套留痕口径否则证据链在共享环节断裂。建议先把线一与线二做成闭环再把线三补齐。一个可参照的整改样本背景某房产经纪机构旗下三十余家门店客户手机号在 CRM、门店登记表、经纪人私人通讯录里明文共存无加密无脱敏购房意向数据在渠道平台间全量明文导出。一次行业检查指出其个人信息保护与数据安全两项均不达标。动作先给各系统的客户字段接入字段加密与脱敏展示密钥由主密钥按门店 系统派生根密钥放入硬件密码机把购房意向与合同数据改为透明加密落库任何导出走审批并写签名日志对门店的人脸采集补做告知与单独同意限制用途与留存期限。结果整改后的一次抽查中用普通查询角色尝试解密客户字段被直接拒绝一条未审批的全量导出被访问日志发现并告警监管复查时个人信息保护与数据安全两项原本不达标的问题全部补齐证据链从我们分别做了变成我们能逐条还原。05 | 避坑清单8 条最容易踩的坑#坑后果怎么验证避开了1客户手机号明文多系统共存一处泄露全线泄露抽查各系统与备份确认手机号字段为密文或脱敏值2经纪人居私通讯录存客户信息脱离企业管控无法追溯检查是否有客户信息不出企业系统的硬约束3人脸采集无告知无同意涉嫌过度收集敏感个人信息抽查采集点是否有告知与单独同意记录4人脸特征明文出设备生物特征泄露不可逆确认特征值存储于采集设备内、不外传5售楼数据全量明文导出经营数据随渠道泄露抽查导出记录是否加密、是否审批留痕6一个密钥多用单点泄露连带全部门店检查密钥派生因子是否含门店与系统标识7根密钥明文导出根一失全部派生值失效确认根密钥仅存于硬件密码机无明文副本8访问与导出无签名日志事后无法追溯谁导出了什么改一条历史日志看是否通过完整性校验挑第 1 条展开说。客户手机号在多个系统明文共存这件事在很多中介门店被视为方便联系客户的常态。问题在于房地产中介个人信息保护的合规要求恰恰把联系方式列为敏感个人信息重点保护对象。明文在多系统互传意味着任何一次备份泄露、任何一台终端失陷都会暴露一批真实客户。把手机号改为字段加密、在查询层脱敏成138****8000成本只是接入一套加密与脱敏能力收益是把个人信息保密性这一监管项从承诺变成可核查的事实。06 | 合规视角住建部房地产数据安全监管要对上哪些要求房地产机构在数据治理上通常同时面对几条线的要求而这些要求的最终落点都在可提交的证据上。个人信息保护相关法规。关注敏感个人信息的处理规则告知、单独同意、最小必要、去标识化或加密。客户的联系方式、家庭结构、人脸特征都属于个人信息其中人脸属于敏感个人信息处理前要有明确目的与单独同意。房地产中介个人信息保护的口径要写进企业的处理规则与采集动作一一对应物业人脸识别隐私合规同样要落到处理规则里让采集、告知、同意、留存四件事可查。至于智慧社区门禁身份认证怎么做这类设备侧问题属于技术实现范畴不在本文合规口径内。数据安全相关法规。关注分类分级与全生命周期保护。购房意向、认购、合同这类经营数据需要在分类分级的基础上落实加密、访问控制、导出审批与审计。住建部房地产数据安全监管的落地要求企业把哪些数据重要、怎么保护、谁动过这三件事讲清楚。住建部门关于房地产经纪与住房租赁的规范管理。行业监管要求强调经纪机构规范采集与使用客户信息、保障交易数据安全。这条线的落点不是某一份文号而是把客户信息保护与售楼数据加密纳入日常经营流程让检查来时不是临时补材料而是日常就有闭环。密码应用基本要求。关注身份鉴别、访问控制、数据完整性、数据保密性四个层面的密码技术应用。前面三条线落到密码上就是字段加密、透明加密、日志签名。监管追问的是用什么算法、密钥在哪里生成与存放、多久轮换一次——客户字段与售楼数据的加密动作必须写进密码应用方案作为证据链的一环。这里的实用建议是不要把这些要求当成几份独立清单分别应对而是建一张映射表把每条要求映射到字段加密、脱敏展示、分域密钥、导出审批、日志签名这五个动作上。一次建设几份清单同时受益。07 | 落地答案住建部房地产数据安全监管怎么承接住建部房地产数据安全监管落到产品能力上通常这样组合三条线与证据链。客户信息线这一段需要的能力是字段级加密 脱敏展示 分域密钥。数据库透明加密解决客户字段落盘这一层敏感列写入时自动加密、读取时自动解密业务 SQL 不用改密钥管理平台承担主密钥保护、按门店或系统派生数据密钥、版本化轮换与历史解密支持让房地产中介个人信息保护里的密钥分域和日常轮换共用同一套治理。根密钥始终在硬件密码机内永不明文导出。售楼数据线这一段需要的能力是透明加密 按系统分域 导出审批与审计。透明加密解决购房意向与合同数据落盘这一层对生产节拍无感密钥管理平台按门店或系统派生彼此隔离访问与导出动作由统一身份认证平台做权限控制与日志签名形成可核查的留痕。人脸处理线这一段需要的能力是告知同意 最小必要 去标识化存储落点就是物业人脸识别隐私合规。处理规则由合规侧定义技术侧只承接特征不出采集设备、本地比对、外传只带签名过的事件这类能力并把同意记录与用途限制落到可查询的台账里。三段能力的组合正好覆盖个人信息保护、数据安全、密码应用三条监管线也直接对应了 06 节里那几份清单的核查项。智慧社区门禁身份认证怎么做门禁侧技术落点不在本文范围但门禁的合规处理规则与本文人脸线一致。08 | 验收清单与下一步上线前建议逐项过一遍这张表#验收项通过标准1客户字段加密清单手机号等敏感列落库为密文2脱敏展示规则对外呼/报表/第三方默认返回脱敏值3越权解密验证普通角色解密客户字段被拒绝4密钥分域清单门店/系统密钥按统一规则派生5根密钥保护根密钥仅在硬件密码机内无明文副本6派生可复现同因子派生一致、不同门店派生不同7售楼数据加密购房意向/合同落库为密文8导出审批记录全量导出均有审批与留痕9日志签名入库改动历史日志被完整性校验发现10人脸告知同意采集点均有告知与单独同意记录11人脸去标识化特征值不出采集设备、不外传12留存期限规则人脸与个人信息有明确最短必要期限13证据链串联采集-存储-使用-共享-删除可逐条还原14客户信息不出私域经纪人私人通讯录无明文客户信息15监管项映射表每条要求映射到五个落地动作趋势上看这项监管的重心正在从规范交易行为往管控数据全生命周期迁移。过去只要合同签得规范就算合规现在的检查会追到单个客户的手机号是否加密、单条购房意向的导出是否审批、单张人脸的同意是否可追溯。这个迁移对架构的实质要求是客户信息、售楼数据、人脸处理三件事不能再各自为政它们必须共享同一套字段加密口径、同一套密钥分域规则、同一条审计留痕。下一篇预告我们接着拆教育科研侧的同一件事高校核心系统密评看教务、一卡通、科研、图书馆这些核心系统怎么在密码应用安全性评估的框架下一体化合规和房地产数据全生命周期的做法有哪些相通、又有哪些根本不同。09 | 常见问题住建部房地产数据安全监管的 4 个高频疑问Q: 住建部房地产数据安全监管整改一般要多久A: 周期主要取决于系统改造量不是门店数量本身。只做客户字段加密与脱敏展示这类轻改造两到四个月可以补齐多数检查项涉及售楼数据透明加密、密钥体系重建与导出审批的往往要五到八个月。真正拉长周期的是客户信息治理把多系统明文共存的手机号收敛到加密与脱敏闭环一般要两到三个月。Q: 房地产中介个人信息保护怎么做才算到位A: 判断标准是看客户联系方式是否加密并分域保护而不是看有没有采集告知。手机号等敏感字段应写入即加密、查询时按角色返回明文或脱敏值字段密钥由主密钥按门店与系统派生根密钥放入硬件密码机普通角色与运维角色拿不到密钥即使取得库文件也解不开明文。Q: 售楼数据加密要怎么做才不影响成交效率A: 优先选驱动层透明加密写入即加密、读取即解密对业务 SQL 与成交流程透明不需要改应用代码。只对购房意向、合同这类高敏感字段开启加密普通业务字段保持明文配合硬件加速对成交与查询效率的影响通常控制在个位数百分比以内。Q: 物业人脸识别要怎么做才合规不踩红线A: 核心是先合规、再处理。人脸属于敏感个人信息采集前要明确告知目的、取得单独同意、遵循最小必要、并限制用途与留存期限特征值应存储于采集设备内、不得外传。存在其他非人脸识别方式的不得作为排他性的验证方式。合规侧的规则要落到可查询的同意台账里。智慧社区门禁身份认证怎么做另有专文本文只答合规侧问题。相关阅读智慧社区门禁身份认证的访客凭证管控POS终端加密安全防护的支付数据加密全链路PCI DSS v4.0电商合规的支付卡数据加密要求文章作者:安当加密-焱垚 住建部房地产数据安全监管：房地产中介个人信息保护与售楼数据加密合规
住建部房地产数据安全监管房地产中介个人信息保护与售楼数据加密合规住建部房地产数据安全监管这件事正在从管交易延伸到管数据。过去中介门店和售楼处最在意的是成交与回款现在监管侧还会追到客户姓名与电话怎么存、人脸信息怎么处理、购房意向数据落到哪家系统、谁在什么时间导出了什么。某连锁房产经纪机构在一次行业检查中因为客户联系方式在多个门店系统里明文互传、无加密无脱敏被要求限期整改。坐标先立房地产场景的合规可以按采集—存储—使用—共享—删除五个环节来拆这是国内个人信息保护与数据安全相关法规的通用框架。房地产行业的特殊点在于它同时握有两类高风险数据一类是客户联系方式、家庭结构这类个人信息一类是房源交易与购房意向这类经营数据。本文切入的是最容易被做浅的一块住建部门关于房地产数据安全监管的口径怎么落到中介客户信息保护与售楼数据加密的可核查动作上。01 | 住建部房地产数据安全监管这件事难在哪儿住建部房地产数据安全监管的复杂度不在技术而在数据散、环节多、授权乱、留痕缺。具体难在下面五处。首要难点在客户信息多处明文留存。一个购房客户的信息往往同时躺在中介门店的 CRM、售楼处的来访登记、渠道的分销系统、经纪人的私人通讯录里很多时候还是明文手机号。监管追到个人信息保护这一项时企业拿不出谁在什么时候访问了哪个客户的什么字段的记录整改就卡住。其次人脸信息处理的合规水位参差不齐。不少售楼处和物业用摄像头做身份识别与客流分析但人脸属于敏感个人信息处理前要告知、要取得单独同意、要最小必要、要能证明没被滥用。很多场所只装了设备、没建处理规则监管问起来只有一句我们是为了安全。再有一处难点在售楼数据跨系统流转无管控。购房意向、认购、合同这些经营数据常在 CRM、ERP、渠道平台之间来回同步常常是全量导出、明文传输。监管侧关心的是这些数据有没有加密、有没有按系统分域、导出有没有审批与留痕。还有一处难点在权限与密钥各自为政。门店有门店的访问账号系统有系统的数据库账号加密密钥有的写进配置文件、有的根本没加密。这类授权乱、密钥散的局面让数据保密性和访问控制两项测评或检查都难以自证。最后一处难点在证据无法串联。采集做了告知、存储做了加密、使用做了审批但三件事用的是三套流程、三份台账监管来查时只能分别交材料拼不出一条这条客户数据从采集到删除全程可控的证据链。把这五处难点串起来看住建部房地产数据安全监管的核心矛盾是监管看的是数据全生命周期的闭环而企业交付的是孤岛式的安全动作。02 | 机制拆解住建部房地产数据安全监管的三条线先把三条线各自的职责划清楚再看它们怎么拼成证据链。线对应监管维度要解决的事典型手段缺了会怎样客户信息线个人信息保护·保密性中介客户的联系方式怎么存字段加密 脱敏展示 分域密钥手机号随备份泄露售楼数据线数据安全·保密性购房意向与合同数据怎么保护透明加密 按系统分域 导出审批经营数据全量裸传人脸处理线敏感个人信息·合法性人脸信息怎么合规处理告知同意 最小必要 去标识化被认定过度收集这三条线的边界要讲清楚客户信息线只解决个人信息存得安不安全不解决经营数据怎么流转售楼数据线只解决经营数据是否加密分域它依赖客户信息线给出的密钥与访问规则人脸处理线不直接参与交易但它决定采集动作本身是否合法。很多机构把这三件事分别交给 IT、合规、物业三个部门最后三份材料拼不出一条证据链。住建部房地产数据安全监管里的中介客户信息线中介客户信息线的落点是字段加密 脱敏展示 分域密钥。客户的姓名与手机号这类字段写入时自动加密、查询时按角色决定返回明文还是脱敏值加密所用的会话密钥由主密钥按门店 系统派生每个门店、每个系统各不相同。这样即使某一个系统的数据密钥泄露也解不开其他系统的数据。住建部房地产数据安全监管里的售楼数据线售楼数据线的落点是透明加密 按系统分域 导出审批。购房意向、认购与合同这类经营数据落库时自动加密业务不需要改代码数据按 CRM、ERP、渠道系统分别派生密钥彼此隔离任何导出动作都要审批并留痕。这一线让数据保密性从承诺变成可核查的事实。住建部房地产数据安全监管里的物业人脸线物业与人脸处理线的落点是先合规、再处理。物业人脸识别隐私合规是这条线的底线人脸属于敏感个人信息处理前要明确告知目的、取得单独同意、遵循最小必要、并证明未被超范围使用。它和智慧社区门禁身份认证怎么做是相邻但不同的问题——门禁的技术落点特征不出设备、本地比对在其它文章已专门拆解本文只从监管合规角度谈处理规则不重复技术实现。下面这张图说明三条线在一次客户到访与成交里的位置关系[客户到访] -- [采集告知与同意] -- [客户信息: 字段加密脱敏展示] | | | | 密钥: 按门店系统派生, 根密钥在HSM v v [售楼/中介系统] -- [经营数据透明加密] -- [导出审批访问日志签名] | | 人脸处理: 告知单独同意最小必要去标识化 v [审计: 采集-存储-使用-共享-删除 全链路留痕]03 | 先跑通住建部房地产数据安全监管的四个环节下面这段演示把三条线跑成一条完整链路先对中介客户的姓名与手机号做 SM4 字段加密落库、可还原、密文与明文不同再演示无密钥的普通角色解密被拒接着演示手机号在查询层做确定性脱敏然后演示售楼数据主密钥按门店 系统派生、不同门店派生密钥不同、主密钥轮换后派生值变化最后演示查询与导出日志逐条 SM2 签名被篡改的日志验签失败。# -*- coding: utf-8 -*- 账号3 Day3 #2 演示住建部房地产数据安全监管房地产中介个人信息保护 售楼数据加密 覆盖五件事 1) 客户敏感字段加密落库 —— 中介客户的姓名/电话用 SM4 加密可还原密文≠明文 2) 越权访问被拒 —— 无密钥的普通角色拿不到明文解密直接失败 3) 电话脱敏展示 —— 查询层对手机号做确定性脱敏展示为 138****8000 4) 售楼数据分域加密 —— 主密钥按「门店 系统」派生不同门店派生密钥不同 5) 访问日志完整性 —— 查询与导出日志逐条 SM2 签名被篡改的日志验签失败 演示用固定私钥且固定 K同一私钥同一K会泄露私钥仅演示用。 断言统一 print(f[{t}] {True if ok else False})全部为 True。 from gmssl import sm2, sm4, sm3, func # ---- 固定私钥已过 xxcsdn_keycheck.py 三关预检 ---- LOG_PRIV 6a3a91c46a3a91c46a3a91c46a3a91c46a3a91c46a3a91c46a3a91c46a3a91c4 # 审计/日志 FAKE_PRIV 5b8e27d05b8e27d05b8e27d05b8e27d05b8e27d05b8e27d05b8e27d05b8e27d0 # 冒名 FIXED_K 0101010101010101010101010101010101010101010101010101010101010101 def pub_of(priv: str) - str: P d * Ggmssl 不会从私钥派生公钥必须显式算出再传入 return sm2.CryptSM2(private_keypriv, public_key)._kg( int(priv, 16), sm2.default_ecc_table[g]) LOG_PUB pub_of(LOG_PRIV) FAKE_PUB pub_of(FAKE_PRIV) def sm3_hex(data: bytes) - str: return sm3.sm3_hash(func.bytes_to_list(data)) # ---- 手写 SM4-CBC ---- def sm4_cbc(key: bytes, iv: bytes, data: bytes, enc: bool) - bytes: assert len(key) 16 and len(iv) 16, SM4 KEY / IV 必须 16 字节 c sm4.CryptSM4() c.set_key(key, sm4.SM4_ENCRYPT if enc else sm4.SM4_DECRYPT) out, prev b, iv for i in range(0, len(data), 16): blk data[i:i 16] if enc: x bytes(a ^ b for a, b in zip(blk, prev)) e bytes(c.one_round(c.sk, list(x))) out e prev e else: d bytes(c.one_round(c.sk, list(blk))) out bytes(a ^ b for a, b in zip(d, prev)) prev blk return out def pkcs7_pad(data: bytes, block: int 16) - bytes: pad block - (len(data) % block) return data bytes([pad]) * pad def pkcs7_unpad(data: bytes) - bytes: pad data[-1] if not (1 pad 16): return data return data[:-pad] def decrypt_or_none(key: bytes, iv: bytes, ct: bytes): try: return pkcs7_unpad(sm4_cbc(key, iv, ct, False)) except Exception: # noqa: BLE001 return None def mask_phone(phone: str) - str: return phone[:3] **** phone[-4:] # 1) 客户敏感字段加密落库 CUST_KEY b16BYTEKEYFORCRM0 # 字段级加密密钥由密钥管理平台下发 IV bSM4IVREALESTATE0 cust (客户信息:name张敏|phone13800138000|intent三居室).encode(utf-8) ct_cust sm4_cbc(CUST_KEY, IV, pkcs7_pad(cust), True) ok_cust_enc decrypt_or_none(CUST_KEY, IV, ct_cust) cust ok_cust_ct_diff ct_cust ! cust # 越权角色拿不到字段密钥解密失败 WRONG_KEY b16BYTEKEYFORGUEST ok_unauth decrypt_or_none(WRONG_KEY, IV, ct_cust) ! cust # 电话脱敏展示 ok_mask mask_phone(13800138000) 138****8000 # 2) 售楼数据分域加密主密钥按「门店 系统」派生 MASTER bREAL-ESTATE-KEY-MASTER-2609 k_storeA sm3_hex(MASTER b|storeA01|sysSALE-CRM) k_storeB sm3_hex(MASTER b|storeB02|sysSALE-CRM) ok_k_len len(k_storeA) 64 ok_k_diff k_storeA ! k_storeB ok_k_det k_storeA sm3_hex(MASTER b|storeA01|sysSALE-CRM) ok_k_rotate k_storeA ! sm3_hex(bREAL-ESTATE-KEY-MASTER-2610 b|storeA01|sysSALE-CRM) SALE_KEY bytes.fromhex(k_storeA[:32]) sale (购房意向:clientCMA260928|area89.6|price5200000).encode(utf-8) ct_sale sm4_cbc(SALE_KEY, IV, pkcs7_pad(sale), True) ok_sale_enc decrypt_or_none(SALE_KEY, IV, ct_sale) sale ok_sale_ct_diff ct_sale ! sale # 3) 访问日志完整性查询/导出日志逐条签名 log LOG|SALE-CRM|2026-09-28T10:31:05|export:clientCMA260928 h_log sm3_hex(log.encode(utf-8)) log_signer sm2.CryptSM2(public_keyLOG_PUB, private_keyLOG_PRIV) log_sig log_signer.sign(h_log.encode(utf-8), FIXED_K) ok_log_sign log_signer.verify(log_sig, h_log.encode(utf-8)) ok_log_tamper not log_signer.verify( log_sig, sm3_hex((log |export:ALL).encode(utf-8)).encode(utf-8)) asserts [ (客户敏感字段加密可还原, ok_cust_enc), (密文与明文不同, ok_cust_ct_diff), (越权角色解密被拒绝, ok_unauth), (电话脱敏展示正确, ok_mask), (门店派生密钥64位, ok_k_len), (不同门店派生密钥不同, ok_k_diff), (同一因子派生可复现, ok_k_det), (主密钥轮换后派生变化, ok_k_rotate), (售楼数据加密可还原, ok_sale_enc), (售楼密文与明文不同, ok_sale_ct_diff), (访问日志签名验签通过, ok_log_sign), (被篡改日志验签被拒, ok_log_tamper), (签名为hex字符串, isinstance(log_sig, str)), (密文为bytes, isinstance(ct_cust, bytes)), ] print( * 60) for t, ok in asserts: print(f[{t}] {True if ok else False}) [客户敏感字段加密可还原] True [密文与明文不同] True [越权角色解密被拒绝] True [电话脱敏展示正确] True [门店派生密钥64位] True [不同门店派生密钥不同] True [同一因子派生可复现] True [主密钥轮换后派生变化] True [售楼数据加密可还原] True [售楼密文与明文不同] True [访问日志签名验签通过] True [被篡改日志验签被拒] True [签名为hex字符串] True [密文为bytes] True跑通之后这四个环节要逐个对上环节一客户敏感字段必须加密落库。演示里姓名与手机号用字段密钥做 SM4 加密后落库读取时再还原明文业务侧不需要改代码。透明加密的好处是不打断成交节奏坏处是要保证密钥管理与根密钥保护到位——根密钥必须在硬件密码机里永不明文导出。这一条对应个人信息保密性这一监管项。环节二越权角色拿不到明文。演示里无密钥的普通角色尝试解密直接失败。这一条对应访问控制客户字段密钥只下发给授权服务普通查询角色、运维角色、第三方渠道都拿不到即使拿到库文件也解不开。这是房地产中介个人信息保护能自证的关键。环节三展示层要做确定性脱敏。演示里手机号在查询层被处理成138****8000展示与统计用脱敏值只有授权场景才返回明文。这一条对应最小必要原则——对外呼、对报表、对第三方默认给脱敏值而不是明文。环节四导出与访问要带签名留痕。演示里查询与导出日志逐条做 SM2 签名被篡改的内容验签直接失败。这一条让使用和共享两个环节从承诺变成可核查的事实监管事后调日志任何改动都骗不过验签。这四个环节里最容易被低估的是环节二和环节四——它们都属于平时看不出问题、出事时才发现没做的类型。04 | 落地动作住建部房地产数据安全监管分线怎么做要落到可执行建议按三条线推进每条线都有明确的交付物。线一客户信息治理。梳理所有持有客户联系方式的系统与副本给 CRM、来访登记、渠道分销统一接入字段加密与脱敏能力明确哪些角色可见明文、哪些只可见脱敏值并写进访问控制规范。这条线的交付物是客户字段加密清单与脱敏展示规则。线二售楼数据治理。给购房意向、认购、合同这类经营数据做透明加密落库密钥按门店 系统或系统 日期派生根密钥托管在硬件密码机建立导出审批与访问日志签名机制。这条线要特别注意门店侧、系统侧、渠道侧的密钥应当共用同一套主密钥与派生规则否则密钥数量随系统数量线性膨胀轮换时必然漏换。交付物是密钥分域清单与导出审批记录。线三物业人脸识别隐私合规。对物业与售楼处的人脸采集做告知与单独同意、限制用途与留存期限、做去标识化或加密存储明确哪些场景是人脸的合法用途、哪些应当保留非人脸的替代方式。这条线把人脸这一敏感个人信息从装了就用变成依法处理交付物是物业人脸识别隐私合规的处理规则与同意记录。想知道智慧社区门禁身份认证怎么做门禁侧技术落点可以看我们另一篇专门拆解门禁的文章本文只谈监管合规口径。三条线推进有先后线一是线二的前提没有字段加密与脱敏口径就无法定义售楼数据的保护边界线三独立于前两条但要用同一套留痕口径否则证据链在共享环节断裂。建议先把线一与线二做成闭环再把线三补齐。一个可参照的整改样本背景某房产经纪机构旗下三十余家门店客户手机号在 CRM、门店登记表、经纪人私人通讯录里明文共存无加密无脱敏购房意向数据在渠道平台间全量明文导出。一次行业检查指出其个人信息保护与数据安全两项均不达标。动作先给各系统的客户字段接入字段加密与脱敏展示密钥由主密钥按门店 系统派生根密钥放入硬件密码机把购房意向与合同数据改为透明加密落库任何导出走审批并写签名日志对门店的人脸采集补做告知与单独同意限制用途与留存期限。结果整改后的一次抽查中用普通查询角色尝试解密客户字段被直接拒绝一条未审批的全量导出被访问日志发现并告警监管复查时个人信息保护与数据安全两项原本不达标的问题全部补齐证据链从我们分别做了变成我们能逐条还原。05 | 避坑清单8 条最容易踩的坑#坑后果怎么验证避开了1客户手机号明文多系统共存一处泄露全线泄露抽查各系统与备份确认手机号字段为密文或脱敏值2经纪人居私通讯录存客户信息脱离企业管控无法追溯检查是否有客户信息不出企业系统的硬约束3人脸采集无告知无同意涉嫌过度收集敏感个人信息抽查采集点是否有告知与单独同意记录4人脸特征明文出设备生物特征泄露不可逆确认特征值存储于采集设备内、不外传5售楼数据全量明文导出经营数据随渠道泄露抽查导出记录是否加密、是否审批留痕6一个密钥多用单点泄露连带全部门店检查密钥派生因子是否含门店与系统标识7根密钥明文导出根一失全部派生值失效确认根密钥仅存于硬件密码机无明文副本8访问与导出无签名日志事后无法追溯谁导出了什么改一条历史日志看是否通过完整性校验挑第 1 条展开说。客户手机号在多个系统明文共存这件事在很多中介门店被视为方便联系客户的常态。问题在于房地产中介个人信息保护的合规要求恰恰把联系方式列为敏感个人信息重点保护对象。明文在多系统互传意味着任何一次备份泄露、任何一台终端失陷都会暴露一批真实客户。把手机号改为字段加密、在查询层脱敏成138****8000成本只是接入一套加密与脱敏能力收益是把个人信息保密性这一监管项从承诺变成可核查的事实。06 | 合规视角住建部房地产数据安全监管要对上哪些要求房地产机构在数据治理上通常同时面对几条线的要求而这些要求的最终落点都在可提交的证据上。个人信息保护相关法规。关注敏感个人信息的处理规则告知、单独同意、最小必要、去标识化或加密。客户的联系方式、家庭结构、人脸特征都属于个人信息其中人脸属于敏感个人信息处理前要有明确目的与单独同意。房地产中介个人信息保护的口径要写进企业的处理规则与采集动作一一对应物业人脸识别隐私合规同样要落到处理规则里让采集、告知、同意、留存四件事可查。至于智慧社区门禁身份认证怎么做这类设备侧问题属于技术实现范畴不在本文合规口径内。数据安全相关法规。关注分类分级与全生命周期保护。购房意向、认购、合同这类经营数据需要在分类分级的基础上落实加密、访问控制、导出审批与审计。住建部房地产数据安全监管的落地要求企业把哪些数据重要、怎么保护、谁动过这三件事讲清楚。住建部门关于房地产经纪与住房租赁的规范管理。行业监管要求强调经纪机构规范采集与使用客户信息、保障交易数据安全。这条线的落点不是某一份文号而是把客户信息保护与售楼数据加密纳入日常经营流程让检查来时不是临时补材料而是日常就有闭环。密码应用基本要求。关注身份鉴别、访问控制、数据完整性、数据保密性四个层面的密码技术应用。前面三条线落到密码上就是字段加密、透明加密、日志签名。监管追问的是用什么算法、密钥在哪里生成与存放、多久轮换一次——客户字段与售楼数据的加密动作必须写进密码应用方案作为证据链的一环。这里的实用建议是不要把这些要求当成几份独立清单分别应对而是建一张映射表把每条要求映射到字段加密、脱敏展示、分域密钥、导出审批、日志签名这五个动作上。一次建设几份清单同时受益。07 | 落地答案住建部房地产数据安全监管怎么承接住建部房地产数据安全监管落到产品能力上通常这样组合三条线与证据链。客户信息线这一段需要的能力是字段级加密 脱敏展示 分域密钥。数据库透明加密解决客户字段落盘这一层敏感列写入时自动加密、读取时自动解密业务 SQL 不用改密钥管理平台承担主密钥保护、按门店或系统派生数据密钥、版本化轮换与历史解密支持让房地产中介个人信息保护里的密钥分域和日常轮换共用同一套治理。根密钥始终在硬件密码机内永不明文导出。售楼数据线这一段需要的能力是透明加密 按系统分域 导出审批与审计。透明加密解决购房意向与合同数据落盘这一层对生产节拍无感密钥管理平台按门店或系统派生彼此隔离访问与导出动作由统一身份认证平台做权限控制与日志签名形成可核查的留痕。人脸处理线这一段需要的能力是告知同意 最小必要 去标识化存储落点就是物业人脸识别隐私合规。处理规则由合规侧定义技术侧只承接特征不出采集设备、本地比对、外传只带签名过的事件这类能力并把同意记录与用途限制落到可查询的台账里。三段能力的组合正好覆盖个人信息保护、数据安全、密码应用三条监管线也直接对应了 06 节里那几份清单的核查项。智慧社区门禁身份认证怎么做门禁侧技术落点不在本文范围但门禁的合规处理规则与本文人脸线一致。08 | 验收清单与下一步上线前建议逐项过一遍这张表#验收项通过标准1客户字段加密清单手机号等敏感列落库为密文2脱敏展示规则对外呼/报表/第三方默认返回脱敏值3越权解密验证普通角色解密客户字段被拒绝4密钥分域清单门店/系统密钥按统一规则派生5根密钥保护根密钥仅在硬件密码机内无明文副本6派生可复现同因子派生一致、不同门店派生不同7售楼数据加密购房意向/合同落库为密文8导出审批记录全量导出均有审批与留痕9日志签名入库改动历史日志被完整性校验发现10人脸告知同意采集点均有告知与单独同意记录11人脸去标识化特征值不出采集设备、不外传12留存期限规则人脸与个人信息有明确最短必要期限13证据链串联采集-存储-使用-共享-删除可逐条还原14客户信息不出私域经纪人私人通讯录无明文客户信息15监管项映射表每条要求映射到五个落地动作趋势上看这项监管的重心正在从规范交易行为往管控数据全生命周期迁移。过去只要合同签得规范就算合规现在的检查会追到单个客户的手机号是否加密、单条购房意向的导出是否审批、单张人脸的同意是否可追溯。这个迁移对架构的实质要求是客户信息、售楼数据、人脸处理三件事不能再各自为政它们必须共享同一套字段加密口径、同一套密钥分域规则、同一条审计留痕。下一篇预告我们接着拆教育科研侧的同一件事高校核心系统密评看教务、一卡通、科研、图书馆这些核心系统怎么在密码应用安全性评估的框架下一体化合规和房地产数据全生命周期的做法有哪些相通、又有哪些根本不同。09 | 常见问题住建部房地产数据安全监管的 4 个高频疑问Q: 住建部房地产数据安全监管整改一般要多久A: 周期主要取决于系统改造量不是门店数量本身。只做客户字段加密与脱敏展示这类轻改造两到四个月可以补齐多数检查项涉及售楼数据透明加密、密钥体系重建与导出审批的往往要五到八个月。真正拉长周期的是客户信息治理把多系统明文共存的手机号收敛到加密与脱敏闭环一般要两到三个月。Q: 房地产中介个人信息保护怎么做才算到位A: 判断标准是看客户联系方式是否加密并分域保护而不是看有没有采集告知。手机号等敏感字段应写入即加密、查询时按角色返回明文或脱敏值字段密钥由主密钥按门店与系统派生根密钥放入硬件密码机普通角色与运维角色拿不到密钥即使取得库文件也解不开明文。Q: 售楼数据加密要怎么做才不影响成交效率A: 优先选驱动层透明加密写入即加密、读取即解密对业务 SQL 与成交流程透明不需要改应用代码。只对购房意向、合同这类高敏感字段开启加密普通业务字段保持明文配合硬件加速对成交与查询效率的影响通常控制在个位数百分比以内。Q: 物业人脸识别要怎么做才合规不踩红线A: 核心是先合规、再处理。人脸属于敏感个人信息采集前要明确告知目的、取得单独同意、遵循最小必要、并限制用途与留存期限特征值应存储于采集设备内、不得外传。存在其他非人脸识别方式的不得作为排他性的验证方式。合规侧的规则要落到可查询的同意台账里。智慧社区门禁身份认证怎么做另有专文本文只答合规侧问题。相关阅读智慧社区门禁身份认证的访客凭证管控POS终端加密安全防护的支付数据加密全链路PCI DSS v4.0电商合规的支付卡数据加密要求文章作者:安当加密-焱垚