For the last decade, I’ve worked a lot with building virtual apps and desktops from a lot of different providers, going from Citrix, VMware, Microsoft, and even old 2X and Dell vWorkspace even… The focus was always providing in most cases a centralized secure workspace for end-users, which needed to access their applications whether it be a Windows application or web-based application. We have also seen we also have had the ability to provide CAD engineers with GPU-powered workspaces as well still against many of the same Windows applications. 
VDI platforms have been a great use-case where we have had applications that require low latency access to data often stored inside the data center. We were able to solve most use cases with remote workers using this type of delivery platform. Sometimes we needed to add a VPN service to provide direct network access to internal services when VDI wasn’t enough.
And with increased adoption of SaaS services as well, the workspace of the end-user also shifts from a centralized to a more decentralized approach in terms of application delivery. However, their primary use is consuming applications.
If we look at the workspace of a user, they need to have access to different applications depending on their role (HR, Finance, Management, and so on) everything is neat and easy to access to consume those applications. In addition, many of these applications have now also been ported to mobile devices making it easier for users to be able to work from anywhere and from any device.
With all the end-user platforms I’ve built I managed to make efficient, optimized, and secure workspaces. However, I always noticed that most developers were not too happy with the VDI service or end-user platform, so in some cases, custom solutions were built to provide developers with their own way of accessing services while still being able to develop on their local workstations.
In addition, with more organizations moving to the public cloud we see a lot more usage of automation (not just IaC) but also with application development allowing developers to control the full lifecycle of an application from just pushing code to a repository. Within the repository, they have a defined CI/CD pipeline that allows ease of deployment of new applications into various platforms.
CI/CD concepts | GitLab

This also means that there need to be more security mechanisms in place to detect that someone is not injecting malicious code from a compromised machine or that someone has been able to steal an access token from a developer to gain access to CI/CD pipeline and steal environment variables for instance.

Some of the recent security articles show different attack methods related to development.

In addition, Microsoft has stated that they have seen an increase in an identity-based attacks by over 300% over the last years. There was also information that in the Uber attack the attacker managed to gain access to the internal Slack service as well Teen hacker behind Uber security breach announced hack in the company’s own Slack. | Mashable and many know that Slack is a platform that might contain a lot of information and secrets.

Unlike end-users, developers are both consuming and building applications which requires that they need to have various levels of access to internal systems and services to be able to test applications, and local test environments and can have the required software installed, and application libraries on a machine. I found this picture as a good description of how a developer environment should look like, essentially a workbench. Most developers I’ve spoken to want to use something familiar, and personal, and built up the way they want it to be with a lot of customization.

Simple Workbench Plans (DIY)

Securing the developer experience

Most enjoy using their own machine as their primary workbench to develop and build applications and not use VDI. Have been forced to use VDI because of security requirements since your own machine which might be a corporate device didn’t have the necessary security features in place to ensure secure access.

However, with a modern approach to secure access built upon ZTNA (Zero-Trust Network Access), we can mechanisms in place on end-user’s machines to verify the health of an endpoint before they are allowed to gain access to internal tools and services. 

There are a lot of vendors in this space that provide ZTNA-based services that can handle uses context-based access using posture from both the user’s identity and the device, meaning that it can check the health of the device before granting access.

I’ve written a blog previously about this here –> Secure Remote Access in 2022 with ZTNA | Marius Sandbu (msandbu.org) that is focused on offerings from Microsoft, Cloudflare, and Citrix. It should be noted that there are other vendors in this market

  • Palo Alto
  • CheckPoint
  • ZScaler

While this part handles the way to do a check of their endpoints before they are allowed to access services such as Slack, Jira, GitHub, and others it is just a small part of the architecture. Now to try and put this in a broader perspective, to try and maintain a secure development environment.

1: ZTNA-based access to internal services which require identity and device posture to verify “health” and other conditions of the access. This ensures that only approved users and devices are allowed to access services such as GitHub, Slack, and Jira (as long as you have integrated those services with an IDP that supports the posture check)

2: Integrated collaboration and code tools with external CASB services, this can be used to ensure that access is not granted to external users and that you do not have any data stored there that should be protected using DLP.  Also, monitor for abnormal activity such as mass downloads from the repository.

3: Having tooling also integrated with a SIEM product to monitor (for instance if a compromised machine and someone can steal a GitHub personal access token, which they are trying to abuse from an unknown location)

4: Identity integration into all SaaS services to ensure lifecycle management of access to the different services. To ensure that access to the services is only from actual active users.

5: Monitor that external services are not collecting information from Slack that they shouldn’t be collecting using CASB services.

This example architecture is showing what a developer setup could look like from a security perspective in terms of providing access and an example pipeline. How the pipeline should be built is of course fully dependent on what kind of application/service is being built.

Now in this scenario, development is being done using a local machine with an IDE. Meaning that the development environment is locally on the machine.

There are of course also other options here on how to access a workbench, another option could be

  • GitHub Codespaces
  • GitPod
  • AWS Cloud9

These all offer a web-based IDE, which means that the developer workbench is directly available from the web browser. This however also means that you are restricted to those application libraries that work within that environment.

The good part is that with a web-based IDE is that most of these provider supports integration via custom iDP that allows us to have context checks before the developer is allowed access.

If a web-based IDE is not enough, and you require local access to internal services you can still use VDI or have a network tunnel service on your developer machines using a ZTNA approach.

Microsoft recently released a new service called Azure DevBox which provides self-service-based VDI. Meaning that developers can provision their own VDI machine based on a predefined image –> Getting started with Microsoft DevBox | Marius Sandbu (msandbu.org)

In terms of setting up remote access without a full VPN approach (per-application access), there are also numerous services that one can use.

  • Cloudflare Zero-Trust
  • Teleport 
  • Pomerium
  • Hashicorp Boundary 
  • (In addition to others already mentioned on the list) Citrix, Microsoft, VMware, and Palo Alto

Most of these also support easy access to virtual machines in addition to providing access to internal services using TCP/UDP like in most cases where developers need just-in-time access to internal lab environments or debugging services running inside a Kubernetes cluster.

For instance, Cloudflare can run as its own Container inside a Kubernetes cluster, making access easy.

 

 

 

 


0 Comments

Leave a Reply

Your email address will not be published.