Cloud Shared Responsibility Mapper
Storage ยท service category

Object storage: who owns each control

Buckets of objects reached over an API; the most common place for data to be left open to the internet. Delivered as infrastructure as a service unless your line says otherwise.

Places a line such as Object storage buckets holding customer files. Map this line.

The split, area by area

Control areaOwnerWhy, and the clause
GOV Governance and policysharedEach party governs its own side: the provider the service it delivers, you which data and services you allow and who may procure them. The allocation between you has to be written down. ISO/IEC 27017 6.1.1
IAM Identity and accessyoursThe accounts, roles and second factors inside your tenancy are yours to grant, review and remove; the provider secures only its own staff's privileged access. ISO/IEC 27017 9.2.3
DAT Data classification and handlingyoursWhat the data is, how it is labelled and where it may go is yours on every model; the provider only tells you what labelling and location options the service offers. ISO/IEC 27017 8.2.2
KEY Encryption and keysyoursOn infrastructure you choose whether volumes and objects are encrypted and who holds the keys; the provider supplies the key service, not the decision. ISO/IEC 27017 10.1.2
NET Network securitysharedThe provider runs the storage network; whether a bucket can be reached from the internet, and from where, is a setting that is yours. ISO/IEC 27017 CLD.9.5.1
LOG Logging and monitoringyoursLogs from the operating system, your applications and your account activity are yours to switch on, keep and watch; the provider logs its own layers. ISO/IEC 27017 CLD.12.4.5
VUL Vulnerability and patch managementyoursYou patch the guest operating system, the software on it and your images; the provider patches the hypervisor and the hardware. ISO/IEC 27017 12.6.1
CFG Configuration and hardeningyoursThe image, the services enabled and every setting from the guest up are yours to harden and hold to a baseline. ISO/IEC 27017 CLD.9.5.2
APP Application securityyoursThe code you deploy is yours to build and test securely; the provider has no view of it. ISO/IEC 27017 14.2.1
INC Incident responsesharedBoth sides respond: the provider must report incidents affecting your data within the agreed time, and you must detect and handle incidents in what you run and report to the provider what affects its service. ISO/IEC 27017 16.1.2
BCP Business continuity and backupyoursBackups of your machines and volumes are yours to schedule, protect and test a restore of; the provider keeps the hardware redundant, not your data. ISO/IEC 27017 12.3.1
PHY Physical and environmentalthe provider'sThe data centres, power, cooling, access to the floor and the disposal of retired media are the provider's; your evidence is its assurance report, not your own inspection. ISO/IEC 27017 11.2.7
SUP Supplier and subservicesharedThe provider must publish its side of the model and the suppliers behind the service; you must hold the matrix for your estate, read the provider's side and keep the agreement that binds both. ISO/IEC 27017 CLD.6.3.1
AIR AI use and data retentionyoursWhat data goes into the service, for what purpose and how long it is kept is yours to decide and delete; the provider stores what you give it. ISO/IEC 27017 CLD.8.1.5

This category moves the line on network security whatever the model: The provider runs the storage network; whether a bucket can be reached from the internet, and from where, is a setting that is yours.

The clauses behind the split, quoted

The split is ours, drawn from the model and these clauses; it does not reproduce any provider's own matrix. Check it against your provider's shared responsibility documentation (named, not quoted) before you hand it to an assessor.

ISO/IEC 27017 6.1.1 Information security roles and responsibilities

Roles and responsibilities for the security of each cloud service should be allocated between the cloud service customer and the cloud service provider and inside each organisation. The customer should assign who owns the relationship, who manages customer-side controls and who evaluates the provider's information; the provider should state which responsibilities it accepts and which remain with the customer for each service it offers, so that no control falls between the two.

What an assessor asks to see:
  • Responsibility matrix per cloud service naming customer and provider owners
  • Provider service description or terms stating accepted responsibilities
  • Internal role assignments for cloud relationship and control ownership
Where it usually falls short:
  • A control both parties assume the other performs, typically backup, logging or key management
  • Responsibility matrix drafted at onboarding and never updated for new service features
Source: ISO/IEC 27017:2015
ISO/IEC 27017 9.2.3 Management of privileged access rights

Privileged access in a cloud service sits on both sides. The customer should control the privileged rights it holds over its tenancy, using strong authentication and keeping the number of privileged users small, and the provider should control privileged access of its own staff to the cloud service and to customer environments, with the assurance the customer asks for. The provider should offer sufficient authentication techniques for the customer's privileged accounts.

