📜 ⬆️ ⬇️

How to create in a large company a convenient workplace for distributed teams?

Recently, many large companies have been trying to implement DevOps practices in order to speed up the process of delivering value to the customer. The people working on the product gather in one team, work in a single information field. What can a big company do if the employees of its teams cannot gather in one room and are scattered in different offices, perhaps even in different cities and time zones?

This begs the answer - register with Internet services for joint development (GitHub, Slack, Evernote, Wunderlist ...). But what to do if your large company works, for example, with client data or financial information, and cannot entrust it to Internet services? The only way out is to deploy a distributed development infrastructure inside the network.

But how to do this to ensure the security of data and processes, while not losing in speed and convenience of work? I will try to answer this question in this article.
')


Just want to make a reservation that the article will not focus on network technologies or information security - for this there is a lot of professional literature. But rather, it will focus on the principles of application of these technologies for maximum user experience with an acceptable level of security threats.

Typical infrastructure of a large company


At the beginning I will describe how the network infrastructure of typical large companies usually looks.
They have a head office in which there is a management, key employees and a data center with valuable information. All workplaces are connected to the corporate network of the head office, and the data center server is also connected to it. Subnets of branches in other cities are connected from the head office network via a physical / mostly virtual channel.

More from the corporate network access to the Internet is most often limited or completely disabled. For security reasons and “care” about employee time. The restriction can work through a filtering proxy server, or through a remote desktop of a certain secure server, in which a browser with Internet access is opened.



So, in a typical large company, if the employee left the office / got sick / went on vacation, he usually does not have the ability to connect to the corporate network. And, taking into account the restriction of Internet access, he also loses the ability to effectively use Internet services. From the means of communication is only a mobile phone.

What to do in this case?

Network Infrastructure Transformation


Below are a few practical steps on how to improve the infrastructure in order to enable more effective communication and distributed work of employees.

Employee mobilization


Now smartphones, tablets, laptops are tightly in our life. Therefore, the best option to start the transformation is to organize an additional workplace for the employee on a mobile device. It is necessary to determine which internal services can still be given access from the Internet, assess the risks of their potential hacking or unavailability. For example, here are potential candidates:


It is clear that such a mobile place will never replace the fixed in the office. But this is at least something in the direction of distributed work.



Although it seems to be taken for granted, there should be a Wi-Fi network in the office for employees. Moreover, not necessarily with access to the corporate network, but definitely with full access to the Internet. The presence of Wi-Fi in the office will allow mobile devices to work, and also may well solve the problem of inconvenient Internet access from fixed workplaces. And to use Internet services for distributed work will become more realistic.
But what if the employee still wants something more on his mobile device than the meeting calendar?

External access to the corporate network


I want to go back to the last point from the point of view of information security.
If a company opens on the Internet any service from its corporate network, it immediately becomes vulnerable to the following attacks:


To reduce the number of potential attackers, a good solution is to put the service on the Internet through a secure channel with an additional degree of protection.

Two-factor authentication


For example, confirmation of login using a one-time SMS password, or a key from a physical / software token, is well suited. In this case, to organize attacks, the attacker needs to take possession of the mobile phone or the victim's token, until she has time to report the missing to the company's security service.



Secure VPN tunnel


In addition to the previous option, it is convenient to use VPN technology to access internal services. In addition to encrypting traffic, the technology introduces an additional verification factor - when creating a VPN connection, the initiator needs a login + password / certificate, without which a potential attack will be suppressed on the network equipment, without reaching the service infrastructure.



Remote Desktop


There is also the option of organizing access to the corporate network on the principle of "remote desktop". That is, access from the Internet is not given to the service, but to the desktop of a secure server that has access to this service. This approach is less convenient to use, because in fact, we get two isolated workspaces: remote desktop (files, browser bookmarks, clipboard ...) and a local laptop. There is an option to fully switch to a remote desktop, but then the remote server must be powerful enough, stable, as well as a communication channel to the Internet to work with it.



Corporate network architecture


