Is your code in VSTS safe? - 1
Control unauthorized access to your code by implementing ‘conditional access’ to your Visual Studio Online (VSO)/ Team Services (VSTS).
This topic might look too simple to be discussed in detail, however, the more you make your needs specific it can get painful (and interesting), especially if you are a traditional enterprise (think about governance, risk, and compliance – GRC teams!). I will be discussing this topic in two parts.
VSTS is a fantastic service in every sense as it enables modern development and releases seamlessly. However, many organizations are skeptical of using a Software as a Service (SaaS) to put their intellectual property's codes on such services. One of the main cause for their skepticism is their lack of understanding about how they can prevent unauthorized access to their code.
While preventing unauthorized access is not the only aspect to protecting the code, it is the most fundamental and important aspect. Other aspects are beyond the scope of this blog.
Before I begin discussing the solution, let us look at key aspects that need to be considered when controlling access – User, Endpoint and Network. We need to ensure all three can be trusted; namely have a Trusted User, a Trusted Endpoint, and a Trusted Network, before we provide access to the code residing in VSTS.
Trusted User: If you want to ensure only authorized users of our company are able to access VSTS and the obvious answer is to control the access to VSTS using your corporate Active Directory (AD). This is where Azure Active Directory (AAD) comes to your rescue. It can be integrated into your on-premises AD to control authentication and provide SSO to more than 2,600 SaaS applications (and VSTS is one of those!). There are third party solutions too, but your first choice should always be Microsoft integrated solutions. You can use Azure AD Connect to integrate your on-premises AD with Azure AD. You can read about it here (or, better, contact us to know more!).
Two important points to consider while designing the solution is – who all needs access and what are their work styles:
- Who: Apart from your own employees (on your AD), you may have individual contractors who work as Developers / Testers without an AD account, or you may have outsourced development to another organization who has their own AD accounts.
- Work styles: Work from home, office, customer/partner locations using their own PC/laptops (endpoints), company provided, customer/partner provided and, at times, even from public endpoints (café /kiosks).
Depending on the 'who' part, you have to select the right options from Azure AD such as enabling B2B integration (for partners or customers) or using Microsoft Account (Live ID) for individual contractors, etc. The 'work styles' part will determine the solution for the Trusted Endpoint and Trusted Network.
The Trusted Network aspect: This is relatively straightforward. Your office network is the only network that you trust and anyone who is trying to access the code/VSTS from another network should not be allowed. So, the question is how do we do this on VSTS that currently does not offer a method to provide your organization's IP ranges as 'Trusted Networks or IPs'? Azure AD once again comes to your rescue. AAD has a feature called Azure AD Conditional Access. Conditional access allows you to set access rules for individual apps based on conditions such as a user’s group membership and location. You can make use of the 'Block access when not at work' rule to block users that aren’t coming from the corporate network. It does not work with Azure AD Basic license, but needs license for Azure Active Directory Premium. Unless you have this license, you won’t see the options shown in the picture below. You can define your office networks or the trusted IP address ranges on the multi-factor authentication settings page. Figure 1 below illustrates how to enable access rules on AAD.
Now you have put in controls where only a Trusted User can access VSTS from a Trusted Network. Till this part, everything looks good. We still need to address the Trusted Endpoint aspect, which is a critical to ensuring your code is safe in VSTS! Now, handling this one requires technology elements outside the realm of Azure and VSTS.
The Trusted Endpoint aspect: In our context, a Trusted Endpoint is a desktop/PC/Surface Pro (basically devices) that the organization (believes) has put sufficient control in place so that the checked out code cannot be taken out of the endpoint. Typically, domain joined endpoints coupled with the implementation of Data Leak Protection (DLP) software is a good solution and there are many popular DLPs out there to choose from. But that solves only one aspect of the Trusted Endpoint issue; the code will not go out of the Trusted Endpoint. But how would the VSTS know that the trusted user is trying to access/checkout the code from a Trusted Endpoint? Currently, there is no way we could achieve this natively using only VSTS.
So, what are the options? We will be discussing those in part 2 of the blog! In the meantime, you can share your thoughts on the topic in the comments!