MySQL访问授权策略

我想,每个人心里都清楚,想要授权最简单方便,维护工作量少,那自然是将所有权限都授予所有的用户了。但是,大家肯定也都知道,一个用户所拥有的权限越大,那么它给系统带来的潜在威胁也就越大。所以,从安全方面来考虑,权限自然是授予得越小越好。一个有足够安全意识的管理员在授权的时候,都会只授予必要的权限,而不会授予任何多余的权限。现在,我们就从安全的角度来考虑如何设计一个更为安全合理的授权策略。

    首先,了解来访主机。

    由于MySQL数据库登录验证用户的时候除了用户名和密码之外,还要验证来源主机。所以我们还需要了解每个用户可能从哪些主机发起连接。当然,也可以在授权的时候直接通过“%”通配符给所有主机访问的权限,但是这样做就违背了安全策略的原则,带来了潜在的风险,所以并不可取。尤其是在没有局域网防火墙保护的情况下,更不能轻易允许可以从任何主机登录的用户存在。能通过具体主机名或IP地址指定的尽量通过使用具体的主机名和IP地址来限定来访主机,不能用具体的主机名或IP地址限定的也需要用尽可能小的通配范围来限定。

随手可及的工具

很明显,为了了解和提高Web网站的表现有许多监测信息和指标的数据需要收集、分析。幸运的是,有许多工具可以用来自我监测。技巧在于如何选择恰当的工具来收集恰当的信息。

    在最广的层次上,这些监测技术可以分为三大类:在Web连接的各个角落收集用户做什么;使用搜索引擎检索Web,在发生变化或出现特定关键字时给出提醒;用脚本直接测试网站。

    一、收集工具

    有许多方法可以收集访问者信息,这取决于你对服务器访问程度、用户浏览器的特性以及被收集的信息。

各存储引擎常用物理备份的恢复方法

和逻辑备份一样,光有备份是没有意义的,还需要能够将备份有效地恢复才行。物理备份和逻辑备份相比最大的优势就是恢复速度快,因为主要是物理文件的复制,将备份文件复制到需要恢复的位置,然后进行简单的操作即可。

    1、MyISAM存储引擎

    MyISAM存储引擎由于其特性,物理备份的恢复也比较简单。

    如果是通过停机冷备份或是在运行状态通过锁定写入操作后的备份集来恢复,仅仅需要通过操作系统的复制命令将备份集中相应的数据文件复制到对应位置,覆盖现有文件即可。

是否合理利用了应用层Cache机制?

对于Web应用,活跃数据的数据量总不会特别大,有些活跃的数据更是很少变化。对于这类数据,是否有必要每次都到数据库中去查询呢?如果能够将变化相对较少的部分活跃数据通过应用层Cache机制缓存到内存中,对性能的提升肯定是成数量级的,而且由于是活跃数据,对系统整体性能的影响也会很大。

    当然,通过Cache机制成功的案例数不胜数,但是失败的案例同样并不少见。如何合理地通过Cache技术让系统性能得到较大的提升也不是通过寥寥几笔就能说清楚的,这里我仅根据以往的经验列举一下什么样的数据适合通过Cache技术来提高系统性能。

InnoDB存储引擎功能上的特点

在MySQL中使用最为广泛的除了MyISAM之外,就数InnoDB了。InnoDB作为第三方公司所开发的存储引擎,和MySQL遵守相同的开源许可证协议。

    InnoDB之所以能如此受宠,主要是因为其功能方面的几个特点。

    1、支持事务安全
   
    InnoDB在功能方面最重要的一点就是对事务安全的支持,这无疑是让InnoDB成为MySQL最为流行的存储引擎的一个非常重要原因。而且它实现了SQL92标准所定义的所有4个级别的要求(READ UNCOMMITTED、READ COMMITTED、REPEATABLE和SERIALIZABLE)。对事务安全的支持,无疑让很多之前因为特殊业务要求而不得不放弃使用MySQL的用户重新支持MySQL,那些之前对数据库选型持观望态度的用户,也大大增加了对MySQL的好感。

