Changes for page eMagiz Security Guide

Last modified by Erik Bakker on 2023/01/02 10:25

From 2.1 to 3.1

From version 1.1

edited by eMagiz
on 2022/06/13 09:29

Change comment: There is no comment for this version

To version 2.1

edited by eMagiz
on 2022/06/13 09:31

Change comment: There is no comment for this version

Raw
Rendered

Summary

Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

@@ -1,20 +1,12 @@
  {{html wiki="true"}}
  <div class="ez-academy">
      <div class="ez-academy_body">
--
--
--            <li class="doc-nav__item"><a href="../../docs/fundamental/index_academy_fundamental_all" class="doc-nav__link">Home</a></li>
--
--
--
--
--
  <div class="doc">
  = eMagiz Security Guide =
--
++
  In this fundamental, we will zoom in on how the various parts of the eMagiz landscape can be viewed from a Security perspective. We will look at the Cloud, on-premises, data within eMagiz, external communication, and the portal during our journey. After this journey, you should have a solid understanding of what role security plays in each of the parts of the eMagiz architecture. Note that protecting your data is a joint responsibility between eMagiz and you. This fundamental aims to clarify the security measures eMagiz has taken in the eMagiz platform. This way, you can assess the eventual additional steps you need to take to ensure that the eMagiz service cooperates securely with the rest of your application and integration landscape.
  Should you have any questions, please get in touch with academy@emagiz.com.
@@ -23,9 +23,11 @@
  * Required reading time: 15 minutes
  == 1. Prerequisites ==
++
  * Some context on cloud functionality will be helpful.
  == 2. Key concepts ==
++
  * Protecting your data is a joint responsibility between eMagiz and you
  * The repository is read-only for clients
  * Data in the Cloud is kept within your VPC
@@ -32,7 +32,7 @@
  * Production data in the portal is behind an MFA check
--
++
  == 3. eMagiz Security Guide ==
  In this fundamental, we will zoom in on how the various parts of the eMagiz landscape can be viewed from a Security perspective. We will look at the Cloud, on-premises, data within eMagiz, external communication, and the portal during our journey. After this journey, you should have a solid understanding of what role security plays in each of the parts of the eMagiz architecture. Note that protecting your data is a joint responsibility between eMagiz and you. This fundamental aims to clarify the security measures eMagiz has taken in the eMagiz platform. This way, you can assess the eventual additional steps you need to take to ensure that the eMagiz service cooperates securely with the rest of your application and integration landscape.
@@ -42,21 +42,20 @@
  eMagiz consists of various components communicating to develop the process layer and subsequently run the message layer as secure and stable as possible for our customers.
 . In the eMagiz integration project, various flows are created that work together to realize the integration. The different types are shown on the top of the picture below: Entry, Exits, Offramps, onramps, and routing flows.
--2. These flows are then deployed together with a specific build number (contains framework components to make these flows work) into a runtime (java based application container).
++2. These flows are then deployed together with a specific build number (contains framework components to make these flows work) into a runtime (java based application container).
 . These runtimes run on Cloud machines that contain Cloud templates (all required components to make the Cloud machine operational such as OS, Java runtime version, and more).
  The top part of the picture depicts the eMagiz repository. All relevant (open-source) libraries needed to run flows on a connector are stored within this repository.
  To prevent unauthorized access to this repository, the following measures have been taken
