Menu
homePrograms

Protection of database management systems. Protection of information in databases

    the data in any table must be accessible to a limited number of users for selection and modification;

    For some tables, it is necessary to provide selective access to its columns;

    Some users should be prohibited from direct (via queries) access to tables, but allowed access to the same tables in a dialogue with the application program.

The data access scheme in relational DBMS is based on the principles:

    The DBMS performs operations on the database on behalf of a specific user, depending on whether the specific user has the rights to perform specific operations on a specific database object.

    Access objects are database elements whose access can be controlled (allowed or denied). A specific user has specific access rights to a specific object.

    Privileges are operations that a user is allowed to perform on specific objects.

2.5.4.2. Mechanism of roles in a DBMS

Ways to define user groups:

    the same identifier is used to access the database for an entire group of individuals (for example, employees of the same department);

    a specific individual is assigned a unique identifier.

A mixed method is also used, in which the group identifier and a unique user identifier are stored. Most often, a user group corresponds to a structural unit of an organization. Privileges are established not only for individual users, but also for their groups.

2.5.5. Protecting information on networks

2.5.5.1. General characteristics of network attacks

Classification of remote attacks is carried out according to various criteria:

1. By the nature of the impact:

Passive - external, do not in any way affect the operation of the computing system and the transmitted data (for example, simple listening);

Active – have a direct impact on the operation of the system (change in the configuration of a distributed computing system (DCS), disruption of performance, etc.).

2. According to the purpose of influence:

The threat of disclosure (leakage) of information, i.e. interception of information without the purpose of modification;

Integrity threat – unauthorized access to information and the possibility of its modification;

The threat of denial of service is a disruption of the system.

3. At the moment of the start of the attack:

Upon request from the attacked object (DNS, ARP requests);

Upon the occurrence of an expected event on the attacked object (for example, a TCP connection is broken);

Unconditional attacks are carried out immediately and regardless of the state of the system and the attacked object.

4. Based on feedback:

With feedback (for some requests sent to the attacked object, the attacker needs to receive a response);

No feedback.

5. By location of the subject of the attack (source of the attack):

Intrasegmental location of the source;

Intersegmental.

6. According to the OSI level (MVOS)

2.5.5.2. Typical security threats

Typical remote attack – this is a remote information destructive effect, carried out programmatically via a communication channel, characteristic of any distributed computing system (DCS).

Here are the characteristics of typical threats in accordance with the classification considered:

1. Network traffic analysis – intra-segment passive threats of disclosure without feedback, applied at the physical or link level.

2. Substitution of a computer system object - when establishing a virtual connection, active influence, threat of disclosure or threat to integrity. Executed by event. Captures the link, network or transport layers.

3. False object injection:

a) imposition of a false route, possibly due to the presence of protocols that allow you to remotely change routing on the Internet (RIP, OSPF, ICMP, SNMP protocols);

b) exploiting the shortcomings of remote access algorithms (TCP protocol, DNS query).

4. Denial of service (DoS) - active impact; unconditional; intersegmental and intrasegmental; at the transport and application levels.

2.5.5.3. Typical attacks in TCP/IP networks

Traffic analysis (sniffing)

Sniffing allows you to study the operating logic of PBC, allows you to intercept data streams exchanged between objects - unauthorized access to the network without modifying data.

Protection: data encryption; you can also encrypt files and share at the file level; Ethernet switching (Figure 7); dedicated communication channel between RVS objects.

False ARP server.

Communication between two remote hosts is carried out by transmitting messages over the network, which are enclosed in exchange packets. The data field contains either the data itself or another higher-level OSI packet. For example, a transport layer packet can be nested within a network layer packet, which in turn is nested within a link layer packet. Projecting this statement onto a network OS that uses TCP/IP protocols, we can say that the TCP packet (transport layer) is nested in the IP packet (network layer), which, in turn, is nested in the Ethernet packet (link layer). Thus, the structure of a TCP packet looks like shown in Figure 8.

The ARP protocol is used to obtain an Ethernet address. It matches the address of the network card with the address of a specific computer. It works like this:

a) The computer sends a broadcast (to everyone at once) ARP request with the required IP address.

b) The computer with the requested address sends a response indicating its Ethernet address to the Ethernet address of the requester. The requested computer receives a response and writes a pair of IP and Ethernet addresses to its local ARP table.

Attack mechanism: the attacker's host sends a false ARP response and in the future will receive all data addressed to a different address (Figure 9).

False DNS server

False DNS works like this:

    Host sends a request to determine the address to the information search DNS server.

    If the domain is local, then the server itself answers the request, otherwise it sends the request to the root DNS server.

    The root server determines the local server for the domain and sends a response to it.

At any stage, responses are cached by the server and client.

There are 3 attack scenarios:

1) Intercepting a request and attempting a false response.

2) A storm of false DNS responses on behalf of the real DNS server.

3) A storm of false DNS responses to the attacked DNS server.

As can be seen from the above formulations, the attack ideas are quite close to the idea of ​​a false ARP server. The DNS service operates over UDP, which differs from TCP in that it does not guarantee connection establishment and delivery.

The first scenario is illustrated in Figure 10. The attacker must be in the path of the main traffic or in the segment of the real DNS server.

Figure 9. Attack using a fake ARP server

a – ARP request waiting phase; b – attack phase; c – phase of receiving, analyzing, influencing and transmitting intercepted information on a false ARP server

Figure 10. Attack by intercepting a request to a DNS server

a – DNS request waiting phase; b – phase of transmitting a false DNS response to the attackers; c – phase of receiving, analyzing, influencing and transmitting intercepted information on a false DNS server

The essence of the second scenario is that false DNS responses are constantly generated by the attacking host, and the attacked host, having made a DNS request, immediately receives a DNS response from the attacker. It contains the attacker's address as the host's IP address. As a result, the attacker will direct all requests to the attacker’s address (Figure 11).

The third scenario consists of organizing a directed flow of responses to the DNS server, as a result of which the server perceives one of these responses as a response to its request and enters its results, i.e., the IP address of the attacking host, into its cache (Figure 12).

    using the hosts file. (inconvenient method for a large number of machines);

    using TCP protocols instead of UDP;

    To protect the network, they try to avoid using DNS services in general.

Protection against Internet attacks:

    filters at the entrance and exit from the network, route control;

    fictitious addresses and gateways (socks, proxy);

    using TCP rather than UDP(named,NFS);

    static ARP and DNS;

    traffic encryption (IPSEC, SKIP, SSL, SSH);

    tunneling with encryption;

    avoidance of broadcast technologies (Ethernet switching, refusal of radio access and asymmetric satellite connections);

    control over CERT and CIAC messages (American Computer Security Centers: www.cert.org And www.ciac.org);

    use of anti-virus tools (on mail servers and browsers);

    use of automated security control tools (SATAN, SAFEsuite, RealSecure, JohnTheRipper, Orge).

