Question How to follow advice "enable backup encryption on the cloud storage side"?

[watou]

Server operating system version

Ubuntu 22.04

Plesk version and microupdate number

Plesk Obsidian 18.0.54 Update 1

In this page of the documentation, we are given the warning

Note: The Plesk internal key encrypts only certain data in a backup but not the whole backup. If you store backups in remote cloud storage, you can enable backup encryption on the cloud storage side.​

But there is no real-world example that can be found via search of how this is accomplished. I can only assume that this advice proposes that I find or create some automation that will encrypt the scheduled backup file after it's been uploaded to my S3 bucket, which of course means it's been uploaded without full, proper encryption in the first place.

All I'm asking is that, if this is a legitimate piece of advice, that someone at Plesk can back it up with a real world scenario, even just in theory! (I'm about to become a forever Plesk customer so it's important that I understand what I'm getting into here.)

Thank you very much in advance.

 

[Peter Debik]

With "cloud storage side" the documentation means encryption that is provided by the cloud storage provider. If your cloud storage space is "encrypted" end-to-end, the cloud storage provider already got you covered with encryption. There is no need to set anything in the backup itself. The algorithms of your storage space do not store you data as plain, unencrypted files, but as encrypted files on the disks of the cloud. Plesk does not know how your cloud storage space is configured. Maybe it is encrypted by default, maybe it is not. Maybe you have an option in your cloud storage package to toggle encryption on/off.

 

[watou]

With "cloud storage side" the documentation means encryption that is provided by the cloud storage provider. If your cloud storage space is "encrypted" end-to-end, the cloud storage provider already got you covered with encryption. There is no need to set anything in the backup itself. The algorithms of your storage space do not store you data as plain, unencrypted files, but as encrypted files on the disks of the cloud. Plesk does not know how your cloud storage space is configured. Maybe it is encrypted by default, maybe it is not. Maybe you have an option in your cloud storage package to toggle encryption on/off.

Thank you for your reply, Peter.

Can Plesk name a supported S3-compatible storage provider that can live up to the advice "enable backup encryption" so that backup tar files are not freely accessible if known by name, over HTTPS? Does any S3-compatible storage provider have a feature called (or meaningfully equivalent to) "enable backup encryption" for the purposes intended by the note in the Plesk documentation?

For my benefit, I'm required to have proper backup security using an S3-compatible cloud storage as a target. For Plesk's benefit, I'm hoping that customers are not being encouraged to configure and implement an inherently insecure cloud backup solution based on vague and unachievable advice in the documentation.

Thanks again for your assistance.

 

[Peter Debik]

Plesk is a web, database and mail control panel, a software to make configuration of servers easier. It is not a consultancy agency for business strategies or third-party service. We do not have the proper market overview to recommend one or another cloud service providers. Maybe you can try a service comparison portal on the Internet, e.g. search like s3 cloud storage providers - Google Suche

 

[watou]

Plesk is a web, database and mail control panel, a software to make configuration of servers easier. It is not a consultancy agency for business strategies or third-party service. We do not have the proper market overview to recommend one or another cloud service providers. Maybe you can try a service comparison portal on the Internet, e.g. search like s3 cloud storage providers - Google Suche

It's extremely disappointing that Plesk appears to include an inherently insecure cloud backup function as a core component of its product offering, and then appears to disavow responsibility for it when questioned. (That's the only reasonable conclusion one can draw from your reply.) I would ask you to reconsider your reply in the hope of constructively engaging with your prospective customer towards a proper solution. Are you interested in this courteous invitation?

 

[Peter Debik]

The backup component is secure and can be used with a wide range of storage providers. It is not true that it is insecure and I wonder who you come to such a conclusion.

Plesk cannot recommend a specific provider. It is your own responsibility to research and choose a provider that is suitable for your requirements. This cannot be delegated to another party. It is not the responsibility of a software manufacturer to give business advice which provider a user shall choose. Instead, Plesk enables you to freely choose and does not enforce specific providers. The vast majority of users sees this as a big advantage.

 

[watou]

Hi Peter, thanks again for your replies.

I come to the previous conclusion because Plesk offers, for example, a solution to automatically upload a scheduled backup to DigitalOcean Spaces and yet there is no ability to fully encrypt the backup, meaning that any person with the full path to the tar file can download it anywhere on the Internet with no authentication. By providing such an insecure solution, Plesk is encouraging its use, which is not showing an interest in customer's data security, a GDPR concern for sure. The best security that can be achieved with the referenced tools Plesk has provided is security through obscurity. Also, when you failed to identify a single example of what is suggested in the documentation note, as I asked, it reasonably leads the reader to believe that Plesk knows of no such examples and frankly doesn't care to clarify their documentation such that customers can make proper use of it.

I hope this makes my point very clear, and thanks again. I would still be eager to hear of one example that can make the referenced documentation note viable, and I would also point out the GDPR issues surrounding the insecure options.

 

[watou]

And there's always the chance I have this wrong, which would be funny!

 

[watou]

I believe my concerns are valid for those organisations that cannot tolerate the existence of unencrypted, off-site backups of customer data, but I see it is arguable for other organisations that already use cloud servers containing unencrypted customer data where another unencrypted copy in an S3 bucket is no less secure.

 

[Kaspar]

