数据加密：开发人员必须了解的关键术语

随着世界变得越来越数据驱动，对用户数据的安全处理比以往任何时候都更加关键。

作为开发人员，我们的工作已经足够艰难：处理高度复杂且脆弱的系统，这些系统有多个故障点，同时我们需要将人类的愿望转化为用户界面和链接。而现在还有一项新兴而重要的考虑因素：数据安全。有充分的理由支持这一点：如果我们的数据被滥用，我们作为客户会感到愤怒（所以我们应该为用户提供安全和愉快的体验），而政府和企业则要求遵守相关法规。

数据安全的责任转嫁

使安全变得更加困难的是它具有多个层次，变成了所有人都有责任却没有人负责的事情。在现代云团队中，有多个团队直接控制数据的进出：开发人员、数据库管理员、链接（如果你愿意称之为DevOps人员）、特权后台用户等等。这些角色/团队可能会闭眼认为数据安全是别人的问题。然而，事实是，他们有自己需要照顾的世界。例如，数据库管理员无法控制应用程序端的安全性，链接人员对后台访问毫无作为，等等。

开发人员和数据安全

所有这些说法都是为了说明，在涉及数据时，开发人员具有最大的访问范围：他们构建应用程序的每个部分；他们连接各种后端服务；他们来回传输访问令牌；他们完全可以读写整个数据库集群；他们编写的应用程序对系统的所有部分具有不受质疑的访问权限（例如，在生产环境中，Django应用程序具有转储或清除过去十年的整个S3集合的所有权限），等等。因此，在源代码级别，安全性方面存在疏忽或忽视的机会最大，这是开发人员的直接责任。

现在，数据安全是一个无底洞，我无法在一篇帖子中详尽其表面。然而，我想介绍一些开发人员必须了解的基本术语，以确保他们的应用程序安全。可以将其视为应用程序数据安全入门课。

让我们开始！

哈希

如果你想要一个高度严谨的定义，总是可以参考链接，但简单来说，哈希是将数据转换为另一种形式，其中信息是不可读的过程。例如，使用众所周知（且非常不安全）的链接过程，字符串“Is my secret safe with you?”可以转换（“哈希”）为“SXMgbXkgc2VjcmV0IHNhZmUgd2l0aCB5b3U/”。例如，如果你开始用Base64格式写个人日记，你的家人就没有办法阅读你的秘密（除非他们知道如何从Base64解码）！

在Web应用程序中，将密码、信用卡号等存储为哈希值的概念被用于数据加密。当然，这使用了高度强大和复杂的算法来执行哈希，而类似Base64的东西则会被破解者轻而易举地打破。

密码哈希使用了一种称为单向哈希的密码学技术，这意味着虽然可能对数据进行混淆，但无法解密它。那么当你登录时，应用程序如何知道你的密码呢？嗯，它使用相同的过程，并将你刚输入的密码的混淆形式与存储在数据库中的混淆形式进行比较；如果它们匹配，你就可以登录！

谈到散列，有一些有趣的事情。如果你曾经从互联网上下载软件或文件，你可能听说过在使用它们之前要先验证文件。例如，如果你想下载 Ubuntu Linux ISO，下载页面将显示一个选项来验证你的下载；如果你点击它，一个弹窗将会打开：

弹窗告诉你运行一个命令，基本上是对刚刚下载的整个文件进行散列，并将结果与下载页面上看到的散列字符串进行比较：5fdebc435ded46ae99136ca875afc6f05bde217be7dd018e1841924f71db46b5。这个转换是使用 SHA256 algorithm 进行的，你可以在命令的最后部分看到它的提及：shasum -a 256 --check。

这个想法是，如果通过检查产生的散列与下载页面上的散列不同，这意味着有人篡改了你的下载，并提供给你一个被篡改的文件。

在密码散列领域，你会听到一些熟悉的名字，比如 MD5（不安全和已经废弃）、SHA-1 和 SHA-2（算法族，其中包括 SHA-256 和 SHA-512）、SCRYPT、BCRYPT 等等。

加盐

所有类型的安全都是一种猫和老鼠的游戏：小偷学习当前系统并想出新的破解方法，这被注意到后，锁制造商改进他们的产品，如此往复。密码学也不例外。虽然将散列转换回密码已经变得不可能，但攻击者随着时间的推移已经开发出结合 intelligent guesswork 和强大的计算能力的复杂技术；因此，十之八九，他们可以仅通过散列来预测正确的密码。

因此，加盐的技术应运而生。它只是意味着密码（或任何数据）的散列计算将基于两个因素的组合：数据本身以及攻击者无法猜测的新随机字符串。因此，使用加盐，如果我们想要对密码 superman009 进行散列计算，我们首先会选择一个随机字符串作为“盐”，比如 bCQC6Z2LlbAsqj77 ，然后对 superman009-bCQC6Z2LlbAsqj77 进行散列计算。得到的散列将与算法产生的通常结构不同，大大减少了智能 reverse engineering 或猜测的范围。

散列和加盐都是非常复杂的领域，并且不断发展。因此，作为应用程序开发者，我们永远不会直接处理它们。但是，如果我们了解这些知识并且能够做出更好的决策，这将对我们非常有帮助。例如，如果你维护一个旧的 PHP framework 并且发现它使用 MD5 散列来存储密码，你就知道是时候在用户账户创建过程中插入另一个密码库了。

密钥

在加密的背景下，你经常会遇到术语“密钥”。到目前为止，我们一直讨论的是密码散列或单向加密，其中我们将数据进行不可逆转的转换并销毁原始形式。这对于日常实际使用是不明智的——一个被写信和发送得如此安全，以至于永远无法阅读的文件毫无用处！因此，我们希望加密数据，使得发送方和接收方能够打开信息，但在传输或存储过程中，数据应该是不可读的。

