问题描述
说我是一个由10人组成的团队的成员,我们正在开发银行业务应用程序,而用户管理模块中的成员很少。
注意:用户管理系统仅基于用户名和密码。仅有一层身份验证。
-
UI团队负责将编码格式的密码发送到后端系统。
-
后端团队负责以加密形式将用户密码存储在数据库中。
-
如果用户尝试登录,则后端系统可以验证UI密码和DB密码是否相同,或者
如果解码(UI的密码)==解码(从数据库检索到的密码),则它们将允许用户登录到应用程序。
-
在这种情况下,开发人员可以从数据库中检索任何用户的登录凭据并可以刷出其银行帐户
让我知道我的想法是否正确,因为我只使用某些内部工具,并且它们使用各自的加密密钥来使用相应编程语言的加密库对密码进行编码和解码。
如果我的想法是错误的(其他开发人员都入侵了银行应用程序用户详细信息),请让我知道用户管理系统是如何安全的,即使他们使用开发人员也无法从数据库解码用户密码知道加密方法并可以访问数据库。
解决方法
在过去没有DevOps的时代,我们通常分担责任。开发人员使用一些综合数据开发了一些代码,以测试他们的热门产品,如果他们认为很好,则将其作为(编译的)发行版提供给在生产中部署该代码的运营团队。这意味着开发人员不能只是将调试器附加到正在运行的进程中,而无法查看用户密码。但是恶意的开发人员仍然可以添加一些代码,以将接收到的密码发送到选择的开发人员的外部服务器。
唯一可以防止这种情况的方法是,在将代码推送到生产环境时要多加注意。例如,运营团队确保至少有两个开发人员已经批准了他们必须部署的发行版,这意味着第二位开发人员正在审查代码。请注意,我们在假设多个恶意开发人员之间进行合谋对开发人员来说风险太大。
如今,DevOps与持续集成是热门的新事物。假设我们有一个集成管道,并且所有开发人员中只有一部分拥有系统权限来设置它。我们还需要代码存储库具有不可重写的历史记录(允许git rebase是一个坏主意),以防止单个开发人员推送恶意代码并隐藏它们确实存在的事实。如果您自己托管代码存储库,则其他开发人员子集应该操作托管它的服务器。如果代码的可审核性还不够,您甚至可以以这样的方式设置持续集成管道,即两个开发人员必须退出发行版。
我提到的控件只是冰山一角。还有其他事情要考虑:
- 您本来就需要信任您的管理员,但是您可以在雇用新人员时以及以后定期(人员变动)时进行后台检查来进行验证。
- 由于这与银行业务有关,因此您可能对管辖区有一些合规要求。这些要求可能会规定一些有用的安全控制措施。
- 您可以拥有一个独立的团队,该团队仅在其中检查每个人(或随机样本)是否是好公民并按照约定的程序运行的审核日志。
- 在没有适当的审核日志记录谁发起模拟的情况下,您的开发人员或其他运营商(银行职员)无法在后端模拟最终用户。
- 以相同的方式保护审核日志,使开发人员或其他特权较高的人员无法更改它们。
- 要求最终用户进行两步验证,以便以某种方式查看生产数据库并查看用户密码的开发人员必须对系统进行更改才能利用此密码。
- 仅存储哈希密码(scrypt或类似密码),并在登录时恒定时间比较哈希值。
- 如果密码很简单,并且您不需要2FA,则开发人员可以使用hashcat或类似工具离线破解它。因此,需要为最终用户的密码设置一些合理的复杂性规则。