BSc CSIT (TU) Science Cloud Computing (BSc CSIT, CSC465) Question Paper 2075 Nepal

Security Issues and Challenges in Cloud Computing

In cloud computing, data and applications are hosted on infrastructure owned and controlled by a third-party provider and shared among many tenants over the public internet. This multi-tenant, outsourced, network-accessible model introduces a distinct set of security concerns.

Major Security Challenges

• Loss of control / data location: The customer no longer physically controls the hardware and may not know in which country/data center the data resides, raising legal and jurisdictional concerns.
• Multi-tenancy: Multiple customers share the same physical hardware; weak isolation can lead to data leakage or side-channel attacks between tenants.
• Data breaches and data loss: Centralized storage of large amounts of data makes the cloud an attractive target.
• Insecure interfaces/APIs: Cloud services are managed through APIs; weak authentication or input validation exposes the system.
• Account/credential hijacking through phishing or stolen keys.
• Insider threats from the provider's staff.
• Compliance and legal issues (e.g., GDPR, data sovereignty).
• Denial of Service (DoS/DDoS) attacks against shared infrastructure.

Data Security

Data must be protected in three states:

• Data at rest: Encrypt stored data using strong algorithms (AES-256). Manage encryption keys separately from the data.
• Data in transit: Use TLS/SSL to encrypt data moving between the client and the cloud and between cloud components.
• Data in use: Protected through access controls and emerging techniques such as homomorphic encryption and trusted execution environments.

Additional measures include data classification, tokenization, secure deletion, and backup/replication for availability.

Identity and Access Management (IAM)

IAM ensures that the right user has the right access to the right resource. Key elements:

• Authentication: Verifying identity using passwords, multi-factor authentication (MFA), and federated/single sign-on (SSO, SAML, OAuth, OpenID).
• Authorization: Granting permissions, typically via Role-Based Access Control (RBAC) or attribute-based policies, following the principle of least privilege.
• Accounting/Auditing: Logging who accessed what and when.
• Identity federation lets enterprise identities be used across cloud services.

Techniques to Ensure Confidentiality and Integrity

• Confidentiality: Encryption (symmetric AES, asymmetric RSA), access control, tokenization, and key management services (KMS/HSM).
• Integrity: Cryptographic hash functions (SHA-256), Message Authentication Codes (MAC) and digital signatures to detect tampering; checksums and versioning for stored objects; Proof of Retrievability / Provable Data Possession schemes to verify that the provider still holds the data intact.

Conclusion

Cloud security is a shared responsibility: the provider secures the underlying infrastructure while the customer secures data, identities and access configuration. A combination of encryption, strong IAM, auditing and compliance controls is required to achieve confidentiality, integrity and availability.

Service Level Agreement (SLA)

A Service Level Agreement (SLA) is a formal, legally-binding contract between a cloud service provider and a customer that defines the expected level of service, the metrics by which it is measured, the responsibilities of each party, and the penalties/remedies that apply if the agreed levels are not met. It converts qualitative expectations into measurable, enforceable terms.

Components of an SLA

• Service description: The exact services covered (e.g., compute, storage, database).
• Service Level Objectives (SLOs): Measurable targets such as availability/uptime (e.g., 99.9%), response time, throughput and latency.
• Performance metrics & measurement method: How each SLO is measured and reported.
• Roles and responsibilities of provider and customer.
• Penalties / service credits: Compensation (often credits) if targets are missed.
• Security and compliance obligations (data protection, certifications).
• Exclusions: Conditions not covered (e.g., scheduled maintenance, force majeure).
• Monitoring and reporting procedures.
• Termination and review clauses.

For example, uptime is computed as:

Quality of Service (QoS) in the Cloud

QoS refers to the overall measurable quality the service delivers, expressed through parameters such as availability, reliability, response time, throughput, latency, scalability and security. The SLA encodes the QoS guarantees the provider commits to.

How QoS is Managed and Monitored

1. Monitoring: Agents, probes and logging continuously collect metrics (CPU, memory, network latency, request rate, error rate, uptime).
2. Measurement against SLOs: Collected data is compared with the thresholds defined in the SLA.
3. Elastic resource provisioning: Auto-scaling and load balancing add/remove resources to keep performance within targets as demand changes.
4. Admission control and scheduling: Requests are scheduled and prioritized so that high-priority workloads meet their QoS.
5. Alerting and SLA enforcement: Violations trigger alerts; if SLOs are breached, service credits/penalties defined in the SLA are applied.
6. Reporting: Dashboards and periodic reports give the customer visibility into compliance.

