Unit 1: Understanding Cloud Security - Subjective Questions

Cloud security is the collection of policies, technologies, controls, and procedures used to protect cloud-based systems, applications, networks, and data.

Its major objectives are:

• Confidentiality: Prevent unauthorized access to information.
• Integrity: Ensure that data remains accurate, complete, and unaltered.
• Availability: Ensure that services and data are accessible when required.
• Authentication and authorization: Verify identities and control access to resources.
• Accountability: Record activities through logging, monitoring, and auditing.

Common cloud security methods include:

• Encryption of data at rest and in transit.
• Identity and Access Management using roles and least privilege.
• Network segmentation, firewalls, and security groups.
• Multi-Factor Authentication for sensitive accounts.
• Vulnerability assessment, patch management, and secure configuration.
• Continuous monitoring, incident response, backup, and disaster recovery.
• Compliance assessments and regular security audits.

The shared responsibility model states that cloud security responsibilities are divided between the cloud service provider and the customer.

• The cloud service provider is responsible for security of the cloud. This generally includes physical data centers, hardware, virtualization infrastructure, core networking, and the availability of the underlying platform.
• The customer is responsible for security in the cloud. This commonly includes identities, access permissions, data, applications, operating-system configuration, encryption settings, and network rules.

The division changes according to the service model:

• In IaaS, the customer manages the operating system, applications, data, and much of the network configuration.
• In PaaS, the provider manages the operating system and runtime platform, while the customer manages applications, data, and identities.
• In SaaS, the provider manages most infrastructure and application components, but the customer remains responsible for users, permissions, data governance, and secure configuration.

A customer cannot assume that moving data to the cloud transfers all security obligations to the provider.

The three service models differ mainly in how much infrastructure is managed by the provider.

In IaaS, the customer has greater control and therefore greater responsibility. In SaaS, the provider manages more technical layers, but the customer still controls how the service is used. For example, an incorrectly configured SaaS sharing permission can expose confidential data even when the provider's infrastructure is secure.

Common cloud security challenges include:

• Misconfiguration: Public storage, overly permissive firewall rules, or unrestricted administrative interfaces can expose resources.
• Weak identity controls: Shared accounts, weak passwords, excessive privileges, and missing MFA increase the risk of unauthorized access.
• Data protection difficulties: Organizations must protect data during transmission, storage, processing, backup, and deletion.
• Insecure APIs: Cloud services are controlled through APIs, so weak authentication or improper input validation can be exploited.
• Limited visibility: Dynamic and distributed cloud resources may make asset discovery, monitoring, and log analysis difficult.
• Insecure interfaces and applications: Vulnerable code, exposed keys, and unpatched systems can compromise services.
• Compliance and data residency: Data may be stored or processed in locations with different legal requirements.
• Shared infrastructure risks: Multi-tenant environments require strong logical isolation.
• Vendor dependency: Outages, provider changes, or lock-in can affect availability and recovery.
• Insider threats: Employees, contractors, or administrators may misuse legitimate access.

A cloud data breach occurs when an unauthorized person gains access to, discloses, changes, or destroys data stored or processed in a cloud environment.

Major causes include:

• Publicly exposed storage or databases.
• Stolen credentials and phishing attacks.
• Excessive permissions and unused accounts.
• Vulnerable applications or APIs.
• Malware, ransomware, or unpatched systems.
• Accidental data sharing or human error.

Effects may include financial loss, privacy violations, regulatory penalties, service disruption, intellectual property theft, and reputational damage.

Preventive controls include:

• Encrypting sensitive data at rest and in transit.
• Applying least privilege and MFA.
• Using secure configuration baselines and continuous posture monitoring.
• Performing vulnerability assessments and patching.
• Monitoring access logs and detecting unusual behavior.
• Classifying data and restricting external sharing.
• Maintaining tested backups and an incident response plan.
• Conducting employee security awareness training.

An insider threat originates from a person who has authorized access to an organization's systems or data.

• An accidental insider threat results from negligence, mistakes, or lack of awareness. Examples include sending a confidential file to the wrong recipient, publishing a storage resource publicly, or exposing an access key in source code.
• A malicious insider threat involves intentional misuse of legitimate access. Examples include stealing customer data, selling credentials, sabotaging services, or copying intellectual property before leaving an organization.

