Skip to Content

Changes for page eMagiz Security Guide

Last modified by Erik Bakker on 2024/08/20 08:53
From version 15.1
edited by Erik Bakker
on 2022/06/13 13:36
Change comment: Renamed from xwiki:Migrated Pages fundamentals.eMagiz Security Guide
To version 7.1
edited by eMagiz
on 2022/06/13 09:33
Change comment: There is no comment for this version

Summary

Details

Page properties
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.ebakker
1 +XWiki.marijn
Content
... ... @@ -1,4 +1,7 @@
1 -{{container}}{{container layoutStyle="columns"}}(((
1 +{{html wiki="true"}}
2 +<div class="ez-academy">
3 + <div class="ez-academy_body">
4 +<div class="doc">
2 2  
3 3  
4 4  
... ... @@ -8,6 +8,9 @@
8 8  
9 9  Should you have any questions, please get in touch with academy@emagiz.com.
10 10  
14 +* Last update: February 17th, 2022
15 +* Required reading time: 15 minutes
16 +
11 11  == 1. Prerequisites ==
12 12  
13 13  * Some context on cloud functionality will be helpful.
... ... @@ -42,7 +42,7 @@
42 42  * 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)
43 43  * 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.
44 44  
45 -[[image:Main.Images.Fundamental.WebHome@fundamental-emagiz-security-guide--definition-emagiz-model.png]]
51 +<p align="center">[[image:fundamental-emagiz-security-guide--definition-emagiz-model.png||]]</p>
46 46  
47 47  === 3.2 Security Guidelines * Cloud ===
48 48  
... ... @@ -53,7 +53,7 @@
53 53  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.
54 54  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.'
55 55  
56 -[[image:Main.Images.Fundamental.WebHome@fundamental-emagiz-cloud-inner-workings--customer-level-overview-double-lane.png]]
62 +<p align="center">[[image:fundamental-emagiz-cloud-inner-workings--customer-level-overview-double-lane.png||]]</p>
57 57  
58 58  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.
59 59  
... ... @@ -142,7 +142,7 @@
142 142  
143 143  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.
144 144  
145 -[[image:Main.Images.Fundamental.WebHome@fundamental-emagiz-security-guide--data-orchestration.png]]
151 +<p align="center">[[image:fundamental-emagiz-security-guide--data-orchestration.png||]]</p>
146 146  
147 147  Data "in transit" is temporarily stored on an encrypted filesystem with the help of encryption algorithms.
148 148  For the Cloud, eMagiz uses the AES-256 encryption algorithm.
... ... @@ -187,7 +187,7 @@
187 187  
188 188  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
189 189  
190 -[[image:Main.Images.Fundamental.WebHome@fundamental-emagiz-security-guide--api-gateway-portal-feedback.png]]
196 +<p align="center">[[image:fundamental-emagiz-security-guide--api-gateway-portal-feedback.png||]]</p>
191 191  
192 192  ===== 3.5.2.2 External IDP =====
193 193  
... ... @@ -241,7 +241,7 @@
241 241  * Model owners are assigned to integration projects by eMagiz Administrators
242 242  * An audit trail is kept of the changes made in the project permission structure
243 243  
244 -[[image:Main.Images.Fundamental.WebHome@fundamental-emagiz-security-guide--access-rights.png]]
250 +<p align="center">[[image:fundamental-emagiz-security-guide--access-rights.png||]]</p>
245 245  
246 246  ===== 3.6.1.4 Partner user access to Client environments =====
247 247  
... ... @@ -262,9 +262,9 @@
262 262  
263 263  * 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.
264 264  
265 -[[image:Main.Images.Fundamental.WebHome@fundamental-emagiz-security-guide--create-new-version.png]]
271 +<p align="center">[[image:fundamental-emagiz-security-guide--create-new-version.png||]]</p>
266 266  
267 -[[image:Main.Images.Fundamental.WebHome@fundamental-emagiz-security-guide--history-pages.png]]
273 +<p align="center">[[image:fundamental-emagiz-security-guide--history-pages.png||]]</p>
268 268  
269 269  * 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.
270 270  
... ... @@ -320,8 +320,8 @@
320 320  
321 321  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.
322 322  
329 +===== Practice =====
323 323  
324 -
325 325  == 4. Key takeaways ==
326 326  
327 327  * Protecting your data is a joint responsibility between eMagiz and you
... ... @@ -328,4 +328,9 @@
328 328  * The repository is read-only for clients
329 329  * Data in the Cloud is kept within your VPC
330 330  * Production data in the portal is behind an MFA check
331 -)))((({{toc/}}))){{/container}}{{/container}}
337 +
338 +</div>
339 +</div>
340 +</div>
341 +
342 +{{/html}}
fundamental-emagiz-cloud-inner-workings--customer-level-overview-double-lane.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.ebakker
Size
... ... @@ -1,1 +1,0 @@
1 -65.2 KB
Content
fundamental-emagiz-security-guide--access-rights.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.ebakker
Size
... ... @@ -1,1 +1,0 @@
1 -9.1 KB
Content
fundamental-emagiz-security-guide--api-gateway-portal-feedback.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.ebakker
Size
... ... @@ -1,1 +1,0 @@
1 -14.7 KB
Content
fundamental-emagiz-security-guide--create-new-version.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.ebakker
Size
... ... @@ -1,1 +1,0 @@
1 -23.6 KB
Content
fundamental-emagiz-security-guide--definition-emagiz-model.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.ebakker
Size
... ... @@ -1,1 +1,0 @@
1 -63.3 KB
Content
fundamental-emagiz-security-guide--history-pages.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.ebakker
Size
... ... @@ -1,1 +1,0 @@
1 -22.5 KB
Content