Kode Vicious - @kode_vicious
PDF使用 KV 进行日志记录
一些读者阅读 Kode Vicious 是为了幽默。另一些读者阅读他是为了批判软件开发领域中的生活。但在他引人入胜的形象之下，隐藏着忠实读者每月寻找他的统一原因：他对所有程序员面临的实际问题提出的宝贵建议。尽管篇幅限制常常使他无法充分处理任何一个问题，但 KV 至少肯定能让你朝着正确的方向思考……有时，这正是你所需要的。
尊敬的 KV，
我一直忙于为公司新的支付处理系统编写日志系统。正如你可能想象的那样，这需要记录大量数据，因为我们必须能够在每个结算周期结束时将日志中的数据与我们的客户和其他用户（如信用卡公司）进行核对，并且我们必须为任何关于账单本身的争议做好准备。
我被指派这项工作有两个原因：因为我是团队中最资历最浅的人，并且因为没有人认为编写另一个日志系统非常有趣。团队中的其他人没有给我太多帮助，他们声称“他们编写的日志系统比他们想到的还要多得多”。你对编写一个合适的日志系统有什么建议吗？
已注销
尊敬的已注销，
如果你的这么多队友以前编写过日志系统，那么为什么你不使用那些系统呢？也许你的队友在对你撒谎，并且从未编写过一行日志系统代码，或者也许——我怀疑这可能更可能——他们尝试过，但他们的系统烂透了。或者也许我只是在愤世嫉俗。
事实证明，编写一个好的日志系统，就像编写任何好的软件一样，既困难又罕见。你的许多决定将取决于对你正在记录的数据的要求，并且由于你正在记录金融交易，因此你有很多要求，其中一些要求必须包括保持数据私密性、审计日志以查找错误以及验证日志中包含的数据是否未被篡改的能力。
数据隐私现在是我们行业中的一件大事。不幸的是，对于过去几年因泄露私人数据而闻名的公司（例如 ChoicePoint、美国银行、富国银行和安永）来说，它还不够重要，但他们现在都为此感到痛苦。个人数据泄露现在是一个如此大的问题，以至于一些政府已经颁布了严厉的立法来惩罚这些违法者，我认为你会想避免这种惩罚。我知道我会。
保持数据私密性的最佳方法是不存储它。存储数据使其有可能被泄露，这似乎是显而易见的，但话又说回来，每次我认为某件事是显而易见的时候，我最终都会读到一条新闻，告诉我，不，还不够显而易见。只保留你需要支持你所需要提出的任何声明的数据，并且不要将数据保留太久。大多数金融机构对他们保留数据的时间都有限制。严格遵守你产品的相关规定，并且不要将任何东西保留超过你需要的秒数。
一旦你缩小了你实际需要保留在日志中的事物列表，请决定哪些可以被盲化，哪些必须加密，哪些可以保持公开。盲化数据意味着它被销毁，但以使其唯一的方式销毁。哈希函数是执行此操作的好方法。给定任何输入，一个好的哈希函数会产生唯一的、看似随机的输出。考虑以下在我的 Mac 上使用 md5 程序的示例
? md5 -s “1234 5678 9012 3456”
MD5 (“1234 5678 9012 3456”)
= d135e2aaf43ba5f98c2378236b8d01d8
? md5 -s “1234 5678 9012 3457”
MD5 (“1234 5678 9012 3457”)
= 0c617735776f122a95e88b49f170f5bf
给定两个看起来像虚假信用卡号码的字符串，其中只有一个数字在一个位置不同，md5 程序会生成看起来像两个不同的随机数。如果你能在这些数字中找到模式，请联系你当地的军情六处或同等机构，因为他们在信号部门为你准备了一份工作。
这两个数字不仅看似随机，而且也是唯一的，这意味着它们可以作为在你的数据日志记录中使用的良好主键。每个带有这些数字的日志条目都唯一地标识了信用卡，但是阅读日志的人无法从哈希值中找出原始信用卡号码。盲化可以用于各种数据，但绝对最好将其用于如果被盗或泄露可能会被他人使用的事物。
如果有你绝对必须能够以其原始形式再次使用的数据——也就是说，它不能被盲化——那么就该开始加密了，至少如果该数据有价值的话。我惊讶于许多人费尽心思加密数据库和实时系统中的数据，然后只是草率地以明文形式将所有数据扔进日志中。我想我应该停止感到惊讶，但这比我用头撞桌子、墙壁、地板或相关工程师要好。
哪些类型的数据可能需要在你的日志中保密？不可能列出详尽的清单，但当然，个人的详细信息，例如全名、地址、电话号码、手机号码和电子邮件地址，是一个好的开始。在你这样做的时候，支付金额、支付地点和其他支付细节也应该保密，因为它们使你的日志成为试图挖掘你公司财务数据的人的诱人目标。你可能会问，“好吧，还剩下什么？” 我不得不说，在金融系统中，可能不多，但我确信有一些用于调试目的的数据可以以明文形式放入日志中。例如，条目生成的时间可能不会是秘密。
现在你已经消除了所有无关的数据，盲化了你可以盲化的数据，并且可能加密了其余的大部分数据，你必须确保日志本身是安全的，免受篡改。你需要做两件事来防止篡改：签署条目并签署日志，每个都使用不同的密钥。条目被签名以确保其有效性，而整个日志被签名以确保没有人手动添加或删除条目。使用两个不同密钥的原因是应该由两个不同的人拥有这些密钥，从而需要串通才能破坏系统的安全性。定期更改密钥也是一个好主意，这样如果密钥被盗，暴露的数据量就会最小化。
关于日志系统还有许多其他方面需要讨论，例如数据存储在哪里、数据可能或不可能跨网络移动、何时需要轮换日志以及如何编写工具来分析和读取日志。但我在这里介绍的是制作一个日志系统的基础知识，我希望这个日志系统不会很糟糕，并且不会轻易侵犯用户的隐私并使你的公司登上新闻头条。哦，还有最后一条建议：不要将日志留在你车里的笔记本电脑上。显而易见？当然，这很明显。
KODE VICIOUS，凡人称之为 George V. Neville-Neil，为乐趣和利润从事网络和操作系统代码工作。他还教授有关编程各个主题的课程。他感兴趣的领域是代码探险、操作系统和重写你的糟糕代码（好吧，也许不是最后一个）。他获得了马萨诸塞州波士顿东北大学的计算机科学学士学位，并且是 、Usenix 协会和 IEEE 的成员。他是一位狂热的自行车爱好者和旅行者，自 1990 年以来一直以旧金山为家。
最初发表于 Queue 第 4 卷，第 5 期—
在 数字图书馆 中评论本文
更多相关文章
Catherine Hayes, David Malone - 质疑非加密哈希函数的评估标准
尽管加密和非加密哈希函数无处不在，但在它们的设计方式上似乎存在差距。存在许多由各种安全要求驱动的加密哈希标准，但在非加密方面，存在一定程度的民间传说，尽管哈希函数历史悠久，但尚未得到充分探索。虽然针对真实世界数据集的均匀分布非常有意义，但当面对具有特定模式的数据集时，这可能是一个挑战。
Nicole Forsgren, Eirini Kalliamvakou, Abi Noda, Michaela Greiler, Brian Houck, Margaret-Anne Storey - DevEx 在行动
随着领导者寻求在财政紧缩和人工智能等变革性技术的背景下优化软件交付，DevEx（开发者体验）在许多软件组织中越来越受到关注。技术领导者直观地接受了良好的开发者体验能够实现更有效的软件交付和开发者幸福感。然而，在许多组织中，旨在改善 DevEx 的拟议举措和投资难以获得支持，因为业务利益相关者质疑改进的价值主张。
João Varajão, António Trigo, Miguel Almeida - 低代码开发生产力
本文旨在通过展示使用基于代码、低代码和极限低代码技术进行的实验室实验结果，研究生产力差异，从而提供对该主题的新见解。低代码技术已明确显示出更高的生产力水平，为低代码在短期/中期内主导软件开发主流提供了强有力的论据。本文报告了程序和协议、结果、局限性和未来研究的机会。
Ivar Jacobson, Alistair Cockburn - 用例至关重要
虽然软件行业是一个快节奏且令人兴奋的世界，其中不断开发新的工具、技术和技巧来为商业和社会服务，但它也很健忘。在快速前进的匆忙中，它容易受到时尚的摆布，并且可能会忘记或忽略已证实的解决它所面临的一些永恒问题的方法。用例于 1986 年首次引入，后来普及，是这些已证实的解决方案之一。
© 保留所有权利。