Cloud Security, Identity and Access Basics

Security is the part of cloud computing that people worry about most and explain least. It often gets reduced to a vague reassurance that the provider “handles security”, which is true in some areas and dangerously misleading in others.

The reality is more useful than that, and not much harder to understand. Security in the cloud is shared. Some responsibilities belong to the provider, some belong to you, and the boundary between them changes depending on the type of service you use.

We touched on this idea earlier in the series when we looked at service models, but we did not stop to explain it properly. Let us do that now.

Security is a shared job

When you run everything yourself in your own building, the security of the whole system is yours. You are responsible for the locks on the doors, the physical equipment, the network, the operating systems, the applications, the accounts and the data.

There is nobody else to point at.

The moment you start using a cloud provider, that changes. The provider takes responsibility for part of the system, while you remain responsible for the parts you control.

This is usually called the shared responsibility model.

The boundary broadly follows the service models we covered earlier. As you move from running your own infrastructure towards using finished software, more of the technical platform is managed and secured by the provider.

The reason is simple: you can only manage the parts you are allowed to control.

Here is a simplified view of who mainly manages each layer:

Step What happens Question answered
Authentication The system verifies the identity making the request. Who are you?
Authorisation The system checks whether that identity has permission to perform the requested action. Are you allowed to do this?
Resource access The request is allowed to continue only if both checks succeed. Can the request reach the resource?

On-premises, every layer is yours because there is no cloud provider involved.

With Infrastructure as a Service, or IaaS, the provider manages the physical data centres, servers, storage hardware and underlying network. You still manage the operating system, the software you install, the application and its data.

For example, you may need to:

With Platform as a Service, or PaaS, the provider also manages the operating system and runtime. You mainly focus on your application code, its configuration, its users and its data.

For example, you may need to:

With Software as a Service, or SaaS, the provider runs the application as well as the platform underneath it. Your remaining responsibilities are smaller, but they are still important.

For example, you may need to:

Some responsibilities therefore remain with you in every model, especially deciding what data you store, who can access it and how the service is configured.

The exact settings differ between services, but the general pattern stays the same. The provider can secure the parts they operate, while you remain responsible for the choices and configurations placed in your hands.

The provider may protect the systems that store and process your data, but they cannot decide the business rules that govern it.

A provider can run a secure platform while a customer accidentally exposes information through poor access settings. That does not mean the provider’s security failed. It means the customer-controlled part of the shared model was configured insecurely.

The useful question to ask about a cloud service is therefore not simply:

Is this service secure?

A better question is:

Which parts of this service am I responsible for securing?

Why identity becomes so important in the cloud

For a long time, security relied heavily on location.

Someone inside the office network was often trusted more than someone connecting from outside it. A firewall at the edge of the network acted like a wall around the building. Where a connection came from helped determine what it could reach.

That boundary is less reliable in the cloud.

Staff may work from home, from cafés or from their phones. Applications may be spread across several networks and cloud services. Systems may need to communicate even though they are not sitting inside the same office building.

Location still matters, but it is no longer enough on its own.

The system also needs to know who is making a request and what that person or system should be allowed to do.

This is where identity becomes important.

An identity is a verified answer to the question:

Who are you?

The identity might belong to a person, such as an employee or customer. It might also belong to an application, automated process or cloud service acting on its own.

Once identity becomes something the system trusts, it also becomes something that must be protected.

An attacker who steals a valid identity may not need to break through a network boundary. They can attempt to sign in and act as though they are the legitimate user.

This is why people sometimes say that identity is the new perimeter.

The phrase does not mean that networks, firewalls and devices no longer matter. It means that identity has become one of the main boundaries used to control access.

The front door is no longer only a physical place. It may also be a sign-in screen, an account or a digital credential.

Proving who you are and deciding what you can do

Two words are often used almost interchangeably in security discussions, even though they answer different questions:

Authentication is the process of proving who you are.

It happens when you sign in and the system checks whether you really are the person or system you claim to be. This might involve a password, a security key, a passkey, a code from an authenticator app or another form of proof.

Authorisation happens after authentication.

Once the system knows which identity is making the request, it checks what that identity is allowed to do.

