住建部房地产数据安全监管：房地产中介个人信息保护与售楼数据加密合规

住建部房地产数据安全监管这件事，正在从"管交易"延伸到"管数据"。过去中介门店和售楼处最在意的是成交与回款，现在监管侧还会追到：客户姓名与电话怎么存、人脸信息怎么处理、购房意向数据落到哪家系统、谁在什么时间导出了什么。某连锁房产经纪机构在一次行业检查中，因为客户联系方式在多个门店系统里明文互传、无加密无脱敏，被要求限期整改。

坐标先立：房地产场景的合规可以按"采集---存储---使用---共享---删除"五个环节来拆，这是国内个人信息保护与数据安全相关法规的通用框架。房地产行业的特殊点在于，它同时握有两类高风险数据：一类是客户联系方式、家庭结构这类个人信息，一类是房源交易与购房意向这类经营数据。本文切入的是最容易被做浅的一块：住建部门关于房地产数据安全监管的口径，怎么落到中介客户信息保护与售楼数据加密的可核查动作上。

01 | 住建部房地产数据安全监管这件事，难在哪儿

住建部房地产数据安全监管的复杂度，不在技术，而在"数据散、环节多、授权乱、留痕缺"。具体难在下面五处。

首要难点在客户信息多处明文留存。 一个购房客户的信息，往往同时躺在中介门店的 CRM、售楼处的来访登记、渠道的分销系统、经纪人的私人通讯录里，很多时候还是明文手机号。监管追到"个人信息保护"这一项时，企业拿不出"谁在什么时候访问了哪个客户的什么字段"的记录，整改就卡住。

其次，人脸信息处理的合规水位参差不齐。 不少售楼处和物业用摄像头做身份识别与客流分析，但人脸属于敏感个人信息，处理前要告知、要取得单独同意、要最小必要、要能证明没被滥用。很多场所只装了设备、没建处理规则，监管问起来只有一句"我们是为了安全"。

再有一处难点在售楼数据跨系统流转无管控。 购房意向、认购、合同这些经营数据，常在 CRM、ERP、渠道平台之间来回同步，常常是全量导出、明文传输。监管侧关心的是这些数据有没有加密、有没有按系统分域、导出有没有审批与留痕。

还有一处难点在权限与密钥各自为政。 门店有门店的访问账号，系统有系统的数据库账号，加密密钥有的写进配置文件、有的根本没加密。这类"授权乱、密钥散"的局面，让"数据保密性"和"访问控制"两项测评或检查都难以自证。

最后一处难点在证据无法串联。 采集做了告知、存储做了加密、使用做了审批，但三件事用的是三套流程、三份台账，监管来查时只能分别交材料，拼不出一条"这条客户数据从采集到删除全程可控"的证据链。

把这五处难点串起来看，住建部房地产数据安全监管的核心矛盾是：监管看的是数据全生命周期的闭环，而企业交付的是孤岛式的安全动作。

02 | 机制拆解：住建部房地产数据安全监管的三条线

先把三条线各自的职责划清楚，再看它们怎么拼成证据链。

线	对应监管维度	要解决的事	典型手段	缺了会怎样
客户信息线	个人信息保护·保密性	中介客户的联系方式怎么存	字段加密 + 脱敏展示 + 分域密钥	手机号随备份泄露
售楼数据线	数据安全·保密性	购房意向与合同数据怎么保护	透明加密 + 按系统分域 + 导出审批	经营数据全量裸传
人脸处理线	敏感个人信息·合法性	人脸信息怎么合规处理	告知同意 + 最小必要 + 去标识化	被认定过度收集

这三条线的边界要讲清楚：客户信息线只解决"个人信息存得安不安全"，不解决"经营数据怎么流转"；售楼数据线只解决"经营数据是否加密分域"，它依赖客户信息线给出的密钥与访问规则；人脸处理线不直接参与交易，但它决定采集动作本身是否合法。很多机构把这三件事分别交给 IT、合规、物业三个部门，最后三份材料拼不出一条证据链。

住建部房地产数据安全监管里的中介客户信息线

中介客户信息线的落点是"字段加密 + 脱敏展示 + 分域密钥"。客户的姓名与手机号这类字段，写入时自动加密、查询时按角色决定返回明文还是脱敏值；加密所用的会话密钥，由主密钥按"门店 + 系统"派生，每个门店、每个系统各不相同。这样即使某一个系统的数据密钥泄露，也解不开其他系统的数据。

