担心你的应用程序的抗量子能力是一个完全合理的担忧。但是，在这篇博文中，我将退一步，描述一些简单但容易被忽视的安全提示。在许多情况下，一行配置可以保护你的网络应用程序免受一系列的攻击。
当然，即使拥有所有描述的解决方案，也不意味着你的应用程序现在是安全的。但是，如果没有它们，潜在攻击的范围就会大大增加。
1.HTTP安全标头
这些头文件通常是我在进行Rails性能和安全审计时首先检查的内容。
来自securityheaders.com的安全标头报告样本
它们中的大多数都不需要定制，所以提高应用程序的安全性就像在你的NGINX或后端服务器上添加一个配置行一样简单。
一个例外是Content-Security-Policy。它必须进行微调以允许你的网站与外部资源互动。手动操作可能有点麻烦，但有一个Mozilla的浏览器扩展。当你点击你的网站时，它会自动生成一个正确的CSP头值。
你可以查看链接的cdn网络文档，以获得关于这些头的更多深入信息。
2.双因素认证
为你的网络应用程序实施2FA可能是一个具有挑战性的过程。但是，在你的开发和支持团队使用的服务中启用它，通常是在用户界面中点击几下就可以了。这可能是保护你的项目免受一系列账户接管攻击的最简单方法。
查看链接的文档，解释如何在用于网络开发的流行服务中启用并选择性地强制执行双因素认证。
Heroku -启用2FA
AWS -启用2FA
Discord -启用2FA
我通常建议在1Password中存储2FA代码，只使用单独的设备或YubiKye作为1Password本身的第二因素。1Password通过浏览器扩展提供无缝的登录整合，还可以通过验证网站来保护用户免受网络钓鱼攻击。
3.电子邮件安全功能
如果你的域名用于发送电子邮件，你应该确保你已经正确配置了SPF（发件人政策框架）、DKIM（域名密钥识别邮件）和DMARC（基于域的消息验证报告和一致性）。正确地配置它们都将防止你的公司受到电子邮件欺骗，即恶意行为者和垃圾邮件发送者试图冒充它。详细解释这些安全机制以及如何配置它们，超出了本博文的范围。请查看链接的 Cloudflare 文档以了解更多信息。但是，这里有一个简短的总结。
SPF的工作方式就像一个允许列表，允许那些应该能够从你的域名发送电子邮件的来源。[更多信息］
DKIM允许以加密方式验证电子邮件是由 DNS 记录中配置的来源产生的。[更多信息］
DMARC描述了其他服务器应如何对待来自你的域名的电子邮件的政策。[更多信息］
在这里你可以验证你的域名是否已经被保护。
所有这些安全功能都是在DNS层面上配置的。对于DKIM，需要在电子邮件提供商处进行额外的配置，所以请查看他们各自的文档。
即使，或者特别是，如果你的域名不是用来发送邮件的，你可以使用正确的DMARC策略明确地拒绝它。
4.安全地传输文件
公司聊天通常是分享数据的首选方式，不幸的是甚至是敏感数据。如果没有围绕哪些第三方集成可以连接到您的聊天应用程序的更复杂的安全政策，它可能成为关键数据泄漏的来源。例如，一个恶意的聊天插件可以要求读取公共频道的信息，而你的公司政策没有强制限制谁可以连接类似工具。聊天应用程序也不能幸免于安全漏洞，所以不信任它们是一个明智的默认。
即使是通过电子邮件分享敏感数据，也应该被劝阻。附件会永远留在第三方服务器上，所以任何账户的接管都会让攻击者获得所有的数据。
建立一个安全共享敏感数据的框架可以使你的公司避免不必要的麻烦。有一个工具可以达到这个目的，那就是Magic Wormhole。它的使用相对简单，即使是团队中技术含量较低的成员也可以使用。你可以通过使用一次性密码的直接连接来共享文件，而且数据不会被持久化。
一个商业上的替代方案可以是通过共享的1Password保险库来同步文件。但与Magic Wormhole相比，除非明确删除，否则共享文件会保留在保险库中。
5.AWS IAM策略
许多Web应用程序使用AWS只是为了与单个S3桶进行交互。不幸的是，一些教程推荐使用AdministratorAccess ，甚至是AWS根用户凭证，作为连接你的Web应用到AWS的快速和简单的方法。授予你的网络应用一个管理AWS的权限可能会产生关键的后果。特别是如果多个应用程序共享同一个AWS账户。一个受损的应用程序可以访问甚至不可逆转地删除不同项目的数据。或者你的信用卡可能被一个比特币挖矿机器人吸走。
如果你的应用程序与单一的S3桶对话，那么你可能应该使用IAM用户凭证与类似的自定义策略。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::your-bucket-name"
]
},
{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:DeleteObject",
"s3:PutObjectAcl"
],
"Resource": [
"arn:aws:s3:::your-bucket-name/*"
]
}
]
}
请查看我的另一篇博文，了解配置S3 IAM策略的逐步指南。它是在Ruby on Rails的背景下写的，但也适用于所有的后台技术栈。
总结
实施上述任何提示都不应该超过几个小时。然而，它们却能保护我们免受具有潜在严重后果的攻击。
