The development of the intranet into BeyondCorp

Aron Köcher, Miro Bilge

Only a few years earlier, the solution to exchange digital information like documents or pictures was to establish a physical connection between the participants. A usb stick was passed around the class to exchange music, you went to your friends house to print some urgent papers or a group of friends met to play games via LAN. With the increasing access to the Internet, new solutions have emerged.
While some users are satisfied with sending files by mail, for a company with different locations and a large number of digital data, a business solution is required.
With Virtual Private Network (VPN), a solution was created that allows one or more participants to become part of another network. The connected member has full access to devices, data and services as if he were physically present. Instead of a real connection, a tunnel is built over public networks, which is why it is called “virtual private”. The basic structure of a virtual private network is always the same. A VPN connection consists of two participants, a client and a server, which establish a connection. Depending on the protocol, the connection can be encrypted and use different layers.

Initially, independent lines and connections based on the data link layer were used to connect individual locations. With the help of Frame Relay, a permanent, virtual link was established between the sites. This technology was replaced with the increasing change from layer 2 to ip-based network technology. Compared to a dedicated line, the financial costs are much lower with the benefits of an ip-based link. Only a one-time configuration and Internet access, which is usually available anyway, is required.
The end user of VPNs usually does not come into contact with Layer-2 VPNs, because if a dedicated line is rented, it is set up in the background by the network operator and appears to the consumer as a physical connection. Therefore, due to current usage and the relevance for the readers of this blog, we will only discuss ip-based VPN in the following.

Besides different protocols with different encryption methods, there are three types of VPN:

Client to Client VPN

Here a connection between two clients is established. This is used, for example, to control a computer using TeamViewer. and it is the only connection type where the complete message traffic is encrypted. Therefore it is limited to two devices.

Client to Site

With a Client to Site VPN, it is possible to connect a client to a remote network. This makes it possible for remote employees, such as during the COVID-19 crisis in the home office, to be a regular part of the company network. They have unlimited access to data and devices in the network. On the network side, this requires a VPN server to which the employee can connect after configuring a VPN client. The client software comes with the common operating systems and is also available as a mobile solution for smartphones. The message traffic is encrypted until it enters the network. This can also be used to protect privacy. Web pages that are accessed via a VPN only see the VPN server, but not the client. This allows the user to spoof his position and, unless logging is used on the server, he cannot be distinguished from the other users. Furthermore a Man-In-The-Middle attack in insecure networks is made more difficult. Attackers only see that an encrypted tunnel to a server has been established by the client. It is hard to draw conclusions about the called services, even if they are not encrypted. The different data protocols are repackaged in a VPN frame and are therefore not recognizable.

Site to Site

If companies grow beyond one location, the question arises how employees at both locations are given access to company data.
For smaller locations, a client-to-site solution is sufficient to allow employees to access data from the main location. If the second location receives services, devices or data carriers that are to be accessed bidirectionally, both networks must be accessible via VPN. For this purpose, a VPN server is set up on the main network and a VPN concentrator on the second. With this site-to-site VPN, all internal network connections are exchanged between the VPN nodes and the two networks appear as one large network.

Limitations

By tunnelling all packets over the VPN interface, all network traffic and speed is directly dependent on this connection. With the failure of the VPN, internal processes are disrupted and, depending on use, the company’s business might come to a halt.
A further point is the security of a VPN. Externally, the network is protected against dangers from the Internet by the firewall. With the VPN a user becomes part of the network and has access to the devices and data contained in it. If an attacker overcomes the encryption of the VPN, the advantage of unrestricted access becomes its disadvantage.
Apart from the security concept which ends at the VPN gateway and firewall, the VPN tunnel is also not untouchable. The number, size and VPN remote terminal offers the possibility of drawing conclusions about the transmitted data.
In addition to security, the provision of services and files and the extension of the network to include external services requires complex configuration. The internal network must be divided into further subnets with different access rights. This adjustment may be required for each customer and service. This demands active network management and can quickly become difficult to manage.

Network Access Control

There are various approaches to prevent the flexibility and options of a VPN, such as location and device independence, from becoming a vulnerability in the company network.
The difficulty lies in the fact that by bridging the VPN, malicious software has access to the internal network. So the approach is to prevent malware from entering the network in the first place. In return, administrators can only grant access to known devices and restrict the installation of drivers and programs on these devices. These restrictions must always be re-evaluated in terms of productivity and must not restrict the user too much. With increasing rights, such as required port sharing, the control over each individual device becomes more difficult. Moreover, the case of a contaminated device is not covered. This is why Cisco published the first approach to transferring network security away from the devices to the network as early as 2003. With Network Access Control (NAC), all devices that want access to the network are subjected to a security check. NAC thus forms a further layer between the VPN and the network, which handles access to services and resources.

