Laxcus Big Data Management System 2.0 (10)-eighth chapter security

Eighth Chapter Safety

Due to the importance of security issues to big Data systems and society at large, we have implemented a system-wide security management strategy in the Laxcus 2.0 release. At the same time, we also consider the different aspects of the system to the requirements of security management is not the same, so selectively to do a different security design and processing. Figure 8 is the Laxcus Security management architecture, first using the SHA1 signature to obtain basic confirmation, and then at the FIXP network level, data communication using RSA encryption, followed by symmetric encryption, system security policy, signature, user security policy. SHA1 is a kind of digital signature, can guarantee the correctness of the transmission between the network, RSA is the most secure encryption means, symmetric encryption is the second, the system security policy contains for different nodes and various services designed security authentication, signature is the system to determine the legitimacy of each login account, User security policy is endowed with the ability of user-defined security rules, which is applied to the user's own distributed task components and data access, which helps to strengthen the data security of the users in the process of processing.

The security management measures described above are very diverse, but they are all about two goals: anti-theft and tamper-proof. Because of the impact of security management on the Data processing business (RSA computing is very high on CPU), at some level of the system, security management is set as an option, and the decision is given to the cluster manager and the user to handle it. For example, in the internal netcom letter, because of the security level of the intranet is relatively high, and the network data transmission is very large, almost all networks are calculated in the intranet. In this case, in order to give the data processing is to free up the basic resources, improve processing efficiency, you can choose to omit some of the security management as appropriate.

This chapter will follow the Laxcus Big Data System architecture to illustrate security management at every level.

Figure 8 Laxcus Security Management architecture

8.1 Environmental Safety

In architecture design, the Laxcus is divided into two internal and external network environments isolated from each other. Internal network topology external secrecy, network address is generally used in TCP/IP protocol in the intranet address (10.0.0.0-10.255.255.255, 172.16.0.0-172.31.255.255, 192.168.0.0- 192.168.255.255), which are managed and maintained by professional cluster managers, are considered "safe". Outside the network by the ordinary registered users to manage, not within the control of the cluster managers, the source can be the Internet or VPN connection, they belong to low-confidence users, is considered "unsafe". The joint point is located between them, in addition to the communication between the two sides of the connection and decomposition task pressure, but also mainly to accept external network requests at the same time, can shield the internal network topology, so that the internal network has a relatively safe operating environment, to prevent possible network attacks.

While the operating environment provides such a security design, the cluster's organization managers are still required to comply with the design requirements when deploying the cluster. In the process of cluster operation, management personnel should also have the common sense of safety management, which is the work that needs to cooperate with each other. On the basis of this architecture security, there are a series of security management measures to further reduce the likelihood of the cluster being attacked.

8.2 Communication Security

The node has both a client/server dual identity. At the beginning of each network communication, in order to ensure that the client is trustworthy, the server requires the client to present the communication security credentials. This credential will ensure that both parties communicate in a secure state.

The communication security credentials are configured on the FIXP server, which holds the information that the client must present. There are three types of secure communication: Address verification, account verification, address/account combination verification. When the server asks for security credentials, the client must adhere to this Protocol and present its own security credentials to the server, otherwise the communication will be aborted by the server. The client can also proactively request security checks to the server, each time the server accepts it.

After the detection of security credentials, it can be determined that the data transmitted between the two ends of the network is correct and trustworthy, which provides a basic security for the subsequent data processing.

There are exceptions in use, such as the intranet communication mentioned above. Because the internal network is relative to the public network, it has a high degree of security and trust, and the communication security items in addition to address verification, the other two need to perform CPU-consuming calculations, which will cause the delay in data processing, large-scale, high-density network computing is not worth the candle. Therefore, the general recommendation is that on both sides of the communication through the VPN or the Internet, secure communication should be enabled, and in the high-trust internal network, this work can choose address authentication or ignore.

8.3 node admittance system

In the Laxcus cluster, a node to make a command request to another node, the client must first log on to its server node, each command issued by the client to accept the server authentication and inspection, this is the node access system.

The node admittance system is a set of security measures defined for the connection and operation between nodes after secure communication. At this level, it is possible to ensure that the connections between the nodes are correct, and that the commands being transmitted are within the scope of the regulation.

For example, the aid node can only connect to the top node, which is illegal to connect to the home node. The front node must be registered with the call node before it can be licensed for command operation. The call node can issue the SQL SELECT command to the data node only, and the command to any other node will be rejected.

We have a set of detailed provisions on the node access system for different nodes, and we will not repeat them here. Since this provision accurately defines the requests between them, the scope of acceptance, and the authorization of the order, each node and each command is inspected during operation, thus eliminating all possible illegal connections and operations.

8.4 user account security

The user logs on using the front node. Regardless of whether the user is connected to the Laxcus cluster in the form of terminal interaction or driver embedding, the system requires the user to provide a login account to confirm that the user is trustworthy. Laxcus account is composed of user name and password, each account must be established by the system administrator, account username and password will be computed as the SHA1 algorithm hash code, and then through the network upload to the top node, saved to the data dictionary for subsequent use.

The user name of the account is unique to the system and cannot be modified once it is established. When the system administrator establishes an account, it will pass the clear text of the account to the account holder through other channels. The account holder has the right to change the password of the account, usually the account holder will change the password set by the system administrator.

In particular, in the process of establishing, modifying and using the account login, the clear text of the account appears only on the user's computer screen or in the user's driver, and does not appear in any part of the network transmission. The top node saves only the account plaintext SHA1 algorithm hash code, due to the SHA1 algorithm reverse crack difficulty, makes the possibility of obtaining the account clear text is very small. This makes the account in the production and use of the process has a great security.