Mitigation measures include:

• Applying least privilege and role-based access control.
• Using MFA and privileged access management.
• Separating administrative duties and requiring approval for sensitive actions.
• Monitoring downloads, unusual locations, privilege changes, and mass data access.
• Using data loss prevention and cloud access security controls.
• Performing periodic access reviews and promptly removing terminated users.
• Protecting and auditing administrative logs.
• Providing security training and establishing clear reporting procedures.
• Combining technical monitoring with fair personnel and incident-response processes.

A compliance risk occurs when cloud usage violates legal, regulatory, contractual, or organizational requirements.

Important sources of risk include:

• Storing personal or regulated data in an unauthorized geographic region.
• Failing to apply required retention, deletion, or backup policies.
• Inadequate access control and absence of audit evidence.
• Using a provider that does not meet required security certifications.
• Incomplete breach notification procedures.
• Unapproved services or shadow IT.
• Lack of data classification and ownership.

Organizations can manage these risks by:

• Identifying applicable laws, standards, and contractual obligations.
• Classifying data according to sensitivity.
• Selecting providers with relevant certifications and transparent audit reports.
• Defining data residency, retention, encryption, and deletion requirements.
• Using IAM, logging, monitoring, and regular compliance assessments.
• Documenting responsibilities in contracts and service-level agreements.
• Maintaining evidence for audits and testing incident-response procedures.
• Reviewing provider and customer configurations continuously because cloud environments change frequently.

Identity and Access Management (IAM) is the framework used to create, authenticate, authorize, manage, and audit identities that access organizational resources.

IAM supports the following activities:

• Identification: Establishing who a user, service, device, or application is.
• Authentication: Verifying the claimed identity using passwords, tokens, certificates, or biometrics.
• Authorization: Determining which resources and actions are permitted.
• Accounting: Recording access and administrative activities for auditing.
• Lifecycle management: Creating, modifying, disabling, and deleting identities.

IAM improves cloud security by enforcing least privilege, centralizing access policies, supporting role-based access control, and reducing unauthorized access. It also enables MFA, single sign-on, conditional access, privileged identity management, and detailed audit logging. Effective IAM should cover human users, service accounts, applications, devices, external guests, and automated workloads.

The principle of least privilege requires each identity to receive only the permissions necessary to perform its authorized tasks, for only as long as those permissions are needed.

Role-Based Access Control (RBAC) assigns permissions to roles rather than directly to individual users. Users are then assigned appropriate roles.

For example:

• A billing employee may receive a Billing Reader role.
• An application administrator may receive permissions to restart application services but not to read customer records.
• A database administrator may manage database configuration but may be restricted from exporting sensitive data.

RBAC makes access easier to manage consistently, while least privilege limits the impact of compromised accounts or mistakes. Effective implementation includes separating duties, using temporary privileged access, reviewing role assignments, removing unused permissions, and avoiding broad roles such as unrestricted administrator access for routine work.

Azure Active Directory, now called Microsoft Entra ID, is a cloud identity and access management service.

Its main structural components are:

• Tenant: A dedicated directory instance representing an organization. It contains identities, groups, applications, devices, policies, and configuration.
• Users: Human identities used to access applications and resources.
• Groups: Collections of users or devices used to simplify permission assignment and policy application.
• Applications and service principals: Registered applications and their tenant-specific security identities. They allow applications to authenticate and access authorized resources.
• Devices: Registered or joined computers and mobile devices that can be evaluated by access policies.
• Roles: Administrative permission sets that control what administrators can manage.
• Directories and subscriptions: A tenant manages identities, while Azure subscriptions contain resources and trust the tenant for authentication.
• Authentication and authorization policies: Controls such as MFA, Conditional Access, and risk-based access determine whether access is allowed.

The tenant acts as the central identity boundary, while users, groups, applications, and devices are governed through its policies.

Secure user and group management should cover the complete identity lifecycle.

