Unit 1: Understanding Cloud Security

I. Cloud Security Foundations

Cloud security is the coordinated use of policies, technologies, processes, and controls to protect cloud-hosted data, applications, identities, and infrastructure. Its governing principle is that security remains necessary even when computing resources are operated by an external cloud service provider.

• Core objectives:
  • Confidentiality: Information is accessible only to authorized identities; encryption and access controls protect customer records.
  • Integrity: Data and configurations remain accurate and unaltered; hashes, digital signatures, and audit logs help detect modification.
  • Availability: Services remain accessible when required; redundancy, backups, and denial-of-service protection support uptime.
• Cloud service models:
  • IaaS: The provider operates physical infrastructure, while the customer secures operating systems, applications, identities, and data.
  • PaaS: The provider additionally manages operating systems and runtimes; the customer focuses on application code, identities, and data.
  • SaaS: The provider operates the application stack, but the customer still controls users, permissions, data handling, and secure usage.
• Deployment contexts: Public, private, hybrid, and multi-cloud environments create different ownership boundaries and security requirements.
• Zero Trust assumption: No user, device, or network location is trusted automatically; every access request should be explicitly verified and minimally authorized.

II. Cloud Protection Methods

A. Overview of cloud security and methods

Cloud security uses preventive, detective, and corrective controls across identities, data, networks, applications, and management systems.

• Preventive controls: IAM policies, firewalls, secure configuration baselines, encryption, and application allowlists reduce the probability of compromise.
• Detective controls: Activity logs, intrusion detection, vulnerability scanning, and Security Information and Event Management (SIEM) systems identify suspicious behavior.
• Corrective controls: Automated account disabling, malware isolation, backup restoration, and incident-response procedures limit damage after detection.
• Data protection:
  • Data at rest can be encrypted with services such as Azure Storage Service Encryption.
  • Data in transit should use protocols such as TLS 1.2 or later.
  • Keys should be rotated and protected through a managed key vault.
• Network protection: Network Security Groups, private endpoints, segmentation, web application firewalls, and distributed denial-of-service protection restrict traffic paths.
• Configuration management: Infrastructure as Code, policy enforcement, patching, and cloud security posture management detect configuration drift.
• Defense in depth: Multiple independent controls protect the same asset; a stolen password, for example, should still encounter MFA, device checks, and limited authorization.

III. Security Ownership

A. Shared responsibility model of cloud security

The shared responsibility model divides security duties between the cloud provider and the customer according to the service model being used.

1. Provider responsibility: security of the cloud

   • Physical facilities: The provider protects data centers, power supplies, cooling systems, and physical access.
   • Core infrastructure: The provider secures physical servers, storage hardware, networking equipment, and the virtualization layer.
   • Managed components: Responsibility expands in PaaS and SaaS because the provider also operates more of the software stack.

2. Customer responsibility: security in the cloud

   • Universal duties: The customer remains responsible for data classification, identities, access decisions, endpoint security, and lawful use.
   • IaaS duties: Customers must patch guest operating systems, secure virtual networks, configure firewalls, and protect installed applications.
   • SaaS duties: Customers primarily manage accounts, sharing settings, retention rules, and the sensitivity of uploaded information.

• Shared controls: Patch management may be divided; the provider patches the host, while an IaaS customer patches the guest operating system.
• Accountability principle: Using a compliant provider does not automatically make the customer’s workload compliant; insecure customer configuration can still expose data.

IV. Cloud Threats and Governance

A. Common cloud security challenges

Cloud environments introduce risks through rapid provisioning, internet-accessible management interfaces, distributed resources, and complex permissions.

• Misconfiguration: Public storage containers, unrestricted inbound ports, or disabled logging can expose resources without exploiting software.
• Visibility gaps: Unsanctioned “shadow IT” accounts and resources may exist outside centralized monitoring.
• Insecure interfaces: Weakly protected APIs can permit unauthorized data access, injection, or automated abuse.
• Credential theft: Phishing, leaked access keys, and token theft allow attackers to operate as legitimate identities.
• Multi-cloud complexity: Different providers use different policy languages, logging formats, and responsibility boundaries.
• Resource abuse: Compromised subscriptions may be used for cryptocurrency mining, causing unexpected cost and service exhaustion.

B. Data breaches

A data breach occurs when protected information is accessed, disclosed, altered, or extracted by an unauthorized party.

• Typical causes: Excessive permissions, compromised credentials, vulnerable applications, public storage, and exposed database endpoints are frequent entry paths.
• Breach sequence: An attacker commonly gains initial access, escalates privileges, discovers valuable data, and exfiltrates it through allowed network channels.
• Business impact: Consequences include notification costs, regulatory penalties, operational disruption, intellectual-property loss, and reputational damage.
• Controls: Encryption, data-loss prevention, least-privilege access, database activity monitoring, egress filtering, and tested incident-response plans reduce exposure.
• Concrete scenario: A storage account containing customer invoices is accidentally configured for anonymous access. Policy enforcement blocks public access, while audit logs identify who changed the configuration and when.

C. Insider threats

Insider threats arise when authorized employees, contractors, or partners intentionally or accidentally misuse legitimate access.

1. Malicious insiders

   • Intent: A privileged administrator may copy customer data for financial gain or deliberately disrupt services.
   • Indicators: Unusual bulk downloads, privilege changes, or access outside normal working patterns can reveal misuse.

2. Negligent insiders

   • Error: A developer may commit an API key to a public repository or send confidential data to the wrong recipient.
   • Reduction: Secret scanning, awareness training, approval workflows, and automatic classification limit accidental exposure.

