Akumina Security and Infrastructure Overview - Akumina Community

Akumina Security and Infrastructure Overview

You are here:
Estimated reading time: 6 min

Purpose

The purpose of this document is to provide an overview of the Akumina security mechanisms and some of the infrastructure that that is utilized to support the dataflows of our Presentation and Management frameworks and applications.

Data Flows

The following URLs and protocols are used in the communications within the Akumina solution:

Protocol https
Port 443
App Manager URI https://<akuminatenantid>.onakumina.com/ or any custom URI
Resource URI SharePoint Resource URI: https://<teanantid>.sharepoint.com

Microsoft Graph URI: https://graph.microsoft.com/

Akumina Data Hub can connect to any Resource URI using SSO enabled OAUTH supported resource server, for example Google Drive, Salesforce, Box, etc.,

 

The following diagram depicts the communication paths/data flows within the Akumina solution.

  1. User requests login through the front-end site
  2. Request made to Azure AD to validate credentials.
  3. Azure AD returns authentication information to allow login to front-end site
  4. Akumina Services Hub (ASH) accessed by the Presentation Framework at which time the user identity is passed to the application
  5. ASH uses Single Sign-On (SSO) to request resource token.  The Akumina Services Hub also requests the Graph API token
  6. Azure AD returns authorized resource token as well as the Graph API token (when applicable).
  7. The ASH requests data through the Graph API endpoint
  8. Graph API returns the requested data to the ASH
  9. The Graph token is stored in an Azure Table created, configured and under the control of the customer. See “Data Encryption Mechanisms” section.
  10. Graph API connection info passed to the Presentation Framework. This enables the rendering and additional functionality in the front-end site including authorized access to the AppManager application for content editors, admins, etc.
  11. AppManager/SharePoint communications for the management of SharePoint list data

Data Encryption Mechanisms

The following details the custom encryption mechanisms that can be employed to protect data that is transmitted and stored in Azure.

Client-Side Encryption

Data can be encrypted by the AppManager/Akumina Services Hub prior to sending the data to the Azure Storage Table (or a customer supplied secure storage location).  Note that all data, encrypted or not, always travels over secure https protocols.

  • The object data is encrypted using AES 256 encryption algorithms
  • For tighter security, the encryption key is stored in the Azure Key Vault, ensuring that only authenticated users/applications can access.
  • Once the data is encrypted, it is transmitted via https to the Azure Storage blob/table
  • For data retrieval, the process is reversed.  Encrypted data is retrieved from Azure Storage and decrypted using the encryption key stored in the Azure Key Vault.

Client-Side Encryption using Envelope techniques

Data can be encrypted using Azure storage client library prior to sending the data to the Azure Storage.

  • The object data is encrypted using content encryption key (CEK) generated by storage client library
  • The CEK is then wrapped (encrypted) using key encryption key (KEK)
  • For tighter security, the encryption key is stored in the Azure Key Vault, ensuring that only authenticated users/applications can access.
  • Encrypted data along with KEK transmitted via https to the Azure storage
  • For data retrieval, the process is reversed.  Encrypted data is retrieved from Azure Storage and decrypted using the encryption key stored in the Azure Key Vault.

Server-Side Encryption

Using Server-Side encryption:

  • Key configuration configured with in Azure service either by using customer owned or service owned key.
  • For service owned keys Azure rotates the keys for better security but no control over encryption keys
  • For customer owned keys adds benefits of control over encryption keys
  • AppManager/Services Hub sends the data over https request.  The Azure Storage services encrypt the data using their proprietary encryption algorithms and stores it in the Azure blob/tables.  The encryption key does not persist on the Azure storage server.
  • When a request for data is made from the AppManager/Services Hub, the Azure storage returns the decrypted data.
  • See “Azure Storage Server-Side Encryption” topic for configuration steps

Combining Encryption Methods

Note that client-side and server-side encryption can be used together to maximize the security of the data.  However, with any encryption there is overhead involved which can have some impact on performance.  In general, the following applies:

  1. Client-side encryption (CSE) only – least impact on performance
  2. Client-side encryption (CSE) with envelop –  higher security
  3. Server-side encryption (SSE) – higher security.  In this case Akumina do not have access to encryption or key management.
  4. Using both CSE and SSE – highest security, most impact on performance due to the number of encryption/decryptions operations happening on both the client and server.

Data Persistence

