Security and Data Immutability

CommunityEnterprise

All data that is sent to and received from the cloud by default uses the HTTPS protocol, so your data is encrypted while being transmitted and received. However, data that resides in the Cloud is not encrypted by default. If you wish extra security of your data while it resides in the cloud, you should consider using Bacula’s data encryption features Data Encryption.

For additional protection against backup data loss, or for regulatory compliance reasons, cloud stored parts can be set to be immutable, which means they can be downloaded from the cloud many times but uploaded to the cloud only once (Write Once Read Many: WORM).

Bacula Cloud Plugin supports the immutability features available from different cloud providers. Immutability needs to be configured externally in the destination storage entity (S3 Bucket, Azure Blob, Google Storage Bucket…) using the available native tools from each provider. Further information about these features:

S3 Object Lock: https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html
Azure Blob Immutable Storage: https://learn.microsoft.com/en-us/azure/storage/blobs/immutable-policy-configure-container-scope?tabs=azure-portal
Google cloud Bucket Lock: https://cloud.google.com/storage/docs/bucket-lock
Oracle cloud Retention Rules: https://docs.oracle.com/en-us/iaas/Content/Object/Tasks/usingretentionrules.htm

Once the destination storage has immutability capabilities enabled, Bacula will work transparently with it. The only requirement is to have greater Bacula retention for the implied volumes than the retention configured in the cloud.

Bucket Versioning

In the case you have bucket versioning enabled in the bucket used to store the Bacula Cloud volumes, you should setup a proper procedure to delete the versioned part files to avoid unnecessary costs.

Versioned part files are created e.g. when Bacula reuses a Cloud volume.

Cloud providers usually propose the setup of Lifecycle policies to delete periodically versioned objects from the bucket.

Per-volume AWS Object-based Lock

Warning

Only for AWS/Amazon cloud driver.

In addition to the above global bucket-level Immutability configuration, it is also possible to set the Storage Device Volume Immutability and the Storage Device Minimum Volume Protection Time device directives to configure volume-based immutability.

The retention mode is controlled by the LockMode directive of the Cloud resource level. It can be Governance or Compliance (see https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html#object-lock-retention-modes for details). Governance is used by default.

Note

For this option to work, the AWS CLI client being used must have at least the following privileges: s3:PutObjectRetention and s3:PutBucketVersioning (see https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html#object-lock-permissions for more details).
S3 does not implement a strict WORM policy when locking objects in the cloud. Instead, S3 uses its versioning capabilities to keep the original object as a protected version over the whole Storage Device Minimum Volume Protection Time duration. Nothing prevents the end users from deleting or overwriting the objects once they have been locked. However, if an object is modified, the protected version can always be retrieved manually (see https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html#object-lock-overview ).