System Overview Network Access Control [17:
https://blogs.getcertifiedgetahead.com/network-access-control/]

For the NAC system to grant access to a compliant device, the definition of compliant must first be defined in a policy rule. Depending on the NAC software and provider, the possibilities of the rules to be set vary. With current anti-virus signatures and installed security updates and patches, Cisco has created a basis for its approach. The network needs additional help to read out such information and check whether the connected device is a new one. The installation of an agent on the devices offers, in addition to access to this data, the possibility of automatically restoring a compliant state in case of non-compliance.
If a device wants to connect to the network, the NAC Health Server notifies the agent to read off the necessary data and checks it against the rules for the respective user group. When the status of the device does not match the rule set, the device is quarantined and cannot access the network.
The NAC server sends the deficiencies to the NAC agent on the unit, which then tries to resolve them.This includes everything from simply installing updates up to removing programs and software. If the compliance of the device can be restored, the NAC server allows access to the resources. The remediation process should be as self-sufficient as possible, but can quickly become quite complex depending on the deficiencies and user role. When creating the rules, different scenarios must therefore be considered. For example, if a customer needs access to shared resources but has an outdated operating system, the agent cannot simply upgrade it, but in principle cannot deny access to these resources. The resource would have to be relocated to a sub-network, which still does not clarify the question of how this potentially risky resource is handled internally. Depending on the number of customers and resources, this process also becomes increasingly complex and difficult to maintain.

Software Defined Perimeter

Compared to Network Access Control, Software Defined Perimeter (SDP) does not establish the connection until the device and user have been authorized and authenticated. At the time of the authentication process, the location of the resource is unknown because it is not registered in the DNS. This is why SDP is also called a Black Cloud, which has many advantages over NAC. With the unique assignment of access rights and roles for each resource, a segmentation of the network is no longer necessary. Resources are only accessible for the respective user roles. This simplifies management by eliminating the need to create an additional subnet for each customer or service. The customer receives a user and is assigned to the resource.

System Overview Software Defined Perimeter [14: https://procureadvisor.com/the-definitive-guide-to-software-defined-perimeter/]

If the customer now wants to access the resource, he first contacts the SDP controller, which confirms his identity and integrity via the user management. Then the user is authorised and receives an authentication token. This token contains the resources that the user can access. If the user now accesses a resource, a VPN connection is established to the respective SDP gateway. This connection is established and terminated automatically via a client software. At the SDP gateway, the user is again identified via his token and then gains access to the one resource.
By using SDP, Destributed Denial of Service, Man-in-the-Middle Attack and Code Injection attacks are prevented or made more difficult. In addition, in most cases the attacker does not receive access to the entire network if the attack is successful.
The use of Software Defined Perimeter forms the basis of Zero Trust Network Access (ZTNA). No device, user or service inside or outside the network is trusted. Every single connection is encrypted and no resource can be reached without prior authentication. Viewing different connections as a separate environment with individual security requirements creates a minimal space of attack. ZTNA is transparent for the user, he only has to log in once via the client and can then access the resources.

To set it up, all users and resources must be assigned a user role and a predefined risk profile. This categorization of services, users and devices means a lot of effort for the company. Once completed, the system can easily be expanded to include roles and guidelines.

BeyondCorp

Before we take a closer look at the BeyondCorp Remote Access business model, the following chapter will first discuss Google’s initial idea. In 2011, Google started to develop its own intranet away from the VPN and towards Google BeyondCorp.

Google’s idea was to get rid of the privileged network with single perimeter security and move to a more flexible solution similar to the Zero Trust Model. Important core components were to evaluate access depending on the respective device and the respective user. For example, a user can be authorized to access a resource from his company laptop, but if he wants to access the same resource via smartphone, this is not allowed. Furthermore, BeyondCorp is intended to provide unlimited network location and user experience. This means that it should make no difference to the employee whether he works from home, the company location or a public Internet café (depending on latency, of course). The same user experience also means that this can only be achieved if secure access is possible without VPN for the employees.

Google’s BeyondCorp was built on the basis of these core components. To ensure these key elements are in place, every request is fully authenticated, authorized and encrypted no matter where it is made from.

Architecture

To realize Google’s goals, the network architecture was redesigned. In the following the individual architecture components are described on the basis of the diagram:

1) Although it is a Google building, there is a privileged network, i.e. a network in which users are trusted and an unprivileged network. The latter is, similar to an external network, not trustworthy at first sight. Users who are in the Google building and on the network could just as well be sitting in a public Internet café from a security point of view. Therefore, access from the Google Building is equivalent to remote access. The difference is that it is possible to make requests from the unprivileged network via a private address space.
Consequently, requests to the Internet run from the unprivileged network. If a user wants to make an internal access to another part of the Google network, this is checked via an Access Control List (ACL).

2) All user requests e.g. from the unprivileged network or enterprise applications from Google run through an Internet Access Proxy. This proxy forces an encrypted connection between the connection partners. The proxy can be specially configured for each application and offers various features such as global reachability, load balancing, access control checks, application health checks and DoS protection.

