sql server权限

Our organization must restrict permissions and prove to an independent party that we investigate access and restrict permissions. We restrict permissions to objects using least permissions and give full access to an exceptional few based on an organizational design that follows best practices. What can we do additionally that will help us prevent unauthorized access or catch when someone who shouldn’t have access is able to infiltrate our systems, especially in the context of showing a third party that we track this.

我们的组织必须限制权限，并向独立的一方证明我们要调查访问并限制权限。 我们将使用最少的权限限制对象的权限，并根据遵循最佳实践的组织设计为少数几个对象提供完全访问权限 。 我们还可以做些什么，这将帮助我们防止未经授权的访问或捕获到那些本不应该具有访问权限的人能够渗透到我们的系统中的情况，尤其是在向第三方展示我们对此进行跟踪的情况下。

总览 (Overview)

In this post we’ll look at two methods we can use for providing information to a third party auditor. The first we’ll be using some techniques by monitoring access, which can be on the level of procedure or T-SQL execution to tracking logins running queries. In addition, we can separate our server by data access – high priority or PII data being placed in a node where few have access to, while lower priority data exist in nodes where more have access to.

在本文中，我们将研究两种可用于向第三方审核员提供信息的方法。 首先，我们将通过监视访问来使用某些技术，这些技术可以在过程或T-SQL执行级别上，以跟踪运行查询的登录名。 此外，我们可以通过数据访问来分隔服务器-将高优先级或PII数据放置在很少有人可以访问的节点中，而将低优先级数据放置在更多人可以访问的节点中。

监控访问和执行 (Monitoring access and execution)

We can monitor access outside of running a consistent trace – though the trace is more comprehensive if we must provide a third party with evidence that we’re tracking user access. We’ll look at three methods of doing this and we have more than these three options, they provide us with some best practices to consider. Using a derivative of our restricting object access, we’ll limit our environment to using procedures or queries that always log who accesses data. In an application layer, this may be a query that returns a result and also inserts data, or we could use the procedure method, which we see below this.

我们可以在运行一致的跟踪之外监视访问-尽管如果必须向第三方提供我们正在跟踪用户访问的证据，则跟踪会更全面。 我们将研究执行此操作的三种方法，除了这三个选项以外，我们还提供了一些可供考虑的最佳实践。 使用限制对象访问的派生类，我们将环境限制为使用始终记录谁在访问数据的过程或查询。 在应用程序层中，这可能是返回结果并插入数据的查询，或者我们可以使用过程方法，此方法将在下面显示。

/*
---- Example table for retaining failed logins
CREATE TABLE tbAuditLog(LogDate VARCHAR(100),LogObject VARCHAR(200),LogDate DATETIME DEFAULT GETDATE()
)
*/CREATE PROCEDURE stpSDRHoldingsOther WITH ENCRYPTION
AS
BEGINSELECT Members,SDRAllocations FROM tbSDRHoldingsINSERT INTO tbAuditLog (LogUser,LogObject) VALUES (SUSER_NAME(),'stpSDRHoldingsOther')
ENDEXEC stpSDRHoldingsOtherSELECT *
FROM tbAuditLog

The downside is that all our procedures must log the user, objects and time, the upside is that even if a user has access, we can spot inconsistencies with access, such as an employee looking at a report 12 times in 1 day for a monthly report, which they generally only look at once or twice during that month. This helps us possibly catch a scenario where UserA comprises UserB’s access and looks at data without approval using UserB’s credentials.

不利之处在于我们所有的程序都必须记录用户，对象和时间，不利之处在于即使用户有权访问，我们也可以发现与访问不一致的地方，例如员工每月1天每天查看12次报告报告，他们通常只看该月一次或两次。 这可以帮助我们捕获UserA包含UserB的访问权并未经UserB的凭据批准而查看数据的情况。

We’ll also observe that in the above procedure example, we’re using the option WITH ENCRYPTION, which prevents users from scripting a stored procedure (with restricted access they shouldn’t have this anyway) to discover what the definition of the procedure is. This adds another layer of security to our objects, though I will caution developers who user procedures like this that they must know the definitions in order to alter them correctly – the cost of inconvenience adds a layer of security.

