标签: security

我在一台机器上丢失了sa密码，当我直接使用admin组中的帐户登录机器时，SQL Server Management Studio将不允许我使用Windows身份验证登录。

我的计划是简单地登录服务器，通过 Windows 身份验证连接，然后重置 sa 以使用新密码。由于我无法通过 Windows 身份验证连接，这将不起作用。

我还可以如何重置 sa 密码？

我的第一个问题，请温柔点。我知道 sa 帐户可以完全控制 SQL Server 和所有数据库、用户、权限等。

我绝对相信应用程序不应该在没有完善的、以商务人士为中心的理由的情况下使用 sa 密码。这个问题的答案包括我对以 IT 为重点的讨论的很多推理

我被迫接受一个新的服务管理系统，除非它使用 sa 密码，否则它将无法工作。我从来没有时间弄清楚为什么在设置评估时，服务器团队试图安装它以使用我设置的固定角色，其中包含 db_creater 和我认为需要的其他权限。哪个失败了。然后我让服务器团队使用 sa 帐户安装，但在其数据库的 dbo 角色帐户下运行，但也失败了。脾气暴躁，我试图让它以 sysadmin 角色的帐户运行，但即便如此也失败了，并且没有有用的错误消息，使我能够在不花费比可用时间更多的时间的情况下弄清楚发生了什么。它仅适用于 sa 帐户和以明文形式存储在配置文件中的密码。

当我询问这个​​问题并且服务器团队与供应商交谈时，他们得到了令人担忧的答案：“这有什么问题？” 然后'好吧，我们可以看看加扰密码'加扰ffs

我知道有一些方法可以限制对文件的访问，但我认为这只是安全性的另一个弱点

无论如何，我的问题是，有人可以向我指出一些文档，我可以用它向企业解释为什么这是一件坏事并且应该是一个很大的不。我在一个领域工作，这意味着我需要认真对待安全问题，并且一直在努力让业务理解，最终可能会被超越，但我需要尝试。

查看特定登录的属性时，可以看到映射到该登录的用户列表：

我分析了 SQL Server Management Studio (SSMS)，我看到 SSMS 一次连接到每个数据库并从 sys.database_permissions 检索信息

是否可以编写一个查询来检索上面显示的用户映射信息，或者我是否被迫使用游标或 sp_MSforeachdb 或类似的东西？

我正在测试针对 SQL Server 数据库的注入攻击的弹性。

db 中的所有表名都是小写的，并且排序规则区分大小写，Latin1_General_CS_AS。

我可以发送的字符串强制为大写，长度最多为 26 个字符。所以我不能发送 DROP TABLE，因为表名将是大写的，因此该语句会由于排序规则而失败。

那么 - 我可以在 26 个字符中造成的最大伤害是多少？

编辑

我对参数化查询等都了如指掌——让我们想象一下，在这种情况下，开发构建要发送的查询的前端的人没有使用参数。

我也不想做任何邪恶的事情，这是由同一组织中的其他人构建的系统。

我有一个用户收到一个 ORA-28002，表明密码将在六天内过期。我运行了以下内容：

ALTER PROFILE DEFAULT LIMIT PASSWORD_LIFE_TIME UNLIMITED; 

但是当我尝试以用户身份登录时，该消息仍然存在。执行这个：

select * from dba_profiles where RESOURCE_NAME LIKE 'PASSWORD_LIFE_TIME';

显示这些值确实更改为 UNLIMITED。

从历史上看，作为安全最佳实践的一部分，建议不要使用默认端口连接到 SQL Server。在具有单个默认实例的服务器上，默认情况下将使用以下端口：

• SQL Server 服务 - 端口 1433 (TCP)
• SQL Server Browser 服务 - 端口 1434 (UDP)
• 专用管理连接 - 端口 1434 (TCP)

问题：

• 这个建议还有用吗？
• 是否应该更改上述所有端口？

使用什么证书来加密实例上的每个数据库。

我可以使用以下方法获取数据，但如何编写查询

USE master
GO

-- this provides the list of certificates
SELECT * FROM sys.certificates


-- this provides the list of databases (encryption_state = 3) is encrypted
SELECT * FROM sys.dm_database_encryption_keys
 WHERE encryption_state = 3;

我注意到 sys.certifcates.thumbprint 和 sys.dm_database_encryption_keys.encryptor_thumbprint 列包含相同的数据。

看看我见过的大多数基于 PHP/MySQL 的网站的结构，如果你稍微挖掘一下，那么辨别数据库密码似乎并不是非常困难，因为在某个地方总是有一个设置或配置文件来存储日志信息进入数据库。除了确保我的数据库权限对远程请求进行适当限制的基本预防措施之外，我可以在自己的项目中实施哪些选项来保护这些信息？

我们有以下设置：

• 包含桌面软件使用的私有数据的多个生产数据库
• 公共网站的网络数据库，需要来自私人数据库的一些数据
• 一个中间数据库，其中包含一些从私有数据库中提取数据的视图和存储过程

目前网站登录web数据库，web数据库连接中间数据库，在生产数据库上拉取数据或执行存储过程。所有数据库都在同一个SQL实例上，整个过程使用同一个用户账号。

用户账户对web数据库和中间数据库有完全访问权限，但只能访问私有数据库的特定视图和存储过程

这真的比让公共数据库直接连接到私有数据库更安全吗？

中间数据库似乎只是为了使事情复杂化，因为使用相同的登录名访问所有数据库中的数据，并且它已经仅限于私有数据库中所需的视图/SP。我希望删除它。

首先介绍一下背景。

LedgerSMB 项目是一个在 PostgreSQL 上运行的开源财务会计软件项目。我们在用户定义的函数中实现了大量的业务逻辑，它们充当程序对象方法和数据库行为之间的主要映射工具。目前我们使用数据库用户作为身份验证用户，部分是出于选择（这允许集中的安全逻辑，以便可以编写其他工具并重用授予用户的权限），部分是必要的（在我们从 SQL-Ledger 分叉之后，有用于在该代码库上改进安全性的选项并不多）。

这让我们可以访问 PostgreSQL 可以访问的合理数量的单点登录选项，从 LDAP 到 Kerberos 5。我们甚至可以在涉及密码的地方使用 PAM。它还允许我们在与其他应用程序集成或允许其他客户端界面时重用权限。对于财务会计应用程序来说，这似乎是一场胜利。

有明显的成本。对于 Web 应用程序，我们可以支持的 http 身份验证类型非常有限。例如，DIGEST 完全出局了。BASIC 可以工作，我们可以很容易地实现 KRB5（我计划支持它并在 1.4 中开箱即用）。非常强大的身份验证措施无法直接对此进行适当管理，尽管我们可能会在必要时将它们填充（例如 BASIC + 客户端 SSL 证书，其 cn 与用户名和特定的根 ca 匹配）。

与此同时，我们遇到了相当多的批评，主要来自开发人员，偶尔来自 dba 的批评，他们告诉我应用程序应该是安全屏障，而不是数据库。我的观点仍然是，较小的安全边界通常更好，业务逻辑和安全逻辑的重用是相辅相成的，我觉得重用业务逻辑而不在同一级别重用安全逻辑是危险的的程序。

我在这里错过了任何主要的权衡吗？有没有我没有考虑的问题？