Conclusion

The SLA is the contractual backbone of cloud services, and QoS management—through continuous monitoring, elastic provisioning, load balancing and SLA enforcement—ensures the provider actually delivers the promised service levels.

Layered (Service) Architecture of Cloud Computing

Cloud computing is commonly organized as a stack of service layers, where each upper layer is built on the services of the layer below:

• IaaS gives raw virtualized compute, storage and network; the user manages OS and applications.
• PaaS adds a managed runtime and tools so developers deploy code without managing servers.
• SaaS delivers complete applications; the user only consumes them.

Virtualization at the hardware layer is what enables resource pooling, on-demand provisioning and multi-tenancy across all upper layers.

NIST Cloud Reference Model (Actors)

The NIST cloud computing reference model defines five major actors:

• Cloud Consumer: Uses the service.
• Cloud Provider: Makes the service available (manages SaaS/PaaS/IaaS).
• Cloud Auditor: Independently assesses security, performance and SLA compliance.
• Cloud Broker: Intermediary that manages use, performance and delivery between consumers and providers.
• Cloud Carrier: Provides the connectivity/transport of services.

Role of the Cloud Broker

A cloud broker is an entity that manages the use, performance and delivery of cloud services and negotiates relationships between providers and consumers. It is useful when integrating services from multiple providers. Its functions include:

• Service Intermediation: Enhancing a service by adding capabilities (identity management, security, reporting).
• Service Aggregation: Combining multiple services into one (data integration, single sign-on across providers).
• Service Arbitrage: Like aggregation but with flexibility to choose among services dynamically to get the best price/performance.

Role of the Cloud Carrier

The cloud carrier provides the connectivity and transport of cloud services from the provider to the consumer, typically through telecommunication and network providers (the Internet, dedicated links). It ensures the network-level SLA (bandwidth, latency, encrypted/dedicated connections) so consumers can reliably reach the service.

Conclusion

The layered architecture (IaaS → PaaS → SaaS over a virtualized data center) describes what is delivered, while the NIST reference model—with its broker and carrier actors—describes who participates in delivering and consuming cloud services.

Elasticity is the ability of a cloud system to automatically provision and de-provision resources at runtime to closely match the current workload, so that the system uses exactly the resources it needs at any moment. It is dynamic and demand-driven.

Scalability is the ability of a system to handle increased load by adding resources, either vertically (scaling up: bigger machine) or horizontally (scaling out: more machines). It is about capacity to grow.

Key difference:

• Scalability is the static capability of growing (planned, often manual); elasticity is the dynamic, automatic, real-time adjustment of resources both up and down in response to load.
• Elasticity prevents over-provisioning (waste) and under-provisioning (poor performance) and underpins the pay-as-you-go model; scalability ensures the system can grow when needed.

In short, every elastic system is scalable, but not every scalable system is elastic.

Challenges in Migrating an Application to the Cloud

• Application compatibility / re-architecting: Legacy or monolithic applications may need redesign (re-platform or refactor) to run efficiently in the cloud.
• Data migration: Moving large volumes of data is time-consuming, costly and risky (downtime, corruption, bandwidth limits).
• Security and compliance: Ensuring data protection, encryption, and meeting regulatory/data-sovereignty requirements after the move.
• Downtime and business continuity: Minimizing service interruption during cut-over.
• Vendor lock-in: Proprietary services make future migration to another provider difficult.
• Performance and latency: Network latency between on-premises and cloud, or between components, may degrade performance.
• Cost estimation: Hidden costs (data egress, storage, API calls) can make the real cost hard to predict.
• Skills and tooling: Staff may lack cloud expertise; new monitoring/automation tools are needed.
• Integration and dependencies: Maintaining interfaces with systems that remain on-premises (hybrid setup).
• Testing and validation: Verifying functionality, security and performance post-migration.

Migration strategies (the "6 R's") such as Rehost (lift-and-shift), Replatform, Refactor, Repurchase, Retire and Retain are chosen per application to manage these challenges.

Cloud Storage

Cloud storage is a service model in which data is stored on remote servers maintained by a cloud provider and accessed over the network/Internet. The provider manages capacity, replication, durability and availability, and the customer pays for what is used (pay-as-you-go). Data is typically replicated across nodes/data centers for fault tolerance.

