Unit 6: Cloud Security - Subjective Questions

Cloud security is the collection of policies, technologies, controls, and operational practices used to protect cloud-hosted identities, networks, applications, infrastructure, and data.

Major security issues include:

• Data breaches: Unauthorized users may access sensitive or confidential information.
• Data loss: Data can be deleted, corrupted, encrypted by ransomware, or made unavailable because of inadequate backups.
• Misconfiguration: Public storage buckets, unrestricted security groups, and excessive permissions commonly expose resources.
• Insecure APIs: Weak authentication, poor input validation, and exposed API credentials can allow attacks on cloud services.
• Account hijacking: Stolen passwords, tokens, or access keys may give attackers control of cloud resources.
• Insider threats: Privileged employees of either the customer or provider may misuse authorized access.
• Multi-tenancy risks: Vulnerabilities in isolation mechanisms can potentially expose one tenant's resources to another.
• Denial-of-service attacks: Attackers may exhaust computing, network, or financial resources.
• Compliance and privacy risks: Data location, retention, and processing may violate legal or industry requirements.
• Limited visibility and shadow IT: Organizations may not know which cloud services, users, and data assets are in use.

These risks should be addressed through strong identity controls, encryption, secure configuration, continuous monitoring, backups, and incident response planning.

The shared responsibility architecture divides security duties between the cloud service provider and the customer.

• The provider is generally responsible for security of the cloud, including physical facilities, hardware, networking infrastructure, and the virtualization platform.
• The customer is responsible for security in the cloud, including identities, data, configurations, and workloads, depending on the service model.

Responsibility by service model

The customer always retains responsibility for understanding the sensitivity of its data and assigning appropriate access. A common mistake is assuming that moving to SaaS transfers every security obligation to the provider. In reality, weak passwords, incorrect sharing settings, and poor data governance remain customer risks.

Security by design means integrating security into architecture, development, deployment, and operation instead of adding it after implementation.

Important principles include:

• Least privilege: Give users, services, and workloads only the permissions necessary for their tasks.
• Secure defaults: Resources should be private, encrypted, and minimally accessible by default.
• Defense in depth: Use multiple controls across identity, network, host, application, and data layers.
• Zero trust: Authenticate and authorize every request rather than trusting it because it originates inside a network.
• Separation of duties: Divide sensitive activities among multiple roles to reduce fraud and error.
• Minimize attack surface: Disable unnecessary ports, services, packages, APIs, and public endpoints.
• Fail securely: A failure should deny access and preserve confidentiality rather than expose data.
• Automation and repeatability: Use infrastructure as code, policy as code, and automated security testing.
• Secure secret management: Store passwords, keys, tokens, and certificates in managed secret vaults rather than source code.
• Continuous verification: Scan code, images, dependencies, and runtime environments throughout the lifecycle.
• Auditability: Generate immutable logs for important administrative, identity, and data operations.

For microservices, these principles also require secure service-to-service authentication, API validation, image signing, dependency scanning, and controlled communication between services.

Identity and Access Management (IAM) controls who or what can access cloud resources and which actions may be performed.

Core IAM functions

• Identification: Assigns a unique identity to a user, application, device, or workload.
• Authentication: Verifies the identity using passwords, certificates, access keys, biometrics, or tokens. Multi-factor authentication (MFA) combines two or more factors and reduces account takeover risk.
• Authorization: Determines permitted operations after authentication. It may use role-based access control, attribute-based access control, or policy-based rules.
• Federation: Allows users to access cloud services through an external identity provider using standards such as SAML, OAuth 2.0, or OpenID Connect.
• Lifecycle management: Creates, modifies, reviews, and removes identities as employees or workloads change.
• Auditing: Records sign-ins, privilege changes, denied requests, and administrative activities.

The principle of least privilege requires assigning only the minimum permissions needed, for only the necessary resources and duration. It can be implemented through narrowly scoped roles, temporary credentials, just-in-time access, permission boundaries, and periodic access reviews.

Human users should normally use federated identities and MFA, while applications should use managed workload identities instead of long-lived embedded access keys.

A cloud security architecture can be represented as multiple defensive layers:

