Building security into your cloud applications is imperative for keeping key customer data private and ensuring that your applications are fast and responsive. In this tutorial, learn how you can keep your applications secure.
Specifically, when thinking about application security, you need to consider:
- Multitenant application isolation
- Application security management
- Identity and access management for applications
- Web application protection
- Security of application runtimes and services
A complete application security solution looks similar to the following image.
Multitenant application isolation
Many clouds are built with a multitenancy architecture where a single instance of a software application serves multiple customers (or tenants). While this architecture is cost-effective, you need to build in application isolation to protect the tenants’ data and applications.
To effectively isolate your apps, you need to have container isolation and network isolation.
Application container isolation
IBM® Bluemix® uses Cloud Foundry capabilities for application isolation. The following diagram shows how Bluemix isolates applications:
Cloud Foundry platform includes a router. This router routes the incoming traffic to the relevant target, which is the droplet execution agent (DEA) node.
Bluemix uses virtual containers that run on IBM SoftLayer® to host each deployed application. When a new app is created, the following workflow occurs:
- Bluemix chooses an appropriate virtual machine to send the application artifacts to.
- After a VM is chosen, an application manager on each VM installs the proper framework and runtime for the application.
- Using the artifacts on the VM, the application is deployed into the framework, on the VM.
- The application starts.
- When the application instance starts, the DEA on the VM assigns an IP address to the application.
- A port is selected as well, and it is communicated to the application using a PORT environment variable that identifies which port to listen to.
- When an inbound request comes in, the router routes the traffic to the relevant application instance.
Application network isolation
A DEA has a single IP address. Inbound and outbound traffic go through the following levels of network address translation:
- Inbound: Traffic goes from the load balancer, to the router, to the DEA on the VM, then to the app container.
- Outbound: Traffic goes from the app container to the DEA, then to the gateway on the DEA virtual network interface. This gateway might be a network address translation (NAT) device.
The image below shows traffic flow through the recommended deployment configuration.
All traffic from the public Internet to the cloud controller happens over HTTPS. However, inside the boundary of the system, components communicate over a publish-subscribe (pub-sub) message bus, NATS, and also HTTP.
Another aspect of network isolation is that IBM Bluemix is configured to prevent system access from external networks and between internal components. Moreover, connections between applications on the same DEA network are restricted.
Besides restricting communication between different applications on the DEA network, IBM Bluemix uses Cloud Foundry’s Application Security Groups (ASG) and DEA Network Properties to configure DEAs to prohibit communication between system components and applications.
Application security management
When developing applications, you need to use secure engineering practices to build security into the foundation of your application.
Following IBM Secure Engineering practices prevents applications or services from introducing vulnerabilities, which are exploitable and present risks to customers.
These practices include:
- Threat modeling to identify relevant weaknesses and attack patterns related to the application
- Secure design that mitigates risks
- Secure coding guides and practices that prevent vulnerabilities
- Security testing to fix problems before the app is deployed and to validate that the product is free of known security issues
You must have all four of these components present in your development lifecycle to ensure that the application you’re developing is secure and free of vulnerabilities.
Security application scanning
IBM Bluemix Public includes the IBM Application Security on Cloud Service, which detects application security vulnerabilities and recommends remediation actions. This service can scan your web, mobile, or desktop applications and uses a variety of analysis techniques including dynamic, static, and interactive analysis.
Dynamic analysis scans a running web application. If you enter a starting URL and user credentials (optional), the analysis will:
- Crawl the application to create a site map.
- Run a battery of tests.
- Generate a security report.
The scan reports vulnerabilities, including details about the HTTP request and response information, so that you can understand exactly what data the test sent to your application and how your application responded.
IBM Application Security on Cloud supports scanning applications that are publicly accessible on the internet (in production) but also those that are inside your corporate firewall (in staging).
For applications not accessible from the Internet, you can install a tool called AppScan Presence in your network. AppScan Presence acts as a proxy to access the applications during a test.
A static analysis reviews your application source code or byte code to review the data flow in your application. A static analysis detects where:
- A malicious user may be able to introduce tainted data into your application.
- How that tainted data flows through your application.
- Where that tainted data may be used that represents a risk to your application.
The static analysis shows you detailed, code-level information related to how the malicious data flows. In addition, the service identifies “Fix Groups,” which are collections of vulnerabilities that you can address with a fix to a single source-code location.
Static Analysis can be used within a developer’s integrated development environment (IDE) or can be automated as part of the build process. We offer IDE plugins for Eclipse, IntelliJ, and VisualStudio.
Mobile applications need to be tested for security vulnerabilities as well. IBM Application Security on Cloud provides a Mobile Analysis capability that is simple to use.
Upload your Android or iOS mobile application to the service and the service sends you you a security report. For Android, upload the same APK file that you deliver to your users. For iOS, the service provides a tool that can be run against your Xcode project to generate a form of your IPA file that can be analyzed.
Visit the IBM KnowledgeCenter to read more about application security on the cloud.
Identity and access management for applications
When implementing identity and access management for an application, the web application’s audience determines the authentication model that is used.
- Unprotected website: No authentication required
- Website with an existing customer audience: Authentication is often handled by a SAML or Open ID Connect-based (OIDC) repository managed by the enterprise
- Website with a new customer audience: Authentication is typically handled by one of the SSO Service Social Login options. This is currently only available in Bluemix Public.
- Website with an audience of suppliers: Authentication is typically handled by a SAML or OIDC repository
- Website for internal employees and users: Authentication is typically handled by a SAML or OIDC repository
Authentication, or the identity service, enables applications deployed to the cloud to authenticate users at an application level, based on a range of identity providers.
For example, the authentication or identity service recognizes a subset or combination of the following identity providers:
- Cloud directory (hosted in the same cloud as the application)
- Social identity provider (such as Google, LinkedIn, Facebook, Twitter, or GitHub)
- Enterprise-hosted identity provider
- Cloud-hosted identity provider
With the proliferation of Software as a Service (SaaS) and API delivery models, API keys have emerged as another source of identities to accommodate.
Application user authentication scenarios
Organizations that use your cloud-enabled application can have a variety of log-in scenario requirements.
The following image shows a few of the ways users can access your web applications. Customers and supplies log in with social identities, partners log in with cloud-hosted directories, and employees log in with an organization’s identity provider.
Let’s look at some use cases of how to implement authorization for users who try to connect their web applications to Bluemix.
- Scenario 1: Organization deploys its web app to Bluemix and requires its employees to log in using their organization’s Identity Provider
As a Bluemix application developer, you can embed a single sign-on capability into your application. The Single Sign-On service supports several identity sources where your users’ credentials are stored.
To fulfill the requirement of this scenario, configure “SAML Enterprise” as the source of the identity. The SAML Enterprise identity allows employees to log in using a third-party identity provider. A successful login completes the authentication process with an exchange of SAML tokens that contain user details.
Alternatively, organizations can choose use their own network and expose their Enterprise Directory to authenticate users to access the web application. However, this solution capability is restricted to solutions that are deployed in a dedicated Bluemix environment. You can configure remote LDAP registry via a server deployment descriptor and make it available to the web application for authenticating users.
- Scenario 2: Organization deploys its web app to Bluemix and requires its users to log in using social websites such as Facebook, Google+, and LinkedIn
As a Bluemix application developer, you can embed single sign-on capability into your application. The Single Sign-On service in Bluemix supports several identity sources where your users’ credentials are stored.
To fulfill the requirement of this scenario, configure “Social Identity” as the source of identity. The Social Identity option allows user to log in using one or more social networks, such as Facebook, Google, GitHub, or LinkedIn.
- Scenario 3 – Organization deploys its web appl to Bluemix and requires its users to log in using Bluemix-hosted cloud directory credentials
As a Bluemix application developer, you can embed single sign-on capability into your application. The Single Sign-On service supports several identity sources where your users’ credentials are stored.
To fulfill the requirement of this scenario, configure “Cloud Directory” as the source of Identity. The Cloud Directory identity source uses a user registry that is hosted in the Cloud. The Cloud Directory hosts password policies and user information. A customer profile to be created along with default password for customer to login using built-in cloud directory.
Single sign-on (SSO)
The single sign-on capability offers a seamless transition between applications – in and out of a cloud environment – without the need to interact with an authentication interface for each application. SSO is also possible across different apps in the same cloud environment.
IBM Single Sign-On for Bluemix (currently Bluemix Public only) is a policy-based authentication service that provides an easy-to-embed, single sign-on capability for any runtime. To enable an application developer to embed single sign-on capability into an application, the administrator creates service instances and adds identity sources.
The Single Sign-On service supports several identity sources where your users’ credentials are stored:
- SAML Enterprise: A user registry with an exchange of SAML tokens that completes the authentication
- Cloud Directory: A user registry that is hosted in IBM Cloud
- Social identity sources: The user registries that are maintained by Google, Facebook, GitHub, LinkedIn, and other social networks
For more information, see the Getting started with Single Sign On documentation, which covers:
- Configuring identity sources, including adding SAML Enterprise, Cloud Directory, and social identity sources
- Configuring apps, including how to create an app, how to bind an app to a service, how to integrate the app with the service, how to configure a Liberty for Java app and a Node.js app, and how to deploy the app
- Administering apps, including customizing apps and pages, syncing with Cloud Directory, importing users, ID tokens, and more
- Deploying the identity bridge, including identity bridge system requirements and installing and configuring the identity
With increasing user mobility and channels to access corporate applications and data, security requires more intelligent controls to assess overall risk prior to authorizing access. Policy-based access management dynamically analyzes a user’s requests for access to business-sensitive applications and data. This policy-based access applies appropriate security policies to minimize the risk of improper data exposure or loss.
At the moment, you need to code policy-based access in Bluemix directly into the application.
User access management for application users
Managing access to the application or authorization is the application’s responsibility. Authorization is supported in dedicated Bluemix while using corporate LDAP directory as the identity source.
You can achieve this through the application-supported capability of enforcing LDAP group-based authorization. The solution is restricted to local and dedicated Bluemix where corporate directory access is available to web application.
In Bluemix Public, granting users access can be given based on the role of a person has in a particular organization or based on the role a person has in the cloud environment.
With Bluemix deployed in a public environment, account owners perform all operations on organizations and spaces, including managing team members and their assigned roles.
Read the Bluemix documentation for information about user roles and how to grant access to other users in a Bluemix Public environment.
Bluemix Local and Bluemix Dedicated
You can add users to your Bluemix instance from your company’s user registry through LDAP. You can add users one-by-one or in groups, and view user permissions. If you are assigned admin permission, you can also set and manage permissions for other users.
Read the Bluemix documentation to learn more about different user permissions and how top grant different users access to specific areas of Bluemix.
Web application protection
Distributed Denial of Service (DDoS) attacks are a major, common, and easy-to-execute threat on web applications. When choosing a cloud platform, it’s important to select one that has built-in protection from DDoS attacks.
Bluemix Public and Bluemix Dedicated: Protection against a DDoS attack
If you already have an in-house or third-party service to provide DDoS protection (including traffic scrubbing), you continue to use this to protect your environment.
All requests from the Internet to Bluemix applications go through IBM DataPower, which provides reverse proxy, transport layer security (TLS) termination, and load-balancing functions. In addition, IPSEC encryption is implemented within the Bluemix network from DataPower to the Bluemix application for CloudFoundry native services. Non-CloudFoundry native services utilize TLS encryption currently 1-way TLS.
For Bluemix Dedicated users, customers can integrate with third-party vendors like Akamai or CloudFlare to use cloud web application firewalls. By configuring your Bluemix Dedicated instance to have direct-access traffic come in from your enterprise network and not directly from the Internet, you can continue to implement your existing tools and best practices for Internet traffic handling.
Bluemix Public and Bluemix Dedicated have custom SSL certificates that support HTTPS endpoints of Bluemix applications.
Read the Bluemix documentation for well-defined procedures for how to manage these certificates.
If you do not already have a DDoS/Traffic scrubbing solution, IBM’s Managed Secure Service helps you prevent DDoS attacks by routing traffic away from your infrastructure during an attack, therefore maintaining the availability and performance of your web properties. IBM offers optional Managed Security Services to strengthen your information security defenses and lower your costs. Check out the Managed Secure Services offering.
Finally, you can also implement a DMZ in front of your local and dedicated Bluemix environment and deploy web application firewall (WAF) tools for your environment.
IBM SoftLayer: Web application firewall and protection against a DDoS attack
A IBM SoftLayer Network Operations Center (NOC) team monitors network performance and security around the clock. Automated DDoS mitigation controls are in place should a DDoS attack occur.
It’s important to clarify here that the primary objective of this DDoS mitigation is to maintain performance integrity of the overall cloud infrastructure. If necessary, IBM SoftLayer will remove the target from the public network for periods of time and nullify incoming connections. Because of IBM SoftLayer’s three-tiered network architecture, a customer would still have access to the targeted system via the private network.
We recommend that customers who are subject to DDoS attacks take preventive actions to mitigate their risk and the impact of DDoS attacks on their IBM SoftLayer web site and application environment. For example, you can subscribe to DDoS traffic-scrubbing services from third-party providers.
If the type of malicious activity warrants it, for example in the case of illegal behavior or DDoS activity, IBM SoftLayer will nullify the traffic and work with the client to remediate the activity. If not remediated in 24 hours, IBM SoftLayer may chose to take the target IP address offline to protect IBM Cloud and its customers.
DDoS attacks from within IBM SoftLayer (a customer or its client) would be against the IBM Cloud Acceptable Use Policy and treated as such.
Protecting application data
Creating a secure environment for your data to reside and move is vital as threats to data security and infrastructure increase. IBM has built-in security measures for protecting data in transit and data at rest, including key management.
Read “Securing Workloads in the Cloud: Data security” for more information about how to protect your company’s data.
Security of application runtimes and services
Securing your application’s runtimes and services is important. There are four types of runtimes in Bluemix:
- Cloud Foundry runtimes
- Virtual machines (VMs)
In the following section, we’ll review security of both Docker containers and VMs.
Security of containers
IBM Containers, which are based on Docker containers, provide full isolation between Docker instances. In IBM Bluemix Public, you should use the IBM Vulnerability Advisor service to assess the Docker images before using any of the images in the repository.
If you create your own image that you host and run on an IBM container, we recommend running IBM Vulnerability Advisor on your images before deploying it.
You should add this step in the Test stage in the Delivery Pipeline service as part of the continuous development and deployment process.
Read the “Verify your containers are secure with Vulnerability Advisor” blog post for more information.
Security of virtual servers
Security of virtual servers includes the typical procedures for securing a compute node (hardening, patching, password policies, and the like). Besides, on Bluemix, control of traffic is controlled using security groups.
Service IDs and API Keys
You must enable authentication for cloud services to ensure that the service is only offered to authorized applications and to enable billing on the calls made to the service.
For most cloud services, the service consumer authenticates itself using a service identity and a secret service key, service ID, or API keys. Even if some of the services require authentication that use credentials that are sent (for instance, with the HTTP basic authorization header) the authentication typically identifies an application, not a user, with the service invocation.
Cloud Foundry, an open source platform that Bluemix builds on, uses the name “service keys” for this kind of authentication.
Whenever a CloudFoundry application is bound to a CloudFoundry Service Instance, a set of credentials is created and attached to the CloudFoundry application’s environment variable VCAP_SERVICES.
You can make certain CloudFoundry Services accessible to non-CloudFoundry application clients, too. For this, Bluemix enables you to manually control the creation and deletion of service keys during the service instance creation and later. This applies to Bluemix services that have already adopted this feature already, including Apache Spark, Service Discovery, Object Storage, and the Watson services adopted this.
For more information, read the “CloudFoundry Services Keys and Sample Go Service Broker” blog post and CloudFoundry documentation.