Cloud security: shared responsibility and practical controls

Cloud security is the work of protecting cloud-hosted data, applications, identities, and infrastructure while keeping services available and recoverable. The difficult part is not finding a longer list of tools. It is deciding who owns each risk, which controls apply to the workload, and what evidence shows that those controls work.

This guide gives organizations a practical way to make those decisions. It covers shared responsibility, identity, configuration, data protection, monitoring, recovery, compliance, and provider evaluation. It also explains where Hivenet products fit without assuming that every cloud service uses the same architecture or responsibility model.

What cloud security covers

A useful cloud security plan starts with three familiar goals:

• Confidentiality: data and systems are accessible only to authorized identities.
• Integrity: unauthorized or accidental changes can be prevented, detected, and corrected.
• Availability: authorized users can reach the service and recover the data when they need it.

Those goals depend on more than encryption. Identity and access management, secure configuration, workload isolation, software maintenance, logging, incident response, backup, recovery, and governance all contribute. The mix changes with the service, the data, and the threats.

Security, privacy, resilience, and compliance are related, but they are not interchangeable. Security manages unauthorized access, change, disruption, and loss. Privacy governs how personal data is collected, used, shared, retained, and deleted. Resilience concerns continuity and recovery. Compliance concerns specific legal, contractual, or policy requirements. For a closer comparison, read security vs. privacy in the cloud.

Shared responsibility changes by service model

Cloud security is a shared responsibility, but there is no single boundary that applies to every product. NIST cloud guidance explains that customers generally take on more operational responsibility as they gain more control over the environment.

Managed software

With software as a service, the provider usually operates the application, platform, and infrastructure. The customer still chooses what data to place in the service, who can access it, how accounts and sharing are configured, and how the service fits legal and recovery requirements.

Managed platforms and APIs

With a managed platform or API, the provider operates more of the runtime or serving layer. The customer remains responsible for application logic, credentials, data handling, integrations, authorization decisions, and safe use of the endpoint.

Virtual machines and containers

With infrastructure services, the provider protects the underlying facilities, hardware, and service boundary described in its documentation. The customer commonly controls the operating system or image, installed software, network exposure, identities, secrets, patches, application security, logs, and recovery process.

Storage services

A storage provider operates the storage service and its documented durability and access mechanisms. The customer still decides what to store, how identities and permissions are configured, whether an independent backup is required, how encryption keys are controlled, and how deletion and export will work. For storage-specific checks, see our secure cloud storage practices.

Write this boundary down for every service. A responsibility matrix should name the owner, the control, the evidence, and the response when the control fails. Recheck it whenever the architecture, plan, region, or provider terms change.

Start with the workload, data, and threat model

Controls are useful only when they address a real risk. Before choosing a platform or copying a reference architecture, document the workload and the data it handles.

• What data is stored, processed, transmitted, logged, or backed up?
• Which data is sensitive, personal, regulated, contractual, or difficult to replace?
• Which people, devices, applications, service accounts, and third parties need access?
• Which interfaces must be public, and which can remain private?
• Which regions, transfers, subprocessors, and dependencies are involved?
• What could cause unauthorized disclosure, privilege abuse, tampering, deletion, ransomware, or service disruption?
• How much downtime and data loss can the organization tolerate?

Turn the answers into a threat model: the assets to protect, plausible attackers and failure paths, expected impact, current controls, gaps, and accepted residual risk. A public demo, an internal analytics job, a customer database, and a production AI endpoint should not inherit the same control set by default.

Identity, access, and secrets

Compromised identities and excessive privileges can bypass otherwise strong infrastructure controls. Start with the paths that allow people and software to act inside the environment.

• Require unique user accounts and avoid shared administrator credentials.
• Use the least privilege needed for each role, workload, and integration.
• Separate routine work from privileged administration and require stronger controls for sensitive actions.
• Enable multi-factor authentication. Favor phishing-resistant methods such as FIDO or WebAuthn where they are supported, as recommended in CISA's MFA guidance.
• Use workload identities or short-lived credentials instead of embedding long-lived secrets in code, images, notebooks, or configuration files.
• Store secrets in an appropriate secrets system, rotate them, and define an emergency revocation process.
• Remove access promptly when a person, device, service, or vendor no longer needs it.
• Review privileged roles, inactive accounts, tokens, keys, and third-party access on a schedule.

MFA reduces account-takeover risk, but it does not make phishing, session theft, malicious applications, or poor authorization disappear. Pair it with device security, login monitoring, safe recovery procedures, and narrowly scoped permissions.