1. Physical layer: Protects data centers, power systems, storage media, and physical servers through guards, surveillance, access controls, and environmental safeguards.
2. Infrastructure and virtualization layer: Secures hypervisors, virtual machines, containers, storage, and tenant isolation.
3. Network layer: Uses virtual networks, subnets, firewalls, security groups, private endpoints, segmentation, and denial-of-service protection.
4. Host and workload layer: Applies hardened images, patching, endpoint detection, vulnerability management, and runtime protection.
5. Application and API layer: Uses secure coding, authentication, input validation, API gateways, web application firewalls, and dependency scanning.
6. Data layer: Provides classification, encryption, key management, backups, tokenization, retention, and data loss prevention.
7. Identity layer: Enforces authentication, authorization, federation, MFA, privileged access control, and service identities.
8. Operations and governance layer: Includes logging, monitoring, incident response, compliance assessment, configuration management, and policy enforcement.

These layers implement defense in depth. If one control fails, other controls can still detect, contain, or prevent an attack. Identity, governance, and monitoring are often treated as cross-cutting controls because they apply to every technical layer.

Cloud network security protects traffic entering, leaving, and moving within a cloud environment.

Key concepts and controls are:

• Virtual network isolation: Separate applications, environments, and business units into virtual networks, accounts, or projects.
• Subnets: Place internet-facing resources in public subnets and sensitive services in private subnets.
• Security groups and network access control lists: Filter traffic according to source, destination, port, protocol, and direction.
• Network segmentation: Restrict lateral movement by separating application tiers and microservices.
• Private connectivity: Use private endpoints, VPNs, or dedicated links to avoid unnecessary exposure to the public internet.
• Web application firewalls: Detect attacks such as SQL injection, cross-site scripting, and malicious HTTP requests.
• Distributed denial-of-service protection: Absorb or filter high-volume attacks.
• DNS security: Protect domain configuration, monitor suspicious queries, and prevent DNS-based attacks.
• Encryption in transit: Use TLS and, where required, mutual TLS for service-to-service communication.
• Network telemetry: Analyze flow logs, firewall logs, and intrusion detection alerts.
• Egress filtering: Control outbound connections to reduce data exfiltration and command-and-control traffic.

A secure design follows default deny, explicitly permits required communication, and continuously reviews exposed ports and public endpoints.

Host security protects the operating systems, virtual machines, container nodes, and runtime environments on which cloud applications execute.

Important controls include:

• System hardening: Remove unnecessary services, close unused ports, disable default accounts, and follow recognized security baselines.
• Patch management: Regularly update operating systems, packages, container runtimes, and installed software.
• Vulnerability scanning: Identify known vulnerabilities and prioritize remediation according to severity and exposure.
• Endpoint detection and response: Detect malware, suspicious processes, persistence mechanisms, and abnormal behavior.
• Access control: Use centralized identity, MFA, just-in-time administrative access, and restricted remote management.
• Secure images: Build systems from approved, minimal, scanned, and version-controlled machine or container images.
• File integrity monitoring: Detect unauthorized changes to system files and configurations.
• Logging: Collect operating-system, authentication, process, and audit logs centrally.
• Runtime protection: Restrict container privileges, use read-only file systems where possible, and prevent untrusted workloads from accessing the host.
• Configuration management: Detect and correct drift from approved baselines.

In containerized environments, hosts and orchestrator nodes must also be protected because a compromised node may affect multiple containers.

Cloud data security should cover the complete lifecycle of data:

1. Creation and collection: Collect only necessary data, validate inputs, identify ownership, and classify sensitivity.
2. Storage: Encrypt sensitive data, apply access policies, enable versioning where appropriate, and prevent unintended public access.
3. Use and processing: Restrict access to authorized workloads and protect sensitive values through masking, tokenization, or confidential computing.
4. Transmission: Use TLS, secure APIs, VPNs, or private links to protect data in transit.
5. Sharing: Approve recipients, limit permissions, record access, and prevent uncontrolled downloads or external sharing.
6. Archival: Apply retention rules, lower-cost protected storage, and legal-hold requirements.
7. Deletion: Use secure deletion and cryptographic erasure, and confirm that retention obligations have been satisfied.

Encryption states

