Mastering Cloud Security: Practical Principles for Public Cloud Adoption

Contents

Category

Article

Tags

cloud securitypublic cloudshared responsibilityenterprise architecture

Contents

Public cloud is not insecure by default. It becomes risky when teams treat it like rented infrastructure without understanding the control boundaries.

The main security question is not:

“Is the cloud provider secure?”

The better question is:

“Have we designed our part of the cloud environment securely?”

Cloud security depends on shared responsibility. The cloud provider secures the underlying cloud platform. The customer remains responsible for identity, data, workload configuration, network exposure, logging, key management, and application security.

This post covers practical principles for reviewing public cloud adoption, which should be assessed alongside the selected modernizing application architecture paths for your workloads.

Secure Public Cloud Workload: Conceptual Control Model

Internet ingress is controlled at the edge, workloads remain private, data is isolated, egress is restricted, administration is governed, and security events are monitored centrally.

Key Architecture Principles

A secure cloud workload should separate ingress, workload execution, data, egress, administration, and monitoring. Each plane should have a clear control point.

Architecture plane	Principle	Key controls
Edge security zone	Internet traffic reaches the control layer before the workload.	Approved DNS, CDN or edge service, DDoS protection, WAF, bot control, rate limiting, origin allow-listing
Private application zone	Workloads run privately and use short-lived identity-based access.	Private subnets, no public IPs, dedicated workload identity or IAM role, runtime secret retrieval
Private data zone	Data services are isolated from public access and encrypted with controlled keys.	Private endpoints, no public storage or database access, separate backup vaults, encryption at rest, customer-managed keys where required
Approved egress zone	Outbound traffic uses approved and logged paths only.	Cloud firewall, NAT with restrictions, proxy, private endpoints, service allow-lists, egress logging
Management plane	Administration uses controlled private access, not public management ports.	Corporate SSO, MFA, PAM, JIT access, disabled public SSH/RDP, admin activity logging
Security monitoring plane	Logs and posture signals are centralized for detection and assurance.	SIEM or security data lake, audit logs, network logs, key logs, data access logs, CSPM, CIEM, CDR, IaC scanning, policy-as-code, drift detection

The design rule is simple: every path into, out of, or across the workload must pass through an approved control point and produce useful logs.

Ingress, egress, administration, data access, and monitoring each have a defined control path.

---

1. Start With Clear Ownership

Cloud security fails when responsibility is unclear.

Define ownership before design approval.

At minimum, clarify:

• Who owns the cloud account, subscription, or project?
• Who approves privileged access?
• Who manages encryption keys?
• Who reviews firewall and security group changes?
• Who monitors cloud security alerts?
• Who responds to incidents?
• Who pays for logging, retention, backup, and security tools?

Do not rely on the vendor’s certification alone. Certifications show that controls exist at a point in time. They do not prove that your workload is configured securely.

Use shared responsibility as the baseline. Then map every major control to either:

• Cloud provider
• SaaS provider
• System integrator
• Internal IT
• Application team
• Security team

No critical control should be ownerless.

---

2. Isolate Data by Design

Public cloud uses shared infrastructure. That is normal. The security goal is to make sure your data, workloads, logs, and keys are isolated from other tenants and from unrelated internal environments.

Dedicated tenancy or physical segregation should be exceptional, not the default. Require it only when justified by regulation, contract, or threat model.

---

3. Control Ingress Like a Production Perimeter

Internet-facing cloud workloads should never be exposed directly without layered controls.

Control area	What to require
Entry point	Approved DNS, CDN or edge protection where appropriate, DDoS protection
Application protection	WAF for web apps, API gateway for APIs, bot protection for public login, search, registration, and transaction flows
Transport security	TLS 1.2 or higher, strong certificate lifecycle management
Origin protection	Only allow traffic from approved WAF, CDN, or gateway paths
Network control	Security groups, firewall rules, and routing limited to approved paths

Do not expose cloud load balancers, storage buckets, databases, Kubernetes APIs, or management endpoints directly to the internet unless there is a documented exception.

Good origin protection patterns include private load balancers, WAF/CDN source allow-listing, mTLS for sensitive service paths, blocked public storage access, and signed URLs or cookies for controlled content.

The rule is simple: the internet should reach your control layer first, not your workload directly.

---

4. Restrict Egress, But Do It Practically

Cloud workloads should not have unrestricted outbound internet access.

Egress Pattern	Core Purpose & Use Case
Cloud-native firewall	FQDN filtering and TLS inspection
Secure web gateway	Controlled egress proxying for enterprise workloads
NAT gateway	Basic outbound internet translation with restrictive routing and logs
Private endpoints / PrivateLink	Direct, private access to internal or managed cloud services
Service endpoints	Platform resource network access policies
On-premises tunnel	Centralized inspection or legacy integrations (avoid default routing if it causes latency)