我们还将观察到，在上面的过程示例中，我们使用了WITH ENCRYPTION选项，该选项可防止用户编写存储过程的脚本（具有受限访问权限，无论如何他们都不应该具有此功能）以发现该过程的定义是什么。 这为我们的对象增加了另一层安全性，尽管我会警告那些使用此类用户过程的开发人员，他们必须知道定义才能正确更改它们-不便的代价增加了一层安全性。

What about invalid logins, where a user attempts to log into a server when they shouldn’t, or when a valid user tries to log in multiple times in a row as if they lost their password? One way we can track this on the server level is to retain all invalid login information from the error log.

无效登录又是什么呢？无效登录，用户在不该登录的情况下尝试登录服务器，或者有效用户尝试连续登录多次（好像他们丢失了密码一样）？ 我们可以在服务器级别跟踪此问题的一种方法是保留错误日志中的所有无效登录信息。

/*
---- Example table for retaining failed logins
CREATE TABLE tbSaveLogins(LogDate DATETIME,LogText VARCHAR(2000)
)
*/DECLARE @save TABLE(LogDate DATETIME,ProcessInfo VARCHAR(200),LogText VARCHAR(MAX))INSERT INTO @saveEXEC sp_readerrorlog 0,1INSERT INTO tbSaveLoginsSELECT t.LogDate, t.LogTextFROM @save tLEFT JOIN tbSaveLogins tt ON t.LogDate = tt.LogDateAND t.LogText = tt.LogTextWHERE ProcessInfo = 'Logon'AND t.LogText LIKE '%Login failed%'AND tt.LogText IS NULLSELECT LogDate, LogTextFROM tbSaveLogins

The downside to saving this information is that it can become noisy in some situations, so I would approach alerting with this information carefully, so that people don’t learn to ignore it. This can be a very accurate way of catching a hack attempt, but too much alerting with it can cause developers to ignore the attempts.

保存此信息的不利之处在于，在某些情况下它可能会变得嘈杂，因此我将谨慎地使用此信息进行警报，以使人们不会学会忽略它。 这可能是捕获黑客尝试的非常准确的方法，但是对其进行过多的警告可能会导致开发人员忽略这些尝试。

The upside is that we can spot irregularities by using aggregate queries and track how this changes over time. In an example scenario, we may get 120 bad logins a month. Suppose that we migrate some priority data to our server without adding new user access and where the priority data only have access a few times a month, but we suddenly see a spike of 7000 bad logins per month. This is an example scenario where we have a possible compromise attempt and we can architect a new design for our priority data, or track who leaked information.

好处是，我们可以通过使用聚合查询来发现违规行为，并跟踪其随时间的变化。 在一个示例场景中，我们每个月可能会有120次错误登录。 假设我们将一些优先级数据迁移到我们的服务器而不添加新的用户访问权限，并且该优先级数据每月仅访问几次，但是突然发现每月出现7000次错误登录的高峰。 这是一个示例场景，在该场景中，我们可能会做出折衷尝试，并且可以为优先级数据设计新的设计，或者跟踪谁泄漏了信息。

In some situations, we may want to take a snapshot of the current logins running queries in addition to the other ideas. In the below query, we get the users running transactions (the filter on status for running) along with the date and time information of the login. Depending on our requirements, we may want to run this on a schedule or we may want to run this randomly if we want to prevent an infiltrator from identifying a consistent query. In some situations, an infiltrator doesn’t want to be on a server consistently logged in, otherwise, they’re easier to identify. An occasional login may get caught in these types of audits.

在某些情况下，除其他想法外，我们可能还希望对当前运行查询的登录进行快照。 在下面的查询中，我们获取正在运行事务的用户（运行状态过滤器）以及登录的日期和时间信息。 根据我们的要求，我们可能希望按计划运行它，或者如果我们想防止渗透者识别一致的查询，我们可能希望随机运行它。 在某些情况下，渗透者不想一直在服务器上始终登录，否则，它们很容易识别。 偶尔的登录可能会陷入这些类型的审核中。

/*
---- Example table for audting running logins
CREATE TABLE tbAuditRunningLogins(LoginTime DATETIME,HostName VARCHAR(500),LoginName VARCHAR(500),AuditDate DATETIME DEFAULT GETDATE()
)
*/INSERT INTO tbAuditRunningLogins (LoginTime,HostName,LoginName)
SELECT login_time, host_name, login_name
FROM sys.dm_exec_sessions
WHERE status IN ('running')SELECT *
FROM tbAuditRunningLogins

