假如说

• 您 100% 确定您的数据库服务器只接受本地连接。
• 您 100% 确定攻击者无权访问允许连接的本地环境。
• 您 100% 确定使用数据库的应用程序在其他方面是安全的。
• 您 100% 确定这些凭据不会用于与系统直接或间接相关的任何其他事情。

那么，暴露出来就没有问题了。

当然，如您所见，这些都是非常大的假设。如果您愿意下注，请继续并允许公开凭据。如果不是（我不会），那么请尽您所能保护您的安全，并将这些凭据保密。

如果他无法访问数据库，则凭据将毫无意义。这就像在戈壁沙漠的偏远地区隐藏在一个守卫的军事掩体内的门钥匙。钥匙只有在你能走到门口时才有用。

话虽如此，让您的凭据像这样泄露是非常糟糕的做法。如果您怀疑它们受到了损害，请更改它们。

只要数据库服务器得到适当保护，并且凭据正确链接到他无权访问的 IP 地址，那么他就无法对它们做任何事情，但它会删除一层保护，如果他确实找到了访问数据库的方式，然后你就被淹没了。

这称为纵深防御。多种机制可防止危害，但是如果怀疑某个级别受到危害，则在修复危害之前您的安全性会降低。

实际上，几乎所有的 sql 数据库（MsSql、MySql、Oracle 等）都具有执行操作系统命令的能力。因此，如果攻击者知道您的数据库密码，他就可以在数据库机器上执行操作系统命令。如果运行您的数据库引擎的进程具有高权限，那么攻击者可以接管您的整台机器。除此之外，你的想象是有限的。例如：

• 他/她可以从数据库机器攻击您网络中的其他计算机。
• 如果您使用虚拟化，攻击可以扩展到VM引擎，并且可以危害虚拟环境中的其他操作系统。
• 为未来的社会工程攻击收集非常重要的感官数据。
• 获取用户帐户名和密码，并尝试将它们用于您组织中的其他信息系统。人们大多使用相同的强？多个系统上的密码。
• 监听网络中的流量并嗅探重要数据。
• 插入木马或后门以供将来访问等。

尽管攻击者知道您的数据库密码，但您可以采取哪些措施来保护自己：

• 您可以限制 db 用户帐户的权限。不要忘记攻击者有时也可以通过使用您操作系统上的漏洞的特殊漏洞来增加他/她在机器上的权限。
• 禁用 DB 服务器的 shell 执行能力（但大多数 db 用户帐户有权再次启用它）
• 限制数据库引擎进程权限。大多数情况下，sql注入攻击都是因为数据库服务器安装错误而成功的。特别是 MsSql 设置可以轻松地将管理员帐户设置为数据库进程所有者。
• 将您的数据库机器与网络隔离。只让传入的请求。您需要通过外部防火墙机器来执行此操作。请记住，攻击者可以访问操作系统，因此如果您从数据库服务器限制它，他/她可以启用它。
• 通过散列（当然使用盐）保护您的用户帐户，如果您的 CPU 资源可用，则在应用程序级别使用对称加密保护敏感数据。

这不是一个完整的列表。它可以变得更大。