The data is securely transferred via HTTPS. TeamBeam uses SSL encryption (AES 256 bit or equivalent) for transfers in either direction (upload + download). Skalio always uses dedicated servers, to which only Skalio employees have access. Data is encrypted using the AES-XTS-Plain64 cipher with a key size of 256 bits. Data storageĪll data is securely stored on encrypted hard disks.
Data segmentationĪll data is stored in a segmented form which makes the files useless (even in the case of a data theft). HostingĪll data is stored on the TeamBeam server cluster hosted in a german data centre. If the legal framework differs in some points, TeamBeam will comply with the stricter directive. This also applies to the revised version of the german data privacy act. TeamBeam will comply with all the provisions of this EU wide data privacy directive. The stage is exited exactly once, at which point the sender of the transfer may be notified of detected malware.General Data Protection Regulation (GDPR)įrom May 2018, the General Data Protection Regulation will be applied. The stage is exited only after all scan operations have returned (with specific results or an exception). The stage is entered by requesting each file to scanned exactly once. The lock is released at the end.Įach transfer runs through the following states:Įach stage has entry- and exit-requirements that determine if it is necessary, already completed or already entered.įor example, the malware-scanning stage is necessary if either the sender or the recipient has the feature contractually available and enabled. This provides cluster-wide thread safety. For the duration of an execution for a transfer, the state engine obtains a distributed cluster-wide lock for that transfer, to avoid side effects. Eventually a transfer exists the state engine with processing status completed.Įxecution of the state engine is safe at any time. The results of these tasks will again trigger the execution of the state engine. Depending on the current state of a transfer and its objects, a stage may be entered or exited, and subsequent tasks may be triggered. Events trigger a transfer's progression through the state engine. Rather than executing tasks sequentially and in a controlled fashion (by a governing thread which waits for the execution of each task it triggers), the tasks are orchestrated by a state engine. Map-and-reduce the results of functions into the governing entity.Ī transfer is considered infected, if at least one of its files is infected.Distribute these tasks across all available resources and allow them to be executed in parallel with the available concurrency of the cluster.When scanning a file for malware and calculating its hashsum, the operations do not affect each other. Where possible, break the work up into tasks without side effects and data-dependency.Since post processing can take an indeterminable time, dependent on the number and size of files as well as the availability of storage backends and their individual computing capacity/load, the implementation follows ideas from functional programming: Only once all necessary tasks are completed, is the new-transfer eMail being sent to the recipient. As a result, the process is implemented very much asynchronously. The time required for this can take an indeterminable time. Post processing of a transfer includes scanning files for malware and calculating hashsums. Afterwards, longer-running post-processing is triggered, and the sender's request is completed. If the checks were successful, the sender may receive an upload-success-eMail. At this point, the reservation-confirmation-request may get rejected, allowing the sender to re-upload files, etc and submit the confirmation again. Most importantly, the server checks if all files have been uploaded as promised, and if the sender's contract has any problems with the data. When the sender confirms a reservation, several tasks are performed synchronously within the confirm-request. This essentially close it and creates the transfers for the recipients. This stage can take a long time, and uploading of files can (and should) be split into segments. Uploading a number of files into that reservation.It contains all data of the future transfer, except for the payload (which often takes long to upload). Creating a reservation, which acts as a draft transfer.From Reservation To NotificationĬreating a new transfer consists of three stages: This article explains the chosen architecture. Legal disclaimer / Imprint and privacy policyĪfter a new transfer has been uploaded and before the recipient is notified, a number of potentially long-running tasks are executed on the transfer and its files.
0 kommentar(er)
