据澎湃新闻 2 月 15 日消息, 2 月 13 日, GDI 基金会荷兰安全研究员 Victor Gevers 在推特上爆料, 中国某公司发生大规模数据泄露事件. Gevers 表示, 该公司所掌握的数百万人的跟踪数据可供任何人访问, 其中包含超过 256 万人的个人信息, 例如身份证号码, 身份证发行日期, 性别, 国家, 住址, 生日, 照片, 雇主和过去 24 小时内的位置, 大约有 668 万条记录. Gevers 称, 该公司的数据库从 2018 年 7 月开始就处于任何人都可以访问的状态.
经仔细阅读分析该案例后, 发现常易被人忽视的日常安全运营之安全基线工作即能轻松预防和避免该类事件的发生, 详细分析如下:
一, 案例成因分析
1. 背景信息
2. 数据泄露原因技术分析
从 Gevers 在推特上发的截图和描述可以初步分析如下, 该公司使用 MongoDB 数据库存放人脸识别等个人敏感数据, 该数据库实例服务使用 MongnDB 安装缺省端口 27017, 该服务端口可由互联网直接访问, 该数据库未启用身份认证机制, 即允许任何人访问.
事件产生原因: 该公司对存放人脸识别敏感数据的 MongoDB 数据库使用了出场安装缺省配置, 未进行日常安全运营中的安全基线工作, 存在严重安全漏洞导致了此事件的发生.
二, 安全运营之安全基线工作的预防能力介绍
在日常安全运营中的安全基线工作中, 企业的安全团队会针对公司使用的各种系统, 软件和数据库开发和发布相应的安全基线标准, 在系统上线前进行部署和合规性检查, 经检查只有在与公司的安全基线标准符合的前提下才允许上线, 这样就可以避免由于各种系统, 软件和数据库由于使用厂家出厂不安全缺省配置导致的安全漏洞问题, 有效地降低和控制安全风险.
下面针对该案例摘录部分 MangoDB 安全基线内容如下:
1. 端到端安全架构设计
MongoDB 端到端安全架构设计如下图所示, 从人员, 过程和产品 (技术) 三个维度进行纵深安全体系防护, 分别通过访问控制, 加密和审计来实施.
网络安全架构部署参照下图, 通过两层防火墙将 web / 应用服务器和 MongoDB 数据库服务器分别隔离在不同的两个 DMZ 类进行网络区域隔离和分层网络访问控制, 数据库服务器通过防火墙访问规则控制只能由 DMZ1 区域内的应用服务器访问, 避免了将其直接暴露给互联网的安全风险问题.
2. 启用 MongoDB 数据库身份认证功能
身份认证功能状态检查:
cat /etc/mongod.conf | grep "Auth="
如果身份认证功能已启用, 则 Auth 的设置值为 "True".
激活身份认证功能步骤:
(1)启动未激活身份认证功能的 MongoDB 数据库实例;
mongod --port 27017--dbpath /data/db1
(2)创建数据库系统管理员用户, 并确保设置的口令符合组织口令策略的要求;
- use admin db.createUser(
- {
- user: "siteUserAdmin", pwd:"password",
- roles: [ { role: "userAdminAnyDatabase",db: "admin" } ]
- }
- )
(3)重启已激活身份认证功能的 MongoDB 数据库实例.
mongod --auth--config /etc/mongod.conf
3. 确保 MongoDB 数据库实例只在授权的接口上侦听网络连接
当前数据库实例网络侦听状态检查:
检查 MongoDB 配置文件;
cat /etc/mongod.conf |grep -A12"net"| grep "bindIp"
检查相关网络访问控制设置;
iptables -L
配置数据库实例侦听在指定网络接口并用防火墙规则进行严格访问控制, 应只允许 DMZ 区域里的应用服务器连接, 下面以主机防火墙 iptables 示例配置如下.
- iptables -A INPUT -s -p tcp--destination-port 27017 -m state --state NEW,ESTABLISHED -j ACCEPT
- iptables -A OUTPUT -d -p tcp--source-port 27017 -m state --state ESTABLISHED -j ACCEPT
如上对比分析可以看出, 如果企业在日常安全运营中, 认真严格地按照 MongoDB 数据库安全基线标准执行的话, 就能够有效地预防和避免类似大数据泄露案例的发生.
Reference:
来源: http://netsecurity.51cto.com/art/201904/594288.htm