VPN<\/a> or without it.<\/p>\nNetwork encryption in a distributed Ethernet network<\/i><\/p>\n
The devices themselves can be either specialized<\/b> (designed exclusively for encryption) or multifunctional (hybrid, convergent<\/b>), meaning they also perform other functions (for example, a firewall or a router). Different vendors classify their devices into different classes\/categories, but that is not important \u2013 what matters is whether they can encrypt inter-site traffic and what characteristics they possess in doing so.<\/p>\n
Just a reminder that terms like \"network encryption\", \"traffic encryption\", and \"encrypter\" are informal, although they are often used. You will most likely not encounter them in Russian regulatory legal acts (including those introducing GOST standards).<\/p>\n
Encryption Levels and Transmission Modes<\/h4>\n \nBefore delving into the characteristics used for assessment, we first need to clarify one important thing: the \"encryption level\". I noticed that it is often mentioned in both official vendor documents (descriptions, manuals, etc.) and informal discussions (in negotiations, training sessions). It seems that everyone is generally aware of what is being referred to, yet I have personally witnessed some confusion.<\/p>\n
So, what exactly is the \"encryption level\"? Clearly, it refers to the layer number of the OSI\/ISO reference model at which encryption occurs. Reading GOST R ISO 7498-2\u201399 \"Information Technology. Open System Interconnection. Basic Reference Model. Part 2. Information Protection Architecture\" provides insight into this. From this document, one can understand that the confidentiality service level (one of the mechanisms by which encryption is ensured) is the protocol level at which the service data block (\"payload\", user data) is encrypted. As stated in the standard, the service can be provided either at this same level, \"in-house\", or utilizing the lower level (this is how it is most often implemented in MACsec, for instance).<\/p>\n
In practice, there are two modes for transmitting encrypted information over a network (IPsec comes to mind, but these modes are also found in other protocols). In transport<\/b> mode (sometimes also referred to as native), only the service<\/b> data block is encrypted while the headers remain \"open\", unencrypted (sometimes additional fields with service information from the encryption algorithm are added, and other fields are modified or recalculated). In tunneling<\/b> mode, the entire protocol<\/b> data block (that is, the packet itself) is encrypted and encapsulated in the service data block of the same or a higher layer, meaning it is framed with new headers.<\/p>\n
The encryption level itself, combined with some transmission mode, is neither good nor bad; thus, it cannot be said that L3 in transport mode is better than L2 in tunnel mode, for example. Many characteristics that are used to evaluate devices depend on them, such as flexibility and compatibility. For operation in L1 (bitstream retransmission), L2 (frame switching), and L3 (packet routing) in transport mode, solutions that encrypt at the same or higher level are required (otherwise, address information will be encrypted, and the data will not reach its destination), while tunnel mode allows overcoming this limitation (albeit at the cost of other important characteristics).<\/p>\n
L2 encryption modes: Transport and Tunnel<\/i><\/p>\n
Now, let's discuss the characteristics.<\/p>\n
Performance<\/h4>\n \nFor network encryption, performance is a complex, multidimensional concept. It can happen that a particular model excels in one performance characteristic but falls short in another. Therefore, it is always beneficial to consider all the components of encryption performance and their impact on network performance and the applications using it. An analogy can be drawn with a car, where not only maximum speed matters but also acceleration time to 100, fuel consumption, and so on. Performance characteristics are highly valued by vendor companies and their potential clients. Typically, performance dictates the ranking among vendors in the encryption device market.<\/p>\n
It is clear that performance depends both on the complexity of the network and cryptographic operations performed on the device (including how well these tasks can be parallelized and pipelined), as well as on the hardware performance and the quality of the embedded software. Therefore, more powerful hardware is used in higher-end models, and there may sometimes be an option to enhance it with additional processors and memory modules. There are several approaches to implementing cryptographic functions: on a universal central processing unit (CPU), specialized custom integrated circuits (ASIC), or on field-programmable gate arrays (FPGA). Each approach has its own pros and cons. For example, the CPU can become a bottleneck for encryption, especially if the processor lacks specialized instructions to support the encryption algorithm (or if they are not utilized). Specialized chips lack flexibility; it is not always possible to reprogram them to improve performance, add new features, or fix vulnerabilities. Additionally, their use becomes cost-effective only at high production volumes. This is why the 'golden mean' has become so popular \u2013 the use of FPGAs. It is precisely on FPGAs that so-called crypto accelerators are made \u2013 embedded or plug-in specialized hardware modules for supporting cryptographic operations.<\/p>\n
Since we are specifically talking about network<\/b> encryption, it is logical that we need to measure the performance of solutions in the same metrics as for other networking devices \u2013 bandwidth, frame loss percentage, and latency. These metrics are defined in RFC 1242. By the way, nothing is mentioned about the often-cited variation of latency (jitter) in this RFC. How should these metrics be measured? I have not found an approved methodology in any standards (official or unofficial like RFC) specifically for network encryption. It would be logical to use the methodology for networking devices established in RFC 2544. Many vendors follow it \u2013 many, but not all. For instance, some only send test traffic in one direction instead of both, as are recommended<\/b> the standard specifies. But oh well.<\/p>\n
Measuring the performance of network encryption devices has its peculiarities. Firstly, it's essential to conduct all measurements for a pair of devices: while encryption algorithms and symmetric functions may be equal, the delays and packet losses during encryption and decryption may not necessarily match. Secondly, it makes sense to measure the delta, the impact of network encryption on overall network performance, comparing two configurations: without encryption devices and with them. Alternatively, in the case of hybrid devices that combine several functions in addition to network encryption, we compare the scenarios with encryption turned off and on. This impact can vary and depend on the connection scheme of the encryption devices, their operational modes, and the nature of the traffic. In particular, many performance parameters depend on packet length, which is why graphs illustrating the dependency of these parameters on packet length are often utilized to compare different solutions, or IMIX is used\u2014traffic distribution by packet length that roughly reflects reality. By comparing the same baseline configuration without encryption, we can benchmark solutions for network encryption implemented differently without delving into those differences: L2 with L3, store-and-forward with cut-through, specialized with converged solutions, GOST with AES, and so on.<\/p>\n
Connection Scheme for Performance Testing<\/i><\/p>\n
The first characteristic to focus on is the 'speed' of the encryption device, that is, the bandwidth<\/b> (bandwidth) of its network interfaces, the bit flow rate. It is determined by the network standards supported by the interfaces. For Ethernet, common figures are 1 Gbit\/s and 10 Gbit\/s. However, as we know, in any network, the maximum theoretical throughput<\/b> (throughput) at each of its levels is always less than the bandwidth: part of the bandwidth is 'eaten up' by inter-frame gaps, service headers, and so on. If a device can receive, process (in our case, encrypt or decrypt), and transmit traffic at the full speed of the network interface, that is, with the maximum theoretical throughput for that layer of the network model, it is said to be operating at line speed<\/b>. For this, it is necessary that the device does not lose or drop packets regardless of their size and the frequency of their arrival. If the encryption device does not support operation at line speed, its maximum throughput is usually indicated in gigabits per second (sometimes specifying packet length \u2013 the shorter the packets, the usually lower the throughput). It is very important to understand that maximum throughput is the maximum lossless<\/b> (even if the device can 'push' traffic at a higher speed, but loses some packets in the process). Furthermore, it is necessary to note that some vendors measure the total throughput across all pairs of ports, so these figures are not very insightful if all the encrypted traffic goes through a single port.<\/p>\n
Where is line speed operation especially important (or, in other words, lossless)? In channels with high throughput and large delays (for example, satellite), where maintaining high transmission speeds requires setting a large TCP window size, and where packet loss sharply reduces network performance.<\/p>\n
However, not all of the bandwidth is used for transmitting useful data. One must account for the so-called overheads<\/b> (overhead) bandwidth. This is the part of the encryption device's bandwidth (in percentage or bytes per packet) that is effectively lost (cannot be used for application data transmission). Overheads occur firstly due to increased size (padding) of the data field in encrypted network packets (depending on the encryption algorithm and its mode of operation). Secondly, due to increased header lengths of packets (tunnel mode, protocol insertion of encryption services, integrity insertion, etc., depending on the protocol and the operation modes of the cipher and transmission mode) \u2013 these overheads are usually the most significant, and they are the ones that are noticed first. Thirdly, due to packet fragmentation when the maximum data block size (MTU) is exceeded (if the network can split a packet exceeding MTU into two, duplicating its headers). Fourthly, due to the appearance of additional control traffic in the network between encryption devices (for key exchange, tunnel establishment, etc.). Low overheads are crucial where the channel's bandwidth is limited. This is particularly evident in traffic from small packets, such as voice \u2013 where overheads can consume more than half of the channel speed!<\/p>\n
Throughput<\/i><\/p>\n
Finally, there is also introduced latency<\/b> The difference (in fractions of a second) in network latency (the time it takes for data to travel from entry to exit in the network) between data transmission without network encryption and with it. Generally speaking, the lower the latency of the network, the more critical the delay introduced by the encryption devices becomes. The delay is introduced by the encryption operation itself (which depends on the encryption algorithm, block length, and cipher mode, as well as the quality of its implementation in the software), as well as the processing of the network packet in the device. The introduced delay depends on both the packet processing mode (inline or \"store-and-forward\") and the platform performance (hardware implementations on FPGA or ASIC are typically faster than software implementations on CPU). L2 encryption almost always incurs less delay compared to L3 or L4 encryption: this is affected by the fact that devices encrypting at L3\/L4 are often implemented using converged solutions. For example, high-speed Ethernet encryptors implemented on FPGA and operating at L2 have an almost negligible delay due to the encryption operation\u2014sometimes, when encryption is enabled between a pair of devices, the total delay they introduce even decreases! Low latency is crucial where it is comparable to the total delays in the channel, including signal propagation delay, which is approximately 5 microseconds per kilometer. Thus, it can be said that for city-scale networks (tens of kilometers in diameter), microseconds can make a significant difference. For example, this applies to synchronous database replication, high-frequency trading, and blockchain.<\/p>\n
Introduced latency<\/i><\/p>\nScalability<\/h4>\n
\nLarge distributed networks can encompass thousands of nodes and network devices, along with hundreds of segments of local networks. It is crucial that encryption solutions do not impose additional restrictions on the size and topology of the distributed network. This primarily concerns the maximum number of node and network addresses. Such limitations can be encountered, for example, when implementing a multipoint topology for an encrypted network (with independent secure connections or tunnels) or selective encryption (such as by protocol number or VLAN). If network addresses (MAC, IP, VLAN ID) are used as keys in a table where the number of rows is limited, these restrictions become evident.<\/p>\n
Furthermore, large networks often have multiple structural levels, including a backbone network, each with its own addressing scheme and routing policy. To implement such an approach, special frame formats (like Q-in-Q or MAC-in-MAC) and routing determination protocols are often employed. To facilitate the construction of such networks, encryption devices must handle these frames correctly (meaning in this context that scalability will imply compatibility, as discussed below).<\/p>\n
doesn\u2019t stop at one thing, like Yandex.Metrica, but evolves and is used in an increasing number of different projects and industries. It can be expanded by adding new features to address new tasks. For instance, it is often believed that storing logs in a DB is outdated, which is why<\/h4>\n \nThis refers to the support of various configurations, connection schemes, topologies, and more. For example, in switched networks based on Carrier Ethernet technologies, this entails supporting different types of virtual connections (E-Line, E-LAN, E-Tree), various types of services (both by ports and by VLAN), and different transport technologies (already mentioned above). This means that the device must be able to operate in both linear (\u2018point-to-point\u2019) and multipoint modes, establish separate tunnels for different VLANs, and allow unordered delivery of packets within a secure channel. The ability to choose different encryption operation modes (including with or without content authentication) and various packet transmission modes allows for a balance between resilience and performance depending on current conditions.<\/p>\n
The support for private networks is also important, where the equipment belongs to one organization (or is leased by it), as well as for operator networks, where different segments are managed by different companies. It is beneficial if the solution allows management by both in-house teams and third parties (under a managed service model). In operator networks, another crucial function is the support for multi-tenancy (joint usage by different customers) through cryptographic isolation of individual clients (subscribers), whose traffic passes through the same set of encryption devices. Typically, this requires the use of separate sets of keys and certificates for each customer.<\/p>\n
If a device is being acquired for a specific scenario, then all these capabilities may not be very important \u2014 the main thing is to ensure the device supports what is needed at the moment. However, if the solution is being purchased for future growth and is chosen as a \"corporate standard\", flexibility becomes essential \u2014 especially considering the interoperability limitations among devices from different vendors (more on that below).<\/p>\n
Simplicity and convenience<\/h4>\n \nEase of maintenance is also a multifaceted concept. It can be generally stated that it encompasses the total time costs of specialists with a certain qualification required to support the solution at various stages of its lifecycle. If there are no costs, and installation, configuration, and operation are fully automated, then the costs are zero, and the convenience is absolute. Of course, this rarely happens in the real world. A reasonable approximation is the model \"node on a line\"<\/b> (bump-in-the-wire), or a transparent connection where the addition and removal of encryption devices does not require any manual or automatic changes to the network configuration. This simplifies the maintenance of the solution: you can easily enable or disable the encryption feature, and if necessary, simply 'bypass' the device with a network cable (that is, connect directly to the ports of the network equipment to which it was connected). However, there is one downside \u2013 malicious actors can do the same. To implement the concept of 'node on the wire', one must consider traffic not only the data layer<\/b>, but also control and management layers<\/b> \u2013 devices must be transparent to them. Therefore, such traffic can only be encrypted when there are no traffic receivers of these types in the network between the encryption devices, as discarding or encrypting it can change the network configuration during the enabling or disabling of encryption. The encryption device can be transparent even for signaling at the physical level. In particular, in case of signal loss, it must convey this loss (that is, disable its transmitters) back and forth ('for itself') in the direction of the signal.<\/p>\n
The support in the division of authority between the Information Security and IT departments, particularly the networking department, is also important. The encryption solution should support the access and auditing management model adopted in the organization. The necessity for interaction between different departments to perform routine operations must be minimized. Therefore, specialized devices that support only encryption functions and are maximally transparent to network operations have the advantage in terms of convenience. In simple terms, employees of the Information Security department should have no reason to turn to the 'network guys' for network configuration changes. Conversely, there should be no need for them to change encryption settings during network maintenance.<\/p>\n
Another factor is the capabilities and convenience of management tools. They should be intuitive and logical, allowing for the import-export of settings, automation, and so on. It's important to immediately pay attention to the available management options (usually these are a proprietary management environment, web interface, and command line) and to the set of features provided in each of them (limitations are common). An important feature is support for out-of-band<\/b> (out-of-band) management, meaning via a dedicated management network, and in-band<\/b> (in-band) management, which means through the shared network that carries useful traffic. Management tools should signal all abnormal situations, including information security incidents. Routine, repetitive operations should be performed automatically. This is especially true for key management, which should be generated\/distributed automatically. Support for PKI is a significant advantage.<\/p>\nCompatibility<\/h4>\n
\nThis refers to the device's compatibility with network standards. It implies not only industrial standards accepted by authoritative organizations like IEEE, but also proprietary protocols from industry leaders, such as Cisco. There are two fundamental ways to ensure compatibility: either through transparency<\/b>, or through explicit support<\/b> of protocols (when the encryption device becomes one of the nodes in the network for a certain protocol and processes the control traffic of that protocol). The completeness and correctness of protocol implementations affect compatibility with networks. It's important to support various PHY layer options (speeds, transmission media, encoding schemes), Ethernet frames of different formats with any MTU, and various L3 control protocols (primarily from the TCP\/IP family).<\/p>\n
Transparency is ensured through mutation mechanisms (temporary alteration of the contents of open headers in traffic between encryptors), passthrough (when individual packets remain unencrypted), and encryption start offsets (when fields in packets that are generally encrypted are left unencrypted).<\/p>\n
How is transparency ensured?<\/i><\/p>\n
Therefore, always clarify how support for a given protocol is ensured. Often, support in transparent mode is more convenient and reliable.<\/p>\n
Interoperability<\/h4>\n \nThis is also compatibility, but in a different sense, namely the ability to work together with other encryption device models, including those from different manufacturers. Much depends here on the state of standardization of encryption protocols. There are simply no universally recognized encryption standards at L1.<\/p>\n
For L2 encryption in Ethernet networks, there is the 802.1ae (MACsec) standard, but it does not use end-to-end<\/b> (end-to-end), but rather inter-port<\/b>, hop-by-hop encryption, and in its original version is unsuitable for use in distributed networks, which is why proprietary extensions have emerged to overcome this limitation (of course, at the cost of interoperability with equipment from other manufacturers). However, in 2018, support for distributed networks was added to the 802.1ae standard, but there is still no support for the GOST encryption algorithm sets. Therefore, proprietary, non-standard L2 encryption protocols generally offer greater efficiency (in particular, lower bandwidth overhead) and flexibility (the ability to change encryption algorithms and modes).<\/p>\n
At higher levels (L3 and L4), there are recognized standards, primarily IPsec and TLS, but it is not so straightforward here either. The thing is, each of these standards is a set of protocols, each with different versions and mandatory or optional extensions. Moreover, some manufacturers prefer to use their proprietary encryption protocols at L3\/L4. Therefore, in most cases, full interoperability should not be expected, but it is important to ensure at least some interaction between different models and different generations of the same manufacturer.<\/p>\n
Reliability<\/h4>\n \nTo compare different solutions, one can use either the mean time to failure or the availability rate. If these figures are not available (or not trusted), a qualitative comparison can be performed. The advantage will be on devices with user-friendly management (lower risk of configuration errors), specialized encryptors (for the same reason), as well as solutions with minimal downtime detection and recovery times, including means of 'hot' backup of nodes and devices as a whole.<\/p>\n
Cost<\/h4>\n \nWhen it comes to cost, as with most IT solutions, it is advisable to compare the total cost of ownership. To calculate it, you don't need to reinvent the wheel; you can use any suitable methodology (for example, from Gartner) and any calculator (like the one already used in the organization for TCO calculation). Clearly, for a network encryption solution, the total cost of ownership consists of direct<\/b> expenses for purchasing or leasing the solution itself, for the infrastructure to host the equipment, and for deployment, administration, and maintenance costs (regardless of whether done in-house or as services from a third party), as well as indirect<\/b> expenses due to the downtime of the solution (caused by the loss of productivity of end users). There is probably only one nuance. The impact of the solution's performance can be accounted for in different ways: either as indirect costs caused by productivity decline, or as 'virtual' direct expenses for the purchase\/upgrade and maintenance of network tools that offset the drop in network performance due to encryption. In any case, costs that are difficult to calculate with sufficient accuracy are better 'set aside' in the calculation: this will lead to more trust in the final value. And, as usual, regardless of the situation, comparing different devices based on TCO makes sense only for a specific usage scenario \u2013 whether real or typical.<\/p>\nResilience<\/h4>\n
\nThe final characteristic is the resilience of the solution. In most cases, resilience can only be assessed qualitatively by comparing different solutions. We must remember that encryption devices are not just tools, but also items of protection. They can be exposed to various threats. Primary among these threats are breaches of confidentiality, reproduction, and modification of messages. These threats can be realized through vulnerabilities in the cipher or its individual modes, as well as through vulnerabilities in encryption protocols (including during the connection establishment and key generation\/distribution stages). Solutions that allow for the change of encryption algorithms or switching cipher modes (at least through firmware updates) will have an advantage, as well as solutions that provide comprehensive encryption, hiding not only user data from attackers but also address and other service information, and those that not only encrypt but also protect messages from reproduction and modification. For all modern encryption algorithms, electronic signatures, key generation, and others that are established in standards, resilience can be considered uniform (otherwise, one can easily get lost in the complexities of cryptography). Do these have to be GOST algorithms? It\u2019s simple: if the application scenario requires FSB certification for encryption devices (which is often the case in Russia), then we only choose between certified solutions. If not, there\u2019s no need to exclude devices without certificates from consideration.<\/p>\n
Another threat is the risk of hacking, unauthorized access to devices (including through physical access from outside and inside the case). The threat can materialize through
Finally, another type of threat is the errors in configuration and operation, the human factor in its pure form. Here, the advantage of specialized encryptors over convergent solutions becomes apparent, as the latter are often tailored to seasoned 'networkers' and may pose difficulties for 'ordinary', broad-spectrum IT specialists.<\/p>\n
In summary<\/h4>\n \nIn principle, one could propose some integral indicator for comparing different devices, something like<\/p>\n
$$display$$K_j=\u2211p_i r_{ij}$$display$$<\/p>\n
\nwhere p is the weight of the indicator, and r is the rank of the device according to this indicator, whereby any of the characteristics listed above can be broken down into 'atomic' indicators. Such a formula could be useful, for example, in comparing tender proposals based on pre-agreed rules. But one could also manage with a simple table like<\/p>\n
Specification
Throughput
+++<\/p>\n
Overheads
+++<\/p>\n
Latency
++<\/p>\n
Scalability
+++<\/p>\n
doesn\u2019t stop at one thing, like Yandex.Metrica, but evolves and is used in an increasing number of different projects and industries. It can be expanded by adding new features to address new tasks. For instance, it is often believed that storing logs in a DB is outdated, which is why
+<\/p>\n
Interoperability
+<\/p>\n
Compatibility
+++<\/p>\n
Simplicity and convenience
++<\/p>\n
Fault tolerance
++<\/p>\n
Cost
+<\/p>\n
Resilience
+++<\/p>\n
\nI would be happy to answer questions and constructive critical comments.habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u042d\u0442\u043e\u0442 \u043e\u0431\u0437\u043e\u0440 (\u0438\u043b\u0438, \u0435\u0441\u043b\u0438 \u0445\u043e\u0442\u0438\u0442\u0435, \u0440\u0443\u043a\u043e\u0432\u043e\u0434\u0441\u0442\u0432\u043e \u0434\u043b\u044f \u0441\u0440\u0430\u0432\u043d\u0435\u043d\u0438\u044f) \u044f \u043d\u0430\u043f\u0438\u0441\u0430\u043b, \u043a\u043e\u0433\u0434\u0430 \u043c\u043d\u0435 \u043f\u043e\u0440\u0443\u0447\u0438\u043b\u0438 \u0441\u0440\u0430\u0432\u043d\u0438\u0442\u044c \u043c\u0435\u0436\u0434\u0443 \u0441\u043e\u0431\u043e\u0439 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0443\u0441\u0442\u0440\u043e\u0439\u0441\u0442\u0432 \u0440\u0430\u0437\u043d\u044b\u0445 \u0432\u0435\u043d\u0434\u043e\u0440\u043e\u0432. \u041a \u0442\u043e\u043c\u0443 \u0436\u0435 \u044d\u0442\u0438 \u0443\u0441\u0442\u0440\u043e\u0439\u0441\u0442\u0432\u0430 \u043f\u0440\u0438\u043d\u0430\u0434\u043b\u0435\u0436\u0430\u043b\u0438 \u043a \u0440\u0430\u0437\u043d\u044b\u043c \u043a\u043b\u0430\u0441\u0441\u0430\u043c. \u041f\u0440\u0438\u0448\u043b\u043e\u0441\u044c \u0440\u0430\u0437\u0431\u0438\u0440\u0430\u0442\u044c\u0441\u044f \u0432 \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u0435 \u0438 \u0445\u0430\u0440\u0430\u043a\u0442\u0435\u0440\u0438\u0441\u0442\u0438\u043a\u0430\u0445 \u0432\u0441\u0435\u0445 \u044d\u0442\u0438\u0445 \u0443\u0441\u0442\u0440\u043e\u0439\u0441\u0442\u0432 \u0438 \u0441\u043e\u0441\u0442\u0430\u0432\u043b\u044f\u0442\u044c \u00ab\u0441\u0438\u0441\u0442\u0435\u043c\u0443 \u043a\u043e\u043e\u0440\u0434\u0438\u043d\u0430\u0442\u00bb \u0434\u043b\u044f \u0441\u0440\u0430\u0432\u043d\u0435\u043d\u0438\u044f. \u042f \u0431\u0443\u0434\u0443 \u0440\u0430\u0434, \u0435\u0441\u043b\u0438 \u043c\u043e\u0439 \u043e\u0431\u0437\u043e\u0440 \u043f\u043e\u043c\u043e\u0436\u0435\u0442 \u043a\u043e\u043c\u0443-\u0442\u043e: \u0420\u0430\u0437\u043e\u0431\u0440\u0430\u0442\u044c\u0441\u044f \u0432 \u043e\u043f\u0438\u0441\u0430\u043d\u0438\u044f\u0445 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-52834","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t