Types of Cloud Storage

1. Block Storage

• Data is split into fixed-size blocks, each with an address but no metadata.
• Behaves like a raw hard disk/volume attached to a VM; a file system or database is built on top.
• Low latency, high performance; ideal for databases, transactional workloads, OS disks.
• Example: Amazon EBS, OpenStack Cinder.

2. File Storage

• Data is stored as files in a hierarchical directory structure (folders/paths) and shared over protocols like NFS/SMB.
• Easy to use and share among multiple users/applications.
• Good for shared file systems, content repositories, home directories.
• Example: Amazon EFS, Azure Files.

3. Object Storage

• Data is stored as objects (data + rich metadata + unique ID) in a flat address space (buckets), accessed via HTTP/REST APIs.
• Highly scalable and durable; ideal for unstructured data—images, videos, backups, big-data, static web content.
• Example: Amazon S3, OpenStack Swift.

Google App Engine (GAE) as a PaaS Offering

Google App Engine is a Platform-as-a-Service (PaaS) product from Google Cloud that lets developers build and deploy web applications and backends without managing the underlying servers, OS, or infrastructure. Google handles provisioning, patching, load balancing and scaling.

Key Features

• Fully managed platform: No server administration; developers only upload code.
• Automatic scaling: Scales instances up and down (even to zero) automatically based on incoming traffic, supporting the pay-as-you-go model.
• Multiple language runtimes: Supports Python, Java, Go, PHP, Node.js, Ruby (Standard and Flexible environments).
• Integrated services: Built-in access to Datastore/Cloud Firestore, Memcache, Cloud SQL, Task Queues, authentication and logging.
• Sandbox environment (Standard) that isolates each application for security.
• Versioning and traffic splitting for easy deployment and A/B testing.
• Built-in load balancing and high availability across Google's infrastructure.

Advantages and Limitations

• Advantages: Fast development, no infrastructure management, automatic scaling, reliability, and tight integration with other Google Cloud services.
• Limitations: Some vendor lock-in, restrictions in the Standard sandbox (limited system calls, runtime constraints), and less low-level control than IaaS.

In summary, GAE is a classic PaaS that abstracts away infrastructure so developers focus purely on application code while Google manages scaling and operations.

Architecture of a Cloud Data Center

A cloud data center is the large physical facility that houses the compute, storage and networking resources that power cloud services, organized for scalability, virtualization, fault tolerance and efficiency.

Main Components / Layers

• Compute (servers): Racks of commodity servers running virtualization (hypervisors) to host many virtual machines/containers, enabling resource pooling and multi-tenancy.
• Storage: Networked storage systems (SAN/NAS, distributed object/block/file storage) with replication for durability.
• Networking: A typical hierarchical/leaf-spine topology connects servers:
  • Top-of-Rack (ToR) switches connect servers within a rack.
  • Aggregation/Spine switches connect racks.
  • Core routers connect the data center to the Internet/WAN.
  • Load balancers and firewalls manage traffic and security.
• Virtualization/Management layer: Hypervisors plus an orchestration/cloud management platform (e.g., OpenStack) that provisions, schedules and monitors resources and enforces SLAs.
• Support infrastructure: Redundant power supply (UPS, generators), cooling (HVAC), fire suppression and physical security to keep the facility highly available.

Key Architectural Goals

• Scalability through commodity hardware and horizontal expansion.
• High availability and fault tolerance via redundancy and replication.
• Efficiency via virtualization and consolidation (high utilization, lower cost).
• Multi-tenancy and isolation for many customers on shared hardware.

Modern data centers often span multiple availability zones/regions so that a failure in one zone does not bring down the service.

Multi-Tenancy

Multi-tenancy is an architectural principle in which a single instance of a software application (and its supporting infrastructure) serves multiple customers (tenants) simultaneously, while keeping each tenant's data and configuration logically isolated from the others. It is fundamental to the economics of SaaS because shared resources reduce cost per tenant.

Implementation Models in SaaS

Multi-tenancy can be implemented at the data level in three common ways:

1. Separate databases: Each tenant has its own database (strong isolation, higher cost, harder to scale).
2. Shared database, separate schemas: One database, one schema per tenant (moderate isolation).
3. Shared database, shared schema: All tenants share tables, distinguished by a TenantID column (most cost-efficient and scalable, but weakest isolation).

Implementation Issues in the SaaS Model

