重新整理 | 屠敏
公司出品 | CSDN（ID：CSDNnews）
据彭博社 BleepingComputer 报导，白俄罗斯重要信息技术巨擘 Yandex 源标识符存储库险遭外泄，在两个非主流的骇客高峰论坛上，该源标识符库被以 Torrent 磁链的形式对内呈现出。
不过，Yandex 在这份新闻稿中则表示，他家子公司并不是遭了骇客攻击，而要一名雇主信以为真，最后这名雇主也变为了 ” 第三任 “。
Yandex 大部份主要就服务项目的源标识符遭泄露
Yandex 另一间子公司，总之许多人也并不孤单，它是白俄罗斯最大的 IT 子公司之一。其提供更多的服务项目要比欧美国家的 Google、国内的腾讯或穆萨腾讯要大得多，为此，也没人赞扬道，能想像呵呵，一间子公司能替代 Google、Uber、Amazon、Netflix 和 Spotify 是什么基本概念。
在骇客中文网站上，告密者标示了两个名叫 Yandex git sources 的文档，其中暗含 Yandex 数款服务项目的源标识符，具体文本主要就包括了 2022 年 7 月外泄者从该子公司盗取的 44.7GB 的文档，而这些标识符库全面覆盖除 Yandex 反流氓应用软件准则外的大部份源标识符。
为此，欧美国家一名应用软件技师 Arseniy Shestakov 综合性了大部份申明重要信息，更进一步预测了 Yandex 服务项目源标识符文本，最后有了一些捷伊发现。其则表示，” 看上去最少 Yandex 大部份主要就服务项目的源标识符都被外泄了。”
具体文本主要就包括：
Yandex 浏览器和检索机器
Yandex 世界地图
Alice（AI 音频副手）
Yandex 的士服务项目
Yandex 或非（电视广告服务项目）
Yandex 邮件
Yandex Disk（云存储服务项目）
Yandex 市场服务项目（有些类似于Amazon）
Yandex 旅行服务项目（旅游预订平台）
Yandex360（工作空间服务项目）
Yandex 云服务项目
Yandex Pay（支付处理服务项目）
Yandex Metrika（互联网预测服务项目）
此次数据外泄的规模有些超乎想像。与此同时，据 Arseniy Shestakov 深挖发现，大部份外泄文档的日期都能追溯到 2022 年 2 月 24 日。
标识符解析
稍微值得庆幸的是，这些文档主要就是存储库的文本，不包含 git 历史记录，且大多数应用软件没有预构建的二进制文档，只有少数例外。因此，这次外泄的重要信息没有个人数据，此外，没有内部工具的标识符本身也不太可能完全重现出一些 Yandex 的服务项目。
不过，有一些开发者倒是从外泄的源标识符中发现了一些不同之处。来自加拿大的一名骇客 Aubrey Cottle 注意到，通过 Yandex 外泄的标识符文档显示，该搜索平台包容种族主义，通过一些标识符就能显而易见。
Yandex 紧急回应
据网友统计，Yandex 此次外泄的文档包含了子公司 79 个服务项目和项目的标识符。面对如此大规模的外泄事件，Yandex 也快速地进行了回应，其发言人 Polina Pestova 则表示：
Yandex 没有被骇客入侵。我们的安全服务项目发现了申明可用的内部存储标识符片段，但是它们的文本与 Yandex 服务项目中使用的当前存储库版本不同。
存储库是用于存储和处理标识符的工具，大多数子公司在内部都是以这种形式使用标识符。存储库是处理标识符所必需的形式，而不是用于存储个人用户数据。我们正在对向公众发布源标识符片段的原因进行内部调查，但我们没有看到对用户数据或平台性能的任何威胁。
不过据 BleepingComputer 报导，Yandex 前高级系统管理员、开发副主管兼传播技术总监 Grigory Bakunov 在探讨这一次的泄漏事件时则表示，数据外泄的动机是政治性的，好在此次涉及数据外泄的 Yandex 雇主并没有试图将标识符出售给竞争对手。
这位前高管补充道，泄漏不包含任何客户数据，因此不会对 Yandex 用户的隐私或安全构成直接风险，也不会直接威胁泄漏专有技术。
Yandex 使用一种名叫为 “Arcadia” 的单存储库结构，但并非大部份子公司的服务项目都使用它。此外，即使只是为了构建服务项目，开发者也需要大量的内部工具和专业知识，因为标准的构建过程不适用。
外泄的存储库仅包含标识符；另两个重要部分是数据。关键部分，如神经网络的模型权重等，都不存在，所以它几乎没用。
尽管如此，还是有很多有趣的文档，如两个名叫 “blacklist.txt” 的文档，可能会暴露 Yandex 的工作服务项目。
当然，不容忽视的是，骇客还是能利用这些源标识符来寻找 Yandex 服务项目的漏洞等。
重要信息技术子公司如何防止内部雇主背后的 ” 小动作 “？
此次由内部雇主引发的外泄事件一经披露，也引发了许多重要信息技术子公司的警觉。毕竟近几年来，内部员工 ” 删库跑路 ” 早已屡见不鲜，一旦遇上，虽然能追责，但对子公司自身的发展带来的伤害和损失在一定层面已经无法挽回，因此，如何从内部尽可能地减少此类事件的发生，也成为各家企业颇为关注的问题。
在此，一位开发者 Frank Forte 也从安全性限制方面总结了几点建议，希望对大家有所裨益：
一、限制技师、运维等岗位雇主对标识符的访问。
企业能设置单独的标识符存储库，只允许雇主访问他们需要查看和处理的部分标识符。或许也能为此使用 Bitbucket（基于 Web 的版本库托管服务项目）之类的东西，然后在每个 repo 上设置权限。
然后企业能编写脚本将不同的存储库组合成最后产品。
这将方便企业便于管理，能够使敏感标识符远离新雇主或外包人才。
不幸的是，如果子公司的标识符是紧密耦合的，这几乎是不可能的，因为大部分标识符需要成为正在构建或测试的项目的一部分。
分割标识符并不能防止标识符外泄，但它确实在一定程度上起到限制作用。
二、拟定强有力的雇主合同
通过这份完善的雇主合同，能阻止雇主外泄标识符。因为一旦涉及到泄密，可能会被抓捕、起诉，还可能会限制未来的工作前景，因为没有子公司会希望自己招聘的新雇主被波及到一些因专有标识符而被起诉的案件中。
三、有明确的雇主政策
让子公司内部雇主清楚地了解什么是 ” 泄漏标识符 “。在 Stack Overflow 等高峰论坛上发布大量标识符以获得帮助可能会无意中外泄重要信息。告诉他们不要这样做，并对这样做的处罚。
四、登录并维护权限和访问权限
企业内部管理层应该及时了解技师谁有权访问以及他们何时有权访问一些系统。当技师不再需要相关系统权限时，应立即删除访问权限。
当然，以上仅是从一些大的维度来分享一些防御措施，更为关键的是还是需要企业自身学会识人、用人，为此，你还有什么样的防御建议，欢迎留言分享 ~~
参考链接：
https://www.quora.com/How-do-tech-companies-make-sure-that-employees-can-t-steal-or-leak-their-source-code
https://www.bleepingcomputer.com/news/security/yandex-denies-hack-blames-source-code-leak-on-former-employee/
https://arseniyshestakov.com/2023/01/26/yandex-services-source-code-leak/
