In Russia, electronic signature (EP) is used in virtually all areas, and many face the EP at their work.
The electronic signature consists of two parts – the closed one, also called the “key” and the open part, the certificate of verification of the electronic signature. The term “cloud EP” means that the certificate and
the closed part of the EP is stored, not as we are all used to – on a carrier, but inside the infrastructure of the organization that produced the signature. The module responsible for storing closed parts,
called the HSM (Hardware Security Module).
Most large organizations set up their own Certification Center (CA). Someone organizes a qualified, someone unqualified, depending on the purpose of the EP, and some –
and other. And not all users find it convenient to use multiple media to gain access to an information system that uses EP-based identification. solve this
the problem may be the so-called “cloud electronic signature”.
Consider the Russia-certified crypto-hardware cryptographic module HSM. Database suite of databases (DBs) and the CryptoPro module directly
HSM contained in DSS CryptoPro software solution – integrates with MSCA based MS (CryptoPro UC 2.0, CryptoPro 1.5), enabling the CA operator to produce keys directly from the application
DSS Crypto. The set of applications in this solution consists of: Identification Center (CI), web user interface, electronic signature service, audit service. In the case of distribution of all
applications on different servers provide network-level security, as all applications exchange information on key-based, one-off certificates,
specified at the system implementation stage. To ensure additional security, the database servers have to be installed separately.
The solution we want to talk about will protect the EP storage from external and internal violators. Suppose you have a UC based on KryptoPro components or its analogs, with
which is a compatible crypto pro DSS solution. An HSM module is installed in the control center of the MCC and, as described above, the private keys of the users will be stored. On the border of the controlled
zone of the UC is installed firewall and cryptographic gateway (“Continent”). It will provide a secure connection to the CryptoPro DSS components and the UC components. In the control zone of the CC, right away
for “Continent” we install WAF (Web Application Firewall). This product will track the transmitted methods for working with the DB from the CryptoPro DSS zone to the CC zone. Also on WAF protection policies
organizes protection of web applications against possible intrusion by a malefactor of access to UC websites. A cryptographic gateway is set up on the border of DSS and UC systems to organize the encrypted one
communication channel. On the border of the DSS, in contact with the main network of the enterprise, installed WAF and firewall. This equipment sets firewall rules and is configurable
WAF Web Application Security Policies describes methods that prevent database access. At this point, we have organized control zones and it is time to organize the DSS segment.
Based on information security, it is suggested that each DSS component be hosted on a separate server. This will reduce the possible load on the servers and allow you to organize
separately located database servers. We configure the database servers in the “hot” reserve according to the “always-on” principle. If the company has a large number of users, then it is necessary to put a balancer
load and organize a cluster of database servers. This also applies to web application servers. This is followed by the installation of the Crypto Pro DSS. This is responsible for identifying users on the system. identification
user is possible as a one-factor method, using only login and password, and two-factor when the user needs to specify an additional one-time password. one time password
can be sent to an email, mobile phone or token of identification. The comparison of the user with the identification token is carried out by the Operator upon confirmation of the user registration, or
by the user after completing the registration procedure and first logging in to the DSS user’s web portal. To do this, you need a database.
Once the user is authorized to do this, it enters the web user interface. The web user interface is a separate web application that integrates everything online
DSS and provides convenient navigation through the complex. From this application, the user can independently manage their EP containers, sign electronic documents and
etc., by going to the service “EP”, to audit the actions in the personal account (audit service). After setting up the CI and the web user interface, the trust setting is set between
applications by specifying the fingerprints of Web application data certificates and configuring WS-federation. Thus, the user when entering his personal account can be sure that his session
will be trusted and only valid between him and the DSS services. Connections between the CI and the web interface will be shared between different physical machines and will also use disposable
tokens for messaging. By intercepting the session and setting the ID, the attacker will not be able to access the transmitted information since the token used will no longer be liquid. For work
the web interface requires a database, which stores information about registered users.
The next step in the setup is to install and configure the DSS component – Service EP. Setting up a web application is similar. Additionally, when setting up the EP Service they are indicated
the registration center web site and DSS operators certificates, you can also specify the CA operator and assign him the DSS operator role. Thus, a single UAC and DSS operator is provided,
which will allow you to work centrally on a set of data systems. The DSS operator acts as the verifying authority, that is, checks the documents provided for the production of the user’s EP and
carries out the procedure of registration of the user in the UAC system. In fact, this operator sends a user registration request to the Registration Center and cannot manage the approval of this
by registration. The DSS operator also performs the procedure of administration of the user, can reset his password, specify a new method of secondary identification, change the contact information. All
described actions the user can carry out with the operator by phone. The EP service requires a database that stores all the activities of a registered user with
The next stage of DSS installation is the installation of an audit service, it is also conducted. The audit service stores in the database all the history of actions taken by registered users, being
centralized collection point of logs throughout DSS web applications.
The following user actions are performed by analogy with the standard workplace certificate usage scheme. The certificate is installed using the web interface
user. In addition to the ability to work through the web interface, the user can use a crypto provider, able to use a cloud-based EP, such as CryptoPro CSP 5.0. In the settings of this
provider specifies the address of the CI and the address of the EP service. Then everything happens by analogy with the use of a standard EP. When viewing the certificate in the container, an identification window appears where
the user enters their data. After successful authorization, the user sees all his containers from the EP, where he performs the certificate installation. After these actions, the certificate is ready for use.
When signing an EP document, the user is identified in the corresponding box and as a result of successful identification, the user has a successfully signed document.
This article gives a brief overview of how to install CryptoPro DSS services, how they work. It describes how WAF and Continent can provide additional
protection of the cloud services infrastructure.
leading engineer of Angara Professional Assistance
Electronic digital signature (EDS)