Processing personalized data according to official rules

[openBackhaul]

Collection of aspects that might be in conflict with official rules:

• AP: the header contains a "user" field with description "User identifier from the system starting the service call". This field might contain clear name of users of the modular application layer without him/her knowing.
• EaTL: records are containing a "user" field with description 'User identifier from the system starting the service call'. This stored field might contain clear name of users of the modular application layer without him/her knowing.
• OL: records are containing a "user-name" field with description 'User name extracted from Authorization header used to identify in basicAuth'. This field contains clear name of administrators of the modular application layer.
• AA: CONFIGfile contains user name (potentially coded into a Base64Code) and rights. This stored field contains name of administrators of the modular application layer.
• nginx: header fields might be stored in some log. This stored field would contain clear name of users of the modular application layer without him/her knowing.
• github: commits, pull-requests, merges, issue handling are documented together with user name. This stored fields contain names of contributers (code, documentation, tickets) to the modular application.
• gitlab: commits, pull-requests, merges, issue handling are documented together with user name. This stored fields contain names of contributers (code, documentation, tickets) to the modular application.
• postman: users have to log-in to connect to Postman cloud. Currently not clear, whether logging takes place. Would be limited to contributors to the modular application layer.
• Jenkins: users have to be identified in a LOADfile for running jobs. This stored field would contain clear name of contributors (particularly testers) to the modular application layer.
• individual applications: implementers might have implemented creation of local logging of unknown content. Stored fields might contain clear name of users of the modular application layer without him/her knowing.

Aspects we do not need to look into, because have already been solved in past:

• OpenDaylight

[alattoch]

So could we say in summary?
Information that relates to a personal user can be contained in:

1. System User of AdministrationAdminstration
   Would it be sufficient to have users for specific roles like in Unix:
   e.g. AA-Admin user instead of alattoch/theinze?

2. Software (comments), Software Configuration (Config File)

3. Testcases

4. Documentation

5. Test protocols

6. eMails

7. could be passed in the http header from the presentation layer (what is outside) but is not required/interpreted.

==>There is no role based UseManagement implemented in the MW SDN Architecture today and no concrete plans today to add this into the MW SDN Architecture.
So the only possible DPA impact today would be a personalized user within AA.
==>I will verify what measures we have to regard.

[alattoch]

[alattoch]

If named user e.g. alattoch are used within AdministratorAdminstartion Data Protection Measures are needed. This process will be triggered now. The process will document MW SDN in an Telefonica GDPL-Register. Two major requirements are seen by the DPA Experts now.

1. Time triggered deletion of all log and Traces Data after 30 days
2. Complete deletion of named user logs after leaving Telefonica. This will be event triggered. The personal data deletion concept needed to agreed with DPA Expert, this will happen end of September 22.
3. "Schutzbedarfsanalyse" need to be updated to document named AdminUsers.

[openBackhaul]

I am trying to derive concrete change requirements from the above text.
The only place I can find such is the 6/9/2023 comment.

>>If named user e.g. alattoch are used within AdministratorAdminstartion Data Protection Measures are needed.
Yes, users are planned to be identified.

>>1. Time triggered deletion of all log and Traces Data after 30 days.
This should not be a problem as the records are stored in ElastiSearch.
ElastiSearch search allows configuring a maximum age of the records.

>>2. Complete deletion of named user logs after leaving Telefonica.
In a first step, this requires manual read/write activity on the application data file of the AA.
(Changing the administrators is not supported via API, neither as services, nor as OaM configuration.)
In principle, it would be possible to provide an API for centralized initiation of a deletion of an administrator.
This would raise organizational questions, e.g. who will initiate the deletion and does his/her tool support REST.

>>3. "Schutzbedarfsanalyse" need to be updated to document named AdminUsers.
This would be an activity outside the scope of the ApplicationPattern.

Overall, I cannot identify a concrete need for a change to the ApplicationPattern in its v2.0.2 release.
Consequently, I would like to move this issue into the next release.

[alattoch]

2. If we get informed that a named User will leave, than we need to delete him at the same working day. This can be covered by an operational process and we would not need a technical methode here.

[alattoch]

we need a discription how to do and than we will include this within the operational manual.