为此，密码学中存在一个“密钥”的概念。它的意思就像它听起来的那样：一个锁的钥匙。拥有信息的人使用某个被称为密钥的秘密对其进行了混淆。除非接收方/攻击者拥有这个密钥，否则无论他们的算法有多么复杂，都不可能解密数据。

密钥轮换

尽管密钥使加密变得可行和可靠，但它们存在与密码相同的风险：一旦有人知道密钥，整个加密过程就会被破解。想象一种情况，某人入侵了像GitHub这样的服务的某个部分（即使只有几秒钟），并能够获取20年前的代码。在代码中，他们还发现了用于加密公司数据的密钥（将密钥与源代码一起存储是可怕的做法，但你会惊讶地发现这种情况经常发生！）。如果公司没有费心更换密钥（就像密码一样），同一个密钥就可以用来制造混乱。

因此，频繁更换密钥的做法得到了发展。这被称为密钥轮换，如果您使用任何受人尊敬的云提供商，它应该作为一项自动化服务提供。

例如，AWS有一个专门的服务叫做AWS Key Management Service (KMS)。自动化服务可以帮助您省去在所有服务器之间更换和分发密钥的麻烦，对于大规模部署来说，这是一个再简单不过的选择。

公钥密码学

如果之前关于加密和密钥的讨论让您觉得非常麻烦，那么您是对的。保持密钥安全并传递它们以便只有接收者可以看到数据会遇到一些后勤问题，这些问题会阻碍今天安全通信的发展。但多亏了公钥密码学，我们可以安全地进行在线通信或购买。

这种类型的密码学是一项重大的数学突破，也是互联网没有因恐惧和不信任而崩溃的唯一原因。这些数学原理非常复杂和高度数学化，所以我只能在这里以概念性的方式解释。

公钥密码学依赖于使用两个密钥来处理信息。其中一个密钥称为私钥，应该保持与您私有，并且永远不与任何人共享；另一个密钥称为公钥（因此得名），应该公开发表。如果我要向您发送数据，我首先需要获取您的公钥，并使用您的公钥加密数据并发送给您；在您的端点，您可以使用您的私钥和公钥组合解密数据。只要您不意外地泄露了私钥，我可以向您发送只有您能打开的加密数据。

这个系统的优点是我不需要知道您的私钥，而截获消息的任何人都无法读取消息，即使他们拥有您的公钥。如果您想知道这是如何可能的，最简短和最非技术性的答案来自于素数的乘法性质：

计算机很难因式分解大素数。因此，如果原始密钥非常大，即使经过数千年，消息也无法被解密。

传输层安全协议（TLS）

现在您知道公钥密码学是如何工作的了。这种机制（了解接收者的公钥并使用其加密数据）是HTTPS流行的背后，并且是导致Chrome显示“该站点是安全的”消息的原因。所发生的是服务器和浏览器彼此使用对方的公钥加密HTTP流量（记住，Web页面是浏览器可以解释的非常长的文本字符串），从而产生安全的HTTP（HTTPS）。

图片来源：Mozilla值得注意的是，加密并不是发生在传输层上；OSI model没有提到加密数据。只是应用程序（在这种情况下是浏览器）在将数据传递给传输层之前对其进行加密，然后传输层将其传递到目的地，在那里进行解密。然而，这个过程涉及传输层，最终结果是数据的安全传输，因此宽泛的“传输”层安全术语一直存在。

你可能会在某些情况下遇到Secure Socket Layer (SSL)这个术语。它与TLS的概念相同，只是SSL比TLS早得多，现在已经被淘汰。

全盘加密

有时安全需求如此强烈，不能留给机会。例如，存储一个国家所有生物特征数据的政府服务器不能像普通应用服务器一样进行配置和运行，因为风险太高。对于这些需求，只在传输时对数据进行加密是不够的，它在静止状态时也必须加密。为此，full disk encryption用于加密整个硬盘，以确保数据在物理入侵时也是安全的。

重要的是要注意，全盘加密必须在硬件级别进行。这是因为如果我们加密整个磁盘，操作系统也会被加密，在机器启动时无法运行。因此，硬件必须知道磁盘内容已加密，并且在将请求的磁盘块传递给操作系统时进行解密。由于需要进行额外的工作，全盘加密会导致读/写速度变慢，这必须被这些系统的开发人员注意。

端到端加密

随着大型社交网络的隐私和安全噩梦不断发生，即使与制作或维护应用程序无关，没有人不知道“端到端加密”这个术语。

我们之前看到了全盘加密提供了终极防弹策略，但对于普通用户来说并不方便。我的意思是，想象一下Facebook希望保护在您的手机中生成和存储的电话数据，但又不能访问加密您的整个手机并在此过程中锁定其他所有内容。

出于这个原因，这些公司开始使用端到端加密，这意味着数据在应用程序创建、存储或传输时都进行了加密。换句话说，即使数据到达接收者，也完全加密，并且只能由接收者的手机访问。

请注意，端到端（E2E）加密不像公钥加密法那样具有任何数学保证；它只是标准的加密，其中密钥存储在业务上，并且您的消息的安全性取决于业务决定。

结论👩‍🏫

你可能已经听说过大多数这些术语。甚至可能全部都听说过。如果是这样，我鼓励你重新理解这些概念，并评估你对它们的重视程度。记住，应用数据安全是一场你每次都需要赢得的战争（而不仅仅是一次），因为即使一次违规行为足以摧毁整个行业、职业甚至生命！