Companies are increasingly adopting cloud-based software tools to empower their employees to work, collaborate, and access data remotely. However, cloud-based tools, such as Microsoft 365, come with new settings that must be securely maintained to prevent hacks. This article will cover:
COVID-19 accelerated the work-from-home trend. Organizations are quickly adopting modern digital workplaces where sensitive data are no longer stored in servers on premises, but rather in the cloud.
On-premises servers and virtual private networks (VPNs) have been replaced with cloud-based tools and platforms that connect users with the resources needed to get work done.
Along with the change, organizations face new security concerns from employees using business software outside the office. Before, you had to manage just one network secured by geography. Now, hundreds of settings must be maintained to control who can access the global network, from which devices, where, and how identities get authenticated.
Microsoft’s lineup of cloud-based collaboration, productivity, security, and mobile device management tools – collectively known as Microsoft 365 – is the leading productivity tool and continues to rapidly gain adoption.
Despite the increased adoption of Microsoft 365, managing settings for Microsoft 365 is difficult, resource-intensive, and error-prone. Engineers must manually point and click through thousands of properties in web-based administration portals to initially get their environments into the desired state and keep them in that state over time.
Cybersecurity models and compliance auditing place importance on establishing best-practice security settings and ensuring that they are applied correctly without drifting over time from the desired state.
There are three primary practices for managing your Microsoft 365 configurations, and it is important that you choose the best option for your organization to ensure compliance and avoid breaches:
Manually, engineers must configure 5,000+ settings click-by-click in the M365 administrative portals and, for those who are more organized, cross-reference against previous configurations or documentation (such as Excel spreadsheets).
The benefit of this method is that you can do what you already know, and it requires no change in your practices. The downside, however, is that it is incredibly time-consuming and error-prone, often leading to mistakes that leave organizations vulnerable.
If you’re a small MSP just getting your start with a couple of tenants, you can begin with manual configuration management. However, once your business is up and running, it's critical to start employing the next couple of methods to ensure your environments are configured correctly and consistently from the beginning. It’s always harder to play catch up, so it's important to do it right from the start.
With PowerShell, you can write imperative scripts to automatedly configure your Microsoft 365 environment settings.
While PowerShell eliminates the time-consuming and error-prone nature of manual configuration, its approach limits its effectiveness for configuration management.
The other issue with PowerShell is the maintenance challenge. If you write your own PowerShell scripts to automate the configuration of your Microsoft 365 tenants, you will have to spend time maintaining those PowerShell scripts: updating them when Microsoft makes (breaking) changes and when you want to change your script.
Maintaining PowerShell scripts can be extremely time-consuming and expensive. If you’re a larger firm with resources dedicated to writing and maintaining your PowerShell scripts, this is a great starting place. Whereas if you are a smaller firm with limited resources, you may want to consider a third-party Microsoft 365 configuration solution that provides some automation via PowerShell scripts such as SkyKick Cloud Manager.
Imperative models, such as PowerShell scripts, deploy settings unidirectionally, which automates the initial set up of your Microsoft 365 configurations. However, because it is one-directional, PowerShell scripts do not provide automation for maintaining existing settings – for ensuring that your settings remain in the desired state over time.
Without writing complex conditional logic, you cannot use the same script to reset an existing environment to align with its desired state. Additionally, if changes are made to settings in the portal, you cannot easily regenerate your PowerShell scripts to incorporate these changes. Your development time is focused on telling the system how to fix itself.
Configuration as Code is the practice of describing, provisioning, and managing settings with code. It’s a declarative model, allowing you to “declare” the desired state for your environment.
Your development time is focused on describing the desired state, and then you let the Configuration as Code platform focus on applying it. The platform understands how to compare the current state of your environment to the desired state and automatically calculate and deploy the corrective actions to re-align the settings.
DevOps rose to prominence about 15-20 years ago following concerns that the current software development model had flaws. It separated development teams (Devs) that wrote code from operations teams (Ops) that deployed code.
The DevOps approach merged the two disciplines, resulting in rapid code delivery via automation and collaboration. With the DevOps model, companies could more effectively test changes to code and push out updates, resulting in faster delivery times and product improvement.
Configuration as Code applies the DevOps approach to configuration management. Inherent to the process, you get ongoing drift detection, backup and restore, and lifecycle management controls.
Organizations that manage multiple tenants can use these practices keep their environments in sync. A gold standard for settings can be established, and the practice helps keep it that way. You can stress-test new settings in a dev environment and use automation to promote the new setting to production.
However, the Configuration as Code model is not without its flaws. Building and maintaining a solution requires niche development talent, team resources, and ongoing maintenance. This is a significant cost.
Yet, a staggering 99% of cloud data breaches result from human misconfigurations. So, for M365 customers and MSPs trying to deploy configurations well, the possibility of misconfiguring a critical policy or setting looms large. This can't be ignored.
For organizations not interested in building their own solution, there’s CoreView Configuration Manager for Microsoft 365. With our Configuration as Code solution, you can build enterprise-grade resilience into your Microsoft 365 tenant configurations.
See how CoreView Configuration as Code can automate configurations and oversight, relieving admins from painful manual work and preventing deadly misconfigurations.
