Wiki source code of eMagiz Security Guide

Version 46.3 by Waria on 2026/06/04 12:21

version	line-number	content
14.1	1	{{container}}{{container layoutStyle="columns"}}(((
41.2	2	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!
1.1	3
	4	Should you have any questions, please get in touch with academy@emagiz.com.
	5
	6	== 1. Prerequisites ==
2.1	7
1.1	8	* Some context on cloud functionality will be helpful.
	9
	10	== 2. Key concepts ==
2.1	11
1.1	12	* Protecting your data is a joint responsibility between eMagiz and you
41.2	13	* The registry containing deployable flows is read-only for clients
1.1	14	* Data in the Cloud is kept within your VPC
32.1	15	* The portal is behind an MFA check
1.1	16
	17	== 3. eMagiz Security Guide ==
	18
41.2	19	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.
1.1	20
	21	=== 3.1 Architectural setup eMagiz ===
	22
	23	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.
	24
41.2	25
	26	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: Entries, exits, offramps, onramps, and routing flows.
	27	2. 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).
1.1	28	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).
	29
	30
41.2	31	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:
1.1	32
	33
41.2	34	* Deploy agents can access the registry and can read the contents belonging to your eMagiz integration project only.
	35	* Client runtimes can read specific flows within the registry as provided by the deploy agent to deploy the flows
	36	* 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.
46.2	37	* 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.
41.2	38	* 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.
	39	* Connections to the registry are always one-way SSL (encrypted) and all access is secured with a unique username/password combination.
	40	* 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.
	41
	42
14.1	43	[[image:Main.Images.Fundamental.WebHome@fundamental-emagiz-security-guide--definition-emagiz-model.png]]
1.1	44
29.1	45	=== 3.2 Security Guidelines - Cloud ===
1.1	46
	47	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.
	48
	49	==== 3.2.1 Cloud setup ====
	50
	51	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.
2.1	52	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.'
1.1	53
14.1	54	[[image:Main.Images.Fundamental.WebHome@fundamental-emagiz-cloud-inner-workings--customer-level-overview-double-lane.png]]
1.1	55
	56	We want to use this picture to explain specific components within the Cloud from a security perspective. We will start at the outside and work our way inwards.
	57
	58	==== 3.2.2 Cloud location ====
	59
	60	There are many regions within the AWS cloud where your cloud setup can be running. Examples of these regions are us-east-1, af-south-1, ap-northeast-1, EU-central-1.
	61
	62	As you can see in the picture, eMagiz cloud slots run within the EU-central-1 region. This region is located in Frankfurt and falls, therefore, under European data and security laws such as the GDPR.
	63
	64	==== 3.2.3 Cloud slot (VPC) ====
	65
	66	Within this region, a unique cloud slot per customer is assigned. This is represented as a Virtual Private Cloud (VPC) in the picture. Setting up a VPC provides a logically isolated section of the AWS Cloud where AWS resources can be launched in a virtual network explicitly defined for you. In addition, there is complete control over the virtual networking environment, including selecting the IP address range, creating subnets, and configuration of route tables and network gateways.
	67
	68	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.
	69
	70	==== 3.2.4 Cloud template ====
2.1	71
1.1	72	This Cloud Template, designed by eMagiz, defines the setup of the cloud instance. The following parts of the cloud setup are configured here:
	73
	74	* Java version
	75	* OS version (Linux)
	76	* Runtime version
	77	* Auto healing
	78	* Monitoring
	79	* Notification options
	80
28.1	81	Making sure you are on the latest cloud template version guards yourself against vulnerabilities in older versions of Java and OS, for example. In addition, it gives the user more options for monitoring the health of the cloud environment reducing the risk of a loss of availability of data (promptly) without compromising the integrity of the data. For more information on what cloud templates are and how to control and update them, please check out this [[microlearning>>doc:Main.eMagiz Academy.Microlearnings.Novice.eMagiz Cloud Management.novice-emagiz-cloud-management-cloud-templates-explained\|\|target="blank"]].
1.1	82
	83	==== 3.2.5 Carwash ====
	84
	85	All data exchanged between an external system and a cloud instance goes through the carwash that protects all client instances from harm and routes data to the correct client instance.
	86
	87	In terms of security, this means the following benefits from being behind the carwash:
	88
	89	* The connection is HTTPS instead of HTTP via the emagiz.com certificate
	90	* Your VMs are protected because only the necessities that need to allow traffic let traffic through
	91	* It gives you the ability to submit a certificate request via the Support portal to ensure two-way SSL (both server and client certificate validation).
	92
	93	=== 3.3 Access to runtime / machine ===
	94
	95	In the last section, we looked at cloud-specific security measures. In this section, we take a step back and look at access to the runtime/machine that holds the process flows that process your data. As one can imagine, anyone with access to the machines where runtimes are running on can compromise the availability, integrity, and confidentiality of data. eMagiz offers two locations where eMagiz runtimes can be installed. Per location, specific security measures are discussed that should be taken to ensure the availability, integrity, and confidentiality of the data.
	96
	97	==== 3.3.1 On-premises ====
	98
	99	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.
	100
2.1	101	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.
1.1	102	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).
	103
	104	===== 3.3.1.1 Rights for installing =====
	105
	106	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.
	107
	108	===== 3.3.1.2 Rights for running =====
	109
	110	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.
	111	There are two options on this level:
