CN112564985A - 一种基于区块链的安全运维管理的方法 - Google Patents

一种基于区块链的安全运维管理的方法 Download PDF

Info

Publication number
CN112564985A
CN112564985A CN202011548632.3A CN202011548632A CN112564985A CN 112564985 A CN112564985 A CN 112564985A CN 202011548632 A CN202011548632 A CN 202011548632A CN 112564985 A CN112564985 A CN 112564985A
Authority
CN
China
Prior art keywords
log
blockchain
data
block chain
maintenance management
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202011548632.3A
Other languages
English (en)
Inventor
不公告发明人
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nanjing Liancheng Technology Development Co ltd
Original Assignee
Nanjing Liancheng Technology Development Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nanjing Liancheng Technology Development Co ltd filed Critical Nanjing Liancheng Technology Development Co ltd
Priority to CN202011548632.3A priority Critical patent/CN112564985A/zh
Publication of CN112564985A publication Critical patent/CN112564985A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/069—Management of faults, events, alarms or notifications using logs of notifications; Post-processing of notifications
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G06F16/278—Data partitioning, e.g. horizontal or vertical partitioning
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/28—Restricting access to network management systems or functions, e.g. using authorisation function to access network configuration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0643—Hash functions, e.g. MD5, SHA, HMAC or f9 MAC

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • Software Systems (AREA)
  • Power Engineering (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Data Mining & Analysis (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

本发明公开了一种基于区块链的安全运维管理的方法，其特征在于，能够为多家企业提供一体化的安全运维管理服务，将所述各个企业的日志采集模块连接到所述区块链系统节点上，对于每个传输到日志采集模块存储服务器的新的日志数据，生成一个包含哈希和当前时间戳的事务，该事务连同来自分布式系统中其它节点的事务一起被包含在一个区块中，当事务足够多时，或发生超时时，则会向区块链追加新的区块，并在区块链上存储所述新的区块所包含的事务信息，日志数据在区块链链下存储，在区块链链下存储的日志数据的可用性保护是通过本地副本来实现的。

Description

一种基于区块链的安全运维管理的方法
技术领域
本发明涉及区块链、安全管理和网络安全的技术领域，尤其涉及到一种基于区块链的安全运维管理的方法。
背景技术
日志数据由企业中的IT信息系统自动生成的。它提供了这些信息系统上发生的事件的信息，但在这其中也可能包含着恶意行为或网络攻击方面的事件信息，例如，拒绝服务攻击DOS/DDOS、木马恶意软件和对企业基础设施的其它类型的攻击。对这些日志数据的分析将有助于挖掘潜在的安全风险和维护企业的正常运营秩序。
如果入侵行为成功，最好能够调查、溯源和确定入侵者（将该入侵者告上法庭或对该企业内部员工进行处罚，但必须要有证据）。实际上，入侵者可能试图更改或删除记录入侵的日志。日志数据除了暴露入侵者对企业IT信息系统的恶意操作和修改之外，也被用于安全运维管理的过程中，例如，安全信息和事件管理SIEM（Security Information andEvent Management）和南京联成安思易集中管控系统。为了能够成功地定位和确定入侵者，企业必须为日志数据这个证据能够提供无可争辩的完整性证明。这一证据必须保证在整个过程中没有任何修改，使得在法庭上审判时入侵者或在企业处罚违反安全行为规范的内部员工仍然可以接受这个证据。
法律上可接受的数字证据的主要要求是重要性和真实性。为了使一件证据具有重要性，应当有一个持久的监护链。可靠和可核查的证据生成、证据传输和证据存储是这一监护链的一部分，也是站在法律角度上鉴定证据的先决条件。因此，可验证的生成过程是安全运维管理中进行安全审计的关键要求。
现有的技术已经开发了各种保护日志数据的安全来免受入侵者攻击的方法。这些已有技术通过使用只写或存储访问保护来完整地保存日志数据的证据。
发明内容
为了解决上述技术问题，本发明提供了一种基于区块链的安全运维管理的方法，基于区块链技术，实现安全运维管理。
一种基于区块链的安全运维管理的方法，其特征在于，能够为多家企业提供一体化的安全运维管理服务，将所述各个企业的日志采集模块连接到所述区块链系统节点上，对于每个传输到日志采集模块存储服务器的新的日志数据，生成一个包含哈希和当前时间戳的事务，该事务连同来自分布式系统中其它节点的事务一起被包含在一个区块中，当事务足够多时，或发生超时时，则会向区块链追加新的区块，并在区块链上存储所述新的区块所包含的事务信息，日志数据在区块链链下存储，在区块链链下存储的日志数据的可用性保护是通过本地副本来实现的。
进一步地，所述日志数据，被分为证据数据和完整性证明；
进一步地，所述证据数据，由实际的日志事件和相关的元数据组成，或者说，它由日志事件信息、生成系统标识符和签名，以及时间戳所组成。
进一步地，所述完整性证明，由一个时间戳的证据数据来表示，该证据数据在指定的时间确认日志事件的存在，并通过如下步骤来验证完整性证明：
从存储服务器抓取日志数据；
哈希Hash日志数据；
签名并将日志数据的哈希提交给区块链节点进行验证；
服务器将存储在区块链事务中的哈希值与提交的日志数据的哈希值进行比较；
如果找到一个相同的哈希值，则有不可否认的证据表明相同的数据是在较早的时间提交的，说明日志数据是没被篡改。
本发明的技术效果在于：
在本发明中，提供了一种基于区块链的安全运维管理的方法，其特征在于，能够为多家企业提供一体化的安全运维管理服务，将所述各个企业的日志采集模块连接到所述区块链系统节点上，对于每个传输到日志采集模块存储服务器的新的日志数据，生成一个包含哈希和当前时间戳的事务，该事务连同来自分布式系统中其它节点的事务一起被包含在一个区块中，当事务足够多时，或发生超时时，则会向区块链追加新的区块，并在区块链上存储所述新的区块所包含的事务信息，日志数据在区块链链下存储，在区块链链下存储的日志数据的可用性保护是通过本地副本来实现的。
附图说明
图1是一种基于区块链的安全运维管理的方法的不可抵赖服务的4个阶段的示意图；
图2是一种基于区块链的安全运维管理的方法的可审计的架构的示意图；
图3是一种基于区块链的安全运维管理的方法的处理日志数据序列的示意图；
图4是一种基于区块链的安全运维管理的方法的扩展框架的示意图；
图5是一种基于区块链的安全运维管理的方法的实施扩展架构的示意图。
具体实施方式
下面是根据附图和实例对本发明的进一步详细说明：
基于区块链的安全运维管理的方法，区块链的分布式架构在很多方面可以帮助安全运维管理，例如：
（1）利用区块链对其安全运维数据进行正确跟踪：在大多数人的一致意见下，防止其安全运维数据测量真值与假值的替代；
（2）使用区块链技术，安全运维数据可以在不涉及第三方建立信任的情况下交换数据，区块链为数据共享提供了分布式信任环境；
（3）安全运维管理的运营和部署成本可以降低，因为它支持P2P（Peer to Peer）通信；
（4）在数据不匹配的情况下，借助区块链技术的哈希机制，可以轻松检测出发生故障的设备；
（5）通过将区块链技术融入网络安全，可以形成一个运营成本低、效率高的安全运维管理环境。
遵循产品架构的方法，首先，阐述系统的需求和目标。基于这些需求，考虑在使用区块链系统时存储数据的可用选项，并描述了基于区块链的可审计日志系统的一般架构。在一个实施例中，还讨论了区块链网络运营的两种选择。
安全日志运维管理系统的总体目标是维护日志文件的可用性和完整性。由被管设备所生成的日志还应具有不可否认性，这意味着日志可验证地对应于特定设备/或系统上发生的事件。在安全日志中，由于篡改的日志可能包含有关危害系统的有价值信息，因此在解决争议期间会进行验证。所有阶段的先决条件是确定什么是构成的真正证据。对于IT信息系统的任何日志，都可能是重要的证据。为了可用性和完整性保护，将日志分为证据数据和完整性证明。证据数据由实际的日志事件和相关的元数据组成。具体来说，它由日志事件信息、生成系统标识符和签名以及时间戳。如果数据是使用虚拟机提取的，则签名由源系统或管理程序生成组成。完整性证明由一个时间戳的证据数据来表示，该证据数据在指定的时间确认日志事件的存在。如果此信息是以不可变方式存储的，则可以稍后使用它来证明证据数据自创建证据以来没有被更改。
图1是一种基于区块链的安全运维管理系统的不可抵赖服务的4个阶段的示意图；下面将加以分别描述：
证据生成：发生在日志源上，例如，连接到外部网络且易受入侵的那些IT信息系统。日志文件应包括用生成系统的私钥签名的数字签名。在本申请中，为每个系统生成一个唯一的公钥/私钥对；
证据传输：在证据传输阶段，日志事件随后从其源传输到存储服务器上。使用加密连接是维护保管链的必要条件；
证据存储：服务接收的任何日志数据都以保留可用性和完整性的方式存储，以便以后使用。这包括防止攻击者试图删除或修改跟踪。由于日志中包含的潜在敏感信息，保密性也是一个问题。已有的解决方案使用专用的附加硬件、第三方提供商或与外部公证系统结合的本地存储。本申请提供的方法通过在由独立节点组成的区块链网络上存储完整性证明来实现证据的不变性；
争议解决：争议解决就会发生，当发生入侵并记录在日志文件中时。入侵者可能试图否认证据的真实性。审计员必须能够验证日志自生成以来是没有被任何人修改的。该证据验证包括签名验证和完整性验证。对于签名验证，审计员必须有权访问生成源的相应公钥证书。完整性证明在本申请中由散列Hash和相应的时间戳来表示，并且必须存储在可证明的不可修改的存储中。它确保签名文件已经在要求的时间内存在。
为了克服已有技术的缺点，本申请使用区块链网络技术。使用区块链网络的好处是它不依赖付费的第三方服务提供商。相反，区块链节点运营商为彼此提供证据不变性服务。由于运营成本由所有成员平均分担，因此除了运营网络之外，不会产生额外成本。
基于区块链的解决方案有助于以保持完整性的方式存储日志文件。数据可以在基于区块链的解决方案中以链上或链下的方式存储。链上存储意味着在所有区块链节点上复制完整的日志数据。日志采集模块/或日志基础实施处理大量的数据，因此在每个节点的完整复制将使得安全运维管理平台的效率低下，并导致较高的存储成本。链上存储的另一个问题是隐私的丢失。日志数据可能无意中包含敏感数据，例如，用户名甚至密码哈希。链下存储将数据保存在本地数据库中，以满足隐私和保密要求。链下数据可以通过其散列Hash链接到相应的链上事务，前提是数据的散列Hash被包含在区块链中并未被修改过。
为了适应区块链的存储限制，本申请将日志存储分成链上存储和链下存储两个部分。证据数据存储在本地日志采集模块存储服务器/或日志基础实施中，防止未经授权的访问以保持机密性。链下数据的可用性保护是通过本地副本来实现的。商用硬件可以用来廉价地存储日志数据，同时避免数据丢失。Apache Kafka 2是一个分布式数据传输系统，它维护本地副本和容错日志，同时允许其它应用程序与数据交互。为了能够检测出链下数据的潜在损坏或修改，完整性证明存储在区块链上的事务中。网络由独立的安全运营服务提供商来维护，以确保任何一家企业都不能修改证明数据。基于区块链的分布式系统中的设备故障也被称为拜占庭（byzantine）故障。在本申请中，使用了一个拜占庭容错BFT（byzantine-fault tolerant）一致性算法来容忍3个f+1节点网络中最多f个拜占庭故障。
BFT状态机复制可以在没有区块链数据结构的情况下实现，以获得一定的吞吐量性能。然而，安全日志需要所述的额外的真实性和完整性保证。区块链提供了这些保证。
如图2所示，证据数据是由不同的源生成和签名的，例如ERP、防火墙、IDS（入侵检测系统）。生成的证据数据被安全地传输到所属企业的日志采集模块存储服务器上。
一种基于区块链的安全运维管理的方法，其特征在于，能够为多家企业提供一体化的安全运维管理服务，并能够确保各家企业的安全运维数据的完整性和高可用性，使用区块链的安全基础实施，将所述各个企业的日志采集模块/或日志基础设施连接到所述区块链系统节点上，对于每个传输到日志采集模块存储服务器/或日志基础设施存储服务器的新的日志数据，生成一个包含哈希和当前时间戳的事务，该事务连同来自分布式系统中其它节点的事务一起被包含在一个区块中，当事务足够多时，或发生超时时，则会向区块链追加新的区块，并在区块链上存储所述新的区块事务Transaction信息（可以用于完整性验证），日志数据在区块链链下存储，在区块链链下存储的日志数据的可用性保护是通过本地副本来实现的。
进一步地，所述日志数据，被分为证据数据和完整性证明；
进一步地，所述证据数据，由实际的日志事件和相关的元数据组成，或者说，它由日志事件信息、生成系统标识符和签名，以及时间戳所组成。
进一步地，所述完整性证明，由一个时间戳的证据数据来表示，该证据数据在指定的时间确认日志事件的存在，并通过如下步骤来验证完整性证明：
从存储服务器抓取日志数据；
哈希Hash日志数据；
签名并将日志数据的哈希提交给区块链节点进行验证；
服务器将存储在区块链事务中的哈希值与提交的日志数据的哈希值进行比较；
如果找到一个相同的哈希值，则有不可否认的证据表明相同的数据是在较早的时间提交的，说明日志数据是没被篡改。
审计员在核实证据时，实际证据数据保留在本地存储的副本中，并可应要求提供给审计员。为了验证证据数据的完整性，审计员首先根据来自PKI的有效公钥证书验证其签名。此步骤确保日志文件可以映射到其源。然后将数据的哈希提交给区块链节点进行验证。然后，服务器将存储在区块链事务中的哈希值与建议的证据的哈希值进行比较。如果找到一个相同的散列Hash，则有不可否认的证据表明相同的数据是在较早的时间提交的。为了容忍可能损坏的区块链节点，也可以独立地从多个区块链节点请求证明。
如图3所示，图3中详细说明了在处理每个日志时发生的数据流。出现两个处理步骤S1、S2，可选的验证步骤S3。为了描述这些步骤，本申请定义了以下形式表示法。每个企业j∈{1.n}都有一个标识符
Figure 688470DEST_PATH_IMAGE001
、一个私有签名密钥
Figure 44496DEST_PATH_IMAGE002
和一个对应的公钥
Figure 710838DEST_PATH_IMAGE003
。
客户端应用程序处理。首先定义了一个日志计数器k∈1，然后得到一个事务计数器i∈1.m。每个新到达的日志
Figure 505619DEST_PATH_IMAGE004
被解析为创建一个负载为
Figure 75272DEST_PATH_IMAGE005
的事务，它包含在一个新的事务
Figure 165981DEST_PATH_IMAGE006
中。最初，i=k，因为每个日志生成一个事务。Hash()是一个哈希函数，而sign()是公钥签名函数的缩写。假设
Figure 148980DEST_PATH_IMAGE006
通过加密通道从客户端应用程序传输到区块链节点，避免中间人（man-in-the-middle）类型的网络攻击；
Figure 419556DEST_PATH_IMAGE006
=(
Figure 404567DEST_PATH_IMAGE007
，
Figure 430292DEST_PATH_IMAGE008
)，其中：
Figure 572692DEST_PATH_IMAGE005
=(
Figure 210740DEST_PATH_IMAGE009
，
Figure 489405DEST_PATH_IMAGE004
)，
Figure 686031DEST_PATH_IMAGE010
=hash(
Figure 4143DEST_PATH_IMAGE004
)，
Figure 115056DEST_PATH_IMAGE008
=sign(
Figure 513807DEST_PATH_IMAGE011
)，
S2：区块链节点处理。在事务被传播到网络并被当前一致性领导者提议作为区块链的一部分之后，实际的处理则在区块链的每个节点上进行。每个事务都包含一个基于分布式一致性的时间戳，每个节点验证日志的唯一性：
Figure 943652DEST_PATH_IMAGE012
如果此条件失败，则事务不会对持久状态进行任何更改。如果条件通过且日志唯一，则将内容哈希到区块链事务哈希的映射被添加到字典中：（
Figure 222493DEST_PATH_IMAGE013
，hash(
Figure 638562DEST_PATH_IMAGE006
)）。这允许在验证期间进行有效的查找。超过三分之二的节点成功处理所述事务后，它将不可逆转地提交到分类账。为了图3的清晰性，其中省略了共识协议消息交换。
S3：验证。为了验证，用户可以选择向客户端应用程序提交日志，客户端应用程序通过发送散列Hash(
Figure 718251DEST_PATH_IMAGE004
)从区块链网络请求证据。如果找到并返回相应的事务，则只需验证其签名和哈希：
Figure 991101DEST_PATH_IMAGE014
Verify()是与sign()对应的验证函数，返回1表示正确的签名，否则返回0。
为了说明目的，图2中仅示出了三个节点。实际部署必须由n≥4个节点组成，以便能够容忍至少一个拜占庭节点。节点应该分别由多家不同的企业所组成，以使企业和攻击者更难修改区块链上的数据。如果一家企业控制了节点的绝大多数，它就可能简单地替换和伪造数据，丧失区块链系统的不变性好处，如图2所示。
另一种选择是在单个企业内运作区块链网络，并将节点分布到多个位置或企业的各个部门。在这种情况下，企业控制着所有节点，入侵者必须在多个位置颠覆节点才能移除跟踪。然而，企业本身可以启动区块链数据的协调替换。这可能是调查中的一个问题，即企业试图隐藏对其基础设施的破坏。向区块链添加锚定机制（anchoring mechanism）可以缓解这种可能性。锚定包括区块链（如比特币）上事务中的最新块哈希。这些检查点事务定期提交，费用很低。这允许外部审计师在锚定时公开验证区块链的状态。
这种方法的优点是，整个日志系统的基础实施仍在企业内。同时，它也会产生类似于区块链方法的事务费用。根据锚定频率的不同，这一成本可以加起来相当可观。在降低频率降低成本的同时，也拓宽了企业可能更换区块链数据的时间窗口。为了完全防止这种情况，检查点之间的时间必须低于内部协调的区块链替换所需的时间。
在一个实施例中，实现了上述设计的某些部分，比如将各个企业的日志采集模块存储服务器扩展到区块链基础实施中。然而，它目前缺乏一种确保原始日志证据的端到端完整性、可审计性和不可否认性的方法。该实施例以基于区块链的安全运维管理的形式添加了此功能。然后考察评估服务的安全性和吞吐量/存储可扩展性。
扩展后的架构如图4所示，将企业的日志采集模块连接到区块链系统节点上（或者说，将企业的日志基础实施连接到区块链系统节点上），完成已有安全运维管理产品诸如SIEM/安思易集中管控系统的框架扩展，这样实现基于区块链的安全运维管理。图中的哈希应用程序从数据流中获取日志记录，并为每个日志计算SHA256哈希。哈希Hash的输入数据包括日志数据及其签名。然后，哈希在签名事务中提交给区块链系统。接收区块链节点对数据库中现有散列进行哈希验证，以防止重复。时间戳与其它验证器一致获得，并包含在事务中。最后，一个单独的证明应用程序提供了一个web界面，在这个界面中，审计人员可以提交证据进行验证。
在本实施例中，考察评估了各种开源的区块链框架。首先，检查框架目前是否提供了一个生产就绪的BFT共识实现。出于性能原因，还希望避免智能合约（Smart Contract）的虚拟化开销，从而寻找提供自定义逻辑本机执行的框架。为了防止区块链的合谋操纵，将基于共识的锚定作为区块链的标准。为了确保低进入壁垒，通过分析运行框架所需的不同服务和容器的数量来评估部署工作。
在本实施例中，使用Exonum比其它允许的框架有几个优点。首先，其它框架还没有提供现成的BFT共识实现或基于共识的锚定。此外，Exonum不使用在虚拟化执行环境中运行的传统智能合约。相反，它使用本机执行的服务来实现自定义逻辑。与智能合约类似，服务由事务调用并在每个区块链节点上执行，但服务代码必须在编译时敲定，并且不能在运行时动态部署。服务包括作为Exonum框架的依赖，并编译为包含应用程序和框架的单个二进制文件。因此，虚拟化不会带来性能开销。二进制文件也可以很容易地部署，而无需维护多个单独的容器（如在Fabric/Sawtooth/Corda中）。
Exonum框架和日志审计服务是用Rust实现的，Rust是一种专注于内存安全、并发性和性能的功能系统编程语言。该框架使用基于PBFT的拜占庭容错一致性算法，支持每秒高达7000个事务的吞吐量。高吞吐量对于确保及时将每个日志记录的完整性证明包含在区块链中非常重要。Exonum框架还为分布式时间戳和比特币锚定提供内置服务。锚定到比特币区块链通过提供可公开验证的检查点来提高安全性。通过使用私有区块链，确定下一个候选区块进行锚定的过程是基于共识的，避免了单一的失败点。由于BFT共识是在本申请使用区块链的关键论点，因此本申请也选择Exonum作为其低开销的区块链方法。除了PBFT的一致性之外，它添加的特性都对提出的解决方案有用。加密的节点连接保持机密性，基于一致性的分布式时间戳确保日志创建时间的不可否认性，事务的块分组提高一致性性能。
该实施例由一个Exonum后端服务和一个轻客户端web应用程序所组成，如图5所示。后端服务运行在Exonum框架的0.5版本上。
如图5所示，前端客户端提供区块链检查、监控和验证日志数据的接口。它使用服务器端后端从区块链检索数据，后者将读取请求重定向到Exonum区块链API。服务器还运行一个用Rust编写的独立后台应用程序，该应用程序不断从基于Apache Kafka的分布式存储服务器集群接收新的日志事件。签名的日志数据经过哈希处理，并在事务中提交给区块链。区块链的日志审计服务验证散列在区块链中不存在，并将到达的事务组合到块中。在与其他节点建立共识后，框架会将新的区块附加到区块链中。
如图5所示，后端服务在Exonum区块链节点上运行，并指定事务数据模型和轻型客户端可与之交互的可用API端点。本申请重用了框架提供的时间戳服务示例，满足了系统设计和形式化规范的所有要求。
实际上，每个企业将在本地服务器上部署区块链节点和客户端应用程序的实例。要部署区块链节点，企业必须同意共享配置文件，其中包括块建议超时和每个块的事务等参数。然后根据每个节点的私钥、IP地址和其它节点的公钥在本地生成每个节点的单独配置文件。然后启动节点二进制文件（包括框架和日志审计服务）并准备接收事务。最后，必须将客户端应用程序配置为从本地存储服务器集群连续接收日志。每个参与者完成安装阶段后，系统可以开始运行。
设计中需要评估的关键方面是安全性和性能。系统安全性很重要，因为易受攻击的漏洞可能会质疑基础设施的用途。性能考虑对于确保大型企业IT基础实施的可扩展性也很重要，特别是因为区块链系统以其可扩展性限制而闻名。安全评估基于对威胁的结构化分析，而性能评估则侧重于基于云的原型部署中的吞吐量和存储度量。
在分布式系统中，有四个基本的安全威胁需要考虑：拦截（interception）、中断（interruption）、修改（modification）和伪造（fabrication）。
拦截（interception）可能导致向区块链提交时间戳的延迟。通过在节点之间设置经过身份验证和加密的通信通道，可以阻止拦截节点的连接。
例如，可以通过拒绝服务攻击来实现中断。通过阻止目标网络上的节点与其他节点通信，攻击者可以延迟未完成的日志事务。或者，入侵者可以尝试获得区块链节点的控制权。一旦有足够多的节点被破坏，就有可能拖延共识或完全控制网络。节点的确切数量取决于网络中验证程序的数量。在拜占庭容错一致性算法中，需要至少1/3的节点来暂停一致性，并且需要>2/3的节点来通过添加/删除验证节点来获得网络控制。这些界限基于这样一个事实：超过三分之二的验证器必须同意以BFT共识提交事务。锚定到一个区块链将完全防止这种类型的攻击。然后，可以根据区块链上发布的检查点来验证私有区块链的内容，以检测操作。
数据修改（modification）是对日志证据的最大威胁。入侵者可以尝试修改原始日志以隐藏跟踪。一旦攻击者控制了日志源，就无法保护新日志的完整性。因此，安全日志的目标是保护入侵前生成的日志数据。本申请提供的两层方法使用副本的存储服务器集群保护可用性，并通过区块链上的证明保护完整性。要使存储在本地存储服务器集群上的原始日志无效，攻击者必须损坏或删除所有副本。要修改区块链上的完整性证明，由于BFT一致性的特性，攻击者必须颠覆或说服超过三分之二的节点。这两种情况都需要对企业的基础设施进行重大渗透，而且在实践中是不太可能的。
伪造（fabrication）日志是一个问题，可能会使证据的认证失效。入侵者可以编造假日志条目，使调查人员误入歧途。为此，必须首先获得对系统的控制权，并在生成日志时泄露其私钥。没有安全措施可以保护在系统被破坏后生成的日志文件。在入侵之前生成的日志文件应该允许识别出泄露的时间，之后日志就不能再被认为是真实的了。此外，维护日志基础设施的企业还可能试图编造日志来错误地责怪对手。这是无法防止的，因为企业控制其私钥，可以在任何时间点提交用这些密钥签名的任意数据。相反，必须通过法律手段排除这种企业伪造的可能性。
关于验证的正确性，提交验证的假日志与区块链中包含的另一个有效日志项具有相同哈希值的概率为非零。然而，这种散列冲突在实际中可以忽略。原型中使用的SHA256算法有
Figure 720022DEST_PATH_IMAGE015
个可能的散列输出，但没有发现计算上可行的冲突。
从隐私的角度来看，日志内容是保密的，因为只有数据的散列存储在区块链上。对于像SHA256这样的抗预镜像哈希函数（按照当前标准），无法找到原始日志文件的内容。
此外，原型的区块链框架存在一些操作安全问题。Exonum没有收到任何安全审计，因此框架安全性的独立验证还不可用。另一个限制是缺少服务端点的内置身份验证和授权。默认情况下，任何人都可以查询私有和公共端点。这对企业IT基础设施来说不是一个关键问题。如果哈希应用程序部署到单独的系统或容器中，则可以将其作为唯一使用公共区块链API端口的外部系统进行白名单。类似地，系统管理员的IP应该是唯一允许访问专用端口的IP，因为它可以用于添加新对等点或关闭节点。白名单可以通过使用AWS安全组、Linux上的iptables或其他防火墙解决方案来完成。
有关日志基础设施性能的三个主要关注点是事务吞吐量、节点可扩展性和存储需求。系统的瓶颈显然是基于区块链的审计层，因为它在所有企业之间的事务吞吐量有限。因此，本申请在安思易集中管控系统的云上建立了不同规模的区块链网络，以对原型进行基准测试。本申请使用具有4个专用虚拟CPU内核和8GB RAM的droplet实例。所有虚拟机都设置在同一数据中心位置。本申请将区块链节点和哈希应用程序部署在同一服务器上。因此，从签署和提交事务到区块链的开销包含在性能度量中。在一些一致性参数的实验之后，本申请解决了默认配置，每个块最多10000个事务，建议超时1秒。这些参数似乎减轻了与系统配置相关的任何瓶颈。对于压力测试，本申请每秒提交5000个日志事务，每次20、30和40秒。事务负载均匀地分布在所有节点上。较高的负载不会增加吞吐量，只会在事务提交结束后增加处理时间。
结果表明，系统总体性能平均在每秒30到350个事务之间变化，每个节点每秒产生250到800个处理事务。每个节点的性能不断下降，而整体性能即使对于大量节点也保持相当稳定。每个节点的性能可以解释为对系统在每个企业中应暴露的平均事务负载的限制。考虑到每个节点的性能阈值在每秒250到800个事务之间，日志事件率不太可能超过系统容量。在这种情况下，一种可能的解决方案是对事务中的日志进行分组。在前述S1中，然后使用r连接的日志
Figure 674203DEST_PATH_IMAGE004
作为输入计算散列
Figure 549012DEST_PATH_IMAGE013
：
Figure 930446DEST_PATH_IMAGE016
区块链上产生的负载减少了1 r。然而，前述S3中的散列验证相应地改变，也需要r记录作为输入。日志的序列号可能不为验证者所知，需要r个验证请求和2个（r-1）附加日志进行验证（在当前日志之前和之后）。这突出了此解决方案的缺点：分组记录（或分片日志）现在被视为一个完整性单元。如果单元中的一个记录已损坏或不再可用，则无法证明单元中所有记录的完整性。
当节点计数等于3 f+ 1时，可以容忍容错最大值，容忍f拜占庭或失败节点。4/7/10个节点的节点计数可以被认为是有效的，分别容忍1/2/3拜占庭节点。
基于每个事务800字节的测量平均大小的每月区块链数据库增长。由于数据字段的大小是固定的，所以所有事务都具有大致相同的大小。数据库随吞吐量和节点数呈线性增长。为避免过度存储，区块链上的日志事务可能在d天后被丢弃，如企业日志保留策略所定义。理想的技术解决方案是一个滚动的区块链，配置为在区块存在d天之后丢弃它们。日志保留期必须事先由所有节点操作员商定。
在本实施例中，将它们与类似的基于区块链的日志方法进行了比较。以前的基于区块链的安全日志记录工作都使用了无许可（比特币）和许可（结构）区块链，但都没有提出基于锚定的集成方法。虽然本申请的解决方案主要基于区块链Exonum，但它也提供了基于共识的锚定到比特币区块链以增加篡改阻力的选项。关于评价，迄今为止，其他工作都没有包括吞吐量和存储限制的基准。由于这些限制对高频日志系统基础设施至关重要。除了进行基准测试外，在本实施例中还提出了通过分组日志或使用滚动区块链来提高可扩展性的途径。
由于比特币交易的存储空间有限，两种基于比特币的方法都将完整性证明和日志数据分开。本申请也可以基于私有区块链，并专注于在链上存储最小数量的数据。
每个条目的不变性是指为每个日志事件生成一个区块链事务。这些成本限制导致发布检查点，而不是单独的日志条目。但是，在检查点日志之间仅存在于本地机器上，这使得在检查点间隔期间能够截断攻击。通过减少检查点间隔可以进行缓解，但同时增加了事务成本。许可系统不受此约束，并提供每个条目的不变性，这从使用Hyperledger Fabric的工作中可以看出。本申请结合了这两种解决方案的优点：它通过使用私有区块链获得每个入口的不变性，通过将检查点发布到由数百个独立节点见证的公有区块链获得公共不可否认性。
以上所述仅为本发明的较佳实施例，并非用来限定本发明的实施范围；凡是依本发明所作的等效变化与修改，都被视为本发明的专利范围所涵盖。

Claims (4)

1.一种基于区块链的安全运维管理的方法，其特征在于，能够为多家企业提供一体化的安全运维管理服务，将所述各个企业的日志采集模块连接到所述区块链系统节点上，对于每个传输到日志采集模块存储服务器的新的日志数据，生成一个包含哈希Hash和当前时间戳的事务，该事务连同来自分布式系统中其它节点的事务一起被包含在一个区块中，当事务足够多时，或发生超时时，则会向区块链追加新的区块，并在区块链上存储所述新的区块所包含的事务信息，日志数据在区块链链下存储，在区块链链下存储的日志数据的可用性保护是通过本地副本来实现的。
2.如权利要求1所述的一种基于区块链的安全运维管理的方法，所述日志数据，被分为证据数据和完整性证明。
3.如权利要求2所述的一种基于区块链的安全运维管理的方法，所述证据数据，由实际的日志事件和相关的元数据组成，或者说，它由日志事件信息、生成系统标识符和签名，以及时间戳所组成。
4.如权利要求2所述的一种基于区块链的安全运维管理的方法，所述完整性证明，由一个时间戳的证据数据来表示，该证据数据在指定的时间确认日志事件的存在，并通过如下步骤来验证完整性证明：
从存储服务器抓取日志数据；
哈希日志数据；
签名并将日志数据的哈希提交给区块链节点进行验证；
服务器将存储在区块链事务中的哈希值与提交的日志数据的哈希值进行比较；
如果找到一个相同的哈希值，则有不可否认的证据表明相同的数据是在较早的时间提交的，说明日志数据是没被篡改。
CN202011548632.3A 2020-12-24 2020-12-24 一种基于区块链的安全运维管理的方法 Pending CN112564985A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202011548632.3A CN112564985A (zh) 2020-12-24 2020-12-24 一种基于区块链的安全运维管理的方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202011548632.3A CN112564985A (zh) 2020-12-24 2020-12-24 一种基于区块链的安全运维管理的方法

Publications (1)

Publication Number Publication Date
CN112564985A true CN112564985A (zh) 2021-03-26

Family

ID=75033189

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202011548632.3A Pending CN112564985A (zh) 2020-12-24 2020-12-24 一种基于区块链的安全运维管理的方法

Country Status (1)

Country Link
CN (1) CN112564985A (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114168685A (zh) * 2021-12-15 2022-03-11 北京天德科技有限公司 一种基于区块链系统的新型数据库架构及运行方法
WO2023105384A1 (en) * 2021-12-07 2023-06-15 International Business Machines Corporation Blockchain clock for storing event data

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109190410A (zh) * 2018-09-26 2019-01-11 华中科技大学 一种云存储环境下的基于区块链的日志行为审计方法
CN110084069A (zh) * 2019-04-17 2019-08-02 江苏全链通信息科技有限公司 基于区块链的服务器日志监控方法和系统
WO2020108289A1 (zh) * 2018-11-29 2020-06-04 华为技术有限公司 一种数据库系统、节点和方法
CN111490978A (zh) * 2020-03-27 2020-08-04 武汉大学 一种基于状态通道的分布式日志审计系统及方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109190410A (zh) * 2018-09-26 2019-01-11 华中科技大学 一种云存储环境下的基于区块链的日志行为审计方法
WO2020108289A1 (zh) * 2018-11-29 2020-06-04 华为技术有限公司 一种数据库系统、节点和方法
CN110084069A (zh) * 2019-04-17 2019-08-02 江苏全链通信息科技有限公司 基于区块链的服务器日志监控方法和系统
CN111490978A (zh) * 2020-03-27 2020-08-04 武汉大学 一种基于状态通道的分布式日志审计系统及方法

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023105384A1 (en) * 2021-12-07 2023-06-15 International Business Machines Corporation Blockchain clock for storing event data
US12019653B2 (en) 2021-12-07 2024-06-25 International Business Machines Corporation Blockchain clock for storing event data
CN114168685A (zh) * 2021-12-15 2022-03-11 北京天德科技有限公司 一种基于区块链系统的新型数据库架构及运行方法
CN114168685B (zh) * 2021-12-15 2023-07-18 北京天德科技有限公司 一种基于区块链系统的新型数据库架构及运行方法

Similar Documents

Publication Publication Date Title
Putz et al. A secure and auditable logging infrastructure based on a permissioned blockchain
Li et al. A blockchain-based authentication and security mechanism for IoT
Liang et al. Provchain: A blockchain-based data provenance architecture in cloud environment with enhanced privacy and availability
Chen et al. Certchain: Public and efficient certificate audit based on blockchain for tls connections
AU2019204708B2 (en) Retrieving public data for blockchain networks using highly available trusted execution environments
Tselios et al. Enhancing SDN security for IoT-related deployments through blockchain
Paccagnella et al. Custos: Practical tamper-evident auditing of operating systems using trusted execution
CN111164948B (zh) 使用区块链网络管理网络安全漏洞
US10425428B2 (en) Verification lineage tracking and transfer control of data sets
Bates et al. Trustworthy {Whole-System} provenance for the linux kernel
Ahmad et al. Secure and transparent audit logs with BlockAudit
US7571474B2 (en) System security event notification aggregation and non-repudiation
Aguiar et al. An overview of issues and recent developments in cloud computing and storage security
US20210256113A1 (en) Blockchain Validation of Software
CN112149105A (zh) 数据处理系统、方法、相关设备及存储介质
JP2023504492A (ja) データ・オブジェクトの効率的しきい値ストレージ
CN108027856B (zh) 使用可信平台模块来建立攻击信息的实时指示器
Ali et al. BCALS: Blockchain‐based secure log management system for cloud computing
Ulybyshev et al. (WIP) blockhub: Blockchain-based software development system for untrusted environments
Fernando et al. SciBlock: A blockchain-based tamper-proof non-repudiable storage for scientific workflow provenance
CN112564985A (zh) 一种基于区块链的安全运维管理的方法
CN112632639A (zh) 一种基于区块链的分布式可信日志管理方法
Shamis et al. {IA-CCF}: Individual accountability for permissioned ledgers
US20070028116A1 (en) Data collation system and method
Mannhart et al. Toward mitigation-as-a-service in cooperative network defenses

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
WD01 Invention patent application deemed withdrawn after publication
WD01 Invention patent application deemed withdrawn after publication

Application publication date: 20210326