3) The basic prerequisite for granting access to the Access Proxy from the unprivileged network as well as from the public network is that the device has a so-called “Managed Device” status. This status means that the device is actively managed by the company and only these devices can access company applications via the Access Proxy. At the same time, Managed Device status implies that the company can track, monitor and analyze changes to the device. The goal of this is to be able to react dynamically to the security status of each device in order to allow or deny requests.
Technically, the Managed Device Status is realized by a certificate. Each device that has the declared status is unique and can be recognized by the certificate. The certificate is renewed periodically and serves as a key to confirm that the device information is valid. In order to obtain a certificate, the respective device must be present in the Device Inventory Database (DID in short) and correctly stored. On the device, the certificate is then stored on a TPM (Trusted Platform Module) or a qualified certificate store, depending on the platform either on the hardware side or on the software side.

4) The Access Proxy is fed by the Access Control Engine so that it can decide which requests from which user and which device it allows and which it does not allow. Based on the Access Control Engine, the Access Proxy can act as a dynamic access layer. In order to provide the Access Proxy with “advisory” support, the Access Control Engine itself has various sources of information at its disposal. Based on this data, both static rules and heuristics are deduced. In addition, machine learning is also used. Information that can be relevant for the Access Control Engine can be, for example, the operating system version number, the device class (cell phone model, tablet, …), access from a new location, user or user group, the device certificate, but also other information and analyses from the device inventory database.
For each request, the Access Control Engine then evaluates whether the required security level matches the security level established for the requested device based on the analyzed data. By determining the security level on the request side, it is also possible to separate parts of an application. For example: A user may be authorized to view an entry in a bug tracking software. But if he wants to update the status of the bug or edit the ticket, it is possible that this request will be blocked, because the trust to this user is not sufficient.

5) The Access Control Engine is in turn fed by a pipeline that extracts and aggregates the dynamic information.

6) BeyondCorp also uses Single Sign On for authentication, similar to the classic Zero Trust Model. The central user authentication portal is used to validate the primary access data. Furthermore, a two-factor authentication was added in the same step. After validation, short-lived tokens are generated, which then form part of the authorization process for specific resources. Depending on the trust level of the resource, the authentication measures can be more or less stringent.
Since the administration of user groups and associated authorizations is relatively complex, for example if authorizations can change when a department changes, the user/group database is closely linked to the processes of HR (Human Resources). Consequently, if there is a new hire, new role/responsibility or someone leaves the company, these processes are recorded in HR. Every change in the HR processes also triggers an update in the database. This ensures that the employee data is always kept updated, while the effort required to keep the database up-to-date at the same time remains low.

7) Besides Single Sign On, Google uses RADIUS Server for network authentication. A user’s access via LAN or WLAN is transferred to the corresponding network via the RADIUS Server, so that an attacker cannot attack the entire network, but only a segment. In the case of Google, the RADIUS server assigns a managed device to the unprivileged network as soon as the device has authenticated itself using a certificate and 802.1x handshake. Another advantage besides security is that the network management is not done statically via fixed VLAN areas and switch/port configurations but can be dynamically referenced. Other devices without certificates for example are assigned to a guest network. In addition, in the case of an outdated device version the RADIUS server can also refer a potentially compromised device from the unprivileged network to a special quarantine network.

Architecture of BeyondCorp components. Own presentation according to [6: A New Approach to Enterprise Security (BeyondCorp)]

