MOR-PLN-067 Version 1 Last Review Date: Nov, 2024
Security
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. Security and Encryption
2.1 SSL Certificate
To secure data transmission from web apps to end users, the use of CBC’s wildcard SSL Certificate has being been installed and applied to all instances of web apps. This enables the encryption of the http communication, protecting sensitive information during transmission between the web app and the end user of the platform.
The SSL Certificate is issued by a 3rd party and provided by CBC directly and installed on azure to be used on the web apps.
Since also WAF is used, and it communicates via http with web applications, https-only setting can’t be enabled on web apps. When accessed through WAF – it forces https access, but the internal addresses are still accessible via http. In order to ameliorate this – access to internal web app addresses is allowed only within the internal VPN network, so no external access is allowed via web apps original address* (not yet applied to prod):
2.2 SQL Server & databases
On the Azure SQL Server instance, only Azure services are allowed access and any IP addresses that are whitelisted under the ‘Firewall settings’ section. This effectively blocks any attempts to access the SQL Server from unauthorised users. Further, access to the SQL Server is restricted behind a user account, protected with a password. Finally, all databases have the ‘Transparent data encryption’ option enabled, to have any database related files (databases, backups, logs) encrypted while at rest.
2.3 Storage Account* (not yet applied to prod)
Access to azure storage accounts is granted only after providing their respective Access Key, that can be revoked and regenerated at any time, via the azure portal. Public access to resources is disabled.
2.4 Key vault
Key vault is an offered service provided by Azure, to securely store and access secrets, like private keys and account passwords. Any azure service that requires to authenticate to another service, can access the key or passwords from the vault. An example would be the Automation service, when it needs to access an SQL server and trigger a store procedure.
2.5 TLS* (*not yet applied to prod)
HTTPS/TLS version 1.2 is used wherever the infrastructure allows it: • SQL Server instances • CosmosDB • Storage account • Service Bus o Access to ports 9350-9354 needs to be blocked by a local firewall, in order to prevent http access. This seems to be available only on premium tier. • SignalR HTTPS/TLS is not enabled on Redis (see improvements section for further detail).
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.