标签: 数据库

  • 齐治DSG:如何让DBA管理SQL权限防删库跑路

    数据安全中很重要的一条是数据库里的数据是否安全。访问数据库的账号是否有权限,是否在权限范围内进行操作,是否既能防止删库等重大问题的出现,又可以保证它的高效安全访问,是每个数据库管理员都必须面对的话题。

    很显然,对于DBA来说,分配数据库权限是“重要且紧急”的任务。重要,是因为权限分配不能出错,权限分大了数据库有风险,权限分小了访问者有诸多不便,可能还会要继续追加权限增加了DBA的工作量;而“紧急”则是经常会有一次性的特殊情况出现,需要进行临时权限分配,且任务完成后需要及时回收。

    如何因地制宜,打组合拳,让DBA更快、更好地管理防删库SQL权限,管理成本最小化投入,管理效率最高?

    齐治数据库访问控制系统DSG,将资产的管理颗粒度分为两类:全局管控(建立数据库资产/库表对象集合,进行统一的操作权限管控)、库表管控(对某个数据库进行单独的细粒度库表权限操作管控),根据各种场景提出了“自助式+粗细结合”的数据库权限综合管控方案。

     

    根据资产的管理颗粒度,DSG可以进行全局管控、库表管控

    场景一:目标数据库少,权限确定


    解决方案:细粒度预授权机制,是白名单机制。
    优势:支持实现权限最小化。
    不足:1.需要预先调研权限需求,有一定工作量;2.在操作员、目标数据库表增多的情况下,权限维护管理工作量加大。

     

    场景二:目标数据库多,权限确定
    解决方案:对象集全局管控机制。将不同的数据库对象打包,统一操作权限管控。
    优势:支持大量数据库表的统一管控,降低管控配置工作量。
    不足:1.管控手段精细化程度不高;2.不能实现权限完全最小化。

     

    场景三:无法预先确定操作权限
    解决方案:按需自助提权机制。大体确定开放的数据库表范围,授予操作员对象浏览权限。
    优势:系统上线调研工作量小,同时支持权限最小化。
    不足:上线后,存在一定的权限申请、审批工作量。

     

    场景四:1.目标数据库很重要,并可以预先确定高危操作;2.黑名单管理方式(默认允许,显式禁止)。
    解决方案:二次复核管控机制。主要管控重要数据,对明确的高危操作进行二次管控。
    优势:1.即使在授权不当的情况下,也可防止误操作、恶意操作;2.二次管控支持黑名单模式,避免白名单方式的管控工作量。
    不足:如果需要二次复核,会一定程度的影响效率。

     

    场景五:目标数据库很多,数据库管理员少
    解决方案:数据属主分管机制。不同部门掌控数据库不同关键点,跨部门分管。
    优势:减轻数据库管理员的工作量;可更加合理地管控操作权限。
    不足:涉及多个部门参与,协调难度较大。

     

    场景六:1.数据库多,数据库管理人员或者数据库属主部门多;2.管理人员需要AB角。
    解决方案:部门分权机制。每个部门分权管理各自的数据库权限。
    优势:支持大规模数据库权限管控。
    不足:部门、人员结构的维护存在工作量。

     

    场景七:数据库管理员不掌握数据库的账号和密码
    解决方案:非全托管机制。可管控具体操作行为。
    优势:避免上线实施前的数据库台账、账号与密码梳理工作。
    不足:管控粒度仅限整个数据库范围,无法细化到库表字段级别的管控。

    这些方案虽然适合不同场景,但在实际使用过程中,齐治DSG支持多维度的权限管理机制,用户根据自身情况进行多维度叠加,例如:

    1.全局管控+细粒度管控+二次复核管控;
    2.部门分权+数据属主管控+自助提权管控;
    3.全局管控+自助提权管控+二次复核管控;
    ……

    用户可以根据自身的实际情况,利用DSG不同的管控机制,构建、优化自身的数据库操作管控流程,以实现数据库管控的最佳性价比。

  • 堡垒机:如何回收员工/运维的数据库账号密码?

    最近数据安全的话题在安全圈非常火热,有客户说数据安全话题有点大,他就关心一个问题:怎么样才能把员工手里的数据库账号和密码收回来?这个问题都解决不了,如何谈数据安全?
    确实,很多数据因为数据库账号问题在裸奔。数据库的账号用在三个场景:
    1.应用系统访问数据库用的应用账号。
    2.DBA(数据库管理员)运维用的账号。
    3.应用运维用的账号。
    这三类账号,都可能散布到员工、外包人员手中,甚至是外部入侵者手中。要回收这些账号,还是要从管理上入手,看一下齐治科技的解决方案建议。
    优化数据库运维管理机制

    通常,我们通过传统堡垒机来进行数据库的运维,DBA、应用运维的数据库运维都有数据库访问权限,传统堡垒机可以通过代填的方式,避免数据库账号密码被人为掌握。
    然而实际情况很难杜绝员工用数据库账号密码通过堡垒机访问数据库,原因是:
    1.有些客户端工具的账号密码代填,很难用堡垒机实现;
    2.员工知道应用系统的账号和密码后,可以通过堡垒机的应用发布客户端访问数据库。
    在不影响IT业务运行的前提下,唯一的方法就是找到某种效率与安全平衡的机制。我们建议从人员的安全性角度思考:DBA是专业的数据库人员,风险可控,让其最大限度地减少数据库账号密码的使用;而应用运维人员,则必须从专用的数据库堡垒机上免密登录访问数据库。
     

    过渡方案

    然而,对于有些客户来说,数据库账号密码本来就是掌握在应用运维人员手中,甚至包括开发、外包,回收难、工作量大,这种情况我们的建议设置回收过渡方案:
    1.关闭堡垒机上的数据库资产权限;
    2.允许在数据库堡垒机中自建数据库连接,SQL指令权限严格控制,按需自助提权;
    3.逐步回收账号密码,托管在数据库堡垒机上之后,授予应用运维所需的SQL指令、库表权限。
    这种机制下,即使应用运维人员掌握数据库账号密码,但是由于数据库堡垒机仅授权最低的SQL操作权限,降低了很大一部分风险。
    最终方案

    回收所有运维账号之后,通过使用数据库堡垒机,便可以形成以下管理机制:

    1.数据库受限通道:托管应用运维账号,应用运维人员有权访问,权限控制到SQL增删改查指令和库表,进行日常的数据库访问操作。真正意义上实现了用户与数据库的“操作”隔离:用户的操作先提交给数据库堡垒机,数据库堡垒机进行SQL语义解析与安全检查后,再连接真实的数据库进行安全的操作,这些操作都是被管控和审计的。
    2.数据库特权通道:托管DBA运维账号,DBA人员有权访问,同时作为应用运维人员在特殊情况下的应急访问通道。加了数据库堡垒机之后,DBA原来的权限和工具都是不变的。
    这种机制下,应用运维人员只有最低的SQL指令、库表访问权限,进一步降低了数据安全风险。数据库堡垒机从身份认证、权限管控、数据库操作、数据保护(动态脱敏和数据导出控制)、操作审计等多个维度控制人的数据库操作行为。
    此时,可以部署齐治特权账号管理系统PAM对应用运维账号、DBA运维账号、应用系统账号进行分阶段的改密回收,从而系统性消除数据库账号密码安全隐患。

    齐治的传统堡垒机,结合数据库专用堡垒机DSG、特权账号管理系统PAM,能够支持客户优化现有的数据库账号密码管理机制,最大限度减少人为的数据库账号暴露面,为客户的数据安全提供最基础的支撑。

    手机铃声响后提示忙音:对不起,您拨打的电话正在通话中?8个原因