All egress must pass through an approved control point and be logged. Prefer private endpoints over public paths for sensitive managed services (storage, databases, secrets, container registries, logs).

---

5. Treat Identity as the Main Security Boundary

In the cloud, identity is the primary boundary. A flawed IAM policy exposes more than a misconfigured firewall rule.

Access Target	Required Security Controls
User Access	Corporate SSO integration, MFA (phishing-resistant for admins), regular access reviews
Privileged Access	Just-In-Time (JIT) approvals, separate break-glass accounts, no shared admins or long-lived user keys
Workload Access	Service accounts with least privilege, workload identities instead of static secrets
SaaS Vendors	Review administrator SSO bypass, local account disablement, logs, session recordings, and customer data access policies

Avoid broad wildcard permissions (e.g., Owner, AdministratorAccess, unrestricted key/IAM permissions). Identity is your control plane: protect it first.

---

6. Encrypt Data, But Focus on Key Control

Encryption requires knowing what is encrypted, who controls/uses the keys, and how rotation, deletion, and backups are handled.

Data Classification	Encryption & Key Controls
Low / Internal	Platform-managed encryption (if supported by risk assessment)
Confidential	Customer-managed keys (CMK)
Highly Confidential	CMKs with HSM backup, environment separation, separated key administrators, rotation, usage logs, key destruction plans, and backup encryption checks
Extreme	Double encryption, external key management, or application-level encryption

Never assume Bring Your Own Key (BYOK) solves all isolation problems. If cloud administrators can bypass key policies, read data, and disable logs, the control is ineffective. Separating key administration from workload administration is vital.

---

7. Build Logging Before Go-Live

Cloud logging must be designed before production. Do not wait for an incident to discover that logs were disabled, overwritten, or retained for too short a period.

Log source	What to collect
Cloud platform	Control plane logs, IAM sign-ins, privileged activity, key management logs
Network	Flow logs, DNS logs, load balancer logs, WAF logs, API gateway logs
Data services	Database audit logs, storage access logs, backup and restore events
SaaS	Administrator logs, user access logs, support access logs where available
Workloads	Endpoint, server, container, and workload security logs

For databases, audit sensitive administrative and data access activity, including schema changes, permission changes, failed logins, privileged queries, and bulk exports.

Send important logs to a central SIEM or security data lake in near real time.

Protect logs from tampering. Store them separately, restrict delete permissions, use immutable storage where possible, monitor logging disablement, and alert on policy changes.

A cloud system without usable logs is not production-ready.

---

8. Use CSPM, But Do Not Depend on It Alone

CSPM is useful for detecting cloud misconfigurations and drift from baseline.

CSPM helps detect	CSPM does not fully solve
Public storage	Poor application logic
Overly permissive security groups	Bad business authorization
Weak IAM policies	Insecure APIs
Missing encryption	Weak SaaS tenant isolation
Disabled logging	Over-permissioned SaaS administrators
Exposed databases	Data leakage through approved channels
Non-compliant configurations	Poor incident response or vendor operations

Use CSPM as a continuous control monitor, not as a replacement for secure architecture, threat modelling, penetration testing, vendor due diligence, or application security review.

For mature environments, combine CSPM with CIEM, CWPP, CDR, CASB or SSE, SSPM (which helps identify when software-as-a-service (SaaS) environments are leaking data), IaC scanning, and policy-as-code in deployment pipelines.

Security should be enforced before deployment, not only detected after deployment.

---

9. Apply Tenant Restrictions for SaaS

SaaS creates a specific risk: users may access unmanaged tenants or personal accounts from corporate devices, browsers, or networks.

Examples include personal Microsoft 365 tenants, external Entra ID tenants, personal Google accounts, unapproved Dropbox or GitHub organizations, and shadow AI workspaces.

For high-risk SaaS platforms, restrict access to approved tenants or workspaces only.

Control	Purpose
Tenant restriction headers	Limit access to approved SaaS tenants
Conditional access	Enforce user, device, location, and risk conditions
CASB or secure web gateway policy	Control SaaS access and uploads
Browser isolation	Separate unmanaged tenant access where needed
DLP controls	Reduce leakage through approved SaaS channels
Device compliance checks	Block unmanaged or non-compliant devices
Download, upload, copy, and paste controls	Limit movement to personal or unmanaged accounts where justified

This is most important for SaaS platforms that store documents, source code, customer records, email, regulated data, or AI prompts and outputs.

