Electronic document management, EDS and system integration. Philosophical conclusions for a glass of wine
When organizing the interaction of systems belonging to different organizations, there are questions about the implementation of the integration of IP and legal - legal plan. I would like to share a little experience and conclusions obtained in the projects of such a plan. The information may seem interesting to analysts, designers, developers, and may be interested managers.
The first time I ran into EDS in my work, working on the auction site. The requirement to sign documents appeared because of the possible option of the winner refusing to pay the won auction for a promotion (English method) with the subsequent demand to return the security deposit (guarantee payment). Analysts generally had little idea how this should all happen, so I had to deal with one smart developer, going into some legal details. And not the fact that I correctly understood all the technical aspects.
')
The second time I ran into a project to refine the state system as an analyst, but neither the programmers nor the project manager, without understanding the essence of the problem, took the easiest way, the first ones thinking that they were doing the right thing, and the second to put them in time, it turns out that he deceived .
For further work in this area, the old company had to gather at a small table and discuss the problem a little.
The second retreat, in which a bit of essence
We, in Kazakhstan, are now quite relevant projects for the integration of various systems using web services. Different systems send each other requests for information and receive responses containing the necessary information to their requests. And before proceeding to the essence of the problem, consider an absurd example:
Aerospace Agency wants to quickly get information about registration of a potential space tourist in a drug treatment center. The Department for Accounting Addicts owns a database of registered users. What actions will take place:
1. A staff member of the Agency writes a letter of inquiry to the Department, indicating the data of a potential tourist, signs it with an authorized person, stamps it, registers the outgoing number with the clerk and sends it by fax / letter, asking to immediately send a fax / letter indicating the incoming numbers and date of the letter.
2. The Department Secretary receives the letter, registers in a special journal, assigning a number and date, sends the letter along an undetermined route for execution and sends the incoming number and date of the letter to the Agency.
3. A staff member of the Agency receives an incoming number and date, and goes about his business, with confidence that his request will be fulfilled.
4. A department employee checks the presence of a potential tourist in the database / file and writes a letter with the answer to the request, indicating the identification details of the request, signs, stamps, registers the outgoing number with the clerk and sends it by fax / letter. And ideally requests an incoming number and date for your answer.
5. The Secretary of the Agency accepts the letter, registers the incoming number and date of the letter, sends the letter to the requesting employee. And ideally sends the incoming number and date to the Department.
What are all these bureaucratic procedures for?
1. The agency knows that the request has arrived and must be processed.
2. The Agency may take any action if it has not received a response within the prescribed period.
3. The agency may take any action if the response contained incorrect data.
4. The agency can always report to the commission on the requests they sent and the answers they received.
5. The department may claim that the request was not received if they did not receive it and did not register it.
6. The Department may claim that the response to the request was received by the Agency.
7. The Department may report for the timing of the response to the request.
8. The department may claim that the response was received exactly as they sent it.
9. The Department may report to the Commission on the Rights of Addicts for all the answers they gave, indicating the requesters.
Those. All these procedures reduce misunderstandings, misunderstandings and mutual accusations of the two parties and they are necessary to resolve controversial issues. Considering the analogy of the interaction of information systems, we reduce the risks in the operation of information systems.
In fact, I see a situation where in most cases the integration of two systems occurs using one web service and one web service client. The following actions occur most often:
1. The client establishes a secure connection using a certificate issued by an accredited certifying center (AUC) and sends a request.
2. The service does incomprehensible checks (in terms of the fact that sometimes developers who do not have the necessary knowledge do not do all checks at all, but will prove that everything is working correctly) by authorizing and identifying the user, creates a response, signs the response with a digital signature of the responsible person (there may also be nuances here) and sends the answer to the client. Everything happens synchronously in one session.
3. The client receives the answer, saves it (it may not even check the correctness of the EDS, and this is what they saw) and enters the data into their system (sometimes even keeping the link to the saved request, and they also saw it).
If our developers are incomplete Landughs, then when the system is functioning, we have the following problems, which are solved in the paper workflow described above:
1. The client can not prove that his requests are not accepted or not processed.
2. Accordingly, the service can claim that no requests were received for it.
3. The service may claim that the answers do not come due to problems with the transport environment during long-term processing of the request.
4. The service may claim that it sends replies, but the client does not receive or save them.
5. The client can claim that he does not receive answers.
6. The commission, while investigating any incident, cannot verify all the requests of various clients for legality and the answers to these requests.
And if our developers are landukhs, then in general it can get to the court of law. So everything, in my opinion, rests on trust and on the fact that so far no one wants to raise this problem.
What the law on EDS and document flow says to us:
1. An electronic document can be created, transmitted, saved and filed by electronic means. An electronic document that complies with the requirements of this Law is equivalent to a paper document.
2. An electronic document is considered to be sent from the moment of its transmission over the information and communication network.
3. An incoming electronic document is considered to be received after it is recorded in the information system of the addressee.
4. The notification of receipt must contain data on the fact and time of receipt of the electronic document and its sender. In the case of non-receipt of its author is considered that the document is not received by the addressee.
(Everyone here again remembered that I am from Kazakhstan. What to do, local laws are at hand, the analogous law of the Russian Federation is a bit non-analogous, and if someone can dig in this direction, I will be glad. Most likely, there will be similar ones somewhere or similar requirements.)
And here is the document flow, you can ask. Moreover, the request (SOAP, XML RPC, etc.) that the client sends is an analogue of its paper request, letters with the text “We ask you to provide information ... blablabla”. And the answer is also a document.
Use a paper workflow model. To do this, you can apply the technology of asynchronous web services. Not in terms of multithreading. Very simple in the picture:
Technically, the following steps should be taken:
1. The requesting party forms a request with the necessary parameters. The request is signed by an EDS and a “time stamp” is attached to it. The request is saved in the log of sent requests and sent to the responding party.
2. The responding party accepts the request, checks the sender of the request, the correctness of the signature, the time stamp and the input parameters of the request, saves the request in the incoming request log, sends the request for subsequent processing to the IC and responds to the Requesting party with a signed digital signature and with a time stamp on the request in processing.
3. The requesting party checks the message about the acceptance of the request for processing for the correctness of the signature and the timestamp, saves the message and marks the request that it sent as received for processing.
4. The responding party, after forming the response, signs it, adds a timestamp, stores the response in the log of sent responses, and sends the response to the requester.
5. The requesting party accepts the response, checks the sender of the response, the correctness of the signature, the timestamp, stores the response, marks the request in the log of sent requests as fulfilled, transmits data from the response to the IC and responds to the Responding party with a signed EDS and a timestamp message, .
6. The responding party checks the message about acceptance of the response to the correctness of the signature and the time stamp, saves the message and marks the request in the log of received requests as fulfilled, and the answer as delivered.
This approach allows you to organize data exchange with the maximum legal responsibility of the parties and quickly diagnose transmission problems. Instead of swearing among themselves, integration leaders from both sides will clearly know at what stage the failure occurred.
And to give it all legal force:
1. Certificates for generating signatures must be issued / certified by an accredited certification center (we have a single “NUT” - national) in the Republic of Kazakhstan to the person responsible for the IP, with the right to sign documents from the LE to the owner of the IP.
2. Certificates for establishing SSL connections must also be issued / certified by an accredited certification authority.
3. To generate an EDS, a certified cryptographic provider is used, which forms a signature in accordance with the approved GOST.
I hope that someone this article will be necessary and will help in making decisions. And I hope that the proposed method will sooner or later be fixed by some legal act in order to cause as few misunderstandings as possible when using electronic document management. I will write to Medvedev (smiley). But I will have more than one project on the integration of IP, so that new topics may appear with a description of typical errors and systematized risks inherent in these projects.
And yes. It may seem like an absolutely unreadable style to someone. Well, forgive, so the brain is arranged.
The first retreat.
The first time I ran into EDS in my work, working on the auction site. The requirement to sign documents appeared because of the possible option of the winner refusing to pay the won auction for a promotion (English method) with the subsequent demand to return the security deposit (guarantee payment). Analysts generally had little idea how this should all happen, so I had to deal with one smart developer, going into some legal details. And not the fact that I correctly understood all the technical aspects.
')
The second time I ran into a project to refine the state system as an analyst, but neither the programmers nor the project manager, without understanding the essence of the problem, took the easiest way, the first ones thinking that they were doing the right thing, and the second to put them in time, it turns out that he deceived .
For further work in this area, the old company had to gather at a small table and discuss the problem a little.
The second retreat, in which a bit of essence
We, in Kazakhstan, are now quite relevant projects for the integration of various systems using web services. Different systems send each other requests for information and receive responses containing the necessary information to their requests. And before proceeding to the essence of the problem, consider an absurd example:
Aerospace Agency wants to quickly get information about registration of a potential space tourist in a drug treatment center. The Department for Accounting Addicts owns a database of registered users. What actions will take place:
1. A staff member of the Agency writes a letter of inquiry to the Department, indicating the data of a potential tourist, signs it with an authorized person, stamps it, registers the outgoing number with the clerk and sends it by fax / letter, asking to immediately send a fax / letter indicating the incoming numbers and date of the letter.
2. The Department Secretary receives the letter, registers in a special journal, assigning a number and date, sends the letter along an undetermined route for execution and sends the incoming number and date of the letter to the Agency.
3. A staff member of the Agency receives an incoming number and date, and goes about his business, with confidence that his request will be fulfilled.
4. A department employee checks the presence of a potential tourist in the database / file and writes a letter with the answer to the request, indicating the identification details of the request, signs, stamps, registers the outgoing number with the clerk and sends it by fax / letter. And ideally requests an incoming number and date for your answer.
5. The Secretary of the Agency accepts the letter, registers the incoming number and date of the letter, sends the letter to the requesting employee. And ideally sends the incoming number and date to the Department.
What are all these bureaucratic procedures for?
1. The agency knows that the request has arrived and must be processed.
2. The Agency may take any action if it has not received a response within the prescribed period.
3. The agency may take any action if the response contained incorrect data.
4. The agency can always report to the commission on the requests they sent and the answers they received.
5. The department may claim that the request was not received if they did not receive it and did not register it.
6. The Department may claim that the response to the request was received by the Agency.
7. The Department may report for the timing of the response to the request.
8. The department may claim that the response was received exactly as they sent it.
9. The Department may report to the Commission on the Rights of Addicts for all the answers they gave, indicating the requesters.
Those. All these procedures reduce misunderstandings, misunderstandings and mutual accusations of the two parties and they are necessary to resolve controversial issues. Considering the analogy of the interaction of information systems, we reduce the risks in the operation of information systems.
How it all happens in the mess around me.
In fact, I see a situation where in most cases the integration of two systems occurs using one web service and one web service client. The following actions occur most often:
1. The client establishes a secure connection using a certificate issued by an accredited certifying center (AUC) and sends a request.
2. The service does incomprehensible checks (in terms of the fact that sometimes developers who do not have the necessary knowledge do not do all checks at all, but will prove that everything is working correctly) by authorizing and identifying the user, creates a response, signs the response with a digital signature of the responsible person (there may also be nuances here) and sends the answer to the client. Everything happens synchronously in one session.
3. The client receives the answer, saves it (it may not even check the correctness of the EDS, and this is what they saw) and enters the data into their system (sometimes even keeping the link to the saved request, and they also saw it).
Problems that I see:
If our developers are incomplete Landughs, then when the system is functioning, we have the following problems, which are solved in the paper workflow described above:
1. The client can not prove that his requests are not accepted or not processed.
2. Accordingly, the service can claim that no requests were received for it.
3. The service may claim that the answers do not come due to problems with the transport environment during long-term processing of the request.
4. The service may claim that it sends replies, but the client does not receive or save them.
5. The client can claim that he does not receive answers.
6. The commission, while investigating any incident, cannot verify all the requests of various clients for legality and the answers to these requests.
And if our developers are landukhs, then in general it can get to the court of law. So everything, in my opinion, rests on trust and on the fact that so far no one wants to raise this problem.
I think that should be so ...
What the law on EDS and document flow says to us:
Law of the Republic of Kazakhstan of January 7, 2003 No. 370-II “On Electronic Document and Electronic Digital Signature”
Chapter 2. Electronic Document
Article 7. Requirements for electronic document circulation
1. An electronic document can be created, transmitted, saved and filed by electronic means. An electronic document that complies with the requirements of this Law is equivalent to a paper document.
2. An electronic document is considered to be sent from the moment of its transmission over the information and communication network.
3. An incoming electronic document is considered to be received after it is recorded in the information system of the addressee.
4. The notification of receipt must contain data on the fact and time of receipt of the electronic document and its sender. In the case of non-receipt of its author is considered that the document is not received by the addressee.
(Everyone here again remembered that I am from Kazakhstan. What to do, local laws are at hand, the analogous law of the Russian Federation is a bit non-analogous, and if someone can dig in this direction, I will be glad. Most likely, there will be similar ones somewhere or similar requirements.)
And here is the document flow, you can ask. Moreover, the request (SOAP, XML RPC, etc.) that the client sends is an analogue of its paper request, letters with the text “We ask you to provide information ... blablabla”. And the answer is also a document.
And what to do?
Use a paper workflow model. To do this, you can apply the technology of asynchronous web services. Not in terms of multithreading. Very simple in the picture:
Technically, the following steps should be taken:
1. The requesting party forms a request with the necessary parameters. The request is signed by an EDS and a “time stamp” is attached to it. The request is saved in the log of sent requests and sent to the responding party.
2. The responding party accepts the request, checks the sender of the request, the correctness of the signature, the time stamp and the input parameters of the request, saves the request in the incoming request log, sends the request for subsequent processing to the IC and responds to the Requesting party with a signed digital signature and with a time stamp on the request in processing.
3. The requesting party checks the message about the acceptance of the request for processing for the correctness of the signature and the timestamp, saves the message and marks the request that it sent as received for processing.
4. The responding party, after forming the response, signs it, adds a timestamp, stores the response in the log of sent responses, and sends the response to the requester.
5. The requesting party accepts the response, checks the sender of the response, the correctness of the signature, the timestamp, stores the response, marks the request in the log of sent requests as fulfilled, transmits data from the response to the IC and responds to the Responding party with a signed EDS and a timestamp message, .
6. The responding party checks the message about acceptance of the response to the correctness of the signature and the time stamp, saves the message and marks the request in the log of received requests as fulfilled, and the answer as delivered.
This approach allows you to organize data exchange with the maximum legal responsibility of the parties and quickly diagnose transmission problems. Instead of swearing among themselves, integration leaders from both sides will clearly know at what stage the failure occurred.
And to give it all legal force:
1. Certificates for generating signatures must be issued / certified by an accredited certification center (we have a single “NUT” - national) in the Republic of Kazakhstan to the person responsible for the IP, with the right to sign documents from the LE to the owner of the IP.
2. Certificates for establishing SSL connections must also be issued / certified by an accredited certification authority.
3. To generate an EDS, a certified cryptographic provider is used, which forms a signature in accordance with the approved GOST.
And as an afterword.
I hope that someone this article will be necessary and will help in making decisions. And I hope that the proposed method will sooner or later be fixed by some legal act in order to cause as few misunderstandings as possible when using electronic document management. I will write to Medvedev (smiley). But I will have more than one project on the integration of IP, so that new topics may appear with a description of typical errors and systematized risks inherent in these projects.
And yes. It may seem like an absolutely unreadable style to someone. Well, forgive, so the brain is arranged.
Source: https://habr.com/ru/post/138405/
All Articles