Securing Sitecore in the Public Cloud

One of the major apprehensions for most businesses when moving Sitecore into the cloud is the concept of the public cloud.

The underlying premise of the public cloud is essentially that the security of those assets is down to you to do and manage. These applications are not natively inside a protected environment that you have 100% control of. You're relying on services and applications that are hosted in a shared data centre and typically accessed via an API or a productised set of services.

This perceived lack of control creates an apprehension about moving to the public cloud and whether your Sitecore solution can truly be secure. The fundamentals of security can be broken down into three areas; people, process, and technology.

People and the public Cloud

From a people perspective, security is often around the least permissions model. It’s about making sure that the right people in your business and your partner businesses have access and control to the assets that they need to be successful. That can be down to sharing things like SQL server passwords, all the way up to knowing where the login endpoints are for certain applications.

The people aspect is probably the highest risk, because the nature of people is that we do make mistakes, and in some certain cases, we also do the wrong things. To avoid people making mistakes, that's relatively clear. That's about control, and that leads into process.

Managing people who do the wrong thing is, of course, harder to do - but that also comes down to discipline, expectations, process and technology. But the security precautions around people goes a little bit further because it also includes things such as:

• Access to laptops and servers
• Locks on the doors in the offices of partners and employees
• Password manager that is protected using multi-factor authentication
• Administrators in your partner businesses
• Named access or named controls in your contractual agreements

So, the definition of security, from a people perspective, goes quite broad. Some organisations may go for certain qualifications, such as ISO or SOC compliance, but it fundamentally comes down to mapping out what your exposure and risk is, and then setting expectations within your business.

Trying to mitigate that problem with technology alone does not work. You need to have open and human conversations with the people responsible for your infrastructure, including your employees and your developers and your marketers, about what it means to work with inside your MarTech - where there is potentially identifiable information.

Process and the Public Cloud

The process aspect comes down to how you operate the marketing technology from a security perspective. Do you have a requirement in your business to continuously extract reports with identifiable data from the MarTech to supply to a compliance organisation? If you do, that naturally infers that somebody needs access to raw data in a database format. Is that database going to be accessed using SQL Server Management Studio on a local machine or is it going to be accessed via a productised interface?

Whatever the decision may be, documenting and defining those processes, and making sure that they are aligned to the business requirements, is critical. If anybody in the business demands a report for a given date, time, or certain requirement, it's important to go back to a process mechanism and to understand why that person needs that data. Typically what we find is that in many of those heated situations, the data isn't really required immediately. It's usually down to the lack of planning.

When putting in processes around how you provision new infrastructure, you should be thinking about a number of things;

• Who is allowed to provision new infrastructure?
• What the process for doing that?
• Is there a cost mechanism for reporting those processes?

It extends through everywhere. All the different areas of your MarTech infrastructure do require process. Many of those processes have already been written and defined. This is not necessarily a new process for managing infrastructure, it just happens to be in the cloud and so has a different slant on it.

Technology and the Public Cloud

From a technical perspective, there is myriad things you have to worry about. Things like usernames and passwords, key chains, vaults, certificates, service principles, or deployment techniques are just the tip of the iceberg. One of the fundamental ways of securing your infrastructure is by taking an infrastructure-as-code-based approach, removing people away from the cloud-based user interfaces to stop ad hoc changes being made in those infrastructures.

Taking an infrastructure-as-code approach yields a couple of benefits.

1. You can predictably write code that creates, defines, and modifies infrastructure. Therefore, it becomes tested, versioned and source controlled. You can execute those scripts inside a controlled environment that might be a user or service principle that has only dedicated access to UAT with another elevated user or co-user who can take that to production.
2. It adds a layer of friction to the deployment and change process, which is a typical trait of the cloud.

We have seen that a lot of people went really fast in the cloud - doing stuff on the fly, burning lots of money and making lots of poor decisions from a security perspective. But, by introducing that infrastructure-as-code approach, you essentially bring a level of thinking that hasn't typically been provided.

When it comes to actually securing assets, the resources that you create from using infrastructure as code can harden and secure your applications quite quickly. These include:

• Enabling advanced threat protection
• Transparent data encryption
• Service principal-driven access
• Role-based access control across the Azure tenancy
• Limiting admins inside the system
• Using the fundamentals of the Azure DevSecOps security toolkit

We've taken an approach to extending Sitecore's secure by default, where every part of the Sitecore infrastructure that we deploy is hardened in the public cloud, does have long, complex, obfuscated passwords, and does employ all of the latest techniques of securing Sitecore in the public cloud, including integrating the Sitecore login with Azure Active Directory where possible.

Marketing technology leaders in the business are now becoming the guardian of the data that you hold from these customer experiences and so taking a security-driven approach is paramount. Whilst your opportunity is to help decentralise and democratise that data across the rest of the business, you also carry the risk of security and exposure.

Working with providers who can help you secure from day one is imperative. Don't treat security as an afterthought, because once you get security right, you can truly increase the customer experience.

If you don’t have the people, process or technology in place to properly secure your Sitecore, book a 90-minute meeting below and we can get started on securing your environment in the right way.