As could be seen in the architecture, the Access Proxy plays a central role in the development of BeyondCorp, and since Google has tried to reuse as much existing technology as possible in the architecture, with the Access Proxy they have done the same. This was based on HTTP/HTTPS reverse proxies, so-called Google Front Ends (GFEs), which were already used in the front-end infrastructure and offered load balancing and TLS handshake “as a service”. These were subsequently extended to access proxies with several configurations like authentication and authorization policies. Since the Access Proxy is a central communication element, it supports OpenID Connect and OAuth as well as user-defined protocols that can be integrated. As a result, the user authenticates himself to the Access Proxy. If access is granted by the Access Control Engine, the request is forwarded to the backend service without any further credentials. There are several reasons for this. On the one hand, this increases security, since no credentials are intercepted on the backend side. Secondly, the Access Proxy is transparent for the backend. If the backend service supports its own authentication e.g. by credentials and/or cookies, confusion would occur if these credentials were also passed on to the backend service.
Nevertheless, the communication between Access Proxy and Backend Service must be secured. Therefore the internal communication takes place via HTTP with an encrypted channel. For this Google uses an internal authentication and encryption framework called LOAS (Low Overhead Authentication System), which enables the service to trust all receiving data. The framework works with mutual authentication which means that both entities in a communications link authenticate each other. This ensures that metadata is also not spoofable. An advantage of this is that new features can be added to the Access Proxy and different backend services can subscribe to the new features by parsing header fields.
Also the combination of Access Proxy with Access Control List through the Access Control Engine offers some advantages. For example, the central location of the components provides a uniform access point, which makes forensic analysis more effective, since logging is controlled centrally, so that an attack can be responded to not only one service, but directly for all backend services. Furthermore, enforcement policies can be managed centrally and defined consistently. Changes can thus be implemented more quickly. Another advantage is that backend developers do not have to worry about authorization. If the trust level of the service does not require any further authentication measures, the developer can rely on the fact that users are already homogeneously authenticated. If this is not sufficient, the rough approach can be refined by a fine-grained approach. For example, if a database application requires an additional authentication measure, this can be combined by the service itself integrating authentication. In this way, the system remains maximally flexible to the needs of the respective service. The service only has to initially configure the Access Proxy correctly to ensure that external communication between the service and the Access Proxy works.

After showing the architecture, the question arises how employees without VPN access can access the network from a client perspective? The answer from Google’s BeyondCorp provides a chrome extension. All access requirements, whether in the office or on the road, are handled through this access point. This is possible at Google, since the majority of all applications are accessible via the web according to the internal company guideline “online first” and the percentage of local applications is kept to a minimum.

The extension automatically manages a user’s Proxy Auto-Config (PAC) files and then routes the user through the Access Proxy to the appropriate destination. When a user connects to a network, the extension automatically downloads the latest PAC file and displays the “Good Connection” icon. Since all requests from the BeyondCorp extension are routed to the Access Proxy, it cannot communicate with devices that cannot reach the Access Proxy. For example, the local printer at the employee’s home. The status provides a solution here. When the employee enters the printer’s IP address in a new browser tab for configuration purposes, the request is sent to the Access Proxy along with all other private address space traffic. The routing request fails and the user receives a failure. Customized 502 error messages have been implemented to tell the employee that the extension must be switched to “Off:Direct”. Subsequently, the user can configure the printer and afterwards reconnect to the Access Proxy.

Infrastructure components

In the upper section we have often talked about different trust levels. In the following section, we will take a closer look at trust tiers and how BeyondCorp structures its infrastructure elements.

Each resource is associated with a minimum trust tier that is necessary for access. The rule is that the lower the level, the more sensitive the information and thus the higher the necessary trust. If an employee now wants to access a resource, the first step is to check the trust level of the employee and his device. Subsequently, a trust level is assigned to the employee. Then it is checked whether the employee’s trust level is equal to or higher than the trust level of the requested resource. This results in the advantage that maintenance costs, e.g. costs for support and productivity, of highly secured devices are kept low and usability is improved at the same time.