In addition, the following solutions are used to protect against intrusion through the use of Web applications:

    disabling Java and all types of scripting languages ​​except JavaScript (many pages will not work);

    use of online antiviruses (AVP);

    allocation of a special computer for Internet access.

Today, among the dynamic page technologies that are more or less safe for a client computer on the Internet, only DHTML (HTML4.0) and JavaScript can be called. It's better to turn everything else off.

Figure 11. Attack by storming DNS responses from a fake server

a – phase of organizing a storm of false DNS responses; b – the phase when the attacked host receives a DNS response to its request; c – phase of receiving, analyzing, influencing and transmitting intercepted information on a false DNS server

Figure 12. Attack by storming DNS responses to the attacked DNS server

a – the phase of waiting for the attacker to receive a DNS request from the DNS server (to speed things up, the attacker generates the necessary DNS request); b – phase of transmitting a false DNS response to the DNS server to the attackers; c – the DNS server issues the IP address of the attacking host in response to requests

The X.800 standard describes the fundamentals of security in relation to a seven-layer reference model. The standard provides the following security services:

    authentication (meaning authentication of communication partners and authentication of data source);

    access control - provides protection against unauthorized use of resources available over the network;

    data confidentiality - X.800 combines significantly different things under this name - from protecting a single piece of data to traffic confidentiality;

    data integrity - this service is divided into subtypes depending on what is controlled - the integrity of messages or data flow, whether recovery is provided in case of integrity violation;

    non-repudiation - this service belongs to the application level, i.e. it means the inability to refuse meaningful actions, such as sending or reading a letter.

The X.509 standard describes an authentication procedure using a directory service. However, the most valuable thing in the standard was not the procedure itself, but its service element - the structure of certificates that store the user name, cryptographic keys and related information. Such certificates are an essential element of modern authentication and integrity monitoring schemes.

The recommendations of periodically organized conferences on Internet security architecture are very general and sometimes formal in nature. The main idea is to provide end-to-end security through end systems. Network infrastructure is expected to be, at best, resilient to availability attacks.

The basic protocols that are most useful from a security point of view include Ipsec, DNSsec, S/MIME, X.509v3, TLS and associated ones. The most developed issues today are issues of protection at the IP level. The IPsec family specifications cover the following aspects:

    access control;

    integrity control at the packet level;

    data source authentication;

    replay protection;

    confidentiality (including partial protection from traffic analysis);

    administration (cryptographic key management).

Authenticity and confidentiality protocols can be used in two modes: transport and tunnel. In the first case, only the contents of the packets and perhaps some header fields are protected. Typically, transport mode is used by hosts. In tunnel mode, the entire packet is protected - it is encapsulated in another IP packet. Tunnel mode (tunneling) is usually implemented on specially dedicated security gateways (which can be routers or firewalls).

Tunneling can be used at both the network and application levels. For example, tunneling for IP and double conversion for X.400 mail have been standardized.

At the transport layer, the authenticity, confidentiality and integrity of data streams are ensured by the TLS protocol (TransportLayerSecurity, RFC2246). We emphasize that here the object of protection is not individual network packets, but data streams (sequences of packets). An attacker will not be able to reorder packages, remove some of them, or insert his own.

Secure application-level protocols can be built on the basis of TLS. In particular, specifications have been proposed for HTTP over TLS.

2.5.5.5. Architecture of information security mechanisms in computer networks

The VOS model distinguishes the following main active methods of unauthorized access to information:

    disguising one logical entity as another with greater authority (false subscriber authentication);

    message redirection (deliberate distortion of address details);

    modification of messages (deliberate distortion of the information part of the message);

    blocking a logical object in order to suppress certain types of messages (selective or complete interception of messages from a specific subscriber, violation of control sequences, etc.).

List of types of services provided for information protection, which are provided using special protection mechanisms:

    Authentication of an equivalent logical entity (authentication of the remote recipient subscriber). Authentication requires the underlying layer to provide connection-oriented services.

    Data source authentication - confirmation of the authenticity of the source (sender subscriber) of the message.

    Access control (access control) - provides protection against unauthorized access to resources potentially accessible through VOS.

    Connection privacy - ensures the confidentiality of all messages transmitted by users within a given connection.

    Connectionless Privacy - Ensures the confidentiality of all user data in a message (a single service data block) transmitted in connectionless mode.

    Data field secrecy - ensures the confidentiality of individual user data fields throughout the entire connection or in a separate service data block.

    Traffic secrecy - prevents the ability to extract information from the observed graph.

    Connection integrity with recovery - allows you to detect insertion, deletion, modification or redirection attempts in a sequence of service data blocks. If integrity is violated, an attempt is made to restore it.

    Connection integrity without recovery.

    Connection-mode Data Field Integrity - Ensures the integrity of an individual user data field throughout the entire flow of service data blocks.

    Data field integrity in connectionless mode - allows you to detect modification of the selected field in a single service data block.

    Connectionless Data Block Integrity - Ensures the integrity of a single service data block during connectionless operation and allows modification and some forms of insertion and redirection to be detected.

    Informing about the sending of data - allows you to identify the sender of information on the recipient side.

    Delivery notification – provides the sender with information about the fact that the data has been received by the addressee.

It has been theoretically proven, and the practice of protecting networks has confirmed that all of the listed services can be provided by cryptographic security means, due to which these means form the basis of all information protection mechanisms in the armed forces. The following tasks are central to this:

    mutual identification (authentication) of network subscribers entering into communication;

    ensuring the confidentiality of data circulating on the network;

    ensuring legal liability of subscribers for transmitted and received data.

The solution to the last of these problems is provided using the so-called digital (electronic) signature.

Internal company operating information, employee personal data, financial information, customer and client information, intellectual property, market research, competitor analysis, payment information - these are the types of information that cybercriminals are most often interested in, and they are almost always stored in corporate databases.

The significance and value of this information leads to the need to protect not only infrastructure elements, but also the databases themselves. Let's try to comprehensively consider and systematize the security issues of various database management systems (DBMS) in the light of new threats, general trends in the development of information security and their increasing role and diversity.

Almost all major DBMS manufacturers are limited to developing the concept of confidentiality, integrity and availability of data, and their actions are aimed mainly at overcoming existing and already known vulnerabilities, implementing basic access models and addressing issues specific to a particular DBMS. This approach provides solutions to specific problems, but does not contribute to the emergence of a general security concept for such a class of software as a DBMS. This greatly complicates the task of ensuring the security of data warehouses in an enterprise.

History of DBMS development

Historically, the development of database security systems occurred in response to the actions of attackers. These changes have also been driven by the overall evolution of databases from mainframe solutions to cloud storage.

The following architectural approaches can be distinguished:

  • full access of all users to the database server;
  • division of users into trusted and partially trusted by DBMS means;
  • introduction of an audit system (logs of user actions) using DBMS tools;
  • introduction of data encryption; moving authentication tools outside the DBMS to operating systems and middleware; refusal of a fully trusted data administrator.

The introduction of security measures in response to threats does not provide protection against new attack methods and creates a fragmented view of the security problem itself.

