Environments with GDPR in mind

vPierre Cloud Computing Leave a Comment

Later on there is an example for dealing with environments with GDPR in mind:

1. Environments – Preliminary Remark – Introduction

The protection of personal data is just as important before the release of a system as after it. The regulations of the Federal Data Protection Law and the EU GDPR apply to the processing of personal data regardless of whether data processing takes place after the system has gone live or during a project phase beforehand.

Irrespective of the phase in which a project is currently in, documentation is required that includes

  • the defined goals,
  • the technical Resources and instruments,
  • the definition of the individual project phases with beginning and end,
  • naming of the responsible persons, and
  • the decision of the responsible person on the beginning of a project phase, documentation of the overall project and the results and conclusions.

The level of detail of this documentation MAY vary according to the development phase of a procedure for processing personal data.

A differentiation MUST be made between the project phases and live operations.

Development and testing must always be done in environments separated from the ordinary production environment. Test servers should be located on non- production network segments.
It must be ensured that actual information classified as confidential (C3) or (C4) is not used as test data in any non-production environment (development, test, acceptance, training).
It must be documented what information or datasets are exported or copied from a production environment for the purpose of test data generation to provide an adequate audit trail. This documentation must also include the relevant authorization.
Any form of personal information (customer data, medical records, personal identifiable information) that may be present within test data that will be used for testing on non-production systems, must be scrambled, masked or anonymized using other means.
If there is a requirement to use real production data from which test data will be generated, always evaluate first, whether a subset of the data is sufficient for the desired testing activity and try to limit the amount of real production data from which test data is generated that can be used on non-production systems.

1.2.  Environments – Project Phases

1.2.1. Functional Tests

The purpose of functional tests is to ensure the basic usability of programs and devices for the subsequent project phases.

A test is characterized by the following features:

  • No users – only testers: Apart from a very small group of testers, there are no regular users of the procedure.
  • No connections to other persons and no data exchange with other procedures in live operations: Tests take place in an isolated environment.
  • No personal data: No personal data MAY be processed in a test or transferred from other live systems. Real data MUST be anonymized before it is transferred to the test procedures.

By definition, no personal data are processed in functional tests.

For this reason, there are no usual minimum data protection requirements to be fulfilled during testing.

Furthermore, by excluding connections to other live systems that include automatic processing of personal data, the functional tests are not expected to have a serious impact on the level of data protection and data Security of other procedures.

1.2.2. Integration and Acceptance Tests

The purpose of the integration and acceptance tests is to secure the concept and implementation against the occurrence of design flaws or implementation errors (e.g. ones not detected during the functional tests) in a quasi-productive environment with realistic load scenarios. With the aid of integration and acceptance tests, any existing or suspected risks, which could not be assessed under the conditions of the functional tests, SHOULD be excluded prior to a pilot or release for normal operation. Such tests MUST be strictly limited with regard to time to scenarios that have been described in detail.

The integration and acceptance tests SHOULD, were possible, not be carried out using personal data.

Personal data MAY only be used within the framework of additional, minimized tests. Basic functions SHOULD already have been checked during the functional tests with data that was sufficiently anonymized. Such initial functional tests MUST be carried out, even if integration and acceptance tests have already been planned.

A copy of the required, original data records MAY be used for test purposes if this is expressly permitted by a legal provision or if, in exceptional cases, despite replication to the test system, an error from the live system CANNOT be resolved without using the original data. Under these circumstances, personal data MAY be used for testing purposes if,

  • an area-specific legal provision does not expressly prohibit this,
  • pseudonymization, according to the GDPR, of the original data for the intended test constellation would involve an unreasonably high amount of effort,
  • the responsible authority has agreed to the procedure in writing,
  • when carrying out or evaluating the test, the interests of the affected persons requiring protection as well as data Security are adequately considered,
  • it is ensured that only those persons needed for troubleshooting and carrying out the test CAN use the data, and
  • access to this data MAY only be granted to persons who are subject to the relevant confidentiality principles and in particular to data protection regulations.

