以下是小编为大家准备的数据库的权限如何分配，本文共9篇，仅供参考，欢迎大家阅读。
篇1：数据库的权限如何分配
区分用户访问数据库的权限，总结了一下有如下要求：
某个用户查询所有数据库的权限
某个用户只有备份数据库的权限
给一个用户只能查看指定数据库的权限
给一个用户只有某个表的权限
要进行以上任务，首先我们先了解下数据库的权限相关的内容
主体
“主体” 是可以请求 SQL Server资源的实体。 与 SQLServer授权模型的其他组件一样，主体也可以按层次结构排列。 主体的影响范围取决于主体定义的范围(Windows、服务器或数据库)以及主体是否不可分或是一个集合。 例如，Windows登录名就是一个不可分主体，而Windows组则是一个集合主体。 每个主体都具有一个安全标识符(SID)。
Windows级别的主体
Windows域登录名
Windows 本地登录名
SQL Server-级的主体
SQL Server登录名
服务器角色
数据库级的主体
数据库用户
数据库角色
应用程序角色
SQLServer sa登录名
SQL Server sa登录名是服务器级的主体。 默认情况下，该登录名是在安装实例时创建的。
public数据库角色
每个数据库用户都属于 public数据库角色。 当尚未对某个用户授予或拒绝对安全对象的特定权限时，则该用户将继承授予该安全对象的public角色的权限。
INFORMATION_SCHEMA和 sys
每个数据库都包含两个实体：
INFORMATION_SCHEMA和 sys，它们都作为用户出现在目录视图中。这两个实体是 SQL Server 所必需的。 它们不是主体，不能修改或删除它们。
基于证书的 SQL Server登录名
名称由双井号 (##)括起来的服务器主体仅供内部系统使用。 下列主体是在安装 SQL Server时从证书创建的，不应删除。
##MS_SQLResourceSigningCertificate##
##MS_SQLReplicationSigningCertificate##
##MS_SQLAuthenticatorCertificate##
##MS_AgentSigningCertificate##
##MS_PolicyEventProcessingLogin##
##MS_PolicySigningCertificate##
##MS_PolicyTsqlExecutionLogin##
guest用户
每个数据库包括一个guest。 授予guest用户的权限由对数据库具有访问权限，但在数据库中没有用户帐户的用户继承。不能删除guest用户，但可通过撤消该用户的CONNECT权限将其禁用。 可以通过在master或 tempdb以外的任何数据库中执行 REVOKE CONNECTFROM GUEST来撤消 CONNECT权限。
客户端和数据库服务器
根据定义，客户端和数据库服务器是安全主体，可以得到保护。 在建立安全的网络连接前，这些实体之间可以互相进行身份验证。 SQLServer支持 Kerberos身份验证协议，该协议定义客户端与网络身份验证服务交互的方式。
创建数据库用户
SQL中支持11种用户类型：
用户基于登录名在 master这是最常见的用户类型。
基于登录名基于的Windows Active Directory帐户的用户
CREATE USER [ContosoFritz];
基于Windows组的登录名的用户。 CREATE USER [ContosoSales];
基于使用 SQLServer身份验证的登录名的用户。 CREATE USER Mary;
在数据库进行身份验证的用户建议以帮助使你的数据库可移植性。
始终允许在 SQL Database。 中包含的数据库中只允许存在 SQL Server。
基于无登录名的 Windows用户的用户
CREATEUSER [ContosoFritz];
基于无登录名的Windows组的用户。 CREATE USER [ContosoSales];
中的用户 SQLDatabase或 SQL数据仓库 基于 Azure Active Directory的用户。 CREATE USER [ContosoFritz] FROMEXTERNAL PROVIDER;
拥有密码的包含数据库用户。 (在中不可用 SQL数据仓库。)CREATE USER Mary WITHPASSWORD = '********';
基于 Windows主体通过 Windows组登录名进行连接的用户
基于无登录名但可通过Windows组中的成员身份连接到数据库引擎的Windows用户的用户
CREATE USER [ContosoFritz];
基于无登录名但可通过其他Windows组中的成员身份连接到数据库引擎的Windows组的用户。 CREATE USER [ContosoFritz];
无法进行身份验证的用户 这些用户无法登录到 SQL Server或 SQL Database。
没有登录名的用户。 不能登录，但可以被授予权限
CREATE USER CustomAppWITHOUT LOGIN;
基于证书的用户。 不能登录，但可以被授予权限，也可以对模块进行签名。 CREATE USERTestProcess FOR CERTIFICATE CarnationProduction50;
基于非对称密钥的用户。 不能登录，但可以被授予权限，也可以对模块进行签名。 CREATE User TestProcessFROM ASYMMETRIC KEY PacificSales09;
下面的图片显示了创建数据库用户需要的选项的含义：
创建用户可以使用界面完成：
也可以使用T-SQL来进行创建
-- 创建登录名：Test 密码是： '123456'.
CREATELOGIN Test
WITH PASSWORD = '123456';
GO
上面说完了用户，下面说下数据库的角色和权限
服务器级别的权限
SQL Server 提供服务器级角色以帮助你管理服务器上的权限。 这些角色是可组合其他主体的安全主体。服务器级角色的权限作用域为服务器范围。 (“角色”类似于 Windows 操作系统中的“组”。)
SQL Server 提供了九种固定服务器角色。 无法更改授予固定服务器角色的权限。 从 SQL Server 开始，您可以创建用户定义的服务器角色，并将服务器级权限添加到用户定义的服务器角色。
你可以将服务器级主体(SQL Server 登录名、Windows帐户和 Windows 组)添加到服务器级角色。 固定服务器角色的每个成员都可以将其他登录名添加到该同一角色。用户定义的服务器角色的成员则无法将其他服务器主体添加到角色。
下表显示了服务器级的固定角色及其权限
下表显示了固定数据库角色及其能够执行的操作。 所有数据库中都有这些角色。无法更改分配给固定数据库角色的权限
无法更改分配给固定数据库角色的权限。 下图显示了分配给固定数据库角色的权限：
SQL 2016有一些数据库的特殊权限
msdb角色
msdb数据库中包含下表显示的特殊用途的角色。
使用R Services
SQL Server(从 SQL Server vNext开始)
安装 R Services时，其他数据库角色可用于管理包
下面讲如何实现文章前面说的需求：
给某个用户查询所有数据库的权限
给某个用户只有备份数据库的权限
给一个用户只有指定数据库的权限
给一个用户只有某个表的权限
给某个用户查询所有数据库的权限
创建一个用户
USE [master] GO CREATE LOGIN [Test1]WITH PASSWORD=N'password@123'
使用Test1连接数据库实例
可以看到数据库列表， 但是无法访问数据库，
赋予test1对FinaceDemo的读取权限
USE [FinaceDemo] GO CREATE USER [Test1] FOR LOGIN [Test1] ALTER ROLE [db_datareader] ADD MEMBER [Test1] GO
这样就可以给test1用户对finacedemo的读取权限
但是test1 没有写入权限
这样就可以单独对test1赋予数据库的读取权限进行查看操作。
给某个用户只有备份数据库的权限
Test1 对于finacedemo无备份权限
赋予备份权限
ALTER ROLE [db_backupoperator] ADD MEMBER [Test1]
给一个用户只有指定数据库的权限
我们需要Test1只能看到 FinanceDemo，其他所有数据库都不能看到
执行下面脚本
USE [master] Deny VIEW any DATABASE TO Test1; go
运行后的效果
Test1 连接后看不到任何数据库
执行：
ALTER AUTHORIZATIONON DATABASE::FinanceDemo TO test1
完成后结果：
Test1能查看到赋予权限的数据库
给一个用户只有某个表的权限
创建测试用户test3
USE [master] GO CREATE LOGIN [Test3] WITH PASSWORD=N'password@123' -----赋予test2可以登录testDB USE [testdb] GO CREATE USER [Test3] FOR LOGIN [Test3] GO
赋予test3对于t2表的update和select权限 grant on dbo.t2to test3 grant select on dbo.t2to test3 use testDB 查看test3用户获得的权限 exec sp_helprotect @username='test3'
可以看到用户test3拥有了t2的select和update权限
执行select * from t2
执行插入操作失败。
以上介绍了对数据库权限细致的管理，更加详细的控制可以参考technet上面的信息。
权限管理非常复杂，以上只是做了简单的介绍。需要更加详细的内容，需要自己去研究。在technet上可以找到更加详细的信息。
[数据库的权限如何分配]
篇2：浅谈如何有效建立权限管理体系数据库
本文拟结合POWERBUILDER语言，简述如何在传统C/S应用系统当中有效建立权限管理体系， 何谓权限管理体系？就是如何控制操作使用者对软件功能和系统数据的访问权限的各个方面。传统的C/S应用系统，多是“前台应用程序+后台 数据库 表”两部分，这样就决定了我
本文拟结合POWERBUILDER语言，简述如何在传统C/S应用系统当中有效建立权限管理体系。
何谓权限管理体系？就是如何控制操作使用者对软件功能和系统数据的访问权限的各个方面。传统的C/S应用系统，多是“前台应用程序+后台数据库表”两部分，这样就决定了我们考虑权限管理体系就必然要考虑两方面的内容：
1、用户在前台的功能权限：即该用户能够使用哪些菜单或窗口功能，例如：张三只能使用数据录入功能，不能使用管理审批功能；
2、用户在后台的功能权限：即该用户能够对库表具有哪些读、取访问权限，例如：张三对于x_table表只有读权限，没有写权限；
是否上述两方面权限管理就足够了呢？答案是否定的，因为从应用角度来考虑，还需要对用户的数据访问权限进行控制，例如：张三属于A分局，李四属于B分局，张三、李四各录入一条数据，那么在查询时显然张三只能查询到其自己录入的数据记录，而不允许其查询到李四录入的数据记录，或者只能查询而不允许修改，因此这就引出了第三方面的权限管理内容：
3、用户在应用的数据访问权限：即该用户能够对哪些数据具有哪些访问权限；
下面我们逐一来了解如何实现上述三个方面的权限管理：
1、前台功能权限：
谈到前台功能权限，我们要建立下面几个概念：
岗位：是指用户具体负责的工作分类，如：数据录入岗、文书审批岗、系统维护岗等；
功能：是指用户能够使用的软件功能，可以通过菜单或窗口来控制，但由于一个系统当中窗口通常数据量庞大，控制用户使用哪些窗口不太实际，因此我们通常菜单控制即可；
工号：是指具体用户登录系统所用的用户ID；
上述三个概念的相互关系如下：
一个岗位可以对应多个功能菜单；
一个功能菜单同样可以对应多个岗位；
一个工号只能属于一个岗位；
进而我们可以设计以下用户登录流程：
（1）用户ID登录系统后读取对应用户表查看其所在岗位；
（2）查找该岗位对应可以使用哪些菜单；
（3）将用户能够使用的菜单和系统实际菜单逐一比较，屏蔽不允许其使用的菜单；
这里面由于涉及到菜单的遍历，需要使用到一些PB的使用技巧，详见另外一篇文章《浅谈如何利用PB实现动态添加菜单》，此处不再赘述，
这样通过上述三者关系，建立起一个用户工号到底能够使用哪些菜单，不能使用哪些菜单。为何要如此复杂，为何不直接定义每个工号能够使用哪些菜单呢？那样的话，显然系统冗余太大，造成资源浪费，不符合规范化要求。
2、后台库表权限：
后台库表权限主要是根据前台工号在后台数据库建立相应的帐号（LOGIN）、用户（USER），并根据一定的规则产生对应密码，并赋予其不同的角色（ROLE）、不同库表的不同读、写权限，由于这部分与所采用的后台具体数据库密切相关，因此本文不再详述。
3、应用数据权限：
应用数据权限的实现，主要通过各类数据表当中必须引入数据记录的录入或产生单位代码和操作员工号ID，当用户访问相应记录时，首先比较当前用户ID及其所在单位，是否与数据记录的产生操作员ID及其单位代码一致，这个问题说起来简单，但实际用PB语言实现起来需要讲究一定技巧，要充分借助“继承”这一特性，尽量高效、通用。
原文转自：www.ltesting.net
篇3：教你给数据库设置交叉权限
由于 SupeSite 需要调用 Discuz! 和 UCHome 的数据，所以如果它们不安装在同一个数据库，SupeSite 的数据库用户必须要对 Discuz! 和 UCHome 的数据库有读取、修改、删除等权限，这就需要在 MySQL 中对用户权限进行修改，授予需要的权限。
本文将演示这种情况，并给出详细的解决步骤。
本文示例的配置如下：
Discuz!
数据库名：discuz_7_sc_utf8
数据库用户名：discuz_mysql
权限：操作 discuz_7_sc_utf8 的全部权限
SupeSite/X-space
数据库名：ss_601_xs_401_sc_utf8
数据库用户名：ss_mysql
权限：操作 ss_mysql 的全部权限
出现情况：安装 SupeSite/X-space 时无法检测到 Discuz! 的数据库，
解决方法：授予 ss_mysql 操作 discuz_7_sc_utf8 的全部权限。
如果为了方便，可以创建一个数据库用户，授予该用户操作 Discuz! 和 SupeSite 数据库的全部权限，在安装时，都使用这个数据库用户，就不会出现本文的这种情况。以后安装别的产品，比如 UCenter Home，再授予该用户操作 UCenter Home 数据库的权限即可。
一、安装 Discuz_7.0.0_SC_UTF8
1、在 MySQL 中创建数据库 discuz_7_sc_utf8
打开 phpMyAdmin =>创建一个新的数据库
篇4：关于用户角色权限的一点想法数据库教程
标题 关于用户角色权限的一点想法(1) biggie（原作） 关键字 关于用户角色权限的一点想法
前言：
权限往往是一个极其复杂的问题，但也可简单表述为这样的逻辑表达式：判断“Who对What(Which)进行How的操作”的逻辑表达式是否为真，针对不同的应用，需要根据项目的实际情况和具体架构，在维护性、灵活性、完整性等N多个方案之间比较权衡，选择符合的方案。
目标：
直观，因为系统最终会由最终用户来维护，权限分配的直观和容易理解，显得比较重要，系统不辞劳苦的实现了组的继承，除了功能的必须，更主要的就是因为它足够直观。
简单，包括概念数量上的简单和意义上的简单还有功能上的简单。想用一个权限系统解决所有的权限问题是不现实的。设计中将常常变化的“定制”特点比较强的部分判断为业务逻辑，而将常常相同的“通用”特点比较强的部分判断为权限逻辑就是基于这样的思路。
扩展，采用可继承在扩展上的困难。的Group概念在支持权限以组方式定义的同时有效避免了重定义时
现状：
对于在企业环境中的访问控制方法，一般有三种：
1.自主型访问控制方法。目前在我国的大多数的信息系统中的访问控制模块中基本是借助于自主型访问控制方法中的访问控制列表(ACLs)。
2.强制型访问控制方法。用于多层次安全级别的军事应用。
3.基于角色的访问控制方法（RBAC）。是目前公认的解决大型企业的统一资源访问控制的有效方法。其显著的两大特征是：1.减小授权管理的复杂性，降低管理开销。2.灵活地支持企业的安全策略，并对企业的变化有很大的伸缩性。
名词：
粗粒度：表示类别级，即仅考虑对象的类别(the type of object)，不考虑对象的某个特
定实例。比如，用户管理中，创建、删除，对所有的用户都一视同仁，并不区分操作的具体对象实例。
细粒度：表示实例级，即需要考虑具体对象的实例(the instance of object)，当然，细
粒度是在考虑粗粒度的对象类别之后才再考虑特定实例。比如，合同管理中，列表、删除，需要区分该合同实例是否为当前用户所创建。
原则：
权限逻辑配合业务逻辑。即权限系统以为业务逻辑提供服务为目标。相当多细粒度的权限问题因其极其独特而不具通用意义，它们也能被理解为是“业务逻辑”的一部分。比如，要求：“合同资源只能被它的创建者删除，与创建者同组的用户可以修改，所有的用户能够浏览”。这既可以认为是一个细粒度的权限问题，也可以认为是一个业务逻辑问题。在这里它是业务逻辑问题，在整个权限系统的架构设计之中不予过多考虑。当然，权限系统的架构也必须要能支持这样的控制判断。或者说，系统提供足够多但不是完全的控制能力。即，设计原则归结为：“系统只提供粗粒度的权限，细粒度的权限被认为是业务逻辑的职责”。
需要再次强调的是，这里表述的权限系统仅是一个“不完全”的权限系统，即，它不提供所有关于权限的问题的解决方法。它提供一个基础，并解决那些具有“共性”的(或者说粗粒度的)部分。在这个基础之上，根据“业务逻辑”的独特权限需求，编码实现剩余部分(或者说细粒度的)部分，才算完整，
回到权限的问题公式，通用的设计仅解决了Who+What+How 的问题，其他的权限问题留给业务逻辑解决。
概念：
Who：权限的拥用者或主体（Principal、User、Group、Role、Actor等等）
What：权限针对的对象或资源（Resource、Class）。
How：具体的权限（Privilege, 正向授权与负向授权）。
Role：是角色，拥有一定数量的权限。
Operator：操作。表明对What的How 操作。
说明：
User：与 Role 相关，用户仅仅是纯粹的用户，权限是被分离出去了的。User是不能与 Privilege 直接相关的，User 要拥有对某种资源的权限，必须通过Role去关联。解决 Who 的问题。
Resource：就是系统的资源，比如部门新闻，文档等各种可以被提供给用户访问的对象。资源可以反向包含自身，即树状结构，每一个资源节点可以与若干指定权限类别相关可定义是否将其权限应用于子节点。
Privilege：是Resource Related的权限。就是指，这个权限是绑定在特定的资源实例上的。比如说部门新闻的发布权限，叫做“部门新闻发布权限”。这就表明，该Privilege是一个发布权限，而且是针对部门新闻这种资源的一种发布权限。Privilege是由Creator在做开发时就确定的。权限，包括系统定义权限和用户自定义权限用户自定义权限之间可以指定排斥和包含关系(如：读取，修改，管理三个权限，管理 权限 包含 前两种权限)。Privilege 如“删除” 是一个抽象的名词，当它不与任何具体的 Object 或 Resource 绑定在一起时是没有任何意义的。拿新闻发布来说，发布是一种权限，但是只说发布它是毫无意义的。因为不知道发布可以操作的对象是什么。只有当发布与新闻结合在一起时，才会产生真正的 Privilege。这就是 Privilege Instance。权限系统根据需求的不同可以延伸生很多不同的版本。
Role：是粗粒度和细粒度(业务逻辑)的接口，一个基于粗粒度控制的权限框架软件，对外的接口应该是Role，具体业务实现可以直接继承或拓展丰富Role的内容，Role不是如同User或Group的具体实体，它是接口概念，抽象的通称。
Group：用户组，权限分配的单位与载体。权限不考虑分配给特定的用户。组可以包括组(以实现权限的继承)。组可以包含用户，组内用户继承组的权限。Group要实现继承。即在创建时必须要指定该Group的Parent是什么Group。在粗粒度控制上，可以认为，只要某用户直接或者间接的属于某个Group那么它就具备这个Group的所有操作许可。细粒度控制上，在业务逻辑的判断中，User仅应关注其直接属于的Group，用来判断是否“同组” 。Group是可继承的，对于一个分级的权限实现，某个Group通过“继承”就已经直接获得了其父Group所拥有的所有“权限集合”，对这个Group而言，需要与权限建立直接关联的，仅是它比起其父Group需要“扩展”的那部分权限。子组继承父组的所有权限，规则来得更简单，同时意味着管理更容易。为了更进一步实现权限的继承，最直接的就是在Group上引入“父子关系”。
User与Group是多对多的关系。即一个User可以属于多个Group之中，一个Group可以包括多个User。子Group与父Group是多对一的关系。Operator某种意义上类似于Resource + Privilege概念，但这里的Resource仅包括Resource Type不表示Resource Instance。Group 可以直接映射组织结构，Role 可以直接映射组织结构中的业务角色，比
篇5：Windows下设置MySQL安全权限数据库教程
注意：本文的内容涉及到修改NTFS磁盘权限和设置安全策略，请务必在确认您了解操作可能的后果之后再动手进行任何的修改，
注意：本文的内容涉及到修改NTFS磁盘权限和设置安全策略，请务必在确认您了解操作可能的后果之后再动手进行任何的修改。
文中提及的权限都是在原有权限上附加的权限。
[修改步骤]
1．创建用户
创建一个名为mysqlusr的用户，设置一个随机密码，密码的长度最好
不要少于20位。
2．设置用户的身份
将mysqlusr用户加入Guests组，并去掉其它任何的组。
3．设置磁盘权限
假设MySQL安装在如下目录中
D:\\hosting\\system\\mysql\\
假设MySQL的数据库存放在如下目录中
D:\\hosting\\MySQLDB\\
假设MySQL的服务运行者修改为mysqlusr
目录权限设置如下
D:\\hosting\\system\\mysql\\
mysqlusr
读取和运行
列出文件夹目录
读取
D:\\hosting\\system\\mysql\\tmpdir
mysqlusr
修改
读取和运行
列出文件夹目录
读取
写入
D:\\hosting\\MySQLDB\\
mysqlusr
修改
读取和运行
列出文件夹目录
读取
写入
4．修改MySQL的相应配置
修改MySQL目录下的my.ini
在其中增加一行，内容如下
tmpdir=D:/hosting/system/MySQL/tmpdir
篇6：一种简单方便的权限管理方法使用菜单数据库教程
菜单
今天刚写完一个权限管理的程序，本来有很多解决方案可以实现，只是当时灵机一现，突然想到用菜单来进行权限分配，因为大部分项目的权限要通过菜单来控制，对于在窗口中要控制的非菜单的控件，控制他们其实也可以用一个隐藏的菜单来对应，这样有不少好处，至少可以在一登陆的时候就把所有权限用菜单的ENABLED为TRUE和FALSE来处理，以后，在需要判断权限时，取权限对应菜单的ENABLED一看便知，不用去数据库里取了！用菜单来进行权限分配的一大好处就是直观，所见即所得，通过点选菜单，使菜单项的CHECDED为TRUE即表示拥有该权限了，一种简单方便的权限管理方法使用菜单数据库教程
。为FALSE即为不拥有该权限。这样的方式，我认为编程比较简单，比用TREEVIEW来的简单，尤其PB6。5的TREEVIEW还不带复选框，用TREEVIEW来分配权限也是不方便，用数据窗口形式，或则列表框都可以实现，不过我还是自以为用菜单来分配方便简单，于是决定要这样做了！不敢独享，放在这里，也算是对所以帮助过我的网友致谢！设计思想：
前提：
权限是按菜单来分配的，一个菜单项对应是一个权限，窗口中要控制的非菜单控件通过隐性菜单项来体现到菜单上，保证一个菜单项对应一个权限。
1，从数据库表里取到用户组（角色或者用户，都一样处理）所具有的权限
2根据这些权限设置菜单，将相应菜单项的CHECKED=TRUE（有权限）
3。用户在菜单上进行权限设置，要设有权限即设置相应菜单的CHECKED属性为真
反之，则假
4确定用户的选择，遍历菜单将每个菜单项与用户组权限表比较，如果用户权限表里有的权限而在对应菜单里CHECKED=FALSE，则删去此权限，为TRUE则不处理，如果用户权限表中没有的权限而在对应菜单里CHECKED=TRUE，则增加此权限，为FALSE则不处理，
效果图如下
：
在每个菜单项的CLICKED事件里写
this.checked=not this.checked
在做这个程序的时候，碰见一个最大的问题就是，在点选菜单时，一点击左键菜单就不展开了，要为下一个权限点选的时候，又要重新点开菜单，这样是很麻烦的。所以我想要是在点开菜单的同时，可以点选很多子项菜单，这样就可以只需要展开一次菜单，然后可以给多个子菜单项进行权限设置了。
这可是个大问题啊，问了很多高人。子定义可视类不能以菜单为基类。又不能给菜单定义用户事件来映射到WINDOW消息上。而且菜单只有CLICKED和SELECTED两个事件，菜单调用CLICKED事件后会自动变成不展开状态，SELECTED事件里又不能用KEYDOWN函数来判断是否点击了鼠标右键或着键盘按下了某个键，在这个事件里去触发窗口里自定义事件（这个事件里放了KEYDOWN来判断是否有鼠标右键或其他键盘键按下），也不能遂愿。郁闷了我一天啊！
今天手写累了，先到这，要是大家觉得放在这不会玷污大家的眼睛的话，我会尽快努力把下文写完的，
待续！
篇7：巧设网站文件目录与数据库权限 拒绝 入侵
在网站运营的过程中，最令站长头痛的可能就是网站被入侵了，实际上，如果提前设置好网站的目录权限，就可以保证网站能够经受大部分的漏洞攻击，本文介绍了设置文件目录和数据库权限的方法，设置权限的方法也并不难，只要根据本文一步步进行操作，就可以大大提高网站的安全性。
网站目录权限的设置方法
大多数网站都是采用程序搭建，对于系统管理的目录，可以将其设置为可读也可执行脚本，但不可写入的权限;但是对于放置网页静态文件的目录，以及放置图片文件、模板文件的目录，就可以将其设置为可读写但不可执行的系统权限。在权限分配明确之后，即使系统被入侵，也只能浏览而无法对文件进行直接的操作。
对于能够执行脚本的文件，最好设置只能读而不能写的权限，而需要写入的文件则将其设置为不能执行脚本，目录权限这样配置下来，网站系统的安全性会大大提高。
数据库权限也要仔细设置
对于网站来说，数据库可以说是站点的核心，所有网站的内容都存储在数据库中。所以说数据库安全也是需要注意的地方，
对于MySQL数据库来说，最好不要对网站直接使用root管理用户的权限，而要专门为每个站点开通一个数据库账号，而且将账户的权限设置仅限于操作当前数据库目录，并且对这些单独的MYSQL账号去掉file和EXECUTE的执行权限，这样一来，即使数据库被SQL注入，也只能到数据库一级，而无法拿到整个数据库服务器的权限。这样一来，只要经常对网站的数据库进行备份，就很少会出现数据库被入侵的情况。
另外需要注意的是，由于很多建站系统并没有使用数据库的存储过程，因此最好禁用FILE、EXECUTE 等执行存储过程或文件操作的权限。
小提示：对于Access的数据库来说，可以将数据库的存放位置进行修改，最好是较为隐蔽的目录，这样会避免数据库文件被恶意探测下载。另外，一些程序也支持修改后缀，比如可以将。mdb的数据库文件修改为。asa等后缀名，同样可以有效地保护数据库安全。
删除不需要的文件
很多内容管理系统中，都会在空间中存在很多以后并不需要的文件，最普遍的可能就属于系统安装文件了，这类文件通常被命名为install.php或者install.asp，如果你的空间中存在类似的文件，现在就赶快删除吧。
另外，一些CMS也会存在很多功能，如问答系统等等，但是往往这些功能在网站中都不会用到，这时候就建议将这些功能的目录删除，或者仅保留Html静态页面，然后将目录设置为可读写但不可执行的权限。
篇8：旁注虚拟主机IIS权限重分配跨目录得webshell
国内的IDC运营商最常见的模式就是IIS搭配解析asp，有星外，新网，西数，华众等等，。。
这些虚拟主机提权都是相当难。最近小生在和习科核心渗透群里的一次渗透测试中，就遇到了一次，这里讲一下。
I)前奏
旁注，同服，虚拟主机服务器，只支持asp解析，aspx和php都不支持
最幸运的是，这个虚拟主机居然忘了禁用wscript
但是服务器上装了流氓软件360和杀毒软件诺顿，虽然我不太理解流氓软件和杀毒软件为何会共存，但是我比较清楚的是，比较难提权。
II)提权
既然是旁注，那就是想办法跨目录，那么跨到哪个目录呢？
IIS的话，其实是很容易的，ASPX大马通常自带，但是asp的话需要执行命令的。看习科兵器库：
attach.blackbap.org/down/wzaq/iis.vbs
这个脚本是iis Web账户密码读取的脚本，上传cmd.exe,cscript.exe以及这个iis.vbs到可写可执行目录(通常是c:\\windows\\temp)
然后
cscript. iis.vbs
就得到iis的账户和密码还有路径了
有些虚拟主机，一台服务器上面上千个asp站，容易超时
那么要改改：
cscript. iis.vbs >iis.txt
复制代码这样就可以避免web超时了
提权的时候确实是费了很大一番劲，各种溢出用遍了，没法成功，各种神器用遍了，搞不到serv-u这些软件
不过最后还是成功了，这样我们就成功添加了一个administrators的账户cond0r，密码是123!@#asdASD
iis溢出得到system，shell.user组件添加用户绕过360
III)跨目录
如果事情都是这么顺利，那么这个帖子也就没啥意义了
问题有这样几个，第一，远程桌面服务开启，读取注册表默认为3389，但是用webshell扫描本机端口3389是关闭的，nmap扫了下，没检测到远程桌面的端口
第二，netstat命令被禁，自己传一个netstat.exe也没回显，同样的net.exe也是一样的
这样即使提权成功了，也没法登陆服务器，好吧，我们不是有IIS的密码吗？
同样是习科兵器库里面，在网站安全分类下
attach.blackbap.org/down/wzaq/bs.rar
用这个神器，上传到iis的虚拟主机以后，运行，，第一个界面默认点“ok”
然后会弹出如下验证框：
这里可以输入目标IIS账户的用户名和密码(IUSER_00744 %MjI1NDkyMDA5MTAyNjE)，但是通常这个办法是不太有效的
这里也不无例外的失败了，那我直接用administrators的账号好了，输入刚刚创建的cond0r的账户和密码
这样子我们就得到了administrators的权限来浏览目录
当然了，这个权限也很容易的就把目标站拿下了
我写的帖子，通常并不是说哪个方法怎样怎样拿下什么站，习科团队正规的授权渗透哪一个单独拿出来也可以作为典型案例来讲，但是哪一个案例也都是无法复制到其他地方去的，所以我讲的都是思想，有了自己的思想就有了灵魂，走出自己的路才是真正的黑阔
篇9：设网站文件目录与数据库权限拒绝安全入侵
网站目录权限的设置方法
大多数网站都是采用程序搭建，对于系统管理的目录，可以将其设置为可读也可执行脚本，但不可写入的权限;但是对于放置网页静态文件的目录，以及放置图片文件、模板文件的目录，就可以将其设置为可读写但不可执行的系统权限，在权限分配明确之后，即使系统被入侵，也只能浏览而无法对文件进行直接的操作。
对于能够执行脚本的文件，最好设置只能读而不能写的权限，而需要写入的文件则将其设置为不能执行脚本，目录权限这样配置下来，网站系统的安全性会大大提高。
数据库权限也要仔细设置
对于网站来说，数据库可以说是站点的核心，所有网站的内容都存储在数据库中。所以说数据库安全也是需要注意的地方。对于MySQL数据库来说，最好不要对网站直接使用root管理用户的权限，而要专门为每个站点开通一个数据库账号，而且将账户的权限设置仅限于操作当前数据库目录，并且对这些单独的MYSQL账号去掉file和EXECUTE的执行权限，这样一来，即使数据库被SQL注入，也只能到数据库一级，而无法拿到整个数据库服务器的权限，
这样一来，只要经常对网站的数据库进行备份，就很少会出现数据库被入侵的情况。
另外需要注意的是，由于很多建站系统并没有使用数据库的存储过程，因此最好禁用FILE、EXECUTE 等执行存储过程或文件操作的权限。
小提示：对于Access的数据库来说，可以将数据库的存放位置进行修改，最好是较为隐蔽的目录，这样会避免数据库文件被恶意探测下载。另外，一些程序也支持修改后缀，比如可以将。mdb的数据库文件修改为。asa等后缀名，同样可以有效地保护数据库安全。
删除不需要的文件
很多内容管理系统中，都会在空间中存在很多以后并不需要的文件，最普遍的可能就属于系统安装文件了，这类文件通常被命名为install.php或者install.asp，如果你的空间中存在类似的文件，现在就赶快删除吧。
另外，一些CMS也会存在很多功能，如问答系统等等，但是往往这些功能在网站中都不会用到，这时候就建议将这些功能的目录删除，或者仅保留Html静态页面，然后将目录设置为可读写但不可执行的权限。
★职责权限
文档为doc格式