--*   Client runtimes can access the repository via a username/password combination through a one-way SSL connection (encrypted) and read the contents of the repository
--*   eMagiz developers that need to upload bundles can access the repository through a one-way SSL connection (encrypted)
--*   A bitbucket pipeline will be created soon to enable automatic updates. This data pipeline will also need a unique username/password combination along with the fact that the connection itself is a one-way SSL connection (encrypted)
--*   The repository is read-only for clients. This means that even if someone gets their hands on a username/password combination, they do not have sufficient rights to alter anything in the repository. They can only read the data that is kept in the repository.
++* Client runtimes can access the repository via a username/password combination through a one-way SSL connection (encrypted) and read the contents of the repository
++* eMagiz developers that need to upload bundles can access the repository through a one-way SSL connection (encrypted)
++* A bitbucket pipeline will be created soon to enable automatic updates. This data pipeline will also need a unique username/password combination along with the fact that the connection itself is a one-way SSL connection (encrypted)
++* The repository is read-only for clients. This means that even if someone gets their hands on a username/password combination, they do not have sufficient rights to alter anything in the repository. They can only read the data that is kept in the repository.
  <p align="center">[[image:fundamental-emagiz-security-guide--definition-emagiz-model.png||]]</p>
--
  === 3.2 Security Guidelines * Cloud ===
  In this section, we take a closer look at the cloud setup in general. Here we will focus on high-level security measurements because we already specified security measurements at the data level.
@@ -64,7 +64,7 @@
  ==== 3.2.1 Cloud setup ====
  The picture below shows a standard double-lane setup of an eMagiz instance within the eMagiz Cloud. A single-lane design looks similar but only consists of one core machine.
--This gives insight into how messages flow through the Cloud, which measures are taken for monitoring and auto-healing, and where data is temporarily stored 'in transit.'
++This gives insight into how messages flow through the Cloud, which measures are taken for monitoring and auto-healing, and where data is temporarily stored 'in transit.'
  <p align="center">[[image:fundamental-emagiz-cloud-inner-workings--customer-level-overview-double-lane.png||]]</p>
@@ -83,7 +83,7 @@
  Incoming data from the internet passes through a load balancer to route data randomly to one of the core machines containing the runtimes holding the process flows. The setup of a VPC is governed by what we call a Cloud Template.
  ==== 3.2.4 Cloud template ====
--
++
  This Cloud Template, designed by eMagiz, defines the setup of the cloud instance. The following parts of the cloud setup are configured here:
  * Java version
@@ -113,10 +113,9 @@
  On-premises means that the runtimes are running on a machine outside the direct control of eMagiz. This means that the machine is running under the control of the customer within their IT landscape.
--Because the machine is outside the direct scope of control of eMagiz, it becomes a joint effort between eMagiz and you as a customer to make sure that not everyone can access this machine. This becomes even more important when working with file-based actions as part of your integration.
++Because the machine is outside the direct scope of control of eMagiz, it becomes a joint effort between eMagiz and you as a customer to make sure that not everyone can access this machine. This becomes even more important when working with file-based actions as part of your integration.
  Advice would be to govern this via an IDP (i.e., Azure AD) so you can set up roles that have access to the machine or parts of the machine (i.e., some files).
--
  ===== 3.3.1.1 Rights for installing =====
  To install a runtime on-premises, you need sufficient rights to execute (batch) programs. This means that the user needs administrator rights on that specific machine to perform the runtime installation correctly.
@@ -125,7 +125,7 @@
  In Windows, a service account is needed to run a Windows Service (in this case, the runtime you have installed). This service account is different compared to the user that does the installing of the runtime.
  There are two options on this level:
--
++
  * Use the local system account. This account has sufficient rights to run the service and can therefore be used for everything: less work to configure, more impact on data integrity when the account gets compromised.
  * Use a specific service account per runtime, limiting the power of users to a particular runtime making you less vulnerable if this account gets compromised.
@@ -158,9 +158,9 @@
  <p align="center">[[image:fundamental-emagiz-security-guide--data-orchestration.png||]]</p>
--Data "in transit" is temporarily stored on an encrypted filesystem with the help of encryption algorithms.
--For the Cloud, eMagiz uses the AES-256 encryption algorithm.
--For on-premise runtime installations, eMagiz uses the AES-128 encryption algorithm.
++Data "in transit" is temporarily stored on an encrypted filesystem with the help of encryption algorithms.
++For the Cloud, eMagiz uses the AES-256 encryption algorithm.
++For on-premise runtime installations, eMagiz uses the AES-128 encryption algorithm.
  These algorithms ensure that even if third parties could get to the data on that encrypted filesystem, they won't be able to read the data.
  That way, the data is kept confidential.