• Provisioning: Create accounts from an approved request and assign only required attributes and access.
• Authentication: Require strong credentials, MFA, and appropriate Conditional Access policies.
• Authorization: Assign access through well-defined groups and roles instead of individual ad hoc permissions.
• Periodic review: Revalidate group membership, privileged roles, guest accounts, and inactive identities.
• Role separation: Separate identity administration, security administration, and resource administration where possible.
• Offboarding: Disable accounts, revoke sessions and tokens, remove group memberships, and recover organizational devices when personnel leave.
• Guest management: Restrict external users, define expiration dates, and review their access regularly.
• Group governance: Use naming standards, owners, approval workflows, and expiration policies.
• Monitoring: Record sign-ins, role changes, membership changes, and unusual authentication events.

Automation can improve consistency, but automated provisioning must be tested so that incorrect group rules do not grant excessive access.

Multi-Factor Authentication (MFA) verifies a user's identity using at least two independent authentication factors.

The factors are:

• Something the user knows: A password or PIN.
• Something the user has: A hardware token, authenticator application, or registered phone.
• Something the user is: A fingerprint, facial pattern, or other biometric characteristic.

MFA reduces the likelihood that a stolen password alone will result in account compromise. It is particularly important for administrators, remote users, privileged applications, and access to sensitive data.

However, MFA is not a complete security solution. Risks include phishing of approval codes, SIM swapping, stolen devices, push-notification fatigue, weak recovery procedures, and poorly protected backup methods. Organizations should prefer phishing-resistant methods such as security keys or certificate-based authentication, apply MFA conditionally according to risk, protect recovery processes, and monitor authentication anomalies.

The methods provide different balances between protection and convenience.

• Password-based authentication: Easy to deploy, but vulnerable to phishing, reuse, guessing, credential stuffing, and database compromise. It should not be the only control for sensitive access.
• App-based MFA: Generates time-based codes or approval prompts. It provides stronger protection than passwords alone, although codes and prompts can still be phished or abused through push fatigue.
• Hardware security keys: Use a physical device and cryptographic protocols. They provide strong, phishing-resistant authentication, but require purchase, enrollment, user training, and secure backup keys.
• Biometric authentication: Uses characteristics such as fingerprints or facial recognition. It is convenient and difficult to forget, but biometric data cannot easily be changed after compromise and may have accuracy, privacy, or device-dependency concerns.

A strong design uses phishing-resistant authentication for privileged users, secure fallback methods, risk-based policies, and user-friendly enrollment and recovery procedures.

Likely causes include an incorrect network rule, a public endpoint, excessive database permissions, weak configuration review, missing posture monitoring, or an exposed administrative credential.

An appropriate response plan is:

1. Containment: Immediately restrict public access, preserve the current configuration, disable compromised credentials, and apply temporary network controls.
2. Investigation: Review database, identity, API, network, and cloud audit logs to determine the exposure period, accessed records, source locations, and possible data changes.
3. Eradication: Correct the configuration, rotate keys and passwords, remove unnecessary accounts, patch affected components, and verify that backups are not compromised.
4. Recovery: Restore normal service through a tested secure configuration and monitor closely for repeated access.
5. Notification: Consult legal, privacy, and compliance teams to determine whether customers, regulators, or partners must be notified.
6. Lessons learned: Identify the control failure, add policy-as-code checks, enforce private-by-default settings, require review for public exposure, and test the response process.

The attack may be a combination of credential phishing and MFA fatigue. The attacker obtains the user's password through a fake sign-in page and repeatedly sends approval requests. The employee may approve one request accidentally or to stop the repeated notifications. The attacker can then use the valid session to access cloud resources.

Controls should include:

• Use phishing-resistant authentication such as FIDO2 security keys or passkeys.
• Require number matching and provide clear sign-in context in approval prompts.
• Block legacy authentication protocols that bypass modern controls.
• Apply Conditional Access based on location, device compliance, risk, and application sensitivity.
• Train employees to reject unexpected prompts and report suspicious activity.
• Detect impossible travel, unfamiliar devices, risky sign-ins, and unusual data access.
• Provide rapid self-service reporting and account-lockout procedures.
• Revoke sessions and reset credentials after suspected compromise.
• Apply least privilege so that a compromised standard account cannot administer the tenant.