I come to the previous conclusion because Plesk offers, for example, a solution to automatically upload a scheduled backup to DigitalOcean Spaces and yet there is no ability to fully encrypt the backup, meaning that any person with the full path to the tar file can download it anywhere on the Internet with no authentication. [..]

That's not true. On creation, by default, the file listing for any new DigitalOcean Spaces bucket is set to private and, more importantly, the file permission for any file uploaded to the bucket is set to private also. Meaning that any backup made in Plesk and stored in a DO Spaces bucket isn't accessible publicly, but only to authenticated users.

Now DigitalOcean Spaces doesn't provide any data encryption for data stored at rest. That's true. But that does not mean the data (backups) storage is insecure. If you require data encryption at rest, AWS S3 is probably a better fit as AWS offers a range of encryption options for data. But it's up to you, as a user, to decide what's best for your situation.

 

[watou]

Thank you for your explanation, @Kaspar, and for providing an example of the viability of the suggestion given in the documentation. Might I suggest improved wording in the documentation to include the new information you have provided for the benefit of future customers and prospects?

 

[Kaspar]

Thank you for your explanation, @Kaspar, and for providing an example of the viability of the suggestion given in the documentation. Might I suggest improved wording in the documentation to include the new information you have provided for the benefit of future customers and prospects?

What would you like to see in the documentation exactly?

 

[pleskpanel]

Encryption at rest really falls under the purview of whatever third party provider is being used so it's really not related to Plesk (even though Plesk can be used to push data to those third party location such via extensions, FTP, etc...).

 

[watou]

When Plesk pushes backup data off the server to somewhere else, each specific software component doing the pushing ought to describe in detail in its documentation what it's doing, and the general consequences of doing so. For example, the Plesk-authored DigitalOcean Spaces extension, for example, should document its specific settings as it pushes the data off the server, and the general implications of how Spaces and the bucket are configured as regards data security. Leaving these details undocumented is not good security practice, in my opinion.

 

[Maarten.]

Backblaze B2 Cloud Storage supports server-side encryption:

Server-Side Encryption

Server-side encryption protects your data by encrypting it before it is stored on disk.

www.backblaze.com

It's compatible with the Amazon S3 API, so you can use the Plesk "Amazon S3 Backup" extension.

 

[Peter Debik]

When Plesk pushes backup data off the server to somewhere else, each specific software component doing the pushing ought to describe in detail in its documentation what it's doing, and the general consequences of doing so. For example, the Plesk-authored DigitalOcean Spaces extension, for example, should document its specific settings as it pushes the data off the server, and the general implications of how Spaces and the bucket are configured as regards data security. Leaving these details undocumented is not good security practice, in my opinion.

Plesk won't document the feature scope of external services. That is the responsibility of the vendors who offer such services.

 

[watou]

To reiterate the other part of my request, will Plesk consider documenting the way in which it pushes backup data to external services, so customers are not left wondering? There are choices embedded in your software components as to how this is done, which are not obvious and not reflected in the documentation. Surely it's not against Plesk policy to give customers this level of knowledge and understanding about how the product interfaces with external services, especially since not providing the information predictably leads to doubts and misunderstandings for no good reasons? Thank you.

 

[Kaspar]

To reiterate the other part of my request, will Plesk consider documenting the way in which it pushes backup data to external services, so customers are not left wondering? There are choices embedded in your software components as to how this is done, which are not obvious and not reflected in the documentation. Surely it's not against Plesk policy to give customers this level of knowledge and understanding about how the product interfaces with external services, especially since not providing the information predictably leads to doubts and misunderstandings for no good reasons? Thank you.

Just to avoid any confusion, it's not up to me decide on Plek's documentation. But I do like to comment on this as I feel your expectations aren't entirely realistic. I do understand the need for more information on the subject of backup security, especially for users who aren't that knowledgeable in this in field. I guess Plesk could be a bit more accommodating in explaining the options of the various Cloud Providers for backup storage in that regard. This issue is that different users have different (security) needs. So it's hard, if not impossible, to detail every option for each use case. Besides, storage providers change their options and evolve their services. Making it hard to keep documentation up to date. (With Plesk's fast release cycle they already have a hard time keeping their own documentation up to date.)

However I strongly feel it's the primary responsibility of users to read up on the (security) options of their preferred storage options. After all it's your own responsibility to keep data safe, not anyone else's.

Fortunately, any of the cloud storage options available to store Plesk backups (AWS, DO Spaces, Dropbox, Google Drive and One Drive) keep backups private by default (as in backups aren't accessible publicly). Some have additional security options, others don't. It up to you do decide what's the fit for you. And if you're concerned with security that requires you the read up on the vendors options.

 

[watou]

I generally agree with what you're saying, @Kaspar, but in the case where a Plesk software component has chosen a setting or parameter that is not exposed in either the UI or the documentation, that can leave customers assuming incorrectly about an important aspect of their data security posture. In your message above, you share facts that are not in the documentation, but in my opinion they should be. (By the way, thank you for sharing those facts, which was all I was after when starting this thread, which is now at message #19!)

 

[Kaspar]

I generally agree with what you're saying, @Kaspar, but in the case where a Plesk software component has chosen a setting or parameter that is not exposed in either the UI or the documentation, that can leave customers assuming incorrectly about an important aspect of their data security posture.

That's why any user should read up on the documentation of the cloud storage provider