Security Considerations for Platform as a Service (PaaS)
With the PaaS (Platform as a Service) model the vendor offers a complete development environment in which application developers can then create and deploy their code. This approach means that instead of building a server environment to run an application and installing a development environment to create applications on that server, the customer can simply connect to a PaaS cloud provider and by using a PaaS compliant development tool, start creating applications that can be deployed worldwide without any delay. The vendor will typically provide code building blocks so that the customer can build applications rapidly and the development environment can either be web-based or by using a development environment on the local computer. Microsoft Windows Azure is one example of a PaaS offering.
Note:
This document is part of a collection of documents that comprise the Reference Architecture for Private Cloud document set. The Reference Architecture for Private Cloud documentation is a community collaboration project. Please feel free to edit this document to improve its quality. If you would like to be recognized for your work on improving this article, please include your name and any contact information you wish to share at the bottom of this page.
Security considerations for PaaS include access and authorization issues, working with distributed applications, and storage and data security.
Authentication, Access Control and Authorization (AAA)
Unlike traditional client-based software development using tools such as Microsoft Visual Studio, PaaS offers a shared development environment, so authentication, access control, and authorization mechanisms must combine to ensure that customers are kept completely separate from each other.
A strong and effective authentication framework is essential to ensure that individual users can be correctly identified without the authentication system succumbing to the numerous possible attacks. Attack vectors on cloud-based environments are similar to those encountered in non-cloud environments and include:
- Impersonation
- Phishing and social engineering attacks
- Brute force (dictionary) attacks
- Password reset attacks
Two-factor authentication such as smartcards or biometric mechanisms can provide increased protection from these attacks but at the expense of greater complexity and longer provisioning cycles. In most cases, PaaS vendors still rely on user name and passwords for authentication and then implement a mechanism that provides access control to data and application-level authorization based on verification of these credentials. They might use some technique for enhancing the security of the authentication process, such as only requesting three characters from the password or answering a "secret question" or identifying a pre-agreed upon image.
A major difference between PaaS cloud solutions and on-premise solutions is that the authentication mechanism may be externalized and use a claim-based identities from one or more WS-* or SAML-based identity provider. Whatever the mechanism that they use, what you must consider is the level of security provided.
When considering a PaaS vendor, look at the operational standards that they implement.
- What are their password complexity requirements and how do they protect credentials?
- Do they enforce changing passwords on a reasonable timescale?
- What do they do to prevent password compromise?
If you are proposing moving to a cloud-based environment, you should require that the cloud vendor’s security policies and procedures is at least as stringent as your own. Although you may be meticulous at choosing complex passwords for your cloud-based accounts, if the vendor does not enforce this requirement, then other customers may not be so rigorous at enforcement, which could degrade the vendor’s overall security posture as a result of a successful attack on another customer’s environment.
Regardless of the authentication mechanism used, it is essential that end-to-end encryption applies to the logon sequence. Ideally, this authentication would be carried out by using a cryptographic hashing mechanism so that the password itself never exposed. Combined with cryptographic security is the requirement for rapid and effective provisioning and deprovisioning of accounts, which is covered in greater depth in the section on identity management.
Authorization permissions apply at the application level and provide confirmation that a user, computer, device or assembly has the required permission to carry out an operation. Usually, authorization is carried out through a roles-based framework, with user accounts assigned to roles. Role-based assignment ensures greater flexibility, as you can dynamically assign user accounts to different roles, so as users move around the organization, they automatically receive the rights they need to carry out their roles.
With PaaS, you should establish the control that you will have over authorization permissions and the level of access that your service provider has. As you are being provided with an application platform rather than installing your own applications (as with IaaS), you will require a greater level of trust in your cloud provider to secure both the infrastructure and platform layers.
Distributed applications
Enterprise Service Bus
In an enterprise environment you can use applications such as Microsoft BizTalk Server to provide an enterprise service bus (ESB).
Figure 6: Enterprise Service Bus
An ESB provides connectivity between services. There is no need to program each service or application to connect to every other service or application. Instead, you provide connectivity between each service and the ESB. In addition to connecting the services, the ESB can provide workflow and transformation capabilities. This enables you to connect heterogeneous systems and tie them together as one coherent solution. An ESB is an ideal method to connect your Private Cloud and enterprise systems. In Figure 5, each Web service can be connected to other Web services through a common connection to and through the ESB.
Furthermore, systems such as BizTalk Server provide additional security to your Private Cloud infrastructure. Security is provided on inbound and outbound messages. The messaging security allows you to validate the source of the message with signatures, decode incoming messages, encode outgoing messages, and digitally sign outgoing messages.
In a Hybrid Cloud model, the ESB, or in this case, the Internet service bus (ISB), can extend these capabilities to the Public Cloud.
Figure 7: Internet Service Bus in Hybrid Cloud
With this model, the ISB provides security and simplified system integration. If you consider an enterprise solution where an in-house web application takes data entry from users, passes the messages to the ESB, which validates, encrypts, and signs the messages before passing them on to a legacy mainframe service. Results are then returned from the mainframe and are validated, encrypted, and signed by the ESB before being passed on to an internal Web service that continues processing the data. Now, think of the Hybrid Cloud Model where you use a PaaS solution which provides the same functionality as the mainframe. By using the ESB (now being used as an ISB), you can connect the PaaS systems to your existing services without having to modify your services at all. The ESB can handle the connectivity, message transformation and security of the connection to the PaaS.
N-Tier Applications
Distributed applications can be challenging to adapt to a cloud environment. For example, consider the situation where you have a n-tier, on-premises, distributed line-of-business application and you want to migrate this application to the cloud. For security reasons, you decide to keep the data tier in a Private Cloud environment but to migrate the business and presentation tiers to the Public Cloud.
Figure 8: N-Tier Cloud Application
Some of the challenges that you may face from this type of migration include:
- Security, particularly authentication, cryptography, access control and firewall ports
- Replacing synchronous operations with asynchronous ones
- Performance management
- Exception management and error reporting
A well-architected distributed application should be able to make the transition from an on-premises environment to a cloud-based configuration relatively painlessly. However, poor architecture and design can result in performance degradation and poor security can result in compromise of some or all components of the application.
Performance degradation can come from design errors such as excessive querying of parameters or heavy use of object properties. In a high-speed, low-latency LAN environment, these factors have minimal effect; in cloud-based environments, such issues can cause the application to perform very slowly.
Although rigorous enforcement of security standards should apply to distributed applications operating entirely within a corporate network , the fact is that security standards and enforcement of those standard for legacy applications (particularly those that have been ported from a mainframe environment) are often less than ideal. While the risk/benefit analysis applied to such designs may be considered acceptable within the confines of the corporate network, such implementations are should be considered unsupportable in the cloud.
As the cloud-based PaaS environment may have different security configuration options and capabilities, intra-tier operations such as delegation and impersonation cannot rely on using domain credentials for these tasks. In addition, the application may require a more wide-reaching authentication setup, with requirements for a federated, claims-based mechanism to establish identity and then using those claims-based identities to authenticate to the different tiers of the application. For more information, see the section on identity and access management.
In cloud environments, network latency and round-trip times mean that any synchronous operations within the application that rely on strict timing must be replaced with asynchronous ones. Even communications between cloud-based tiers cannot be guaranteed to be timely.
Note:
There are mechanisms that can provide time synchronization in distributed environments (such as Network Time Protocol) but only more advanced protocols such as Clock Sampling Mutual Network Synchronization are likely to provide the level of accuracy to support for very high transaction levels. Applications that use Precision Time Protocol (PTP) will not function in a cloud environment.
Finally, an application that has been ported into the cloud must be able to manage exceptions and provide a mechanism for error reporting, otherwise diagnostics becomes challenging. Within local area networks, mechanisms such as event forwarding provide adequate methods for reporting application errors up through a server hierarchy, but cloud-based distributed applications must be able to communicate errors using message-based delivery, such as Simple Mail Transfer Protocol (SMTP). Similarly, any application instrumentation must be implemented with regard to how any exceptions can be passed back to a central console and followed up.
In consequence, any distributed application that you intend to port to the cloud must be thoroughly assessed for design and security flaws. Although the cloud provides advantages of scalability and agility, applications still need to be tuned, instrumented, synchronized and secured according to the realities of the PaaS cloud environment.
Storage and Data
You should consider that applications work on unencrypted data. That is to say, before the application can manipulate information, that information must be presented to it in an unencrypted format. At the point of processing the data, it is not encrypted even if it was encrypted during storage and transport. Encryption remains a valuable tool in securing data during storage and transport. In fact, data could be stored in encrypted form with a Public Cloud Vendor, transported in encrypted form, processed behind the firewall of the customer and stored on the Public Cloud without unencrypted data being exposed on the Internet at any time. This means that the primary risks come at the point of processing, not the point of storage.
REFERENCES:
ACKNOWLEDGEMENTS LIST:
If you edit this page and would like acknowledgement of your participation in the v1 version of this document set, please include your name below:
[Enter your name here and include any contact information you would like to share]