@@ -174,7 +174,7 @@
  To ensure data integrity in the transport layer of eMagiz, it uses the TLS protocol. This means that all client-server communication is secured via TLS. In eMagiz, this is implemented as follows: The necessary certificates of the client(s) are trusted by the server, and the server is trusted by the client(s). The relevant information is stored in key stores and truststores that are unique per integration project (ll the integration configurations made to a single eMagiz instance spread across the ILM Phase from Capture to Manage). This ensures that data cannot be sent to other client projects or other environments within your project.
  In other words, it prevents others from eavesdropping on your channels. eMagiz follows the standard guidelines when setting up TLS. Therefore, we ensure that the configured trusted certificate authority (CA) bundle that your messaging server uses to verify client connections is limited to only the CA used for your nodes, preferably an internally managed CA.
--=== 3.5 External data exchange  ===
++=== 3.5 External data exchange ===
  Because eMagiz provides the integration between two or more applications via the eMagiz platform, the point at which the data is interchanged between application and integration is a critical part of the integration in terms of security.
  Within eMagiz, there are three main integration patterns a user can configure to support their business case most optimally. First, this section will look at all three integration types in detail and specify the security measures.
@@ -190,9 +190,9 @@
  * SOAP Authentication
  * OAuth2.0
  * Basic Authentication
--
--This way, each connection between the application and the integration (end-point) can be adequately secured and gives the flexibility to confer with the external application which method suits their needs the best.
++This way, each connection between the application and the integration (end-point) can be adequately secured and gives the flexibility to confer with the external application which method suits their needs the best.
++
  ==== 3.5.2 API Gateway ====
  A structure with roles and rights per role can be specified within the portal or via an external IDP to secure the front end of the API Gateway in eMagiz.
@@ -205,8 +205,8 @@
  ===== 3.5.2.2 External IDP =====
--Apart from configuring the roles, users, and rights within the portal itself, it is also possible to hook the API Gateway up to an external IDP.
--By communicating with this IDP via the OAuth2.0 protocol, a check is done every time a client calls a specific operation to see whether that client has sufficient rights to access the operation.
++Apart from configuring the roles, users, and rights within the portal itself, it is also possible to hook the API Gateway up to an external IDP.
++By communicating with this IDP via the OAuth2.0 protocol, a check is done every time a client calls a specific operation to see whether that client has sufficient rights to access the operation.
  If the client has sufficient rights, the process continues. For example, if the client has insufficient rights, the client receives a 401 Unauthorized.
  For the backend of the API Gateway, the same logic applies as stated above for messaging, which means that eMagiz supports the industry standard. Therefore, you as a user should confer with the external party about the correct method.
@@ -215,7 +215,7 @@
  To prevent the error message if it occurs is sent straight back to the client, you can configure the front end of the API Gateway, so that correct HTTP Status codes are given back to the client, including a descriptive message.
-- For more information on how this precisely can be configured via the eMagiz platform, please check the following [microlearning](../microlearning/crashcourse-api-gateway-configure-roles-and-users.md)
++For more information on how this precisely can be configured via the eMagiz platform, please check the following [microlearning](../microlearning/crashcourse-api-gateway-configure-roles-and-users.md)
  ==== 3.5.3 Event Streaming ====
@@ -226,7 +226,7 @@
  Apart from producing or consuming on specific topics based on the ACL, users also need to have a valid Keystore (containing the key and cert generated automatically) and a valid truststore (containing the CA certificate of the event streaming cluster) to produce or consume data.