住建部房地产数据安全监管里的售楼数据线

售楼数据线的落点是"透明加密 + 按系统分域 + 导出审批"。购房意向、认购与合同这类经营数据，落库时自动加密，业务不需要改代码；数据按 CRM、ERP、渠道系统分别派生密钥，彼此隔离；任何导出动作都要审批并留痕。这一线让"数据保密性"从承诺变成可核查的事实。

住建部房地产数据安全监管里的物业人脸线

物业与人脸处理线的落点是"先合规、再处理"。物业人脸识别隐私合规是这条线的底线：人脸属于敏感个人信息，处理前要明确告知目的、取得单独同意、遵循最小必要、并证明未被超范围使用。它和"智慧社区门禁身份认证怎么做"是相邻但不同的问题------门禁的技术落点（特征不出设备、本地比对）在其它文章已专门拆解，本文只从监管合规角度谈处理规则，不重复技术实现。

下面这张图说明三条线在一次客户到访与成交里的位置关系：

text 复制代码

[客户到访] --> [采集告知与同意] --> [客户信息: 字段加密+脱敏展示]
      |                                        |
      |                                        | 密钥: 按门店+系统派生, 根密钥在HSM
      v                                        v
[售楼/中介系统] --> [经营数据透明加密] --> [导出审批+访问日志签名]
      |
      | 人脸处理: 告知+单独同意+最小必要+去标识化
      v
[审计: 采集-存储-使用-共享-删除 全链路留痕]

03 | 先跑通：住建部房地产数据安全监管的四个环节

下面这段演示把三条线跑成一条完整链路：先对中介客户的姓名与手机号做 SM4 字段加密落库、可还原、密文与明文不同；再演示无密钥的普通角色解密被拒；接着演示手机号在查询层做确定性脱敏；然后演示售楼数据主密钥按"门店 + 系统"派生、不同门店派生密钥不同、主密钥轮换后派生值变化；最后演示查询与导出日志逐条 SM2 签名，被篡改的日志验签失败。

python 复制代码

# -*- 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 * G；gmssl 不会从私钥派生公钥，必须显式算出再传入"""
    return sm2.CryptSM2(private_key=priv, 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 = b"16BYTEKEYFORCRM0"   # 字段级加密密钥（由密钥管理平台下发）
IV = b"SM4IVREALESTATE0"
cust = ("客户信息:name=张敏|phone=13800138000|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 = b"16BYTEKEYFORGUEST"
ok_unauth = decrypt_or_none(WRONG_KEY, IV, ct_cust) != cust

# 电话脱敏展示
ok_mask = mask_phone("13800138000") == "138****8000"


# ===== 2) 售楼数据分域加密：主密钥按「门店 + 系统」派生 =====
MASTER = b"REAL-ESTATE-KEY-MASTER-2609"
k_storeA = sm3_hex(MASTER + b"|store=A01|sys=SALE-CRM")
k_storeB = sm3_hex(MASTER + b"|store=B02|sys=SALE-CRM")
ok_k_len = len(k_storeA) == 64
ok_k_diff = k_storeA != k_storeB
ok_k_det = k_storeA == sm3_hex(MASTER + b"|store=A01|sys=SALE-CRM")
ok_k_rotate = k_storeA != sm3_hex(b"REAL-ESTATE-KEY-MASTER-2610" + b"|store=A01|sys=SALE-CRM")

SALE_KEY = bytes.fromhex(k_storeA[:32])
sale = ("购房意向:client=CMA260928|area=89.6|price=5200000").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:client=CMA260928"
h_log = sm3_hex(log.encode("utf-8"))
log_signer = sm2.CryptSM2(public_key=LOG_PUB, private_key=LOG_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'}")

text 复制代码

============================================================
[客户敏感字段加密可还原] = 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: 核心是先合规、再处理。人脸属于敏感个人信息，采集前要明确告知目的、取得单独同意、遵循最小必要、并限制用途与留存期限；特征值应存储于采集设备内、不得外传。存在其他非人脸识别方式的，不得作为排他性的验证方式。合规侧的规则要落到可查询的同意台账里。智慧社区门禁身份认证怎么做另有专文，本文只答合规侧问题。

住建部房地产数据安全监管：房地产中介个人信息保护与售楼数据加密合规