For example, an authenticated user might be allowed to:

The building analogy works well here.

Authentication is showing your staff pass at the front desk and proving that the pass belongs to you.

Authorisation is deciding which doors that pass opens once you are inside.

Being recognised as a real employee does not mean you should be able to enter the server room, the finance office or every other restricted area.

In the same way, successfully signing in does not mean an account should be allowed to do everything.

graph LR A[Identity makes a request] --> B[Authentication<br/>Who are you?] B --> C[Authorisation<br/>Are you allowed?] C --> D[Protected resource] %% cc-caption: The system first verifies the identity making the request, then checks whether that identity is allowed to access the protected resource.

For a protected resource, the system normally performs both checks.

It first establishes which identity is making the request. It then checks whether that identity is allowed to perform the requested action.

If either check fails, access is denied.

Many serious security mistakes happen on the authorisation side. The login works correctly, but the account is allowed to do far more than it should.

Giving people only the access they need

One common way to manage permissions is role-based access control, usually shortened to RBAC.

Instead of granting permissions to every person individually, you define roles.

A role is a collection of permissions designed for a particular job or responsibility.

For example, an organisation might create roles such as:

A member of the support team can be assigned the support role and receive the permissions needed for that job. If they move to another team, the old role can be removed and a different one assigned.

This is easier to manage than configuring every person separately. It also reduces the chance of old permissions being forgotten when someone changes jobs.

Roles can also be assigned to systems and applications.

For example, a backend application might be given permission to read from one database but not to delete it. An automated reporting process might be allowed to read billing information but not change any account settings.

Underneath this is an important security principle called least privilege.

Least privilege means that every person and every system should receive only the access genuinely required to perform its task.

Not access that might be useful one day.

Not administrator access because it is quicker than working out the correct permissions.

Only the permissions that are actually needed.

It can be tempting to grant broad access because tight permissions sometimes create friction and support requests. However, every additional permission creates another action that could be performed accidentally or by someone who has compromised the account.

Least privilege does not assume that your employees are untrustworthy.

It assumes that mistakes happen, accounts are compromised and software sometimes behaves in unexpected ways. Restricting permissions limits how much damage any one identity can cause.

One more lock on the front door

Passwords alone are not a particularly strong way to protect an identity.

People reuse them, choose weak ones and sometimes enter them into convincing phishing pages. Passwords can also be exposed through data breaches, malware or accidental sharing.

If a password is the only protection on an account, a stolen password may be enough for an attacker to sign in.

Multi-factor authentication, usually shortened to MFA, asks for more than one kind of proof.

The factors normally come from different categories:

A common example combines a password with a temporary code from an authenticator app.

Someone who steals the password would still need the second factor before they could sign in.

MFA does not prevent every type of account attack, but it makes a stolen password much less useful because the password alone is no longer enough.

Some forms of MFA are stronger than others. Temporary codes can still be captured by convincing phishing pages. Physical security keys and passkeys are designed to be much more resistant to this kind of attack.

Even so, enabling any well-designed MFA is usually a major improvement over relying on a password alone.

The key takeaway

Security in the cloud is not something the provider simply does for you. It is a responsibility you share with them.

The boundary between your responsibilities and the provider’s responsibilities changes depending on whether you are using IaaS, PaaS or SaaS.

The further you move towards finished software, the more of the underlying platform the provider manages. However, important responsibilities still remain with you, particularly around your data, identities, permissions and configuration.

With lower-level services such as IaaS, your responsibilities also include areas such as operating-system security, application security and network controls.

Identity has become especially important because users and systems no longer operate from one clearly defined physical location.

Authentication establishes who is making a request.

Authorisation decides what that identity is allowed to do.

Roles make permissions easier to manage as an organisation grows.

Least privilege limits each identity to the access it genuinely needs.

MFA makes stolen passwords less useful by requiring another form of proof.

Every cloud provider has services for managing these areas, although the names and details differ.

We will look at those products when we reach the separate series for each provider. For now, the concepts matter more than the product names because the underlying ideas are the same wherever you go.

Understand which responsibilities belong to you, treat identity as one of your most important security boundaries and give every person and system only the access they need.

That is the foundation of thinking about cloud security clearly.