Changes for page eMagiz Security Guide

Last modified by Waria on 2026/07/23 09:35

From 40.1 to 39.1 From 62.1 to 61.1

From version 61.1

edited by Waria
on 2026/06/23 12:57

Change comment: There is no comment for this version

To version 40.1

edited by Erik Bakker
on 2024/08/08 11:54

Change comment: There is no comment for this version

Raw
Rendered

Summary

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

Details

Page properties

Author

@@ -1,1 +1,1 @@
--XWiki.waria
++XWiki.ebakker

Content

@@ -1,5 +1,5 @@
  {{container}}{{container layoutStyle="columns"}}(((
--In this fundamental, we will delve into the security perspective of the eMagiz landscape. We'll explore the cloud setup, data protection, and more to understand the role security plays in each part of the eMagiz architecture. Let's dive in!
++in this fundamental, we will delve into the security perspective of the eMagiz landscape. We'll explore the cloud setup, data protection, and more to understand the role security plays in each part of the eMagiz architecture. Let's dive in!
  Should you have any questions, please get in touch with academy@emagiz.com.
@@ -10,36 +10,33 @@
  == 2. Key concepts ==
  * Protecting your data is a joint responsibility between eMagiz and you
--* The registry containing deployable flows is read-only for clients
++* The repository is read-only for clients
  * Data in the Cloud is kept within your VPC
  * 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 at clarifying 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.
++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.
  === 3.1 Architectural setup eMagiz ===
  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.
--* Your customized flows are combined with a base image (which contains framework components to make the flows work) and are deployed 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).
++1. 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).
++3. 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.
--[[image:Main.Images.Fundamental.WebHome@fundamental-emagiz-security-guide--emagiz-architecture.png]]
++To prevent unauthorized access to this repository, the following measures have been taken
--Your flows are stored within a registry so deployments can be managed efficiently. 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.
++[[image:Main.Images.Fundamental.WebHome@fundamental-emagiz-security-guide--definition-emagiz-model.png]]
--* Deploy agents can access the registry and can read the contents belonging to your eMagiz integration project only.
--* Client runtimes can read specific flows within the registry as provided by the deploy agent to deploy the flows
--* When running your eMagiz integration project in the cloud, security during communication between eMagiz and the registry is taken care of by the eMagiz cloud.
--* When running your eMagiz integration project on-premises, you will have to make sure that your server is running Docker and the eMagiz deploy agent so the server can access the registry successfully and securely. For more information on this look here: [[eMagiz Deploy Agent>>doc:Main.eMagiz Academy.Microlearnings.Intermediate Level.eMagiz Runtime Management.intermediate-runtime-management-deploy-agent.WebHome||target="blank"]]
--* A bitbucket pipeline can access the registry to update the provided base image that is needed to run all your flows. This pipeline cannot access your flows, only the libraries used to build your flows.
--* Connections to the registry are always one-way SSL (encrypted) and all access is secured with a unique username/password combination.
--* As mentioned above, the registry is read-only for agents and client runtimes. 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 registry. They can only read the data that is kept in the registry.
--
  === 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.
@@ -101,11 +101,21 @@
  ===== 3.3.1.1 Rights for installing =====
--To run your runtimes on-premises, Docker and the eMagiz deploy agent need to be installed and updated when required. On Windows machines, you will need administrator rights to perform these actions. On Linux machines, you need at least sudo privileges for these actions.
++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.
++===== 3.3.1.2 Rights for running =====
++
++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.
++
++In Linux, the service will be running under the local system account as per default.
++
  ==== 3.3.2 Cloud ====
--In the eMagiz Cloud, access is restricted to those who have a legitimate reason to access it based on the SLA level agreements between customers and eMagiz. This means support engineers, consignment employees, and your model owner have access to your specific cloud setup.
++In the eMagiz Cloud, the access is restricted to those who have a legitimate reason to access it based on the SLA level agreements between customers and eMagiz. This means support engineers, consignment employees, and your model owner have access to your specific cloud setup.
  This access is, per role, furthermore limited. This means that consignment employees and model owners can only see the logging of the runtimes on the machine and the ability to start/stop machines.
  Support engineers can see more to analyze problems on a lower level.
@@ -118,7 +118,7 @@
  ===== 3.3.2.2 Rights for running =====
--The VPC in the Cloud runs on a Linux environment. Therefore, the same logic applies as specified above for Linux systems. For example, in Linux, the service will run under the local system account as default.
++The VPC in the Cloud runs on a Linux environment. Therefore the same logic applies as specified above for Linux systems. For example, in Linux, the service will run under the local system account as default.
  === 3.4 Data encryption during transport ===
@@ -131,8 +131,10 @@
  [[image:Main.Images.Fundamental.WebHome@fundamental-emagiz-security-guide--data-orchestration.png]]
  Data "in transit" is temporarily stored on an encrypted filesystem with the help of encryption algorithms.
--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.
--The runtime image release notes mention the currently enabled cipher suites in case they have changed: [[Runtime Images release notes>>doc:Main.Release Information.Runtime Images.WebHome||target="blank"]]
++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.
  Above, we mentioned that data "in transit" is temporarily stored. This can happen in two places:
@@ -164,11 +164,23 @@
  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 ====
--To secure the front end of the API Gateway in eMagiz rights can be assigned to users in User Management. Users are automatically created for systems integrated by the API pattern in the Portal. Next to that manual users can be added for external systems that interact with the eMagiz API Gateway. You can configure read and write rights per created operation in your model. If a user has insufficient rights for the requested action, they will receive 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.
--===== 3.5.2.1 Error handling =====
++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. 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.
++===== 3.5.2.1 Portal =====
++
++As you can see in the picture shown below, the roles are defined so that the Read role can only access two integrations available for this specific API Gateway. If a client has insufficient rights, they will receive a 401 Unauthorized
++
++[[image:Main.Images.Fundamental.WebHome@fundamental-emagiz-security-guide--api-gateway-portal-feedback.png]]
++
++===== 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.
++If the client has sufficient rights, the process continues. For example, if the client has insufficient rights, the client receives a 401 Unauthorized.
++
++===== 3.5.2.3 Error handling =====
++
  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>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course API Gateway.crashcourse-api-gateway-configure-roles-and-users||target="blank"]].