On the architecture side, the Trust Inferer is responsible for the classification of the trust, which continuously analyzes the device status for the trust evaluation and thus determines the trust level. For this purpose, it uses the information of the Device Inventory Service, which in turn uses various information for aggregation (see figure below). If, for example, a laptop has not applied a security patch for the operating system, this may be less severe for a laptop with a lower trust level than for a laptop that was initially assigned a higher trust level. Conversely, this laptop with a high trust level could be temporarily downgraded due to the missing patch until the patch is applied. This way, employees are always encouraged to keep their software up-to-date. If the trust level has dropped to a minimum, consequences can also be drawn on the network side: A completely outdated laptop can thus be transferred to a quarantine network until the device is rehabilitated. This limits access to resources to a maximum and protects confidential information.

Architecture of the BeyondCorp Infrastructure Components [7: Design to Deployment at Google (BeyondCorp)]

BeyondCorp Migration

As we have already seen in previous sections, it is not easy to convert the company’s own intranet in the same way as BeyondCorp, since a relatively large amount of restructuring is required, both on the network side and from the perspective of the overall architecture. The following section gives some advice on how to do this and how Google has implemented the restructuring.

First of all, it is important to realize that the intranet conversion is initially less technical effort, but rather more bureaucratic. One must be aware that the conversion affects the entire company including all employees and therefore the idea should be communicated early. The goal of this is to get maximum support at all management levels, which also means that everyone in management must have understood the benefits of a restructuring for the company. For example, reducing the risk of attacks could be an argument, while at the same time improving productivity. A risk table can be helpful for better understanding, as shown in the following example:

Own figure

Once the management has understood that the changeover makes sense, supporting processes can be set up through early communication, which can be declared by change management.

It is also important to be aware that the changeover is a lengthy process. It is only possible to renew incrementally, as many layers are affected, such as the network, security gateways, client platforms and backend services. Therefore, it makes sense to define migration teams in the different layers and to determine a leader who coordinates with the other leaders of all layers.

Automatic transfer of employees to Managed Non-Privileged Network

The idea of Google was to keep the administrative effort to transfer employees from the privileged network to the unprivileged network as small as possible. For this purpose, a pipeline was developed that would automatically move the user away from the VPN to BeyondCorp with the Chrome Extension. The pipeline consists of three phases and starts with the logging mode: A traffic monitor was initially installed on each device. Each call from the privileged network is analyzed via an Access Control List (ACL) and classified whether the same call would have been accessible from the unprivileged network. This means that the same service would have been accessible via the Access Proxy. This was then logged and recorded. The content of the ACL was then stored centrally in a repository with the source IP address data to identify the user and the destination IP address to determine which service was not available. In the first phase it was possible to analyze relatively quickly which service was not yet connected to the Access Proxy, but at the same time had a high demand from the employees. As a result, a prioritization list could be created, which services should be attached in which order. The logging mode was executed until the following rule came into effect: If the employee could have accessed more than 99.9% of the content over 30 days via the unprivileged network, he will be put into enforcement mode after an e-mail notification with the employee’s consent. This differs from the logging mode in that requests that could not have been accessed from the unprivileged network are captured and dropped. If an employee has again been able to reach more than 99.99% of the requests via the unprivileged network over a period of 30 days, he will be transferred to the unprivileged network again after an e-mail notification. If less than 99.99% of the requests can be reached from the unprivileged network or the employee rejects the request, he is automatically downgraded back to logging mode. With this approach more than 50% of all employees could be automatically transferred to the unprivileged network.

The pipeline for moving Google computers to the Managed Non-Privileged (MNP) network [9: Maintaining Productivity While Improving Security (Migrating to BeyondCorp)]

BeyondCorp Remote Access

In early 2020, Google launched BeyondCorp Remote Access. This is a SaaS solution designed to support companies, especially during COVID-19, to be able to work securely from home without VPN access. The reason for the current launch, to create an alternative without VPN, is the bottleneck of VPN. Due to the sudden shift away from the office to the home office, many IT departments could not provide enough or a stable VPN network for all employees. Google has heard from many customers that this has made it impossible to access internal web applications such as customer service systems, software bug trackers and project management dashboards that would otherwise have been easily accessible from the company’s own network via web browser.

As a result, BeyondCorp Remote Access was released as a zero-trust solution based on its own BeyondCorp system. In addition to the aforementioned advantage of providing a fast solution without VPN, Google promises that customers, for example, can also easily access internal web applications. The proxy service also has enforcement policies that are checked depending on location, user and device. For example, Google provides the following example of an enforcement policy in its blog entry: “My HR managers who work from home with their own laptops can access our web-based document management system (and nothing else), but only if they use the latest version of the operating system and use phishing resistant authentication such as security keys.”.