What an assessor asks to see:
  • List of privileged cloud accounts on the customer side with approvals
  • Provider description of privileged access controls for its staff
  • Evidence of multi-factor authentication on privileged cloud accounts
Where it usually falls short:
  • Provider root or console credentials shared between customer staff
  • No statement from the provider on how its administrators reach customer environments
Source: ISO/IEC 27017:2015
ISO/IEC 27017 8.2.2 Labelling of information

The customer should label information according to its classification before and while it is in a cloud service, using labelling the service can carry, and the provider should describe what labelling capability the service offers and whether labels survive processing. Both should agree how labels are handled where the provider's staff can see customer information.

What an assessor asks to see:
  • Labelling scheme applied to cloud-hosted information
  • Provider documentation of labelling features
  • Test that labels persist through the service
Where it usually falls short:
  • Labels stripped when information is uploaded to a service that cannot carry them
  • No labelling rule for information created inside the cloud service
Source: ISO/IEC 27017:2015
ISO/IEC 27017 10.1.2 Key management

Cryptographic keys used by the service should be explained to the customer: the provider should give information about the keys the service uses and the key management options available, including whether the customer may manage its own keys and how keys are protected and destroyed. The customer should decide who manages the keys for its cloud-hosted information and should keep management of keys it controls under its own key management policy.

What an assessor asks to see:
  • Key management arrangement per cloud service stating who holds keys
  • Provider documentation of key protection, rotation and destruction
  • Customer key management records for customer-managed keys
Where it usually falls short:
  • Keys held by the provider with no statement of who can access them
  • Customer-managed keys lost, making cloud-hosted data unrecoverable
Source: ISO/IEC 27017:2015
ISO/IEC 27017 CLD.9.5.1 Segregation in virtual computing environments

A customer's virtual environment running on a cloud service is to be protected from other customers of the service and from unauthorised persons. The provider should enforce logical segregation between tenants across compute, storage and network, should segregate its own management environment from customer environments, and should describe the segregation to customers; the customer relies on that segregation and should verify the description before placing sensitive information in the service.

What an assessor asks to see:
  • Provider description of tenant segregation across compute, storage and network
  • Independent assurance covering tenant isolation
  • Customer review of the segregation before onboarding
Where it usually falls short:
  • Isolation claimed at the hypervisor with shared storage that is not segregated
  • Provider management plane reachable from a customer network
Source: ISO/IEC 27017:2015
ISO/IEC 27017 CLD.12.4.5 Monitoring of cloud services

The cloud service customer is to have the capability to monitor specified aspects of the operation of the cloud services it uses. The provider should give customers the means to monitor the aspects relevant to their security, such as service availability, security events and the use of their resources, and should describe those capabilities; the customer should decide which aspects it needs to monitor and should use the capabilities provided, supplementing them where the provider's monitoring is not enough.

What an assessor asks to see:
  • Provider description of monitoring capabilities offered to customers
  • Customer monitoring configuration for the cloud service
  • Evidence the monitoring output is reviewed and acted on
Where it usually falls short:
  • Monitoring capability offered but never enabled by the customer
  • Customer security monitoring that stops at its own network edge
Source: ISO/IEC 27017:2015
ISO/IEC 27017 12.6.1 Management of technical vulnerabilities

Technical vulnerabilities in a cloud service are divided between what the provider patches and what the customer patches, and the provider should give the customer information about how it manages vulnerabilities affecting the cloud service, including the parts the provider patches and the parts the customer must patch itself, and the notification it gives. The customer should manage vulnerabilities in the components it controls (its virtual machines, applications and configuration) and should track the provider's handling of the rest.

What an assessor asks to see:
  • Provider vulnerability management statement and notification channel
  • Customer vulnerability process covering cloud-hosted components it controls
  • Patch records for customer-managed cloud assets
Where it usually falls short:
  • Customer assumes the provider patches guest operating systems it actually leaves to the customer
  • No provider channel for vulnerability notification the customer monitors
Source: ISO/IEC 27017:2015
ISO/IEC 27017 CLD.9.5.2 Virtual machine hardening

Virtual machines in a cloud computing environment are to be hardened to meet business needs. Whichever party configures a virtual machine should apply hardening: only needed ports, protocols and services enabled, unnecessary components removed, and technical controls such as anti-malware and logging appropriate to the workload; the customer hardens the machines it controls and the provider those it operates, including the images it offers to customers.

