[think]数据安全分析不应该想当然

=Start=

缘由:

起因是有个数据安全的case排查,需要对企业内部的GitLab系统日志做分析后给出是否存在异常的结论。现在记录了好几种类型的GitLab日志,但我简单试了试之后发现能对做判断有帮助的当前主要是 gitlab-shell.log 这个日志,其中有个 command 字段的取值主要有 “git-upload-pack” 和 “git-receive-pack” ,虽然从英语字面意思上能猜个大概,但保险起见还是实际测试验证一下,最后发现猜想和实际相去甚远,再结合之前的一些经历和想法,所以简单闲扯几句。

PS:其实很早就发现类似的问题了,但是我好像已经慢慢开始习惯这个现状了(可能和不同人的实际工作状态、习惯有关,不一定是想这样,但体现到实际结果上确实就是这么个情况)。节后这两天相对来说没有那么忙,又就着一个现成的问题再简单记录一下,方便以后回顾。

正文:

参考解答:

网上流传较广的日志字段格式说明:

gitlab-shell.log
**注意:此日志只记录Gitclone协议的操作

……
日志中有价值的信息:

* 同步动作:command:gitaly-receive-pack
* 推送操作:command:gitaly-upload-pack
……

实际测试情况记录:

  • git clone/fetch/pull 在后端shell-log里面记录的是command是 “git-upload-pack” 不要被英文含义给带偏了。
  • git push 在后端shell-log里面记录的是command是 “git-receive-pack” 和clone的含义刚好是反的,不注意研究还真看不出来。

# production_json.log
It contains a structured log for Rails controller requests received from GitLab

# production.log
It contains information about all performed requests

# api_json.log
It helps you see requests made directly to the API

# application.log
It helps you discover events happening in your instance such as user creation and project removal

# application_json.log
It contains the JSON version of the logs in application.log

# gitlab-shell.log
GitLab Shell is used by GitLab for executing Git commands and provide SSH access to Git repositories.
User clone/fetch activity using SSH transport appears in this log as executing git command <gitaly-upload-pack....

个人觉得一个比较理想的数据安全分析流程(SOP)大概是这样的:

  1. 先有需求(需求方可以是老板、业务方、已发生待调查的case、未发生但根据经验极有可能出case的点……);
  2. 再判断需求的合理性,以及可行的解决方案列表,选出当前最合适的一个方案;
  3. 方案定了,需要分析的日志基本也就确定了,剩下的就是寻求日志的官方介绍/说明(对于开源的应用,就是官方文档/甚至是代码;对于内部应用,就是开发同学的说法/相关代码);
  4. 如果已有日志表了,那就申请对应日志表的权限(没有的话就再等等)看看日志的大致情况(数据量级、记录的操作类型、涉及用户量等概况信息);同时也要申请一个相关系统的账号,用于自己登录上去实际看看系统具备的功能,熟悉一下系统的大致功能,同时等有日志了也对比看看你的操作和实际日志记录情况是否符合,如果相符那就最好,如果不相符就需要找开发进一步确认了。
  5. 如果第4步做的比较好的话,其实也就差不多了;但是很多人在第4步只是走了一个过场,领导问看到日志没有?TA说看到了,有日志。领导问日志记录的全不全?TA说每天的日志量都挺大的,应该是全的?一般的领导应该不会再问了,毕竟再问下去就剩自己动手做了,领导自己事情也多,没办法什么都帮你把关;最核心的还是你自己要具备一种打破砂锅问到底的求索精神,事情既然交给你了,你就有责任把事情做好,交付一个好的结果,具体应该怎么做其它人并不关心。

==

  1. 申请相关系统账号,方便必要的时候进行测试和验证;
  2. 申请相关日志权限,了解日志的实际记录情况;
  3. 对照实际测试操作情况检查日志记录情况; #不要想当然,拿实际结果说话
  4. 对照检查OK则通过;否则需要推动开发进行自查自纠,直到对照检查通过为止。 #在开发写日志时也要注意一下命名和实际含义的区别不要太大,比如明明是个下载操作,日志里却有upload的关键字
  5. 还有很重要的一些点(但很多人都会漏掉的):
    梳理并建立一个日志统计大盘,用于了解相关日志的变化趋势,方便事后快速定位问题发生日期; #事出反常必有妖,如果有问题,大盘的某个趋势图中应该能有所体现,如果不能的话那个图可能需要重新画了
    自动定期拨测,通过配置告警实现异常实时通知。 #大盘只有大趋势,拨测可以细化到具体接口/功能,能提供百分比、具体时间段等更细节的信息

