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.
The following URLs and protocols are used in the communications within the Akumina solution:
| Protocol | https |
| Port | 443 |
| AppManager 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.
The following details the custom encryption mechanisms that can be employed to protect data that is transmitted and stored in Azure.
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.
Data can be encrypted using Azure storage client library prior to sending the data to the Azure Storage.
Using Server-Side encryption:
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:
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:
Please reference here for information on Akumina Cookies.
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
|
| 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. |
Akumina’s solution facilitates compliance with the EU General Data Protection Regulation (GDPR) via a combination of several methods:
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 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;