MOR-PLN-038 Version 2 last review date: Sep, 2023
1. Overview
This is an overview on the security and backup configurations on the Azure Infrastructure. This covers the way data are encrypted while saved and transferred, as well as protection from unauthorized access. Further, it outlines the backup schedule that is being followed, as well as the restore procedure in case a recovery must take place. A set of recommendation actions and additional configurations are listed, to enhance the security and the redundancy of the platform.
2. x
3. Backup and Restore
Each service has its own approach on how it stores a copy of its data, to secure against hardware/software failures or malicious attacks.
3.1 Scheduled backups for web apps
Web apps, on the standard pricing tier, allow for daily backups of the web app itself, to a storage account (created under the same azure subscription). This is enabled and configured on the web app itself, and it is scheduled to take a backup daily at midnight.
The backup files are retained for 30 days, and the backup process includes a snapshot of the database, based on the DB connection string, as configured in the web app settings.
3.2 Restoring web apps from a backup
In case there is a need to restore a backup, it can be done via the “backup” section, by selecting the Restore option and choosing the appropriate backup file. This will effectively override the existing web app, with the copy saved in the backup file, as well as restore the database to the snapshot that exists on the backup file.
An alternative scenario, is the need to restore a backup file, under a new/different web app, as well as a different database. In this case, a new web app must first be created (if it doesn’t already exist), and the database connection configured in the web app settings must point to the database that the DB snapshot will be restored under. Having the above ready, it is possible to choose a different web app as the target, when restoring a specific backup file.
3.3 Database point-in-time restoration
Databases in the Azure platform, keep a historical record of the transaction log for the last few days. This allows us to bring the database to any specific date and time, within the period that the database is maintaining those records.
For the basic pricing tier, this period is 7 days and for the standard period and above is 30 days and this feature, complements the daily backups of the web apps, that include a snapshot of the database. The benefit of this approach, is the possibility to restore the database at any time during the last few days, and is not restricted to specific snapshots taken by a usual backup procedure.
3.4 Storage geo-redundancy
Azure storage will be configured to use ‘RA-GRS’ as the replication mode. This approach keeps a copy of the storage, at a different azure location. The secondary storage is accessible with read only permissions and is available in case the primary location fails.
4. Disaster Recovery Plan
A set of measures and processes are in place, to allow for a fast recovery of a possible failure. That can happen due to the temporary azure services outages, hardware failure, wrong configuration or malicious attacks.
4.1 Geo-replication of database
Azure SQL Databases have the ability to be replicated live to another azure datacentre. The copied database is an exact copy of the initial one, and can be access in read-only mode. Those databases are in a Primary-Secondary relationship, and it takes less than a second for any change on the Primary database to be reflected on a Secondary database. It is also possible to have multiple Secondary databases.
For the developed platform, the production database will be replicated to ‘Australia East’ region, under S0 (Standard) pricing tier. The pricing tier might need to be scaled-up, depending on usage.
4.2 Access Storage’s secondary location
As previously mentioned, the storage account will be configured to ‘RA-GRS’ replication mode, that stores a copy of the underlying data, to a secondary region, that can be accessed in read-only mode. The secondary storage location can be accessed via a different domain name, by appending the following string, after the account name, on the connection string: “-secondary”
4.3 Recover from a disaster
In the unlikely scenario of a failure, the platform can be brought online, to a working azure region. To do so, each of the affected services can be recovered (individually) as below:
4.3.1 Web apps
In the case of a web app failing, it can be re-created under a different resource, to a different azure region, and then deploy an instance of it, directly from the team foundation’s source repository (continuous integration). The application settings must then be configured, to point to a functioning copy of the database, to the appropriate blob storage, as well as table storage. After having the new instance working, the DNS records of the domain name should be switch over to the newly created web app, to direct incoming traffic to the working instance. An alternative approach, will be to restore a backup of the web app, under a new one. This method will have the benefit of avoiding having to configure all the application settings. This approach can be used in case the backup file has the latest production version.
4.3.2 Database
In the event of the Primary database not being accessible, it is a matter of switching the relation of the Primary-Secondary databases, so that a Secondary database becomes the Primary. As soon as the new relation is established, the newly Primary database will be write-enabled. Final step would be to switch the database connection sting of the web apps (‘Application Setting’ section), to point to that database.
It is worth mentioning that, as soon as the Secondary database (which was Primary before) becomes available again, the replication process will sync it to the newly Primary database. If it is then needed, the relation Primary-Secondary can be reverted.
4.3.3 Storage Account
If the primary storage account fails, it auto-recovers itself, by switching to a working copy, that the replication mode (‘RA-GRS’) provides. Moreover, the secondary location of the storage can be accessed, by appending the below string, after the storage account name:
storagename-secondary.blob.core.windows.net This change will only allow for read-only access to the storage and any write process will fail. In case the auto-recovery of the primary storage is delayed or failed, an approach will be to create a new storage account and copy over the data from the secondary storage of the initial storage account.
5. Areas of improvement
5.1 Databases
5.1.1 Long-term backup retention
Long-term backup retention allows to store weekly backups in Azure recovery services vault up to 10 years. This helps meet compliance and other data retention requirements.
5.1.2 Auditing & Threat Detection
Auditing and threat detection can help maintain regulatory compliance, understand database activity, and gain insight into discrepancies and anomalies that could indicate business concerns or suspected security violations. Once turned on and configured, Threat Detection will send emails for security alerts. Threat Detection detects anomalous database activities indicating potential security threats to the database. This enables you to detect and respond to potential threats as they occur.
5.1.3 Vulnerability Assessment
SQL Vulnerability Assessment (VA) is a service that provides you with visibility into your security state, and includes actionable steps to investigate, manage, and resolve security issues and enhance your database fortifications. It is designed to be usable for non-security-experts. Getting started and seeing an initial actionable report takes only a few seconds.
HTTPS is not used to access Redis Cache due to performance issues with Azure’s HTTPS implementation for Redis, which itself does not support HTTPS natively. Due to this – Redis Cache is still accessed via HTTP. This might be due to the fact that the lowest tier Redis cache (C0), on shared infrastructure, is used. Live checks should be made to determine whether a dedicated instance (C1) resolves the issue.
6. Additional services
6.1 Azure Security Center
Upgrade to the standard tier for enhanced security to allow for • Just in time VM Access • Adaptive application controls • Network threat detection • VM threat detection
Data Collection should also be enabled to allow Security Center to provide better recommendations.
6.2 Web application firewall (WAF)
Web application firewall (WAF) is a feature of Application Gateway that provides centralized protection of your web applications from common exploits and vulnerabilities. Web application firewall is based on rules from the OWASP core rule sets 3.0 or 2.2.9. Web applications are increasingly targets of malicious attacks that exploit common known vulnerabilities. Common among these exploits are SQL injection attacks, cross site scripting attacks to name a few.
Preventing such attacks in application code can be challenging and may require rigorous maintenance, patching and monitoring at multiple layers of the application topology. A centralized web application firewall helps make security management much simpler and gives better assurance to application administrators against threats or intrusions. A WAF solution can also react to a security threat faster by patching a known vulnerability at a central location versus securing each of individual web applications.
6.3 Remote backups
Currently, Azure doesn’t offer a built-in solution to backup azure storage to another storage provider, or on customer premises. However, it’s possible to build such a solution and schedule remote backups to other storage providers such as AWS or to an ftp server hosted by CBC. Azure storage can be backed-up to another azure storage, in a different azure subscription, by implementing the following tool: http://markjbrown.com/azure-webjobs-azcopy/ (opens in a new tab) It takes care of asynchronously replicating the azure storage. It is also possible to improve upon this solution, and take advantage of azure storage snapshots, that effectively “freeze” an image of the storage as it was at that time. However, this approach will incur additional cost, as the snapshots increase, and they start deviating between them. Alternatively, the contents of an azure storage can be backed-up to an FTP server. This can be done via a webjob that can monitor new files being created on the blob section of the azure storage, and initiate ftp transfer requests to the remote server. The webjob will live along-side the main azure web app and will share the same resource of the application. Any increase in the cost will be occurred from the bandwidth used to transfer the files, as well as the need to increase the App Service Plan, in case the resources are not enough. Another option for keeping the azure storage backed-up remotely to an FTP server, is the use of a 3rd party tool, called GoodSync (www.goodsync.com (opens in a new tab)) that can take care of synchronizing the two sides (azure storage and ftp sever), in a one-way configuration. In that way, any deletions happening to azure storage, are not propagated to the ftp server, and any modified files, can be kept historically for a configurable amount of time.
This tool can be hosted either on a virtual machine on azure, or on CBC premises, preferably at the same location as the FTP server. It will be configured in backup mode, taking the contents of azure storage and saving them to the FTP server. This option requires the proper license for GoodSync to operate on the respective OS and the cost of the virtual machine to run this under.
6.4 Traffic Manager
Microsoft Azure Traffic Manager allows you to control the distribution of user traffic for service endpoints in different datacenters. It can be used as the customer base expands globally and we want users to be served by a local instance of the app, to reduce latency and improve the experience. It works at the DNS level, by resolving to a different IP, depending on the location the user is visiting. Further, it can monitor the health of underlying services (i.e. azure web app) and can delegate traffic to a healthy instance, increasing the availability of the overall platform. Careful planning is required, on how the underlying services must be distributed, which parts will remain common across the instances (i.e. azure storage, database), depending on the usage of the platform. In the case of storage, an option is to delegate read-only request to the secondary copy of it (located on another geo-location), and write request to the main instance. Azure storage can also be connected with azure CDN, which is a fast Content Deliver Network, distributed globally. The same can be done for the database, as the geo-replicated database can be accessed as read-only. For the database we can have multiple replications, across all azure datacentres. Finally, if write-request become a bottleneck for the platform, we can introduce synchronized databases, distributed to different datacentres. In that case, the application logic will also need to adjust to accommodate for this scenario and handle deadlocks gracefully. For azure storage, the architecture can be adjusted, so files are stored closest to their source, where they are most likely to be accessed. In essence, the platform will be aware of multiple storage locations and will delegate write requests to the appropriate one.