• At rest: Protects stored databases, disks, objects, and backups.
• In transit: Protects network communication.
• In use: Protects data during processing through technologies such as trusted execution environments.

Effective key management includes centralized key generation, controlled access, rotation, revocation, backup, separation of duties, and audit logging. Customer-managed keys offer additional control, but they also make the customer responsible for key availability and lifecycle management.

Cloud security operations, often called Cloud SecOps, is the continuous process of monitoring, detecting, investigating, containing, and recovering from security incidents in cloud environments.

Major activities include:

• Asset discovery: Maintain an inventory of accounts, identities, workloads, data stores, APIs, and external services.
• Log collection: Centralize audit, identity, network, application, operating-system, and data-access logs.
• Threat detection: Use rules, threat intelligence, analytics, and behavioral baselines to identify suspicious events.
• Vulnerability management: Scan workloads and dependencies, prioritize risk, and verify remediation.
• Configuration monitoring: Detect public exposure, unencrypted storage, excessive permissions, and policy violations.
• Alert triage: Validate alerts, assess severity, correlate related events, and reduce false positives.
• Incident response: Contain compromised identities or workloads, preserve evidence, eradicate the cause, and restore services.
• Security automation: Use playbooks to disable credentials, isolate hosts, block indicators, and notify responders.
• Post-incident improvement: Conduct root-cause analysis and update controls, playbooks, and architecture.

Cloud response procedures should be tested regularly because resources are dynamic and evidence may disappear when short-lived containers or instances terminate.

The major cloud providers offer comparable security capabilities under different product names.

All three providers support identity policies, encryption, centralized logging, compliance reporting, and automated configuration assessment. Tool selection should consider workload requirements, integration, regional availability, operational skills, and cost rather than relying only on product names.

Security compliance means demonstrating that cloud systems meet applicable laws, regulations, contracts, and industry standards. It is important because organizations remain accountable for protecting regulated data even when a cloud provider processes or stores it.

Common requirements include:

• GDPR: Protects personal data of individuals in the European Union and imposes requirements for lawful processing, data-subject rights, breach notification, and international transfers.
• HIPAA: Establishes safeguards for protected health information in the United States.
• PCI DSS: Defines security controls for systems that store, process, or transmit payment-card data.
• ISO/IEC 27001: Specifies requirements for an information security management system.
• SOC 2: Evaluates service controls relating to security, availability, processing integrity, confidentiality, and privacy.
• NIST frameworks: Provide guidance for risk management, cybersecurity controls, and incident response.

Cloud compliance requires data classification, control mapping, evidence collection, risk assessment, access reviews, encryption, logging, retention management, and regular audits. Provider certifications can support compliance, but they do not automatically make a customer's workload compliant. The customer must configure services properly and satisfy its part of the shared responsibility model.

Interoperability is the ability of applications, data, security controls, and operational processes to work consistently across different cloud and on-premises platforms.

Major challenges include:

• Different service interfaces: Providers use different APIs, resource models, policy languages, and naming conventions.
• Identity inconsistency: Roles and permissions may not map directly between platforms, creating excessive or missing access.
• Data portability: Proprietary formats, large transfer volumes, and egress charges may make migration difficult.
• Inconsistent security controls: Encryption, firewall, logging, and threat-detection capabilities differ among providers.
• Fragmented visibility: Logs and alerts arrive in different formats and must be normalized for centralized analysis.
• Configuration drift: Equivalent workloads may develop different security settings across environments.
• Regulatory complexity: Data may cross regions or providers with different contractual and legal conditions.
• Skill requirements: Teams must understand multiple security and operational ecosystems.
• Vendor lock-in: Heavy dependence on proprietary databases, serverless services, or IAM models can make migration costly.

Organizations can reduce these risks through open standards, containers, portable data formats, federated identity, abstraction layers, centralized security monitoring, infrastructure as code, and clearly tested exit strategies. However, excessive abstraction may prevent effective use of valuable cloud-native features.

Cloud monitoring and performance management involve collecting and analyzing operational information to maintain availability, responsiveness, capacity, reliability, and security.

The three primary observability signals are:

• Metrics: Numerical measurements such as CPU utilization, memory consumption, request rate, latency, error rate, disk operations, network throughput, and queue depth.
• Logs: Timestamped records of application, operating-system, identity, network, and security events.
• Traces: End-to-end records showing how a request travels through distributed microservices.