规范的对象命名


    规范的命名本身并不会对性能有任何影响,在这里我们单独来讲一讲,主要是因为这是一个不太被人重视,但是对后期的数据库维护影响非常大的内容。就像编程语言各自的一些不成文的编码基本规范一样,虽然由于在最初使用时看不出太多的利益,因而被人认为是一种束缚,但是当每一个人在接手维护一段编写很不规范的代码时,估计大部分都会非常郁闷,甚至在心里暗骂当初的编写者。其实任何系统都一样,没有任何规范可循,完全一个天马行空的作风,只会给后人(甚至可能是自己)留下一个让人摸不着头脑的烂摊子,难以维护。

代码

1)Query语句相关安全因素

   “SQL注入攻击”这个术语我想大部分读者都听说过了。指的就是攻击者根据数据库Query语句解析器的原理,利用程序中对客户端所提交数据的校验漏洞,通过程序动态提交数据接口来提交非法数据,达到入侵目的。

   “SQL注入攻击”的破坏性非常大,轻者造成数据被窃取,重者数据遭到破坏,甚至可能丢失全部的数据。“SQL注入攻击”漏洞的产生主要是编码不够严谨造成的,所以这里就不做介绍了,如果读者还不是太清楚何为“SQL注入攻击”建议通过互联网搜索一下,可以得到非常多且详细的介绍及案例分析。

主机

有了网络设备的保护,MySQL就足够安全了么?我想大家肯定都会给出否定的回答。因为即使局域网出入口的安全设备足够强大,可以拦截住外围试图入侵的所有威胁者,但如果威胁来自局域网内部呢?比如局域网中被控制的设备,某些被控制的有权限接入局域网的设备,以及内部入侵者等。它们仍然是威胁者。所以说,即使有了第一层防线的保护,仍然存在安全风险,局域网内部仍然会有不少的潜在威胁存在。

    这个时候就需要我们部署第二道防线“主机层防线”了。“主机层防线”主要拦截网络(包括局域网内)或直接的未授权用户试图入侵主机的行为。因为一个恶意入侵者在登录到主机之后,可能通过某些软件程序窃取那些自身安全设置不够健壮的数据库系统的登入口令,从而达到窃取或破坏数据的目的。如一个主机用户可以通过一个未删除且未设置密码的无用户名本地账户轻易登入数据库,也可以通过MySQL初始安装好后就存在的无密码的“root@localhost”用户登录数据库并获得数据库最高控制权限。

备份策略的设计思路

备份是否完整,能否满足要求,关键还是要看所设计的备份策略是否合理,以及备份操作是否确实按照所设计的备份策略来进行的了。针对不同的用途,所需要的备份类型是不一样的,备份策略也各有不同。如为了应对在线应用的数据丢失问题,备份就需要快速回复,而热情最好是只需要增量回复就能找回所需数据。对于这类需求,最好是有在线的,且部分延迟回复的备用数据库。因为这样可以在最短时间内找回所需要的数据。甚至在某些硬件设备出现故障的时候,将备用库直接开放,对外提供服务都可以。当然,在资源缺乏的情况下,可能难以找到足够的备用硬件设备来

静态网页和动态网页

目前的www网页根据其生成方式,大致可以分为静态网页和动态网页两种。

    1、静态网页

    最初由HTML制作的文件是属于静态文件。所谓静态页面,是因为请求的用户不能与从网络服务器上传来的内容进行交互,也就是说一旦这个文件被用户请求,下载到本地的浏览器上,它的内容就是固定的,不会因为用户不同的请求而发送不同的页面,这在一定程度上限制了网页的内容,也给页面带来了极大的局限性。

    另外每个用户都可以通过使用浏览器的【查看源文件】命令来打开网页的HTML源代码,任何人都可以轻易地看到一个制作精美的网页源代码,这对于HTML来说是一个极大的缺陷。

«192021222324252627282930313233»
最近发表
控制面板
您好,欢迎到访网站!
  [查看权限]
网站分类
搜索
Tags列表
网站收藏
图标汇集
  • 订阅本站的 RSS 2.0 新闻聚合
友情链接

热门搜索: 外链域名 高外链域名 高收录域名

Copyright www.thyst.cn. Some Rights Reserved.