The main security obstacle in cloud software development is a misunderstanding about who is responsible for what. The provider secures its data centres and the platform it sells. You, and the developers working for you, remain responsible for how that platform is configured, who can sign in to it and what happens to the data. The providers call this the shared responsibility model, and most of the practical precautions follow from it.
Why developing in the cloud changes the risks
Building and running software in the cloud is now the ordinary way to do it. Source code is kept in a hosted service, new versions are built and released by automated tools, and a test environment can be created in minutes and deleted when it is no longer needed. Those are real advantages over a single server in the office.
The risks move with them. An office server was protected, however imperfectly, by a locked door and a firewall. A cloud environment is protected by accounts and settings. Its management console can be reached from anywhere in the world, so one stolen administrator password or one careless setting can expose everything.
The shared responsibility model in the providers’ own words
Amazon Web Services describes itself as responsible for “security of the cloud”, meaning the infrastructure that runs its services, and the customer as responsible for “security in the cloud”. For a virtual server, AWS says the customer manages “the guest operating system (including updates and security patches)”, the software installed on it and the firewall settings.
Microsoft puts it this way for Azure: “For all cloud deployment types, you own your data and identities.” It lists data, devices, accounts and access management as responsibilities the customer always keeps.
How much else you keep depends on the kind of service. The table is a simplified version of Microsoft’s published matrix.
| Area | Your own server | Virtual server in the cloud | Managed platform service |
|---|---|---|---|
| Building, hardware and physical network | You | Provider | Provider |
| Operating system updates | You | You | Provider |
| Network and firewall rules | You | You | Shared |
| Application code and its settings | You | You | Shared |
| User accounts and access | You | You | You |
| Data | You | You | You |
The second column deserves attention. Moving an application unchanged onto a virtual server hands over the hardware and nothing else. An out-of-date operating system is still out of date, and end-of-support dates apply exactly as they did in the office.
The National Cyber Security Centre (NCSC) draws the same conclusion in its guidance on shared responsibility. It advises organisations to “delegate as much responsibility for security to your hyperscale cloud platform as you can”, which in practice means preferring managed services to virtual servers. It also says that you will always be responsible for three things: making sure the service can meet your security needs, configuring it securely, and deciding which data you put in it. Our article on cloud native architecture describes how an existing system can move towards managed services in stages.
The obstacles that come up during development
Too many people with too much access. Developers are often given full administrator rights because it is quicker than working out what they need. The NCSC’s guidance on using a cloud platform says access “should require strong authentication” and that access controls should be granular, so that people and programs can reach only what they need. In practice that means a named account for each person, a second factor at sign-in for all of them, and separate live and test environments with different permissions.
Passwords and keys in the wrong place. An application needs credentials to reach its database and other services. If they are written into the source code or a settings file, they end up on every developer’s laptop and in every copy of the code. Both large providers supply a secrets store that hands credentials to the application when it runs. Use it, and change the credentials when someone who knew them leaves.
Real data in test environments. Copying the live database is the easiest way to get realistic test data. The copy is usually less well protected than the original and soon forgotten. If it contains personal data, the law applies to it just as it does to the live system. Use anonymised data where you can, protect test copies to the same standard where you cannot, and delete them when the work is finished.
Things opened to the internet by accident. Typical examples are a storage folder made public to share one file, a database port opened so that a developer can connect from home, and remote desktop left open to the world. The NCSC recommends putting security policies and a secure starting configuration in place “before you start building anything”, so that new resources are locked down by default.
The release pipeline holds the keys. The automated tools that build and release software need permission to change the live system. Whoever can alter those tools can alter what is released. Protect them as carefully as the live environment.
Nobody is watching. Cloud platforms can record who did what, but someone has to switch that on, keep the records and read the alerts. The NCSC also advises including your cloud platform in your incident response planning. In plain terms, decide in advance who is called when something goes wrong, and test that a backup can be restored.
For an internet-facing system holding sensitive data, an independent penetration test by a specialist firm is worth commissioning. It is not a service we offer ourselves.
What UK data protection law adds
If the system holds personal data, your organisation is normally the controller and the cloud provider is a processor, as is a software company that can see the data while supporting the system. Guidance from the Information Commissioner’s Office (ICO) says that a controller must only use a processor that can provide “sufficient guarantees” about its handling of the data, that a written contract is needed, and that the controller’s responsibilities continue after the contract is signed.
Two further points matter for cloud systems.
- Where the data is. The ICO’s guidance on international transfers says that if you contract with a cloud provider based outside the UK, it is “very likely” that you are making a restricted transfer, which brings extra rules. Find out which region your data is stored in and what the provider’s terms say about access from other countries.
- Breaches. A breach that is likely to put people at risk must be reported to the ICO within 72 hours of your becoming aware of it. A processor has to tell you without undue delay, so make sure your suppliers know whom to contact.
The ICO marks several of these pages as under review following the Data (Use and Access) Act, so check the current wording. None of this is legal advice. If the system holds sensitive records, take advice on your own position.
Questions to ask whoever builds or runs your system
- Whose name is the cloud account in, and who holds the top-level administrator sign-in? It should be your organisation, even if the developer who set it up has left.
- Who has access to the live environment, by name, and does every one of them sign in with a second factor?
- Where are the application’s passwords and keys kept, and when were they last changed?
- Is live data used for testing, and where are the copies?
- Who applies operating system and database updates, and how soon after they are released?
- What is recorded, who receives the alerts, and when was a restore last tested?
- Which region is the data stored in?
A supplier who looks after the system under a maintenance agreement should be able to answer all seven without hesitation. If you are about to move a system, settle them as part of the cloud migration plan and not afterwards.