Security

In the past, the security boundary of an enterprise was restricted to the physical premises it occupied. Users had to physically access the building to gain access to endpoints that connected to enterprise data systems.

Over time, the physical boundary has eroded. Users were granted external access to enterprise data through Virtual Private Networks and physical authentication tokens. Some restricted data access was presented on websites – especially for commercial purposes. This has expanded in recent years to encompass mobile applications.

Now users expect to be able to access enterprise data from any location on any device. Increasingly, users are also bringing their own devices, and these are not subject to enterprise control.

ALL users should now be considered as part of the External Environment, and represent a security threat. Even internal users and the devices they use to access enterprise data can’t be fully trusted, so it is better to assume that they may be compromised. For the sake of clarity, we have separated the external threats into two groups:

Security diagram

This illustrates the high-level context for an enterprise solution architecture. The users and applications identified above in the External Environment must have secure access to the solution components (websites, applications, web APIs, queues, storage etc.) in the External Facing Security Zone. This means that identity must be established, enforced and protected well beyond the traditional enterprise security boundary.

In addition to securing access to the External Facing Security Zone from user endpoints, protection needs to be expended to stop leakage of enterprise data beyond the endpoint on to non-enterprise components.

Any component of the solution that is being accessed by external users or applications needs to be placed within the External Facing Service Zone.

All components in the External Facing Service Zone need to be subjected the highest possible levels of security, monitoring, detection and containment. At a network level, this includes external firewalls, network traffic monitoring with incident/event alerting, and containment for anomalous traffic detection. Internally, the services should also be separated from each other by subnets and internal firewalls. At the request level, all requests for access should be properly authenticated, and access to data should be restricted by well-understood authorization rules. All data flowing between the External Environment and the Secure Internal Environment should be encrypted and monitored to ensure that only authorised data is being transferred.

Even solution components that are not exposed directly to the external environment should still be segregated on separate subnets with internal firewalls. All Data At Rest (Persistent Storage) such as file shares, databases, tapes, etc should be encrypted both at the physical and logical level.

Authentication
Stand-alone

The application will create a User Profile record for every person that wishes to use the application. This User Profile will use the person’s Username (typically their email address) and Password to authenticate users as they access the website or mobile application. Once successfully signed, in the User Profile GUID is then used to determine which Workspaces the person can access.

Microsoft Active Directory (AD)

Accounts are maintained in Microsoft Active Directory – Directory Services. When a person has successfully signed in, the AD account GUID is used to determine which Workspaces the person can access.

Azure Active Directory (AAD) B2B

Accounts are maintained in Azure Active Directory B2B. When a person has successfully signed in, the AAD account GUID is used to determine which Workspaces the person can access.

Azure Active Directory (AAD) B2C

Accounts are maintained in Azure Active Directory B2C. When a person has successfully signed in, the AAD account GUID is used to determine which Workspaces the person can access.

Authorization
Workspaces

Each person has a single User Profile record or AAD entry that supplies a User Profile GUID to the application.

Initially, a person has to use an Invitation to join a Workspace with the provided User Profile GUID. The link supplied by the Invitation determines which Workspace the person will join and what functionality will be available to that person. The act of joining a workspace creates a new User record and associated User GUID for the person within the Workspace.

When a person signs into the application, a list of Workspaces that the person has access to is generated. The person is presented with the Workspace List from which they can select a specific Workspace to enter. As they enter the Workspace, the person’s User GUID within the Workspace is retrieved. This User GUID is then used to determine which records the person can see within the workspace.

Application Data

Each record in the database has a Concept GUID, generated when it is created. The Form Definition for the Concept GUID determines whether access control is applied to records of this type when they are listed.

If access control is applied, then before the record is returned in a list, a check is made to determine whether the Instance GUID of the record exists in the Instance Access table associated with either the User GUID or the Group GUID of a group to which the person belongs.

Access controls are ALWAYS applied to attempts to read or save individual application data records, irrespective of the access control setting on the concept’s Form Definition. There are rare cases of system configuration data which are not checked when they are read.

Public Attached Files

This mechanism works well for uploading videos and pictures for social media sites.

Once a file is uploaded into the application, it is stored in a directory (either on a local server or in an Azure Blob container) and given a unique Attachment GUID. Access to the file is then made via http using a URL that contains two GUIDs - the Workspace GUID and Attachment GUID.

Note: any person who has the file attachment URL is assumed to be able to access the file.

Private Attached Files

Once a file is uploaded into the application, it is stored in a directory (either on a local server or in an Azure Blob container) and given a unique Attachment GUID. The file can only be accessed through a Data in Rest call, which will pass the file contents directly and securely to other DaaS services for display or processing.