In this article, you will learn about some recent data leaks and how to keep your sensitive data safe by implementing encryption and IAM policy best practices.
Recent Public Data Breaches
Great security leaks happen because of human factors, not technical drawbacks. Here are a few examples of recent big data leaks, all with a common cause – administrators or users did not correctly configure data access restriction policies:
- Dow Jones, the world’s leading financial information agency, was affected by an Amazon Web Services (AWS) cloud data leakage because of user error and wrong bucket access restriction configuration. Names, email addresses and financial information of about 2 million customers were exposed.
- NICE Systems, a third-party vendor for Verizon, misconfigured cloud-based file repository, exposed the names, addresses, account details, and account PINs of 14 millions Verizon customers. The Amazon S3 data repository was configured to allow public access to call logs which included the above-mentioned data.
- Republican National Committee (RNC) voter database, was left exposed to any unauthorized user. As it was later discovered, this happened due to misconfigured AWS security policies.
These accidents uncovered complex and unapparent data access settings in AWS; it is all too easy to share a directory, not only with someone’s colleagues but with the rest of the world. There is also one thing worth mentioning, in each aforementioned case – the data stored was encrypted, but easily accessible by those who had a public link. So, if someone gets access to data which has been publically exposed, nothing prevents them from being able to download said information and use it against the true data owner.
Fortunately, there are a few best practices that can help you prevent your own data leaks and protect sensitive data, even in unauthorized access cases.
Protecting Your Data
Speaking of cloud storage, you need to cover two basic areas to protect your data from unauthorized access and usage:
- Ensure no one from the outside can access sensitive data. For most cases, it is a good idea to leave cloud buckets (like folders in general) private and give access to some users or groups, temporarily, or only when necessary.
- Keep the cloud data encrypted. In case data is stolen, the perpetrator will not be able to read its contents, nor use it against your company.
Over the next few chapters, we will detail particular properties to consider when implementing granular data access and encryption: access management mechanism choosing and encrypting data using a personal server’s key.
Implementing Access Management Policies
Amazon Web Services’ file buckets – are the main object for data collaboration. Each bucket has a unique name and URL that you can give to any user, even those outside of your company. However, the user can only gain access by being on the bucket’s Access Control List (ACL). Complications can arise here, as the bucket owner can allow any user access, simply to save time of configuration, on such a complex thing. Let’s overview the basics of AWS Identity and Access Management (IAM) policies.
You can create users in IAM, assign them individual security credentials or request temporary security credentials, to provide users access to AWS services and resources.
First of all, you need to create personal IAM User accounts in AWS Management Console for all users who need cloud data access. Avoid using common accounts with the same KEY-SECRET pairing for a group of users. There are two types of IAM accounts:
- Programmatic access – use it when you need to grant access to API calls or data objects, for a user or group.
- AWS Management Console access – use it only when you need to grant AWS Console management access. For example, this account type is necessary for AWS administration delegation.
Next, create a group for any resources you’d like to share (e.g. data bucket). AWS security groups are one of the best of IAM policy best practices when it is required to” include all user accounts needed in the same access level. Now you are ready to create IAM Access Policy.
Access Policy lets you configure the following:
- Actions you will allow – each AWS service has its own set of actions.
- Resources you allow the action on – users cannot access any resources that you have not explicitly granted permissions to.
- Effect (allow or deny) while accessing data – all resources are denied by default; you have authority over all access rights, for each user.
Policies are JSON documents, typically depicted as per below:
- Choose the Effect desired (Allow or Deny) and select the AWS service access that you want to restrict.
- Select the actions you want to allow or deny. You can specify All Actions or individual actions. Remember, that general good practice is to limit resource access as much as possible.
- Type the resource to which you want to allow or deny access. Some operations allow only «Resource»:»*» while others allow you to specify the Amazon Resource Name (ARN) of individual resources. You can include an asterisk (*) as a wildcard in any field of the ARN.
- Repeat steps 1-3 for any additional statements you would like to specify.
Finally, you need to assign it to a resource access group after creating access policy.
If using CloudBerry Explorer for Amazon S3, you can manage IAM Policy without AWS Management Console. IAM Manager features allow you to:
- Create and manage IAM policies.
- Manage user accounts and groups.
- Create and assign security policies.
Create user accounts and groups using Access Manager (IAM):
- Click Access Manager (IAM) on the main menu and then select Access Manager from the submenu, allowing you to manage user and group accounts.
- You can create a new user in the group by selecting on the left, or modify existing user accounts. The same can be repeated with groups.
- When creating the new user you can even create his/her access and secret keys right in CloudBerry Explorer UI. Right-click newly created user and select Manage Access Keys.
Note that you can access user keys only when they are created – save access and secret keys in the safe place during creation session. If you lose the keys, you will have to create new ones and reconfigure the software that uses this user’s account.
What is exciting in the new CloudBerry Explorer for Amazon S3 PRO is that you can even create IAM Policies using the app’s simple constructor. Just select the service you want to configure access to, select group or user(s) and check actions you wish to permit or deny.
IAM Policy Manager in CloudBerry ExplorerCloudBerry IAM policy manager has the same mechanism as AWS Console, but with a simpler user interface.
Protect Data with Encryption
Amazon S3 Cloud supports two variables of encryption:
- Server-Side Encryption – Amazon S3 will encrypt your data before saving it on disks, and decrypt it when you download the data.
- Client-Side Encryption – allows data encryption on the client’s side and then uploads it to Amazon S3. In this case, user manages the encryption process, keys, etc.
Server-side encryption, with a password on the server’s side, is convenient and transparent for users, but it only protects the data at rest. If someone should access the raw disks for the AWS bucket without proper security credentials, they’ll get a lot of useless encrypted files. However, if they access the files because of incorrect user-privileges, AWS happily decrypts the data at access time. The data leaked from the breaches mentioned above likely did not implement any encryption or used something like server-side encryption. This type of encryption is automatic on the AWS side.
You can avoid that scenario by using server-side encryption with a user password.
If you set a user’s password, any application requiring a download of data will have to provide a custom password, so that AWS servers can decrypt the data. Technically, your app should simply supply the desired key, as part of a GET request. Then S3 will decrypt the data, taking care to expeditiously remove the key from memory.
You can encrypt and decrypt your data using AWS Server-Side Encryption, and custom key with CloudBerry Explorer PRO for Amazon S3. Just open the Tools – Options window, choose the Compression and Encryption tab and paste your key ID in the corresponding field. You can also create a custom key using PowerShell.
Managing Server-Side encryption using CloudBerry Explorer for Amazon S3 UI.
Client-side encryption -is a type of encryption that encrypts data on the client side, prior to upload. It is considered to be safer than server-side encryption without a user-selected key as the encryption key is held by user. Encrypted data travels over the internet with an additional layer of encryption (in addition to the SSL/TLS encryption used with the secured connection). Like server-side encryption with a user-defined password, any data leaked because of a security access misconfiguration will remain encrypted and unusable.
In CloudBerry Explorer PRO there is an option to encrypt data using military-state AES-256 encryption algorithm. Simply go to Tools|Options|Compression and Encryption and choose Use Client-Side Encryption.
CloudBerry Explorer for Amazon S3 UI has an ability to enable or disable server-side encryption with Amazon-provided keys. Just right-click the desired bucket and select the Server-Side Encryption option.