Then the question arises - why not open the entire corporate network via VPN or remote desktop? And why not give all employees laptops to work from anywhere in the world?
Still, the potential leakage of strategic information is too great a risk for a large company. Especially if the employee is with a working laptop somewhere abroad. Or did a compromise of employee authentication occur.

In addition, often for the development of new products on DevOps practices for all team members, full access to the entire network is not necessary. It is enough to have access to the test site and the adjacent infrastructure.



Network segmentation


Therefore, an important task is to be able to distinguish between access to strategically important network resources, and less important ones used by teams in their daily work.

The basic principle of delineation is network segmentation, that is, to restrict access to certain services at the network level. In large companies, this principle is often neglected, since it is easier to grow the entire network infrastructure in a single network space, not to waste time on opening network accesses between different parts of the infrastructure. In this case, capturing one server from the outside puts all remaining resources at risk.

Therefore, the principle of segmentation - resources that are accessible from the outside, must be located in an isolated network segment.



Access between segments


Then the question arises - what to do if these services still need access to some resources of the corporate network? For example, the task management service needs access to the corporate mail server to send out notifications about new tasks. In this case, access is opened, but strictly at certain addresses and ports. In order to capture a task management service, the maximum damage is email SPAM mailings, or the mail service is not available through the same DDoS. Of course, these are unpleasant scenarios, but at least the strategic information will not get out.

Control ports


In order to additionally protect internal services from attacks from potentially captured external services, it is recommended not to open the “control” ports of the internal network. That is, those through which it is possible to get full access over the server (SSH, Telnet, RDP, FTP ...).

The most ideal option is not to open access to the internal network at all. And, instead, open only reverse access - from the internal to the external network. For example, to send a letter, not the sending system makes a request to the postal system, but on the contrary, the postal system refers to the sending queue of accumulated letters.

User access to segments


The next question is how much to make isolated segments for external access? The safest option is one segment per service. In this case, with the seizure of this service, neighboring services will not suffer, or will suffer minimally. But this incurs additional overhead in creating network segments and opening accesses between them.

Therefore, the most balanced option is to combine similar services into a common segment. For example, a task management system, source codes, and a knowledge library. They all need the same access to other services: mail server, user authentication server, database server.

As a result, in addition to placing them in a common network segment, it seems logical to open access to external services not point-wise (from each individual service), but in large quantities (from the entire network segment). This will save time on opening network accesses in case of an increase in the number of services in this segment.



After the availability of the required number of network segments and services in them, it is advisable to limit access from outside to different network segments. In other words, let the user only to those segments whose services he really needs to work.

Impersonal data


If the team still needs access to the infrastructure of their products for their development?
Usually, product development is carried out on test sites, the most dangerous in which is user data / financial information. Oddly enough, the data itself is not needed for development, usually their impersonal copy is quite suitable! There are a huge number of methods of depersonalization, the simplest of which is to replace surnames, telephone numbers and other information on clients with similar in structure and meaningless character sets.



What's next?


Suppose that you have taken these difficult steps in your large organization: rendered services into isolated segments, opened network accesses, and impersonal data. What's next?

Unfortunately, employees can be very conservative and not willing to move to a new infrastructure. Not even because it is better or worse, it's just new, and they are used to the old. And the transition for them - the additional costs of the project, and the benefits - the potential opportunity to work outside the office, which may not be all interesting.

Or, even the team switched to a new infrastructure, began to settle in, but the old one did not disappear. And there is always the temptation to return to a stationary workplace from a laptop and do something as before.

Team Artificial Isolation


It is necessary to withdraw the team from the office, you can not even in another city, but in coworking / anti-cafe / another office. But with two prerequisites - in a new place there should not be a corporate local network. And the new office should not be within walking distance from the old one. Both conditions completely exclude the possibility of returning to the old infrastructure. And, if the new infrastructure is well prepared, the team will return to the old office completely independent of the old one, as well as a bonus - additionally cohesive.



Total


Summing up the article, I can say for sure from my own experience - even the biggest companies that keep their secrets may well create the conditions for distributed development for their employees. It is only necessary to implement simple, reasonable technical and organizational principles, some of which I described above.

If you have something to add from your experience, please write in the comments!

Source: https://habr.com/ru/post/320132/


All Articles