In addition, users must have a security license issued by a system administrator in addition to providing a login account. This is a file that has been signed by the RSA algorithm and is established and maintained by the system administrator. When a user logs in, the certificate is presented first, the server checks the validity of the certificate, determines that the certificate is valid and the login is trustworthy, then performs an account check, further determines the correctness and scope of operation of the account, and decides whether to accept or reject it.

In this way, each user's login process is a combination of RSA and SHA1, first signing the account with SHA1, and then using RSA for transmission and verification. Because this is the first stage of entering the cluster, it must be guaranteed to have sufficient security strength. This double security measure guarantees the trustworthiness of every logged-on user.

After the login is successful, both parties enter the formal communication status. We typically require data to be encrypted or signed. Currently available encryption and signature algorithms are: AES, DES, 3DES, MD5, SHA1 and so on. These algorithms and passwords will automatically transform with the communication process, which makes it difficult to obtain clear text in a short time, which further improves the data security of both parties.

To sum up, the user into the Laxcus cluster in turn there are three security thresholds: RSA, user account, symmetric encryption or digital signature, the first two to ensure the security of the user login, the latter to ensure the security of the data content after login.

8.5 User Rights Management

The user logs on using the front node, but has the right to enter the cluster. To get the data processing power, you also need to get further permission to manipulate.

Data manipulation permissions are also authorized by the Administrator. Data manipulation permissions are divided into three levels from high to low: User-level, database-level, and table-level. There are multiple action options at each level, some of which exist at multiple levels, and for this homogeneous option, the upper-level operation permission defaults to the next-level operation permission. For example, the SQL "select" Operation permission, the user-level "select" is higher than the database-level "Select", the Database-level "Select" is higher than the table-level "select".

Data manipulation permissions assigned by the administrator can also be recycled by the administrator. After the permission is reclaimed, the data request that exceeds the permission is immediately taken into effect and will be rejected thereafter.

Through user Rights Management, the administrator can control the user's data processing operations within the specified scope, to prevent the user may be ultra vires operation.

8.6 Private business security

The private business is the user's data business, and this piece of security management is left to the user to handle. At this level, users are free to organize their own data content and data formats. Organization is divided into two types: 1. The system provides a class interface, before sending, the data in accordance with their own understanding of the data format, in various ways together, after receiving, and then re-disassemble. The "Classwriter, Classreader" In the class interface also provides encryption/decryption capabilities, further enhancing the security capability. So in the process of data transmission, because the format and content have been processed, the crack becomes very difficult. As for the password, it can be placed in a place where the outside world is hard to spy, such as a command-custom parameter, or a data dictionary in the cluster.

The array data in the data table can be encrypted at build time through the system-provided "Packing" interface. This content has already been processed in the generation, only in the display time is untied, re-appear in the plaintext format, the intermediate process is in the form of ciphertext. In the case of not mastering the password, the outside world is also unable to peep.

Figure 8.6.1 A class of interface functions

8.7 Distributing task components security

The security of the distributed task component is ensured by the sandbox. Sandbox is a container that restricts program operation and processing power, and is now integrated into the Laxcus Big Data management system. All the distributed task components in the running state are placed in the sandbox to run.

The root cause of running the distributed task component in the sandbox is that the distributed task component originates from the user, and from a conservative security standpoint, we cannot prejudge that each distributed task component is benign and trustworthy and does not contain malicious code in their program, so from the principle of unified processing, We assume that these distributed task components are unsafe and need to be constrained and restricted during their operation to prevent all kinds of things that might compromise the system or other distributed task components.

The distributed task components running in the sandbox are strictly supervised by the sandbox and can only "read, write, delete" the files under the directory, or obtain the specified system attributes, and other operations are excluded. During the run, each action request issued by the distributed task component is first uploaded to the sandbox for security checks, and the sandbox rejects execution when the discovery operation exceeds the permitted range to ensure a safe running environment.

The sandbox security check item is placed in the safety policy file and loaded at system startup. It is easy to modify the security policy file, but this is the responsibility of the Cluster Administrator, which is not the ability of the average user.

Figure 8.7.1 Sandbox security policy options

8.8 Data block security

The security of a data block depends on the signature of the data. When the data block moves from the cache state to the chunk state, the system calculates the data content of the data block, generates a 256-bit laxcus signature, and saves it as a checksum to the data block. The process of generating a data block signature is fast, with a 64M data block signature generation time, on Pentium4 2.0G computers, usually around 10 milliseconds.

When the data node restarts, or the block is loaded into memory, or transmitted over the network to another data node, the system re-generates a checksum based on the data content, compares it to the existing checksum, confirms the integrity of the data, and ensures that the data for subsequent data processing is correct.

8.9 dsm/nsm Safety

When the data block is transferred from the cache state to the chunk state, in addition to generating the block signature, the CRC32 checksum code is generated for each row or column collection based on the data block's storage model, and is saved at the beginning of the record.

The reason for setting the row/column set checksum is that because the entire block of data is not often called, and the row/column set data is always heavily and frequently passed on the network, this makes the row/column set data validation more meaningful.

However, compared with a small number of data block signature calculation, the transmitted Line/column set because of the granularity, large data volume, frequent check times, the calculation duration will be longer, which will consume a lot of computing resources, affecting the processing efficiency of network computing. Therefore, when the task requester receives the result of the calculation, it chooses whether to detect it based on the source of the data. In the case of intranet data, this check can be ignored due to the high degree of network security.

Laxcus Big Data Management System 2.0 (10)-eighth chapter security