Access to the original data MUST be logged. After completion of the test, the used copy of the original data MUST be deleted immediately from the test area or made anonymous in the test area. The use of original data copies with occasion, reason, extent and duration, the Security measures taken, as well as the preceding tests with test data are quasi audit-proof (the term audit-proof refers to secure archiving in an audit-proof manner in electronic archiving systems . The term itself is based on the understanding of the term audit from an economic perspective and concerns information and documents that are subject to retention requirements or worthy of retention (this means a quasi waiver of immutability in mass Storage).

Prior consent MUST be obtained from the Data Protection Officer, if he or she is not also the authorized person.

The integration and acceptance tests MUST take place in a defined and controlled environment.

The object of the integration and acceptance tests is, in particular, also the testing and any necessary corrections of the required technical and organizational Security measures. They serve as the basis for the preparation of the safety concept and the risk analysis for the subsequent normal operation. The performance of integration and acceptance tests is a prerequisite for releasing the system for normal operation under consideration of the Security aspects.

If personal data are used in the integration and acceptance tests, then a summary of an IT concept and a Security concept, which has been adapted to the test conditions, are required at a minimum.

1.3.1. Pilot Operation

The purpose of the pilot phase is to carry out a real-life test in an area limited in terms of time and subject matter, in order to be able to test the defined minimum technical and organizational requirements in relation to their suitability for practical use on the basis of experience and, if required, to be able to modify them accordingly.

During the pilot phase, the main database is usually worked with. If, for example, a changeover from the old to the new process is required on a specific date, parallel operation of the old and new process MAY be necessary temporarily. However, parallel operation, in which the existing legacy process remains the leading system, SHOULD not be used. Personal data MAY be processed in a pilot within a defined time-frame.

The prerequisite for a pilot phase is an IT concept from which the purpose of the procedure, as well as the aim of the pilot phase, CAN be derived.

If personal data are processed during the pilot, a complete Security concept and a risk analysis based on the Security concept are required. If a pilot phase is only started with a limited scope, the Security concept MAY also be restricted to this limited range of functions. If the pilot phase corresponds with normal operation of the system in relation to the processing of personal data, the Security concept MUST be fully aligned with the respective minimum requirements.

If the effectiveness of the technical and organizational measures described in the Security concept is to be tested under real conditions during the pilot, the Security concept MUST provide statements regarding the minimization of any risks that MAY arise for the personal data.

In principle, a pilot requires approval by the Management if personal data are to be processed. For a pilot, the approval process CAN also be delegated to an „authorized person“.

The purpose of normal operation is to operate an automated procedure in accordance with the defined minimum requirements and agreed objectives. The applicable rules for the proper processing of personal data MUST be observed.

Normal operation takes place following approval by Management. Approval MUST be provided in writing.

The programs and Security measures used MUST be tested before normal operation is started. Such tests MAY, for example, be carried out with the personal data of persons responsible for the procedure or employees of the project who have agreed to these tests. Well documented functional tests, and integration and acceptance tests from previous project phases CAN significantly reduce the effort required for the necessary tests prior to the release of the procedure.

1.4.  Environments – Additional Minimum Requirements for Environments

The „production“ environment MUST be physically and logically separated from the other environments such as development (Dev), Test and QA, etc.

Networks consisting of technical infrastructure components or systems that do not comply with the applicable Security requirements for testing and development purposes SHALL be treated as untrusted Networks and MUST be isolated from other Networks or not connected directly to them.

For the environment, containerization SHOULD be introduced in three phases at a minimum: development, test and production (see diagram Service consuming view). From a technical/production perspective, we have two internal environments (see diagram Service delivery view).

Accordingly, this environment uses Services that SHOULD also be separated gradually. The minimum number of the stages we expect are production and non-production in accordance with the regulations associated with PAM (Privileged Account Management).

Example logical diagrams for these environments:

Environments for Container Services as an example

To bring this together, we have two main Logical Views here:

  • Service delivery view
  • Service consuming view

The “Service delivery view” consists of three stages:

  • Development
  • Test
  • Production

The “Service consuming view” consists of minimum three stages:

  • Development (DEV)
  • Test (TST)
  • Production (PROD)

The “Service consuming view” consists in the customer typically of four stages:

  • DEV for Development
  • TST for Test
  • ACC for Acceptance
  • PROD for Production

But the Production stage of the “Service delivery view” consists the stages of the “Service consuming view”.

Besides the tenant called Service consumers are only responsible for compliance concerns especially IT Security, data protection and so forth.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.