2.1	112
1.1	113	* 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.
	114	* 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.
	115
	116	In Linux, the service will be running under the local system account as per default.
	117
	118	==== 3.3.2 Cloud ====
	119
	120	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.
	121	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.
	122
	123	Support engineers can see more to analyze problems on a lower level.
	124
24.1	125	All other users don't have access to the cloud setup as there is no need for access because they can perform the relevant actions on the Cloud via the eMagiz portal. For more information on how please see the [[eMagiz Cloud Management>>doc:Main.eMagiz Academy.Microlearnings.Novice.eMagiz Cloud Management.WebHome\|\|target="blank"]] course.
1.1	126
	127	===== 3.3.2.1 Rights for installing =====
	128
	129	To install a runtime in the Cloud, you need sufficient rights within the Deploy phase of eMagiz. We will later touch on portal rights on a model and phase level in this fundamental.
	130
	131	===== 3.3.2.2 Rights for running =====
	132
	133	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.
	134
	135	=== 3.4 Data encryption during transport ===
	136
	137	==== 3.4.1 Data "in transit" ====
	138
	139	As an integration provider, we transport data between applications. To ensure that the transport of this data is performed securely, several measurements have been taken to keep the information confidential.
	140
	141	Let us first look at the data "in transit." This is the process phase where data is interchanged between flows within the eMagiz platform. This data interchange goes (i.e., from entry to onramp or offramp to exit) via the orchestration of the JMS server on the messaging layer. This is nicely shown in the picture below.
	142
14.1	143	[[image:Main.Images.Fundamental.WebHome@fundamental-emagiz-security-guide--data-orchestration.png]]
1.1	144
2.1	145	Data "in transit" is temporarily stored on an encrypted filesystem with the help of encryption algorithms.
	146	For the Cloud, eMagiz uses the AES-256 encryption algorithm.
	147	For on-premise runtime installations, eMagiz uses the AES-128 encryption algorithm.
1.1	148	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.
	149	That way, the data is kept confidential.
	150
	151	Above, we mentioned that data "in transit" is temporarily stored. This can happen in two places:
	152
	153	* On the JMS level (EFS)
	154	* Before the message is placed on a queue (H2)
	155
	156	==== 3.4.2 Transport Layer Security ====
	157
	158	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.
	159	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.
	160
2.1	161	=== 3.5 External data exchange ===
1.1	162
	163	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.
	164	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.
	165
	166	==== 3.5.1 Messaging ====
	167
	168	Messaging is the most flexible option of the three; therefore, a wide range of options is available within eMagiz to secure the connections.
	169	eMagiz offers users the tools to set up integrations and end-points in a secure manner. eMagiz supports well-known market standards, including:
	170
	171	* OpenID Connect
	172	* WS-Security
	173	* API Keys in combination with HTTPS/SSL
	174	* SOAP Authentication
	175	* OAuth2.0
	176	* Basic Authentication
	177
2.1	178	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.
	179
1.1	180	==== 3.5.2 API Gateway ====
	181
26.1	182	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.
1.1	183
	184	===== 3.5.2.1 Portal =====
	185
	186	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
	187
14.1	188	[[image:Main.Images.Fundamental.WebHome@fundamental-emagiz-security-guide--api-gateway-portal-feedback.png]]
1.1	189
26.1	190	===== 3.5.2.2 (External) IDP =====
1.1	191
26.1	192	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.
2.1	193	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.
1.1	194	If the client has sufficient rights, the process continues. For example, if the client has insufficient rights, the client receives a 401 Unauthorized.
	195
	196	===== 3.5.2.3 Error handling =====
	197
	198	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.
	199
30.1	200	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"]].
1.1	201	==== 3.5.3 Event Streaming ====
	202
	203	Within the Event Streaming solution, eMagiz provides Event Streaming users, and topics can be created.
	204	Access to a topic within a cluster is governed by an Access Control List (ACL). This ACL links users to a topic and defines what the user can do on a topic (consume, produce, both).
	205
	206	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.
	207
	208	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.
	209
