今天早上,我在喝咖啡的时候想,如果我能用一个密钥加密租户的数据,然后用另一个密钥解密数据,那就太好了。这样,只有登录用户才能访问其组织(租户)中的数据。作为系统管理员,我无法访问它。到目前为止这是公钥加密。系统可以使用公钥加密数据,私钥是解密密钥,类似于TLS。解密密钥本身可以使用每个租户用户的明文密码加密并存储在User表中,而这些密码不是存储的。因此,只有当租户用户使用明文密码登录到系统时,才能获得解密密钥。这样,即使是系统管理员也无法在没有租户用户登录时访问数据。
用多个密钥加密相同的明文并不会使它们在物质上更容易受到攻击,因此拥有这样的私钥的多个加密副本是可以的。
一个棘手的部分是在用户创建帐户时用密码加密解密密钥。另一个用户需要先登录并创建一个invite链接,该链接将包含用系统密钥加密的解密密钥。这似乎没问题,因为这是将用户添加到组织中的常见流程。
另一个棘手的部分是重置用户的密码。他们需要访问他们的电子邮件,加上另一个登录用户创建的invite链接(或者原始的invite链接)。
在我看来这是可行的。如果您丢失了所有密码,数据是无法恢复的,但应该是这样的。
它似乎会减少许多表面积的攻击,因为解密密钥只存在于明文时,用户登录。实际上,如果您在每个用户请求中发送密码,而不是使用单独的登录和会话,则解密密钥仅在请求期间以明文形式存在,这是最起码的可能。攻击者需要破坏系统,等待请求捕获密钥并能够解密数据。系统管理员将无法访问用户的数据,除非他们也以某种方式破坏了系统。另一方面,如果你不能信任你的系统管理员,你就完蛋了。但这将防止用户随意访问数据--用户的数据仍然很有价值,这意味着攻击者需要同时访问持久化的数据和内存中的瞬时解密密钥。
会像我描述的那样起作用吗?它能提高安全性吗?我没看到这里有什么瑕疵吗?
发布于 2022-10-26 14:46:11
不确定这个问题会是密码。这一切似乎都很好。
发布于 2022-10-26 21:16:43
首先,异步加密是相当昂贵的。由于这个原因,大型数据加密的常用方法是使用带有随机密钥的系统加密,并且只对该密钥使用异步加密。这种模式允许对一组数据进行一次简单的加密:只有系统密钥必须使用所有公钥进行加密。您甚至可以将物理上唯一的私钥(例如智能卡上的密钥)存储在物理保险箱中,并将其用作最后的解密工具(如果需要考虑数据的可用性)。当我们回到物质世界时,我们更容易拥有一个系统,它需要两个物理密钥,由不同的人拥有,以确保没有一个人能够不被注意地访问智能卡。
你的建议的其余部分仍然有效,与你在帖子结束时所表现出来的完全一样的信任问题,也没有更多或更少。
发布于 2022-10-27 20:38:45
您提到的加密方法有一些技术问题,但是这个解决方案最大的问题是威胁模型和您对信任的假设。
如果您的系统管理员不受信任,那么服务器本身就是不可信的。如果服务器不受信任,则不能假定服务器端代码将保持完整和未修改。您的系统需要将用户的明文密码(或用于加密信息的派生程序)发送到服务器。因此,恶意系统管理员可以操纵服务器,以转储任何用户登录时存储的密码和/或明文数据。
如果服务器不受信任,则必须使用服务器不知道的密码(或密钥或其他秘密提供程序)加密(并验证)数据客户端。但是,如果应用程序是在JS中执行加密操作的网页,则这通常是不可行的。在这种情况下,必须信任JS,这样才不会将明文数据或密钥传输到服务器,但是JS由服务器提供,因此不能被信任。
您可以选择发布应用程序(桌面、移动应用程序等)。用于客户端加密。但是,如果您不信任您的系统管理员,您如何信任您的源代码管理和构建基础设施,或者您发布的应用程序安装程序文件?您是否任意选择信任开发人员,尽管不信任系统管理员?如果开发人员迁移到sysadmin部门,他们突然不受信任了吗?有什么理由可以证明这一点呢?不可能和解。
在一种组织安全文化中,拥有王国钥匙的人被认为是不可信任的,这是站不住脚的。实现制衡是合理的,以提供监督并减少错误和内部威胁的风险,但默认情况下,您必须向员工提供高度的信任。
在有些情况下,您可能希望部署客户端加密来保护用户数据,但这些情况通常是基于数据窃取场景,在这种情况下,威胁参与者侵入并窃取所有服务器端数据。
https://security.stackexchange.com/questions/265837
复制相似问题