🌕写在前面
🎉欢迎关注🔎点赞👍收藏⭐️留言📝
✉️今日分享：劝君莫惜金缕衣，劝君惜取少年时。
在数据安全呼声愈发高涨的同时，越来越多的安全厂商在不断探索合适的解决方案，数据库防火墙肯定是绕不开的话题，可以说它是磨刀石也是验金石。
随着不断的探索，数据库防火墙在运维侧使用确实能发挥更大效果，根据能量守恒和熵增不可逆两大宇宙定律，降低对性能和高可用的要求，由此转向开发更多的运维管理功能，数据库防火墙在迭代更新中愈发耀眼。
性能、可用性等非功能性需求在产品最初的需求方案分析阶段很容易被忽略，而性能和可用性往往会影响到产品的实现，包括功能架构、操作方式、界面展现、后台处理方式等。所以产品在设计之初就要考虑到性能、可用性、安全性、环境要求等非功能性需求设计。
数据库防火墙性能主要考虑两方面的影响：延迟和并发。如果偏向运维侧使用的话，对实时性要求没有接入业务那么高，但是功能要尽可能多，更加融入运维场景。
在数据库防火墙的需求分析过程中，即需要针对运维对象、运维所需功能等，考虑响应时间、吞吐量、并发的要求，进行需求分析和产品设计。数据库防火墙这种软件产品都是license控制使用，性能大小、功能模块都可以由授权证书控制。
首先明确产品定位是运维管理，面向有众多第三方人员参与运维、内部管理人员众多的政企机构，打造一个一站式运维管控平台，集成更多的运维所需功能，避免更多的风险暴露面。接下来分析使用对象和运维场景。
🍓防护主体：数据库。
🍓使用对象：DBA、内部人员、第三方人员、开发测试人员等。
🍓涉及的场景都是围绕数据库操作行为展开的，比如对上百个数据库的运行状态监控、数据库操作行为全程审计监控、运维端访问控制、身份认证与权限管控等。
🍓产品最好能支持SaaS化，支持云上部署。
在运维场景中，通过一个接口平台实现对所有数据库的访问，并且支持单点登录，相当于是一个数据库连接工具可以操作所有数据库，优点是提升数据操作效率和减少风险点，与4A的设计理念有点像。
针对运维端实现对数据库访问行为的全审计，包括运维账号的登入登出、访问终端IP地址，方便事后回溯，对高危操作实时告警。
通过代理模式部署，如果运维端访问敏感数据表，可以针对返回结果实时脱敏，防止数据泄露，这种动态脱敏实现的技术为结果集改写和SQL语句改写技术，通过对数据库协议的反向代理实现数据库层的动态脱敏目标。
在运维端根据不同的人员级别进行权限赋予，实现人员的操作权限分离和细粒度的管控，严格控制数据库操作的行为和流程。
如果运维人员进行超出自身权限的操作，该操作将被阻断，并提示用户需要发起提权审批流程。在工作时间段放宽操作权限，在非工作时间段的操作可以根据需求设置审批规则，根据业务场景优化审批流程，这种最好能对接OA系统，方便审批。
能够实现数据库各种运行指标进行全方位实时监控。系统能够发现和识别数据库异常以及潜在的性能问题，并及时将数据库异常报告给管理员，通过针对各项运行指标的统计分析报表，帮助管理员、运维人员、决策者多视角了解数据库的运行状态，从而更好的应对数据库的需求及规划。
由于SQL注入攻击和数据库漏洞攻击的伴生性，数据库防火墙需要具备数据库漏洞检测和防御功能。并且虚拟补丁这个功能也非常重要，实施虚拟补丁，关键点在于请求的路径上设置检测点，阻断非法请求，让受保护数据库本身的漏洞隐形，从而达到“漏洞修复”的目的。
安全策略支持机器学习。可自定义学习期，并基于学习期完成语句、会话的建模分析，构建数据库安全防护模型，实现面向数据库的主动预防和实时审计机制。
数据库防火墙在运维端的突出表现值得去研究，这种场景需求还是很多的，技术演变只会越来越精彩，上述提到的几点都是一些基本功能，技术实现不过多讨论，这种一体化的运维管控平台以前用的多是为了合规检查，现在注重实用，谁不想一个平台就解决数据库运维的工作呢。
技术的发展是无止境的，对安全的需求也没有尽头。只要威胁在演变，技术在革新，防御手段就需不断进化以至平衡。随着用户需求提升，也祝愿数据安全爱好者们能不断打破边界，大踏步朝技术更深处走去。
🙏因个人水平确实有限，不足之处，请帮忙指正，以上内容分享仅供参考和学习，如有侵权，请联系我删除。