2.1	210	These are all security measures to prevent third parties from getting unauthorized access to the data stored on the topics.
1.1	211
31.1	212	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"]].
1.1	213
34.1	214
1.1	215	=== 3.6 eMagiz iPaaS Portal ===
	216
	217	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.
	218
	219	==== 3.6.1 Authentication & Authorization for ILM Phases ====
	220
	221	===== 3.6.1.1 User access to https://my.emagiz.com =====
	222
32.1	223	Users can be added with their email address by the eMagiz Partner Manager or by their company contact, upon which the user gets an email to sign in. A temporary password is created and emailed, which has to be changed at the first login to the iPaaS portal. In addition, users are connected to organizations in eMagiz.
33.1	224	In the administration section of the user, upon first login an MFA configuration needs to be executed by the user so they can access models to which they have been granted rights. Typical authenticators on a smartphone can be used, such as Google Authenticator. For more information, check out this [[microlearning>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Platform.crashcourse-platform-security-add-mfa.WebHome\|\|target="blank"]]. An MFA response is required for model owners to manage the permissions on a model level. See the following sections for more details on these functions.
1.1	225
	226	===== 3.6.1.2 Users access to Integration Projects =====
	227
2.1	228	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.
1.1	229
	230	===== 3.6.1.3 User authorizations to Integration projects. =====
	231
33.1	232	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 (which is asked of the model owner upon login).
2.1	233
1.1	234	* When Edit permission is granted on an ILM phase, all the sub-options are configurable
	235	* View rights mean that all options can be viewed only
	236	* 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
	237	* Model owners are assigned to integration projects by eMagiz Administrators
	238	* An audit trail is kept of the changes made in the project permission structure
	239
14.1	240	[[image:Main.Images.Fundamental.WebHome@fundamental-emagiz-security-guide--access-rights.png]]
1.1	241
	242	===== 3.6.1.4 Partner user access to Client environments =====
	243
	244	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.
	245
	246	===== 3.6.1.5 Summary of relevant access to environments for eMagiz Administrators =====
	247
2.1	248	eMagiz Administrators can view all integration projects and have model owner rights for all integration projects.
	249
	250	===== 3.6.1.6 Password policy & Validity =====
	251
1.1	252	Below are relevant items for the password policy in the eMagiz portal.
	253
2.1	254	* There is no expiry policy on the password - eMagiz has a Forget Password functionality.
1.1	255	* 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."
	256
	257	==== 3.6.2 Integration project versioning & audit trails ====
	258
	259	* In all the relevant parts of the integration project, developers can version the changes made. The type (major, minor, or patch) can be indicated and commented on to describe the change. Once the version is created, that particular version will be available for Deployment and is then kept in the history of changes on a low level. Both are illustrated in the pictures below.
	260
14.1	261	[[image:Main.Images.Fundamental.WebHome@fundamental-emagiz-security-guide--create-new-version.png]]
1.1	262
14.1	263	[[image:Main.Images.Fundamental.WebHome@fundamental-emagiz-security-guide--history-pages.png]]
1.1	264
	265	* On a CDM level, the same functionality exists to indicate the version type incl. comments. All changes to the CDM model are logged in an audit trail that can help understand what changes are made by who in case of error resolution. The CDM is also protected by the permission structure of the Integration project.
	266
	267	* In Design, the required architecture of the different eMagiz components can be created. An audit trail is kept to see who has made what change, so actual realization issues of this architecture can be resolved faster. For example, in Deploy, the architecture is implemented to the Cloud, and a similar audit trail is kept there.
	268
	269	==== 3.6.3 eMagiz Monitoring capabilities & Security features ====
	270
2.1	271	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.
1.1	272
	273	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.
	274
	275	=== 3.7 GDPR compliancy ===
	276
2.1	277	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.
1.1	278
	279	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.
	280
2.1	281	=== 3.8 Data retention ===
	282
1.1	283	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.
	284
	285	==== 3.8.1 Messaging ====
	286
	287	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.
	288
	289	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.
	290
	291	==== 3.8.2 Event Streaming ====
	292
	293	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.
	294
	295	* 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.
2.1	296	* 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.
1.1	297	* These backup files are stored in the object storage in the same region where the service virtual machines are located.
	298
	299	==== 3.8.3 API Gateway ====
	300
	301	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.
	302
	303	==== 3.8.4 Data management ====
	304
