SaaS Customer Security for Web Applications built on Azure Static HTML Architecture

Azure Static HTML Architecture provides SaaS providers with a ready environment to build, deploy, and operate Web applications, freeing the providers of the need to buy, build, and maintain the supporting infrastructure. See: https://docs.microsoft.com/en-us/dotnet/standard/modern-web-apps-azure-architecture/common-web-application-architectures .

Primary elements of the Architecture include:

  1. Azure Active Directory.
  2. Application development, deployment, and execution environment.
  3. Azure SQL Database
  4. Azure Blob Storage (for Application and Web Server log files).
  5. Azure Management Portal

The SaaS customer in this architecture faces multiple security issues and options.  The primary security issue is three players in the model and their varied security roles and responsibilities: Azure; the SaaS provider; and the Customer itself.  The following is a broad division of security responsibilities:

  1. Microsoft Azure: Security and testing/assurance of the Azure architecture including SSAE 16 audits and reporting.
  2. SaaS Provider: Secure DevOps; Azure Security assurance and testing; SaaS Web application security and testing; SaaS customer baseline security standards and enforcement; implementation of client security options; and SSAE 16 audit and reporting on its Web application security and controls including development, maintenance, and support processes.
  3. SaaS Customer: Identity and access management for its SaaS users; selection and implementation of security options; data security; and SaaS Web application security assurance. 

Note that we added above what might be considered a unique requirement on the SaaS Provider...to define and enforce baseline security standards on its customers (in a multi-tenant solution), even in those instances in which customers have a dedicated SQL database. Azure and other cloud providers offer a variety of more and less secure features, and SaaS customers that implement strong security could be at risk of compromise due to customers that choose weaker security options.  We would argue that the SaaS provider has a responsibility to assure that all of its customers comply with a security baseline to establish security controls for the benefit of all of its customers.

Looking at the security options, we make the following security recommendations, many of which may equally apply to other Azure architectures and other cloud providers:

  1. Identity & Access Management
    • Use Azure Strong Passwords.
    • Use Azure Multi-Factor Authentication.
    • Self-Administer user accounts and roles; provision roles using a least-privilege approach.
    • Assure the encryption of sign on credentials from user entry to the Web application.
    • Secure HTTP and Session Cookies: Security for HTTPS and cookies continue to evolve.  Verify that against a best-practice source (owasp.org) that your SaaS provider has implemented highly secure configurations.
       
  2. File Transfer: Use Azure Managed File Transfer instead of SFTP.
     
  3. SQL Database:
    • Use Azure Transport Layer security (Data in Motion).
    • Use Azure TDE encryption (Data at Rest).
    • Store encryption keys in the Azure Key Vault.  If required, Azure also provides a Hardware Security Module using Azure Key Vault
    • For password-based encryption, define and secure your own encryption passwords.
       
  4. Database & Data Security
    • Use Azure Data Discovery & Classification to identify and enable focused auditing of sensitive data.
    • Actively maximize the use of Azure SQL database Auditing and Threat Detection capabilities.
    • Establish procedures to collaborate with your SaaS provider's Security Operations Center or Technical Support team on the investigation and resolution of security incidents and alerts. 
    • If required, Azure also provides fine-grained security at the Row and Cell level, and data masking capabilities.

The above list highlights certain critical security controls, but it is not exhaustive.  Customers of SaaS applications should complete their security due diligence in advance of a purchase of the solution.  This does not necessarily result in a Go/No-Go decision, but it certainly should result in the selection of higher than lower security options.  To that end, the prospective SaaS customer should:

  1. Research and identify relevant security options and configurations.
  2. Ask your SaaS provider for specific security and secure configuration information: How does the provider secure encryption passwords and keys?  Don't accept simple answers such as “We use HTTPS.”  Ask to see the provider's secure configuration script for HTTPS and cookies.
  3. Obtain your SaaS provider's commitment to your specific security requirements, secure configurations, and security procedures in your services agreement and/or supporting service level agreements.
Rate this article: 
No votes yet
Article category: