Over the last few months we have seen a dramatic shift in terms of Alpha Anywhere
developers moving to Alpha Cloud. The reasons for this trend are outlined on this page.
One of the strongest motivations for people making this shift has been the high levels
of security afforded by having their Alpha Anywhere applications deployed in Alpha Cloud.
This article below provides more insights into this topic.
Please contact firstname.lastname@example.org with any questions.
Alpha Cloud is a deployment environment for web and mobile applications built with Alpha Anywhere. Deployment is easy with reasonable defaults, but you are also in control of a rich set of options.
In this article, we will look at some general concepts related to securing a web site and discuss how the environment isolates your subscription resources and your running application from the internet and from other applications running on Alpha Cloud. We will also discuss programming practices you will want to follow in order to prevent potential exploits.
Who is Responsible for Security?
The short, and perhaps obvious answer, is that we all are.
Security is a Team Sport
Microsoft Windows - Secure Operating System
Amazon Web Services - Secure Infrastructure
Alpha Cloud - Secure Deployed Servers
Deployed Applications - Best Practices
How Having a Secure Infrastructure Helps
Because Alpha Cloud is built on the Amazon AWS infrastructure and because Alpha Anywhere Application Server for IIS runs on Microsoft Windows Server, we automatically get a certain level of isolation from other tenants of Alpha Cloud and of of the Amazon ecosystem in general. Both Microsoft and Amazon invest significant effort in hardening the software and Amazon adds monitoring of the environment and traffic from the internet. As you will see, Alpha Cloud is implemented using best practices for both Amazon AWS and Microsoft Windows Server.
A secure infrastruction, however, does not mean that your web site is automatically protected from attacks from malicious web clients. Errors in logic and poor programming practice can create opportunities for malicious actors to attack your site and your database. The responsibility is shared by Amazon, Microsoft, Alpha Software and you!
Security is an Ongoing Effort
The bad guys don't stop trying new things. As new exploits are discovered and addressed, we all need to be proactive in making sure we adopt new practices in a changing world.
Security Principles and Concepts
Overall Objectives of Security
A secure system is expected to maintain:
Confidentiality - Only those with a need to know and who have been explicitly permitted are allowed to see data managed by the application.
Integrity - The application assures that data it manages is not subject to tampering or deletion. It is accurate and complete.
Availability - The application must be useable, and the data is available when it is needed.
Non-repudiation - When someone does make a change (whether authorized or not) a record of the change is made.
Focus of Effort
In order to meet those objectives we must do the following:
Authentication - Assuring we know who is accessing the system. There are many approaches to authentication from basic user and password interfaces with or without multi-factor checks, to client side certificates and third party approaches.
Authorization - Individuals or groups are permitted to perform operations on select data.
Encryption - When data is not actively being manipulated, it is kept in a format that is very difficult (hopefully impossible!) to read or tamper with.
Auditing - A record of significant actions (especially updates or deletes) is kept and available to be reviewed.
Data Protection - Data needs to be protected in the following cases:
- In Transit - When data is moved over the network (especially the internet), it is especially vulnerable.
Transport Layer Security (TLS - classically referred to as SSL) is a method of encrypting connections between two processes or servers. It is the most common way of protecting data in transit.
- At Rest - When data is stored on disk, it must be strongly encrypted in case there is a physical or server breach.
Proper controls must also restrict access to the disk and the machine controlling the disk.
- In Process - Whenever your application manipulates data (including displaying it on a web page), you need to consider the possibility that the data may be accessed from other malicious code, written to temporary storage that is not encrypted, or included on a web response or page that is not authorized.
A well secured system is useful and adds value to the organization using it while implementing authentication, authorization, encryption and auditing to prevent those who do not have permission from doing things they are not allowed to, and from seeing things they shouldn't see, all while keeping track of actions that are taken.
Alpha Cloud Architecture
In order to make clearer how the architecture of Alpha Cloud facilitates secure deployment, we need to get some context. What is Alpha Cloud exactly?
Components of Alpha Cloud
Most of Alpha Cloud is not about running your application. Instead, most of the services associated with Alpha Cloud center around:
Definining your application and how it is deployed.
Moving assets from Alpha Anywhere to Alpha Cloud.
Configuring the Amazon AWS environment and the individual Microsoft Windows servers to run the deployed applications
Installing the right versions of your application and Alpha Anywhwere Application Server for IIS on each server that it is assigned to run on.
The diagram below shows the major components of the Alpha Cloud ecosystem. Most of the Alpha Cloud software has no direct access to the Amazon AWS infrastructure. The Alpha Cloud control plane (the part that creates and maintains the infrastructure and defines deployments) does not have access to any server on Alpha Cloud. Every change in Amazon AWS configuration is accomplished through Amazon AWS APIs that change the Amazon configuration indirectly.
This loose coupling between Alpha Cloud and the running servers improves performance, but also keeps Alpha Cloud software away from your running application. The agent software running on each server is responsible for keeping the local server consistent with the declared definition managed by Alpha Cloud. Every change in application configuration is communicated to running servers through a configuration file maintained by the control plane and read by the agent software on the running server.
We will look at the Amazon AWS configuration in the next section.
When you publish your web project to Alpha Cloud, all of the components and scripts in your web project are copied to storage on Alpha Cloud. The items to be published to Alpha Cloud are encrypted locally using a key provided by the control plane before being copied to temporary storage on Alpha Cloud. The uploaded assets are then reencrypted using a private key before being stored permanently on Alpha Cloud. Alpha Cloud uses Amazon AWS S3 - Simple Storage Service as a repository for application resources. Each time you publish to Alpha Cloud, a new version of your web project is created. Previously published versions of your application are kept in case they are needed.
Deployments on Alpha Cloud occur when you assign a version of your published application to a web site and select a specific build of Alpha Anywhere Application Server for IIS to run with that application. Alpha Cloud manages the process by assigning your web site to a server group, creating a deployment package and updating the configuration file for that server group to let the servers in that group know that they should run the web site.
Each server in a server group is responsible for installing the deployment package, the correct build of Alpha Anywhere Application Server for IIS, and any certificates required for the web site. A piece of software (called an Agent) creates the Microsoft IIS (Internet Information Services) resources required to run your application. That same service encrypts and pushes logs for your application to secure storage so you can view them through the Alpha Cloud dialogs in Alpha Anywhere. Additional software installed with Alpha Anywhere Application Server for IIS tracks and reports usage for your application. The usage information is is also available in the Alpha Cloud dialogs in Alpha Anywhere.
How Alpha Cloud uses Amazon AWS
When we say that Alpha Cloud is built on Amazon AWS and runs Microsoft Windows Server, we mean that Alpha Cloud automates the tasks that you would have to perform yourself to configure an on-premises environment using Alpha Anywhere Application Server for IIS. The deployed application runs the same Alpha Anywhere Application Server for IIS that you can license and run yourself.
If you choose to, you can license the Alpha Anywhere Application Server for IIS and create an environment comparable to Alpha Cloud by subscribing to Amazon AWS and building the same infrastructure we do. However, in addition to the infrastructure, Alpha Cloud provides automation for the many tasks you would have to complete yourself to create a configuration to run your application securely and robustly at scale.
Amazon has a number of services that can be assembled to build a robust and highly scaleable application deployment.
Auto-scaling Groups - Amazon AWS Auto-scaling is a facility that manages sets of running virtual machines. Based on declared rules for the auto-scaling group, server instances are created or terminated as needed to meet service demands. The auto-scaling group recognizes instances that terminate for any reason and replaces them by creating and starting new instances.
Load Balancers - Amazon implements three different types of load balancer services that work with auto-scaling groups to distribute the load to available server instances. Every server group has a dedicated load balancer service.
Availability Zones - Amazon AWS runs in multiple data centers, called availability zones, within each region. Alpha Cloud configures each auto-scaling group and load balancer across three of these availability zones. As a result, failure in any one zone (or even two) will not disable the application.
Routing Tables - Each server group has dedicated subnets within which its server instances can run. There is a separate subnet for each auto-scaling group in each availability zone. Routing tables prevent access between server instances of different groups. The tables also prevent access to the server from outside the subnet. Only traffic routed through the load balancer on ports 80 and 443 will be allowed.
NAT Gateways - This service is created in each availability zone to provide anonymous access to the internet using static public addresses from which a server instance can connect to databases and other internet services. Alpha Cloud has allocated these IPs using the Amazon AWS Elastic IP facility and other documentation will refer to them as Egress IPs.
Amazon AWS services have been certified under a number of standards. For more information see ISO Certified.
You will see an element referred to as a "bastion host". This is a gateway server that can be used by Alpha Software to access a running server instance to debug issues. Access to the bastion host is strictly controlled and one must navigate multiple levels of security to reach a server. Although having this access was critical during initial development of Alpha Cloud, it is now rarely used and may be removed at some time in the future.
What are Server Groups?
An Alpha Cloud Server Group is a collection of one or more identical Windows Server virtual machine instances running behind a load balancer. At runtime, a deployment is assigned to a web site and that web site is assigned to a server group. A server group definition is mapped to one or more Amazon AWS auto-scaling groups using all of the services described above.
Note: The default behavior for every web site you deploy on Alpha Cloud is that there are at least two server instances running in multiple data centers behind a load balancer. We use up to three availability zones depending on how many are available in a region.
How Secure Is This?
Let's look at the components that make up the environment for a running web site.
Amazon creates an isolated network using the following:
Virtual Private Cloud (VPC) - All Alpha Cloud deployments run in a virtual private cloud. This VPC has its own set of private IP addresses from which subnets are allocated.
Private Subnets - Every server group is assigned a separate private subnet within the VPC in each availability zone.
Denied by Default - Unless a route is explicitly configured, traffic between subnets is not allowed. Traffic directly from the internet is never allowed. Since traffic is only allowed from the load balancer to specific subnets on ports 80 and 443, each server group is isolated from every other server group in the VPC and from the internet.
Each server instance runs Microsoft Windows Server (currently at version 2016).
In order to keep current with security patches to Windows Server, server groups are updated automatically whenever Amazon issues an updated machine image (AMI) of Windows Server. Alpha Cloud's control plane watches for these updates reconfigures the auto-scaling group to create new servers using these new versions. This process rotates out instances by creating new servers using the Amazon API and then deleting old servers once the new ones are available. This way, your application is never out of service.
The default Windows Server 2016 environment includes some ciphers, hashes and protocols that are considered insecure. At startup, the Alpha Cloud configuration removes the insecure ones to assure that deployed applications get the best rating for security. For more information on how Alpha Cloud gets an A+ rating on TLS security, see Alpha Cloud Security Capabilities.
Alpha Anywhere Application Server for IIS runs under Microsoft Internet Information Services (IIS) and the web sites are configured in IIS with tight security as follows:
Application Pools - Every deployed application runs in a separate application pool (a set of processes). If a web site has more than one application assigned to it, each application runs in a separate application pool.
Application Pool Identity - Every application pool is created with a unique unprivileged identity. In effect, each application runs under a different user with minimal permissions.
Access Control Lists (ACLs) - ACLs must be assigned to grant an application pool identity permission to read it's own application files and to write selected log files. Each application pool identity must be granted permission to read and write files that belong to it and is not permitted to access other folders.
The key practice applied to deployment on a Windows Server in Alpha Cloud is referred to as the "principle of least privilege". Your web site is deployed with only enough permission to run an IIS process, to read from your deployed components and other files, write logs, and manage temporary files. There are even quotas set on how much disk space your application can use.
For security reasons, you do not have access to any server your application is running on. Even if you could, an application is running at scale with multiple servers and requests may be routed to different servers, for the same web session; so you would have to manage multiple servers.
Web Site Tenancy
By default, a web site is assigned to a server group that includes web sites from multiple subscribers to Alpha Cloud. The Alpha Cloud control plane assigns web sites to server groups based on the resources already committed to a server group. In general, once a web site is assigned to a server group, it does not move to another group; that is unless the web site is disabled and then reenabled and the control plane chooses a different group. The security practices discussed above, make this a reasonable choice for applications in that they are already properly isolated from each other.
The default web site assignment in Alpha Cloud is referred to as Public tenancy. There are three types of tenancy in Alpha Cloud and they differ primarily in the way a web site is assigned to a server group.
Public - As discussed above, Alpha Cloud assigns web sites with Public tenancy to server groups that may also include web sites from other subscribers. In these server groups, Alpha Cloud controls the number of IIS processes that run and the rules for scaling up and down based on server load. Again, this is the default tenancy for deployed web sites.
Subscription - In Subscription tenancy, any web site from your subscription that is assigned to the same server group name may be assigned to the same deployed server group. We say may, because there are still limits on how many web sites are assigned to a server group, so a there may be more than one server group created to deploy all of the web sites assigned to the group name.
In Subscription tenancy, you can also create named groups of servers that have different numbers of IIS processes and scaling rules than the groups used in Public tenancy.
Dedicated - In Dedicated tenancy, each web site is deployed to its own server group regardless of the name. As with Subscription tenancy, you can also create named groups of servers that have different numbers of IIS processes and scaling rules than the groups used in Public tenancy. The server group for the web site will use the configuration for the named server group.
Here is a summary of the options available for tenancy assigned to a web site:
Public tenancy is sufficient to isolate your application from other applications. Subscription and Dedicated tenancy are generally not needed, but are offered for cases where you want (or are required to have) more control over the deployment environment. This feature comes at a cost, because Alpha Cloud is not able to use server instances for other subscribers and we must pay to keep them running whether you use them or not. For this reason, you are charged an additional fee to cover the cost of keeping a, potentially, unused server running. This charge is based on the minimum number of instances you schedule and is charged by the hour.
Note: For more information on tenancy in Alpha Cloud see Tenancy in Alpha Cloud
Securing Your Subscription
In order to protect your subscription, Alpha Cloud retricts access to your definitions and files based on user names and passwords assigned by e-mail address. Anyone can create a user account on Alpha Cloud, but only by either purchasing a subscription, or being authorized as a maintainer can anyone make changes to your applications and deployments and other assets.
In order to keep your data private and secure, in keeping with the principles discussed above:
Encryption - Every asset stored in S3 is encrypted.
- Published applications - As discussed previously files are encrypted during upload and then reencrypted when written to permanent storage.
- Deployment packages
- User logs and resources (IIS, Failed Request, Alpha Anywhere, dump files) - These logs are created on the server and then pushed to Amazon S3 so you can view them in the Alpha Cloud dialogs. They are decrypted by Alpha Cloud when they are displayed in Alpha Anywhere or downloaded.
Note: If you choose to have your logs copied to storage from the server, you are responsible for security of the target storage. See Managing Log Custom Storage for more information on copying server logs to your own storage account.
- Alpha Cloud Management logs - all of the logs used to manage Alpha Cloud are encrypted in S3 and require decryption by our management softtware by authorized operators to read.
Authorization - Every definition related to your subscription is authorized based on role and object identity.
- The Alpha Cloud API authenticates and authorizes users, actions and objects before reading or writing information.
- You must be the owner of a subscription, the primary contact for the subscription or an authorized maintainer of a subscription to change most Alpha Cloud entities.
There are also options to grant users limited security so they can publish and deploy, but not have total control of the subscription.
For more information on the security within your subscription see Delegating Access to Your Cloud Resources.
Auditing - Sensitive activities are audited. Alpha Cloud records actions taken to create, update and delete resources.
Note: Audting logs are only accessible to Alpha Cloud operations.
Securing Your Application
Although Amazon, Microsoft, and Alpha Software have created a secure environment for you to deploy into, you still need to make sure you use best practices in your application and any resources it accesses to make sure you don't compromise your own data.
Let's look at some of the things you will want to consider to keep your data safe and private.
Data at Rest
Data In Transit
Data at Rest
Alpha Cloud automatically encrypts objects stored in S3. When you store objects outside of Alpha Cloud, make sure you are taking advantage of encryption facilities.
Amazon S3, for example supports a number of approaches to security buckets by default:
SSE-3 - Server Side Encryption with Amazon S3-Managed Encryption Keys
SSE-KMS - Server-Side Encryption with AWS KMS-Managed Keys
SSE-C - Server Side Encryption with Customer-Provided Keys
Note: A5Storage includes a settable encryption key.
Encrypt data in your database. If you are using Amazon RDS, you already have options to encrypt your database:
Amazon RDS uses AES-256 encryption
Amazon RDS is available for Aurora, MariaDB, MySQL, Oracle, PostgreSQL, SQL Server
Note: All logs, backups, snapshots and read replicas are also encrypted.
Oracle and SQL Server can use TDE (Transparent Data Encryption)
Data In Transit
When data is moving between a client device and a server or between the server and another service:
Always use HTTPS (TLS/SSL) between the browser and your web site and your server and the internet. Alpha Anywhere has facilities for secure transfer of data that are easily configured and often automatic.
Purchase a certificate for your web site. It looks more professional, but also protects your users from something called a man-in-the-middle attack.
When data is moving between your server and your database:
Alpha Anywhere supports SSL for MariaDB, MySQL, PostgreSQL, Oracle, SQL Server.
Alpha Cloud includes client drivers for Aurora, MariaDB, MySQL, PostgreSQL, Oracle, SQL Server, and SQL Anywhere
Alpha Cloud automatically recognizes Amazon RDS and handles certificate authorities for supported databases.
Avoid generating XBasic or SQL code dynamically. Use parameters in SQL execute function calls. Failing to do this can result in what are called injection attacks. A user can enter code into a web page text box that gets executed by your application or your database to compromise your system.
Always enable security for your application when you first create your web project.
Use the principle of least privilege when creating users and groups for your application. Don't let users see data or perform actions they should not. Alpha Anywhere has a lot of features that make it easy to assign and manage users and roles. Be sure to use them.
Make sure to configure password expressions that prevent your users from creating weak passwords to access your application.
Take advantage of component features that show and hide fields based on a user's role assignments.
Create TLS (also called SSL) certificates specific to each host and upload them to your cloud configuration. Avoid sharing a certificate between an in-house web site and your cloud based web sites.
Protect your TLS private key. Access to this key makes it possible for an attacker to pretend they are you.
Always take advantage of TLS when connecting to your database. Alpha Anywhere makes connecting to Amazon RDS databases securely as simple as a single checkbox in the connection string dialogs in Alpha Anywhere.
Limit access to your database and be sure to limit the rights and privileges of your application connection string account.
Security is hard and it requires an ongoing effort to protect your resources and those of your customers.
Unfortunately, there is much more to securing your application than we could possibly cover in a single article. You should now have a basic understanding of the thought and effort Alpha Software has invested to make sure your deployed applications are running in a secure infrastructure. We will continue to review our software and the environment we run in.
Here are some additional things you can do to help:
Protect passwords for all of your Alpha Cloud users.
Be sparing when authorizing users to manage resources for your cloud subscription. There is a fine grained level of control built in to Alpha Cloud so you can delegate permissions on an as-needed basis.
Keep up-to-date on Alpha Anywhere builds both in development and in production. We update our software and libraries we include with Alpha Anywhere to keep current on fixes, but also to improve security.
Report any concerns or signs of intrusion to Alpha Cloud support immediately upon discovering them!
Monitor the Alpha Software web site and documentation on a regular basis for alerts and best practices to protect your deployed applications.