Shared Responsibility Model in Azure DevOps
More and more organizations opt for Azure DevOps to store their source code and project data. Azure DevOps has many benefits – from rapid application deployment and problem-solving capabilities to improved collaboration and communication at the workplace.
Yet, they sometimes overlook one important issue – the Shared Responsibility Model. This is a framework which outlines the responsibilities of the user and the provider in regards to security. Such a model varies from provider to provider and the one relevant for Azure DevOps is designed by Microsoft. So, let’s have a look at Microsoft and customer responsibilities when it comes to security…
Azure DevOps operates under a pay-as-you-go model. The responsibilities vary and are different for SaaS, PaaS, IaaS, and On-prem. Macrosoft states that “Azure DevOps uses platform as a service (PaaS) infrastructure” but there is also an On-Premise version of the solution – Azure DevOps server. To understand all these models’ options let’s look at each of them in detail.
Source: Microsoft Shared Responsibility Model
The Software as a Service (SaaS) Shared Responsibility Model outlines that users have limited control, typically limited to configuration settings within the app. As for the underlying infrastructure, operating systems, middleware, and application software – these are managed by the service provider.
In Platform as a Service (PaaS), the provider’s responsibilities include physical data centers, physical networks, physical hosts, and operating systems. Your responsibilities as a user are: information and data, devices, accounts, and identities. Responsibilities start to vary when it comes to network controls, applications, as well as identity and directory infrastructure, depending on their type.
With the Infrastructure as a Service (IaaS) model your responsibilities expand. You must pay attention to operating systems, network controls, applications, identity and directory infrastructure, information, and data, devices, accounts, and identities. In IaaS the provider’s duty is to take care of physical data centers, physical networks, and physical hosts.
Responsibilities for On-premise solutions
When it comes to on-premise installations, here we can see that full responsibility for data protection, and network security is on the shoulders of a user.
As you can see, in every of the presented models, an Azure DevOps user should take care of the security of their data and implement security best practices.
Microsoft’s responsibilities as a service provider
To be specific, Microsoft actually outlines that in terms of PaaS, their responsibilities are the following:
- physical data centers
- physical network
- physical hosts
- operating systems
In terms of data storage, Microsoft must upkeep storage account service availability, secure local as well as geo-replications, and generate security access keys. As for data loss protection, Microsoft will cover all logs, notifications, and reports. Furthermore, there are integrated policy templates for you to use, to simplify the process. And, last but not least, (actually probably one of the most important aspects) is the service availability, which determines if you can access your Azure DevOps data.
Let’s move on to what Microsoft does to keep this model in place and adhere to it. First off, Microsoft includes basic retention for your deleted Azure DevOps data. Of course, you can customize retention policies for pipelines, releases, and tests. By default your retention for logs, artifacts, and runs will be set to 30 days, although you get to adjust retention, the limit is 365 days. Once the retention period expires, your sensitive data will be permanently deleted. It poses an issue of: what if something you deleted more than a year ago turns out to be important and you will need it for compliance, security, or resource point of view? That will be tough to tackle, therefore it is always advisable to implement a backup & DR solution.
Microsoft, as the provider, is responsible for the uptime of Azure DevOps. The underlying infrastructure of Azure DevOps is kept secure by the provider and it includes:
- protection on the network level
- physical security of data centers
- operational safeguards – policies, practices, and technical measures protecting the operational environment of a system
Azure DevOps has a 99% uptime SLA. Meaning that it should be available 99.9% of the time. However, things like unplanned downtime happen due to maintenance, hardware failures, regional outages, and natural disasters. To combat this Microsoft implemented redundant infrastructure, storing multiple copies of data and apps. There are also failover mechanisms to help with data and application availability during outages in one region. And of course, Microsoft has complex monitoring systems to track issues and address them.
In terms of authentication, Azure DevOps supports multi-factor authentication (MFA), which is great for access security. You also get role-based access control (RBAC), however, these have to be configured by the user before they start working – really worth it for secure permissions management. Furthermore, as the provider, Microsoft takes care of the authentication mechanisms to secure the login processes.
Microsoft takes care of updates and patches to the whole underlying Azure DevOps platform, including the infrastructure, operating systems, and the services that run Azure DevOps (pipelines, artifacts storage, etc.). There are also security patches for protection against any known vulnerabilities, such as potential security holes in the software itself. Updates also cover compliance for Azure DevOps to remain compliant with the industry standards. The platform updates happen automatically so it does not require user intervention.
Responsibilities of an Azure DevOps user
As we have mentioned, the customers are responsible for taking care of their data, endpoints, accounts, and access management. These elements which you take care of in terms of security can be directly improved by you. You can implement strict access controls, follow industry best practices, back up your data, and make sure you are ready for any disaster scenario.
Microsoft Shared Responsibility Model outlines “information and data”. It essentially means the protection and management of data that you own. Therefore, you are responsible for data encryption, access control, and classification of your data.
- Azure is responsible for encrypting data at rest but you must ensure that data in transit is also encrypted, implement your own encryption and properly manage your encryption keys.
- Make sure that only verified users have access to your data. Apply relevant frameworks like the Role-Based Access Controls (RBAC), and closely monitor, adjust the permissions. No excess permissions or access should be applied to any user.
- Evaluate what kinds of data you have. Then, label it, and you can group the data according to sensitivity levels.
“Devices” are physical or endpoint devices like desktops, laptops, or mobile devices that customers use to access the desired cloud services. You, as the customer, are responsible for securing these devices. Protect your endpoints, keep devices malware-free, and implement secure configurations like storage encryption.
“Microsoft may offer tools (e.g., Microsoft Defender for Endpoint) to help secure your devices, but the ultimate responsibility for securing access devices falls on the customer,” states Microsoft Shared Responsibility Model
Source: Microsoft documentation
Another responsibility that you as the user need to address is accounts and identities. You need to make sure that the authorization process is secure and that no threat can impact your data. It is advisable to:
- Implement Multi-Factor Authentication (MFA) (an extra step before to authenticate the user)
- Set up password policies and standards (change them monthly, minimum 16 characters etc.)
- Adhere to the principle of least privilege (users only get access to data required to finish their tasks)
- Take advantage of Microsoft Entra ID (unify your authorization processes)
- Use Personal Access Tokens (PATs) or SSH keys
When it comes to network controls, applications, identity, and directory infrastructure, the responsibilities are shared equally between the service provider and the user.
The provider must ensure that the identity infrastructure (Azure Active Directory) is up and running with proper maintenance, uptime, and secure processes for all services related to authentication. Yet, you as the user still have to set up effective authentication policies and implement user access controls, such as the aforementioned MFA, principle of the least privilege, and RBAC. The underlying infrastructure is secured by your provider but passwords, access management, and third-party apps that your organization uses are on you.
The main risk and cause of issues in cyber security is still the human element. Almost three-quarters (74%) of CISOs identify it as the most significant vulnerability. It’s crucial to adapt to the Shared Responsibility Model to avoid data loss, compliance violations, or operational disruptions.
Security breaches
Security breaches could be caused by misconfigurations in managing access controls, permissions, and credentials. Inefficient access policies or unprotected credentials can result in unauthorized access and stolen intellectual property, corrupted repositories, or even operational disruptions.
Keeping up with compliance
Compliance violations are another risk. While Microsoft takes care of the compliance for the platform, users are responsible for their data. This includes who has access to sensitive information and how it is used. Poor configurations result in failure to meet compliance requirements (e.g., GDPR, HIPAA) and can lead to fines and reputational damage.
To put it simply, the data on the platform is your responsibility. Therefore, wherever you can implement or improve its security – do it!
As we have already said, within the Shared Responsibility Model, a user is the one who is in charge of their account data protection. Backup is one of those measures that can help you ensure that your critical DevOps and project data can be accessible and recoverable in any event of failure. Moreover, Microsoft itself suggests that backup is a necessary measure:
“You can recover deleted organizations or projects within the 28-day window following deletion. But, once this time period elapses, these entities are permanently deleted and can’t be restored. While these backups serve as a crucial component for disaster recovery, it’s essential for customers to practice appropriate data management and backup strategies to ensure comprehensive protection of their data,” states Microsoft’s documentation.
Moreover, in the same documentation, Microsoft states that it isn’t able to restore data due to accidental deletion that was caused by a user, it can only restore its services in case of major service outages or disruptions:
“Accidental deletion here refers to scenarios that arise as a result of an incident on our services. It doesn’t include customers’ accidental deletion of assets (for example, repositories, work items, attachments, or artifacts)… We don’t support restoring assets that customers accidentally delete. These backups are meant only for business continuity and to aid recovery from outage or disaster scenarios,”
Source: Microsoft: Data protection overview
While personal solutions like snapshots, backup scripts, or cloning may seem like a good option, in the long term perspective they can lead to human errors due to constant updates and human intervention, incomplete backups, poor monitoring, compliance risks, and the actual cost of backup scripts… which can go up to thousands.
Alternative? Professional third-party backup solutions, like GitProtect backup and Disaster Recovery software for Azure DevOps. With the backup software, you can reduce your storage management burden by implementing both at-rest encryption and in-flight encryption when transferring data to external storage. Additionally, it enhances storage efficiency through security features like compression and deduplication.
Without dedicated backup software, restoring data becomes a challenging task. By integrating a third-party backup solution, users gain access to point-in-time recovery and disaster recovery options, with the flexibility to choose retention types such as GFS, FIFO, or forever incremental, depending on their needs.
Let’s face it – staying compliant with legal and industry requirements is a complex challenge for businesses. Moreover, the majority of security compliance protocols, including GDPR, ISO 27001, NIST, DORA, CRA, and others, require organizations to have a backup and Disaster Recovery. Thus, by implementing a backup solution you can meet compliance standards by ensuring encryption, data integrity, secure restoration, and disaster recovery capabilities. As a result, your customer responsibilities in securing your account data can be fulfilled.
When it comes to retention, imagine having the ability to retrieve code you wrote five years ago, even if it was removed from Azure DevOps. With the support of a third-party solution, this becomes achievable as you get unlimited retention. Moreover, you get the possibility to align your backup and DR strategy with backup best practices, including the choice of data residency, the 3-2-1 backup rule fulfillment and data replication, ransomware protection, Restore and DR capabilities, etc.
[FREE TRIAL] Ensure compliant Azure DevOps backup and recovery with a 14-day trial 🚀
[CUSTOM DEMO] Let’s talk about how backup & DR software for Azure DevOps can help you mitigate the risks