What an assessor asks to see:
  • Hardening standard for cloud virtual machines
  • Configuration evidence or scan results for a sample of machines
  • Provider statement on hardening of provided images
Where it usually falls short:
  • Provider default images deployed unchanged with all services enabled
  • Customer hardening standard written for physical servers and never applied to cloud images
Source: ISO/IEC 27017:2015
ISO/IEC 27017 14.2.1 Secure development policy

Where the customer develops applications on a cloud service, its secure development policy should address the cloud environment, including the provider's development tools and interfaces and the security of code and data in shared development resources. The provider should give customers information about the secure development practices and the interfaces it makes available.

What an assessor asks to see:
  • Customer secure development policy with a cloud section
  • Provider documentation of development interfaces and practices
  • Review of cloud-hosted development environments against the policy
Where it usually falls short:
  • Production credentials used in a cloud development environment
  • Customer developers using provider tooling with no security guidance
Source: ISO/IEC 27017:2015
ISO/IEC 27017 16.1.2 Reporting information security events

The provider should give the customer a mechanism to report information security events it observes in the cloud service, and should report to the customer events and incidents affecting the customer's information within the agreed time. The customer should report to the provider events it detects that may affect the service, and should tell its own users how to report events involving cloud services.

What an assessor asks to see:
  • Provider reporting channel and notification commitment
  • Customer procedure for reporting events to the provider
  • Records of events reported in each direction
Where it usually falls short:
  • Incident notification obligation in the contract with no working contact behind it
  • Customer users unaware that cloud service events should be reported
Source: ISO/IEC 27017:2015
ISO/IEC 27017 12.3.1 Information backup

The provider should specify the backup capabilities it offers, including scope, frequency, retention, protection of the backups and how the customer may restore, and should state what it does not back up. The customer should decide which of its cloud-hosted information needs backup, whether to rely on the provider's backups or keep its own, and should test that restoration works.

What an assessor asks to see:
  • Provider backup specification for the service
  • Customer backup decision and arrangements per cloud service
  • Restore test records
Where it usually falls short:
  • Customer assumes the provider backs up its data when the service only replicates it
  • Backups held only inside the same cloud account they protect
Source: ISO/IEC 27017:2015
ISO/IEC 27017 11.2.7 Secure disposal or re-use of equipment

The provider should arrange for secure disposal or re-use of equipment that has held customer information, so that customer data cannot be recovered from storage that is retired or reassigned to another tenant, and should tell customers about the arrangement. The customer should confirm that the provider's disposal practice meets its requirements for the information it places in the service.

What an assessor asks to see:
  • Provider media sanitisation and disposal procedure
  • Disposal or destruction records
  • Customer review of the provider's disposal statement
Where it usually falls short:
  • Storage reassigned between tenants without sanitisation
  • Customer requirement for certified destruction not passed to the provider
Source: ISO/IEC 27017:2015
ISO/IEC 27017 CLD.6.3.1 Shared roles and responsibilities within a cloud computing environment

Responsibilities for information security in the use of a cloud service are shared, and the standard requires that they be allocated to identified parties, documented, communicated and implemented by both the cloud service customer and the cloud service provider. The provider should document and publish the responsibilities it takes on and those it leaves with the customer; the customer should record the allocation, assign owners inside its organisation, and act on its share.

What an assessor asks to see:
  • Shared responsibility document for each cloud service, agreed by both parties
  • Communication of the allocation to the customer's users and the provider's staff
  • Evidence the customer performs its allocated responsibilities
Where it usually falls short:
  • A published provider responsibility model that the customer never mapped to its own roles
  • Allocation that names organisations but no individuals
Source: ISO/IEC 27017:2015
ISO/IEC 27017 CLD.8.1.5 Removal of cloud service customer assets

Assets of the cloud service customer that are on the cloud service provider's premises are to be removed, and returned where necessary, in a timely manner when the cloud service agreement ends. The provider should describe how customer assets are returned and deleted at termination, in what form and within what time; the customer should plan for termination from the start, including retrieval of its data in a usable format and confirmation of deletion.

What an assessor asks to see:
  • Provider termination and data return procedure with timescales
  • Customer exit plan for the cloud service
  • Confirmation of deletion after termination
Where it usually falls short:
  • Data return window shorter than the customer's migration takes
  • Provider deletes customer data with no confirmation, or keeps it in backups indefinitely
Source: ISO/IEC 27017:2015

Other services in storage