Another advantage of BeyondCorp Remote Access is its rapid deployment. With little local technology required and the ability to incrementally migrate individual applications, the Google service can be quickly integrated into the corporate structure, with Google advising that during a pandemic, key services should be connected first and then incrementally added to keep employee productivity high. This includes network-side architectural changes and security controls, as internal web applications can remain hosted in the same location. BeyondCorp Remote Access only takes care of the connection and linkage between application and employee. Finally, with the proxy service, a company can also avoid outsourcing time-consuming deployment, maintenance and infrastructure management tasks to the cloud and simplify licensing. This also promises easy scaling, low latencies and redundancy.

Overview BeyondCorp Remote Access Architecture [12: https://medium.com/andcloudio/remote-access-with-beyondcorp-f3bedd1432f2]

How does BeyondCorp Remote Access work?

If the user tries to call up a web application, the access first goes to the Cloud Identity Access Proxy (IAP). In addition to load balancing and encryption, the IAP also takes care of authentication and authorization. The service uses Google Accounts for this purpose. It is also possible to connect a local identity management system such as Active Directory. In this case, Google Cloud Directory Sync is used to synchronize user names with the cloud identity, while passwords are stored locally and instead SAML (Security Assertion Markup Language) as SSO is implemented to authenticate users with the existing local identity management system. The access between client and proxy is then analogous to Google’s BeyondCorp via a chrome extension. This extension collects and reports device information that is constantly synchronized with the Google Cloud and can be stored in a device inventory database in the Google Cloud.

Subsequently, IAM (Identity- and Access Management) roles can be used during authorization to decide whether or not the user is granted access. Behind the firewall is then the IAP Connector, which is used to forward the data traffic secured by Cloud IAP to local applications. This is also supported by a DNS, which creates public domain names for the internal local apps and assigns the IAP Proxy IP address to them. This allows access to a locally hosted enterprise application. It is also possible to integrate Google Cloud Apps and applications from other clouds.

Connecting BeyondCorp Remote Access and local web application [12: https://medium.com/andcloudio/remote-access-with-beyondcorp-f3bedd1432f2]

To initially link the company’s internal network traffic with Google Cloud and remote access, there are three solutions that Google offers. Firstly, the company’s internal network is connected via Dedicated Interconnect (direct connection to Google). The traffic flows directly from network to network, not over the public Internet. The next variant is Partner Interconnect (more connection points through a supported service provider). Here, the traffic between the networks is routed via a service provider, but also not via the public Internet. The last variant is to use IPsec VPN, where the traffic is extended to the Google Cloud VPC (virtual private cloud) network, which enables private IP addresses as well.

Reservations about BeyondCorp Remote Access

While BeyondCorp Remote Access offers many advantages, it also provides some concerns that are discussed below:

First, BeyondCorp Remote Access is limited only to web and cloud based applications that can be linked. In the long term, Google plans to link local applications as well, but this is not yet possible. Another drawback is that each application must be individually integrated into the system. Therefore, in times of the pandemic, Google recommends prioritizing the applications according to their importance and to see which applications should be connected first. This must be done incrementally and there is no generic solution that can connect all applications at once with one configuration. Another point is the deep integration of the Google Cloud with the company network. This entails both technical and financial dependency. The former, because web applications moved to the cloud allow both Control Plane and Data Plane to operate via it. Furthermore, in the event of a technical problem, the administrators can do nothing to remedy it. You have to wait until Google gets the problem under control. In March 2019, for example, there was an operational disruption in the Google Cloud that would have made the company network unreachable from the outside. Financial dependency is also a point that should not be neglected. If the entire company architecture is linked to the Google Cloud over time, the company is also dependent on its pricing policy. If prices rise to this extent, moving to an alternative system will be very expensive and possibly not profitable. Finally, data protection is also an important issue. Depending on the explosive nature of the data, a company must consider whether it should be linked to the Google Cloud. All queries run via Google’s identity proxy, it is questionable whether every company wants to give Google such deep insights into the system. The same applies to user recognition. Even if you integrate an Active Directory system, user names are still synchronized via the Google Cloud. Finally, not all institutions are authorized to integrate BeyondCorp Remote Access. For example, the HdM would not have the necessary authority to connect students to the intranet via remote access because SSO must not synchronize from LDAP.

Conclusion

In summary, a zero trust approach makes sense in any case. The Zero Trust solution greatly simplifies the security over VPN access and firewall as a single perimeter, and also the complicated administrative overhead of integrating mobile devices and cloud systems. Each access is evaluated not only on the basis of authorization, but also depending on the respective request. This allows a much more fine-grained determination of whether or not access is permitted in the context of time, place and device. BeyondCorp Remote Access is also very useful for small companies, especially in times of COVID-19, to allow easy and fast access to the home office without VPN. However, the dependency on Google is a risk that must be made aware of and evaluated in the company context. If necessary, it may be worthwhile in the medium term to fall back on BeyondCorp Remote Access during the pandemic, but in the long term it is worth planning a strategy to set up one’s own zero trust model.

Sources

[1]: Bhattarai, Saugat & Nepal, Sushil. (2016). VPN research (Term Paper). 10.13140/RG.2.1.4215.8160. (Accessed 31.9.2020)

[2]: Sridevi, Sridevi & D H, Manjaiah. (2012). Technical Overview of Virtual Private Networks(VPNs). International Journal of Scientific Research. 2. 93-96. 10.15373/22778179/JULY2013/32.

[3]: Minnich, S. (2020, August 13). Heise Medien GmbH & Co. KG. Retrieved September 05, 2020, from
https://www.heise.de/download/specials/Anonym-surfen-mit-VPN-Die-besten-VPN-Anbieter-im-Vergleich-3798036

[4]: Helling, P. (n.d.). Was ist VPN? Retrieved September 05, 2020, from https://www.netzorange.de/it-ratgeber/vpn-bietet-sichere-verbindungen-auf-unsicheren-kanaelen/

[5]: Török, E. (2009, August 10). NAC-Grundlagen, Teil 1: Sicheres Netzwerk durch Network Access Control. Retrieved September 13, 2020, from https://www.tecchannel.de/a/sicheres-netzwerk-durch-network-access-control,2020365,3

[6]: Ward, R., & Beyer, B. (2014, December). A New Approach to Enterprise Security (BeyondCorp). 39(6)

[7]: Osborn, B. A., Mcwilliams, J., Beyer, B., & Saltonstall, M. X. (2016). Design to Deployment at Google (BeyondCorp). 41(1)

[8]: Luca Cittadini, Batz Spear, Betsy Beyer, & Max Saltonstall. (2016). The Access Proxy (BeyondCorp Part III). 41(4)

[9]: Peck, J., Beyer, B., Beske, C., & Saltonstall, M. X. (2017). Maintaining Productivity While Improving Security (Migrating to BeyondCorp). 42(2)

[10]: Victor Escobedo, Betry Beyer, Max Saltonstall, & Filip Żyźniewski. (2017). The User Experience (BeyondCorp 5). 42(3)

[11]: Hunter King, Michael Janosko, Betsy Beyer, & Max Saltonstall. (2018). Building a Healthy Fleet (BeyondCorp). 43(3)

[12]: Gunjetti, D. kumar. (2020, August 28). Remote Access to Corporate Apps with BeyondCorp. Medium. Retrieved 13. September 2020, from
https://medium.com/andcloudio/remote-access-with-beyondcorp-f3bedd1432f2

[13]: Keep your teams working safely with BeyondCorp Remote Access. (o. J.). Google Cloud Blog. Retrieved 13. September 2020, from https://cloud.google.com/blog/products/identity-security/keep-your-teams-working-safely-with-beyondcorp-remote-access/

[14]: ProcureAdvisor, & *, N. (2019, February 14). The definitive guide to Software-defined perimeter. Retrieved September 13, 2020, from https://procureadvisor.com/the-definitive-guide-to-software-defined-perimeter/

[15]: „ZTNA”-Technologien: Was ist das, warum jetzt erwerben und wie wählt man die richtige Lösung? (n.d.). Retrieved September 13, 2020, from https://www.zscaler.de/blogs/corporate/ztna-technologies-what-they-are-why-now-and-how-choose

[16]: Problem mit Google Cloud: Massive Störung bei mehreren Google-Diensten. (o. J.). Retrieved September 13, 2020, from https://www.handelsblatt.com/technik/it-internet/problem-mit-google-cloud-massive-stoerung-bei-mehreren-google-diensten/24413414.html

[17]: Darril. (2015, March 19). Network Access Control. Retrieved September 14, 2020, from
https://blogs.getcertifiedgetahead.com/network-access-control/