预约演示三视角安全框架
家办数据面临三类威胁：权力机构的合规压力、内部人员的意外操作、外部攻击者的恶意入侵。Ginkgo平台从架构层分别应对。
面向权力
法律主权隔离
新加坡公司主体，仅受新加坡法律管辖，不受其他司法管辖区强制披露要求影响。
- —新加坡公司注册，法律主体在新加坡
- —新加坡PDPA合规，数据处理有法律依据
- —数据不跨司法管辖区转移（TODO：业务方确认具体数据驻留政策）
面向意外
最小化人为接触
加密密钥由AWS KMS托管，开发与运维人员在日常运营中不接触明文数据和密钥。
- —AWS KMS密钥托管，运维人员不持有密钥
- —RBAC权限模型，最小权限原则
- —MFA多因素认证（TOTP/SMS/Email三种），防止账户误用
- —操作审计日志，所有关键操作可追溯
面向恶意攻击
纵深防御
多层防御体系，即使单层被突破，攻击者仍无法获取完整的家族持仓信息。
- —身份-持仓解耦：账户身份与实际持仓数据分离存储
- —PDF脱敏输出：导出报表自动脱敏敏感字段
- —AWS金融级基础设施，传输全程TLS加密
- —定期第三方安全审计（TODO：审计机构名称待业务方确认）
五分类措施
访问权限 / 存储安全 / 交易信息 / 持仓信息 / 弱关联——五个维度全面覆盖家办数据安全。
🔑
访问权限控制
谁能看到什么，精确到字段级别。
- ·RBAC角色权限模型，按岗位分配最小必要权限
- ·MFA多因素认证强制启用（TOTP/SMS/Email）
- ·会话超时自动登出
- ·TODO：IP白名单 / 设备管理策略待业务方确认
🛡️
存储安全
数据在磁盘上始终以加密形式存储。
- ·AWS KMS管理加密密钥，密钥不在应用层暴露
- ·存储加密（AES-256）
- ·AWS多地域备份，防止单点故障数据丢失
- ·数据库访问隔离，不同客户数据不共享存储实例（TODO：技术细节待业务方确认）
📋
交易信息保护
交易记录是最敏感的家族财务信息之一，单独设防。
- ·交易数据传输全程TLS加密
- ·交易记录访问按角色严格限制
- ·TODO：交易数据保留周期 / 删除策略待业务方确认
📊
持仓信息保护
持仓是家族最核心的私密资产，身份-持仓解耦确保即使凭证泄露也无法拼出完整持仓图。
- ·身份-持仓解耦架构：账户ID与持仓数据分离存储
- ·持仓快照按客户物理隔离
- ·PDF报表导出自动脱敏敏感数字（TODO：脱敏规则细节待业务方确认）
🔗
弱关联设计
即使攻击者拿到部分数据，也难以还原完整的家族财富图谱。
- ·身份标识与财务数据使用不同存储和密钥
- ·内部系统日志不记录持仓金额明文
- ·TODO：具体弱关联技术实现细节待业务方确认
安全常见问题
数据存储在哪里？会跨境转移吗？
Ginkgo平台数据托管在AWS新加坡区域。TODO：跨境数据转移的具体政策待业务方确认后补充。
Ginkgo的员工能看到我的持仓数据吗？
Ginkgo采用身份-持仓解耦架构，日常运维操作不涉及客户持仓明文数据。AWS KMS密钥由AWS托管，运维人员不持有。定期第三方安全审计。TODO：内部访问控制的具体细节待业务方确认。
如果发生数据泄露，Ginkgo会怎么处理？
TODO：数据泄露响应流程和通知政策待业务方确认后补充。
新加坡PDPA对我有什么保护？
新加坡《个人数据保护法》（PDPA）要求数据处理方有明确法律依据，数据主体（即您）有权查阅、更正和删除个人数据，并有权知道数据被用于何种目的。Ginkgo作为新加坡注册公司，受PDPA约束。
Ginkgo是否通过了第三方安全认证？
TODO：第三方安全审计机构名称和认证状态待业务方确认后补充。
预约演示