35.1	305	For more information on the conceptual ideas behind data management within the eMagiz platform, you can look at this [[fundamental>>doc:Main.eMagiz Academy.Fundamentals.fundamental-traceability-in-emagiz\|\|target="blank"]]. For more concrete information on how to implement it within an eMagiz flow you could check out this [[microlearning>>doc:Main.eMagiz Academy.Microlearnings.Advanced Level.Data Management.advanced-data-management-data-sink\|\|target="blank"]] and this [[microlearning>>doc:Main.eMagiz Academy.Microlearnings.Advanced Level.Data Management.advanced-data-management-long-term-archiving\|\|target="blank"]]. All the information within the data sink and the long-term archiving solution is kept within the same VPC in the Cloud and can only be accessed by authorized parties.
34.1	306
1.1	307	=== 3.9 Compliancy ===
	308
31.1	309	* eMagiz is currentlty ISO-27001 certified.
	310	* eMagiz is currently SOC2 Type 2 certified.
1.1	311
	312	=== 3.10 Other ===
	313
	314	==== 3.10.1 Penetration testing ====
	315
	316	eMagiz services are periodically assessed and penetration tested by an independent pentesting supplier for any security issues.
	317
	318	During these tests, the pentester will try to achieve goals (penetration of the target system on various levels) by undertaking various means. Such a test can help determine whether a system is vulnerable to attack if the defenses were sufficient and which defenses (if any) the test defeated. In addition, eventual findings from those tests are dealt with conforming to the corrective action processes in our ISMS.
	319
	320	== 4. Key takeaways ==
	321
	322	* Protecting your data is a joint responsibility between eMagiz and you
	323	* The repository is read-only for clients
	324	* Data in the Cloud is kept within your VPC
33.1	325	* The portal is behind an MFA check
34.1	326
36.1	327	== 5. Suggested additional readings ==
	328
	329	* [[Fundamental (Navigation)>>doc:Main.eMagiz Academy.Fundamentals.WebHome\|\|target="blank"]]
37.1	330	** [[eMagiz Cloud (Explanation)>>doc:Main.eMagiz Academy.Fundamentals.fundamental-emagiz-cloud-inner-workings\|\|target="blank"]]
	331	** [[Traceability (Explanation)>>doc:Main.eMagiz Academy.Fundamentals.fundamental-traceability-in-emagiz\|\|target="blank"]]
36.1	332	* [[Crash Courses (Menu)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.WebHome\|\|target="blank"]]
39.1	333	** [[Crash Course Platform (Navigation)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Platform.WebHome\|\|target="blank"]]
	334	*** [[Security - Add MFA (Explanation)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Platform.crashcourse-platform-security-add-mfa.WebHome\|\|target="blank"]]
41.1	335	*** [[Portal Security - Basic (Explanation)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Platform.crashcourse-platform-manage-portal-security-basic\|\|target="blank"]]
39.1	336	** [[Crash Course API Gateway (Navigation)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course API Gateway.WebHome\|\|target="blank"]]
38.1	337	** [[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"]]
39.1	338	** [[Crash Course Event Streaming (Navigation)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Event Streaming.WebHome\|\|target="blank"]]
38.1	339	** [[User Management (Explanation)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Event Streaming.crashcourse-eventstreaming-user-management\|\|target="blank"]]
	340	* [[Novice Level (Menu)>>doc:Main.eMagiz Academy.Microlearnings.Novice.WebHome\|\|target="blank"]]
36.1	341	** [[eMagiz Cloud Management (Navigation)>>doc:Main.eMagiz Academy.Microlearnings.Novice.eMagiz Cloud Management.WebHome\|\|target="blank"]]
	342	*** [[Cloud Templates Explained (Explanation)>>doc:Main.eMagiz Academy.Microlearnings.Novice.eMagiz Cloud Management.novice-emagiz-cloud-management-cloud-templates-explained\|\|target="blank"]]
38.1	343	* [[Advanced Level (Menu)>>doc:Main.eMagiz Academy.Microlearnings.Advanced Level.WebHome\|\|target="blank"]]
39.1	344	** [[Data Management (Navigation)>>doc:Main.eMagiz Academy.Microlearnings.Advanced Level.Data Management.WebHome\|\|target="blank"]]
	345	*** [[Data Sink (Explanation)>>doc:Main.eMagiz Academy.Microlearnings.Advanced Level.Data Management.advanced-data-management-data-sink\|\|target="blank"]]
	346	*** [[Long Term Archiving (Explanation)>>doc:Main.eMagiz Academy.Microlearnings.Advanced Level.Data Management.advanced-data-management-long-term-archiving\|\|target="blank"]]
14.1	347	)))((({{toc/}}))){{/container}}{{/container}}

Wiki source code of eMagiz Security Guide

Navigation