Ideology and problems of developing financial systems. Part 1
In my humble experience, in our country there is no division into software developers and developers of financial systems. The most that I have met at the interviews is the question of whether I dealt with information systems that operate under high loads (Channel One, Yandex, etc.). Otherwise, they are always interested only in the knowledge of certain information technologies. In my opinion, the development of information systems is a whole culture of the development and design of architecture. At the same time, the first place should always be architecture: its balance, flexibility, safety and reasonableness about the future development of the system (including possible integration with third-party systems that do not have that flexibility, that reasonableness and that sharpness under the business process) .
An example of the differences is the construction of conventional systems that are guided by current information and financial systems.
A financial accounting and auditing system is being created. The system, as they say, all in one. The system is developed, accepted by the customer, developed and refined. After a couple of years, the customer comes up with dividing the entire business process into two separate components, namely: the financial service is divided into two parts: financial and accounting. Under this case, the separation of systems is planned: the customer wants the old system to remain, but some functionality (related to accounting activities) was fully implemented in 1C-Accounting. And here immediately the question of the integration of the two systems arises. 1C-Accounting - a great financial system, or rather not even 1C-Accounting, but the entire framework. I will not even talk about the essential problems of 1C: a part of the built-in functionality is so “embedded” that it will not be possible to change it without consequences in the future; It is very difficult to integrate at least one directory from the external database. I can only say that on the fly, loading all changes from the main system into it is a rather non-trivial task. But let us return to our system and ask ourselves the question: if we now have not one system, but two (three, four, five, ..), what to do with the entities that become common to these systems. We can even omit those entities creation, editing and deletion of which is allowed only in one of the systems (here the business process can be painted even at the database level). But what to do, say, with reference directories common to both systems? After all, users are people who don’t feed them with bread - just give me some information. The results of this can be, if not catastrophic, then they will select quite a lot of man-hours that will be required to solve these seemingly small problems. And it turns out that it turned out at the end of December, when they began to collect reports for the year, and the data, say, under contracts, crawl away. The users responsible for this data, of course, don’t remember for what reason a few months ago they did exactly what they did. The logic of the product owner usually comes down to the fact that “this is a system problem, you are responsible for it — you and solve the problem”, forgetting that the problem may be not so much in the system as in the data. In total this would not have happened under one condition - the system architecture and interaction rules would have been thought out from the very beginning.
')
Here and further, I would like to talk about the difficulties that our team faced. Perhaps if a few years ago I had come across a similar material, we would have avoided many problems that took (and continue to take) a lot of time from us. I would have had even a simple mention that such and such a problem may arise because of this and that. Now I myself am ready to talk about a few similar ones. In addition, I will try to outline the solutions that we discussed and which we finally took. So, let's begin.
The authorization algorithm and planning the architecture of the system of access rights at the design stage
It is obvious that all the nuances associated with the implementation of the business process, never take into account, but you should think about them.
The easiest and simplest path that many choose is to make a construction of the form:
instance of work_class_s_BD.connection_method (username, password)
where username and password are the data that the user enters when the client starts.
Already here one big security issue is visible. It so happened that we have experience in supporting the system in the organization in which we maintain the system, and our competitors have a local network and user machines. We could never have thought that we would have to protect the data transmitted between our users and our servers within the same organization, geographically located in the same building, but it turns out that this also happens.
What can an attacker who has access to the user's machine do? He can do one simple thing - throw the memory dump onto the carrier and tear away the username and password in a calm atmosphere.
Therefore, rule number 1: confidential data (namely, data for access to which there are at least some restrictions) should be stored outside the server only in the time period when it is impossible for the system to function without them. In this example, after establishing a connection with the database, it is necessary to destroy (or fill up with garbage) all variables, the contents of the user name and password.
Now we set the task: how to check that the user is the user and that his computer is his computer?
Standard MS SQL tools (for example) cannot solve this problem. Moreover, it must be abandoned (at least because of domain authorization, which, first, kills the entire security policy in the example above, and second, it does not provide any flexibility, which will be discussed further).
It is worth noting that for the integration of several systems you will not be able to use anything except database policies (or write a layer to work between different programs, but this will take a lot of time). That is why we should initially try to share data that will potentially change in other systems and data that is allowed to be edited only in our system. At the same time, it is necessary to separate them not just according to the tables, but carried out to different bases. But I will try to write about it next time.
So, authorization.
The simplest (which did not take a lot of time) and the action that we came up with is the following scheme:
o User enters username and password
o Password is converted by tricky algorithm, using all possible data about the hardware of the local machine
o A connection is created with the entered username and password received.
Thus, we fasten the data of a specific machine (the attacker will not be able to recreate them all, at least the unique number of the processor and network card). On the other hand, even having a computer at your disposal, you also need to know the user's password.
Of course, we understand that there are no impenetrable systems, but our cunning algorithm will force those who try to disassemble the code to sweat, which means it will give us time.
But the most important thing: even knowing the user's password and having access to the computer - you will not be able to do something really scary: the access rights policy will interfere.
We have long been looking for a middle ground between the tools that the database offers us (MS SQL) and the fact that we build on. In the end, it was unequivocally decided that the detail provided by the database (separate rights to each table, view, and storage) is not enough - the entire logic of the business process is much more complicated.
In the end, we implemented the following two-tier security system scheme from client applications:
o When the application starts, a connection with the database is automatically created.
o The user enters the username and password, which are transmitted to the server in encrypted form with the operation code that the user wants to make (in this case, the connection)
o Next, the proprietary rights system returns a result that indicates the validity of this action (after receiving the result code, the program “understands” the data will be returned to it in the next request for receiving data).
Then this scheme is used everywhere, which allows you to completely shift the business process, taking into account the most sophisticated rights.
Thus, the DB toolkit gives us space for maneuvers regarding the operation of different systems with the database, and detailed logic is written at the application and database levels: the stored procedure will never return data if the function that checks the validity of user actions returns a failure code.
Total
It was a rather tedious and lengthy article, but I hope for someone it will be useful. If this happens all the same, then next time I would like to talk about the problem and the logic of the interactions of several systems.
An example of the differences is the construction of conventional systems that are guided by current information and financial systems.
A financial accounting and auditing system is being created. The system, as they say, all in one. The system is developed, accepted by the customer, developed and refined. After a couple of years, the customer comes up with dividing the entire business process into two separate components, namely: the financial service is divided into two parts: financial and accounting. Under this case, the separation of systems is planned: the customer wants the old system to remain, but some functionality (related to accounting activities) was fully implemented in 1C-Accounting. And here immediately the question of the integration of the two systems arises. 1C-Accounting - a great financial system, or rather not even 1C-Accounting, but the entire framework. I will not even talk about the essential problems of 1C: a part of the built-in functionality is so “embedded” that it will not be possible to change it without consequences in the future; It is very difficult to integrate at least one directory from the external database. I can only say that on the fly, loading all changes from the main system into it is a rather non-trivial task. But let us return to our system and ask ourselves the question: if we now have not one system, but two (three, four, five, ..), what to do with the entities that become common to these systems. We can even omit those entities creation, editing and deletion of which is allowed only in one of the systems (here the business process can be painted even at the database level). But what to do, say, with reference directories common to both systems? After all, users are people who don’t feed them with bread - just give me some information. The results of this can be, if not catastrophic, then they will select quite a lot of man-hours that will be required to solve these seemingly small problems. And it turns out that it turned out at the end of December, when they began to collect reports for the year, and the data, say, under contracts, crawl away. The users responsible for this data, of course, don’t remember for what reason a few months ago they did exactly what they did. The logic of the product owner usually comes down to the fact that “this is a system problem, you are responsible for it — you and solve the problem”, forgetting that the problem may be not so much in the system as in the data. In total this would not have happened under one condition - the system architecture and interaction rules would have been thought out from the very beginning.
')
Here and further, I would like to talk about the difficulties that our team faced. Perhaps if a few years ago I had come across a similar material, we would have avoided many problems that took (and continue to take) a lot of time from us. I would have had even a simple mention that such and such a problem may arise because of this and that. Now I myself am ready to talk about a few similar ones. In addition, I will try to outline the solutions that we discussed and which we finally took. So, let's begin.
The authorization algorithm and planning the architecture of the system of access rights at the design stage
It is obvious that all the nuances associated with the implementation of the business process, never take into account, but you should think about them.
1. Connection to the database.
The easiest and simplest path that many choose is to make a construction of the form:
instance of work_class_s_BD.connection_method (username, password)
where username and password are the data that the user enters when the client starts.
Already here one big security issue is visible. It so happened that we have experience in supporting the system in the organization in which we maintain the system, and our competitors have a local network and user machines. We could never have thought that we would have to protect the data transmitted between our users and our servers within the same organization, geographically located in the same building, but it turns out that this also happens.
What can an attacker who has access to the user's machine do? He can do one simple thing - throw the memory dump onto the carrier and tear away the username and password in a calm atmosphere.
Therefore, rule number 1: confidential data (namely, data for access to which there are at least some restrictions) should be stored outside the server only in the time period when it is impossible for the system to function without them. In this example, after establishing a connection with the database, it is necessary to destroy (or fill up with garbage) all variables, the contents of the user name and password.
Now we set the task: how to check that the user is the user and that his computer is his computer?
Standard MS SQL tools (for example) cannot solve this problem. Moreover, it must be abandoned (at least because of domain authorization, which, first, kills the entire security policy in the example above, and second, it does not provide any flexibility, which will be discussed further).
It is worth noting that for the integration of several systems you will not be able to use anything except database policies (or write a layer to work between different programs, but this will take a lot of time). That is why we should initially try to share data that will potentially change in other systems and data that is allowed to be edited only in our system. At the same time, it is necessary to separate them not just according to the tables, but carried out to different bases. But I will try to write about it next time.
So, authorization.
The simplest (which did not take a lot of time) and the action that we came up with is the following scheme:
o User enters username and password
o Password is converted by tricky algorithm, using all possible data about the hardware of the local machine
o A connection is created with the entered username and password received.
Thus, we fasten the data of a specific machine (the attacker will not be able to recreate them all, at least the unique number of the processor and network card). On the other hand, even having a computer at your disposal, you also need to know the user's password.
Of course, we understand that there are no impenetrable systems, but our cunning algorithm will force those who try to disassemble the code to sweat, which means it will give us time.
But the most important thing: even knowing the user's password and having access to the computer - you will not be able to do something really scary: the access rights policy will interfere.
2. Access policy
We have long been looking for a middle ground between the tools that the database offers us (MS SQL) and the fact that we build on. In the end, it was unequivocally decided that the detail provided by the database (separate rights to each table, view, and storage) is not enough - the entire logic of the business process is much more complicated.
In the end, we implemented the following two-tier security system scheme from client applications:
o When the application starts, a connection with the database is automatically created.
o The user enters the username and password, which are transmitted to the server in encrypted form with the operation code that the user wants to make (in this case, the connection)
o Next, the proprietary rights system returns a result that indicates the validity of this action (after receiving the result code, the program “understands” the data will be returned to it in the next request for receiving data).
Then this scheme is used everywhere, which allows you to completely shift the business process, taking into account the most sophisticated rights.
Thus, the DB toolkit gives us space for maneuvers regarding the operation of different systems with the database, and detailed logic is written at the application and database levels: the stored procedure will never return data if the function that checks the validity of user actions returns a failure code.
Total
It was a rather tedious and lengthy article, but I hope for someone it will be useful. If this happens all the same, then next time I would like to talk about the problem and the logic of the interactions of several systems.
Source: https://habr.com/ru/post/108617/
All Articles