Important performance indicators include:

• Availability, calculated as:

• Average and percentile latency, such as the 95th and 99th percentiles.
• Throughput or requests processed per second.
• Error and timeout rates.
• Resource saturation and scaling activity.
• Recovery time and recovery point objectives.
• Service-level indicators and service-level objectives.

An effective system uses dashboards, correlation identifiers, distributed tracing, automated alerts, anomaly detection, and retention policies. Alerts should represent user impact and actionable conditions rather than every temporary resource fluctuation.

A cloud incident response lifecycle contains the following stages:

1. Preparation: Define roles, contacts, logging requirements, evidence procedures, tools, and automated playbooks.
2. Detection and analysis: Correlate alerts, confirm the incident, determine affected identities and resources, and assign severity.
3. Containment: Disable compromised credentials, isolate workloads, restrict network access, or block malicious indicators.
4. Eradication: Remove malware, patch vulnerabilities, rotate secrets, correct configurations, and eliminate persistence.
5. Recovery: Restore clean resources and data, validate security, and gradually return services to operation.
6. Post-incident review: Determine root cause, measure response effectiveness, and improve controls and procedures.

Cloud forensics is affected by:

• Ephemeral resources: Containers and temporary instances may disappear quickly.
• Provider-controlled infrastructure: Customers may not have direct access to physical systems or hypervisor evidence.
• Distributed data: Logs and artifacts may exist across accounts, services, and regions.
• Multi-tenancy: Evidence collection must not violate another tenant's privacy.
• Automation: Resources can change rapidly, but snapshots and log exports can also be automated.

Organizations should centralize immutable logs, synchronize time, preserve snapshots and metadata, document chain of custody, and coordinate provider support before an incident occurs.

Major trends influencing cloud security include:

• Zero-trust architecture: Continuous identity, device, workload, and context verification will replace network-location-based trust.
• Confidential computing: Trusted execution environments will provide stronger protection for data in use.
• Passwordless authentication: Passkeys, biometrics, and hardware-backed credentials will reduce password theft.
• AI-assisted security: Machine learning and generative AI will support detection, investigation, code analysis, and incident response.
• Cloud-native application protection platforms: Posture management, workload protection, identity risk, and application security will become more integrated.
• Policy as code: Security and compliance requirements will be automatically tested during development and deployment.
• Software supply-chain security: Signed artifacts, software bills of materials, provenance checks, and dependency verification will receive greater attention.
• Post-quantum cryptography: Organizations will inventory cryptographic assets and prepare for algorithms resistant to quantum attacks.
• Autonomous remediation: Systems will automatically correct common misconfigurations and contain well-understood threats.
• Sovereign and industry clouds: More services will support national data residency and sector-specific regulatory controls.
• Edge security: Distributed devices and processing nodes will require lightweight identity, secure updates, and local threat detection.

These innovations can strengthen security, but they also introduce new risks involving complexity, model integrity, automation errors, and governance.

Edge computing processes data close to the devices or locations where it is generated instead of sending all data to a centralized cloud region.

Security benefits

• Sensitive data can be filtered or anonymized locally before cloud transmission.
• Reduced network dependency can improve resilience and availability.
• Local detection can respond rapidly to safety or security events.
• Less data transfer may reduce exposure during transmission.

Security challenges

• Physical exposure: Edge devices may operate in uncontrolled locations and be stolen or modified.
• Large attack surface: Thousands of distributed devices are harder to inventory and protect.
• Limited resources: Some devices cannot support heavyweight encryption, scanning, or monitoring tools.
• Patch complexity: Intermittent connectivity and hardware diversity complicate secure updates.
• Weak identity: Default passwords or cloned device credentials can enable unauthorized access.
• Untrusted networks: Edge nodes often communicate over public or wireless networks.
• Data consistency: Local and cloud copies must be synchronized without unauthorized modification.

Security controls should include hardware roots of trust, secure boot, signed firmware, unique device identities, encrypted communication, remote attestation, segmentation, tamper detection, local access control, and automated lifecycle management.

Artificial intelligence can improve cloud security by analyzing large volumes of data faster than manual processes.