Secure configurations, networks, APIs, and workloads

Cloud services are designed to be configurable, which means an unsafe default or rushed deployment can create an unnecessary exposure. Maintain an inventory of accounts, projects, regions, instances, containers, storage, APIs, public endpoints, images, and dependencies. Assign an owner and expected configuration to each item.

For virtual machines and containers, use maintained base images, remove unneeded services, patch operating systems and packages, restrict administrative access, and replace rather than preserve unknown or unmanaged instances. Keep infrastructure and application changes reviewable. Scan dependencies and images, but treat scan output as a queue for investigation rather than proof that a workload is safe.

Expose only the network paths the workload needs. Prefer private access for administrative interfaces and internal tools. Hivenet's Compute connectivity guidance, for example, recommends SSH port forwarding when a web interface is intended only for its operator. Public HTTPS, TCP, or UDP access should be an explicit decision, with authentication, authorization, transport protection, and service-level hardening.

Protect APIs with authenticated requests, authorization checks at every sensitive operation, input validation, rate and resource limits, safe error handling, and monitoring. Document which endpoints are public, which data they expose, and how keys or tokens can be rotated without an outage.

Protect data and manage keys

Encryption reduces specific confidentiality risks, but the word alone does not explain the control. Ask where encryption applies, which algorithms and protocols are used, who controls the keys, which metadata remains visible, and which access or recovery paths can decrypt the content.

• Encryption in transit protects data while it moves between systems. It does not determine who can access the data at either endpoint.
• Encryption at rest protects stored data and media. Its effect depends on key separation, access controls, and the systems allowed to use the key.
• Client-side or end-to-end encryption can reduce provider-access risk when implemented across the required devices, features, sharing paths, and recovery flow.
• Integrity controls help detect unauthorized or accidental changes. Hashing, authentication, digital signatures, and authenticated encryption serve different purposes; none should be described as a universal guarantee.

Define who can create, use, rotate, revoke, recover, and destroy keys. Separate key administration from routine data access where the risk justifies it. Also define retention, deletion, legal hold, backup, and export rules. Encryption cannot correct an overly broad permission, a compromised endpoint, an unsafe application, or the loss of the only recovery secret.

Logging, detection, vulnerability management, and response

Preventive controls will sometimes fail. Teams need enough visibility to detect misuse, understand what happened, contain it, recover, and improve the system.

Collect the logs that answer operational questions: who signed in, which privileged actions occurred, what changed, which endpoint was called, which workload communicated externally, and whether a security control failed. Centralize important events, protect their integrity and retention, and alert on conditions that someone can investigate. A large log volume without ownership, context, or an escalation path creates noise rather than detection.

Combine configuration review, vulnerability management, dependency maintenance, and exposure testing. Set remediation timelines according to exploitability, exposure, asset value, and business impact. Verify fixes instead of closing findings on the basis of a ticket alone.

An incident plan should name decision makers, technical responders, communications owners, provider contacts, evidence requirements, legal or contractual notification paths, and recovery priorities. Exercise credible scenarios before an emergency. Monitoring helps teams detect and respond; it cannot make an environment impenetrable.

Resilience, backup, recovery, and exit

Availability and recoverability are different. Redundant infrastructure may keep a service running through a component failure, while a backup protects against deletion, corruption, ransomware, account compromise, or provider loss only when it is isolated from the original failure path.

Define a recovery time objective (RTO) for how quickly the service should return and a recovery point objective (RPO) for how much data loss is tolerable. Map the regional, identity, network, software, and provider dependencies that could prevent recovery. Keep necessary recovery credentials available during an identity or account incident.

Test restores with representative data, permissions, applications, and users. Check version-retention and deletion windows instead of assuming that synchronization or replication provides a backup. For important workloads, maintain an independent copy or export and verify that it can be used without the primary environment.

An exit plan is also a security control. Record usable export formats, data volumes, transfer time, contractual notice, deletion behavior, and the skills required to move. For a consumer-focused treatment of these questions, use the cloud storage security checklist.

Compliance and provider due diligence

Security controls can support compliance, but encryption, a framework, or a provider certificate does not make an entire organization compliant. Legal duties depend on the data, purpose, jurisdiction, roles, contracts, and processing activity. This guide is not legal advice.

Separate the evidence you review:

