在当今这个数据驱动的世界，安全地处理用户数据变得空前重要。
作为开发者，我们的工作已经相当具有挑战性：在将瞬息万变的人类愿望转化为用户界面和后端的同时，还要处理高度复杂且脆弱的系统，其中可能存在多个故障点。 除了这些任务之外，现在还需要考虑一个新兴且至关重要的问题：数据安全。 这样做是有充分理由的：如果我们用户的数据被滥用，我们作为客户会感到愤怒（因此我们有义务为用户提供安全和愉快的体验），同时政府和企业也要求我们必须合规。
数据安全：责任分担
让安全问题变得更加复杂的是，它具有多个层面，并且很容易出现“谁都负责，就等于没人负责”的情况。在现代云团队中，有多个团队直接控制数据的入口和出口：开发人员、数据库管理员、系统管理员（DevOps人员）、具有特权的后台用户等等。 这些角色或团队可能很快就会忽视数据安全，认为那是其他人的责任。然而，现实情况是他们都需要专注于自己领域的工作，数据库管理员无法控制应用程序的安全，DevOps人员对后台访问也无能为力，等等。
开发人员与数据安全
总的来说，在涉及到数据时，开发人员拥有最大的访问权限：他们构建应用程序的每个部分；他们连接到各种后端服务； 他们传递访问令牌；他们控制整个数据库集群，可以根据他们的命令进行读取或写入操作；他们编写的应用程序可以毫无疑问地访问系统的所有部分（例如，生产环境中的 Django 应用可以随意转储或清除过去十年中整个 S3 存储桶）。因此，最容易出现安全漏洞的地方通常在源代码层面，而这正是开发人员的直接责任。
数据安全是一个深不见底的领域，我甚至无法在一篇文章中触及皮毛。但是，我想介绍一些开发人员必须了解的基本术语，以确保他们的应用程序安全。你可以将其看作是应用数据安全入门 101 课程。
让我们开始吧！
哈希
如果您想获得一个高度严格的定义，可以参考维基百科，但简单来说，哈希是将数据转换为另一种形式的过程，转换后的信息是不可读的。例如，使用众所周知（且非常不安全）的Base64编码，字符串“我的秘密对你安全吗？”可以转换为（“哈希”）“SXMgbXkgc2VjcmV0IHNhZmUgd2l0aCB5b3U/”。 例如，如果您开始以 Base64 格式编写私人日记，您的家人将无法读取您的秘密（除非他们知道如何从 Base64 解码！）
这种对数据进行加扰的思想被广泛应用于存储网络应用程序中的密码和信用卡号等敏感信息（实际上应该应用于所有类型的应用程序）。这样做的目的是，如果数据被泄露，攻击者不应该能够使用密码或信用卡号造成实际损害。通常会使用高度健壮和复杂的算法进行哈希处理，像 Base64 这样的算法根本不堪一击，很容易被攻击者破解。
密码哈希使用一种称为单向哈希的加密技术，这意味着虽然可以对数据进行加扰，但无法将其解密。那么，当您登录时，应用程序如何知道这是您的密码？实际上，应用程序会使用相同的哈希过程，将您刚刚输入的密码的哈希值与数据库中存储的哈希值进行比较。如果两个哈希值匹配，您就可以成功登录！
当提到哈希时，这里有一些有趣的事情。如果您曾经从互联网下载软件或文件，您可能会被告知在使用这些文件之前先验证它们。例如，如果您想下载 Ubuntu Linux ISO，下载页面会提供一个选项来验证您的下载。如果单击该选项，将会打开一个弹出窗口：
弹出窗口会提示您运行一个命令，该命令本质上是对您刚刚下载的整个文件进行哈希处理，并将结果与您在下载页面上看到的哈希字符串进行比较：5fdebc435ded46ae99136ca875afc6f05bde217be7dd018e1841924f71db46b5。这种转换过程使用了SHA256算法，您可以在命令的末尾看到它的身影：shasum -a 256 –check。
这样做的目的是，如果您计算出的哈希值与提供的哈希值不同，则表示您的下载被篡改，您得到的文件可能被植入了恶意软件。
在密码哈希领域，您可能会听到一些熟悉的名字，如 MD5（不安全且已失效）、SHA-1和 SHA-2（一系列算法，包括 SHA-256 和 SHA-512）、bcrypt 等。
盐
所有类型的安全措施都是一场猫捉老鼠的游戏：窃贼了解现有的系统，并想出新的破解方法，而锁匠则不断改进他们的设计。密码学也不例外。尽管将哈希值转换回密码已经变得不可能，但随着时间的推移，攻击者开发出了复杂的技术，将智能猜测与强大的计算能力相结合。因此，在许多情况下，只要给定哈希值，他们就能预测出正确的密码。
“先生，我猜是小精灵怪？！”
正因如此，加盐技术应运而生。这意味着密码（或任何其他数据）的哈希计算将基于两个因素的组合：数据本身以及攻击者无法猜测的新随机字符串。因此，通过加盐，如果要对密码“superman009”进行哈希处理，我们首先会选择一个随机字符串作为“盐”，例如“bCQC6Z2LlbAsqj77”，然后对“superman009-bCQC6Z2LlbAsqj77”执行哈希计算。生成的哈希值将与算法生成的通常结构不同，从而大大减少了智能逆向工程或猜测的可能性。
哈希和加盐都是非常复杂且不断发展的领域。因此，作为应用程序开发人员，我们通常不会直接处理它们。但是，如果我们了解这些概念，并做出更明智的决定，这对我们有很大的帮助。例如，如果您维护一个旧的 PHP 框架，并且发现它使用 MD5 哈希来存储密码，那么您就知道应该在用户账户创建流程中引入另一种密码库了。
密钥
在加密的上下文中，您经常会遇到“密钥”这个术语。到目前为止，我们一直在讨论密码哈希或单向加密，在这些过程中，我们会不可逆地转换数据，并破坏其原始形式。这对于日常实际使用来说是不理想的，例如，编写文档并通过电子邮件安全地发送，但接收者却永远无法读取它，这是没有意义的。因此，我们需要加密数据，以便信息仅对发送方和接收方可见，而在传输或存储过程中保持不可读状态。
为此，密码学中引入了“密钥”的概念。它就像一把锁的钥匙。拥有信息的人使用一个称为密钥的秘密来加扰数据。除非接收者或攻击者拥有此密钥，否则无论他们使用的算法多么复杂，都不可能解密数据。
密钥轮换
虽然密钥使加密变得可行和可靠，但它们也存在密码所具有的风险：一旦有人知道了密钥，整个安全性就荡然无存。假设有人破解了 GitHub 等服务的某些部分（哪怕只有几秒钟），并获得了 20 年前的代码。在代码中，他们还发现了用于加密公司数据的密钥（将密钥与源代码一起存储是非常糟糕的做法，但这种情况发生的频率会让你感到惊讶！）。如果公司不改变其密钥（就像密码一样），则可能继续被利用。
因此，频繁更换密钥的做法应运而生。这被称为密钥轮换，如果您使用任何可靠的云 PaaS 提供商，它应该以自动服务的形式提供。
图片来源：AWS
例如，AWS 提供一项专门服务，称为 AWS 密钥管理服务 (KMS)。自动化的服务为您省去了在所有服务器之间更改和分发密钥的麻烦，对于大规模部署而言，这非常有帮助。
公钥加密
如果之前有关加密和密钥的所有讨论让您感觉很麻烦，那么您的感觉是正确的。安全地存储密钥并传递它们，以便只有接收者才能查看数据，这会带来后勤问题，这些问题可能会阻碍当今安全通信的蓬勃发展。但是，多亏了公钥密码学，我们才能够安全地在线通信或购物。
这种类型的密码学是一项重大的数学突破，也是互联网没有因恐惧和不信任而崩溃的唯一原因。算法的细节非常复杂且高度数学化，所以我只能在这里从概念上解释一下。
图片来源：电子前沿基金会
公钥密码术依赖于使用两个密钥来处理信息。其中一个密钥称为私钥，应该严格保密，绝不与任何人共享；另一个密钥称为公钥（名称的由来），应该公开分发。如果我要向您发送数据，我需要先获得您的公钥，然后使用该公钥加密数据并发送给您；最后，您可以使用您的私钥和公钥组合解密数据。只要您没有泄露您的私钥，我就可以向您发送只有您才能打开的加密数据。
这个系统的精妙之处在于，我不需要知道您的私钥，并且任何截获消息的人，即使拥有您的公钥，也无法读取它。如果您想知道这是如何实现的，最简短且最非技术性的答案来自素数乘法的特性：
计算机很难分解大素数。因此，如果原始密钥非常大，您可以确信即使在数千年内，消息也无法被解密。
传输层安全 (TLS)
现在您了解了公钥密码术的工作原理。这种机制（了解接收者的公钥并使用它向他们发送加密数据）是所有 HTTPS 流行的原因，也是 Chrome 显示“此网站是安全的”的原因。实际上，服务器和浏览器正在使用彼此的公钥加密 HTTP 流量（请记住，网页是浏览器可以解释的非常长的文本字符串），从而产生安全的 HTTP (HTTPS)。
图片来源：Mozilla。有趣的是，加密实际上并没有发生在传输层上；OSI 模型中没有提及加密数据。实际上，数据是在传递到传输层之前由应用程序（在本例中是浏览器）加密的，传输层随后将其发送到目的地，并在那里进行解密。但是，由于整个过程涉及到传输层，所以最终实现了数据的安全传输，因此“传输”层安全的这个不严格的术语一直存在。
在某些情况下，您甚至可能会遇到术语“安全套接字层”(SSL)。它与 TLS 的概念相同，只不过 SSL 出现的时间更早，现在已被 TLS 取代。
全盘加密
有时，安全需求非常强烈，以至于不能有丝毫的侥幸。例如，存储一个国家所有生物识别数据的政府服务器不能像普通的应用程序服务器一样配置和运行，因为风险太高。仅在传输过程中加密数据不足以满足这些需求；它还必须在静止时加密。为此，可以使用全盘加密来加密整个硬盘，以确保即使在发生物理损坏的情况下数据也是安全的。
需要注意的是，全盘加密必须在硬件级别完成。这是因为如果加密了整个磁盘，那么操作系统也会被加密，机器启动时将无法正常运行。因此，硬件必须知道磁盘内容已加密，并且必须在将请求的磁盘块传递给操作系统时即时执行解密。由于增加了这些额外的工作，全盘加密会导致读/写速度变慢，此类系统的开发人员必须牢记这一点。
端到端加密
如今，由于大型社交网络不断爆出的隐私和安全问题，即使与应用程序的构建或维护无关，也很少有人不知道“端到端加密”这个词了。
我们之前已经了解到，全盘加密是如何提供最终的防弹策略的，但这对于日常用户来说并不方便。我的意思是，想象一下，如果 Facebook 希望保护存储在你手机中的数据安全，但同时又不能访问手机中的其他任何数据。
出于这个原因，这些公司开始采用端到端加密，这意味着数据在应用程序创建、存储或传输时都被加密。换句话说，即使数据到达接收者手中，它也仍然是完全加密的，并且只能通过接收者的手机访问。
图片来源：谷歌
请注意，端到端 (E2E) 加密不像公钥密码术那样具有任何数学保证；它只是标准的加密方式，其中密钥与企业一起存储，并且您的消息的安全性取决于企业的决定。
结论👩🏫
您可能已经听说过大部分的术语，甚至可能全部都听说过。如果是这样，我鼓励您重新审视您对这些概念的理解，并评估您对它们的重视程度。请记住，应用程序的数据安全是一场你必须赢得每一次（而不是偶尔）胜利的战争，因为即使是一次违规也足以摧毁整个行业、职业甚至生命！