• Data isolation and security: Preventing one tenant from accessing another's data (a bug or SQL flaw can leak data); strict access control and tenant-aware queries are required.
• Performance/"noisy neighbor": One tenant's heavy load can degrade performance for others; needs throttling, quotas and resource governance.
• Customization: Different tenants want different features/UI/workflows from a single shared codebase—handled via configuration/metadata, not code forks.
• Scalability: The shared instance must scale as tenants and data grow.
• Maintenance and upgrades: A single shared codebase means upgrades affect all tenants at once and must be carefully managed.
• Backup, recovery and SLA per tenant: Per-tenant backup/restore and meeting individual SLAs in a shared system is complex.
• Compliance: Different tenants may have different regulatory/data-residency requirements.

Good multi-tenant SaaS design balances cost efficiency (sharing) against isolation, security and customizability.

Pay-As-You-Go Billing and Metering

Pay-as-you-go (PAYG), also called utility/usage-based pricing, is a cloud billing model in which customers are charged only for the resources they actually consume, with no large upfront capital investment. It treats computing like a utility (electricity/water): you pay for what you use.

Metering

Metering is the underlying process of measuring and recording resource consumption so it can be billed. The cloud platform continuously monitors usage of metered resources such as:

• Compute: vCPU/instance-hours.
• Storage: GB stored per month.
• Network: data transfer (especially egress) in GB.
• Requests/operations: number of API calls, transactions.
• Other services: database hours, function invocations, etc.

The metered usage is aggregated over a billing period and multiplied by the published unit rates. Conceptually:

Characteristics and Benefits

• No upfront cost / converts CapEx to OpEx.
• Cost scales with actual demand—you stop paying when you stop using (especially with auto-scaling and elasticity).
• Transparency via detailed usage reports and dashboards.
• Variants: reserved/spot pricing, free tiers and tiered/volume discounts complement basic PAYG.

Limitations

• Costs can be hard to predict and may grow unexpectedly without monitoring (e.g., high data-egress charges), so cost governance and budgeting are important.

In essence, metering measures consumption and PAYG turns that measurement into a fair, usage-based bill, which is one of the core economic advantages of cloud computing.

Fault Tolerance and High Availability in the Cloud

Fault tolerance is the ability of a system to continue operating correctly even when some components fail. High availability (HA) means the service remains accessible for a very high percentage of time (e.g., 99.99%) by minimizing downtime. The cloud achieves both mainly through redundancy and automation.

Techniques Used

• Redundancy: Duplicate critical components (servers, storage, network paths, power) so there is no single point of failure.
• Replication: Data is copied across multiple nodes/data centers so a failure does not cause data loss.
• Multiple Availability Zones / Regions: Resources are spread across geographically separate zones so a zone outage does not take the service down; supports disaster recovery.
• Load balancing: A load balancer distributes traffic across healthy instances and routes away from failed ones.
• Health checks and failover: Continuous monitoring detects failures; traffic/workload automatically fails over to standby/healthy resources.
• Auto-scaling and auto-healing: Failed instances are automatically replaced; capacity is adjusted to maintain performance.
• Clustering: Groups of servers act as one; if one fails, others take over.
• Backups and snapshots: Enable recovery after data corruption or major failures.
• VM live migration: Workloads are moved off failing hardware without interruption.

Summary

By combining redundancy, data replication, multi-zone deployment, load balancing, health-check-driven failover and auto-healing, cloud platforms eliminate single points of failure and keep services running with minimal downtime, satisfying the availability targets defined in the SLA.

Containerization

Containerization is a lightweight OS-level virtualization technique that packages an application together with all its dependencies, libraries and configuration into a single portable unit called a container. Containers run as isolated user-space processes on a shared host operating system kernel. Docker is the most common container engine, and Kubernetes is widely used to orchestrate containers at scale.

Key Points

• Containers share the host OS kernel but are isolated using namespaces and cgroups.
• They are portable ("build once, run anywhere") and start in seconds.
• They are lightweight, enabling high density (many containers per host) and fast deployment, making them ideal for microservices and CI/CD.

Containers vs Virtual Machines

Summary

A VM virtualizes the hardware (each VM runs a complete OS on a hypervisor), providing strong isolation but with heavy overhead. A container virtualizes the OS (sharing the host kernel), making it far more lightweight, faster to start and more portable, at the cost of slightly weaker isolation. The two are often combined—running containers inside VMs—to balance efficiency and security.