Taking into account such evolutionary features, a large number of heterogeneous security tools have appeared and exist, which ultimately led to a lack of understanding of comprehensive data security. There is no common approach to data storage security. Predicting future attacks and developing defense mechanisms are also becoming more difficult. Moreover, for many systems, attacks that have been known for a long time remain relevant, and the training of security specialists becomes more complicated.

Modern problems of database security

The list of main DBMS vulnerabilities has not undergone significant changes in recent years. Having analyzed the DBMS security tools, database architecture, known vulnerabilities and security incidents, we can identify the following reasons for this situation:

  • Only large manufacturers take security issues seriously;
  • database programmers, application programmers and administrators do not pay due attention to security issues;
  • different scales and types of stored data require different approaches to security;
  • different DBMSs use different language constructs to access data organized based on the same model;
  • New types and models of data storage are emerging.

Many vulnerabilities remain relevant due to inattention or ignorance of database system administrators about security issues. For example, simple SQL injections are widely used today against various web applications that do not pay enough attention to the query input data.

The use of various information security tools is a financial compromise for the organization: the introduction of more secure products and the selection of more qualified personnel require greater costs. Security components can often negatively impact the performance of a DBMS.

These problems are aggravated with the advent and widespread use of non-relational DBMSs, which operate on a different data model, but are built on the same principles as relational ones. The variety of modern NoSQL solutions leads to a variety of data models used and blurs the boundary of the concept of a database.

The consequence of these problems and the lack of uniform methods is the current security situation. Most NoSQL systems lack not only generally accepted security mechanisms such as encryption, data integrity support and data auditing, but even developed means of user authentication.

Database protection features

Data storage includes two components: stored data (the database itself) and management programs (DBMS).

Ensuring the security of stored information, in particular, is impossible without ensuring secure data management. Based on this, all DBMS vulnerabilities and security issues can be divided into two categories: data-dependent and data-independent.

Vulnerabilities independent from data are also typical for all other types of software. Their cause, for example, may be untimely software updates, the presence of unused functions, or insufficient qualifications of software administrators.

Most aspects of DBMS security are data dependent. In the same time many vulnerabilities are indirectly data dependent. For example, most DBMSs support data queries using some query language containing sets of user-accessible functions (which, in turn, can also be considered query language operators) or arbitrary functions in a programming language.

The architecture of the languages ​​used, at least as far as specialized languages ​​and feature sets are concerned, is directly related to the data model used to store information. Thus, the model determines the features of the language and the presence of certain vulnerabilities in it. Moreover, such vulnerabilities, for example, injection, are performed differently (sql injection, java injection) depending on the syntax of the language.

Database security requirements

Based on the division of vulnerabilities, it is possible to distinguish between data-dependent and data-independent measures to ensure the security of information storage facilities.

Data independent The following requirements for a secure database system can be mentioned:

  • Operating in a trusted environment.

A trusted environment should be understood as the enterprise infrastructure and its protective mechanisms determined by security policies. Thus, we are talking about the functioning of the DBMS in accordance with the security rules that apply to all other enterprise systems.

  • Organization of physical security of data files.

The physical security requirements for DBMS data files are generally no different from the requirements that apply to any other user and application files.

  • Organizing a secure and up-to-date DBMS setup.

This requirement includes general security tasks such as keeping updates up to date, disabling unused features, or maintaining an effective password policy.

The following requirements can be called data dependent:

  • Security of user software.

This includes the tasks of building secure interfaces and data access mechanisms.

  • Secure organization and work with data.

The issue of data organization and management is key in information storage systems. This area includes tasks of organizing data with integrity control and other DBMS-specific security problems. In fact, this task includes the bulk of data-dependent vulnerabilities and protection against them.

Basic aspects of creating secure databases

To solve the identified problems of ensuring DBMS information security, it is necessary to move from the method of closing vulnerabilities to an integrated approach to ensuring the security of information repositories. The main stages of this transition should be the following provisions.

  • Development of comprehensive methods for ensuring the security of data warehouses in an enterprise.

The creation of complex methods will allow them to be used in the development and implementation of data warehouses and custom software. Following a comprehensive methodology will allow you to avoid many DBMS management errors and protect yourself from the most common vulnerabilities today.

  • Assessment and classification of DBMS threats and vulnerabilities.

The classification of DBMS threats and vulnerabilities will allow them to be organized for subsequent analysis and protection, and will enable security specialists to establish the relationship between vulnerabilities and the reasons for their occurrence. As a result, when introducing a specific mechanism into a DBMS, administrators and developers will have the opportunity to identify and predict the threats associated with it and prepare appropriate security measures in advance.

  • Development of standard security mechanisms.

Standardization of approaches and languages ​​for working with data will make it possible to create security tools applicable to different DBMSs. At the moment, they can only be methodological or theoretical, since, unfortunately, the emergence of ready-made complex software security tools largely depends on the manufacturers and developers of the DBMS and their desire to create and follow standards.

about the author

Maxim Sovetkin graduated from the Faculty of Mechanics and Mathematics of the Belarusian State University and has been working at Itransition for more than seven years. Today he is a leading systems engineer, responsible for the design, development and support of corporate IT infrastructure.

The database is a critical corporate resource that must be properly protected with appropriate controls. There are dangers such as:

  • * theft and falsification of data;
  • * loss of confidentiality (violation of secrecy);
  • * violation of personal data privacy;
  • * loss of integrity;
  • * loss of availability.

Data protection issues are often discussed in conjunction with

maintaining data integrity (at least in an informal context),

although in reality these are completely different concepts. Term protection

refers to the security of data from unauthorized access, alteration, or intentional destruction, and integrity refers to the accuracy or reliability of the data. These terms can be defined as below.

  • · Data security means preventing access to it by unauthorized users.
  • · Maintaining data integrity means preventing

their destruction upon access by authorized users.

In other words, data protection is getting assurances that users are allowed to do the things they are trying to do, and integrity maintenance is getting guarantees that the actions users are trying to do will be acceptable.

There are some similarities between these concepts, since both in ensuring data protection and in maintaining data integrity, the system is forced to check whether certain established restrictions are violated by user actions. These restrictions are formulated (usually by the database administrator) in some suitable language and stored in the system directory. Moreover, in both cases, the DBMS must somehow track all actions performed by the user and check their compliance with the established restrictions.

These two topics are discussed separately, since data integrity is a fundamental concept, while data protection is a secondary concept, despite its great practical importance (especially in these days of the ubiquity of the Internet, e-commerce and related access tools).

