Table of Contents:

• Accidental Access Key Sharing
• Unintended "Everyone" Permission Setting
• Unintended loss of data
• Unexpected billing due to accidental overage
• Unexpected storage space depletion due to version files

There are risks and considerations when using Research Object Storage (S3).  Below is a selection, but there may be others not listed:

Accidental Access Key Sharing

Anyone that you share your access key and secret with will have full access to your Research Object Storage (S3) account and bucket(s), including read/write and account configuration access.  For example, if you provide a student assistant with your key and secret and they then leave the university, they would still have access to your account unless you deactivate the key. 

Solution:  Please share only with those that absolutely need it.  If you believe that your key and secret have been accidentally shared with others–or if you simply want to disable it– please contact us right away at researchdrive@wisc.edu.  We will disable your old access key and, if desired, issue you a replacement. 

Unintended "Everyone" Permission Setting

You can set an "Everyone" permission on a bucket or individual files, which would allow others to access the files without an access key.  Furthermore, you have the ability to assign this permission "write" and even "full control" of your account, which would allow others to make substantial changes to your account.  If done unintentionally, this would create major security risks for your account.

Solution:  Use this feature carefully.  Never provide an "Everyone" permission with "write" or "full control" access (provide "read" access only if absolutely necessary).  Keep track of which buckets or files you grant this permission to.  To learn how to add/remove the "Everyone" permission (or just check whether it is enabled), see Bucket Creation & Configuration:  "Everyone" Permission (i.e. enabling access without an access key).

Unintended loss of data

If you accidentally delete files and/or buckets, you may not be able to recover them.  This service offers an optional feature called "versioning", which would allow you to recover previous versions of the file(s).  However, you can delete those version files by either removing them directly or deleting the entire bucket.  Once deleted, the version files are unrecoverable.  Furthermore, versioning must first be enabled on user-created buckets and is not enabled by default (we have enabled versioning with a 30 day retention policy on your default bucket). 

Solution:  Research Object Storage (S3) is best suited for automated, rather than human-centered, workflows.  Minimize human interaction with files stored on this service to help prevent accidental data deletion.

Unexpected billing due to accidental overage

Eligible researchers receive a 50TB no cost cost storage subsidy provided through campus support.  When your account was created, we provided you with a pre-made "default" bucket that has a 50TB storage cap applied to it, meaning you cannot upload more than 50TB (unless you request additional fully billed space).  This minimizes the risk that you will exceed the subsidized storage and be billed for additional storage used.

If you create additional buckets beyond the default bucket, those bucket will not have a storage cap set and you could exceed your 50TB no cost storage subsidy.  Any storage beyond the subsidy will be billed at the current rate. 

Solution:  To minimize the risk of exceeding your 50TB storage subsidy, please store all data within the default bucket.

Unexpected storage space depletion due to version files

Versioning files, which are created anytime a file is added to or edited within a bucket with versioning enabled, consume storage space and count against your no cost subsidy.  The longer you retain versions, the more storage space they consume.   

Any additional buckets you create will NOT have versioning turned on by default.  If you choose to enable this feature within a bucket you create, the default version "lifecycle" (i.e. how long the version is kept) will be "forever", meaning version files will never be deleted by the system.

If you edit files frequently and versions are set to never expire, you could "fill up" your storage quickly with versioning files.  Furthermore, version files within user-created buckets might cause you to exceed your no cost subsidy and incur fees without realizing it (see "unexpected billing due to accidental overage" above).

Solution:  Only store data in the default bucket we created for you.  Versioning is turned “on” by default for the default bucket and assigned a lifecycle of 30 days.   This lifecycle helps ensure that you can recover from data loss within the last month but also helps to prevent you from using up all of your storage and risking charges on old version files.