Ideology and problems of developing financial systems. Part 1
In my humble experience, in our country there is no separation between software developers and developers of financial systems. The biggest thing I met at the interviews was the question of whether I was dealing with information systems that operate under high loads (Channel One, Yandex, etc.). For the rest, 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, architecture should always be in the first place: its balance, flexibility, security and thoughtfulness regarding the future development of the system (including possible integration with third-party systems that will not have that flexibility, thoughtfulness and that focus on the business process) .
An example of differences is the construction of conventional systems that focus on current information and financial systems.
A system of financial accounting and auditing is being created. The system, as they say, is all in one. The system is developed, accepted by the customer, developed and finalized. After a couple of years, the customer decides to divide the entire business process into two separate components, namely: the financial service is divided into two parts: financial and accounting. Under this business, the separation of systems is planned: the customer wants the old system to remain, but some functionality (related to accounting activities) was completely carried out in 1C-Accounting. And then immediately the question arises of the integration of the two systems. 1C-Accounting - a wonderful financial system, or rather not even 1C-Accounting, but the entire framework. I will not even talk about significant 1C problems: part of the built-in functionality is so “sewn in” that it will not work without consequences in the future; it is very difficult to integrate at least one directory from an external database. I’ll just say “on the fly” to load into it all the changes from the main system - a rather non-trivial task. But back to our system and ask ourselves this question: since we now have not one system, but two whole (three, four, five, ..) what to do with entities that become common to these systems. We can even omit the creation entities whose editing and deletion is allowed only in one of the systems (here the business process can be described even at the database level). But what to do, say, with directories common to both systems? After all, users are people who don’t feed bread - just let some information double up. The results of this may be, if not catastrophic, then they will take quite a few man-hours, which 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 statements for the year, and the data, say, on contracts is spreading. The users who are responsible for this data, of course, do not remember for what reason several months ago they did exactly what they did. The product owner’s logic usually boils down to “this is a system problem, you are responsible for it - you solve the problem”, forgetting that the problem may not be so much in the system as in the data. All this would not have happened under one condition - the architecture of the system and the rules of interaction would have been thought out from the very beginning. The users who are responsible for this data, of course, do not remember for what reason several months ago they did exactly what they did. The product owner’s logic usually boils down to “this is a system problem, you are responsible for it - you solve the problem”, forgetting that the problem may not be so much in the system as in the data. All this would not have happened under one condition - the architecture of the system and the rules of interaction would have been thought out from the very beginning. The users who are responsible for this data, of course, do not remember for what reason several months ago they did exactly what they did. The product owner’s logic usually boils down to “this is a system problem, you are responsible for it - you solve the problem”, forgetting that the problem may not be so much in the system as in the data. All this would not have happened under one condition - the architecture of the system and the rules of interaction would have been thought out from the very beginning.
Hereinafter, I would like to talk about the difficulties that our team faced. Perhaps if a few years ago such material had caught my eye, we would have avoided many of the problems that have taken (and continue to take) a lot of time from us. Even a simple mention would be enough for me that such and such a problem could arise because of this and that. Now I myself am ready to talk about several of these. In addition, I will try to outline the solutions that we discussed and which we eventually adopted. So, let's begin.
The authorization algorithm and planning the architecture of the access rights system at the design stage
It is obvious that all the nuances associated with the implementation of the business process are never taken into account, but it is worth thinking about them.
The simplest and most straightforward way that many people choose is to make a design of the form:
instance_work_class_db_db.connection method (username, password)
where username and password are the data that the user enters when starting the client.
One big security problem is already visible here. It just so happened that we have experience maintaining the system in the organization in which we serve the system, and competitors - the local network and users' machines. We would 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 it happens.
What can an attacker who has access to a user's machine do? He can do one simple thing - throw a memory dump onto the media and tear out the username and password in a calm environment.
Therefore, rule No. 1: confidential data (namely, data that has at least some restrictions on access) should be stored outside the server only during that period of time when the system cannot 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 username and password.
Now we pose the problem: how to verify 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, firstly, kills the entire security policy in the example above, and secondly, does not give any flexibility, which will be discussed later).
It is worth noting that for the integration of several systems it will not work to use anything other than database policies (or write a layer to work between different programs, but it will take a lot of time). That is why we must initially try to separate data that will potentially change in other systems and data that is allowed to be edited only in our system. At the same time, they should not be separated simply by tables, but taken out to different databases. But I’ll try to write about this next time.
So, authorization.
The simplest (which did not take a lot of time) and the effective thing that we came up with is the following scheme:
o The user enters the username and password
o The password is converted using a cunning algorithm using all possible data about the hardware of the local machine
o A connection is created with the user name entered and the password received .
Thus, we fasten the data of a specific machine (an attacker will not be able to recreate all of them, at least a unique processor and network card number). On the other hand, even if you have 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 make those who try to disassemble the code sweat, and therefore give us time.
But the most important thing: even knowing the user's password and having access to the computer, it will not be possible to accomplish something really scary: the access rights policy will interfere.
We have been looking for a middle ground for a long time between the tools that the database (MS SQL) offers us and what we build on. In the end, it was unequivocally decided that the detail provided by the database (individual rights to each table, presentation and storage) is not enough - the whole logic of the business process is much more complicated.
In the end, we implemented the following two-level security system scheme from client applications:
o When the application starts, a connection to the database is automatically created
o The user enters a username, password, which are transmitted to the server in encrypted form with the operation code that the user wants to perform (in this case connection)
o Further, the own system of rights 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 data request).
Further, this scheme is used everywhere, which allows you to completely shift the business process, taking into account the most sophisticated rights.
Thus, the database toolkit gives us room for maneuvering regarding the operation of different systems with the database, and detailed logic is prescribed at the application and database level: the stored procedure will never return data if the function that checks the validity of user actions returns a failure code.
Total
The result was a rather tedious and long article, but I hope for someone it will be useful. If this all the same happens, then next time I would like to talk about the problem and the logic of the interactions of several systems.
An example of differences is the construction of conventional systems that focus on current information and financial systems.
A system of financial accounting and auditing is being created. The system, as they say, is all in one. The system is developed, accepted by the customer, developed and finalized. After a couple of years, the customer decides to divide the entire business process into two separate components, namely: the financial service is divided into two parts: financial and accounting. Under this business, the separation of systems is planned: the customer wants the old system to remain, but some functionality (related to accounting activities) was completely carried out in 1C-Accounting. And then immediately the question arises of the integration of the two systems. 1C-Accounting - a wonderful financial system, or rather not even 1C-Accounting, but the entire framework. I will not even talk about significant 1C problems: part of the built-in functionality is so “sewn in” that it will not work without consequences in the future; it is very difficult to integrate at least one directory from an external database. I’ll just say “on the fly” to load into it all the changes from the main system - a rather non-trivial task. But back to our system and ask ourselves this question: since we now have not one system, but two whole (three, four, five, ..) what to do with entities that become common to these systems. We can even omit the creation entities whose editing and deletion is allowed only in one of the systems (here the business process can be described even at the database level). But what to do, say, with directories common to both systems? After all, users are people who don’t feed bread - just let some information double up. The results of this may be, if not catastrophic, then they will take quite a few man-hours, which 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 statements for the year, and the data, say, on contracts is spreading. The users who are responsible for this data, of course, do not remember for what reason several months ago they did exactly what they did. The product owner’s logic usually boils down to “this is a system problem, you are responsible for it - you solve the problem”, forgetting that the problem may not be so much in the system as in the data. All this would not have happened under one condition - the architecture of the system and the rules of interaction would have been thought out from the very beginning. The users who are responsible for this data, of course, do not remember for what reason several months ago they did exactly what they did. The product owner’s logic usually boils down to “this is a system problem, you are responsible for it - you solve the problem”, forgetting that the problem may not be so much in the system as in the data. All this would not have happened under one condition - the architecture of the system and the rules of interaction would have been thought out from the very beginning. The users who are responsible for this data, of course, do not remember for what reason several months ago they did exactly what they did. The product owner’s logic usually boils down to “this is a system problem, you are responsible for it - you solve the problem”, forgetting that the problem may not be so much in the system as in the data. All this would not have happened under one condition - the architecture of the system and the rules of interaction would have been thought out from the very beginning.
Hereinafter, I would like to talk about the difficulties that our team faced. Perhaps if a few years ago such material had caught my eye, we would have avoided many of the problems that have taken (and continue to take) a lot of time from us. Even a simple mention would be enough for me that such and such a problem could arise because of this and that. Now I myself am ready to talk about several of these. In addition, I will try to outline the solutions that we discussed and which we eventually adopted. So, let's begin.
The authorization algorithm and planning the architecture of the access rights system at the design stage
It is obvious that all the nuances associated with the implementation of the business process are never taken into account, but it is worth thinking about them.
1. Connection to the database.
The simplest and most straightforward way that many people choose is to make a design of the form:
instance_work_class_db_db.connection method (username, password)
where username and password are the data that the user enters when starting the client.
One big security problem is already visible here. It just so happened that we have experience maintaining the system in the organization in which we serve the system, and competitors - the local network and users' machines. We would 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 it happens.
What can an attacker who has access to a user's machine do? He can do one simple thing - throw a memory dump onto the media and tear out the username and password in a calm environment.
Therefore, rule No. 1: confidential data (namely, data that has at least some restrictions on access) should be stored outside the server only during that period of time when the system cannot 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 username and password.
Now we pose the problem: how to verify 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, firstly, kills the entire security policy in the example above, and secondly, does not give any flexibility, which will be discussed later).
It is worth noting that for the integration of several systems it will not work to use anything other than database policies (or write a layer to work between different programs, but it will take a lot of time). That is why we must initially try to separate data that will potentially change in other systems and data that is allowed to be edited only in our system. At the same time, they should not be separated simply by tables, but taken out to different databases. But I’ll try to write about this next time.
So, authorization.
The simplest (which did not take a lot of time) and the effective thing that we came up with is the following scheme:
o The user enters the username and password
o The password is converted using a cunning algorithm using all possible data about the hardware of the local machine
o A connection is created with the user name entered and the password received .
Thus, we fasten the data of a specific machine (an attacker will not be able to recreate all of them, at least a unique processor and network card number). On the other hand, even if you have 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 make those who try to disassemble the code sweat, and therefore give us time.
But the most important thing: even knowing the user's password and having access to the computer, it will not be possible to accomplish something really scary: the access rights policy will interfere.
2. Access policy
We have been looking for a middle ground for a long time between the tools that the database (MS SQL) offers us and what we build on. In the end, it was unequivocally decided that the detail provided by the database (individual rights to each table, presentation and storage) is not enough - the whole logic of the business process is much more complicated.
In the end, we implemented the following two-level security system scheme from client applications:
o When the application starts, a connection to the database is automatically created
o The user enters a username, password, which are transmitted to the server in encrypted form with the operation code that the user wants to perform (in this case connection)
o Further, the own system of rights 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 data request).
Further, this scheme is used everywhere, which allows you to completely shift the business process, taking into account the most sophisticated rights.
Thus, the database toolkit gives us room for maneuvering regarding the operation of different systems with the database, and detailed logic is prescribed at the application and database level: the stored procedure will never return data if the function that checks the validity of user actions returns a failure code.
Total
The result was a rather tedious and long article, but I hope for someone it will be useful. If this all the same happens, then next time I would like to talk about the problem and the logic of the interactions of several systems.