参考链接:

https://docs.gitlab.com/ee/administration/logs.html#gitlab-shelllog

gitlab Clone Pull Push 日志信息
https://blog.csdn.net/wyounger/article/details/110956403

上面那篇文章的英文机翻版本
https://developpaper.com/gitlab-clone-pull-push-log-information/ #自动抓取文章并翻译为英文的一个网站,看上去好像还行,但其实不行

git pull 和 git fetch的区别?
https://www.zhihu.com/question/38305012

=END=

声明: 除非注明,ixyzero.com文章均为原创,转载请以链接形式标明本文地址,谢谢!
https://ixyzero.com/blog/archives/5154.html

《[think]数据安全分析不应该想当然》上的6个想法

  1. 《好好的数据工具箱——全链路全周期生态共赢价值赋能》
    https://zhuanlan.zhihu.com/p/398082765
    `
    前几天和朋友一起聚餐,当时大家在讨论一个非常质朴的择业问题——数据相关的工作里,如果三选一,是做数据运营好,还是数据分析更好,亦或是做数仓更好?

    小乙觉得:“做运营好,因为运营更贴近一个公司的业务,而业务是公司的核心所在。”
    小华觉得:“数据分析更好,因为这个角色,通常可以从更整体性的视角看待公司的业务。而且现在是数据时代,在这个时代,数据才是公司的核心资产。”
    小姬觉得:“做数仓工程师更好,因为数仓建设才能算是一门真正技术。荒年不饿手艺人,掌握一门过硬的技术,才能在多变的职业生涯中,有自己的不败之地。”

    不过在赞同的同时,好好突然生出一种危机感。在当下有道理的话、有争议的事,在三五年后,会是一番怎样的光景呢?

    “大多数人将职业生涯当做一场短跑比赛。然而事实上,事业生涯是一场至少45年的马拉松。”——《远见》布赖恩•费瑟斯通豪

    无论是选择哪一个岗位,在这样一个变化的时代,仅依靠单一的业务知识、分析能力、或数仓技术到底能不能支撑我们长久的职业发展?

    从需求的角度而言,招聘市场上的JD表明:目前,大多数公司期望的是更复合型的数据人才。
    从供给的角度出发,随着工具的发展,数据科学的应用门槛变得越来越低;数据分析方法与数仓技术,对人们来说变得越来越可及。所以,成为兼具业务知识、分析能力、数仓技术的复合型人才是可行的。
    `

  2. 数据治理:先保证数据质量,再谈数据驱动
    https://mp.weixin.qq.com/s/Zp3URv4sRWU8nsiACwQEKw
    `
    01 — 从DIKW金字塔模型到数据供应链

    要实现数据驱动,重要的是创建一个“数据供应链”,保证数据在从生产、采集、存储、加工、处理,到分析、应用的全过程中的数据质量,并且确保每个过程都是为业务目标而服务的。

    02 — 供给侧:重点关注的数据质量维度

    数据质量问题贯穿整个“数据供应链”。我们经常听到:“垃圾进,垃圾出”,这句话是指高质量数据分析结果,取决于高质量的数据输入,输入的数据质量低下,数据分析结果也叫没有什么价值。以及笔者经常提的“数据治理要从源头抓起”,也是说的这个意思。重点都在强调数据供给侧保障数据质量的重要性。数据供给侧更多的是站在数据生产者或数据管理者的角度看数据质量的,重点关注以下的5个数据质量维度。

    1、数据完整性。
    2、数据准确性。
    3、数据一致性。
    4、数据唯一性。
    5、数据有效性。

    03 — 需求侧:超越准确性的数据质量维度

    从数据供给侧(生产和管理的角度)来看,数据质量主要关注准确性。其目标是尽可能地将数据与现实世界的实体相匹配。通过实施数据清理、修复数据、转换等一系列数据管理工作旨在提高数据准确性。

    04 — 提升企业数据质量的8点建议
    1、业务需求和影响评估
    2、全面盘点和正确描述
    3、数据质量从源头抓起
    4、能选择的时候别输入
    5、建立数据驱动的文化
    6、DataOps——数据运营
    7、数据质量,防大于治
    8、数据质量成效评估

    # end
    数据驱动是依靠数据来赋能决策和运营,高质量数据无疑是实现数据驱动的保证。高质量数据意味着高质量的洞察力、值得信赖的分析报告,可优化的业务流程,更加良好的客户体验和更好的投资回报率。
    `

  3. 如何改进您的数据质量
    https://mp.weixin.qq.com/s/UV3rvB5g1i3fEAP4UQ2KqA
    `
    企业机构每年因糟糕的数据质量而造成的平均损失达到1290万美元。除了直接影响收入外,从长远来看,质量差的数据还会增加数据生态系统的复杂性,进而导致决策失误。
    随着企业越来越多地使用数据分析来帮助推动业务决策,企业日益重视其系统中的数据质量(DQ)。Gartner预测到2022年,70%的企业机构将通过指标来严格追踪数据质量水平并将数据质量提高60%,以此显著降低运营风险和成本。

    数据质量直接关系到决策的质量。高质量的数据能够提供更好的客户线索、对客户的更深入了解和更好的客户关系。数据质量是数据和分析(D&A)领导人需要不断提升的竞争优势。

    1. 确定数据质量改进将如何影响业务决策

    2. 定义“足够好”数据的标准

    3. 建立全企业机构数据质量标准

    4. 尽早并且经常使用数据剖析

    5. 设计和实施用于监测主数据等关键数据资产的数据质量仪表盘

    6. 从基于真实的语义模型转向基于信任的语义模型

    7. 将数据质量列为数据和分析治理委员会会议的议程

    8. 规定数据管理员角色的数据质量责任和操作步骤

    9. 在首席数据官团队或同等机构的领导下,建立一个跨业务部门和IT部门的数据质量专项工作组

    10. 建立数据质量审核作为发布管理的“关口”

    11. 定期向业务部门传达改进数据质量所带来的收益

    12. 充分发挥外部/业内同行团体的作用,例如来自厂商、服务提供商和其他老牌论坛的用户团体
    `

  4. 数据质量管理:6个维度,50个检查项!
    https://mp.weixin.qq.com/s/fzTxhpUglr3pgfAB6OPizA
    `
    01. 数据质量定义
    数据质量的高低代表了该数据满足数据消费者期望的程度,这种程度基于他们对数据的使用预期。数据质量必须是可测量的,把测量的结果转化为可以理解的和可重复的数字,使我们能够在不同对象之间和跨越不同时间进行比较。 数据质量管理是通过计划、实施和控制活动,运用质量管理技术度量、评估、改进和保证数据的恰当使用。

    02. 数据质量维度
    1、准确性:数据不正确或描述对象过期
    2、合规性:数据是否以非标准格式存储
    3、完备性:数据不存在
    4、及时性:关键数据是否能够及时传递到目标位置
    5、一致性:数据冲突
    6、重复性:记录了重复数据

    03. 数据质量分析
    数据质量分析的主要任务就是检查数据中是否存在脏数据,脏数据一般是指不符合要求以及不能直接进行相关分析的数据。脏数据包括以下内容:
    1、缺省值
    2、异常值
    3、不一致的值
    4、重复数据以及含有特殊符号(如#、¥、*)的数据

    04. 数据质量管理
    大多数企业都没有一个很好的数据质量管理的机制,因为他们不理解其数据的价值,并且他们不认为数据是一个组织的资产,而把数据看作创建它的部门领域内的东西。缺乏数据质量管理将导致脏数据、冗余数据、不一致数据、无法整合、性能底下、可用性差、责任缺失、使用系统用户日益不满意IT的性能。
    在做数据分析之前一般都应该初步对数据进行评估。初步数据评估通过数据报告来完成的,数据报告通常在准备把数据存入数据仓库是做一次,它是全面跨数据集的,它描述了数据结构、内容、规则、和关系的概况。通过应用统计方法返回一组关于数据的标准特征,包括数据类型、字段长度、列基数、粒度、值、格式、模式、规则、跨列和跨表的数据关系,以及这些关系的基数。初步评估报告的目的是获得对数据和环境的了解,并对数据的状况进行描述。
    `

  5. 谈数据:数据质量管理的10个最佳实践
    https://mp.weixin.qq.com/s/F7xtDrMSaAFojwua71gIWQ
    `
    数据质量管理需要的是工匠精神,需要不断地对您拥有的数据进行反复“打磨”,循环迭代,将数据治理“常态化”,而不是指望实施一个项目就能实现数据质量的百分百提升。

    关于如何做好数据质量的管理,我们给出以下10条最佳实践,希望对您有所启发。

    01 – 对齐业务目标!

    02 – 评估数据质量

    03 – 分析根本原因

    04 – 制定解决方案

    05 – 控制数据质量

    06 – 纠正数据问题

    07 – 组织体系保障

    08 – 质量考核体系

    09 – 先进技术赋能

    10 – 在数据生命周期中关注数据质量

    数据的生命周期从数据规划开始,中间是一个包括设计、创建、处理、部署、应用、监控、存档、销毁这几个阶段并不断循环的过程。企业的数据质量管理应贯穿数据生命周期的全过程。

    数据规划。从企业战略的角度不断完善企业数据模型的规划,把数据质量管理融入到企业战略中,建立数据治理体系,并融入企业文化中。
    数据设计。推动数据标准化制定和贯彻执行,根据数据标准化要求统一建模管理,统一数据分类、数据编码、数据存储结构,为数据的集成、交换、共享、应用奠定基础。
    数据创建。利用数据模型保证数据结构完整、一致,执行数据标准、规范数据维护过程,加入数据质量检查,从源头系统保证数据的正确性、完整性、唯一性。
    数据使用。利用元数据监控数据使用;利用数据标准保证数据正确;利用数据质量检查加工正确。元数据提供各系统统一的数据模型进行使用,监控数据的来源去向,提供全息的数据地图支持;企业从技术、管理、业务三个方面进行规范,严格执行数据标准,保证数据的规范化输入,标准化。
    `

  6. Informatica:数据质量管理六步法
    https://mp.weixin.qq.com/s/JUWxWU60JrFa0hAtjjvXfQ
    `
    01 – 探查数据的内容、结构和异常

    02 – 建立度量并定义目标
    接下来,需要在关键应用数据字段中明确衡量数据质量的度量标准,并为每个数据字段明确各自的数据质量目标。该度量标准应基于数据质量的以下六个维度:

    * 完整性:哪些数据丢失或不可用?
    * 符合性:哪些数据以非标准格式存储?
    * 一致性:哪些数据值提供相互矛盾的信息?
    * 重复性:哪些数据记录或属性是多余的?
    * 整体性:哪些数据未被引用或遭受其它损害?
    * 准确性:哪些数据是不正确或过时的?

    03 – 定义和实施数据质量规则

    04 – 将数据质量规则构建到数据集成过程中

    05 – 检查异常并完善规则

    06 – 监控数据质量与目标

    笔者一直的观点:数据质量管理需要的是工匠精神,需要不断地对您拥有的数据进行反复“打磨”,循环迭代,将数据治理“常态化”,而不是指望实施一个项目就能实现数据质量的百分百提升。
    `

    The Informatica Data Quality Methodology – A Framework to Achieve Pervasive Data Quality Through Enhanced Business-IT Collaboration
    https://www.informatica.com/downloads/7130-DQ-Methodology-wp-web.pdf
    `
    Step 1: Profile the Data for Content, Structure, and Anomalies
    Step 2: Establish Data Quality Metrics and Define Targets
    Step 3: Design and Implement Data Quality Business Rules
    Step 4: Build Data Quality Rules into Data Integration Processes
    Step 5: Review Exceptions and Refine Rules
    Step 6: Monitor Data Quality Versus Targets
    `

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注