Since we need to submit evidence that we’re tracking information to a third party, these types of audits also make this process easier, since we’re logging this information with a timestamp for the random audit or scheduled audit, depending on the requirements.

由于我们需要向第三方提交跟踪信息的证据，因此这些类型的审核也使此过程变得更加容易，因为根据要求，我们使用时间戳记记录此信息以进行随机审核或计划审核。

通过访问描述数据存储 (Delineating data storage by access)

For a database with priority and (or) PII data, we may consider placing the database on a separate server with a few restricted accounts, firewall restrictions, and other security enhancements like two-factor authentication. Even if an infiltrator managed to compromise an account and had access to a username and password, without the firewall being open, or without a two-factor code, this would mean nothing. Even though this doesn’t guarantee security, we can provide this as a security design we’re using if we’re answering to an audit from a third party involving our security practices.

对于具有优先级和（或）PII数据的数据库，我们可以考虑将数据库放置在具有一些受限制的帐户，防火墙限制以及其他安全性增强功能（如两因素身份验证）的单独服务器上。 即使入侵者设法打开了一个帐户并可以访问用户名和密码，而没有打开防火墙，也没有两个因素的代码，这也没有任何意义。 即使这不能保证安全性，但如果我们要回答涉及我们的安全实践的第三方审核，我们也可以将其作为我们使用的安全性设计提供。

Part of the reason why demarcating data can be so effective, even if costly, is that it requires companies consider who should have what level of access. Unfortunately, some security breaches occur because these discussions never happened, so everyone has full access to all data. In addition, because our database servers are separate, hacks trying to increase permissions become more difficult, as it may not be a service account that an infiltrator must get access to, but also passing through a firewall and other obstacles. Finally, because fewer people will have access to this server, this makes tracking the behavior of the users even easier – how do two people tend to query versus hundreds?

标定数据之所以如此有效（即使成本很高）的部分原因是，它要求公司考虑谁应该具有什么级别的访问权限。 不幸的是，由于从未进行过这些讨论，因此发生了一些安全漏洞，因此每个人都可以完全访问所有数据。 此外，由于我们的数据库服务器是分开的，因此试图增加权限的黑客变得更加困难，因为渗透者可能不一定要获得服务帐户访问权限，而是要穿越防火墙和其他障碍。 最后，由于访问此服务器的人数减少，这使得跟踪用户的行为变得更加容易–两个人相比数百人，他们倾向于查询吗？

The price tag for this option does come with higher costs, as demarcating data on separate servers for enhanced security means that we have multiple servers and these servers do not directly communicate with each other. This means our methods for transferring data will leave us with less automation and convenience, even if the security is more robust.

此选项的价格标签确实带来了更高的成本，因为在单独的服务器上划分数据以增强安全性意味着我们拥有多个服务器，并且这些服务器不会直接相互通信。 这意味着即使安全性更高，我们用于传输数据的方法也会给我们带来更少的自动化和便利。

结论 (Conclusion)

In addition to retaining this information, we want to make sure that where we store the data is restricted. If we keep a copy of the audit data local to the database where all users have read access, this defeats the purpose. We can retain copies in other restricted databases and migrate the data, if needed, since the audit data itself will become priority data.

除了保留此信息外，我们还要确保存储数据的位置受到限制。 如果我们将审计数据的副本保留在所有用户都具有读取访问权限的数据库的本地，这将无法达到目的。 我们可以将副本保留在其他受限数据库中，并在需要时迁移数据，因为审核数据本身将成为优先级数据。

In addition, all security requires a combination of techniques and no technique alone is sufficient to protect against compromise, especially in a complex technical environment. While these will add some costs, for some environments, the cost for any compromise is much greater than the cost for monitoring and preventing possible infiltrations.

此外，所有安全性都需要技术的组合，并且没有任何一种技术足以抵御危害，特别是在复杂的技术环境中。 尽管这些将增加一些成本，但对于某些环境而言，任何折衷的成本要远远大于监视和防止可能的渗透的成本。

参考资料 (References)

• Information about active users on a SQL Server 有关SQL Server上活动用户的信息
• Creating stored procedures using the encryption option 使用加密选项创建存储过程
• Good review of permissions and options in SQL Server from Microsoft 对Microsoft SQL Server中的权限和选项进行了很好的审查

翻译自: https://www.sqlshack.com/securing-access-for-auditing-in-sql-server/

sql server权限