Multi-level information security in cloud CRM
Protecting information in cloud CRM is a key stumbling block in disputes between SaaS developers and desktop services. Let us see how the representatives of the first camp solve this problem.
First of all, physical information protection is necessary: ​​so that the server with the data is not stolen. For this, the servers are located in a 24-hour guarded data center with video surveillance and limited access for people to these premises. Only a limited number of employees are allowed there, and neither the representatives of the clients, nor even other employees of the developer company can get there.
The second level of physical protection is to ensure the integrity of the data contained on these servers. This issue is solved by applying the policy of backing up information, which provides for daily automatic copying of the database and CRM files, as well as - twice a week - to separate foreign servers and local removable media.
Data transfer also needs to be protected, because there is a possibility of interception of information at the time of its transit. For cloud systems with web access, it is important to use the https protocol using an SSL certificate. As a result, traffic encryption allows you to protect these systems from being intercepted by sniffers, etc.
')
Each user logs in to the username and password assigned to him. The program automatically detects the availability of solutions and organizations available to the user, and if there are any, offers to select a base for entry. If there is only one such program, then it is entered without additional questions.
User password data is stored in a private database in the form of a hash.
In order to avoid theft of the session of authorized users, verification of the login and password hash is performed when loading each page of the system. When authentication fails, the user is automatically logged out of the system.
One of the convenient variants of the algorithm used in the development of CRM is based on the position “every operation in the system is a separate access object”. This access object, in turn, can be assigned rights for individual employees. This model is close to the discretionary access control policy, which allows us to build a table of rights, the rows in which are the system objects, and the columns are the users of the program. At the intersection of columns and rows put + or -, which means the presence or absence of employee access to certain objects of the system. Accordingly, each user has his own separate column in this table, implemented in the program as a set of actions available to him.
To facilitate the understanding of this table, the objects of the system are divided into thematic groups.
Here is an example of such a table:
The rights management interface in CRM is built by analogy with this table.
The table of available rights is automatically generated when the user is authenticated when each CRM page is loaded. In this case, the program can check whether the current user has the right to a particular action or not. This is done with a single line of code like this:
Calling this method in relation to the table shown allows you to find out if you have access to object 64 — view the list of items from the current user.
Accordingly, the program will show or not show the corresponding section in the system.
For a number of objects in the system, access control by roles is required. Roles reflect access to data in the system according to the set of powers of the employee in the company. For example, the head of a department has access to commercial offers, which were put up by all the employees of his department, and each employee has access only to his commercial offers.
The role policy is established when designing a program section and at the program level is implemented according to the black box principle: the document list class based on the current employee’s profile returns a list of available document numbers using a special method, or, if the section involves a large number of documents, any formalized rules to filter them. For example, these can be parameters for selecting a SQL query to a database table containing documents or a list of employees whose documents are available.
For example, you can set access to the scheduler's records in such a way that the head of the department will be able to process both his records and the records of subordinate employees. In the program, such an access algorithm is determined using a simple method:
The method returns a list of employees whose records are visible to the specified employee. The list can be substituted into the selection parameters of the SQL query to the database table that stores the scheduler entries.
“Under the hood” of this method contains the actual software implementation of all role policies.
For individual sections of the program, access control at the document level has been implemented. For example, in the file section, you can control access to folders at the individual user level: the system administrator can share with the folder any rights to the folder (create, delete subfolders, download, delete files, move folders and files), and the employee who created the folder - only those rights that are currently allocated to him by the administrator.
The function described above is implemented as a “share” button in the file registry folder, which brings up a window like this:
For example, we work under “Employee 2”. The possibility of “shooting yourself in the leg” is excluded - close access to the folder for yourself: checkboxes in the corresponding line are inactive. The column “Editing file description (own files)” is inactive, because Employee 2 does not have these rights in this version of the system. A tick is attached to it, because for this folder, such rights were given to him all the same.
The fact of any access to any program data is recorded in the system log. This allows administrators to track who has access to which data. The syslog entry itself has the following fields:
The system log in the program can be filtered by any of the listed fields.
This is what a system log might look like. It shows, in particular, that Employee 2 removed certain rights from the Test employee:
Due to the structure of the general journal, the program implements event logs for each document — for example, an account event log. After studying this magazine, you can find out who contributed what information, when, what actions he performed specifically on this document.
In addition, the report “User Activity” is available in CRM. It allows you to find out the time of work of a given employee in a given period: total, by day, by session, and view the complete event log for this employee.
Finally, using the CRM event log, software reporting modules (in the form of tables and graphs) about the real-time work of employees in the system are created. This feature allows you to control the use of employee time.
Let us show an example of such a graphic report:
Thus, the information security system in CRM has several main objectives: on the one hand, it must proceed from the assumption that each employee has access to the data he needs to work (and is insured against accidental damage or deletion), and on the other hand hand, it is necessary to protect the commercial information of the company from unauthorized access. In cloud CRM, several tools are used to solve these tasks at once, which not only allow you to achieve your goals, but also, for all their merits, make them no less secure than desktop applications.
Physical protection
First of all, physical information protection is necessary: ​​so that the server with the data is not stolen. For this, the servers are located in a 24-hour guarded data center with video surveillance and limited access for people to these premises. Only a limited number of employees are allowed there, and neither the representatives of the clients, nor even other employees of the developer company can get there.
The second level of physical protection is to ensure the integrity of the data contained on these servers. This issue is solved by applying the policy of backing up information, which provides for daily automatic copying of the database and CRM files, as well as - twice a week - to separate foreign servers and local removable media.
Protection at the level of data transmission
Data transfer also needs to be protected, because there is a possibility of interception of information at the time of its transit. For cloud systems with web access, it is important to use the https protocol using an SSL certificate. As a result, traffic encryption allows you to protect these systems from being intercepted by sniffers, etc.
')
Authorization in the system
Each user logs in to the username and password assigned to him. The program automatically detects the availability of solutions and organizations available to the user, and if there are any, offers to select a base for entry. If there is only one such program, then it is entered without additional questions.
User password data is stored in a private database in the form of a hash.
In order to avoid theft of the session of authorized users, verification of the login and password hash is performed when loading each page of the system. When authentication fails, the user is automatically logged out of the system.
The system of rights and objects
One of the convenient variants of the algorithm used in the development of CRM is based on the position “every operation in the system is a separate access object”. This access object, in turn, can be assigned rights for individual employees. This model is close to the discretionary access control policy, which allows us to build a table of rights, the rows in which are the system objects, and the columns are the users of the program. At the intersection of columns and rows put + or -, which means the presence or absence of employee access to certain objects of the system. Accordingly, each user has his own separate column in this table, implemented in the program as a set of actions available to him.
To facilitate the understanding of this table, the objects of the system are divided into thematic groups.
Here is an example of such a table:
The rights management interface in CRM is built by analogy with this table.
The table of available rights is automatically generated when the user is authenticated when each CRM page is loaded. In this case, the program can check whether the current user has the right to a particular action or not. This is done with a single line of code like this:
$au->user_rights->CheckAccess(64);
Calling this method in relation to the table shown allows you to find out if you have access to object 64 — view the list of items from the current user.
Accordingly, the program will show or not show the corresponding section in the system.
CRM access control at the document level by role
For a number of objects in the system, access control by roles is required. Roles reflect access to data in the system according to the set of powers of the employee in the company. For example, the head of a department has access to commercial offers, which were put up by all the employees of his department, and each employee has access only to his commercial offers.
The role policy is established when designing a program section and at the program level is implemented according to the black box principle: the document list class based on the current employee’s profile returns a list of available document numbers using a special method, or, if the section involves a large number of documents, any formalized rules to filter them. For example, these can be parameters for selecting a SQL query to a database table containing documents or a list of employees whose documents are available.
For example, you can set access to the scheduler's records in such a way that the head of the department will be able to process both his records and the records of subordinate employees. In the program, such an access algorithm is determined using a simple method:
$viewed_ids=$_plans->GetAvailableUserIds($result['id']);
The method returns a list of employees whose records are visible to the specified employee. The list can be substituted into the selection parameters of the SQL query to the database table that stores the scheduler entries.
“Under the hood” of this method contains the actual software implementation of all role policies.
CRM access control at the document level by users
For individual sections of the program, access control at the document level has been implemented. For example, in the file section, you can control access to folders at the individual user level: the system administrator can share with the folder any rights to the folder (create, delete subfolders, download, delete files, move folders and files), and the employee who created the folder - only those rights that are currently allocated to him by the administrator.
The function described above is implemented as a “share” button in the file registry folder, which brings up a window like this:
For example, we work under “Employee 2”. The possibility of “shooting yourself in the leg” is excluded - close access to the folder for yourself: checkboxes in the corresponding line are inactive. The column “Editing file description (own files)” is inactive, because Employee 2 does not have these rights in this version of the system. A tick is attached to it, because for this folder, such rights were given to him all the same.
Safety reports
The fact of any access to any program data is recorded in the system log. This allows administrators to track who has access to which data. The syslog entry itself has the following fields:
- Date of action
- Action name
- IP address from which the action was performed
- The user who committed the action
- Affected user (if any)
- Affected user group (if any)
- Rights used from rights table
- Code of the affected document
- Comments (contain the values ​​of the updated fields, explanations for the action, etc.)
The system log in the program can be filtered by any of the listed fields.
This is what a system log might look like. It shows, in particular, that Employee 2 removed certain rights from the Test employee:
Due to the structure of the general journal, the program implements event logs for each document — for example, an account event log. After studying this magazine, you can find out who contributed what information, when, what actions he performed specifically on this document.
In addition, the report “User Activity” is available in CRM. It allows you to find out the time of work of a given employee in a given period: total, by day, by session, and view the complete event log for this employee.
Finally, using the CRM event log, software reporting modules (in the form of tables and graphs) about the real-time work of employees in the system are created. This feature allows you to control the use of employee time.
Let us show an example of such a graphic report:
Summary
Thus, the information security system in CRM has several main objectives: on the one hand, it must proceed from the assumption that each employee has access to the data he needs to work (and is insured against accidental damage or deletion), and on the other hand hand, it is necessary to protect the commercial information of the company from unauthorized access. In cloud CRM, several tools are used to solve these tasks at once, which not only allow you to achieve your goals, but also, for all their merits, make them no less secure than desktop applications.
Source: https://habr.com/ru/post/263641/
All Articles