⚙    bpm    sdlc    bianl    data    meta    math    ⚙ 👐 🎭 index - references    elucidation    metier 🎭
⚒    Intro    Foundation    Receiving containers    Limiting access    Administrate receive area    Pattern chain ⚒ 👐    top bottom   👐

Devops Meta


data exchange

Patterns as operational constructs.

more_dmeta naming conventions generic pull request information data exchange, why is it critical?

There are a lot of questions to answer:
📚 Information data is describing?
⚙ Relationships data elements?
🎭 Who is using data for what proces?
⚖ Inventory information being used ?

🔰 Somewhere in a loop of patterns ..
Most logical back reference: previous.

Contents

Reference Topic Squad
Intro Patterns as operational constructs. 01.01
Foundation Why and how doing information exchange. 02.01
Receiving containers Receiving storage area, basic acces. 03.01
Limiting access Limited white list receiving storage. 04.01
Administrate receive area Administrate receiving storage. 05.01
Pattern chain Defining the chain - Transformations. 06.00
Dependencies other patterns 06.02

Progress



Duality service requests

duality service requests sdlc: Needed to integrated business application systems when those assembly lines are separated. Reliability of the information (data) and delivering that in time is critical.

bianl: Analyses of the business process for answering improvement questions is not critical.
Analysing data for creating new information that is mandatory and must be delivered with a deadline is critical.

log_legal1.jpg

Why and how doing information exchange.


The need for data that is collected or being derivate at another process getting into the local process is a normal requirement.
There must be a list of what is needed.
Exchange, The sending on some request.
The process flow of delivering data is clear.
  1. When should it be send
  2. What should be send
  3. How (who is the executor) should be send
  4. To who, the recipient
With an easy object is that could be like the following figure.
post dleviering parcel-letter.jpg

Exchange, The Delivery end-point question.
The process of handling the deliveries/parcels not. Questions:
  1. Who´s is handling the receiving point
  2. Is there a check of not putting unwanted stuff
  3. Will there be a quality check on the delivery/parcel
Use of a secured location secured storage to get mail/parcel post getting parcel-letter.jpg
Having a safe place fore receiving the goods is for additional safety.

Olympia_odenon.jpg

The secured storage approach.


There are a lot of tools for a secured file transfer.
- FTP, SFTP, XFB, XCOM. Cryptshare etc.

A gap in engineering is usually the authorisation of the receiving storage area. This is an hot issue when using a multi tenancy service. Multi tenancy is sharing a lot of things reducing resources and software releases complexity. Requirement: solving multi tenancy while not adding too much complexity.

Using OS controls implementing limited access security.
⚠ Assuming the authorisation could be done by describing them by files is a pitfall. The files are moved and deleted at a moment in time. When the access is bound to a file it can get deleted also.
💡 using a well defined ACL (access control list) on a directory will result in a reliable reusable container in the same way of the controlled receiving of parcels.

The Unix (DAC) Solution: The idea is that files are registered in directories an by that will need authorisation to those directories for any access. There are three different options of access as the owner group and others have different rights.
This is Standard solution in Unix. Commonly used at “/tmp” or Unix-mail.
It is also common knowledge fore auditors (search internet with the keywords)

In a table representation:
owner:
group
appl01_bd: 
appl01_bd
appl01_bt: 
appl01_bt
appl01_ba: 
appl01_ba
appl01_bp: 
appl01_bp
Environment - D T A P
/data/…/xchn_d/appl01_d/.. D g
D o
R
RW */3
/data/…/xchn_t/appl01_t/.. D g
D o
R
RW */3
/data/…/xchn_a/appl01_a/.. D g
D o
R
RW */3
/data/…/xchn_p/appl01_p/.. D g
D o
R
RW */3
Remarks:
The advantage of this approach are: Disadvantages are:

Delphi_odenon.jpg

Limited white list receiving storage.


What is achieved is that files can get stored by other accounts and the intended receiver can read and also delete files. The deletion is only for the owner of the file (sender) and owner of the directory possible.
💣 More detailed questions of possible abuse should get covered.

Shortcomings of basic receiving storage

Defining administration role for receiving storage
There is an administrator role defined for managing the receiving storage exchange area needed.
An impersonated name and group could be: user:group xchn_<dtap>:xchn_<dtap>
Any account that wanted to use the storage exchange area is required to be member of the group. Note the required strict dtap segregation is implied by using separated accounts and groups.