• A law or regulation, such as the EU General Data Protection Regulation or California privacy rules administered by the California Privacy Protection Agency, creates legal requirements within its scope.
• A framework, such as the NIST Cybersecurity Framework, helps an organization describe and manage cybersecurity outcomes.
• A standard, such as ISO/IEC 27001, defines requirements for an information security management system.
• A certification or attestation applies to a stated entity, service, period, and scope. Verify those details rather than relying on a logo.

When evaluating a provider, ask for current documentation covering responsibility boundaries, data locations, subprocessors, support access, encryption and key control, logging, incident terms, deletion, continuity, testing, audit or certification scope, and export. Confirm that contracts and service descriptions match the plan, region, and product you will actually use. Readers who need a deeper privacy and governance review can continue with our cloud data privacy guide.

How Hivenet fits the model

Hivenet's current architecture overview describes product-specific operating models. Compute, Inference API, S3-compatible storage, Store, and Send solve different jobs, so their responsibility boundaries should be evaluated separately.

With Compute with Hivenet, teams launch GPU or CPU instances and control the environment they run. That places responsibility for the operating system or template choice, installed software, workload configuration, credentials, public exposure, application behavior, and recovery with the customer, alongside the infrastructure responsibilities Hivenet documents for the service.

Inference API is a managed endpoint path, so Hivenet operates more of the serving layer while the customer remains responsible for API credentials, application authorization, data sent to the endpoint, output handling, and integration security. S3-compatible storage, Store, and Send each have different access, data, sharing, and recovery paths. Do not transfer a control claim from one product to another without current product documentation.

Use Hivenet's Trust and transparency page and the relevant product documentation as the starting point for due diligence. Before a production or regulated workload, confirm the required controls, regions, responsibilities, support path, and contractual evidence for that exact product and plan. No cloud provider removes the customer's responsibility to protect credentials, configure services safely, maintain applications, and plan recovery.

Review Hivenet Trust

Cloud security checklist

1. Name the owners. Record provider, customer, and third-party responsibilities for every service.
2. Classify the workload and data. Include sensitivity, privacy, legal, contractual, regional, and recovery requirements.
3. Model credible threats. Cover compromised identities, unsafe interfaces, misconfiguration, vulnerable software, malicious insiders, deletion, ransomware, and outages.
4. Secure identities and secrets. Use least privilege, separate administrator access, MFA, short-lived credentials, rotation, offboarding, and access reviews.
5. Reduce exposure. Inventory services, harden images, patch dependencies, keep private interfaces private, and authorize every API operation.
6. Map encryption and key control. Verify transit, storage, processing, sharing, metadata, key ownership, rotation, recovery, and deletion behavior.
7. Make detection actionable. Collect important logs, protect them, define alerts, and assign responders.
8. Manage vulnerabilities. Prioritize by exposure and impact, set deadlines, and verify remediation.
9. Prepare for incidents. Define roles, communications, evidence, provider escalation, notification, and recovery steps.
10. Test recovery and exit. Measure restore time and data loss, protect independent copies, and prove that exports are usable.
11. Verify legal and assurance evidence. Check contracts, subprocessors, locations, current certification scope, and official regulatory sources.
12. Review after change. Reassess when a service, region, architecture, identity path, dependency, or requirement changes.

Cloud security FAQ

Who is responsible for cloud security?

The provider and customer both have responsibilities, and the boundary depends on the service model. A software provider usually operates more of the stack than an infrastructure provider. Customers still own decisions about their data, identities, permissions, integrations, configuration, and recovery unless a contract and service description assign a responsibility elsewhere.

Can the cloud be secure?

A cloud service can support workloads with demanding security requirements when its controls, responsibility model, evidence, and operations match the risk. Security remains a process of reducing and managing risk. No architecture or provider can guarantee that a workload will never be compromised, disrupted, misconfigured, or lost.

Which cloud security controls should come first?

Start by inventorying the workload and data, assigning responsibility, reducing unnecessary exposure, securing privileged identities, enabling appropriate MFA, removing long-lived secrets, patching known vulnerabilities, collecting useful logs, and testing recovery. Priorities should then follow the threat model and business impact.

Is compliance the same as security?

No. Security controls help manage confidentiality, integrity, availability, and related risks. Compliance means meeting defined legal, contractual, or policy requirements. A secure control can support compliance, while a certificate or checklist does not prove that every workload is securely configured or legally compliant.

How should an organization evaluate a cloud provider?

Compare the exact product and plan against the workload's requirements. Review responsibility boundaries, architecture, regions, access paths, encryption and key control, logging, incident terms, continuity, deletion, export, support, subprocessors, contracts, and the current scope of audits or certifications. Then test the controls the customer must operate.