• Privilege safeguards: Privileged Identity Management can provide time-limited, approval-based administrative access.
• Separation of duties: No single person should both authorize and complete a sensitive action such as deleting backups.
• Monitoring boundary: User monitoring should be proportionate, documented, and consistent with privacy and employment requirements.

D. Compliance risks

Compliance risk is the possibility that cloud processing violates legal, regulatory, contractual, or organizational requirements.

• Data location: Regulations or contracts may restrict the country or region in which personal, financial, or government data is stored.
• Data lifecycle: Retention schedules must define how long records remain available and when backups and replicas are securely deleted.
• Access evidence: Audit logs should record identity, action, resource, result, and timestamp for investigations and assessments.
• Framework alignment: Organizations may map cloud controls to requirements such as GDPR, ISO/IEC 27001, PCI DSS, or sector-specific rules.
• Third-party risk: Provider certifications support assurance, but customers must examine service scope, contractual terms, subprocessors, and breach-notification duties.
• Continuous compliance: Azure Policy can audit or deny resources that violate rules, such as deployment outside approved regions.

V. Identity Security in Microsoft Azure

A. Identity and Access Management (IAM)

IAM ensures that verified identities receive appropriate access to resources for an approved purpose and duration.

• Identification: A username, service principal, managed identity, or device identity states who or what is requesting access.
• Authentication: Passwords, certificates, security keys, or biometrics establish that the claimed identity is genuine.
• Authorization: Policies determine permitted actions after authentication; Azure Role-Based Access Control assigns roles at management-group, subscription, resource-group, or resource scope.
• Least privilege: A user who only reads virtual-machine status should receive Reader, not Contributor or Owner.
• Role elements: A role assignment combines a security principal, a role definition, and a scope.
• Lifecycle governance: Joiner, mover, and leaver processes create access, update it after role changes, and revoke it immediately on departure.
• Workload identities: Managed identities avoid embedding usernames, passwords, or access keys in application code.

B. Azure Active Directory (AAD) structure

Azure Active Directory, now named Microsoft Entra ID, is Microsoft’s cloud identity and access-management service.

• Tenant: A tenant is an organization’s dedicated identity directory and trust boundary, identified by a tenant ID.
• Directory objects: Users, groups, devices, service principals, and application registrations are stored as objects with unique identifiers.
• Subscriptions: An Azure subscription trusts one Entra tenant for authentication, although one tenant can support multiple subscriptions.
• Administrative units: These divide management responsibility, allowing administrators to manage only selected users or groups.
• Applications: An application registration defines software identity and authentication settings; its service principal represents that application within a tenant.
• External identities: Business-to-business collaboration allows guest users to access selected resources without creating ordinary employee accounts.
• Distinction: Entra directory roles administer identity services, while Azure RBAC roles authorize access to Azure resources.

C. User and group management

User and group management organizes identities so access can be granted consistently and removed efficiently.

• User types: Member accounts usually belong to employees, while guest accounts represent external collaborators.
• Group-based access: Permissions should normally be assigned to groups such as Finance-Readers, not separately to every employee.
• Group types: Security groups control resource access; Microsoft 365 groups support collaboration services such as shared mailboxes and sites.
• Membership models: Assigned membership is maintained manually, while dynamic membership uses attributes such as department or location.
• Provisioning: HR-driven workflows can automatically create, update, disable, and delete accounts as employment status changes.
• Periodic review: Access reviews verify that members still require group, application, or privileged-role access.
• Deletion protection: Disabled accounts and retention periods can preserve investigation evidence before permanent deletion.

D. Multi-Factor Authentication (MFA)

MFA requires evidence from at least two different authentication-factor categories, reducing dependence on passwords.

• Factor categories:
  • Knowledge: Something the user knows, such as a password or PIN.
  • Possession: Something the user has, such as a security key or authenticator-equipped phone.
  • Inherence: Something the user is, such as a fingerprint or facial characteristic.
• Valid combination: A password plus an authenticator approval is MFA; two passwords are still only one factor category.
• Conditional Access: Policies can require MFA according to user role, application sensitivity, device compliance, location, or sign-in risk.
• Phishing resistance: FIDO2 security keys and certificate-based methods resist credential replay better than SMS codes.
• Operational controls: Organizations need secure registration, recovery, temporary access, and lost-device procedures.
• Attack consideration: Repeated approval prompts can cause MFA fatigue; number matching and risk-based blocking reduce accidental approval.

VI. Applied Cloud Security

A. Real-time scenario-based case studies

Scenario-based cases show how technical controls, ownership decisions, and incident response operate together during active cloud events.

• Case 1, compromised administrator: An administrator approves a fraudulent MFA request, after which an attacker creates credentials for an application.
  • Sign-in risk alerts trigger account blocking; responders revoke sessions, remove unauthorized credentials, inspect audit logs, and require phishing-resistant MFA for privileged roles.
• Case 2, exposed web database: A team deploys an IaaS database with a public IP address and an inbound rule allowing port 1433 from 0.0.0.0/0.
  • Azure Policy denies the configuration; remediation uses a private endpoint, restricted network rules, database authentication controls, and monitored query logs.
• Case 3, departing employee: A developer downloads source code shortly before resignation and retains an active personal device session.
  • The leaver workflow disables the account, revokes tokens, removes group memberships, rotates accessible secrets, and preserves logs for investigation.
• Case 4, regulated-data deployment: A project team attempts to store personal data in an unapproved region.
  • Region restrictions block deployment; classification labels, encryption, retention rules, and documented access reviews provide continuing compliance evidence.