In a table representation:
key:
group
xchn_d:
xchn_d
xchn_t:
xchn_t
xchn_a:
xchn_a
xchn_p:
xchn_p
Environment D T A P
/data/../xchn_d    D g
D o
RX
---
/data/../xchn_t    D g
D o
RX
---
/data/../xchn_a    D g
D o
RX
---
/data/../xchn_p    D g
D o
RX
---

A living environment with existing files.
The environment is set up with empty directories. When it is used files will exist. The DAC attributes will vary when they are created. Moving a file will need to copy the file and delete the received file by the reciever as moving would keep the sender owner atttibutes.
In a table representation:
D owner:
D group
appl01_bd: 
appl01_bd
appl01_bt: 
appl01_bt
appl01_ba: 
appl01_ba
appl01_bp: 
appl01_bp
F owner:
F group
*/1 ?: 
appl01_bd
*/1 ?: 
appl01_bt
*/1 ?: 
appl01_ba
*/1 ?: 
appl01_bp
Environment - D T A P
/data/…/xchn_d/appl01_d D g
D o
R
RW */3
/data/…/xchn_d/appl01_d/.. F g
F o
R */4
- */5
/data/…/xchn_t/appl01_t D g
D o
R
RW */3
/data/…/xchn_t/appl01_t/.. F g
F o
R */4
- */5
/data/…/xchn_a/appl01_a D g
D o
R
RW */3
/data/…/xchn_a/appl01_a/.. F g
F o
R */4
- */5
/data/…/xchn_p/appl01_p D g
D o
R
RW */3
/data/…/xchn_p/appl01_p/.. F g
F o
R */4
- */5
Remarks:
umbrellas.jpg

Administrate receiving storage.


Achieved: intended functionality on exchanging files by sender and receiver.
Safety: Limited to only impersonated accounts and only those granted for this functionality.
Not yet mentioned are administrative actions needed to be in place for this.

Managing storage size capacity and availability
What is needed is someone that will monitor the machine capacity usage.
⚠ Too many big files at the same moment could cause capacity problems. Communicating for solutions in capacity is necessary.
Files should get deleted or archived to another location after being processed.
Security incidents should have some follow up (IRC).

Defining new receive locations
When a new directory needs to get defined that could be done using root access rights. Another way is:
  1. As impersonated owner (xchn_<dtap>) account: open up the directory right to create a new directory.
  2. As impersonated owner of the receiving application: define the new directory in the agreed setting. Naming and access rights.
  3. As impersonated owner (xchn_<dtap>) account: close the directory right to create a new directory.
All other needed autorisations are based on group meberships. Groupmemberships are managed by a central dpeartment

Reference when an auditor does information requests
It is a standard approach within Linux(Unix) exists as used on maps like "/tmp" and "cron" "mail" See: rights-management source: debian_handbook.info or> file attributes explanation source: linuxconfig.org
When used on a directory, instead, the setgid bit alters the standard behaviour so that the group of the files created inside said directory, will not be that of the user who created them, but that of the parent directory itself. This is often used to ease the sharing of files.
Allowing other (public) rights in the directories (RWX) can raise questions. The limitations by the hierarchy and those special bits on a directory not generic understood well.
Chapter 49. Security and SELinux source: RedHat

🤔 A path traversal attack is using the lack of security in the system. Running a process that is not having least privileges set.
This pattern is closing any traversal attack gap by implementing well defined security.

Left attention points


feel_brains_06.jpg

Defining the chain - Transformations.


Pattern: information exchange & data security
Defining an exchange storage area by:
  1. Having a controlled administrated entry.
    Using a name like xchn_<dtap>
  2. Set up well defined access controls guided by the xchn administrator for receiving and sending parties.
  3. Allow each party for their own sub directories.

Although there is no additional software and scripting must be build in house this pattern can seen as an "application". With (application id 019, * parallel line the name for receiving application name
A name could be:
<dtap>/B019_/&let019N>/L<*>_Ldta/%*

Remarks:
Conflicting other Patterns.
This approach is a very simple solution at host security controls level.
⚠ It is often felt as threatening projects running commercial products, instead of having a (os level) secured environment.

Dependencies other patterns
more_dmeta naming conventions generic pull request information This page is a pattern on naming conventions.

Within the scope of metadata there are more patterns like exchanging information (data), building private metadata and securing a complete environment.

🔰 Somewhere in a loop of patterns ..
Most logical back reference: previous.



⚒    Intro    Foundation    Receiving containers    Limiting access    Administrate receive area    Pattern chain ⚒ 👐    top bottom   👐
⚙    bpm    sdlc    bianl    data    meta    math    ⚙ 👐 🎭 index - references    elucidation    metier 🎭

© 2012,2019 J.A.Karman