The many aspects of the data protection issue are described below.

  • · Legal, social and ethical aspects (for example, whether a person has a legal basis for asking, say, information about a client's loan).
  • · Physical conditions (for example, is the room containing computers or terminals locked or otherwise secured).
  • · Organizational issues (for example, how does the enterprise that owns the system decide who is allowed to have access to certain data).
  • · Management issues (for example, how, if a system is protected from unauthorized access using a password scheme, the secrecy of the passwords used is ensured and how often they are changed).
  • · Hardware security features (for example, does the computing equipment used have built-in security features such as keys to protect stored information or privileged management mode).
  • · Operating system capabilities (for example, whether the operating system you are using erases the contents of RAM and disk files when you stop working with them, and how the recovery log is processed).
  • · Aspects directly related to the DBMS itself (for example, whether the DBMS being used supports the concept of a data owner).

Typically, modern DBMSs support one of two widely used methods of organizing data protection - selective or mandatory, and sometimes both of these methods. In both cases, the data unit (or data object) for which protection is organized can be selected from a wide range, from the entire database to specific components of individual tuples. The differences between these two methods are briefly described below.

In selective control, each user is typically granted different access rights (otherwise known as privileges) to different objects. Moreover, different users typically have different access rights to the same object. (For example, user U1 may be allowed access to object A but denied access to object B, while user U2 may be allowed access to object B but denied access to object A.) Therefore, election schemes have considerable flexibility.

In the case of mandatory control, on the contrary, each data object is assigned a certain classification level, and each user is assigned a certain level of access. As a result, only those users who have the appropriate level of access are granted access to the data object. Mandate schemes usually have a hierarchical structure and are therefore more rigid. (If user U1 has access to object A, but does not have access to object B, then in the security scheme object B will have to be located at a higher level than object A, which means there cannot be any user U2 who will have access to object B, but will not have access to object A.)

Regardless of which scheme is used (selective or mandatory), all decisions regarding granting users the rights to perform certain operations with certain objects must be made exclusively by management personnel. Therefore, all these issues are beyond the capabilities of the DBMS itself, and all that it can do in this situation is to put into action decisions that will be made at another level. Based on these considerations, the following conditions can be determined.

  • · The adopted organizational decisions must be brought to the attention of the system (i.e., presented as security restrictions expressed using some language for describing security requirements) and must be constantly available to it (stored in the system directory).
  • · Obviously, the system must have some means of checking incoming access requests against established security rules. (Here, the term access request refers to the specific combination of the requested operation, the requested object, and the requesting user.) Typically, such verification is performed by the DBMS security subsystem, which is sometimes also called the authorization subsystem.
  • · To decide which specific security restrictions apply to a given access request, the system must be able to determine the source of the request, i.e. be able to identify the requesting user. Therefore, when connecting to a system, the user is usually required to enter not only his ID (to indicate who he is) but also a password (to confirm that he is who he says he is). It is assumed that the password is known only to the system and those persons who have the right to use this user ID. The process of verifying a password (i.e., verifying that users are who they say they are) is called authentication.

It should also be noted that nowadays there are much more complex authentication methods compared to simple password verification, in which a number of biometric devices are used for authentication: fingerprint readers, iris scanners, palm geometric analyzers, voice checkers, signature recognition devices, etc. All of these devices can be effectively used to verify "personal characteristics that no one can fake."

By the way, with regard to user IDs, it should be noted that the same ID can be shared among a number of different users that are part of a certain group. In this way, the system can support groups of users (also called roles), providing equal access rights for all its members, for example, for all employees in the accounting department. In addition, the operations of adding new users to a group or removing them from it can be performed independently of the operations of setting access privileges for this group on certain objects.

Selective access control scheme

It should be noted again that many DBMSs support either selective or mandatory access control schemes, or both types of access simultaneously. However, it would be more accurate to say that in reality, most DBMSs support only a selective access scheme, and only a few support only a mandatory access scheme. Because in practice, selective access schemes are much more common.

Some language must be used to define selective protection restrictions. For obvious reasons, it is much easier to indicate what is permitted than what is not permitted. Therefore, such languages ​​usually support the definition not of security restrictions themselves, but of powers that are inherently the opposite of security restrictions (i.e., they allow certain actions rather than prohibit them). Let's give a brief description of a hypothetical language for defining powers using the following example.

GRANT RETRIEVE ( S#, SNAME, CITY ), DELETE

TO Jim, Fred, Mary;

This example illustrates the fact that, in general, access permissions include the four components described below.

  • 1. Name (in this example SA3, "suppliers authority three" - the authority of the supplier with number 3). The permissions you set will be registered in the system directory under this name.
  • 2. One or more privileges specified in the GRANT construct.
  • 3. The name of the relation variable to which the permissions are applied, specified in the ON construct.
  • 4. Many users (more precisely, user IDs), which are granted the specified privileges with respect to the specified relation variable specified using the TO clause.

The following is the general syntax for the authority definition statement.

AUTHORITY

GRANT

ON

TO ;

Mandatory access control scheme

Mandatory access control methods are applied to those databases in which the stored information has a fairly static and rigid structure, which is typical, for example, of some military or government organizations. The basic idea is that each data object is assigned a certain classification level (or the required security classification, for example “Top Secret”, “Secret”, “For Official Use”, etc.), and each user is given a graded security clearance level , similar to existing classification levels. It is assumed that these levels form a strict hierarchical system (for example, “Top Secret” > “Secret” > “For Official Use”, etc.). Then, based on these provisions, two very simple rules can be formulated, first proposed by Bell and La Padula.

  • 1. User i can sample data from object j only if his security level is greater than or equal to the classification level of object j (simple security property).
  • 2. User i can modify object j only if his clearance level is equal to the classification level of object j (star property).

The first rule is quite obvious, while the second requires additional explanation. First of all, it should be noted that another way to formulate the second rule is: “By definition, any information recorded by user i automatically acquires a classification level that is equal to the clearance level of user i.” Such a rule is necessary, for example, to prevent the recording of secret data by a user with access level

“Secret”, to a file with a lower classification level, which will violate the entire secrecy system.

Data encryption

Previously, it was assumed that some malicious user was trying to illegally break into the database using the normal access tools available on the system. Now we should consider the case where he tries to penetrate the database bypassing system, i.e. physically moving external storage media or connecting to a communication line. The most effective method of combating such threats is data encryption, i.e. storage and transmission of particularly important data in encrypted form.

To learn the basic concepts of data encryption, you need to introduce some new concepts. The original (unencrypted) data is called plaintext.

The plaintext is encrypted using a special encryption algorithm. The input to such an algorithm is plaintext and the encryption key, and the output is a transformed form of the plaintext, called ciphertext. Details of the encryption algorithm may be published, but the encryption key is never disclosed. It is the encrypted text, incomprehensible to anyone who does not have the encryption key, that is stored in the database and transmitted over the communication line.

Example 5.1. Let the following string be given as the plaintext.

AS KINGFISHERS CATCH FIRE (For ease of presentation, the data here is assumed to consist of only spaces and uppercase characters.) Additionally, assume that the encryption key is the following string.

The encryption algorithm used is described below.

1. Split the plaintext into blocks whose length is equal to the length of the encryption key.

AS+KI NGFIS HERS+ CATCH +FIRE

  • (Here spaces are indicated by a "+" sign.)
  • 2. Replace each plaintext character with an integer in the range 00-26, using 00 for space, 01,... for A, and 26 for Z. The result is the following string of numbers.
  • 0119001109 1407060919 0805181900 0301200308 0006091805
  • 3. Repeat step 2 for the encryption key, resulting in the following string of numbers.
  • 0512091520
  • 4. Now sum the values ​​​​placed for each character in each block of plaintext with the corresponding values ​​​​substituted for the encryption key characters, and for each sum of these two values, determine and write the remainder of division by 27.
  • 5. Replace each number in the bottom line of step 4 with the corresponding text symbol.

FDIZB SSOXL MQ+GT HMBRA ERRFY

If the encryption key is known, then the decryption procedure in this example can be performed quite simply. The question is how difficult it is for an illegal user to determine the encryption key given the plaintext and the ciphertext. In this simple example, this is not very difficult to accomplish, but it is clear that more complex encryption schemes can be developed. Ideally, the encryption scheme should be such that the effort spent on decrypting it is many times greater than the benefit obtained. (In fact, this remark applies to all aspects of the security problem, i.e., the cost of attempting to crack the security system should be significantly higher than the potential benefit from this.) The ultimate goal of the search for such schemes should be considered a scheme for which its developer himself, having open and encrypted variants of the same part of the text, unable to determine the key and therefore decrypt another part of the ciphertext.

Security management is usually carried out at three levels:

  • * database level;
  • * operating system level;
  • * network level.

At the operating system level, the database administrator (DBA) must have rights to create and delete database-related files. On the contrary, ordinary users should not have such rights. Refer to standard Oracle documentation for operating system-level security information. In many large organizations, the DBA or database security administrator works closely with computer system administrators to coordinate efforts to develop security requirements and practices.

Database security requirements describe procedures for granting access to the database by assigning each user a username/password pair. Requirements may also limit the amount of resources (disk space and CPU time) allocated to one user and stipulate the need to audit user actions. Database-level security also provides access control to specific database schema objects.

The work examines some of the most significant legal requirements for the protection of personal data (PD). General approaches to protecting databases managed by a DBMS are presented. An example of PD protection taking into account legal requirements for the Oracle platform is shown - one of the most widely used in medium and large information systems.

The law on the protection of personal data is not implemented. Why?

To begin with, let us recall some provisions of Federal Law No. 152 “On Personal Data”.

According to Article 3 of the law, “an operator is a state body, municipal body, legal entity or individual that organizes and (or) carries out the processing of personal data, as well as determining the purposes and content of the processing of personal data.” Thus, we come to the conclusion from which we will proceed: almost all legal entities of the Russian Federation are potential PD operators.

The law also explicitly states that the processing of personal data means almost everything that can be done with them, from receiving data to its depersonalization and destruction: “processing of personal data - actions (operations) with personal data, including collection, systematization, accumulation , storage, clarification (updating, changing), use, distribution (including transfer), depersonalization, blocking, destruction of personal data."

In addition, the requirements of the Law “On the Protection of Personal Data” No. 152-FZ contain some, to put it mildly, unusual procedures for Russian organizations, such as:

  • obtaining consent from citizens to process their personal data, including (when necessary) transfer to third parties;
  • determination of the composition of personal data for each information system processing personal data (ISPD);
  • classification of ISPD by data volume and security characteristics depending on the assessment of possible damage to data subjects;
  • preparation and organization of regular notifications about the processing of personal data to the authorized body.

Let us note that the vast majority of Russian organizations do not have the practice of meeting such requirements. There are no established rules for mutual trust relationships; for example, it is extremely rare that an offer agreement is drawn up for consent to use the personal data of citizens. But this approach has been successfully practiced in developed countries for quite a long time. And one more thing: even if such an agreement would clearly define what types of processing of personal data are permitted by a particular organization, as well as who specifically would be held responsible for violation of the agreed types of processing and compromise of personal data, few citizens would decide to conclude such an agreement. Given the vagueness of the wording of the legislation, it is obvious that even if a citizen gave his consent to the processing of his personal data, in any case he would be completely dependent on how wisely and conscientiously the operator would interpret the provisions of the law.

It is worth adding that, according to some data, the mentioned classification and the requirements corresponding to each class, according to Government Decree No. 781, have already been developed by FSTEC, the FSB and the Ministry of Information and Communications of Russia and will be published in the near future. This long-awaited document will shed light on these and other aspects of the practical application of Federal Law-152. But the main hopes associated with it lie in receiving practical instructions on how to implement the requirements of the law for government organizations processing citizens’ personal data.

By and large, commercial structures have long been protecting business-critical data (for example, the register of shareholders and other commercial information), including personal data. However, few organizations comply with the requirements of federal trade secret law, but this is a broad topic beyond the scope of this article.

In turn, government organizations are waiting for specific instructions and methods for building protection systems, depending on the class of the information system and the nature of the data processed by this system. I would like to hope that in the near future all the necessary documents will be finalized and published, and this will give impetus to the beginning of real work on the protection of personal data.

The law is harsh but fair

No less interesting is what opportunities the law provides for the citizens themselves - the subjects of personal data. In addition to the above, let us recall other provisions of the law. According to Part 4 of Article 14 of the Federal Law No. 152, the subject of personal data has the right to receive, when applying or receiving a request, information regarding the processing of his personal data, including containing: confirmation of the fact of processing of personal data by the operator, as well as the purpose of such processing; PD processing methods used by the operator; information about persons who have access to personal data; list of personal data processed and the source of its receipt; terms of processing of PD, including terms of their storage; information about what legal consequences for the subject of personal data the processing of his personal data may entail. In fact, this is also a difficult task for the operator, because no one has repealed Article 137 of the Criminal Code of the Russian Federation “Violation of privacy” dated June 13, 1996. The article, in particular, states that criminal liability is entailed by: illegal collection or dissemination of information about the private life of a person, constituting his personal or family secret, without his consent, or dissemination of this information in a public speech, publicly displayed work or the media, if these acts were committed out of selfish or other personal interest and caused harm to the rights and legitimate interests of citizens.

According to Article 17 of Federal Law-152, if the subject of personal data believes that the operator is processing his personal data in violation of the requirements of this Federal Law or otherwise violates his rights and freedoms, the subject of personal data has the right to appeal the actions or inaction of the operator to the authorized body for the protection of the rights of subjects PD or in court. In this case, persons guilty of violating the requirements bear administrative, civil, criminal and other liability provided for by law.

It seems very significant that developers are responsible for implementing security requirements in information security systems.

Here are the main components of the system of state control and supervision over ensuring the security of personal data during their processing in the information system:

  • Rossvyazohrankultura is the authorized body for the protection of the rights of subjects of personal data;
  • FSB - Federal executive body authorized in the field of ensuring state security and the use of encryption tools;
  • FSTEC - Federal Service for Technical and Export Control and Counteraction to Foreign Intelligence - the authorized body in the field of control of the technical means of protection used;
  • Ministry of Information Technologies and Communications of the Russian Federation - the procedure for classifying information systems containing personal data.

Thus, a well-thought-out system of state control of operators processing personal data is created.

How to properly protect databases?

Measures to protect personal data differ little from the generally accepted approach to protecting information with limited access. So, an integrated approach to database protection consists of successive stages, including:

  • determination of an adequate threat model;
  • risk assessment;
  • development of a protection system based on it using methods provided for the corresponding class of information systems (IS);
  • checking the readiness of information security systems (IPS) with the preparation of the relevant documentation (system description, operating rules, regulations, etc.), including conclusions on the possibility of operating this IPS;
  • installation and commissioning of information protection equipment;
  • accounting of the information security systems used, technical documentation for them, as well as PD media;
  • accounting of persons authorized to work with PD in the IS;
  • development of a complete description of the personal data protection system;
  • control over the use of information security.

At the same time, two components of building an information protection system are traditionally used: conduct an inventory of information resources, identify their owners, categorize information (including limited access, if necessary, introduce a trade secret regime), prepare and sign an order for the implementation of developed organizational protection measures, justify and get a budget, select and prepare personnel, train them, organize retraining, and... that's not all.

All these activities should be described and approved in regulatory and administrative documentation. At the same time, management support is very important for the consistent implementation of the developed security policy. Obviously, the best practice is for each employee to sign a separate agreement for working with restricted information. As a last resort, employees must be instructed, which, in turn, must be confirmed by the signature “read” indicating the full name and position of the employee in all orders and instructions.

Let's move on to consider the technical means of protecting a database containing personal data in more detail.

Main components of a database security system

The classic database protection scheme is divided into the following mandatory procedures:

  • Access control- each user, including the administrator, has access only to the information he needs according to his position.
  • Access protection - access to data can be obtained by a user who has passed the identification and authentication procedure.
  • Data encryption- it is necessary to encrypt both data transmitted over the network to protect against interception, and data written to the media to protect against theft of the media and unauthorized viewing/modification by non-means of the database management system (DBMS).
  • Data access audit- actions with critical data must be logged. The users on whom it is being maintained should not have access to the protocol. In the case of applications using a multi-tier architecture, the above protection functions also apply, with the exception of data protection on the media - this function remains with the database.

DBMS and Oracle applications are equipped to one degree or another with all of the listed security functions, which distinguishes them from competitors' products. Let us consider these procedures in more detail.

Access control

Pursuing the goal of protecting the database from insider threats, to ensure access control in the DBMS version 10g Release 3, Oracle has released a new product Database Vault, designed to prevent unauthorized access to information by users, including those with special powers, for example, database administrators. The set of rules in Database Vault that restrict access is quite wide. For example, an organization's management may define rules that require two employees to be present at the same time to complete tasks that require access to critical information. Thus, Database Vault solves the following problems:

  • restricting access to data by the database administrator and other privileged users;
  • preventing manipulation of the database and access to other application manager applications;
  • providing control over who, when and where can access the application.

Access protection

Authentication in the context of Oracle means verifying the identity of someone or something - a user, an application, a device - who or what needs access to data, resources or applications. After a successful authentication procedure, the authorization process follows, which involves assigning certain rights, roles and privileges to the authentication subject.

Oracle provides a variety of authentication methods and allows you to use one or more of them at the same time. What all of these methods have in common is that the username is used as the authentication subject. Some additional information, such as a password, may be requested to confirm its authenticity. Authentication of Oracle DBMS administrators requires a special procedure, which is determined by the specific job responsibilities and degree of responsibility of this employee. Oracle software also encrypts user passwords for secure transmission over the network.

So, let's take a closer look at authentication methods in the Oracle DBMS.

Authentication using the operating system

A number of operating systems allow the Oracle DBMS to use information about users managed by the OS itself. In this case, the computer user has access to database resources without additionally specifying a name and password - his network credentials are used. This type of authentication is considered insecure and is mainly used to authenticate the DBMS administrator.

Authentication using network services

This type of authentication is provided by the Oracle Advanced Security server option. It provides the following services:

1. SSL - authentication uses the SSL (Secure Socket Layer) protocol - an application layer protocol. It can be used for authentication in the database and in the general case (if user authentication is then used using DBMS) does not depend on the global user management system provided by the Oracle directory service - Oracle Internet Directory.

2. Authentication by third party services.

Based on Kerberos. The use of Kerberos as an authentication system with a trusted third party is based on the use of the so-called. shared secret. This ensures the security and reliability of the trusted party and makes it possible to use Single Sign-On, centralized password storage, transparent authentication through database links, and enhanced security on workstations.

Based on PKI. The use of PKI for authentication involves issuing digital certificates for users (applications), which are used for direct authentication on database servers within one organization. This does not require the use of an additional authentication server. Oracle defines the following components for using PKI:

  • SSL protocol
  • a set of OCI (Oracle Call Interface - application interface for accessing the database) and PL / SQL functions
  • trusted certificates, to verify the authenticity of certificates presented by users (applications)
  • Oracle wallets are key containers containing the user's private key, his certificate and trusted certificate chains
  • Oracle AS Certificate Authority - component of Oracle Application Server, designed for issuing certificates and further managing them
  • - Oracle Wallet Manager (OWM) - a DBMS component for managing wallets

Based on RADIUS. Oracle DBMS supports the RADIUS protocol (Remote Authentication Dial - In User Service) - a standard protocol for authenticating remote users. In this case, third-party authentication services and devices become available with which the RADIUS server can interact (for example, one-time password generation devices, biometric devices, etc.).

Based on LDAP directory service. Using an LDAP directory service makes authentication management and user (application) account management very efficient. In the Oracle DBMS infrastructure, the directory service is represented by the following components:

  • Oracle Internet Directory (OID) allows you to centrally store and manage information about users (so-called enterprise users). Allows you to have a single user account for many databases. Integration with third party directory services is possible, such as MS Active Directory or iPlanet. OID allows you to flexibly manage the security attributes and privileges of each user, including those authenticated with digital certificates. To increase security during the authentication process, it is possible to use the SSL protocol.
  • Oracle Enterprise Security Manager is a utility for managing users, groups, roles and privileges.

3. Authentication in multi-tier applications

The above authentication methods can also be applied in multi-tier applications. As a rule, to access applications from the Internet, authentication using a name and password (including using the RADIUS protocol) or using the SSL protocol is used. Other methods are used for users to work on a local network.

Data encryption

To protect data transmitted over the network in the Oracle DBMS, starting with version 8i, the options are used Oracle Advanced Security, which provides the function Network encryption, which allows you to encrypt the entire data stream. The security of information is ensured by the secrecy of the key with which the data is encrypted.

Network encryption allows you to achieve a high level of security. The following encryption algorithms are supported: AES (10g/11g only). DES, 3 DES, RC 4(10g/11g only).

Protection of data transmitted over the network in Oracle applications is ensured by the SSL protocol using algorithms that are supported by the application server, as a rule, this is the Oracle WEB server.

Data protection on the media is provided by two components of the Oracle DBMS - packages that implement encryption algorithms and an option Transparent Data Encryption (T DE). Starting with version 8i, the Oracle DBMS provides application developers with packages of stored procedures that implement the following algorithms: DES with a key length of 56 bits, Triple DES with key length 112 and 168 bits ,AES with key lengths of 128, 192 and 256 bits RC 4(10g/11g only).

Option TDE appeared in the Oracle DBMS version 10g Release 2 as an integral part Advanced Security. It allows you to selectively encrypt table columns using Triple DES (with a key length of 168 bits), AES (with a key length of 128, 192 or 256 bits) algorithms. Management of encryption keys is taken over by the database kernel, and the use of such encryption does not require reworking the client and server application software. In DBMS version 11g and higher, it became possible to encrypt the entire table space.

Data access audit

DBMS Oracle has powerful tools for auditing user actions, including both data access and registration/logout events and changes to the database structure. Starting from version 9i, the DBMS is equipped with a detailed audit option (Fine Grained Audit Control), which allows you to audit access under conditions determined by fairly flexible customizable rules. However, these audit tools do not allow you to monitor the actions performed by the database administrator, and also do not prevent him from changing the audit log, deleting any lines and leaving no trace of such actions. The emerging need to audit activities and protect audit data from privileged users, including database administrators, prompted Oracle develop a new audit concept. It is based on the idea on which the functionality is based Database Vault: The database administrator is isolated from audit management, which for obvious reasons provides a higher level of database security. As in the case Database Vault rules for assigning audits to Audit Vault very flexible.

Are the built-in protections sufficient?

Our brief overview of the information security tools that Oracle Corporation has built into its products and technologies demonstrates a solid foundation for building information systems with various levels of security that meet the latest security requirements. However, even a superficial glance at the security systems of various software using a DBMS or Oracle application server will show that, with rare exceptions, built-in security tools are either not used at all, or they are replaced by proprietary developments of similar functionality or ready-made developments offered on the market, or built-in tools are supplemented by third-party software.

Essentially, we are dealing with three approaches of domestic companies to the issue of information security in general and to protecting databases from ever-growing threats in particular.

Unfortunately, it is worth recognizing that the first approach is the most common and involves the use of simple password authentication, authorization and data encryption.

The following arguments can most often be heard from supporters of this approach in the development and operation of information systems:

  • the simplest and, therefore, more reliable in terms of operation;
  • low cost of ownership;
  • a higher level of protection is not required.

Of course, password protection does not require additional costs either at the development stage or at the stage of operation of the IS - all the “concerns” for servicing users and their passwords are taken over by the DBMS or application server. There are also no costs for additional hardware (authentication servers, directory services, key information storage devices, etc.) and software (licenses, third-party software, etc.). It is important that the requirements for the qualifications of database administrators and security administrators in this case are much lower, and this is also a matter of economy. The third argument seems to have historically been preserved from those times when security issues were not seriously addressed.

Protection systems built according to the second approach are slightly less common. In part, systems from the first option are transferred to them, when, for example, customers of such a system, tired of the “low” cost of ownership of password protection, order developers or buy a ready-made password management system. It happens that periodic scandals with data theft force us to make software “patches” on a ready-made system to implement encryption, often using our own “super-strong” algorithms.

The arguments for this approach are approximately the following: built-in security measures are clearly insufficient and are replete with vulnerabilities;

  • It’s better to deal with a “local” development team than to rely on vendor support;
  • the system works normally with password protection and it is better not to touch it; it is enough to implement additional password management software.

The two options for using security measures discussed above are typical for information systems developed and implemented mainly in the late 90s of the last century. A typical example is billing systems, which are independently developed by dozens of companies. No less striking examples are the databases of healthcare and law enforcement agencies. But they contain impressive amounts of confidential information and, in particular, personal data, which Russian legislation obliges to reliably protect. Is such a negligent attitude towards protecting the database with personal data of citizens the reason for the constant appearance of collections of databases on individuals and legal entities among pirated copies of films? The answer to this question should be sought, first of all, based on the shortcomings of the described approaches. Let us make an attempt to analyze the supporters of these approaches.

Is password authentication enough?

Indeed, the ease of use of password protection is beyond doubt. But simplicity and reliability of protection in this case are incompatible. In terms of safety and ease of use, this technology is becoming obsolete. The strength of a password and, therefore, the safety of its use directly depends on its quality (the characters used, their case, difference from meaningful words). And ease of use rapidly decreases even with a slight increase in the “security” of the password, because remembering an unreadable combination of characters is quite difficult. Let's look at the numbers and facts. User passwords are stored in the Oracle DBMS as hash values ​​and are readable by privileged users. The algorithm for calculating a password hash has long been known. The most comprehensive study of password strength in Oracle was conducted by Red - Database - Security GmbH - the world's leading expert in the field of security of Oracle products. Here is some data on password strength for DBMS versions 7-10g:

On a computer with a Pentium 4 3 GHz, the required time is (brute force attack):

  • 10 seconds all 5 character combinations
  • 5 minutes all 6 character combinations
  • 2 hours all 7-character combinations
  • 2.1 days all 8 character combinations
  • 57 days all 9 character combinations
  • 4 years all 10-character combinations

And this is when using far from the most powerful computer. As performance increases, a dictionary attack is carried out even faster. This is not to say that Oracle does not react to this state of affairs - in version DBMS 11g the situation has improved significantly. The hash generation algorithm and the quality of password generation have been strengthened. As a result, the above figures increased by 2.5-3 times. But, despite such improvements, Oracle recommends the use of enhanced authentication tools, which have also been improved for the better, for example, it has become possible to use HSM (Hardware Security Module) for authentication and storage of encryption keys.

Thus, we conclude: the reliability and security of using passwords to protect IP currently no longer meets the requirements of companies that, on the one hand, care about their reputation, and on the other, are obliged to comply with the requirements of current legislation.

Low cost of ownership - a myth?

Widespread misconception. Statistics confirm the facts of significant costs for servicing, say, forgotten passwords. Companies suffer even more significant losses due to low reliability and security of password protection.

Are built-in security vulnerabilities?

And in this matter, we are again faced with the common opinion that standard security measures are insufficient. How can we explain the emergence of such an opinion, especially taking into account the fact that built-in security measures are most often not used at 100%. T

As for the vulnerabilities of built-in security measures in Oracle, the situation here is exactly the same as in other complex systems. Oracle Corporation has traditionally taken a responsible approach to identifying and eliminating vulnerabilities found. CPU updates (Critical Patch Update) are released regularly (4 times a year), eliminating flaws discovered both by Oracle itself and by dozens of other companies, the most famous of which is the already mentioned Red - Database - Security GmbH. For example, in the CPU in October 2007, 27 vulnerabilities were eliminated in the DBMS, 11 in the application server, 13 in various applications. Considering the number of Oracle products, their versions and software and hardware platforms for them, this is not so much.

Own development vs vendor support

There are many opinions on this issue. Some organizations prefer to have their own development departments, some do not. Perhaps the most compelling argument in favor of vendor support is that not every company can afford to have information security specialists in its development department.

However, even if such resources exist, it is worth keeping in mind that a “home-written” system largely depends on the team of developers who took part in its design and creation. This means their level of professionalism, their qualifications are decisive in terms of the quality of development, the absence of bookmarks built into the software, and vulnerabilities that can be exploited by external attackers. In addition, “home-written” solutions are fraught with the fact that the departure of one or more key “authors” of these solutions may entail risks associated with the correct support and development of the previously created infrastructure by new specialists.

So, let's sum up the intermediate results. The main arguments put forward by the apologists of the approaches we have listed - built-in security measures are not used and “home-made” means are more reliable than standard ones - actually have no serious basis. And companies that pursue these options to protect their databases are actually exposing the confidential information contained in the database to the risk of theft and leakage.

Possibilities for enhancing security functions: when is it necessary?

The example we gave above about protecting the databases of various social institutions is actually very indicative. After all, we are talking about a state enterprise, which is directly related to compliance, on the one hand, with the interests of the state, and on the other, with the interests of citizens. Accordingly, the issue of protecting stored and processed data circulating in the information infrastructure of this institution becomes priority number one. And in this case, the maximum use of the capabilities of standard protection tools in solutions from reliable suppliers may still be insufficient. The requirement to strengthen protection for state-owned enterprises is connected, on the one hand, with the introduction of technologies of a higher level of security, and on the other, with the fulfillment of legal requirements, in particular, on the use of exclusively certified means of protection.

That is why the third “mixed” approach to protecting information systems has recently begun to gain momentum. If we analyze the typical requirements for IP protection and the capabilities that can be implemented using built-in Oracle tools, we can immediately identify what needs to be supplemented:

Russian cryptography algorithms (PKI, digital signature, encryption on the network and on media)

Implementation of encryption when writing to media without using TDE

Storage of key material.

For obvious reasons, the Oracle developers did not provide a universal implementation of these two points, although they did provide some general approaches.

Application of domestic cryptographic algorithms

Cryptographic algorithms can be used in the process of authentication, digital signature generation (GOST R 34.10-2001), to protect the communication channel (GOST 28147-89, GOST R 34.11-94) and data encryption (GOST 28147-89). Oracle's built-in tools do not implement these algorithms either in the DBMS, or in the application server, or in applications. The implementation of cryptography in the form of libraries, standard cryptography providers (CSP), development kits (SDK) is offered by several Russian manufacturers - CryptoPro, Signal-Com, Infotex, Lissy, CryptoCom, CryptoEx, etc. However, getting Oracle products to work with the proposed libraries is quite problematic . The point is not that these tools are not compatible at the software and hardware level - embedding cryptography into Oracle products should not violate the vendor's license agreement regarding software integrity. If, as a rule, problems with embedding do not arise with IS built on the basis of the Oracle application server or the entire set of Oracle applications, then with a DBMS the situation is more complicated. Due to the fact that the DBMS kernel does not have a software interface for cryptographic operations (authentication, encryption), workarounds have to be used. For example, use the Kerberos authentication protocol or one-time password generators with the RADIUS protocol, and protect the communication channel using certified software.

Encrypt data without using TDE

Despite the extreme simplicity of the Oracle TDE option, it is often necessary to abandon its use. There are two main reasons:

Some data types are not supported

There is no possibility to routinely apply Russian cryptoalgorithms

There is no real protection against privileged users.

The first problem can be solved in principle using third-party products - DbEncrypt for Oracle (Application Security, Inc.), eToken SafeData (Aladdin Software Security R.D.), The Encryption Wizard for Oracle (Relational Database Consultants, Inc.). The second problem is fundamentally solved in the same way, but here there are fewer options - eToken SafeData or The Encryption Wizard for Oracle. Moreover, for the first product an additional version assembly is required (depending on the certified cryptography manufacturer used), but for the second product, it was simply not possible to find the necessary information. The third problem could, in principle, be solved by sharing options TDE And Oracle Database Vault but in this case, the powers of the DBMS administrator smoothly flow to the Database Va u lt administrator, i.e. the problem of protection from privileged users remains.

Key material storage

Key material (certificates, private keys, encryption keys) used by Oracle's built-in security tools to authenticate or encrypt data is stored in key containers (called wallets) like regular files. A password is required to access information in your wallet. Often this storage method does not meet security requirements, especially on customer workstations. Oracle DBMS, starting with version 10g, allows you to store private keys on hardware devices that support the PKCS#11 standard. At the same time, Oracle does not in any way guarantee the operation of hardware devices other than production devices nCipher (nCipher Corporation Ltd.). This is not always acceptable, for example, if only certified hardware is intended to be used. And in this case, the problem of storing keys and certificates can be solved using third-party solutions. On the Russian market, perhaps the only product in its class is eToken SecurLogon for Oracle (Aladdin Software Security R.D.).

Conclusion

Despite the conscious understanding of the problem raised by both legislators and government and commercial organizations, personal data is still susceptible to information leaks, the damage from which is sometimes estimated at very impressive figures. The lack of high-profile precedents can be explained by the latency of crimes in this area. However, leaks occur constantly and sooner or later a full-scale fight against database theft will be launched at the state level. Of course, you can use uncertified solutions, you can use unlicensed software and reinvent the wheel yourself, ignoring proven industrial solutions... But only in this case, organizations should be aware of all the additional risks - from financial to reputational - associated with the use of such products , they also take full responsibility. There are threats and there are consequences. By adopting one or another approach to ensuring the security of information resources, organizations either take risks or create the safest conditions for themselves.

Currently, security requirements from consumers are quite high, and the optimal solution is to make full use of built-in security tools and wisely supplement them with products and solutions from third-party developers. However, often the desire to build reliable IP protection comes up against a banal lack of qualified personnel - developers, analysts, technical support engineers, consultants. The consequence of this is poor knowledge of the capabilities of built-in security features of Oracle and other systems and their correct use. Another consequence is the same situation, but in relation to the products of other manufacturers of information security software and hardware and their use in conjunction with Oracle technologies and products. As a result, existing systems continue to use outdated password protection systems, acquiring unnecessary modifications and heaps of additional regulations, and, even worse, new information systems with old protection technologies are being developed. The way out of this situation, first of all, is in training personnel who have expert knowledge in information security itself, in the Oracle product line and who are able to integrate the developments of Russian companies with built-in security measures. Such training should begin in specialized universities, and specialists in this field should have the opportunity to build up experience and skills in training centers. I would like to see support in this matter both from Oracle and from other manufacturers operating in the Russian information security market.

In this regard, a very encouraging trend, in our opinion, is the emergence of real solutions, methods and approaches to organizing information security systems, developed by domestic companies together with Russian representative offices of Western corporations. Such cooperation makes it possible to ensure not only the stable performance of the protection mechanisms as part of the information system, but also the compliance of these solutions with the requirements of Russian legislation.