@@ -179,12 +179,13 @@
  Only users with sufficient rights in the Deploy phase of eMagiz can add users, topics and change the ACL entries specific to the Event Streaming cluster.
--Apart from producing on or consuming specific topics based on the ACL, users need to authenticate themselves on the Event Streaming cluster using 2-way SSL. For this they need a client certificate (also known as a keystore) and the trusted server certificate (also known as truststore).
++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.
  For more information on how this precisely can be configured via the eMagiz platform, please check the following [[microlearning>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Event Streaming.crashcourse-eventstreaming-user-management||target="blank"]].
++
  === 3.6 eMagiz iPaaS Portal ===
  The eMagiz portal provides access to users to manage their eMagiz integration configurations. It provides access to all the features to develop, deploy and manage integrations across Test, Acceptance, and Production environments.
@@ -224,7 +224,7 @@
  Below are relevant items for the password policy in the eMagiz portal.
--* There is no expiry policy on the password - eMagiz has a Forgot 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 ====
@@ -247,27 +247,28 @@
  === 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 username 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 administrators and contain no personal data.
++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 ===
--Within the basic configuration, eMagiz only processes the data and does not keep any data. 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.
++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 ====
--In the integrations where the Messaging pattern is selected, the entry connectors (runtimes that receive or pull messages) are equipped with a small temporary database to ensure the messages are preserved in this phase. In case of brief downtime of consecutive components where these messages are processed, these messages are held. This is one part of the Guaranteed Delivery mechanism in eMagiz. Messages are encrypted (AES-128) and stored until the message is processed. Depending on input received and throughput achieved by the poller, a message is kept between seconds and minutes in the database.
--The database can only be thoroughly cleaned if needed by removing the data file of this database. Only users that have sufficient permissions can execute this action.
++In the integrations where the Messaging pattern is selected, the entry connectors (runtimes that receive or pull messages) are equipped with a small temporary database to ensure the letters are preserved in this phase. In case of brief downtime of consecutive components where these messages are processed, these messages are held. This is one part of the Guaranteed Delivery mechanism in eMagiz. Messages are encrypted (AES-128) and stored until the message is processed * the database can only be thoroughly cleaned if needed by removing the data file of this database. Only users that have sufficient permissions can restart. Depending on input received and throughput achieved by polling the database, this can range between seconds and minutes that a message is kept in the database.
++The eMagiz JMS component manages the queues between the different steps in the integration flow. All data within these queues are encrypted via an encryption algorithm (AES-256), and data will only be retained here until the next step in the process is ready to consume the data.
--The eMagiz JMS server manages the queues between the different steps in the integration flow. All data within these queues are encrypted via an encryption algorithm (AES-256), and data will only be retained here until the next step in the process is ready to consume the data.
--
  ==== 3.8.2 Event Streaming ====
--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 (between 2 and 7 days, depending on configuration and license) to ensure that consumers have sufficient time to consume the data before it is deleted.
--For details on how your data is secured during retention, such as encryption and back-up policies, we refer you to the security policies of our provider KPN DSH: https://policy-public.kpnnet.org/ksp/explore/ksp-taxonomy/560104
++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.
++* 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.
@@ -292,7 +292,7 @@
  == 4. Key takeaways ==
  * Protecting your data is a joint responsibility between eMagiz and you
--* The registry containing deployable flows is read-only for clients
++* The repository is read-only for clients
  * Data in the Cloud is kept within your VPC
  * The portal is behind an MFA check
@@ -304,7 +304,6 @@
  * [[Crash Courses (Menu)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.WebHome||target="blank"]]
  ** [[Crash Course Platform (Navigation)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Platform.WebHome||target="blank"]]
  *** [[Security - Add MFA (Explanation)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Platform.crashcourse-platform-security-add-mfa.WebHome||target="blank"]]
--*** [[Portal Security - Basic (Explanation)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Platform.crashcourse-platform-manage-portal-security-basic||target="blank"]]
  ** [[Crash Course API Gateway (Navigation)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course API Gateway.WebHome||target="blank"]]
  ** [[Configure Roles and Users (Explanation)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course API Gateway.crashcourse-api-gateway-configure-roles-and-users||target="blank"]]
  ** [[Crash Course Event Streaming (Navigation)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Event Streaming.WebHome||target="blank"]]