Multi-level data protection in cloud CRM
Protecting information in cloud-based CRMs is a key stumbling block in disputes between developers of SaaS and desktop services. Let us see how the representatives of the first camp solve this problem.
First of all, physical information protection is needed: so that the data server is not stolen. For this, the servers are located in a round-the-clock guarded data center with video surveillance and limited access for people to these premises. Only a limited circle of employees is allowed there, and neither customer representatives, nor even other employees of the developer company can get there.
The second level of physical protection is ensuring the safety of the data contained on these servers. This issue is resolved by applying a policy of information backup, 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 transmission also needs protection, since 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 system data from being intercepted by sniffers, etc.
Each user logs in to the username and password allocated to him. The program automatically determines the availability of solutions and organizations available to the user, and if available, prompts him to select a base for entry. If there is only one such program, then you are logged into it without additional questions.
User password data is stored in the database in a closed form in the form of a hash.
In order to avoid theft of the session of authorized users, the login and password hash are checked at the loading of each page of the system. If authentication fails, the user automatically logs out of the system.
One of the convenient variants of the algorithm used in the development of CRM is based on the position “each 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 a discretionary access control policy, which allows us to build a rights table in which rows are system objects and columns are program users. At the intersection of columns and rows, + or - is placed, which means the presence or absence of employee access to certain system objects. Accordingly, each user gets his own separate column in this table, implemented in the program as a set of actions available to him.
To facilitate understanding of this table, system objects are divided into thematic groups.
Here is an example of such a table:
The CRM rights administration interface is built by analogy with this table.
The table of available rights is automatically generated during user authentication at loading each CRM page. In this case, the program can check whether the current user has the right to this or that action or not. This is done with a single line of code of approximately the following form: Calling this method in relation to the table shown allows you to find out if there is access to object 64 — view the list of items for the current user. Accordingly, the program will show or not show the corresponding section in the system.
For a number of system objects, access control by role is required. Roles reflect access to data in the system according to the set of employee credentials in the company. For example, the head of a department has access to commercial offers that all employees of his department put up, and each employee only has access to their commercial offers.
The role policy is laid down during the design of the program section and is implemented at the program level according to the “black box” principle: the document list class, based on the profile of the current employee, returns a list of document numbers available to him 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 fetching an SQL query to a database table containing documents or a list of employees whose documents are available.
For example, you can set access to scheduler records in such a way that the department manager can 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 query parameters of the SQL query to the database table that stores the scheduler records.
“Under the hood” of this method is the actual software implementation of all role policies.
For individual sections of the program, access control at the document level is implemented. For example, in a file section, you can control access to folders at the individual user level: the system administrator can share any rights with a folder with employees (create, delete subfolders, download, delete files, move folders and files), and the folder’s creator-employee only with 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 “shoot yourself in the foot” is excluded - to close access to the folder to yourself: the checkmarks in the corresponding line are inactive. The column “Editing file description (own files)” is inactive, because Employee 2 does not have such rights in this version of the system. He has a tick, because for this folder, such rights were still given to him.
The fact of any access to any program data is recorded in the system log. This allows administrators to track who accessed 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 the system log might look like. In it, in particular, it is shown that Employee 2 deleted 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. Having studied this journal, you can find out who contributed what information, when, what actions did specifically on this document.
In addition, the CRM report is available "User activity". It allows you to find out the operating time 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, program modules for reports (in the form of tables and graphs) on the real-time work of employees in the system are created. This function allows you to control the use of employee time.
Let us show an example of such a graphical report:
Thus, the information security system in CRM pursues several main goals: on the one hand, it must be based on 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 parties, it is necessary to protect the company's commercial information from unauthorized access. In cloud CRM, several tools are used to solve these problems at once, which not only allow you to achieve your goals, but, for all their merits, make them no less secure than desktop applications.
Physical protection
First of all, physical information protection is needed: so that the data server is not stolen. For this, the servers are located in a round-the-clock guarded data center with video surveillance and limited access for people to these premises. Only a limited circle of employees is allowed there, and neither customer representatives, nor even other employees of the developer company can get there.
The second level of physical protection is ensuring the safety of the data contained on these servers. This issue is resolved by applying a policy of information backup, 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 Layer Protection
Data transmission also needs protection, since 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 system data from being intercepted by sniffers, etc.
Authorization in the system
Each user logs in to the username and password allocated to him. The program automatically determines the availability of solutions and organizations available to the user, and if available, prompts him to select a base for entry. If there is only one such program, then you are logged into it without additional questions.
User password data is stored in the database in a closed form in the form of a hash.
In order to avoid theft of the session of authorized users, the login and password hash are checked at the loading of each page of the system. If authentication fails, the user automatically logs 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 “each 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 a discretionary access control policy, which allows us to build a rights table in which rows are system objects and columns are program users. At the intersection of columns and rows, + or - is placed, which means the presence or absence of employee access to certain system objects. Accordingly, each user gets his own separate column in this table, implemented in the program as a set of actions available to him.
To facilitate understanding of this table, system objects are divided into thematic groups.
Here is an example of such a table:
The CRM rights administration interface is built by analogy with this table.
The table of available rights is automatically generated during user authentication at loading each CRM page. In this case, the program can check whether the current user has the right to this or that action or not. This is done with a single line of code of approximately the following form: Calling this method in relation to the table shown allows you to find out if there is access to object 64 — view the list of items for the current user. Accordingly, the program will show or not show the corresponding section in the system.
$au->user_rights->CheckAccess(64);
Access control in CRM at the document level by role
For a number of system objects, access control by role is required. Roles reflect access to data in the system according to the set of employee credentials in the company. For example, the head of a department has access to commercial offers that all employees of his department put up, and each employee only has access to their commercial offers.
The role policy is laid down during the design of the program section and is implemented at the program level according to the “black box” principle: the document list class, based on the profile of the current employee, returns a list of document numbers available to him 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 fetching an SQL query to a database table containing documents or a list of employees whose documents are available.
For example, you can set access to scheduler records in such a way that the department manager can 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 query parameters of the SQL query to the database table that stores the scheduler records.
“Under the hood” of this method is the actual software implementation of all role policies.
Access control in CRM at the document level by user
For individual sections of the program, access control at the document level is implemented. For example, in a file section, you can control access to folders at the individual user level: the system administrator can share any rights with a folder with employees (create, delete subfolders, download, delete files, move folders and files), and the folder’s creator-employee only with 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 “shoot yourself in the foot” is excluded - to close access to the folder to yourself: the checkmarks in the corresponding line are inactive. The column “Editing file description (own files)” is inactive, because Employee 2 does not have such rights in this version of the system. He has a tick, because for this folder, such rights were still given to him.
Security Reports
The fact of any access to any program data is recorded in the system log. This allows administrators to track who accessed which data. The syslog entry itself has the following fields:
- Action date
- Action name
- IP address from which the action was taken
- User who committed the action
- Affected user (if any)
- Affected user group (if any)
- Used rights from the rights table
- Affected Document Code
- Comments (contain the values of the updated fields, explanations of the action, etc.)
The system log in the program can be filtered by any of the listed fields.
This is what the system log might look like. In it, in particular, it is shown that Employee 2 deleted 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. Having studied this journal, you can find out who contributed what information, when, what actions did specifically on this document.
In addition, the CRM report is available "User activity". It allows you to find out the operating time 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, program modules for reports (in the form of tables and graphs) on the real-time work of employees in the system are created. This function allows you to control the use of employee time.
Let us show an example of such a graphical report:
Summary
Thus, the information security system in CRM pursues several main goals: on the one hand, it must be based on 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 parties, it is necessary to protect the company's commercial information from unauthorized access. In cloud CRM, several tools are used to solve these problems at once, which not only allow you to achieve your goals, but, for all their merits, make them no less secure than desktop applications.