Encryption transforms readable plaintext into ciphertext using a cryptographic key.

• Data at rest is protected while stored in disks, databases, object storage, snapshots, and backups. Encryption limits the usefulness of copied storage media or improperly accessed files.
• Data in transit is protected while moving between users, applications, services, and networks. Secure protocols such as TLS help provide confidentiality and integrity during communication.

Important key-management practices include:

• Use strong, approved cryptographic algorithms and secure protocols.
• Store keys in a managed key vault or hardware security module rather than source code or plain configuration files.
• Restrict key access using least privilege and separate key administrators from data administrators.
• Rotate keys according to risk and policy.
• Maintain secure backups and recovery procedures for keys.
• Log and monitor key usage.
• Define key ownership, creation, expiration, revocation, and destruction procedures.
• Consider customer-managed keys when regulatory or separation-of-duty requirements demand additional control.

Logging creates a record of events, monitoring analyzes the behavior of systems and identities, and alerting notifies responsible personnel when defined conditions occur.

Useful cloud security logs include:

• Authentication and sign-in events.
• Administrative actions and configuration changes.
• Role and group membership changes.
• API calls and resource access.
• Network flow and firewall events.
• Storage downloads, sharing changes, and data access.
• Endpoint and application security events.

Effective monitoring should centralize logs, synchronize timestamps, protect logs from alteration, define suitable retention periods, and correlate events across services. Alerts should identify high-risk activities such as disabling security controls, creating privileged accounts, unusual geographic access, mass downloads, and repeated failed logins. Organizations must tune alert thresholds to reduce false positives and connect detections to an incident-response process. Logs are also important for forensics, compliance evidence, and accountability.

Defense in depth uses multiple independent security layers so that failure of one control does not automatically compromise the entire system.

For a cloud-hosted web application, the layers may include:

• Identity layer: MFA, least privilege, RBAC, and privileged access controls.
• Perimeter layer: Web application firewall, DDoS protection, and secure DNS.
• Network layer: Private subnets, segmentation, security groups, and restricted administrative access.
• Application layer: Secure coding, input validation, dependency scanning, and API authentication.
• Data layer: Encryption, tokenization, database permissions, and data loss prevention.
• Host and workload layer: Patching, hardened images, endpoint protection, and container controls.
• Detection layer: Centralized logs, threat detection, vulnerability monitoring, and alerting.
• Recovery layer: Immutable backups, tested restoration, and incident-response procedures.

This approach reduces both the probability of successful compromise and the impact when a control fails.

The three concepts represent different stages of access control:

• Authentication answers, "Who are you?" It verifies identity using credentials, MFA, certificates, or biometrics.
• Authorization answers, "What are you allowed to do?" It evaluates roles, policies, resource permissions, and conditions before granting an action.
• Accounting, also called auditing or accountability, answers, "What did you do?" It records successful and failed sign-ins, resource access, administrative changes, and other relevant actions.

All three are required. Authentication without authorization may allow an authenticated user to access everything. Authorization without reliable authentication cannot identify which person should receive permissions. Without accounting, an organization cannot investigate incidents, demonstrate compliance, identify misuse, or determine whether policies are effective. Together, they support controlled access and traceable activity.

The active account creates a serious risk because a former contractor may still authenticate and use permissions that are no longer justified. The confidential group membership increases the likelihood of unauthorized disclosure, while the absence of offboarding evidence may create compliance and audit problems.

Corrective actions include:

• Disable the account immediately and revoke active sessions, refresh tokens, and application passwords.
• Remove the contractor from all groups and administrative roles.
• Review sign-in, file-access, download, and sharing logs for activity after contract termination.
• Rotate credentials or secrets that the contractor could access.
• Determine whether confidential information was viewed or copied and follow breach procedures if required.
• Establish an identity lifecycle process linked to the human-resources or contractor-management system.
• Require manager approval, expiration dates, and periodic reviews for external accounts.
• Use automated joiner, mover, and leaver workflows.
• Maintain audit evidence showing timely deprovisioning and access reviews.