• Add destination with MBS API
    Noted, and done, thanks!
  • Decryption of files without the client
    There are two related issues at play here. The first deals with end-of-service/disaster data recovery. In the event that we choose to stop using CloudBerry, then repatriating the data is simple: we use the client. However, if, for any reason, the CloudBerry servers themselves become unavailable, it is impossible for us to repatriate the data, even though it stills exists in the cloud storage.

    Second, we require control of the client-side encryption keys, which CloudBerry does not at this moment provide. We do control the passphrase used to generate the key, but we have no way of generating the encryption key ourselves.

    That is indeed what we are using in the meantime.

    Thanks for responding,
  • Decryption of files without the client
    I just caught the "standalone" before CloudBerry Backup. I am working with CloudBerry Managed Backup, as we plan to offer a backup service internally.

    I hope you can revisit your decision not to share these details, as the solution might not meet Government of Canada's security requirements as it is, and we have might have to move to another solution for backup/archiving data.

    Thank you for always answering my questions!
  • User prefix in the S3 bucket
    In case somebody was wondering, this is how you'd determine the random ID given to a user using the API.

    # -- Start a requests Session.
session = requests.Session()

# -- Get an access token the API credentials generated in the management
# -- console, and prepare the header for future requests.
response  = session.post("https://api.mspbackups.com/api/Provider/Login",json={"UserName": config['mbs_api_auth']['UserName'], "Password": config['mbs_api_auth']['Password']})
json_test = json.loads(response.text)

session.headers = {"Accept": "application/json",
                   "Authorization": "Bearer {}".format(json_test['access_token'])}

# -- Get the list of users.
response  = session.get("https://api.mspbackups.com/api/Users")
user_list = json.loads(response.text)

# -- Determine the user ID from their user account, stored in the email field
# -- for some reason.
for element in user_list:
  if element['Email'] == args.user:
    print("User {} has ID {}".format(args.user,element['ID']))
  • Decryption of files without the client
    Ok.

    Making internal encryption methodologies public does not make them less secure, though.
  • Decryption of files without the client
    Why is not possible? I don't see any technical limitation. I just need to be able to use the PBKDF with the same salt and I should be able to generate the AES256 key that was used to encrypt the data.
  • User prefix in the S3 bucket
    Will that also work with the API?
  • Client-side encryption
    Ok. I'll just recap to make sure I got everything right.

    The password is stored encrypted in the client configuration file, is decrypted at plan execution time by fetching the AES key from CloudBerry's servers. The key is used locally to encrypt the data that needs to be uploaded during that backup plan's execution.

    Is the password stored in its encrypted form in the Remote Deploy pane of the Management Console, or is it elided from the configuration file completely?
  • Client-side encryption
    Thanks for the link, that's very helpful!

    From this documentation, since CloudBerry controls (it has to, in fact) the AES key used to encrypt the password, it means that CloudBerry has the capability of recovering the encryption passphrase, and, thus, the encryption key. Is this correct?
  • Client-side encryption
    So, I'm guessing that the passphrase is taken through a PBKDF or some other cryptographic process to generate a key from the passphrase?
  • Remote Deploy: Configuration file format documentation
    Ok, thanks for the response.
  • Remote Deploy: removing a Backup plan from a configuration doesn't remove it from the client
    Ok, I'll make a note of that. Thanks!
  • Remote Deploy: Configuration file format documentation
    Ok.

    What I would have liked is for a plain-text configuration file that I could pass to the Configuration & Rules API (the API for which I have a feature request ;) )­.

    As you probably guessed from my comments in the last few days, I'm trying to automate management of the service as much as possible.
  • Remote Deploy: configuration not applied when changing user
    Sorry, that's on me.

    I created a new configuration, but for Windows instead of MacOS/Linux. When I changed it to MacOS/Linux and opened the client again, the new configuration was pushed.

    The old backup plan was still present and active. It's probably a good idea to keep it there, but something to keep in mind when managing the service.
  • Custom client configuration
    ↪David Gugick
    Good, thanks! In my use case, we'd like to enforce some basic settings, like the storage destination, the use of client-side encryption, but leave the include/exclude options to the user, for example.

    In general, it would be nice to have granular "permissions" for users on backup plans. For instance, the user could be allowed to create new plans as long as it follows some rules, or not have permission to create new plans and be allowed to edit only some settings of an existing plan.

    As for the API, I would like to create new configurations, edit configurations, create new rules and edit existing rules with the API. In short, I'd like to do everything I can do with the console with the API.

    Thank you so much for your responsiveness, it means a lot!
  • Custom client configuration
    ↪David Gugick
    Thank you David for the answers. If I understand correctly, setting a master password would preclude a user from opening the client on their own computer (please correct me if I'm wrong). I'm looking for something more granular, say: the user can change the contents of the backup (include/exclude), but not the remote storage or the client-side encryption setting.

    If it's not granular, it means I need to setup a master password and manage all backup plans myself.

    Moreover, I'd like for the API to have all the features of the management console, so I can automate pretty much all management tasks. Is that something you're looking to do in the future?
  • Custom client configuration
    Hmm, there seems to be no way to force a user to use client-side encryption though. In my case, I would want to manage the encryption for the user, so I wouldn't even want the user to be able to turn off that option in a given backup plan, and reject the creation of backup plans that do not use client-side encryption.
  • Custom client configuration
    Is this functionality exposed through the API? I'd like to automate the creation of configuration deployments.
  • Custom client configuration
    Oh ok cool, I seem to have missed this option entirely when going through the UI! This does pretty much everything I need. Thanks!
Home » JoeyDumont