Object storage platforms, such as Amazon S3 are evolving at a rapid pace. The Amazon S3 API has become a de facto standard alongside other platform like OpenStack Swift and Ceph, and with that progression, it brings us many new features and integrations.
One such feature I’d like to focus on is Amazon’s Identity and Access Management System (IAM), which provides both identity management and access control across their suite of AWS products. In relation to Amazon S3, you can use IAM to provision access/secret keys and control what operations certain accounts are able to perform. For example, with IAM and S3, we could restrict the buckets an account has access to, allow read-only access to objects with specific prefixes, and permit uploading objects with a predefined prefix.
When organisations are looking to roll out an object storage system, like S3, within their organisation, it’s common for them to look at IAM as their solution to permissions and access management. It’s also something that Amazon actively promote:
Following Amazon’s suggestions you could implement a very basic form of access control on your objects within your bucket. But what are the issues with their suggested approach?
The first thing to note is that AWS IAM policies can get very complex. There is a lot of power and flexibility, but things can get complicated quickly, particularly if there are many accounts and/or buckets and many users who require access privileges..
Our experience is that in these scenarios the IAM policy will not scale very well. Every time a new staff member or a new customer requires access to the storage, you’ll need to provision them with an IAM account and modify your IAM policy to reflect this. Additionally, the IAM policy management is not very user-friendly, so it will need to be changed by someone who is experience at managing the policy file, and there is no way to clearly indicate through the IAM policy which users have access to which resources.
Secondly, there exists opportunities for users to be able to list the contents of other users home directories. As a non-administrator, being able to list the contents of other users personal files (confidential or not) presents a huge risk with respect to confidentiality and compliance, particularly in relation to the forthcoming GDPR initiative.
Finally, from a governance and compliance point of view, there is no business level logging of end-user actions. Cloud Trail can of course be setup but any compliance auditor would need to understand who has access to which files, and which users can see which files, and why. With IAM policies, it is very difficult to achieve this.
In summary, although IAM may be able to provide an elementary level of protection, it’s rough edges begin to show when we start to evaluate object based permissions. It’s just not built for this.
Now lets move onto the actual S3 resources. S3 is organized around the concepts of Buckets and Objects (rather than servers with files).
S3 Buckets are a root level storage resource within S3. Normally bucket access is as narrowly aligned as possible in terms of its access and how it is used ie. it is normally dedicated to a single task or resource. Many of the breaches that make the news are more often than note public facing bucket breaches.
Bucket polices are the permission structures for buckets and they define who, how and where buckets can be accessed. Such policies are either hand generated in JSON or generated from the use of Amazons Policy generator. Such polices can be complex and can often end up with Admin’s sifting through JSON to figure out what is going on!
Both IAM and Bucket policies can be applied simultaneously and access attempts will calculate the least privilege union of the two policies and take action accordingly.
Now consider IAM resource and Bucket Policy management in a scenario with hundreds of S3 accounts, thousands of users and many different access policies !
So what should you do if you want to adopt something like Amazon S3, and care about authentication / authorisation, governance and compliance? Well, we did a lot of work on the access and federation of identity management within the Enterprise File Fabric solution to provide a simpler solution to some of these types of issues.
You can consider the File Fabric as a centralised unification and governance hub for files (and Objects) that provides:
* Single-Sign-On using your existing identity management system, like LDAP, Active Directory or SAML, and use it to automatically provision end-user accounts
* A visual permissions manager to easily create, manage and review permissions to folders and files allowing IT fine grainer control
* Use the audit log to track every single user event that occurs, like file opens, file sharing and permission changes – across web, desktop, and all devices
* Personal ‘home’ directories, that only those users can access.
* Allow users to access Objects / files across multiple devices, like Mobiles, Tablets and Desktops. Choose between Drive or Folder Sync, and/or best-of-breed application integrations.
* Generate business level reports on who has access to which resources and also business level audit reports on object or file event access
If you’re interested in how Storage Made Easy can help your organisation, sign up for a free, no-obligation trial of the Enterprise File Fabric.
by 