--These are all security measures to prevent third parties from getting unauthorized access to the data stored on the topics.
++These are all security measures to prevent third parties from getting unauthorized access to the data stored on the topics.
  For more information on how this precisely can be configured via the eMagiz platform, please check the following [microlearning](../microlearning/crashcourse-eventstreaming-user-management.md)
@@ -243,11 +243,12 @@
  ===== 3.6.1.2 Users access to Integration Projects =====
--Users can be added to Integration projects, which hold all the configurations required to run the different integrations for the TAP environments. Integration projects are connected to organizations in eMagiz to ensure the integration project remains within the limits of the license agreements. Users can be added to integration models by a model owner. Users can't be added to integration projects of other clients.
++Users can be added to Integration projects, which hold all the configurations required to run the different integrations for the TAP environments. Integration projects are connected to organizations in eMagiz to ensure the integration project remains within the limits of the license agreements. Users can be added to integration models by a model owner. Users can't be added to integration projects of other clients.
  ===== 3.6.1.3 User authorizations to Integration projects. =====
--Every integration project has a model owner who can distribute rights across functionalities and environments. The picture below shows the various options available across the Integration Life Cycle (ILM) Phases Capture through Manage. In addition, the model owner manages the user permissions and needs to have the MFA authentication level passed before making any changes.
++Every integration project has a model owner who can distribute rights across functionalities and environments. The picture below shows the various options available across the Integration Life Cycle (ILM) Phases Capture through Manage. In addition, the model owner manages the user permissions and needs to have the MFA authentication level passed before making any changes.
++
  * When Edit permission is granted on an ILM phase, all the sub-options are configurable
  * View rights mean that all options can be viewed only
  * In case the user has no Edit or View rights to a specific ILM phase, the phase will not be displayed at all in the eMagiz iPaaS portal
@@ -261,12 +261,14 @@
  Partner organizations are supported in eMagiz. Model owners can grant access to a model to their organization's users and affiliated organizations. On top of that, eMagiz administrators manage the connection between client and partners organization.
  ===== 3.6.1.5 Summary of relevant access to environments for eMagiz Administrators =====
--eMagiz Administrators can view all integration projects and have model owner rights for all integration projects.
--===== 3.6.1.6 Password policy & Validity  =====
++eMagiz Administrators can view all integration projects and have model owner rights for all integration projects.
++
++===== 3.6.1.6 Password policy & Validity =====
++
  Below are relevant items for the password policy in the eMagiz portal.
--* There is no expiry policy on the password - eMagiz has a Forget Password functionality.
++* There is no expiry policy on the password - eMagiz has a Forget Password functionality.
  * Password must be 8 - 20 characters long, cannot contain white spaces, and must contain at least one digit, one upper case, and one lower case letter."
  ==== 3.6.2 Integration project versioning & audit trails ====
@@ -283,17 +283,18 @@
  ==== 3.6.3 eMagiz Monitoring capabilities & Security features ====
--Monitoring your (Production) environment helps you monitor and detect deviations within your environment in near real-time. The ILM phase Manage provides access to errors logs generated in message processing by the platform and monitoring logs of the Cloud components and eMagiz runtimes. All errors and relevant logging is stored for a limited period (two weeks) within eMagiz for auditing or reporting purposes. Furthermore, notifications can be sent to people to alert them of a potential loss of data integrity. These alerts can contain a warning or the actual error that occurred.
++Monitoring your (Production) environment helps you monitor and detect deviations within your environment in near real-time. The ILM phase Manage provides access to errors logs generated in message processing by the platform and monitoring logs of the Cloud components and eMagiz runtimes. All errors and relevant logging is stored for a limited period (two weeks) within eMagiz for auditing or reporting purposes. Furthermore, notifications can be sent to people to alert them of a potential loss of data integrity. These alerts can contain a warning or the actual error that occurred.
  If specific messages are processed but result in validation errors or other errors, the message is sent to the error stack. The developer can view the actual message, including the content, to understand the error reported adequately. For example, the eMagiz store holds a specific transformation (Mask XSLT) that can mask all the fields of the XML message sent to the error stack. It can mask all the fields or only specific fields that contain sensitive data. Clients are requested to make this assessment per integration advised by the eMagiz Partner. In future versions of eMagiz, particular attributes of entities in System Messages or CDM messages can be flagged, so the platform automatically takes care of this feature.
  === 3.7 GDPR compliancy ===
