Security of UpSlide endpoints

Avatar
Written by Jérôme | Updated

UpSlide is a desktop application and all documents produced or used by UpSlide are stored within our client network (or tenant). However, to function optimally, UpSlide needs to connect to webservices hosted in UpSlide Microsoft Azure tenant. This articles describes how these ressources are secured. 

Our Azure Stack

The endpoints UpSlide connects to are:

  • Software licensing: Azure AppService (ASP.NET Stack) and Azure SQL Database
  • Usage Stats: Azure AppService (ASP.NET Stack) and Azure SQL Database
  • Software Update and Settings: Azure AppService, Azure SQL Database and Azure Storage Account (especially blob storage)

How this infrastructure is monitored

To ensure availability and performance of our endpoints, we use Azure Monitor (combined with App Insights App services) to collect and display data, such as Exception Rates and Response time, in real time on interactive dashboards.

How we secure access to those resources

Least access privileges scheme is used here:

  • Nobody working at UpSlide except IT C-Levels have the owner (full) permissions on our subscription. 
  • Members of the Development Team have write premissions on test and staging ressources. Not on production data or services. 
  • The IT Team have rights on resource creation and management. Delete locks are in place to ensure that nothing is deleted due to human error. 
  • The Accounting team only has billing admin rights to manage costs. 

All secrets needed to access our automated releases pipelines (such as SAS Keys to upload to our blob storages, SQL DB Credentials, Certificates passwords) are stored in Azure Key Vaults.

How we ensure that our Azure Resources themselves are secured

Please note that since we rely on Platform as a service (PaaS) solutions, this part won’t cover the “system” part of the security such as software updates since this is handled by Azure natively (more details here or here).

UpSlide infrastructure doesn't rely on any IaaS (VM / Containers) services which could need manual patching.

  • Azure AppServices:
    • Custom rules monitoring alerts are in place to detect any PenTest/Intrusion attempts.
    • Each code is scanned before release using a code analysis engine. We use Sonarqube to analyse our code quality and detect potential vulnerabilities.
    • Every 3 Months, an automated Vulnerability Scanner scans our endpoints for any known vulnerabilities.
    • All communication between UpSlide and the AppService is encrypted before transit using AES 256 and is sent over HTTPS.
  • Azure SQL Databases:
    • No external access can be made to our databases except from Trusted IP and Azure Services. 
    • Weekly Vulnerability scan is done to ensure that no security issues are raised (access rights too permissive, unknown IP’s whitelisted, etc…). 
    • Azure SQL Data encryption is enabled and enforced using Azure policies to our subscription.
  • Azure Storage Accounts:
    • Encryption at rest and in transit is enabled by default on Storage accounts. 
    • Use of Storage Access Keys to upload / read on storage accounts instead of storage account key that is too permissive.
    • Storage accounts have security level access set to “blob only." This ensures that our packages can be downloaded by everyone, but our storage account can’t be enumerated (no public access except to final resource which is given to client software by our app service). 
  • All of our infrastructure relies on Azure AD Accounts, and MFA (Multi Factor Authentication) is enforced for all people working at UpSlide, reducing the risk of compromising one of our user accounts.