No data is stored within the Akumina system.  All data persistence occurs within the Microsoft (or customer) provided storage mechanisms.

Specifically, in the cloud-based solution, data persists in the following locations:

  • O365
  • SharePoint list data
  • Outlook, Planner and Calendar if using the Akumina Workspaces feature
  • Azure AD
  • Azure Storage (and/or customer configured secured storage location).  See “Data Encryption Mechanisms” section.

Credentials/Permissions/Roles Handling

The Microsoft O365 portal provides the login mechanism for users entering the site.  Azure AD is the identity provider, responsible for verifying the identity of a user, and ultimately issuing security tokens upon successful authentication of that user.

For permissioning of operations during the setup and use of the AppManager and Framework components, SharePoint group membership and group permission levels provide the governance.   The permissions rules follow SharePoint definitions and restrictions in all cases.  Azure AD groups can also be embedded within a SharePoint group and the users in the AD group will be recognized.

The following table lists the roles/actions in the system associated with installing, configuring and using the AppManager and Framework-based front-end intranet site.

The default SharePoint groups names are only used to reflect the permission levels required to perform the actions. There is no dependency on the group name, only the permissions assigned.

Role Actions
Azure Portal Admin Configuring/Managing Azure AD and creating the Graph API App required when Graph API dependent Akumina features are enabled
SharePoint Tenant Admin Installing AppManager in the App Catalog
SharePoint Site Collection Admin Adding AppManager to the Site Collection

Configuring certain SharePoint Site Collection Settings options as called out in the installation guide

SharePoint Site “Owner” Initial Configuration of AppManager Settings including Site URL and permissions mapping of AppManager Administrative and Reporting access to SharePoint Groups

Access to front-end site controls for widget editing.

Typically, the level enabled for

  • The initial AppManager Deployment of Akumina Frameworks into the root Site Collection
  • AppManager Deployment of the Foundation Site Root site.
  • AppManager Deployment of Foundation Site Departments (subsites) into the Site Collection.  The user can be an “Owner” at only the subsite level for this action

 

SharePoint Site “Content Editor” Typically has SharePoint Site “Member” (Contributor) level of access as they need to have read/write permissions to the list.  Each Content App can have its own permission group assigned to enable access control down to the individual user level.
SharePoint Site “Members” Typically used to enable general user access with contribution capability to the front-end intranet site (such as adding documents, commenting, etc.).  Permissions are set on the SharePoint lists themselves to control access to the content.  Permissions are respected by the Akumina widgets to enable/disable content presentation.
SharePoint Site “Visitors” Typically used to provide “read-only” access to the content on the front-end site.  Again, access to content for this group is controlled within the SharePoint list permissions mapping.

GDPR Compliance

Akumina’s solution facilitates compliance with the EU General Data Protection Regulation (GDPR) via a combination of several methods:

  • The underlying platform (SharePoint, Office 365 and Azure Active Directory) facilitating compliance
  • Limiting the amount of data subject to the GDPR
  • For data subject to the GDPR:
    • Data is already consented to.
    • Actions required for compliance are defaults.
  • Security and data encryption methods outlined in previous sections of this topic

The following table summarizes Akumina compliance with some of the key aspects of GDPR compliance:

GDPR Attribute Akumina Solution Applicability/Compliance
Categories of personal data and data subjects Current employee data
Elements of personal data included within each data category Name, Email, Job Title, Department, Office Location, Phone Number, Office Number
Source of the personal data From Company directory (Azure AD), which is collected directly from individuals employed by the organization.
Purposes for which personal data is processed User company Directory.
Legal basis for each processing purpose (non-special categories of personal data) Consent.
Special categories of personal data N/A
Legal basis for processing special categories of personal data N/A
Retention period The duration of the person’s employment.
Action required to be GDPR compliant? The Akumina people sync will update the data store with the current employee information. By default, this runs every minute, or can be run on demand, so when a person leaves the company, this will remove their information from the data store.

 

References

Akumina Hosting Security Policy

Akumina enforces security as a high priority, and relies on Azure Security center recommendations for our procedures. The following are the steps that we take as part of our hosting policy to secure Akumina Applications;

  • Periodically review the applicable security recommendations using the Azure Security Center
  • Follow the strong password rotation policy
  • Enforce restricted port access
  • Keep up-to-date on the latest OS patches
Was this article helpful?
Dislike 0
Views: 56
//]]>