The goal is simple: corporate users should access corporate data through approved tenants, not unmanaged workspaces.

---

10. Review Vendor Security Beyond Certifications

ISO 27001 and SOC 2 Type II are useful, but they are not enough. Review the actual scope and operating model.

Area	What to verify
Report scope	Service, region, environment, cloud platform, data center, and production coverage
Exceptions	Exclusions, unresolved findings, user entity controls, and control gaps
Data location	Where data is stored, processed, backed up, and accessed from
Subprocessors	Who they are, where they operate, and what data they can access
Tenant isolation	How isolation is designed, tested, monitored, and evidenced
Privileged access	How vendor support access is approved, logged, time-bound, and reviewed
AI and data use	Whether customer data is used for model training or retained after termination
Incident response	Notification timelines, evidence sharing, and customer communication process

For cloud-hosted vendors, review the hyperscaler evidence, but do not stop there. The vendor’s configuration, access model, logging, tenant isolation, support process, and subcontractor chain matter more than the hyperscaler certificate.

A secure hyperscaler does not automatically make the SaaS vendor secure. Use structured third-party assessments for evaluating third-party vendor security controls and reviewing subcontractor flows.

---

11. Contract the Controls That Matter

Security requirements must be written into the contract, not left as verbal assurance.

Control area	What to include
Data location	Approved regions, data residency, backup location, data transfer limits
Third parties	Subprocessor list, notification process, approval rights where possible
Encryption and keys	Encryption requirements, key ownership, key management, key rotation expectations
Logging and audit	Log availability, audit access, admin activity evidence, retention expectations
Incident response	Notification timeline, breach cooperation, evidence sharing, escalation path
Vulnerability management	Remediation timelines, penetration testing obligations, retest expectations
Assurance rights	Right to audit or equivalent assurance through independent reports
Exit and deletion	Data deletion, backup retention, exit support, return of data, termination handling
Regulatory support	Cooperation for regulator requests, audits, and investigations

Be practical with audit rights. Large hyperscalers and major SaaS providers may not allow direct customer audits. In those cases, require equivalent assurance such as SOC 2 Type II, ISO 27001, CSA CAIQ, penetration test summaries, independent assessment reports, customer audit programs, or contractual rights to request additional evidence.

The goal is not to collect documents. The goal is to prove that critical risks are controlled.

---

12. Define Cloud Go-Live Criteria

No production cloud workload should go live based only on project urgency. Use clear go-live criteria.

Area	Minimum go-live check
Architecture	Architecture reviewed, shared responsibility mapped, data classification completed
Identity	IAM reviewed, MFA enforced, privileged access controlled
Network	Ingress restricted, egress controlled, private access used where required
Data protection	Encryption enabled, key ownership defined, backup configured, restore tested
Logging and monitoring	Logs enabled, SIEM integration tested, alerting confirmed
Security testing	Vulnerability scan completed, critical and high findings fixed or risk-accepted
Operations	Incident runbook prepared, support ownership confirmed, rollback plan documented
Vendor and contract	Vendor assurance reviewed, contractual security clauses agreed, exit plan documented

If a control is missing, record it as a risk. Do not hide it as a project dependency.

---

Key Takeaways

Cloud security is not achieved by buying cloud services. It is achieved by designing clear controls around identity, data, network paths, keys, logs, and vendor operations.

Use three rules:

1. Isolate what matters. Separate environments, data, keys, logs, and privileges.
2. Control every path. Review ingress, egress, admin access, support access, API access, and SaaS tenant access.
3. Prove it continuously. Use logs, CSPM, SIEM, access reviews, testing, and vendor assurance to confirm that controls continue to work.

The cloud provider secures the foundation. You still own the risk of what you configure, expose, store, and operate.

---

References

• CSA Cloud Controls Matrix for cloud control domains and shared cloud control responsibilities.
• NIST SP 800-210 for cloud access control across IaaS, PaaS, and SaaS.
• AWS Shared Responsibility Model for customer responsibility over data, IAM, and encryption choices.
• Microsoft Entra Tenant Restrictions v2 for controlling access to unauthorized tenants.
• Google Cloud VPC Service Controls as an example of service perimeter controls to reduce data exfiltration risk.
• MAS Advisory on Cloud Services for regulatory expectations on cloud risk management and governance in Singapore.
• ABS Cloud Computing Implementation Guide (July 2024) for security guidelines and control implementation requirements in the financial sector.
• IMDA Compliance and Certification for Singapore security standards (such as Multi-Tier Cloud Security - MTCS) and cloud certification requirements.
• MAS Technology Risk Management Guidelines for overarching expectations on IT security controls, system availability, and technology risk management.