Security applications of AI

• Detect anomalous user, network, and workload behavior.
• Correlate alerts and identify probable attack paths.
• Classify malware, phishing messages, and malicious API activity.
• Prioritize vulnerabilities according to exploitability and business impact.
• Summarize incidents and recommend response actions.
• Detect sensitive data and support automated classification.
• Assist developers in identifying insecure code and configuration.

Risks introduced by AI

• Prompt injection: Malicious input can manipulate an AI system into ignoring intended instructions.
• Data leakage: Models may expose confidential prompts, training data, or retrieved documents.
• Model poisoning: Attackers may corrupt training data or model updates.
• Adversarial input: Carefully designed content may cause incorrect classifications.
• Insecure automation: Incorrect AI recommendations may trigger disruptive remediation.
• Model theft: Valuable models, parameters, or system prompts may be extracted.
• Bias and opacity: Decisions may be unfair or difficult to explain.
• AI-enabled attacks: Adversaries can automate phishing, reconnaissance, malware development, and social engineering.

Safe use requires access control, data minimization, output validation, human approval for high-impact actions, model monitoring, red-team testing, and audit logging.

Traditional perimeter-based security assumes that systems and users inside a protected network are more trustworthy than those outside it. Zero-trust security assumes that no request should be trusted automatically, regardless of its network origin.

Zero trust is particularly suitable for cloud environments because users, services, and data are distributed across regions, providers, devices, and remote networks. Its implementation requires strong IAM, MFA, workload identity, device assessment, encryption, microsegmentation, logging, and continuous policy evaluation.

DevSecOps integrates security responsibilities and automated controls into planning, coding, building, testing, deployment, and operation.

A secure microservices pipeline should include:

• Threat modeling: Identify assets, trust boundaries, abuse cases, and required controls before implementation.
• Source-code protection: Enforce branch protection, peer review, signed commits, and restricted repository access.
• Static analysis: Detect insecure coding patterns before execution.
• Dependency scanning: Identify vulnerable or malicious third-party packages.
• Secret scanning: Prevent credentials and tokens from entering source repositories or build logs.
• Infrastructure-as-code scanning: Detect insecure cloud resources before deployment.
• Container security: Use minimal base images, scan image layers, sign images, and verify signatures during admission.
• Software bill of materials: Record the components included in each release.
• Dynamic and API testing: Test running applications for authentication, input-validation, and authorization failures.
• Deployment controls: Use policy as code, protected environments, and separation of duties.
• Runtime monitoring: Detect abnormal service behavior, vulnerable workloads, and unauthorized changes.

The pipeline itself must also be protected because compromised build tools or credentials can distribute malicious artifacts to every deployed environment.

A layered security design should combine preventive, detective, and corrective controls.

1. Identity layer

• Federate employee access through a central identity provider.
• Require MFA and use least-privilege roles.
• Assign separate managed identities to individual microservices.
• Use short-lived credentials and just-in-time administrative access.

2. Network layer

• Place the API gateway behind denial-of-service protection and a web application firewall.
• Keep application and database services in private subnets.
• Allow only required service-to-service communication through microsegmentation.
• Use TLS externally and mutual TLS between sensitive internal services.

3. Application and workload layer

• Validate all inputs and enforce authentication and authorization at APIs.
• Scan source code, dependencies, infrastructure templates, and container images.
• Deploy signed minimal images and restrict container privileges.
• Store secrets in a managed vault and rotate them automatically.

4. Data layer

• Classify sensitive customer data and minimize collection.
• Encrypt data at rest and in transit using managed keys with controlled access.
• Apply masking or tokenization to high-risk fields.
• Use encrypted, versioned, and regularly tested backups.

5. Operations and governance layer

• Centralize identity, network, application, and data-access logs.
• Monitor configuration drift, excessive permissions, vulnerabilities, and abnormal behavior.
• Define incident-response playbooks and automate credential revocation and workload isolation.
• Map controls to applicable privacy and industry regulations.
• Test recovery, penetration resistance, and access controls regularly.

This architecture follows defense in depth, zero trust, least privilege, secure defaults, and continuous monitoring. Its effectiveness should be validated through threat modeling, security testing, audits, and incident simulations.