--Our privacy policy is mentioned on this page: https://www.emagiz.com/privacy-policy/. The eMagiz platform holds for registered users only the username and password. The user name is the company email address, and no other data is kept on a personal user level.
++Our privacy policy is mentioned on this page: https://www.emagiz.com/privacy-policy/. The eMagiz platform holds for registered users only the username and password. The user name is the company email address, and no other data is kept on a personal user level.
  The eMagiz portal at https://my.emagiz.com does not store any cookies. Instead, there are functional items only kept in the user's session data once active in the eMagiz portal. Specific logs are created in the eMagiz portal that displays operational issues a user has in using the portal. These logs are only viewable by eMagiz users and contain no personal data.
--=== 3.8 Data retention   ===
++=== 3.8 Data retention ===
++
  eMagiz stores specific integration scenario data. Within the basic configuration, eMagiz only processes the data and doesn't keep any data from these message streams. All messages are treated the same way, and the platform doesn't distinguish between regular, personal, or sensitive data. Clients are requested to make such assessments and take precautionary measures. Below we have detailed the parts of the eMagiz offering, per integration pattern, in which data is held temporarily. Afterward, we turn our focus to our data management offerings in which we store data for a longer period to support the client's needs.
  ==== 3.8.1 Messaging ====
@@ -307,10 +307,9 @@
  In the case of event streaming, data is temporarily kept on the topic within the event streaming cluster. As specified above, access to a topic is secured with the help of the ACL. This is a safeguard against a loss of integrity of data. Regarding Event Streaming, data is retained for a more extended period (often days) to ensure that consumers have sufficient time to consume the data before it is deleted. This does mean that unauthorized third parties can not easily access the data on these topics. In addition, authorized users can edit the retention size and retention times on the topic level.
  * Service instances and the underlying VMs use full volume encryption using LUKS with a randomly generated ephemeral key per each instance and volume. The key is never re-used and will be trashed at the destruction of the instance, so there's a natural key rotation with roll-forward upgrades. We use the LUKS default mode aes-xts-plain64:sha256 with a 512-bit key.
--* Backups are encrypted with a randomly generated key per file. These keys are encrypted with RSA key-encryption key-pair and stored in the header section of each backup segment. The file encryption is performed with AES-256 in CTR mode with HMAC-SHA256 for integrity protection. The RSA key pair is randomly generated for each service. The key lengths are 256-bit for block encryption, 512-bit for integrity protection, and 3072-bits for the RSA key.
++* Backups are encrypted with a randomly generated key per file. These keys are encrypted with RSA key-encryption key-pair and stored in the header section of each backup segment. The file encryption is performed with AES-256 in CTR mode with HMAC-SHA256 for integrity protection. The RSA key pair is randomly generated for each service. The key lengths are 256-bit for block encryption, 512-bit for integrity protection, and 3072-bits for the RSA key.
  * These backup files are stored in the object storage in the same region where the service virtual machines are located.
--
  ==== 3.8.3 API Gateway ====
  At this moment, there is no data stored in eMagiz API Gateways configurations. Instead, backend flows that connect to the APIs being called use the same queuing mechanism as mentioned in the previous section around Messaging.
@@ -341,7 +341,7 @@
  * Production data in the portal is behind an MFA check
  </div>
--</main>
  </div>
  </div>
++
  {{/html}}

Changes for page eMagiz Security Guide

Summary

Details

Navigation