Chapter 2: Access Control and Identity Management Cloud Security - Unit II B.Tech - Computer Science / Information Science / Information Technology - Semester V Cloud Security A Comprehensive Undergraduate Textbook CHAPTER 2 Access Control and Identity Management Unit II: ACCESS CONTROL AND IDENTITY MANAGEMENT Sections Covered 2.1 Access Control Requirements for Cloud Infrastructure 2.2 User Identification Techniques 2.3 Authentication and Authorization Mechanisms 2.4 Role-Based Access Control (RBAC) 2.5 Multi-Factor Authentication (MFA) 2.6 Single Sign-On (SSO) 2.7 Identity Federation 2.8 Identity Providers and Service Consumers 2.9 Storage Access Control Options 2.10 Network Access Control Options 2.11 Operating System Hardening and Minimization 2.12 Verified and Measured Boot 2.13 Intrusion Detection Systems (IDS) 2.14 Intrusion Prevention Systems (IPS) Chapter 2: Access Control and Identity Management Cloud Security - Unit II Table of Contents Chapter Introduction / Overview Learning Outcomes Key Concepts 2.1 Access Control Requirements for Cloud Infrastructure 2.2 User Identification Techniques 2.3 Authentication and Authorization Mechanisms 2.4 Role-Based Access Control (RBAC) 2.5 Multi-Factor Authentication (MFA) 2.6 Single Sign-On (SSO) 2.7 Identity Federation 2.8 Identity Providers and Service Consumers 2.9 Storage Access Control Options 2.10 Network Access Control Options 2.11 Operating System Hardening and Minimization 2.12 Verified and Measured Boot 2.13 Intrusion Detection Systems (IDS) 2.14 Intrusion Prevention Systems (IPS) 2.15 Laboratory Exercise 2.16 Further Reading / Viewing 2.17 Assessment Questions Chapter Introduction / Overview Cloud computing allows organizations to use computing resources such as applications, servers, storage, databases, networking and analytics over the internet. This flexibility makes cloud computing powerful, but it also makes identity and access control one of the most important parts of cloud security. In a traditional organization, many users and systems operate inside a fixed network boundary. In cloud environments, users may connect from different locations, workloads may run across many regions, and resources may be accessed through APIs. Therefore, security cannot depend only on a network perimeter. It must strongly verify identity, enforce least privilege and continuously monitor access. Access control answers the question: who or what is allowed to access a resource, and under what conditions? Identity management answers the question: how do we create, verify, manage and retire identities for users, services, devices and workloads? Together, these two areas form the foundation for secure cloud usage. This unit explains access control requirements, user identification, authentication, authorization, RBAC, MFA, SSO, identity federation, identity providers, storage and network access control, operating system hardening, secure boot, measured boot, IDS and IPS. Each concept is explained with cloud-focused examples so that students can understand how real cloud infrastructure is protected. Did You Know? In cloud security, identity is often called the new perimeter because cloud users, APIs and workloads may be outside a fixed campus network. Strong identity controls are therefore essential before any resource is accessed. Learning Outcomes Upon successful completion of this chapter, students will be able to: 1. Define access control and explain why it is critical in cloud infrastructure. 2. Describe different user identification techniques used in cloud environments. 3. Differentiate between authentication and authorization with suitable examples. 4. Explain role-based access control and design simple RBAC policies. 5. Understand multi-factor authentication, single sign-on and identity federation. 6. Identify the roles of identity providers and service consumers in federated access. 7. Compare storage and network access control options in cloud platforms. Chapter 2: Access Control and Identity Management Cloud Security - Unit II 8. Explain operating system hardening, minimization, secure boot and measured boot. 9. Differentiate between IDS and IPS and describe their role in cloud security monitoring. 10. Apply access control principles to design a secure cloud environment for a small organization. Key Concepts Term Meaning Access Control The process of deciding whether a subject such as a user, device or service can perform an action on a resource. Identity A digital representation of a user, application, service, device or workload. Authentication The process of verifying that an entity is who or what it claims to be. Authorization The process of deciding what an authenticated entity is allowed to do. RBAC Role-Based Access Control; permissions are assigned to roles, and users are assigned to roles. MFA Multi-Factor Authentication; identity verification using two or more factor types. SSO Single Sign-On; a user logs in once and accesses multiple applications without repeated logins. Identity Federation A trust relationship where one organization or service accepts identity assertions from another trusted identity provider. IdP Identity Provider; a system that authenticates users and issues identity tokens or assertions. Service Consumer / Service Provider An application or cloud service that relies on an identity provider to verify users. Secure Boot A boot protection technique that allows only trusted, signed boot software to run. Measured Boot A technique that records cryptographic measurements of boot components, usually using a TPM. IDS Intrusion Detection System; detects suspicious activity and raises alerts. IPS Intrusion Prevention System; detects and attempts to block malicious traffic or actions. 2.1 Access Control Requirements for Cloud Infrastructure Access control requirements define how cloud resources should be protected from unauthorized use. A cloud infrastructure contains many types of resources such as virtual machines, containers, storage buckets, databases, APIs, secrets, networks and management consoles. Each resource must have clear rules that specify who can access it, what actions are permitted and from which conditions access is allowed. Cloud access control must support both human users and non-human identities. Non-human identities include service accounts, machine identities, workloads, API clients, automation scripts and containers. These identities are powerful because they often run continuously and may have access to sensitive data. Therefore, they must be managed with the same seriousness as human accounts. A strong cloud access control design normally follows the principle of least privilege. This means that a user or workload should receive only the permissions required to perform its job, and no unnecessary permissions should be granted. It also follows separation of duties, where critical actions are divided among different people or roles to reduce misuse. Chapter 2: Access Control and Identity Management Cloud Security - Unit II Figure 2.1: Identity-centric access architecture for cloud infrastructure Requirement Explanation Cloud Example Unique identity Every user, device and workload should have a unique identity. Each administrator has an individual account instead of sharing a common admin login. Least privilege Only required permissions should be assigned. A backup service can read database snapshots but cannot delete production databases. Strong authentication Access should require strong proof of identity. Console login requires password plus MFA or passkey. Fine-grained authorization Permissions should specify exact actions on exact resources. Allow read access to one storage bucket, not all buckets. Context awareness Access decisions may consider device, location, risk, time and network. Block admin access from unknown countries or unmanaged devices. Centralized logging Access decisions and activities should be logged. IAM audit logs are sent to a SIEM for investigation. Lifecycle management Accounts must be created, changed and removed at the right time. Remove access immediately when an employee leaves the organization. Best Practice Avoid long-lived administrator credentials. Use centralized identity, role-based access, just-in-time privilege elevation and full audit logging for sensitive operations. 2.2 User Identification Techniques User identification is the process of recognizing a user or entity before authentication and authorization can occur. Identification does not prove that the user is genuine; it only establishes which identity is being claimed. For example, entering a username identifies a user, but entering a password, biometric factor or security key authenticates the user. In cloud environments, identification may apply to employees, customers, administrators, service accounts, virtual machines, containers, serverless functions and APIs. A good identification system should be unique, consistent, traceable and resistant to impersonation. Technique Description Advantages Limitations Username or email ID User enters a unique name or email address. Simple and easy to manage. Can be guessed, enumerated or reused across services. Employee ID / student ID Organization-issued unique identifier. Useful in institutions and internal systems. May not work across partner systems. Digital certificate Identity is represented using a Strong for devices, servers Requires certificate lifecycle Chapter 2: Access Control and Identity Management Cloud Security - Unit II certificate issued by a trusted authority. and mutual TLS. management. API key / client ID Application or script identifies itself using a generated key or ID. Simple for service-to-service calls. Unsafe if exposed or not rotated. Service account Non-human identity created for applications and workloads. Supports automation without personal user accounts. May become over-privileged if not reviewed. Workload identity Identity tied to a running workload, VM, container or function. Reduces need for static secrets. Requires platform support and careful configuration. Biometric identifier Physical feature such as fingerprint or face is associated with identity. Convenient for user verification. Needs privacy protection and secure storage of templates. Important Point Identification is not the same as authentication. A username says who is claiming access. Authentication proves that the claimant is genuine. 2.3 Authentication and Authorization Mechanisms Authentication and authorization are closely related but different. Authentication verifies identity, while authorization grants or denies permission after identity has been verified. In a cloud environment, both steps are usually enforced before access is allowed to cloud resources. Authentication mechanisms include passwords, passkeys, OTPs, authenticator apps, hardware security keys, certificates, biometrics and federated tokens. Authorization mechanisms include IAM policies, roles, groups, access control lists, attribute-based policies and resource-level permissions. Aspect Authentication Authorization Main question Are you really who you claim to be? What are you allowed to do? Occurs when Before a user or service is trusted. After identity is verified. Common mechanisms Password, MFA, certificate, token, biometric. RBAC, ABAC, ACL, IAM policy, resource policy. Failure result Login or session is denied. Specific action or resource access is denied. Cloud example Admin signs in using MFA. Admin can restart VM but cannot delete database backups. Authorization decisions should be explicit and auditable. A secure design should deny access by default and allow access only through clearly defined policies. This approach reduces accidental exposure caused by broad permissions. Authorization Model How It Works Example Discretionary Access Control (DAC) Resource owner controls access to the resource. A file owner grants read access to another user. Mandatory Access Control (MAC) Central security labels and rules control access. Only users with a matching security clearance can access classified data. Role-Based Access Control (RBAC) Permissions are assigned to roles; users are assigned to roles. Helpdesk role can reset passwords but cannot change network settings. Attribute-Based Access Control (ABAC) Access depends on attributes such as user department, device status, location and time. Allow access only if user is in Finance and device is compliant. Policy-Based Access Control Formal policies evaluate identity, action, resource and context. Cloud IAM policy permits a service to read only one object prefix. 2.4 Role-Based Access Control (RBAC) Role-Based Access Control is a widely used access control model in cloud systems. Instead of assigning permissions directly to every user, permissions are grouped into roles. Users or groups are then assigned to these roles. This makes administration easier and reduces errors. Chapter 2: Access Control and Identity Management Cloud Security - Unit II RBAC is useful because organizations usually have repeated job functions. For example, a developer, database administrator, network administrator, security auditor and billing manager need different permissions. RBAC allows each job function to receive a suitable permission set. Figure 2.2: Role-Based Access Control model RBAC Component Meaning Example User A human account, application account or service account. alice@college.edu Group A collection of users with similar access needs. Cloud-Developers group Role A named set of permissions. ReadOnlyAdmin, StorageBackupOperator Permission Allowed action on a resource. Read logs, create VM, update firewall rule Policy Formal statement that grants or denies access. Allow read-only access to audit logs Role assignment Binding between user/group and role. Developers group receives DeployApplication role RBAC Design Rule Create roles based on job responsibility, not on individual preference. Avoid assigning broad administrator roles when task- specific roles are enough. Role Typical Permissions Should Not Have Cloud Viewer View dashboards, inventory and logs. Delete resources or change configuration. Developer Deploy application code to development environment. Modify production security policies. Database Operator Backup, restore and monitor databases. Change network firewall rules. Security Auditor Read security logs and compliance reports. Modify or delete logs. Billing Manager View billing, budgets and cost reports. Access production data. 2.5 Multi-Factor Authentication (MFA) Multi-Factor Authentication strengthens login security by requiring two or more different forms of evidence. The three common factor categories are something you know, something you have and something you are. A password alone is only one factor and may be stolen through phishing, reuse or credential leaks. Chapter 2: Access Control and Identity Management Cloud Security - Unit II MFA is especially important for cloud administrator accounts, remote access, identity provider accounts, privileged users and accounts that can access sensitive data. Modern security guidance recommends phishing- resistant MFA, such as security keys or passkeys, for high-risk accounts. Factor Type Examples Strengths Weaknesses Something you know Password, PIN, security answer. Easy to deploy. Can be guessed, stolen or phished. Something you have Authenticator app, OTP token, hardware key, passkey device. Stronger than password alone. Device may be lost; OTP can still be phished. Something you are Fingerprint, face recognition, iris pattern. Convenient and hard to share. Requires privacy and secure biometric handling. Something you do Typing pattern, behavior pattern. Useful for continuous risk analysis. May be less reliable as a primary factor. Somewhere you are Known network or geolocation signal. Helpful for risk-based access. Can create false positives or privacy concerns. Security Reminder MFA should not be disabled for convenience. Emergency break-glass accounts should be tightly controlled, monitored and reviewed regularly. 2.6 Single Sign-On (SSO) Single Sign-On allows a user to authenticate once with a trusted identity system and then access multiple applications without entering separate credentials for each application. SSO improves user convenience and centralizes authentication policies. In cloud environments, SSO is commonly implemented using standards such as SAML and OpenID Connect. A user logs in to an identity provider, and the identity provider issues a token or assertion to the application. The application trusts the identity provider and uses the token to establish a session. Figure 2.3: SSO and identity federation flow SSO Benefit Explanation Centralized login control Password policy, MFA policy and session rules are managed in one place. Reduced password fatigue Users do not need to remember many application passwords. Faster onboarding New users can be given access to multiple applications through groups and roles. Faster offboarding Disabling one identity can remove access from many applications. Improved monitoring Login events are easier to audit because they pass through a central identity system. Risk Mitigation Chapter 2: Access Control and Identity Management Cloud Security - Unit II Compromise of central identity account affects many applications. Use phishing-resistant MFA, strong monitoring and conditional access. Incorrect federation configuration can allow unauthorized access. Validate issuer, audience, certificate, redirect URI and token lifetime. Long sessions may remain active after risk changes. Use session timeout, re-authentication and risk-based access policies. Application does not map claims correctly. Test role/attribute mapping and use least privilege defaults. 2.7 Identity Federation Identity federation is a trust relationship between identity domains. It allows one system to accept identity information issued by another trusted system. For example, a college may use its own identity provider to allow students and staff to sign in to cloud-based learning applications without creating separate passwords in every application. Federation typically uses tokens or assertions. These assertions contain information such as user identifier, issuer, audience, validity period, authentication method and attributes such as role or department. The receiving service validates the token before creating a session or granting access. Federation Element Purpose Identity Provider (IdP) Authenticates the user and issues token or assertion. Service Provider / Relying Party Application that relies on the identity provider. Trust metadata Defines endpoints, certificates, signing keys and issuer information. Assertion / token Carries verified identity claims from IdP to service. Claims / attributes Information such as name, email, role, department or group. Audience Identifies the intended service that may accept the token. Token lifetime Limits how long the token remains valid. Important Point Federation does not mean blind trust. The service must verify the token signature, issuer, audience, expiry time and claims before allowing access. Protocol Common Use Main Idea SAML 2.0 Enterprise web SSO and cloud SaaS applications. Exchanges XML-based authentication and authorization assertions. OpenID Connect (OIDC) Modern web, mobile and API-based sign- in. Adds an identity layer on top of OAuth 2.0 and uses ID tokens. OAuth 2.0 Delegated authorization for APIs. Allows a client to access resources with scoped access tokens. LDAP / Directory Integration Internal enterprise identity directories. Applications query a directory or sync identities from it. 2.8 Identity Providers and Service Consumers An Identity Provider is responsible for authenticating users and issuing trusted identity information. A service consumer, also called a relying party or service provider, is the application that consumes this identity information to allow or deny access. In cloud computing, many services do not store passwords directly. Instead, they rely on identity providers for sign-in. Responsibility Identity Provider Service Consumer / Relying Party Primary role Authenticates users and issues tokens. Accepts tokens and provides application access. Stores credentials? Usually yes, or connects to a credential store. Usually no; relies on IdP token. Controls MFA? Usually enforces MFA and conditional access. May request step-up authentication for sensitive actions. Maintains application session? May maintain IdP session. Maintains application session after token validation. Example Microsoft Entra ID, Google Workspace, Okta, Keycloak. Cloud dashboard, SaaS application, internal web app. Chapter 2: Access Control and Identity Management Cloud Security - Unit II The security of this relationship depends on proper configuration. The identity provider must protect credentials and signing keys. The service consumer must validate the token correctly and map user claims to proper roles. If the mapping is too broad, users may get excessive privileges. Configuration Checklist Check issuer, audience, redirect URI, token lifetime, signing certificate, clock skew, group-to-role mapping and logout behavior before enabling production SSO. 2.9 Storage Access Control Options Cloud storage systems store objects, files, block volumes, backups, snapshots and database data. Storage access control is critical because misconfigured storage is a common cause of data exposure. Access must be controlled at account, bucket, folder, object, volume and key-management levels. Figure 2.4: Storage and network access controls in cloud infrastructure Storage Control Purpose Example IAM policy Grants identity-based access to storage actions. Allow backup role to read objects in backup bucket. Bucket / resource policy Defines access rules directly on storage resource. Deny public access to all objects. Access Control List (ACL) Legacy or object-level permission control. Grant read access to a specific object. Encryption key policy Controls who can use encryption or decryption keys. Only database service role can decrypt customer data. Network restriction Limits storage access to approved networks or endpoints. Allow storage access only from private VPC endpoint. Versioning and retention Protects against accidental deletion or ransomware. Keep object versions for 30 days. Access logging Records who accessed what and when. Storage access logs sent to security analytics. Best Practice For sensitive storage, combine IAM permissions, resource policies, encryption, private network endpoints, versioning, retention and logging. Do not depend on only one control. Chapter 2: Access Control and Identity Management Cloud Security - Unit II 2.10 Network Access Control Options Network access control protects the communication paths between users, applications and cloud resources. In cloud environments, network controls are usually software-defined. They include virtual networks, subnets, route tables, firewalls, security groups, network ACLs, private endpoints and web application firewalls. Control Option Layer / Scope Purpose Example Virtual Private Cloud / VNet Network boundary Creates isolated virtual network space. Production workloads run in a private VPC. Subnet Network segment Separates application tiers. Public subnet for load balancer; private subnet for database. Security group Instance or interface level Stateful allow rules for traffic. Allow HTTPS from load balancer to web server. Network ACL Subnet level Stateless allow/deny rules. Block traffic from a malicious IP range. Cloud firewall Network edge or centralized inspection Inspects and filters traffic. Block known command-and- control domains. WAF Application layer Protects web applications from attacks. Block SQL injection and cross-site scripting patterns. Private endpoint Private service access Avoids public internet exposure. Database accessed only through private endpoint. VPN / Direct connection Hybrid connectivity Connects enterprise network to cloud securely. Campus network connects to cloud VPC via VPN. Network access control should be designed with defense in depth. Even if an attacker compromises one system, segmentation should limit lateral movement. Sensitive databases, management interfaces and internal APIs should not be exposed directly to the public internet. Remember Security groups are usually stateful, while network ACLs are often stateless in many cloud platforms. Always check the specific cloud provider behavior before designing rules. 2.11 Operating System Hardening and Minimization Operating system hardening means configuring an OS to reduce vulnerabilities and limit the damage caused by compromise. Minimization means removing unnecessary software, services, accounts, ports and features. In cloud infrastructure, OS hardening is important for virtual machines, container hosts, bastion servers and administrative workstations. A default operating system installation usually includes many features that may not be needed for a particular workload. Every unnecessary package, open port or service increases the attack surface. Hardening reduces this attack surface and improves security posture. Hardening Area Recommended Action Reason Patch management Apply OS and security updates regularly. Reduces exposure to known vulnerabilities. Service minimization Disable or remove unused services. Fewer services mean fewer attack paths. Account control Disable default accounts and avoid shared admin accounts. Improves accountability and reduces misuse. Privilege management Use least privilege and sudo / elevation when required. Limits damage from compromised accounts. Firewall configuration Allow only required inbound and outbound ports. Restricts unwanted network access. Logging and auditing Enable security logs, login logs and command auditing. Supports investigation and compliance. Secure configuration baseline Use CIS or organizational security baseline. Creates consistent and repeatable security settings. Malware protection / EDR Use endpoint monitoring where appropriate. Detects suspicious processes and file changes. Secrets protection Avoid storing passwords and keys in plain files. Prevents credential theft. Chapter 2: Access Control and Identity Management Cloud Security - Unit II # Example Linux hardening checks for students sudo apt update && sudo apt upgrade sudo systemctl list-unit-files --type=service sudo ss -tulpen sudo ufw status sudo passwd -l unused_user sudo auditctl -s Laboratory Tip Before hardening a production system, test the changes in a lab or staging environment. Incorrect hardening can accidentally block applications or administrators. 2.12 Verified and Measured Boot Verified boot and measured boot protect the system startup process. Boot-level attacks are dangerous because malware that runs before the operating system can hide from normal security tools. Cloud platforms and modern operating systems use hardware-backed trust, firmware validation and cryptographic measurements to protect boot integrity. Verified boot checks whether boot components are trusted before allowing them to run. Secure Boot is a common example, where firmware verifies digital signatures of boot software. Measured boot records measurements, such as cryptographic hashes, of each boot component into a trusted hardware component such as a TPM. These measurements can later be used for attestation. Figure 2.5: Secure boot, measured boot and operating system hardening chain Concept Meaning Purpose Root of Trust A trusted hardware or firmware component that starts the chain of trust. Provides a reliable starting point. Secure / Verified Boot Allows only trusted signed boot components to execute. Prevents unauthorized bootloaders or bootkits. Measured Boot Records measurements of firmware, bootloader and OS components. Provides evidence of how the system booted. TPM Hardware security module used to store keys and measurements. Supports attestation and key protection. Attestation A process of proving the integrity state of a system to another service. Allows cloud platform to trust only healthy hosts. Runtime protection Security controls after OS starts. Complements boot protection with monitoring and hardening. Important Point Secure boot prevents untrusted boot components from loading. Measured boot records what loaded. Both are stronger when combined with attestation and monitoring. Chapter 2: Access Control and Identity Management Cloud Security - Unit II 2.13 Intrusion Detection Systems (IDS) An Intrusion Detection System monitors network traffic, host activity or application events to identify suspicious behavior. IDS tools usually generate alerts rather than automatically blocking traffic. Security teams use these alerts to investigate possible incidents. In cloud environments, IDS may be deployed at different levels. A network-based IDS can inspect traffic between subnets or through a virtual appliance. A host-based IDS can monitor file changes, processes and logins inside a VM. Cloud-native detection services can analyze API calls, identity activity, flow logs and threat intelligence. Figure 2.6: IDS and IPS processing flow IDS Type Monitors Example Use Network-based IDS Packets and network traffic. Detect scanning, command-and-control traffic or suspicious connections. Host-based IDS Files, processes, user logins and OS events. Detect unauthorized file changes or privilege escalation. Wireless IDS Wireless network activity. Detect rogue access points or suspicious wireless behavior. Network behavior analysis Traffic patterns and unusual flows. Detect abnormal data exfiltration or DDoS-like behavior. Cloud-native IDS / threat detection Cloud logs, API calls and identity events. Detect unusual IAM activity or compromised credentials. Detection Method Explanation Strength Limitation Signature-based Matches known attack patterns. Good for known threats. May miss new attacks. Anomaly-based Detects deviation from normal behavior. Can detect unknown threats. May produce false positives. Heuristic / rule-based Uses expert rules and conditions. Flexible and understandable. Needs regular tuning. Threat intelligence-based Uses known malicious IPs, domains and indicators. Useful for current threats. Depends on quality of intelligence feed. Security Reminder An IDS is valuable only when alerts are reviewed, tuned and connected to incident response. Too many false alerts can cause alert fatigue. Chapter 2: Access Control and Identity Management Cloud Security - Unit II 2.14 Intrusion Prevention Systems (IPS) An Intrusion Prevention System goes one step beyond detection. It is usually deployed inline so that traffic passes through it. When malicious activity is detected, an IPS can drop packets, block connections, reset sessions, quarantine traffic or update firewall rules. IPS can reduce the time between detection and response, but it must be configured carefully. A poorly tuned IPS may block legitimate traffic and affect business operations. Therefore, IPS deployment often starts in monitoring mode before prevention rules are enabled. Feature IDS IPS Primary function Detect and alert. Detect and block/prevent. Deployment Often out-of-band or passive. Usually inline with traffic path. Action Generates alert or log. Drops, blocks, resets or quarantines. Risk May miss active prevention. May block legitimate traffic if misconfigured. Best use Monitoring, investigation and compliance. Active protection against known threats and policy violations. IPS Action Description Cloud Example Drop packet Discard malicious traffic. Drop exploit payload detected in HTTP traffic. Reset connection Terminate suspicious connection. Close session from known malware host. Block source Temporarily or permanently block an IP or identity. Add IP to deny list after repeated attack attempts. Rate limit Reduce traffic rate from suspicious source. Limit DDoS-like traffic patterns. Quarantine workload Isolate a suspected compromised VM or container. Move VM to restricted security group. Alert and ticket Notify security team for response. Create incident ticket for SOC review. Best Practice Use IDS/IPS together with logging, SIEM, vulnerability management, endpoint detection, backup and incident response. No single control is enough for cloud security. 2.15 Laboratory Exercise Laboratory Title: Design a Cloud IAM and Access Control Plan for a College Web Application Scenario: A college hosts a web application in the cloud. The application has students, faculty, developers, database administrators and security auditors. It uses object storage for documents, a database for records and virtual machines for application hosting. Tasks: 11. Identify all human and non-human identities required for the system. 12. Design at least five RBAC roles: Student, Faculty, Developer, Database Operator and Security Auditor. 13. Define permissions for storage, database, virtual machines and logs. 14. Recommend MFA requirements for administrators and privileged users. 15. Design an SSO flow using an identity provider and cloud application. 16. Propose storage access control settings for public and private documents. 17. Propose network controls using public subnet, private subnet, firewall and security groups. 18. List five OS hardening steps for the application server. 19. Explain where IDS and IPS can be deployed and what alerts/actions are expected. 20. Prepare a one-page diagram of the proposed security architecture. Deliverable Marks Identity and role list 10 RBAC permission table 20 SSO/MFA explanation 15 Storage and network access control design 20 Hardening, IDS and IPS plan 20 Neat diagram and clarity 15 Chapter 2: Access Control and Identity Management Cloud Security - Unit II 2.16 Further Reading / Viewing Resource Type Resource Reason for Recommendation Official Standard NIST SP 800-207: Zero Trust Architecture Explains identity-aware, least-privilege and resource-focused access security. Official Guideline NIST SP 800-63-4: Digital Identity Guidelines Current NIST guideline for identity proofing, authentication and federation. Official Control Catalog NIST SP 800-53 Revision 5 Provides security and privacy control families such as Access Control and Identification and Authentication. Government Guidance CISA MFA guidance Explains the importance of MFA and phishing-resistant MFA. Technical Specification OpenID Connect Core 1.0 Useful for understanding modern identity tokens and cloud SSO. Technical Standard OASIS SAML 2.0 Important enterprise SSO and federation standard. Operating System Security Microsoft Secure Boot and TPM documentation Useful for understanding verified boot, measured boot and platform integrity. NIST Publication NIST SP 800-94: Guide to Intrusion Detection and Prevention Systems Explains IDS/IPS technologies, types and deployment considerations. Suggested Viewing Students may practice this unit by drawing an IAM architecture for any familiar application such as a college portal, hospital system, online shopping system or library management system. 2.17 Assessment Questions Part A - Multiple Choice Questions (1 Mark Each) Q1. Which principle states that users should receive only the permissions required for their work? a. Maximum privilege b. Least privilege c. Open access d. Shared administration Answer: (b) Q2. What does authentication verify? a. What a user is allowed to do b. Whether a user identity is genuine c. How much storage is used d. Which subnet is public Answer: (b) Q3. Which access control model assigns permissions to roles and users to roles? a. RBAC b. DAC only c. Packet filtering d. Encryption Chapter 2: Access Control and Identity Management Cloud Security - Unit II Answer: (a) Q4. Which of the following is an example of MFA? a. Password only b. Username only c. Password plus hardware security key d. Email address only Answer: (c) Q5. What is the main purpose of SSO? a. Encrypt storage b. Allow one login to access multiple applications c. Remove all passwords without replacement d. Disable audit logging Answer: (b) Q6. What does an Identity Provider do? a. Only stores files b. Authenticates users and issues tokens or assertions c. Blocks packets only d. Runs virtual machines Answer: (b) Q7. Which control is commonly used to allow inbound traffic to a cloud VM? a. Security group b. Spreadsheet c. Screen saver d. Mouse driver Answer: (a) Q8. What does measured boot record? a. Only username length b. Boot component measurements c. Monthly bill d. Screen resolution Answer: (b) Q9. What is the main difference between IDS and IPS? a. IDS alerts; IPS can block b. IDS encrypts; IPS decrypts c. IDS manages billing; IPS manages storage d. There is no difference Chapter 2: Access Control and Identity Management Cloud Security - Unit II Answer: (a) Q10. Which item is part of operating system hardening? a. Enable all services b. Use shared admin account c. Disable unused services and patch regularly d. Keep default passwords Answer: (c) Part B - Short Answer Questions (5 Marks Each) 21. Define access control. Why is it important in cloud infrastructure? 22. Explain the difference between identification, authentication and authorization. 23. What is RBAC? Explain with a cloud example. 24. Explain MFA and list the common factor categories. 25. What is SSO? Mention two advantages and two risks. 26. Define identity federation and explain the role of tokens or assertions. 27. Differentiate between an identity provider and a service consumer. 28. List any five storage access control options in cloud computing. 29. Explain security groups, network ACLs and firewalls in cloud networking. 30. What is operating system hardening? Give five hardening steps. 31. Explain verified boot, measured boot and TPM. 32. Differentiate between IDS and IPS. Part C - Long Answer / Essay Questions (10 Marks Each) 33. Explain access control requirements for cloud infrastructure in detail. Include least privilege, separation of duties, lifecycle management and logging. 34. Discuss authentication and authorization mechanisms used in cloud security. Explain with examples from cloud IAM. 35. Explain RBAC in detail. Design an RBAC model for a college cloud application with students, faculty, administrators and auditors. 36. Discuss MFA, SSO and identity federation. Explain how they work together in a modern cloud environment. 37. Explain storage and network access control options in cloud computing. Include IAM policies, bucket policies, security groups, firewalls and private endpoints. 38. Discuss operating system hardening, minimization, verified boot and measured boot. Explain their importance in cloud virtual machines. 39. Explain IDS and IPS in detail. Include types, detection methods, deployment models and limitations. Part D - Analytical / Case-Based Questions Case Study. A startup stores customer invoices in cloud object storage. A developer accidentally makes the bucket public. Explain which access control options should be used to prevent this mistake. Analyse. An organization uses SSO but does not enforce MFA for administrators. Explain the security risk and suggest improvements. Practical Design. Design a secure cloud network for a web application with web, application and database tiers. Mention subnets, security groups and firewall rules. Troubleshooting. An IPS blocks legitimate application traffic after a new rule update. Explain how the security team should investigate and tune the IPS. Policy Design. Write a brief RBAC policy plan for a cloud security auditor who must read logs but must not modify or delete them. End of Chapter